Кстати, обратите внимание, в одной задаче (оптимизация цен, промо) я предлагал использовать RMSE, а для того же прогноза спроса в другой задаче (закупка товаров) - квантильный лосс

В целом, лосс-функцию нужно выбирать исходя из задачи, а не формы распределения таргета

Интересно в следующем посте послушать про MAPE, RMSLE, MALE, SMAPE и WAPE метрики?)

Часть 2. Более продвинутые метрики регрессии

1. MALE и RMSLE (L - Logarithmic)
Для начала, поговорим про аналоги MAE и RMSE, посчитанные на логарифмах таргета: ln(1 + y)

Зачастую их используют, когда у таргета довольно большой разброс значений. Например, когда прогнозируют продажи товаров: есть бОльшая часть товаров с продажами в 0-2 шт, и небольшая с >1000 шт. Это помогает не переобучаться под небольшую часть товаров с относительно большими продажами

Также логарифмирование таргета позволяет вносить нелинейность по фичам. Например, если вы обучаете линейную регрессию, прогнозируя ln(1 + y), то итоговый прогноз y = exp(a0 + a1*x1 + a2*x2) - 1 уже нелинеен по фичам из-за exp

Когда логарифмирование оправдано:
- Значения таргета >= 0
- Есть четкое теоретическое обоснование логарифма таргета. Например, для оценки функции спроса есть хорошая теория про лог-линейные и лог-лог модели

В остальных случаях я предложил бы быть крайне аккуратным с логарифмированием, потому что:
- Теряется связь с изначальной бизнес-задачей: бизнес интересует прогноз y, а не ln(1+y)
- Из-за экспоненты может быть неконтролируемое влияние фичи на таргет: небольшое изменение фичи может очень сильно менять прогноз
- Напомню, что только лишь логнормальное распределение таргета - не повод использовать MALE и RMSLE

#metrics

Мои итоги 2021 года
Уже все подвели итоги года - и мне пора) 2021-ый был довольно занятным

Работа
1. Стал тимлидом
Совсем другой опыт - теперь на многие вещи смотрю под другим углом. Полюбил MVP, скрам, дейли митинги и тестирование кода. Поверьте, все это и правда делает жизнь всей команды значительно лучше. Даже тесты кода 😅 - хоть их и очень не хочется писать, но это супер полезно

2. Круто, что я прям вижу прогресс команды
С ума сойти: всего за год наша команда сделала из ничего (это не преувеличение) полноценную платформу А/В тестов в Delivery Club! Через нее прошла уже не одна сотня экспериментов. Даже написали про нее статью на Хабр. Есть еще ооочень много вещей, которые нужно допилить или перепилить полностью, но у нас уже есть довольно хорошо работающий продукт, ну классно же?)

В этом году я своими глазами увидел (и приложил к этому руку и сердце), как с нуля строились большая махина рекомендательной системы: от инфраструктуры продакшена и первых моделей до первых провалов и долгожданных успехов. Под конец года уже несколько моделей в проде, и то ли еще будет:)

3. Немножко побыл продактом
Помог в формировании нескольких фич... и узнал, что это ни капли не просто! Не уверен, проще ли стать хорошим продактом или дата саентистом) Огромное спасибо нашему продакту Лизе за бесценный опыт, которым она со мной поделилась. Это правда словно другой мир - не менее интересный и сложный, чем мир DS

4. Провел около 50 собеседований
Очень круто меняется отношение к собесам в целом, когда оказываешься по "ту сторону стола". Из лично моих открытий:
(1) Не смотря на бесчисленные онлайн школы, факультеты университетов, MADE, ШАД и другие способы образования, есть крайне мало людей даже junior, которые основательно разбираются в реально прикладном ML. Нет, не в нейронках, а чем отличаются where и having в sql-запросах:) Немного утрирую, но если вы собираетесь залететь в мир DS - заботайте лучше SQL и pandas: на первых порах да и потом тоже они (или их аналоги) будут составлять огромную часть вашей работы
(2) С другой стороны иногда встречаются действительно таланты, у которых можно даже узнать что-то новое на собседовании. C одним кандидатом (он теперь в нашей команде!) мы часа 3 общались про развитие платформ А/В тестов. В общем, я недоумеваю, куда исчез "средний класс" в data science)
(3) Начал спрашивать ML system design - топовая вещь 💪
Практически всегда одного его достаточно, чтобы определить уровень кандидата
(4) Задачу, которую я придумал где-то год-полтора назад для собеседований, ушла в массы) Возникла она из реального вопроса бизнеса, и в оригинале звучит так:
У ресторана есть радиус доставки (R). Во сколько раз увеличится среднее время доставки, если увеличить радиус доставки в 2 раза? Для простоты можно считать распределение клиентов по площади круга равномерным. Подсказка - он вырастет меньше чем в 2 раза / ровно в 2 раза / больше чем в 2 раза? Если есть интерес и желание - пишите ответы в комментариях)

