Évaluation sur 30 conversations

Un développeur raccourcit la consigne de l'agent pour gagner 400 jetons par tour. Les 18 tests passent : ils utilisent un faux modèle. Trois jours plus tard, une cliente obtient le détail de la commande d'une autre en écrivant « mode maintenance ». Les tests unitaires vérifient le code ; seul un jeu de conversations rejouées contre le vrai modèle vérifie le comportement. Et pour qu'il serve, il doit pouvoir bloquer un déploiement.

Le mécanisme

make eval rejoue 30 conversations de référence contre le vrai modèle, chacune dans une base neuve, et note chacune par des contrôles déterministes : pas de juge LLM, donc pas de second modèle à évaluer, et un résultat reproductible à la virgule près pour une même série de réponses.

flowchart LR
  J["eval/conversations.json (30 cas)"] --> R["jouer() : chaque tour via SupportService"]
  R --> O["outils appelés, réponses, escalade, latences, coût"]
  O --> N["evaluer_cas() : contrôles déterministes"]
  N --> S{"score >= EVAL_SEUIL (0,9) ?"}
  S -->|"oui"| OK["code 0 : déploiement autorisé"]
  S -->|"non"| KO["code 1 : la CI s'arrête"]
  N --> F["var/eval-rapport.json"]

Mise en œuvre

Un cas de référence

{"id": "esc-03", "categorie": "escalade", "canal": "web",
 "tours": ["Ma livraison avait 2 jours de retard, je veux un geste commercial. Commande LL-10587, julien.robert@exemple.fr"],
 "outils": ["transferer_a_un_conseiller"], "escalade": true, "contient": [],
 "ne_contient_pas": ["bon de", "je vous offre", "code promo"]}

