# D3 · Evaluating AI Applications Concevoir des évaluations avec des jeux de données représentatifs et des graders, évaluation offline versus online, prévenir les régressions, analyse des échecs et le prompt optimizer pour les applications d’IA sur l’API OpenAI. import { Accordions, AccordionItem } from '@prosefly/astro-components'; Ce domaine représente environ **16 %** de l’examen blanc OAI-API — à peu près **10 des 60 items** — et reflète le cours Academy *Evaluate AI Applications* (70 min). Il teste si vous savez prouver qu’une application d’IA fonctionne et la maintenir en état de marche : construire un jeu de données représentatif, choisir un grader, exécuter en offline avant en online, attraper les régressions et analyser les échecs au lieu de deviner. Une nuance à connaître : **l’Evals API est désormais regroupée sous les « Legacy APIs » dans la documentation**, mais la *pratique* de l’évaluation reste aussi centrale que jamais — dites « l’Evals API (désormais regroupée avec les legacy APIs) » plutôt que de la présenter comme la surface la plus récente. ## Ce que vous devez savoir Une évaluation est un jeu de données plus un grader plus une métrique. Le jeu de données doit être **représentatif** des entrées réelles, y compris les cas difficiles et rares, pas une poignée d’exemples triés sur le volet. Le grader décide du pass/fail : correspondance exacte ou code pour les contrôles déterministes, ou un **LLM-as-judge** avec une grille pour la qualité ouverte. Vous exécutez les évaluations **offline** avant de livrer (sur un jeu de données figé) et les évaluations **online** après (en échantillonnant le trafic en direct), et vous gardez une référence pour que tout changement de prompt ou de modèle qui baisse le score soit attrapé comme une **régression**. Quand quelque chose échoue, vous faites une **analyse des échecs** — regrouper les échecs, trouver le motif, corriger la cause — plutôt que d’ajuster le prompt au hasard. Le **prompt optimizer** peut améliorer un prompt face à votre évaluation. ## Objectifs d’apprentissage À la fin de cette page, vous devriez être capable de : 1. **Construire un jeu de données d’évaluation représentatif**, y compris les cas limites et adversariaux. 2. **Choisir un grader** — correspondance exacte, basé sur le code, ou LLM-as-judge avec une grille. 3. Distinguer l’évaluation **offline** et **online** et utiliser chacune correctement. 4. **Prévenir les régressions** en établissant une référence et en relançant les évaluations à chaque changement. 5. **Analyser les échecs** en les regroupant plutôt qu’en ajustant au hasard. 6. Utiliser le **prompt optimizer** et savoir où se situent les évaluations dans la documentation actuelle. --- ## 3.1 Ce qu’est une évaluation ```text ┌──────────────┐ ┌────────────┐ ┌──────────┐ INPUT ─►│ votre app │─► │ OUTPUT │─►│ GRADER │─► pass / score │ (prompt+model)│ │ │ │(règle ou │ └──────────────┘ └────────────┘ │ juge) │ ▲ └──────────┘ │ │ DATASET (entrées représentatives) METRIQUE (accuracy, score de grille) ``` Une évaluation transforme « ça a l’air mieux » en un nombre que vous pouvez comparer entre versions. Sans elle, chaque changement de prompt est une supposition et chaque régression est livrée silencieusement. :::tip[Signal d’évaluation] Les énoncés avec « comment savez-vous que ça marche », « prouver que le changement est une amélioration », « avant de livrer » ou « le nouveau prompt semble meilleur » sont des items d’évaluation. La bonne réponse mesure sur un jeu de données ; « ça a l’air bien en quelques essais » est le distracteur. ::: ## 3.2 Jeux de données représentatifs Le jeu de données est l’évaluation. Un jeu biaisé donne une réponse confiante et fausse. | Propriété | Pourquoi ça compte | Comment l’obtenir | | --- | --- | --- | | **Représentatif** | Le score doit refléter le trafic réel | Échantillonner des entrées réelles, pas des faciles inventées | | **Couvre les cas limites** | Les entrées rares sont là où se cachent les échecs | Ajouter délibérément les cas difficiles, ambigus, adversariaux | | **Labellisé / a des références** | Le grading a besoin d’une vérité terrain ou d’une grille | Faire labelliser par des SME ; ou définir des critères de grille | | **Bonne taille** | Trop petit est bruité ; trop grand est lent/coûteux | Assez pour qu’un changement de 1–2 % soit significatif (souvent 100–500) | | **Mis à part** | Empêche l’ajustement au test | Garder un jeu sur lequel le prompt n’a jamais été ajusté | ## 3.3 Choisir un grader | Grader | Utiliser pour | Exemple | | --- | --- | --- | | **Correspondance exacte / chaîne** | Déterministe, une seule bonne réponse | Étiquette de classification, champ extrait | | **Basé sur le code** | Règles vérifiables, structure, plages | « Est un JSON valide et `priority` dans 1–4 » | | **LLM-as-judge** | Qualité ouverte face à une grille | « Le résumé est-il fidèle et complet ? » | | **Humain** | Le plus fort enjeu ou calibration de grille | Échantillonnage pour valider le juge | Pour un juge LLM, rédigez une grille explicite et validez-la face à des labels humains sur un échantillon — un juge non vérifié ne fait que déplacer le problème de confiance. ```python grader = { "type": "score_model", "model": "gpt-5.6-terra", "input": [{"role": "system", "content": ( "Score the ANSWER 1-5 for faithfulness to CONTEXT. " "5 = every claim is supported; 1 = unsupported claims. " "Return only the integer.")}], } ``` ## 3.4 Offline versus online ```text OFFLINE ── jeu figé, avant de livrer ──────► gate de la release │ (contrôle de régression) ▼ ONLINE ── échantillon du trafic réel, après ─► attraper la dérive réelle (entrées nouvelles, cas limites) ``` - Les évaluations **offline** s’exécutent sur un jeu de données curé dans des gates de style CI ; elles répondent à « la version B est-elle au moins aussi bonne que la version A ? » - Les évaluations **online** échantillonnent le trafic de production et le gradent (souvent avec un juge LLM ou des signaux de type pouce levé) ; elles attrapent des entrées que votre jeu de données n’a jamais eues. Les deux comptent : l’offline arrête les régressions connues avant la release ; l’online fait remonter les échecs inconnus après. ## 3.5 Prévenir les régressions La valeur d’une évaluation est la comparaison dans le temps. Gardez un score de **référence** et relancez l’évaluation à chaque édition de prompt, changement de modèle ou montée de dépendance. | Changement | Risque de régression | Garde-fou | | --- | --- | --- | | Édition de prompt | Corrige un cas, en casse deux autres | Relancer l’évaluation complète, comparer à la référence | | Mise à niveau de modèle | Le comportement change subtilement | Relancer avant de basculer le trafic de production | | Changement de reasoning effort | Le compromis qualité/coût change | Remesurer à la fois la qualité et le coût | | Nouvelle source de récupération | L’ancrage change | Relancer l’évaluation de réponses ancrées | :::caution[Le piège de l’exemple unique] « Il a géré mon seul exemple difficile, on livre » est la cause de régression la plus fréquente : un changement qui corrige le cas visible casse silencieusement des cas non vus. Seule la comparaison sur le jeu complet vous protège. ::: ## 3.6 Analyse des échecs Quand le score baisse, n’ajustez pas au hasard. **Regroupez les échecs et trouvez le motif.** ```text 1. Extraire chaque item en échec de l'exécution d'évaluation. 2. Les lire ; grouper par cause commune (p. ex. "entrées longues", "nombres", "une catégorie", "demandes ambiguës"). 3. Former une hypothèse sur la cause. 4. Changer UNE chose qui traite le plus grand cluster. 5. Relancer l'évaluation ; confirmer que le cluster a rétréci sans nouvelles régressions. ``` Corriger le plus grand cluster en premier est le mouvement à plus fort levier ; poursuivre les échecs individuels est lent et introduit souvent des régressions. ## 3.7 Le prompt optimizer et où vivent les évaluations - Le **prompt optimizer** prend un prompt et une évaluation et propose une formulation améliorée mesurée face à votre métrique — il automatise la boucle ajuster-et-mesurer, mais il a besoin d’un bon jeu de données et d’un grader pour avoir du sens. - Dans la documentation actuelle, **Evals, fine-tuning, Agent Builder et l’Assistants API sont regroupés sous les « Legacy APIs ».** Les évaluations comptent toujours conceptuellement — se lancer, travailler avec les évaluations, le prompt optimizer, les modèles externes, les bonnes pratiques, les graders — donc décrivez-la comme « l’Evals API (désormais regroupée avec les legacy APIs) » et continuez d’utiliser la pratique ; ne la présentez pas comme la surface la plus récente ni ne l’abandonnez. ## Cadre de décision Utilisez le cadre **PROVE** pour rendre toute affirmation de qualité défendable. | Lettre | Étape | Question | | --- | --- | --- | | **P** | Pick the metric | Quel nombre définit « assez bon » ? | | **R** | Representative data | Le jeu de données correspond-il au trafic réel et aux cas limites ? | | **O** | One grader | Correspondance exacte, code, ou un juge LLM validé ? | | **V** | Versus baseline | La nouvelle version est-elle au moins aussi bonne que la dernière ? | | **E** | Examine failures | Quel est le plus grand cluster d’échecs, et sa cause ? | L’étape que les équipes sautent le plus est **R** — elles évaluent sur des exemples faciles inventés et sont surprises en production. ## Erreurs fréquentes | Erreur | Pourquoi elle survient | Que faire à la place | | --- | --- | --- | | Livrer sur « ça a l’air mieux » | Le ressenti fait figure de preuve | Comparer une métrique sur un jeu de test mis à part | | Évaluer sur des exemples faciles inventés | Plus rapide que d’échantillonner des entrées réelles | Construire un jeu représentatif avec des cas limites | | Aucune référence de comparaison | Personne n’a enregistré le score de la version A | Stocker la référence ; chaque changement lui est comparé | | Faire confiance à un juge LLM non validé | Le juge paraît faisant autorité | Valider le juge face à des labels humains sur un échantillon | | Ajuster le prompt au hasard après un échec | Plus rapide que l’analyse | Regrouper les échecs, corriger la plus grande cause, remesurer | | N’exécuter que des évaluations offline | La CI semble suffisante | Ajouter des évaluations online pour attraper la dérive réelle | | Tester un exemple et généraliser | Le cas visible est convaincant | L’exemple unique est là où se cachent les régressions | | Traiter les évaluations comme obsolètes parce que « legacy » | La documentation les a regroupées | La pratique est centrale ; utiliser l’Evals API en connaissance de cause | ## Défi de mise en situation **Mise en situation.** Votre assistant de politique basé sur le RAG répond aux questions RH. Un collègue édite le prompt système pour corriger une plainte sur des réponses trop verbeuses, essaie trois questions qui paraissent désormais plus resserrées, et veut déployer. Vous avez une évaluation de 240 questions réelles avec réponses de référence et un juge de fidélité, plus une référence de 91 % fidèle / 88 % complet. **Trace de raisonnement d’expert.** 1. **Rejeter « trois questions avaient l’air bien ».** Trois cas triés sur le volet ne sont pas une preuve ; le changement a pu améliorer la brièveté au détriment de la complétude sur les questions que personne n’a vérifiées. 2. **Exécuter l’évaluation complète face à la référence.** Supposons que la fidélité tient à 91 % mais que la complétude tombe à 79 %. C’est une régression : le prompt plus court omet désormais des détails requis. Sans la comparaison sur le jeu de données, cela est livré silencieusement. 3. **Faire une analyse des échecs, pas un autre ajustement de prompt.** Extraire les items nouvellement en échec. S’ils se regroupent sur les questions en plusieurs parties (« quelle est la politique et comment faire appel ? »), la cause est le prompt qui rogne les parties secondaires, pas la verbosité en général. 4. **Changer une chose.** Ajuster le prompt pour conserver la complétude sur les questions en plusieurs parties tout en rognant le remplissage, puis relancer. Confirmer que la complétude remonte vers la référence sans nuire à la fidélité. 5. **Considérer aussi l’online.** Même une évaluation offline réussie n’aura pas toutes les formulations réelles ; ajouter un échantillon de fidélité online pour que la dérive remonte après le lancement. 6. **Utiliser l’optimizer avec soin.** Le prompt optimizer pourrait proposer une formulation, mais seulement parce que vous avez désormais un jeu de données représentatif et un grader validé face auxquels il peut optimiser. **Décision conforme à l’examen :** exécuter l’évaluation complète face à la référence, attraper la régression de complétude, regrouper les échecs, corriger la plus grande cause, remesurer, et ajouter un échantillon online. **Pas** déployer sur trois réponses séduisantes, **pas** continuer d’ajuster la formulation sans mesurer. ## Pièges d’évaluation | Piège | Pourquoi il est tentant | Le discriminant | | --- | --- | --- | | « Il a géré mon exemple difficile, on livre » | Le cas visible est convaincant | Un exemple cache les régressions ; comparer le jeu complet | | « Les nouvelles réponses se lisent mieux, on déploie » | La fluidité fait figure de qualité | Une métrique sur un jeu représentatif est la preuve | | « Le juge LLM a dit 5/5, donc c’est juste » | Les juges paraissent faisant autorité | Valider le juge face à des labels humains d’abord | | « L’évaluation offline a passé, on a fini » | Le gating CI semble complet | Les évaluations online attrapent les entrées absentes du jeu | | « Les évaluations sont legacy, on saute » | La documentation les a regroupées | La pratique est centrale ; l’utiliser délibérément | | « Ajuster le prompt jusqu’à ce que les échecs baissent » | Ça donne l’impression d’avancer | Regrouper les échecs et corriger la cause, puis remesurer | ## Questions d’entraînement Chaque item indique combien de réponses sélectionner. Engagez-vous avant de révéler. A. Déployer ; deux bons exemples suffisent. B. Exécuter l’évaluation complète sur un jeu de données représentatif et comparer le score à la référence. C. Demander au modèle si le nouveau prompt est meilleur. D. Augmenter le reasoning effort. **Réponse : B.** Seule une comparaison sur le jeu de données face à la référence montre si le changement aide globalement. Deux exemples (A) cachent les régressions, demander au modèle (C) n’est pas une preuve, et augmenter l’effort (D) est sans rapport avec la validation du changement. A. Dix exemples faciles écrits à la main. B. Un échantillon représentatif de tickets réels incluant les catégories rares et les cas ambigus, labellisé par des SME. C. Uniquement les tickets que le modèle a déjà justes. D. Des tickets synthétiques générés par le même modèle. **Réponse : B.** Un jeu représentatif, couvrant les cas limites et labellisé par des SME reflète la performance réelle. Les exemples faciles inventés (A) et les tickets générés par le modèle (D) sont non représentatifs, et évaluer uniquement sur les réussites (C) est circulaire. A. LLM-as-judge avec une grille subjective. B. Correspondance exacte / basée sur le code face aux valeurs de champs labellisées. C. Revue humaine de chaque facture. D. Signaux de pouce levé des utilisateurs. **Réponse : B.** L’extraction de champs déterministe a une vérité terrain, donc la correspondance exacte/par code est précise et bon marché. Un juge LLM (A) ajoute du bruit pour un contrôle déterministe, la revue humaine par facture (C) ne passe pas à l’échelle, et le pouce levé (D) n’est pas une vérité terrain au niveau du champ. A. L’offline utilise un jeu de données curé et figé avant de livrer ; l’online échantillonne le trafic de production en direct après. B. L’offline est pour les petites équipes et l’online pour les grandes. C. Ce sont la même chose sous des noms différents. D. Les évaluations online remplacent le besoin d’évaluations offline. **Réponse : A.** Les évaluations offline gèrent la gate des releases sur un jeu figé ; les évaluations online gradent le trafic réel pour attraper la dérive. Elles sont complémentaires (contredisant C et D), et la distinction porte sur le moment et les données, pas la taille de l’équipe (B). A. Rien ; le modèle fait autorité. B. Valider le juge face à des labels humains sur un échantillon et affiner la grille jusqu’à ce qu’ils s’accordent. C. Utiliser comme juge le même modèle qui a produit les résumés, sans grille. D. Ne lui faire confiance que s’il utilise `gpt-6-astra`. **Réponse : B.** Un juge LLM doit être calibré face à des labels humains avec une grille explicite, sinon il ne fait que déplacer le problème de confiance. Il ne fait pas automatiquement autorité (A), l’auto-grading sans grille (C) est faible, et la taille du modèle seule (D) ne le valide pas. A. Lire les items en échec à entrées longues et former une hypothèse sur la cause. B. Changer une chose qui traite le cluster, puis relancer l’évaluation. C. Revenir en arrière et ne jamais mettre à niveau aucun modèle. D. Reformuler le prompt au hasard jusqu’à ce que le score remonte. E. L’ignorer parce que la moyenne est encore acceptable. **Réponse : A et B.** L’analyse des échecs signifie regrouper, hypothéser, changer une chose et remesurer. Ne jamais mettre à niveau (C) est une réaction excessive, la reformulation au hasard (D) risque de nouvelles régressions, et ignorer un cluster (E) laisse un vrai mode de défaillance en production. A. Pour montrer un joli graphique à la direction, uniquement. B. Pour que chaque changement de prompt, de modèle ou de dépendance puisse lui être comparé et que les régressions soient attrapées avant de livrer. C. Parce que l’API l’exige. D. Pour éviter d’avoir à écrire des graders. **Réponse : B.** Une référence est le repère face auquel chaque changement est mesuré, ce qui est la façon dont les régressions sont détectées. Les graphiques (A) sont un effet secondaire, l’API ne l’exige pas (C), et cela ne remplace pas les graders (D). A. Comme la surface la plus récente et recommandée pour tout travail nouveau. B. Comme l’Evals API désormais regroupée sous les Legacy APIs, tandis que la pratique de l’évaluation reste centrale. C. Comme entièrement retirée et indisponible. D. Comme identique à la Responses API. **Réponse : B.** La documentation a regroupé Evals (avec fine-tuning, Agent Builder, Assistants) sous les Legacy APIs, pourtant l’évaluation reste une pratique essentielle. Ce n’est ni la surface la plus récente (A), ni retirée (C), ni la même que Responses (D). A. Un modèle plus grand. B. L’évaluation online échantillonnant le trafic en direct pour attraper les entrées absentes du jeu offline. C. Un reasoning effort plus élevé. D. Davantage de prompt engineering. **Réponse : B.** Les évaluations offline ne peuvent pas couvrir des entrées qu’elles n’ont jamais contenues ; les évaluations online échantillonnent le trafic réel pour les faire remonter. Un modèle plus grand (A), plus d’effort (C) ou plus de travail de prompt (D) ne traitent pas la boucle de retour manquante. A. De rien ; il améliore les prompts à l’aveugle. B. D’un jeu de données d’évaluation représentatif et d’un grader, parce qu’il optimise le prompt face à votre métrique. C. D’un abonnement `gpt-6-astra` uniquement. D. Que vous désactiviez toutes les autres évaluations. **Réponse : B.** L’optimizer ajuste un prompt face à une métrique, il a donc besoin d’un jeu de données et d’un grader pour mesurer. Il n’est pas aveugle (A), ne dépend pas d’un palier de modèle spécifique (C), et n’exige pas de désactiver les évaluations (D) — il les utilise. A. Livrer immédiatement ; la plainte est résolue. B. Construire un petit jeu de données représentatif avec des références, établir une référence avec l’ancien prompt, puis comparer le nouveau prompt. C. Demander à trois collègues si ça a l’air mieux. D. Augmenter le max output tokens. **Réponse : B.** Sans jeu de données vous ne pouvez pas détecter les régressions, alors construisez-en un et établissez une référence avant de comparer. Livrer sur un seul correctif (A) risque une casse silencieuse, les opinions (C) ne sont pas une mesure, et les tokens de sortie (D) sont hors sujet. A. Pour calibrer et valider un grader LLM-as-judge sur un échantillon. B. Pour grader les sorties à plus fort enjeu où les erreurs sont coûteuses. C. Pour remplacer entièrement le jeu de données par des opinions. D. Pour ralentir l’évaluation exprès. E. Parce que les graders automatisés ne peuvent jamais être crus pour quoi que ce soit. **Réponse : A et B.** Les humains calibrent les juges et gradent les items à fort enjeu où le coût de l’erreur justifie l’effort. Remplacer le jeu de données par des opinions (C) retire la rigueur, ralentir exprès (D) est inutile, et les graders automatisés sont dignes de confiance pour de nombreux contrôles déterministes (E). A. Le modèle est cassé. B. Le jeu de données est trop petit pour donner un signal stable et significatif ; l’agrandir à une taille représentative. C. Le reasoning effort est trop bas. D. Le grader devrait être uniquement humain. **Réponse : B.** Un jeu minuscule est bruité, donc de petits changements font varier le score ; un jeu représentatif (souvent 100–500) le stabilise. Le modèle va probablement bien (A), l’effort (C) ne corrige pas le bruit d’échantillonnage, et passer aux humains (D) ne traite pas la taille. A. Une seule fois, tout au début du projet. B. Chaque fois que le prompt, le modèle ou la source de récupération change, et périodiquement en online. C. Jamais ; la récupération est déterministe. D. Uniquement quand un utilisateur se plaint. **Réponse : B.** Tout changement de prompt, modèle ou récupération peut altérer l’ancrage, alors relancez l’évaluation à chacun et échantillonnez en online. Une exécution unique (A) ignore la dérive, la récupération n’est pas totalement déterministe dans son effet d’ancrage (C), et attendre les plaintes (D) est réactif et tardif. ## Points clés à retenir - Une évaluation est un jeu de données représentatif plus un grader plus une métrique — elle transforme « a l’air mieux » en un nombre comparable. - Construisez le jeu de données à partir d’entrées réelles et incluez délibérément les cas limites et adversariaux. - Adaptez le grader à la tâche : exact/code pour les contrôles déterministes, un juge LLM validé pour la qualité ouverte. - Exécutez des évaluations offline pour gérer la gate des releases et des évaluations online pour attraper la dérive réelle. - Gardez une référence et relancez à chaque changement de prompt, de modèle, d’effort ou de récupération pour attraper les régressions. - Faites l’analyse des échecs en regroupant, en corrigeant la plus grande cause et en remesurant — pas par des ajustements au hasard. - L’Evals API est désormais regroupée avec les Legacy APIs, mais l’évaluation reste une pratique centrale ; le prompt optimizer a besoin d’un bon jeu de données et d’un grader.