Чанкинг — стратегии разбиения документов
Chunking в RAG в 2026 полезно понимать не как вопрос “какой размер чанка поставить”, а как упаковку знаний для retrieval. Чанк должен быть достаточно маленьким, чтобы находиться по конкретному вопросу, и достаточно цельным, чтобы не терять смысл на границах. Именно этот баланс обычно и ломает retrieval сильнее, чем выбор ещё одной embedding-модели.
Главный practical сдвиг: хороший chunking теперь чаще строят не вокруг одной магической цифры, а вокруг структуры документа, retrieval задачи и downstream контекста. Поэтому разговор “500 символов и overlap 50” уже слишком грубый для большинства production-кейсов.
1. Chunking — это retrieval packaging
Если упростить, chunking определяет:
- что станет единицей поиска;
- что будет ранжироваться;
- что попадёт в prompt или tool context;
- насколько легко потом показывать citation.
Поэтому плохой chunking может ломать RAG сразу в трёх местах:
- retrieval не находит нужный факт;
- retrieval находит слишком широкий шумный кусок;
- generation получает контекст, где смешаны несколько тем.
Именно поэтому в 2026 хороший chunking почти всегда оценивают через retrieval metrics, а не по эстетике “красиво ли нарезан текст”.
2. Почему fixed-size больше не выглядит универсальным default
Фиксированный размер всё ещё полезен как baseline, но у него есть системное ограничение: он ничего не знает о структуре документа.
Проблемы fixed-size chunking:
- ломает заголовки и подпункты;
- режет таблицы и списки;
- смешивает соседние темы;
- плохо ведёт себя на HTML/Markdown/PDF-парсинге;
- усложняет citations.
Это не значит, что fixed-size нельзя использовать. Это значит, что в production его стоит воспринимать как дешёвый baseline, а не как лучший вариант “по умолчанию”.
3. Recursive chunking остаётся хорошим default
LangChain current docs по-прежнему рекомендуют RecursiveCharacterTextSplitter как хороший generic splitter. И это остаётся разумным выбором, потому что он:
- пытается сохранить абзацы;
- потом строки;
- потом слова;
- и только потом режет жёстко.
Это уже намного лучше, чем просто “отрезать каждые N символов”, потому что recursive splitter хотя бы уважает естественные границы текста.
Хороший default, когда:
- документы в целом текстовые;
- нет очень сложной структуры;
- нужен быстро работающий baseline;
- команда только строит первый retrieval loop.
4. Structure-aware chunking всё важнее
Для HTML, Markdown, документации, policy docs, таблиц и wiki-страниц лучший retrieval часто получается не от semantic magic, а от уважения к структуре:
- section headers;
- lists;
- tables;
- code blocks;
- FAQ items;
- policy clauses.
Если чанк режет таблицу пополам или отделяет заголовок от содержания, retrieval становится хуже даже при хороших embeddings.
Именно поэтому structure-aware splitters для HTML/Markdown и pipelines через Unstructured или похожие парсеры стали важнее обычной нарезки по символам.
5. Semantic chunking полезен, но не всегда обязателен
Semantic chunking пытается объединять предложения не по форматированию, а по смысловой близости. Это может дать лучший retrieval, если:
- документы плохо структурированы;
- темы в тексте меняются не по абзацам;
- форматирование грязное;
- нужен retrieval по смысловым блокам, а не по layout.
Но practical минусы тоже важны:
- ingestion становится медленнее;
- chunking pipeline дорожает;
- сложнее дебажить;
- эффект не всегда заметнее, чем хорошая structure-aware схема + reranking.
Поэтому semantic chunking полезно подавать не как “следующий обязательный уровень зрелости”, а как вариант для сложных и неаккуратно структурированных корпусов.
6. Late chunking меняет картину для long-context embeddings
Новая важная рамка 2026: некоторые embedding stacks поддерживают late chunking, где сначала кодируется более длинный связный контекст, а chunk vectors формируются позже. Это помогает сохранить больше surrounding context, не скатываясь в giant chunks на уровне retrieval.
Практически это значит:
- классический pre-chunking больше не единственная схема;
- long-context embedding models могут лучше держать связь между соседними частями;
- для некоторых corpora late chunking даёт более сильный retrieval signal.
Но operationally это уже более сложный pipeline, и его не стоит ставить раньше, чем вы наладили базовый retrieval eval.
7. Overlap всё ещё нужен, но не бесконечный
Overlap помогает не потерять смысл на границах чанков. Но слишком большой overlap:
- раздувает индекс;
- повышает дублирование;
- засоряет retrieval top-k похожими кусками;
- увеличивает cost indexing и storage.
Практическое правило:
- overlap нужен там, где мысль часто пересекает границы;
- overlap не должен превращать retrieval в поиск по нескольким почти одинаковым chunk-ам;
- если overlap большой, часто особенно полезен reranking или dedup layer.
8. Как выбирать chunking strategy
Самая полезная логика такая:
Generic docs
Начните с recursive chunking.
Structured docs
Сначала используйте structure-aware splitting по section headers, tables, lists и code blocks.
Noisy / mixed corpus
Пробуйте semantic chunking или гибридную схему.
Long-context embedding stack
Проверьте, даёт ли смысл late chunking.
Production tuning
Мерьте не “красоту чанков”, а:
- retrieval recall;
- retrieval precision / noise;
- citation quality;
- answer groundedness downstream.
9. Что чаще всего ломает chunking в production
- один универсальный chunk size для всех типов документов;
- нарезка без структуры;
- слишком большие chunks “чтобы модель видела больше”;
- слишком маленькие chunks “чтобы всё точнее находилось”;
- агрессивный overlap без dedup;
- отсутствие eval после смены splitter-а.
Плюсы
- Хороший chunking заметно улучшает retrieval без смены модели
- Structure-aware схемы особенно полезны для docs, FAQ, policy и HTML
- Recursive splitter остаётся pragmatic baseline
- Late и semantic chunking дают дополнительный уровень контроля для сложных корпусов
Минусы
- Один магический chunk size почти никогда не работает везде
- Semantic chunking дороже и сложнее в дебаге
- Большой overlap раздувает индекс и шум в retrieval
- Плохой chunking часто маскируется под проблему embeddings или reranking