Чанкинг (разбиение документов)

Чанкинг — это разбиение документа на небольшие фрагменты, или чанки, перед индексацией, построением эмбеддингов, поиском и RAG. На практике он нужен, чтобы модель работала не со всем файлом сразу, а с кусками, которые можно найти, ранжировать и передать в контекст. Метод полезен не всегда: для коротких заметок, строго структурированных таблиц, исходного кода с длинными межфайловыми зависимостями и документов, где критична точная страничная ссылка, простое разбиение может ухудшить результат, если потерять структуру, заголовки или связь между абзацами.

Простыми словами

Представьте длинный регламент на 80 страниц. Если отдать его модели целиком, возникнут три проблемы: это дорого, медленно и плохо управляется при поиске нужного места. Чанкинг решает задачу проще: документ режут на логичные куски, например по разделам, абзацам или фиксированному размеру, а затем каждый кусок отдельно индексируют.

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

Главная практическая идея такая: хороший чанк должен быть достаточно маленьким для точного поиска и достаточно полным, чтобы не терять смысл. Именно баланс между этими двумя требованиями и определяет качество пайплайна.

Как это работает

Обычно процесс состоит из четырех шагов.

1. Очистка документа. Из текста удаляют шум: артефакты OCR, повторяющиеся колонтитулы, номера страниц, битую разметку.
2. Разбиение. Текст режут по выбранной стратегии: по фиксированной длине, по структуре документа или по смысловым границам.
3. Перекрытие. Часто соседние чанки делают с overlap, то есть с повтором нескольких предложений или токенов, чтобы не потерять мысль на границе.
4. Индексация. Для каждого чанка строят эмбеддинг, сохраняют текст и метаданные: источник, заголовок, страница, раздел, дата, версия документа.

Основные стратегии

Стратегия	Когда подходит	Риск
Фиксированный размер в символах или токенах	Быстрый старт, однотипные тексты, базовый RAG	Режет фразы и теряет структуру
Рекурсивное разбиение по абзацам, предложениям, заголовкам	Статьи, регламенты, документация	Нужно аккуратно настроить пороги размера
Структурное разбиение по разделам, HTML-узлам, Markdown, страницам	Документы с явной разметкой	Крупные разделы могут оказаться слишком длинными
Семантическое разбиение	Смешанные тексты, где важны смысловые переходы	Сложнее, дороже и не всегда предсказуемо

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

Как выбирать размер чанка

Единственного правильного размера нет. Его выбирают под задачу, модель и тип текста. Для поисковых и RAG-сценариев удобнее мыслить токенами, а не символами, потому что ограничения контекста и стоимость считаются именно так. Если чанк слишком маленький, он хорошо находится в поиске, но теряет смысл. Если слишком большой, в него попадает много лишнего текста, растет шум при ранжировании и расход токенов.

Практическое правило: сначала определить, какой минимальный фрагмент в вашем домене уже содержит законченную мысль. Для FAQ это может быть пара абзацев, для юридического документа — пункт с подпунктами, для API-документации — секция метода вместе с параметрами и примером ответа.

Перекрытие тоже не должно быть механическим. Оно помогает, когда смысл часто переносится через границу абзацев, но слишком большой overlap раздувает индекс и создает дубликаты при выдаче.

Зачем нужно

• Повысить точность поиска. Находить релевантный фрагмент проще, чем весь документ.
• Снизить шум в контексте. В ответ попадают только нужные куски, а не десятки лишних страниц.
• Уложиться в ограничения модели. Большие документы часто не помещаются в окно контекста целиком.
• Сократить стоимость обработки. Меньше текста отправляется на эмбеддинги, ранжирование и генерацию в каждом запросе.
• Сделать цитирование управляемым. Чанк можно связать с разделом, страницей и исходным файлом.

Для практиков главное не само разбиение, а управляемость последующего поиска. Если в индексе лежат плохие чанки, никакой хороший reranker или модель ответа полностью это не исправят.

Пример

