Реранкер в RAG: зачем переранжировать результаты поиска

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

Представим базу знаний интернет-магазина. Покупатель спрашивает: «Как изменить адрес, если заказ уже оплачен, но ещё не отправлен?» Поиск находит условия доставки, способы оплаты, возврат товара и нужный пункт об изменении заказа. Если в контекст попадут первые три совпадения, модель может ответить общими словами. Реранкер получает вопрос вместе с каждым найденным фрагментом и пытается поставить инструкцию об изменении адреса выше остальных.

Где реранкер находится в цепочке RAG

В RAG языковая модель отвечает с опорой на найденные документы. Между получением вопроса и генерацией ответа можно выделить несколько шагов:

1. Первичный поиск. Векторный поиск, BM25 или их сочетание собирают кандидатов из базы.
2. Подготовка списка. Приложение убирает повторяющиеся фрагменты и сохраняет их идентификаторы, ссылки и метаданные.
3. Переранжирование. Модель оценивает соответствие кандидатов исходному вопросу и меняет порядок выдачи.
4. Сборка контекста. Лучшие фрагменты помещаются в доступный бюджет токенов вместе с указанием источников.
5. Ответ. Генеративная модель читает этот контекст и формулирует результат.

Для первого эксперимента можно найти 30–50 кандидатов, переранжировать их и передать в ответ 3–5 фрагментов. Это стартовая настройка для проверки, а не универсальная норма: количество зависит от длины текстов, сложности вопросов и допустимой задержки. Важен сам принцип — широкий отбор сначала, более внимательная оценка потом.

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

Чем реранкер отличается от эмбеддингов

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

Распространённый вариант реранкера — cross-encoder, модель совместной оценки пары «вопрос — документ». Она получает оба текста одновременно и выдаёт оценку релевантности. Для каждого нового вопроса пары приходится оценивать заново, поэтому такой этап обычно применяют к ограниченному списку кандидатов.

Не всякое переранжирование устроено как cross-encoder. Есть, например, модели с поздним взаимодействием токенов, такие как ColBERT, и оценка документов через генеративную модель. При выборе инструмента стоит уточнить архитектуру: от неё зависят хранение данных и стоимость обработки.

Почему гибридного поиска иногда недостаточно

Гибридный поиск объединяет совпадения по словам и по смыслу. Он полезен, если запрос содержит одновременно точное обозначение — например, номер ошибки — и описание проблемы обычным языком.

Но объединение списков ещё не означает, что каждый фрагмент внимательно сопоставлен с вопросом. Например, RRF сводит выдачи по позициям документов. Модель переранжирования добавляет другую проверку: насколько содержание кандидата подходит к запросу. Эти этапы можно использовать вместе.

В нашем условном примере текст «Как оплатить заказ» может хорошо совпадать со словами покупателя. Однако для решения вопроса важнее фрагмент «Изменение адреса до передачи заказа в доставку». Проверять такую разницу особенно полезно в инструкциях с условиями, исключениями и похожими названиями разделов.

Как подключить реранкер: API или локальная модель

Через API: короткий путь к эксперименту

Cohere принимает вопрос и массив текстов, а возвращает их индексы и оценки. Параметр top_n ограничивает число возвращённых результатов, но не список оцениваемых документов.

Пример по документации API v2, проверенной 9 октября 2026 года, использует вымышленные фрагменты. Нужны пакет requests, ключ в COHERE_API_KEY и доступ к указанной модели в аккаунте.

import os
import requests

query = "Как изменить адрес оплаченного, но не отправленного заказа?"
chunks = [
    {"id": "payment", "text": "Заказ можно оплатить банковской картой."},
    {"id": "address", "text": "До передачи заказа в доставку адрес меняет поддержка."},
    {"id": "returns", "text": "Для возврата товара оформите заявку в личном кабинете."},
]

