Оффлайн-метрики врут: почему рексистема с идеальным NDCG проваливается в A/B-тесте?

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Обучили рекомендательную модель, NDCG@10 вырос с 0.31 до 0.38, все радуются. Катят в A/B — а бизнес-метрики не двигаются... Знакомо?

Это, пожалуй, самая частая история в рексистемах — и одна из самых болезненных. Разберём, почему офлайн-метрики != успех, и что с этим делать.

🤨 Оффлайн-тест не знает, что пользователь ещё не видел

Это самый главный подвох: тестовые данные — не «правда о вкусах пользователей», а история их взаимодействий с сервисом. Часть этой истории — то, что показывала прошлая рекомендательная модель + намерения пользователей, ищущих через поиск + переходы по прямым ссылкам, из рекламы, по советам друзей… В любом случае этот срез — то, с чем человек уже как-то столкнулся.

А теперь представьте: новая модель находит объект, про который пользователь раньше никогда не знал и сам бы просто на него не наткнулся. Возможно, увидев его, он скажет «вау, хочу» — но узнаем мы это только через A/B-тест. А пока в отложенной выборке для оценки этого клика нет — по NDCG это будет «ошибкой», и метрика оштрафует модель за то, что она на самом деле стала лучше.

🤨 Popularity bias: оффлайн любит популярное, онлайн — нет

Ещё одна ловушка: популярные объекты в исторических данных представлены в разы чаще — модель, которая хорошо ранжирует именно популярное, будет показывать отличный NDCG (даже если внутри ML-алгоритм, а не просто топ-продаж). Проблема в том, что для пользователя разницы почти нет: он и так знает про эти объекты, «вау-эффекта» от рекомендаций нет и вовлечённость не растёт. А редкие, но потенциально интересные именно ему вещи модель обходит стороной — просто потому, что в логах по ним слишком мало сигнала.

Что помогает диагностировать эту проблему:

➖ Смотреть на coverage — какую долю каталога модель вообще рекомендует;
➖ Считать метрики отдельно по началу, середине и хвосту распределения объектов;
➖ Если на «хвосте» метрики близки к нулю, модель просто выучила популярное.

🤨 Feedback loop: модель обучается на себе же

Как только модель уехала в прод, она начинает влиять на данные, на которых будет обучаться следующая версия. Показали что-то в топе → получили клики → переобучили модели → снова показали то же самое. Через пару итераций система схлопывается в узкий набор рекомендаций, а оффлайн-метрики этого вообще не видят: с точки зрения NDCG всё прекрасно, модель отлично предсказывает клики, которые сама же и породила.

🤨 NDCG и Recall@k считают число угадываний, а бизнесу нужны деньги

Даже если оффлайн-оценка честная, есть вторая проблема: NDCG, Recall@k и им подобные — это метрики про число попаданий. Неважно, что вы кладёте в позитив: клики, заказы, добавления в избранное, купленные товары — метрика считает, сколько из них попало в топ-k. А бизнесу нужна выручка!

Модель может отлично предсказывать заказы — но много заказывают, как правило, дешёвые позиции — а магазин может зарабатывать на дорогих. Средний чек по рекомендациям тоже смотреть отдельно бесполезно: он легко растёт, если модель начала показывать дорогое всем подряд — но тогда заказов при этом становится меньше, и в сумме мы снова потеряем.

Что с этим делать:

➖ Считать оффлайн не только NDCG/Recall, но и взвешенные версии (по цене, марже, длительности просмотра — по тому, что реально важно);
➖ Обязательно смотреть на новизну и разнообразие рекомендаций, а не только на релевантность;
➖ И всегда помнить: оффлайн-метрика — это гипотеза, а не окончательный приговор.

🙂 Так что же делать?

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

Из продвинутых идей — если у вас уже накопилась история A/B-тестов, полезно провести отдельное исследование: взять прошедшие эксперименты, посмотреть, как для этих моделей выглядели оффлайн-метрики, и сопоставить с тем, что показал онлайн. Дальше посчитать корреляцию между оффлайн- и онлайн-метриками. Иногда выясняется, что ваш любимый NDCG@10 вообще не коррелирует с выручкой, а какой-нибудь Recall@50 с фильтрацией по хвосту — коррелирует отлично. Такое знание про свой домен экономит потом кучу циклов разработки.

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

Сохраняйте, чтобы не потерять! ❤️

Всем привет! Я Валерия Елпатьевская, инженер данных в Альфа Банке и ментор Симулейтив 👋🏻

Пришла рассказать, что мы стартуем второй поток бесплатного ML-интенсива 12-18 августа — буду помогать вам сделать первые шаги в data science и не дам застрять на задачах.

Что ещё будет на интенсиве:

