Гуси и цены на такси
Wild goose chase paradox

Продолжаем тему коэффициентов к базовой цене. Вы не задумывались, почему в дождь цены на такси просто космические?

Всему виной surge pricing, который предсказывает тот самый коэффициент к базовой цене. Обычно, в surge pricing таргетируют целевой уровень сервиса. Скажем, время подачи машины не более 5 минут в среднем

Что происходит в дождь? ☔️

Время подачи машины ~ желающие уехать / (кол-во машин * среднее время в пути)

А в дождь просходит настоящая катастрофа

1. Число желающих уехать резко растёт

2. Сильно снижается эффективность 1 машины = время в пути растет

Это происходит из-за пробок и снижения плотности свободных такси на км^2

Иногда это приводит к тому, что время ожидания такси критически растет - люди начинают отменять поездки

И вот таксист долго едет к первому клиенту - заказ отменен. Ему назначают второй далёкий заказ (далёкий, тк он условно единственный свободный таксист на все Химки), он опять долго едет - заказ отменен. И так по кругу

В итоге, таксист ездит к клиентам, но не успевает - заказы отменяются. Это похоже на погоню за "дикими гусями" (wild goose chase). Они улетают до того, как их схватят 🦆

Открыла парадокс компания Uber, почитать подробнее можно тут

Единственное решение - очень сильно поднять цену поездки, чтобы спрос на них опять же очень сильно упал. Так что такси не наживается на клиентах в дождь, а скорее пытается поймать гусей сохранить приемлемый сервис

Ответ про фичи для CatBoost

Опрос про трансформацию фичей для CatBoost собрал максимум комментариев за историю канала (сейчас их 35!)
И еще мне немало накидали на вентилятор в реакциях)) Так что тема выглядит актуальной - разбираемся в ней 💪


(x - mean(x))^2
Влияет на перформанс CatBoost

Был отличный пример в комментариях для x = (-4;4), mean(x) = 0, —> (x - mean(x))^2 = (4; 4)
раньше -4 и 4 можно было разделить CatBoost-ом, а после трансформации - нельзя

Зачем тогда так делать?
- Иногда полезно считать “нестандартность” наблюдения. Например, нам может быть важно, отличается ли условно время в пути от среднего
- Еще это супер фича для эмбеддингов - можно считать, насколько эмбеддинг пользователя отличается от среднего эмбеддинга (почти как cos-инусная близость)


round(x, some step)
Влияет на перформанс CatBoost

При округлении вы снижаете число возможных разбиений датасета деревом
- Очень полезная история для робастности прогноза на высоко-дисперсных фичах (средний чек, кол-во кликов и тп)
- Для борьбы с переобучением на выбросах
- Для экономии памяти и ускорения вычислений. Вообще бывает полезно округлять float64 фичи до int8 / int16. С помощью этого и еще пары трюков (я как-нибудь напишу об этом пост) я умдрялся переводить расчеты со Spark на python с ускорением в 10 раз 🚀
Кек, но правда - вам не всегда нужен spark:)


log(x)
Вообще-то говоря, может влиять!

На собеседовании от вас скорее всего ждут ответа “Нет, не влияет. Дерево перебирает все возможные пороги разбиения. И нет разницы, выбрать порог x > A или log(x) > log(A)”

Но в реальности может влиять из-за 2ух факторов:
1/ Дерево перебирает не все пороги разбиения 🙃
За кол-во порогов отвечает параметр max_bin, который по дефолту в катбусте на CPU = 254. И кстати, он прилично аффектит на скорость обучения вашей модели

2/ Пороги разбиения (квантизация фичей) выбираются по дефолту не по квантилям распределения (робастно к монотонным трансформациям вроде логарифма), а иначе. В catboost по дефолту - GreedyLogSum. Поэтому логарифмирование Х при некоторых способах разбиения может влиять на выбор порогов —> влияет на перформанс

Серый АВ - что делать дальше?

Недавно АВ важной для меня фичи покрасился в серый = нет стат значимых улучшений и ухудшений. Эмоционально я прям расстроился. Если у вас тоже такое бывает, то помните о 4 важных вещах:

1. Проверьте ваш MDE и процедуру тестирования
Убедитесь, что нет багов, и вы можете детектить достаточно маленькие эффекты (MDE - minimum detectable effect). Часто разумный эффект на крупной метрике задетектить статистически невозможно - переходите к прокси. Например, от общей конверсии к конверсии определенного шага воронки

