Компанія з 4000 PDF-документів, яка індексує їх із налаштуванням за замовчуванням «по 500 символів», отримує асистента, який цитує правильний абзац, але не розуміє, про який договір йдеться. Точність retrieval у такому варіанті падає на 30–50% порівняно з правильно відкаліброваним пайплайном. Проблема не в мовній моделі чи векторній базі, а в грануляції фрагментів.
Три основні стратегії та коли їх застосовувати
Фіксований розмір (fixed-size chunking) ділить документ на фрагменти з наперед визначеною кількістю токенів або символів, з опціональним зсувом (overlap). Це найпростіший підхід, швидкий в реалізації та передбачуваний за вартістю індексації. Підходить, коли документи мають однорідну структуру, наприклад, системні логи чи описи продуктів, написані за одним шаблоном. Основний недолік: спліттер не розпізнає межі речення, тому часто перериває думку на півслові.
Recursive character splitter (наприклад, RecursiveCharacterTextSplitter у LangChain) намагається зберегти семантичні межі, ділячи послідовно за \n\n, \n, . , і лише в кінці — за символом. Для більшості польських бізнес-документів, тобто інструкцій, регламентів і звітів, написаних прозою, це стандартний вибір, який забезпечує хороше співвідношення якості до витрат.
Семантичний чанкінг групує речення зі схожим значенням на основі косинусної відстані між послідовними ембедінгами. Розмір фрагментів змінний, що ускладнює прогнозування кількості токенів і вартості інференсу, але точність retrieval для довгих, щільних документів (наприклад, багатосторінкових договорів) буває на 10–25% вищою, ніж при fixed-size.
Вибір розміру фрагмента та overlap
#Універсального розміру не існує. Він залежить від трьох факторів: моделі ембедінгів, характеру запитань користувача та середньої довжини відповіді, яку очікує асистент.
Практичні межі для польських бізнес-документів:
- Фактичні запитання (дати, назви, суми): 256–512 токенів, overlap 50–80 токенів.
- Запитання, що потребують контексту процедури: 512–1024 токенів, overlap 100–150 токенів.
- Наративні документи, аналізи, звіти: 1024–2048 токенів, overlap 150–200 токенів.
Overlap — це не «марнування місця». Фрагмент A, що закінчується на середині абзацу, і фрагмент B, що починається на 100 токенів раніше, разом гарантують, що семантичний пошук знайде відповідь навіть при запитанні, яке потрапляє точно на межу поділу.
Моделі ембедінгів мають обмеження вхідного контексту: BGE-M3 підтримує до 8192 токенів, але його оптимальна якість лежить у діапазоні 512–1024 токенів на фрагмент. Вище цього порогу семантичний сигнал розподіляється по всьому вікну, і точність retrieval знижується.
Чанкінг таблиць і коду: окремий підхід
Таблиці та код — це структури, які стандартний спліттер за символом руйнує. Таблиця, розірвана між двома фрагментами, втрачає заголовки стовпців в одному і дані в іншому, тому модель не може пов'язати значення з їхнім значенням.
Рішення: виявляйте таблиці та блоки коду на етапі парсингу документа (наприклад, через pdfplumber, camelot або Unstructured.io), а потім:
- Таблиці: перетворюйте у текстовий формат (Markdown або JSON row-by-row) і зберігайте як окремий chunk з метаданими
type: table. Якщо таблиця довша за 512 токенів, діліть її на блоки по 5–10 рядків, повторюючи заголовок у кожному блоці. - Код: зберігайте як один chunk не довше 1024 токенів. Якщо фрагмент коду довший, діліть за блоками функцій (рядки, що починаються з
def,function,class), а не за довільною кількістю символів.
Метадані type: table і type: code дозволяють фільтрувати їх у гібридних запитах. Детальніше про цей процес у статті як підготувати корпоративні дані під AI.
Стратегія vs тип документа: довідкова таблиця
#| Тип документа | Рекомендована стратегія | Розмір чанка (токени) | Overlap (токени) |
|---|---|---|---|
| FAQ, списки питань і відповідей | Семантичний за питанням | 128–256 | 0–30 |
| Договори, регламенти (пункти) | Recursive за заголовком розділу | 512–768 | 80–120 |
| Інструкції з експлуатації, процедури | Recursive стандартний | 512–1024 | 100–150 |
| Аналітичні звіти, наратив | Семантичний або fixed-size | 1024–2048 | 150–200 |
| Таблиці даних (прайс-листи, реєстри) | Таблиця row-by-row + заголовок | 256–512 | 0 (повторити заголовок) |
| Фрагменти коду, скрипти | Fixed за межею функції | 512–1024 | 0 |
| Електронні листи, короткі повідомлення | Fixed-size або без поділу | 128–256 | 0–20 |
Метадані чанка як другий сигнал retrieval
#Сам текст фрагмента — це не все. Кожен chunk повинен містити метадані, які векторна база може фільтрувати перед reranking'ом: назву вихідного файлу, номер сторінки, тип документа, дату оновлення, ідентифікатор клієнта або проєкту (якщо стосується).
Фільтрація за метаданими перед векторним пошуком зменшує простір пошуку та виключає з результатів застарілі або нерелевантні документи. Для компанії з 4000 документів, розподілених за категоріями (договори, інструкції, FAQ), цей крок скорочує список кандидатів на 60–80% перед власне семантичним ранжуванням.
Пайплайн RAG з фільтрами метаданих виглядає так: запит користувача → ембедінг запиту → фільтр (наприклад, type: contract AND client_id: X) → векторний пошук на підмножині → reranking top-k → генерація відповіді. Ефект вимірюваний: точність відповідей зростає, а кількість галюцинацій зменшується, оскільки модель отримує лише релевантні фрагменти.
Детальніше про оцінку якості retrieval у статті RAG: оцінка якості відповідей.
Спробуйте наживо
Маєте власний набір документів і не знаєте, з чого почати? Наведений нижче sandbox дозволяє протестувати резонінг для вашого випадку:
FAQ
#Скільки токенів повинен мати один chunk для юридичних документів?
#Для договорів і регламентів оптимум лежить у діапазоні 512–768 токенів з overlap 80–120 токенів. Важливіше за сам розмір — точка поділу: діліть за заголовками розділів (§ 1, § 2, «Загальні положення»), а не за довільною кількістю символів. Пункт, який потрапить цілком в один chunk, буде точніше retrieval-ований, ніж той самий пункт, розірваний на два фрагменти.
Чи завжди більший overlap покращує якість retrieval?
#Ні. Overlap понад 20–25% розміру чанка підвищує вартість індексації і може створювати надлишковість, яка порушує ранжування. Якщо два фрагменти з 50% спільного вмісту потрапляють до топ-5 результатів, модель отримує дубльований контекст замість різних перспектив. Overlap 10–15% розміру чанка — безпечна відправна точка для більшості документів.
Як чанкінг впливає на гібридний пошук BM25 + вектори?
#Чанкінг впливає на обидві складові: надто короткі фрагменти втрачають ключові слова для BM25, надто довгі розмивають векторний сигнал. Для гібридного пошуку оптимум зазвичай лежить у діапазоні 512–1024 токенів, де обидва сигнали працюють ефективно. Варто провести A/B-тести на репрезентативному наборі запитань перед остаточним визначенням розміру.
Чи потрібно переіндексовувати документи після зміни стратегії чанкінгу?
Так, повна переіндексація необхідна після зміни стратегії або розміру чанка. Ембедінги, згенеровані з по-різному поділених фрагментів, несумісні з попередніми. На практиці: підготуйте нову колекцію поряд зі старою, проведіть тести якості на golden set, і лише після досягнення кращих результатів переключіть трафік на нову колекцію. Детальніше про цей процес у статті оновлення знань RAG та версіонування.
Як обробити PDF-документи зі змішаною структурою (текст, таблиці, зображення)?
#Використовуйте структурний парсер, наприклад, Unstructured.io або pdfplumber, який виявляє типи елементів перед спліттером. Суцільний текст обробляйте recursive спліттером, таблиці конвертуйте в Markdown row-by-row з повтореним заголовком, зображення (графіки, схеми) описуйте за допомогою vision-моделі та додавайте опис як окремий chunk з метаданими type: image_caption. Така сегментація дозволяє зберегти семантичну структуру документа без втрати інформації в жодному з шарів.