➖ Практика на Kaggle — решаете реальные задачи и сразу кладёте их в портфолио;
➖ Закрытый финальный эфир — разберём, как оформить готовый проект в GitHub так, чтобы его не стыдно было показать работодателю;
➖ Сертификат и призы самым активным участникам!

Продвинутый Python и математика не нужны — стартуем с азов, а разбираться в непонятных местах будет с кем. Буду ждать вас на интенсиве!

➡️ Зарегистрироваться на интенсив

Батч или real-time: выбор, который делают до того, как обучили модель

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Обучить модель — это в лучшем случае половина работы ML-инженера. Дальше возникает вопрос, от которого многие новички просто отмахиваются: а как эта модель будет работать в проде?

Про сам факт деплоя обычно все помнят: «завернём в докер и поднимем сервис». А вот про то, что архитектура инференса модели — это отдельное инженерное решение с кучей нюансов, задумываются далеко не сразу. Разберём два типа инференса: real-time vs батч.

Батч-предсказания: посчитали заранее и положили в хранилище

Идея простая: раз в сутки (или в час, или в неделю) прогоняем модель на всей базе пользователей/объектов, складываем предсказания в таблицу или кэш — и когда они понадобятся, просто достаём готовое.

Где это отлично работает:

➖ Скоринг оттока клиентов раз в неделю;
➖ Ежедневные рассылки и запланированные рекламные кампании;
➖ Сегментация клиентов раз в месяц.

Обратите внимание, что в каждом из перечисленных кейсов задано некоторое регулярное расписание обновления — ничего не происходит в режиме онлайн.

✅ Плюсы такого подхода очевидны: дёшево, просто эксплуатировать, легко переобучать, никаких проблем со скоростью ответа сервиса — предсказание уже готово и ждёт где-нибудь в базе данных. 

❌ Минус тоже очевиден: это свежесть предсказаний. Если пользователь зарегистрировался час назад, а батч прогонится только ночью, до утра его для системы «не существует». Также невозможно учитывать контекст «в прямом эфире»: что человек только что положил в корзину, что накликал, с какого устройства сейчас зашёл.

Real-time инференс: модель отвечает на запрос здесь и сейчас

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

И вот тут начинаются те самые «нюансы, о которых не рассказывают в курсах по ML»:

➖ Скорость ответа бьётся на бюджеты. У вас есть, скажем, 200 мс на весь ответ пользователю. Из них съест сеть 30 мс, бизнес-логика — 50 мс, достать фичи из feature store — 40 мс. И на саму модель остаётся 80 мс, а это уже жёсткое ограничение на архитектуру: тяжёлый бустинг на 5000 деревьях сюда просто не влезет.

➖ Фичи должны быть доступны онлайн. Если в трейне вы использовали «средний чек пользователя за последние 30 дней», в проде эту фичу надо где-то оперативно считать и хранить. Отсюда снова вырастает целый слой инфраструктуры.

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

➖ Отказоустойчивость. Модель может упасть, быть перегруженной, отвечать слишком долго. Что показывать пользователю в этом случае? Fallback на популярное или более простую эвристику? А может, закэшированное предсказание? Это тоже часть архитектуры, а не «додумаем потом».

Гибрид: чаще всего в проде именно он

В реальности чистый real-time и чистый батч встречаются реже, чем гибриды. Классика жанра — двухстадийные системы: тяжёлая модель раз в сутки считает эмбеддинги и отбирает кандидатов (батч), а лёгкий ранкер переставляет их онлайн с учётом свежего контекста (real-time). Или есть near-real-time: например, когда фичи обновляются через потоковые системы с задержкой в секунды (допустим, по триггеру), а предсказание считается по запросу.

Такой подход даёт лучшее из двух миров: тяжёлую логику выносим в офлайн, а онлайн оставляем ровно столько, сколько нужно для свежести.

Как выбирать?

Стоит задать себе несколько вопросов ещё до обучения модели:

❓ Насколько быстро предсказание должно реагировать на новые события? Если разница между «сейчас» и «через сутки» для бизнеса не важна, берите батч и не усложняйте.
❓ Сколько объектов надо скорить? Если базу в 100 млн пользователей раз в день, выбирайте батч; а если это редкие входящие запросы — можно и real-time.
❓ Какая пиковая нагрузка на сервис (RPS — количество запросов в секунду)? Порядка 10 запросов в секунду и порядка 10 000 — это разные архитектуры и разные затраты.

Понимание всего этого — то, что отличает ML-инженера от «человека, который умеет обучать модели». У нас на курсе есть отдельный модуль как раз про фишки production — тема сильно недооценённая, а без неё модель так и остаётся ноутбуком.

Сохраняйте, чтобы не потерять! ❤️

🔥 Ваш шанс получить крепкую базу в data science

