Індексація документів для RAG (PDF, DOCX, HTML, Markdown)

Індексація документів RAG: де втрачається якість відповідей

Часто асистент відповідає впевнено й неправильно не через модель, а через те, що лежить у пошуковому індексі. Індексація документів RAG — це етап, де якість втрачається непомітно: відповіді виглядають зв'язними, посилання на джерела стоять, а факти в них уже місяць як застаріли. Нижче — чотири поломки, які ми знаходимо в більшості впроваджень.

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

Лікується розпізнаванням із збереженням структури: заголовки, списки й таблиці переносяться в розмітку, а не в суцільний рядок.

Друга — втрата контексту під час пошуку. Якщо документ ріжеться на фрагменти за фіксованою кількістю символів, розривається посеред таблиці чи речення, а заголовок розділу залишається в попередньому шматку.

Пошук знаходить обривок, модель добудовує відповідь за змістом — і виходить правдоподібна вигадка. Тому межі фрагментів прив'язують до смислових блоків і додають у кожен шматок назву розділу, щоб фрагмент був зрозумілий без сусідів.

Третя — застарілі версії файлів у базі знань і розрізнені джерела. Поки файли живуть на мережевому диску, у вікі та в пошті, копії розходяться: правку внесено в одну, пошук віддає іншу, дублікати конкурують за місце у видачі.

Індекс має оновлюватися інкрементально за зміною файлу, позначати попередню редакцію недійсною і зберігати посилання на актуальне джерело.

Нарешті, відсутність перевірки якості: ніхто не вимірює, на скільки запитань асистент відповідає за документом, а на скільки — за здогадом. Далі розбираємо, як це закривається.

Що дає керована індексація: ефект у вимірюваних метриках

Повнота пошуку по базі знань визначається не моделлю, а тим, як корпус розібраний на фрагменти.

Під час індексації документів RAG кожне джерело ріжеться за смисловими блоками — пункт регламенту, таблиця, розділ інструкції, — а не за фіксованою кількістю знаків, із перекриттям на межі сусідніх блоків.

Усередину фрагмента їде набір метаданих: джерело, розділ, редакція, дата набрання чинності. Тому потрібний абзац потрапляє у відповідь, а не розчиняється між двома сусідніми шматками тексту.

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

Час оновлення бази знань вимірюється хвилинами від публікації документа до його появи у відповідях, а не вікном нічного перезбирання всього корпусу — сховище на Qdrant приймає точкові правки без зупинки пошуку.

Третій ефект — зниклий клас відмов «відповідь не за документом». Кожна відповідь несе посилання на фрагмент-джерело, а за низької близькості система чесно повідомляє, що даних немає, замість того щоб добудувати формулювання за здогадом. Це знімає найдорожчий сценарій: впевнена відповідь за скасованою редакцією.

Разом це дає передбачувану базу знань — видно, що в ній лежить, коли оновлювалося і на який документ спирається кожна відповідь.

Порівняння режимів підготовки: PDF, DOCX, HTML і Markdown

Режим підготовки визначає, що потрапить в індекс RAG: зв'язний текст зі збереженою ієрархією чи пласке полотно без заголовків. Для одних джерел текст вилучається напряму, для інших потрібен додатковий прохід, а частина обмежень закладена в самому форматі.

Основна ціна — скани. Розпізнавання дає текст, але не гарантує порядок читання на багатоколонкових сторінках, тому проблемні сторінки перевіряються вручну й позначаються. Інакше в індекс потрапляє зліплений фрагмент, і пошук за ним відповідає неточно. У DOCX і HTML складність не у вилученні, а в очищенні: шаблонна навігація й меню створюють дублі.

Markdown виграє тим, що ієрархія задана заздалегідь — розбір зводиться до читання структури без здогадів. На практиці корпус майже завжди змішаний, тому режими комбінуються: один документ проходить вилучення тексту, сусідній — розпізнавання з перевіркою.

Ми оцінюємо склад джерел за часткою кожного формату і вже потім обираємо схему — від цього залежить, скільки ручних перевірок закладати.

Порядок впровадження: від аудиту корпусу до передачі

Індексація — це не «завантажити папку в пошук», а ланцюжок рішень, кожне з яких потім дорого змінювати: неправильна схема розбиття дає рвані відповіді, а відсутність прав доступу — витік закритих документів у загальну видачу. Тому порядок робіт фіксований: спочатку розбираємося з корпусом, тільки потім збираємо індекс.

