Évaluer des systèmes multi-agents en production

Pourquoi une démo qui marche une fois ne prouve-t-elle rien ?

Un système multi-agents change à chaque modification de prompt, d’outil, de modèle ou de contexte. Sans un jeu fixe de scénarios, personne ne distingue une amélioration d’une régression.

Une démo montre que le système peut réussir. L’évaluation montre à quelle fréquence il réussit, et ce que coûte un échec.

Que veut dire concrètement évaluer un système d’agents ?

La bonne question n’est jamais « est-ce que ça marche ? ». C’est « cette version est-elle meilleure que la précédente, sur quels scénarios, selon quels critères, à quel coût, avec quelles erreurs ? ». C’est une expérience, pas une réunion de relecture.

FORGE, mon laboratoire d’évaluation, est construit autour de cette idée. Son objet central est l’exécution d’évaluation : une version de scénario, une version d’agent, une configuration, la trace d’exécution, les évaluations et les scores, figés dans un manifeste reproductible. Comparer deux versions revient alors à comparer deux ensembles d’exécutions, avec scores, coût, erreurs et niveau de confiance.

FORGE est une bêta publique et ses résultats dépendent des scénarios configurés. C’est la méthode que je défends, pas la promesse qu’un outil résout l’évaluation à votre place.

De quelles couches d’évaluation a-t-on besoin ?

Aucune méthode ne suffit seule. Chaque couche attrape un type d’échec différent, et sa limite doit être couverte par la suivante. Je les empile de la plus économique et objective à la plus coûteuse et nuancée.

Comment comparer deux versions d’un système d’agents ?

On choisit une référence et un candidat, on exécute les deux sur les mêmes scénarios, on répète les exécutions parce que les sorties d’un modèle varient, et on regarde les écarts par critère plutôt qu’un score global. Une moyenne unique cache le scénario où le candidat a empiré.

• Figer et versionner les scénarios, pour que le test ne bouge pas pendant que l’agent évolue.
• Exécuter la référence et le candidat plusieurs fois chacun, et comparer avec des statistiques appariées, pas sur une seule exécution.
• Présenter les écarts par critère avec un intervalle de confiance, pas seulement un score composite.
• Lister les régressions par scénario, même quand la moyenne s’améliore.
• Terminer par une recommandation exploitable : déployer, déployer avec prudence, ne pas déployer, ou non concluant.

Comment éviter de se tromper soi-même avec son propre jeu de tests ?

Le plus grand risque n’est pas un mauvais agent, c’est un agent qui a l’air bon. Dès qu’une équipe règle ses prompts sur un jeu de tests public, les scores montent, et le comportement réel pas forcément. Je distingue trois types de scénarios : publics pour le développement courant, privés dont le contenu et le résultat attendu restent cachés à l’agent, et frais, ajoutés régulièrement pour détecter la sur-optimisation.

Des chaînes canaris aident à détecter la contamination, et une taxonomie d’erreurs (hallucination, contradiction, mauvais outil, fuite de données, erreur de source) transforme un vague « ça semble moins bien » en liste comptable et vérifiable.

La calibration humaine boucle le dispositif. Si les juges et les relecteurs ne sont pas d’accord, il faut d’abord corriger le juge, pas l’agent. Le désaccord entre juges est aussi le meilleur moyen de prioriser ce qu’un humain doit relire.

À quoi ressemble l’évaluation d’un RAG sur une vraie plateforme ?

Sur la plateforme de la DILA (secteur public, services du Premier ministre), l’évaluation couvrait toute la chaîne RAG, pas seulement le texte final. C’est important, car une réponse fluide peut cacher un échec de récupération. Ces chiffres ont été mesurés sur la plateforme de la DILA, pas par FORGE.

• Une fidélité faible avec un rappel élevé pointe la génération : le modèle avait les faits et les a ignorés.
• Un rappel faible pointe la récupération : aucun changement de prompt ne corrigera une réponse dont les preuves n’ont jamais été trouvées.

Pourquoi noter le coût et la latence comme la qualité ?

Un agent qui répond bien mais enchaîne les appels d’outils pendant des minutes n’est pas meilleur, il est plus cher. Le coût, la latence et les tokens par étape appartiennent à la même grille que la qualité, avec des pondérations que l’on choisit et que l’on sait expliquer.

FORGE note plusieurs dimensions, dont la qualité, la cohérence, le raisonnement, la sécurité, la robustesse, le coût, la latence et l’expérience utilisateur, et chaque score composite est accompagné de sa formule. Ma règle est simple : aucun score sans explication. Chaque note doit remonter au critère, au juge (modèle, version, prompt), à la règle et à l’étape de trace concernée.

Le programme DILA a montré la même logique à l’échelle d’une plateforme : l’optimisation des chaînes et la réutilisation ont contribué à un coût par requête d’IA en baisse de 30 %. Ce chiffre vient de la plateforme de la DILA, pas de FORGE, mais il montre pourquoi le coût est un critère de qualité et non un détail pour la finance.

Que doit décider un point de contrôle avant mise en production ?

Un point de contrôle transforme l’évaluation en décision. En pratique, il s’exécute en intégration continue : si un candidat régresse sur un critère déclaré critique, le pipeline s’arrête, et le rapport montre quels scénarios et quelles étapes de trace en sont la cause.

Il faut aussi une porte de sortie. Une régression peut être acceptée, mais avec un responsable nommé et une raison, pour que la décision reste auditable. Ce que le point de contrôle apprend retourne dans les scénarios : chaque incident constaté en production devient un nouveau test.

C’est aussi ce qui rend l’autonomie possible. Quand on peut montrer ce qui se passe sur un jeu fixe de scénarios, on peut autoriser un agent à faire davantage, et retirer cette autorisation quand les preuves changent.