Зачем второй этап

Embedding сравнивает запрос и документ через компактные представления. Reranker рассматривает их совместно или на уровне нескольких vectors и лучше различает тонкие условия. Цена - дополнительная задержка и вычисления.

Что reranker не умеет

Он переставляет только найденных кандидатов. Если нужный chunk потерян из-за chunking, фильтра или малого top-k, второй этап его не вернёт. Сначала обеспечьте candidate recall.

Cross-encoder и late interaction

Cross-encoder совместно читает query и passage и обычно точен, но дорог. Late interaction заранее хранит несколько token-level vectors и переносит часть работы в индекс. Выбор зависит от latency, corpus и инфраструктуры.

Настройка двух k

candidate_k определяет ширину первого этапа, final_k - сколько chunks попадёт дальше. Увеличение первого повышает шанс найти ответ и цену reranking; увеличение второго может засорить prompt. Делайте grid search, а не настраивайте параметры отдельно.

Threshold и отказ

Reranker score не универсальная вероятность. Калибруйте порог на своих данных и оставьте сценарий «доказательство не найдено». Порог нужно пересматривать после обновления модели или корпуса.

Дедупликация и diversity

Соседние overlapping chunks могут занять весь top. Группируйте по документу, учитывайте section diversity и при необходимости расширяйте контекст после выбора лучшего child chunk.

Latency budget

Считайте embedding запроса, оба retrievers, fusion, reranker и загрузку payload. Ограничьте длину passages, используйте batching и кэш только с корректным version key и permission scope.

Как доказать пользу

Сравните retrieval nDCG/MRR, context precision и downstream correctness. Отдельно измерьте провалы: правильный кандидат отсутствовал, reranker понизил его или LLM не использовала доказательство.

С чего начать внедрение?
С узкого сценария, измеримого baseline и набора реальных запросов. Сначала зафиксируйте качество и ограничения, затем меняйте один параметр за эксперимент.
Какие метрики считать обязательными?
Качество результата, p95 latency, ошибки, стоимость и отдельные метрики ключевого этапа. Среднее значение без сегментов и percentiles скрывает провалы.
Можно ли выбрать параметры по документации?
Документация задаёт безопасный baseline, но финальные параметры выбирают по собственному корпусу, нагрузке и eval-набору.
Как обновлять систему без риска?
Версионировать конфигурацию, запускать shadow-сравнение, затем canary и иметь заранее проверенный rollback target.
Почему нужен набор отрицательных примеров?
Он показывает, умеет ли система отказываться и не поднимать нерелевантные результаты только потому, что они ближайшие среди доступных.
Что сохранять для расследования?
Версии компонентов, trace ID, параметры запроса, IDs доказательств, решения фильтров и агрегированные метрики с соблюдением правил доступа и retention.
← Все статьи блога