2. Около 70% АВ тестов серые, и это нормально
В тестах мы проверяем гипотезы. И какими бы гениальными вы ни были, 2 из 3 ваших невероятных идей ничего не принесут в бизнес-метриках - это неприятно, но факт. Поэтому лучше учиться быстро проверять много гипотез, а не делать ставку на одну крупную

3. Серый АВ дает знание о том, чего делать дальше НЕ нужно
Знать, что точно не работает - прекрасно. Поэтому обычно из пула гипотез (про персональные рекомендации, способы оплаты и тп) тестируют самую сильную. И если она не работает - возможно, вам нужно копать в другую сторону

4. А что еще хорошего приносит ваша фича?
Может быть, технической стабильности - теперь не нужно дежурить по ночам? Или лучше RPS? Или прозрачность для бизнеса? В денежных метриках это не измерить, но такие вещи тоже очень важны


В общем, если ваш АВ вдруг стал серым, вспомните про эти 4 пункта,
выдохните, и продолжайте тестировать новые гипотезы 😉

Bias-variance tradeoff: Спрашивают на каждом собесе, применяют в реальности единицы

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

Ошибка = Bias^2 + Variance + sigma^2

Bias - как точно мы попадаем в среднем в истину

Variance - Как сильно колеблется наша предсказания функция относительно истинной

Sigma^2 - Неснижаемая дисперсия данных

И мы можем за счёт регуляризации снижать Variance за счёт роста Bias, и наоборот. Прекрасная теоретическая выкладка, но что с этим в реальности-то делать? 🤔

Давайте сначала посмотрим на простом примере, какая тут ситуация с Bias и Variance


UPD: Ценителям очень точных определений лучше посмотреть на них по ссылке в посте:) Текстом я писал определения с некоторыми допущениями для более широкой аудитории

Я недавно стрелял из лука, поэтому вопрос (а после будут выводы) по этой мишени

Bias-variance tradeoff p.2

Bias, по моему опыту, важен в двух кейсах: Causal inference и Предсказание условного мат ожидания конкретного распределения

Часто мы предсказываем, например, кол-во продаж. В теории, оно имеет распределение Пуассона. И имея несмещенное предсказание среднего (Bias ~ 0), можно легко получать все квантили распределения по формуле

В простейшем случае Causal inference через линейную регрессию важно иметь Bias ~ 0, чтобы были несмещенные коэффициенты. Кстати, поэтому в случае causal inference не стоит использовать регуляризацию в линейной регрессии (она смещает коэффициенты к 0)

А/В тесты - это линейная регрессия

Кажется, я тоже немало продвигал такую идею. И вот, Филипп (мы вместе учились, но он был на +1 курс) сделал очень годные лекции с доказательствами, что обычный T-test, CUPED, CUPAC и многое другое - частные случаи линейной регрессии 😱

Мой рекомендасьон к прочтению)

По мотивам вот этого поста
TL;DR для контекста:

Вы с командой смотрите на первые цифры эксперимента новой сложной темы (например, впервые работали с ML моделью). Запуск прошёл тяжело, было много нового для вас и команды, прошли немало сложностей.

Один из ваших разработчиков говорит:
"Ну и каких ещё результатов вы ожидали, если так на коленке всё делать?"

Автор предлагает очень разумное решение: объяснить разработчику, что задача и была попробовать затащить новую штуку, чтобы получить больше знаний. Совершенно нормально, что вы сделали это быстро и не получили супер крутого результата. Вы получили знания, которые помогут понять, как дорабатывать решение дальше.

Круто, но мы с вами на канале ml4value интересуемся не софт скиллами в первую очередь!

В чем value неудачного ML-эксперимента?


1. Возможно ваша оффлайн ML-метрика/таргет не коррелирует с бизнесовой метрикой

Нужно найти новую оффлайн метрику/таргет

Из классики: учили модель рекомендаций на предсказание кликов - получили кликбейт в топе. Меняете на клики + добавление в корзину, например


2. Эффект от простого MVP не превышает стат погрешности (ниже MDE)

Тут стоит подумать, превысит ли ее эффект от SOTA. Обычно простейшие решения дают 80% эффекта


3. Вы круто решаете ML-задачу, но не боль конечного пользователя

Из не-млного, но бесящего постоянно 😇: Фильтр по рейтингу на любых картах

