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

(утащил с гз-шного форума)

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

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

Интересная точка зрения и кмк более перспективный подход

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

Курс по Базе ML мы с Витей и Ильей Ирхиным запустили год назад — для тех кто хочет детально разобраться как все устроено, а решать зубодробительные задания в ШАД в планы не входит.

И несмотря на то что уж казалось бы что нового можно было сделать в базе, мы продолжали курс улучшать

Вот уже и третий поток запускаем 5 августа

Велкам!

Напомню формат — 4-6 мес (зависит от начального уровня, есть подготовительные модули по статистике и питону — ведет их Дима)

По вопросам отвечает замечательная Марина

Вот и фоточки с митапа подъехали

Кейс из двух частей

Часть 1

Лет пять назад в одной сети по продаже техники решили попробовать ML, но относились с недоверием.

Куда ML применить в ритейл? Повысить продажи, например.

Как вообще происходит управление продажами крупной сети?

Если совсем на пальцах:
1) Для каждой точки продаж строится прогноз — сколько они продадут в следующем месяце.
2) Это число умножается на повышающий коэффициент — тн «амбицию» и объявляется бизнес-планом точки на сл месяц.
А сам процесс называется бизнес-планированием.

3) Далее в дело вступает перфоманс-менеджемент — выполнившим бизнес-план — 🤝премия (или грамота — зависит от), невыполнявшим — развитие 🤕.

ML в бизнес-планирование было решено внедрять в 2 этапа:

1) На пилоте (на части точек продаж) убедиться что с помощью ML прогнозы получаются точнее чем текущий у аналитиков (линейный прогноз на трех лагах)
2) Если ML точнее — пропилотировать план с амбицией, отсчитанной уже от ML-прогноза

Если по итогам продажи растут — молодцы 🙌

Итак, на первом этапе посчитали что понадобится 4 месяца для пилота

Команда аналитики дала свой прогноз, команда ML— свой (чуть покрутили prophet)

Но через 2 мес CEO решил оба прогноза увеличить на 8% и спустить пилотным точкам 🤣
До конца пилота оставалось 2 мес

Здесь просится голосовалка

Часть 2 (грустная)

Проходит сельскохозяйственная конференция.
Встает француз:
— Мы сеем картошку 15 мая, а снимаем урожай 16 сентября.
Встает англичанин:
— Мы сеем картошку 15 апреля, а урожай снимаем 16 августа.
Встает чукча:
— Мы сеем картошку 15 июня, а снимаем урожай 16 июня.
— Через день? А почему так рано?
— Очень кушать хочется.

Убедили CEO больше ничего не трогать, перестроили модель получше (заодно и от prophet отказались), запустили новый пилот, уже на 2 мес.

ML победил прогноз аналитиков со счетом 18 % MAPE vs 25% MAPE

Пора переходить ко второму этапу пилота?

Если бы так — то анекдот в начале поста был бы зря 🤣

После того как план стал точнее больше сотрудников стали его выполнять!! -> компании пришлось больше потратиться на премии
На этом эксперимент с ML был признан убыточным 🤦‍♂️

Аналитики, правда, скрипты обучения модели попросили )

Но, конечно, как и в ценообразовании, нужно было происследовать эластичность выручки от плана и делать модель мотивации (то есть включать амбицию в модель) с учетом этой эластичности

Консультирование — неблагодарное дело — за деньги час слушаешь (смеяться нельзя) и 5 минут говоришь.
Слушать в тысячу раз тяжелее.
Но иногда отказаться нельзя.

Итак, одна североамериканская компания зарабатывает на опросах — пользователь попадает на сайт, ему за копеечку предлагают ответить на ряд вопросов, вопросы разные по сложности — где-то галочку в чекбокс поставить а где-то и текстом записать — и оплачиваются тоже они по-разному. Потом эти данные компания перепродает с наценкой, тем и живет.

