Разбиение на чанки по типу документа, улучшающее RAG

Почему один размер фрагмента не работает

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

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

Руководства ломаются наоборот. Одна задача часто включает шаги, предупреждения, примечания и таблицу с настройками или лимитами. Если чанк разрежет текст между шагом 3 и предупреждением под ним, модель может вернуть действие и пропустить заметку о безопасности. Если чанки слишком большие, извлечение принесёт лишний материал и закопает важную инструкцию.

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

Политики сильнее зависят от структуры, чем от длины. Область применения, исключения, правила утверждения и даты обновления часто живут в отдельных частях. Если поиск возвращает правило без исключения, ответ может звучать уверенно и всё же быть неверным.

Один размер может сработать в демо. В продакшене он обычно ломается.

Что посмотреть перед тем, как разбивать

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

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

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

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

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

Последний пункт важнее, чем многие команды ожидают. Если вы хотите ответы, которым можно доверять, храните чёткие поля для цитирования: название документа, номер раздела, ID пункта, версия, дата и ID тикета. Извлечённый фрагмент гораздо легче проверить, когда модель может указать точное место, откуда он взят.

Как разбивать контракты

Контракты редко ломаются ровно по фиксированной длине. Смысл чаще всего живёт на уровне пункта, поэтому сначала делите по юридической структуре, а затем по числу токенов.

Держите каждый пункт вместе с его заголовком и нумерацией. Если раздел читается как «7.2 Ограничение ответственности», сохраняйте эту полную метку вместе с текстом. Номер важен, потому что люди спрашивают «что разрешает 7.2?» и соседние пункты часто выглядят почти одинаково.

Определения должны иметь свои отдельные чанки. Контракт может использовать термины вроде «Confidential Information» или «Cause» в десяти местах, но реальное значение содержится в одном разделе определений. Храните это определение отдельно, а затем связывайте его с пунктами, которые используют термин, через метаданные или ссылки.

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

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

Для метаданных держите всё просто и последовательно: имена сторон, дата вступления в силу или дата подписи, версия документа или номер поправки, номер и заголовок раздела, и часть документа — тело, приложение или приложение‑A.

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

Как разбивать руководства

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

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

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

Предупреждения должны оставаться рядом с шагом, на который они влияют. Если шаг 6 говорит отключить питание перед открытием панели, держите это предупреждение в том же чанке, что и шаг 6, или сразу перед ним. Не выносите все предупреждения в отдельный «блок безопасности», если руководство уже не трактует их как общие правила.

Длинные процедуры всё ещё требуют более мелких частей, но разделы должны следовать диапазонам шагов с понятными метками. Например, задача может разбиваться как «шаги 1–4: подготовка и снятие крышки», «шаги 5–8: замена фильтра» и «шаги 9–11: сборка и тестирование». Такие метки помогают поиску и позволяют модели объяснить, откуда взят ответ.

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

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

Тикеты поддержки быстро становятся хаотичными. Последний ответ часто содержит «всё ещё ломается» или «та же ошибка снова», что почти ничего не говорит само по себе. Поместите первое сообщение о проблеме в тот же чанк, что и последнее полезное состояние, чтобы поиск возвращал и симптом, и его текущее состояние.

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

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

Логи, stack trace и пометки к скриншотам должны оставаться рядом с сообщением, которое их объясняет. Сырой дамп ошибки без предложения перед ним трудно использовать. Примечание «см. вложение» бесполезно без окружающего сообщения, объясняющего, что видел пользователь и куда он кликнул.

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

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

На практике полезный тикет‑чанк часто включает исходный отчёт, текущий статус, релевантную заметку из лога, обходной путь и окончательное решение. Обычно этого достаточно, чтобы модель ответила, не таща за собой весь тред.

Как разбивать политики

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

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

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

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

