Что такое agentic chunking в работе с LLM

Agentic chunking — это способ разбиения текста на смысловые фрагменты (чанки) с помощью ИИ‑агентов, которые сами решают, где резать текст и как подписывать каждый фрагмент. В отличие от фиксированных схем, здесь ИИ учитывает структуру, контекст и смысл, а затем создаёт чанки и добавляет к ним метаданные для RAG‑систем.

Базовое определение agentic chunking

Agentic chunking — это подход, при котором разбиение документа выполняет не жёсткий алгоритм, а автономный ИИ‑агент: он анализирует содержание, формирует чанки и описывает их. Такой подход сочетается с RAG‑архитектурами и устраняет ограничения простого разрезания текста по символам или предложениям.

Ключевая идея проста: вместо фиксированных границ мы даём LLM или агенту задачу понять документ, определить смысловые блоки и оформить их в виде чанков, пригодных для индексации и последующего поиска. Это уже не просто «нарезка по длине», а управляемый ИИ процесс, включающий анализ, разбиение и маркировку.

Agentic chunking относится к агентным видам автоматизации, где система выполняет шаги самостоятельно: выбирает стратегию разбиения, адаптируется к формату текста и добавляет поверх исходного материала вспомогательную информацию — заголовки, аннотации, ключевые слова.

Почему вообще нужен chunking для LLM

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

Контекстное окно определяет, сколько токенов (слов и их частей) модель может учитывать за один раз, не «забывая» начало. Если документ превышает этот предел, его приходится делить на части и подбирать релевантные фрагменты уже среди этих частей, а не среди сырых файлов.

Без chunking сценарий с RAG (retrieval-augmented generation) работать корректно не будет: модель либо не увидит нужный фрагмент, либо получит слишком обрезанный контекст. Разбиение на чанки и последующее индексирование обеспечивают быстрый поиск подходящих фрагментов и их вставку в подсказку для LLM.

Chunking и RAG: как связаны

В RAG‑подходе chunking нужен для того, чтобы превратить документы в набор небольших, осмысленных единиц, которые можно искать по смыслу, а затем подставлять в запрос к LLM. Agentic chunking делает эти единицы более точными и информативными для поиска.

Схема RAG выглядит так: документы превращаются в embeddings (векторные представления), эти векторы сохраняются в векторной базе, а потом система по запросу пользователя ищет ближайшие по смыслу вектора и передаёт связанные с ними чанки обратно в LLM. Ответ строится с учётом этого дополнительного контекста, что снижает риск галлюцинаций и повышает точность.

Ограничение по контекстному окну не позволяет положить в подсказку весь документ или набор документов. Поэтому:

• документы режутся на чанки, подходящие по размеру под контекст;
• каждый чанк индексируется отдельно;
• на этап ответа попадает только часть из них — те, что ближе всего к запросу по embedding‑сходству.

Agentic chunking встраивается именно в этот этап подготовки данных: он отвечает за формирование более «умных» чанков и метаданных, а не просто за нарезку по символам или строкам.

Классические методы chunking и их ограничения

До agentic chunking использовались три базовых стратегии: фиксированная нарезка, рекурсивное разбиение по разделителям и семантическая нарезка по embedding‑сходству. Они работают, но каждая даёт свои артефакты и ограничения.

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

Фиксированный размер чанков

Фиксированный chunking делит текст на блоки одинаковой длины по символам или токенам, иногда с небольшим перекрытием между блоками. Такой подход прост и дешёв по вычислениям, но часто рвёт смысловые единицы и игнорирует структуру документа.

Стандартная схема: выбирается длина чанка (например, 500–1000 токенов) и длина перекрытия (например, 50–100 токенов). Текст идёт подряд, и каждая новая порция формирует чанк, а кусок конца предыдущего чанка дублируется в начало следующего, чтобы снизить риск разрыва фразы или абзаца.

Плюсы очевидны:

• реализация в несколько строк кода;
• минимальная нагрузка на процессор и память;
• предсказуемое количество чанков и размер каждого блока.

Но по смыслу такие чанки часто получаются «рваными»: внутри одного блока могут смешиваться разные подтемы, заголовки оказываются в конце чанка, а содержательное объяснение — уже в следующем блоке. Для RAG это ухудшает качество поиска и ответы LLM, потому что вектор описывает «среднюю температуру» по несвязанным кускам текста.

Рекурсивное разбиение по разделителям

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

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

Алгоритм работает так:

1. попробовать разделить текст по самому крупному разделителю;
2. если получившийся фрагмент всё ещё слишком длинный, применить следующий по уровню разделитель;
3. продолжать, пока длина не станет приемлемой или не останется только уровень слов/символов.

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

Семантическое chunking по embedding‑сходству

Семантический подход создаёт векторное представление отдельных предложений или коротких фраз и строит чанки на основе близости этих векторов. Новый чанк начинается там, где меняется тема или резко меняется embedding‑сходство соседних предложений.

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

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

Но и здесь есть тонкости: один абзац может содержать несколько подтем, а неудачно выбранный порог чувствительности приведёт к слишком коротким или чрезмерно длинным чанкам. Плюс требуется более дорогой по ресурсам embedding‑проход по всему тексту.

Чем agentic chunking отличается от классических подходов

Agentic chunking использует ИИ‑агента, который сочетает приёмы классического chunking с генеративными возможностями LLM: он разбивает текст, переупорядочивает фрагменты при необходимости и снабжает их метаданными. Это делает чанки не просто кусками текста, а документальными сущностями с заголовками и краткими описаниями.

Вместо чисто алгоритмических правил, агент может:

