# Reranker в RAG: сколько документов передавать на повторную оценку

Reranker в RAG: выбор top-k, длина пар вопрос–документ, качество повторной оценки, GPU и CPU, общий бюджет задержки и измерение полезности на одном корпусе.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/reranker-rag-latency/
Language: ru

Reranker в RAG повторно оценивает кандидатов, найденных первым поисковым этапом. Он помогает упорядочить короткий список, но добавляет вычисления для каждой пары вопрос–фрагмент. Для выбора GPU важно определить число кандидатов, их длину и допустимую задержку всей операции.

Ниже — план измерения без универсального обещания улучшения. Разбор основан на официальных источниках, проверенных 1 ноября 2026 года.

## Разделите retrieval и повторную оценку

[Sentence Transformers Quickstart](https://sbert.net/docs/quickstart.html) различает embedding-модели и Cross-Encoder для оценки пар. Первый этап быстро создаёт кандидатов, второй выполняет более подробную работу с выбранными текстами. Эти стадии имеют разные ресурсные профили.

Если нужного документа нет в исходном списке, reranker не может поднять его на первое место. Поэтому сначала проверьте качество и полноту retrieval. Увеличение мощности повторной оценки не заменяет исправление разбиения документов или первого поиска.

## Выберите несколько глубин списка

Для пилота возьмите одинаковые вопросы и несколько значений top-k. Числа выбираются под ваш корпус и допустимое время. Например, небольшой и более широкий список позволяют проверить, появляется ли полезный документ и сколько стоит дополнительная обработка.

| Параметр | Возможное влияние |
| --- | --- |
| Число кандидатов | Больше пар для обработки |
| Длина фрагмента | Иной объём модельной работы |
| Размер batch | Изменение памяти и эффективности |
| Одновременные вопросы | Конкуренция за один вычислительный ресурс |

Не сравнивайте два режима на разных текстах и не называйте полученную разницу свойством GPU без сохранения остальных условий.

## Сохраните бюджет задержки

Пользователь ждёт не только reranker. В общий путь входят кодирование вопроса, поиск, передача кандидатов и генерация ответа. Отдельно измерьте эти стадии и полное время до полезного результата.

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

## Подтвердите качество порядка

[Qdrant Ranking and Reranking](https://qdrant.tech/course/beginners/module-6/ranking-and-reranking/) описывает изменение порядка кандидатов. Подготовьте вопросы с известными полезными фрагментами и сравните выдачу до и после. Сохраните примеры, где порядок стал лучше и где ухудшился.

Дополнительно проверьте формат входа выбранной модели. Неверная подготовка пары может дать корректный числовой ответ, который не соответствует ожидаемому смыслу. Значение score следует трактовать по документации модели, а не как универсальную вероятность правильности документа.

## Решите, нужен ли отдельный ресурс

Если reranker и генератор делят GPU, испытайте их совместную работу. Поочерёдный тест не показывает пиковую память и очереди при реальных одновременных запросах. Разделение ресурсов имеет смысл обсуждать после измерения общего ограничения.

Для конкретных моделей полезны [BGE reranker](/ru/journal/bge-reranker-gpu/) и [Qwen reranker](/ru/journal/qwen-reranker-serving/).