Реранкер в RAG: когда он даёт скачок качества

MAATRIX

Вы добавили в RAG реранкер, потому что в статье написали, что так «правильно» — а разницы в качестве ответов почти не заметили, зато задержка выросла на заметные доли секунды. Или наоборот: у вас есть подозрение, что часть релевантных фрагментов теряется где-то за top-5, но вы не понимаете, окупит ли вторая модель эту потерю. Разберём честно, в каком именно случае реранкер даёт реальный скачок качества, а в каком — просто добавляет задержку без пользы.

Двухэтапная архитектура: широкий поиск, потом узкая пересортировка

RAG-поиск в проде почти никогда не строится в одно действие — и это не случайность, а компромисс между скоростью и точностью, разложенный на два последовательных этапа.

Первый этап — retrieval. Быстрый, но грубый метод отбирает из всего корпуса достаточно широкий набор кандидатов — например top-50 фрагментов. Быстрым он получается потому, что работает с упрощённым представлением текста: эмбеддинги, посчитанные заранее и один раз, сравниваются с эмбеддингом запроса через векторное расстояние (обычно косинусное). Это может быть чисто векторный поиск (Qdrant, pgvector, Chroma), лексический (BM25 по ключевым словам) или их комбинация — конкретный метод для этого этапа не так важен, важно, что он один: сравнить готовое представление запроса с готовым представлением каждого чанка, без пересчёта под конкретную пару.

Цена этой скорости — упрощение. Эмбеддинг кодирует смысл текста «вообще», в отрыве от конкретного вопроса, к которому его потом будут сравнивать. Из-за этого top-50 после первого этапа — это не «50 самых релевантных фрагментов», а скорее «50 фрагментов, которые точно стоит рассмотреть внимательнее» — с гарантированной полнотой, но необязательно точным порядком.

Второй этап — rerank. Специализированная модель-реранкер берёт этот уже узкий набор (не весь корпус — только то, что прошло первый отбор) и оценивает каждую пару «запрос + кандидат» заново, отдельно и более тщательно. На выходе — новый порядок, из которого в контекст модели идёт уже действительно узкий финальный набор — например top-5. Это тот же принцип, что в поиске: сначала индекс быстро сужает миллионы документов до сотни, затем более дорогой алгоритм ранжирует именно эту сотню.

Если вы ещё не подняли сам retrieval-слой — эмбеддинги, векторную базу, чанкинг — это отдельная тема, и начинать стоит с неё: без рабочего первого этапа реранкер пересортировывать нечего. Базовая схема описана в статье как поднять RAG по своим документам на сервере.

Почему реранкер точнее: совместный анализ пары вместо сравнения двух чисел

Ключевое архитектурное отличие реранкера от эмбеддера — не в размере модели и не в «качестве вообще», а в том, что именно она видит на входе.

Эмбеддер (bi-encoder) кодирует запрос и фрагмент раздельно и независимо. Он превращает текст фрагмента в вектор один раз, заранее, до того как узнал, каким будет вопрос. Затем то же самое происходит с вопросом — уже в момент запроса. Дальше система просто сравнивает два готовых числовых представления. Модель никогда не видела вопрос и фрагмент рядом друг с другом — она оценивала их смысл порознь, а сравнение делает уже не модель, а простая математика (косинусное расстояние).

Реранкер устроен принципиально иначе. Он получает на вход пару целиком — запрос и конкретный кандидат вместе, в одном проходе через модель — и всё внимание модели (в архитектуре трансформера это буквально механизм attention между всеми токенами обоих текстов) работает на то, чтобы понять, отвечает ли этот фрагмент именно на этот вопрос. На выходе — не вектор, а одно число: скор релевантности конкретно этой пары.

Разница на практике заметна там, где у эмбеддера системно не хватает разрешения:

