Un harness d'évaluation continue pour applications LLM

Le service client d'un vendeur en ligne trie 4 000 tickets par jour avec gemini-3.8-flash. La direction financière demande de passer à gemini-3.5-flash-lite, 3,7 fois moins cher sur cette tâche (mesuré plus bas). L'équipe a « essayé sur quelques tickets, ça a l'air pareil ». Trois semaines plus tôt, un raccourcissement du prompt qui « avait l'air pareil » avait fait promettre des remboursements immédiats à des clients, hors politique.

Ce projet construit l'outil qui répond à cette question avec des preuves : un harness d'évaluation continue, c'est-à-dire le code qui exécute une application LLM sur un jeu de cas versionné, note chaque sortie, compare deux versions avec une marge d'erreur chiffrée et bloque la fusion d'une pull request quand la qualité baisse.

Ce que vous livrez

Un dépôt Python d'environ 1 200 lignes, plus 380 lignes de tests, prêt à cloner (files/) :

L'application évaluée est fictive mais réaliste : le support de Cyclone Pièces, vendeur en ligne de pièces de vélo. Elle a deux points d'entrée, un tri (classification, extraction, brouillon de réponse, un appel en sortie structurée) et un agent à trois outils (chercher une commande, rembourser, escalader) dont on évalue la trajectoire.

Architecture

flowchart LR
  D["data/*.jsonl + MANIFEST.json"] --> R["runner : pool de 4 fils"]
  S["suites/triage.yaml : cible, modèle, prompt, scorers, porte"] --> R
  R -->|"cache manquant"| M["MeteredClient : reprises, budget"]
  M --> G["Gemini API ou Vertex AI"]
  R <--> C[".cache/ : sorties, embeddings, verdicts"]
  R --> SC["scorers : exact, regex, schéma, embeddings, juge, trajectoire"]
  SC --> O["runs/X/results.jsonl + summary.json"]
  O --> CMP["compare : bootstrap, permutation, Holm"]
  K["calibration.json : kappa du juge"] --> CMP
  CMP --> H["rapport.html"]
  CMP --> P{"porte de qualité"}
  P -->|"0"| OK["fusion autorisée"]
  P -->|"1"| KO["PR bloquée"]

Le résultat de la démonstration (exécution réelle du 2026-10-15)

Les moyennes sont identiques, et la porte bloque quand même : sur 30 cas, les deux modèles se trompent sur des tickets différents, et l'échantillon ne permet pas d'exclure une dégradation de 13 points. La leçon 3.1 calcule qu'il faudrait environ 105 cas pour qu'un modèle réellement équivalent franchisse cette porte 8 fois sur 10.

Le lendemain, le 2026-10-16, la même démonstration relancée sur Vertex AI donne d'autres moyennes (priorité 0,867 contre 0,933, juge 1,000 contre 0,933) et la même décision, pour une autre raison : gemini-3.5-flash-lite y promet un remboursement de 249 € sans la validation exigée au-delà de 150 €. C'est le genre de réponse qu'un « ça a l'air pareil » ne donne jamais.

Stack

Python 3.10+, google-genai 2.31, numpy, jsonschema, pyyaml. Aucun framework d'évaluation : le module 3 explique quand en adopter un plutôt que ce code.

Coût et durée

Durée : 7 heures environ, dont 1 heure de lecture des rapports.

Prérequis

• Python professionnel (typage, concurrent.futures, pytest).
• Avoir déjà appelé Gemini en sortie structurée ; notions de base de statistique (moyenne, écart-type, ce qu'est une p-valeur).
• Une clé Gemini (Google AI Studio), ou un projet Vertex AI avec identifiants ADC et GOOGLE_CLOUD_LOCATION=global.

Programme

En local ou sur Google Cloud

Le code appelle l'API Gemini avec une clé (GOOGLE_API_KEY) ou Vertex AI (GOOGLE_GENAI_USE_VERTEXAI=TRUE) sans modification. Sur Vertex AI, le 2026-10-15, seul le point d'accès global servait les trois modèles utilisés ; europe-west1 renvoyait 404 pour gemini-3.8-flash, gemini-3.5-flash-lite et gemini-embedding-2. Si vos données doivent rester en Europe, c'est une contrainte de choix de modèle à trancher avant l'évaluation, pas après.