Модуль 18. Нейронные рекомендатели и ранжирование

Чему вы научитесь в этом модуле

• Объяснять архитектуру two-tower и почему она масштабируется до миллионов товаров.
• Объяснять, чем ранжирование отличается от классификации и почему метрику считают по порядку элементов, а не по их баллу.
• Вычислять precision@k и NDCG вручную и объяснять, что именно они награждают.
• Называть причину, по которой офлайн-метрика и онлайн-эффект расходятся.
• Понимать, почему единственная честная проверка рекомендателя — A/B-тест, а не метрика на логах.

Время: около двух недель. Пререквизиты: модуль 17. Ноутбук: открыть в Colab · notebooks/18-neural-recommenders-and-ranking.ipynb

Зачем нужен этот модуль

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

Two-tower

Основная архитектура промышленных рекомендательных систем — две башни (two-tower). Одна нейронная сеть сжимает признаки пользователя в вектор, другая — признаки товара, и предсказание, как и в модуле 17, — это их скалярное произведение.

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

Последовательные модели идут ещё дальше: предсказывают следующий товар по истории взаимодействий, как языковая модель предсказывает следующий токен. Это ровно трансформер из модуля 10, только применённый к последовательности товаров, а не слов.

Ранжирование, а не классификация

Рекомендатель не отвечает «да/нет» — он упорядочивает. Пользователь видит первые несколько позиций, и поэтому важно не то, какой балл модель присвоила товару, а то, в каком порядке товары расположились. Метрика классификации здесь неуместна: точность не различает ситуации «релевантный товар на первом месте» и «релевантный товар на десятом».

Метрики ранжирования оценивают именно порядок. Precision@k — доля релевантных результатов среди первых \(k\) позиций. NDCG — по сути то же самое, но с учётом позиции: релевантное наверху ценится выше, чем внизу, и вес позиции убывает логарифмически. Идеальный порядок даёт NDCG = 1.0.

Нажимайте «идеальный порядок» и «перемешать». Релевантность каждого результата показана точками; метрики вычисляются в реальном времени. Главное наблюдение: один и тот же набор результатов даёт NDCG = 1.0 в идеальном порядке и заметно меньше в перемешанном — баллы не изменились, изменился только порядок. Рекомендатель оптимизируется именно на это.

Офлайн против онлайн

Теперь то, ради чего написан весь курс, — и в рекомендательных системах это болит особенно.

Модель обучают и проверяют на логах: что показывали пользователям, на что те кликали. Логично взять модель с лучшей офлайн-метрикой и выкатить. Она проигрывает. Причина не в самой метрике, а в том, откуда взялись логи.

Логи — не случайная выборка реальности. Их собрал старый рекомендатель: пользователь кликал только по тому, что ему показали, а показывал старый рекомендатель то, что сам считал хорошим. Товар, который мог бы прекрасно подойти, но старый рекомендатель его не показал, в логах выглядит непопулярным — не потому, что он плох, а потому, что он невидим. Модель, обученная на таких логах, наследует слепые зоны предшественника и уверенно их воспроизводит. Это смещение отбора (selection bias), и офлайн-метрика его не обнаруживает: она считается на тех же самых смещённых логах.

Единственная честная проверка — показать модель реальным пользователям в A/B-тесте и измерить, что реально изменилось. Как это сделать, не обманув себя, — тема модуля 20.

Прокси, петля и причинность — три модуля об одном. Клик — это прокси пользы, и оптимизировать его до конца опасно ровно так же, как в модуле 16. Смещение логов — начало петли обратной связи из модуля 19: система учится на данных, которые сама же и породила. А отделить «модель лучше» от «модели повезло с выборкой» умеет только причинный эксперимент из модуля 20.

Практическая часть

Часть 1. Работа с ноутбуком

Откройте notebooks/18-neural-recommenders-and-ranking.ipynb. Только numpy и matplotlib, вычисления занимают секунды.

Что содержится внутри:

1. Метрики ранжирования с нуля: precision@k, recall@k, NDCG, MRR. Демонстрация того, что они оценивают порядок, а не балл.
2. Two-tower на признаках: башни пользователя и товара, поиск ближайших. Признаки позволяют обслужить нового пользователя там, где чистое матричное разложение бессильно.
3. Офлайн против онлайн: логи, смещённые старым рекомендателем. Модель, лучшая на логах, не поднимает хорошие, но невидимые товары. Разрыв измерен числом, а не рассказан словами.

Часть 2. Собственный лог

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

1. Что в этом логе показывалось, а что нет? Какие товары в принципе не имели шанса получить клик?
2. Если обучить модель на этом логе, какие слепые зоны она унаследует?
3. Как выглядела бы честная проверка на реальных пользователях?
4. Какую метрику вы бы наблюдали — и почему клик может обманывать даже её?

Задание

1. Реализуйте NDCG@k и precision@k. Постройте, как NDCG падает при перемешивании идеального порядка.
2. Соберите two-tower из двух маленьких сетей и покажите поиск ближайших товаров для пользователя.
3. Дайте новому пользователю только признаки (без истории взаимодействий) и покажите, что two-tower выдаёт рекомендации, а матричное разложение из модуля 17 — нет.
4. Смоделируйте смещённый лог: старый рекомендатель показывал преимущественно популярное. Обучите модель на этом логе и измерьте, сколько хороших, но невидимых товаров она пропускает.
5. Сравните офлайн-метрику на логе и «онлайн»-метрику на полной истине. Насколько офлайн оказывается оптимистичнее?

Проверка усвоения

1. Из чего состоит two-tower и почему векторы товаров можно вычислить заранее?
2. Чем ранжирование отличается от классификации?
3. Что награждает NDCG сверх того, что даёт precision@k?
4. Почему модель с лучшей офлайн-метрикой может проиграть в продакшене?
5. Что такое смещение отбора в логах и откуда оно берётся?
6. Почему клик — это прокси, и с каким модулем это рифмуется?
7. Какая проверка рекомендателя является единственно честной и почему?

Что дальше

В модуле 19 смещение логов замыкается в петлю: рекомендатель учится на данных, которые сам же и породил, и начинает оптимизировать вовлечение — прокси внимания. Reward hacking из модуля 16 выходит на миллиарды людей, и у него появляется психологическая цена.

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

---

Принцип

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