Une bonne session dans le playground n’est pas une preuve
Les systèmes génératifs sont faciles à démontrer : les humains choisissent naturellement des requêtes coopératives et interprètent un langage plausible comme un progrès. La production est différente. Les entrées sont incomplètes, les permissions changent, les sources se contredisent, les outils expirent et les utilisateurs découvrent des chemins que l’équipe n’avait pas imaginés.
L’évaluation transforme « cela semblait fonctionner » en décision de livraison. Microsoft Foundry fournit évaluateurs, traçage, supervision et intégration Application Insights, mais l’organisation doit toujours définir la réussite pour son processus.
Commencer par la décision soutenue
Ne commencez pas par sélectionner des métriques génériques. Écrivez d’abord l’affirmation opérationnelle :
À partir d’un dossier approuvé, l’assistant produit un brouillon ancré dans les sources qu’une personne qualifiée peut accepter ou corriger sans introduire de faits non étayés.
Cette affirmation révèle les preuves nécessaires : dossiers représentatifs, usage attendu des sources, affirmations interdites, effort de révision, latence et traitement de l’incertitude.
Si le système agit, ajoutez des exigences sur le choix de l’outil, l’exactitude des arguments, l’autorisation, les effets de bord et la reprise.
Construire un jeu d’évaluation représentatif
Un jeu utile contient plus que les cas habituels :
- cas fréquents et importants pour l’activité ;
- cas difficiles mais valides ;
- entrées incomplètes ou contradictoires ;
- demandes à refuser ou à escalader ;
- données sensibles et frontières d’autorisation ;
- échecs d’outils et de dépendances ;
- incidents déjà observés en production.
Versionnez le jeu et documentez la raison d’être de chaque cas. Protégez les données de test avec la même discipline que les données de production. Les cas synthétiques peuvent élargir la couverture, mais ne remplacent pas les exemples du processus réel sélectionnés par les experts.
Utiliser un portefeuille de mesures
Aucun score unique ne résume l’aptitude à la production. Combinez plusieurs formes de preuve :
Les contrôles déterministes vérifient schéma, citations, champs requis, contenus interdits, limites numériques et arguments exacts des outils.
Les mesures métier évaluent si le système accomplit le travail. Souvent propres au domaine, elles peuvent nécessiter une revue humaine ou un évaluateur personnalisé.
Les mesures de qualité peuvent examiner pertinence, ancrage, cohérence ou fluidité. Une réponse fluide peut être fausse ; la qualité rédactionnelle ne remplace jamais l’exactitude.
Les mesures de sécurité testent contenus nocifs, attaques par prompt, traitement des données sensibles et risques liés aux politiques.
Les mesures d’agent examinent l’achèvement de la tâche, la précision des appels d’outils, la trajectoire et le respect du cadre autorisé.
Les évaluateurs LLM-as-judge sont utiles, mais restent probabilistes. Calibrez-les contre des jugements humains et examinez les désaccords.
Rendre la porte explicite
Définissez les critères avant l’évaluation finale. Une porte de livraison peut exiger :
- aucune défaillance critique d’autorisation ou de frontière des données ;
- la réussite de tous les contrôles déterministes obligatoires ;
- un seuil minimal de succès sur les cas prioritaires ;
- aucune régression au-delà de la tolérance convenue ;
- une latence et un coût acceptables sous charge représentative ;
- l’acceptation nommée des défaillances résiduelles connues.
Présentez les distributions et les échecs individuels, pas seulement une moyenne. Un score de 95 % peut cacher une défaillance catastrophique dans les cinq pour cent les plus importants.
Relier les traces à l’évaluation
Les traces distribuées exposent les appels de modèle, la recherche documentaire, les outils, la latence et les dépendances d’un processus en plusieurs étapes. Utilisez-les pour expliquer pourquoi une évaluation a échoué : mauvaise source, identifiant mal formé ou modification des instructions.
Conservez les versions de l’application, du prompt, de l’agent, du modèle, des outils et du jeu avec chaque exécution. Sans cette filiation, la comparaison devient une conjecture.
Continuer après la mise en production
L’observabilité doit suivre la santé opérationnelle et les signaux de qualité. Évaluez un échantillon approprié du trafic dans des limites claires de confidentialité et de conservation. Alertez sur des conditions significatives, pas sur chaque mouvement statistique.
Ajoutez les incidents confirmés et les erreurs récurrentes au jeu d’évaluation. Rejouez la porte lorsque prompts, modèles, recherche documentaire, outils, politiques ou logique applicative changent sensiblement.
L’évaluation est un système de gestion
Le but n’est pas un tableau de bord rempli de scores. C’est un accord reproductible entre responsables métier, experts, ingénierie, sécurité et opérations sur ce qui peut être déployé.
Foundry fournit une mécanique utile d’évaluation et d’observabilité. La confiance vient de la qualité des cas, des seuils, des responsables et de la boucle de correction qui l’entourent.
Référence officielle
Microsoft présente l’évaluation, la supervision, le traçage, les tests avant production et l’évaluation continue dans Observabilité de l’IA générative.