Lessons learned

Наткнулся на отличную статью от Андрея Лукьяненко про опыт, полученный за 10 лет в DS. Подписываюсь под каждым пунктом!

Что из неочевидного хочу добавить от себя

1. Ваш руководитель / старший товарищ - это ваш "ресурс"

Я глобально верю в идею TLaaS - Team Lead as a Service. TL очень заинтересован в вашем росте, поэтому если у вас есть блокеры (инфраструктура, непонятные требования etc), то вы можете "использовать" TL как ваш ресурс)

2. Вы лучше всех в компании разбираетесь в своей области

В конкретном юпитер ноутбуке, задаче или области вы разбираетесь лучше, чем ваш старший товарищ, тим лид или CEO/CTO. Вы - эксперт) И скорее всего именно вы знаете как лучше - предлагайте свои идеи!

3. Ошибаться - нормально. Ненормально не учиться на своих ошибках

Однажды я чуть не выкатил в прод рекомендательный блок с обратным порядком сортировки товаров. Просто забыл указать
df.sort_values(ascending=False)

Но из этого кейса у меня родился неплохой подход по автотестам для рек систем. И с тех пор эта ошибка не повторялась (но конечно бывали другие 🙃)

Сегодня пост про soft-навыки

Есть у меня странное хобби: я собираю истории провалов ML проектов 😱

В историях успеха на конференциях вы чаще всего слышите про новые архитектуры нейронок, хитрые аналитические приемы и все то, что называется hard skills. Но в извечтных мне историях провалов чаще говорят про soft: не обсудили до конца финальный ml-результат, поехали сроки на полгода, отлично решили не ту задачу - и это еще не полный список 😉

Недавно видел общедоступную историю не успеха в канале "Нескучный data sceince" https://news.1rj.ru/str/not_boring_ds
В общем, кейс довольно сильно совпадает с моим опытом. Действительно, стоит заранее убедиться, что:
- бизнес понимает, зачем ему нужна модель
- как ее применять
- какой бизнес-эффект

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

Всем успешных ML-проектов!)

Как тестировать рекомендательные системы

Под одним из прошлых постов было много вопросов о тестировании рек систем: как не выкатить на прод рекомендации в обратном порядке, например)

Я на практике использовал такие тесты:

1. Полнота данных
70% ошибок максимально глупые: упала база и не залились данные. Сменился год с 21 на 22 и у вас полетела часть запросов
Решается обычным assert-ом на кол-во строк, уникальных дат/юзеров/товаров

2. Качество фичей
Есть тысяча статей про distribution shift, детекцию выбросов и т.д., но обычно проблемы куда проще. Использовать np.mean вместо np.nanmean и получить 90% NaN в фиче? Иметь средние чеки в 1млрд руб, хотя реальные чеки до 5-10к? Вот с чем стоит побороться в первую очередь!
Решается также обычным assert-ом

3. ML и бизнес метрики
Assert-ы на ml метрики на тестовой выборке. Если позволяет инфра, то каждое переобучение модели сопровождать мини-АВ

4. Бизнес-адекватность
У 70% пользователей в топе рекомендаций рестораны с рейтингом < 3.0? Популярные товары не в топе? Тоже стоит с этим побороться

Лучше классическими автотестами на real-time / батчевых запросах к модели

Обычно хватает ~1к запросов и базовой логики с теми же assert-ами

5. Смотреть глазами
Никто не любит это делать, но потратьте 3 минуты своего времени и посмотрите рекомендации модели для себя и своего соседа на адекватность перед выкаткой. Это спасет вам много времени и денег 😅

#recsys

Сколько денег приносит платфома А/В тестирования?

Наткнулся на неплохую бизнесовую статью об этом от Glowbyte. Там описаны 3 источника выгоды от АВ платформы:

1. Снижение трудозатрат аналитиков
2. Возможность тестить больше гипотез
3. Рост доверия к алгоритму принятия решений

В целом, согласен) Я бы сюда еще добавил:

4. Можем понять, что фича/проект не успешны и откатить их

Вы даже не представляете, сколько только на моем опыте было скидок, партнерств с брендами и продуктовых фичей, которые казались гениальными. На них тратились огромные бюджеты, силы разработки, но всего пара А/В тестов показывала, что инкрементального эффекта они не дают. Хотя в абсолютах от продаж занимают значимую долю

5. Скорость принятия решений

На ручной обсчет А/В может уйти много времени. Бывают более приоритетный задачи. А платформа А/В считает тесты обычно на следующий день после окончния

