Гибридный поиск: как объединить BM25 и векторы

Документация проверена 24 октября 2026 года. Рекомендации по реализации ниже опираются на актуальную документацию Elasticsearch, Weaviate и Pinecone. Параметры оценки — это предлагаемый начальный протокол проверки, а не результаты измерений или бенчмарки поставщиков.

Что такое гибридный поиск?

Гибридный поиск учитывает и буквальную формулировку, и смысл запроса. В рассматриваемой архитектуре поиск по ключевым словам формирует один ранжированный список, векторный поиск — другой, а метод объединения сводит их в общую выдачу. Обе ветви и их объединение описаны в объяснении Weaviate.

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

BM25 — функция лексического ранжирования: она оценивает документы по словам запроса, которые в них встречаются. На оценку влияют частота терминов и длина документа; это полезнее простого подсчёта совпавших слов. В Elasticsearch BM25 служит методом оценки текстового сходства по умолчанию. Эти факторы описаны в справочнике Elastic по оценке сходства.

Векторный поиск сравнивает эмбеддинги — числовые представления содержимого — и находит близкие по смыслу материалы. Он может связать запрос «Меня постоянно выбрасывает из аккаунта» с документом об истечении срока действия сессии, даже если слова не совпадают. Этот подход разобран в нашем руководстве по семантическому поиску.

Возьмём условный запрос ERR_SESSION_EXPIRED after login. Лексическая ветвь позволяет включить в выдачу материалы с точной строкой ошибки. Семантическая может добавить инструкции о сессиях аутентификации и их продлении. Метод объединения определяет итоговый порядок. Пример показывает желаемое поведение, но не обещает, что система без настройки выдаст результаты именно в таком порядке.

Как обрабатывать точные идентификаторы в гибридном поиске

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

Если точное написание идентификатора определяет нужную запись, храните его в отдельном поле для точного совпадения. Для таких структурированных значений Elastic описывает поле keyword. Запрос по вымышленному артикулу AX-BLUE не должен незаметно превращаться в рекомендацию AX-GREEN только потому, что описания похожи. См. справочник по полю keyword.

Правило выбора: если система распознала уникальный идентификатор и по требованиям продукта должна вернуть соответствующую запись, направляйте запрос на точный поиск. Гибридное ранжирование используйте для вопросов, где идентификатор сочетается с более широкой задачей, например с поиском инструкции по устранению неполадки у этого товара.

Как объединить результаты: RRF или взвешенные оценки

Начните с reciprocal rank fusion, если нужна базовая конфигурация без калибровки несопоставимых шкал оценок. Взвешенные оценки стоит рассматривать, когда есть разметка для настройки баланса и причина сохранять различия между значениями оценок.

RRF учитывает позиции в списках

Reciprocal rank fusion, или RRF, суммирует вклад каждого списка, в котором встречается документ:

RRF(документ) = сумма 1 / (c + rank) по спискам результатов.

Позиции отсчитываются с первого места. Если документа нет в списке, этот список ничего не добавляет к его оценке. Gordon V. Cormack, Charles L. A. Clarke и Stefan Büttcher представили RRF в статье SIGIR 2009. В экспериментах они зафиксировали константу на значении 60. В статье она обозначена как k; здесь мы используем c, чтобы не путать её с количеством результатов в recall@k.

Удобство RRF в том, что высокая оценка BM25 и высокая оценка векторного поиска не обязаны означать одно и то же. Важны только позиции. В реализации RRF от Pinecone явно описаны и отсчёт позиций с первого места, и обработка отсутствующих документов.

У этого подхода есть следствие, которое нужно проверить. В условном примере документ A занимает первое место в списке по ключевым словам и отсутствует в векторном списке. Документ B — второй в обоих. При c = 60 документ A получает 1/61, а B — 2/62. Побеждает B. Это наш расчёт по формуле, а не поисковый бенчмарк.

Взвешенное объединение сохраняет различия между оценками

При взвешенном объединении оценки релевантности сначала приводят к сопоставимым шкалам, а затем складывают с весами. Распространённая формула:

score = alpha × нормализованная оценка векторного поиска + (1 − alpha) × нормализованная оценка поиска по ключевым словам.

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

Линейный ретривер Elasticsearch поддерживает взвешенную сумму с нормализаторами, например minmax. Объединение по относительным оценкам в Weaviate сохраняет относительные различия внутри каждого набора результатов, тогда как объединение по позициям их отбрасывает.

Начните сравнение с RRF; оставляйте взвешенное объединение, только если его преимущество подтверждают отложенные запросы. Не складывайте исходные оценки BM25 с оценками векторного сходства в расчёте на осмысленную сумму. Фиксируйте и глубину отбора кандидатов: состав нормализуемого списка влияет на диапазон его оценок.

Когда гибридный поиск лучше чисто векторного

Гибридный подход помогает, когда поиск по ключевым словам находит релевантные материалы, пропущенные векторной ветвью, а объединение сохраняет их достаточно высоко в выдаче. Это проверяемое условие, а не обещание более высокой точности во всех случаях.

В первую очередь подход стоит испытать в таких задачах:

