Reranker для RAG может поднять релевантный документ выше в выдаче, но сам факт переупорядочивания ещё не означает, что ответы системы станут лучше. Проверить это можно на небольшом наборе реальных запросов: разметить, какие фрагменты действительно отвечают на каждый запрос, сравнить ранжирование до и после reranker и отдельно измерить задержку. Такой тест покажет, улучшает ли дополнительный этап поиск именно в вашей коллекции, а не на чужом бенчмарке.
Что именно меняет reranker в RAG-поиске
Типичный поиск сначала быстро отбирает кандидатов — например, по векторному сходству, ключевым словам или их сочетанию. Затем reranker оценивает пары «запрос — документ» и переставляет найденные фрагменты по релевантности. В отличие от биэнкодера, который заранее вычисляет векторы запросов и документов, кросс-энкодер может совместно обработать текст запроса и кандидата. Это часто позволяет точнее оценивать конкретную пару, но вычисление для каждого кандидата обходится дороже.
Важное ограничение: reranker обычно сортирует уже найденные документы, а не ищет по всей базе заново. Если нужного фрагмента нет среди кандидатов, перестановка его не вернёт. Поэтому тест должен разделять два вопроса:
Находит ли первичный поиск нужные документы в достаточно широком пуле?
Поднимает ли reranker правильные документы в верх выдачи?
В документации Cohere описан rerank API, принимающий запрос и список текстовых документов и возвращающий их с оценками и новым порядком. Sentence Transformers показывает аналогичное применение CrossEncoder для переоценки результатов поиска. Это описание механики, а не обещание улучшения на любой коллекции.
Как собрать небольшой тестовый набор
Начните не с синтетических формулировок, а с запросов, которые реально задают пользователи: из логов поиска, тикетов поддержки или внутренних сценариев. Удалите персональные данные и секреты. Если логов пока нет, составьте набор из типовых задач, но включите разные способы задавать один вопрос.
Для первичной проверки обычно достаточно нескольких десятков запросов, если их можно тщательно разметить; для устойчивых выводов потребуется больше. Важнее не конкретное число, а покрытие разных случаев: точные названия, редкие термины, естественные вопросы, запросы с несколькими условиями и вопросы, на которые в базе нет ответа.
Для каждого запроса сохраните:
- исходную формулировку;
- список релевантных документов или фрагментов;
- степень релевантности, если она бывает частичной;
- ожидаемый ответ или ключевые факты, которые документы должны подтверждать;
- признак «ответа в коллекции нет», если применимо.
Разметку стоит проверять хотя бы вторым человеком на части набора. Несогласие разметчиков не просто шум: оно может означать, что критерий релевантности не определён. Например, для вопроса о лимите API документ с текущим значением может быть релевантен, а старая версия документа — нет, даже если совпадение слов высокое.
Сравните две выдачи на одинаковых условиях
Снимите результаты базового поиска и поиска с reranker на одном и том же наборе запросов. Зафиксируйте версию корпуса, параметры первичного поиска, число кандидатов и размер финальной выдачи. Если менять несколько параметров одновременно, станет непонятно, что повлияло на результат.
Простейший протокол:
Первичный поиск возвращает, например, 20 кандидатов.
Базовый вариант берёт первые 5 по исходному рангу.
3. Вариант с reranker оценивает те же 20 и берёт первые 5 после переупорядочивания.
4. Для обоих вариантов рассчитываются одинаковые метрики.
5. Повторите прогон для нескольких размеров пула кандидатов — например, 10, 20 и 50, если это укладывается в ваш бюджет.
Числа здесь — параметры эксперимента, а не универсальные рекомендации. Если у вас короткие документы и маленький корпус, широкий пул может не дать пользы. Для длинных или похожих друг на друга фрагментов он может быть важнее. Сравнение должно отражать реальную конфигурацию приложения.
Какие метрики показывают результат
Recall@k отвечает на вопрос: попал ли хотя бы один релевантный документ в первые *k* результатов? Если каждый запрос имеет несколько релевантных фрагментов, можно также считать долю найденных релевантных документов среди всех размеченных. Укажите, какой именно вариант Recall используете: обозначение без определения легко трактовать по-разному.
MRR (Mean Reciprocal Rank) учитывает позицию первого релевантного результата. Если правильный документ стоит первым, вклад запроса равен 1; если на третьем месте — 1/3; если его нет в выдаче — 0. Метрика полезна, когда пользователю достаточно быстро увидеть один подходящий источник.
nDCG@k подходит, когда релевантность бывает градуированной, например «полностью отвечает», «частично помогает» и «не относится к вопросу». В отличие от бинарной оценки, она учитывает степень полезности и позицию результата.
Не выбирайте одну метрику для всех сценариев. Для поиска, где важен хотя бы один подтверждающий фрагмент, полезен Recall@k. Для короткой выдачи, которую просматривают сверху вниз, важны MRR или nDCG@k. Отчёт должен показывать метрики по отдельным типам запросов: среднее значение может скрыть ухудшение на редких, но критичных темах.
Воспроизводимый пример вычисления MRR
Допустим, в тесте три запроса. Первый релевантный документ после базового поиска стоит на позициях 1, 3 и отсутствует в топ-5. Reciprocal rank для запросов составит 1, 1/3 и 0, а MRR — примерно 0,44.
После reranker позиции стали 2, 1 и 4. Значения равны 1/2, 1 и 1/4; среднее — примерно 0,58. Это улучшение ранга на данном маленьком наборе, но не доказательство, что система в целом стала лучше. При малом числе запросов результат особенно чувствителен к одному случаю.
Для воспроизводимости сохраните идентификаторы документов, исходные и новые позиции, оценки reranker и версии моделей. Простая таблица или CSV позволят перепроверить метрики и разобрать конкретные перестановки. Не сравнивайте только агрегированное число: выясните, какие запросы выиграли, какие проиграли и почему.
Проверьте ошибки, а не только среднее значение
Возьмите случаи, где reranker изменил верх выдачи, и вручную просмотрите их. Полезно разделить ошибки на несколько типов:
- нужный документ отсутствовал среди кандидатов;
- подходящий фрагмент был, но reranker опустил его;
- нерелевантный документ поднялся из-за совпадающих терминов;
- фрагмент релевантен отдельно, но не содержит достаточного контекста для ответа;
- несколько почти одинаковых фрагментов заняли места, которые могли бы получить разные источники.
Первый тип указывает на проблему первичного поиска или индекса, а не на модель переупорядочивания. В остальных случаях стоит проверить качество текста, разбиение документов на фрагменты, язык запросов и документов, а также соответствие модели вашей области. Кросс-энкодер оценивает релевантность текста, но не гарантирует истинность утверждения и не проверяет актуальность документа автоматически.
BEIR полезен как напоминание о разнообразии задач и корпусов в оценке поиска: результат на одном наборе не переносится сам собой на другую область. Используйте внешние бенчмарки для предварительного отбора кандидатов, но решение принимайте по собственному набору.
Измерьте задержку и стоимость вместе с качеством
Reranker добавляет вычисления после первичного поиска. Для API-модели зафиксируйте время ответа, число документов на входе и применимые тарифы; для локальной модели — оборудование, размер пакета, загрузку и задержку. Сравнивайте не только среднее время: p95 покажет, насколько медленно проходит большая часть запросов в хвосте распределения.
Проведите замеры на тех же запросах и при одинаковой нагрузке. Отдельно измерьте этап reranking и полное время поиска. Если система использует кэш или пакетную обработку, протестируйте и соответствующий рабочий режим: одиночный вызов не всегда отражает поведение в эксплуатации.
Решение можно принять по заранее установленному порогу: например, внедрять reranker, только если он улучшает выбранную метрику на важных запросах и укладывается в лимит задержки. Сам порог зависит от продукта. Для внутреннего инструмента допустимы одни компромиссы, для интерактивного поиска с жёстким SLA — другие.
Когда reranker не поможет
Если правильного материала нет в индексе, он устарел или разбит на бессмысленные фрагменты, переупорядочивание не устранит причину. Проверьте полноту индекса, метаданные и обработку обновлений. Для точных идентификаторов, кодов ошибок и редких названий добавьте тесты, где лексический поиск может быть сильнее векторного.
Ещё один риск — подгонка под тестовый набор. Если постоянно менять параметры, ориентируясь на одни и те же запросы, итоговая конфигурация может хорошо работать только на них. Разделите набор на отладочную и отложенную части; после выбора настроек оцените результат на запросах, которые не использовались при настройке. Для небольших коллекций используйте повторную разметку и осторожно трактуйте небольшие различия.
Чек-лист перед включением в рабочий RAG
Перед развёртыванием убедитесь, что:
- базовый поиск действительно находит нужные документы в достаточно широком пуле;
- тестовые запросы отражают реальные задачи и включают отсутствие ответа;
- релевантность размечена по ясным правилам;
- сравниваются одинаковые кандидаты и одинаковый размер финальной выдачи;
- метрики определены, а ошибки проверены вручную;
- замерены задержка и стоимость на рабочей конфигурации;
- результат подтверждён на отложенных запросах;
- изменение индекса, модели или корпуса запускает повторную проверку.
Начните с небольшого офлайн-теста и сохраните исходные результаты. Если выигрыш заметен только на отдельных типах запросов, можно применять reranker выборочно или скорректировать первичный поиск. Если улучшение не воспроизводится либо достигается ценой неприемлемой задержки, добавление ещё одной модели в цепочку не решит проблему само по себе.
