9 min de lecture - Evaluation-driven development pour les apps LLM en production

Les applications LLM échouent différemment des logiciels traditionnels.

Elles passent les tests unitaires et se comportent malgré tout mal en production, car la qualité y est floue, les entrées sont désordonnées, et de petits changements de prompt ou de modèle peuvent faire varier les résultats.

C'est pourquoi l'evaluation-driven development (EDD) est essentiel : il consiste à traiter l'évaluation comme des tests — vous définissez ce que signifie « bon », vous le mesurez sur un golden set, et vous conditionnez les mises en production à l'absence de régression de qualité.

Ce que vous allez apprendre

• Les éléments clés d'un workflow EDD pour les applications LLM
• Comment construire un golden set et une grille de notation
• Comment conditionner les mises en production et détecter la dérive
• Un modèle de spécification d'évaluation à copier-coller et à adopter

L'essentiel

L'evaluation-driven development pour les applications LLM consiste à traiter la qualité comme une suite de tests. Construisez un golden set d'exemples réels, définissez une grille d'évaluation et des seuils, et relancez l'évaluation à chaque changement de prompt, de modèle ou de retrieval. Bloquez les mises en production en cas de régression de qualité, et surveillez la dérive en production grâce au logging et à l'échantillonnage. L'EDD réduit les débats du type « on a l'impression que c'est moins bon » en transformant la qualité en preuve mesurable.

La mentalité EDD : « la qualité est un contrat »

Si vous ne pouvez pas décrire ce qu'est un « bon résultat », vous ne pouvez pas livrer de façon fiable.

L'EDD commence par la rédaction d'un contrat de qualité :

• À quoi ressemble une réponse correcte ?
• Qu'est-ce qui est inacceptable ?
• Quel est le comportement de repli en cas d'incertitude ?
• Quel est le seuil à atteindre pour livrer ?

Étape 1 : construire le golden set (petit, réel et soigné)

Commencez plus petit que vous ne le pensez :

• 30 à 100 exemples par workflow suffisent pour démarrer
• incluez des cas limites et des « cas d'échec »
• incluez le contexte que vous attendez en production (documentation, tickets, historique)

Le golden set doit être géré comme du code de production. Quelqu'un doit en assurer la maintenance.

Étape 2 : définir la grille d'évaluation (comment noter les résultats)

Évitez le « ça a l'air bien ». Utilisez une grille avec quelques catégories :