• Синонимы и парафраз. «Как остановить подписку» и «порядок расторжения договора оказания услуг» лексически и даже семантически близки, но по сути один текст — вопрос пользователя, другой — юридическая формулировка, которая на него не отвечает напрямую. Совместный анализ пары это различает лучше, чем сравнение двух независимо посчитанных облаков смысла.
• Частичное совпадение против точного ответа. Длинный фрагмент, поверхностно упоминающий пять смежных тем, у эмбеддера нередко получает более высокое сходство с вопросом, чем короткий фрагмент, отвечающий на него буквально и по делу — просто потому что у длинного текста больше «точек соприкосновения» с любым запросом.
• Отрицания и уточнения. «Настройка backup без шифрования» и «настройка backup с шифрованием» у эмбеддера могут лечь рядом в векторном пространстве — тема одна и та же. Реранкер, читающий пару целиком, различает их гораздо надёжнее, потому что оценивает именно соответствие, а не общую тематическую близость.

Если в вашем пайплайне эмбеддинги вообще плохо разделяют смысловые нюансы, возможно, дело ещё и в выборе самой модели эмбеддингов — это разобрано в статье эмбеддинг-модели: какую выбрать для RAG. Но даже с хорошим эмбеддером системное ограничение независимого кодирования никуда не девается — оно устранимо только на втором этапе.

Где именно возникает скачок качества

Реранкер не улучшает результат равномерно во всех случаях — эффект сильно зависит от того, как выглядит выдача первого этапа.

Наибольший ощутимый выигрыш — когда первичный поиск возвращает много кандидатов с близким по векторной метрике сходством, но реально разной фактической релевантностью. Это типичная картина, когда:

• в базе много документов на одну тему с пересекающейся лексикой (несколько версий инструкции, разные разделы одного регламента, похожие тарифные планы);
• вопрос пользователя сформулирован не теми словами, что в документе (парафраз, разговорный стиль против технического текста источника);
• разница в косинусном сходстве между top-1 и top-15 после первого этапа минимальна — доли процента — то есть эмбеддер сам «не уверен» в порядке.

В такой ситуации реранкер разгребает именно то, с чем эмбеддер справляется хуже всего: тонкое ранжирование близких по смыслу, но не равнозначных по сути кандидатов.

Где выигрыш почти незаметен — когда первичный поиск и так возвращает явного лидера с большим отрывом по сходству, а остальные кандидаты откровенно не по теме. Здесь реранкер просто подтверждает то, что и так очевидно, а его задержка становится чистыми потерями без компенсации в качестве.

Отдельный случай, где реранкер регулярно окупается — базы с короткими похожими друг на друга чанками (FAQ, каталоги товаров, нормативные пункты). Там у векторного поиска мало «зацепок» для различения близких формулировок, и совместный анализ пары даёт больше пользы, чем в базах с длинными развёрнутыми документами, где смысловые различия и так крупнее.

Цена точности: почему реранкер медленнее и что это значит для задержки

Компромисс здесь прямой и техническо объяснимый — а не «просто так дороже».

Эмбеддинг каждого чанка считается один раз, заранее, при индексации, и хранится в векторной базе. Поиск в момент запроса — это сравнение уже готовых чисел, операция дешёвая даже на миллионах записей. Реранкер так не работает: он не может посчитать что-то заранее, потому что оценивает не текст сам по себе, а именно пару «запрос + кандидат» — а запрос известен только в момент обращения пользователя. Значит, каждый раз, для каждого запроса, модели нужно прогнать через себя все пары кандидатов заново.

Именно поэтому реранкер применяют не ко всему корпусу, а только к узкому предварительно отобранному набору — 20–50 кандидатов, а не миллион документов. Прогнать cross-encoder по всей базе для каждого запроса было бы вычислительно неприемлемо: количество пар растёт линейно с размером корпуса, и на большой базе это превратилось бы в минуты, а не миллисекунды.

Но даже на 20–50 кандидатах реранкер — это дополнительный проход через нейросеть, вставленный последовательно между retrieval и генерацией ответа. Он не параллелится с самим поиском (кандидатов сначала нужно найти, потом уже пересортировать) и не параллелится с генерацией ответа языковой моделью (сначала нужно решить, что именно попадёт в контекст). Это добавляет к общему времени ответа RAG-системы заметную задержку — насколько именно заметную, зависит от размера реранкер-модели, числа кандидатов и от того, работает ли она на GPU или CPU; точных цифр здесь давать не будем — это стоит измерить на своём железе и своей модели, ориентиры из чужих бенчмарков на вашей конфигурации могут не подтвердиться.

