Hybrid Search: векторы + ключевые слова = точность

Как это работает: магия эмбеддингов

Идея гениальная. Берём текст, прогоняем через нейросеть, получаем вектор — массив из 1024 чисел, который «кодирует смысл». Похожие по смыслу тексты получают похожие векторы. «Король — Мужчина + Женщина = Королева» — помните этот пример? Магия.

Поиск превращается в геометрию: находим ближайшие точки в 1024-мерном пространстве. Быстро, элегантно, и — самое привлекательное — понимает синонимы. Спрашиваешь про «автомобиль», находит документы про «машину». Красота.

Где магия заканчивается

А теперь три сценария, в которых векторный поиск ломается. Не «работает хуже». Ломается.

Сценарий 1: Точные идентификаторы

Пользователь ищет артикул SKU-7829-BX. Вектор не знает, что это идентификатор. Для него это набор символов, который в embedding-пространстве может оказаться рядом с SKU-7830-BX или вообще с Product-Box-Large, потому что «BX» ≈ «Box» в латентном пространстве.

Номера законов, ID заказов, коды ошибок, артикулы — всё, что состоит из букв и цифр без «смысла», — для вектора это шум.

Сценарий 2: Акронимы и специфичная терминология

В банковской среде KYC, AML, SOFR, ICAAP, PCI DSS — это не просто сокращения, это точные термины с конкретным значением. Embedding-модель, обученная на общем корпусе, может не различать SOFR (ставка финансирования) от LIBOR (межбанковская ставка). Для неё оба — «что-то про процентные ставки».

А теперь представьте: compliance-офицер ищет документ про конкретный переход с LIBOR на SOFR, а получает общую статью про управление процентным риском. Формально релевантно. Практически — бесполезно.

Сценарий 3: Out-of-domain

Модель multilingual-e5-large обучена на миллиардах текстов из интернета. Она прекрасно понимает Википедию, новости, блоги. Но внутренняя документация вашего завода? Специфичные термины вашей отрасли? Сленг вашей команды? Модель их никогда не видела.

Метафора: векторный поиск — это библиотекарь-эмпат. Он чувствует, что вы хотите «что-то грустное про любовь», и принесёт три прекрасных романа. Но попросите конкретную книгу по ISBN 978-5-17-118543-2 — и он посмотрит на вас как на сумасшедшего. «ISBN? Это ведь просто цифры, они ничего не значат!»

Технология 1970-х, которая отказывается умирать

BM25 — Best Matching 25 — это алгоритм ранжирования из семейства TF-IDF, стандарт де-факто для полнотекстового поиска. Его корни уходят в 1970-е, финальная формула опубликована в 1994 году. Elasticsearch, Solr, PostgreSQL full-text search, и даже Google в ранние годы — все использовали вариации BM25.

Как он работает? Просто: считает, как часто слова из запроса встречаются в документе, с поправкой на длину документа и редкость слова в корпусе. Если слово «SOFR» встречается в 3 из 1000 документов, а вы его ищете — документы с этим словом получают высокий score.

Почему BM25 жив и здоров

Три причины, по которым «тупой» поиск по словам иногда умнее вектора:

1. Точность на идентификаторах. Если в запросе есть «Постановление №2864» — BM25 найдёт документы, где есть именно «2864». Не «2432», не «2865». Точно «2864». Вектор на это не способен.
2. Интерпретируемость. Мы точно понимаем, почему документ нашёлся: слова совпали, вот они, подсвечены. Никакого чёрного ящика.
3. Скорость и простота. BM25 работает на инвертированном индексе — структуре данных, которую умеет строить любая база данных. Не нужен GPU. Не нужна embedding-модель. Не нужен отдельный сервис.

Где BM25 проваливается

Конечно, у «тупого» поиска есть фатальный недостаток: он не понимает смысл.

«Машина» и «автомобиль» — для BM25 это два совершенно разных слова. «Как снизить расходы на инфраструктуру» — BM25 не найдёт документ «Оптимизация TCO серверного парка», потому что ни одного общего слова.

Если векторный поиск — библиотекарь-эмпат, то BM25 — это робот-библиотекарь. Он находит ровно то, что вы написали. Ни больше, ни меньше. Буквально.

Идея, которая лежала на поверхности

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

Hybrid Search — это когда мы выполняем два поиска параллельно:

• Векторный (семантический) — ищет по смыслу
• Ключевой (BM25) — ищет по словам

А потом объединяем результаты.

Логика простая: если документ нашёлся и по смыслу, и по ключевым словам — он точно релевантен. Если только по одному из каналов — возможно, но менее уверенно.

Главная проблема: как складывать яблоки и апельсины?