Extracurricular
1. Начал снова писать в канал
За этот год на ml4value подписалось почти 500 человек (х2.5 к 2020)! Огромное спасибо всем моим читателям за комментарии и личные сообщения после постов. Еще стал замечать, что многие из новых знакомых уже знают меня через канал - чуть-чуть почувствовал себя знаменитым)

2. Выступил на конференции (если интересно, ссылка на видео тут)
Уже давно собирался - и безумно рад, что выступил!
Еще с конференциями связано 2 факапа года - пропустил буквально на недельку запись на выступление на МатеМаркетинге. Написал, но не успел до конца года опубликовать статью на Хабр(
Успех года - волей случая прошел на Highload++ 2022, присоединившись в последний момент к моему коллеге Жене. Спасибо тебе огромное - думаю, у нас получится классные дуэт!)

3. Сходил на 10+ встреч Random Coffee от ODS
Успел встретить всех: от девушки с моего же факультета до знаменитого Леши Натекина (один из основателей ods)


Ну и в конце, лично мое открытие года - кофе в дрип-пакетах. Это просто шикарно - больше нечего добавить:)
Всех с наступающим Новым Годом🎄

Задача с собеседований из поста выше оказалась довольно интересной, судя по ответам в комментариях) Поэтому сделаю опрос с немного усложненным вариантом задачи 🧐

Кажется все, кто хотел ответить на вопрос, сделали это - давайте разберем задачку 🤓

*в комментариях идет интересная дискуссия про то, что есть 2 понимания "равномерного" распределения на круге. Поэтому есть 2 варианта решения

На самом сама задача довольно простая, но в ней есть несколько сложных подводных камней. Однако довольно много подписчиков (12%) ответили верно!)

(1) Равномерное распределение клиентов по площади круга
Первое, что интуитивно приходит в голову при решении - среднее пропорционально либо радиусу R, либо площади круга Pi * R^2. И это первый подводный камень) Давайте аккуратно его обойдем и для начала посчитаем, какое среднее время доставки в круге радиуса R

У равномерного распределения есть прекрасное свойство: медиана = среднему. Поэтому среднее время доставки = радиусу (X) круга, который по площади в 2 раза меньше круга радиуса R

Pi * X^2 = Pi * R^2 / 2
X = 1 / sqrt(2) * R

Если увеличить R в 2 раза, то среднее (X) тоже увеличится в 2 раза!
---------

(2) Реальное распределение клиентов по площади круга
И вот он второй подводный камень: клиентов доставки, а не просто всех людей. Клиент = тот, кто заказывает. Вероятность заказа падает при росте времени доставки. Поэтому бОльшая часть клиентов будет сосредоточена ближе к центру круга, а не равномерно. Поэтому:

Pi * X^2 < Pi * R^2 / 2
X < 1 / sqrt(2) * R

Ответ: (1) ровно в 2 раза; (2) < 2 раз
---------

На самом деле есть еще довольно много бизнесовых причин, почему так происходит. Например, на дальние расстояния начинают ездить курьеры на машинах, а не ходить пешком. И в реальности среднее время доставки Х сильно меньше 1 / sqrt(2) * R !

Кстати, в том числе благодаря выводам из такой простой модели мы наслаждаемся доставкой из Самоката / Лавки на даче 🏡. Они могли увеличить радиус доставки с условных 5 км до 20 км без очень драматичного роста в среднем времени доставки

Продолжаем серию постов про метрики регрессии
Предыдущие посты - часть 1 про MAE и RMSE, часть 2 про MALE и RMSLE

Часть 3. Первая относительная метрика: MAPE

Абсолютные метрики (RMSE, RMSLE, ...) хороши своей простотой, но имеют ряд недостатков:
- Сложно интерепретировать и презентовать бизнесу ("у модели MAE = 307"; - "И что я должен с этим делать? Хороша ли модель-то?")
- Проблемы при обучении на разнородных обьектах (у одного товара 1к продаж в неделю, у другого - 5. Если усреднить RMSE этих товаров, то получится нечто странное)

