Tester un agent IA : ce que les tests ne voient pas

445 tests au vert, et le bug est parti en production quand même. Une question courte, juste une référence, posée depuis une interface en anglais : l’assistant répondait en français. Les tests vérifiaient que le prompt disait la bonne chose. Rien ne mesurait ce que le modèle faisait.

Cet article raconte comment j’évalue l’agent IA que j’ai mis en production pour des équipes de maintenance : ce que je mesure, comment je lis les résultats, et les bugs que seules les évals ont trouvés.

Deux filets, pas un

Les tests vérifient le câblage : plus de 2 600, avec 99 % de couverture de branches, lint, types stricts et audit de sécurité. S’ils sont rouges, rien ne part. Les évals mesurent le comportement, et elles ne bloquent rien. Elles coûtent quelques dollars, elles sont bruitées, et l’arbitrage qu’elles éclairent (un peu de qualité contre beaucoup de latence, par exemple) est une décision produit, pas un seuil.

Ce que je mesure

La recherche, étape par étape

La recherche est notée à chaque étage séparément : mots, sens, hybride, puis reclassement. Ainsi, un chiffre qui bouge désigne sa propre cause. Sur 77 vraies questions annotées, je suis le rappel, le MRR et le nDCG@10. Les bonnes réponses sont décrites par des règles (« la page 12 du document dont le titre contient… ») plutôt que par des identifiants, pour survivre à une réindexation.

Les questions sans réponse comptent autant : on mesure si le premier résultat sort plus haut que la médiane des vraies réponses. On compare des rangs, jamais des scores, car deux fournisseurs ne notent pas sur la même échelle.

Les réponses : du déterministe d’abord

Avant tout juge, des contrôles bêtes et infaillibles : chaque référence citée existe-t-elle dans le contexte fourni ? Une source est-elle citée quand il en faut une ? Le chiffre attendu, que seul l’outil SQL peut produire, est-il dans la réponse ? Ensuite seulement, un modèle juge répond à trois questions par oui ou par non : la réponse répond-elle, est-elle fidèle aux sources, reste-t-elle prudente quand les preuves manquent ?

cited = set(REF_RE.findall(answer))
if cited:  # every reference the answer cites must exist in what it was given
    checks["grounded"] = cited <= set(REF_RE.findall(context))
if case.expect.get("citation") and context:
    checks["cited_something"] = bool(cited) or "](" in answer
if figure := case.expect.get("figure"):  # a count only the SQL tool can produce
    checks["right_figure"] = digits(figure) in digits(answer)

# the judge answers three yes/no questions, and fails closed
match = re.search(r"\{.*\}", raw, re.S)
if not match:
    return {}  # no verdict is never a pass

Oui ou non, parce qu’une note sur 5 invite à débattre d’un 3. Le modèle juge reste le même d’une comparaison à l’autre, pour que son biais s’annule. Et un verdict illisible n’est jamais compté comme une réussite.

Rejouer plutôt que rechercher

Les sorties des outils sont capturées une fois en production, puis rejouées. Deux modèles reçoivent exactement le même contexte, sans VPN ni base vectorielle. Un outil absent de l’enregistrement répond « aucun résultat » : choisir le mauvais outil coûte quand même.

À vous de jouer

Ce banc reprend l’assistant de SAV vélo de l’article sur la recherche hybride. Choisissez un changement et regardez ce qu’il casse, ce qu’il répare, et ce qu’il coûte. Les cas marqués d’une étoile sont des vetos.

Lire un rapport d’évals

1. La couverture des jugements, d’abord. Au premier passage, le reclassement semblait cassé : son nDCG passait de 0,78 à 0,62. En réalité, 39 % de ses dix premiers résultats n’avaient jamais été jugés, contre 2,4 % pour l’hybride, et un document non jugé compte comme faux. Après 359 documents arbitrés, la couverture s’affiche avant tout score.
2. Les vetos, ensuite. Aucune référence inventée (100 % exigés), aucune fuite sur les questions sans réponse après reclassement. Un seul écart, et la discussion s’arrête.
3. L’arbitrage, enfin. Qualité, coût, latence. Un changement de modèle a fait passer le coût par question de 0,0160 à 0,0131 dollar et la latence médiane de 8,5 à 5,6 secondes, à qualité égale ou meilleure sur chaque contrôle. Chaque modèle n’avait tourné qu’une fois : je l’ai écrit dans la décision.

Les bugs que seules les évals ont trouvés

• La langue. Plus la question perdait de mots anglais, plus la réponse basculait en français : 9 fois sur 16 pour une référence seule. Le premier correctif a lui-même échoué à l’éval, dans l’autre sens. Mettre la condition avant la consigne l’a réglé, et un test vérifie désormais l’ordre des phrases du prompt.
• Les tableaux disparus. Au premier passage de l’éval d’extraction, on a découvert que tous les tableaux de tous les documents étaient silencieusement ignorés. Valeurs retrouvées : de 7 sur 18 à 16 sur 18 après correction.
• Le banc lui-même. Un juge dont la réflexion mangeait tout le budget de tokens (cinq verdicts envolés, qu’on aurait pris pour un échantillon plus petit), une limite de tokens plus basse qu’en production qui coupait les réponses avant l’avertissement obligatoire, une capture où tous les outils échouaient. D’où 53 tests sur le banc d’évals lui-même.

Ce que j’en retiens

• Les tests bloquent, les évals éclairent. Ne confondez pas les deux.
• Notez chaque étape séparément, pour qu’un chiffre qui bouge désigne sa cause.
• Du déterministe avant le juge, des critères binaires, et un échec par défaut.
• Affichez la couverture avant le score.
• Traitez le banc comme du code de production : il ment aussi.
• Chaque mauvaise réponse signalée devient un cas. Le jeu grossit avec l’usage, et c’est ce qui fait sa valeur.