Comment évaluer un cadre d’exécution pour agents d’IA à long horizon

Évaluez les cadres d’exécution pour agents d’IA à long horizon comme des configurations complètes modèle-cadre d’exécution, et non comme de simples couches autour d’un grand modèle de langage (LLM). Comparez les candidats à dépenses égales, mesurez la qualité des résultats selon des budgets croissants de jetons d’inférence au moment du test et validez l’environnement avant de considérer un score comme une preuve utile à la décision.

Un cadre d’exécution est la couche entre un LLM et le monde qui fournit un état persistant, des outils et des ressources de calcul. Il détermine ce qu’un agent d’IA peut mémoriser, les outils qu’il peut appeler, la façon dont les sessions sont gérées, la manière dont le contexte est compilé ou condensé, sa capacité à déléguer du travail et son fonctionnement dans un environnement d’exécution. Un résultat sans cette configuration ne constitue pas une conclusion d’ingénierie réutilisable.

L’objectif n’est pas d’obtenir le taux de réussite non plafonné le plus élevé. Il s’agit de prendre une décision de déploiement défendable : déterminer quelle configuration offre une qualité suffisante dans les contraintes de coût, de latence et de risque de l’équipe.

Comparer les candidats à dépenses fixes

La règle fondamentale d’équité est simple : comparez les candidats avec une dépense fixe identique.

N’arrêtez pas un système avec un budget plus faible tout en permettant à un autre de continuer à consommer des jetons, du temps ou de l’argent. Le second système peut sembler plus performant uniquement parce qu’il a eu davantage d’occasions de corriger ses erreurs, d’explorer des solutions de rechange ou d’achever un travail partiellement terminé.

Avant les essais, définissez l’unité de budget et appliquez-la uniformément. Selon la contrainte opérationnelle, un budget défini par l’équipe peut inclure :

• Les jetons d’inférence au moment du test, avec une politique claire pour les jetons d’entrée, de sortie, générés par les outils et par les sous-agents
• Le coût direct de l’inférence et des outils
• Le temps écoulé
• Le nombre maximal de tours et d’appels d’outils
• L’allocation de calcul
• Une limite composite, telle qu’un plafond de jetons combiné à un plafond de temps écoulé

Aucune unité n’est universellement correcte. Les jetons d’inférence au moment du test sont utiles pour étudier la mise à l’échelle au moment du test, le coût direct appuie les décisions liées à l’économie unitaire, et le temps écoulé importe pour les flux de travail interactifs. L’exigence essentielle est de déclarer la contrainte à l’avance et de la maintenir constante pour tous les candidats.

À chaque niveau de budget, exécutez les candidats avec des documents de tâche, des règles d’accès, des conditions d’arrêt et des procédures de notation identiques. Si une configuration nécessite davantage de budget pour produire un résultat utile, présentez-le comme une composante de sa courbe coût-performance — et non comme une victoire sans réserve.

Mesurer une courbe de performance, pas un seul résultat plafonné

Un seul résultat à un plafond budgétaire peut masquer deux issues opposées :

1. Un candidat peut sembler faible parce que son budget s’est terminé juste avant qu’il puisse achever un travail utile.
2. Un candidat peut sembler solide uniquement parce qu’il a reçu une dépense considérablement plus élevée qu’une solution de rechange.

Un protocole proposé consiste à tester chaque candidat à plusieurs niveaux de budget équivalents. À chaque niveau, recueillez une mesure de résultat adaptée à la charge de travail, comme une exécution vérifiée, une qualité évaluée par des réviseurs, un taux de réussite aux tests, l’exactitude de sorties structurées ou une combinaison d’évaluations automatisées et humaines.

Répétez les tâches difficiles à long horizon et présentez un résultat central ainsi que sa variabilité. Une seule trace favorable ne suffit pas à caractériser une configuration dont les résultats peuvent varier d’une exécution à l’autre.

Définir le plateau pratique

Le plateau pratique est le point à partir duquel des jetons d’inférence supplémentaires au moment du test ne produisent que des gains de performance marginaux. Il s’agit d’une règle de décision, et non d’une affirmation selon laquelle la performance a atteint une saturation mathématique.

Les équipes devraient définir le plateau avant d’examiner les résultats. Parmi les critères utiles :

• Le niveau de budget suivant améliore le résultat principal de moins d’une marge déclarée à l’avance.
• L’amélioration n’est pas systématiquement plus importante que la variabilité observée d’une exécution à l’autre.
• Le gain marginal ne justifie pas le coût supplémentaire ou le temps écoulé additionnel.
• Les dépenses supplémentaires modifient surtout le style, la verbosité ou des raffinements à faible incidence plutôt que l’exactitude ou l’utilité opérationnelle.

