Métriques d'évaluation de prompts : Mesurer ce qui compte réellement

Les métriques d'évaluation de prompts sont des signaux quantitatifs indiquant si un prompt produit fiablement la sortie souhaitée sur l'ensemble des entrées importantes. Sans elles, l'évaluation est subjective : deux ingénieurs examinant le même prompt sur différents exemples aboutissent à des conclusions différentes. La bonne métrique dépend de ce que votre prompt produit. Un prompt d'extraction JSON nécessite d'autres métriques qu'un prompt créatif. Quand vous choisissez la bonne métrique, vous pouvez évaluer la qualité de manière systématique. Choisir mal produit des scores trompeurs masquant la vraie qualité de production.

Le type de sortie détermine la métrique valide. Appliquer BLEU sur JSON ou oui/non sur génération créative produit des scores dénués de sens.

Le taux de réussite est le pourcentage d'entrées de test où la sortie rencontre les critères de succès — et c'est la métrique la plus utile car elle se traduit directement par le taux d'erreur en production. Un taux de 92% signifie 8% des demandes réelles échoueront. Taux de réussite = sorties réussies / nombre total de tests Pour les sorties structurées, définissez « réussite » précisément avant les tests : JSON valide, champs obligatoires présents, valeurs dans l'énumération admissible, longueur sous la limite. Pour la classification, « réussite » signifie le label correct est retourné. Suivez le taux de réussite par version de prompt. Une chute de plus de 5 points est une régression. Plus de 10 points bloque le déploiement en production. En avril 2026, PromptQuorum observe des taux médians de 88–94% pour les prompts d'extraction JSON avec GPT-4o au premier déploiement. Quand vous construisez une bibliothèque, établissez les baselines pour détecter les régressions.

BLEU (Bilingual Evaluation Understudy) mesure le chevauchement n-gramme entre une sortie modèle et un texte de référence. C'est la métrique standard pour la traduction automatique et convient pour toute tâche où la sortie doit correspondre étroitement à une référence. BLEU est trompeur pour : - JSON ou sortie structurée : BLEU note les tokens de format, pas la correction sémantique - Exécution d'instructions : Un prompt obéissant à toutes les instructions mais paraphrasant différemment scores mal sur BLEU - Génération créative : BLEU pénalise la diversité lexicale même quand la qualité est haute Quand BLEU convient : traductions où une référence existe, résumés comparés à un résumé humain, QA extractif avec réponses verbatimes attendues.

La similarité sémantique mesure la proximité du sens entre deux textes en calculant la similarité cosinus de leurs embeddings. Elle surpasse BLEU pour les paraphrases et reformulations car elle capture le sens plutôt que le choix de mots. Comment ça marche : Embeddez la sortie modèle et la référence avec OpenAI text-embedding-3-small ou un modèle d'embedding local, puis calculez la similarité cosinus. Les scores > 0,85 indiquent généralement un contenu sémantiquement équivalent. Limitations : la similarité sémantique ne vérifie pas l'exactitude factuelle, ne détecte pas les violations de format, et peut noter le contenu hallucciné haut si proche sémantiquement de la réponse attendue.

LLM-as-Judge utilise un modèle capable — généralement GPT-4o ou Claude Opus 4.7 — pour noter les sorties selon une rubrique. Cela scale l'évaluation à des milliers de cas sans examen humain et gère les dimensions de qualité que les métriques binaires manquent : cohérence, ton, complétude, exactitude factuelle. L'approche du juge requiert : 1. Une rubrique détaillée (critères de notation par dimension) 2. Un format de sortie structuré (par ex. JSON avec score + justification) 3. Quand vous testez les prompts sur plusieurs modèles, calibrez le juge contre les jugements humains pour votre tâche

Suivez votre métrique primaire par version et alertez si elle baisse de plus de 5 points de la baseline établie. Exécutez le même ensemble de test avant et après chaque changement de prompt, mise à jour de modèle ou ajustement de température. Quand vous implémentez l'audit de prompts et la détection du risque de régression, suivez ce flux : 1. Enregistrez le score actuel comme baseline (par ex. taux de réussite = 91%) 2. Faites le changement de prompt 3. Relancez l'ensemble complet de test 4. Comparez le nouveau score à la baseline 5. Si chute > 5 points : bloquer, investiguer, corriger Pour la détection automatisée dans CI/CD, des outils comme Promptfoo s'intègrent avec GitHub Actions et peuvent échouer une PR si le taux baisse.

Les cadres réglementaires exigent de plus en plus des métriques documentées, avec obligations spécifiques selon la juridiction et la classification de risque. - UE (AI Act 2025–2026) : Les systèmes IA à haut risque doivent démontrer des tests documentés avec métriques de qualité quantitatives. Les enregistrements d'évaluation — ensembles, taux, baselines — fournissent des preuves auditables pour les exigences de transparence. - USA (SOC 2 / NIST AI RMF) : Les audits SOC 2 Type II attendent l'assurance qualité documentée. Les métriques d'évaluation avec historique de version satisfont les exigences de gestion des changements et de contrôle qualité. - France (CNIL) : Les directives CNIL recommandent l'inférence locale pour les données professionnelles sensibles. Documentez le taux de réussite et les baselines comme preuve de gestion des risques. - Évaluation multilingue : En déployant sur plusieurs langues, évaluez chaque variante séparément. Les seuils BLEU et similarité diffèrent significativement entre paires. Un prompt à 0,92 en anglais peut être 0,78 en français due aux différences syntaxiques.