Чанкінг документів для RAG (рекурсивний, семантичний, на рівні речень)

Чому стратегії чанкінгу визначають якість відповідей

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

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

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

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

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

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

Тому стратегію нарізки підбирають під структуру документів, а не беруть за замовчуванням: розбираємо, як це закривається.

Ефект від керованої нарізки: що змінюється

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

• Частка відповідей із коректним джерелом. Розріз посеред пункту регламенту чи таблиці дає відповідь за уривком — послатися на конкретний розділ неможливо. Межі за смисловими блоками повертають точне посилання, і розбір звернення займає хвилини.
• Усунений клас відмов «не вистачило контексту». Якщо питання потребує двох сусідніх абзаців, а в індекс потрапив один, система мовчить або додумує. Перекриття фрагментів і склеювання за структурою прибирають цей клас цілком.
• Час складання бази знань. Нарізка відомими блоками замість повного перерахунку векторних подань скорочує первинне складання з годин до десятків хвилин і робить його передбачуваним у міру зростання корпусу.
• Оновлення документа без повного перескладання. Правка одного наказу перераховує лише його фрагменти, решту індексу не чіпаємо. Нова редакція потрапляє у відповіді того самого дня.
• Якість пошуку за регламентами. Метрика — частка запитів, де потрібний пункт опинився на початку видачі. На розмічених регламентах вона зростає помітно, бо фрагмент містить і умову, і наслідок норми.

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

Стратегії чанкінгу: порівняння підходів

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

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

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

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

Етапи робіт: від аудиту документів до передачі

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

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

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

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

• Конфігурація нарізки — алгоритм для кожного класу документів: рекурсивний поділ за розділювачами, семантичний за зміною теми або нарізка за межами речень.
• Правила перекриття фрагментів — скільки контексту переноситься в сусідній фрагмент, щоб відповідь не обривалася на стику розділів, і чим це правило відрізняється для таблиць і регламентів.
• Схеми обробки документів — маршрут від завантаження файлу до запису в індекс Qdrant: парсинг, очищення, розмітка метаданими, розгалуження за типами джерел.
• Правила доступу до документів — які розділи потрапляють у загальний індекс, які в закриті колекції, як права успадковуються з вихідної системи.
• Регламент оновлення бази — що і коли переіндексовується під час правки документа, хто запускає прогін і за якими ознаками приймає результат.
• Інструкція для підтримки — типові відмови: битий парсинг, порожні фрагменти, дублі; що перевіряється на кожному кроці й як відновитися.
• Чек-листи повторного прогону — звірка кількості фрагментів до і після, контрольні питання до пошуку, умова відкату на попередню версію нарізки.

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

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

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

Що було у вихідній базі

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

Асистент повертав рядок «Разом» без шапки або пункт третього рівня без батьківського заголовка: формально схоже, за змістом мимо. На контрольному наборі з 400 питань точність влучання в джерело трималася близько 64%.

Що змінили і що вийшло

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

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

Точність влучання в джерело зросла з 64% до 93% на тому самому наборі питань. Частка відповідей, де модель посилалася на потрібний документ, але не на ту таблицю, впала в рази, а випадків «фрагмент обрізано на середині рядка» не залишилося.

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

Що робити, якщо базу вже нарізано старим способом?

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

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

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

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

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

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

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

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

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

Що відбувається з таблицями?

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

Як перевірити якість нарізки?

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

Чи доведеться перескладати базу при зміні схеми?

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

Обговоримо задачу і повернемося з планом робіт

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

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

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

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

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