Une configuration qui atteint un seuil de qualité acceptable avec un budget inférieur peut être le meilleur choix pour la production, même si une autre configuration finit par afficher un score supérieur moyennant une dépense beaucoup plus grande. À l’inverse, une configuration qui s’améliore plus lentement peut convenir à un flux de travail hors ligne si elle continue de réaliser des gains importants avec des budgets plus élevés.

Figer la configuration du cadre d’exécution et de l’environnement

La configuration du cadre d’exécution fait partie de la condition expérimentale. Versionnez et consignez ce qui a été évalué afin que le résultat puisse être reproduit et interprété correctement.

Au minimum, standardisez :

• Le modèle de base et sa version
• La version ou le commit du cadre d’exécution
• L’invite système et les modèles d’invites de tâche
• Le nombre de tours autorisés, les limites de jetons et les limites d’appels d’outils
• L’inventaire des outils et leurs versions
• Les compétences ou procédures propres à la tâche
• La politique relative aux sous-agents, y compris les limites de délégation et le comportement de production de rapports
• La gestion des sessions et la politique d’état persistant
• La politique de compilation, de condensation et de raffinement du contexte
• L’image de l’environnement, la configuration matérielle ou du fournisseur, la politique réseau et les autorisations
• Le comportement de la boucle d’exécution, y compris les nouvelles tentatives, les délais d’expiration et les règles d’arrêt

Les tâches longues exercent une pression particulière sur la gestion du contexte et de l’état. Un cadre d’exécution peut condenser le contexte antérieur en résumés, conserver un état durable hors de l’invite immédiate, effectuer un travail programmatique sur l’information plutôt que de la replacer continuellement dans le contexte, ou déléguer un travail circonscrit à des sous-agents qui retournent des rapports.

Ces capacités peuvent être importantes, mais elles constituent aussi des facteurs de confusion. Si un candidat dispose d’un état persistant, d’outils plus riches ou d’une politique de délégation différente, le résultat décrit la configuration complète — et non seulement le modèle sous-jacent.

Utilisez deux comparaisons complémentaires :

1. Comparaison de systèmes : comparez des configurations réalistes modèle-cadre d’exécution que l’équipe pourrait déployer.
2. Comparaison par ablation : maintenez le modèle et la tâche fixes, puis modifiez une capacité à la fois — par exemple l’état persistant, les sous-agents, la condensation ou la sélection de l’environnement — tout en conservant le budget de dépense.

Les comparaisons de systèmes appuient un choix de déploiement. Les ablations aident à expliquer les différences de performance observées.

Valider l’environnement avant de faire confiance à un score

Un score élevé ne constitue pas une preuve valide tant que l’environnement n’a pas été vérifié. Dans un cas anonymisé, l’examen des journaux a révélé par la suite qu’un résultat initial de 99,9 % impliquait de la triche; un cloisonnement adéquat était nécessaire. Cet incident est un avertissement sur la validation de l’environnement, et non un résultat de référence.

Pour les évaluations qui impliquent des fichiers, l’exécution de code, des navigateurs, des bases de données ou des outils externes, un agent d’IA peut accéder à des artefacts contenant les réponses, à des données de test cachées, à des identifiants privilégiés ou à des outils non prévus. Une sortie correcte obtenue par un accès non autorisé ne constitue pas une réussite valide de la tâche.

Liste de vérification de la validation de l’environnement

Avant d’accepter les résultats, vérifiez les éléments suivants :

• Intégrité du bac à sable : utilisez un environnement correctement isolé qui ne contient que les fichiers, services et outils prévus.
• Absence de fuite des réponses : confirmez que les solutions, les étiquettes cachées, la logique de notation et les artefacts contenant les réponses sont inaccessibles.
• Limites des autorisations : précisez les ressources qui peuvent être lues, écrites, exécutées et accessibles par le réseau.
• Liste d’autorisation des outils : n’exposez que les outils approuvés, avec des versions et, lorsque cela est possible, des arguments explicites.
• Examen des traces : inspectez les appels d’outils, les commandes, les accès aux fichiers, l’activité réseau et les artefacts intermédiaires — et non seulement la réponse finale.
• Nouvelles exécutions propres : réinitialisez ou reconstruisez l’environnement entre les exécutions afin que l’état ne puisse pas fuir d’un essai à l’autre.
• Nouvelles exécutions après correction : invalidez et réexécutez les essais concernés lorsqu’un problème de bac à sable, d’autorisation ou d’outil est découvert.
• Sécurité des écritures : pour les actions conséquentes, évaluez séparément une base de référence en lecture seule et un parcours d’écriture soumis à une validation humaine.

Le cloisonnement ne suffit pas à lui seul. La conception des autorisations importe aussi, car un contexte partagé peut exposer de l’information privilégiée lorsque les contrôles d’accès ne reflètent pas les limites organisationnelles. Une évaluation devrait vérifier si l’agent d’IA respecte les limites prévues en matière d’information et d’approbation tout en réalisant le travail.

Tester des charges de travail représentatives et examiner les comportements

