Этап сегментации RAG

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

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

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

Эта статья является частью серии. Ознакомьтесь с введением , прежде чем продолжить.

Дробление экономики

При определении общей стратегии разбиения на фрагменты необходимо учитывать бюджет и требования к качеству и производительности для коллекции документов. Существуют инженерные затраты на проектирование и реализацию каждой уникальной реализации блоков и затраты на обработку документов, которые отличаются в зависимости от подхода. Если документы имеют внедренные или связанные носители, необходимо учитывать экономику обработки этих элементов. Для фрагментирования эта обработка обычно использует языковые модели для создания описания носителя. Затем эти описания разбиваются на блоки. Альтернативный подход для некоторых видов данных заключается в том, чтобы передавать их as-is в мультимодальную модель во время выполнения вывода. Однако этот подход не влияет на экономику сегментирования.

В следующих разделах рассматривается экономика фрагментирования изображений и общее решение.

Экономика фрагментирования изображений

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

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

Другая стратегия оптимизации затрат — кэшировать с помощью шаблонаCache-Aside. Вы можете создать ключ, основанный на хэше изображения. Сначала проверьте наличие кэшированного результата из предыдущего или ранее обработанного документа. Если так, вы можете использовать этот результат. Такой подход устраняет затраты на вызов классификатора или языковой модели. Если кэш отсутствует, при вызове классификатора или языковой модели вы кэшируете результат. Будущие вызовы этого образа используют кэш.

Следующий простой рабочий процесс интегрирует все эти процессы оптимизации затрат:

1. Проверьте, кэшируется ли обработка изображений. В этом случае используйте кэшированные результаты.

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

3. Создайте описание изображения. Кэшируйте результат.

Экономика общего решения

При оценке стоимости общего решения следует учитывать следующие факторы:

• Число уникальных реализаций разбиения на части: Каждая уникальная реализация имеет затраты на инжиниринг и обслуживание. Обязательно учитывайте количество уникальных типов документов в коллекции и затраты и компромиссы по качеству уникальных реализаций для каждого из них.

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

• Количество исходных документов: Количество исходных документов, которые необходимо обработать для запуска решения.

• Количество добавочных документов: Количество и скорость новых документов, которые необходимо обрабатывать для постоянного обслуживания системы.

Загрузка и разбиение

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

Разделение загрузки и разбиение на части

Существует несколько причин, по которым можно разделить этапы загрузки и дробления. Может потребоваться инкапсулировать логику в коде загрузки. Вы можете сохранить результат выполнения кода загрузки перед разбиением на части, особенно когда вы экспериментируете, попробуя разные варианты разбиения, чтобы сэкономить время обработки или затраты. Наконец, может потребоваться запустить код загрузки и разбиения на части в отдельных процессах по архитектурным причинам, таким как процессное ограждение или сегментация безопасности, которая включает удаление персональных данных.

Инкапсулировать логику в коде загрузки

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

• Удалите или заметите элементы, которые вы хотите игнорировать.

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

• Скачайте или скопируйте изображения в хранилище файлов, например Azure Data Lake Storage, которые будут обрабатываться отдельно от текста документа. Если вы определите, что в анализе документа есть окружающий текст, который предоставляет ценный контекст для изображения, сохраните этот текст вместе с изображением в хранилище файлов.

• Переформатируйте таблицы, чтобы их было проще обработать.

Сохранение результата загрузки кода

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

Запуск загрузки и разбиения кода в отдельных процессах

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

Объединение загрузки и блокирования

Объединение кода загрузки и блока является более простой реализацией в большинстве случаев. Многие операции, которые вы могли бы рассмотреть для выполнения на этапе предварительной обработки в отдельной фазе загрузки, можно выполнить на этапе разбиения на части. Например, вместо замены URL-адресов изображений описанием на этапе загрузки, логика разбиения может обращаться к большой языковой модели, чтобы получить текстовое описание и разбивать это описание на части.

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