За одну сессию кто-то отвечает на пару вопросов, а кто-то на 20-30, и выручка c каждого пользователя разная.

Задача ML-команды так подбирать вопросы пользователю (сразу учитывая отклик — ответил он на текущий вопрос или нет) так чтобы растить ARPU — Average Revenue Per User — упрощенно, вероятность того, что пользователь на вопрос ответит, умножить на стоимость вопроса в долларах — такое вот мат ожидание.

Проблема у команды классическая — NDCG (точность ранжирования моделью -- то есть правильность порядка выбора вопросов) на оффлайне высокий, в эксперименте тоже, но A/B по ARPU не прокрасился 🤷.

В чем может быть проблема и как исправить ситуацию? Пишите в комментах 💡

Свой ответ поставил в отложку на через сутки ) небольшая подсказка -- кейс в тематике канала )

на этой неделе уже было одно реальное письмо счастья (в начале сл. недели выложу), но вот это неожиданно (видимо Jure свой аккаунт дал продажникам в управление, но как же приятно)

PS Jure Leskovec -- топ#1 человек в мире графовых нейронок (GNN)

Вау!!! Искренне поздравляю ребят!

с радостью отмечу что в этот раз ребята выступали под своим флагом 🇷🇺

Итак, развязка вчерашней задачи

Я большой любитель каскадов моделей (выше был пример в кейсе про недвижку)
Потому конечно же посоветовал построить модель обрыва сессии, сделать онлайн калибровку, и полученную вероятность учитывать в формуле мат. ожидания

На оффлайне эта модель выбила 0.75 ROCAUC, в новом эксперименте 0.8 ROCAUC — модель получилось сильной (оно и неудивительно, топ-фичи — прокси на трудоемкость вопроса для пользователя)

Что же пошло не так?

❗️ Факт 1. Вместо сплита на A/B по пользователям сплит был по сессиям — то есть один и тот же пользователь мог появиться в разных сессиях в разных группах -- и в тестовой и в контрольной

Но это не самое главное и достаточно часто встречается.

‼️Факт 2:

После того как модель выбирала вопрос, который показать следующим, на стороне бэка включались пост-фильтры — например, входит ли юзер в релевантный сегмент и прочее. Если отрабатывал фильтр — бэк снова дергал ручку модели, ровно с тем же набором фичей 🤣🤦‍♂️😂😂😂🙈🏆💎.

Как вы думаете, к чему же такой запрос приводил?

Правильно, к тому что модель давала ровно такой же ответ, цикл повторялся 700-800 раз до тайм-аут и разрыва сессии , интерфейс у пользователя все это время висел. Отловили ручным тестированием.

Век живи — век учись. И старайся фильтровать до модели!

Спойлер 👀

Ждем сегодня подробного поста про статью от первого автора (со ссылкой на архив конечно же) 🦄

Заодно познакомлю вас с ее каналом -- интрига 👻

Меня часто спрашивают сколько займет по времени вырасти от джуна до синьора / лида.

Обычно я в пример привожу Дашу
В начале 22го она пришла к нам джуном (кстати взяв 4е место в нашей сореве)

Несколько месяцев она уже лидит RnD-группу нейросетевых рекомендаций в МТС \ MWS.

Но на этом она не останавливается — не так уж и сложно было ее убедить опубликовать свои идеи в статье на RecSys’25, что стоило не только новогодних и майских праздников, а еще и много нервов 🙃.

А на днях Даша еще и канал завела — не стесняйтесь подписываться!

PS
ссылочка любителям сюжетов про быстрый рост 😃

"eSASRec: Enhancing Transformer-based Recommendations in a Modular Fashion»

Нашу статью приняли на ACM RecSys 2025! (arxiv).
Совместная работа с Никитой Зелинским, Сашей Петровым, исследователями из МТС (и экс-МТС), а также с Андреем Савченко.

