✅ Évaluation continue et qualité IA

1.1 Les 4 questions auxquelles seule une eval pipeline répond

1. Est-ce que mon prompt v2 est meilleur que mon prompt v1 ? (Sans eval : impossible de savoir, on devine)
2. Est-ce que basculer de Claude Sonnet à Kimi K2.6 dégrade la qualité ? (Sans eval : pari aveugle)
3. Est-ce que mon RAG s'est dégradé après l'ajout de 1000 nouveaux documents ? (Sans eval : on découvre par les plaintes)
4. Est-ce que ma nouvelle fonctionnalité agent maintient le niveau qualité antérieur ? (Sans eval : on fait confiance)

1.2 Le cycle « prompt → eval → improve → repeat »

C'est le cycle de référence du LLMOps moderne (cf. la fiche Context engineering & coûts sur la gouvernance prompts) :

→ Sans dataset golden et scoring automatique, ce cycle est impossible.

2.1 Le format type

Pour chaque cas du golden :

• Input : le prompt utilisateur réel ou représentatif
• Contexte (si applicable) : documents RAG, historique conversation
• Expected output : la réponse idéale (ou les caractéristiques d'une bonne réponse)
• Tags : catégorie de cas (facile/moyen/difficile, type de question, etc.)
• Source : d'où vient le cas (utilisateur réel anonymisé, cas synthétique, edge case)

2.2 Les 4 sources de cas pour ton golden

1. Cas réels anonymisés : extraits de tes logs production (anonymise les PII). Reflète la distribution réelle des usages.
2. Cas edge : situations rares mais critiques (questions ambiguës, cas limites, erreurs typiques).
3. Cas adverses : prompts de stress test (jailbreak attempts, prompt injection, requêtes hors scope).
4. Cas synthétiques : générés par LLM puis revus humain — pour étendre la couverture.

2.3 Sweet spot PME : 50-200 cas

3.1 Evals règle-based (rapides, déterministes)

Vérifications automatiques sans LLM :

• Format : JSON valide selon schéma, XML conforme, longueur
• Mots-clés : présence obligatoire, mots interdits (data leak, vulgarité)
• Patterns regex : numéros au bon format, dates valides
• Latence : temps de réponse sous SLA

→ Coût : quasi-nul. Vitesse : milliseconde. À automatiser systématiquement.

3.2 Evals sémantiques (similarity scoring)

Comparaison entre la sortie générée et une référence :

• BLEU / ROUGE : métriques classiques (utiles mais imparfaites)
• Embedding similarity : cosine similarity entre embedding de la sortie et de la référence
• BERTScore : variante avancée

→ Coût : faible. Vitesse : 100ms-1s. Utile pour fact-checking et tâches structurées.

3.3 Evals LLM-as-judge (qualité narrative)

Un LLM juge la qualité d'une sortie d'un autre LLM, selon des critères définis :

• Critères : précision, cohérence, ton, complétude, absence d'hallucination
• Échelle : 1-5 ou 1-10, avec rationale obligatoire
• Modèle juge : généralement plus puissant que le modèle évalué (ex : Claude Opus juge Claude Sonnet)

→ Coût : significatif (chaque eval = 1 appel LLM puissant). À utiliser parcimonieusement, en complément des règle-based.

3.4 Stratégie type PME

• Règle-based sur 100 % des cas (rapide, gratuit)
• Sémantique sur 100 % des cas où une référence existe (fact-checking)
• LLM-as-judge sur 20-30 % des cas (échantillonnage qualité narrative, coût maîtrisé)

3.5 Définitions canoniques Anthropic (mai 2026)

Référentiel terminologique à adopter pour aligner le vocabulaire interne aux pratiques 2026 (Anthropic Engineering, « Demystifying evals for AI agents ») :

3.6 Heuristique « eval first, optimize second »

Pourquoi : sans baseline d'évaluation, toute optimisation est mesurée à l'aveugle. Les premiers gains paraissent grands (« ça marche mieux ») mais on découvre 6 mois plus tard que la qualité est restée stable, voire a régressé. Cette heuristique est l'équivalent qualité du « single LLM call d'abord » côté architecture (voir Cadrer un projet IA — Heuristique anti-hype).

3.7 Bruit infra vs régression modèle — comment distinguer

Source complémentaire : Anthropic « Quantifying infrastructure noise in agentic coding evals » (mai 2026).

Quand un eval baisse, deux causes possibles :

1. Régression modèle : le modèle de base a changé, ou le prompt a dérivé
2. Bruit infra : latence variable, indisponibilité ponctuelle d'un tool, instabilité de l'API

Méthode pour distinguer : répéter l'eval N fois sur le même input et mesurer la variance.

• Variance haute → bruit infra (à corriger côté infra avant de modifier l'agent)
• Variance basse mais score bas → régression réelle (à investiguer côté modèle/prompt)

4.1 Stack open-source self-hosted

4.2 Stack SaaS

4.3 Recommandation pratique

Pour démarrer en PME : Phoenix Arize self-hosted + DeepEval pour tests CI. Stack gratuit, contrôle, EU.

Si manque de bandwidth ops : Comet Opik free tier + DeepEval pour CI.

5.1 Le principe

À chaque modification (nouveau prompt, nouveau modèle, nouvelle pipeline RAG) : run automatique sur le golden + comparaison avec la baseline. Si dégradation > seuil défini → bloquer le déploiement.

5.2 Workflow type CI/CD pour LLM

Pour la phase production runtime, voir la fiche Agents en production : observabilité.

5.3 Outils CI/CD compatibles

• GitHub Actions : runners gratuits pour OSS, payants à grand volume
• GitLab CI : équivalent
• Argo Workflows : pour pipelines plus complexes self-hosted

→ Setup PME : 1-3 jours pour wirer une PR avec un run d'eval automatique.

6.1 Pourquoi A/B tester

Pour valider l'impact réel d'une amélioration sur les utilisateurs (vs amélioration mesurée sur le golden, qui peut être un overfitting).

6.2 Pattern type

• 50 % des sessions → variante A (baseline)
• 50 % des sessions → variante B (nouvelle)
• Mesure des KPI : satisfaction explicite (👍/👎), conversion, drop-off, NPS
• Durée minimum : 1-2 semaines pour signal statistique

6.3 Outils

• LiteLLM gateway (cf. la fiche Inférence SaaS vs self-hosted) supporte le routage A/B nativement
• Statsig, Eppo, Optimizely : plateformes A/B testing établies