• Поиск для поддержки: точные строки ошибок, имена функций и термины, связанные с аккаунтами, в сочетании с описаниями симптомов.
• Поиск по каталогу: точные названия товаров или артикулы в сочетании с потребностями, например проверкой совместимости или подбором запчастей.
• Поиск по внутренней базе знаний: названия проектов и сокращения в сочетании с вопросами на естественном языке.

В обзоре гибридного поиска Pinecone коды товаров, строки ошибок и названия прямо выделены как сигналы для поиска по ключевым словам, который дополняет поиск по смыслу на плотных векторах.

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

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

Как добавить гибридный поиск в существующее хранилище

Сохраните текущее хранилище, если оно поддерживает нужные поисковые операции. Одновременная смена базы данных и стратегии поиска затрудняет понимание того, что именно принесло пользу.

В таблице сравнивается место объединения результатов, а не качество поставщиков.

Гибридный поиск в Elasticsearch

Elasticsearch поддерживает текстовый и векторный поиск и позволяет поместить текстовый ретривер standard и векторный ретривер knn внутрь ретривера rrf. Эта схема и её окно кандидатов описаны в официальном справочнике по ретриверу RRF.

В существующем индексе храните текст для поиска и его эмбеддинг под одним ID документа. Обе ветви должны искать по одному и тому же набору доступных материалов, после чего их результаты объединяются. Согласуйте между ветвями ограничения по тенанту, правам доступа и версии продукта.

Следующий запрос можно выполнить после настройки ES_URL и ES_API_KEY. Он предполагает, что уже есть индекс docs, текстовое поле text, поле плотного вектора embedding и файл query-vector.json с реальным массивом эмбеддинга запроса. Создайте этот массив той же моделью, которую использовали для документов в индексе. Для команды нужны jq и curl.

jq -n --slurpfile v query-vector.json \
  --arg q 'ERR_SESSION_EXPIRED after login' \
  '{
    size: 10,
    retriever: {
      rrf: {
        retrievers: [
          {standard: {query: {match: {text: $q}}}},
          {knn: {
            field: "embedding",
            query_vector: $v[0],
            k: 50,
            num_candidates: 100
          }}
        ],
        rank_window_size: 50,
        rank_constant: 60
      }
    }
  }' > hybrid-request.json

curl --fail-with-body "$ES_URL/docs/_search" \
  -H "Authorization: ApiKey $ES_API_KEY" \
  -H 'Content-Type: application/json' \
  --data-binary @hybrid-request.json

Это пример параметров для оценки. size задаёт количество результатов в итоговой выдаче, а rank_window_size — сколько результатов каждого дочернего ретривера может участвовать в объединении. Прежде чем переносить этот пример без фильтров в приложение с разграничением доступа, добавьте ограничения, определяющие доступность материалов. Elastic описывает родительский filter, который применяется к дочерним ретриверам согласно их спецификациям.

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

Гибридный поиск в Weaviate

Weaviate — база данных с текстовым и векторным поиском — предоставляет гибридный поиск через collection.query.hybrid. Лексическая составляющая использует BM25F, вариант с поддержкой нескольких полей. Документация гибридных запросов описывает поля для поиска, выбор метода объединения и объяснение оценок.

В query_properties укажите поля с полезными лексическими сигналами: например, заголовки, тексты ошибок и названия товаров. Если приложение само создаёт эмбеддинги, передавайте вектор запроса; иначе используйте настроенную для коллекции векторизацию. При сравнении методов объединения задавайте fusion_type явно, а для разбора причин изменения позиции результата запрашивайте explain_score.

Явно задавайте и alpha: значение 0 выбирает поиск по ключевым словам, а 1 — векторный поиск. Актуальная документация предупреждает, что без этого параметра фактическое взвешивание зависит от клиента. По умолчанию используется relativeScoreFusion; также доступен rankedFusion. См. справочник Weaviate по объединению результатов.

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

Гибридный поиск в Pinecone

В документации поисковой базы данных Pinecone описаны разные схемы гибридного поиска. Выберите схему до того, как копировать пример: объединение плотных и разреженных векторов на сервере и RRF на клиенте — разные реализации. См. обзор гибридного поиска Pinecone.

Для BM25 в сочетании с поиском по плотным векторам схема на Documents API выполняет полнотекстовый поиск и поиск по плотным векторам, после чего ваше приложение объединяет упорядоченные ID документов с помощью RRF. Такая клиентская реализация приведена в руководстве Pinecone по RRF.

Для встроенного объединения плотных и разреженных векторов Vectors API позволяет хранить оба представления в каждой записи и объединять их в одном запросе. Руководство по единому индексу требует vector_type="dense" и metric="dotproduct"; клиент масштабирует векторы запроса, чтобы задать их относительное влияние.

Разреженный вектор — это способ представления, а не доказательство того, что его создал BM25. Явно указывайте в описании архитектуры используемую лексическую модель или функцию оценки полнотекстового поиска.

