Чанки документов разрезают важный контекст RAG: как настроить разбиение

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

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

Что проверить в первую очередь

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

• Проверьте, сохраняются ли заголовки разделов и путь документа в metadata.
• Посмотрите средний и максимальный размер chunk в tokens, а не символах.
• Найдите, где определение, отрицание или исключение оказалось в соседнем chunk.
• Сравните retrieved chunks до reranker и фактический context модели.

Почему возникает проблема

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

• Splitter режет только по длине и игнорирует headings, paragraphs and lists.
• Overlap слишком мал для длинного логического перехода или слишком велик и создает дубли.
• Таблицы и код преобразуются в плоский текст с потерей структуры.
• Embedding строится для маленькой части без parent summary or title.
• Top-k заполнен почти одинаковыми соседними chunk одного раздела.

Пошаговая диагностика

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

• Создайте набор вопросов с известными документами и точными supporting spans.
• Измерьте retrieval recall before generation.
• Визуализируйте границы chunk на исходном Markdown, HTML or PDF structure.
• Сравните fixed, recursive, heading-aware and semantic splitting.
• Проверьте влияние top-k, MMR, metadata filters and reranker отдельно.

Как сочетать маленький поиск и большой контекст

Маленькие chunks точнее индексируются, но часто недостаточны для ответа. Parent-child retrieval позволяет искать по компактному фрагменту, а модели возвращать целый логический раздел с заголовком и соседними условиями.

• Документ разбирается на структурные blocks с устойчивыми IDs.
• Child chunks индексируются вместе с title, path and key metadata.
• После поиска система расширяет результат до parent section или соседнего окна.
• Reranker and diversity не позволяют одному разделу занять весь context дублями.

Как исправить проблему

Исправление делите на небольшие обратимые изменения. Сначала устраните подтвержденную причину, затем повторите исходный сценарий и проверьте соседние функции. Массовое обновление данных запускайте на ограниченной выборке с отчетом и только после сверки расширяйте на весь объем. Не отключайте авторизацию, проверку сертификатов, валидацию или аудит ради быстрого исчезновения симптома.

• Разбивайте по заголовкам, абзацам и спискам с token-aware лимитом.
• Добавляйте небольшой overlap на естественных границах, а не посреди слова or sentence.
• Храните parent ID и возвращайте расширенный логический раздел после retrieval.
• Обрабатывайте таблицы, код and FAQ специализированными правилами.
• Настройте reranking, diversity and context budget на оценочном наборе.

Безопасный порядок внедрения

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

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

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

• Supporting span попадает в retrieved context для контрольных вопросов.
• Условие и исключение находятся вместе и не противоречат ответу.
• Контекст не заполнен многочисленными дублями соседних chunks.
• Изменение стратегии улучшает retrieval metrics и ручную точность, а не только субъективную плавность текста.

Типичные ошибки при исправлении

• Выбирать chunk size только по популярному примеру без своих документов.
• Оценивать только финальный ответ и не смотреть retrieval.
• Добавлять огромный overlap, раздувая индекс и повторяя контент.
• Смешивать разные версии документа без metadata filters.

Как предотвратить повторение

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

• Храните version, source, heading path and parent ID у каждого chunk.
• Запускайте retrieval evaluation после изменения parser or embeddings.
• Добавляйте реальные неудачные вопросы в постоянный тестовый набор.
• Переиндексируйте документы контролируемо и не смешивайте несовместимые embeddings.

Что контролировать после выпуска

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

Что подготовить для технического разбора

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

Частые вопросы

Какой размер чанка считается правильным?

Универсального числа нет. Он зависит от структуры, embedding model и типа вопросов. Начните со смысловых блоков и измеряйте retrieval recall.

Нужен ли semantic chunking?

Иногда полезен, но сложнее и дороже. Часто heading-aware recursive splitting plus parent retrieval дает предсказуемый результат.

Когда нужна помощь специалиста

Если RAG находит похожие фразы, но теряет важные условия, я могу проанализировать документы и retrieval, настроить структурный chunking, parent context и оценку качества.