# D4 · Evaluation, Testing & Optimization Métriques d’évaluation, construction de jeux d’éval, conception du harnais, notation par rubrique et LLM-as-judge, tests A/B et significativité, évals offline vs online, suites de régression, diagnostic des défaillances, et le playbook d’optimisation coût/latence. import { Accordions, AccordionItem, Tabs, TabItem, Steps } from '@prosefly/astro-components'; Ce domaine pèse **16 % – environ 10 des 63 items**. Il teste si vous savez prouver qu’un système fonctionne et le maintenir en état : choisir les bonnes métriques, construire des jeux d’éval dignes de confiance, mener des tests LLM-as-judge et A/B calibrés, attraper les régressions en CI, diagnostiquer *quelle couche* a échoué, et optimiser coût et latence sans dégrader la qualité. Le jugement dominant : **mesurer par segment avec une évaluation indépendante**, jamais en agrégé seul ni en auto-déclaration. ## Objectifs d’apprentissage À la fin de cette page, vous devriez savoir : 1. Choisir les **métriques** d’évaluation (justesse, latence p50/p95, coût par tâche, sûreté, sécurité) par cas d’usage. 2. Construire des **jeux d’éval** : golden sets, données synthétiques, cas limites, couverture par segment. 3. Concevoir un **harnais de test** et une **notation par rubrique** ; exécuter le **LLM-as-judge** dans une session/un modèle séparé et le **calibrer**. 4. Mener des **tests A/B par paires** et raisonner sur la **significativité statistique**. 5. Distinguer les évals **offline vs online** et exécuter des **suites de régression en CI**. 6. **Diagnostiquer** l’échec de prompt vs l’hallucination vs le décalage de modèle vs l’échec de récupération. 7. Appliquer le **playbook d’optimisation coût/latence/token** et déployer les changements via **canary**. --- ## 4.1 Evaluation metrics Des cas d’usage différents ont des définitions différentes de « bon ». Un architecte choisit les métriques qui correspondent aux critères de réussite (D1). | Métrique | Définition | Quand elle domine | | --- | --- | --- | | Justesse / succès de tâche | Résultat correct vs vérité terrain ou rubrique | La plupart des tâches critiques pour la qualité | | Latence p50 / p95 | Temps de réponse médian / de queue | Systèmes interactifs/liés à un SLA (surveillez le **p95**, pas seulement le p50) | | Coût par tâche | \$ par unité de travail achevée | Systèmes à fort volume, sensibles au coût | | Sûreté | Taux de sorties nocives/violant la politique | Systèmes face à l’utilisateur, réglementés | | Sécurité | Résistance à l’injection de prompt/l’exfiltration | Agents utilisant des outils, entrées non fiables | :::tip[Signal d’examen] « La latence moyenne est bonne mais certains utilisateurs attendent 12 s » → vous êtes testé sur la **latence p95/de queue**, non la moyenne. « La justesse globale est de 92 % » alors qu’un segment échoue → la réponse est des **métriques par segment**, non l’agrégat (anti-patron n° 10). ::: --- ## 4.2 Building eval datasets Une éval ne vaut que son jeu de données. La couverture compte plus que la taille. | Élément du jeu | Objectif | Provenance | | --- | --- | --- | | Golden set | Entrées curées avec sorties attendues vérifiées | Étiquetées à la main par des SME ; la source de vérité | | Données synthétiques | Étendre la couverture à moindre coût ; explorer les entrées rares | Générées avec un modèle, puis un échantillon revu par un humain | | Cas limites | Solliciter la frontière de défaillance | Extraits des erreurs de production, entrées adverses | | Couverture par segment | Assurer que chaque type de doc / palier client / langue est représenté | Stratifier le jeu pour qu’aucun segment ne soit invisible | :::caution[Aveuglement à l’agrégat] Un golden set composé à 90 % d’un seul type de document reportera une justesse élevée pendant que le type à 10 % échoue silencieusement. **Stratifiez** le jeu de données et reportez les métriques par segment. ::: --- ## 4.3 Harness design and rubric grading Un **harnais de test** fait passer chaque entrée d’éval dans le système et note la sortie. Méthodes de notation, du moins cher au plus riche : | Méthode | À utiliser quand | Réserve | | --- | --- | --- | | Correspondance exacte / de chaîne / regex | Sorties déterministes (IDs, classifications, champs JSON) | Fragile pour le texte libre | | Notation par rubrique | Critères structurés (p. ex. justesse, complétude, ton chacun 0–2) | Nécessite une rubrique claire ; utilisez LLM-as-judge ou des humains pour l’appliquer | | LLM-as-judge | Qualité de texte libre à l’échelle | Doit utiliser un **modèle/session séparé** et être **calibré** | | Revue humaine | Enjeu le plus élevé, ambigu, ou référence de calibration | Lent/coûteux ; à utiliser comme étalon-or | Une rubrique transforme la qualité floue en dimensions vérifiables : ```text Criterion Weight Scale Correctness 0.5 0 wrong · 1 partial · 2 fully correct Grounding 0.3 0 unsupported · 1 partial · 2 fully cited Tone/format 0.2 0 off · 1 minor · 2 on-spec Score = Σ (weight × normalised criterion) ``` --- ## 4.4 LLM-as-judge and calibration Le LLM-as-judge met l’évaluation à l’échelle, mais seulement s’il est digne de confiance. - Utilisez un **modèle différent ou au moins une session neuve** que celui testé — l’auto-revue en même session porte le biais de raisonnement original (anti-patron n° 9). - **Calibrez** le juge contre un ensemble d’**étiquettes humaines** : mesurez l’accord (p. ex. justesse vs humain, corrélation). Si le juge est en désaccord avec les humains, corrigez la rubrique/le prompt avant de lui faire confiance à l’échelle. - Surveillez les biais du juge : biais de position (favorise la première option), biais de longueur (favorise les réponses plus longues), auto-préférence (favorise le style de sa propre famille). ```text human-labelled sample ──▶ run judge ──▶ compare │ │ └────── agreement ≥ threshold? ──── yes ─▶ trust judge at scale no ─▶ revise rubric/judge prompt, recalibrate ``` :::caution[Ne laissez jamais le modèle corriger sa propre copie en même session] Demander à la session productrice « est-ce correct ? » conserve le biais qui a produit la réponse. L’évaluation doit être indépendante. ::: --- ## 4.5 Pairwise A/B testing and statistical significance Pour comparer le prompt A vs le prompt B (ou le modèle A vs B), la comparaison **par paires** sur les mêmes entrées est plus sensible que la comparaison de moyennes séparées. 1. Exécutez les deux variantes sur les **mêmes** entrées d’éval (conception appariée). 2. Faites choisir le gagnant par item par un juge/humain indépendant (ou notez chacun). 3. Calculez le taux de victoire et testez si la différence est **statistiquement significative** — une victoire de 52 % sur 30 items est du bruit ; la même sur 2 000 items peut être réelle. Utilisez un test de significativité et reportez l’intervalle de confiance. 4. Ne promouvez le gagnant que si l’amélioration est significative **et** tient par segment (aucune régression sur aucun segment). :::tip[Signal d’examen] « Le prompt B a l’air un peu meilleur sur une poignée d’exemples » → la bonne réponse invoque la **significativité statistique / un échantillon plus grand**, non « livrer B parce qu’il a l’air meilleur ». L’appréciation à l’œil sur petit échantillon est un piège. ::: --- ## 4.6 Offline vs online evaluation | | Éval offline | Éval online | | --- | --- | --- | | Quand | Pré-release, en CI | En production, trafic réel | | Données | Golden/jeux synthétiques | Interactions utilisateur réelles | | Mesure | Justesse vs réponses connues, régressions | Résultats réels : déflexion, thumbs, complétion de tâche, coût | | Risque | Peut ne pas refléter la distribution de production | Expose les utilisateurs aux changements (atténuer avec le canary) | Vous avez besoin des **deux** : l’offline gate les releases ; l’online attrape la dérive de distribution que le golden set a manquée. ### Suites de régression en CI Chaque changement de prompt, de modèle ou de récupération doit exécuter la **suite de régression** avant promotion. Une suite de régression est le golden set accumulé plus chaque défaillance de production passée transformée en test. C’est ainsi que vous empêchez qu’un correctif pour un segment n’en casse un autre. ```text PR opened ─▶ CI runs regression suite (offline evals, per-segment) ├─ any segment regresses ─▶ block merge └─ all pass ─▶ allow ─▶ canary online ─▶ ramp ``` --- ## 4.7 Diagnostic des défaillances : quelle couche a cassé ? Quand une sortie est fausse, isolez la couche avant de « corriger » quoi que ce soit. Corriger la mauvaise couche est l’erreur la plus coûteuse de ce domaine. | Symptôme | Cause probable | Confirmer par | Corriger à | | --- | --- | --- | --- | | La réponse utilise des faits absents du contexte fourni | Hallucination / grounding faible | Vérifier la faithfulness contre les chunks récupérés | Instruction de grounding, citations | | Bons chunks récupérés, mauvaise forme/mauvais format de réponse | Échec de prompt | Inspecter le prompt vs la sortie ; tester le prompt isolément | Prompt/template | | Confiant-mais-faux après un changement de données | Récupération/indexation (périmée) | Journaliser les IDs des chunks récupérés | Ré-indexation / pipeline de fraîcheur (D3) | | Échoue seulement sur les cas les plus durs, correct ailleurs | Décalage de modèle (trop petit) | Relancer les échecs sur un modèle plus fort | Router/escalader le palier de modèle | | Échoue seulement sur un segment | Couverture / problème propre au segment | Métriques par segment | Correctif ciblé données/prompt/récupération | ```text Wrong output ─▶ Was the right context retrieved? ├─ No ─▶ retrieval/indexing failure (D3) └─ Yes ─▶ Is the answer unsupported by that context? ├─ Yes ─▶ hallucination / grounding └─ No ─▶ Is only the hardest tier failing? ├─ Yes ─▶ model mismatch (escalate tier) └─ No ─▶ prompt/format failure ``` --- ## 4.8 Le playbook d’optimisation coût / latence / token N’optimisez qu’après avoir pu mesurer (par segment) et sans régresser sous la barre de qualité. | Levier | Réduit | Arbitrage / réserve | | --- | --- | --- | | Prompt caching (préfixe stable d’abord) | Coût d’entrée, latence | Nécessite un préfixe stable ; minimum ~1024 tokens | | Batching (Message Batches API) | 50 % du coût | Jusqu’à 24 h de latence — seulement le travail tolérant à la latence | | Routage / cascades | Coût | Ajoute une étape de classification/validation | | Réduction de sortie / sorties structurées | Coût de sortie, latence | Ne pas supprimer du contenu nécessaire | | Réglage de l’effort (baisser là où c’est suffisant) | Tokens de thinking, latence | Trop bas nuit aux tâches difficiles | | Dimensionnement du modèle | Coût, latence | Re-valider la qualité sur le modèle plus petit | | Moins d’allers-retours d’outils / découverte progressive | Latence, tokens | Nécessite une discipline d’ensemble d’outils | ```text Cost too high? ─▶ cache stable prefix ─▶ route cheap-first ─▶ batch tolerant work ─▶ trim output Latency too high? ─▶ smaller/faster model ─▶ fast mode ─▶ fewer round-trips ─▶ lower effort ─▶ stream (after each change: re-run the regression suite per segment) ``` :::tip[Signal d’examen] Les réponses d’optimisation qui sautent la re-validation sont fausses. Chaque changement de coût/latence doit être **ré-évalué par segment** — un modèle moins cher ou un effort plus bas qui régresse silencieusement un segment est un échec, non une victoire. ::: --- ## 4.9 Canary rollouts of prompts and models Ne basculez jamais un changement de prompt ou de modèle à 100 % d’un coup. 1. Passez la suite de régression offline (par segment). 2. Déployez sur une **petite tranche canary** de trafic réel avec des métriques online et des garde-fous de rollback automatique. 3. Comparez canary vs contrôle sur les résultats réels et le coût ; montez en charge par pourcentage si tout est sain. 4. Gardez la version précédente déployable pour un rollback instantané. --- ## 4.10 Raisonnement de significativité A/B avec des chiffres L’examen ne vous demande pas de faire un test t à la main, mais il exige que vous sachiez **quand une différence est réelle**. L’intuition clé : un petit échantillon peut produire une grande victoire apparente par hasard. **Exemple chiffré — petit échantillon.** Le prompt B bat A sur **7 items appariés sur 12** (taux de victoire de 58 %). ```text Under the null (no difference), each item is a coin flip (p = 0.5). Getting ≥ 7 of 12 heads by pure chance is very common (~39% two-sided). → 7/12 is well within noise. Do NOT promote B. ``` **Exemple chiffré — grand échantillon.** Sur **2 000** items appariés, B gagne **1 080** (54 %). ```text Expected under null = 1,000; std dev ≈ sqrt(n·p·(1-p)) = sqrt(2000·0.25) ≈ 22.4 Observed excess = 1,080 − 1,000 = 80 wins → z ≈ 80 / 22.4 ≈ 3.6 z ≈ 3.6 ⇒ p < 0.001 → the 54% win is statistically significant. ``` Résultat de même direction (B meilleur), mais seul le grand échantillon soutient la promotion — et seulement s’il tient aussi **par segment** (aucun segment ne régresse). | Situation | Bonne action | | --- | --- | | Grande victoire, échantillon minuscule | Collecter plus de données ; ne pas promouvoir | | Petite victoire, énorme échantillon, significative, aucune régression de segment | Promouvoir via canary | | Significative au global mais un segment régresse | Ne **pas** promouvoir ; l’agrégat masque une régression | | Le juge n’est pas calibré | Corriger la calibration avant de faire confiance à tout résultat A/B | :::tip[Signal d’examen] Toute option qui dit « livrer B parce qu’il a gagné N sur une douzaine » est le piège. La bonne réponse invoque un **échantillon plus grand + significativité statistique + aucune régression par segment**. Les qualificatifs « MOST » et « FIRST » pointent généralement vers « rassembler un échantillon significatif » plutôt que « livrer maintenant ». ::: --- ## 4.11 An observability and eval-record schema Pour évaluer et déboguer à l’échelle, il vous faut un enregistrement cohérent par requête. Un schéma minimal : ```json { "correlation_id": "9f3a-...", "request_id": "req_01H...", "timestamp": "2026-09-15T11:02:33Z", "segment": { "tenant": "42", "language": "es", "ticket_type": "refund" }, "model": "claude-sonnet-5", "prompt_version": "support-agent@3.2.1", "retrieval": { "k": 50, "kept": 6, "chunk_ids": ["c_101","c_233"], "recall_at_k": 0.94 }, "usage": { "input_tokens": 6120, "output_tokens": 1440, "thinking_tokens": 300 }, "cost_usd": 0.0271, "latency_ms": { "ttft": 610, "total": 5230 }, "stop_reason": "end_turn", "eval": { "faithfulness": 0.9, "rubric_score": 1.7, "judge_model": "claude-opus-5" }, "outcome": { "human_override": false, "user_thumb": "up" } } ``` | Groupe de champs | Permet | | --- | --- | | `segment` | Métriques par segment (le contrôle anti-agrégat) | | `prompt_version` / `model` | Attribuer les régressions à un changement précis ; attribution A/B | | `retrieval` | Diagnostiquer récupération vs grounding ; suivi du recall@k | | `usage` / `cost_usd` | Dashboards de coût-par-tâche ; décisions de routage | | `latency_ms` | Suivi du SLA p50/p95 (suivez `total`, surveillez la queue) | | `eval` / `outcome` | Scores du juge offline vs signaux humains online | :::caution[Si ce n’est pas journalisé, vous ne pouvez pas l’évaluer] Les tags de segment, la version prompt/modèle, le détail de récupération et le coût par requête sont les champs le plus souvent absents — et leur absence est la raison pour laquelle les équipes ne peuvent reporter qu’un agrégat trompeur. Concevez le schéma avant le lancement. ::: --- ## 4.12 Scénario détaillé : promouvoir un changement de prompt en toute sécurité **Scénario.** Une équipe teste à la main un nouveau prompt de support sur 15 tickets favoris, voit des réponses « clairement meilleures », et veut livrer à 100 % demain. Le système sert des tickets en anglais et en espagnol et trois paliers de tenant. Le juge est la même session Sonnet 5 qui a généré les réponses. **Trace de raisonnement d’expert.** 1. **Rejeter l’échantillon et le juge.** 15 items triés sur le volet ne prouvent rien, et noter dans la session productrice porte son biais (anti-patron n° 9). Corrigez d’abord la méthode. 2. **Construire le jeu d’éval.** Utilisez un golden set **stratifié** couvrant les deux langues et les trois paliers, plus des cas limites extraits des défaillances de production. 3. **Juge indépendant et calibré.** Notez avec un **modèle/session séparé** (ou des humains), calibré contre des étiquettes humaines pour attraper le biais de longueur/de position. 4. **A/B apparié avec significativité.** Exécutez A vs B sur les mêmes entrées ; exigez une victoire **statistiquement significative** sur un échantillon assez grand, et confirmez **aucune régression par segment** (p. ex. l’espagnol ne doit pas chuter). 5. **Gater en CI, puis canary.** La suite de régression par segment doit passer ; puis canary sur une petite tranche réelle avec rollback avant de monter en charge. 6. **Garder la version antérieure à chaud** pour un rollback instantané. **Pourquoi les alternatives tentantes sont fausses :** « livrer parce que ça avait l’air meilleur sur 15 » est de l’appréciation à l’œil sur petit échantillon ; « faire confiance à l’auto-note en même session » est du biais de même session ; « basculer à 100 % pour rassembler le signal plus vite » retire le filet de sécurité ; « tester seulement l’anglais parce que c’est le gros du trafic » réintroduit l’aveuglement à l’agrégat qui a masqué la défaillance espagnole. --- ## 4.13 Common misconceptions | Idée reçue | Réalité | Pourquoi c’est important à l’examen | | --- | --- | --- | | « Une grande victoire sur quelques exemples signifie que B est meilleur. » | Les petits échantillons sont dominés par le bruit ; testez la significativité. | L’appréciation à l’œil sur petit échantillon est le piège A/B classique. | | « La justesse globale est la métrique qui compte. » | Les métriques par segment attrapent les défaillances que l’agrégat masque. | L’anti-patron n° 10 apparaît dans la plupart des items de D4. | | « La latence moyenne reflète l’expérience utilisateur. » | Les SLA interactifs vivent sur la queue p95/p99. | Les distracteurs moyenne-seule sont faux. | | « Le modèle peut noter sa propre réponse. » | L’auto-revue en même session porte le biais producteur. | Un juge indépendant et calibré est requis. | | « Le LLM-as-judge est objectif. » | Les juges ont des biais de longueur/position/auto-préférence ; calibrez. | Les énoncés de biais de longueur testent ceci. | | « Optimisez le coût, mesurez plus tard. » | Chaque changement de coût doit être re-validé par segment. | Sauter la ré-éval est une mauvaise réponse. | | « Corrigez le prompt quand la sortie est fausse. » | Diagnostiquez d’abord la couche défaillante (récupération/grounding/prompt/modèle). | Corriger la mauvaise couche est l’erreur coûteuse. | --- ## Pièges de l’examen dans ce domaine | Piège | Pourquoi c’est faux | | --- | --- | | Ne reporter que la justesse agrégée | Masque les défaillances par segment (anti-patron n° 10) | | Utiliser la latence moyenne comme métrique de SLA | Masque la queue ; utilisez le p95 | | LLM-as-judge dans la même session/le même modèle que le système | Biais d’auto-revue en même session (anti-patron n° 9) | | Faire confiance à un juge sans le calibrer contre des humains | Les biais du juge (position/longueur/auto-préférence) passent inaperçus | | « B a l’air meilleur sur 10 exemples, livrons-le » | Aucune significativité statistique ; bruit de petit échantillon | | Optimiser le coût sans relancer les évals | Peut régresser silencieusement un segment | | Corriger le prompt alors que la récupération était périmée | Mauvaise couche ; diagnostiquez avant de corriger | | Basculer un changement de modèle à 100 % d’un coup | Pas de canary ; pas de rollback sûr | | Golden set biaisé vers un seul segment | L’agrégat a l’air bon pendant qu’un segment échoue | | Batcher du trafic interactif sensible à la latence | 24 h de latence violent le SLA | | Promouvoir une variante qui gagne au global mais régresse un segment | L’agrégat masque la régression ; exigez l’absence de régression par segment | | Faire confiance à un résultat A/B d’un juge non calibré | Le biais du juge contamine la comparaison ; calibrez d’abord | | Omettre les champs segment/version/coût de l’enregistrement d’éval | Force un reporting agrégé-seul trompeur | | Confondre un grand taux de victoire sur un échantillon minuscule avec la significativité | Les petits échantillons sont du bruit ; calculez/estimez la significativité | | Ne suivre que la latence `total` sans TTFT pour l’UX en streaming | Le TTFT pilote la latence perçue dans les apps interactives | --- ## Questions d’entraînement A. De rien ; 92 % dépasse la cible. B. De métriques par segment qui ventilent la justesse par type de ticket, révélant la défaillance du segment remboursement que l’agrégat masque. C. D’un golden set plus grand du même mélange. D. D’un modèle à effort plus élevé pour tous les tickets. **Réponse : B.** La justesse agrégée masque une défaillance de segment (anti-patron n° 10). Des métriques stratifiées, par segment, exposent le problème de remboursement pour qu’il soit corrigé. L’agrégat (A) est trompeur ; un jeu au même mélange plus grand (C) le masque toujours ; escalader tous les tickets (D) surpaie sans diagnostiquer. A. Cela coûte trop cher. B. L’auto-revue en même session conserve le biais de raisonnement qui a produit la réponse ; le juge doit être un modèle/session séparé et calibré contre des humains. C. Le juge devrait toujours être un plus gros modèle. D. Le LLM-as-judge n’est jamais valable. **Réponse : B.** Noter dans la session productrice porte le biais original (anti-patron n° 9). L’indépendance plus la calibration humaine sont requises. Le coût (A) n’est pas l’enjeu central ; le juge n’a pas besoin d’être plus gros (C) ; le LLM-as-judge est valable quand il est indépendant et calibré (D). A. Livrer B ; il a gagné la comparaison. B. L’échantillon est bien trop petit pour être significatif ; exécutez un A/B apparié sur un jeu d’éval grand et par segment et testez la significativité statistique avant de promouvoir. C. Livrer A ; c’est le sortant. D. Faire la moyenne des deux prompts. **Réponse : B.** Un résultat 6/10 est du bruit ; la promotion exige un test apparié sur un échantillon représentatif avec significativité statistique et aucune régression par segment. Livrer sur de petits échantillons appréciés à l’œil (A), se replier sur le sortant (C), ou « faire la moyenne » des prompts (D) sont tous non fiables. A. La latence moyenne seule. B. La latence de queue (p95/p99), car la moyenne masque la queue lente que les utilisateurs vivent réellement. C. Le compte total de requêtes. D. Le compte de tokens seul. **Réponse : B.** Une moyenne saine avec un mauvais p95 signifie que la queue est le vrai problème ; les SLA des systèmes interactifs suivent p95/p99. La moyenne (A) le masque ; le compte de requêtes (C) et les tokens (D) ne sont pas des SLA de latence. A. Un biais de longueur chez le juge. B. Calibrer contre des étiquettes humaines et réviser la rubrique pour noter explicitement la justesse/le grounding, non la longueur. C. Le juge est parfaitement fiable. D. Toujours choisir la réponse la plus longue. E. Supprimer entièrement l’éval. **Réponse : A et B.** Le juge présente un biais de longueur ; le remède est la calibration contre des humains et une rubrique qui note les dimensions qui comptent. Le juge n’est pas fiable (C), récompenser la longueur (D) est le bug, et supprimer les évals (E) abandonne la mesure. A. Des vérifications manuelles ponctuelles après release. B. Une suite de régression par segment en CI qui bloque le merge si un segment régresse. C. Faire confiance au jugement de l’auteur. D. Ne tester que le segment qui a changé. **Réponse : B.** Une suite de régression par segment en CI est exactement la garde contre le fait de corriger un segment en en cassant un autre. Les vérifications manuelles (A) et la confiance en l’auteur (C) ne sont pas fiables ; ne tester que le segment changé (D) est ce qui a causé le risque. A. Récupération ; ré-indexer. B. Génération/grounding (hallucination) ; resserrer l’instruction de répondre uniquement à partir du contexte, ajouter des citations, et vérifier la faithfulness — la récupération va bien. C. Décalage de modèle ; utiliser Haiku. D. Infrastructure ; ajouter des retries. **Réponse : B.** Un rappel élevé signifie que le bon contexte était présent, donc un fait non soutenu est un échec de grounding/une hallucination à la génération. La ré-indexation (A) vise une couche saine ; un modèle plus petit (C) n’aidera pas ; les retries (D) sont sans rapport. A. Baisser l’effort à l’aveugle et livrer. B. Déplacer le job vers la Message Batches API (remise de 50 %, sous 24 h) et relancer la suite de régression par segment pour confirmer l’absence de régression de qualité. C. Basculer aussi tout le trafic interactif sur Haiku. D. Désactiver l’évaluation pour économiser du calcul. **Réponse : B.** Un job de masse tolérant à la latence est le cas d’usage de la Batch API ; chaque changement de coût est suivi d’une re-validation par segment. Les baisses d’effort à l’aveugle (A) risquent la qualité ; changer le trafic interactif (C) est hors périmètre ; désactiver les évals (D) retire le filet de sécurité. A. Échec de récupération ; tout re-chunker. B. Décalage de modèle — le palier est trop petit pour les cas les plus durs ; router/escalader ceux-ci vers un modèle plus fort (cascade) tout en gardant le modèle bon marché pour le reste. C. Échec de prompt ; réécrire tout le prompt. D. Infrastructure ; ajouter plus de répliques. **Réponse : B.** Une signature nette « échoue seulement sur les cas les plus durs » pointe vers la capacité du modèle ; une cascade escalade juste ces cas, préservant le coût ailleurs. Tout re-chunker (A) et réécrire le prompt (C) visent des couches qui fonctionnent sur les 95 % restants ; les répliques (D) n’affectent pas la justesse. A. Passer d’abord la suite de régression offline par segment. B. Canary sur une petite tranche réelle avec des métriques online et un rollback automatique, puis monter en charge. C. Basculer à 100 % immédiatement pour rassembler le signal plus vite. D. Laisser chaque équipe éditer le prompt sur place. E. Sauter les évals offline si le changement est petit. **Réponse : A et B.** Un déploiement sûr est gate de régression offline → canary avec rollback → montée en charge. Basculer à 100 % (C) retire le filet de sécurité ; les éditions sur place par équipe (D) détruisent la gouvernance ; sauter les évals offline pour les « petits » changements (E) est ainsi que les régressions passent. A. Le coût par tâche. B. La latence p95. C. La latence moyenne seule. D. Le total de tokens générés à travers la flotte. E. Le nombre de versions de prompt. **Réponse : A et B.** Sensible au coût + interactif → le coût par tâche et la latence p95 (de queue) sont les métriques contraignantes. La latence moyenne (C) masque la queue ; le total de tokens (D) et le compte de versions de prompt (E) ne sont pas des métriques de qualité/SLA face à l’utilisateur. A. Le jeu était trop petit. B. Le jeu manquait de couverture par segment (langue) ; stratifiez le golden set pour que chaque langue/segment soit représenté et reporté séparément. C. Le modèle est cassé. D. Les évals online sont inutiles. **Réponse : B.** Un jeu non stratifié rend tout un segment invisible aux évals offline. Stratifier par langue (et autres segments) avec un reporting par segment fait remonter l’écart. La taille (A) n’est pas l’enjeu ; le modèle n’est pas cassé (C) ; les évals online (D) restent nécessaires mais la cause racine ici est la couverture. A. Le test de 12 items, car les réponses avaient l’air clairement meilleures. B. Le résultat de 2 000 items : une victoire de 54 % à n=2 000 est à ~3,6 écarts-types du hasard (p < 0,001), donc statistiquement significative — à condition qu’aucun segment ne régresse. C. Aucun ; les tests A/B ne sont pas fiables. D. Faire la moyenne des deux taux de victoire. **Réponse : B.** À n=2 000 l’excédent de 80 victoires sur les 1 000 attendues est ≈3,6σ (écart-type ≈ 22,4), ce qui est significatif ; 7/12 est dans le bruit du pile ou face. Le petit test (A) est du bruit ; l’A/B est fiable à l’échelle (C) ; faire la moyenne des taux de victoire (D) n’a pas de sens. A. Le promouvoir ; la victoire globale est significative. B. Ne pas le promouvoir tel quel ; une régression par segment bloque la promotion même quand l’agrégat s’améliore — corrigez d’abord la régression espagnole. C. Promouvoir et surveiller les plaintes. D. Retirer l’espagnol du jeu d’éval. **Réponse : B.** L’absence de régression par segment est un gate ferme ; une victoire agrégée qui masque une régression de segment est l’anti-patron n° 10. Promouvoir quand même (A, C) livre une régression connue ; retirer l’espagnol (D) la re-masque. A. Des métriques GPU manquantes. B. Les enregistrements d’éval manquent d’un tag `segment` (et de la version prompt/modèle), donc les métriques ne peuvent être ni stratifiées ni attribuées. C. Le modèle juge est trop petit. D. La latence n’est pas journalisée. **Réponse : B.** Sans tags de segment ni champs de version, seul un agrégat est calculable et les régressions ne peuvent pas être attribuées. Les métriques GPU (A) sont sans rapport ; la taille du juge (C) ne crée pas l’écart de reporting ; la latence (D) est un signal différent. A. Un tag `segment` (tenant/langue/type). B. Les `prompt_version` et `model` utilisés. C. La température CPU du serveur. D. Un UUID aléatoire sans lien. E. Le nom de la campagne marketing. **Réponse : A et B.** Les tags de segment permettent des métriques stratifiées ; la version prompt/modèle permet d’attribuer les régressions et les résultats A/B à un changement précis. La température CPU (C), un UUID non lié (D), et un nom de campagne (E) ne soutiennent pas l’évaluation. A. Augmenter l’effort du modèle. B. Noter avec un juge indépendant et calibré (modèle/session séparé) sur un jeu stratifié, car l’auto-revue en même session porte le biais producteur. C. Livrer en canary immédiatement. D. Supprimer l’ancienne version de prompt. **Réponse : B.** La notation en même session est l’anti-patron n° 9 ; la méthode doit être corrigée avec un juge indépendant, calibré par des humains, avant toute décision de promotion. L’effort (A) ne corrige pas le biais ; le canary (C) est prématuré ; supprimer la version antérieure (D) retire le rollback. A. Le total de tokens générés. B. Le time-to-first-token (TTFT), car la latence perçue dans les UI de streaming est pilotée par la vitesse de démarrage de la sortie. C. Le compte quotidien de requêtes. D. Le nombre de versions de prompt. **Réponse : B.** Dans les UI de streaming, les utilisateurs perçoivent la réactivité par le moment où les tokens démarrent (TTFT), non par le temps total seul. Le total de tokens (A), le compte de requêtes (C) et le compte de versions (D) ne sont pas des métriques d’expérience de latence. ## À retenir - Choisissez des métriques qui correspondent aux critères de réussite : justesse, latence **p95** (non la moyenne), coût par tâche, sûreté, sécurité — et reportez-les **par segment**. - Construisez des jeux d’éval **stratifiés** (golden + synthétique + cas limites) pour qu’aucun segment ne soit invisible. - Utilisez la **notation par rubrique** et le **LLM-as-judge dans un modèle/session séparé**, et **calibrez** le juge contre des étiquettes humaines. - Comparez les variantes avec des **tests A/B appariés** et exigez la **significativité statistique** plus l’absence de régression par segment avant de promouvoir. - Exécutez les évals **offline** en CI comme gate de régression et les évals **online** pour attraper la dérive de distribution ; les deux sont nécessaires. - **Diagnostiquez la couche défaillante** (récupération vs grounding vs prompt vs modèle vs segment) avant de corriger quoi que ce soit. - Optimisez avec caching, batching, routage, réduction et réglage de l’effort — puis **re-validez par segment**. - Déployez via **canary** avec rollback automatique ; ne basculez jamais à 100 % d’un coup. - Jugez la **significativité, non les impressions** : une grande victoire sur 12 items est du bruit ; une petite victoire sur des milliers peut être réelle (z ≈ excédent ÷ √(n·p·(1−p))) — et elle doit tenir **par segment**. - Concevez le **schéma d’enregistrement d’éval** (segment, version prompt/modèle, récupération, usage, coût, latence, score du juge, résultat) avant le lancement — vous ne pouvez pas évaluer ce que vous n’avez pas journalisé. - Suivez le **TTFT** pour l’UX en streaming aux côtés de la latence totale p95 ; la vitesse perçue est pilotée par le temps du premier token.