Ограничение: фильтрация по ключевым словам с последующим ранжированием по плотным векторам не равнозначна ранжированию с учётом обоих сигналов. Фильтр удаляет кандидатов и не вернёт уже исключённое совпадение по синониму. Используйте фильтр для обязательного условия, а объединение — когда результат должна иметь возможность добавить любая из поисковых ветвей.

Как работает гибридный поиск в RAG?

Гибридный поиск меняет этап извлечения материалов в генерации с дополнением поиском — retrieval-augmented generation, или RAG: приложение передаёт найденные источники языковой модели перед формированием ответа. Он не заменяет генерацию и не доказывает правильность ответа.

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

Агентный RAG добавляет решения о том, какое поисковое действие выполнить и нужен ли повторный поиск. Одним из таких действий может быть обращение к гибридному ретриверу. Если бот поддержки пропускает точный код ошибки, сначала исправьте и оцените этот ретривер, а затем усложняйте оркестрацию.

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

Как сравнить recall@k до и после изменений

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

Recall@k = количество релевантных ID в первых k результатах ÷ количество всех размеченных релевантных ID для этого запроса. Усредните значения по запросам, чтобы получить макроусреднённую полноту recall@k. Если разметка неполная, называйте результат полнотой относительно известных оценок релевантности: он не показывает полноту поиска по всем релевантным материалам корпуса.

Запустите локальный скрипт оценки полноты

Сохраните следующий код в evaluate_recall.py. Он использует только стандартную библиотеку Python 3. В qrels.jsonl каждому запросу соответствует один JSON-объект с полями qid, slice и relevant. Каждый файл результатов сопоставляет ID запроса с упорядоченным списком найденных ID.

Например, запись разметки может выглядеть так: {"qid":"q-exact","slice":"exact","relevant":["guide-login"]}. А файл результатов может содержать {"q-exact":["guide-reset","guide-login"]}. Это примеры формата, а не результаты поиска в проверенной системе. В каждом файле результатов должны присутствовать все размеченные запросы; если поиск ничего не вернул, укажите пустой список.

import json
import sys
from collections import defaultdict
from statistics import mean

qrels_path, bm25_path, vector_path, hybrid_path, cutoff = sys.argv[1:]
k = int(cutoff)
if k < 1:
    raise ValueError("k must be positive")

with open(qrels_path, encoding="utf-8") as f:
    labels = [json.loads(line) for line in f if line.strip()]
if not labels or len({r["qid"] for r in labels}) != len(labels):
    raise ValueError("Labels must be nonempty with unique query IDs")

runs = {}
for name, path in (("bm25", bm25_path), ("vector", vector_path),
                   ("hybrid", hybrid_path)):
    with open(path, encoding="utf-8") as f:
        runs[name] = json.load(f)
    missing = {r["qid"] for r in labels} - runs[name].keys()
    if missing:
        raise ValueError(f"{name} is missing query IDs: {sorted(missing)}")

groups = defaultdict(list)
skipped = 0
for row in labels:
    relevant = set(row["relevant"])
    if not relevant:
        skipped += 1
        continue
    scores = {}
    for name, run in runs.items():
        unique_ids = list(dict.fromkeys(run[row["qid"]]))
        scores[name] = len(relevant & set(unique_ids[:k])) / len(relevant)
    groups["overall"].append(scores)
    groups["slice:" + row["slice"]].append(scores)

if not groups:
    raise ValueError("No answerable queries to score")
for group, rows in sorted(groups.items()):
    values = {name: mean(r[name] for r in rows) for name in runs}
    delta = values["hybrid"] - values["vector"]
    report = " ".join(f"{name}={v:.3f}" for name, v in values.items())
    print(f"{group} n={len(rows)} recall@{k} {report} delta={delta:+.3f}")
print(f"Excluded no-answer queries: {skipped}")

Запустите скрипт на отложенной разметке и соответствующих выгрузках:

python3 evaluate_recall.py qrels.jsonl bm25.json vector.json hybrid.json 10

Скрипт удаляет повторяющиеся ID до отсечения списка по k. Используйте то же правило удаления дублей в приложении. Он показывает изменение гибридного поиска относительно векторного, а также результат базового поиска по ключевым словам, чтобы сильная лексическая система не выпала из сравнения.

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

Где заканчиваются обещания и с чего начать

Фраза «гибридный поиск берёт лучшее от обоих подходов» скрывает инженерный выбор. Он может расширить охват полезных материалов, но одновременно даёт ещё одной поисковой ветви влияние на итоговый список. RRF способен понизить точное совпадение; взвешенное объединение может отдать преимущество ветви из-за особенностей её шкалы оценок или нормализации. Ни один метод не компенсирует отсутствие нужного содержимого в источниках.

Разработчикам стоит действовать сейчас, если проверка показывает, что релевантные документы с точными терминами отсутствуют среди векторных кандидатов. Добавьте лексическую ветвь, согласуйте ID документов и права доступа и проведите сравнение на размеченных запросах.

Командам эксплуатации стоит отложить внедрение, если текущая проблема — устаревшие материалы, отсутствие прав доступа или разметки релевантности. Сначала устраните эти препятствия, затем сравнивайте стратегии поиска.

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

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

Частые вопросы

Практические руководства по разработке — в рассылке.