Живем в безумное время: планы очень быстро меняются, куча перемещений,  и в целом изменений в жизни

Одно из них связано с тем, что Яндекс купил Delivery Club. Что ж, это хорошая возможность, чтобы немного сменить вектор своего развития

В ближайшее время я перехожу в Яндекс.Лавку 🛒 руководить ML в коммерции: прогноз спроса, оптимизация остатков, цен, промо и многое другое!

Так что скоро будут новые посты на эту тему 😉

Оптимизация цен на товары: прогноз спроса ч.1

Фундаментальная задача везде, но вокруг неё так много мифов! Давайте начнём разбираться с базы

Q = Q(P) - спрос в штуках, зависит от цены
P - цена
C - издержки на 1 штуку товара

Базово задача - максимизировать прибыль:
Q(P) * (P - C) --> max

И самое сложное - смоделировать зависимость Q(P)

Экономисты предполагают, что спрос складывается из многих таких выборов между продавцами, товарами и тд. Поэтому
Важна не абсолютная цена (79 руб), а относительная (Р/ P_competitor = +2% к цене конкурента, P / P_analogue = -5% к цене товара-аналога, P/ P_yesterday = +3% к вчерашней цене этого же товара)

Поэтому функция спроса на товары
Q = f(P/ P_competitor, P / P_analogue, ...)

Вообще, теоретически, на этом можно остановиться и применять наш любимый ML для прогноза Q с фичами на относительные цены. Но в реальности все сложнее 😅

Об этом - в следующих постах

#pricing #timeseries

Пока думал, с чего начать серию постов о трудностях прогноза спроса Q(P, др. факторы), коллеги из Самоката выпустили статью о своём прогнозе спроса

В основном рассказ про то, как заставить бустинги работать на шумных временных рядах. Из интересного:

- Доп. статистическая модель прогноза ошибки бустинга. Деревья плохо ловят тренды и иногда средние по товарам, поэтому подход оправдан
- Восстановление спроса с учётом остатков товара
- Прогноз новинок

Мой рекомендасьон к прочтению. Особенно если вы раньше тесно не работали с временными рядами)

Прогноз спроса ч.2
Несмещенность эффекта цены

Итак, мы прогнозируем спрос в зависимости от цены Q(P). Для наглядности возьмем самую простую линейную модель:

Q(P) = c0 + c1 * P

Нам важна несмещенность коэффициента c1, чтобы корректно управлять ценой. Пожалуй, важнейший фактор, влияющий на несмещенность - пропущенные переменные

Есть даже красивая теорема о пропущенной переменной:

Если ты забыл добавить в модель фичу, которая влияет на таргет и коррелирует с ценой,  то коэффициент c1 (~влияние цены) смещается

То есть, если в праздники растут скидки, и вы не добавили фичу на праздники - влияние цен учтено неверно:)

(!) Также если влияние цены нелинейно, и ты не добавил условно price**2 / не применил нелинейную модель, то коэффициент смещается 🥶

#pricing #timeseries

..и что делать?

Во-первых, учитывать другие фичи, которые коррелируют с ценами. То есть в случае линейной модели важно прогнозировать
Q(P) = f(P) + g(other features)

Я бы не рекомендовал использовать что-то сложнее:

Q(P) = f(P) + g(other features)
Q(P) = f(P) * g(other features)

Иначе потом будет крайне сложно решать оптимизационную задачу. Например, коллеги из Я.Маркета используют довольно сложные нейронки для функций f(P) и g(*). Но в конце эти функции просто суммируются и нормируются

А что ещё можно делать - расскажу в следующих постах 😉

Итоги года

2022 был очень напряжённым на события в мире. Много переживаний и саморефлексии. Что я понял за это время и во что это вылилось:

1. Стал "Head of ..." на 9 мес и вернулся обратно в "ML team lead"

Как оказалось, на уровне "Head of ..." вместо многоточия можно ставить что угодно: в основном, тут работа по построению команды, найму, росту людей в команде, общению с бизнесом. Поэтому условно не так важно Head of чего вы становитесь

Это был прикольный опыт (со стороны "менеджеров" бизнес, команда и вообще все выглядит иначе), но я все же хочу быть поближе именно к ML продуктам. Из этого последовал такой поинт

2. Переход в Яндекс.Лавку 🥖

В целом, критериев выбора работы я сформировал 3:
- Интересная и сложная ML / оптимизационная задача
- Большое влияние на бизнес
- Сильная команда

В Лавке все это было! Поэтому тут я занимаюсь как Team lead алгоритмами прогноза спроса, закупки товаров, и ценообразованием

