Гибридный поиск RAG
Автор: Ai Flowi · Опубликовано
Гибридный поиск RAG объединяет лексический поиск по словам и точным терминам с семантическим поиском по смыслу, представленному эмбеддингами. Объединённые кандидаты дают подтверждения для генерации с дополнением контекста найденными данными. Оценивайте точные идентификаторы и перефразированные вопросы отдельно, чтобы выяснить, сохраняются ли оба вида подтверждений после отбора.
Для предлагаемого пути проверки компоненты OpenSearch, Prompt Template и Language Model в AI Flowi Workflow описаны в каталоге; Ai Flowi не проверяла их в производственной среде. Описание OpenSearch упоминает гибридный поиск, но экспортированный интерфейс не определяет построение запроса, объединение сигналов или настройку внешнего индекса. Это руководство предлагает план проверки, а не подтверждённый сценарий встроенного гибридного поиска.
1. Создайте корпус, различающий сигналы поиска
Подготовьте искусственные фрагменты с явными идентификаторами, объяснениями на естественном языке и похожими, но неприменимыми записями. Используйте вымышленный код оборудования в одном фрагменте и описательный вопрос о его назначении в другой проверке. Оставляйте версии и идентификаторы фрагментов видимыми, чтобы проверять возвращённые подтверждения, а не доверять тому, насколько гладко звучит ответ.
| Особенность фрагмента | Тип вопроса | Ожидаемые подтверждения |
|---|---|---|
| Точный код оборудования | Запросите инструкции для этого кода. | Нужный код остаётся распознаваемым в найденном тексте. |
| Процедура на обычном языке | Спросите о той же задаче другими словами. | Процедуру можно найти без точного повторения фразы. |
| Похожий код другого предмета | Спросите об исходном коде. | Близкий идентификатор не подставляется без уведомления. |
| Правило и условие его применения | Спросите, действует ли правило в конкретном случае. | Для генерации ответа доступны и правило, и условие. |
Это предложенные случаи, а не зафиксированные результаты поиска. Обозначьте нужные фрагменты до любых испытаний. Поиск по коду требует точного сохранения идентификатора, а перефразирование — охвата смысла, поэтому оценивайте объединение по этим двум требованиям. Не предполагайте, что наличие обоих сигналов даёт полный или правильный контекст.
По теме: Чанкинг для RAG.
2. Считайте настройку внешнего поиска предварительным условием
Вам нужны сервис OpenSearch, который вы вправе запрашивать, индекс с подготовленным корпусом, учётные данные с правами для нужных операций и подходящее подключение эмбеддингов. До генерации ответов подготовьте необходимый аккаунт провайдера и ключ по инструкции подключения Language Model; провайдер модели и внешний поисковый сервис оплачиваются отдельно от запусков процесса.
Поручите администратору поискового сервиса документировать фактические лексическую, семантическую и объединённую конфигурации для сравнения. Для внешней настройки обратитесь к официальной документации гибридного поиска OpenSearch. Эта документация не проверялась при подготовке офлайн-черновика; страница не делает привязанных к версии заявлений о поддерживаемых запросах, обработчиках или поведении движка.
Проверьте предварительные требования стартового сценария гибридного поиска RAG в библиотеке сценариев, прежде чем выбирать его как отправную точку. Не считайте этот сценарий проверкой выполнения описанного ниже варианта OpenSearch. Процедура опирается на выгруженное описание интерфейса компонента OpenSearch и отделяет настройку сервиса от полей конструктора.
3. Проверьте, что фактически доступно в компоненте
Описание OpenSearch в каталоге одновременно называет семантические возможности и поиск по ключевым словам, что и обосновывает сравнение кода с перефразированием. Входы поиска включают search_query, index_name, number_of_results, embedding и filter_expression. Выходы — search_results типа JSON, dataframe типа Table и vectorstoreconnection типа VectorStore.
В выгрузке нет входа, явно обозначающего гибридный режим, вес лексического сигнала, правило объединения или конвейер нормализации. engine перечисляет варианты, но название движка не определяет способ объединения лексических и семантических результатов. Не придумывайте переключатель гибридного режима и не помещайте недокументированный синтаксис структурированных запросов в search_query; это поле принимает подключение Message.
4. Настройте путь проверки для подготовленного индекса
Проверка подготовленного индекса: пример конфигурации, а не результат документированного испытания
| Компонент | Входные поля компонентов из каталога | Проверка до продолжения |
|---|---|---|
| OpenSearch | opensearch_url: сервис с разрешённым доступом; index_name: подготовленный тестовый индекс; auth_mode: "basic" или "jwt" согласно настройке; use_ssl: true; verify_certs: true. | Проверьте доступ к конечной точке и действительность сертификатов, не публикуя значения учётных данных. |
| Настройки поиска OpenSearch | search_query: один обозначенный вопрос; number_of_results: 5; embedding: настроенное подключение Embeddings, где оно требуется; vector_field: поле, подтверждённое администратором. | Пять — пример количества запрашиваемых результатов, а не лимит провайдера или встроенная настройка гибридного режима. |
| Prompt Template | template: проверенный текст подтверждений, исходный вопрос и указания опираться на источники. | Для первой проверки введите подтверждения вручную; динамические привязки требуют проверки в редакторе. |
| Language Model | input_value: Prompt Message; model: настроенная LanguageModel; system_message: отвечать только по предоставленным подтверждениям. | Проверяйте ответ отдельно от испытания поиска. |
Не задавайте ingest_data во время предложенного испытания только поиска. Пустое поле позволяет избежать намеренного запроса загрузки данных, но не ограничивает права учётных данных. Установите эти права во внешнем сервисе. До использования реальных данных проверьте требования аутентификации с администратором, включая значение полей JWT.
5. Сравните наблюдаемые лексические, семантические и объединённые результаты
Используйте один и тот же снимок корпуса и набор вопросов для всех конфигураций поиска. Получите отдельно обозначенные результаты только лексического, только семантического и объединённого поиска из внешней тестовой среды. Если конструктор не может выбрать эти режимы через проверенную конфигурацию, зафиксируйте ограничение вместо обозначения трёх одинаковых вызовов как разных экспериментов.
Для каждого вопроса сохраняйте идентификаторы возвращённых фрагментов, порядок и применимые фильтры. Проверяйте ошибки точных кодов, пропуски при перефразировании и отсутствие фрагментов с условиями применения. Фиксируйте фактическую настройку сервиса для каждого наблюдения. Подтверждайте объединённый запуск по его конфигурации сервиса; ни формулировка компонента, ни возвращённый список не демонстрируют веса сигналов.
Отделяйте права внешнего сервиса от эксперимента с сигналами; руководство по базам знаний объясняет подготовку более простого базового варианта поиска.
При сравнении лексических, семантических и объединённых запусков сохраняйте неизменным набор допустимых источников. Иначе кажущееся улучшение поиска может объясняться вновь разрешённым фрагментом. Для каждого запуска фиксируйте и подтверждённую администратором конфигурацию, и допустимый корпус; экспортированное поле filter_expression не задаёт своей грамматики и не показывает, какие фильтры фактически сработали.
6. Проверьте подтверждения до подготовки ответа
При подготовке найденных подтверждений для генерации следуйте проверкам границ форматирования в руководстве по чат-боту на базе знаний и справочнике Prompt Template.
Полезное сравнение для гибридного поиска объединяет два вопроса об одном искусственном предмете: один называет точный код оборудования, другой описывает назначение без кода. Запишите, какие идентификаторы источников сохраняются для обоих вопросов при каждой внешней конфигурации. Если вопрос с точным кодом находит соседний предмет, а поиск по перефразированному вопросу даёт правильный результат, общее среднее скроет дефект идентификации. Рассматривайте пару вместе и проверяйте объединённые подтверждения до того, как формулировка модели замаскирует подмену.
В ожидаемом ответе утверждения привязаны к возвращённым исходным фрагментам, а отсутствие подтверждений обозначено явно. Запрошенный идентификатор должен сохраняться в точности. Используйте оценку RAG для проверки охвата фрагментов и опоры на источники. Если остаётся проблема порядка кандидатов, изучите переранжирование RAG; это последующий этап отбора, а не доказательство настройки гибридного поиска.
7. Когда гибридный поиск не нужен?
Не добавляйте внешнюю поисковую инфраструктуру, если более простой поиск уже подходит для набора вопросов. Гибридный поиск не исправляет отсутствие исходных документов, неоднозначные идентификаторы или неправильно подготовленный текст. Руководство по поиску в базе знаний предлагает более простой исходный вариант, если его документированные границы подходят вашему корпусу.
Это предложение не подтверждает предоставление индекса, размещённого у провайдера, встроенные средства управления режимами, совместимость движков, грамматику запросов или автоматическое восстановление после сбоев. Выгрузка также не содержит измеренного сравнения задержки или качества. Подтвердите внешнюю конфигурацию и проверьте выходные данные до обозначения любого запуска в конструкторе как гибридного поиска. При сбое поиска оставляйте генерацию отключённой вместо подготовки ответа по данным ошибки.
Допущения при оценке затрат на гибридный поиск
Тарифы: Go от USD8 в месяц при годовой оплате (USD10 помесячно), Plus от USD16 (USD20 помесячно), Pro 100 от USD80 (USD100 помесячно), Pro 200 от USD160 (USD200 помесячно) и Pro 500 от USD400 (USD500 помесячно), от 5,000 до 250,000 Flowi Tokens в месяц с возможностью пополнения; 1 токен за каждый запуск узла; использование сторонних API и моделей не включено.
Отдельно закладывайте расходы на внешнюю индексацию, эмбеддинги, сравнение поисковых вариантов и генерацию моделью. Запрошенное число результатов не описывает тарификацию работы поискового сервиса.