Reranking в RAG для русских документов: как проверить качество

Короткий ответ: оценивайте порядок, а не обещание модели

Reranking — это повторное упорядочивание уже найденных фрагментов. Сначала retrieval возвращает, например, десять кандидатов по векторному или гибридному поиску, затем отдельный ранжирующий шаг выбирает те, которые лучше соответствуют вопросу. Для русского корпуса особенно важно не путать совпадение слов с полезностью ответа: в документах встречаются сокращения, падежи, названия продуктов и почти одинаковые формулировки. Поэтому проверка начинается не с подключения нового API, а с перечня реальных задач: найти регламент, назвать срок, объяснить условие или указать источник.

Создайте небольшой набор из 30–80 обезличенных вопросов и заранее отметьте фрагменты, которые редактор считает достаточными. Для каждого вопроса зафиксируйте исходный top-k, порядок после reranking и решение проверяющего. Сравнивайте не только среднюю метрику, но и опасные случаи: корректный фрагмент ушёл ниже порога, похожий документ занял первое место, ссылка ведёт на устаревшую редакцию. Такой журнал даёт команде основание выбрать порог и rollback, а не выдавать разовый удачный ответ за постоянное свойство модели.

Подготовьте корпус и тестовый набор без лишних данных

Перед экспериментом уберите из fixtures клиентские идентификаторы, полные запросы пользователей, секреты, приватные URL и файлы, которые не нужны для оценки. Оставьте стабильный document_id, версию документа, короткий безопасный текстовый фрагмент и метку доступа. Если документ нельзя поместить в тестовую среду, создайте синтетический аналог с тем же типом неоднозначности. Это помогает проверить морфологию, длинные заголовки и конфликтующие версии, не превращая RAG-оценку в канал передачи данных.

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

Сравнивайте baseline и reranking по одинаковому контракту

Запускайте baseline и вариант с reranking с одинаковыми фильтрами tenant, прав доступа, языком, top-k и дедлайном. Если вместе с reranking меняются chunking, embedding или prompt, нельзя понять, какой компонент дал эффект. Удобный минимум — таблица с question_id, списком document_id до и после, позицией ожидаемого фрагмента, временем выполнения и пометкой reviewer. Метрики вроде Recall@k и MRR полезны как ориентир, но их нельзя выдавать за гарантию качества каждого будущего ответа.

Проверьте стоимость и задержку в пределах своего теста, не подставляя универсальные цены. Дополнительный ранжирующий вызов может быть оправдан для сложных юридических или технических запросов, но избыточен для коротких точных FAQ. Разделите маршруты по типу вопроса и задайте budget: например, сначала быстрый поиск, а reranking — только при низкой уверенности или нескольких близких кандидатах. При ошибке, timeout или неподтверждённой возможности каталога безопасный путь — вернуть исходный результат с явной отметкой, а не молча менять состав источников.

Проверьте источники до генерации ответа

После ранжирования не передавайте первые фрагменты напрямую в финальный prompt без контроля. Сверьте tenant, ACL, версию документа и дату действия каждого кандидата. Если в top-k присутствуют две редакции одного регламента, приложению нужна явная политика: предпочесть действующую версию, показать дату или остановить ответ при конфликте. Reranker не подтверждает право доступа и не является источником истины; он только помогает упорядочить то, что уже разрешено искать.

Полезно хранить компактное доказательство ответа: question_id, выбранные document_id, версии, позиции и результат ручной оценки. Не сохраняйте весь prompt или текст документа ради наблюдаемости. По этим метаданным можно воспроизвести спорный случай, найти деградацию после обновления индекса и откатить маршрут. Для публичного интерфейса показывайте пользователю название и ссылку лишь тогда, когда ваша система действительно может выдать этот источник и права доступа это позволяют. Придуманная или недоступная ссылка хуже честного ответа «источник не подтверждён».

Запускайте постепенно и заранее определите rollback

Сначала включите reranking для тестового проекта или небольшой доли безопасных внутренних запросов. Наблюдайте долю вопросов с найденным подтверждённым источником, время ответа, ошибки интеграции и число ручных исправлений. Не сравнивайте произвольные периоды: держите фиксированный набор контрольных запросов и повторяйте его после обновления индекса, маршрута или модели. Если метрики ухудшились, не спорьте с единичными примерами — отключите feature flag и вернитесь к зафиксированному baseline.

В RussiaAPI создавайте только собственный ключ для server-side теста и сверяйте текущий каталог до подключения конкретной возможности. Продукт не обещает наличие отдельного reranker, одинаковую семантику параметров или постоянную цену. Архитектура должна позволять заменить компонент, не раскрывая секрет в браузере и не отправляя внешние ключи. Такой подход превращает reranking из маркетингового термина в проверяемый эксперимент: команда видит, где порядок документов помогает, а где нужен другой индекс, ручная разметка или честное ограничение ответа.

Server-side пример

Пример показывает локальную проверку на сервере. Ключи берутся только из окружения; до запуска подтвердите маршрут, model ID и параметры в текущем каталоге RussiaAPI.

export function compareRankings({ questionId, baseline, reranked, expectedId }) {
  const position = (items) => items.findIndex((item) => item.document_id === expectedId) + 1;
  return {
    questionId,
    baselinePosition: position(baseline),
    rerankedPosition: position(reranked),
    selected: reranked.filter((item) => item.access === 'allowed').slice(0, 5).map((item) => item.document_id),
  };
}
// Call a documented RussiaAPI route only from your server; do not put any API key in a browser bundle.

Проверьте синтаксис через node --check, добавьте аутентификацию своего маршрута и негативные тесты. Не логируйте тело запроса или заголовки только ради отладки.