Vérifier une sortie d'IA
Toute sortie d'IA reste une hypothèse tant qu'elle n'est pas testée. On explicite ses hypothèses, on la confronte à un cas dont on connaît la réponse, puis on relit ce qu'on va signer.
- vérification
- hallucination
- test
- validation
- cas de contrôle
- relecture
Syntaxe
1. Hypothèses : qu'a supposé le modèle (schéma, version, règle métier) ?2. Cas de contrôle : un exemple dont vous connaissez déjà la réponse3. Exécution : playground SQL, tests, lint, build, calcul à la main4. Relecture : sauriez-vous expliquer chaque ligne à l'oral ?Exemple
Demande : « nombre de commandes par client, y compris les clients sans commande »Requête générée : SELECT c.nom, COUNT(*) AS nb FROM clients c LEFT JOIN commandes o ON o.client_id = c.id GROUP BY c.id, c.nom;Cas de contrôle : la cliente « Durand » n'a passé aucune commande.Exécution : Durand → 1 ← faux : COUNT(*) compte la ligne complétée par des NULLCorrection : COUNT(o.id) au lieu de COUNT(*)Résultat attendu après correction : Durand → 0À retenir
- Adaptez la preuve au domaine : une requête s'exécute sur des données connues, un code passe le lint et les tests, un MCD se justifie cardinalité par cardinalité.
- Pour une recherche documentaire, remontez à la source primaire (texte officiel, documentation) plutôt que de croiser deux réponses de chatbots qui peuvent partager la même erreur.
- Demandez au modèle quels cas limites pourraient faire échouer sa solution, puis testez-les vous-même.
- Ne rendez jamais un travail produit avec l'IA que vous ne sauriez pas expliquer et défendre seul.
- Piège : vérifier seulement que « ça tourne ». Une requête qui s'exécute sans erreur peut renvoyer un résultat faux ; seul un cas de contrôle dont vous connaissez la réponse le révèle.
Voir aussi
- Structure ROCCF du briefUn bon prompt est un brief en cinq rubriques : Rôle, Objectif, Contexte, Contraintes et Format. Cette grille ROCCF évite la réponse générique et rend le prompt réutilisable par l'équipe.
- Itérer un promptLe premier prompt est rarement le bon. Une boucle demande, sortie, critique, amélioration corrige un défaut précis à chaque tour, au lieu de tout relancer en espérant un meilleur résultat.
- HallucinationsUn LLM produit le texte le plus plausible, pas le plus vrai : il peut inventer une fonction, une loi ou une source avec aplomb. On s'en protège en fournissant des sources et en vérifiant.
- Évaluer un système LLMOn n'améliore pas ce qu'on ne mesure pas : un jeu de cas de test avec des critères explicites, rejoué à chaque changement de prompt ou de modèle, remplace l'impression que « c'est mieux ».