Что такое реранкинг и как он работает в RAG

Зачем оценивать найденное ещё раз

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

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

Как порядок инструкций влияет на материалы для ответа

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

Как забронировать переговорную на субботу?

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

Будни

Для бронирования переговорной с понедельника по пятницу выберите свободное время во внутреннем календаре.

Отмена брони

Чтобы отменить бронирование переговорной, удалите свою запись из внутреннего календаря.

Выходные

Если переговорная нужна в субботу или воскресенье, отправьте заявку администратору: укажите дату и время встречи.

Подготовка комнаты

Перед встречей в переговорной проверьте, что пульт от экрана лежит на столе.

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

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

Для наглядности зададим простое условие: в каждом из двух вариантов приложение передаёт модели только первую инструкцию из списка. Это правило нашего примера, а не рекомендация передавать ровно один отрывок в реальной системе.

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

Как забронировать переговорную на субботу?

Те же четыре найденные инструкции. Меняется порядок.

Правило отбора: приложение передаёт модели первую инструкцию.

Исходный порядок

1. Буднивыбрана
2. Отмена брони
3. Выходные
4. Подготовка комнаты

Модель получает с тем же вопросом:

Для бронирования переговорной с понедельника по пятницу выберите свободное время во внутреннем календаре.

В тексте нет правила для выходных.

Возможный порядок после оценки

1. Выходныевыбрана
2. Будни
3. Отмена брони
4. Подготовка комнаты

Модель получает с тем же вопросом:

Если переговорная нужна в субботу или воскресенье, отправьте заявку администратору: укажите дату и время встречи.

В тексте есть правило для выходных.

Что изменилось между вариантами

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

Материалы, которые приложение фактически передаёт модели для ответа, здесь называем контекстом. В нашем сравнении изменился состав контекста, хотя набор найденных отрывков остался прежним.

Реранкер оценил соответствие текстов вопросу. Приложение выбрало материал. Языковой модели ещё предстоит составить ответ по вопросу и полученной инструкции. Подходящая инструкция даёт ей нужные сведения, но правильность ответа всё равно нужно проверять. Сам реранкер не отправляет заявку и не проверяет, свободна ли комната.

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

Когда перестановки недостаточно

Нужная инструкция не попала в найденный список

Представим, что поиск вернул инструкции для будней, отмены брони и подготовки комнаты. Текста про выходные среди них нет.

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

Из полученного текста исчезло существенное условие

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

Исходный текст:

Если переговорная нужна в субботу или воскресенье, отправьте заявку администратору: укажите дату и время встречи.

Текст, который получила система:

Отправьте заявку администратору: укажите дату и время встречи.

Вопрос остался прежним: «Как забронировать переговорную на субботу?» Суббота из него никуда не исчезла. Потерялась связь между обращением к администратору и применением этого правила в выходные.

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

Такая потеря возможна при делении документов на фрагменты. Для повторной оценки важен текст, который фактически дошёл до реранкера, и то, сохранились ли в нём существенные условия.

Что подтверждает высокая оценка

Реранкер может поставить инструкции высокую оценку, если сочтёт её подходящей к вопросу. Но здесь остаются три отдельных вопроса:

• Подходит ли текст к запросу? Инструкция про выходные относится к бронированию на субботу.
• Верна ли сама инструкция? Действительно ли в этой организации нужно обращаться к администратору?
• Правильно ли составлен ответ? Передала ли языковая модель содержание инструкции без ошибки?

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

Как понять, нужен ли реранкинг

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

Для этого сравнивают работу с дополнительной оценкой и без неё на реальных вопросах. Смотрят, стали ли в отбор чаще попадать подходящие материалы, затем отдельно проверяют ответы. Чтобы понять вклад именно реранкинга, остальные условия сравнения сохраняют одинаковыми.

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

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

Технические подробности: устройство, настройки и проверка

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

Как выполняют повторную оценку

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

Модель, которая независимо обрабатывает вопрос и документы, называют bi-encoder. Представления документов можно подготовить заранее и использовать для разных вопросов. Такой способ поиска описан в документации Sentence Transformers.

При повторной оценке можно использовать модель, которая получает вопрос и найденный фрагмент вместе. Она совместно обрабатывает эту пару и оценивает соответствие, учитывая связи между частями обоих текстов. Такая модель называется cross-encoder.

Для нового вопроса пары нужно оценить заново. Выполнять это для всей большой коллекции документов затратно, поэтому совместную оценку часто применяют к ограниченному списку, полученному поиском. Различие способов обработки раскрыто в документации Cross-Encoder.

Cross-encoder — распространённая реализация реранкера, но не единственная. Есть модели, которые оценивают несколько найденных текстов совместно. А для небольшого набора текстов совместную оценку можно применять сразу, без предварительного поиска. Конкретное устройство модели не гарантирует, что она учтёт нужное условие лучше другой.

Отдельно стоит различать повторную оценку и объединение результатов нескольких поисков. Например, приложение может получить один список по совпадениям слов, другой — по смысловой близости. Объединение сводит их в общий список; последующая модельная оценка заново определяет соответствие его элементов вопросу. В Azure AI Search эти действия разделены, но устройство этого сервиса не является обязательной схемой для всех приложений.

Что возвращает реранкер и как выбирать материалы

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

Например, Rerank API Cohere принимает вопрос и список текстов, а возвращает упорядоченные результаты с оценками и индексами исходных элементов. Индекс указывает на элемент первоначального списка: по нему приложение связывает оценку с нужным текстом.

Здесь нужно различать три величины:

