Реранкинг — второй этап поиска. Первый этап возвращает кандидатов быстро и грубо, второй пересортировывает их точнее и оставляет лучшие.
Почему одного поиска мало
Векторный поиск сравнивает два независимо построенных вектора. Запрос кодируется, ничего не зная о документе, документ — ничего не зная о запросе. Это быстро и позволяет заранее построить индекс, но грубо.
Такая архитектура называется bi-encoder. Две независимые кодирующие сети: вектор документа строится один раз при индексации, вектор запроса — в момент обращения, векторный поиск сводится к сравнению векторов. Именно это делает возможным поиск по миллионам фрагментов за миллисекунды.
Реранкер — cross-encoder. Он получает пару «запрос и фрагмент» вместе и оценивает, отвечает ли этот фрагмент на этот вопрос. Такая модель видит связь напрямую: слова запроса сопоставляются словам фрагмента в момент оценки, поэтому она различает случаи, где векторная близость одинакова, а полезность разная, — например, тексты на смежную тему.
Цена различия — в способе счёта. Оценка cross-encoder зависит от запроса, поэтому её нельзя посчитать заранее, а время растёт линейно с размером базы — прогнать через реранкер весь индекс невозможно. Отсюда двухэтапная схема: bi-encoder отбирает 20–50 кандидатов, cross-encoder точно сортирует только их.
Что это меняет на практике
Типичная картина в неработающей системе: правильный фрагмент есть в выдаче, но на восьмом-пятнадцатом месте, а в контекст попадают первые пять. Ответ строится по посторонним фрагментам. Реранкер поднимает нужное в первую тройку.
Поэтому прежде чем менять модель или переписывать промпт, стоит проверить: попадает ли правильный фрагмент в двадцать кандидатов. Если да — задача решается реранкингом, и это дешевле всех остальных вариантов.
Профиль проблемы виден по метрикам. Если на проверочном наборе recall при глубине 20–50 высок, а MRR или NDCG низкие — нужное находится, но тонет. Это и есть профиль ситуации «поможет реранкинг»; как считать метрики — в статье про метрики качества RAG.
Настройка
Сколько кандидатов подавать. Обычно 20–50. Больше — выше шанс, что нужное вообще попадёт на второй этап, и больше задержка. Ориентир для верхней границы — глубина, на которой тонет нужный фрагмент по замерам recall, плюс запас в 20–30 %.
Сколько оставлять. Пять-десять. Дальше срабатывает эффект длинного контекста: лишние фрагменты мешают.
Порог отсечения. Если ни один фрагмент не набрал приемлемой оценки, честнее ответить «в документах не нашлось», чем строить ответ по слабым совпадениям. Этот порог — один из главных рычагов против выдумок.
Порядок настройки. Сначала размер выдачи первого этапа подбирают по recall, затем число оставляемых фрагментов — по метрикам ответа, и только потом порог — по корректности отказа. Без размеченного набора порог ставится «на глаз» и либо душит правильные ответы, либо пропускает мусор.
Порог отсечения и отказ
Механизм рычага. Оценки реранкера для релевантных и нерелевантных фрагментов — два пересекающихся распределения. Порог режет их пересечение: ниже порога остаются слабые совпадения, по которым генератор строит уверенные галлюцинации; выше — теряется часть правильных фрагментов, и система ложно отказывает.
Калибровка по набору. Порог выбирают на проверочном наборе, где примерно пятая часть вопросов — без ответа в документах. Порог поднимают, пока доля корректных отказов не достигнет целевой, и следят, чтобы полнота ответов не просела. Ложный отказ и выдумка — зеркальные издержки одного числа.
Порог привязан к модели. Шкалы оценок разных реранкеров не сопоставимы: после смены модели порог пересчитывают. То же — при заметном обновлении базы знаний: распределение оценок сдвигается вместе с корпусом.
Чем платим
Задержкой: добавка ко времени ответа заметна, особенно на большом числе кандидатов. И вычислениями — реранкер это отдельная модель, которую надо где-то запускать.
Порядок величин задержки. Одна пара «запрос — фрагмент» на GPU оценивается за единицы-десятки миллисекунд, на CPU — на порядок медленнее. Пятьдесят кандидатов на CPU — секунды; батчинг, обработка пар одним пакетом, сокращает время в несколько раз. Точные значения снимают замером на своём инференсе.
Бюджет двух видов. Реранкер по API оплачивается вызовами: каждая пара — расход, счёт растёт линейно с трафиком. Своя модель требует GPU или выделенного сервера и сопровождения, зато стоимость фиксирована и тексты не покидают контур. Компромисс обычно ищут, уменьшая число кандидатов и выбирая компактную модель реранкера.
Какого реранкера выбрать
Компактная локальная модель. Небольшие cross-encoder на сотни миллионов параметров — типовой выбор: минимальная задержка на GPU, запуск в своём контуре, нет оплаты за вызов. Платят качеством на сложных перефразированиях и, у части моделей, слабой работой с русским языком.
Крупная модель через API. Точнее на запутанных запросах и не требует железа; плата — задержка, стоимость за вызов и передача текстов фрагментов вовне, что для персональных данных ограничено законом.
LLM в роли реранкера. Генеративной модели можно поручить оценить или сравнить фрагменты; это гибко — можно спрашивать не только о релевантности, но и о достаточности фрагмента для ответа. Плата — цена токенов, задержка выше специализированных моделей и шумные оценки; уместно в экспериментах, а не при жёстком бюджете ответа.
Критерии выбора по убыванию веса: допустимая задержка, качество работы с русским языком, требование держать данные в контуре, стоимость на вашем трафике. Развилка «своя модель или API» разобрана отдельно.
Частые вопросы
Насколько реранкинг улучшает ответы?
Заметнее всего там, где нужный фрагмент находится, но не попадает в первые позиции — это типичная ситуация. Величину прироста нужно измерять на своём наборе вопросов: она сильно зависит от того, насколько однородны документы. Обещать конкретный процент до замера нельзя.
Сколько кандидатов подавать на реранкинг?
Обычно 20–50. Меньше — теряется смысл этапа, нужное может не дойти до пересортировки. Больше — растёт задержка, потому что каждая пара обрабатывается отдельно. Подбирается по допустимому времени ответа.
Можно ли обойтись без реранкинга?
На простых однородных базах — да. Он становится нужен, когда документы разнородны и много текстов на смежные темы: именно там векторный поиск возвращает похожее вместо нужного.
Что делать, если ни один фрагмент не набрал оценки?
Отвечать, что в документах не нашлось. Это лучше, чем строить ответ по слабым совпадениям: именно так и появляются уверенные выдумки со ссылкой на нерелевантный источник.
Почему реранкинг не улучшил метрики?
Чаще всего нужного фрагмента нет среди кандидатов: низкий recall первого этапа пересортировкой не лечится — чинить надо чанкинг и эмбеддинги. Вторая причина — завышенный порог отсечения, отрезающий правильные фрагменты: проверьте долю ложных отказов.
Реранкеру нужен GPU?
Зависит от потока и бюджета ответа. Единицы-десятки запросов в час терпят CPU с батчингом — задержка укладывается в секунды. Параллельные пользователи и ответ за доли секунды означают GPU либо урезание числа кандидатов.
Можно ли реранкером скрывать документы без доступа?
Нет. К моменту реранкинга фрагмент уже попал в выдачу и мог утечь в логи и метрики. Разграничение доступа должно работать до поиска — на уровне фильтрации индекса по правам пользователя, это разобрано в статье про разграничение доступа.