Le stack d'évaluation LLM : comment mesurer réellement votre fonctionnalité IA

La compétence pour laquelle personne n'a été formé

Toutes les équipes livrent des fonctionnalités LLM. Presque aucune équipe ne dispose d'un véritable moyen de savoir si ces fonctionnalités sont bonnes.

Le cohort AI Evals For Engineers & PMs de Hamel Husain et Shreya Shankar a formé plus de 2 000 praticiens, dont des ingénieurs et des chefs de produit d'OpenAI et d'Anthropic. La raison pour laquelle il s'est rempli n'est pas théorique. C'est que les personnes qui construisent ce type de produit ont réalisé que leur processus de QA se résumait à « demander à l'ingénieur prompt de lire 30 sorties et de se fier à son intuition ».

Hamel appelle cela une « vibes eval ». C'est la pratique dominante, et c'est la raison pour laquelle tant de fonctionnalités IA sont livrées, font bonne impression en démo, puis se dégradent en silence. Sur le podcast de Lenny's Newsletter, Hamel et Shreya ont soutenu que les évaluations sont désormais la compétence la plus levier dans le travail de produit IA, plus importante que l'art du prompt, plus importante que le choix du bon modèle. La raison est structurelle. Si vous ne pouvez pas mesurer la qualité, vous ne pouvez pas l'améliorer.

La plupart des équipes le savent. Elles ne le font toujours pas. Pourquoi ? Parce que les évaluations ressemblent à du travail d'infrastructure, n'ont pas de propriétaire clair, et la première version semble toujours pire que de lire les sorties à la main. L'astuce consiste à réaliser que « lire les sorties à la main » est l'évaluation. La discipline est de le faire une fois, d'écrire ce que vous avez vu et de ne plus jamais le refaire de la même manière.

Cet article est le playbook. Il est volontairement indépendant des outils. Vous pouvez exécuter ce stack avec Inspect AI du UK AI Safety Institute, Phoenix d'Arize, Promptfoo, Langfuse, le framework OpenAI Evals, l'outillage d'évaluation d'Anthropic, ou une pile de scripts Python et un Google Sheet. C'est la méthodologie qui porte le poids.

Pourquoi « ça a l'air bien » cesse de fonctionner à grande échelle

La première fois que vous livrez une fonctionnalité LLM, « ça a l'air bien » est une barre acceptable. Vous avez écrit le prompt, testé dix entrées, les sorties semblent raisonnables, vous appuyez sur deploy.

La deuxième fois, vous êtes en difficulté.

Les sorties LLM sont non déterministes par conception. Une température à 0 réduit la variance mais ne l'élimine pas. Le même prompt avec le même modèle peut produire des réponses subtilement différentes d'une exécution à l'autre et nettement différentes d'une version de modèle à l'autre. Ajoutez ensuite ce qui change sous vos pieds :

Dérive de modèle. Les fournisseurs mettent à jour les modèles en conservant le même nom. Le GPT-4o d'aujourd'hui n'est pas le GPT-4o d'il y a trois mois. Même chaîne dans votre config, comportement différent. Vous ne recevrez pas de notification.
Décalage de distribution. Les entrées qu'envoient les vrais utilisateurs ne sont pas celles avec lesquelles vous avez testé. Prompts plus courts, langues différentes, mises en forme étranges, pièces jointes. La longue traîne est l'endroit où les évaluations comptent le plus.
Entropie de prompt. Chaque fois que quelqu'un modifie le system prompt pour corriger la plainte d'un utilisateur, vous risquez d'en casser trois autres dont vous aviez oublié l'existence. Sans évaluations, c'est invisible jusqu'à ce que les tickets de support explosent.
Dérive de la récupération. Si vous utilisez un RAG, votre index change constamment. La portion retrieval de votre pipeline se dégrade en silence.

La taxe cachée, c'est le temps de votre équipe. Chaque changement devient une demi-journée pendant laquelle quelqu'un clique sur des prompts. Chaque mise à jour de modèle devient un exercice « laissez-moi vérifier deux ou trois choses » qui prend une semaine. Chaque escalade devient une enquête ponctuelle parce que personne ne peut répondre à « est-ce une régression, ou cela a-t-il toujours été cassé pour les requêtes de ce type ? »

Les vraies évaluations rendent ces questions peu coûteuses à traiter. Le coût est en amont. Les économies se cumulent.