Рекомендации

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

• Начните с объединения логики загрузки и фрагментирования. Разделите их, если этого требует решение.

• Не следует преобразовывать документы в промежуточный формат, если вы решили разделить процессы. Этот тип операции может привести к потере данных.

Подходы к фрагментации

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

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

Синтаксический анализ на основе предложений

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

Инструменты:токенизатор предложений spaCy, LangChain рекурсивный разделитель текста, токенизатор предложений NLTK
Инженерные усилия: Минимальные
Затраты на обработку: Низкий
Варианты использования: Неструктурированные документы, написанные в прозе или полными предложениями, когда ваша коллекция документов содержит избыточное количество различных типов документов, требующих индивидуальных стратегий разбиения на части.
Примеры: Созданное пользователем содержимое, например открытые отзывы от опросов, публикации форума, отзывы, сообщения электронной почты, роман или эссе

Синтаксический анализ фиксированного размера с перекрытием

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

Необходимо выбрать фиксированный размер блоков и количество перекрытий. Так как результаты зависят от разных типов документов, лучше всего использовать инструмент, такой как визуализатор фрагментов Hugging Face, для проведения исследовательского анализа. Вы можете использовать такие средства, чтобы визуализировать фрагменты документов на основе ваших решений. При использовании синтаксического анализа фиксированного размера следует использовать маркеры BERT вместо счетчиков символов. Маркеры BERT основаны на значимых единицах языка, поэтому они сохраняют больше семантической информации, чем число символов.

Инструменты:Рекурсивный разбиватель текста LangChain, визуализатор фрагментов Hugging Face
Инженерные усилия: Низкий
Затраты на обработку: Низкий
Варианты использования: Неструктурированные документы, написанные в прозе или непрозе с полными или неполными предложениями. Коллекция ваших документов содержит чрезмерное количество различных типов, требующих индивидуальных стратегий разделения на части.
Примеры: Созданное пользователем содержимое, например открытые отзывы от опросов, публикации форума, отзывы, сообщения электронной почты, личные заметки, заметки о исследованиях, списки

Пользовательский код

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

Сервис:Python (re, regex, BeautifulSoup, lxml, html5lib, marko), R (stringr, xml2), Джулия (Gumbo.jl)
Инженерные усилия: Средняя
Затраты на обработку: низкая
Варианты использования: Полуструктурированные документы, в которых можно вывести структуру
Примеры: Заявки на патенты, исследовательские документы, страховые политики, сценарии и сцены

Расширение языковой модели

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

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

Если логика фрагментирования разбивает описание изображения на несколько блоков, убедитесь, что url-адрес изображения включен в каждый блок. Добавьте URL-адрес изображения в каждый блок, чтобы гарантировать, что метаданные возвращаются для всех запросов, обслуживаемых изображением. Этот шаг важен для сценариев, когда конечный пользователь должен получить доступ к исходному образу через этот URL-адрес или использовать необработанные образы во время вывода.

Сервис:Azure OpenAI, OpenAI
Инженерные усилия: Среднее
Затраты на обработку: Высокий
Варианты использования: Изображения, таблицы
Примеры: Создание текстовых представлений таблиц и изображений, обобщение расшифровок из собраний, речевых выступлений, интервью или подкастов

Анализ макета документа

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

Библиотеки и службы анализа макета документов предоставляют модель, представляющую структурное и текстовое содержимое документа. Вам по-прежнему нужно написать код, взаимодействующий с моделью.

Модели анализа документовTools:Document Intelligence, Donut, Layout Parser
Инженерные усилия: Средний
Затраты на обработку: Средние
Варианты использования: Полуструктурированные документы
Примеры: Новости, веб-страницы, резюме

Предварительно созданная модель

