Reranker в RAG стоит проверять не по тому, насколько убедительно выглядят его оценки релевантности, а по тому, меняются ли полезным образом документы в верхней части выдачи. Практичный тест — взять реальные запросы, вручную отметить подходящие фрагменты, сравнить исходный порядок поиска с порядком после reranking и затем проверить влияние на ответы и задержку.
Такой тест помогает решить конкретную задачу: нужен ли reranker в вашей системе и какой вариант лучше работает на вашем корпусе. Универсальной модели-победителя нет: результат зависит от языка, предметной области, разбиения документов на чанки и качества первичного поиска.
Что именно проверяет reranker в RAG
Первичный поиск — например, по эмбеддингам — отбирает кандидатов. Reranker получает запрос и эти документы, оценивает соответствие и переставляет их по релевантности. Часто это cross-encoder: он обрабатывает запрос вместе с каждым кандидатом, а не кодирует их независимо, как типичная схема bi-encoder-поиска.
Отсюда важное ограничение: reranker обычно не находит документ, которого нет среди кандидатов. Если нужный фрагмент не попал в исходную выборку, улучшение порядка его не вернёт. Поэтому тест должен отдельно учитывать полноту первичного поиска и качество перестановки.
Документация Sentence Transformers описывает cross-encoder как модель для оценки пар «запрос — текст» и отмечает, что такие модели применяют для reranking. Это объясняет, почему их часто запускают после быстрого retrieval, а не вместо него: оценка каждой пары требует отдельного вычисления.
Соберите тестовый набор из реальных запросов
Начните с 50–200 запросов из логов, если это возможно. Уберите персональные данные и секреты, а повторяющиеся запросы сгруппируйте. Если реальных логов мало, добавьте типичные вопросы, но не ограничивайтесь синтетическими примерами: формулировки пользователей часто отличаются от формулировок документации.
Для каждого запроса сохраните:
- текст запроса в исходном виде;
- список кандидатов от текущего retrieval с идентификаторами фрагментов;
- метку релевантности для каждого кандидата;
- источник и версию индекса.
Разметку делайте по содержанию, а не по совпадению слов. Например, документ о лимитах API может отвечать на вопрос «почему запросы перестали проходить?», даже если слово «ошибка» в нём не встречается. Удобна шкала из трёх уровней: 0 — не отвечает, 1 — полезен косвенно или частично, 2 — непосредственно отвечает. Согласуйте критерии до начала разметки и зафиксируйте спорные случаи.
Не размечайте только выдачу одной модели. Объедините кандидатов из исходного поиска и нескольких сравниваемых reranker; иначе система может выглядеть успешной просто потому, что эталонные документы не попали в проверяемый пул.
Как сравнить качество reranker на одних и тех же данных
Зафиксируйте корпус, запросы, настройки первичного поиска и число кандидатов. Затем сравните как минимум три варианта: исходный порядок retrieval, reranker A и reranker B. Для каждого запроса передавайте моделям один и тот же список кандидатов.
Простой воспроизводимый вариант — экспортировать кандидатов в JSONL:
json
{«query»:»Как настроить таймаут API?»,»documents»:[
{«id»:»doc-17″,»text»:»Параметр timeout задаёт…»},
{«id»:»doc-42″,»text»:»Повторные запросы выполняются…»}
]}
Для каждой модели сохраните исходный порядок, итоговый порядок и время обработки. Запишите точные названия моделей, версии библиотек, параметры и дату теста. Если модель предоставляет только числовой score, не сравнивайте абсолютные значения между разными моделями: шкалы могут не совпадать. Сравнивайте порядок документов внутри каждого запроса.
Часть запросов оставьте для проверки, не меняя по ним настройки. Если подбирать пороги и параметры на всём наборе, итоговая метрика будет слишком оптимистичной. Для небольшой коллекции достаточно разделить запросы по темам, чтобы в отложенную часть попали разные типы вопросов.
Метрики: не сводите результат к одной цифре
Для оценки верхушки выдачи полезны MRR и nDCG@k. MRR показывает, насколько высоко оказался первый релевантный документ. nDCG учитывает позиции нескольких релевантных документов и, при градуированных метках, различие между частично и полностью полезным фрагментом.
Дополнительно измеряйте Recall@k: долю запросов, для которых среди первых k результатов вообще есть нужный документ. Это особенно важно, если reranker меняет порядок, но не может расширить набор кандидатов. Сравните Recall до reranking и после него; при неизменном пуле кандидатов он обычно не должен меняться, если вы не отбрасываете документы или не меняете условия оценки.
Например, для запроса с релевантными фрагментами на позициях 4 и 9 исходный поиск может дать низкий MRR. Если reranker поднял один из них на первое место, MRR улучшится. Но если второй полезный фрагмент исчез из первых пяти результатов, это может ухудшить полноту контекста для вопросов, требующих нескольких источников. Поэтому смотрите метрики на нескольких значениях k и проверяйте типичные ошибки вручную.
BEIR — бенчмарк для оценки систем поиска на разных наборах данных и задачах. Его материалы полезны как ориентир по разнообразию тестовых коллекций и метрик, но публичный бенчмарк не заменяет проверку на собственных запросах: домен, язык и структура корпуса могут отличаться.
Проверьте, не улучшилась ли только сортировка
Высокая метрика ранжирования — промежуточный результат. Для RAG важен конечный ответ. Запустите одну и ту же модель-генератор на контексте из исходного retrieval и после reranking, сохранив идентичными промпт, лимиты и параметры генерации.
Оцените ответы по заранее выбранным критериям: отвечает ли система на вопрос, подтверждается ли ключевое утверждение контекстом, не потеряно ли важное условие. Для небольшой выборки проведите слепую ручную проверку: оценщик не должен знать, какой вариант выдачи использован. Автоматический судья может ускорить первичный просмотр, но его оценки тоже требуют проверки на случайной подвыборке.
Метрики контекстной точности, такие как context precision в Ragas, помогают оценить, насколько высоко в контексте расположены релевантные фрагменты. Это не доказательство фактической правильности ответа. Отдельно проверяйте случаи, когда генератор уверенно отвечает, хотя нужных сведений в retrieved-контексте нет.
Измерьте задержку и стоимость полного сценария
Cross-encoder оценивает пары «запрос — кандидат», поэтому цена reranking зависит от числа кандидатов и длины текстов. Сравнивайте не только среднее время, но и p50/p95 задержки на том же оборудовании и при одинаковой конкуренции запросов. Зафиксируйте размер батча, длину фрагментов, число кандидатов и наличие ускорителя.
Измерьте весь путь: поиск, reranking, сбор контекста и генерацию. Ускорение одного этапа может не дать заметного выигрыша пользователю, если основное время занимает генерация. Если reranker работает как внешний API, учитывайте цену вызовов и ограничения по пакетной обработке; сверяйте их с действующей документацией провайдера.
Практический компромисс — сначала получить, например, 50 кандидатов, затем rerank и передать генератору верхние 5–10. Это лишь стартовая настройка, а не универсальная рекомендация: проверьте несколько значений k на своём наборе, поскольку длинный контекст тоже имеет стоимость и способен добавить нерелевантные сведения.
Разберите ошибки по типам
После расчёта метрик просмотрите запросы, где новая модель ухудшила выдачу. Частые причины — короткие неоднозначные запросы, редкие термины, русский и английский в одном фрагменте, таблицы, длинные чанки или документы, где ответ выражен иначе, чем в вопросе.
Разделите ошибки по источнику:
- нужного документа не было среди кандидатов — проблема первичного поиска или корпуса;
- документ был, но reranker опустил его — проблема ранжирования или доменного соответствия;
- релевантный фрагмент поднялся, но ответ стал хуже — проверьте сбор контекста и генерацию;
- метрики выросли, а пользователи не видят разницы — возможно, тестовые запросы не отражают реальные сценарии.
Такая классификация помогает не лечить reranker изменением чанкинга или промпта и наоборот.
Когда оставлять reranker в системе
Оставляйте его, если улучшение на отложенных запросах устойчиво, особенно в верхних позициях, а ответы становятся полезнее без неприемлемого роста p95 и стоимости. Не принимайте решение по одной агрегированной метрике: проверьте срезы по языку, типу запроса и источнику документов.
Перед внедрением сохраните тестовый набор и повторяйте измерение после обновления модели, индекса, чанкинга или retrieval-конфигурации. Зафиксируйте случаи, где система обязана воздержаться от ответа. Тогда reranker оценивается не как абстрактный «умный фильтр», а как конкретное изменение поведения вашего RAG.
Минимальный следующий шаг: возьмите десятки реальных запросов, соберите общий пул кандидатов, разметьте релевантность и сравните исходный поиск с двумя моделями на MRR, nDCG@k, ручной проверке ответов и p95 задержке. Если нужные документы не попадают в пул, сначала улучшайте retrieval — reranker эту границу не преодолеет.
