Чому Multi-Index RAG: один індекс не витягує різнорідні дані
Єдиний індекс будується в припущенні, що всі дані говорять однією мовою. На практиці в нього потрапляють регламенти у PDF, тікети підтримки, вивантаження з облікової системи, листи й скани договорів.
У них різна структура, довжина фрагмента, термінологія й щільність фактів, а одна модель подання змушена усереднити все це в спільний простір ознак.
Вузьке місце виникає на етапі відбору кандидатів, до будь-якого синтезу відповіді. Щільні вектори добре уловлюють смислову близькість, але розмивають точні ідентифікатори — артикул, номер договору, код помилки, прізвище: після усереднення вони майже не розрізненні.
Лексичний пошук за ключовими словами, навпаки, надійний на точних збігах і безпорадний там, де питання задано перефразуванням.
Далі деградація накопичується: у верхню частину видачі потрапляють фрагменти з нерелевантного джерела, переранжування працює за свідомо зашумленими кандидатами, і модель добудовує відповідь за змістом, а не за документом.
Середня релевантність при цьому виглядає прийнятно — провал видно не в метриках, а на конкретних запитах, де відповідь упевнено неправильна.
Розбираємо, як це закривається: джерела розносяться за кількома індексами під свій тип даних, запит маршрутизується між ними, а результати об’єднуються й переранжуються на спільному рівні.
Що дає об’єднання індексів: якість відповідей і стійкість
Один індекс — це одна точка зору на дані: він добре вловлює або зміст, або точні терміни, а недоступність джерела перетворюється на порожню відповідь.
Об’єднання кількох індексів знімає обидві проблеми: якість зростає не за рахунок перенавчання моделі, а тому що на вхід генерації потрапляє повніша й різнорідніша видача.
Точність відповідей і повнота покриття
Щільний векторний індекс знаходить близьке за змістом, але втрачає артикули, абревіатури й рідкісні терміни; розріджений лексичний — навпаки.
Ми об’єднуємо їх гібридно — наприклад, через Elasticsearch з полями BM25 і kNN, — результати зливаємо ранговим злиттям і проганяємо через переранжувальник.
На вимірюваннях це дає зростання частки правильних відповідей з 60% до 85% і повноти покриття — частки питань, на які в базі взагалі є опора, — з 70% до 95%.
Час відгуку при цьому залишається в бюджеті: злиття й переранжування додають близько 200 мс за цільового відгуку до двох секунд.
Стійкість до відмови окремих джерел
Другий ефект — відмовостійкість. Кожне джерело опитується паралельно, зі своїм таймаутом і запобіжником: якщо індекс недоступний або деградував, запит не падає повністю — видача збирається за рештою, а переранжувальник вимикається першим, щоб зберегти відгук.
Ми логуємо частку запитів, обслугованих за неповним набором джерел: у нормі вона нульова, за збою зростає, але відповіді продовжують надходити, і деградація видна в метриках раніше, ніж її помічає користувач.
Схеми Multi-Index RAG: маршрутизація, злиття, федерація
Схема об’єднання джерел задає, скільки колекцій опитується на кожне питання і як їхні відповіді зводяться в один контекст. Нижче — три підходи, між якими зазвичай обирають.
Маршрутизація запиту
Класифікатор або компактна модель відносить питання до однієї-двох колекцій, решта не опитуються. Це найшвидший варіант за відгуком, але помилка класифікатора необоротна: документ із невибраної колекції генератор уже не побачить. Страховка — правило «нижче порога впевненості опитуємо всі індекси».
Злиття результатів
Кожен індекс повертає свій ранжований список, і його потрібно звести в єдиний порядок — взаємним ранговим голосуванням або зваженими оцінками. Схема не потребує навчання, але чутлива до ваг: колекція з довгими документами інакше перетягує видачу.
Федеративний пошук опитує всі колекції паралельно й не залежить від класифікатора — ціною затримки й роздутого контексту. Гібридний пошук додає до векторного порівняння лексичне, тому артикули й абревіатури перестають губитися. Обидва варіанти збираються на Elasticsearch — злиття й ранжування бере на себе пошуковий шар.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Маршрутизація запиту | Колекції розділені за темами, важливий швидкий відгук | Помилка класифікатора відсікає потрібний документ |
| Злиття результатів | Джерела перетинаються, потрібен єдиний порядок | Потребує калібрування ваг між індексами |
| Федеративний пошук | Колекції непорівнянні, важлива повнота | Зростають затримка й обсяг контексту |
| Гібридний пошук | У запитах є коди, артикули, вузькі терміни | Дорожча індексація, потрібні обидва типи індексів |
Як ми впроваджуємо мультиіндексний пошук: етапи робіт
Будь-яке рішення класу Multi-Index RAG починається не з моделі, а з інвентаризації знань. Нижче — порядок робіт так, як він іде в проєкті: від карти даних до передачі рішення вашій команді супроводу.
Аудит джерел і карта даних
- Інвентаризація: корпоративна база знань, файлові сховища, облікові системи, тікети, регламенти. За кожним джерелом — формат, обсяг, частота змін, власник і права доступу.
- Карта даних: фіксуємо, які питання закриває кожне джерело, де дані дублюються і де суперечать одне одному. Результат — документ, за яким будується схема індексації.
- Схема індексації: під кожен тип даних — окремий індекс, своя стратегія розбиття на фрагменти й набір метаданих: дата, власник, рівень доступу, посилання на першоджерело.
Налаштування пошуку й перевірка на еталонних питаннях
- Налаштування пошуку: маршрутизація запиту за релевантними індексами, об’єднання й переранжування видачі, правила цитування. Відповідь без посилання на фрагмент джерела вважаємо невалідною.
- Перевірка на еталонних питаннях: набір із 80–120 питань із відомими відповідями, включно з тими, відповіді на які в базі немає. Дивимося, чи потрапляє потрібний фрагмент у верхні позиції і чи вміє система чесно сказати, що даних немає.
- Ітерації: правимо розбиття, метадані й ваги — до стабільної якості на всьому наборі, а не на окремих вдалих прикладах.
- Передача в експлуатацію: регламент оновлення індексів у разі зміни джерел, моніторинг частки питань без відповіді, інструкції для власників даних.
Артефакти впровадження: схеми, конфігурації, регламенти
Після впровадження Multi-Index RAG у замовника залишається не презентація, а комплект робочих артефактів, за якими система живе й розвивається без нас. Кожен документ прив’язаний до конкретного вузла: індексів, маршрутизатора запитів, шару доступу до даних. Перелік нижче фіксує, що саме передається і що в кожному артефакті описано.
Схема потоків даних
- Маршрутизація запиту: який індекс опитується першим, за якими ознаками запит іде в решту, де спрацьовує об’єднання видачі.
- Карта джерел: перелік сховищ, їхній формат, частота змін і власник на боці замовника.
- Конфігурації індексів: параметри розбиття тексту, метрика близькості, ваги під час злиття результатів — із поясненням, що змінюється при додаванні нового джерела.
- Точки деградації: поведінка системи за недоступності одного з індексів і режим відповіді за неповною видачею.
Регламенти оновлення й доступу
- Переіндексація: тригери за розкладом і за подією, порядок повного й часткового перезбирання.
- Політики доступу: розмежування за ролями на рівні індексу й документа, успадкування прав із вихідних систем, журналювання видачі.
- Експлуатаційна документація: порядок приймання нового джерела, відкат на попередню версію індексу, зони відповідальності.
Кейс: як зросла точність відповідей після об’єднання джерел
Клієнт — сервісна компанія, де знання розподілені між внутрішньою базою, архівом звернень і регламентами в документах. Асистент відповідав лише за базою, тому на складені питання на кшталт «строк ремонту за договором із відстрочкою» видавав упевнену, але неправильну відповідь.
Початкова ситуація
Частка правильних відповідей трималася близько 60%: довідкові питання закривалися, а все, що вимагало зіставити звернення з пунктом регламенту, — ні. Інженери переперевіряли асистента вручну, час підготовки відповіді сягав 40 хвилин, а кожна четверта тема поверталася повторно.
Причина була не в моделі, а в розірваному контексті: пошук ішов за одним джерелом, і релевантний фрагмент із регламенту не доходив до генерації.
Що змінилося після впровадження
Ми зібрали кілька незалежних індексів — базу в Confluence, архів звернень і файлові регламенти — і розвели їх за типами запитів.
Маршрутизація надсилає питання лише до потрібних індексів, а результати об’єднуються за позиціями й вагами джерел, а не за сирими оцінками близькості: фрагмент, перший у слабкому індексі, більше не перебиває точне влучання в сильному.
| Показник | До | Після |
|---|---|---|
| Частка правильних відповідей | ~60% | ~90% |
| Час підготовки відповіді | 40 хв | 6 хв |
| Повторні звернення за темою | ~25% | ~8% |
| Відповідей із посиланням на джерело | не рахували | усі |
Точність зросла не за рахунок зміни моделі, а за рахунок повноти контексту: відповідь спирається на два-три джерела, а посилання дає змогу перевірити висновок за секунди. Розбір із керівником підтримки — у відгуку нижче.
Чим відрізняється злиття результатів від федеративного пошуку?
Різниця — у точці, де зустрічаються відповіді джерел, і в тому, чи є в них спільна шкала. За федеративного пошуку запит іде в кожен індекс окремо, і джерело повертає найкращі фрагменти за своїми правилами.
Злиття результатів зводить кандидатів в один пул до ранжування — тоді в них з’являється спільний порядок.
Ключова складність — непорівнянність оцінок. Бали лексичного пошуку й близькість векторного подання лежать у різних діапазонах, а приведення до спільного відрізка спотворює хвости: рідкісний, але точний фрагмент отримує низьку нормалізовану оцінку. Тому джерела віддають порядок, а не бал, і списки об’єднуються рангово.
Далі вступає переранжування. Пул збирається по кілька кандидатів із кожного індексу, дублікати згортаються, і один прохід важкої моделі за повними текстами фрагментів дає єдиний порядок. Точність на верхніх позиціях зростає, але разом з обсягом кандидатів зростає й затримка відповіді.
Федеративна схема потрібна там, де звести джерела в один пул не можна: розмежування прав, різні регламенти, дані не залишають свій контур. Кожен вузол ранжує сам, об’єднання йде за метаданими й квотами на джерело, а переранжування можливе лише локально. Мінус — «говірке» джерело перетягує контекст на себе.
Вибір схеми визначається однорідністю джерел і доступністю текстів. Однорідні корпуси й право читати фрагменти повністю — злиття з переранжуванням.
Гетерогенні джерела з розмежуванням доступу — федеративний шар, поверх якого злиття зводиться до рангового об’єднання всередині дозволеної підмножини.
Технічні сумніви: якість, затримки, оновлення даних
П’ять питань найчастіше спливають на етапі оцінки: чи не зросте час відповіді, як швидко застарівають дані, як розмежовано права, чи витримає інфраструктура навантаження і хто підтримує систему після запуску. Перевіряємо кожен сумнів на пілоті — з метриками на реальних запитах, а не на демо-прикладах.
Чи не зросте затримка відповіді, якщо індексів кілька?
Пошук іде паралельно за всіма індексами: час відповіді визначає найповільніший, а не їхня сума. Бюджет часу й правило відсікання задаємо на етапі проєктування — індекс, що не встиг, пропускається, відповідь будується за рештою.
Як швидко оновлюються дані і що зі старінням?
У кожного індексу свій регламент свіжості: критичні джерела оновлюються за подією зміни, довідники — за розкладом. Фрагменти несуть дату й версію джерела, тому видно, на яких даних побудовано відповідь.
Як розмежовуються права доступу до джерел?
Права перевіряються до потрапляння фрагментів у контекст моделі — інакше дані витечуть через відповідь. Фільтр застосовується до кожного індексу окремо, усі звернення логуються.
Чи витримає інфраструктура зростання запитів?
Індекси масштабуються незалежно: навантаження на рідкісне джерело не гальмує частий. Кешування й черга переіндексації згладжують піки, ємність рахуємо за профілем звернень.
Хто підтримує рішення після запуску?
Передаємо регламент підключення нового джерела, правила переіндексації й панель метрик. Супровід — окремий режим: планові оновлення, розбір інцидентів, допомога при розширенні.
Обговоримо ваше завдання й повернемося з оцінкою та планом
Розмова про Multi-Index RAG починається не з вибору моделі, а з розбору завдання: які питання система має закривати, де лежать відповіді й хто ними користується. Від цього залежить, скільки індексів реально потрібно і як маршрутизувати запити між ними.
Щоб повернутися з оцінкою обсягу робіт і планом впровадження, а не із загальними словами, потрібні вступні щодо даних і сценаріїв:
- Джерела: які системи й файли містять відповіді, як часто оновлюються, чи є вивантаження в машинно-читаному вигляді.
- Вимоги до даних: структура, мова, наявність метаданих і розмітки, хто відповідає за актуальність.
- Права доступу: як розмежувати видачу за ролями, щоб один індекс не показував чуже.
- Сценарії запитів: типові формулювання користувачів і що вважаємо точною та повною відповіддю.
- Обсяг: скільки документів і запитів на день, яке зростання очікуємо.
- Обмеження: де розміщуємо контур, що потрібно логувати й зберігати.
- Критерії приймання: за якими метриками якості вважаємо рішення працюючим.
Опишіть завдання у вільній формі — повернемося з оцінкою обсягу робіт, планом впровадження і складом команди. Якщо частини вступних поки немає, це не блокує старт: уточнимо на першому розборі.
