Qdrant Hybrid Search: находим точнее чем просто по смыслу

Qdrant Hybrid Search решает конкретную проблему: чистый векторный поиск находит документы близкие по смыслу, но пропускает точные термины, коды ошибок и артикулы, если они не сильно повлияли на общий вектор фразы. Гибридный поиск объединяет семантику с классическим поиском по ключевым словам BM25 и, по независимым замерам, поднимает точность retrieval примерно на 30% против чистого dense-поиска. Разберем, почему теряется точность, как работает reciprocal rank fusion в Qdrant, зачем нужны фильтры по метаданным и как выглядит рабочий конфиг.

Обновлено: сентябрь 2026. Гибридный поиск связывает BM25 (точные термины) и dense-векторы (смысл) через reciprocal rank fusion, встроенную в Qdrant с версии 1.10. Прирост точности retrieval около 30% против чистого векторного поиска. Ниже: живой пример проблемы, разбор RRF, фильтры по payload и конфиг на Python.

Почему обычный векторный поиск теряет точные термины?

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

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

Такая же история с артикулами товаров, версиями библиотек, номерами заказов. Семантика хороша там, где пользователь описывает намерение своими словами: "как отменить платеж" вместо точного названия функции. Но как только в игру входит точный идентификатор, dense-вектор становится слабым звеном. Разработчики Qdrant прямо называют это ограничением семантического поиска в документации по гибридным запросам: чистая семантика и чистая лексика решают разные задачи, и ни одна не покрывает обе.

Если вы только настраиваете базовый поиск, сначала разберитесь с самим Qdrant: установка Qdrant и первый поиск на Python закрывает этот шаг с нуля.

Как Hybrid Search в Qdrant комбинирует BM25 и векторный поиск?

Qdrant запускает BM25 и dense-поиск параллельно, а затем сливает два ранжированных списка через reciprocal rank fusion. RRF учитывает только позицию документа в каждом списке, а не абсолютную оценку.

Дело в том, что оценки dense и sparse поиска физически несравнимы. Косинусная близость всегда лежит в диапазоне от -1 до 1, а BM25-скор ничем не ограничен и может быть и 3, и 30. Reciprocal rank fusion обходит эту проблему: для каждого документа берется его ранг в каждом списке, а не сырой скор, и считается сумма обратных рангов. Метод предложили Кормак, Кларк и Бюттхер еще в 2009 году, и с тех пор RRF стал дефолтным способом слияния в Elasticsearch, OpenSearch и Qdrant.

По независимым замерам, связка BM25 плюс dense-поиск с RRF дает прирост точности порядка 30% против чистого векторного поиска — такую оценку в своей документации приводит проект Qdrant RAG MCP Server для базовой реализации гибридного поиска. Разброс цифр по разным датасетам бывает и скромнее: например, на e-commerce-датасете WANDS прирост NDCG составил около 7%. Порядок цифр зависит от того, сколько в корпусе точных идентификаторов против описательных запросов.

С версии Qdrant 1.10 весь этот пайплайн собирается одним вызовом через Universal Query API: вы описываете prefetch по dense и sparse векторам, а затем указываете Fusion.RRF как финальный шаг. Без универсального API пришлось бы делать два отдельных запроса и сливать результаты вручную на стороне приложения.

Что такое семантический поиск и на чем он строится — отдельная тема, разобранная тут: семантический поиск, что это и как находить смысл.

RRF или DBSF: какой метод слияния выбрать?

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

RRF — простой и почти не требует настройки, кроме параметра k, который отвечает за то, насколько резко штрафуются документы с низким рангом. Индустриальный стандарт — k=60: при таком значении разница между позицией 1 и позицией 2 не раздувается искусственно, а документы, которые несколько методов поставили в топ независимо друг от друга, получают честное преимущество. При k=0 маленькая разница в похожести, скажем 0.95 против 0.94, может превратиться в двукратную разницу очков, что не отражает реальную релевантность.

DBSF работает иначе: пересчитывает шкалу каждого списка через среднее и разброс оценок, а затем складывает результаты. Это сохраняет "силу лидерства" — если один метод выдал явного фаворита, DBSF это не сотрет. Qdrant поддерживает оба метода из коробки, и в статье про гибридный поиск на сайте Qdrant рекомендация звучит прагматично: начните с RRF, а DBSF сравнивайте на тех же тестовых запросах, если точности не хватает.

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

Зачем гибридному поиску нужны фильтры по метаданным?

Фильтры в Qdrant ограничивают и dense, и sparse часть поиска точными условиями по payload: категория, дата, статус документа. Гибридный поиск находит похожее по смыслу и по словам, а фильтр сужает это только до нужного раздела базы.

Представим базу знаний с документами по продукту, HR и юридическим темам вперемешку. Пользователь спрашивает про отпуск, и семантически близкие документы могут найтись сразу в трех разделах. Фильтр по полю category = "hr" в payload убирает лишнее еще до того, как запрос дойдет до ранжирования, и не нужно заводить отдельные коллекции под каждый раздел.

В Qdrant фильтр можно навесить и на dense, и на sparse часть prefetch-запроса одновременно, так что RRF или DBSF работают уже только внутри отфильтрованного подмножества. Для полей вроде id, категории или тега используется keyword-фильтрация как точное совпадение, для длинного текстового поля — text-фильтрация с токенизацией, подробности в гайде Qdrant по фильтрации. Для скорости под фильтруемые поля стоит заранее создать payload index — без индекса Qdrant Cloud вообще ограничивает фильтрацию по большим коллекциям.