Пользователь хочет найти "хороший, проверенный ресторан". Ставит фильтр "рейтинг > 4.5". Получает кучу ресторанов с рейтингом 5.0 и 1 отзывом (вероятно, фродовый от самого владельца). Ну вот зачем так делать?

Если цель сделать фильтр "хорошие места", то хорошо бы фильтровать по рейтинг > Х и кол-во отзывов > Y

Если вы дочитали до сюда и хотите чего-то ML-ного, то для задачи удержания клиентов лучше предсказывать не по вероятности оттока > Х, а добавить ещё условие и остаточный пусть 3-месячный LTV после удержания > Y

Я очень скурпулезно отношусь к тому, что пишу на канале, поэтому реклама тут бывает очень редко

Сам проходил первый запуск HardML, когда мы уже построили свою платформу АВ и рекомендаций в Delivery Club - и все равно модули по АВ и ранжированию были довольно полезными. Поэтому смело рекомендую)

Ну а 5 июня стартует новый поток HardML, скидка для подписчиков 5% по промокоду ML4VALUE27 ⬇️

Имеете опыт в машинном обучении, но хотите двигаться ещё дальше?

Валерий Бабушкин, Vice President, Data Science в Blockchainꓸcom, вместе с командой опытных специалистов из Яндекса, AliExpress и X5 Retail Group подготовил продвинутый курс, на котором вам предстоит решать сложные и нестандартные задачи бизнеса.

Ранжирование и матчинг, динамическое ценообразование, uplift-моделирование, ускорение и повышение чувствительности A/B-тестов — выбирайте нужные блоки или проходите курс целиком.

Если вы уже сталкивались с чем-то из этого в своей работе, то познакомитесь с best practices индустрии. А если нет — дополните своё резюме новыми кейсами и станете более разносторонним ML-специалистом.

Новый поток стартует уже 5 июня, а по промокоду MLVALUE27 вы получите скидку 5%. Ждем вас!

[Зарегистрироваться]

Что спросить у кандидата про бустинг?

Пока в мире хайпуют нейронки вроде ChatGPT, в табличных данных все еще царят бустинги. Спрашивать у кандидатов классические вопросы уже не комильфо: их все выучили

- "Почему бустинг градиентный? При чем тут вообще градиент"
- "Прогнозируем продажи (они >=0). Случайный лес прогнозирует тоже >=0, а бустинг иногда и отрицательные числа, почему так?"

Поэтому я придумал новый годный вопрос для middle+ 😈

"Мы прогнозируем бустингом сразу много временных рядов: продажи каждого из 10_000 товаров. В приличной доли из них бустинг делает очень странный прогноз - он стабильно выше/ниже среднего значения продаж конкретного товара в 2-3 раза. Почему так может быть?"

Я отвечу на него через несколько дней, ну а вы можете написать свои варианты в комментарии ⬇️

"Мы прогнозируем бустингом сразу много временных рядов: продажи каждого из 10_000 товаров. В приличной доли из них бустинг делает очень странный прогноз - он стабильно выше/ниже среднего значения продаж конкретного товара в 2-3 раза. Почему так может быть?"


В комментариях верно подметили глобально одну большую проблема - Underfitting модели. Она может выражаться в:

1. Бустинг с rmse лоссом неустойчив к “выбросам”
Он может учитывать выбросы вверх (праздники, промо) и вниз (кончился товар, продажи = 0) и за счёт этого может "выглядеть на графике", что в среднем прогноз выше/ниже большинства продаж. Хотя с учётом выбросов он равен среднему. Лечится учетом фичей праздников - без них underfit

2. Бустинг плохо ловит тренды
Бустинги плохо учат тренды в данных, поэтому на трейне все модели быть ОК, а вот растущий тренд в тесте бустинг не поймает. Тоже некоторого рода underfit или ограничение деревьев, смотря как на это посмотреть 🙃

3. Не учет timeseries_id (то бишь id товаров)
Да, некоторые товары могут продаваться в тысячах штук, а другие в единицах. Поэтому бустинг может в среднем прогнозировать правильно (сотни), но по конкретным товарам сильно ошибаться:) Это скорее under-fitting


От себя добавлю:
4. Лосс имеет значение
Часто мы не хотим, чтобы выбросы влияли на обучение и берём MAE как лосс. Но помните, что MAE даёт прогноз = медиане, а медиана может очень сильно отличаться от среднего

