Raft explique comment évaluer les agents IA avant de les intégrer aux processus de travail

Raft a publié une analyse pratique de la manière dont les entreprises peuvent vérifier la fiabilité des agents IA avant de leur confier de vrais processus métier. L'idée centrale de l'article est simple : on ne doit pas croire un agent sur la foi d'une démonstration ou d'un taux de réussite moyen ; il faut le soumettre régulièrement à des evals aux critères clairs.

Pourquoi la confiance ne suffit pas

À mesure que les systèmes d'agents passent des expérimentations aux scénarios de production, les entreprises se posent une question parfaitement rationnelle : que faire si l'agent se trompe, enfreint les règles ou se met à agir de façon étrange ? Avec un humain, on peut analyser l'incident, changer la motivation et instaurer des contrôles. Avec l'IA, cela ne marche pas. Le modèle n'a pas d'incitation propre à se comporter « correctement », donc la confiance qu'on lui accorde ne peut reposer ni sur des impressions, ni sur les promesses d'un éditeur, ni sur un seul pilote réussi.

Les auteurs proposent de voir la confiance comme la répétabilité du résultat. Si un système reçoit de nombreuses fois des données d'entrée similaires et produit de façon stable le résultat attendu, on peut lui confier cette catégorie de tâches. Si chaque action doit être revérifiée à la main, la valeur de l'automatisation s'évanouit vite. Les evals ne sont donc pas ici une analyse supplémentaire, mais le mécanisme de base pour autoriser un agent à travailler.

Comment constituer un eval set

Le point de départ est le ground truth set : un ensemble de cas réels, ou aussi proches que possible de la réalité, où les données d'entrée sont associées au résultat attendu. On l'assemble généralement à partir de tâches historiques que l'équipe a déjà traitées manuellement. L'article souligne que les evals n'exigent pas des milliers d'exemples, contrairement au fine-tuning. Il importe davantage que chaque cas soit univoque : deux experts indépendants doivent répondre de la même manière à la question de savoir si l'agent a réussi ou non.

Un eval set type comporte plusieurs couches :

• des tâches avec des données d'entrée précises et un critère de réussite
• une exécution de test de l'agent avec son résultat final
• un ou plusieurs graders pour différents aspects de la qualité
• une transcription des étapes : appels d'outils, actions intermédiaires et logique du parcours

À titre d'exemple, Raft décrit un agent de support d'une boutique en ligne qui traite les remboursements. Un cas teste un remboursement simple dans un délai de 30 jours, un autre le refus d'une demande hors politique, un troisième une situation ambiguë où l'on ne peut ni rembourser automatiquement ni refuser simplement sans demander de précisions. Cette conception montre un point important : il faut évaluer non seulement la réponse finale, mais aussi le comportement en chemin. Parfois, le meilleur résultat n'est pas une action, mais une escalade correcte vers un humain.

Pour les vérifications elles-mêmes, on peut combiner trois approches. Les graders déterministes conviennent là où des signaux exacts comptent, comme le montant du remboursement ou l'appel du bon outil. Les juges LLM sont utiles pour évaluer le ton, l'exhaustivité et la clarté de la réponse. Les humains sont nécessaires au départ pour constituer les données de référence et calibrer les évaluateurs automatiques ; sinon, le système se met vite à mesurer ce qui est commode plutôt que ce qui compte vraiment pour l'entreprise.

Quelles métriques surveiller

L'article insiste tout particulièrement sur le fait que les systèmes d'agents sont non déterministes. Vérifier strictement chaque étape n'a donc pas de sens : un même bon résultat peut être atteint par des chemins différents. Mais le chemin compte quand même, car il consomme du temps, des tokens et des accès aux outils, et peut en outre enfreindre des politiques internes. Un bon eval doit répondre simultanément à deux questions : le résultat est-il correct, et le chemin était-il raisonnable ?

95 % de réussite, ça sonne bien, tant que les erreurs ne se logent pas

dans les faux positifs.

C'est pourquoi le seul pass rate ne suffit pas. Pour les décisions binaires, il est utile de regarder la matrice de confusion, la precision, le recall et le F1, car les différents types d'erreurs ne coûtent pas la même chose à l'entreprise. Un agent qui approuve trop facilement les remboursements crée une catégorie de risque ; un agent qui rejette massivement des demandes légitimes en crée une tout autre.

Par ailleurs, les auteurs rappellent les pièges classiques : la loi de Goodhart, l'obsolescence de l'eval set et l'illusion du tableau de bord « au vert », quand la métrique semble correcte alors que les plaintes réelles des utilisateurs augmentent.

Ce que cela signifie

Pour les entreprises qui veulent déployer des agents IA dans le support, les opérations ou le développement, la conclusion principale est unique : il faut d'abord construire le système de vérification, puis seulement passer l'automatisation à l'échelle. Ce ne sont pas les équipes dont l'agent paraît plus intelligent en démo qui l'emportent, mais celles qui comprennent le coût de ses erreurs, savent mesurer la qualité par scénario et mettent régulièrement à jour leurs evals en même temps que le produit.