В этом материале
RRF объединяет ранжированные списки дочерних поисков, а linear retrieval нормализует и взвешивает их баллы в явно заданной конфигурации конкретной версии.
RRF и linear retriever в Elasticsearch объединяют сигналы по разным контрактам: позиции против нормализованных взвешенных баллов. Сравнивайте механизмы при одинаковых дочерних поисках, прежде чем считать любую из конфигураций общим улучшением hybrid search.
Явно назвать правило объединения
Справочник RRF retriever описывает слияние рангов дочерних результатов. Исходная величина балла предоставляет другую информацию, чем позиция. Linear retriever, напротив, нормализует и взвешивает баллы ветвей. Большой разрыв способен влиять на такое вычисление даже при неизменном порядке. Ни один механизм не восстанавливает доказательство, которое не попало в окно результатов дочернего поиска. Эту границу следует показывать в сравнении, а не скрывать одним итоговым числом.
Разделить окна и размер ответа
Окно дочерней выдачи и размер финального ответа являются разными ограничениями. Сохраняйте оба вместе с настройками плотных кандидатов. Руководство kNN определяет векторный этап, поставляющий одну ветвь. Увеличение его популяции одновременно с изменением fusion смешивает два решения. Экспортируйте идентификаторы и баллы ветвей: тогда возвращение документа можно связать с формированием кандидатов либо конечным объединением, а не приписывать любой удачный результат новому названию алгоритма.
Определить нормализацию до весов
Текущий справочник linear описывает нормализаторы ветвей и зависящее от версии наследование верхнего normalizer. Проверяйте установленный выпуск: одинаковый запрос не обязан иметь тот же смысл во всех версиях. Вес ненормализованного лексического балла способен подавить другую ветвь из-за масштаба величин. Это ещё не доказательство настоящей полезности лексического поиска для данного класса вопросов. Сначала установите обработку баллов, затем выбирайте обоснованный баланс сигналов.
| Выбор слияния | Основная сохраняемая информация |
|---|---|
| RRF | Позиции в дочерних выдачах |
| Linear с нормализацией | Нормализованные величины и веса |
| Изменение окна кандидатов | Доступность доказательства для fusion |
Создать набор расхождений
Подготовьте учебные вопросы с точными кодами ошибок и перефразированными описаниями. Добавьте случай явного лексического лидера и случай близких верхних баллов. Разметьте фрагменты по источникам до настройки. Фильтры должны совпадать; проверьте их применение к каждой дочерней ветви. Иначе внешне улучшенная выдача может включить документы вне нужной допустимой популяции и решить другую задачу, для которой исходная разметка уже не является корректным эталоном.
Разобрать проигравшие случаи
Даже при росте средней релевантности сохраните ухудшившиеся примеры. Определите, отсутствовал ли нужный фрагмент, иначе ли нормализовался или был перевешен при объединении. Финальный hybrid-балл не является независимой от корпуса вероятностью: его масштаб и смысл зависят от конфигурации поиска. Поэтому перенос порога другого индекса требует собственной размеченной проверки, а не автоматического повторения числа, которое когда-то работало в иной коллекции документов.
Сохранить границы API и возможностей
До публикации исполняемого запроса запишите версию сервера, поддерживаемый синтаксис и предпосылки доступности функций. Документация текущего API не подтверждает каждую старую установку или лицензионную конфигурацию. Храните проверочный набор с запросами, окнами, normalizer и весами. Обоснованный результат указывает реализацию, улучшившую определённые задачи доказательств, вместе с оставшимися ошибками. Он не объявляет единственный алгоритм слияния лучшим для любого корпуса и любого распределения запросов.
Связанные материалы: Локальный RAG-сервер: какие компоненты размещать рядом с GPU; Reranker в RAG: сколько документов передавать на повторную оценку.