Допустим, вы строите внутренний помощник по кадровым политикам компании: отпуска, командировки, компенсации, больничные. Исходные данные — PDF и страницы в корпоративной вики.

1. Сначала вы извлекаете текст и очищаете его от повторяющихся шапок и номеров страниц.
2. Потом разбиваете документ по заголовкам H1/H2, а внутри разделов — по абзацам, удерживая каждый чанк в целевом диапазоне длины.
3. Добавляете метаданные: source, section_title, page, doc_version.
4. Делаете небольшой overlap между соседними чанками, чтобы правило, начатое в одном абзаце, не потерялось в следующем.
5. Строите эмбеддинги и сохраняете чанки в векторное хранилище.

Теперь запрос можно ли перенести неиспользованный отпуск приведет не к целому PDF, а к 2-4 фрагментам из раздела про перенос отпуска. Если же вы нарезали бы текст только по 3000 символов без учета заголовков, в один чанк могли попасть одновременно отпуск, командировка и компенсации. Поиск нашел бы его, но ответ модели был бы менее точным и с большим количеством посторонних деталей.

В этом примере лучшее решение — не максимальный размер чанка, а сохранение структуры документа. Для политик и регламентов заголовок раздела часто так же важен, как основной текст, поэтому его стоит включать в каждый дочерний чанк как метаданные или префикс.

Заблуждения и ограничения

Заблуждение 1: чем меньше чанк, тем лучше поиск. Нет. Слишком мелкие фрагменты теряют контекст, и модель видит отдельные фразы без условий и исключений.

Заблуждение 2: достаточно выбрать универсальный размер один раз. Нет. Для FAQ, договоров, кода, тикетов поддержки и научных статей нужны разные правила разбиения.

Заблуждение 3: overlap всегда полезен. Нет. Избыточное перекрытие плодит почти одинаковые записи в индексе, мешает дедупликации и может ухудшить итоговую выдачу.

Заблуждение 4: чанкинг заменяет хорошую подготовку данных. Нет. Если текст плохо извлечен из PDF, потеряны таблицы, списки и заголовки, качественное разбиение уже не спасет.

Ограничения метода важно учитывать заранее.

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

Частые вопросы

Нужно ли делать overlap всегда?

Нет. Он нужен, когда смысл регулярно пересекает границу чанка. Для коротких автономных блоков, например карточек товаров или ответов в FAQ, overlap может быть минимальным или нулевым.

Чем разбиение по токенам лучше разбиения по символам?

Токены ближе к тому, как модель реально потребляет текст. Это удобнее для контроля стоимости, длины контекста и стабильности пайплайна. Символы подходят только как грубое приближение.

Можно ли чанковать по страницам PDF?

Можно, но это редко лучший вариант. Граница страницы почти никогда не совпадает со смысловой границей. Страницы полезнее хранить как метаданные, а не как единственное правило разбиения.

Что важнее: размер чанка или качество метаданных?

Оба фактора важны. Но в рабочих системах хорошие метаданные часто дают не меньше пользы, чем тонкая настройка размера. Без источника, заголовка и версии даже найденный чанк сложнее использовать и проверять.

Связанные понятия

• RAG — схема, в которой перед генерацией модель получает найденные фрагменты из внешней базы знаний.
• Эмбеддинги — векторные представления текста, по которым ищут похожие чанки.
• Векторный поиск — поиск ближайших фрагментов в embedding-пространстве.
• Реранжирование — дополнительная стадия, где найденные чанки пересортировывают более точной моделью.
• Парсинг документов — извлечение текста и структуры из PDF, HTML, DOCX, Markdown и других форматов.
• Метаданные — поля, которые помогают фильтровать и объяснять найденный чанк: источник, раздел, страница, дата, язык.

Если нужен рабочий старт без долгой настройки, начинайте со структурного или рекурсивного разбиения, храните метаданные и проверяйте качество на реальных запросах пользователей. Чанкинг — не отдельная магия, а инженерный компромисс между точностью поиска, сохранением смысла и стоимостью обработки.