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

Гибридный поиск — это подход, в котором система одновременно использует лексическое ранжирование по словам и фразам и векторный поиск по смысловой близости, а затем объединяет результаты в один список. На практике его применяют там, где пользователи пишут и точные термины, и свободные формулировки: в базах знаний, документации, enterprise search, e-commerce и RAG. Метод не лучший выбор, если запросы почти всегда состоят из артикулов, кодов ошибок, идентификаторов или названий полей, данные строго структурированы, корпус очень мал, либо требования к объяснимости, стоимости и задержке важнее, чем выигрыш в полноте поиска.

Простыми словами

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

Векторный поиск решает другую задачу. Он переводит текст запроса и документов в числовые представления, которые называют эмбеддингами, и ищет близкие по смыслу элементы. Поэтому запрос слишком много запросов к API может найти документ про rate limit, даже если формулировки не совпадают.

Гибридный поиск объединяет оба сигнала:

• лексический — для точных совпадений, имен, кодов, артикулов, терминов;
• семантический — для перефразировок, синонимов и естественного языка.

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

Как это работает

Типовая схема

1. Документы индексируются в двух формах: в инвертированном индексе для лексического поиска и в векторном индексе для поиска по эмбеддингам.
2. Для каждого документа хранится текст, метаданные, а часто и служебные поля: тип документа, язык, ACL, дата, tenant, статус публикации.
3. Запрос пользователя проходит по двум веткам. В первой система запускает BM25 или близкий алгоритм по словам запроса. Во второй строит эмбеддинг запроса и ищет ближайшие векторы.
4. Каждая ветка возвращает свой список кандидатов, например top-k.
5. Списки объединяются. Для этого применяют либо ранговое слияние вроде RRF, либо взвешенную сумму после нормализации оценок.
6. Поверх результатов можно применить фильтры и дополнительный reranking, если нужна более точная верхушка выдачи.

Ключевая практическая деталь: сырые оценки из разных веток обычно нельзя просто складывать. Балл BM25 и, например, cosine similarity живут в разных шкалах. Поэтому в рабочей системе сначала выбирают стратегию слияния, а затем проверяют ее на размеченном наборе запросов.

Что обычно настраивают

• Модель эмбеддингов. Она должна соответствовать языку и предметной области. Поиск по юридическим документам, исходному коду и каталогу товаров требует разных моделей или хотя бы разной проверки качества.
• Вес веток. Если в запросах много кодов, названий таблиц и SKU, лексическая ветка часто получает больший вес.
• Размер кандидатного набора. Слишком маленький top-k ухудшает полноту, слишком большой повышает задержку.
• Фильтры. Права доступа, язык, tenant и актуальность документов лучше учитывать явно, а не надеяться на семантику.
• Режим обновления индекса. При смене модели эмбеддингов обычно требуется переиндексация векторов.

Зачем нужно

Гибридный поиск полезен там, где пользователи формулируют один и тот же запрос по-разному, а бизнесу важны и точность, и полнота.

• Сохраняет точные совпадения. Коды ошибок, команды, имена продуктов, номера версий и артикулы не теряются за счет лексической ветки.
• Лучше обрабатывает свободный язык. Пользователь может описать проблему своими словами, и векторная ветка найдет близкие по смыслу документы.
• Снижает зависимость от словаря запроса. Разные команды и подразделения часто называют одну и ту же вещь по-разному.
• Повышает качество контекста для RAG. Если в retrieval-слое есть и точные, и семантические сигналы, LLM реже получает нерелевантный контекст.
• Лучше работает на смешанном корпусе. Например, когда в индексе одновременно лежат runbook, FAQ, changelog, API-справка и постмортемы.

Для практиков главное не в том, что метод «умнее», а в том, что он устойчивее к разным типам запросов. Это особенно заметно в корпоративном поиске, где одни пользователи вводят точные термины, а другие описывают задачу разговорным языком.

Пример

Представим внутренний поиск по документации платформенной команды. В индексе лежат runbook, постмортемы, инструкции по эксплуатации и заметки о релизах. Пользователь пишет запрос: почему API отвечает 429 после ротации ключа.