5. Веса товаров в лоссе имеют значение
Если у вас редко-продающиеся товары имеют меньший вес в лоссе, чем часто-продающиеся в сотни раз, то очевидно редкопродающиеся товары вы будете плохо прогнозировать). Например, в RMSE loss в 10 раз меньше продающийся товар имеет по факту в 100 (!) раз меньший вес

Можно лечить аккуратным установлением весов, скажем, через multi-RMSE loss


Если резюмировать
- Не забывайте важные фичи во временных рядах (праздники, промо, сезоннности, тренды, среднее значение каждого ряда)
- Думайте ооочень внимательно над лоссом 📈

Иначе можно получить очень неприятные артефакты:)

На выходных записали видео с Александром Миленькиным (автор Data Feeling) про наш путь в DS, текущие задачи, найм, удаленку и не только

Пока все монтируется - вот вам небольшое превью кусочка истории о "Очень синьерном миддле". Или почему так сложно бывает расти из миддла в синьера 🚀

Корреляция и время

Фраза “Корреляция не означает причинно-следственную связь” стала уже максимально избитой. Но уже в который раз вижу, что эту фразу в контексте временных рядов понимают неверно. А с учеом того, что 90% табличных данных - по факту временные ряды (цены, продажи, фин показатели и тп) - неверно понимается почти всегда 😱

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

Их все обьединяет то, что у двух показателей есть тренд во времени. И мы видим корреляцию на самом деле двух трендов, а не самих показателей

Проблема в том, что во временных рядах корреляцию и причинно-следственную связь ищут совсем не так:

*Упрощенно* алгоритм такой:
- Удалить трендовую и сезонную составляющую: e = y - trend - seasonal
- Если временной ряд не один, а много (1 показатель за 10 лет у разных стран, например), то нужно еще вычесть среднее значение каждой страны: e = y - trend - seasonal - group_mean
- После этого считать корреляцию остатков (e) у 2-ух переменных

Тогда никакой ложной корреляции, как в примерах выше, вы не увидите 👌

Ну и в целом, когда ничинаете работать с временными рядами, то очень много из классической статистики работает совсем не так: корреляция, стат значимоть коэффициентов регрессии, what-if анализ на изменение 1 фичи и тп. Тк что будьте крайне аккуратны: ведь временные ряды есть везде 😈


P.S. Хороший пример ложной корреляции - это когда есть 2 переменные, измеренные в 1 момент времени

Например, если вы за 1 день измерите размер стопы и длину волос у 10_000 людей, то найдете отрицательную значимую, но ложную корреляцию между этими показателями

Attention, tabular data!
TabR is coming

Что ж, вот наконец модели на базе attention стали показывать годные результаты на табличных данных!) Если хотите детальнее посмотреть, как, то есть прекрасный обзор новой архитектуры TabR
от Андрея Лукьяненко

Метод выглядит многообещающим, но я бы пока к нему пригляделся в реальных приложениях. Как я понял из статьи (поправьте, если не так), для бустингов и TabR не делали почти никакого feature engineering. Но это очень сильно бустит перформанс бустингов в реальных задачах

Так что будет очень интересно сравнить эти 2 модели, когда в обеих будут мощные фичи 🔥

Confidence - АВ платформа Spotify скоро будет продаваться всем желающим

Довольно занятная история произошла на прошлой неделе: Команда spotify анонсировала запуск своей внутренней АВ-платформы Confidence для всех. Видимо, пробуют занять нишу ушедшего Google Optimize

Судя по тех статьям от самих инженеров spotify, под капотом есть вся классика АВ:
- Разведение экспериментов по слоям с двойным солированием
- Календарь экспериментов для разведения тестов по времени
- Проверка сплитования АА-тестами и определение MDE
- Калькулятор размера выборки

Из несколько необычных killer-фич:
- Sequential testing. Можно закончить эксп по достижению стат значимости. Но сами же инженеры Spotify не рекомендуют его использовать 🙃Ведь есть эффект “дня недели” - если в тесте понедельников больше чем суббот, то можно получить смещение
- Явно на уровне UI разделяют целевые и вспомогательные метрики - ну наконец-то! Больше нельзя будет продакту поставить 20 целевых метрик в эксперименте и катить, если прокрасилась хоть одна:)

Остальные детали откопать пока не удалось. Так что ждем официальной раскатки с документацией - будем ее препарировать 😈