TGStat
TGStat
Введите текст для поиска
Расширенный поиск каналов
  • flag Russian
    Язык сайта
    flag Russian flag English flag Uzbek
  • Вход на сайт
  • Каталог
    Каталог каналов и чатов Региональные подборки Тематические подборки Платные каналы Поиск каналов
    Добавить канал/чат
  • Рейтинги
    Рейтинг каналов Рейтинг чатов Рейтинг публикаций
    Рейтинги брендов и персон
  • Аналитика
  • Поиск по публикациям
  • Мониторинг Telegram
  • Продвижение
    Реклама через Яндекс Бизнес Реклама в каналах через TGStat Agency Реклама на сайте TGStat.ru
Дата канальи

1 Aug 2025, 13:45

Открыть в Telegram Поделиться Пожаловаться

#кейсы #ML #корпжиза

Пока кто-то разрабатывает модели для работы с неструктурированными данными, KPI каналий на внедрение LLM заставляет решать проблему по-другому:

(утащил с гз-шного форума)
Продолжаю наблюдение за приближением дня, когда машины восстанут из пепла ядерной войны. И вот что приходится наблюдать в процессе разработки замены планктону. Есть некоторый бизнес-процесс, в котором есть неструктурированные данные в виде некоторых отчетов. Эти отчеты пишут одни сотрудники организации, а читают другие. Отчет в целом в достаточно свободной форме, т.к. может описывать достаточно широкий круг событий, и предполагается, что читающие этот отчет обладают определенной квалификацией (и соответственно стоят дорого). Раскрывать детали процесса именно в этой организации я не имею желания, но в качестве похожего примера можно привести финансового аналитика, например CFA, который читает отчет эмитента и дальше использует данные отчета в своих гнусных целях. Эмитенты, как известно, многие свои отчеты пишут в относительно свободной форме.

В процессе разработки "агента", который заменит дорогого CFA возникают естественные на текущем этапе развития технологии трудности. На имеющемся потоке документов нужно слишком много few-shot-ов, чтобы этот несчастный агент хедо-бедно работал. Или нужен дополнительный SFT, или еще того хуже RLHF / DPO, чтобы он хотя бы справлялся чаще, чем не справлялся (про accuracy ~99% там речи даже близко не идёт). Проблема в том, что документы достаточно разнообразны. Ну и естественно, чтобы повысить accuracy (и получить бонус) разработчики и их менеджеры выдвигают крамольные идеи, например: а почему бы нам не сделать данные более структурированными? Скажем, например, что в отчете должны быть определенные разделы. И таких разделов должно быть много, чтобы отвечать на все необходимые вопросы, и LLM могла бы легче извлечь правильные данные или ответить на вопрос. Так вот, в текущем процессе так и происходит: к писателям возникают требования структурировать отчеты. Существенно детализируется перечень информации, который обязательно должен быть в отчете. Разрабы составляют "идеальные отчеты", которые LLM точно прочитает правильно (т.к они есть во few-shot) и приводят их в пример писателям отчетов. Данные становятся более структурированными, а значит автоматизация планктона постепенно становится проще. Собственно очевидный вывод: то, что раньше даже в голову не приходило автоматизировать, сейчас начинают шатать не только со стороны LLM, но и стороны неструктурированных данных. А значит рано или поздно все данные станут достаточно структурированными, чтобы планктон стал не нужен.
Интересная
точка зрения и кмк более перспективный подход

У вас в компаниях тоже процесс оструктурирования всего чего можно?

2.2k 5 15 4 22
Каталог
Каталог каналов и чатов Подборки каналов Поиск каналов Добавить канал/чат
Рейтинги
Рейтинг каналов Telegram Рейтинг чатов Telegram Рейтинг публикаций Рейтинги брендов и персон
API
API статистики API поиска публикаций API Callback
Наши каналы
@TGStat @TGStat_Chat @telepulse @TGStatAPI
Почитать
Академия TGStat Исследование Telegram 2019 Исследование Telegram 2021 Исследование Telegram 2023
Контакты
Справочный центр Поддержка Почта Вакансии
Всякая всячина
Пользовательское соглашение Политика конфиденциальности Публичная оферта
Наши боты
@TGStat_Bot @SearcheeBot @TGAlertsBot @tg_analytics_bot @TGStatChatBot