Качество схемы обеспечивают восемь правил валидации. Они выполняются в коде после того, как ИИ-генерация схемы собрала свой ответ, — последняя страховка поверх конвейера, который и так исправляет себя шаг за шагом.
Исправление происходит там, где допущена ошибка, а не в конце. Генерация — это последовательность небольших вызовов, каждый из которых решает одну задачу и несёт собственный валидатор: он проверяет ответ этого вызова, сохраняет всё корректное и повторно запрашивает только то, чего ещё не хватает. Поэтому модель, отвечающая фрагментами, сходится к результату, а не начинает всё заново.
Полностью прервать генерацию могут только два шага: присвоение имени сущности и распределение свойств по доменам экспертизы. Для всего остального есть детерминированный запасной вариант — именно поэтому здесь применимы небольшие модели.
Не все правила применяются как к генерации схемы, так и к редактированию с помощью ИИ. Правила, сравнивающие с входными данными, пропускаются при редактировании, так как вы можете намеренно добавлять или удалять поля:
| Область действия | Применённые правила | Почему |
|---|---|---|
| Генерация | Все 8 правил | Входные данные доступны для сравнения |
| Редактирование с помощью ИИ | Только правила 2, 3, 4, 5 | Нет входных данных; пользователь может намеренно изменить структуру |
Количество областей экспертизы не должно превышать рассчитанный максимум, основанный на числе ваших свойств. Это не даёт ИИ создавать слишком много узкоспециализированных областей для небольших схем.
Too many expertise domains: 6 defined, maximum is 3Максимум вычисляется как floor(property_count / 6), но не менее 1. Схема с 12 свойствами допускает до 2 областей.
Каждая схема должна определять хотя бы одно свойство. Пустую схему нельзя использовать для обогащения.
Schema must have at least one propertyЭто выявляет случаи, когда ИИ создаёт корректную структуру JSON, но забывает включить в неё какие-либо реальные поля.
Тип каждого свойства должен быть одним из стандартных типов JSON Schema: string, number, integer, boolean, array, object или null.
revenue: invalid type 'float'ИИ иногда придумывает типы вроде «float», «decimal» или «date». Это правило выявляет их и запрашивает исправление на допустимый тип.
Каждый $ref должен указывать на существующий объект: #/$defs/... — на определение сущности, #/$enums/... — на набор значений. Висячие ссылки нарушают конвейер обогащения.
manufacturer: $ref '#/$defs/Company' references undefined definitionЭти два пространства имён разделены: ссылка #/$defs/ — это связь с вложенной сущностью, а ссылка #/$enums/ ограничивает текстовое свойство закрытым списком допустимых значений. У каждой должна быть соответствующая запись в своём блоке.
Значение экспертизы каждого свойства должно соответствовать одной из определённых областей экспертизы. Это предотвращает опечатки и несогласованность.
revenue: expertise 'finance' not in defined domains: ['financial_analyst']ИИ может использовать «finance» вместо определённого ключа «financial_analyst». Это правило выявляет несоответствие, чтобы ИИ мог его исправить.
Свойства, не являющиеся объектами и не сохраняемые, должны иметь назначенную область экспертизы. Это гарантирует, что каждое обогащаемое поле обрабатывается специализированной областью.
revenue: expertise is required for non-object typesТипы-объекты исключены, поскольку их дочерние свойства несут собственную экспертную область. Сохраняемые поля исключены, поскольку они проходят без изменений.
Тип схемы для каждого свойства должен соответствовать фактическому типу Python соответствующего значения в ваших входных данных.
revenue: type mismatch - input is number but schema says 'string'Если во входных данных есть "revenue": 42.5, схема должна использовать тип "number" или "integer", а не "string". Валидатор гибок: он принимает "number" для целых чисел и наоборот.
Каждый ключ в ваших входных данных должен присутствовать как свойство в сгенерированной схеме. Это не даёт ИИ незаметно отбрасывать поля.
Missing property from input: 'headquarters'Если во входном JSON есть ключ "headquarters", сгенерированная схема должна его включать. Это обеспечивает полное покрытие ваших данных.
Правило 7 (сопоставление типов) использует автоматический вывод типов для сравнения ваших входных значений с типами, объявленными в схеме. Вывод типов гибкий, чтобы избежать ложных срабатываний:
| Входное значение | Выведенный тип | Также принимает |
|---|---|---|
| true / false | boolean | (только логическое значение) |
| 42 | integer | number |
| 3.14 | number | integer |
| "hello" | string | (только строка) |
| [1, 2, 3] | array | (только массив) |
| {"key": "val"} | object | (только объект) |
Примечание: логические значения проверяются перед целыми числами, поскольку в некоторых языках логический тип является подтипом целого. Такой порядок предотвращает интерпретацию true как целого числа.
Эта таблица описывает, что принимает валидатор, а не что производит генерация. Значение 3 в образце не делает свойство целочисленным: числовые поля выпускаются как number, если только отдельный шаг не подтвердит, что величина действительно дискретна и ни одно наблюдаемое значение этому не противоречит. Одно целое число в образце — не доказательство того, что половинные значения невозможны, а ошибочное объявление integer усечёт 6.2 до 6 в базе данных потребителя.