Устранение ошибки No Global Metrics в Custom Extractor

The “no global metrics” error (Error 13) in Google Document AI Custom Extractor training typically occurs when the evaluation pipeline cannot compute meaningful performance metrics due to issues with your nested FormField schema, validation problems, or dataset configuration. This error indicates that the training process succeeded but evaluation failed because no valid ground‑truth comparisons could be made between predictions and labeled data.

Contents

• Понимание ошибки
• Анализ дизайна схемы
• Проблемы валидации набора данных
• Шаги устранения неполадок
• Альтернативные подходы к схеме
• Получение подробных логов
• Вывод

Понимание ошибки

Код ошибки 13 с сообщением «Internal error encountered» и конкретным сообщением о «no global metrics» означает, что обучение завершилось, но этап оценки не смог вычислить стандартные метрики (точность, полнота, F1‑score), потому что не удалось найти валидные данные для сравнения.

«No global metrics» указывает на то, что для вашего тестового набора Document AI не смог обнаружить ни одной пригодной метки, чтобы посчитать статистику оценки. Это может произойти, если:

• В тестовых документах нет помеченных сущностей
• Пайплайн оценки не может сопоставить предсказания с реальными метками из‑за проблем со схемой
• Возникают проблемы с нормализацией или структурой полигонов ограничений
• Вложенная структура сущностей затрудняет вычисление метрик

Как отмечено в обсуждениях на Stack Overflow, эта ошибка особенно распространена при использовании схем родитель/дочерний, как в вашем случае с FormField.

Анализ дизайна схемы

Ваша вложенная схема FormField с дочерними свойствами label и fieldType создаёт несколько проблем, которые могут вызывать ошибки оценки:

Ограничения схемы родитель/дочерний

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

Это приводит к фундаментальному несоответствию: обучение создаёт сущности FormField, но система оценки ожидает вычислять метрики по фактическим текстовым полям (значениям label и fieldType). Поскольку эти значения являются производными, а не извлекаемыми, пайплайн оценки может не распознать их как валидные цели для метрик.

fieldType как производное свойство

Использование fieldType с методом «Derive» вместо «Extract» особенно проблематично для обучения. Документация по механизмам Document AI объясняет, что производные свойства работают иначе и могут не участвовать в том же пайплайне оценки.

Если fieldType установлен как derive, система может не суметь вычислить сравнения между предсказанным и фактическим типом поля во время оценки, что приводит к ошибке «no global metrics».

Требования к полигону ограничений

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

Проблемы валидации набора данных

Несмотря на то, что вы устранили начальные ошибки валидации, несколько вопросов, связанных с набором данных, могут всё ещё вызывать проблемы оценки:

Распределение типов сущностей

В вашем наборе данных одинаковое количество сущностей FormField, label и fieldType (1140 каждой), что выглядит сбалансированным. Однако система оценки может искать другие паттерны. Документация по Custom Extractor ожидает, что будут найдены реальные текстовые данные для сравнения с предсказаниями.

Если сущности fieldType содержат только тип информации (например, «text», «checkbox», «date») без извлекаемого текста, система оценки может не распознать их как валидные сущности для метрик.

Содержимое тестовых документов

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

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

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

Шаги устранения неполадок

На основе исследований приведены конкретные шаги для устранения ошибки «no global metrics»:

1. Сгладьте структуру схемы

Вместо вложенных родитель/дочерних отношений рассмотрите возможность «плоской» схемы:

{
  "name": "FormField",
  "type": "FORM_FIELD",
  "properties": {
    "fieldType": {"type": "TEXT", "extractMethod": "EXTRACT"},
    "label": {"type": "TEXT", "extractMethod": "EXTRACT"},
    "boundingBox": {"type": "GEOMETRY"}
  }
}

Такой подход рассматривает все компоненты как отдельные сущности, которые могут корректно оцениваться.

2. Измените метод fieldType на EXTRACT

Переключите свойство fieldType на «EXTRACT» вместо «DERIVE». Это гарантирует, что информация о типе поля будет рассматриваться как извлекаемая сущность, участвующая в метриках оценки.

3. Улучшите валидацию набора данных

Убедитесь, что:

• Для каждого типа сущности есть достаточное количество примеров (минимум 5‑10)
• Тестовые документы содержат те же типы сущностей, что и обучающие
• Полигон ограничений правильно нормализован и согласован

4. Используйте шаблоны фундаментальных моделей

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

Альтернативные подходы к схеме

Одна сущность с несколькими свойствами

Создайте одну сущность FormField с несколькими свойствами:

FormField (EXTRACT, optional multiple)
├── fieldType (TEXT, EXTRACT, required once)
├── label (TEXT, EXTRACT, required once)  
├── valueBoundingBox (GEOMETRY, required once)
└── labelBoundingBox (GEOMETRY, optional)

Такой подход сохраняет всю связанную информацию в одной сущности, при этом каждый компонент может корректно оцениваться.

Отдельные сущности для каждого компонента

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

FormField (GEOMETRY, EXTRACT, optional multiple)
FormFieldLabel (TEXT, EXTRACT, optional multiple)
FormFieldType (TEXT, EXTRACT, optional multiple)

Это даёт системе оценки чёткие цели для вычисления метрик по каждому типу сущности.

Получение подробных логов

К сожалению, отчётность Document AI о сбоях обучения часто ограничена. Однако вы можете попробовать следующие подходы для получения более подробной информации:

Cloud Logging

Проверьте Cloud Logging вашего проекта и отфильтруйте операции Document AI. Ищите подробные сообщения об ошибках, которые могут дать больше информации о том, что происходит во время оценки.

Метаданные операции

Метаданные операции, показывающие состояние «FAILED», могут содержать дополнительные детали. Как показано в примерах Stack Overflow, структура метаданных включает информацию о валидации, которая может помочь диагностировать проблемы.

Ручная оценка

После обучения более простого модели используйте функцию «Evaluate & test» в консоли Document AI, чтобы увидеть, как модель работает на отдельных документах. Это поможет выявить конкретные паттерны, вызывающие проблемы.

Вывод

Ошибка «no global metrics» в обучении Custom Extractor Google Document AI в основном вызвана ограничениями вложенных схем родитель/дочерний в пайплайне оценки. Чтобы решить эту проблему:

1. Сгладьте структуру схемы – избегайте вложенных отношений, которые система оценки не может корректно обработать.
2. Смените fieldType с DERIVE на EXTRACT – чтобы он участвовал в вычислении метрик.
3. Убедитесь, что все сущности имеют достаточное количество примеров как в обучающем, так и в тестовом наборе.
4. Рассмотрите использование фундаментальных моделей, которые справляются с сложными макетами при меньших объёмах данных.

Ключевой вывод: система оценки Document AI работает лучше всего с простыми, «плоскими» структурами сущностей, где каждый компонент может быть независимо оценён. Ваша вложенная схема FormField, хотя логически корректна для представления отношений полей формы, создаёт сложности для внутреннего пайплайна вычисления метрик. Перестройка схемы в одну сущность с несколькими свойствами или в полностью отдельные сущности должна позволить успешно обучить модель, способную извлекать тип поля, метку и информацию о ограничениях, необходимые для вашего iOS‑клиента.