L'anatomie d'un stack d'évaluation LLM

Il y a cinq couches. Elles s'appuient les unes sur les autres. Sauter une couche signifie que celles au-dessus notent du bruit.

Couche	Objectif	Exemples d'outils	Pièges
1. Traces	Capturer chaque entrée, sortie, appel d'outil, ensemble de récupération, latence et coût des exécutions en production	Langfuse, Phoenix, exporteurs OpenTelemetry	Échantillonnage trop agressif ; charges utiles d'appels d'outils manquantes ; PII dans les logs
2. Analyse d'erreurs	Open-coder 50 à 100 traces réelles, regrouper les modes de défaillance, bâtir une taxonomie d'erreurs	Notion, Airtable, un CSV	Sauter cette étape ; une seule personne le fait seule sans calibration
3. Jeu de données de référence	50 à 100 exemples étiquetés à la main couvrant chaque mode de défaillance et le happy path	Format de dataset Inspect AI, JSONL, votre propre schéma	Données purement synthétiques ; aucune couverture des modes de défaillance trouvés à l'étape 2
4. LLM-as-judge	Un modèle de scoring avec un barème, validé contre des étiquettes humaines à >=85 % d'accord	OpenAI Evals, Promptfoo, Inspect AI, custom	Utiliser un juge que vous n'avez jamais validé ; scoring à juge unique ; dérive du barème
5. Intégration CI	Exécuter l'évaluation à chaque PR, bloquer les fusions en cas de régression, alerter en cas de dégradation	GitHub Actions, GitLab CI, runners personnalisés	Exécution trop lente ; pas de plafond de coût ; flambée du prix du modèle juge

