Реализация Multi-Index RAG: объединение нескольких источников

Почему Multi-Index RAG: один индекс не тянет разнородные данные

Единый индекс строится в предположении, что все данные говорят на одном языке. На практике в него попадают регламенты в PDF, тикеты поддержки, выгрузки из учётной системы, письма и сканы договоров. У них разная структура, длина фрагмента, терминология и плотность фактов, а одна модель представления вынуждена усреднить всё это в общее пространство признаков.

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

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

Разбираем, как это закрывается: источники разносятся по нескольким индексам под свой тип данных, запрос маршрутизируется по ним, а результаты объединяются и переранжируются на общем уровне.

Что даёт объединение индексов: качество ответов и устойчивость

Один индекс — это одна точка зрения на данные: он хорошо ловит либо смысл, либо точные термины, а недоступность источника превращается в пустой ответ. Объединение нескольких индексов снимает обе проблемы: качество растёт не за счёт переобучения модели, а потому что на вход генерации попадает более полная и разнородная выдача.

Точность ответов и полнота покрытия

Плотный векторный индекс находит близкое по смыслу, но теряет артикулы, аббревиатуры и редкие термины; разреженный лексический — наоборот. Мы объединяем их гибридно — например, через Elasticsearch с полями BM25 и kNN, — результаты сливаем ранговым слиянием и прогоняем через переранжировщик. На замерах это даёт рост доли верных ответов с 60% до 85% и полноты покрытия — доли вопросов, на которые в базе вообще есть опора, — с 70% до 95%. Время отклика при этом остаётся в бюджете: слияние и переранжирование добавляют порядка 200 мс при целевом отклике до двух секунд.

Устойчивость к отказу отдельных источников

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

Схемы Multi-Index RAG: маршрутизация, слияние, федерация

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

Маршрутизация запроса

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

Слияние результатов

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

Федеративный поиск опрашивает все коллекции параллельно и не зависит от классификатора — ценой задержки и раздутого контекста. Гибридный поиск добавляет к векторному сравнению лексическое, поэтому артикулы и аббревиатуры перестают теряться. Оба варианта собираются на Elasticsearch — слияние и ранжирование берёт на себя поисковый слой.

Как мы внедряем мультииндексный поиск: этапы работ

Любое решение класса Multi-Index RAG начинается не с модели, а с инвентаризации знаний. Ниже — порядок работ так, как он идёт в проекте: от карты данных до передачи решения вашей команде сопровождения.

Аудит источников и карта данных

1. Инвентаризация: корпоративная база знаний, файловые хранилища, учётные системы, тикеты, регламенты. По каждому источнику — формат, объём, частота изменений, владелец и права доступа.
2. Карта данных: фиксируем, какие вопросы закрывает каждый источник, где данные дублируются и где противоречат друг другу. Результат — документ, по которому строится схема индексации.
3. Схема индексации: под каждый тип данных — отдельный индекс, своя стратегия разбиения на фрагменты и набор метаданных: дата, владелец, уровень доступа, ссылка на первоисточник.

Настройка поиска и проверка на эталонных вопросах

• Настройка поиска: маршрутизация запроса по релевантным индексам, объединение и переранжирование выдачи, правила цитирования. Ответ без ссылки на фрагмент источника считаем невалидным.
• Проверка на эталонных вопросах: набор из 80–120 вопросов с известными ответами, включая те, ответа на которые в базе нет. Смотрим, попадает ли нужный фрагмент в верхние позиции и умеет ли система честно сказать, что данных нет.
• Итерации: правим разбиение, метаданные и веса — до стабильного качества на всём наборе, а не на отдельных удачных примерах.
• Передача в эксплуатацию: регламент обновления индексов при изменении источников, мониторинг доли вопросов без ответа, инструкции для владельцев данных.

Артефакты внедрения: схемы, конфигурации, регламенты

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

Схема потоков данных

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

Регламенты обновления и доступа

• Переиндексация: триггеры по расписанию и по событию, порядок полной и частичной пересборки.
• Политики доступа: разграничение по ролям на уровне индекса и документа, наследование прав из исходных систем, журналирование выдачи.
• Эксплуатационная документация: порядок приёмки нового источника, откат на предыдущую версию индекса, зоны ответственности.

Кейс: как выросла точность ответов после объединения источников

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

Исходная ситуация

Доля верных ответов держалась около 60%: справочные вопросы закрывались, а всё, что требовало сопоставить обращение с пунктом регламента, — нет. Инженеры перепроверяли ассистента вручную, время подготовки ответа доходило до 40 минут, а каждая четвёртая тема возвращалась повторно.

