D3 · Evaluating AI Applications

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

        ┌──────────────┐    ┌────────────┐    ┌──────────┐
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.

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.

3.3 Choisir un grader

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.

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

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.

3.6 Analyse des échecs

Quand le score baisse, n’ajustez pas au hasard. Regroupez les échecs et trouvez le motif.

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.

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

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

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Engagez-vous avant de révéler.

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.