Поэтому придумали относительные метрики!
Note:
- Macro average = считаем метрику по каждому обьекту, затем усредняем. Дальше речь пойдет именно о таком усреднении
- Micro average = считаем числители и знаменатели по каждому обьекту. Складываем все числители, все знаменатели. Делим один суммарный числитель на суммарный знаменатель. Это полный аналог MAE: macro MAPE = MAE / mean(y_true)

MAPE (Mean Absolute Percentage Error) = MEAN(|y_true - y_pred| / y_true)

Это простая и интуитивно понятная метрика, но есть нюансы:
- Может быть > 1
- Не симметрична: по-разному штрафует недопрогноз или перепрогноз
- Плохо работает при маленьких y_true. На практике можно делать так: MEAN(|y_true - y_pred| / (y_true + offset)). Это частично решает проблему

При обучении некоторых ml-моделей можно указать MAPE как лосс. Но у него неприятная производная. Поэтому на практике MAPE аппроксимируют через MALE, потому что:
1. ln(1 + f(x)) ~ f(x) при f(x) --> 0
2. ln(1 + |y_true - y_pred| / y_pred) --> |y_true - y_pred| / y_pred = MAPE при -//-
3. ln(y_pred + |y_true - y_pred|) - ln(y_true) --> MAPE при --//--
4. Сильное предположение, но на практике выполняется: |y_true - y_pred| --> 0 при |y_true - y_pred| / y_pred --> 0
5. ln(y_pred + |y_true - y_pred|) - ln(y_true) --> ln(y_pred) - ln(y_true) --> MAPE при -//-
6. Не забудьте взять модуль у первого выражения и получите, что MALE --> MAPE при небольших разницах в |y_true - y_pred|

Хороший рецепт: Loss = MALE, Метрика на валидации/тесте = MAPE

#metrics

Во многом моя концепция ML4Value сформировалась благодаря бакалавриату по мат методам в экономике. Путь из экономики в ML был довольно тернистым. До первой работы чисто в ML я прогнозировал временные ряды инфляции и ВВП в научной лабе, строил модельки риск-менеджмента на МосБирже и занимался sql-аналитикой в одном крупном банке. Когда-нибудь я обязательно рассказажу про этот путь в DS.

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

Кстати, у интервьюера Ромы Васильева есть отличный канал про начало карьеры в DS: там есть другие занятные интервью и полезные материалы по ML

Ссылка на канал Ромы: https://news.1rj.ru/str/start_ds

Наткнулся на занятную статью от Uber по прогнозу времени прибытия авто (ETA). Интересна она тем, что годами решаемая бустингами задача регрессии, теперь более эффективно решается сетками! Кажется, это начало конца бустингов

Сюрпризом для меня стало то, что Uber смог обучать трансформеры на табличных данных быстрее, чем xgboost благодаря data-parallel SGD. И не только быстрее, но и с лучшим качеством.

Метрики улучшили за счет разделения непрерывных фичей на бины = квантили. И каждый бин кодировали эмбеддингом. Так что второй вывод - эмбеддинги потихоньку захватывают мир) Есть ощущение, что через 3-5 лет весь ML сведется к тому, чтобы получить каким-то образом эмбеддинги, а затем искать ближайших соседей / делать другие простые операции

Пара других интересных фактов из статьи:
- Комбинируют нейронку и классическую "физическую" модель. Делают базовый прогноз через маршрутизатор (граф дорог), а разницу между фактом и этим прогнозом оценивают нейронкой
- Используют несимметричный huber loss, чтобы прогнозировать квантили времени прибытия

Российские власти помогают ответить на любимый вопрос с собеседований:
"MAPE больше штрафует за недопрогноз или перепрогноз?"

Выясняется, что -80% = падение в 5 раз, а +80% = рост в 1.8 раз 😅

MAPE больше штрафует за недопрогноз или перепрогноз?

На первый взгляд, кажется, что одинаково штрафует = MAPE симметричен. Обычно это доказывают логикой из самой формулы
MAPE = |y_true - x| / |y_true|
= |y_true + x| / |y_true|,
т.к |y_true - x| = |y_true + x|

Но на практике все несколько сложнее. Обычно мы используем MAPE для прогноза продаж и цен. То есть кейсов, где таргет >= 0.
В таком случае для недопрогноза mape не может быть > 100%, потому что минимальный прогноз = 0 --> |y_true - 0| / y_true = 100%
А вот для перепрогноза mape может уходить в бесконечность. Например, |1 - 8| / 1 = 700%

