# Гибридный поиск OpenSearch: normalization и score-ranker pipeline

Нормализация баллов OpenSearch и reciprocal rank fusion относятся к разным конфигурациям search pipeline.

Автор: Команда Retrivium
Обновлено: 2026-11-03
Канонический URL: https://retrivium.ai/ru/journal/opensearch-hybrid-normalization-score-ranker/
Language: ru

Нормализация баллов OpenSearch и reciprocal rank fusion относятся к разным конфигурациям search pipeline. До интерпретации итоговой релевантности и замены embedding-модели установите, какой процессор действительно обрабатывает выбранный гибридный запрос.

## Найти этап объединения

[Справочник normalization-processor](https://docs.opensearch.org/latest/search-plugins/search-pipelines/normalization-processor/) помещает его работу между фазами query и fetch. Он объединяет баллы поисковых условий после нормализации величин. Это не нормализация эмбеддингов документа перед индексацией. Сохраните различие в названиях настроек и диагностике. Нормализация вектора способна изменить кандидатов, тогда как процессор баллов поисковой фазы определяет объединение уже найденных результатов ветвей. Эти вмешательства не следует описывать одним общим действием с непонятной границей.

## Отличить ранги от величин

[Справочник score-ranker](https://docs.opensearch.org/latest/search-plugins/search-pipelines/score-ranker-processor/) описывает RRF на той же поисковой фазе, но с опорой на позиции. Его трактовка входа отличается от нормализации баллов, поэтому перенос весов либо порогов между схемами не является неизменным контролем. Проверенные страницы указывают появление normalization в 2.10, score-ranker — в 2.19. Это границы введения функций, а не доказательство одинаковых настроек по умолчанию и возможностей каждой актуальной установки.

## Подтвердить применение pipeline

Сохраните настоящий запрос рядом с определением выбранного pipeline. Наличие именованной конфигурации на сервере не доказывает, что конкретный запрос её использовал. Для диагностики запишите фактический путь обращения и исследуйте поведение на намеренно простом наборе. Не делайте вывода об ошибке алгоритма, если запрос обошёл процессор, работа которого должна была оцениваться. В таком случае сначала исправляют исследуемую конфигурацию и только потом сравнивают релевантность полученной выдачи.

| Уровень конфигурации | Сохраняемые сведения |
|---|---|
| Условия hybrid | Порядок и настройки отдельных поисков |
| Search pipeline | Тип и параметры процессора |
| Запрос | Применённый к этому запуску pipeline |

## Проверить разные масштабы ветвей

Создайте учебный запрос, где лексическая и векторная ветви возвращают частично общие документы с разными масштабами баллов. Сохраните исходные позиции и величины. Сравните нормализованную конфигурацию с RRF при прежних настройках ветвей. [Документация RRF](https://docs.opensearch.org/latest/vector-search/ai-search/hybrid-search/rrf/) объясняет путь объединения рангов. Оценивайте полезные исходные доказательства, а не ожидайте, что отображаемые числа двух методов будут напрямую сопоставимы или означать один и тот же порог принятия результата.

## Отделить нехватку кандидатов

Если нужный фрагмент отсутствует во всех ветвях, процессор его не добавит. При замене только объединения сохраняйте глубину кандидатов и фильтры. Расширение окна может помочь вопросу независимо от fusion. Ошибка порядка условий также способна назначить вес не тому сигналу. Сохраните объяснение изменившихся результатов, чтобы средняя метрика не скрыла несовпадение конфигурации и не приписала восстановленный документ алгоритму, который фактически не участвовал в обработке запроса.

## Опубликовать версионный результат

Храните установленный выпуск, определение процессора, запросы проверки и разметку. Сравнивайте конечную релевантность и стоимость выполнения, не превращая пример производителя в локальный замер. После новой ветви или изменения анализатора проверяйте соответствующий вход и его объединение. Приёмка должна называть действительно исследованный pipeline и оставшиеся ошибки, а не расплывчато объявлять нормализацию или RRF включёнными для всех обращений.

Связанные материалы: [Локальный RAG-сервер: какие компоненты размещать рядом с GPU](/ru/journal/rag-server-local-architecture/); [Бенчмарк GPU для инференса, которому можно доверять](/ru/journal/inference-benchmark-method/).