Что хотят услышать интервьюеры:

Качество рекомендаций можно оценивать не только через train/test split, но и через временную валидацию, офлайн-метрики на логах, A/B-тесты и косвенные бизнес-метрики. Для рекомендательных систем особенно важен сценарий проверки на будущих данных, а не случайное разбиение. Если данных мало, используют кросс-валидацию по пользователям или по времени, чтобы не допустить утечки.

Определение:

Проверка качества рекомендаций без классического деления на train и test — это набор подходов, где модель оценивают на основе истории взаимодействий, временных срезов, логов показов и поведения пользователей после внедрения. Главная идея — измерять, насколько рекомендации были бы полезны в реальном использовании, не нарушая временной порядок и не смешивая прошлое с будущим.

Пример использования:

Допустим, есть журнал просмотров фильмов за полгода. Модель обучают на первых пяти месяцах, а качество оценивают на последнем месяце: насколько часто среди рекомендованных фильмов оказался тот, который пользователь реально посмотрел. Если нужен способ без явного train/test, можно использовать rolling window: каждый следующий временной отрезок становится проверкой для модели, обученной на предыдущих.

# Пример временной оценки качества рекомендаций
# История действий уже отсортирована по времени

def precision_at_k(recommended, actual, k=10):
    rec_k = recommended[:k]
    return len(set(rec_k) & set(actual)) / k

# train_period: первые N месяцев
# eval_period: следующий месяц
# model.fit(train_period)
# recommendations = model.recommend(user_id, k=10)

# actual_items = фактически просмотренные/купленные пользователем items в eval_period
# score = precision_at_k(recommendations, actual_items, k=10)

Пояснение кода:

Здесь код показывает идею офлайн-оценки по будущему периоду. Сначала формируется список рекомендаций для пользователя, затем он сравнивается с тем, что пользователь реально сделал в следующем временном окне. Метрика precision@k показывает долю релевантных объектов среди топ-k рекомендаций. На практике вместо одной метрики часто считают несколько: Recall@k, NDCG@k, MAP@k, а также coverage и diversity.

Ключевые моменты:

Для рекомендаций случайный train/test split часто плох, потому что может нарушить временной порядок и дать утечку.
Самый практичный офлайн-подход — временная валидация: обучаем на прошлом, проверяем на будущем.
Если нужен более устойчивый результат, используют rolling/expanding window или кросс-валидацию по времени.
Кроме точности попадания в будущие действия, важно смотреть coverage, diversity, novelty и бизнес-метрики.
Финальная проверка качества в продакшене обычно делается через A/B-тест, а не только офлайн-метриками.

Как проверить качество рекомендаций без деления данных на train и test?