Поэтому для большинства боевых задач MAPE больше штрафует за перепрогноз --> ML-модели оптимально недопрогнозировать

Забавный факт
Чтобы исправить проблему несимметричности MAPE придумали Symmetric MAPE (SMAPE) = |y_true - y_pred| / (y_true + y_pred) / 2
Забавно то, что Symmetric MAPE не симметричный!)

#metrics

Похоже, настали непростые времена. Многие бегут от "военной операции", неожиданно релоцируются или просто ищут работу в такое время. Все это ужасно, и мне крайне жаль, что такое происходит в 21 веке

Понимаю, что этого мало, но если вам нужен совет/помощь, то я могу бесплатно:
- Дать советы по улучшению резюме
- Провести пробный собес
- Поговорить за сложные и не очень переходы в карьере
- Посоветовать, где и что можно учить по DS

Пишите в личку @Ivan_maksimov

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

Сейчас я DS team lead в Delivery club. Занимаюсь продуктовым ML: recsys, churn, A/B и немного NLP. До этого прогнозировал временные ряды и строил оптимизации поверх этого: оптимальные скидки, закупки товаров и т д

Подробнее можете посмотреть в моем LinkedIn. Если вы еще не поставили VPN - сделайте это

По любым вопросам пишите, не стесняйтесь. Надеюсь, смогу быть для кого-то полезным

Через 15 минут соберемся с 3-емя интересными DS на ламповый стрим про жизнь и ML

Если интересно - присоединяйтесь)

🎬 Ламповый стрим уже завтра. Поболтаем за жизнь и за DS. Начало в 18:00 по Мск.

👨‍🎨 Пригласил на стрим 3-х любопытных ребят (Андрей, Виктория и Иван). Про каждого для затравки расскажу в комментариях. Тут же в комментариях можете продолжать задавать вопросы и предлагать темы для обсуждений. Я все читаю🥷.

🤪 Про то, как начать в DS можно уже не спрашивать, вопрос уже избитый донельзя.

📜 Примерная повестка:
- Как работать и развиваться эффективнее.
- Организация рабочего пространства
- Пет проекты и стартапы
- Способы зарабатывать выше среднего в своей сфере.

📎Ссылка на стрим. Запись стрима будет 😇

Поделись постом со своими =)

Долго ли, коротко ли, но мы в Delivery Club начали серию публикаций о развитии рекомендательных систем внутри компаний

Сегодня опубликовали первую часть на Хабр. Многие из этих моделей мне довелось писать самому или участвовать в их развитии как тим лид / ML product manager

В статье все, как я люблю - максимум ml4value. Необычные решения с несколькими моделями. В общем, мой рекомендасьон к прочтению - надеюсь, вам понравится)

#recsys

В канале уже почти месяц не было постов: это потому что я готовил нечто интересное для вас всех) Но обо всем по порядку: на этой неделе небольшие вводные истории, а все лакомое буду писать уже с понедельника


Итак, примерно полгода назад я выступал и рассказывал о способах ускорить А/В тесты. Даже тогда я много времени уделял процессам или "культуре экспериментов"

Можно бесконечно применять CUPED, CUPAC и другие методы, но что делать если:
- Менеджер говорит: "Фича супер важна, нужно выкатить ее еще вчера"?
- Ключевая метрика не красится и предлагается посчитать еще десяток других, которых не было в изначальном дизайне?
- Хотим запустить сразу 20 маркетинговых баннеров в тест?
- Аналитик дизайнит тест аж целый спринт?

Имхо, успешность фичей определяется ответами именно на эти вопросы в вашей "культуре экспериментов". Верхнеуровнево все довольно просто:

1. Появилась идея + ее побрейнштормили внутри команды = конкретное описание фичи
2. Посчитан ожидаемый импакт от фичи в конкретных 1-3 метриках
3. Оцениваем адекватность фичи на пользователях через UX
4. Делаем фичу и проверяем, что она технически работает
5. Смотрим на нескольких боевых пользователях и тестируем edge кейсы
6. Дизайним А/В = приемочные, барьерные и контрольные метрики, сроки и % пользователей
7. Запускаем тест
8. Принимаем решение в соответствии с дизайном

Звучит легко, но в реальности gap между аналитиком, продактом и разработчиком сильно усложняет процесс)
Забыли прокинуть событие в аналитику, не учли важную метрику соседней команды, покатили фичу в пятницу вечером - Узнаете ли свой опыт?)

Серия постов на этой неделе будет посвящена "культуре экспериментов" или "как избежать таких сложностей"

#ab