Règles de validation - Documentation Entity Enricher

Règles de validation

Huit règles de validation garantissent la qualité des schémas. Lorsqu'une règle échoue pendant la génération de schéma par IA, l'erreur est renvoyée à l'IA pour une auto-correction automatique.

Fonctionnement de l'autocorrection

Après que l'IA a généré un schéma, celui-ci passe par les 8 règles de validation. Si une règle échoue, les messages d'erreur correspondants sont compilés et renvoyés à l'IA comme retour. L'IA produit alors un schéma corrigé, qui est validé à nouveau. Cette boucle se poursuit jusqu'à 6 tentatives au total (1 initiale + 5 nouvelles tentatives).

Flux de correction

L'IA génèreSchéma avec propriétés, types, expertises et descriptions
Vérifications du validateur8 règles appliquées séquentiellement, toutes les erreurs collectées
En cas d'erreursMessages d'erreur renvoyés : « Fix these issues: [revenue: type mismatch...] »
L'IA corrigeProduit un schéma mis à jour corrigeant les erreurs signalées
RépéterJusqu'à ce que toutes les règles soient validées ou que le nombre maximal de tentatives soit atteint

En pratique, la plupart des schémas passent du premier coup. La boucle d'autocorrection est un filet de sécurité qui gère les cas limites où l'IA commet des erreurs de type ou oublie un champ.

Règles de génération vs édition

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éeRègles appliquéesPourquoi
GénérationLes 8 règlesLes données d'entrée sont disponibles pour comparaison
Édition par IARègles 2, 3, 4, 5 uniquementAucune donnée d'entrée ; l'utilisateur peut modifier la structure intentionnellement

Les 8 règles

Règle 1

Nombre de domaines d'expertise

Portée : Génération uniquement

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.

Exemple d'erreur : Too many expertise domains: 6 defined, maximum is 3

Le 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.

Règle 2

Au moins une propriété

Portée : Les deux

Chaque schéma doit définir au moins une propriété. Un schéma vide ne peut pas être utilisé pour l'enrichissement.

Exemple d'erreur : Schema must have at least one property

Cela couvre les cas où l'IA produit une structure JSON valide mais oublie d'y inclure le moindre champ réel.

Règle 3

Types de schéma JSON valides

Portée : Les deux

Chaque type de propriété doit être l'un des types JSON Schema standard : string, number, integer, boolean, array, object ou null.

Exemple d'erreur : 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.

Règle 4

Les cibles $ref existent

Portée : Les deux

Toutes les références $ref doivent pointer vers des entités définies dans la section $defs du schéma. Les références orphelines cassent le pipeline d'enrichissement.

Exemple d'erreur : manufacturer: $ref '#/$defs/Company' references undefined definition

Lorsque l'IA crée une référence telle que #/$defs/Company, une définition Company correspondante doit exister dans le bloc $defs.

Règle 5

La clé d'expertise existe

Portée : Les deux

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.

Exemple d'erreur : 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.

Règle 6

Expertise requise

Portée : Génération uniquement

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é.

Exemple d'erreur : revenue: expertise is required for non-object types

Les 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.

Règle 7

Le type correspond aux données d'entrée

Portée : Génération uniquement

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.

Exemple d'erreur : 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.

Règle 8

Toutes les propriétés d'entrée présentes

Portée : Génération uniquement

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.

Exemple d'erreur : 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.

Inférence de type

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éeType inféréAccepte aussi
true / falseboolean(booléen uniquement)
42integernumber
3.14numberinteger
"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.

Prochaines étapes