Привет! На связи Мария Жарова, ментор курса «Дата-сайентист» 👋🏻

Спешу сообщить, что 26 августа стартует новый поток курса «Дата-сайентист» с моей менторской поддержкой ❤️

На курсе объединили опыт практикующих экспертов, чтобы за 8 месяцев вы:

➖ Освоили полный стек инструментов аналитики и инженерии данных: от SQL и Python до Docker, Airflow и ETL-пайплайнов;
➖ Погрузились в мир data science: от регрессии, кластеризации и рекомендательных систем до архитектур нейронных сетей, обработки текста (NLP) и компьютерного зрения;
➖ Решили реальные бизнес-кейсы: только практика от действующих аналитиков, которая ляжет в ваше портфолио.

На курсе я покажу не только как обучить модель, но и как довести её до продакшена на реальных кейсах.

Места на поток ограничены! Узнайте подробности о курсе по кнопке ниже:

✅ Узнать подробности и записаться

Модель уже начала деградировать. Просто вы об этом ещё не знаете

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Модель в проде — это не «настроил и забыл». Это живой сервис, который потихоньку деградирует с первого же дня после релиза. Вопрос только в том, заметите вы это сами или расскажут коллеги из бизнеса, когда посыпется выручка.

Разберём, как выстроить мониторинг модели так, чтобы про её “устаревание” узнавать заранее, а не постфактум — что смотреть, с какой периодичностью и на что ставить триггеры.

В целом, мониторинг модели можно разбить на три разных слоя, где каждый отлавливает свой тип проблем.

📌 Слой 1: входные данные. Проблемы на этом этапе часто называют data drift: 

➖ Меняется ли распределение фичей относительно того, на чём модель училась?
➖ Появились ли новые категории, которых раньше не было? 
➖ Не стало ли внезапно 30% пропусков там, где раньше было 2%?

Инструменты для проверки здесь стандартные статистические: PSI (Population Stability Index), KS-тест, сравнение распределений по бакетам. По каждой ключевой фиче — свой контроль (не по всему набору, а именно по ключевым, иначе алерты превратятся в шум).

📌 Слой 2: предсказания модели — это уже называется prediction drift. Даже если входные данные стабильны, может поехать распределение предсказаний — вот несколько типичных примеров: 

➖ Модель начала чаще предсказывать положительный класс;
➖ Средний скор пополз вверх.

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

📌 Слой 3: качество модели или concept drift — это самое важное и самое сложное, тут мы смотрим на реальные метрики: precision, recall, ROC-AUC, бизнес-KPI. Основная загвоздка здесь в том, что настоящий таргет обычно приходит с задержкой — факт оттока станет известен через месяц, факт возврата кредита через год… И до этого момента честно посчитать качество нельзя.

Но всё же есть способ поймать проблему, даже пока таргет ещё не пришёл!

➖ Использовать прокси-метрики: часто есть промежуточный сигнал, который приходит быстрее (клик до покупки, первая просрочка до дефолта, отписка до оттока). Конечно, это не идеально, но обычно даёт хоть какой-то ранний неплохой сигнал.
➖ Сравнить с бенчмарком: держите рядом простую эвристику или прошлую версию модели и мониторьте разрыв. Если разрыв схлопывается — модель теряет своё преимущество.
➖ Смотрите на сегментные метрики: часто модель деградирует не целиком, а на конкретных срезах (новые пользователи, определённый регион, новая версия приложения). Общий скор может быть в норме, а вот в разрезе по сегментам — катастрофа.

💡 Совет: ставьте триггеры на переобучение

Классический подход: «переобучаем модель раз в месяц, потому что так решили на глаз». Иногда это оверкилл — если модель стабильна и трогать её нет смысла, а иногда наоборот — за месяц уже всё развалилось.

Поэтому более зрелый подход — комбинировать регулярное переобучение по расписанию как базовый цикл с добавлением триггерного переобучения по алертам (PSI по ключевой фиче ушёл за порог, качество на прокси-метрике просело на N%, доля новых значений категорий превысила X%).

💡 И ещё совет — джентльменский набор метрик для мониторинга модели в проде:

➖ Распределение ключевых фичей и алерт на их сдвиг;
➖ Распределение предсказаний модели во времени;
➖ Доступные онлайн-метрики (те самые прокси);
➖ Реальные метрики с лагом, как только таргет приезжает;
➖ Разбивка по ключевым сегментам, а не только общая цифра;
➖ Отдельно health--чек самого сервиса: скорость ответа, количество ошибок.

И помните, что мониторинг — это не «сделаем, когда будет время», а часть релиза наравне с самим сервисом алгоритмом. Модель без мониторинга — это чёрный ящик, который однажды перестанет работать, и вы узнаете об этом последним.

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