У векторного поиска score — это косинусное расстояние, число от 0 до 1. У BM25 score — это TF-IDF число, которое может быть 0.5 или 45.7. Складывать их напрямую нельзя — это как складывать килограммы с километрами.

И вот тут появляется самый элегантный алгоритм, о котором вы, возможно, никогда не слышали.

Reciprocal Rank Fusion (RRF): элегантность в одну формулу

В 2009 году группа исследователей из Университета Ватерлоо опубликовала paper, в котором предложила гениально простое решение:

Забудьте про абсолютные score. Используйте только позиции в рейтинге (rank).

Формула:

RRF_score(документ) = 1/(k + rank_vector) + 1/(k + rank_bm25)

Где k = 60 — константа сглаживания (авторы paper проверили разные значения, 60 оказалось оптимальным и с тех пор стало стандартом).

Как это работает — на пальцах

Допустим, у нас есть документ X:

• В векторном поиске он на 2-м месте (rank = 2)
• В BM25-поиске он на 1-м месте (rank = 1)

RRF_score(X) = 1/(60 + 2) + 1/(60 + 1) = 0.0161 + 0.0164 = 0.0325

А документ Y:

• В векторном поиске на 1-м месте (rank = 1)
• В BM25-поиске на 15-м месте (rank = 15)

RRF_score(Y) = 1/(60 + 1) + 1/(60 + 15) = 0.0164 + 0.0133 = 0.0297

Документ X побеждает, потому что он высоко в обоих рейтингах. Документ Y — суперзвезда в одном канале, но проигрывает в комбинации.

Почему это гениально:

• Не нужно нормализовать score — мы работаем только с рангами
• Не нужно обучать веса — формула фиксированная
• Не нужен GPU — чистая арифметика
• Работает за микросекунды

Аналогия: представьте, что два друга рекомендуют вам рестораны. Один — гурман (вектор), другой — знает все адреса города (BM25). Если оба рекомендуют одно место — вы туда точно идёте. Если только гурман — может, вкусно, но может и закрыто. Если только «справочник» — может, и работает, но невкусно. RRF — это именно эта логика, но в математике.

Теория — это хорошо, но я из тех людей, которые не верят ничему без бенчмарка. Поэтому мы провели эксперимент.

Задача

Банковские документы на русском языке: политики, регламенты, нормативные акты. 50 документов, 10 тестовых запросов — намеренно сложных, с акронимами (KYC, AML, SOFR, ICAAP), номерами постановлений (№2864, №2432) и профессиональной терминологией.

Именно такие запросы ломают «чистый» векторный поиск.

Участники

*Для Hybrid нужен GPU только на этапе индексации (создания эмбеддингов). На этапе поиска — нет.

Результаты

Перечитайте эти цифры ещё раз.

Hybrid RRF даёт 96% качества тяжёлого Reranker'а. Без GPU на каждый запрос. Без дополнительной модели. Без latency в сотни миллисекунд. Один SQL-запрос.

А чистый Vector Search? Recall 0.767 — на 17% хуже, чем Hybrid. Каждый шестой релевантный документ теряется.

Где именно Hybrid побеждает

Самое интересное — на каких запросах Hybrid обгоняет чистый вектор. Вот конкретные примеры из нашего бенчмарка:

Запрос: «Постановление №2864, требования PEP»

• Vector: Recall 0.67 — не смог отличить номер постановления
• BM25: Recall 1.00 — нашёл по точному совпадению «2864»
• Hybrid: Recall 1.00 — BM25 «подстраховал» вектор

Запрос: «CAR, CET1, Постановление №2432»

• Vector: Recall 0.33 — нашёл только 1 из 3 документов
• BM25: Recall 0.33 — тоже только 1
• Hybrid: Recall 0.67 — комбинация нашла 2, потому что vector нашёл один документ по семантике, а BM25 — другой по exact match «2432»

Вот это и есть суть Hybrid: два метода компенсируют слабости друг друга.

А когда Hybrid проигрывает?

Честности ради — бывает. В нашем бенчмарке на 2 из 10 запросов (STR/AML и ECL/IFRS 9) Hybrid показал хуже, чем чистый вектор (0.33 vs 0.67).

Причина: BM25-ветка притянула шумные документы. Слово «AML» встречается в 5+ документах корпуса, и BM25 подтянул нерелевантные совпадения, которые в RRF-фьюжне вытеснили правильные результаты вектора.

Подозреваю, что с настройкой весов (например, 0.7 × vector + 0.3 × BM25 вместо равных) этот эффект можно смягчить. Но на 8 из 10 запросов равные веса работают прекрасно.

Как это делают (почти) все

Вот типичная архитектура RAG-системы, которую я вижу в каждом втором проекте:

