Reranking в RAG: зачем второй этап поиска меняет качество ответа

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

Материал отвечает на long-tail вопрос об архитектуре. Широкая RAG-задача описана на странице RAG-систем. Критерии ниже можно использовать в архитектурном брифе, но эта статья не заменяет коммерческий landing page.

Проблема: первый поиск оптимизирует recall, а не финальные доказательства

Первый retriever должен быстро искать по разрешённому корпусу на каждом запросе. BM25, vector search, hybrid fusion или встроенный индекс базы часто возвращают десятки или сотни кандидатов. Это нормально для recall: релевантный passage должен пережить первый этап, даже если он не оказался первым.

У модели ответа другое ограничение. Её контекст конечен, нерелевантные passages размывают инструкцию, а правдоподобный текст из неверного источника может дать уверенный, но неподтверждённый ответ. Поэтому брать первые k кандидатов без проверки — это не нейтральный выбор, а неявная policy. Второй этап оценивает запрос и каждый кандидат вместе, после чего оставляет меньший evidence set для synthesis.

Reranking имеет смысл оценивать только после базовых контрактов:

• trusted request scope: tenant, role, locale, product и lifecycle источника;
• identity, версия и стабильный locator для каждого кандидата;
• first-stage search с достаточным recall на representative questions;
• явный no-answer или review route при недостаточном evidence.

Без этих условий reranker может лишь убедительнее ранжировать неправильный corpus.

Двухэтапная архитектура: retrieval кандидатов и selection доказательств

Ниже — минимальная схема RERANK-7. Это архитектурный пример, а не заявление о конкретном vendor или универсальном score threshold.

REQUEST -> trusted scope -> retrieve N eligible candidates
        -> normalize + deduplicate passage versions
        -> rerank query x candidate with pinned model/config
        -> diversity + source/evidence checks
        -> select K passages with locators
        -> answer with citations | no-answer | review

Первый этап может быть lexical, semantic или hybrid. Его результат обязан сохранить first-stage score и retrieval lane, но эти значения не являются финальным решением о релевантности. Reranker получает нормализованный запрос, текст кандидата, разрешённые metadata источника и версию модели/конфигурации. Он сортирует только уже разрешённых кандидатов.

Selection остаётся policy-решением. Например, три первых результата из одного устаревшего документа могут быть хуже двух актуальных passages из разных разделов. Production selector может требовать lifecycle current, разнообразие источников, ограничивать дублирующиеся chunks и отклонять высокий score без locator.

Ключевые компоненты и их контракты

Request scope и eligibility источников

Авторизация должна работать до retrieval и до reranking. Запрос не даёт право искать между tenants. Соберите deterministic eligibility filter из authenticated identity и source metadata, примените его в первом поиске и сохраните для второго этапа. Логирование готового ответа не заменяет предотвращение forbidden candidate в наборе для scoring.

Candidate record

Полезный candidate record — это не только текст. Ему нужны sourceId, immutable sourceVersion, locator, lifecycle, locale, access attributes, first-stage rank и content hash. Hash помогает удалить дубликаты passage versions до того, как reranker многократно поднимет их в выдаче. Locator делает финальную citation проверяемой.

Конфигурация reranker

Зафиксируйте версию модели или алгоритма, preprocessing contract, requested N, selected K и правило нормализации score. При смене модели сравните representative evaluation set до незаметного изменения поведения ответов. Scores разных версий не обязаны быть сравнимыми; версию нужно сохранять в request trace.

Evidence selector

Selector превращает ranking в разрешённый context. Он владеет deterministic rules, которые не должны зависеть от вероятностного score: lifecycle, source diversity, максимум passages на документ, token budget, доступность citation и минимальное evidence condition. Он должен уметь вернуть меньше K фрагментов или ни одного.

Оригинальное доказательство: минимальный reranking contract

Этот псевдокод показывает границу так, чтобы её можно было проверить в репозитории или test harness.

const scope = deriveTrustedScope(request.identity, request.locale);
const candidates = retrieve({ query, scope, limit: 60 });
const eligible = deduplicate(candidates).filter(isCurrentAndCitable);
const ranked = rerank({ query, candidates: eligible, model: "pinned-reranker-v7" });
const evidence = selectDiverse(ranked, { limit: 6, maxPerSource: 2, requireLocator: true });

