Пока кто-то разрабатывает модели для работы с неструктурированными данными, KPI каналий на внедрение LLM заставляет решать проблему по-другому:
(утащил с гз-шного форума)
У вас в компаниях тоже процесс оструктурирования всего чего можно?
(утащил с гз-шного форума)
Продолжаю наблюдение за приближением дня, когда машины восстанут из пепла ядерной войны. И вот что приходится наблюдать в процессе разработки замены планктону. Есть некоторый бизнес-процесс, в котором есть неструктурированные данные в виде некоторых отчетов. Эти отчеты пишут одни сотрудники организации, а читают другие. Отчет в целом в достаточно свободной форме, т.к. может описывать достаточно широкий круг событий, и предполагается, что читающие этот отчет обладают определенной квалификацией (и соответственно стоят дорого). Раскрывать детали процесса именно в этой организации я не имею желания, но в качестве похожего примера можно привести финансового аналитика, например CFA, который читает отчет эмитента и дальше использует данные отчета в своих гнусных целях. Эмитенты, как известно, многие свои отчеты пишут в относительно свободной форме.Интересная точка зрения и кмк более перспективный подход
В процессе разработки "агента", который заменит дорогого CFA возникают естественные на текущем этапе развития технологии трудности. На имеющемся потоке документов нужно слишком много few-shot-ов, чтобы этот несчастный агент хедо-бедно работал. Или нужен дополнительный SFT, или еще того хуже RLHF / DPO, чтобы он хотя бы справлялся чаще, чем не справлялся (про accuracy ~99% там речи даже близко не идёт). Проблема в том, что документы достаточно разнообразны. Ну и естественно, чтобы повысить accuracy (и получить бонус) разработчики и их менеджеры выдвигают крамольные идеи, например: а почему бы нам не сделать данные более структурированными? Скажем, например, что в отчете должны быть определенные разделы. И таких разделов должно быть много, чтобы отвечать на все необходимые вопросы, и LLM могла бы легче извлечь правильные данные или ответить на вопрос. Так вот, в текущем процессе так и происходит: к писателям возникают требования структурировать отчеты. Существенно детализируется перечень информации, который обязательно должен быть в отчете. Разрабы составляют "идеальные отчеты", которые LLM точно прочитает правильно (т.к они есть во few-shot) и приводят их в пример писателям отчетов. Данные становятся более структурированными, а значит автоматизация планктона постепенно становится проще. Собственно очевидный вывод: то, что раньше даже в голову не приходило автоматизировать, сейчас начинают шатать не только со стороны LLM, но и стороны неструктурированных данных. А значит рано или поздно все данные станут достаточно структурированными, чтобы планктон стал не нужен.
У вас в компаниях тоже процесс оструктурирования всего чего можно?
1👍12❤4🔥3
Курс по Базе ML мы с Витей и Ильей Ирхиным запустили год назад — для тех кто хочет детально разобраться как все устроено, а решать зубодробительные задания в ШАД в планы не входит.
И несмотря на то что уж казалось бы что нового можно было сделать в базе, мы продолжали курс улучшать
Вот уже и третий поток запускаем 5 августа
Велкам!
Напомню формат — 4-6 мес (зависит от начального уровня, есть подготовительные модули по статистике и питону — ведет их Дима)
По вопросам отвечает замечательная Марина
И несмотря на то что уж казалось бы что нового можно было сделать в базе, мы продолжали курс улучшать
Вот уже и третий поток запускаем 5 августа
Велкам!
Напомню формат — 4-6 мес (зависит от начального уровня, есть подготовительные модули по статистике и питону — ведет их Дима)
По вопросам отвечает замечательная Марина
mlinside.ru
Курс Базовый ML
1❤8👍5🔥4🦄2👎1🎉1
Вот и фоточки с митапа подъехали
belofoto.ru
MTC True Tech, Summer Cinema by KION
Фотограф Ольга Белова
🔥9❤4
Кейс из двух частей
Часть 1
Лет пять назад в одной сети по продаже техники решили попробовать ML, но относились с недоверием.
Куда ML применить в ритейл? Повысить продажи, например.
Как вообще происходит управление продажами крупной сети?
Если совсем на пальцах:
1) Для каждой точки продаж строится прогноз — сколько они продадут в следующем месяце.
2) Это число умножается на повышающий коэффициент — тн «амбицию» и объявляется бизнес-планом точки на сл месяц.
А сам процесс называется бизнес-планированием.
3) Далее в дело вступает перфоманс-менеджемент — выполнившим бизнес-план — 🤝премия (или грамота — зависит от), невыполнявшим — развитие 🤕.
ML в бизнес-планирование было решено внедрять в 2 этапа:
1) На пилоте (на части точек продаж) убедиться что с помощью ML прогнозы получаются точнее чем текущий у аналитиков (линейный прогноз на трех лагах)
2) Если ML точнее — пропилотировать план с амбицией, отсчитанной уже от ML-прогноза
Если по итогам продажи растут — молодцы 🙌
Итак, на первом этапе посчитали что понадобится 4 месяца для пилота
Команда аналитики дала свой прогноз, команда ML— свой (чуть покрутили prophet)
Но через 2 мес CEO решил оба прогноза увеличить на 8% и спустить пилотным точкам 🤣
До конца пилота оставалось 2 мес
Здесь просится голосовалка
Часть 1
Лет пять назад в одной сети по продаже техники решили попробовать ML, но относились с недоверием.
Куда ML применить в ритейл? Повысить продажи, например.
Как вообще происходит управление продажами крупной сети?
Если совсем на пальцах:
1) Для каждой точки продаж строится прогноз — сколько они продадут в следующем месяце.
2) Это число умножается на повышающий коэффициент — тн «амбицию» и объявляется бизнес-планом точки на сл месяц.
А сам процесс называется бизнес-планированием.
3) Далее в дело вступает перфоманс-менеджемент — выполнившим бизнес-план — 🤝премия (или грамота — зависит от), невыполнявшим — развитие 🤕.
ML в бизнес-планирование было решено внедрять в 2 этапа:
1) На пилоте (на части точек продаж) убедиться что с помощью ML прогнозы получаются точнее чем текущий у аналитиков (линейный прогноз на трех лагах)
2) Если ML точнее — пропилотировать план с амбицией, отсчитанной уже от ML-прогноза
Если по итогам продажи растут — молодцы 🙌
Итак, на первом этапе посчитали что понадобится 4 месяца для пилота
Команда аналитики дала свой прогноз, команда ML— свой (чуть покрутили prophet)
Но через 2 мес CEO решил оба прогноза увеличить на 8% и спустить пилотным точкам 🤣
До конца пилота оставалось 2 мес
Здесь просится голосовалка
❤6🐳5👍2😁1
Какой прогноз оказался ближе всего к факту (считали по MAPE) по итогам пилота?
Anonymous Quiz
24%
Прогноз аналитиков
26%
Прогноз аналитиков, увеличенный на 8%
28%
Прогноз ML
23%
Прогноз ML, увеличенный на 8%
Часть 2 (грустная)
Убедили CEO больше ничего не трогать, перестроили модель получше (заодно и от prophet отказались), запустили новый пилот, уже на 2 мес.
ML победил прогноз аналитиков со счетом 18 % MAPE vs 25% MAPE
Пора переходить ко второму этапу пилота?
Если бы так — то анекдот в начале поста был бы зря 🤣
После того как план стал точнее больше сотрудников стали его выполнять!! -> компании пришлось больше потратиться на премии
На этом эксперимент с ML был признан убыточным 🤦♂️
Аналитики, правда, скрипты обучения модели попросили )
Но, конечно, как и в ценообразовании, нужно было происследовать эластичность выручки от плана и делать модель мотивации (то есть включать амбицию в модель) с учетом этой эластичности
Проходит сельскохозяйственная конференция.
Встает француз:
— Мы сеем картошку 15 мая, а снимаем урожай 16 сентября.
Встает англичанин:
— Мы сеем картошку 15 апреля, а урожай снимаем 16 августа.
Встает чукча:
— Мы сеем картошку 15 июня, а снимаем урожай 16 июня.
— Через день? А почему так рано?
— Очень кушать хочется.
Убедили CEO больше ничего не трогать, перестроили модель получше (заодно и от prophet отказались), запустили новый пилот, уже на 2 мес.
ML победил прогноз аналитиков со счетом 18 % MAPE vs 25% MAPE
Пора переходить ко второму этапу пилота?
Если бы так — то анекдот в начале поста был бы зря 🤣
На этом эксперимент с ML был признан убыточным 🤦♂️
Аналитики, правда, скрипты обучения модели попросили )
Но, конечно, как и в ценообразовании, нужно было происследовать эластичность выручки от плана и делать модель мотивации (то есть включать амбицию в модель) с учетом этой эластичности
GitHub
GitHub - facebook/prophet: Tool for producing high quality forecasts for time series data that has multiple seasonality with linear…
Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth. - facebook/prophet
2🔥21😁13❤2👍1🤣1
Консультирование — неблагодарное дело — за деньги час слушаешь (смеяться нельзя) и 5 минут говоришь.
Слушать в тысячу раз тяжелее.
Но иногда отказаться нельзя.
Итак, одна североамериканская компания зарабатывает на опросах — пользователь попадает на сайт, ему за копеечку предлагают ответить на ряд вопросов, вопросы разные по сложности — где-то галочку в чекбокс поставить а где-то и текстом записать — и оплачиваются тоже они по-разному. Потом эти данные компания перепродает с наценкой, тем и живет.
За одну сессию кто-то отвечает на пару вопросов, а кто-то на 20-30, и выручка c каждого пользователя разная.
Задача ML-команды так подбирать вопросы пользователю (сразу учитывая отклик — ответил он на текущий вопрос или нет) так чтобы растить ARPU — Average Revenue Per User — упрощенно, вероятность того, что пользователь на вопрос ответит, умножить на стоимость вопроса в долларах — такое вот мат ожидание.
Проблема у команды классическая — NDCG (точность ранжирования моделью -- то есть правильность порядка выбора вопросов) на оффлайне высокий, в эксперименте тоже, но A/B по ARPU не прокрасился 🤷.
В чем может быть проблема и как исправить ситуацию? Пишите в комментах 💡
Свой ответ поставил в отложку на через сутки )небольшая подсказка -- кейс в тематике канала )
Слушать в тысячу раз тяжелее.
Но иногда отказаться нельзя.
Итак, одна североамериканская компания зарабатывает на опросах — пользователь попадает на сайт, ему за копеечку предлагают ответить на ряд вопросов, вопросы разные по сложности — где-то галочку в чекбокс поставить а где-то и текстом записать — и оплачиваются тоже они по-разному. Потом эти данные компания перепродает с наценкой, тем и живет.
За одну сессию кто-то отвечает на пару вопросов, а кто-то на 20-30, и выручка c каждого пользователя разная.
Задача ML-команды так подбирать вопросы пользователю (сразу учитывая отклик — ответил он на текущий вопрос или нет) так чтобы растить ARPU — Average Revenue Per User — упрощенно, вероятность того, что пользователь на вопрос ответит, умножить на стоимость вопроса в долларах — такое вот мат ожидание.
Проблема у команды классическая — NDCG (точность ранжирования моделью -- то есть правильность порядка выбора вопросов) на оффлайне высокий, в эксперименте тоже, но A/B по ARPU не прокрасился 🤷.
В чем может быть проблема и как исправить ситуацию? Пишите в комментах 💡
Свой ответ поставил в отложку на через сутки )
🔥10❤4🤔3🦄2
Вау!!! Искренне поздравляю ребят!
❤3
Forwarded from Жизнь и датка (Alexander Guschin)
Шесть золотых!
Миша, Матвей, Андрей, Данис, Тимур, Олег!
Вы лучшие!
Заняли флагами пол сцены) 😁
Миша, Матвей, Андрей, Данис, Тимур, Олег!
Вы лучшие!
Заняли флагами пол сцены) 😁
🔥40🤝3🦄3👍1
Итак, развязка вчерашней задачи
Я большой любитель каскадов моделей (выше был пример в кейсе про недвижку)
Потому конечно же посоветовал построить модель обрыва сессии, сделать онлайн калибровку, и полученную вероятность учитывать в формуле мат. ожидания
На оффлайне эта модель выбила 0.75 ROCAUC, в новом эксперименте 0.8 ROCAUC — модель получилось сильной (оно и неудивительно, топ-фичи — прокси на трудоемкость вопроса для пользователя)
Что же пошло не так?
❗️ Факт 1. Вместо сплита на A/B по пользователям сплит был по сессиям — то есть один и тот же пользователь мог появиться в разных сессиях в разных группах -- и в тестовой и в контрольной
Но это не самое главное и достаточно часто встречается.
‼️Факт 2:
После того как модель выбирала вопрос, который показать следующим, на стороне бэка включались пост-фильтры — например, входит ли юзер в релевантный сегмент и прочее. Если отрабатывал фильтр — бэк снова дергал ручку модели, ровно с тем же набором фичей 🤣🤦♂️😂😂😂🙈🏆💎.
Как вы думаете, к чему же такой запрос приводил?
Правильно, к тому что модель давала ровно такой же ответ, цикл повторялся 700-800 раз до тайм-аут и разрыва сессии , интерфейс у пользователя все это время висел. Отловили ручным тестированием.
Век живи — век учись. И старайся фильтровать до модели!
Я большой любитель каскадов моделей (выше был пример в кейсе про недвижку)
Потому конечно же посоветовал построить модель обрыва сессии, сделать онлайн калибровку, и полученную вероятность учитывать в формуле мат. ожидания
На оффлайне эта модель выбила 0.75 ROCAUC, в новом эксперименте 0.8 ROCAUC — модель получилось сильной (оно и неудивительно, топ-фичи — прокси на трудоемкость вопроса для пользователя)
Что же пошло не так?
❗️ Факт 1. Вместо сплита на A/B по пользователям сплит был по сессиям — то есть один и тот же пользователь мог появиться в разных сессиях в разных группах -- и в тестовой и в контрольной
Но это не самое главное и достаточно часто встречается.
‼️Факт 2:
После того как модель выбирала вопрос, который показать следующим, на стороне бэка включались пост-фильтры — например, входит ли юзер в релевантный сегмент и прочее. Если отрабатывал фильтр — бэк снова дергал ручку модели, ровно с тем же набором фичей 🤣🤦♂️😂😂😂🙈🏆💎.
Как вы думаете, к чему же такой запрос приводил?
Век живи — век учись. И старайся фильтровать до модели!
Telegram
Дата канальи — про «специалистов» в данных / ML / AI
Итак, победил (пусть и не абсолютно) кейс с модельной архитектурой.
Полностью и исключительно вымышленный, естественно, просто плод воображения.
Когда застройщик обращается в банк за кредитом для планируемого строительства жилых корпусов, залоговой службе…
Полностью и исключительно вымышленный, естественно, просто плод воображения.
Когда застройщик обращается в банк за кредитом для планируемого строительства жилых корпусов, залоговой службе…
😁11🔥8❤5
Меня часто спрашивают сколько займет по времени вырасти от джуна до синьора / лида.
Обычно я в пример привожу Дашу
В начале 22го она пришла к нам джуном (кстати взяв 4е место в нашей сореве)
Несколько месяцев она уже лидит RnD-группу нейросетевых рекомендаций в МТС \ MWS.
Но на этом она не останавливается — не так уж и сложно было ее убедить опубликовать свои идеи в статье на RecSys’25, что стоило не только новогодних и майских праздников, а еще и много нервов 🙃.
А на днях Даша еще и канал завела — не стесняйтесь подписываться!
PS
ссылочка любителям сюжетов про быстрый рост 😃
Обычно я в пример привожу Дашу
В начале 22го она пришла к нам джуном (кстати взяв 4е место в нашей сореве)
Несколько месяцев она уже лидит RnD-группу нейросетевых рекомендаций в МТС \ MWS.
Но на этом она не останавливается — не так уж и сложно было ее убедить опубликовать свои идеи в статье на RecSys’25, что стоило не только новогодних и майских праздников, а еще и много нервов 🙃.
А на днях Даша еще и канал завела — не стесняйтесь подписываться!
PS
ссылочка любителям сюжетов про быстрый рост 😃
2🔥18❤6🦄3🤔1
Forwarded from Red RecSys
"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 - и ." Зато честный.
Спасибо всем, с кем мы вместе сделали эту работу ❤️
Нашу статью приняли на 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 - и ." Зато честный.
Спасибо всем, с кем мы вместе сделали эту работу ❤️
arXiv.org
eSASRec: Enhancing Transformer-based Recommendations in a Modular Fashion
Since their introduction, Transformer-based models, such as SASRec and BERT4Rec, have become common baselines for sequential recommendations, surpassing earlier neural and non-neural methods. A...
🔥13👍7❤4
Пока придумывал броские заголовки постов для сл недели, наткнулся на бесплатный завтрак (в оригинале Free Lunch), который-таки приняли на SIGIR'25 (топовая конфа, кажется A*):
PS: речь об отсылке к No free lunch theorem
🧀😆
InfoNCE is a Free Lunch for
Semantically guided Graph Contrastive Learning
PS: речь об отсылке к No free lunch theorem
🧀😆
1👍5🔥3😁3