Правила проверки — Документация Entity Enricher

Правила проверки

Восемь правил валидации обеспечивают качество схемы. Когда любое правило не выполняется во время генерации схемы с помощью AI, ошибка отправляется обратно AI для автоматического самоисправления.

Как работает самокоррекция

После того как ИИ генерирует схему, она проходит через все 8 правил валидации. Если какое-либо правило не выполняется, конкретные сообщения об ошибках собираются и отправляются обратно ИИ в качестве обратной связи. Затем ИИ создаёт исправленную схему, которая проверяется снова. Этот цикл продолжается до 6 попыток в общей сложности (1 начальная + 5 повторных).

Процесс исправления

ИИ генерируетСхема со свойствами, типами, экспертизой и описаниями
Проверки валидатора8 правил применяются последовательно, все ошибки собираются
При ошибкахОтправленные сообщения об ошибках: «Исправьте эти проблемы: [revenue: несоответствие типа...]»
ИИ исправляетСоздаёт обновлённую схему, устраняющую обнаруженные ошибки
ПовторитьПока все правила не будут пройдены или не будет достигнуто максимальное число попыток

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

Правила генерации и редактирования

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

Область действияПрименённые правилаПочему
ГенерацияВсе 8 правилВходные данные доступны для сравнения
Редактирование с помощью ИИТолько правила 2, 3, 4, 5Нет входных данных; пользователь может намеренно изменить структуру

8 правил

Правило 1

Количество областей экспертизы

Область действия: Только генерация

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

Пример ошибки: Too many expertise domains: 6 defined, maximum is 3

Максимум вычисляется как floor(property_count / 6), но не менее 1. Схема с 12 свойствами допускает до 2 областей.

Правило 2

Хотя бы одно свойство

Область действия: Оба

Каждая схема должна определять хотя бы одно свойство. Пустую схему нельзя использовать для обогащения.

Пример ошибки: Schema must have at least one property

Это выявляет случаи, когда ИИ создаёт корректную структуру JSON, но забывает включить в неё какие-либо реальные поля.

Правило 3

Допустимые типы JSON Schema

Область действия: Оба

Тип каждого свойства должен быть одним из стандартных типов JSON Schema: string, number, integer, boolean, array, object или null.

Пример ошибки: revenue: invalid type 'float'

ИИ иногда придумывает типы вроде «float», «decimal» или «date». Это правило выявляет их и запрашивает исправление на допустимый тип.

Правило 4

Цели $ref существуют

Область действия: Оба

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

Пример ошибки: manufacturer: $ref '#/$defs/Company' references undefined definition

Когда ИИ создаёт ссылку вроде #/$defs/Company, в блоке $defs должно быть соответствующее определение Company.

Правило 5

Ключ экспертизы существует

Область действия: Оба

Значение экспертизы каждого свойства должно соответствовать одной из определённых областей экспертизы. Это предотвращает опечатки и несогласованность.

Пример ошибки: revenue: expertise 'finance' not in defined domains: ['financial_analyst']

ИИ может использовать «finance» вместо определённого ключа «financial_analyst». Это правило выявляет несоответствие, чтобы ИИ мог его исправить.

Правило 6

Требуется экспертиза

Область действия: Только генерация

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

Пример ошибки: revenue: expertise is required for non-object types

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

Правило 7

Тип соответствует входным данным

Область действия: Только генерация

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

Пример ошибки: revenue: type mismatch - input is number but schema says 'string'

Если во входных данных есть "revenue": 42.5, схема должна использовать тип "number" или "integer", а не "string". Валидатор гибок: он принимает "number" для целых чисел и наоборот.

Правило 8

Все входные свойства присутствуют

Область действия: Только генерация

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

Пример ошибки: Missing property from input: 'headquarters'

Если во входном JSON есть ключ "headquarters", сгенерированная схема должна его включать. Это обеспечивает полное покрытие ваших данных.

Вывод типов

Правило 7 (сопоставление типов) использует автоматический вывод типов для сравнения ваших входных значений с типами, объявленными в схеме. Вывод типов гибкий, чтобы избежать ложных срабатываний:

Входное значениеВыведенный типТакже принимает
true / falseboolean(только логическое значение)
42integernumber
3.14numberinteger
"hello"string(только строка)
[1, 2, 3]array(только массив)
{"key": "val"}object(только объект)

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

Дальнейшие шаги