response = requests.post(
    "https://api.cohere.com/v2/rerank",
    headers={"Authorization": "Bearer " + os.environ["COHERE_API_KEY"]},
    json={
        "model": "rerank-v4.0-pro",
        "query": query,
        "documents": [chunk["text"] for chunk in chunks],
        "top_n": 2,
    },
    timeout=20,
)
response.raise_for_status()
for result in response.json()["results"]:
    chunk = chunks[result["index"]]
    print(chunk["id"], result["relevance_score"], chunk["text"])

Индекс из ответа относится к массиву documents. Сохраняйте связь с исходным фрагментом и его ссылкой. Пример показывает интеграцию; оценки зависят от сервиса. Обработка ошибок и повторных запросов здесь опущена.

Локально: больше контроля над данными

Для обработки на своей инфраструктуре можно проверить мультиязычную BAAI/bge-reranker-v2-m3. В карточке модели указана лицензия Apache 2.0 и приведены примеры через FlagEmbedding и Transformers. Это отдельная модель переранжирования: сходное название с bge-m3 не делает её заменой модели эмбеддингов.

Локальный запуск потребует места для весов, памяти и проверки скорости на вашем оборудовании. API снимает часть работы по эксплуатации, но отправляет вопрос и тексты внешнему провайдеру. Выбор удобно делать по трём ограничениям: допустимо ли передавать документы наружу, какая задержка приемлема и сколько запросов ожидается. Для русского корпуса результат проверяют на русских вопросах — одна надпись «multilingual» качество не гарантирует.

Какие настройки проверить в первую очередь

• Количество кандидатов. Слишком короткий список может потерять нужный фрагмент ещё до реранкера. Слишком длинный увеличивает объём обработки. Сравните несколько размеров на одном наборе запросов.
• Длину текста. Вопрос и фрагмент должны помещаться в ограничения выбранного инструмента. Обрезанный конец инструкции может содержать главное условие; в Cohere длинные документы обрезаются до установленного лимита.
• Состав фрагмента. Заголовок раздела иногда помогает понять короткий абзац. Проверьте вариант «заголовок + текст», сохранив отдельно адрес источника и служебные метаданные.
• Повторы. Пять соседних кусков одной инструкции могут вытеснить другой полезный документ. Проверьте дедупликацию и разнообразие источников перед сборкой контекста.
• Порог оценки. Не переносите условное «выше 0,7 — подходит» между моделями. Числа зависят от модели и преобразования выхода; высокий score не равен доказанной истинности текста.

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

Как понять, что реранкер действительно помог

Предлагаемый порядок проверки: соберите небольшой набор реальных вопросов и вручную отметьте фрагменты, достаточные для ответа. Включите простые запросы, уточнения с условиями, похожие формулировки и вопросы, на которые в базе ответа нет. Для первого опыта подойдут, например, 30–50 вопросов; важнее их разнообразие, чем само число.

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

• Recall@K на первом этапе: какая доля размеченных релевантных фрагментов попала в K кандидатов. Если нужные сведения не найдены, начинать следует с поиска.
• MRR на итоговой выдаче: насколько высоко стоит первый релевантный результат. Это удобно для вопросов с одной достаточной инструкцией.
• nDCG@K: насколько удачно упорядочены результаты с разной степенью полезности. Для неё нужна соответствующая разметка релевантности.
• Качество ответа и задержка: хватает ли выбранных источников для ответа, верны ли ссылки и укладывается ли полная цепочка в допустимое время.

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

Что реранкер не исправит

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

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

С чего начать

Реранкер имеет смысл проверять, когда нужный документ уже находится, но стоит слишком низко и не попадает в контекст. Сохраните базовую выдачу, добавьте оценку кандидатов и сравните результаты на размеченных вопросах. Оставляйте этот этап, если он улучшает отбор источников при приемлемой задержке и стоимости. Если нужных фрагментов в кандидатах нет, сначала исправляйте первичный поиск и подготовку документов.