3. Кажется стал digital nomad-ом

За год побывал в Киргизии, Армении, Грузии, Турции и на 2ух островах: Сахалине и Шри-Ланке. И даже покатал на борде недели 3 суммарно 🏂

Совмещать продуктивную работу и кучу путешествий можно - проверено ✔️

4. Запустил свой курс по А/В

Долго к этому шёл, и наконец первый поток курса завершен!) Смог рассказать кучу всего про бизнесовые моменты в АВ, но осознал, что многим интересны ещё и технические детали. В 2023 будет второй запуск, но уже в обновлённом формате - сейчас думаю над ним

..и в 2023 надеюсь мир вокруг меня станет постабильнее - смогу писать больше постов 😄

Что тебя ждет при переходе Team Lead —> Head of ML
Вы просили в комментариях пост на эту тему - я делаю)

Если кратко в 3 пунктах:
- Позиция именно про людей = команду 💪
- Умей говорить “нет” так, чтобы не обижать людей
- Как сам все организуешь - так все и будет. А-ля “Делай нормально - нормально будет" 🧐

Дальше немного рандомных, но важных поинтов про работу с людьми, задачами и деньгами


Люди
Ты руководишь непосредственно team lead-ами (1-3 чел), а не дата саентистами (суммарно их до 25 чел). Если маркетинг говорит, что кто-то неверно сделал дешборд / модель странная / whatever, то нужно прийти к тим лиду, обсудить это с ним - а он сам уже поговорит с командой

Приходится давать негативный фидбек (если не ты, то кто?). А потом еще и придумывать на 1-1, как можно исправить проблемы
Приходится сравнивать людей между собой (привет, review) - лично мне это не очень нравилось

Если бизнес хочет от вас странных вещей, то ты должен им обьяснить, что не так и предложить альтернативу


Задачи
Внезапно задач а-ля “Сделай модель оттока” нет. Вместо этого есть боли бизнеса. “Кажется, мы тратим слишком много денег на привлечение новичков. Как нам растить клиентскую базу?”. В куче болей ищешь действительно важные (95% негативного фидбека - про крайние кейсы, которые в масштабах компании ни на что не влияют). И думаешь “что ML-ного делать?”, чтобы это исправить. А вот “как делать?” - решают скорее тим лиды и члены команд

Надо продавать ML идеи бизнесу. Это сложно. Нужно считать финансовый эффект от моделей: да, возможно ты откроешь эксель😱
Внезапно обнаруживаешь, что гениальные идеи изначально финансово убыточны
Вдруг понимаешь, что иногда хороший дашборд полезнее SOTA модели


Деньги
Бюджет на команду, новые ставки, закупка чего-то - теперь это к тебе)
Например, бюджет на команду Х, суммарно все хотят повышений зп до 1.5 Х - тебе нужно что-то с этим делать 🤔
Нужно много общаться про ревью и про то, кто что хочет от него

Надо показывать денежный эффект от работы команды (не ROC AUC +3%, и даже не +2% конверсии), и убеждать бизнес, что именно вы его принесли. А/В тут здорово помогают! Ах да.. помогают, если ты обьяснил бизнесу, что это такое:)

Данные ~ сила влияния в компании

Недавно осознал, что возможность работать с данными даёт очень много власти (да-да!) внутри компании

Как:
1. Создаёшь 1 полезный дашборд
2. Ставишь регулярно встречу, где аналитики и бизнес смотрят на дэш
3. На этой встрече рассказываешь инсайты из данных дэша, проблемы и тд
4. По результатам встречи ставишь задачи другим командам на исправление проблем (разработке, операционной команде, ...)

Profit - вы стали частично влиять на другие команды 😈

Про цели на уровне всего бизнеса в конкретных метриках

Супер важно до старта любых проектов договориться, чего вы хотите на уровне всего бизнеса. Из-за целей может меняться набор проектов (ратсите заказы - нужны проекты с промо, растите маржинальность - нужно что-то совем иное) или их настройки (повышать / понижать цены в динамическом прайсинге)

Обычно все метрики крутятся вокруг заказов в шт, выручки в руб, маржи в руб и маржинальности в %. Я определяю, хороша ли целевая метрика тем, насколько легко ее “хакнуть”. Пара спорных примеров целей бизнеса (легко хакнуть)

1) Максимизируем заказы
Спорно, потому что скорее всего это приведет к сильному падению маржи и маржинальности
Как хакаем: Даем скидку 90% на все - перевыполняем любые мыслимые KPI, получаем кучу бонусов (если после такого маневра у компании останутся хоть какие-то деньги)
Иногда рабочая стратегия, если сейчас вы захватываете долю рынка, а потом резко сможете стать прибыльными - выиграете за счет масштаба

