Как свести задачу ранжирования к задаче классификации

Что проверяют

Знаете ли вы подходы learning to rank и понимаете ли, что теряется при сведении ранжирования к классификации. Следом обычно спрашивают, какой метрикой мерить результат и как правильно делить данные на обучение и валидацию.

Как отвечать

Сведение возможно двумя способами, и оба стоит назвать:

• pointwise: каждая пара «запрос, документ» получает метку «релевантен / нет» или оценку от 0 до 4 для многоклассовой либо порядковой постановки. Обучается обычный классификатор, ранжирование строится по предсказанной вероятности. Просто, но модель оптимизирует точность отдельных меток, а не порядок внутри запроса;
• pairwise: берутся пары документов одного запроса с разной релевантностью, цель бинарная: должен ли первый стоять выше второго. Классификатор учится на разности признаков (идея RankSVM) или на разности скоров с логистической функцией потерь (RankNet). Это честная бинарная классификация, но число пар растёт квадратично, поэтому их семплируют.

Дальше скажите, что есть listwise-подход, который оптимизирует метрику списка напрямую, например LambdaMART. На практике всё это есть в бустингах: lambdarank в LightGBM, rank:pairwise и rank:ndcg в XGBoost, YetiRank и PairLogit в CatBoost. Им нужен идентификатор группы, то есть запроса.

Оценка: NDCG@k, MAP, MRR, которые считаются внутри каждого запроса и усредняются. Разбиение по группам (GroupKFold), чтобы документы одного запроса не попадали одновременно в обучение и валидацию.

Откуда метки: асессорская разметка или клики. Клики смещены по позиции: верхние документы кликают чаще просто потому, что они сверху, и это нужно учитывать при обучении.

Где спотыкаются

Берут метки из позиций в текущей выдаче: верх релевантен, низ нет. Модель тогда учится воспроизводить старый ранжировщик, а не релевантность.

Меряют ROC-AUC или accuracy по всему датасету. Глобальная метрика смешивает запросы и может расти, когда порядок внутри запросов не меняется вовсе.

Делят выборку случайно по строкам, а не по запросам. Утечка через общие признаки запроса завышает качество на валидации, а в проде оно проседает.