Гибридный поиск в RAG: замена косинуса на три сигнала для точности и экономии
Представьте: менеджер продукта проверяет ответы ИИ-помощника, который ищет информацию в корпусе документов. Большинство ответов оказываются бессвязными — система часто подбирает фрагменты, которые лишь отдалённо похожи по смыслу, но не отвечают на вопрос. Это происходит потому, что текущий процесс — встроить вопрос, сравнить векторные представления всех кусков текста и взять лучшие по косинусному сходству — игнорирует структуру документа и оставляет процесс непрозрачным.
Если ваша команда хочет получать точные, проверяемые ответы и контролировать расходы, стоит спросить: можно ли заменить косинусный ранг на фильтрацию по структурированным таблицам и использовать несколько простых сигналов?
Что предлагает репозиторий doc-intel/notebooks-vol1
Команда разработчиков выложила набор инструментов, который разбивает каждый документ на две таблицы: строки (line_df) и оглавление (toc_df). Вместо одного косинусного сходства используются три параллельных сигнала:
- Ключевые слова — ищут точные совпадения в строках.
- Поиск по оглавлению (TOC) — определяет, в какой главе может находиться ответ.
- Векторное сходство (косинус) — запускается только когда ключевые слова не находят подходящего фрагмента.
Затем «арбитр»-модель получает результаты всех трёх сигналов и выбирает окончательный набор строк для генерации ответа. Полный набор Jupyter-ноутбуков позволяет сразу протестировать метод на своих данных. Эти материалы помогают перейти от «чёрного ящика» к прозрачному процессу, где каждый шаг можно отследить и повторить.
Как вписать подход в обычный процесс разработки ИИ-продукта
- Подготовка данных — вместо простого разрезания текста на куски, скрипт формирует две таблицы: каждая строка с номером строки и каждый пункт оглавления с номером раздела.
- Фильтрация — запрос сначала проверяется на наличие ключевых слов в line_df. Если найдено, это уже готовый «якорь».
- Разумный fallback — если ключевых слов нет, система ищет в toc_df раздел, где мог бы скрываться ответ, и только затем, при необходимости, считает векторное сходство.
- Арбитр-модель — небольшая языковая модель (можно взять open-source GPT-2/3-like) получает список кандидатов от трёх сигналов и, используя простые правила (например, «приоритет — якорь > раздел > вектор»), формирует финальный набор строк.
- Генерация — только отобранные строки передаются в генеративную модель, что экономит вычислительные ресурсы и повышает точность.
Такой порядок сохраняет привычный поток (вопрос → поиск → генерация), но заменяет однобокий ранжирующий шаг на комбинацию проверяемых условий.
Как проверить идею без превращения её в игрушку
| Шаг | Что сделать | Что ожидать |
|---|---|---|
| 1 | Склонировать репозиторий doc-intel/notebooks-vol1 и запустить ноутбук 01_prepare_data.ipynb на небольшом наборе PDF-документов. | Появятся файлы line_df.csv и toc_df.csv. |
| 2 | Запустить 02_keyword_search.ipynb с запросом, содержащим явные термины (например, «позиционное кодирование»). | Получите несколько строк-якорей без любой векторной обработки. |
| 3 | Протестировать 03_toc_reasoning.ipynb запросом, где термин отсутствует, но тема явно указана в заголовке раздела. | Система вернёт нужный раздел + несколько строк из него. |
| 4 | При необходимости включить 04_embedding_fallback.ipynb и сравнить ответы с предыдущими шагами. | Векторный поиск спасёт только те запросы, где остальные сигналы не помогли. |
| 5 | Оценить время выполнения и количество токенов, переданных в генеративную модель, сравнив с традиционным пайплайном (один ранг по косинусу). | Должно быть заметно меньше запросов к модели и более короткие контексты. |
Если на каком-то этапе результаты ухудшаются, можно отключить соответствующий сигнал и сравнить показатели.
Какие риски стоит проверить перед внедрением
- Сложность предобработки — разбиение на line_df и toc_df требует парсинга PDF/HTML, который иногда даёт «мусорные» строки. Это может привести к пропуску нужных фрагментов. Проверьте: запустите парсер на пару типовых документов и вручную проверьте первые 10 строк/заголовков.
- Отсутствие достаточного словарного покрытия — ключевые слова работают лишь при точных совпадениях. При новых терминах система вернётся к векторному поиску, что увеличит нагрузку. Составьте список «словарных дыр» (термины, которые не находятся) и протестируйте fallback.
- Зависимость от арбитра-модели — если модель слишком «ленивая», может отдавать слишком короткие ответы. Плохие ответы ухудшат восприятие продукта. Проверьте несколько запросов, сравнив «арбитр-без правил» и «арбитр-с приоритетом».
- Отсутствие публичных бенчмарков — статья не предоставляет сравнения с другими системами (ColBERT, Cohere Rerank). Трудно оценить, насколько экономия реальна. Сравните время и точность с одним из open-source ранжировщиков на той же задаче.
- Лицензионные ограничения — репозиторий открытый, но использованные модели могут иметь коммерческие ограничения. Нарушение лицензий — юридический риск. Проверьте лицензии на модели и библиотеки, указанные в requirements.txt.
Что решить этой неделе
- Склонировать репозиторий doc-intel/notebooks-vol1 и запустить минимум один ноутбук на пробных данных.
- Проверить, насколько удобно получать line_df и toc_df из своих текущих документов.
- Составить список ключевых слов для самых частых бизнес-вопросов и добавить их в таблицу keywords.csv.
- Оценить, насколько уменьшится нагрузка на генеративную модель (количество токенов).
- Согласовать с юристом лицензии используемых моделей, если планируется коммерческий запуск.
Если результаты покажутся убедительными, можно включить эту схему в основной процесс поиска и перейти к пилотному тесту на реальных запросах.
Заключение
Подход, основанный на комбинировании простых сигналов (ключевые слова, оглавление) и векторного fallback, позволяет существенно сократить количество передаваемых в генеративную модель токенов, улучшить интерпретируемость результатов и снизить стоимость вычислений. При правильной настройке арбитр-модель обеспечивает гибкую приоритизацию, а структура line_df/toc_df делает процесс отладки прозрачным. В дальнейшем стоит исследовать автоматическое расширение словарей ключевых слов и интеграцию более продвинутых ранжировщиков (например, ColBERT) в качестве дополнительного сигнала, чтобы ещё более точно балансировать между скоростью и качеством. Такой гибридный процесс открывает путь к масштабируемым и надёжным системам поиска, готовым к реальному использованию в бизнес-приложениях.