L'ordre importe. Vous ne pouvez pas construire un jeu de données de référence sans d'abord découvrir quels modes de défaillance existent (analyse d'erreurs), et vous ne pouvez pas faire d'analyse d'erreurs sans traces. Vous ne pouvez pas valider un juge sans un golden set étiqueté. Vous ne pouvez pas exécuter le pipeline en CI tant que le juge n'est pas réellement digne de confiance.

Le récapitulatif étape par étape du curriculum de Hamel et Shreya d'Aakash Gupta parcourt le même squelette avec des noms légèrement différents, et c'est ce qui ressemble le plus à un consensus dans le domaine. Nous allons procéder couche par couche.

Étape 1 : capturer les traces

Une trace est l'enregistrement complet d'une interaction LLM. Pas seulement l'entrée et la sortie, mais tout ce que le système a fait entre les deux.

Une trace utile contient :

L'historique complet des messages (system prompt, tours utilisateur, tours assistant)
Le nom et la version exacts du modèle tels qu'appelés
Tous les appels d'outils, leurs arguments et leurs réponses
Pour le RAG : la requête de récupération, les documents renvoyés, les scores, les documents réellement utilisés dans le prompt final
Le nombre de tokens, la latence ventilée par étape et le coût en dollars
Un request ID que vous pouvez relier à la session utilisateur
Tout signal de feedback (pouce levé, copier, regénérer, abandonné)

Le principe : la trace est la source de vérité. Si vous ne pouvez pas reconstruire exactement ce que le modèle a vu et fait à partir de la seule trace, votre évaluation est en aval de la devinette.

En matière d'échantillonnage, le compromis se joue entre volume et coût. Pour un produit à fort trafic, journalisez 100 % des traces mais ne conservez les charges utiles complètes que pour un échantillon (5 à 10 %), le reste étant réduit aux métadonnées. Journalisez 100 % des traces d'erreurs (échecs d'appels d'outils, timeouts, récupération à faible confiance, feedback négatif). Ce sont vos mines d'or.

Au sujet des PII : les traces contiendront des données utilisateur. Appliquez les mêmes règles de masquage et de rétention que pour tout autre log de production. La plupart des équipes hachent les IDs utilisateur, suppriment les emails et font tourner les logs sur un calendrier de 30 à 90 jours.

Si vous le faites vous-même, écrivez un petit wrapper autour de votre SDK LLM qui émet du JSON structuré vers votre pipeline de logs. Le format compte moins que la discipline de toujours journaliser.

Étape 2 : analyse d'erreurs (open coding)

C'est l'étape que tout le monde saute, et c'est celle qui fait fonctionner tout le reste.

La recherche de Shreya Shankar emprunte une technique à la recherche qualitative appelée open coding. Vous vous installez avec 50 à 100 traces réelles. Vous les lisez. Vous annotez ce qui ne va pas (ou ce qui va). Vous n'imposez pas de catégories à l'avance. Vous laissez les catégories émerger des données.

Concrètement :

Tirez 100 traces de la production. Mélangez des échantillons aléatoires avec des traces signalées par du feedback négatif, des erreurs ou une latence élevée.
Ouvrez un tableur. Colonnes : trace ID, résumé de l'entrée, résumé de la sortie, problème (texte libre), sévérité (1-3), tags (vides au départ).
Pour chaque trace, écrivez ce qui ne va pas en langage clair. Pas « mauvaise sortie ». Précis : « a halluciné un nom de fonction qui n'existe pas dans le code de l'utilisateur », ou « a répondu dans la mauvaise langue », ou « a refusé une requête bénigne ».
Après 20 à 30 traces, les mêmes problèmes reviennent. Commencez à les taguer. Des tags de deux mots suffisent.
Après les 100, regroupez les tags. Vous arriverez généralement à 5-15 modes de défaillance distincts plus « semble correct ».

C'est votre taxonomie d'erreurs. Hamel décrit ce moment dans ses Field Notes on LLM Evals comme l'instant où des préoccupations vagues deviennent des affirmations testables. « Le bot hallucine parfois » se transforme en « le bot hallucine des noms de fonctions dans 8 % des requêtes liées au code, surtout lorsque les noms de variables sont peu courants ». C'est quelque chose pour quoi vous pouvez écrire une évaluation.

Une seconde paire d'yeux compte. Faites coder les mêmes 30 traces indépendamment par quelqu'un d'autre. Là où vous êtes en désaccord, la taxonomie est floue et doit être affûtée. C'est la même vérification d'accord inter-annotateurs que vous appliquerez plus tard au juge LLM.

Étape 3 : construire un jeu de données de référence

Un jeu de données de référence est un ensemble fixe d'entrées, de comportements attendus et d'étiquettes par rapport auxquels votre pipeline est évalué. Considérez-le comme votre suite de tests de régression pour un LLM.

Taille : 50 à 100 exemples constituent un véritable point de départ. Pas 10 (trop bruyant). Pas 1 000 (trop coûteux, trop lent). Faites-le grandir à mesure que vous trouvez de nouveaux modes de défaillance, mais la première version doit être suffisamment petite pour qu'un humain puisse lire chaque exemple en un après-midi.

Couverture : chaque mode de défaillance issu de l'analyse d'erreurs a besoin d'au moins 5 à 10 exemples. Plus 20 à 30 exemples du happy path. Plus quelques cas limites (très long, très court, non anglais, adverse). L'article arXiv Constructing Domain-Specific Evaluation Sets for LLM-as-a-judge mérite d'être lu sur la stratégie de couverture.

Critères d'inclusion :

Des entrées d'utilisateurs réels plutôt que synthétiques. Le tout-synthétique est un piège connu : il tend à ressembler aux prompts que votre équipe écrirait, et non à ce que les utilisateurs envoient réellement.
Chaque exemple a un résultat attendu étiqueté. Pour la génération ouverte, c'est un barème (doit X, ne doit pas Y, idéalement Z), pas une chaîne attendue littérale.
Chaque exemple est tagué avec un ou plusieurs modes de défaillance.
Les données sensibles sont nettoyées.

Barème d'étiquetage : écrivez à quoi ressemble « bon ». Pour certaines tâches, exact-match (a-t-il appelé la bonne API). Pour la plupart, c'est un barème de propriétés : « doit citer au moins un document récupéré », « ne doit pas refuser », « doit être dans la langue de l'utilisateur », « ne doit pas inventer de noms de fonctions ». Chaque propriété est une vérification binaire.

Cadence de rafraîchissement : une fois par trimestre, tirez un nouveau lot de 50 à 100 traces de production et reprenez l'open coding. De nouveaux modes de défaillance s'ajoutent. Les anciens qui ne se produisent plus restent (vous voulez une couverture de régression). Lorsque le modèle ou le prompt change de manière significative, faites un rafraîchissement hors cycle.

Le piège à éviter : ne laissez pas l'équipe qui écrit le prompt rédiger seule le jeu de données de référence. Il surapprendra les forces du prompt. Faites étiqueter au moins la moitié des exemples par quelqu'un en dehors du travail quotidien sur le prompt.

Étape 4 : LLM-as-judge avec validation humaine

Pour les tâches sans réponse unique correcte (résumé, classification avec catégories floues, Q&R ouvertes), vous avez besoin d'un moyen de scorer les sorties à grande échelle. Le scoring manuel ne tourne pas à chaque PR.

Le LLM-as-judge est la technique : utiliser un appel LLM séparé pour scorer la sortie de votre pipeline contre le barème. Ça fonctionne. L'analyse des méthodes LLM-as-judge de Confident AI rapporte que l'accord juge-humain a dépassé 85 % sur plusieurs benchmarks en 2025-2026, soit à peu près le niveau d'accord que deux humains présentent entre eux sur des tâches subjectives. Ce n'est pas parfait, mais c'est suffisamment bon pour être utile, à condition de le valider.

La méthodologie, dans l'ordre :

Écrivez un barème pour le juge. Pas « cette réponse est-elle bonne ». Précis : « La réponse cite-t-elle au moins l'un des documents fournis ? O/N. La réponse refuse-t-elle quand elle ne le devrait pas ? O/N. La réponse invente-t-elle des noms de fonctions absents du code de l'utilisateur ? O/N. » Binaire ou Likert court. Les juges sont mauvais sur les échelles de 1 à 10.
Choisissez un modèle juge. Un modèle généraliste fort (de classe GPT-4 ou Claude Sonnet/Opus) surpasse généralement les petits modèles, mais pour des évaluations à fort volume, un juge moins cher convient si vous le validez.
Étiquetez votre golden set à la main. Deux humains, indépendamment. Calculez l'accord inter-annotateurs (kappa de Cohen ou simple pourcentage d'accord sur un binaire). Si les humains ne s'accordent pas au-dessus de 80-85 %, votre barème est trop flou. Affûtez-le.
Faites tourner le juge sur le même ensemble. Comparez les étiquettes du juge aux étiquettes humaines. Si l'accord juge-humain est inférieur à 80 %, votre prompt de barème pour le juge est erroné, ou le modèle juge est trop faible. Itérez sur le prompt du juge.
Mettez le juge en production uniquement quand l'accord est à 85 % ou plus. En dessous, vous automatisez du bruit.