1. Сколько кандидатов передано на оценку. Это набор, с которым работает реранкер.
2. Сколько результатов возвращено. Интерфейс может вернуть только часть списка. В приведённом API Cohere параметр top_n ограничивает именно количество возвращаемых результатов.
3. Сколько текста передано модели для ответа. Приложение решает, какие результаты использовать и какой объём материалов включить в контекст.

Число фрагментов не определяет их суммарную длину. Поэтому top_n сам по себе не задаёт объём текста в контексте: одинаковое количество результатов может содержать разное количество текста. Единого рекомендуемого числа фрагментов из этого также не следует.

Как понимать оценку и выбирать порог

Числовую оценку соответствия текста вопросу называют score, или оценкой релевантности. Здесь релевантность означает, насколько текст подходит к запросу по оценке модели.

Значение 0,8 не означает 80% вероятности истинного ответа. Это число относится к оценке текста для ранжирования — расположения результатов в порядке приоритета.

У реализаций различаются шкалы и способы получения оценок. Например, semantic ranker в Azure AI Search использует шкалу от 0 до 4. Даже если два других интерфейса возвращают числа от 0 до 1, одинаковый диапазон ещё не делает оценки сопоставимыми.

В рекомендациях Cohere также отмечено, что оценка зависит от вопроса и переданных текстов. Универсального правила «всё выше 0,8 подходит» нет.

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

Что происходит с длинными текстами

Часть документа может не попасть на оценку из-за ограничения длины. Лимиты и поведение при их превышении зависят от модели и интерфейса; это видно в рекомендациях Cohere по обработке длинных документов.

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

Где работает реранкер и кто получает тексты

Реранкер может быть внешним сервисом или моделью, запущенной на выбранном сервере.

При прямом обращении к внешнему API приложение отправляет вопрос и включённые в запрос тексты. Такой вход описан в документации Cohere. Отправка этих материалов сама по себе не означает, что сервису открыт доступ ко всей базе знаний.

Другой вариант — загрузить модель и выполнять оценку в выбранном окружении. Пример загрузки и запуска есть в карточке Qwen3-Reranker. При этом название провайдера не определяет единственный способ размещения: Cohere, например, описывает облачные и частные варианты. Доступность конкретной версии модели в нужном окружении проверяют отдельно.

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

Право пользователя видеть документ также проверяется отдельно. Высокая оценка соответствия вопросу не даёт такого права. Например, Microsoft описывает фильтрацию поисковых результатов по доступу; реранкинг её не заменяет.

У скачиваемых моделей различаются условия использования. Это видно, например, при сопоставлении карточки Qwen3-Reranker и карточки Jina. Возможность скачать модель не означает одинаковых разрешений на её применение: условия относятся к выбранной модели и версии.

Как проверить вклад реранкинга

Чтобы выяснить, что дала именно повторная оценка, сравнивают исходный и новый порядок в одинаковых условиях.

1. Подберите вопросы к своей базе. Включите обычные и неоднозначные формулировки. Для каждого вопроса вручную отметьте подходящие материалы и, если нужно, степень их соответствия. Эти отметки называют разметкой: с ними будут сравниваться результаты системы.
2. Сохраните реальные результаты поиска. Нужны тексты кандидатов, их исходный порядок и обозначения, по которым можно различить эти тексты. Если поиск пропустил полезный документ, нельзя незаметно добавить его в набор для сравнения.
3. Получите повторную оценку того же набора. Используйте те же вопросы и ту же разметку. Зафиксируйте версии моделей и настройки, чтобы было понятно, какие варианты сравниваются.
4. Одинаково собирайте контекст. Сохраните правило отбора и предел объёма текста. Если отбор ограничен числом первых результатов, это ограничение также должно совпадать.
5. Отдельно проверьте ответы. В обоих вариантах используйте одну и ту же языковую модель и одну и ту же инструкцию для неё. Улучшение порядка найденных текстов ещё не подтверждает улучшения ответов.
6. Сопоставьте качество с затратами. Измерьте время обработки, расход вычислительных ресурсов или плату за дополнительную оценку.

Сравнение исходного и повторно упорядоченного списка предусмотрено в средствах оценки Cross-Encoder в Sentence Transformers. Для оценки собственного поиска важно сохранять фактически найденный набор кандидатов.

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

Что показывают метрики

Метрики позволяют выразить качество отбора и порядка числами относительно подготовленной разметки. Ниже три показателя из документации Elastic по оценке ранжирования.

• Recall@k — полнота отбора первых результатов. Буквой k здесь обозначено число первых результатов, которые рассматривают. Метрика показывает, какая доля всех материалов, размеченных как подходящие к вопросу, попала в этот отбор.
• MRR — показатель положения первого подходящего результата. Он учитывает обратную позицию этого результата, усреднённую по вопросам. Чем ближе первый подходящий результат к началу списка, тем больший вклад он вносит в показатель.
• nDCG — оценка порядка с учётом степени соответствия. Она учитывает, насколько каждый материал подходит к вопросу и на какой позиции находится, относительно идеального порядка по той же разметке.

Для полноты важно указать, какой набор оценивается. При перестановке состав всего найденного списка не меняется, поэтому полнота этого списка остаётся прежней. Но подходящий фрагмент может подняться в первые выбранные результаты. Поэтому recall@k этого отбора может измениться, хотя новых документов поиск не нашёл.

Все эти показатели зависят от разметки. Если она неполна, выводы тоже ограничены. Recall@k, MRR и nDCG не проверяют фактическую правильность сгенерированного ответа.

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

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