Выбор границ и перекрытий фрагментов для RAG для сохранения контекста раздела
В этой статье объясняется, как выбирать эффективные границы и перекрытия фрагментов в системах RAG (Retrieval-Augmented Generation), сравнивая стратегии фиксированного размера и ориентированные на документы. Используя гипотетический пример служебной записки, демонстрируются риски разделения семантических единиц и показывается, как метаданные и перекрытия могут сохранить контекст. Рекомендации основаны на документации Microsoft Azure по фрагментации в векторном поиске и рабочих процессах RAG.
В этом материале
Короткий ответ
Для сохранения контекста раздела в RAG используйте фрагментацию, ориентированную на документы, которая уважает семантические границы, такие как заголовки, и включайте соответствующие метаданные, например названия разделов, в каждый фрагмент. Фрагменты фиксированного размера с перекрытием могут разделять критически важную информацию, поэтому дополняйте их структурной осведомленностью. Например, политика, гласящая «Возвраты: нераспечатанные товары могут быть возвращены в течение 14 дней», должна сохранять вместе как условие, так и срок действия. При использовании фрагментов фиксированного размера применяйте перекрытие (например, 10-25%) и повторяйте заголовки разделов в качестве метаданных. Всегда проверяйте поведение поиска вблизи известных границ и изменяйте по одному параметру за раз во время настройки.
Выберите единицу, которая сохраняет ответ
Основная цель фрагментации - гарантировать, что каждый фрагмент содержит достаточно контекста для самостоятельного ответа на потенциальные запросы. Как указано в руководстве Microsoft по RAG, фрагменты, которые слишком малы и не имеют достаточного контекста, приводят к плохим результатам. В нашей гипотетической служебной записке - «Возвраты: нераспечатанные товары могут быть возвращены в течение 14 дней. Гарантия: производственные дефекты покрываются в течение 12 месяцев» - запрос о праве на возврат зависит как от условия (нераспечатанные), так и от временного ограничения (14 дней). Если граница фрагмента разделяет «в течение» и «14 дней», поиск может упустить полное условие.
Выбирайте фрагмент, который сохраняет вместе нужное условие и срок его действия, но помещается в фактический предел входа модели эмбеддингов. Важны и структура документа, и число токенов: длинный раздел всё равно может потребовать разбиения. Короткое целостное правило является полезной отправной точкой, но не гарантирует, что поисковая система его найдёт.
Сохраняйте заголовки с их отрывками
Заголовки разделов предоставляют важный контекст для интерпретации содержания. Когда отрывок, такой как «нераспечатанные товары могут быть возвращены в течение 14 дней», появляется без заголовка «Возвраты», его смысл становится неоднозначным. Документация Microsoft по RAG подчеркивает сохранение семантически релевантного контента, что включает в себя связывание заголовков с их соответствующими текстовыми блоками.
Связывайте заголовок раздела с его текстом. Хранение заголовка только в метаданных не означает, что он попадёт в эмбеддинг или будет показан языковой модели. Если заголовок несёт необходимый контекст, включайте его в текст для эмбеддинга и в найденный контекст, передаваемый генератору ответа. Словарь ниже иллюстрирует хранение фрагмента; это не полная конфигурация индекса Azure.
chunk = {
"text": "Returns: unopened items may be returned within 14 days.",
"metadata": {"section": "Returns"}
}Сравните два иллюстративных варианта разбиения
Рассмотрим два иллюстративных сегмента служебной записки. Во-первых, предположим, что граница, основанная на количестве символов, разрезает заметку посередине слова:
Фрагмент 1: «Возвраты: нераспечатанные товары могут быть возвращены ср» Фрагмент 2: «еди 14 дней. Гарантия: производственные дефекты» Фрагмент 3: «покрываются в течение 12 месяцев.»
Здесь политика возврата разделена между фрагментами, что рискует неполным поиском. Теперь сравните подход, ориентированный на документы, который использует «Гарантия:» в качестве границы:
Фрагмент A: «Возвраты: нераспечатанные товары могут быть возвращены в течение 14 дней.» Фрагмент B: «Гарантия: производственные дефекты покрываются в течение 12 месяцев.»
Эта версия сохраняет обе политики нетронутыми. В то время как первый метод полагается исключительно на размер, второй уважает семантическую структуру - ключевое преимущество, подчеркнутое в руководстве Azure по фрагментации переменного размера и семантической фрагментации.
Выберите начальный размер и перекрытие
Azure AI Search рекомендует начинать с 512 токенов (~2000 символов) и 25% перекрытия (128 токенов) при использовании фрагментации фиксированного размера. Это обеспечивает баланс между непрерывностью контекста и избыточностью. Перекрытие позволяет фразам, разделенным между фрагментами, полностью появляться по крайней мере в одном результате.
Для нашего примера установка размера фрагмента 60 символов с перекрытием 15 символов может помочь преодолеть разрыв между «в течение» и «14 дней». Однако одно только перекрытие не может гарантировать сохранение намерения, если логическая единица охватывает более одного фрагмента. Таким образом, хотя перекрытие повышает надежность, оно не заменяет структурную осведомленность.
Учитывайте повторяющийся контекст
Перекрытие вводит дублирование текста, увеличивая затраты на хранение и индексацию. Как отмечается в статье Microsoft по RAG, некоторые подходы влекут за собой более высокие финансовые и временные затраты. Повторение заголовков разделов в нескольких фрагментах также добавляет избыточность, но улучшает интерпретируемость.
В нашем случае повторение «Возвраты:» в начале каждого фрагмента в этом разделе обеспечивает ясность, даже если это увеличивает использование токенов. Компромисс отдает предпочтение точности перед эффективностью, когда правильный ответ на вопросы пользователя зависит от контекста.
Проверяйте ответы вблизи границ
После фрагментации протестируйте запросы, нацеленные на информацию вблизи вероятных точек разделения. Например, спросите «Как долго я могу возвращать нераспечатанные товары?» и проверьте, включает ли извлеченный фрагмент как тему, так и временные рамки.
Поскольку это гипотетический пример, фактическая система поиска не тестируется. Но в реальных реализациях проверка результатов вокруг структурных переходов - таких как после заголовков или разделений в середине предложения - имеет решающее значение для проверки качества фрагментов, как указано в документации по этапу фрагментации RAG.
Изменяйте один параметр за раз
При оптимизации фрагментации изменяйте только одну переменную за итерацию - размер, перекрытие или метод разбора - чтобы изолировать ее эффект. Например, сначала протестируйте фрагменты фиксированного размера при 500 против 1000 символов, затем настройте перекрытие с 10% до 25%, сохраняя другие настройки постоянными.
Этот систематический подход поддерживает надежную оценку, в соответствии с рекомендацией Microsoft экспериментировать с различными перестановками фрагментации и наблюдать компромиссы перед окончательным утверждением стратегии.
Знайте, что проверка фрагментации не может доказать
Визуализация фрагментов или проверка перекрытия не гарантирует эффективность поиска. Семантические границы не подразумевают автоматически релевантность, и никакой статический анализ не доказывает, что фрагмент будет найден для данного запроса. Как отмечает руководство Microsoft, ваш подход к фрагментации является полупостоянным и влияет на последующие процессы, поэтому предположения должны быть эмпирически проверены.
Сохранение «Возвратов» с их политикой облегчает интерпретацию отрывка, но фактический поисковый механизм все равно должен выбрать его, а ответ должен правильно его использовать. Проверяйте извлеченные доказательства и просматривайте сгенерированные ответы по репрезентативным запросам. Хороший результат по одному запросу не устанавливает надежность; сравните несколько граничных случаев, включая вопросы, ответы на которые отсутствуют в документе.
Что проверить
- Содержит ли каждый фрагмент полную семантическую единицу?
- Сохраняется ли контекст заголовка раздела в каждом соответствующем фрагменте?
- Будет ли запрос об окне возврата извлекать полное условие?
- Достаточно ли перекрытия для охвата разделений в середине фразы?
- Был ли изменен только один параметр фрагментации во время тестирования?
Границы применения
Этот анализ использует гипотетический пример и не отражает фактическую производительность поиска. Эффекты токенизации, ограничения, специфичные для модели, и качество встраивания не оцениваются. Рекомендации предполагают доступ к структуре документа и зависят от правильной реализации прикрепления метаданных и логики перекрытия.