В этом материале
Normalization processor объединяет нормализованные баллы поисковых условий, тогда как score-ranker processor применяет RRF на основе позиций.
Нормализация баллов OpenSearch и reciprocal rank fusion относятся к разным конфигурациям search pipeline. До интерпретации итоговой релевантности и замены embedding-модели установите, какой процессор действительно обрабатывает выбранный гибридный запрос.
Найти этап объединения
Справочник normalization-processor помещает его работу между фазами query и fetch. Он объединяет баллы поисковых условий после нормализации величин. Это не нормализация эмбеддингов документа перед индексацией. Сохраните различие в названиях настроек и диагностике. Нормализация вектора способна изменить кандидатов, тогда как процессор баллов поисковой фазы определяет объединение уже найденных результатов ветвей. Эти вмешательства не следует описывать одним общим действием с непонятной границей.
Отличить ранги от величин
Справочник score-ranker описывает RRF на той же поисковой фазе, но с опорой на позиции. Его трактовка входа отличается от нормализации баллов, поэтому перенос весов либо порогов между схемами не является неизменным контролем. Проверенные страницы указывают появление normalization в 2.10, score-ranker — в 2.19. Это границы введения функций, а не доказательство одинаковых настроек по умолчанию и возможностей каждой актуальной установки.
Подтвердить применение pipeline
Сохраните настоящий запрос рядом с определением выбранного pipeline. Наличие именованной конфигурации на сервере не доказывает, что конкретный запрос её использовал. Для диагностики запишите фактический путь обращения и исследуйте поведение на намеренно простом наборе. Не делайте вывода об ошибке алгоритма, если запрос обошёл процессор, работа которого должна была оцениваться. В таком случае сначала исправляют исследуемую конфигурацию и только потом сравнивают релевантность полученной выдачи.
| Уровень конфигурации | Сохраняемые сведения |
|---|---|
| Условия hybrid | Порядок и настройки отдельных поисков |
| Search pipeline | Тип и параметры процессора |
| Запрос | Применённый к этому запуску pipeline |
Проверить разные масштабы ветвей
Создайте учебный запрос, где лексическая и векторная ветви возвращают частично общие документы с разными масштабами баллов. Сохраните исходные позиции и величины. Сравните нормализованную конфигурацию с RRF при прежних настройках ветвей. Документация RRF объясняет путь объединения рангов. Оценивайте полезные исходные доказательства, а не ожидайте, что отображаемые числа двух методов будут напрямую сопоставимы или означать один и тот же порог принятия результата.
Отделить нехватку кандидатов
Если нужный фрагмент отсутствует во всех ветвях, процессор его не добавит. При замене только объединения сохраняйте глубину кандидатов и фильтры. Расширение окна может помочь вопросу независимо от fusion. Ошибка порядка условий также способна назначить вес не тому сигналу. Сохраните объяснение изменившихся результатов, чтобы средняя метрика не скрыла несовпадение конфигурации и не приписала восстановленный документ алгоритму, который фактически не участвовал в обработке запроса.
Опубликовать версионный результат
Храните установленный выпуск, определение процессора, запросы проверки и разметку. Сравнивайте конечную релевантность и стоимость выполнения, не превращая пример производителя в локальный замер. После новой ветви или изменения анализатора проверяйте соответствующий вход и его объединение. Приёмка должна называть действительно исследованный pipeline и оставшиеся ошибки, а не расплывчато объявлять нормализацию или RRF включёнными для всех обращений.
Связанные материалы: Локальный RAG-сервер: какие компоненты размещать рядом с GPU; Бенчмарк GPU для инференса, которому можно доверять.