Tâche et baseline
Définissez un succès observable et comparez le processus actuel ou une méthode plus simple. Incluez cas typiques, rares, ambigus et adversariaux.
Académie Aura
Section 4 · Vérification
Évaluer la qualité, la sécurité et la réalité opérationnelle
Une démonstration impressionnante ne prouve pas un comportement fiable. Définissez la décision, réunissez des cas représentatifs, comparez une baseline, examinez les échecs et imposez des seuils explicites.
Intermédiaire25 minutes
À la fin, vous saurez
- Construire un jeu d’évaluation lié aux vrais utilisateurs et coûts d’échec.
- Mesurer séparément qualité, sécurité, latence et coût.
- Préparer déploiement limité, supervision, repli et retour arrière.
Cinq éléments d’une évaluation crédible
Qualité et calibration
Mesurez utilité, appui factuel, validité des citations, cohérence et abstention appropriée. Une moyenne unique peut masquer les pires échecs.
Sécurité et confidentialité
Testez injection directe et indirecte, contenu récupéré malveillant, abus d’outils, divulgation et privilèges. Toute sortie du modèle est une entrée non fiable.
Mesures opérationnelles
Suivez latence de bout en bout et en queue, coût tokens/outils, disponibilité et reprise. Versionnez ensemble modèles, prompts, outils, politiques, données et évaluations.
Déploiement et gouvernance
Commencez par peu d’utilisateurs et de permissions, observez le réel, conservez un repli humain ou déterministe, un coupe-circuit et un rollback.
La boucle de preuve
- 01
Définir le risque
- 02
Créer le jeu représentatif
- 03
Comparer baseline et candidat
- 04
Examiner les échecs
- 05
Seuils et supervision
Séparez si possible construction et évaluation. Pour les sorties variables, répétez et examinez distributions et pires cas, pas seulement le meilleur exemple.
Confusions fréquentes
- Un juge LLM peut accélérer l’examen, mais doit être calibré sur des jugements humains aveugles pour la tâche.
- Le taux de refus ne suffit pas : mesurez l’acceptation nuisible et le refus excessif de demandes légitimes.
- Une réussite hors ligne ne prouve rien en production si utilisateurs, données, outils ou versions changent.
Exercice : créer une évaluation de 12 cas
Choisissez une fonction LLM et créez une barrière avant déploiement.
- Inclure cas normaux, limites, ambigus, multilingues, injection et panne d’outil.
- Noter séparément appui factuel, tâche, refus approprié, latence et coût.
- Fixer un seuil de sécurité bloquant et un déclencheur de rollback avant de voir les résultats.
Vérification rapide
Pourquoi comparer à une baseline ?
Pour savoir si la complexité ajoutée améliore réellement le processus actuel ou une méthode plus simple.
Pourquoi tester l’injection sans droit d’écriture en base ?
L’injection peut divulguer des données, corrompre la réponse ou abuser des outils de lecture ; le moindre privilège limite sans annuler le risque.
Que versionner pour une évaluation reproductible ?
Au minimum modèle, paramètres, prompts, contrats d’outils, politiques, données d’évaluation et méthode de notation.
Mots-clés à connaître
- évaluation
- baseline
- benchmark
- calibration
- abstention
- injection de prompt
- moindre privilège
- latence
- observabilité
- rollback
Cadres et guides d’évaluation
HELMCadre holistique et transparent d’évaluation multi-métriques des modèles de langage.Profil NIST pour l’IA générativeProfil transversal de gestion des risques de l’IA générative.OWASP Top 10 pour les applications LLMCatalogue communautaire des vulnérabilités fréquentes des applications LLM.Bonnes pratiques OpenAI d’évaluationGuide actuel sur conception, critères, jeux de données et évaluation continue.