Смысловой поиск по векторам — то, ради чего RAG обычно и затевают: система находит нужное, даже если человек сформулировал вопрос другими словами. Это работает.
Но у него есть слепая зона, и она предсказуемая: всё, что не несёт смысла, а является обозначением. Артикулы, номера договоров, коды моделей, фамилии, названия версий. Для векторной модели «ТМ-40/6» и «ТМ-46/0» — почти одно и то же, потому что различие между ними не смысловое, а символьное.
Отсюда рабочая схема: искать двумя способами одновременно и объединять результаты.
Что умеет каждый способ
Смысловой поиск сравнивает векторы вопроса и фрагментов. Находит переформулировки: «сколько ждать доставку» найдёт фрагмент про «срок поставки составляет», хотя общих слов почти нет.
Проваливается на: точных обозначениях, редких терминах, аббревиатурах, именах собственных, числах.
Словесный поиск ищет совпадения слов с учётом их редкости: чем реже слово встречается в корпусе, тем больше веса даёт его совпадение. Классическая реализация — BM25.
Находит: артикулы, коды, номера, точные термины. Проваливается на: синонимах и переформулировках. Вопрос «как вернуть товар» не найдёт фрагмент, где написано «процедура возврата изделия», если ни одно слово не совпало.
Слепые зоны у них разные, и именно поэтому совмещение работает лучше любого из двух.
| Тип запроса | Смысловой | Словесный |
|---|---|---|
| «сколько ждать доставку» | находит | может промахнуться |
| «условия по тарифу Т-450» | промахивается | находит |
| «что делать при браке» | находит | зависит от формулировки |
| «договор №4417-А» | промахивается | находит |
| «можно ли вернуть, если вскрыли упаковку» | находит | частично |
| «характеристики ТМ-40/6» | промахивается | находит |
Как объединять результаты
Проблема объединения не техническая, а арифметическая: у двух поисков несравнимые оценки. Векторная близость лежит в одном диапазоне, вес BM25 — в другом и зависит от корпуса. Складывать их напрямую нельзя: сумма не имеет смысла, а веса подобрать не на чем.
Объединение по позициям
Самый надёжный способ на практике. Учитываются не оценки, а места в списках: фрагмент получает тем больше очков, чем выше он стоит у каждого из поисков. Известен как reciprocal rank fusion.
Почему работает. Позиция сравнима всегда, а оценки — нет. Настраивать почти нечего, поведение предсказуемое. Документ, попавший в верх обоих списков, уверенно выигрывает у документа, который хорош только по одному признаку.
С этого способа разумно начинать.
Взвешенная сумма после нормализации
Оценки каждого поиска приводятся к общему диапазону, затем складываются с весами. Даёт больше контроля, но требует подбора весов на размеченных данных. Без них веса берутся наугад, и это ровно та ситуация, когда настройка создаёт видимость управляемости.
Переоценка вместо объединения
Оба поиска дают кандидатов, а порядок определяет отдельная модель. Тогда объединение можно делать грубо — важна только полнота списка кандидатов, а не их порядок. Разбор — «Реранкинг».
На практике это чаще всего лучшая схема: гибридный поиск отвечает за полноту, переоценка — за точность.
Что ещё добавляют в поиск
Фильтры. Права доступа, дата, раздел, тип документа. Применяются как условие поиска, а не как понижение оценки: отфильтрованное не должно всплыть ни при каком раскладе. Особенно это касается прав — «Разграничение доступа в RAG».
Расширение запроса. По вопросу генерируется несколько переформулировок, поиск идёт по каждой, результаты объединяются. Помогает на коротких и неоднозначных вопросах, стоит дополнительного обращения к модели.
Поиск по выжимке. Ищем не по тексту фрагмента, а по его краткому пересказу или по списку вопросов, на которые он отвечает. Иногда даёт заметный прирост: вопрос пользователя ближе к вопросу, чем к формулировке регламента.
Разбор: поиск, который «работал, но не находил»
Задача. База знаний по оборудованию: документация, прайс, инструкции по обслуживанию. Пользователи — инженеры и менеджеры.
Симптом. Менеджеры были довольны, инженеры жаловались. Одна и та же система.
Что показал разбор запросов. Различие оказалось в характере вопросов.
Менеджеры спрашивали смыслово: «какой срок гарантии на насосы», «что входит в обслуживание». Векторный поиск справлялся.
Инженеры спрашивали точно: «допустимое давление ТМ-40/6», «артикул уплотнения для ЦН-125», «что означает ошибка E-24». Три класса запросов, и все три векторный поиск обрабатывал плохо: обозначения он не различает, коды ошибок для него шум.
Проверили на контрольном наборе: на смысловых вопросах нужный фрагмент попадал в первую пятёрку почти всегда, на технических — примерно в трети случаев.
Что сделали.
Добавили словесный поиск и объединение по позициям. Технические запросы стали находиться.
Дальше вскрылась вторая проблема, которую первая маскировала: коды ошибок вида «E-24» словесный поиск тоже находил плохо, потому что при разбиении текста на слова дефис разрывал обозначение на «E» и «24», а «E» — слишком частый символ. Пришлось поправить правила разбиения, чтобы обозначения не распадались.
Третье: добавили в индекс синонимы обозначений — в документах одно и то же изделие называлось и «ТМ-40/6», и «ТМ40-6», и «насос ТМ серии 40».
Что изменилось. Доля технических вопросов, где нужный фрагмент попадал в первую пятёрку, выросла примерно втрое. На смысловых вопросах результат не ухудшился — это проверялось отдельно, потому что при таких правках легко испортить то, что работало.
Общий вывод. Прежде чем настраивать поиск, посмотрите, какие вопросы вам задают на самом деле. Если среди них есть обозначения, коды и номера, одного векторного поиска не хватит никогда, и это не лечится сменой модели векторизации.
Когда гибридный поиск не нужен
Честная оговорка: он не бесплатен — второй индекс, объединение, больше кода в сопровождении.
Можно обойтись одним смысловым поиском, если:
- в текстах нет артикулов, кодов, номеров и редких обозначений;
- вопросы формулируются обычным языком, без точных наименований;
- корпус небольшой и однородный.
Разумный порядок: собрать на векторном поиске, измерить на реальных вопросах, добавлять словесный при виде характерных провалов. Как измерять — «Метрики RAG».
Частые вопросы
Что такое гибридный поиск в RAG?
Это одновременный поиск двумя способами: смысловым по векторам и словесным по совпадению слов, с последующим объединением результатов. Нужен потому, что слепые зоны у этих способов разные: векторный не различает артикулы и коды, словесный не понимает переформулировки.
Почему векторный поиск не находит артикулы?
Потому что он сравнивает смысл, а у обозначения смысла нет. Для модели «ТМ-40/6» и «ТМ-46/0» выглядят почти одинаково: различие между ними символьное, а не смысловое. Точные совпадения — задача словесного поиска.
Как объединять результаты двух поисков?
Надёжнее всего по позициям в списках, а не по оценкам: оценки у разных поисков несравнимы, а позиции сравнимы всегда. Фрагмент, оказавшийся высоко в обоих списках, выигрывает у того, что хорош только по одному признаку. Взвешенная сумма даёт больше контроля, но требует размеченных данных для подбора весов.
Заменяет ли реранкинг гибридный поиск?
Нет, они решают разные задачи. Гибридный поиск отвечает за полноту: нужный фрагмент должен вообще попасть в список кандидатов. Реранкинг отвечает за точность: расставить кандидатов в правильном порядке. Если фрагмент не найден, переоценивать нечего.
Нужен ли гибридный поиск всегда?
Нет. Если в документах нет обозначений, кодов и номеров, а вопросы задаются обычным языком, векторного поиска может хватить. Разумно начать с него, измерить качество на реальных вопросах и добавлять словесный, когда увидите характерные провалы.
Что делать, если одно и то же называется в документах по-разному?
Добавлять синонимы в индекс. Это частая ситуация: в документации изделие называется полным обозначением, в переписке — сокращённым, в прайсе — с другим разделителем. Ни векторный, ни словесный поиск сами эту связь не установят.
Что дальше
Полнота списка кандидатов — половина дела, дальше нужен порядок: «Реранкинг». Если поиск проваливается систематически — «Почему RAG не находит документ». Выбор модели векторизации для русского — «Эмбеддинги для русского».
Настройка поиска под конкретный корпус и характер вопросов — часть работы по разработке и внедрению ИИ.