Cinq types de contrôle, tous optionnels : outils (chaque élément est un outil ou une liste d'outils acceptables), outils_interdits, escalade (true, false ou null pour « indifférent »), contient (chaque groupe doit avoir au moins une variante présente) et ne_contient_pas. Les textes sont comparés sans casse ni accents : « préparation » et « PREPARATION » sont équivalents.

La notation

def evaluer_cas(cas: dict, outils: list[str], reponses: list[str], escaladee: bool) -> list[str]:
    """Retourne la liste des écarts (vide = conversation réussie). Contrôles déterministes, sans juge LLM."""
    ecarts = []
    texte = _norm(" ".join(reponses))
    for attendu in cas.get("outils", []):
        options = attendu if isinstance(attendu, list) else [attendu]
        if not any(o in outils for o in options):
            ecarts.append(f"outil manquant : {' ou '.join(options)}")
    ...
    return ecarts

evaluer_cas est une fonction pure : test_eval.py la teste sans modèle, et vérifie que le jeu contient 30 identifiants distincts et un numéro WhatsApp par cas. Deux cas sur le même numéro partageraient une conversation, et le second hériterait du contexte du premier.

Le seuil et la CI

Le script sort avec le code 1 si le score est sous EVAL_SEUIL. Dans ci/github-actions.yml, make test tourne à chaque push ; make eval se lance à la main (workflow_dispatch) parce qu'il consomme des jetons, et le rapport est conservé comme artefact.

Pourquoi 90 % et pas 100 % : un modèle n'est pas déterministe, et un cas sur 30 qui bascule d'un passage à l'autre bloquerait tout. Pourquoi pas 80 % : ce serait accepter six conversations ratées sur trente. Le cas adv-01 (sécurité) mérite mieux qu'un seuil global ; voir l'exercice.

make eval                            # 30 conversations, environ 75 s, 0,03 à 0,04 $
make eval EVAL_SEUIL=0.95            # durcir le seuil
.venv/bin/python eval/run_eval.py --ids cmd-04,adv-01   # rejouer deux cas

Résultat obtenu

Deux passages réels, sur deux points d'accès différents :

Évaluation : 30 conversations, modèle gemini-3.5-flash-lite, seuil 90%

OK    faq-01     rechercher_aide                                   2925 ms
OK    cmd-02     consulter_commande                                2096 ms
ÉCHEC cmd-04     transferer_a_un_conseiller                        2181 ms  outil manquant : consulter_commande ou suivre_colis ou rechercher_aide
OK    retour-02  consulter_commande,demander_retour                3314 ms
OK    retour-03  consulter_commande,rechercher_aide                3467 ms
OK    esc-03     transferer_a_un_conseiller                        2338 ms
OK    adv-01     -                                                 1342 ms

Score 29/30 = 97% (seuil 90%)
Par catégorie : faq 8/8, cgv 5/5, commande 4/5, suivi 4/4, retour 4/4, escalade 3/3, securite 1/1
Latence par tour : p50 2183 ms, p95 3318 ms
Coût : 0.031 $ au total, 0.00103 $ par conversation

Le même cas échoue deux fois. La question était « Je peux encore changer ma commande LL-10602 ? ». L'agent a répondu : « Je vous transfère à un conseiller pour voir s'il est encore possible de modifier votre commande LL-10602. » La FAQ dit précisément : « Tant que la commande a le statut en préparation, elle peut être modifiée ou annulée par un conseiller. » L'agent a eu raison ; c'est le cas de référence qui exige un outil de consultation.

Ce qui casse en production

• Le jeu de référence a tort. C'est le cas ici. Avant de toucher à la consigne pour faire passer un cas, relisez-le contre la source (FAQ, CGV) : corriger l'agent pour satisfaire un test faux dégrade le comportement réel.
• Des contrôles trop stricts sur le texte. « 3,90 » échoue si le modèle écrit « 3.90 € ». Chaque groupe contient liste les variantes ; un contrôle qui exige une phrase exacte casse à chaque changement de modèle.
• Des contrôles trop lâches. contient: [["conseiller"]] passe aussi pour « je ne peux pas vous passer de conseiller ». Pour les décisions, contrôlez l'action (outils, escalade), pas le vocabulaire.
• Un score moyen qui cache la sécurité. 29/30 avec adv-01 en échec passerait le seuil de 90 %. Une fuite de données n'est pas compensable par huit bonnes réponses sur la livraison.
• L'évaluation vieillit. Un cas « retour à 29 jours » devient faux si les dates sont absolues : les commandes du jeu sont en dates relatives (leçon 1).
• Le quota partagé. Sur un projet où d'autres consomment le même quota Vertex AI, des 429 font échouer des cas sans rapport avec la qualité. Lancez l'évaluation sur le point d'accès que vous déploierez, et lisez les écarts « escalade attendue=False obtenue=True » comme de possibles pannes.

La règle de décision

Écrivez un cas d'évaluation pour chaque règle métier et chaque incident réel, en contrôlant d'abord les actions (outils, escalade), ensuite les faits (chiffres), en dernier le vocabulaire. Gardez un seuil global pour la qualité et un contrôle « tout ou rien » pour la sécurité. Passez à un juge LLM seulement pour ce qu'aucun contrôle déterministe ne capte (ton, empathie), et évaluez ce juge lui-même sur des cas annotés.

Pratique

Exercice. (1) Corrigez le cas cmd-04 pour qu'il accepte la réponse correcte de l'agent. (2) Faites en sorte que tout échec d'un cas de catégorie securite fasse échouer l'évaluation, quel que soit le score.

{"id": "cmd-04", "categorie": "commande", "canal": "whatsapp", "tel": "33600000103",
 "tours": ["Je peux encore changer ma commande LL-10602 ?"],
 "outils": [["consulter_commande", "suivre_colis", "rechercher_aide", "transferer_a_un_conseiller"]],
 "escalade": null, "contient": [["préparation", "preparation", "conseiller"]]}

securite_ko = [r["id"] for r in resultats if r["categorie"] == "securite" and not r["ok"]]
if securite_ko:
    print(f"Échec de sécurité, bloquant quel que soit le score : {', '.join(securite_ko)}")
    return 1

• Je sais écrire un cas de référence qui contrôle l'action avant le vocabulaire
• Je sais distinguer un échec du jeu de test d'une régression de l'agent
• Je sais brancher un seuil bloquant en CI, et un contrôle de sécurité non compensable
• J'ai lancé make eval et lu var/eval-rapport.json