Разбиение документов на чанки для RAG: стратегии и размеры
Практика3 минРедакция Innovialabs
Коротко
Чанк должен быть понятен сам по себе и содержать одну мысль. Для большинства задач лучше всего работает разбиение по структуре документа с рекурсивным делением длинных разделов и небольшим перекрытием, а размер подбирается на тестовых вопросах.
Короткий ответ
В RAG-системе модель видит не весь документ, а только найденные чанки — фрагменты текста. Если чанк обрезан посреди мысли или смешивает три темы, поиск находит не то, а модель отвечает неточно.
Практичный старт для большинства корпоративных документов:
- резать по структуре — заголовки, разделы, пункты;
- длинные разделы делить рекурсивно — по абзацам, затем по предложениям;
- добавлять небольшое перекрытие между соседними чанками;
- к каждому чанку прикреплять путь заголовков и метаданные.
Точный размер подбирайте на своих данных, а не по чужим рекомендациям.
Четыре стратегии
| Стратегия | Как работает | Плюсы | Минусы |
|---|---|---|---|
| Фиксированная | Режет каждые N токенов | Просто и предсказуемо | Рвёт предложения и таблицы |
| Рекурсивная | Делит по разделителям: абзац → строка → предложение | Сохраняет естественные границы | Не знает о смысловой структуре |
| Семантическая | Ставит границу там, где меняется смысл соседних предложений | Связные чанки | Дороже, нужны эмбеддинги на этапе разбиения |
| Структурная | Использует разметку: заголовки Markdown/HTML, пункты, разделы | Лучшие границы для регламентов и документации | Нужен хороший парсер |
На практике стратегии комбинируют: сначала структура, затем рекурсивное деление внутри слишком длинных разделов.
Как размер чанка влияет на ответы
Маленькие чанки:
- точнее находятся по узкому вопросу;
- но теряют контекст: «срок составляет 10 дней» без указания, срок чего.
Большие чанки:
- несут больше контекста;
- но размывают эмбеддинг: вектор описывает сразу несколько тем, и поиск хуже ранжирует;
- съедают окно контекста модели и добавляют шум.
Компромиссные приёмы:
- Обогащение заголовками: в начало чанка добавляется «Документ → Раздел → Подраздел». Маленький чанк становится понятным.
- Small-to-big: ищете по маленьким чанкам, а в модель передаёте родительский раздел целиком.
- Перекрытие: несколько предложений из предыдущего чанка, чтобы мысль на границе не потерялась. Слишком большое перекрытие плодит дубли в выдаче.
Таблицы
Таблица, разрезанная пополам, бесполезна: строки без заголовков столбцов не читаются. Что делать:
- не разрывать таблицу внутри, если она помещается в разумный размер;
- большие таблицы делить по строкам, повторяя заголовок в каждом чанке;
- для справочников превращать строку в текст: «Тариф: Базовый; Срок: 12 месяцев; Условие: ...»;
- хранить таблицу в Markdown или HTML, а не как поток слов.
PDF и сканы
PDF — формат для печати, а не для текста. Типичные проблемы: колонтитулы в каждом чанке, перемешанные колонки, переносы слов, таблицы как набор строк.
Чек-лист:
- используйте парсер, который распознаёт структуру макета (заголовки, колонки, таблицы);
- удаляйте колонтитулы и номера страниц;
- склеивайте переносы и абзацы, разорванные границей страницы;
- для сканов — OCR, затем выборочная ручная проверка;
- сохраняйте номер страницы в метаданных — пригодится для ссылки в ответе.
Как подобрать параметры
- Соберите набор реальных вопросов с указанием, где в документах ответ.
- Сделайте 2–3 варианта разбиения (разные размер, перекрытие, стратегия).
- Для каждого измерьте, попадает ли нужный фрагмент в top-k выдачи.
- Выберите вариант, затем проверьте качество итоговых ответов.
Меняйте один параметр за раз — иначе непонятно, что сработало.
Частые ошибки
- Один размер на все типы документов: договоры, FAQ и инструкции требуют разного подхода.
- Чанки без метаданных — нельзя ни сослаться на источник, ни отфильтровать.
- Индексация «сырого» текста PDF без очистки.
- Подбор параметров без тестового набора вопросов.