Разбиение документов для RAG: фрагмент должен сохранить условие ответа

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

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

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

Фрагмент — это не абзац, а минимальная единица, которая отвечает на вопрос целиком

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

Поэтому единица разбиения — не «примерно страница» и не «столько-то символов», а смысловой блок, который самодостаточен. Абзац про сроки возврата и абзац про исключения из сроков — это один блок, даже если между ними пустая строка. Таблица с ценами и примечание под ней «цены без НДС» — тоже один блок. Разрезать по формальному признаку (по количеству знаков, по каждому заголовку, по каждой строке таблицы) удобно скрипту, но не тому, кто потом читает выдачу.

У этого правила есть цена: чанки становятся неровными. Где-то три строки, где-то полторы страницы. Это нормально. Ровность размера — удобство инфраструктуры, а не свойство смысла. Гораздо хуже, когда ради красивой статистики «в среднем 800 символов» условие отрывается от утверждения.

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

Что реально ломается: пять типовых разрывов

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

Таблица, разрезанная построчно. Прайс-лист или матрица скидок, разбитая на отдельные строки, теряет шапку. Строка «Партнёр — 12%» без заголовка столбцов теряет базу расчёта: 12% от какой суммы и на каких условиях. Если таблица большая, её режут по смысловым группам строк, дублируя шапку и связанные примечания в каждом фрагменте — иначе строка теряет условия.

Потерянный заголовок. Раздел «Гарантийные обязательства» разбит на абзацы, и в каждом фрагменте остался только текст без названия раздела. Отдельный абзац «Срок составляет 24 месяца» вне контекста может относиться к чему угодно — к гарантии, к рассрочке, к договору аренды. Заголовок нужно «приклеивать» к каждому фрагменту раздела как наследуемый ярлык.

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

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

Ссылка на приложение. «Подробности — в Приложении 3». Сам фрагмент корректен, но ответ неполон без приложения. Если приложение проиндексировано отдельно и никак не связано с основным текстом, связка теряется.

Наследуемые заголовки и метаданные: как фрагмент помнит, откуда он

Самый дешёвый способ сохранить контекст — не резать документ «в отрыве от дерева», а протаскивать в каждый фрагмент путь к нему. У документа есть название, у раздела — заголовок, у подраздела — свой. Если каждый чанк несёт цепочку «Договор поставки → Раздел 4. Возврат → 4.2. Акционные позиции», то даже вырванный из середины абзац знает, о чём он. Это не украшение: поисковый запрос «возврат акционного товара» гораздо лучше совпадёт с фрагментом, где эти слова есть и в заголовке, и в тексте.

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

Отдельно стоит продумать, что делать с перекрёстными ссылками. «См. п. 5.1» внутри документа — это указатель, который после разбиения перестаёт работать: п. 5.1 может оказаться в другом фрагменте или вообще не попасть в индекс. Практичный приём — при подготовке либо разворачивать ключевые ссылки в самодостаточную формулировку, либо хранить в метаданных фрагмента список связанных пунктов и подтягивать их при выдаче. Второй путь сложнее, но честнее: он не искажает исходный текст.

Фрагмент документа для RAG: что именно мы храним и проверяем

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

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

Отдельно про таблицы и списки. Их стоит хранить как отдельный тип, а не как «текст с переносами», потому что при выдаче их полезно показывать целиком, а не в обрезанном виде. Строка прайса, вырванная из середины, хуже, чем таблица из десяти строк, показанная полностью: читатель сам найдёт нужную строку, если видит шапку.

Условный эпизод: прайс, сноска и менеджер, который поверил выдаче

Разберём первый подробный случай, целиком условный. Компания торгует оборудованием, у неё есть прайс-лист в виде таблицы: модель, базовая цена, скидка партнёра, срок поставки. Под таблицей — сноска мелким шрифтом: «Цены указаны без НДС; для позиций со сроком поставки свыше 30 дней действует предоплата 50%». Менеджер спрашивает у ассистента: «Какие условия по модели X, если поставка 45 дней?»

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

Что меняется при аккуратном разбиении. Таблица хранится как единый объект с шапкой, а сноска приклеена к ней как примечание — либо в том же фрагменте, либо отдельным фрагментом с явной связью «примечание к таблице цен». Тогда на вопрос про 45 дней выдача приносит и строку, и условие предоплаты. Ответ становится полным, а менеджер не обещает клиенту цену без предоплаты.

Здесь важно, что проблема была не в модели и не в поиске как таковом. Оба работали корректно. Сломалось разбиение: условие, без которого ответ неверен, оказалось физически в другом месте индекса. И заметьте — укрупнение фрагментов «на всякий случай» тоже не панацея: если склеить весь прайс в один гигантский кусок, поиск по конкретной модели начнёт размываться, а в выдачу полезет лишнее.

Условный эпизод: регламент, две редакции и пункт, который отменили

Второй случай, тоже условный, про версии. Отдел закупок ведёт регламент согласования заявок. В прошлой редакции порог согласования был один, в новой — другой, и появился пункт «заявки свыше порога дополнительно согласуются с финансовым контролем». Обе редакции лежат в общей папке, потому что «вдруг пригодятся». Ассистент получает вопрос: «Кто согласует заявку на такую-то сумму?»

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

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

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

Где проходит граница: что разбиение не решает

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

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

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

Фрагмент документа для RAG на экране сотрудника

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

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

Третий — возможность пожаловаться на конкретный фрагмент. Кнопка «этот ответ неверен / устарел / неполон» с привязкой к chunk_id превращает разрозненные жалобы в очередь на пересборку конкретных документов. Без такой привязки вы будете получать «ассистент врёт» без адреса, и чинить придётся наугад.

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

Как проверить разбиение: тестовые вопросы и что они ловят

Проверка начинается не с настройки, а с набора вопросов, на которые система обязана отвечать правильно. Соберите их из реальных обращений сотрудников — тех, где ответ требует условия, исключения или второй половины абзаца. Десяти-пятнадцати таких вопросов обычно хватает, чтобы увидеть основные разрывы.

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

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

Фрагмент документа для RAG: исключения и проверка условий

Есть документы, которые сопротивляются любой единой схеме. Смета с вложенными разделами и итогами: если резать по строкам, итоги теряют смысл; если не резать — фрагмент огромен. Разумный компромисс — хранить смету целиком как объект и дополнительно индексировать отдельные смысловые блоки со ссылкой на родителя. Тогда поиск найдёт нужный раздел, а при выдаче можно показать его в контексте всей сметы.

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

Третий — документы с формулами и схемами, где текст ссылается на рисунок. Если рисунок не проиндексирован, фрагмент «как показано на схеме» повисает в воздухе. Здесь либо описывать схему текстом при подготовке, либо честно помечать фрагмент как неполный.

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

Практикум: разобрать один документ и один вопрос

Возьмём условный документ — инструкцию по оформлению возврата — и один условный вопрос: «Клиент хочет вернуть товар, купленный три недели назад по акции, что делать?» Задача практикума — не настроить систему, а руками пройти путь фрагмента и увидеть, где рвётся смысл.

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

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

Рекомендации, а не гарантии

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

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

Один шаг проверки

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

Смежный вопрос разобран отдельно: RAG-система: как ИИ находит ответ в ваших документах.