Документы → Elasticsearch (полнотекстовый поиск)
         → Qdrant / Milvus / Pinecone (векторный поиск)
         → PostgreSQL (метаданные, фильтры)

Приложение на Python:
  1. Запрос в Elasticsearch → top-50
  2. Запрос в Qdrant → top-50
  3. Запрос в PostgreSQL → фильтры
  4. Склейка результатов в коде
  5. RRF в Python
  6. Передача в LLM

Три базы данных. Три соединения. Три точки отказа. Три набора мониторинга. И — вишенка на торте — три копии данных, которые нужно синхронизировать.

Это как готовить ужин, используя три кухни в разных домах. Технически возможно. Практически — безумие.

Как это можно делать

А теперь тот же результат, но в одном SQL-запросе:

-- Hybrid Search in one SQL query
WITH vector_results AS (
    SELECT doc_id,
           cosine_distance(embedding, :query_vec) AS score,
           ROW_NUMBER() OVER (ORDER BY cosine_distance(embedding, :query_vec)) AS rank
    FROM documents
    WHERE department = :user_dept
      AND version_status = 'active'
    ORDER BY score DESC LIMIT 50
),
bm25_results AS (
    SELECT doc_id,
           score(content) AS score,
           ROW_NUMBER() OVER (ORDER BY score(content) DESC) AS rank
    FROM documents
    WHERE MATCH(content, :query_text)
      AND department = :user_dept
      AND version_status = 'active'
    ORDER BY score DESC LIMIT 50
)
SELECT doc_id,
       1.0/(60 + v.rank) + 1.0/(60 + b.rank) AS rrf_score
FROM vector_results v
FULL OUTER JOIN bm25_results b USING (doc_id)
ORDER BY rrf_score DESC
LIMIT 10;

Один запрос. Векторный поиск, BM25, фильтрация по правам доступа, RRF — всё внутри.

Обратите внимание на WHERE department = :user_dept AND version_status = 'active'. Это не просто фильтр — это контроль доступа и версионирование, встроенные прямо в поисковый запрос. Не отдельный сервис. Не middleware. WHERE clause.

Какие базы данных это умеют?

В 2026 году unified-подход поддерживают:

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

Когда использовать какой метод

5 правил Hybrid Search

1. Начинайте с Hybrid по умолчанию. Чистый вектор — только если вы уверены, что у вас нет запросов с точными идентификаторами.
2. Используйте RRF (k=60) для объединения. Не изобретайте свою формулу. RRF проверен на десятках бенчмарков и используется в Elasticsearch, Azure AI Search и десятках production-систем.
3. Добавляйте Reranker, только если точности Hybrid не хватает. Cross-encoder добавляет 100-500 мс к каждому запросу и требует GPU. Hybrid RRF даёт 96% его качества бесплатно. Reranker — это для critical queries, не для каждого поиска.
4. Не плодите зоопарк баз данных. Три системы, склеенные скотчем — это три точки отказа, три набора данных для синхронизации и три головные боли на дежурство. Если можно уместить в одну — уместите.
5. Тестируйте на своих данных. Наш бенчмарк — это банковские документы. Ваш домен может быть другим. Возьмите 10 реальных запросов, прогоните через Vector, BM25 и Hybrid — и посмотрите, где расхождения. Если Hybrid побеждает на 3+ запросах — паттерн валидирован.

Итого, без воды

Hybrid Search — это параллельный запуск векторного (семантического) и ключевого (BM25) поиска с объединением результатов через математическую формулу RRF.

Зачем: потому что вектор теряет точные совпадения, а ключевые слова не понимают смысл. Вместе они компенсируют слабости друг друга.

Главный сюрприз: RRF (формула 2009 года, без ML, без GPU) даёт 96% качества тяжёлых нейросетей-реранкеров. Это Pareto-оптимальное решение для 90% задач.

Когда нужно: если вы строите RAG, если ваши пользователи ищут документы, если в запросах есть коды, номера, акронимы, или смесь терминологии и «обычного языка».

Когда НЕ нужно: если у вас чат-бот для свободного общения, без привязки к конкретным документам.

Источники

1. Cormack, G.V., Clarke, C.L.A., Buettcher, S. "Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods" — оригинальный paper про RRF, SIGIR 2009
2. Microsoft Azure AI Search: Hybrid Search — "hybrid retrieval often provides better results than vector search alone"
3. Robertson, S.E. et al. "Okapi at TREC-3" — оригинальная публикация BM25, 1994
4. Apache Doris — Inverted Index + Vector Search — документация по гибридному поиску
5. Наш бенчмарк: Vector vs BM25 vs Reranker vs Hybrid RRF — полные результаты и методология