Чанкинг документов для ИИ: зачем резать текст на части

Прежде чем документ попадёт в память ИИ-ассистента, его режут на части. Эту подготовку называют чанкингом: длинный текст делится на фрагменты, обычно от абзаца до страницы, каждый фрагмент переводится в эмбеддинг, числовой отпечаток смысла, и ложится в векторную базу. Когда Вы потом задаёте вопрос, ассистент ищет не по целым документам, а по этим кускам: находит ближайшие по смыслу и подкладывает их модели для ответа. Поэтому качество будущих ответов закладывается уже на нарезке. Слишком мелкие куски теряют контекст: фраза без окружения читается как цитата, вырванная из статьи. Слишком крупные размывают смысл: в одном фрагменте перемешаны три темы, и поиск цепляет его по любой из них, но точно не отвечает ни на одну. Рабочее правило сформулировали инженеры Pinecone: если фрагмент понятен человеку без окружающего текста, он будет понятен и модели.

Зачем вообще резать документы

У нарезки две причины, и обе практические.

Первая: у моделей, которые превращают текст в эмбеддинги, есть предел входа. У модели text-embedding-3-small от OpenAI это 8192 токена, примерно десять страниц, если считать страницу в 800 токенов, как это делает сама OpenAI. Текст длиннее в один эмбеддинг не помещается: хвост отрезается, и договор на сорок страниц превратился бы в отпечаток первых десяти.

Вторая причина важнее, и она про точность поиска. Эмбеддинг это один числовой вектор на весь фрагмент: у той же text-embedding-3-small в нём 1536 чисел, подали Вы на вход абзац или целую главу. Один вектор хранит один сгусток смысла. Если сжать в него документ, где перемешаны цены, сроки и история переговоров, получится усреднённый отпечаток, который одинаково слабо похож на любой конкретный вопрос.

Здесь помогает образ библиотеки. Хороший каталог не заводит одну карточку на всё собрание сочинений: он описывает каждый том, а внутри тома ещё и главы. Чанкинг делает ту же работу для памяти ассистента: превращает толстый документ в набор карточек, каждая из которых находится по своему смыслу.

Слишком мелко и слишком крупно: что ломается

Представьте, что из Вашей переписки в память легла одинокая строка «согласовали по 90 тысяч». Без окружения она бесполезна: с кем согласовали, за что, когда? Так проявляется слишком мелкая нарезка: отдельные предложения точны по форме, но им не хватает контекста, чтобы ответ получился верным. Инженеры Pinecone отмечают, что для агентов это особенно опасно: фрагмент без контекста провоцирует выдуманные детали и неверные действия.

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

Как режут на практике: пять подходов

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

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

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

Самый тонкий подход называют семантической нарезкой: соседние группы предложений сравнивают по эмбеддингам и ставят границу там, где смысл заметно сдвинулся, то есть началась новая тема. А чтобы куски не теряли связь с целым, к ним иногда дописывают короткое пояснение из всего документа: этот приём описала Anthropic в 2024 году под названием contextual retrieval.

Размер при любом подходе подбирается опытом. Ориентиры из практики Pinecone: куски в 128 и 256 токенов для точечных фактов, 512 и 1024 токена там, где важен связный контекст.

Что это значит для Вас

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

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

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