Причина была не в модели, а в разорванном контексте: поиск шёл по одному источнику, и релевантный фрагмент из регламента не доходил до генерации.

Что изменилось после внедрения

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

Точность выросла не за счёт смены модели, а за счёт полноты контекста: ответ опирается на два-три источника, а ссылка позволяет проверить вывод за секунды. Разбор с руководителем поддержки — в отзыве ниже.

Чем отличается слияние результатов от федеративного поиска?

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

Ключевая сложность — несопоставимость оценок. Баллы лексического поиска и близость векторного представления лежат в разных диапазонах, а приведение к общему отрезку искажает хвосты: редкий, но точный фрагмент получает низкую нормализованную оценку. Поэтому источники отдают порядок, а не балл, и списки объединяются рангово.

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

Федеративная схема нужна там, где свести источники в один пул нельзя: разграничение прав, разные регламенты, данные не покидают свой контур. Каждый узел ранжирует сам, объединение идёт по метаданным и квотам на источник, а переранжирование возможно только локально. Минус — «говорливый» источник перетягивает контекст на себя.

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

Технические сомнения: качество, задержки, обновление данных

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

Как быстро обновляются данные и что с устареванием?

У каждого индекса свой регламент свежести: критичные источники обновляются по событию изменения, справочники — по расписанию. Фрагменты несут дату и версию источника, поэтому видно, на каких данных построен ответ.

Как разграничиваются права доступа к источникам?

Права проверяются до попадания фрагментов в контекст модели — иначе данные утекут через ответ. Фильтр применяется к каждому индексу отдельно, все обращения логируются.

Выдержит ли инфраструктура рост запросов?

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

Кто поддерживает решение после запуска?

Передаём регламент подключения нового источника, правила переиндексации и панель метрик. Сопровождение — отдельный режим: плановые обновления, разбор инцидентов, помощь при расширении.

Обсудим вашу задачу и вернёмся с оценкой и планом

Разговор о Multi-Index RAG начинается не с выбора модели, а с разбора задачи: какие вопросы система должна закрывать, где лежат ответы и кто ими пользуется. От этого зависит, сколько индексов реально нужно и как маршрутизировать запросы между ними.

Чтобы вернуться с оценкой объёма работ и планом внедрения, а не с общими словами, нужны вводные по данным и сценариям:

• Источники: какие системы и файлы содержат ответы, как часто обновляются, есть ли выгрузки в машинно-читаемом виде.
• Требования к данным: структура, язык, наличие метаданных и разметки, кто отвечает за актуальность.
• Права доступа: как разграничить выдачу по ролям, чтобы один индекс не показывал чужое.
• Сценарии запросов: типовые формулировки пользователей и что считаем точным и полным ответом.
• Объём: сколько документов и запросов в день, какой рост ожидаем.
• Ограничения: где размещаем контур, что нужно логировать и хранить.
• Критерии приёмки: по каким метрикам качества считаем решение работающим.

Опишите задачу в свободной форме — вернёмся с оценкой объёма работ, планом внедрения и составом команды. Если части вводных пока нет, это не блокирует старт: уточним на первом разборе.

• Сваливают разнородные данные в один индекс. Регламенты, таблицы, переписка и презентации устроены по-разному; без разделения по индексам система выдаёт усреднённый ответ, который плохо работает и для точной цифры, и для развёрнутого пояснения.
• Не описывают правила маршрутизации. Ждут, что система сама догадается, какой источник считать первоисточником; при расхождении версий ответ начинает зависеть от случайного порядка обработки, а не от логики предметной области.
• Оставляют дубли и устаревшие копии. Старые редакции документа конкурируют с новыми за место в выдаче, и ответ теряет достоверность, хотя поиск формально «сработал».
• Проверяют качество на нескольких удачных вопросах. Без набора проверочных вопросов с эталонными ответами невозможно отличить реальный рост точности от везения; изменения в конфигурации начинают вносить наугад.
• Не разграничивают права доступа между источниками. Объединение индексов легко подтягивает в ответ фрагмент, который сотруднику видеть не положено, — а обнаруживается это уже после запуска.
• Выбирают схему объединения по моде, а не по задаче. Слияние и федеративный поиск решают разные задачи; выбор «потому что так современнее» приводит к лишним задержкам там, где хватило бы простой маршрутизации.
• Запускают сразу на всех источниках. Без поэтапного включения — сначала один проверенный массив, затем остальные — невозможно понять, какой источник испортил качество ответов.