Лето. Питер. GenAI

26-27 июня в Питере пройдет Conversations 2025 — конференция по СonversationalAI и GenAI для бизнеса и разработчиков. Будет много про RAG-и, агентов и мультимодольность

В Technology Track (а есть еще business, product и startup) есть занятные доклады:

- ETL для RAG: как отделить стог сена от стога иголок и не спалить серверную? (Альфа банк и Just AI)

- LLM в клиентских ботах МТС: галлюцинации, громоздкие промпты и другие неочевидные вызовы (МТС)

- LLM под капотом Алисы: реальная история внедрения GPT-технологий (Яндекс)

В общем, 2 дня насыщенной программы, 4 трека, 40+ спикеров, нетворкинг с вечеринкой и первая в России премия по genAI🔥

Вот здесь — сайт Conversations, здесь — программа и билеты.
Скидка 10% на билеты по промокоду: CNVS25sPtS

AB платформа X5 - reverse engineering

Периодически слежу за развитием подходов А/В в индустрии. За год вышло немало статей от Х5 про их АВ-плафторму + наткнулся на новость, что ее проверили на ФКН Вышки и подвтердили, что все валидно. Тех репортов нет, но кто мне помешает сделать reverse engineering этой АВ платформы по статьям Х5 с Хабра?)

Отправная точка - 2019г
Была подробная статья про А/В экспы Х5 в оффлайне на 15к магазинах

Если я все верно понял, то 5 лет назад все работало так:
1. Сэмплируем контрольную группу из K магазинов
2. К каждому контрольному магазину подбираем 1 наиболее похожий тестовый магазин по фичам на предтестовом периоде
3. Проводим А/В
4. Применяем методы снижения дисперсии (почему-то сюда вписана и линеаризация, ну да ладно)
5. Применяем стандартный Т-тест

После этого было довольно много статей на Хабре - так давайте обьединим их в одну картинку


А/В плафторма X5 на 2025г из этих разрозненных кусочков на Хабре (сугубое имхо)!

1. Статистический фильтр
В оффлайне маленькое кол-во данных (15-30к магазинов) - это огромная проблема. Приходится выстраивать очередь экспов. Логичная идея: давайте сначала проверять на исторических данных, можно ли вообще ожидать эффект от фичи? Если да, то только тогда зпускать АВ. Как я понял, способ такой проверки у Х5 эволюционировал от diff-in-diff до поиска коинтеграции временных рядов через эконометрические VECM модели (мое бакалаврское прошлое ликует 🔥). В общем случае VECM-модель - это хиттрая линейная регрессия на временных рядах, которую можно посчитать и на исторических данных без АВ, и потом уже в самом АВ для снижения дисперсии

2. Разбиение магазинов
Видимо осталось тем же, что и в 2019-ом: К каждому контрольному магазину подбираем 1 наиболее похожий тестовый

3. Проводим сам А/В

4. Снижение дисперсии через линейную регрессию
Когда-то в своем видео "13 способов ускорить А/В тест: не CUPED-ом единым" я и сам рассказывал, что все методы ускорения А/В сводятся к линейной регрессии. Похоже, этот подход и внедрен в Х5

5. Т-тест: все еще один в поле воин!)
Была просто куча статей про плюсы/минусы разных стат критериев. Чем плох баес, можно ли заменить t-test на welch test, как поживает манн-уитни. Но из этих статей я делаю вывод, что T-test все еще держится по совокупности плюсов и минусов

6. Мета-анализ
Тут начинается кое-что занятное) Часто одна команда проводит за квартал серию экспов на улучшение одной и той же метрики. Хорошо бы понять, а какой прирост метрики был в сумме от всех внедрений? Спойлер - это часто сильно меньше суммы каждого отдельного внедрения. Есть разные способы делать такой подсчет. Сразу несколько статей про мета-анализ наводит на мысль, что Х5 живет инвестиционными циклами в квартал-полгода. И на самом деле важны не сами зеленые А/В, а суммарные эффект от команды/продукта за период. Такой подход одобряем

Если вы из Х5 и готовы сказать, в чем я прав, а в чем - нет, то welcome в комментарии ⬇️

// Reverse engineering AB плафтормы X5 подготовил тг-канал @ml4value