Такие службы, как Аналитика документов, предоставляют предварительно созданные модели, которые можно использовать для различных типов документов. Некоторые модели обучены для определенных типов документов, таких как налоговая форма США W-2, а другие предназначены для более широкого жанра типов документов, таких как счета.

Средства:предварительно созданные модели Аналитики документов, интеллектуальная обработка документов Power Automate, LayoutLMv3
Инженерные усилия: Низкие
Затраты на обработку: Средний или высокий
Варианты использования: Структурированные документы, в которых существует предварительно созданная модель
Конкретные примеры: Счета, квитанции, карты медицинского страхования, формы W-2

Настраиваемая модель

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

Tools:Document Intelligence custom models, Tesseract
Инженерные усилия: Высокие
Затраты на обработку: Средний или высокий
Варианты использования: Структурированные документы, в которых предварительно созданная модель не существует
Примеры: Расписания ремонта и обслуживания автомобилей, академические расшифровки, записи, технические руководства, операционные процедуры, рекомендации по обслуживанию

Структура документа

Степень структурированности документов может быть различной. Некоторые документы, такие как формы правительства, имеют сложную и хорошо известную структуру, например налоговую форму США W-2. На противоположном конце спектра находятся неструктурированные документы, например заметки в свободной форме. Степень структуры типа документа является хорошей отправной точкой для определения эффективного подхода к фрагментации. Несмотря на отсутствие конкретных правил, в этом разделе приведены некоторые рекомендации.

структурированные документы.

Структурированные документы, иногда называемые документами фиксированного формата, имеют определенные макеты. Данные в этих документах находятся в фиксированных расположениях. Например, дата или имя семьи клиента находится в одном расположении в каждом документе одного и того же фиксированного формата. Примером документа фиксированного формата является налоговый документ США W-2.

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

Примеры: Форма W-2, страховая карта
Типичные подходы: Предварительно созданные модели, пользовательские модели

Полуструктурированные документы

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

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

Примеры: Счета, квитанции, веб-страницы, файлы markdown
Типичные подходы: Модели анализа документов

Структура на основе предположений

Некоторые документы имеют структуру, но не написаны в разметке. Для этих документов структура должна быть определена. Хорошим примером является следующий документ о регулировании ЕС.

Так как вы можете четко понять структуру документа и нет известных моделей, вы можете определить, что можно написать пользовательский код. Формат документа, как этот, может не оправдать усилий по созданию пользовательской модели, это зависит от количества различных документов подобного типа, с которыми вы работаете. Например, если ваша коллекция содержит все нормативные акты ЕС или законы штата США, пользовательская модель может быть хорошим подходом. Если вы работаете с одним документом, например с регламентом ЕС, пользовательский код может оказаться более экономичным.

Примеры: Юридические документы, скрипты, производственные спецификации
Типичные подходы: Пользовательский код, пользовательские модели

Неструктурированные документы

Хороший подход к документам, которые не имеют структуры, основаны на предложениях или фиксированных размерах с перекрывающимися подходами.

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

Экспериментирование

В этой статье описываются наиболее подходящие подходы к разбиению на части для каждого типа документа, но на практике любой из подходов может быть уместным для всех типов документов. Например, синтаксический анализ на основе предложений может быть подходящим для высокоструктурированных документов, или пользовательская модель может быть подходящей для неструктурированных документов. Часть оптимизации вашего решения RAG заключается в экспериментировании с различными подходами к сегментированию. Рассмотрим количество ресурсов, технических навыков ресурсов и объем документов, которые необходимо обработать. Чтобы достичь оптимальной стратегии обработки данных, обратите внимание на преимущества и компромиссы каждого подхода, который вы тестируете, чтобы убедиться, что вы выбрали правильный подход для вашего варианта использования.

Следующий шаг

Связанные ресурсы

• Блокирование больших документов для решений поиска векторов в службе "Поиск ИИ Azure"
• Интегрированное разделение и встраивание данных в Поиск с использованием ИИ Azure