Chunking (разбивка текста)

Chunking (разбивка текста) — это процесс деления большого документа на меньшие фрагменты, или чанки, чтобы их можно было извлекать по отдельности и чтобы они помещались в окно контекста модели. В документации LangChain text splitters описываются именно как инструменты для такой разбивки: большие документы делят на меньшие части для поиска (retrieval) и соответствия контекстному окну.

Английский термин: chunking. Также встречается: text splitting, text chunking, «разбиение на чанки», «нарезка текста». В этой статье под chunking имеется в виду подготовка текста для поиска и RAG, а не токенизация.

Короткий ответ: chunking нужен, когда документ слишком длинный для удобного поиска или прямой передачи в модель. По официальным источникам из этого набора, актуальным на 2026-08-16, на практике чаще всего встречаются три семейства подходов: эвристические и structure-aware splitters в LangChain, управляемая разбивка через chunking_strategy в OpenAI vector stores и токен-, sentence- и semantic-splitters в LlamaIndex.

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

Грубо говоря, chunking — это способ разрезать длинный текст на куски так, чтобы каждый кусок всё ещё что-то значил сам по себе. Если не делать такую разбивку, система либо возьмёт слишком много текста сразу, либо найдёт нужный абзац, но не сможет аккуратно передать его в модель.

Можно представить это как работу с книгой без оглавления. Вместо того чтобы каждый раз перелистывать весь том, вы заранее делите его на главы, разделы и абзацы, а потом ищете только нужный фрагмент. Аналогия упрощает картину, но для практики она полезна: смысл chunking не в «уменьшении текста вообще», а в том, чтобы сделать его пригодным для поиска и последующей подачи в LLM.

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

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

Большой документ
    ↓
Выбор стратегии разбивки:
- по структуре
- по разделителям и символам
- по токенам (tokens)
- по предложениям
- по смыслу
    ↓
Чанк 1 | Чанк 2 | Чанк 3 | ...
    ↓
Загрузка в vector store / индекс
    ↓
Запрос пользователя
    ↓
Извлечение подходящих чанков
    ↓
Передача найденных фрагментов в контекст модели

1. Вы выбираете стратегию. В LangChain есть универсальные splitters и splitters, которые учитывают структуру Markdown, HTML, JSON и кода. Для большинства случаев сама документация LangChain советует начинать с RecursiveCharacterTextSplitter.
2. Вы задаёте размер и, при необходимости, перекрытие. В руководстве LangChain для Python показаны параметры chunk_size и chunk_overlap. Смысл перекрытия в том, чтобы соседние чанки делили между собой часть текста и не теряли контекст на границе.
3. Разделитель влияет на качество. В JavaScript-документации LangChain для рекурсивного сплиттера показан набор разделителей по умолчанию: ["nn", "n", " ", ""]. Там же отдельно сказано, что для языков без явных границ слов могут понадобиться свои разделители, иначе слова будут резаться неудачно.
4. В managed-сценариях разбивкой может управлять сама платформа. В OpenAI vector stores у file batches есть поле chunking_strategy. Если его не указывать, текущая auto-стратегия использует max_chunk_size_tokens=800 и chunk_overlap_tokens=400. В static-режиме можно задать собственные значения, но max_chunk_size_tokens должен быть в диапазоне от 100 до 4096, а overlap не может превышать половину размера чанка.
5. Не все splitters одинаковы по логике. В LlamaIndex SentenceSplitter документирован как токен-ориентированный splitter с дефолтами chunk_size=1024 и chunk_overlap=200. А SemanticSplitterNodeParser режет не по фиксированному окну, а группирует семантически связанные предложения; в исходнике видны дефолты вроде buffer_size=1 и breakpoint_percentile_threshold=95.

Отдельно важно помнить про токены (tokens). На странице OpenAI Tokenizer дан ориентир для английского: примерно 4 символа на токен или около 75 слов на 100 токенов. Это полезная грубая оценка для прикидки размера чанка, но именно для английского; переносить её на русский без проверки токенизатором не стоит.

Где применяется

• Подготовка базы знаний для RAG. Документы разбивают заранее, чтобы затем извлекать не весь файл, а только подходящие фрагменты.
• Загрузка файлов в OpenAI vector stores. Если вы используете managed ingestion, chunking может выполняться через chunking_strategy на стороне платформы. Перед внедрением стоит отдельно проверить матрицу доступности endpoint-ов: в документации по data controls перечислены /v1/vector_stores и File Search, но доступность может зависеть от endpoint-а и аккаунта.
• Предобработка структурированных документов. Для Markdown, HTML, JSON и кода у LangChain есть splitters, которые учитывают структуру, а не только длину текста.
• RAG-пайплайны, где важны границы предложений или смысловых блоков. Здесь чаще полезны sentence- или semantic-подходы из LlamaIndex, а не грубое фиксированное окно.

Практический пример

Сценарий: вы собираете RAG по внутренней документации и хотите, чтобы система поднимала цельные фрагменты разделов, а не случайные обрывки абзацев.