if (!hasSufficientEvidence(evidence, query)) return routeToNoAnswerOrReview();
return answerWithCitations({ query, evidence, trace: { scope, ranked } });

60 и 6 здесь не являются универсальными настройками. Это явные параметры эксперимента. Для реальной системы стоит проверять глубину candidates, selected depth, latency, diversity источников, citation coverage и число безопасных no-answer decisions на собственном task set.

Ошибки, которые reranking не должен скрывать

Релевантный passage не попал в candidate set

Reranking не поднимет passage, который пропустил first-stage retrieval. Отдельно проверяйте recall на exact IDs, paraphrases, multilingual cases, обновлениях документов и permission-limited queries. Рост N может улучшить recall, но меняет стоимость и latency; это нужно тестировать, а не считать автоматически безопасным.

Дубликаты chunks захватывают контекст

Несколько overlap chunks одного документа могут получить похожие высокие scores. Deduplicate по source version и semantic span до scoring или ограничивайте их в selector. Проверяйте diversity источников в evaluation output, а не только aggregate relevance.

Устаревший или запрещённый документ получает высокий score

Высокая semantic relevance не отменяет access или lifecycle. Применяйте deterministic filters до reranker, перепроверяйте перед synthesis и включайте denied-path tests. Fail closed, если filter configuration недоступна или source version кандидата нельзя подтвердить.

Изменение score принимают за улучшение качества

Новый reranker может изменить шкалу scores и ухудшить выбранный evidence. Сравнивайте фиксированные test cases с human-reviewed relevance labels и citation checks. Храните version, release date, revision evaluation dataset и rollback path. Красивое распределение scores не доказывает production improvement.

Latency или provider failure незаметно меняет ответ

Определите degraded behavior до incident. Система может перейти на проверенный first-stage-only mode, отправить запрос на review или вернуть no-answer. Выбор зависит от последствия плохого ответа. Не обходите reranker молча, если acceptance criteria требуют его работы.

Тестирование: измеряйте решения, а не только output модели

Начните с небольшого поддерживаемого evaluation set: обычные вопросы, exact identifiers, paraphrases, ambiguous requests, устаревшие факты, denied-access queries, no-answer cases и недавно изменённые документы. Для каждого case сохраните source version и expected evidence condition.

Оценивайте этапы раздельно. First-stage retrieval отвечает, попал ли нужный source в candidate set. Reranking — вышли ли наиболее полезные eligible passages в selected context. Финальный ответ — остался ли он привязан к этим passages, сохранил ли uncertainty и показал ли citations. Один final-answer metric не укажет на сломанную границу.

Production-check до rollout

Сначала проведите bounded pilot, а не переключайте весь user traffic. Сохраняйте request-safe traces: scope, candidate IDs, source versions, ranks, reranker configuration, selected evidence и final route. Redact query или document content там, где лог не должен хранить их. Release gate обязан включать functional и safety cases.

require(scope.isTrusted && retrieval.configVersion)
require(candidate.sourceVersion && candidate.locator)
require(policy.allows(candidate, scope))
require(evalSet.exact && evalSet.paraphrase && evalSet.denied && evalSet.noAnswer)
require(release.hasRollback && trace.redactionReviewed)

if (!evidence.isSufficient) route = "no-answer-or-review"
if (reranker.failed && !degradedMode.wasEvaluated) route = "fail-closed"

В этом check нет универсального score threshold намеренно. Threshold имеет смысл только вместе с domain, source set, acceptance set и стоимостью ошибки. Более честное production-утверждение: reranking change имеет явный scope, traceable evidence, проверенное failure behavior и rollback route.

Место reranking в AI engineering brief

Reranking — component decision, а не самостоятельный business outcome. Для архитектурного ревью подготовьте representative queries, типы документов, access rules, update cadence, последствия ответа и evidence первого поиска. Тогда можно решить, оправдан ли второй этап, какие tests нужны и какие ответы должны остаться на human review.

За более широким delivery evidence перейдите к кейсам. Следующие темы retrieval-серии разберут citations и traceability; до этого reranking output должен оставаться подчинённым source lineage и видимому evidence.