1. Аудит корпусу документів. Рахуємо формати й обсяги, шукаємо дублікати й розходження версій, окремо позначаємо скани без текстового шару, вкладені таблиці, документи кількома мовами. Результат — карта корпусу зі списком місць, де вилучення тексту напередодні втратить сенс.
2. Схема розбиття на фрагменти. Визначаємо розмір фрагмента й перекриття між сусідніми, ріжемо за структурою — заголовками й розділами, а не за фіксованою кількістю символів. Мета — щоб фрагмент був самодостатнім і не розривав таблицю чи список посередині.
3. Метадані й права доступу. На кожен фрагмент вішаємо джерело, дату, версію, підрозділ і гриф доступу. Права успадковуються з вихідної системи зберігання, тому співробітник бачить у видачі лише те, що йому дозволено відкрити.
4. Налаштування вилучення за форматами. PDF беремо за текстовим шаром, скани — через розпізнавання, DOCX розбираємо з урахуванням таблиць і стилів, HTML і Markdown — за структурою заголовків. Для кожного формату налаштовуємо свою обробку й перевіряємо її на вибірці.
5. Складання пошукового індексу. Поєднуємо пошук за змістом із повнотекстовим за ключовими словами, артикулами й числами — інакше запити з точними позначеннями провалюються. Переіндексація запускається за розкладом і за подією зміни документа.
6. Перевірка на еталонних питаннях. Збираємо набір питань із наперед відомими відповідями й дивимося частку знайдених джерел, повноту й точність видачі, час відповіді. За результатами правимо схему розбиття й метадані, а не «крутимо налаштування навмання».
7. Передача. Віддаємо конфігурацію індексації, регламент переіндексації, набір еталонних питань і дашборд якості — щоб команда замовника могла перевіряти індекс після кожного оновлення корпусу.

Конфігурації, схеми розбору й регламенти оновлення

Передаємо не «працюючий пошук», а набір артефактів, за якими ваша команда сама піднімає й розвиває базу знань: конфігурації розбору, карту джерел, правила доступу й регламент регулярного оновлення. Нижче — що саме залишається в репозиторії та вікі після здачі.

• Робочі конфігурації індексації. Файли налаштувань за кожним типом джерела: які поля документа потрапляють в індекс, як нарізаються довгі розділи, скільки контексту підклеюється до фрагмента. Конфігурації версіонуються — зміна розбору не потребує перезбирання всієї бази.
• Схема джерел і потоків даних. Карта: звідки приходить документ, через який розбір він проходить, куди потрапляє результат, де зберігається джерельний файл. З картою видно, що зламається, якщо відключиться мережева папка або зміниться структура вивантаження.
• Схеми розбору за форматами. Окремі правила для PDF, DOCX, HTML і Markdown: як витягуються заголовки й таблиці, що робити зі сканами та вкладеними файлами, які документи йдуть у ручну перевірку.
• Регламент оновлення бази знань. Частота переіндексації за кожним джерелом, умови повного перезбирання проти точкового додавання, поведінка під час видалення документа з джерела — застарілі фрагменти йдуть із видачі разом із ним.
• Правила доступу й розмежування. Хто зі співробітників бачить які розділи, як права джерела переносяться в індекс, що відбувається під час зміни ролі користувача.
• Журнал перевірок якості. Набір контрольних питань, за якими перевіряється видача після кожного оновлення: частка правильних влучень, випадки видачі документа без прав, втрати під час розбору таблиць. Прогін відтворюється однією кнопкою.
• Документація й передача. Інструкція з переіндексації, порядок відкату до попереднього знімка бази, розбір типових збоїв і точки, куди дивитися в логах.

З цим набором оновлення бази знань перестає бути окремим проєктом: правка в регламенті чи конфігурації займає хвилини й не потребує нашої участі.

Кейс: база знань підтримки до та після перезбирання

Що було до перезбирання

Підтримка виросла до бази в кілька десятків тисяч документів: регламенти в PDF, інструкції в DOCX, статті порталу в HTML і Markdown.

Індексатор різав їх фіксованим вікном за символами, без урахування структури: заголовок потрапляв в один фрагмент, таблиця умов — в інший, вкладення в індекс не потрапляло взагалі.

Відповіді асистента спиралися на застарілі ревізії та шматки сусідніх розділів: частка відповідей за актуальним розділом трималася близько 60%, пошук потрібного фрагмента займав до 10 секунд, а кожне п'яте звернення оператор закривав вручну — відкривав документ і шукав очима.

Що змінили

Розбір переписали за структурою документа: розмітка заголовків і таблиць зі збереженням ієрархії, метадані версії та строку дії на кожному фрагменті, дедуплікація однакових розділів, окрема обробка вкладень.

Реєстр векторів перенесли в OpenSearch — гібридний пошук за змістом разом із точними термінами й фільтр за чинною ревізією прямо в запиті. Перезбирання стало інкрементальним: оновлюється лише змінений документ, застарілі фрагменти не накопичуються.

Через місяць вимірювань після перезбирання:

• частка відповідей за актуальним розділом — з 60 до 94%;
• час пошуку потрібного фрагмента — з 10 до 1,5 секунди;
• звернення з ручним розбором — з 20 до 4%;
• документи з коректно розібраними таблицями — з 55 до 97%.