1. Если документы уже имеют понятную структуру, сначала попробуйте structure-aware splitters для Markdown, HTML, JSON или кода. Это снижает риск разрезать заголовок отдельно от содержимого раздела.
2. Если нужен универсальный старт на стороне приложения, используйте рекомендацию LangChain и начните с RecursiveCharacterTextSplitter. Базовые ручки для подбора — chunk_size и chunk_overlap.
3. Если вы загружаете файлы в OpenAI vector store и не хотите вручную резать текст, можно не указывать chunking_strategy. Тогда, по текущей документации, будет использоваться auto-режим с 800 токенами на чанк и 400 токенами перекрытия.
4. Если нужен более жёсткий контроль, переходите на static chunking и подбирайте max_chunk_size_tokens в допустимых пределах 100–4096. Не задавайте chunk_overlap_tokens больше половины от размера чанка — это прямо ограничено в документации.
5. Если на границах чанков теряются целые мысли, попробуйте sentence-based вариант. Для LlamaIndex в документации SentenceSplitter показаны дефолты 1024/200; если же смысловые блоки живут длиннее одного предложения, имеет смысл проверить semantic splitter.

Практический вердикт: если у вас нет замеров на собственных документах и запросах, не существует «правильного» универсального размера чанка. Разумный старт — взять рекомендованный базовый splitter или auto-режим платформы, а затем смотреть на качество извлечённых фрагментов, а не только на числа в токенах.

Чем отличается от похожих терминов

Ограничения и заблуждения

• Заблуждение: «есть универсальный размер чанка». В источниках прямо нет такого универсального числа. На подходящий размер влияют язык, токенизатор, retriever и размер контекстного окна.
• Заблуждение: «chunking = токенизация». Нет. Токенизация отвечает за то, как модель разбирает текст на токены, а chunking — за то, как вы режете документ на фрагменты до retrieval.
• Заблуждение: «дефолты платформы вечны». Для OpenAI auto-параметры документированы как текущее поведение. Перед релизом их нужно перепроверять в актуальной API reference.
• Ограничение по доступности. Для vector stores и File Search доступность может зависеть от endpoint-а и аккаунта, поэтому проверка матрицы доступности перед внедрением обязательна.
• Ограничение версий документации. У LlamaIndex часть документации версионирована, а semantic splitter описан через текущий исходный код репозитория. Это значит, что старые docs и текущее поведение пакета могут не совпадать полностью.
• Ограничение грубых оценок по токенам. Ориентир OpenAI «примерно 4 английских символа на токен» полезен только как rule of thumb для английского. Для русского и смешанных корпусов лучше считать токены реальным токенизатором.

Редакционная оговорка: эта статья объясняет механики и текущие официально задокументированные параметры, но не даёт «лучший размер чанка для всех случаев». В исходниках такого универсального ответа нет.

Связанные термины и инструменты

В реальных пайплайнах chunking часто сочетается с Batching (пакетная обработка), когда документы грузят партиями, и становится этапом более длинной Chain (цепочки агентов) с retrieval и генерацией ответа. Не путайте это с Fine-tuning (дообучением): chunking меняет подготовку контекста и поиск по документам, а не параметры самой модели.

Если вам нужен быстрый старт без собственной логики разбиения, смотрите на managed chunking в OpenAI vector stores. Если важен контроль над структурой документа, начните с LangChain splitters. Если у вас RAG-пайплайн, где критичны границы предложений или смысловые блоки, полезнее смотреть на splitters в LlamaIndex.

Источники

• Releases · openai/openai-python · GitHub
• Releases · run-llama/llama_index · GitHub

• Text splitter integrations – Docs by LangChain
• Splitting recursively – Text splitter integration guide – Docs by LangChain
• File Batches | OpenAI API Reference
• Tokenizer – OpenAI API
• Data controls in the OpenAI platform – OpenAI API
• SentenceSplitter – LlamaIndex 🦙 0.9.48
• semantic_splitter.py · run-llama/llama_index

Вопросы и ответы

Chunking и токенизация — это одно и то же?

Нет. Токенизация описывает, как текст превращается в токены для модели, а chunking — как вы заранее режете документ на извлекаемые фрагменты для поиска и RAG.

С какого splitter лучше начать?

Если вы режете текст на стороне приложения, в документации LangChain рекомендуют начинать с RecursiveCharacterTextSplitter для большинства случаев. Если вы используете OpenAI vector stores и не хотите настраивать разбиение вручную, можно начать с auto-режима через chunking_strategy.

Нужно ли делать overlap между чанками?

Часто да, потому что перекрытие помогает не потерять контекст на границах. В OpenAI auto-режиме текущее значение overlap документировано как 400 токенов при размере чанка 800, а в static-режиме overlap не должен превышать половину размера чанка.

Когда fixed-size chunking хуже semantic splitting?

Когда смысловые блоки плохо совпадают с фиксированным окном по длине. В LlamaIndex semantic splitter не просто считает токены, а группирует семантически связанные предложения, поэтому он может лучше сохранять цельные мысли в одном чанке.

Можно ли ориентироваться на правило «4 символа на токен»?

Только как на грубую оценку для английского, потому что именно так это сформулировано на странице OpenAI Tokenizer. Для русского текста и смешанных документов лучше проверять фактическое число токенов инструментом токенизации.