Если задержка первого этапа у вас и так на грани приемлемой — например векторная база уже отвечает медленнее, чем хотелось бы, — добавлять поверх ещё один последовательный этап стоит с особой осторожностью. Причины медленного векторного поиска разобраны в статье Qdrant: медленный поиск по векторам — причины и решение; имеет смысл сначала убедиться, что первый этап не является уже узким местом сам по себе.

Практическая настройка: сколько кандидатов брать и куда встраивать модель

Рабочая схема без лишних деталей:

1. Retrieval: top-K1 = 20–50 кандидатов
   (векторный поиск, лексический BM25 или гибрид)
2. Rerank: cross-encoder оценивает каждую пару
   запрос + кандидат из набора K1
3. Финальный отбор: top-K2 = 3–5 кандидатов
   передаются модели как контекст

Несколько практических соображений по настройке:

• K1 (размер первичного набора) — это баланс полноты и задержки. Больше кандидатов на входе в реранкер — выше шанс, что действительно релевантный фрагмент туда попадёт, но и больше пар нужно прогнать через модель. Начинать разумно с 20–30 и увеличивать только если видно, что нужные фрагменты систематически проваливаются за пределы этого окна.
• K2 (финальный набор для контекста) — определяется бюджетом контекстного окна модели и тем, сколько разных фрагментов реально нужно для ответа, а не самим фактом наличия реранкера. Пять хорошо отранжированных фрагментов почти всегда полезнее пятнадцати средне отранжированных.
• Реранкер — отдельный сервис в пайплайне, а не часть векторной базы. Разворачивается как отдельная модель (через API провайдера или локально на своём железе) между шагом retrieval и шагом генерации; менять векторную базу или эмбеддер при добавлении реранкера не нужно — это независимые компоненты.
• Логируйте оба порядка — до и после реранка. Это даёт возможность потом посмотреть, насколько сильно вторая модель меняет порядок на реальных запросах, а не только на тестовых.

Если ваш RAG уже выдаёт странные ответы и вы подозреваете реранкер как решение — сначала стоит исключить более частую причину: проблемы на этапе чанкинга, из-за которых в индекс попадают обрезанные или бессмысленные фрагменты. Разбор такого случая — в статье RAG выдавал чушь: проблема была в чанкинге. Реранкер не чинит плохие чанки — он просто точнее их сортирует.

Как проверить, нужен ли вам реранкер, прежде чем включать его в прод

Правильный порядок действий — не «добавить реранкер, потому что так советуют», а сначала измерить на своих данных, даёт ли он разницу, которая стоит своей задержки.

Практическая методика:

1. Соберите 20–30 реальных запросов, похожих на то, что будут спрашивать пользователи — не выдуманных, а близких к продакшен-нагрузке. Лучше взять их из логов, если система уже где-то работает в тестовом режиме, или составить вручную, ориентируясь на реальные сценарии использования.
2. Прогоните каждый запрос дважды — через обычный retrieval (top-5 без реранка) и через полную схему retrieval + rerank (top-50 → rerank → top-5).
3. Сравните итоговые наборы фрагментов вручную. Не автоматической метрикой — глазами, для каждого запроса: изменился ли состав top-5, стал ли он ближе к тому, что вы бы выбрали сами как эксперт по теме.
4. Отдельно замерьте добавленную задержку на своём железе и с вашим количеством кандидатов — именно ту цифру, с которой придётся жить в проде, а не ориентир из чужого бенчмарка.
5. Решайте по совокупности. Если реранкер меняет состав top-5 в заметной доле запросов — и именно в сторону более релевантных фрагментов — задержка обычно того стоит. Если состав почти не меняется, а первичный поиск и так стабильно выдаёт релевантные фрагменты первыми, добавлять второй этап пока незачем — можно вернуться к вопросу позже, если база вырастет или запросы станут сложнее.

Этот тест стоит нескольких часов работы и полностью снимает главный риск — вставить в пайплайн дополнительную задержку ради выигрыша, которого на ваших конкретных данных просто нет.

Частые вопросы