Сохраняйте, чтобы не потерять! ❤️

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

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Разберём три вещи, которые удивляют почти всех, кто переходит в ML. Речь не про «недостаточное знание алгоритмов» — поговорим про разрыв ожиданий и реальности самой роли.

1️⃣ Работа с данными — это больше половины времени, а не «быстрый подготовительный этап»

В голове новичка проект устроен так: сначала быстренько готовим данные за пару часов, а дальше начинается «настоящая работа» — модели, гиперпараметры, метрики. В реальности пропорции обратные: львиную часть времени занимают подготовка, чистка, стыковка источников, разбирательства «а почему у нас в одной таблице user_id — int, а в другой — string», проверка на утечки, построение фичей…

И это не из-за того, что в больших компаниях данных много и они всегда грязные. А потому что понимание данных — это и есть залог успешного моделирования. Важно понимать, что высокого качества ML-алгоритма можно достичь далеко не только благодаря SOTA-моделям, а часто благодаря качественно подготовленным данным для обучения.

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

2️⃣ Модель — это маленький кусочек системы, а не её центр

Ещё одно открытие, которое приходит только с опытом: сама модель — обычно самая простая часть проекта. Поставить на обучение в сотый раз CatBoost — дело нескольких минут. А вот вокруг модели живёт целая инфраструктура, которую и надо уметь строить для каждого случая индивидуально:

➖ Откуда берутся фичи в проде и совпадают ли они с тем, на чем модель обучалась;
➖ Что происходит, если модель упала или отвечает слишком долго;
➖ Как её версионировать, откатывать, катить постепенно;
➖ Как понять, что она устарела и её пора переобучать.

Джун обычно приходит с мыслью «я умею обучать модели» — но это лишь входной билет, а настоящая работа начинается там, где модель едет в прод. Именно поэтому в вакансиях ML-инженера всё чаще появляются требования, схожие со списом инструментария бэкенд-разработчика — Python на приличном уровне, Docker, Kubernetes, CI/CD, базы данных, очереди, стриминг. Без этого модель так и остаётся Jupyter–ноутбуком.

3️⃣ Коммуникация с бизнесом — часть роли, а не «пусть менеджеры этим занимаются»

Самая недооценённая часть работы, особенно у технически сильных ребят. Мысль «я делаю модель, а с бизнесом пусть говорит продакт» — очень частая, и очень мешающая.

Проблема в том, что ML-задачи почти никогда не приходят в готовом виде. «Хотим предсказывать отток» — это не задача, это направление для размышлений. Что считать оттоком? На каком горизонте? Что с этим предсказанием потом делать — рассылать промо, звонить, менять тариф? Какая цена ошибки в одну и другую сторону? Ответы на эти вопросы определяют всё — от разметки до выбора метрики — и получить их можно только в разговоре с бизнесом.

Опытные ML-инженеры эту часть тащат самостоятельно: они умеют прийти с правильными вопросами, объяснить ограничения модели без матана, показать “вот здесь можно сделать точнее, но это займёт месяц — стоит ли оно того?”. Джун же часто молча берёт задачу как есть, несколько недель что-то делает, приносит результат — и выясняется, что решал совсем не ту проблему.

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

Что делать с этой информацией?

Плохая новость: по туториалам и соревнованиям всего это не выучить 🙂 Там просто нет таких данных, такой инфраструктуры и такого контекста.

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

Именно поэтому у нас на курсе эти три темы вплетены в каждый модуль, а не вынесены в «дополнительные материалы для интересующихся». Без них ML-инженер быстро упирается в потолок «человека, который умеет обучать модели», а роль требует сильно большего.

Сохраняйте, чтобы не потерять! ❤️

🔥 Новый поток интенсива по ML

9-16 сентября пройдёт следующий поток ML-интенсива с менторской поддержкой!

Ментор Валерия Елпатьевская, инженер данных в Альфа Банке, будет помогать вам сделать первые шаги в data science и не даст застрять на задачах.

Что ещё будет на интенсиве:

➖ Практика и соревнование на Kaggle — решаете реальные задачи и сразу кладёте их в портфолио, а также соревнуетесь с другими участниками;
➖ Закрытый эфир для участников интенсива — поговорим о профессиях в data science и возможностях для развития начинающего специалиста;
➖ Сертификат и призы самым активным участникам!

Продвинутый Python и математика не нужны — стартуем с азов, а разбираться в непонятных местах будет с кем. Буду ждать вас на интенсиве!

➡️ Зарегистрироваться на интенсив

Всем привет! Небольшой опрос нашей аудитории — пожалуйста, ответьте на несколько вопросов ниже, а мы в ответ сделаем наш контент лучше и интереснее ⬇️