Лексическая ветка почти наверняка поднимет документы с точным кодом 429 и словом ключ. Векторная ветка, в свою очередь, может найти постмортем, где причина описана иначе: rate limit started after credential rotation. Если объединить результаты, оператор увидит и документ с симптомом, и документ с вероятной причиной, даже если формулировки не совпали.

Запрос	Что дает лексическая ветка	Что дает векторная ветка	Почему гибрид лучше
почему API отвечает 429 после ротации ключа	Документы с точным кодом 429, словом ключ, упоминанием API	Документы про rate limit, credential rotation, деградацию после смены секретов	Верх выдачи содержит и точный симптом, и смысловую причину
сбросить права сервисному аккаунту	Инструкции со словами права и аккаунт	Документы, где операция названа как re-provision service identity	Система лучше переносит разницу в терминологии команд

Минимальная рабочая конфигурация

1. Индексировать текст заголовка и тела документа в инвертированный индекс.
2. Построить эмбеддинги для тех же документов и хранить их в векторном индексе.
3. На запросе брать, например, кандидатов из обеих веток и объединять через RRF как стартовую стратегию.
4. Применять фильтры доступа и типа документа до финального ранжирования.
5. Собирать оценочный набор запросов и смотреть Recall@k, MRR, nDCG@k и задержку.

Такой старт обычно практичнее, чем сразу строить сложный каскад с несколькими reranker-моделями.

Заблуждения и ограничения

• «Гибридный поиск всегда лучше». Нет. Если пользователи ищут по SKU, номеру договора, ID инцидента или точному имени таблицы, хороший лексический поиск часто проще, дешевле и быстрее.
• «Векторный поиск понимает смысл без ошибок». Нет. Эмбеддинги могут смешивать близкие, но разные понятия, особенно в узких доменах и при плохой модели.
• «Достаточно сложить два score». Нет. Без нормализации или рангового слияния можно получить нестабильную выдачу.
• «Фильтры больше не нужны». Нужны. Доступ, tenant, язык, дата, тип документа и статус публикации должны управляться явно.
• «Можно настроить один раз и забыть». Нельзя. Состав корпуса, стиль запросов и сама модель эмбеддингов меняются; качество надо регулярно проверять.

Есть и эксплуатационные издержки: двойная индексация, отдельный пайплайн генерации эмбеддингов, больше потребления памяти, сложнее отладка релевантности и выше задержка, если поверх retrieval добавлен reranking. Метод также хуже подходит для полностью структурированных запросов, которые естественнее решаются через SQL, фильтры или точечный lookup.

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

Чем гибридный поиск отличается от векторного?

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

Нужен ли reranking?

Не всегда. Для многих задач достаточно хорошего retrieval и аккуратного слияния результатов. Reranking полезен, когда нужно улучшить верхние позиции выдачи, но он почти всегда увеличивает задержку и усложняет пайплайн.

Можно ли использовать гибридный поиск без LLM?

Да. Это самостоятельная техника retrieval. Она полезна в обычном поиске по сайту, в корпоративной базе знаний, help center, каталоге товаров и внутренней документации.

Как оценивать качество?

Нужен набор реальных запросов с релевантными документами или хотя бы ручная разметка топов. Обычно сравнивают Recall@k, MRR, nDCG@k, долю успешных сессий и задержку. Сегментируйте метрики по типам запросов: точные идентификаторы, естественный язык, смешанные случаи.

Что выбрать для объединения результатов: взвешенную сумму или RRF?

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

Связанные понятия

• BM25 — классический алгоритм лексического ранжирования по терминам и их частоте.
• Эмбеддинги — числовые представления текста, позволяющие сравнивать смысловую близость.
• ANN — approximate nearest neighbors, приближенный поиск ближайших векторов для ускорения retrieval.
• Reranking — дополнительное переупорядочивание небольшого набора кандидатов более точной моделью.
• RAG — retrieval-augmented generation, схема, где LLM отвечает на основе найденных документов.
• Инвертированный индекс — структура данных для быстрого поиска документов по словам и токенам.