Erreurs courantes :

Utiliser un appel juge unique sans validation. L'accord peut être de 60 %. Vous ne le sauriez jamais.
Utiliser le même modèle pour générer et juger. Il existe un biais de self-preference connu. Utilisez une famille de modèles différente pour le juge quand c'est possible.
Laisser le barème du juge dériver par rapport au barème humain. Ils doivent être le même prompt. Si vous en modifiez un, revalidez.
Utiliser un seul appel juge comme vérité terrain. Pour les évaluations à fort enjeu, exécutez le juge avec trois appels indépendants et prenez le vote majoritaire. Un désaccord entre appels juges est lui-même un signal.

Une fois validé, le juge peut scorer des milliers de sorties en quelques minutes pour quelques dollars. C'est la récompense. Vous passez de « on évalue avant chaque release » à « on évalue à chaque PR ».

Étape 5 : intégrer le pipeline dans la CI/CD

Tout l'intérêt de ce stack est que personne n'a à se souvenir de lancer les évaluations. La CI le fait.

Une forme exploitable :

À chaque PR touchant les prompts, les configs de modèle ou le code du pipeline : exécutez l'évaluation golden. Bloquez la fusion si une métrique chute de plus d'un seuil (disons 3 points de pourcentage en accuracy, ou toute régression sur une vérification stricte comme « ne doit pas refuser les requêtes bénignes »).
À chaque montée de version de modèle : exécutez l'évaluation complète sur une infra équivalente à la production. Comparez côte à côte.
Sur un planning nocturne : exécutez l'évaluation sur un échantillon de traces de production fraîches. Cela attrape le décalage de distribution que le golden set statique manque.
Plafonds de coût : capez le budget d'évaluation par PR. Une valeur par défaut sensée est de 1 à 5 $ par exécution. Si votre évaluation coûte plus, échantillonnez le golden set ou utilisez un juge moins cher pour les évaluations en PR et le juge complet pour les releases.

Un pattern qui fonctionne : une « fast eval » de 20 à 30 exemples à chaque commit (moins de 2 minutes) et une « full eval » de 100 à 300 exemples à l'approbation de la PR et sur main. Même pipeline, tailles d'échantillon différentes.

