« Ça avait l’air bon quand j’ai essayé » est la façon dont la plupart des régressions de prompts atteignent la production. Les tests et l’évaluation de prompts remplacent cela par des preuves : un ensemble fixe d’entrées, une définition de ce qu’est une sortie correcte et un contrôle exécuté à chaque modification du prompt.
Les deux termes se recoupent. Évaluer, c’est mesurer la qualité d’un prompt ou de sa sortie. Tester, c’est exécuter ces mesures automatiquement et échouer quand un seuil n’est pas atteint.
Deux choses que vous pouvez évaluer
Le prompt lui-même. Est-il clair, complet, cohérent et sûr tel qu’il est écrit ? C’est de l’analyse statique. Elle ne nécessite aucun appel au modèle ; elle est donc instantanée, gratuite et donne le même résultat à chaque fois.
La sortie du modèle. Avec ce prompt et cette entrée, la réponse est-elle correcte ? Cela nécessite des appels au modèle et un moyen de juger le résultat.
Elles détectent des problèmes différents, et un bon processus utilise les deux. Les contrôles statiques s’exécutent à chaque frappe et à chaque commit. L’évaluation de la sortie s’exécute quand un changement peut affecter le comportement.
Couche 1 : contrôles statiques du prompt
Un contrôle statique lit le texte du prompt et cherche des défauts connus :
- Aucun objectif énoncé, ou aucun format de sortie.
- Mots vagues et tailles sans chiffres.
- Instructions qui se contredisent ou se répètent.
- Variables de modèle non délimitées.
- Formulations d’injection, identifiants ou données personnelles.
- Nombre de tokens au-dessus d’un budget.
C’est ce que fait l’évaluation de prompts PromptFlowEngine. Le score est 100 moins une pénalité fixe par constat (30 pour critique, 10 pour avertissement, 3 pour information), plafonné à 50 dès que quelque chose est critique, avec la même arithmétique pour chacune des huit dimensions. Comme la formule est publiée, une variation de score remonte toujours à un constat précis.
Un score statique ne dit pas si la réponse du modèle est juste. Il dit si le prompt donne au modèle une chance équitable.
Couche 2 : un jeu de tests
Un jeu de tests est une liste d’entrées avec des attentes. Commencez petit.
| Type de cas | Pourquoi |
|---|---|
| Entrées typiques | Confirme que le chemin principal fonctionne |
| Cas limites | Vide, très long, mauvaise langue, mal formé |
| Entrées adverses | Tentatives de passer outre les instructions |
| Échecs passés | Chaque bogue trouvé devient un test permanent |
Vingt cas bien choisis valent mieux que deux cents quasi-doublons. Tirez-les du trafic réel quand c’est possible, données personnelles retirées.
Couche 3 : décider si une sortie réussit
Utilisez la méthode la moins chère capable de juger la propriété.
Assertions de code. Déterministes et gratuites. Utilisez-les partout où c’est possible.
- S’analyse comme du JSON et correspond au schéma.
- Contient, ou ne contient pas, une chaîne donnée.
- Longueur dans les bornes.
- L’étiquette est égale à l’étiquette attendue.
- Réponse numérique dans la tolérance.
Comparaison à une référence. Comparez à une bonne réponse connue par correspondance exacte ou par une mesure de similarité. Adaptée à l’extraction et à la classification, faible pour l’écriture libre.
Évaluation par modèle. Un second modèle juge la sortie selon une grille. Utilisez-la pour les qualités que le code ne peut pas vérifier : fidélité à une source, ton, exhaustivité.
You are grading an answer against a source document.
Does the answer contain any claim not supported by the source?
Reply with a JSON object: {"unsupported_claims": [string], "pass": boolean}.
<source>{{source}}</source>
<answer>{{answer}}</answer>
Les évaluateurs par modèle sont eux-mêmes des prompts, avec leurs propres modes de défaillance. Limitez chaque grille à une question, demandez la preuve avant le verdict et vérifiez l’évaluateur sur un échantillon de jugements humains avant de lui faire confiance.
Revue humaine. L’étalon de référence, et le plus coûteux. Utilisez-la pour calibrer les méthodes automatiques et pour examiner un échantillon de sorties de production.
Métriques à suivre
| Métrique | Ce qu’elle vous dit |
|---|---|
| Taux de réussite | Part des cas de test qui répondent aux attentes |
| Validité du format | Part des sorties qui s’analysent correctement |
| Fidélité | Part des réponses étayées par le contexte fourni |
| Justesse des refus | Décline ce qu’il faut, répond à ce qu’il faut |
| Cohérence | Accord entre exécutions répétées d’une même entrée |
| Tokens et latence | Coût de la qualité que vous obtenez |
Indiquez le taux de réussite avec le nombre de cas. « 90 % » sur 10 cas, c’est un échec.
Gérer le non-déterminisme
Le même prompt et la même entrée peuvent produire des sorties différentes. Tenez-en compte :
- Réglez une température basse pour les tâches qui exigent de la cohérence.
- Exécutez chaque cas plusieurs fois et indiquez le taux de réussite, pas un résultat unique.
- Faites des assertions sur des propriétés (« mentionne le délai de remboursement ») plutôt que sur le texte exact.
- Figez la version du modèle et relancez la suite quand elle change.
Tests de régression en CI
Les tests ne vous protègent que s’ils s’exécutent automatiquement.
À chaque commit : contrôles statiques. Ils sont rapides et n’exigent aucune clé d’API. La barrière de test de prompts fait échouer une pull request quand un fichier de prompt passe sous un score minimal, dépasse une limite de tokens ou contient un constat critique comme une clé divulguée.
- run: promptflow check "prompts/**/*.md" --min-score 70 --max-tokens 1500
Lors de changements de prompt ou de modèle : le jeu de tests de sortie, avec un seuil de taux de réussite.
Selon un calendrier : l’ensemble complet face au modèle en production, pour détecter les changements côté fournisseur.
PromptFlowEngine couvre le premier de ces points. Il n’exécute pas de prompts face à un modèle ; l’évaluation de la sortie exige votre propre exécuteur de tests et un accès au modèle.
Comparer deux versions
Pour choisir entre des brouillons, comparez-les sur les mêmes entrées et regardez ce qui a changé, pas seulement les totaux : quels cas sont passés de réussite à échec, comment les tokens ont évolué et si de nouveaux problèmes sont apparus. La vue de comparaison de l’espace de travail indique les écarts de qualité, de tokens et de coût entre deux prompts et liste les constats que chaque version résout ou introduit.
Un processus minimal pour démarrer
- Exécutez le contrôle statique et corrigez les avertissements.
- Écrivez 20 cas de test avec leurs attentes.
- Ajoutez des assertions de code pour le format et le contenu requis.
- Enregistrez le taux de réussite de référence.
- Conditionnez les pull requests au contrôle statique.
- Relancez le jeu de tests chaque fois que le prompt ou le modèle change.
Pour savoir comment utiliser ces résultats afin d’améliorer un prompt, voir l’optimisation de prompts. Pour garder versions et résultats organisés, voir la gestion de prompts.