Чому RAG-індексація корпоративних баз знань дає сміттєві відповіді
RAG-індексація корпоративної бази знань виглядає як завантаження документів у векторне сховище, але відповідь модель будує не за сторінкою цілком, а за кількома знайденими фрагментами.
Якщо фрагмент зібрано неправильно, модель не промовчить — вона акуратно добудує відповідь і видасть її з такою ж впевненістю, як і правильну.
Перше джерело збоїв — різнорідна розмітка. Сторінки в Confluence, Notion і SharePoint живуть вкладеними блоками, врізками та списками завдань; плаский парсер знімає ієрархію, і заголовок розділу відривається від свого тіла. У видачу потрапляють кроки із сусідньої інструкції, а порядок дій втрачає сенс.
Друге — версії та копії. Одна інструкція лежить у трьох місцях і в двох редакціях; після розбиття на фрагменти вони майже не відрізняються за вектором, і пошук по документації витягує будь-яку з них.
Розірвані таблиці додають своє: параметри виїжджають без заголовків стовпців, а вкладення — схеми та регламенти у файлах — до індексу не потрапляють узагалі.
У сумі це дає нерелевантні відповіді при формально працюючому пошуку: модель отримує суміжні абзаци замість потрібного пункту й заповнює прогалини здогадом. Якість видачі падає не через модель, а через те, що їй подали.
Далі розбираємо, як це закривається: структурний розбір розмітки, розбиття за смисловими блоками замість фіксованої довжини, дедуплікація редакцій і окремі проходи для таблиць і вкладень.
Що змінюється після керованої перебудови пошуку по базі
Перше, що змінюється, — видача перестає залежати від того, чи вгадав співробітник формулювання. Гібридний пошук поєднує точний збіг за словами й векторну близькість, а переранжування піднімає вгору фрагменти, де справді є відповідь.
Індексуємо простори Confluence, Notion і SharePoint в єдиному RAG-контурі: джерела залишаються на своїх місцях, змінюється лише шар пошуку.
Повнота видачі та опора на джерело
До перебудови сторінки індексувалися цілком: довгий документ розмивався в один вектор, і потрібний абзац не потрапляв у топ. Після нарізки на смислові блоки з перекриттям контексту частка запитів, де правильний фрагмент опинився в першій п’ятірці, зросла з 61% до 93%.
Відповіді без опори на джерело скоротилися приблизно вчетверо — якщо релевантного блоку немає, система повідомляє про це, а не добудовує формулювання.
Швидкість відповіді та актуальність бази знань
Повнота видачі марна, якщо відповідь іде пів хвилини: люди повертаються до ручного пошуку по папках.
Ми тримаємо швидкість відгуку передбачуваною на піковому навантаженні — черга запитів обслуговується за одиниці секунд, бо видача й переранжування кешуються за нормалізованим запитом.
Оновлення індексу відбувається за подією: правка сторінки потрапляє в пошук за хвилини, а не протягом доби, і биті посилання на перейменовані розділи більше не спливають.
Підсумок вимірюється не «стало зручніше», а часткою відповідей із підтвердженим джерелом, часом відгуку під навантаженням і тим, як швидко база знань наздоганяє зміни. Далі — як ці метрики виглядають на конкретній базі до й після.
Повна, інкрементальна та гібридна перебудова: що вибрати
Режим оновлення індексу — частина зобов’язань за сервісом, а не деталь реалізації: від нього залежить, як швидко нова відповідь з’являється в пошуку й скільки навантаження йде в початкові системи.
Вибір визначається двома вимірами — часткою документів, що змінюються за добу, і допустимим відставанням індексу від правки. Без них сервіс або відповідає за застарілими версіями, або постійно перечитує сховища цілком.
Порівнюємо три режими за обсягом даних за цикл, чутливістю до частоти правок і вимогами до доступності під час збирання.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Повна перебудова | Рідкі правки пакетами, є вікно обслуговування | Читає весь корпус: на великому обсязі цикл триває годинами |
| Інкрементальне збирання | Рівномірний точковий потік правок | Потрібно відстежувати зміни й видалення; при зміні розмітки накопичуються розходження |
| Гібридний індекс | Змішані джерела: одні змінюються часто, інші стабільні | Два контури оновлення, потрібна звірка повноти й чищення застарілих фрагментів |
Як вибрати режим під потік змін
Дивимося на профіль правок, а не на розмір бази. Рівномірний потік у частки відсотка сторінок за добу закриває інкрементальне збирання; рідкі масові зміни структури або розмітки — привід періодично запускати повну й тримати гібридний індекс.
Перемикання робимо без простою: нова версія збирається поряд, вмикається після перевірок на контрольних питаннях, відкат — на попередню версію.
Етапи RAG-індексації: від аудиту джерел до приймання
Порядок робіт однаковий для будь-якого набору джерел. Спочатку фіксуємо, що реально лежить у базах і як часто змінюється, і лише потім будуємо індекс — інакше частина документів не потрапляє в пошук, а частина живе застарілими копіями.
- Аудит джерел. Обходимо простори й розділи Confluence, Notion і SharePoint: обсяг, частота правок, власники, дублі. Закриті розділи або виключаємо, або позначаємо рівнем доступу, щоб права зберігалися і у видачі.
- Схема розбиття. Ріжемо за смисловими блоками — заголовки, таблиці, кроки інструкцій, а не за фіксованим вікном. Єдиний розмір фрагмента для регламенту й листування дає уривки смислу на стиках.
- Метадані документа. До кожного фрагмента прив’язуємо джерело, розділ, власника, дату зміни й рівень доступу. Без них не працюють фільтри за просторами й відкликання документа з індексу.
- Конвеєр оновлення. Налаштовуємо інкрементальну переіндексацію за подіями зміни й видалення, повний прохід за розкладом — як страховку від пропущених подій.
- Перевірка якості. Збираємо контрольний набір питань з еталонними відповідями й дивимося, чи потрапляє потрібний фрагмент у перші позиції. Промахи розбираємо окремо: найчастіше це дублі або застаріла версія.
- Передавання в експлуатацію. Фіксуємо регламент переіндексації, відповідального за якість бази й порядок підключення нових джерел. Приймання відбувається на ваших даних, а не на демонстраційному наборі.
Схеми розбиття тексту, політики доступу та регламенти оновлення
Індексація — не разовий запуск, а набір артефактів, які залишаються у вашому контурі й далі живуть самостійним життям. Передаємо їх разом із працюючим збиранням: за кожним пунктом у вашої команди є файл або регламент, а не усні домовленості.
- Карта джерел. Які простори, розділи й бази потрапляють в індекс, хто власник кожного, що виключено свідомо і за чиїм рішенням.
- Правила успадкування прав. Доступи з початкової системи переносяться в індекс за тією ж ієрархією: співробітник отримує у відповіді лише ті фрагменти, що відкриті йому в самій вікі або сховищі.
- Конфігурації збирання. Схеми розбиття за типами документів — регламенти, тікети, таблиці, листування — з розміром фрагмента й перекриттям під кожен тип.
- Регламент оновлення. Частота переіндексації за джерелами, обробка видалених і переміщених документів, поведінка при зміні прав доступу.
- Метрики якості. Контрольний набір питань, частка відповідей із посиланням на підтверджувальний фрагмент, частка чесних відмов «не знаю», динаміка за ітераціями.
- Інструкція для команди. Як підключити нове джерело, як відкликати доступ, що робити, якщо відповідь розходиться з документом-джерелом.
Підтримка без нас
Усе перелічене — робочі конфігурації й текстові регламенти, а не закритий код: нове джерело або змінена політика доступу правляться вашими інженерами за одну ітерацію.
Ми підключаємося, коли змінюється сам корпус документів — тоді переглядаємо схеми розбиття й пороги метрик якості.
Кейс: як скоротили частку нерелевантних відповідей у підтримці
До впровадження база знань жила в трьох системах: регламенти — в Confluence, продуктові нотатки — в Notion, шаблони листів — у SharePoint.
Пошук працював за ключовими словами, тому на питання «як оформити повернення» оператор отримував десяток сторінок і сам вирішував, яка з них чинна. Відповіді йшли клієнтам без опори на документ, а розходження спливали вже на етапі повторного звернення.
Ми звели джерела в один індекс, розбили документи на фрагменти за ієрархією заголовків і зберегли метадані: власник розділу, дата останньої правки, статус «чинний/архів».
У контур відповіді додали поріг упевненості — якщо опори в документах не вистачає, система не вигадує, а передає питання оператору разом із знайденими фрагментами.
Динаміка метрик
| Показник | До | Після |
|---|---|---|
| Відповіді без опори на документ | 38% | 6% |
| Частка нерелевантних відповідей | 31% | 8% |
| Час підготовки відповіді | 7 хвилин | 45 секунд |
| Звернення з повторним розбором | 44% | 13% |
| Відповіді з посиланням на джерело | немає | 100% |
Зворотний зв’язок команди
Оператори перестали звіряти три системи вручну: посилання на вихідний документ знімає спір про те, звідки взялося формулювання. Керівник підтримки відзначає інше: нові співробітники виходять на самостійні відповіді помітно швидше, бо система підказує, де лежить норматив.
Правки в базі стали точковими. За логами видно, який фрагмент дав неправильну відповідь, — правиться конкретний розділ, а не весь регламент, і після переіндексації виправлення одразу потрапляє у відповіді.
Що робити, якщо база знань уже проіндексована стороннім сервісом?
Спочатку з’ясовуємо, що залишилося від стороннього сервісу: параметри розбиття на фрагменти, склад метаданих, урахування прав доступу.
Якщо це є у вивантаженні — переносимо налаштування й добудовуємо втрачене; якщо віддано лише готові вектори без структури, чистіше переіндексувати джерела напряму. Індекс без метаданих майже завжди дає гіршу видачу.
Дві втрати видно одразу. Права: документи індексувалися під службовим обліковим записом — успадкування втрачено, у відповідь потрапляють сторінки, недоступні тому, хто запитує.
Дублікати: одна інструкція в різних просторах Confluence, у вкладенні та в особистій копії дає три схожі фрагменти й витісняє решту. Лікуємо дедуплікацією за хешем вмісту й канонізацією посилань.
М’яка міграція без зупинки: новий індекс збирається поряд зі старим, наповнюється знімком джерел і наздоганяється за змінами. Запити поки йдуть у старий, а на новий надходить та сама вибірка в тіньовому режимі — якість порівнюємо на живому потоці.
Перемикання за прапорцем, коли метрики збіглися; відкат тим самим прапорцем, старий індекс тримаємо в запасі кілька тижнів.
Підходи порівнюємо за трьома сценаріями: перенесення налаштувань — швидко, але успадковує старі помилки розбиття; паралельний запуск — дорожчий за ресурсами, зате перевіряє якість на реальних питаннях; повна переіндексація — найпередбачуваніша, потребує вікна на перший прохід.
Приймання — еталонні питання з відомими відповідями: частка потраплянь потрібного фрагмента в першу трійку й нуль відповідей за документами поза правами користувача.
Технічні сумніви: права доступу, розмітка, втрата контексту
Сумніви на етапі оцінки зазвичай одні й ті самі: хто побачить фрагмент, що робити з таблицями й вкладеннями, чи не розсиплеться смисл під час нарізки.
Усе це закривається на рівні конвеєра індексації: у кожного фрагмента є власник і метадані, а пошук фільтрує кандидатів за ними до того, як текст потрапить у модель.
Як успадковуються права доступу на фрагменти?
Права читаються з джерела разом зі вмістом — сторінка, простір, групи, персональні винятки — і зберігаються в індексі поряд із фрагментом. Пошук перевіряє їх для конкретного користувача до видачі: недоступний фрагмент не потрапляє у вибірку, і модель його не бачить. Зміна прав підхоплюється під час наступної синхронізації.
Таблиці та вкладення перетворяться на кашу?
Таблиці розбираються структурно: рядок і заголовок стовпця зберігаються, інакше значення втрачає сенс. Вкладення — документи, презентації, PDF — ідуть окремим конвеєром і прив’язуються до батьківської сторінки.
У кожного фрагмента залишається посилання на вихідний розділ, відповідь можна перевірити в першоджерелі.
Як не втратити контекст під час нарізки?
Фрагменти ріжуться за смисловими межами з перекриттям, а заголовки розділів і шлях за деревом сторінок пишуться в метадані. У модель надходить не одиночний фрагмент, а фрагмент разом із ієрархією. Це знижує частку відповідей, де вирвана з контексту фраза трактується неправильно.
Що з застарілими сторінками та суперечностями?
Версії дедуплікуються за вмістом, у разі конфлікту пріоритет надається свіжішому й підтвердженому власником фрагменту. Архівні простори й чернетки виключаються з індексу явним правилом.
Документи різними мовами?
Багатомовні джерела індексуються в єдиному векторному просторі: питання й документ приводяться до спільного подання, тому релевантне знаходиться незалежно від мови сторінки. Відповідь формулюється мовою питання.
Обговоримо задачу: з чого почнемо і що потрібно від вас
Щоб повернутися з оцінкою, а не із загальними словами, нам потрібен мінімум ввідних: де лежать знання, як швидко вони змінюються й хто відповідає за доступи. Перший розбір задачі — це одна розмова з інженером, на якій ми розбираємо структуру джерел і домовляємося про план робіт. Нижче — що підготувати до цієї зустрічі.
- Аудит джерел. Перелік просторів у Confluence, баз Notion, бібліотек SharePoint, файлових сховищ і внутрішніх порталів — із позначкою, що реально використовується в роботі, а що залишилося архівом і в індекс не піде.
- Частота правок. Як швидко застарівають сторінки, чи є регламент публікації, хто стежить за актуальністю й чи потрібно переіндексовувати все або достатньо зміненого.
- Доступи та вивантаження. Сервісний обліковий запис із правом читання, вивантаження сторінок у відкритому форматі або разовий знімок бази. Якщо контур закритий — обговорюємо збирання всередині вашої мережі.
- Обмеження щодо даних. Розділи, які індексувати не можна: кадри, договори, персональні дані. Винятки закладаємо в правила збору на старті, а не після.
- Очікувані сценарії. 5–10 реальних питань, на які асистент має відповідати, — за ними видно, які типи документів критичні, а які можна не чіпати.
- Відповідальний за приймання. Одна людина з вашого боку, яка підтверджує повноту відповідей і вирішує спірні випадки на етапі налаштування.
Після розбору ми надсилаємо план робіт: склад індексу, режим оновлення, схему перевірки відповідей на тестовому наборі й оцінку термінів за етапами. Опишіть задачу — повернемося з оцінкою та планом.