• exactitude factuelle (avec citations si pertinent)
• conformité aux règles (ce qu'il ne doit pas faire)
• correction du format (schéma, structure)
• utilité (répond-il à la vraie question de l'utilisateur ?)

Vous pouvez noter manuellement au début, puis automatiser certaines parties plus tard.

Une grille d'évaluation que les équipes peuvent réellement utiliser (exemple)

Le moyen le plus rapide de rendre une grille inutilisable, c'est de la rendre trop académique. Limitez le nombre de catégories et gardez la notation simple.

Une approche pragmatique consiste à utiliser une échelle 0/1/2 par catégorie :

• 2 (conforme) : correct et suffisamment complet pour être livré
• 1 (partiel) : utile mais il manque quelque chose d'important
• 0 (échec) : faux, dangereux ou inutilisable

Exemple de grille pour un assistant de connaissance interne :

• Ancrage (0/1/2) : cite-t-il le bon document interne, ou invente-t-il ?
• Exactitude (0/1/2) : la réponse est-elle fidèle à la source ?
• Autorisation (0/1/2) : refuse-t-il lorsque l'accès manque ?
• Format (0/1/2) : respecte-t-il systématiquement le schéma de sortie ?

Définissez ensuite « livrable » comme un seuil du type « score moyen >= X », complété par une règle stricte comme « l'autorisation ne peut pas obtenir 0 ».

Cela transforme le « on dirait que c'est moins bon » en une discussion ciblée sur la catégorie qui a régressé.

Évaluation hors ligne et en ligne (les deux sont nécessaires)

L'évaluation hors ligne est celle que vous exécutez sur le golden set. Elle répond à la question : ce changement améliore-t-il les résultats sur les cas connus ?

L'évaluation en ligne est ce que vous apprenez de la production. Elle répond à la question : le comportement réel des utilisateurs a-t-il changé, et sommes-nous en train de dériver ?

En pratique :

• L'évaluation hors ligne détecte les régressions reproductibles (changements de prompt, de modèle ou de retrieval).
• Le monitoring en ligne capture la réalité du terrain (nouveaux types de tickets, variations saisonnières, nouveaux documents).

Si vous ne faites que de l'évaluation hors ligne, la production vous réservera des surprises. Si vous ne faites que de l'évaluation en ligne, vous n'aurez pas de référence et chaque débat deviendra subjectif.

Le verrou minimal de mise en production EDD (par où commencer)

Vous n'avez pas besoin d'une plateforme d'évaluation parfaite pour commencer à conditionner vos mises en production. Un verrou minimal ressemble à ceci :

1. Exécutez le golden set sur la baseline actuelle (résultats stockés).
2. Exécutez le golden set sur le changement candidat (prompt, modèle, retrieval).
3. Comparez les scores et analysez les écarts entre les échecs.
4. Bloquez le changement s'il passe sous le seuil ou s'il introduit de nouveaux « échecs critiques ».

Même si la notation est manuelle au début, c'est l'étape « comparer les échecs » qui fait gagner du temps. Elle oblige l'équipe à examiner les mêmes exemples, plutôt que d'argumenter à partir d'anecdotes.

Une fois que la boucle fonctionne manuellement, vous pouvez en automatiser certaines parties. Mais n'attendez pas l'automatisation pour vous lancer.

Quand l'évaluation coûte cher : gardez la boucle, réduisez l'échantillon

Certaines équipes évitent l'EDD parce qu'exécuter l'évaluation coûte de l'argent ou prend du temps. N'abandonnez pas la pratique pour autant. Réduisez-la.

Gardez un petit ensemble de « smoke tests » (10 à 20 exemples) exécuté à chaque changement, et lancez le golden set complet selon un calendrier fixe (chaque nuit ou chaque semaine). Vous obtenez ainsi des signaux de régression rapides, sans bloquer chaque petit ajustement.

Étape 3 : conditionner les changements (prompt, modèle, retrieval)

Si un changement peut modifier les résultats, il doit déclencher une évaluation :

• changements de prompt
• changements de modèle ou de fournisseur
• changements de source pour le retrieval (nouveaux documents, nouveau chunking, nouveau reranker)
• changements de règles

Le verrou minimal de mise en production :

• exécuter la suite d'évaluation,
• comparer par rapport à la baseline,
• livrer uniquement si le seuil est atteint,
• effectuer un rollback si une régression est détectée.

Comment garder un golden set sain (pour qu'il ne se dégrade pas)

Un golden set échoue lorsqu'il cesse de représenter la réalité. Deux règles de maintenance simples :

• Ajoutez les échecs, pas seulement de nouveaux exemples. Lorsque le système échoue en production, capturez l'entrée et le comportement « correct » attendu (anonymisé si nécessaire), puis ajoutez-le à l'ensemble.
• Versionnez l'ensemble comme du code. Les changements apportés au golden set doivent être relus. Sinon, certains seront tentés de « corriger le test » pour faire passer un changement.

Si vous ne devez faire qu'une seule chose : planifiez une courte revue mensuelle où vous ajoutez les 10 principaux nouveaux cas d'échec issus de la production. Cela permet de garder la suite d'évaluation honnête sans en faire un projet de recherche.

Étape 4 : surveiller la dérive en production

L'évaluation hors ligne détecte les régressions reproductibles. Le monitoring de production capture la réalité :

• échantillonner les résultats (avec anonymisation)
• suivre la latence et le coût
• journaliser les refus et la fréquence de recours au comportement de repli
• examiner les escalades et les corrections

Évaluation spécifique au RAG (n'accusez pas le modèle pour un mauvais retrieval)

Si votre workflow s'appuie sur le retrieval, vous avez deux modes d'échec distincts :

1. Le retrieval a récupéré le mauvais contexte (ou aucun contexte).
2. La génération a mal exploité le contexte (ou l'a ignoré).

Une manière pratique de déboguer consiste à journaliser :

• quels documents ou chunks ont été récupérés,
• si la réponse les a cités,
• et si la réponse était correcte.

Quand les équipes disent que « le modèle est devenu moins bon », c'est souvent le signe d'un changement dans le retrieval, d'un changement de documents, ou d'un problème de filtre de droits d'accès. L'EDD rend cela visible.

Un mode d'échec bien réel : le retrieval change, la qualité s'effondre

C'est un scénario fréquent :

• Une équipe modifie le chunking ou ajoute une nouvelle source de documents.
• L'assistant se met à citer la mauvaise source, ou répond avec assurance sur la base d'un contexte non pertinent.
• Les parties prenantes concluent que « le modèle est devenu moins bon ».

L'EDD permet d'isoler rapidement le problème, car vous pouvez observer :

• quels exemples ont régressé,
• si le retrieval a renvoyé un contexte différent,
• si la génération a ignoré le contexte récupéré,
• et si un filtre de droits d'accès a exclu la bonne source.

Sans EDD, vous serez tenté de « forcer le prompt » et vous perdrez des jours.

À copier-coller : modèle de spécification d'évaluation

Utilisez ce modèle comme document interne pour chaque workflow.

Spécification d'évaluation (workflow LLM)

Workflow :
Responsable :
Intention de l'utilisateur :

Jeu de référence :
- Source :
- Taille :
- Fréquence de mise à jour :

Critères d'évaluation :
- Exactitude :
- Respect des règles :
- Format :
- Utilité :

Seuil de mise en production :
Seuil de régression :

Comportement de repli :
Consignes de journalisation et de conservation :

Erreurs fréquentes

• Pas de golden set, seulement des opinions. Solution : construisez-en un, même petit.
• Grille trop complexe. Solution : commencez avec 3 à 5 catégories.
• Pas de plan de rollback. Solution : traitez les prompts et les modèles comme des mises en production.
• Journalisation accidentelle de contenu sensible. Solution : définissez tôt le périmètre des données et les règles d'anonymisation.

Mesurez la qualité, ou débattez-en indéfiniment

L'évaluation, c'est ce qui fait passer une application LLM du statut de « démo » à celui de « produit ». Si vous pouvez mesurer la qualité, vous pouvez l'améliorer. Si vous ne le pouvez pas, vous en débattrez indéfiniment. Besoin d'aide pour construire un framework d'évaluation ? Parlons-en.