Le reporting compte. Le commentaire de PR doit afficher le taux de réussite global, le taux de réussite par mode de défaillance, le diff par rapport à main et des liens vers les traces ayant échoué. N'enterrez pas cela dans un fichier de log.

Alertez sur la dérive de baseline. Si le taux de réussite nocturne chute de 5 points et y reste pendant deux jours, quelque chose a changé (mise à jour de modèle, changement d'index de récupération, service en aval). L'évaluation est aussi votre couche de monitoring.

Les anti-patterns que les builders continuent de livrer

Quelques patterns à surveiller, car ils continuent d'apparaître dans les vraies équipes :

Des vibes evals livrées en prod. Un ingénieur regarde 20 sorties, dit « livrez ça », et la fonctionnalité passe en production. Trois semaines plus tard, personne ne peut répondre à « est-ce mieux que la semaine dernière ».

Scoring avec un seul juge non validé. Quelqu'un lit un article sur le LLM-as-judge, écrit un prompt d'une ligne (« notez ceci de 1 à 10 »), et commence à prendre des décisions sur les scores. Les scores sont du bruit.

Aucune taxonomie d'erreurs. L'équipe a sauté l'open coding. Le golden set a été écrit de tête. Il surapprend sur les cas évidents et rate chaque mode de défaillance intéressant que les utilisateurs réels rencontrent.

Aucune vérification d'accord humain. Quand deux humains ne se sont pas accordés sur les étiquettes, « l'accord » du juge avec l'un d'eux ne veut rien dire.

Données synthétiques uniquement. Le golden set est généré par un autre LLM. Ça a l'air super. Ça passe toutes les évaluations. La production casse parce que les entrées utilisateur réelles ne ressemblent pas aux entrées générées par un LLM.

Un seul chiffre résumant tout. « Notre score d'évaluation est de 87 % ». Sur quoi ? Sur quels modes de défaillance ? Des taux de réussite par mode de défaillance sont nécessaires. Un agrégat cache les échecs qui comptent.

L'évaluation comme arrière-pensée. Traitée comme un exercice trimestriel plutôt qu'un pipeline continu. Devient obsolète en un cycle de release. Personne ne lui fait confiance.

Le plan d'évaluation en 7 jours pour une équipe sans évaluations

Si vous partez de zéro, voici une semaine qui vous mène à un pipeline fonctionnel.

Jour 1 : capturer les traces. Choisissez une fonctionnalité LLM. Ajoutez un logging qui capture l'entrée, la sortie, les appels d'outils, le contexte de récupération s'il y en a, la version du modèle et un request ID. Redirigez vers l'endroit où vivent vos logs. Ne choisissez pas encore d'outil ; un fichier JSONL fait l'affaire pour la première semaine. Objectif en fin de journée : plus de 100 traces issues de la production.

Jour 2 : open coding, premier tour. Tirez 50 traces. Une personne les lit. Annotation en texte libre de ce qui ne va pas ou de ce qui va. Pas encore de catégorisation. Juste décrire.

Jour 3 : open coding, deuxième tour. Une seconde personne fait les mêmes 50. Comparez les notes. Construisez la taxonomie des modes de défaillance à partir des patterns. Visez 5 à 12 modes de défaillance nommés. Estimez une fréquence approximative pour chacun.

Jour 4 : jeu de données de référence v0. Prenez 50 à 80 exemples qui couvrent chaque mode de défaillance plus le happy path. Étiquetez chacun avec un barème : ce qui doit être vrai d'une bonne réponse. Stockez en JSONL ou dans un tableur, peu importe, mais stockez-le dans le contrôle de version.

Jour 5 : construire le juge. Écrivez un prompt de juge qui score chaque propriété du barème en binaire. Choisissez un modèle juge d'une famille différente de votre modèle de production. Faites-le tourner sur le golden set.

Jour 6 : valider le juge. Faites étiqueter le même golden set par deux humains contre le même barème. Calculez l'accord humain-humain et l'accord juge-humain. Si l'accord juge-humain est inférieur à 80 %, itérez sur le prompt du juge. Arrêtez-vous lorsque vous atteignez 85 % ou à l'épuisement du jour six. Si vous n'arrivez pas à 85 %, le barème est le problème. Affûtez les questions binaires.

Jour 7 : câbler la CI. Une GitHub Action qui exécute l'évaluation sur les PRs touchant les prompts ou le code du pipeline. Sortez un commentaire avec le taux de réussite, la ventilation par mode de défaillance et des liens vers les traces ayant échoué. Définissez un budget. Définissez un seuil de régression.

Fin de semaine : vous avez des traces, une taxonomie, un golden set, un juge validé et une gate CI. L'intégralité du stack. C'est petit, et c'est le but. À partir de là, ça se cumule.

Après la première semaine, vous passerez l'essentiel de votre temps d'évaluation sur trois choses : faire grandir le golden set, affiner le barème à mesure que vous trouvez des ambiguïtés et enquêter sur les régressions attrapées par la CI. Rien de tout cela ne nécessite un autre gros chantier.

Questions fréquemment posées

Quelle est la différence entre une vibes eval et une vraie évaluation ?

Une vibes eval, c'est « j'ai lu 20 sorties et ça a l'air mieux ». Une vraie évaluation comporte : un ensemble d'entrées fixe, un barème écrit, un mécanisme de scoring qui ne dépend pas de qui se trouve à lire, et un moyen de comparer deux exécutions. Le test décisif le plus rapide : si vous ne pouvez pas répondre à « quel était le score d'évaluation la semaine dernière et cette semaine, et quels modes de défaillance ont régressé », vous n'avez pas de vraie évaluation.

Quelle taille doit avoir mon jeu de données de référence ?

50 à 100 exemples pour la première version. Assez grand pour couvrir chaque mode de défaillance avec 5 à 10 cas, assez petit pour qu'un humain puisse tout lire en un après-midi. Faites-le grandir au fil du temps à mesure que vous trouvez de nouveaux modes de défaillance en production. La plupart des pipelines matures se situent entre 200 et 500 exemples ; très peu gagnent à dépasser 1 000, sauf s'ils évaluent de nombreux cas d'usage distincts.

Le LLM-as-judge s'accorde-t-il vraiment avec les humains ?

Quand vous le validez, oui. La recherche de Confident AI rapporte un accord juge-humain supérieur à 85 % sur des barèmes validés en 2025-2026, soit à peu près le niveau auquel deux humains s'accordent entre eux. Le piège : cela ne tient que si vous avez d'abord calibré le juge contre des étiquettes humaines. Un prompt de juge copié depuis un tutoriel, jamais validé, n'est qu'une machine à opinions.

Ai-je besoin d'un outil d'évaluation spécialisé, ou puis-je faire le mien ?

Pour la première semaine, faites le vôtre. Des fichiers JSONL, un script Python, un tableur pour les étiquettes. Une fois que vous dépassez ce stade (généralement lorsque plusieurs personnes doivent étiqueter, ou que vous voulez une interface pour parcourir les traces), choisissez un outil. Inspect AI, Phoenix, Promptfoo, Langfuse et le framework OpenAI Evals couvrent tous la même forme de base avec des ergonomies différentes. La méthodologie est le moat, pas l'outil.

Quand devrais-je ré-étiqueter mon jeu de données de référence ?

Trimestriellement comme référence. Hors cycle quand vous changez de modèle, quand vous modifiez significativement le prompt, quand les tickets de support explosent avec un nouveau mode de défaillance, ou quand votre évaluation nocturne sur des traces de production fraîches montre que le golden set n'est plus représentatif.

En conclusion

Les équipes qui gagneront les deux prochaines années de travail produit IA ne sont pas celles qui ont les prompts les plus astucieux. Ce sont celles qui peuvent répondre, n'importe quel mardi, à « notre fonctionnalité IA est-elle meilleure aujourd'hui qu'il y a un mois, sur quelles dimensions et pour quels utilisateurs ». C'est une question d'évaluations, pas une question de prompt.

La méthodologie s'est stabilisée : traces, analyse d'erreurs, jeu de données de référence, juge validé, boucle CI. Cinq couches, chacune constructible en un jour ou deux par une petite équipe. L'écart entre les équipes qui disposent d'un stack d'évaluation et celles qui n'en ont pas se creuse vite.

Si vous avez livré une fonctionnalité LLM et que vous ne pouvez pas répondre à la question de régression avec confiance, votre tâche de la première semaine n'est pas un autre ajustement de prompt. C'est un fichier JSONL, cinquante traces et un tableur d'étiquettes. Le reste du stack en découle. Commencez petit, validez sans pitié, livrez le pipeline avant la prochaine fonctionnalité.