Ingénierie des Boucles : Révolutionner la Gouvernance des Agents IA

L'Enjeu de la Gouvernance dans les Agents IA

Au cours de l'année passée, j'ai consacré mon temps à développer des agents d'intelligence artificielle capables de réaliser des tâches concrètes. Ces agents ne se contentent pas de répondre à des questions, mais vont jusqu'à écrire du code, générer des rapports, planifier des tâches et interagir avec des systèmes de production. Une leçon clé est ressortie de cette expérience : plus un modèle devient sophistiqué, plus il peut causer des dommages avant que le problème ne soit détecté. Par exemple, un poème généré par GPT qui inclut un fait erroné est relativement inoffensif. En revanche, une commande API générée par GPT qui supprime une base de données de production peut avoir des conséquences désastreuses. La distinction ne réside pas dans le modèle lui-même, mais dans l'architecture qui l'entoure.

Les Limites des Architectures d'Agents Actuels

Actuellement, la majorité des systèmes d'agents IA suivent l'un des deux schémas suivants :

• Modèle 1 : Le One-Shot Wonder. Ce modèle consiste à fournir une invite au modèle et à obtenir une sortie. Il est rapide, peu coûteux et souvent efficace, jusqu'à ce que la tâche nécessite plusieurs étapes. À ce moment-là, le modèle peut perdre le contexte et produire des résultats qui semblent corrects mais ne le sont pas.

• Modèle 2 : La Boucle ReAct. Ce modèle repose sur un cycle de raisonnement, action, observation et répétition. Bien qu'il soit plus puissant, il manque de gouvernance explicite. Il n'existe pas de mécanisme clair pour déterminer quand s'arrêter, changer de cap ou impliquer un humain.

Ces deux approches partagent une faille fondamentale : elles considèrent la fiabilité comme une caractéristique du modèle, plutôt que du système dans son ensemble.

L'Approche de l'Ingénierie des Boucles

L'ingénierie des boucles propose une nouvelle perspective. Plutôt que de chercher à rendre le modèle plus intelligent, elle se concentre sur la création d'une architecture de gouvernance autour du modèle. En s'appuyant sur des concepts tels que la théorie du contrôle, les machines d'état, l'orchestration des flux de travail et l'apprentissage par renforcement, cette approche identifie six composants essentiels pour garantir la fiabilité des agents :

1. Représentation des Objectifs
   Il ne s'agit pas simplement de « rédiger un article de blog », mais de définir la tâche de manière structurée, en incluant les contraintes (budget, temps, règles de sécurité), les critères de succès et les conditions d'arrêt. Sans ces éléments, l'agent n'a pas de repère fixe, comme un navire sans destination.

2. Modèle d'État
   Ce modèle se compose de cinq couches distinctes :

   • État statique : Inclut l'objectif, les contraintes et la configuration.
   • État dynamique : Comprend les sorties actuelles et les résultats intermédiaires.
   • État des outils : Répertorie les outils disponibles et leur statut.
   • État réflexif : Intègre les leçons tirées des itérations précédentes.
   • État de gouvernance : Gère le budget de risque, le budget de coût et les itérations restantes.

   Contrairement à la plupart des systèmes d'agents qui regroupent ces éléments dans une seule fenêtre de contexte, l'ingénierie des boucles les sépare explicitement pour permettre à l'agent de distinguer entre « ce que j'essaie de faire », « ce que j'ai fait » et « ce que j'ai appris ».

1. Exécuteur d'Actions
   Ce composant établit une frontière contrôlée autour de l'utilisation des outils. Chaque action doit passer par un contrôle de risque avant d'être exécutée. Cela contraste avec un agent qui peut appeler n'importe quelle API à volonté, et un qui doit demander la permission avant de dépenser de l'argent ou de modifier des fichiers.

2. Collecteur d'Observations
   Le collecteur d'observations enregistre ce qui s'est réellement passé, et non ce que l'agent avait l'intention de faire. Cette distinction est cruciale car les modèles de langage sont notoirement mauvais en auto-évaluation. Un agent pourrait croire qu'il a réussi à enregistrer un fichier alors que le système de fichiers a renvoyé une erreur de permissions.

3. Évaluateur
   Ce composant évalue quatre dimensions à chaque itération :

   • Confiance : Quelle est la certitude de l'agent quant à sa prochaine étape ?
   • Progrès : L'agent se rapproche-t-il de l'objectif ou tourne-t-il en rond ?
   • Dérive : L'agent s'est-il éloigné de la tâche originale ?
   • Risque : La prochaine action pourrait-elle causer des dommages ou dépasser le budget ?

4. Contrôleur
   Le contrôleur est le décideur ultime. En fonction de l'évaluation fournie par l'évaluateur, il choisit parmi plusieurs options : continuer, réviser, rétrograder, escalader à un humain ou arrêter l'exécution. C'est un composant souvent absent dans la plupart des systèmes d'agents, qui disposent d'un modèle pour décider quoi faire, mais pas d'un mécanisme pour décider s'il faut continuer.

Diversité des Boucles

Toutes les tâches ne nécessitent pas la même structure de boucle. Le document identifie cinq types de boucles, qui peuvent être combinées. Une seule tâche peut passer par des boucles de planification, d'exécution et de vérification, toutes enveloppées dans une boucle de gouvernance qui maintient le risque sous contrôle.

Les Failles des Architectures Actuelles

Le document propose une analyse comparative des architectures actuelles :

• Les agents one-shot sont rapides et peu coûteux, mais ne disposent pas de mécanisme de récupération. Si la première sortie est incorrecte, il faut tout recommencer.
• Les boucles ReAct non guidées, qui sont la norme dans la plupart des frameworks, sont flexibles mais manquent de condition de terminaison formelle. Elles continuent à dépenser des ressources jusqu'à ce que la fenêtre de contexte soit remplie ou qu'un humain intervienne.
• Les agents orchestrés par des flux de travail, tels que Prefect, Airflow ou AWS Step Functions, offrent une excellente traçabilité et gouvernance pour les modes de défaillance anticipés. Cependant, dès que la tâche s'écarte du graphique prédéfini, le système devient fragile.
• Les agents conçus avec l'ingénierie des boucles sont adaptés aux situations où le plan émerge à l'exécution. La gouvernance n'est pas intégrée dans un graphique statique, mais dans un ensemble de politiques dynamiques appliquées à chaque itération.

L'Argument Contre l'Ingénierie des Boucles

Le document aborde honnêtement la critique principale : « Les outils d'orchestration de flux de travail matures fournissent déjà un suivi d'état, des réessais, des portes d'approbation humaine et des journaux d'audit. L'ingénierie des boucles n'est-elle pas simplement une re-nommée de capacités existantes ? » La réponse est claire : « Les contrôles de gouvernance doivent s'exécuter à chaque itération plutôt qu'à des points d'exception, car il n'y a pas de carte de conception qui indique quelles itérations pourraient échouer. » Dans un système orchestré par flux de travail, l'ensemble du graphique est défini à l'avance, et les étapes risquées sont connues car elles ont été placées là. Dans un système conçu avec l'ingénierie des boucles, le plan est généré par le modèle à l'exécution, et il est impossible de prévoir quelle étape pourrait poser problème. Par conséquent, chaque étape doit être vérifiée.

C'est là l'idée centrale : lorsque l'on ne peut pas prédire où l'échec se produira, une couche de gouvernance omniprésente est nécessaire.