Стратегии разбиения данных для практического использования в RAG: фиксированный размер, семантическое разбиение и структура «родитель-дочерний».
Практический обзор процесса разбиения данных в RAG: от фиксированного размера и рекурсивного разделения до структуры «родитель-дочерний», предложений, позднего разбиения, метода RAPTOR, таблиц, кода и тестирования производительности.
Источники: Chunking Strategies for Production RAG: From Fixed-Size to Context-Aware and Multimodal Retrieval
Предположим, сотрудник, занимающийся обработкой претензий в страховой компании, спрашивает внутреннего ассистента: какое одобрение требуется для претензии на возмещение ущерба от воды в размере 40 000 евро и что необходимо проверить перед выплатой? Ассистент опирается на действующее руководство по обработке претензий. Файлы были корректно загружены, OCR сработало, предварительная обработка устранила шум, модель встраивания нашла нужное руководство, а алгоритм переранжирования вывел его в верхнюю часть списка.
Ответ всё равно остается неполным.
Опытный сотрудник по урегулированию случаев не удивится. Правило не изложено в одном абзаце. В описательном предложении говорится, что заявки, связанные с подозрением в предшествующих повреждениях, требуют независимой инспекции перед выплатой. Под этим предложением приведена таблица полномочий. На следующей странице находится диаграмма потока, показывающая, что сначала также необходимо провести проверку на мошенничество и подтвердить право собственности. В системе документации указываются идентификатор руководства, его версия и регион применения.
Для специалиста, работающего с этими документами, это не четыре отдельных факта. Это одно бизнес-правило, изложенное в четырех разных форматах: абзац определяет условие, таблица указывает, кто может одобрить заявку, диаграмма показывает порядок проверок, а метаданные указывают действующую версию.
Стандартный разделитель, настроенный на 500 токенов, может поместить абзац в один фрагмент, верхнюю половину таблицы — во второй, соответствующую строку таблицы — в третий, а извлеченный текст диаграммы — в четвертый. Каждый фрагмент считается допустимым. Каждая попытка вставки данных успешна. Панель управления остается зеленой. Однако знания были фундаментально перестроены. Во время запроса системе необходимо связать тип утверждения с диапазоном значений, соотнести его с лицом, уполномоченным принимать решения, найти требования к проверке и восстановить все необходимые данные, причем всё это из фрагментов, которые невозможно прочитать по отдельности. Языковая модель получает эти фрагменты и формирует неполный ответ.
Именно поэтому отладка с использованием технологии RAG вводит в заблуждение. Команды меняют модели вставки данных, увеличивают параметр top-k, покупают более мощные алгоритмы переупорядочивания или переписывают запросы. Иногда это помогает. Чаще же это лишь компенсирует ущерб, нанесенный при сегментации данных. Низкое качество реализации технологии RAG часто является следствием проблем с разделением данных на фрагменты, маскирующихся под проблемы с самой языковой моделью.
Большинство обсуждений по теме разбиения текста сводится к одному числу: 256 токенов, 512 или 1 000, а также к вопросу о степени перекрытия. Это вполне разумные вопросы реализации, но архитектурный вопрос отличается:
Что должно оставаться вместе, чтобы при извлечении по отдельности текст всё равно имел тот же смысл?
Далее рассматриваются от самых простых стратегий до техник, появившихся в 2024 и 2025 годах; указываются случаи, когда каждая из них оправдывает свои затраты, и в конце приводится проект для практического использования, способный справляться со сложными корпоративными документами.
Место разбиения текста в процессе обработки
Разбиение текста — это не изолированный шаг обработки. Это граница между пониманием чистых документов и созданием поисковой базы знаний. Все этапы, предшествующие ему, определяют, что можно разделить, а все последующие зависят от того, сохраняют ли полученные фрагменты достаточно смысла, структуры и информации о происхождении для правильного поиска.
Представьте себе полный путь. Источники вроде PDF, таблиц, изображений, JSON, баз данных, API и кода обрабатываются: они принимаются, анализируются, очищаются и нормализуются. Только после этого слой разбиения на части определяет, как каждый тип контента превращается в единицу поиска. Для повествовательного текста может использоваться структурное или семантическое разделение. Для сложных правил подходят представления на уровне предложений. Таблицам необходимы границы, соответствующие их схеме. JSON должен соответствовать бизнес-объектам. Изображения требуют визуальных описаний, связанных с исходным файлом.
Поэтому в производственных системах редко используется единый размер частей для всего. Один корпус может содержать представления на уровне документа, раздела, абзаца, предложения и токена одновременно. Пары «родитель-дочерь» используют маленькие части для точности и более крупные — для контекста, в то время как позднее разбиение на части, контекстуальный поиск и технология RAPTOR восстанавливают информацию, которая иначе была бы потеряна в результате разделения.
Процесс разбиения на части также не завершается с появлением векторов. Метаданные частей, версии документов, связи между родительскими и дочерними элементами, механизмы контроля доступа и ссылки на исходные материалы должны сохраняться на протяжении всего процесса индексации, поиска, переранжирования, сбора контекста и генерации результатов. Оценка закрывает этот цикл: случаи неудачного поиска, дублирование контекста, неверные цитаты и изменения в шаблонах запросов должны влиять на решения, связанные с разбиением документов на части. В реальных условиях разбиение документов заключается не столько в их разрезании, сколько в проектировании единиц поиска, на которых основывается вся остальная работа.
Основной компромисс
Возьмем краткий отрывок из документа с правилами:
High-risk corporate customers must complete Enhanced Due Diligence.
Facilities above EUR 10 million require Group Credit Committee approval.
Fully cash-collateralised facilities may follow the exception defined in Section 7.4.3.
Сохранение всего вместе помогает сохранить контекст, но приводит к получению общего, размытого вектора. Агрессивное разделение обеспечивает точный поиск, однако правило утверждения может отклоняться от класса клиентов, к которому оно применяется, а исключение может оказаться оторванным от правила, которое оно изменяет.
В этом и заключается вся напряженность: небольшие фрагменты повышают точность, большие фрагменты сохраняют контекст, а производственные системы требуют осознанного баланса. Каждая техника разбиения на фрагменты — это свой путь в этом компромиссе, и ни одна из них не устраняет необходимости знания документов и вопросов, которые на самом деле задают пользователи.
Простые базовые подходы
Разбиение на фрагменты фиксированного размера
Разбиение на фрагменты фиксированного размера предполагает разделение текста на блоки определенной длины, обычно по токенам, с возможностью перекрытия. Этот метод прост, детерминирован и экономичен.
Подсчёт токенов обычно эффективнее подсчёта символов, поскольку модели с вкладками работают с токенами. Пятьсот символов на немецком или китайском языках могут содержать гораздо меньше значимых единиц, чем такое же количество символов на английском языке. Метод заключается в кодировании текста в токены, последовательном обработке их с фиксированным интервалом и декодировании каждого окна. Накладка означает, что каждое окно начинается до того, как закончится предыдущее.
- Хорошо подходит для: однородного прозаического текста, базовых тестовых сценариев, случаев, когда наиболее важна операционная простота, и ранних прототипов, которым сначала нужна рабочая инфраструктура.
- Не срабатывает, когда: значение зависит от структуры. Условие может заканчиваться на токене 499, в то время как его исключение начинается на токене 501, причём границы ничего не знают о бизнес-логике.
Что делает накладка
Перекрытие служит защитой от сбоев при определении границ. Без него предложение может быть разделено на две части, и ни одна из них не будет иметь смысла сама по себе. С перекрытием каждая часть содержит элементы соседней, поэтому обе остаются понятными.
Цена этого подхода реальна: больше векторов, большие затраты на генерацию эмбеддингов, увеличение объема хранилища и списков результатов, забитых практически идентичными фрагментами текста. Показатель в двадцать процентов — это скорее привычка, чем закон, поэтому рассматривайте его как параметр для сравнения с показателями эффективности поиска.
Разбиение на фиксированного размера заслуживает внимания не благодаря оптимальности, а за предоставление стабильной базы для сравнения. Если более сложный метод не может значимо превзойти его на вашем корпусе данных, дополнительная сложность не оправдана.
Рекурсивное разделение
В корпоративных документах полезные границы уже заданы в заголовках, разделах, абзацах, предложениях и списках. Рекурсивное разделение использует эти границы прежде, чем обратиться к произвольным точкам разреза. Например, рекурсивный сепаратор символов из LangChain сначала пробует использовать двойные переносы строк, которые обычно обозначают абзацы. Если фрагмент всё ещё слишком большой, он пробует использовать одиночные переносы строк, затем знаки препинания в конце предложений, затем пробелы и, наконец, отдельные символы. Предел размера — это порог, при достижении которого применяется соответствующий метод разделения.
Порядок использования разделителей важнее, чем само число размера. Для хорошо структурированных политик, процедур, руководств и технической документации это часто является эффективным стандартным решением.
Один совет по обработке: если при извлечении уже была определена иерархия, не удаляйте её и не просите инструмент разделения заново её находить. Раздел с номером 7.4 в главе, посвящённой выдаче займов, уже указывает, какие тексты относятся друг к другу. Сохраняйте эту структуру в метаданных и используйте её для ограничения процесса разделения. Проще говоря, не разрушайте структуру во время разбиения на части, а затем не пытайтесь её восстановить при извлечении информации.
Рекурсивное разделение предполагает, что структура в целом соответствует смыслу, но это не всегда так. Один абзац может содержать три не связанных между собой правила, а пять абзацев могут описывать один процесс. Именно здесь и пригодяются методы, основанные на смысле.
Единицы — предложения и абзацы
Инструменты вроде spaCy и NLTK предоставляют обученные детекторы предложений, которые справляются с проблемами, возникающими при наивном разделении текста на предложения: сокращениях, десятичных числах, названиях и тройных тире. Разбиение на абзацы проще и часто более эффективно, поскольку абзац — это группировка, сознательно выбранная автором. Для чистых документов разделение на абзацы и объединение коротких соседних фрагментов до минимального размера представляет собой разумный компромисс между подходами с фиксированным размером и семантическими подходами.
Недостаток заключается в переменном размере фрагментов. Некоторые абзацы содержат 50 токенов, а другие — 800, что усложняет их группировку, увеличивает задержки при создании эмбеддингов и затрудняет прогнозирование размера индекса. То, оправдывают ли лучшие границы такие трудности, зависит от корпуса данных.
Подвижные окна как инструмент для повышения точности
Слайдинг-виндоу — это метод разбиения на фиксированного размера блоки, при котором перекрытие текстов рассматривается как механизм поиска, а не просто средство обеспечения границ. Логика заключается в том, что вектор запроса наилучшим образом совпадает с тем отрывком, который прямо на него отвечает. Если этот отрывок расположен между границами в рамках одного блока, ни один из блоков не сможет получить высокий балл. При достаточном уровне перекрытия каждый отрывок разумной длины будет полностью включён хотя бы в один блок.
Увеличение уровня перекрытия повышает точность восстановления информации, но при этом возникает избыточность. При уровне перекрытия свыше 30–40 процентов списки типа top-k заполняются почти идентичными записями, которые тратят ресурсы на хранение контекста без добавления новых фактов; для большинства корпусов подходит уровень перекрытия 10–25 процентов. Оценивайте уровень перекрытия, измеряя коэффициент возврата дубликатов наряду с показателем Recall@k, поскольку повышение Recall@5 при удвоении количества дубликатов может не улучшить качество ответов.
Стратегии, учитывающие смысл
Семантическое разбиение на блоки
Семантическое разбиение заменяет правило подсчёта токенов вопросом: изменилась ли тема настолько, чтобы начать новый блок? Представьте раздел, в первых двух предложениях которого описаны требования к инспекции, в третьем — лимиты оплаты, а в четвёртом — правила борьбы с мошенничеством. Фиксированный инструмент разделения не может распознать такие смены тем, в то время как хорошо настроенный семантический разбиватель может.
Типичный алгоритм включает три этапа. С помощью лингвистической модели текст разделяется на предложения. Каждое предложение или небольшой фрагмент из соседних предложений преобразуется с помощью инструмента sentence-transformer. Затем вычисляется косинусовое расстояние между соседними векторами представлений, и устанавливается граница там, где это расстояние превышает установленный порог в процентах, обычно между 85-м и 95-м процентилями расстояний в данном документе.
Этот порог является критической настройкой. Если он слишком высок, связанные между собой идеи разлетаются на крошечные, бессмысленные фрагменты. Если слишком низок, отдельные темы остаются объединёнными, восстанавливая шум, который вы хотели устранить.
Это также увеличивает затраты, поскольку перед определением границ необходимо выполнить полный проход эмбеддинга. Для коротких, структурированных документов такие затраты имеют незначительный эффект. Однако для длинных текстов с нерегулярным форматированием выявление реальных смен тем может значительно улучшить процесс поиска. Есть одно важное ограничение: метод предполагает, что темы меняются постепенно и заметно между предложениями. В сложном юридическом или нормативном тексте, где одно предложение может содержать три условия и два исключения, расстояния на уровне предложений создают шумные сигналы.
Разбиение на группы «родитель-дочерь»
Это один из наиболее эффективных подходов в практическом применении технологии RAG, поскольку он решает противоречие, которое игнорируют методы обработки по отдельным единицам: лучшая единица для поиска информации не всегда является лучшей для её генерации.
Возьмём фрагмент длиной 2 000 токенов, охватывающий темы ограничений, исключений, механизмов контроля и процедур эскалации. Если включить его целиком, это сохранит контекст, но даст расплывчатый вектор. Разделение на фрагменты по 200 токенов улучшит точность поиска, однако найденный фрагмент может не содержать всего необходимого для корректного анализа со стороны модели.
Метод разбиения на родительские и дочерние фрагменты разделяет эти две задачи. Родительский фрагмент — это более крупная целостная часть текста, такая как целое предложение, процедура или подраздел. Дочерние фрагменты — это более мелкие, сфокусированные части, полученные из родительского: отдельные условия, пороговые значения или исключения. Для включения в модель и поиска используются только дочерние фрагменты. Когда находится дочерний фрагмент, его идентификатор родителя позволяет загрузить более крупный исходный текст, который и читает модель.
LlamaIndex и LangChain предлагают реализации этого механизма с использованием иерархических узлов, поиска от небольших до крупных объемов данных и поиска родительских документов. Каждый дочерний элемент хранит ID родителя в своих метаданных, и после поиска происходит расширение результатов до уровня родительских элементов перед сбором контекста.
В регулируемых средах идентификаторы должны иметь четкую привязку к источнику. Читаемый ID, объединяющий информацию о документе, версии и разделе, безопаснее произвольного UUID, поскольку дочерний элемент версии 7.2, связанный с родительским элементом версии 7.1, создает контекст, который кажется правдоподобным, но на самом деле содержит ошибки. Эта схема работает и в разных форматах данных: дочерний элемент может быть сериализованной строкой таблицы, визуальным описанием диаграммы или предложением, причем все они имеют общего родителя, соответствующего одному логическому разделу.
Разбиение на части на основе предложений
Возьмём предложение из политики кредитования: рискованные корпоративные заемщики требуют усиленной проверки на предмет кредитоспособности и ежегодного анализа, причём комитет должен давать согласие каждый раз, когда их уровень риска превышает установленный лимит. В нём содержатся три чётких факта. Система поиска, отвечающая на вопрос о том, как часто проверяются такие клиенты, не должна проходить через все критерии одобрения, чтобы найти соответствующий результат.
Разбиение предложений на части приводит к тому, что текст разделяется на атомарные, самодостаточные утверждения, каждое из которых можно извлечь отдельно. Извлечение обычно осуществляется во время построения индекса с помощью языковой модели на основе тщательно структурированного запроса, который сохраняет все условия, пороги, ограничения и исключения, разрешает использование местоимений там, где это возможно в тексте, и не делает выводов, не указанных прямо. Для приведенного выше предложения результатом может стать три утверждения: такие клиенты требуют проведения тщательной проверки, ежегодного анализа, и при превышении порога риска — одобрения комитетом.
Каждое утверждение получает собственное векторное представление, поэтому векторный пространство становится пространством атомарных фактов, а не целых отрывков текста, что повышает точность при задавании узких, ориентированных на поиск фактов вопросов. Действуют два ограничения на формирование результатов:
- Предложение не является источником истины. Это представление, сгенерированное моделью. При работе в регулируемых условиях сначала извлекаются предложения, а затем обращаются к авторитетному тексту для получения оснований, обоснований и цитат. Предложение — это запись в индексе, а не утверждение.
- Затраты растут стремительно. Один документ объемом 10 000 токенов может содержать сотни предложений, каждое из которых требует вызова функции встраивания, поэтому индекс быстро увеличивается.
Восстановление потерянного контекста
Позднее разбиение на чанки
Традиционный способ разбиения сначала делит текст на части, а затем встраивает каждую из них отдельно. Способ позднего разбиения на чанки, введенный Jina AI в 2024 году, меняет часть этой последовательности.
Метод позднего разбиения на чанки сначала пропускает весь документ через модель эмбеддингов с длинным контекстом для получения представлений токенов на уровне контекста. После этого задаются границы чанков путем объединения векторов токенов, находящихся внутри каждого окна. Отличие от простого использования более крупных чанков заключается в том, что единица поиска остаётся небольшой. Текст по-прежнему сфокусирован, но его вектор отражает среду, в которой он появился. Местоимения, аббревиатуры, прямые ссылки и термины, определённые ранее, обрабатываются в процессе генерации эмбеддингов, а не оставляются на рассмотрение модели в момент генерации текста.
Затраты на инфраструктуру действительно велики. Для этого требуется модель эмбеддингов длинного контекста, обеспечивающая вывод на уровне токенов, дополнительная память для индексации и тщательно проработанный код объединения данных. Она также не может исправить проблемы с плохой сегментацией: таблица, сериализованная некорректно, или диаграмма, добавленные на этапе предобработки, остаются недоступными. Эта модель решает проблему потери контекста во время генерации эмбеддингов, но не решает проблемы на более ранних этапах. Для корпусов с тесными межвыраженческими связями, такими как нормативные документы, контракты и руководства, улучшение качества эмбеддингов может быть значительным.
Контекстуальный поиск
Метод контекстуального поиска от Anthropic, опубликованный в 2024 году, подходит к решению той же проблемы изоляции по-другому. Он не изменяет архитектуру эмбеддингов, а обогащает тексты, используемые для поиска в каждом фрагменте, на этапе создания индекса.
Одиночное предложение, указывающее на ограничение, может не соответствовать запросу, содержащему информацию о классе клиента, юрисдикции и органе, уполномоченном давать разрешения, поскольку эти термины находятся в окружающем документе. Поэтому перед индексацией для каждого фрагмента генерируется краткое утверждение, специфичное для документа, в котором указывается, из какой части какой версии политики взят отрывок и что он определяет. Это утверждение добавляется в начало, и полученная комбинация включается в индекс.
По оценкам Anthropic, сочетание контекстуальных эмбеддингов с алгоритмом BM25 в контекстуальном режиме сократило количество ошибок при поиске в топ-20 на 49 процентов, а добавление этапа переранжирования сократило их ещё на 67 процентов. Эти цифры основаны на собственных корпусах данных Anthropic и не являются гарантиями. Фактическая эффективность зависит от ваших документов, запросов, модели эмбеддингов и настроек поиска. Важно не сами цифры, а то, что добавление контекста, специфичного для конкретного документа, к изолированным фрагментам может существенно помочь в тех случаях, когда важное значение находится за пределами границы фрагмента.
Это наиболее эффективно помогает с неоднозначными фрагментами: отдельными строками таблиц, подписями к изображениям, упоминаниями определенных терминов и фрагментами, объем которых определялся родительским разделом, к которому они больше не относятся. Он также хорошо сочетается с механизмом поиска в рамках отношений «родитель-дочерний». Существует одно важное правило: генерируемый контекст служит лишь вспомогательным инструментом для поиска, а не источником информации. Если всем фрагментам присваивать одинаковое общее описание, векторы станут слишком похожими, что ухудшит качество поиска. Хорошая контекстуализация включает только то, что необходимо для понимания фрагмента без учета его соседних элементов.
RAPTOR: несколько уровней абстракции
RAPTOR, сокращение от Recursive Abstractive Processing for Tree-Organized Retrieval, решает проблему, характерную для поиска одного уровня: детальные фрагменты хорошо отвечают на узкоспециализированные фактологические вопросы, но плохо справляются с вопросами, требующими синтеза информации из разных разделов. Сравните запрос о том, кто утверждает тот или иной факт, с запросом о всей системе контроля организации для данного типа фактов. На первый вопрос есть один авторитетный ответ в таблице, а на второй требуются доказательства из правил проверки, полномочий по делегированию, политик поддержки или восстановления данных, процедур рассмотрения и механизмов уровневой передачи ответственности, причем, вероятно, из разных разделов и документов.
RAPTOR создаёт иерархию. Исходные фрагменты образуют нижний уровень. Связанные фрагменты группируются на основе степени схожести, а языковая модель подводит итоги для каждой группы. Эти краткие обзоры затем снова группируются и обобщаются, причём процесс повторяется до тех пор, пока не останутся несколько обзоров высокого уровня, отражающих весь документ или корпус. При поиске узкоспециализированный вопрос может соответствовать отдельному фрагменту, тогда как более общий вопрос — обзору высокого уровня, поэтому одна система может обрабатывать оба типа запросов без изменений в архитектуре.
Основная проблема при создании контента — происхождение информации. Краткие изложения являются интерпретациями, а интерпретации могут искажать критерии, крайние случаи и исключения, то есть те детали, которые имеют наибольшее значение в регулируемой работе. Используйте узлы высокого уровня для поиска соответствующих частей корпуса, затем возвращайтесь к исходным текстам перед генерацией. Краткое изложение помогает найти доказательства, а исходный текст служит основой для выводов модели. RAPTOR оправдывает свою стоимость при работе с длинными документами, нормативными рамками и большими руководствами, где пользователи задают как детальные, так и обобщающие вопросы в рамках одного запроса. Для коротких наборов данных или однотипных типов запросов такая сложность редко оправдывается.
Структурированный и нетекстовый контент
Таблицы: структура — это смысл
Вернитесь к таблице авторитетов. В ней хранятся явные связи: тип претензии — ущерб от воды, диапазон сумм выше 25 000 евро, утверждающий лицо — региональный менеджер по претензиям. Если преобразовать её в последовательность слов, связи между столбцами, придающие смысл каждому значению, исчезнут, поэтому таблицам требуется специальный подход.
При использовании небольших таблиц часто лучше сохранять их целостность, особенно когда запросы сравнивают строки или требуют полного набора условий. Необходимо представить данные так, чтобы связи между столбцами и строками сохранялись, например, преобразовав каждую строку в пары «метка-значение», обозначающие каждый столбец. При использовании больших таблиц строки позволяют делить данные на более точные части, но каждая строка должна содержать свои заголовки, поскольку три простых значения без меток сами по себе не имеют смысла.
Под процессом сериализации скрывается более важное решение. Если пользователи задают детерминированные вопросы, такие как перечисление всех утверждающих суммы, превышающие определенный порог, использование методов векторного поиска может оказаться совершенно неподходящим решением. Таблицы, получаемые с помощью SQL или dataframe, превосходят любые методы на основе эмбеддингов для поиска с точными фильтрами. Принцип заключается в следующем: не стоит уничтожать явную структуру лишь для того, чтобы всё выглядело как текст.
JSON и структурированные записи
Тот же принцип применим и к JSON. Запись, содержащая поля segment, rating, region, amount, approver и флаг review, уже показывает, какие поля связаны между собой, поэтому использование инструмента разделения токенов для сериализованного JSON игнорирует это. Небольшие записи должны оставаться целыми, с удобной формой поиска, которая отображает каждое поле вместе с его меткой. Для крупных объемов данных необходимо выявить естественные бизнес-элементы, такие как клиенты, счета, транзакции, события проверки или решения по делам, и разделить данные вокруг них.
Внутри записи следует разделять семантические поля от тех, которые можно фильтровать. Поля, касающиеся вопросов на естественном языке, должны входить в состав эмбеддинга. Такие поля, как region, version, business unit и effective date, обычно лучше использоваться в качестве фильтров метаданных в индексе, чем как часть вектора. Предварительный фильтрация по метаданным происходит быстрее и с большей точностью для категориальных ограничений, а также позволяет сохранить смысловую составляющую эмбеддинга.
Код: синтаксис — это граница
Код создает аналогичные проблемы в других областях. Универсальный инструмент разделения, рассекающий файл на Python на 500-м токене, может отделить функцию от её оператора возврата или класс от его методов. Для поиска кода границы должны соответствовать синтаксису: функции, методы, классы и модули. Модуль ast в Python может преобразовать исходный код в дерево и извлечь каждую функцию, асинхронную функцию и класс как целостную единицу, так что фрагменты кода будут соответствовать семантике языка, а не просто ориентироваться на количество символов. Для репозиториев на многих языках библиотека tree-sitter предоставляет единый интерфейс парсинга для десятков языков и справляется с крайними случаями, которые упускают регулярные выражения. Структура «родитель-дочерний» работает естественно: сначала получаются точные данные о методе, а затем, когда модели нужен более широкий контекст, они расширяются до соответствующего класса или файла.
Диаграммы и изображения
Не рассматривайте текст, полученный с помощью OCR, как полное отражение визуального изображения. Диаграмма потоков передает смысл с помощью стрелок, последовательности действий, разветвлений, группировки элементов и пространственного расположения, чего OCR не может зафиксировать. Используйте модель, способную обрабатывать изображения, чтобы составить описание того, что передаёт изображение, а не только перечислить содержащиеся в нём слова. Храните указатель на оригинальное изображение. Сгенерированное описание служит записью в индексе, тогда как исходное изображение является доказательством, отображаемым системой. В регулируемых системах цитата должна указывать на оригинальное визуальное изображение, а не на его описание.
Маршрутизация по типу контента
Настоящие документы имеют сложную структуру. Один руководство может содержать описательные правила, таблицу источников, диаграмму процесса, метаданные в формате JSON и встроенные ссылки. Нет никаких разумных оснований применять один инструмент обработки ко всем четырем типам документов, поскольку каждый из них несет информацию по-разному: абзац — через лингвистическую связность, таблица — через пересечения строк и столбцов, диаграмма — через положение, направление и группировку элементов, а JSON — через явные ключи.
Оптимальным решением является маршрутизатор с разбиением на части — диспетчер, который определяет тип содержимого каждого извлеченного блока и направляет его в соответствующую стратегию обработки. Этот маршрутизатор не должен быть сложным; его ценность заключается в том, что он превращает маршрутизацию по типу содержимого в осознанный дизайнерский выбор, а не в случайный результат применения универсального разделителя. Для руководства по требованиям описания будут использоваться структурное или семантическое разбиение, для таблиц — сериализация с учетом структуры таблицы, для диаграмм — модель визуализации для описания, а для JSON-метаданных — разделение с учетом объектов.
Каждый полученный фрагмент должен содержать одинаковые основные метаданные, такие как идентификатор документа, версия, идентификатор родителя, раздел и область. Благодаря этой общей структуре последующие этапы могут понимать, что строка таблицы, абзац и описание диаграммы являются связанными элементами одного раздела.
Когда преимущество имеют более крупные единицы
Большая часть описанных выше подходов направлена на повышение степени детализации, что может создать ложное впечатление о том, что меньше всегда лучше. Исследования LongRAG рассматривали противоположное направление, проверяя, могут ли гораздо более крупные единицы извлечения данных — в некоторых экспериментах до 4 000 токенов — превзойти детализированное извлечение при решении сложных многоэтапных задач. Результаты показали, что крупные фрагменты не являются универсально лучшими; скорее, степень детализации извлечения должна соответствовать степени детализации запроса.
На вопрос о том, как часто необходимо пересматривать определенный тип учетной записи, можно дать ответ размером с одно предложение. Для получения полной информации о рамках управления определенным типом утверждений требуются данные из нескольких областей, и детализированное извлечение данных может заставить систему собирать общий ответ из множества изолированных фрагментов, в результате чего возникают ошибки сборки даже при том, что каждый фрагмент верен.
Выбор и оценка
Как выбрать стратегию
Ни одна стратегия разбиения на части не является оптимальной во всех случаях. Выбор зависит от структуры документа, типов запросов, лимита задержек, толерантности к затратам на индексацию и специфики последующей обработки. Тип запроса имеет такое же значение, как и тип документа. Одна и та же схема может использоваться как для узких поисковых запросов, касающихся минимальной частоты проверки, так и для широких запросов на объяснение всей структуры, причем для них требуется разная степень детализации результатов поиска. Если ваши данные для оценки охватывают только один тип, оптимальная стратегия может показать худшие результаты в реальных условиях использования.
Ориентир:
- Единообразный текст, ранний прототип: фиксированный размер с умеренным перекрытием частей.
- Хорошо структурированные руководства и инструкции: рекурсивное или основанное на структуре разбиение, при этом иерархия сохраняется в метаданных.
- Длинные повествования с нерегулярным форматированием: семантическое разбиение, если дополнительные затраты приводят к ощутимой прибавке качества результатов.
Эталонные тесты вместо догадок
Быстрый взгляд на несколько фрагментов и вывод о том, что они кажутся разумными, помогает при отладке, но это не оценка. Настоящий вопрос заключается в том, помогает ли та или иная стратегия системе извлечения найти доказательства, необходимые для запросов, которые на самом деле отправляют пользователи.
Создайте набор для оценки, охватывающий различные типы задач: узкую информацию, связанную с одной строкой таблицы; вопросы, требующие нескольких источников доказательств и включающие повествовательную часть с описанием процесса; условные вопросы об исключениях; а также синтетические вопросы, объединяющие данные из нескольких разделов. Свяжите каждый запрос с идентификаторами единиц данных, которые необходимо найти.
Сам по себе показатель эффективности поиска недостаточен. Зафиксируйте размер индекса по сравнению с базовым значением фиксированного размера, стоимость генерации векторных представлений для каждого документа, время индексации и поиска, количество контекстных токенов в каждом запросе, долю дубликатов, точность ответов и корректность цитат. Три дополнительных балла по показателю Recall@5 имеют мало значения, если размер индекса увеличивается в четыре раза, а результаты заполняются почти идентичными копиями.
В типичном корпусе политик вероятным паттерном является то, что рекурсивное разделение превосходит метод с фиксированным размером на несколько пунктов при одинаковых затратах по индексу, семантическое разбиение добавляет ещё немного при умеренных дополнительных затратах, метод «родитель-дочерний» повышает точность воспроизведения ещё больше с заметным увеличением объёма индекса, а использование предложений вместе с информацией о родителях обеспечивает наивысшую точность воспроизведения, но при значительно более высоких затратах и сложности. Контекстуальный поиск может достичь аналогичной точности при меньшем увеличении объёма индекса, что может оправдать применение соответствующей модели во время индексации, а RAPTOR может уступать методу «родитель-дочерний» при обработке узких фактов, но превосходить его при синтезе информации. Рассматривайте это как иллюстрацию характера компромиссов, а не как точный результат измерений. Оптимальная точка работы зависит от требований к точности, ограничений по задержкам, бюджета на индексацию и от того, оправдывает ли каждое улучшение свою сложность.
Не оптимизируйте поиск в одиночку
Предположим, что сильное перекрытие улучшает показатель Recall@5, но топ-пять результатов теперь содержит четыре практически идентичных фрагмента из одного предложения, в результате чего другой релевантный фрагмент оказывается вне рамок допустимого объема контекста. Один показатель улучшился, но качество работы системы снизилось. Необходимо оценить весь процесс — от поиска и переранжирования до сбора контекста и генерации ответа — проверяя на каждом этапе, сохранились ли необходимые доказательства, не заняли ли дубликаты полезное пространство, верен ли и обоснован ли ответ, а также указывает ли цитата на правильный источник и версию.
В регулируемых системах корректность цитирования — это не вопрос дополнительной роскоши. Ответ может быть фактически верным, но основываться на неверной версии правила. Это по-прежнему считается нарушением требований, и оно остается незамеченным, если не проводить явную проверку происхождения цитат.
Архитектура производственной системы
Основное изменение в подходе заключается в том, что зрелая система управления проектами почти никогда не нуждается в едином инструменте для обработки данных. Ей требуется слой маршрутизации, который направляет каждый блок контента к соответствующей стратегии обработки, хранит метаданные о происхождении всех полученных фрагментов и содержит прямые ссылки на авторитетный источник.
Для руководства по оформлению претензий разумным подходом является следующее: описательные разделы делятся на структурные или семантические части; сложные правила преобразуются в предложения с сохранением родительского элемента; небольшие таблицы передаются целиком в сериализованном виде; большие таблицы разбиваются на блоки строк с учетом заголовков; диаграммы сопровождаются описаниями, соответствующими моделям визуального понимания; а записи в формате JSON разделяются с помощью объектов. Каждый блок, независимо от типа, содержит одинаковые идентификаторы: ID документа, версия, ID родительского элемента, раздел, область и ссылку на исходный документ. Эта общая структура имеет такое же значение, как и сами блоки, поскольку она позволяет восстановить связь между строкой таблицы, правилом и описанием процесса как доказательствами из одного раздела определенной версии.
Возвращение к претензии о ущербе от воды
Вопрос никогда не заключался в том, является ли 500 или 800 токенов правильным размером. В исходном материале содержались различные виды доказательств. В параграфе говорилось о необходимости независимой проверки. В таблице указывалось, кто утверждает диапазон сумм. На диаграмме показаны проверки, предшествующие оплате. Метаданные указывали, какая версия и регион применяются.
Хорошо спроектированный слой разбиения на части сохраняет каждую часть в её исходной структуре и фиксирует, что они принадлежат к одному разделу. Это позволяет при поиске иметь возможность выбора: вопросы, связанные с утверждением, возвращают строку из таблицы, вопросы, связанные с проверкой, — соответствующую клаузулу, вопросы, связанные с обработкой, — описание диаграммы, а сложные вопросы запрашивают несколько связанных элементов и раскрывают информацию об их общем родителе. В этом и заключается разница между простым разбиением текста и проектированием единиц поиска.
Порядок, который имеет значение, не фиксирован: сначала семантика, затем предложения, причем побеждает самая свежая идея. Скорее следует: изучить исходный материал, изучить запросы, сохранить существующую структуру, выбрать степень детализации поиска, восстановить отсутствующий контекст, сохранить происхождение информации, оценить качество поиска и ответов, и добавлять сложность только там, где это действительно необходимо.
Последний чек-лист перед индексацией
Прежде чем фрагменты попадут в процесс генерации эмбеддингов, каждый из них должен соответствовать трем критериям:
- Возможность поиска. Достаточно конкретен, чтобы соответствовать важным запросам, но не настолько общ, чтобы случайно совпадать со всем.
- Интерпретируемость. Содержит достаточно контекста, чтобы сам по себе иметь смысл, или имеет надежный способ восстановления этого контекста через обращение к родительским элементам.
При отсутствии хотя бы одного из этих элементов слой разбиения на части передает свои проблемы на этапы поиска, переранжирования, сбора контекста и генерации ответа. Хранилище векторов с радостью индексирует некачественные единицы данных, API для генерации векторов возвращает вектор без жалоб, а модель может написать на его основе уверенный ответ — при этом ничто не указывает на то, что представление данных верно. Исправление поврежденной единицы данных — самый дешевый способ решения проблемы до того, как она превратится в проблему для генерации векторов.
Перед запуском продукта также необходимо спланировать обработку логов, секретов и конфигураций, использование детерминистичных идентификаторов, версионирование моделей и промптов, отслеживание происхождения частей данных, реализацию механизмов контроля доступа, подготовку наборов данных для оценки, управление жизненным циклом индексов, а также мониторинг качества поиска, задержек и затрат.