Ошибки рекомендательной системы, которые не видны по одной метрике
Модель может пройти offline-проверку и затем постепенно терять пользу из-за дрейфа признаков и смещённых обучающих данных. Сергей Кузнецов разбирает учебный ноутбук, построенный на ошибках из практики.
Видео · на русском
Разбор ошибок при проектировании рекомендательной системы / Сергей КузнецовСергей Кузнецов · Опубликовано: 8 октября 2025 г.
Исходный доклад · Открыть оригинал
Сначала различаем пример и внедрение
В мастер-классе используются искусственные данные и намеренно ошибочный ноутбук. Прежняя выдача сортировала объекты по средней оценке, а новая система соединяет рекомендательные модели с бустингом.
Проверяют не подбор гиперпараметров, а логику применения: что увидит ранжировщик после обновления вспомогательных моделей и как предыдущие показы сформировали данные.
00:00 — фрагмент докладаШкала оценки модели может измениться
Вспомогательная модель поставляет численный признак бустингу. После её переобучения распределение оценок может сдвинуться, хотя смысл предпочтений не изменился. Старые пороги бустинга начинают работать иначе.
Спикер показывает нормализацию таких оценок и рекомендует контролировать их стабильность. Ошибка опасна постепенностью: сервис не падает, но бизнес-показатели могут ухудшаться.
19:00 — фрагмент докладаОтрицательные примеры меняют вывод модели
Если обучаться только на зарегистрированных взаимодействиях, прежнее ранжирование влияет на то, какие объекты попадут в выборку. В примере это приводит к перевёрнутой зависимости между исходной оценкой и полезностью.
Проверка вкладов признаков через SHAP помогает заметить нелогичное поведение. Авторы меняют формирование отрицательных примеров, учитывая более широкий набор объектов. Возможность проверить истинную релевантность здесь обеспечена учебными данными.
Код учебного эксперимента.
Источник: Кадр из докладаХороший прогноз не всегда полезен для рекомендаций
В заключении приведён практический случай: перед покупкой в истории всегда был клик по этому товару. Модель научилась использовать очевидный предшествующий шаг и прекрасно проходила offline-проверку, но не помогала открывать нужные товары онлайн.
Поэтому проверять нужно не только доступность признака во времени, но и то, какую задачу модель фактически решила. Качественная временная разбивка сама по себе не устраняет влияние прежней системы показов.
Утечка данных возможна и при обучении на логах.
Источник: Кадр из доклада