Оффлайн-тестирование рекомендаций — это способ оценить модель или логику рекомендаций на исторических данных, без запуска в продакшене.
Пример сценария
Допустим, вы в Spotify. У вас есть гипотеза:
Если мы усилим вес новых треков в миксе Discover Weekly, пользователи будут открывать больше новых артистов.
Вариант A: запустить A/B и рисковать UX 😬 — дорого, долго, и может всё испортить.
Вариант B: оффлайн-симуляция 🤓 — тестируем на исторических пользовательских действиях.
Как это делается? Пошагово:
1. Подготовка данных
Вам нужны логи пользовательского поведения:
- Что человек слушал (user → track → timestamp)
- Что ему рекомендовали в тот момент
- Что он выбрал сам
Это и есть ваша «земля» — на ней будет играть симуляция.
2. Создание симулятора
Вы моделируете альтернативную логику рекомендаций:
- Например, новая модель, которая чаще включает новые треки.
Прогоняете её на прошлом поведении:
→ Что бы модель рекомендовала пользователю X 10 апреля?
→ А он на самом деле выбрал что?
→ А он на самом деле выбрал что?
3. Метрики сравнения
Сравниваете, насколько альтернативная модель могла бы:
- лучше угадать, что человек послушал (точность, hit rate, MRR);
- предложить более разнообразный контент (diversity, novelty);
- увеличить вовлечённость (например, послушал бы больше минут, больше артистов).
4. Пример интерпретации
Новая модель с 15% новинок даёт +8% diversity и +4% coverage, но –3% по точности.
→ Значит, возможно, вылетает релевантность — стоит балансировать.
→ Или идти в прод уже на A/B, но с фильтрами/таргетом.
→ Или идти в прод уже на A/B, но с фильтрами/таргетом.
Инструменты и библиотеки
Дополнение — симуляции
Можно создавать агентов, которые имитируют поведение пользователей:
- На основе прошлого поведения
- С вероятностями переходов (например, кликнет или нет)
- Можно обучать этих агентов (reinforcement learning)
Почему это круто?
- Не рискуете пользовательским опытом
- Можно быстро перебрать десятки моделей
- Помогает узко отобрать кандидатов, которых потом пустить в A/B