Gains :
- Capacité à établir des couches de validation de sortie basées sur des schémas et des règles
- Capacité à exiger de manière significative la participation humaine dans les décisions à fort impact
- Capacité à concevoir un routage basé sur la vérification et le seuil de confiance avec le deuxième modèle
Un modèle linguistique produit des résultats fluides, convaincants et souvent précis, mais « convaincant » n’est pas la même chose que « correct ». Le modèle peut ajuster silencieusement un montant, une date ou un champ JSON ; C'est ce qu'on appelle une hallucination (le modèle produit en toute confiance des informations qui n'existent pas dans la réalité). Dans un système d'entreprise, si ce résultat passe à l'étape suivante (un paiement, un e-mail, une écriture dans une base de données) l'erreur se répercute sur le monde réel. Dans cette unité, nous apprendrons à filtrer la sortie avec des couches de vérification avant qu'elle n'entre dans le système et à exiger l'intervention d'un humain dans la boucle dans les décisions à fort impact.
Pourquoi la validation des résultats est-elle requise ?
La sortie du modèle peut être corrompue de deux manières principales : le format (n'est pas conforme au schéma JSON attendu, le champ est manquant/excédentaire) et le contenu (le format est correct mais la valeur est fausse : un code produit inexistant, une date illogique). Il existe une troisième dimension en termes de sécurité : la sortie malveillante (une commande malveillante produite à la suite d'une injection ou d'une fuite). Un système solide arrête les trois à la porte.
Attention : « Modèle généralement précis » n'est pas un critère de production. Dans un système sans vérification, même une erreur sur mille signifie 100 transactions erronées par jour sur 100 000 requêtes par jour.
Couches d'authentification : étape par étape
- Validation du schéma. Vérifiez auprès de la machine que le résultat est conforme à la structure attendue : les champs sont-ils présents, leurs types sont-ils corrects, les champs obligatoires sont-ils remplis ?
- Validation des règles/logique métier. Les valeurs correspondent-elles aux règles métier ? (Montant > 0, la date n'est pas dans le futur, le code produit appartient au catalogue.)
- Contrôle de référence/source. Si le modèle produit une assertion, peut-il être lié à la source ? (La citation de RAG est-elle réellement dans le document ?)
- Validation avec le deuxième modèle (LLM-as-juge). Un modèle indépendant évalue le résultat comme « correct/incomplet/risqué ».
- Seuil de confiance et orientation. Si le modèle ou le validateur signale un faible niveau de confiance, le résultat ne passe pas automatiquement ; s'adresse aux humains.
- Contrôle humain. Un résultat de puissance élevée ou faible dépend de l'approbation d'un expert.
Quatre modèles copiables
Schéma + "inventez-vous si vous ne savez pas" ensemble :
Renvoyez la réponse UNIQUEMENT dans le schéma JSON suivant : Écrivez « low ». N’écrivez JAMAIS une estimation comme si elle était exacte.
Vérification avec le deuxième modèle (invite du juge) :
Vous êtes un validateur indépendant. Vous trouverez ci-dessous un texte <source> et une <claim>. Vérifiez si CHAQUE numéro et date de la réclamation apparaissent textuellement dans la source. Pour chacun, dites : "vérifié | pas dans la source | contredit la source." Si même l'un d'entre eux est « absent/en conflit », marquez le résultat comme « EXAMEN HUMAIN REQUIS ».<source>{{ text }}</source><claim>{{ model_output }></claim>
Règle de routage du seuil de confiance :
Règle de routage :- emin_misin = "high" ET montant < 10 000 TL -> traitement automatique - emin_misin = "medium" OU montant 10 000-100 000 TL -> deuxième vérification du modèle - emin_misin = "low" OR montant > 100 000 TL -> approbation humaine requise
Carte récapitulative de l'audit humain (accélère l'examen) :
Lorsque vous présentez la décision à une personne, produisez cette carte : - Qu'est-ce qui est proposé ? (une phrase) - Sur quelle source est-il basé ? (référence de l'article/du document)- Quelles sont les 2 hypothèses les plus faibles ?- Si elles sont approuvées, peuvent-elles être annulées ? (oui/non)
Invite faible/Invite forte
mauvaise approche
Approche forte
"Soustraire le montant de la facture" (texte libre)
Schéma JSON strict + null + champ de confiance
Écrire la sortie directement dans le système de paiement
Schéma → règle → approbation humaine (si nécessaire)
Je dis juste au modèle "assure-toi"
Validation numéro/date avec deuxième modèle
Traiter chaque sortie avec la même confiance
Un routage basé sur l’influence et la confiance
L’approche forte n’espère pas que le modèle soit correct ; Cela crée une porte qui vous attrapera lorsque vous vous trompez.
Trois mini-étuis
Cas 1 — Le programme à lui seul n’était pas suffisant. Une automatisation comptable extrayait le montant des factures au format JSON. Le schéma était correct, mais le modèle produisait « 125 000 » au lieu de « 1 250,00 » sur une facture (décalage décimal). Le projet n’a pas réussi à saisir cela ; la vérification des règles (« le montant doit être conforme au total des articles de la facture de ± 1 % ») a été détectée et un enregistrement incorrect de 112 500 TL a été évité.
Cas 2 — Le deuxième modèle a capturé l'hallucination. « Préavis de résiliation de 30 jours », a indiqué un assistant juridique dans le résumé du contrat ; Or, dans le contrat, c'était 90 jours. Lorsque le juge indépendant a signalé le modèle comme étant « en conflit avec la source », le résultat a été transmis à l'humain et corrigé. Si c'était automatique, le client notifierait l'annulation sur la base d'une date erronée.
Cas 3 — Le routage a réduit la charge de 70 %. Un système de réclamations d’assurance approuvait automatiquement les réclamations de faible montant et de haute sécurité et envoyait uniquement celles dépassant le seuil/faiblement sécurisées à l’expert. Sur les 3 200 demandes quotidiennes, seules 950 sont tombées sur les humains ; les experts ont consacré leur temps aux 30 % réellement risqués, le temps moyen de transaction passant de 4 heures à 40 minutes.
Astuce : ne configurez pas le contrôle humain de manière à ce que « les gens puissent tout voir » : cela les fatiguerait et l'approbation deviendrait un tampon. Au lieu de cela, acheminez uniquement les résultats à fort impact et à faible confiance vers l’humain ; Cela concentre l’attention sur ce qui compte vraiment.
Donner du sens au contrôle humain
Human-in-the-loop ne consiste pas à mettre une case à cocher sur papier. L'examinateur doit avoir (1) le contexte pour comprendre la décision, (2) l'accès à la source et (3) l'autorité pour dire « non ». Sinon, le contrôle reste cosmétique. La carte de révision (quatrième modèle ci-dessus) est destinée à fournir précisément ce contexte.
Erreurs courantes
- Il suffit de valider le schéma et d'ignorer les erreurs de contenu/valeur.
- En pensant qu'en disant au modèle "assurez-vous", vous effectuez une véritable vérification.
- Mettez automatiquement en œuvre des décisions irréversibles et à fort impact.
- Mettre un contrôle humain sur chaque sortie et transformer l’approbation en un tampon sans signification.
- Dire « approuver » au réviseur sans donner la source et le contexte.
- Traiter toutes les sorties avec le même risque sans établir de seuil de confiance ni de routage.
En résumé
- La sortie est corrompue de trois manières : la forme, le contenu et l’intention malveillante ; un système solide arrête les trois à la porte.
- Couches : validation de schéma, règles/logique métier, contrôle de source, deuxième modèle (LLM-as-juge) et routage de seuil de confiance.
- L'intervention humaine devrait être obligatoire pour les résultats à fort impact et à faible sécurité.
- L'évaluation humaine doit être significative : l'évaluateur doit avoir un contexte, un accès aux ressources et l'autorité de dire « non ».
- La sécurité et l'efficacité sont obtenues en dirigeant uniquement les produits à risque vers les humains, et non vers tous les résultats.
Tâche de candidature
Prenons un exemple de votre propre sortie IA. Définissez d’abord un schéma JSON et forcez-y la sortie. Ensuite, écrivez au moins deux règles métier (par exemple, « le montant correspond au total des éléments »). Enfin, établissez une table de routage : quelle combinaison confiance/influence va automatiquement, laquelle va au deuxième modèle, qui va à l'humain ? Générez un échantillon défectueux et observez où chaque couche le capture.
liste de contrôle
- [ ] Je définis un schéma strict pour la sortie et je le vérifie avec la machine.
- [ ] J'ai ajouté au moins une validation métier/règles (logique de valeur).
- [ ] Je peux relier les affirmations à la source et les vérifier.
- [ ] Deuxième modèle ou validation humaine disponible pour des résultats à impact élevé/faible sécurité.
- [ ] Règle de routage définie sur la base de la confiance et de l'influence.
- [ ] L'examinateur reçoit le contexte, la source et le pouvoir de rejeter.