Комбинация гибридного поиска с фильтрами закрывает практическую задачу "найди похожее по смыслу, но только в этом разделе и не старше такой-то даты" без разрастания архитектуры на десятки коллекций. Это особенно актуально для корпоративных баз знаний, где документов тысячи и часть из них устарела: подробный разбор такого кейса — в статье про RAG для корпоративной базы знаний.

Как настроить Hybrid Search в Qdrant: пример конфигурации

Ниже рабочий скелет на Python через qdrant-client. Коллекция хранит два именованных вектора: dense и sparse (BM25), фильтр применяется на этапе prefetch.

from qdrant_client import QdrantClient, models

client = QdrantClient(url="https://xxx.qdrant.tech", api_key="...")

client.create_collection(
    collection_name="support_docs",
    vectors_config={
        "dense": models.VectorParams(size=384, distance=models.Distance.COSINE),
    },
    sparse_vectors_config={
        "bm25": models.SparseVectorParams(modifier=models.Modifier.IDF),
    },
)

results = client.query_points(
    collection_name="support_docs",
    prefetch=[
        models.Prefetch(
            query=models.Document(text=query, model="Qdrant/bm25"),
            using="bm25",
            filter=models.Filter(
                must=[models.FieldCondition(key="category", match=models.MatchValue(value="support"))]
            ),
            limit=20,
        ),
        models.Prefetch(
            query=models.Document(text=query, model="sentence-transformers/all-MiniLM-L6-v2"),
            using="dense",
            filter=models.Filter(
                must=[models.FieldCondition(key="category", match=models.MatchValue(value="support"))]
            ),
            limit=20,
        ),
    ],
    query=models.FusionQuery(fusion=models.Fusion.RRF),
    limit=10,
)

Обратите внимание на modifier=models.Modifier.IDF в конфигурации sparse-вектора: без него BM25-скоринг в Qdrant считается неполно, и это одна из самых частых ошибок при первой настройке. Дальше меняете limit в prefetch — обычно берут 15-30 кандидатов с каждой стороны перед финальным fusion, чтобы не терять релевантные документы на этапе первичного отбора.

Когда гибридный поиск не нужен?

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

Тут стоит быть честным: гибридный поиск — это дополнительная инфраструктура. Нужно поддерживать sparse-индекс, следить за IDF-модификатором, тюнить k в RRF. Если ваша база — это, например, подборка вдохновляющих цитат или общих статей, где пользователь никогда не ищет точный код или артикул, прирост от BM25 будет статистической погрешностью, а сложность конфигурации останется.

Гибридный поиск оправдан там, где реально смешаны два типа запросов: часть пользователей знает точные термины, часть описывает задачу своими словами. Это база поддержки, юридические документы, каталоги товаров, техническая документация. Если у вас такой смешанный трафик — да, добавляйте BM25 и RRF. Если нет — не усложняйте пайплайн ради чекбокса в архитектуре.

Максим: «Портал VibeCoderz мы собрали за неделю тремя скриптами голосом в Claude Code, сейчас там больше 6 200 материалов. На таком объеме без точного поиска по терминам половина статей просто не находится, чистая семантика их размывает».

Глоссарий

• Dense-вектор — числовое представление текста, кодирующее смысл. Похожие по значению фразы дают близкие вектора.
• Sparse-вектор (BM25) — представление текста через веса конкретных слов. Работает как точный поиск по ключевым словам.
• RRF (Reciprocal Rank Fusion) — алгоритм слияния нескольких ранжированных списков по позиции документа, а не по абсолютной оценке.
• DBSF (Distribution-Based Score Fusion) — альтернативный метод слияния, нормализующий шкалы оценок перед суммированием.
• Payload — метаданные точки в Qdrant: категория, дата, теги, любые JSON-поля для фильтрации.
• Reranker — модель, которая пересортировывает уже отобранных кандидатов, например cross-encoder.
• Universal Query API — единый метод Qdrant с версии 1.10 для сборки сложных пайплайнов retrieval, fusion и rerank в одном вызове.

Часто задаваемые вопросы

Что такое hybrid search в Qdrant простыми словами?
Это поиск, который одновременно смотрит на смысл запроса через векторы и на точное совпадение слов через BM25, а затем сводит оба результата в один список через RRF или DBSF.

Нужен ли reranker вместе с гибридным поиском?
Не обязательно. Гибридный поиск сам по себе уже улучшает качество кандидатов. Reranker вроде cross-encoder добавляет точность на финальном шаге, но и добавляет 100-300 мс задержки, поэтому включайте его только если метрики точности реально этого требуют.

Какой k использовать в RRF?
Индустриальный стандарт — k=60, он же дефолт в Qdrant, Elasticsearch и OpenSearch. Для старта этого достаточно, точечная настройка нужна только если есть размеченный набор запросов для сравнения.

Можно ли комбинировать hybrid search с фильтрами по дате?
Да, фильтр вешается на каждый prefetch-запрос отдельно, включая dense и sparse часть, и работает как обычное условие по payload, например диапазон по дате публикации.

Гибридный поиск работает на бесплатном тарифе Qdrant?
Да, sparse-векторы и Universal Query API доступны и в self-hosted, и в бесплатном тарифе Qdrant Cloud. Ограничения на бесплатном тарифе касаются объема хранилища и количества payload-индексов, а не самой функции fusion.

В чем разница между keyword и text фильтром в Qdrant?
Keyword-фильтр ищет точное совпадение всей строки, подходит для id, категорий, тегов. Text-фильтр токенизирует поле и ищет отдельные слова или фразы внутри длинного текста.

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

Если настраиваете гибридный поиск для собственного RAG-проекта и хочется сверить архитектуру, запишитесь на консультацию к Максиму или посмотрите каталог AI-инструментов на VibeCoderz.

Обновлено: сентябрь 2026.

BlogPosting:

FAQPage:

HowTo: