Зачем RAG нужен reranking

Первичный retriever оптимизирован на быстрый поиск кандидатов, а не на идеальную сортировку. Reranker получает небольшой top-k набор и повторно оценивает документы с более дорогой, но точной моделью.

Двухэтапный retrieval

Типичный pipeline выглядит так: vector или hybrid search возвращает 20–100 кандидатов, затем reranker пересчитывает relevance score и оставляет 5–15 фрагментов для LLM. Это разделяет задачи recall и precision.

Cross-encoder reranker

Cross-encoder одновременно видит query и candidate chunk, поэтому лучше ловит точные смысловые связи, чем независимые embeddings. Цена — больше latency и compute на каждый кандидат.

LLM reranker

LLM можно использовать для pairwise или listwise ranking, особенно если relevance зависит от сложных business rules. Но такой подход дороже, менее детерминирован и требует строгого output schema.

Не начинайте с огромного top-k

Если reranker получает сотни chunks, latency быстро растёт. Сначала добейтесь хорошего recall на первом этапе, затем подбирайте минимальный candidate set, который не теряет нужные документы.

Добавьте metadata filters до reranking

Tenant, permissions, language, date, document type и product scope лучше фильтровать до дорогой модели. Reranker не должен исправлять ошибки access control или очевидно нерелевантный corpus.

Hard negatives важнее случайных negatives

Для тестов собирайте документы, которые похожи на правильный ответ, но не содержат нужного факта. Именно hard negatives показывают, умеет ли reranker отличать близкий контекст от действительно полезного.

Метрики offline

Смотрите nDCG, MRR, Recall@K и Precision@K до и после reranking. Отдельно измеряйте, попал ли supporting document в финальный context window.

Проверяйте влияние на generation

Рост retrieval score сам по себе не гарантирует лучший ответ. Запускайте end-to-end evals: faithfulness, answer correctness, citation accuracy и refusal quality.

Latency и cost budget

Логируйте candidate count, reranker latency, model version, tokens и cache hit rate. Для high-traffic систем полезны batching, smaller top-k и fallback на первый-stage ranking при деградации.

Production rollout

Запускайте reranker через feature flag или A/B test. Сравнивайте success rate, p95 latency, cost per request и downstream answer metrics, а не только offline benchmark.

Практический checklist

  • Быстрый retriever отвечает за recall.

  • Metadata filters применяются до reranker.

  • Candidate top-k ограничен.

  • Есть hard-negative dataset.

  • Измеряются nDCG/MRR/Precision@K.

  • Есть end-to-end RAG evals.

  • Логируются latency и cost.

  • Версии reranker фиксируются.

  • Есть fallback при timeout.

  • Изменения проходят A/B или regression gate.

Вывод

Reranking полезен там, где первый retrieval уже находит правильные документы, но плохо сортирует близкие кандидаты. Лучший результат даёт не самый большой reranker, а сбалансированный двухэтапный pipeline с измеримым выигрышем в качестве и контролируемой latency.