Регламент оновлюється — новий фрагмент з'являється у видачі протягом хвилини, попередній зникає з фільтра, тому відкат до старої ревізії залишається можливим за метаданими.

Оператори більше не звіряють версію вручну: асистент відповідає з посиланням на чинний розділ або повідомляє, що підтвердження в базі немає.

Чим відрізняється розбиття за структурою від розбиття за змістом?

Обидва підходи розв'язують одну задачу — перетворити потік тексту на фрагменти для індексу. Різниця в тому, де проходить межа розрізу: за розміткою документа чи за зміною теми. Помилка на цьому кроці не лікується ні моделлю пошуку, ні переранжуванням.

Розбиття за структурою спирається на готову розмітку: заголовки, розділи, абзаци, списки, окремі комірки таблиць. Для регламентів, інструкцій і договорів це виграшна стратегія — фрагмент залишається самодостатнім і не змішує дві теми в одному векторі. Слабке місце — довгий розділ без підзаголовків: він їде в індекс цілком.

Розбиття за змістом рахує близькість сусідніх речень і ріже там, де змінюється тема — це працює на текстах без розмітки: розшифровках, статтях, листуванні. Зворотний бік у тому, що межа може пройти посеред таблиці чи покрокової інструкції, і в індекс піде половина кроку.

Перекриття фрагментів згладжує стики: хвіст попереднього шматка дублюється на початку наступного, зазвичай на 10–20%. Рятує відповіді, що лежать на межі, але роздуває індекс і додає майже однакові результати — їх доводиться відсіювати за схожістю.

На практиці нарізку збирають гібридно: структурні межі як основа, змістове дроблення — усередині великих розділів, із перенесенням заголовка батька в кожен фрагмент.

Вплив нарізки на точність помітніший за зміну моделі пошуку, тому її перевіряють на наборі реальних питань до запуску.

Часті технічні сумніви перед стартом проєкту

Перед стартом ми не показуємо презентацію, а розбираємо корпус документів: які формати, звідки беруться права, хто власник кожного джерела.

П'ять питань нижче повторюються майже в кожному проєкті з індексації документів для RAG — відповіді на них визначають схему індексації, обсяг робіт і те, що реально опиниться в результатах пошуку.

Відповіді ми фіксуємо письмово в технічному описі рішення. Це дешевше, ніж на етапі здачі виявити, що половина архіву — скани, а частина співробітників має бачити лише свій відділ.

Чи можна оновлювати базу без повного перезбирання?

Так. Індексація йде за версіями: перезбираються лише змінені документи, решта береться з попереднього індексу. Попередня версія зберігається, тому відкат до попереднього стану пошуку займає хвилини, а не добу.

Як права доступу потрапляють у результати пошуку?

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

Що робити із суперечливими документами?

Ми не усереднюємо суперечності. Зберігаємо джерело, дату й статус версії, а за конфлікту система показує обидва фрагменти із зазначенням, звідки кожен узято. Пріоритет джерела задає власник документа — це правило налаштовується, а не зашите в код.

Як переконатися, що пошук знаходить потрібне?

Збираємо набір контрольних питань з еталонними фрагментами й вимірюємо частку влучень до та після кожної зміни схеми. Без такого набору будь-яка правка індексації — це правка навмання.

Обговоримо задачу: що знадобиться для оцінки обсягу робіт

Щоб повернутися з оцінкою обсягу корпусу й планом впровадження, доступ до всієї інфраструктури не потрібен — достатньо описати задачу в термінах документів, питань і прав.

Чим конкретніші вихідні дані, тим менше допущень в оцінці й тим раніше стартує пілот на одному розділі: одна тема, живі питання співробітників, перевірка якості відповідей до масштабування на весь масив.

• Склад корпусу: скільки файлів і розділів, де вони лежать — файлове сховище, внутрішній портал, поштовий архів, база знань.
• Формати та їхня якість: PDF зі сканами без текстового шару, DOCX із відстежуваними правками, HTML, Markdown у репозиторії. Скани змінюють обсяг робіт — їм потрібен окремий крок розпізнавання.
• Динаміка: скільки документів додається за місяць, чи є застарілі редакції, які не можна показувати у відповідях.
• Часті питання користувачів: 20–30 реальних формулювань. За ними ми збираємо перевірний набір і до впровадження бачимо, яких даних у корпусі не вистачає.
• Поточна схема прав доступу: які групи що бачать. Від неї залежить розмежування на рівні фрагментів і те, як індексуються документи з обмеженнями.
• Точки повернення відповіді: внутрішній портал, месенджер, робоче місце оператора — від цього залежить формат видачі й посилань на джерело.
• Обмеження: де заборонені зовнішні сервіси, чи потрібні журнали звернень і зберігання історії запитів.

Опишіть задачу й надішліть те, що вже є, — повернемося з оцінкою обсягу, планом впровадження й пропозицією щодо пілотного розділу.