Гибридный или векторный поиск: когда нужны оба сигнала — вопрос выбора между смысловым поиском и объединением смыслового и ключевого. Векторный поиск находит документы по смыслу, keyword-поиск ловит точные коды и имена. Гибридный режим запускает оба запроса и сливает результаты в один список. Выбор зависит от того, какие условия несёт запрос читателя.
Что делает каждый сигнал и где его предел
Основной механизм прост. Keyword-поиск сопоставляет слова запроса со словами документа и ранжирует совпадения по редкости и частоте терминов. В документации Elastic сказано, что лексический поиск опирается на алгоритм вроде BM25F и даёт прозрачное объяснимое ранжирование, поддерживая бусты полей, синонимы и анализаторы. В статье Weaviate уточняется, что BM25 развивает TF-IDF, добавляя нормализацию по длине документа относительно средней длины всех документов в базе, а параметры k1 и b помогают калибровать поведение под конкретный набор данных.
Предел keyword-поиска проявляется на перефразировании. Запрос «как поменять элемент питания» не содержит слов «аккумулятор» или «батарея», и точного совпадения может не быть вовсе. Документация Pinecone описывает это так: полнотекстовый поиск и разреженные векторы находят конкретные термины вроде кодов товаров, строк ошибок и имён, а семантический поиск по плотным векторам находит ответ, сформулированный другими словами.
Векторный поиск работает через эмбеддинги. Модель превращает смысл текста в числовой вектор, векторы хранятся в базе, а близость считается по метрике расстояния — это описано в блоге Weaviate. Elastic добавляет, что такой поиск полезен для неструктурированных данных и исследовательских запросов, когда пользователь не знает точных терминов.
Предел векторного поиска — точные идентификаторы. Код Z-17 и код Z-71 близки по форме, и модель может поставить соседний код выше нужного. Документация Microsoft прямо относит запросы по кодам товаров, узкому жаргону, датам и именам людей к сценариям, где лучше работает keyword-поиск с его точными совпадениями. Оба сигнала имеют собственную слепую зону, и именно поэтому возникает вопрос об их объединении.
Гибридный запрос — это один запрос, настроенный сразу на полнотекстовый и векторный поиск, по формулировке документации Microsoft. Он выполняется по индексу, где текстовые поля соседствуют с векторными, и использует обычные возможности текстового слоя: фильтры, фасеты, сортировку, профили скоринга. Ограничение здесь структурное: описанный Microsoft вариант требует текстовых и векторных полей в одном индексе и подготовки эмбеддингов. Другие архитектуры могут объединять выдачи отдельных хранилищ.
Учебный вход: три запроса и таблица решений
Возьмём условный корпус из трёх документов. Д1: «Z-17. Для замены аккумулятора откройте сервисную крышку». Д2: «Z-71. Для замены батареи снимите нижнюю панель». Д3: «Z-17. Гарантия на зарядное устройство действует по чеку». Ранги ниже — заданные учебные входы для разбора. Ни один поисковый движок и ни одна модель эмбеддингов при подготовке примера не запускались, это не замер качества.
Заполненная таблица решений выглядит так:
| Запрос | Тип условия | keyword | vector | Допустимые документы | Выбранный этап | Причина уточнения |
|---|---|---|---|---|---|---|
| Z-17 | точный идентификатор | Д1, Д3 | Д2, Д1 | Д1, Д3 | фильтр точного кода | действие не задано |
| как поменять элемент питания | перефразирование | — | Д1, Д2 | Д1, Д2 | векторный поиск | код устройства неизвестен |
| замена батареи Z-17 | смешанное | Д1, Д3 | Д2, Д1 | Д1 | объединение и проверка | лишние Д2 и Д3 |
Разберём строки по порядку. В первой строке запрос состоит из одного кода. Keyword-поиск возвращает Д1 и Д3, векторный — Д2 и Д1. Эталон по буквальному идентификатору — множество Д1 и Д3. Д2 не соответствует коду Z-17, его отбрасываем. Остаётся вопрос: что именно нужно читателю — замена аккумулятора или условия гарантии. Обе темы относятся к Z-17, и выбор между ними делает человек.
Вторая строка показывает работу смыслового сигнала. Точных слов запроса в документах нет, keyword-список пуст, векторный поиск возвращает Д1 и Д2. Эталон по смыслу — оба документа. Д1 говорит о замене аккумулятора, Д2 — о замене батареи, и оба подходят под перефразированный вопрос. Код устройства при этом неизвестен, поэтому выдать Д1 единственно правильным ответом нельзя: показываем оба кандидата или уточняем модель.
Третья строка — смешанный запрос, где есть и код, и действие. Keyword даёт Д1 и Д3, векторный — Д2 и Д1. Объединяем кандидатов, сохраняем жёсткое условие Z-17 и проверяем действие. Д2 уходит из-за кода, Д3 — из-за темы. Остаётся Д1. Если после проверки Д1 в списке нет, корректный ход — сообщить о пробеле и уточнить запрос. Подстановка ближайшего документа здесь не подтверждена.
Структурная корректность и фактическая правильность
Две проверки результата разведены и решают разные задачи. Структурная корректность отвечает на вопрос, выполнена ли инструкция поиска: сработал ли фильтр по коду, слиты ли списки, попал ли документ в допустимое множество. Фактическая правильность отвечает на вопрос, тот ли это документ, который нужен читателю по смыслу.
В третьей строке учебного примера объединение двух вымышленных списков поставило Д2 первым. Структурно слияние прошло, списки соединились. Фактически ответ неверен: Z-71 отличается от Z-17, и документ про другую модель не должен занимать верхнюю позицию. Проверка точного идентификатора должна исключить Д2 из допустимого ответа. В конкретном движке её можно реализовать фильтром; порядок фильтрации задаётся его API и проверяется отдельно от слияния.
В первой строке ловушка другого рода. Д1 стоит первым в keyword-списке и вторым в векторном. Соблазн выдать его как ответ велик. Фактически запрос не задаёт действие, и оба документа про Z-17 остаются допустимыми. Первое место не разрешает неопределённость действия: запрос по коду допускает обе темы.
Во второй строке пустой keyword-список выглядит как отсутствие документов. Фактически отсутствие точных слов в запросе не означает отсутствия документов по смыслу, и векторный сигнал находит оба подходящих кандидата. Пустой список одного сигнала — это свойство запроса, и его нельзя читать как отрицательный ответ.
Практический вывод: слияние и финальная проверка — разные шаги. Слияние собирает кандидатов из двух источников, проверка применяет жёсткие условия запроса и отбрасывает лишнее. Документация Pinecone описывает фильтр как отдельный рычаг, который сужает пул кандидатов до ранжирования, чтобы документ вне области не конкурировал за место в выдаче.
Как устроено слияние и как его настроить
Один из способов слияния ранжированных списков — Reciprocal Rank Fusion. Документация Microsoft указывает, что гибридный поиск объединяет результаты полнотекстового и векторного запросов, которые используют разные функции ранжирования: BM25 для текста, HNSW и eKNN для векторов, а RRF сливает результаты в один набор. Блог Weaviate описывает тот же порядок: сначала оба поиска идут параллельно, затем результаты попадают в алгоритм слияния, который строит единый список. Документация Pinecone уточняет границу понятий: RRF — это метод слияния, один из способов объединить ранжированные списки, тогда как гибридный поиск — более широкая идея соединения сигналов.
Вес сигналов настраивается. Документация Qdrant замечает, что по умолчанию каждый запрос получает равный вес, а на практике один ретривер часто сильнее другого на конкретной нагрузке: плотный лучше работает на естественно-языковых запросах, BM25 выигрывает на запросах с идентификаторами. Равный вес даёт слабому сигналу тянуть выдачу вниз. Веса задаются массивом чисел, по одному на каждый подзапрос, и их количество обязано совпадать с числом подзапросов.
Настройка весов опирается на размеченный набор. Документация Qdrant советует разделить проверочные запросы на две половины: подбирать веса на первой, измерять на второй. Измерение на тех же запросах, по которым шла настройка, завышает результат. Для этого есть переиспользуемый помощник tune_rrf_weights с поиском по сетке, который адаптируется под разделение на обучающую и проверочную части.
Учебный конфиг для собственной базы выглядит так:
Паспорт проверки для запроса «замена батареи Z-17»
Документы и ранги: заданы в учебной таблице выше.
Жёсткое условие: буквальный код Z-17.
Смысловое условие: действие замены аккумулятора.
Keyword-кандидаты: Д1, Д3.
Vector-кандидаты: Д2, Д1.
Объединённое множество: Д1, Д2, Д3.
После проверки кода: Д1, Д3.
После проверки действия: Д1.
Если Д1 не найден: ответа по инструкции нет, нужно уточнение.
Это ручной паспорт решения по заданным спискам, а вызов API и расчёт RRF здесь не выполнялись. Для своей базы замените корпус, запрос и эталон. Вес сигналов подбирайте на размеченных запросах; конкретный синтаксис зависит от продукта и версии. Высокий вес поиска по словам сам по себе не превращает совпадение кода в обязательный фильтр.
Когда подход не решает задачу
Гибридный поиск не даёт универсального улучшения. Разберём случай, где он не спасает. Читатель спрашивает: «почему Z-17 не заряжается». В корпусе есть документ про замену аккумулятора, документ про гарантию и документ про другую модель. Ни один из них не описывает причину неисправности. Keyword-поиск вернёт документы с кодом Z-17, векторный поиск подтянет близкие по теме материалы про аккумуляторы, слияние соединит оба списка. Ответа на вопрос в базе нет, и объединение сигналов этого не меняет.
Здесь работает правило отказа. Если после проверки нужного документа в объединённом списке нет, корректный ход — сообщить об отсутствии ответа и уточнить запрос. Подстановка ближайшего документа по теме даёт правдоподобный и неверный ответ, а в сценарии с агентом это хуже пустого результата.
Второй случай — запрос, где одно условие жёсткое, а второе отсутствует. Запрос «Z-17» из первой строки учебного примера не содержит действия. Гибридный поиск вернёт смесь документов про аккумулятор и про гарантию, и оба будут допустимы. Слияние не подскажет, какой из них нужен, потому что этой информации в запросе нет. Уточняющий вопрос решает задачу, а настройка весов — нет.
Третий случай — неподготовленная векторная ветка. В описанном Azure AI Search варианте индекс содержит векторные поля с эмбеддингами рядом с текстовыми полями. Если эти поля ещё не подготовлены, сначала настройте их и проверьте заполнение. В других архитектурах место хранения и способ получения эмбеддингов определяются выбранным продуктом.
Как проверить свою базу
Проверка строится на собственных эталонах. Возьмите набор запросов трёх типов: точные идентификаторы, перефразированные вопросы, смешанные запросы с кодом и действием. Для каждого запроса заранее выпишите документы, которые считаете правильным ответом. Это и есть эталон, с которым сравнивается выдача.
Дальше сравните способы на одинаковых запросах. Прогоните keyword-поиск, векторный поиск и гибридный режим по одному набору и посмотрите, какие эталонные документы найдены каждым способом. Учебные ранги из этой статьи переносить на реальную систему нельзя: они заданы для разбора и не описывают поведение конкретного движка.
Отдельно проверьте фильтр точного идентификатора. Если код является жёстким условием, документы с соседними кодами должны быть исключены из допустимого ответа. Порядок фильтрации влияет на полноту выдачи и зависит от движка. Документация Microsoft замечает, что фильтр можно применять в начале или в конце обработки запроса, и при использовании семантического ранжирования постфильтрация как последний шаг выглядит предпочтительной, но поведение стоит проверить на своих запросах.
Наконец, проверьте отказ. Добавьте в набор запрос, ответа на который в базе нет, и убедитесь, что система сообщает об отсутствии результата. Документация Elastic описывает разницу сценариев: в интернет-магазине поиск может быть успешен, если помогает быстро фильтровать и уточнять результаты, а агенту часто нужен один высокорелевантный ответ для действия. Отказ — часть корректного поведения, и его стоит проверять так же, как попадание.
Частые вопросы
Чем гибридный поиск отличается от векторного?
Векторный поиск ранжирует документы по близости смысловых векторов. Гибридный запускает ещё и keyword-запрос и сливает два ранжированных списка в один. Документация Microsoft описывает гибрид как один запрос, настроенный сразу на полнотекстовый и векторный поиск. Векторный режим остаётся одним из двух сигналов внутри гибрида.
Когда достаточно векторного поиска?
Когда запросы сформулированы свободным языком и не содержат точных идентификаторов. Документация Elastic относит к таким случаям неструктурированные данные, исследовательские запросы и ситуации, где пользователь не знает точных терминов. Если в базе нет кодов, артикулов и имён, которые нужно ловить буквально, второго сигнала может не потребоваться.
Что такое RRF и зачем он нужен?
Reciprocal Rank Fusion — алгоритм слияния ранжированных списков. Документация Microsoft указывает, что RRF объединяет результаты полнотекстового и векторного запросов в один набор. Документация Pinecone уточняет, что RRF — это метод слияния, один из способов соединить списки, и он не равен всему гибридному поиску.
Как настроить вес сигналов?
Веса задаются массивом чисел, по одному на каждый подзапрос, и их число совпадает с числом подзапросов. Документация Qdrant советует подбирать их на размеченном наборе: настраивать на одной половине запросов, измерять на второй. Равный вес по умолчанию даёт слабому сигналу влиять на выдачу.
Что делать, если ответа в базе нет?
Сообщить об отсутствии ответа и уточнить запрос. В учебном примере для смешанного запроса правильный ход — отказаться от ответа, если нужный документ не прошёл проверку. Подстановка ближайшего по теме документа даёт правдоподобный и неверный результат.