Выбрать цену и не прогореть: Юнит экономика, ч1

В России и мире некоторый кризис, поэтому опять актуальна эффективность бизнеса. Ну и куда же в ней без оптимизации цен?
Обычно мы хотим больше прибыли за счет оптимальных цен. В более продвинутых кейсах не только прибили, а баланса выручка-прибыль, но об этом в следующий раз

Прибыль = прогноз спроса * (цена - издержки) —> max

Про прогноз спроса (он, кстати, зависит от цены) я уже рассказывал на pml и писал (раз, два). Цену мы выбираем сами. Для решения задачи осталось посчитать издержки, но они вроде же известны? Закупочная цена товара есть во всех ERP-системах

Она-то есть, и через нее мы можем посчитать front маржу товара (цена - закупочная цена). Проблема в том, что так не получится прибыль, которая реально остается на счетах компании. Но она получится, если считать юнит экономику товара

UE, unit economics - цена за вычетом всех (вообще всех!) издержек на этот товар

И вот тут начинаются проблемы: на этих детали, кстати, погорело много селлеров на маркетплейсах
- Товар нужно доставить до покупателя - логистические издержки
- При доставке его могут еще и вернуть (х2 логистика), и попортить/потерять - списания
- В конце сезона / срока годности нужно хоть как-то распродать остатки - будем выдавать скидки
- Товары нужно хранить, и это стоит приличных денег - издержки хранения
- Храня товар, мы замораживаем в нем деньги. А могли бы положить их на депозит под 15-18% и получить прибыль - недополученная прибыль

🧪 Итого, мы получаем формулу прибыли:

Прибыль = прогноз спроса * UE
= sales * (price - цена закупки - логистические издержки - скидки для продажи) - списания * цена закупки - фикс косты - time * ст-ть хранения * средний обьем хранения - deposit_rate * time * sales * закуп - …

Несколько сложнее, чем цена - закупочная цена, да?) И нам нужно оптимизировать вот это все сразу, выбирая цену. При этом цена сидит почти в каждом компоненте: в скидках, списаниях, обьеме и времени хранения, ...

Поэтому считайте юнит экономику товара, а не "купил за 70, продал за 100"
А как прогнозировать ее компоненты (списания, обьем хранения и тп) расскажу уже в следующем посте

To be continued...

Упрощай и властвуй: RecSys в одну стадию

Недавно на весь рекомендательный мир прогремел новый тех репорт модели OneRec от китайского аналога тиктока Kuaishou. Они заменили многостадийную рексистему на одну генеративную нейронку и получили приличный рост метрик. Но пока все еще стоит вопрос о массовой применимости такой модели.

Мои коллеги из Яндекс Лавки недавно тоже отказались от кандидатогенерации. Теперь их catboost в рантайме скорит весь ассортимент даркстора (до 5000 SKU), укладываясь в 300 мс. И это уже может быть массово полезно очень многим!

📈 Внутри статьи — рассказ о том, как инженеры Лавки избавлялись от лишних признаков, по-хитрому готовили фичи, оптимизировали рантайм катбуст, и что всё это в итоге дало.

Как знать, может скоро мы все окажемся в мире без кандидатогенерации!

Разнообразие рекомендаций: Sampled MMR
В рекомендательных системах есть 2 проблемы: дураки и дороги слишком много товаров и их однотипность. Например, у вас есть миллионы книг - хочется получить топ-10 самых релевантных от разных авторов/жанров

Чтобы обрабатывать большие каталоги товаров мы часто сэмплируем что-либо: товары, пользователей, негативы и тп.

Для борьбы с однотипностью используем методы повышения разнообразия, например Maximal Marginal Relevance (MMR). В нем при составлении списка рекомендаций мы штрафуем каждый следующий товар за похожесть по эмбеддингу на товары в списке до него. Эффектно, но долго. На практике для списков длиннее 10 скорее не работает.

Логичным выглядит скрестить сэмплирование и MMR. Что и сделали ребята из T-Bank AI Research - получился алгоритм Sampled MMR

Отличия Sаmpled MMR от классических MMR, DPP:
– Благодаря сэмплированию гораздо быстрее на длинных списках: почти х10 на списках из топ-200 товаров

– Обещают даже более высокое покрытие каталога и разнообразие между юзерами за счет все того же сэмплирования

