Raft montre comment les entreprises peuvent évaluer les agents d'IA avant leur déploiement dans les flux de travail

Raft a publié une analyse pratique de la façon dont les entreprises peuvent vérifier la fiabilité des agents IA avant de leur confier des processus métier réels. L'idée principale de l'article est simple : un agent ne peut pas être approuvé sur la base d'une démonstration ou d'un taux de réussite moyen — il doit être régulièrement exécuté à travers des evals avec des critères clairs.

Pourquoi il y a peu de confiance

Alors que les systèmes d'agents transitent des expériences vers des scénarios de travail, l'entreprise se pose une question rationnelle : que faire si l'agent commet des erreurs, viole des règles ou commence à se comporter étrangement. Avec un humain, vous pouvez analyser l'incident, changer la motivation et introduire des contrôles. Avec l'IA, cela ne fonctionne pas.

Un modèle n'a pas d'incitations inhérentes pour se comporter "correctement", donc la confiance en lui ne peut pas être construite sur des sentiments, des promesses de vendeur ou un seul pilote réussi. Les auteurs proposent de voir la confiance comme la reproductibilité des résultats. Si un système reçoit régulièrement des données d'entrée similaires et produit de manière fiable le résultat attendu, on peut lui confier cette classe de tâches.

Si chaque action doit être vérifiée manuellement, la valeur de l'automatisation disparaît rapidement. Par conséquent, les evals agissent ici non pas comme une analyse supplémentaire, mais comme un mécanisme fondamental d'autorisation d'un agent à travailler.

Comment construire un ensemble d'eval

Le point de départ est un ground truth set : une collection de cas réels ou aussi proches de la réalité que possible, où les données d'entrée sont liées au résultat attendu. Habituellement, un tel ensemble est compilé à partir de tâches historiques que l'équipe a déjà traitées manuellement. L'article souligne spécifiquement que les evals n'ont pas besoin de milliers d'exemples comme l'affinage en a besoin. Ce qui importe davantage, c'est que chaque cas soit sans ambiguïté : deux experts indépendants doivent répondre de la même manière si l'agent a réussi la vérification ou non. Un ensemble d'eval typique se compose de plusieurs couches :

• tâches avec des données d'entrée spécifiques et des critères de succès
• exécutions de test de l'agent avec résultats finaux
• un ou plusieurs graders pour différents aspects de la qualité
• transcription des étapes : appels d'outils, actions intermédiaires et logique d'acheminement

À titre d'exemple, Raft décrit un agent d'assistance pour le commerce électronique qui traite les retours. Un cas teste un retour simple dans les 30 jours, un autre teste un rejet pour une demande hors politique, un troisième teste une situation ambiguë où vous ne pouvez ni rembourser automatiquement ni simplement rejeter sans clarification. Cette conception montre quelque chose d'important : vous devez évaluer non seulement la réponse finale, mais aussi le comportement le long du chemin vers celle-ci.

Parfois, le meilleur résultat n'est pas une action, mais une escalade correcte vers un humain. Pour les vérifications elles-mêmes, trois approches peuvent être mélangées. Les graders déterministes fonctionnent là où les signaux précis importent, comme les montants de remboursement ou les invocations d'outils.

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 collecter des données de référence et calibrer les évaluateurs automatisés, sinon le système commencera rapidement à mesurer ce qui est pratique plutôt que ce qui compte réellement pour l'entreprise.

Quelles métriques observer

Un accent distinct dans l'article porte sur le fait que les systèmes d'agents sont non-déterministes. Par conséquent, vérifier rigidement chaque étape n'a aucun sens : le même bon résultat peut être obtenu par différents chemins. Mais le chemin compte toujours car il consomme du temps, des tokens et l'accès aux outils, et peut également violer les politiques internes.

Un bon eval doit répondre à deux questions à la fois : le résultat est-il correct et le chemin vers celui-ci était-il raisonnable ? Un taux de réussite de 95 % semble formidable — jusqu'à ce que les erreurs soient des faux positifs. C'est pourquoi le taux de réussite seul est insuffisant.

Pour les décisions binaires, il est utile de regarder la matrice de confusion, la précision, le rappel et le F1, car différents types d'erreurs coûtent à l'entreprise de différentes manières. Un agent qui approuve trop facilement les retours crée une catégorie de risque ; un agent qui rejette massivement les demandes légitimes en crée une complètement différente. Au-delà de cela, les auteurs rappellent les pièges typiques : la loi de Goodhart, l'obsolescence de l'ensemble d'eval et l'illusion d'un tableau de bord "vert", quand la métrique semble bonne mais les plaintes réelles des utilisateurs augmentent.

Ce que cela signifie

Pour les entreprises qui souhaitent déployer des agents IA en support, opérations ou développement, la conclusion principale en est une : d'abord vous devez construire un système de vérification, et seulement ensuite augmenter l'automatisation. Les équipes gagnantes ne sont pas celles dont l'agent semble plus intelligent dans une démo, mais celles qui comprennent le coût de ses erreurs, peuvent mesurer la qualité par rapport aux scénarios et mettent régulièrement à jour les evals avec le produit.