Ретрив и ранжирование в рекомендациях

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 11, остальные разбираются в тренажёре.

1. #ranking_retrieval1 / 5
   Learning-to-rank: чем pairwise/listwise подход лучше поточечной регрессии релевантности для ранжирования?

   A)Поточечная регрессия технически неспособна выдать хоть какой-то порядок элементов в выдаче рекомендаций

   B)Pairwise и listwise работают без разметки релевантности, а поточечный подход её требует

   C)Они оптимизируют относительный порядок элементов, а не абсолютную оценку — это ближе к тому, что мерят ранжирующие метрики

   D)Разницы по сути нет: все три подхода оптимизируют ровно одну и ту же функцию потерь и дают идентичный порядок выдачи

   показать ответ и разбор

   +C)Они оптимизируют относительный порядок элементов, а не абсолютную оценку — это ближе к тому, что мерят ранжирующие метрики

   // разбор: Поточечный подход учит предсказывать абсолютную релевантность каждого элемента отдельно, но пользователю важен порядок в выдаче, а не точность оценки. Pairwise (правильный порядок пар) и listwise (качество всего списка) прямо оптимизируют относительное ранжирование, лучше согласуясь с метриками вроде NDCG. Поэтому в ранкерах они обычно бьют наивную регрессию скора.

2. #ranking_retrieval2 / 5
   Ранкер обучают на кликах из своей же выдачи. Какую петлю обратной связи это создаёт и чем грозит?

   A)Никакой петли не возникает: клики являются объективным и несмещённым сигналом истинной релевантности товара

   B)Позиционный/популярностный биас: верх кликают чаще, петля усиливает; нужны дебиас и exploration

   C)Основной риск здесь — переполнение хранилища логами кликов, которое лечится регулярной очисткой старых данных

   D)Петля лишь ускоряет сходимость обучения ранкера и полезна во всех отношениях без каких-либо негативных побочных эффектов

   показать ответ и разбор

   +B)Позиционный/популярностный биас: верх кликают чаще, петля усиливает; нужны дебиас и exploration

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

3. #ranking_retrieval3 / 5
   Зачем на этапе retrieval берут приближённый поиск соседей (ANN), а не точный перебор?

   A)Точный перебор по миллионам товаров на каждый запрос слишком медленный; ANN находит почти те же топ-кандидаты в разы быстрее

   B)ANN возвращает точный результат, просто его проще реализовать в коде, чем полный перебор, и работает он с той же скоростью, что и наивный полный перебор

   C)Приближённый поиск нужен затем, чтобы добавить случайности и разнообразия в выдачу

   D)Точный перебор запрещён из-за приватности, а ANN якобы обезличивает эмбеддинги пользователей автоматически

   показать ответ и разбор

   +A)Точный перебор по миллионам товаров на каждый запрос слишком медленный; ANN находит почти те же топ-кандидаты в разы быстрее

   // разбор: На этапе retrieval нужно из миллионов товаров быстро достать сотни ближайших к вектору запроса. Точный перебор всех расстояний на каждый запрос не укладывается в бюджет задержки. ANN-индексы (HNSW, IVF, PQ) находят почти-ближайших соседей за доли миллисекунды, жертвуя крошечной долей точности ради огромного ускорения — приемлемый размен, ведь ошибки добирает последующий ranking. Случайность и приватность тут ни при чём.

4. #ranking_retrieval4 / 5
   Что такое in-batch negatives при обучении two-tower ретривера и зачем они?

   A)Специальные заранее размеченные людьми отрицательные примеры, добавляемые вручную в каждый батч обучения, которые команда разметки заранее готовит вручную под каждую обучаемую модель

   B)Полный перебор всех непросмотренных товаров как негативов для каждого пользователя на каждом шаге

   C)Приём, применимый лишь на инференсе: негативы подмешиваются в выдачу для разнообразия рекомендаций

   D)Товары ДРУГИХ примеров того же батча берут как негативы для данного юзера — дёшево и много негативов сразу

   показать ответ и разбор

   +D)Товары ДРУГИХ примеров того же батча берут как негативы для данного юзера — дёшево и много негативов сразу

   // разбор: Two-tower учат сближать вектор юзера с его позитивным товаром и отдалять от негативов. Явно набирать негативы дорого, поэтому берут in-batch: для пары (юзер, его товар) негативами служат товары остальных пар того же батча — они почти наверняка нерелевантны и уже посчитаны, что даёт много дешёвых негативов и эффективный softmax по батчу. Это трюк обучения, не разметка и не инференс; иногда правят на popularity bias.

5. #ranking_retrieval5 / 5
   Почему тяжёлый ranker может использовать признаки, недоступные лёгкому two-tower ретриверу?

   A)Не может: ranker и retriever используют один и тот же набор входных признаков, иначе их скоры окажутся несопоставимыми и весь каскад развалится

   B)Ranker работает без признаков, полагаясь на порядковый номер кандидата из retrieval

   C)Ranker считает совместные (cross) признаки пары юзер-товар и контекст — он оценивает лишь сотни кандидатов, а не весь каталог

   D)Two-tower, наоборот, богаче признаками, а ranker намеренно упрощают ради максимальной скорости выдачи

   показать ответ и разбор

   +C)Ranker считает совместные (cross) признаки пары юзер-товар и контекст — он оценивает лишь сотни кандидатов, а не весь каталог

   // разбор: Two-tower обязан кодировать юзера и товар РАЗДЕЛЬНО (иначе не предрассчитать эмбеддинги и не искать через ANN), поэтому он не видит совместных признаков пары. Ranker оценивает лишь сотни отобранных кандидатов, а не весь каталог, и может позволить себе дорогие cross-признаки (совпадение категорий юзер×товар, свежесть, контекст запроса, взаимодействия) — отсюда его точность. Это следствие каскада, а не произвол.