Как нарезать юридические документы на чанки
Юридические документы плохо режутся фиксированным окном. Как построить chunking для legal или enterprise RAG?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Chunking идет по структуре документа: раздел, статья, пункт, таблица, definition. Каждый chunk хранит metadata, parent section, overlap и ссылки на источник.
Полный разбор
В legal RAG fixed-size chunking часто ломает смысл. Один пункт может зависеть от заголовка, определения выше по тексту или соседнего подпункта. Поэтому pipeline сначала парсит документ: заголовки, статьи, пункты, подпункты, таблицы, приложения, определения и ссылки на другие разделы.
Chunk строится вокруг смыслового блока. Если пункт короткий, к нему добавляется parent heading и соседний контекст. Если пункт длинный, он делится с overlap и сохраняет ссылку на исходный раздел. Metadata хранит документ, версию, дату, jurisdiction, раздел, номер статьи, тип блока и права доступа.
Качество chunking проверяется через retrieval tasks. Если нужный ответ часто требует два соседних чанка, нужно менять overlap или context assembly. Если retrieval возвращает огромные chunks, генератор получает лишний текст и хуже цитирует источник.
Теория
Chunking в RAG задает, что retriever вообще может найти. Для юридических документов структура текста важнее произвольного окна по токенам.