2) Максимизируем выручку
Лучше, но хакается почти также: даем не такую агрессивную скидку, чтобы рост заказов был > падения цены (выручка растет)

3) Максимизируем маржу
Пам-пам, тоже не очень хорошая метрика
Хакнуть сложнее. Но представьте, что у вас был бизнес с маржинальностью 20% и маржой в рублях = 1 млрд. Можно сделать маржинальность 1% и маржой в рублях 1.1 млрд. Номинально маржа в руб выросла, но бизнес стал сильно менее выгодным по маржинальности в %. +любое внешнее колебание (выросли ставки по кредиту бизнесу, зп рабочих, закупочные цены) и выши +1.1 млрд стремительно превратятся в условно -3 млрд

4) Максимизируем маржу/выручку с ограничением на маржинальность
Вот это уже годится!
Но тоже есть пара нюансов (опрос ниже)
И можно еще лучше (следующий пост)

В хороших компаниях умеют рисовать кривые размена метрик. На графике типичные кривые размена маржа - выручка, маржа - заказы

Верный ответ на опрос выше - 3ий и 4ый

1) Точка 1 - а, б
В ней маржа +15%, выручка +0%
поэтому это точка максимума как маржи в руб, так и маржи в %

(!) Прелесть в том, что это кажется идеальным вариантом, но график вам немножко привирает 😈
Надо посмотреть на то, какой будет прирост заказов в этой точке. А он будет сильно отрицательным (пересечение продолжения оранжевой кривой и горизонтали от точки 3 где-то в отрицательной области оси Х)!
Возможно вы вырастите маржу на 15%, но снизите заказы условно в 2 раза (~потеряете кучу клиентов)

2) Точка 3 - в
Изменение маржи, % = маржа * (1 + delta_margin) / (выручка *(1 + delta_revenue)) = (маржа / выручка) * (1 + delta_margin) / (1 + delta_revenue)

чтобы маржа в % не менялось надо имет delta_margin = delta_revenue (как раз верно на диагонали)
Максимизация выручки - движение вправо вдоль оси Х. Максимальный сдвиг вправо, но не ниже диагонали дает нам точку
3 - в: максимум выручки при ограничении, что маржа в % не падает

3) Точка 2 - г
Вот тут интереснее
Ограничение, что маржа в руб не падает соответствует пересечению диагонали и оранжевой кривой (точка 4)
Чтобы его сохранить, но мыслить в размене маржа-выручка, нужно провести огранчение по горизонтали - мы не можем падать ниже горизонтали, двигаясь по синей кривой - это нам дает точку 2

Обратите внимание, и в точке 2, и в точке 3 мы максимизируем выручку при огрничении на маржинальность. Но оказывается, маржинальность = маржа / заказ накладывает сильно более жесткое ограничение (получаем прирост маржи в руб около 5% вместо 10%), чем маржа = маржа / выручка

Последний душный пост в серии или лучшая Цель = размен метрик

Какие минусы max выручка, маржинальность >= Х%:

1) Не позволит вам сильно вырастить выручку

max выручка = двигаемся вправо по синей кривой;
маржинальность >= Х% = не ниже диагонали

—> мы должны выбирать точку на пересечении диагонали и синей кривой 🤔
Единственный способ дальше улучшать выручку - растить маржу в руб сильнее, чем выручку. Просто скидками / маркетингом / минорными улучшениями продукта не обойтись. Нужно делать качественные улучшения (новый алгоритм прайсинга условно) и сдвигать синюю кривую вверх

2) Переход из точки А в точку В дает увеличение прироста маржи 5 —> 10% (+5 пп), а падение выручки всего c 5 до 4% (-1 пп) 📈
То есть мы размениваем 1 пп выручки на 5 пп маржи - неплохо, да? Но с текущими целевыми метриками этого сделать нельзя


Цель = допустимый размен метрик
Поэтому в идеале ставить цель в допустимых разменах метрик. Например: готовы менять -1 пп выручки на +3 пп маржи
Это дает касательную к графику с наклоном 1/3 —> выбираем точку В

Можно эту цель дополнительно ограничить условием ”маржинальность в % не падает”