Не разбивайте таблицы на мелкие куски. Если в политике есть лимиты, пороги или диапазоны утверждения в таблице, храните всю таблицу с её заголовком и любым пояснением. Чанк, содержащий только «до $500», почти бесполезен, если департамент или путь утверждения находятся в другом чанке.

Полезные метаданные для политик обычно включают аудиторию, департамент, тип политики, дату вступления в силу и статус версии. Политики — это не тикеты и не руководства. Они требуют контроля версий, чёткого владения и достаточного локального контекста, чтобы ответить «какое правило действует сейчас?» без смешения со старым текстом.

Простой способ задать правила

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

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

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

Затем протестируйте поиски, которые люди действительно задают. Держите их простыми. Вопросы вроде «Что завершает контракт досрочно?», «Как сбросить устройство после обновления?», «Почему тикет 184 был открыт снова?» и «Кто утверждает исключения по этой политике?» скажут вам больше, чем аккуратные бенчмарковые подсказки.

Эти запросы покажут, может ли один чанк ответить на вопрос, или модель нужна два–три соседних чанка. Это важнее, чем красивое число токенов. Если ответы продолжают пересекать границы, ваши чанки слишком маленькие или разрезаны не в тех местах.

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

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

Обычно этого достаточно, чтобы построить надёжную первую версию без недельной подгонки.

Простой пример

Клиент пишет в поддержку: «Можем ли мы досрочно расторгнуть этот контракт?» Если в вашей RAG‑системе всё соглашение хранится одним большим чанком, поиск может вернуть десять страниц смешанных условий. Модель тогда должна сортировать правила оплаты, ответственность, определения и подписи. Это часто приводит к размытым ответам или упущенным деталям.

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

Полезный ответ короткий и конкретный:

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

Теперь сравните это с руководством по продукту. Техник спрашивает, как заменить фильтр. Лучший результат — не целая глава, а один чанк задачи с шагами и предупреждением о предварительном отключении питания. Если поиск вернёт только предупреждение, ответ неполон. Если он вернёт двадцать страниц, модель может закопать предупреждение или пропустить самую нужную задачу.

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

Частые ошибки

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

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

Ещё одна ошибка — разрезать пронумерованные пункты пополам. Если вы разрежете «8.2 Ограничение ответственности» посередине исключения, модель может вернуть фрагмент, который противоречит полному пункту. Держите номер пункта, заголовок и целую мысль в одном чанке, когда это возможно.

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

Тикеты создают другой тип беспорядка. Многие команды сохраняют каждый ответ, даже если половина треда — «спасибо» или повторение той же неудачной попытки. Это увеличивает объём, а не количество фактов. Храните исходный отчёт, полезные шаги по устранению, окончательный диагноз и подтверждённое решение. Сверните остальное.

Метаданные также слишком часто игнорируют. Текст редко подскажет модели, является ли чанк черновиком, текущей политикой, приложением контракта или решённым тикетом. Добавьте тип документа, версию, номер раздела, область продукта и дату. Без этого извлечение вынуждено угадывать.

Быстрая проверка перед запуском

Быстрый тест покажет, помогает ли подход или просто делает индекс аккуратным. Прогоните тест на реальных вопросах, а не на подсказках для демо.

Возьмите по пять реальных вопросов на каждый тип документа. Для контрактов: «Сколько уведомления требуется для расторжения?» Для руководств: «Какие шаги сбрасывают устройство?» Для тикетов: «Что в прошлый раз исправило эту ошибку?» Для политик: «Кто утверждает исключение?» Используйте формулировки, которыми ваша команда реально пользуется в поиске, чате или поддержке.

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

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

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

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

Это медлительный вечер — но он экономит недели гонки за странными ответами позже.

Что делать дальше

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

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

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

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

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

Если хотите второго мнения, Oleg Sotnikov (oleg.is) работает как внештатный CTO и советник по разработке AI‑первичных продуктов и системам извлечения в продакшне. Внешний обзор может помочь понять, какие правила чанкинга действительно работают, а какие просто увеличивают индекс.

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