3 инсайта про реком системы с IML
Пару дней назад рассказал про рекомендации Я.Маркета на конфе IML. А еще послушал доклады и поговорил в кулуарах с ребятами из Окко, Headhunter, Авито, Ламода и не только. Вот какие инсайты я вынес
1. Все начинают работать с контентом в рекомендациях
Массово переходят от моделей на id-товаров/юзеров к контентными трансформерами над историей пользователя. Это сильно лучше масштабируется, помогает идти в real-time и рекомендовать товары из "длинного хвоста"
2. Контента стало гораздо больше
Платформы достигли 10М+ контентых единиц (товаров, документов, рилсов, ...)
Приходится строить действительно большие системы, да еще и в real-time
При этом нужно рекомендовать желательно весь контент, и тут начинается борьба с popularity bias и работа с холодным стартом для контента: нужно рекомендовать не самые популярные и холодные товары
В обеих проблемах как раз помогают контентные трансформеры, но и не только они:
- Взвешивание сэмплов
- Дебаясинг: например, через фичу позиции товара в ленте
- Насильная вставка новинок/менее популярных категорий в ленты
3. Реклама и продвижение
Контента много и все контент-мейкеры хотят получать свой кусочек траффика. Но конкуренция растет: по многим отчетам ~80% селлеров на маркетплейсах зарабатывают чистыми <100K в мес, цена подписчика в соцсетях в космосе (в тг 100-150 руб/подписчик). Появилась явная потребность в механиках продвижения контента и запрос на "честное" распределение показов (условно, каждый получает хотя бы 10 показов)
Поэтому задача рекомендаций резко усложняется: становится все больше похожей на задачу оптимизации с ограничениями. А в пределе даже на комбинаторную задачу о наполнении рюказка. Во многих компаниях лента рекомендаций - это уже не отранжированные товары по некоему скору, а N слотов под самые персональные товары, K под рекламные, L под новые, ...
↕️ Очень верится, что в ближайшем будущем парадигма рекомедаций сдвинется в сторону комбинаторики, а не просто ранжированию списка
P.S. Официальных фоток и записей с конференции пока нет, поэтому вот вам 1 фотка доклада от меня и немножко питерского вайба
Пару дней назад рассказал про рекомендации Я.Маркета на конфе IML. А еще послушал доклады и поговорил в кулуарах с ребятами из Окко, Headhunter, Авито, Ламода и не только. Вот какие инсайты я вынес
1. Все начинают работать с контентом в рекомендациях
Массово переходят от моделей на id-товаров/юзеров к контентными трансформерами над историей пользователя. Это сильно лучше масштабируется, помогает идти в real-time и рекомендовать товары из "длинного хвоста"
2. Контента стало гораздо больше
Платформы достигли 10М+ контентых единиц (товаров, документов, рилсов, ...)
Приходится строить действительно большие системы, да еще и в real-time
При этом нужно рекомендовать желательно весь контент, и тут начинается борьба с popularity bias и работа с холодным стартом для контента: нужно рекомендовать не самые популярные и холодные товары
В обеих проблемах как раз помогают контентные трансформеры, но и не только они:
- Взвешивание сэмплов
- Дебаясинг: например, через фичу позиции товара в ленте
- Насильная вставка новинок/менее популярных категорий в ленты
3. Реклама и продвижение
Контента много и все контент-мейкеры хотят получать свой кусочек траффика. Но конкуренция растет: по многим отчетам ~80% селлеров на маркетплейсах зарабатывают чистыми <100K в мес, цена подписчика в соцсетях в космосе (в тг 100-150 руб/подписчик). Появилась явная потребность в механиках продвижения контента и запрос на "честное" распределение показов (условно, каждый получает хотя бы 10 показов)
Поэтому задача рекомендаций резко усложняется: становится все больше похожей на задачу оптимизации с ограничениями. А в пределе даже на комбинаторную задачу о наполнении рюказка. Во многих компаниях лента рекомендаций - это уже не отранжированные товары по некоему скору, а N слотов под самые персональные товары, K под рекламные, L под новые, ...
↕️ Очень верится, что в ближайшем будущем парадигма рекомедаций сдвинется в сторону комбинаторики, а не просто ранжированию списка
🔥30👍8🤔3❤1👌1
Конференции
Часть моего доклада на Data Fest заблокировал PR. Рассказывать важные куски общими словами мне не хотелось, поэтому решил сняться с конференции(
С одной стороны, грустно и обидно - в доклад я вложил всю душу и немало сил. С другой, архитектура рекома и несколько внедрений от нашей команды оказались настолько крутыми, что о них нельзя рассказывать конкурентам - это прям мотивирует)
🧐 В итоге, я буду слушателем на Data Fest - ждите интересных саммери и инсайтов
Часть моего доклада на Data Fest заблокировал PR. Рассказывать важные куски общими словами мне не хотелось, поэтому решил сняться с конференции(
С одной стороны, грустно и обидно - в доклад я вложил всю душу и немало сил. С другой, архитектура рекома и несколько внедрений от нашей команды оказались настолько крутыми, что о них нельзя рассказывать конкурентам - это прям мотивирует)
🧐 В итоге, я буду слушателем на Data Fest - ждите интересных саммери и инсайтов
❤35😱28😢13🤣12👍6
Милиарды параметров и данных для рекомендаций
Пожалуй, самая большая новость в российском мире рекомендаций -- анонс от Яндекса просто огромной трансформерной модели ARGUS-1В и настолько же огромного датасета рекомендаций Я.Музыки YAMBDA-5B. Об этом еще мало где писали, но тем интереснее сделать разбор:)
Датасет Я.Музыки YAMBDA-5B
Типичные проблемы рисерча в рекомендациях и сравнения моделей:
- Датасеты очень маленькие (в сотни-тысячи раз меньше продакшн данных)
- В данных нет последовательностей (даже в movielens!). Поэтому трансформеры так себе под них подходят
- Нет метаданных/признаков айтемов и юзеров (а в продакшен задачах есть)
Ребята попробовали решить это в YAMBDA. Почти 5B событий, около 1М айтемов, есть время события для моделирования последовательности треков (а такая зависимость явно есть). Плюсом идут готовые эмбеды и фичи. Из небольших минусов: нет названий треков и человекочитаемых метаданных. Но это NDA, так что понятно, почему
В общем, в следующий раз вместо Movielens или Amazon reviews вы знаете, какой датасет взять
Рекомендательный трансформер ARGUS-1B
Кажется, не все распарсили, что доклад про ARGUS на датафесте во многом базировался на YAMBDA-подобном датасете. Так что датасет и модель полезно рассматривать в паре
Так что за ARGUS? Насколько я знаю, первый в РФ рекомендательный трансформер с контекстным окном 8К и размером 1В параметров. Из крутого:
- Таргеты Next item + Feedback prediction. То есть модель предсказывает, с каким треком провзаимодействует пользователь, и какой фидбек ему даст (дослушал до конца, лайкнул, ..). Вообще-то это сразу и отбор кандидатов, и ранжирование - ну кайф же 🔥
- Достаточно подробно рассказали архитектуру: позднее связывание, кодирование товара через DCN, трансформеры
- Намекнули, как все-таки удалось масштабироваться до 8К действий юзера в контексте трансформера: берем последовательность действий юзера, сдвигаем на одно действие. Одним проходом трансформера получаем эмбеды во всех стейтах. Далее эффективен считаем лосс. Очень похоже на BERT/GPT-подобные "эффективности" архитектуры в NLP, но в рекоме мало кто смог завести
- В итоге, от ARGUS получили колоссальные приросты в продакшене Музыки и Алисы. Ну и мы в Я.Маркете тоже тестим Argus: ожидаем не менее колоссальных приростов)
Разбор подготовил тг-канал @ml4value
Пожалуй, самая большая новость в российском мире рекомендаций -- анонс от Яндекса просто огромной трансформерной модели ARGUS-1В и настолько же огромного датасета рекомендаций Я.Музыки YAMBDA-5B. Об этом еще мало где писали, но тем интереснее сделать разбор:)
Датасет Я.Музыки YAMBDA-5B
Типичные проблемы рисерча в рекомендациях и сравнения моделей:
- Датасеты очень маленькие (в сотни-тысячи раз меньше продакшн данных)
- В данных нет последовательностей (даже в movielens!). Поэтому трансформеры так себе под них подходят
- Нет метаданных/признаков айтемов и юзеров (а в продакшен задачах есть)
Ребята попробовали решить это в YAMBDA. Почти 5B событий, около 1М айтемов, есть время события для моделирования последовательности треков (а такая зависимость явно есть). Плюсом идут готовые эмбеды и фичи. Из небольших минусов: нет названий треков и человекочитаемых метаданных. Но это NDA, так что понятно, почему
В общем, в следующий раз вместо Movielens или Amazon reviews вы знаете, какой датасет взять
Рекомендательный трансформер ARGUS-1B
Кажется, не все распарсили, что доклад про ARGUS на датафесте во многом базировался на YAMBDA-подобном датасете. Так что датасет и модель полезно рассматривать в паре
Так что за ARGUS? Насколько я знаю, первый в РФ рекомендательный трансформер с контекстным окном 8К и размером 1В параметров. Из крутого:
- Таргеты Next item + Feedback prediction. То есть модель предсказывает, с каким треком провзаимодействует пользователь, и какой фидбек ему даст (дослушал до конца, лайкнул, ..). Вообще-то это сразу и отбор кандидатов, и ранжирование - ну кайф же 🔥
- Достаточно подробно рассказали архитектуру: позднее связывание, кодирование товара через DCN, трансформеры
- Намекнули, как все-таки удалось масштабироваться до 8К действий юзера в контексте трансформера: берем последовательность действий юзера, сдвигаем на одно действие. Одним проходом трансформера получаем эмбеды во всех стейтах. Далее эффективен считаем лосс. Очень похоже на BERT/GPT-подобные "эффективности" архитектуры в NLP, но в рекоме мало кто смог завести
- В итоге, от ARGUS получили колоссальные приросты в продакшене Музыки и Алисы. Ну и мы в Я.Маркете тоже тестим Argus: ожидаем не менее колоссальных приростов)
Разбор подготовил тг-канал @ml4value
🔥35❤10👍7
Глянцевый журнал рекомендаций
Какое-то время назад были популярны журналы моды, тачек и всего прочего. Там собраны красивые картинки, которые дополняют друг друга. И смотрится все это как единое целое
Казалось бы, рекомендации товаров в приложении устроены также? А вот ни разу. Обычно мы скорим каждый товар независимо, поэтому все рекомендации могут состоять условно только из кроссовок. Чтобы такого не случалось, добавляются эвристики разнообразия
🩼 Иногдакостыли эвристики простые типа «не более 5 товаров из одной категории». Иногда это ml-эвристики как у Авито: ребята сделали занятный рассказ про замену статистической эвристики разнообразия на ml-эвристику предсказания будущей категории покупки (см скрины)
Но все же мы не собираем рекомендации «как журнал». Не прогнозируем скор сразу всей пачки рекомендаций из 10 товаров, а очень хочется. Формально, это переход от pointwise/pairwise к listwise лоссу. Есть острое желание потестить это в проде и даже есть пара наработок. Придется бороться с комбинаторным взрывом, учиться учитывать «полезность» сразу пачки рекомендаций и многое
другое!
И вот стало интересно, может кто-то уже пробовал listwise подход в рекоме/поиске? Или есть идеи/рисерчи на этот счет? Буду рад услышать ваши мысли в комментариях ⬇️
Какое-то время назад были популярны журналы моды, тачек и всего прочего. Там собраны красивые картинки, которые дополняют друг друга. И смотрится все это как единое целое
Казалось бы, рекомендации товаров в приложении устроены также? А вот ни разу. Обычно мы скорим каждый товар независимо, поэтому все рекомендации могут состоять условно только из кроссовок. Чтобы такого не случалось, добавляются эвристики разнообразия
🩼 Иногда
Но все же мы не собираем рекомендации «как журнал». Не прогнозируем скор сразу всей пачки рекомендаций из 10 товаров, а очень хочется. Формально, это переход от pointwise/pairwise к listwise лоссу. Есть острое желание потестить это в проде и даже есть пара наработок. Придется бороться с комбинаторным взрывом, учиться учитывать «полезность» сразу пачки рекомендаций и многое
другое!
И вот стало интересно, может кто-то уже пробовал listwise подход в рекоме/поиске? Или есть идеи/рисерчи на этот счет? Буду рад услышать ваши мысли в комментариях ⬇️
✍13👍9🔥6❤2👎1
Лето. Питер. 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
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
🔥7👍6🤔4🤣3
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
Периодически слежу за развитием подходов А/В в индустрии. За год вышло немало статей от Х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
Хабр
Как проводить A/B-тестирование на 15 000 офлайн-магазинах
Привет! На связи команда Ad-hoc аналитики Big Data из X5 Retail Group. В этой статье мы расскажем о нашей методологии A/B-тестирования и сложностях, с которыми мы ежедневно сталкиваемся. В Big Data Х5...
❤18👍15🔥9👎2
Выбрать цену и не прогореть: Юнит экономика, ч1
В России и мире некоторый кризис, поэтому опять актуальна эффективность бизнеса. Ну и куда же в ней без оптимизации цен?
Обычно мы хотим больше прибыли за счет оптимальных цен. В более продвинутых кейсах не только прибили, а баланса выручка-прибыль, но об этом в следующий раз
Прибыль = прогноз спроса * (цена - издержки) —> max
Про прогноз спроса (он, кстати, зависит от цены) я уже рассказывал на pml и писал (раз, два). Цену мы выбираем сами. Для решения задачи осталось посчитать издержки, но они вроде же известны? Закупочная цена товара есть во всех ERP-системах
Она-то есть, и через нее мы можем посчитать front маржу товара (цена - закупочная цена). Проблема в том, что так не получится прибыль, которая реально остается на счетах компании. Но она получится, если считать юнит экономику товара
UE, unit economics - цена за вычетом всех (вообще всех!) издержек на этот товар
И вот тут начинаются проблемы: на этих детали, кстати, погорело много селлеров на маркетплейсах
- Товар нужно доставить до покупателя - логистические издержки
- При доставке его могут еще и вернуть (х2 логистика), и попортить/потерять - списания
- В конце сезона / срока годности нужно хоть как-то распродать остатки - будем выдавать скидки
- Товары нужно хранить, и это стоит приличных денег - издержки хранения
- Храня товар, мы замораживаем в нем деньги. А могли бы положить их на депозит под 15-18% и получить прибыль - недополученная прибыль
🧪 Итого, мы получаем формулу прибыли:
Прибыль = прогноз спроса * UE
= sales * (price - цена закупки - логистические издержки - скидки для продажи) - списания * цена закупки - фикс косты - time * ст-ть хранения * средний обьем хранения - deposit_rate * time * sales * закуп - …
Несколько сложнее, чем цена - закупочная цена, да?) И нам нужно оптимизировать вот это все сразу, выбирая цену. При этом цена сидит почти в каждом компоненте: в скидках, списаниях, обьеме и времени хранения, ...
Поэтому считайте юнит экономику товара, а не "купил за 70, продал за 100"
А как прогнозировать ее компоненты (списания, обьем хранения и тп) расскажу уже в следующем посте
To be continued...
В России и мире некоторый кризис, поэтому опять актуальна эффективность бизнеса. Ну и куда же в ней без оптимизации цен?
Обычно мы хотим больше прибыли за счет оптимальных цен. В более продвинутых кейсах не только прибили, а баланса выручка-прибыль, но об этом в следующий раз
Прибыль = прогноз спроса * (цена - издержки) —> max
Про прогноз спроса (он, кстати, зависит от цены) я уже рассказывал на pml и писал (раз, два). Цену мы выбираем сами. Для решения задачи осталось посчитать издержки, но они вроде же известны? Закупочная цена товара есть во всех ERP-системах
Она-то есть, и через нее мы можем посчитать front маржу товара (цена - закупочная цена). Проблема в том, что так не получится прибыль, которая реально остается на счетах компании. Но она получится, если считать юнит экономику товара
UE, unit economics - цена за вычетом всех (вообще всех!) издержек на этот товар
И вот тут начинаются проблемы: на этих детали, кстати, погорело много селлеров на маркетплейсах
- Товар нужно доставить до покупателя - логистические издержки
- При доставке его могут еще и вернуть (х2 логистика), и попортить/потерять - списания
- В конце сезона / срока годности нужно хоть как-то распродать остатки - будем выдавать скидки
- Товары нужно хранить, и это стоит приличных денег - издержки хранения
- Храня товар, мы замораживаем в нем деньги. А могли бы положить их на депозит под 15-18% и получить прибыль - недополученная прибыль
🧪 Итого, мы получаем формулу прибыли:
Прибыль = прогноз спроса * UE
= sales * (price - цена закупки - логистические издержки - скидки для продажи) - списания * цена закупки - фикс косты - time * ст-ть хранения * средний обьем хранения - deposit_rate * time * sales * закуп - …
Несколько сложнее, чем цена - закупочная цена, да?) И нам нужно оптимизировать вот это все сразу, выбирая цену. При этом цена сидит почти в каждом компоненте: в скидках, списаниях, обьеме и времени хранения, ...
Поэтому считайте юнит экономику товара, а не "купил за 70, продал за 100"
А как прогнозировать ее компоненты (списания, обьем хранения и тп) расскажу уже в следующем посте
To be continued...
Telegram
ML for Value / Ваня Максимов
Запись моего рассказа про Прогноз спроса с Practical ML Conference, если вы не смогли вчера быть лично или на трансляции 😄
https://youtu.be/18UzF2w9nec?t=28517
https://youtu.be/18UzF2w9nec?t=28517
2👍33🔥15
В твиттере вирусится индус Soham Parekh, который прекрасно проходит собесы, а потом работает на нескольких работах в топ стартапах сразу
Часть людей пишет, что на работах он ничего не делает и много откуда его уволили через 2-3 недели
Другие восхищаются и тиражируют мемасики на эту тему - честно скопировал этот из дружеского тг-канала
Лично я скорее позитивно отношусь к 2 работам сразу, если человек с ними обеими справляется. На практике это обычно одна основная full time и вторая - part time (преподавание,
А вы что думаете?
🔥 - уже работаю на 2+ работах: это новая реальность
👍 - пока сомневаюсь, но смотрю в эту сторону
🤔 - мне и на одной работе хорошо
🤔63👍43🔥30❤2😁2
Упрощай и властвуй: RecSys в одну стадию
Недавно на весь рекомендательный мир прогремел новый тех репорт модели OneRec от китайского аналога тиктока Kuaishou. Они заменили многостадийную рексистему на одну генеративную нейронку и получили приличный рост метрик. Но пока все еще стоит вопрос о массовой применимости такой модели.
Мои коллеги из Яндекс Лавки недавно тоже отказались от кандидатогенерации. Теперь их catboost в рантайме скорит весь ассортимент даркстора (до 5000 SKU), укладываясь в 300 мс. И это уже может быть массово полезно очень многим!
📈 Внутри статьи — рассказ о том, как инженеры Лавки избавлялись от лишних признаков, по-хитрому готовили фичи, оптимизировали рантайм катбуст, и что всё это в итоге дало.
Как знать, может скоро мы все окажемся в мире без кандидатогенерации!
Недавно на весь рекомендательный мир прогремел новый тех репорт модели OneRec от китайского аналога тиктока Kuaishou. Они заменили многостадийную рексистему на одну генеративную нейронку и получили приличный рост метрик. Но пока все еще стоит вопрос о массовой применимости такой модели.
Мои коллеги из Яндекс Лавки недавно тоже отказались от кандидатогенерации. Теперь их catboost в рантайме скорит весь ассортимент даркстора (до 5000 SKU), укладываясь в 300 мс. И это уже может быть массово полезно очень многим!
📈 Внутри статьи — рассказ о том, как инженеры Лавки избавлялись от лишних признаков, по-хитрому готовили фичи, оптимизировали рантайм катбуст, и что всё это в итоге дало.
Как знать, может скоро мы все окажемся в мире без кандидатогенерации!
👍28🔥8❤6
Хранить нельзя списать: Юнит экономика, ч2
Начнем разбирать издержки с той самой статьи расходов, которая часто и рушит бизнес: хранение товара. Просто следите за руками
Спрос = f(price)
Ст-ть хранения = g(спрос) = g(f(price)) =
= Средний обьем в мес, м2 * ставка аренды
+ Средний обьем в мес, руб * ставка депозита (связка с оборачиваемостью?)
+ max(Средний срок хранения, дни - Срок годности; 0) * себестоимость товара
Прибыль = Спрос * (цена продажи - цена закупки) - Стоимость хранения --> max(price)
Мало того, что нужно получить зависимость g(f(price)). Так этаж* g() еще и очень сложно устроена!
Вот есть у нас прогноз спроса = f(price). Он в штуках, а не в м2. Он - это не обьем хранения. Он не знает о текущих остатках на складах и сколько нужно закупить товара до некоторого оптимального обьема хранения. Он еще не знает, что закупать товар можно только коробками по 12-20 штук
Если спрос маленький (до 10 штук), то его колбасит по полноценному Пуассону. И любая ошибка прогноза (очень вероятная) приводит к покупке не 1 коробки, а 2ух коробок - здравствуйте х2 издержки хранения (списания)
😈О как..
Какое-то "хранение" превратилось в нелинейную комбинаторную невыпуклую и черт еще знает какую заадчу математической оптимизации
Допустим, мы знаем текущий сток(обьем хранения) на складе. И у нас есть прогноз спроса. Казалось бы, закупаем c учетом округлени до коробки round(Спрос - Сток) и все дела?
Типичная ошибка навичка. Мы ведь не решаем задачу продать весь сток поскорее, а хотим побольше прибыли заработать. Если товар на складе закончился, а заказы поступают - мы недополучаем прибыль от этих заказов.
Поэтому появился термин Старховые запасы. Из приятного - можно решать задачи прогноза спроса и определения страховых запасов почти независимо!
Обьем закупки = round(Спрос + Страховой запас - Сток)
Средний обьем хранения = (Сток + Спрос + 2 * Страховой запас + доп хранение из-за округления) / период между поставками
А дальше есть 2 пути
- Зубодробительно решать задачу математически, например, вот так
- Делать симуляции типа Монте-Карло, тк округления "по коробкам" все равно здорово ломают математику
Как бы я ни любил красивую математику, порекомендую заняться симуляцией
💡 Несколько интересных выводов из опыта таких симуляций :
- При маленьком обьеме спроса (до 10 штук товара за период между закупками) ловить нечего - нужно продавать много и вкладываться в рекламу
- Чем меньше размер "коробки" вы можете закупить, тем лучше
- Следите за сроками годности товаров. Фрэш со сроком годности 4 дня и меньше - кровавый океан
- Редкие поставки с большим лагом во времени очень круто растят стоимость хранения
- Если не считать, сколько товара закупать, то можно легко погореть только на хранении)) Хотя казалось бы, это просто фикс ставка за склад в месяц
- Вы удивитесь, но с маржинальностью товара = (цена - закупка) / цена менее 100% у небольшого продавца шансов на прибыль нет. Гораздо эффективнее будет положить деньги на закупку товара на депозит под 16-18%
Это была аналитика дляселлеров ml-щиков бесплатно, без регистрации и смс
Подготовлено каналом @ml4value
Начнем разбирать издержки с той самой статьи расходов, которая часто и рушит бизнес: хранение товара. Просто следите за руками
Спрос = f(price)
Ст-ть хранения = g(спрос) = g(f(price)) =
= Средний обьем в мес, м2 * ставка аренды
+ Средний обьем в мес, руб * ставка депозита (связка с оборачиваемостью?)
+ max(Средний срок хранения, дни - Срок годности; 0) * себестоимость товара
Прибыль = Спрос * (цена продажи - цена закупки) - Стоимость хранения --> max(price)
Мало того, что нужно получить зависимость g(f(price)). Так эта
Вот есть у нас прогноз спроса = f(price). Он в штуках, а не в м2. Он - это не обьем хранения. Он не знает о текущих остатках на складах и сколько нужно закупить товара до некоторого оптимального обьема хранения. Он еще не знает, что закупать товар можно только коробками по 12-20 штук
Если спрос маленький (до 10 штук), то его колбасит по полноценному Пуассону. И любая ошибка прогноза (очень вероятная) приводит к покупке не 1 коробки, а 2ух коробок - здравствуйте х2 издержки хранения (списания)
😈О как..
Какое-то "хранение" превратилось в нелинейную комбинаторную невыпуклую и черт еще знает какую заадчу математической оптимизации
Допустим, мы знаем текущий сток(обьем хранения) на складе. И у нас есть прогноз спроса. Казалось бы, закупаем c учетом округлени до коробки round(Спрос - Сток) и все дела?
Типичная ошибка навичка. Мы ведь не решаем задачу продать весь сток поскорее, а хотим побольше прибыли заработать. Если товар на складе закончился, а заказы поступают - мы недополучаем прибыль от этих заказов.
Поэтому появился термин Старховые запасы. Из приятного - можно решать задачи прогноза спроса и определения страховых запасов почти независимо!
Обьем закупки = round(Спрос + Страховой запас - Сток)
Средний обьем хранения = (Сток + Спрос + 2 * Страховой запас + доп хранение из-за округления) / период между поставками
А дальше есть 2 пути
- Зубодробительно решать задачу математически, например, вот так
- Делать симуляции типа Монте-Карло, тк округления "по коробкам" все равно здорово ломают математику
Как бы я ни любил красивую математику, порекомендую заняться симуляцией
- При маленьком обьеме спроса (до 10 штук товара за период между закупками) ловить нечего - нужно продавать много и вкладываться в рекламу
- Чем меньше размер "коробки" вы можете закупить, тем лучше
- Следите за сроками годности товаров. Фрэш со сроком годности 4 дня и меньше - кровавый океан
- Редкие поставки с большим лагом во времени очень круто растят стоимость хранения
- Если не считать, сколько товара закупать, то можно легко погореть только на хранении)) Хотя казалось бы, это просто фикс ставка за склад в месяц
- Вы удивитесь, но с маржинальностью товара = (цена - закупка) / цена менее 100% у небольшого продавца шансов на прибыль нет. Гораздо эффективнее будет положить деньги на закупку товара на депозит под 16-18%
Это была аналитика для
Подготовлено каналом @ml4value
Please open Telegram to view this post
VIEW IN TELEGRAM
❤26🔥16👍14🤯2
Разнообразие рекомендаций: 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 июля
В рекомендательных системах есть 2 проблемы:
Чтобы обрабатывать большие каталоги товаров мы часто сэмплируем что-либо: товары, пользователей, негативы и тп.
Для борьбы с однотипностью используем методы повышения разнообразия, например 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 июля
👍19🔥9❤3🤣1
Погрузиться в ML-задачи маркетплейсов
Осознал, что я уже 8 лет делаю ML в маркетплейсах. И скучно не становится, потому что тут есть много нетривиальных задач (рекомендации, поиск, назначение курьеров) и постоянно появляются новые. Они круто прокачивают и по хард скиллам, и по пониманию бизнеса
Иногда крупные ecom-ы проводят соревнования по своим задачам — это хороший шанс попробовать свои силы в них. Скоро как раз стартует такое соревнование — E-CUP 2025 от Ozon Tech с призовым фондом 7.2 млн рублей и 3 треками:
1. Рекомендации: предсказание следующей покупки пользователя
Тут круто было бы попробовать трансформеры для recsys. Есть даже уже готовые open source решения в RecTools и RePlay. В RecTools даже недавно завезли нашумевший HSTU трансформер, по образу которого строятся SOTA рекомендации
Еще рекомендации в моде сильно зависят от визуального сигнала — можно потренироваться с дообучением CLIP/BLIP/SigLIP эмбедов.
2. Логистика: автопланирование курьеров
Задача скорее комбинаторная, а не ML-ная, но от этого не менее интересная! Эффективно распределить 20к заказов между 200 курьерами не так-то просто. На этой задаче можно изучить базовые логистические алгоритмы типа Венгерского алгоритма, а еще что-то более продвинутого вроде буферного назначения или батчинга заказов.
3. Контроль качества: автоматическое выявление поддельных товаров
Бессмертная классика. Понятная задача, где нужно и признаки придумать, и нейронки покрутить. Хорошая бизнес-ориентированная альтернатива учебным проектам по классификации комментариев.
Если интересно прокачаться в задачах маркетплейсов, то регистрируйтесь
Осознал, что я уже 8 лет делаю ML в маркетплейсах. И скучно не становится, потому что тут есть много нетривиальных задач (рекомендации, поиск, назначение курьеров) и постоянно появляются новые. Они круто прокачивают и по хард скиллам, и по пониманию бизнеса
Иногда крупные ecom-ы проводят соревнования по своим задачам — это хороший шанс попробовать свои силы в них. Скоро как раз стартует такое соревнование — E-CUP 2025 от Ozon Tech с призовым фондом 7.2 млн рублей и 3 треками:
1. Рекомендации: предсказание следующей покупки пользователя
Тут круто было бы попробовать трансформеры для recsys. Есть даже уже готовые open source решения в RecTools и RePlay. В RecTools даже недавно завезли нашумевший HSTU трансформер, по образу которого строятся SOTA рекомендации
Еще рекомендации в моде сильно зависят от визуального сигнала — можно потренироваться с дообучением CLIP/BLIP/SigLIP эмбедов.
2. Логистика: автопланирование курьеров
Задача скорее комбинаторная, а не ML-ная, но от этого не менее интересная! Эффективно распределить 20к заказов между 200 курьерами не так-то просто. На этой задаче можно изучить базовые логистические алгоритмы типа Венгерского алгоритма, а еще что-то более продвинутого вроде буферного назначения или батчинга заказов.
3. Контроль качества: автоматическое выявление поддельных товаров
Бессмертная классика. Понятная задача, где нужно и признаки придумать, и нейронки покрутить. Хорошая бизнес-ориентированная альтернатива учебным проектам по классификации комментариев.
Если интересно прокачаться в задачах маркетплейсов, то регистрируйтесь
🔥7👍5👌4🤔1