– По парето-границе размена релевантности на разнообразие обходит MMR, DPP

Из приятного есть параметр “температуры” для управления степенью разнообразия и код на гитхабе

Кстати, Sampled MMR придумали ребята из T-Bank AI Research - можно узнать детали у них на Turbo ML Conf в Москве уже 19 июля

Один АВ-тест в год или положить прод?

Всем хочется простого, человеческого счастья, чистого кода и стабильности ML-систем. Но это требует много времени и навыков. Поэтому в таких системах проводить изменения сложно и обычно катают один АВ-тест в год: не преувеличиваю, видел такого немало

Другая крайность - костыль на костыле в коде, АВ-тесты текут рекой, но половина из них невалидны

Сам я адепт быстрых изменений-костылей, но и за валидность АВ. Поэтому очень верю в концепцию двух репозиториев: research и prod. И я сам приложил руку к такой практике в паре компаний, и так уже работает во многих местах. Например, ML-cпецы финтеха Точка Банк недавно писали про это пост с докладом, где довольно хорошо раскрыли эту тему с примерами про масштабирование sklearn, тайпингами transformers и другими не всегда очевидными деталями.

В research код не такой красивый и быстрый, зато понятный и быстроизменяемый. В пределе research код вообще может возвращать csv-шку, которая заливается в прод на время А/В. И если эксперимент зеленый, то дорабатывается полноценное решение уже в prod репозитории с нормальными таймингами, стабильностью и регулярным обучением моделей

Самая большая сложность - внедрить правила / контракты, по которым эти репозитории дружат друг с другом. А не Jupyter notebook переписывать на Go с нуля каждый раз. Но если помучиться и сделать это, то дальше вас ждёт дивный новый мир, где research + prod = мощная коллаборация

А вы за какой вариант?

🌚 - Только стабильность prod кода и тайминги сразу, только хардкор
🔥 - За быстрые эксперименты, пусть и .csv. Если дает метрики, то по существующим договорённостям перенесём в prod решение с небольшими доработками
⚡️- Вжух-вжух и в продакшен, дальше видно будет. Мир быстро меняется: может за полгода выйдет gpt-6 и мы перепишем все с нуля

Мои экс-коллеги из WB проводят RecSys Meetup!)

Обещают рассказать много всего передового: трансформеры, semantic IDs, балансировка интересов пользователей и продавцов, связь онлайн и оффлайн метрик рекома

А если подетальнее, то в программе:
- Semantic IDs: архитектура и наш опыт внедрения
- Трансформеры в персональных рекомендациях: от гипотез до AB-тестирования
- Счастье пользователя vs счастье продавца. Онлайн-доранжирование и байесовская оптимизация в товарных рекомендациях
- Как мы обучаем CLIP-ы для текстовых тегов

Митап пройдет 28 августа в 18:00 оффлайн и онлайн

Для участия оффлайн нужна регистрация по ссылке

Хуже = лучше

Моя команда в Я.Маркете внедрила метрику дискаверийности (новизны) рекомендаций товаров. И в этом полугодии мы пробуем ее активно растить

Естественно, посмотрели статьи про рост beyond accuracy метрик, внедрили успешные подходы из них, запустили А/В и …
научились стат значимо метрику дискавери снижать 🌚

И меня это очень порадовало

Теперь мы точно знаем, что влияет на метрику в минус - будем делать ровно наоборот и вероятно получим рост! Так что «красные» А/В тесты с падением метрик - часто гораздо полезнее кучи «серых» тестов без изменения метрик

А вообще, вопросиков к современным статьям очень много (особенно в recsys). Неправильный train-test split, подбор метрик под результаты, специально недотюненные бейзлайны, …

Поэтому я обожаю reproducibility reports (впору уж писать свой), где независимые авторы пробуют повторить результаты из статей - и пишут свои менее biased выводы. Один из самых известных в recsys Turning Dross into gold loss: is Bert4Rec really better than SasRec? пару лет назад позволил внедрить SasRec-like модели почти во всех доменах и компаниях

В общем, проверяйте даже «общепринятые» подходы и радуйтесь, если смогли подвинуть ваши метрики даже вниз - отсюда появляется куча идей, как подвинуть их уже вверх 👆