Оффлайн-метрики врут: почему рексистема с идеальным 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-инженер» и «Дата-сайентист» 👋🏻
Обучили рекомендательную модель, 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 с фильтрацией по хвосту — коррелирует отлично. Такое знание про свой домен экономит потом кучу циклов разработки.
Кстати, про то, как правильно оценивать модели именно в проде — у нас есть отдельный модуль на курсе. Тема сильно недооценённая, а без неё в реальных задачах никуда.
Сохраняйте, чтобы не потерять! ❤️