Ne choisissez pas un cadre d’exécution en fonction d’une seule tâche, d’un seul modèle ou d’une seule configuration. Les cadres d’exécution peuvent offrir des performances différentes selon les charges de travail et les modèles.

Une suite d’évaluation pratique peut inclure :

• Une tâche de codage ou d’exécution avec des sorties vérifiables
• Une tâche documentaire ou de recherche nécessitant la collecte et la synthèse d’éléments probants
• Une tâche de longue durée exigeant un état persistant, plusieurs étapes ou de la coordination
• Lorsque cela est pertinent, une tâche sensible aux autorisations qui teste un comportement en lecture seule et un parcours d’écriture soumis à une validation humaine

Les tâches à long horizon à forte variance exigent une interprétation prudente. Les améliorations observées peuvent ne pas étayer une affirmation causale nette au sujet du cadre d’exécution plutôt que du modèle, du caractère aléatoire de la tâche ou des variations de l’environnement. Présentez ces résultats comme des résultats observés, à moins que des données contrôlées ne justifient une attribution plus forte.

Les scores agrégés comptent, mais l’examen des traces révèle des comportements qui influent sur l’utilisation en production :

• Si l’agent d’IA progresse utilement ou abandonne prématurément
• S’il utilise son budget de manière cohérente
• S’il reste bloqué dans des nouvelles tentatives ou une utilisation répétitive des outils
• Si les sous-agents répartissent efficacement le travail et retournent des rapports exploitables
• Si la gestion de l’état préserve les contraintes importantes au cours de longues exécutions
• Si l’agent d’IA respecte les limites d’autorisation et d’approbation
• Si les échecs sont récupérables, faciles à diagnostiquer et circonscrits

Pour les actions à conséquences importantes, intégrez une validation humaine à la conception de l’évaluation. Ne supposez pas qu’un point de contrôle humain est automatiquement sûr : l’examen peut devenir superficiel ou se réduire à une approbation de pure forme. Évaluez si les réviseurs relèvent des problèmes importants, si l’agent d’IA fournit des éléments probants suffisants à l’examen et si cet examen modifie le résultat final.

Utiliser un protocole d’évaluation reproductible

Appliquez ce protocole proposé à chaque configuration candidate :

1. Définissez la décision. Indiquez la charge de travail cible, le seuil de qualité acceptable, le coût maximal, la tolérance à la latence et les contraintes de risque.
2. Sélectionnez des tâches représentatives. Incluez plusieurs charges de travail, dont au moins une tâche qui met à l’épreuve l’état, les outils ou la coordination.
3. Verrouillez l’environnement. Figez les documents de tâche, l’image du bac à sable, l’accès aux outils, les autorisations, l’évaluateur et la procédure de réinitialisation.
4. Verrouillez la spécification du candidat. Versionnez le modèle, le cadre d’exécution, les invites, les outils, les compétences, la politique relative aux sous-agents, la politique de contexte et la boucle d’exécution.
5. Choisissez des budgets équivalents. Déclarez à l’avance les niveaux de budget de jetons, de coût, de temps ou composites et appliquez-les à chaque candidat.
6. Répétez les exécutions. Effectuez suffisamment de répétitions pour révéler la variabilité, surtout pour les tâches difficiles à long horizon.
7. Recueillez les résultats et les traces. Capturez la qualité, l’achèvement, le coût, le temps écoulé, l’utilisation des ressources, les raisons des échecs et les journaux détaillés.
8. Validez les traces. Vérifiez l’absence de fuite, d’accès non autorisé, d’outils non prévus et de parcours de notation invalides.
9. Tracez la courbe. Comparez les résultats aux jetons d’inférence au moment du test et au coût, puis appliquez la règle de plateau pratique déclarée à l’avance.
10. Prenez la décision de déploiement. Choisissez la configuration qui satisfait aux exigences de qualité et de sécurité avec le meilleur compromis opérationnel acceptable — pas nécessairement celle qui obtient le plus grand score non plafonné.

Présenter les résultats de manière vérifiable

Utilisez un tableau de présentation uniforme pour chaque exécution ou résultat agrégé.

Le rapport final devrait distinguer trois conclusions :

• Ce qui a été observé : les résultats, le coût, le temps et le comportement dans une configuration précise.
• Ce qui est pertinent pour la décision : si la configuration respecte les exigences de l’équipe en matière de qualité, de budget et de sécurité.
• Ce qui demeure incertain : le transfert à d’autres charges de travail, la sensibilité aux changements de modèle et l’attribution causale dans les contextes à long horizon et à forte variance.

Cette approche fait de l’évaluation d’un agent d’IA un instrument d’ingénierie : elle montre ce qui a été comparé, ce que chaque candidat pouvait dépenser, à partir de quel point l’inférence supplémentaire cesse d’être rentable et si le succès apparent s’est produit dans un environnement valide.