Конференции
Часть моего доклада на 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👍11🔥6❤2👎1
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...
❤20👍15🔥10👎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👍34🔥16
В твиттере вирусится индус Soham Parekh, который прекрасно проходит собесы, а потом работает на нескольких работах в топ стартапах сразу
Часть людей пишет, что на работах он ничего не делает и много откуда его уволили через 2-3 недели
Другие восхищаются и тиражируют мемасики на эту тему - честно скопировал этот из дружеского тг-канала
Лично я скорее позитивно отношусь к 2 работам сразу, если человек с ними обеими справляется. На практике это обычно одна основная full time и вторая - part time (преподавание,
А вы что думаете?
🔥 - уже работаю на 2+ работах: это новая реальность
👍 - пока сомневаюсь, но смотрю в эту сторону
🤔 - мне и на одной работе хорошо
🤔65👍45🔥32❤2😁2
Упрощай и властвуй: RecSys в одну стадию
Недавно на весь рекомендательный мир прогремел новый тех репорт модели OneRec от китайского аналога тиктока Kuaishou. Они заменили многостадийную рексистему на одну генеративную нейронку и получили приличный рост метрик. Но пока все еще стоит вопрос о массовой применимости такой модели.
Мои коллеги из Яндекс Лавки недавно тоже отказались от кандидатогенерации. Теперь их catboost в рантайме скорит весь ассортимент даркстора (до 5000 SKU), укладываясь в 300 мс. И это уже может быть массово полезно очень многим!
📈 Внутри статьи — рассказ о том, как инженеры Лавки избавлялись от лишних признаков, по-хитрому готовили фичи, оптимизировали рантайм катбуст, и что всё это в итоге дало.
Как знать, может скоро мы все окажемся в мире без кандидатогенерации!
Недавно на весь рекомендательный мир прогремел новый тех репорт модели OneRec от китайского аналога тиктока Kuaishou. Они заменили многостадийную рексистему на одну генеративную нейронку и получили приличный рост метрик. Но пока все еще стоит вопрос о массовой применимости такой модели.
Мои коллеги из Яндекс Лавки недавно тоже отказались от кандидатогенерации. Теперь их catboost в рантайме скорит весь ассортимент даркстора (до 5000 SKU), укладываясь в 300 мс. И это уже может быть массово полезно очень многим!
📈 Внутри статьи — рассказ о том, как инженеры Лавки избавлялись от лишних признаков, по-хитрому готовили фичи, оптимизировали рантайм катбуст, и что всё это в итоге дало.
Как знать, может скоро мы все окажемся в мире без кандидатогенерации!
👍29🔥9❤7
Хранить нельзя списать: Юнит экономика, ч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
❤29🔥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 июля
👍23🔥12❤4🤣1
Один АВ-тест в год или положить прод?
Всем хочется простого, человеческого счастья, чистого кода и стабильности ML-систем. Но это требует много времени и навыков. Поэтому в таких системах проводить изменения сложно и обычно катают один АВ-тест в год: не преувеличиваю, видел такого немало
Другая крайность - костыль на костыле в коде, АВ-тесты текут рекой, но половина из них невалидны
Сам я адепт быстрых изменений-костылей, но и за валидность АВ. Поэтому очень верю в концепцию двух репозиториев: research и prod. И я сам приложил руку к такой практике в паре компаний, и так уже работает во многих местах. Например, ML-cпецы финтеха Точка Банк недавно писали про это пост с докладом, где довольно хорошо раскрыли эту тему с примерами про масштабирование sklearn, тайпингами transformers и другими не всегда очевидными деталями.
В research код не такой красивый и быстрый, зато понятный и быстроизменяемый. В пределе research код вообще может возвращать csv-шку, которая заливается в прод на время А/В. И если эксперимент зеленый, то дорабатывается полноценное решение уже в prod репозитории с нормальными таймингами, стабильностью и регулярным обучением моделей
Самая большая сложность - внедрить правила / контракты, по которым эти репозитории дружат друг с другом. А не Jupyter notebook переписывать на Go с нуля каждый раз. Но если помучиться и сделать это, то дальше вас ждёт дивный новый мир, где research + prod = мощная коллаборация
А вы за какой вариант?
🌚 - Только стабильность prod кода и тайминги сразу, только хардкор
🔥 - За быстрые эксперименты, пусть и .csv. Если дает метрики, то по существующим договорённостям перенесём в prod решение с небольшими доработками
⚡️- Вжух-вжух и в продакшен, дальше видно будет. Мир быстро меняется: может за полгода выйдет gpt-6 и мы перепишем все с нуля
Всем хочется простого, человеческого счастья, чистого кода и стабильности ML-систем. Но это требует много времени и навыков. Поэтому в таких системах проводить изменения сложно и обычно катают один АВ-тест в год: не преувеличиваю, видел такого немало
Другая крайность - костыль на костыле в коде, АВ-тесты текут рекой, но половина из них невалидны
Сам я адепт быстрых изменений-костылей, но и за валидность АВ. Поэтому очень верю в концепцию двух репозиториев: research и prod. И я сам приложил руку к такой практике в паре компаний, и так уже работает во многих местах. Например, ML-cпецы финтеха Точка Банк недавно писали про это пост с докладом, где довольно хорошо раскрыли эту тему с примерами про масштабирование sklearn, тайпингами transformers и другими не всегда очевидными деталями.
В research код не такой красивый и быстрый, зато понятный и быстроизменяемый. В пределе research код вообще может возвращать csv-шку, которая заливается в прод на время А/В. И если эксперимент зеленый, то дорабатывается полноценное решение уже в prod репозитории с нормальными таймингами, стабильностью и регулярным обучением моделей
Самая большая сложность - внедрить правила / контракты, по которым эти репозитории дружат друг с другом. А не Jupyter notebook переписывать на Go с нуля каждый раз. Но если помучиться и сделать это, то дальше вас ждёт дивный новый мир, где research + prod = мощная коллаборация
А вы за какой вариант?
🌚 - Только стабильность prod кода и тайминги сразу, только хардкор
🔥 - За быстрые эксперименты, пусть и .csv. Если дает метрики, то по существующим договорённостям перенесём в prod решение с небольшими доработками
⚡️- Вжух-вжух и в продакшен, дальше видно будет. Мир быстро меняется: может за полгода выйдет gpt-6 и мы перепишем все с нуля
🔥40⚡8🌚4🗿1
Мои экс-коллеги из WB проводят RecSys Meetup!)
Обещают рассказать много всего передового: трансформеры, semantic IDs, балансировка интересов пользователей и продавцов, связь онлайн и оффлайн метрик рекома
А если подетальнее, то в программе:
- Semantic IDs: архитектура и наш опыт внедрения
- Трансформеры в персональных рекомендациях: от гипотез до AB-тестирования
- Счастье пользователя vs счастье продавца. Онлайн-доранжирование и байесовская оптимизация в товарных рекомендациях
- Как мы обучаем CLIP-ы для текстовых тегов
Митап пройдет 28 августа в 18:00 оффлайн и онлайн
Для участия оффлайн нужна регистрация по ссылке
Обещают рассказать много всего передового: трансформеры, semantic IDs, балансировка интересов пользователей и продавцов, связь онлайн и оффлайн метрик рекома
А если подетальнее, то в программе:
- Semantic IDs: архитектура и наш опыт внедрения
- Трансформеры в персональных рекомендациях: от гипотез до AB-тестирования
- Счастье пользователя vs счастье продавца. Онлайн-доранжирование и байесовская оптимизация в товарных рекомендациях
- Как мы обучаем CLIP-ы для текстовых тегов
Митап пройдет 28 августа в 18:00 оффлайн и онлайн
Для участия оффлайн нужна регистрация по ссылке
🔥18❤9🥴7🤣6👍3
Хуже = лучше
Моя команда в Я.Маркете внедрила метрику дискаверийности (новизны) рекомендаций товаров. И в этом полугодии мы пробуем ее активно растить
Естественно, посмотрели статьи про рост beyond accuracy метрик, внедрили успешные подходы из них, запустили А/В и …
научились стат значимо метрику дискавери снижать 🌚
И меня это очень порадовало
Теперь мы точно знаем, что влияет на метрику в минус - будем делать ровно наоборот и вероятно получим рост! Так что «красные» А/В тесты с падением метрик - часто гораздо полезнее кучи «серых» тестов без изменения метрик
А вообще, вопросиков к современным статьям очень много (особенно в recsys). Неправильный train-test split, подбор метрик под результаты, специально недотюненные бейзлайны, …
Поэтому я обожаю reproducibility reports (впору уж писать свой), где независимые авторы пробуют повторить результаты из статей - и пишут свои менее biased выводы. Один из самых известных в recsys Turning Dross into gold loss: is Bert4Rec really better than SasRec? пару лет назад позволил внедрить SasRec-like модели почти во всех доменах и компаниях
В общем, проверяйте даже «общепринятые» подходы и радуйтесь, если смогли подвинуть ваши метрики даже вниз - отсюда появляется куча идей, как подвинуть их уже вверх 👆
Моя команда в Я.Маркете внедрила метрику дискаверийности (новизны) рекомендаций товаров. И в этом полугодии мы пробуем ее активно растить
Естественно, посмотрели статьи про рост beyond accuracy метрик, внедрили успешные подходы из них, запустили А/В и …
И меня это очень порадовало
Теперь мы точно знаем, что влияет на метрику в минус - будем делать ровно наоборот и вероятно получим рост! Так что «красные» А/В тесты с падением метрик - часто гораздо полезнее кучи «серых» тестов без изменения метрик
А вообще, вопросиков к современным статьям очень много (особенно в recsys). Неправильный train-test split, подбор метрик под результаты, специально недотюненные бейзлайны, …
Поэтому я обожаю reproducibility reports (впору уж писать свой), где независимые авторы пробуют повторить результаты из статей - и пишут свои менее biased выводы. Один из самых известных в recsys Turning Dross into gold loss: is Bert4Rec really better than SasRec? пару лет назад позволил внедрить SasRec-like модели почти во всех доменах и компаниях
В общем, проверяйте даже «общепринятые» подходы и радуйтесь, если смогли подвинуть ваши метрики даже вниз - отсюда появляется куча идей, как подвинуть их уже вверх 👆
🔥28👍16❤7😁4