Qwen choisit une étape à la fois, le runtime vérifie : comment fonctionne un agent IA sous contrôle

Connecter un agent à des outils n’a rien de compliqué. La difficulté est ailleurs : que faire lorsqu’une réponse assurée du modèle ne suffit pas ? Si l’agent propose de remettre en service un système dégradé, qui s’assurera que l’infrastructure supportera la bascule du trafic et que le service sera effectivement rétabli ? L’auteur d’une analyse publiée sur Habr a voulu le vérifier en pratique et a construit un environnement dédié.

Le modèle propose, le runtime décide

Le banc d’essai s’appelle Governed Agent Runtime. Il simule un service de paiement : versions et réplicas, charge en RPS, métriques des dépendances, contraintes de capacité et de tolérance aux pannes N-1. L’agent est une instance locale de Qwen ; l’article précise Qwen3.8:27b Q4_K_M. Le modèle choisit l’étape suivante, tandis qu’un code déterministe contrôle l’admissibilité et l’exécution des opérations. Ce code vérifie les préconditions, demande une validation humaine avant toute modification d’état et gère les budgets d’appels au modèle et aux outils.

Un point essentiel : le runtime distingue des états faciles à confondre. « 8 réplicas demandés » ne signifie pas que 8 réplicas sont opérationnels. « Trafic basculé » ne signifie pas que le service est rétabli. « Opération autorisée » ne signifie pas qu’elle a été exécutée. « Le modèle considère la tâche comme terminée » ne signifie pas que l’état final a été confirmé.

Quand l’évaluateur était en cause

Sur cinq scénarios à une seule étape, exécutés trois fois chacun, Qwen a obtenu 12 sur 15, tandis que le contrôle du runtime a réussi 15 tests sur 15. Le scénario S12, consacré à la préparation d’un plan de retour arrière, a échoué : le modèle avait ajouté au plan des seuils comme « taux d’erreurs 5xx supérieur à 5% » et « rétablissement si le taux d’erreurs 5xx reste inférieur à 1% pendant 5 minutes ». Ces chiffres ne figuraient pas dans son contexte.

Après l’ajout au contexte des calculs de la plateforme — à 820 RPS, six réplicas ne suffisent pas, sept ne satisfont pas la contrainte N-1 et huit suffisent —, le modèle a de nouveau reçu une évaluation négative. L’auteur a comparé trois éléments : les données présentées au modèle, les exigences de l’évaluateur et la réponse produite. Il est apparu qu’une partie des exigences de l’évaluateur n’était pas fondée sur les données d’entrée. Le résultat a été reclassé de « négatif » à « indéterminé ».

C’est ainsi qu’est né l’Evaluation Traceability Gate. Chaque critère d’évaluation substantiel doit renvoyer à un fait présent dans le contexte du modèle ou reposer sur un raisonnement documenté, et la décision doit être validée par un humain. Le critère imposant de vérifier le rétablissement avant de supprimer l’ancienne version n’a toujours pas trouvé de justification ; le gate l’a donc bloqué. Lors d’un nouvel essai, Qwen a commis une véritable erreur : le modèle a basculé le trafic avant de confirmer que les huit réplicas étaient prêts.

Une étape à la fois

L’auteur a alors modifié la formulation de la tâche. À chaque appel, le modèle propose exactement une action ou STOP, puis reçoit des observations actualisées après l’étape. Lors de l’essai réussi, Qwen a suivi cette séquence : passage à 8 réplicas, contrôle distinct de leur état, bascule des 820 RPS, vérification du rétablissement, finalisation du retour arrière. Cela représente cinq appels au modèle, neuf opérations avec les outils et trois validations humaines. Avant les étapes dépendantes des précédentes, le modèle demandait de lui-même des observations à jour et ne confondait pas une opération autorisée avec une opération exécutée.

Dans le scénario négatif, la plateforme a renvoyé FAIL lors du contrôle du rétablissement. Au lieu de finaliser le retour arrière, Qwen a choisi STOP, le runtime a enregistré SAFE_FALLBACK et les instances dégradées sont restées en place.

Les enseignements à en tirer

Premièrement : ne donnez pas au modèle le pouvoir d’exécuter. Laissez-le proposer, et confiez au code la vérification des préconditions et de l’état final. Deuxièmement : distinguez « demandé », « autorisé », « exécuté » et « confirmé » comme autant de statuts dans les journaux et les contrats des outils. Troisièmement : l’évaluateur est lui aussi un artefact susceptible d’être incohérent avec le contexte d’entrée. Si vous évaluez un agent selon des critères qu’il ne pouvait pas connaître, vous mesurez votre propre processus, pas le modèle.

Les limites sont évidentes. L’environnement est simulé et volontairement simplifié, les essais sont peu nombreux et une partie des conclusions repose sur une analyse sémantique manuelle. Mais l’approche s’applique à tout agent qui intervient en production : il faut vérifier la réponse du modèle, mais aussi les liens entre la spécification, le contexte et l’évaluateur.