В работе мы представляем модульный взгляд на классические трансформерные бейзлайны в RecSys и ищем наиболее эффективную архитектуру (собранную по принципу лего), которая показывает хорошее качество в самых разных сетапах - от привычной LOO валидации на небольших академических датасетах до парето-оптимальности (в рамках NDCG / Beyond-Accuracy качества) на тайм сплите. Финальная связка - которую мы назвали eSASRec - получилась из «Shifted Sequence" задачи обучения (как в SASRec), LiGR архитектуры слоёв трансформера (как в продовой модели LinkedIn из «From Features to Transformers…») и Sampled Softmax лосса (тут без сюрпризов, хотя стоит сказать, что gBCE был очень близок по качеству, но не всегда быстро сходился).

На самом деле, в рамках этой достаточно долгой работы (первые экспы начались больше чем полгода назад) мы отвечали и на более широкий спектр вопросов. В академии есть свой заданный «порядок» для написания статей, и мы не могли добавить никаких выводов сверх основного фокуса работы. Так что вот основные официальные выводы статьи: есть обновленный SASRec, и он хорош во всех сетапах, в которых мы его тестили. Например, он даёт взрывные +23% от качества ActionPiece и TIGER в академических бенчмарках. А ещё в терминах парето-оптимальности он держит качество на уровне HSTU и FuXi, хотя в отличие от последних не использует таймстемпы ни в истории пользователей, ни при формировании рекомендаций. Ещё eSASRec максимально просто имплементировать и он не имеет проблем с масштабированием (тут спасибо LinkedIn за архитектуру). И мы открываем доступ к нашим имплементациям и коду бенчмарков.

А теперь - что в статью не вошло, и о чём можно было бы подискутировать).

Лично для меня помимо определения современного бейзлайна самым интересным был вопрос - можно ли верить SOTA клеймам на основе академических RecSys датасетов?

Я отвечу для начала очень простым примером из наших результатов: классическая LOO валидация на самых популярных датасетах Амазона показала, что давно известный вариант SASRec+SS без каких-либо обновлений уже давал те самые +23% к качеству ActionPiece и TIGER. Просто никто этот вариант на данных датасетах в качестве бейзлайна не заводил. А завели вариант BCE, 1 негатив, имплементация RecBole, 5 лет назад - и с тех пор только копипастили из статьи в статью. Значит ли это, что SASRec+SS такая уж «SOTA» рядом с TIGER?

По моим ощущениям (мы же дискутируем?), результаты на Amazon Beauty/Sports/Toys в целом не то чтобы отражали реальную полезность моделей - они явно отдают предпочтение более простым архитектурам. Например, оптимальные гипер-параметры там: 1 слой трансформера, 1 голова, количество факторов 64. А ещё HSTU и FuXi на этих датасетах тоже ощутимо «проигрывают» старенькому SASRec+SS. Хотя на Мувиленсе - уже ощутимо “выигрывают”.

Про тайм сплит и beyond-accuracy: мы в статье отмечаем эффективность моделей индикаторами Парето-оптимальности. Это позволяет хоть немного делать выводы о результатах архитектур между разными датасетами (пока нет общепринятого академического подхода для оценки степени трейд-оффа точности и “персонализации”). Наши выводы - что есть архитектуры, которые оставались Парето-оптимальными на всех тестовых датасетах (например, HSTU и eSASRec). Но даже между ними нельзя сказать заранее, какая модель окажется выше по NDCG, а какая - выше по Coverage, всё сильно зависит от данных. Не самый утешительный вывод в ML, где мы привыкли к "вот это State-of-the-Art - и ." Зато честный.

Спасибо всем, с кем мы вместе сделали эту работу ❤️

Пока придумывал броские заголовки постов для сл недели, наткнулся на бесплатный завтрак (в оригинале Free Lunch), который-таки приняли на SIGIR'25 (топовая конфа, кажется A*):

InfoNCE is a Free Lunch for
Semantically guided Graph Contrastive Learning

PS: речь об отсылке к No free lunch theorem

🧀😆