Почему для Enterprise RAG необходим гибридный поиск, а не только векторы

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

Введение

Технология Retrieval-Augmented Generation позволяет ассистентам запрашивать информацию из внешних источников перед тем, как отвечать. В большинстве демонстраций в центре внимания находится векторный поиск:

Documents
    │
Chunking
    │
Embedding Model
    │
Vector Database
    │
Top-K Retrieval
    │
Large Language Model

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

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

Механизмы поиска по ключевым словам сопоставляют токены. Запрос «Как можно сбросить пароль?» находит документы, содержащие слова сброс/пароль/аккаунт. Запрос «Невозможно получить доступ к аккаунту» может совсем не находить документы о паролях, несмотря на идентичную цель. Эмбеддинги переносят смысл в векторное пространство, поэтому парафразы всё равно могут совпадать. Для часто задаваемых вопросов и повествовательных документов это представляет собой прорыв.

Где терпят неудачу чистые векторы

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

Если у нас есть запись вида:

Invoice Number : INV-93842
Status         : Paid
Customer       : ABC Corporation

запрос «Каков статус счета-фактуры INV-93842?» часто возвращает руководства по оплате вместо самой счета-фактуры, поскольку эмбеддинги уделяют больше внимания понятиям «счет-фактура/оплата», чем точному идентификатору.

Другие способы сбоев

Поиск по ошибкам в базе данных осуществляется следующим образом:

ORA-12514

вместо страницы с ошибкой ORA-12514 может возвращаться общий руководство по подключению.

Запросы о продукте, такие как:

RTX-9000 Switch

могут приводить к обзорам сетевых решений вместо руководства RTX-9000.

Вопросы о версии, касающиеся:

Version 4.3.12

часто влекут за собой получение общих записей о выпуске, а не конкретно версии 4.3.12.

Поиск информации в сфере здравоохранения для:

Patient ID: P-482731

может возвращать документы с процедурами регистрации вместо записей о пациентах.

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

Почему эмбеддинги здесь не справляются

Модели учатся различию между «врач↔лекарь» и «автомобиль↔машина». Такие строки, как:

INV-93842

или

RTX-9000

имеют незначительное семантическое содержание. Изменение:

INV-93842

на

INV-93843

приводит к смене бизнес-субъекта, при этом векторы остаются практически идентичными. Это характерно для методов плотного поиска, а не ошибка конкретного поставщика.

Разделение задач в корпоративном поиске

Семантическая информация (правила использования, процесс подачи заявок, сброс пароля) — здесь преимущества у векторов. Точная информация (идентификаторы, коды, SKU, версии) — здесь преимущества у поиска по ключевым словам/BM25.

Использование только одной стратегии означает отличные результаты в одной области и трудности в другой. Гибридный поиск создан для учета обеих сфер.

Что такое гибридный поиск

Вместо использования только BM25 или векторов применяются оба метода с их объединением:

User Query
                         │
        ┌────────────────┴────────────────┐
        │                                 │
        ▼                                 ▼
 Keyword Search (BM25)           Vector Search
        │                                 │
        └──────────────┬──────────────────┘
                       ▼
              Merge & Score Fusion
                       ▼
                 Cross-Encoder Re-ranker
                       ▼
                Top Relevant Context
                       ▼
                 Large Language Model

Поиск по ключевым словам защищает идентификаторы и редкие токены. Поиск по векторам позволяет находить синонимы и различные формулировки. Механизм переранжирования (или объединение рангов) сортирует полученные результаты в соответствии с запросом пользователя.

Почему гибридный подход лучше

Для вопроса «Почему счёт-фактура INV-93842 всё ещё ожидает утверждения?» гибридный подход позволяет находить точный идентификатор с помощью ключевых слов, загружать связанные документы рабочего процесса с использованием векторов и переустанавливать ранжирование так, чтобы запись счёта-фактуры оставалась на первом месте, в то время как документы процесса оставались доступными. Каждый метод используется в той сфере, где он наиболее эффективен.

Заключительные мысли

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

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

С точки зрения практической реализации необходимо фиксировать, какая ветвь способствовала получению каждого результата (использование ключевых слов или метода денсного поиска), настраивать веса слияния данных на наборе для оценки, включающем как вопросы на парафразирование, так и запросы к идентификаторам, а также воздерживаться от объявления о завершении работы метода RAG после демонстрации, в ходе которой задаются лишь простые семантические вопросы. Именно запросы к идентификаторам являются теми критериями проверки, при соблюдении которых предприятия на практике терпят неудачу.

Создание гибридной системы без чрезмерных усилий

Начните с использования алгоритма BM25 (или эквивалентного лексического поиска) наряду с существующим векторным индексом — многие векторные базы данных уже предоставляют гибридные API. Сохраняйте совпадение идентификаторов блоков, чтобы процесс слияния данных был простым. Сначала используйте метод слияния на основе взаимного ранга, прежде чем обучать модель для переранжирования данных; этот метод дешев в реализации и зачастую «достаточно хорош», чтобы подтвердить сокращение разрыва в качестве обработки запросов к идентификаторам.

Создайте набор для оценки с двумя группами вопросов: вопросы на перефразирование (семантические) и вопросы на определение идентификаторов (точные). Оценивайте показатель recall@k отдельно. Используйте гибридный подход только тогда, когда улучшается показатель в обеих группах или хотя бы в одной без ухудшения показателя в другой. Обращайте внимание на задержку: параллельная работа двух поисковых механизмов обычно нормальна, в то время как последовательная переориентация огромных наборов кандидатов — нет.

Стратегия разбиения на части по-прежнему важна. Идентификаторы, находящиеся в огромных частях текста, снижают качество оценок как методом BM25, так и другими способами. Целесообразно использовать границы частей, при которых заголовки счетов, названия кодов ошибок и строки с SKU остаются нетронутыми. Фильтры метаданных (линия продукта, регион, тип документа) помогают еще больше сократить количество ложных результатов перед объединением информации.

Наконец, проинформируйте заинтересованных сторон в компании: фраза «мы включили все» не является стратегией поиска. Гибридный подход — это стратегия, соответствующая тому, как предприятия на самом деле задают вопросы: наполовину на естественном языке, наполовину с использованием идентификаторов заказов, введенных с экрана.

Чек-лист внедрения

1. Провести поиск записей в логах производства; отметить, какие требуют точного совпадения, а какие — парафразирования.
2. Настроить лексический поиск на том же корпусе и с использованием тех же идентификаторов блоков, что и векторный индекс.
3. Слиять результаты поиска с RRF; фиксировать источники данных для каждого найденного результата.
4. Оценить показатель recall@k для обеих групп данных; скорректировать веса.
5. Только после этого рассмотреть возможность использования обученного ранжировщика, если позволяет лимит задержек.
6. Сохранять поля идентификаторов в метаданных для использования фильтров при необходимости, когда интерфейс уже знает номер счета или SKU.

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