Huit règles de validation garantissent la qualité du schéma. Elles s'exécutent dans le code une fois que la génération de schéma par IA a assemblé sa réponse — un dernier filet de sécurité au-dessus d'un pipeline qui se corrige déjà étape par étape.
La correction a lieu là où l'erreur se produit, pas à la fin. La génération est une séquence de petits appels à préoccupation unique, dotés chacun de leur propre validateur : il vérifie la réponse de cet appel, conserve ce qui est valide et ne redemande que ce qui manque encore. Un modèle qui répond par fragments converge donc au lieu de tout recommencer.
Seules deux étapes peuvent faire échouer une génération d'emblée : nommer l'entité et router les propriétés vers les domaines d'expertise. Tout le reste dispose d'un repli déterministe, ce qui rend les petits modèles utilisables ici.
Toutes les règles ne s'appliquent pas à la fois à la génération de schéma et à l'édition par IA. Les règles qui comparent aux données d'entrée sont ignorées lors de l'édition, car vous pouvez volontairement ajouter ou supprimer des champs :
| Portée | Règles appliquées | Pourquoi |
|---|---|---|
| Génération | Les 8 règles | Les données d'entrée sont disponibles pour comparaison |
| Édition par IA | Règles 2, 3, 4, 5 uniquement | Aucune donnée d'entrée ; l'utilisateur peut modifier la structure intentionnellement |
Le nombre de domaines d'expertise ne doit pas dépasser le maximum calculé en fonction de votre nombre de propriétés. Cela empêche l'IA de créer trop de domaines trop fins pour de petits schémas.
Too many expertise domains: 6 defined, maximum is 3Le maximum est calculé comme floor(property_count / 6), avec un minimum de 1. Un schéma de 12 propriétés autorise jusqu'à 2 domaines.
Chaque schéma doit définir au moins une propriété. Un schéma vide ne peut pas être utilisé pour l'enrichissement.
Schema must have at least one propertyCela couvre les cas où l'IA produit une structure JSON valide mais oublie d'y inclure le moindre champ réel.
Chaque type de propriété doit être l'un des types JSON Schema standard : string, number, integer, boolean, array, object ou null.
revenue: invalid type 'float'L'IA invente parfois des types comme "float", "decimal" ou "date". Cette règle les détecte et demande une correction vers un type valide.
Chaque $ref doit pointer vers un élément existant : #/$defs/... vers une définition d'entité, #/$enums/... vers un ensemble de valeurs. Les références orphelines cassent le pipeline d'enrichissement.
manufacturer: $ref '#/$defs/Company' references undefined definitionLes deux espaces de noms sont distincts : une référence #/$defs/ est une relation vers une entité imbriquée, tandis qu'une référence #/$enums/ restreint une propriété textuelle à une liste fermée de valeurs autorisées. Chacune doit avoir une entrée correspondante dans son propre bloc.
La valeur d'expertise de chaque propriété doit correspondre à l'un des domaines d'expertise définis. Cela évite les fautes de frappe et les incohérences.
revenue: expertise 'finance' not in defined domains: ['financial_analyst']L'IA peut utiliser "finance" au lieu de la clé définie "financial_analyst". Cette règle détecte l'incohérence afin que l'IA puisse la corriger.
Les propriétés qui ne sont ni des objets ni préservées doivent être affectées à un domaine d'expertise. Cela garantit que chaque champ enrichissable est pris en charge par un domaine spécialisé.
revenue: expertise is required for non-object typesLes types objet sont exemptés, car leurs propriétés enfants portent leur propre expertise. Les champs préservés sont exemptés, car ils sont transmis tels quels.
Le type de schéma de chaque propriété doit correspondre au type Python réel de la valeur correspondante dans vos données d'entrée.
revenue: type mismatch - input is number but schema says 'string'Si votre entrée contient "revenue": 42.5, le schéma doit utiliser le type "number" ou "integer", pas "string". Le validateur est flexible : il accepte "number" pour les entiers et inversement.
Chaque clé de vos données d'entrée doit apparaître comme propriété dans le schéma généré. Cela empêche l'IA d'abandonner silencieusement des champs.
Missing property from input: 'headquarters'Si votre JSON d'entrée contient une clé "headquarters", le schéma généré doit l'inclure. Cela garantit une couverture complète de vos données.
La règle 7 (correspondance de types) utilise une inférence de type automatique pour comparer vos valeurs d'entrée aux types déclarés du schéma. L'inférence est flexible afin d'éviter les faux positifs :
| Valeur d'entrée | Type inféré | Accepte aussi |
|---|---|---|
| true / false | boolean | (booléen uniquement) |
| 42 | integer | number |
| 3.14 | number | integer |
| "hello" | string | (chaîne uniquement) |
| [1, 2, 3] | array | (tableau uniquement) |
| {"key": "val"} | object | (objet uniquement) |
Remarque : les booléens sont vérifiés avant les entiers, car dans certains langages, le booléen est un sous-type d'entier. Cet ordre évite que true soit inféré comme un entier.
Ce tableau décrit ce que le validateur accepte, pas ce que la génération produit. Un exemple de valeur à 3 ne fait pas de la propriété un entier : les champs numériques sont livrés en number à moins qu'une étape dédiée n'affirme que la quantité est réellement discrète et qu'aucune valeur observée ne la contredise. Un nombre entier dans un échantillon ne prouve pas que les demis soient impossibles — et déclarer un entier à tort tronquerait 6.2 en 6 dans une base de données consommatrice.