Космические плюсы этого подхода:
- Легко балансировать метрики. Причем сколько угодно штук
- Не уходите в крайность вроде max Маржа, руб (помните кейс в посте выше, где маржа в руб растет на 10%, а маржинальность падет с 20% до 1%?)
- Просто аккуратно задаете вопросы бизнесу “На сколько % выручки мы готовы поменять 1% маржи”? Поначалу никто не будет хотеть вам отвечать (потому что именно это в итоге определяет цель компании, а определить ее сложно), но если вы будете настойчивыми, то оно того стоит!

Бонус для тех, кто еще не устал от душности в постах:
- Видео с теорией про то, как строятся кривые и находятся точки оптимума. Много формул, графиков, но тема разбирается от и до

P.S. Удивительно, но я не смог найти ни одного короткого и простого обьяснения кривых размена маржа-выручка или маржа-заказы 👀
Видимо, буду сам писать пост на Хабр про них

Недавно во Вьетнаме встретил человека, который не умеет читать на родном языке - шок

Но еще больший шок, когда data-people плохо знают свой родной язык - метрики 😱

Поэтому с понедельника начнём разбирать, как выглядят в реальном мире разные концепции метрик: воронка конверсий, юнит экономика и PnL

Воронка конверсий - идея

К нам на сайт / в приложение приходят X пользователей в неделю
30% из них кликают на карточку товара = 0.3Х
Из этих 30% аж половина (50%) жмет “добавить в корзину” = 0.3 * 0.5X
Ну а реально оплачивают из нажавших всего 10% = 0.3 * 0.5 * 0.1X = 0.015 Х


💡 Базовых идей в воронке конверсий 3
1. Заказы = Трафик * конверсия из захода в приложение в заказ

2. Конверсия из захода в приложение в заказ (CR appstart-order) раскладывается на произведение поэтапных конверсий:
CR appstart-order = CR appstart-item click * CR item click - add to cart * CR add to cart - order

3. Мы можем работать над отдельными этапами воронки. Если улучшаем конверсию на одном этапе и не снижаем конверсию на других этапах + не влияем на трафик, то мы растим заказы. Вот про эту идею часто забывают 🥲. Разберем ее детальнее завтра


Зачем такая концепция нужна?

1. Определить, на каком этапе пути пользователя есть проблемы
В кейсе выше CR appstart-order = 1.5% (0.015 Х)
Кажется, можно лучше (спойлер: не всегда). Тут выглядит проблемной конверсия из добавления в корзину в оплату (CR add to cart - order = 10%)
Тут уже можно дальше закапываться и смотреть, что не так: оплата картой не работает? Юзер добавил товар в корзину, а при оплате видит, что его нет в наличии? Доставка стоит 100500 руб?

2. Упростить понимание бизнеса:
Сравните запрос: “Что-то у нас мало заказов - что делать?” и “Давайте посмотрим, какой этап воронки конверсий у нас проседает”

3. Ускорить ваши А/В 😇
Дисперсия поэтапных конверсий (того же CR add to cart - order) обычно кратно ниже дисперсии общей конверсии (CR appstart-order) и тем более заказов

Поэтому для роста условно “CR add to cart - order” на 1 пп нужно в разы меньше наблюдений, чем для роста на 1 пп “CR appstart-order”. На есть нюансы из-за базовой идеи №3

Нюансы воронки конверсий

Как и писал выше,
Мы можем работать над отдельными этапами воронки. Если улучшаем конверсию на одном этапе и не снижаем конверсию на других этапах + не влияем на трафик, то мы растим заказы

Представьте, что вы решили добавить на главной странице огромный баннер “Скидка 90% на все по промокоду DISCO”. Клиенты радостно выбирают товары, добавляют в корзину, собираются оплатить и тут.. не видят поля, куда ввести промокод. Что происходит с точки зрения метрик:
- CR app start - item click — растет
- СR item click - add to cart — растет
- СR add to cart - order — падает
- Общая конверсия CR appstart-order — скорее всего не меняется

По идее баннер размещен на главной странице, поэтому влияет в первую очередь на CR app start - item click. Если аналитик не подумал посмотреть в А/В остальные метрики, то он мог бы решить, что фича отличная, а это не так!
———————

Пример выше немного вымышленный, …хотя посмотрите на главные страницы некоторых приложений 😅

Но вот вам менее очевидные кейсы из реальной жизни:

- Убрали принудительную регистрацию при старте приложения. Нужно регистрироваться только при оформлении заказа

- Стали показывать стоимость доставки не только на корзине, но на каждом этапе воронки

- Добавляем раздел “Избранное” на маркетплейсе машин

- Добавляем фичу “Подписаться на скидки на данный товар”

Можете подумать, как себя поведут разные конверсии в этих кейсах. Ну а разбор будет уже завтра 👀