Инженерное вскрытие RAG — почему векторный поиск слеп и как мы починили его старыми алгоритмами

В сентябре прошлого года на внутреннем аудите базы документации по радиоэлектронике произошел показательный сбой.

Инженер ввел запрос: «Рабочий ток срабатывания варистора СН2-1А при 430 вольтах».

Система на базе ChromaDB и флагманской модели эмбеддингов выдала уверенный ответ: «Рабочий ток составляет 25 ампер, время срабатывания 15 наносекунд». Прибор с такими параметрами сгорел бы на стенде за две секунды.

Когда мы заглянули в поисковую выдачу по служебным инструкциям, выяснилось: реальная таблица с характеристиками варистора СН2-1А получила от векторной базы смехотворный скор 0.61 и осталась на 48-м месте. А на первое место с оценкой 0.86 вылез кусок описания мощного промышленного разрядника Р-27 просто потому, что в нем семь раз встречались слова «ток», «напряжение», «защита» и «срабатывание».

Большие векторные модели не умеют искать точные технические данные. Они ищут похожие по настроению и теме тексты.

Ниже подробный разбор того, почему геометрия многомерных пространств проваливается на артикулах, и как связка из алгоритма 1994 года и тяжелого реранкера полностью убирает галлюцинации из поиска.

Чтобы понять причину сбоя, нужно посмотреть, как устроен Bi-Encoder.

Модель эмбеддингов берет текст из двухсот слов и сжимает его в одну точку в пространстве из 1024 измерений. В этом пространстве направление вектора задается общим смысловым полем документа.

Если в документе много слов об электробезопасности, реле и трансформаторах, вектор документа улетает в кластер «электротехника». Когда пользователь задает вопрос, вектор вопроса летит в тот же самый кластер.

Но маркировка детали «СН2-1А» для модели эмбеддингов — это просто редкая последовательность из трех субтокенов. Она весит меньше одного процента от общей длины вектора. Векторное пространство проглатывает эту деталь: документ с похожими рассуждениями об электричестве, но с другой деталью внутри, оказывается к вопросу ближе, чем сухая табличная строчка с точным артикулом.

Плотный векторный поиск принципиально не различает «Договор 48-А» и «Договор 48-Б», «ГОСТ 12.1.004» и «ГОСТ 12.1.005», «винт М3» и «винт М8». Для геометрии векторов это статистический шум.

Когда в 2023 году все бросились строить векторные базы, индустрия выбросила на свалку тридцать лет наработок классического информационного поиска. И совершенно зря.

Алгоритм BM25 (Best Matching 25), разработанный еще в девяностые годы, работает на базе инвертированного индекса. Ему плевать на семантику и философский контекст. Он считает точные совпадения редких слов.

Если пользователь спросил про «СН2-1А», BM25 мгновенно понимает, что токен «СН2-1А» встречается во всей базе из ста тысяч страниц ровно два раза. Это придает документу гигантский вес по шкале IDF (Inverse Document Frequency).

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

Мы поднимаем два независимых поисковых движка: BM25 для вылова точных артикулов и дат, и плотные эмбеддинги для понимания синонимов и перефразировок.

Результаты объединяются через алгоритм слияния рангов (Reciprocal Rank Fusion):

RRF_score = (1 / (60 + позиция_в_BM25)) + (1 / (60 + позиция_в_векторах))

Если документ попал в верхние строчки обоих списков, его финальный балл взлетает. Если он найден только по точному артикулу через BM25, он все равно гарантированно попадает в топ-20 кандидатов.

После первого этапа у нас на руках оказывается двадцать разношерстных кандидатов. Доверять их языковой модели еще нельзя: среди них полно мусора.

Здесь вступает модель второго уровня — Cross-Encoder (например, bge-reranker-v2-m3).

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

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

Прогнать всю базу через Cross-Encoder невозможно: это потребовало бы часов вычислений на каждый запрос. Но переранжировать двадцать кандидатов занимает всего 35 миллисекунд.

Даже идеальный гибридный поиск выдаст кашу, если документ нарезан на куски по количеству символов.

Если разрезать PDF-файл посередине таблицы, кусок превращается в бессмысленный набор цифр: «250 | 5 | 120 | Да». Поиск найдет этот кусок, но модель не поймет, к какой колонке относится каждое число.

Мы внедрили метод связанных родительских контекстов (Parent-Child Indexing).

Документ нарезается на два слоя:

• Дочерние микро-фрагменты (150 токенов): используются только для поисковых индексов BM25 и векторной базы.
• Родительские смысловые блоки (800-1200 токенов): содержат таблицу целиком вместе с заголовком главы и пояснениями.

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

Вот реальный прогон на тестовом запросе по каталогу компонентов: «Укажи артикул и напряжение варистора СН2-1А».

Вывод в консоли:

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

Гибридный пайплайн с первой попытки положил в контекст точный паспорт изделия с нужным артикулом ЭЛ-8924 и напряжением 430В.

Векторные базы отлично подходят для поиска похожих картинок или рекомендаций музыки.

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