Рекомендации по анализу содержимого Azure в средствах Foundry

Azure Content Understanding in Foundry Tools использует генерированный ИИ для обработки документов, изображений, видео и аудио, преобразования их в структурированные форматы выходных данных. В этой статье приведены рекомендации по максимальной точности и эффективности.

Определение эффективных схем полей

Четкие и подробные определения полей критически важны для точного извлечения. Следуйте этим принципам:

Написание подробных описаний

Укажите четкие конкретные описания, которые помогут модели получить правильные сведения. Включите подсказки по расположению, ожидания по форматированию и альтернативные метки.

Пример : поле даты выставления счетов:

The date when the invoice was issued, typically found at the top right corner. May be labeled as 'Invoice Date', 'Billing Date', or 'Issue Date'. Format is usually MM/DD/YYYY or DD-MM-YYYY.

Включить все псевдонимы

Перечислить все возможные имена для каждого поля, по возможности, особенно при работе с различными типами файлов. Это разнообразие помогает модели распознавать поле независимо от вариантов маркировки.

Пример — распределение инвестиций:

Equal to the 'Distributions' column. Also disclosed as 'Realizations' or 'Realized Proceeds'.

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

Описывайте, что представляет собой поле, а не то, что оно не представляет. Положительные описания являются более четкими и более эффективными.

Вместо: "Это поле не является датой выставления счета и не является сроком платежа".
Использование: "Дата доставки товаров или услуг, найденных в разделе сведений о доставке".

Сопоставление языка с содержимым

Определите имена полей и описания на том же языке, что и файл. Несоответствия языка могут значительно снизить точность.

Пример: Для итальянских счетов используйте Fornitore с итальянскими описаниями вместо Vendor описаний на английском языке.

Использование структурированных типов для повторяющихся данных

Определите повторяющиеся элементы, такие как элементы строки или записи, как массивы объектов, а не строковые поля, запрашивающие выходные данные JSON.

Пример: элементы строки счета:

"lineItems": {
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "description": { "type": "string" },
      "quantity": { "type": "number" },
      "unitPrice": { "type": "number" },
      "total": { "type": "number" }
    }
  }
}

Укажите методы генерации

Явно задайте метод (extractилиgenerateclassify) для каждого поля в зависимости от его назначения:

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

Оптимизация классификации и категоризации

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

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

Не создавайте отдельные категории для документов или файлов с одинаковым семантическим типом, но различными визуальными макетами. Например, используйте одну Invoice категорию для всех вариантов счета, а не Invoice_Template_A и Invoice_Template_B.

Написание определений эффективных категорий

• Используйте общие названия: "Годовой финансовый отчет", "SEC Form 10-K"
• Использование только символов ASCII в именах категорий
• Предоставление различающего контекста: семантическое значение, ключевые маркеры содержимого или отличительные компоновки
• Определите категорию "Другое", если необходимо выявить аномалии
• Избегайте различий только в флажке: не создавайте отдельные категории, которые отличаются только в значениях флажков.

Пример— категории налоговых форм:

"2024_Form_1040": "US Individual Income Tax Return for tax year 2024. Contains '2024' prominently at the top."
"2025_Form_1040": "US Individual Income Tax Return for tax year 2025. Contains '2025' prominently at the top."

Эффективное использование показателей достоверности

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

• Критические поля (TotalAmount, ContractTerminationDate): используйте более высокие пороговые значения (≥0.90)
• Важные поля (VendorName, InvoiceNumber): используйте средние пороговые значения (≥0.80)
• Некритичные поля (примечания, заметки): используйте более низкие пороговые значения (≥0.70)

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

Повышение точности с течением времени

Начните с описания, а затем добавьте примеры

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

Добавьте примеры обучения для низкой уверенности.

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

Оптимизация обработки аудио и видео

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

Узкий выбор языка

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

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

Избегайте извлечения содержимого в качестве полей без необходимости

Текстовая транскрипция речи, текст оптического распознавания символов (OCR) и ключевые кадры видео автоматически доступны в результатах анализа. Не определяйте поля для этого содержимого, если вам не требуется дополнительная обработка, например сводные данные или извлечение сущностей.

Связанный контент

• Создание пользовательского анализатора
• Предварительно созданные анализаторы
• Квоты и ограничения службы