• оценивать содержание чанка с учётом более широкого контекста;
• объединять или, наоборот, делить фрагменты, если формально они помещаются в лимит, но по смыслу неоднородны;
• назначать каждому чанку человекопонятный заголовок и резюме;
• добавлять тематические метки (например, «определение», «пример», «ограничения метода»).

Итог: структура чанков ближе к тому, как человек делил бы документ для последующего поиска и чтения, а не к простой нарезке по длине или по символам‑разделителям.

Как работает agentic chunking: типичный pipeline

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

Ниже приведена обобщённая схема, которая встречается в открыто публикуемых примерах на GitHub и в проектах на базе LlamaIndex, LangChain и открытых LLM.

Подготовка текста

На первом этапе текст вытягивается из исходного источника (PDF, DOCX, HTML, база данных) и очищается. Цель — оставить только содержательное наполнение без служебных элементов, которые будут мешать и chunking, и дальнейшему поиску.

Очистка обычно включает:

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

После этого текст становится более однородным и удобным для алгоритмов, которые анализируют структуру и смысл.

Разбиение на базовые чанки

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

Для agentic chunking на этом шаге обычно:

1) выбирают стартовую стратегию (рекурсивное разбиение, семантический подход или их комбинация);
2) настраивают перекрытие между соседними чанками, чтобы сохранить связность переходов;
3) следят за тем, чтобы итоговый размер чанка был безопасен для контекстного окна выбранной LLM.

Результат — набор осмысленных, но ещё «сырых» чанков, которые пока не снабжены метаданными и не оптимизированы под задачи RAG.

Обогащение и переупаковка чанков с помощью LLM

На этом этапе включается ИИ‑агент: LLM анализирует отдельные чанки и, при необходимости, объединяет их или наоборот делит, чтобы сохранить целостность смысловых блоков. Параллельно агент формирует метаданные для каждого чанка.

Что может делать агент на этом шаге:

• генерировать заголовки — короткие, информативные названия, описывающие суть чанка;
• создавать краткие резюме — 1–3 предложения, пересказывающие содержание чанка;
• добавлять тематические тэги — область знаний, тип содержания (теория, описание алгоритма, ограничения, пример), уровень детализации;
• проверять цельность — если смысл одного фрагмента продолжается в следующем чанке, агент может учитывать это при разметке и выборе заголовков.

Благодаря этому каждый чанк превращается в отдельную информационную единицу, которую можно эффективно искать не только по содержанию текста, но и по сопроводительной информации.

Создание embedding и индексирование

После того как чанки подготовлены и размечены, для каждого из них строится embedding и они загружаются в векторную базу. Дальше эти вектора используются retrieval‑моделью для поиска релевантных фрагментов по запросу пользователя.

Здесь важно, что:

— в embedding может идти как сам текст чанка, так и комбинация текста с заголовком и резюме;
— метаданные (заголовок, тэги, источник, позиция в документе) попадают в индекс как отдельные поля, по которым возможен фильтр или дополнительный отбор чанков.

При RAG‑запросе retrieval‑модель ищет близкие по смыслу embedding и возвращает не просто текстовые фрагменты, а чанки вместе с метаданными. Эти данные затем включаются в подсказку для LLM, а заголовки и резюме помогают лучше организовать ответ.

Agentic chunking и агентная автоматизация

Agentic chunking относится к агентной автоматизации, потому что за логику разбиения и разметки отвечает автономный ИИ‑агент, а не статический скрипт. Агент принимает решения о границах чанков и структуре метаданных, исходя из анализа текста и заранее заданной цели.

Под agentic AI в этом контексте понимают систему, которая:

• получает задачу высокого уровня — подготовить набор чанков для RAG;
• самостоятельно выполняет серию шагов (анализ, разбиение, разметка, проверка);
• использует LLM и вспомогательные модели в качестве инструментов внутри этого процесса;
• минимально зависит от ручного управления на уровне отдельных документов.

Agentic chunking хорошо сочетается с agentic RAG‑системами, где не только разбиение, но и сам процесс поиска, ранжирования и компоновки контекстов для ответа тоже выполняется агентами. В таких сценариях метаданные, созданные на этапе chunking, позволяют агенту более гибко выбирать нужные фрагменты.

Типичный стек и практическая реализация agentic chunking

В публичных примерах agentic chunking часто реализуют на Python с использованием фреймворков для LLM‑оркестровки и открытых моделей. Популярны комбинации LlamaIndex, LangChain и моделей из экосистемы Hugging Face.

Общий подход выглядит так:

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

Преимущества agentic chunking для RAG‑систем

Agentic chunking даёт преимущества в точности поиска, качестве ответов и масштабируемости RAG‑систем, потому что соединяет структурированный chunking и генеративную разметку. Чанки становятся не просто кусками текста, а богатыми объектами с описаниями.

Ключевые плюсы:

• Более эффективный поиск. Заголовки и резюме, созданные ИИ, помогают retrieval‑моделям быстрее отбирать релевантные элементы в больших индексах.
• Более точные ответы. Семантически цельные чанки дают LLM контекст, который ближе к исходным смысловым блокам документа, а это снижает риск вырванных из контекста цитат.
• Гибкость по типам документов. Агентный подход легче адаптировать под разные форматы: техническую документацию, код, отчёты, презентации, протоколы.
• Сохранение структуры содержания. Использование рекурсивного и семантического разбиения вместе с агентной дообработкой помогает сохранять логическую последовательность и внутренние связи между частями текста.

В результате agentic chunking становится удобным строительным блоком для систем, которые завязаны на точный поиск по собственным данным и устойчивое поведение LLM при длинных и сложных запросах.