Extension des outils d'agent et contrôlabilité du système

Une situation courante consiste à évaluer un système d’agent. La première chose que vous regardez est « combien d’outils il peut accepter ».

Il peut vérifier les bases de données, envoyer des messages, modifier les bons de travail, émettre des scripts et faire fonctionner des navigateurs. Cela ressemble certainement plus à un système véritablement fonctionnel qu’à un modèle de chat uniquement. Il est donc facile pour l’équipe d’aller dans cette direction : si nous connectons quelques outils supplémentaires, accordons plus d’autorisations et rendons les liens plus automatiques, le système sera plus fort.

Le problème est qu’être fort ne signifie pas être contrôlable.

Mon jugement est le suivant : **La contrôlabilité du système d’agent ne dépend pas du nombre d’outils, mais de la convergence des états, des limites d’autorisation et du repli en cas d’échec. Lorsqu’il y aura de plus en plus d’appels d’outils, de contextes de plus en plus longs et de plus en plus d’effets secondaires des actions, sans contraintes ni mécanismes de convergence clairs, le système deviendra généralement plus difficile à prédire. **

Il existe de nombreux outils, la solution est la plage exploitable ; contrôlable, la solution est de savoir si les résultats peuvent être contenus

La solution des « outils réglables » est que l’Agent ne donne plus seulement des suggestions, mais peut affecter directement le système réel.

Il s’agit d’une expansion de capacité, pas d’un faux problème.

Mais une fois que le système passe de « répondre aux questions » à « effectuer des actions », l’orientation de l’ingénierie change. Il n’est plus nécessaire de juger si le contenu de sortie ressemble à de la parole humaine, mais de juger :

• Qu’est-ce qu’il a fait exactement cette fois-ci ?
• Faites ce mouvement au lieu d’un autre mouvement plus sûr ;
• Quelle sera l’ampleur de l’impact si vous faites une erreur ;
• En cas d’échec au milieu, le système s’arrêtera-t-il, réessayera-t-il ou laissera-t-il un demi-ensemble d’effets secondaires ?
• La prochaine fois qu’une demande similaire arrivera, prendra-t-elle un chemin complètement différent ?

En d’autres termes, à mesure que le nombre d’outils augmente, la complexité passe des « problèmes d’exactitude du texte » aux « problèmes de prévisibilité du comportement du système ».

Ces deux types de problèmes n’ont pas la même ampleur.

Un modèle qui ne peut répondre qu’à des questions est généralement un bruit cognitif s’il commet des erreurs ; si un Agent peut ajuster plus d’une douzaine d’outils, une fois qu’il n’y a plus de contraintes, s’il fait des erreurs, ce sera du bruit d’action, et s’il fait des erreurs, ce sera du bruit du système.

Ce qui devient vraiment incontrôlable en premier, c’est souvent l’État.

De nombreuses équipes gâchent l’Agent, et la première réaction est que le modèle est instable. En fait, de nombreux problèmes se situent en dehors du modèle.

Par exemple, un processus courant :

• L’agent vérifie d’abord le système de bons de travail et obtient les tâches à traiter ;
• Effectuez une nouvelle recherche dans la base de connaissances pour trouver les méthodes d’élimination historiques ;
• Appelez ensuite la requête de la base de données ;
• Envoyer un autre message au groupe de service ;
• Ajouter un dossier d’élimination finale.

Chaque étape de ce lien est « raisonnable », mais tant que l’état intermédiaire n’est pas clairement défini, le système rencontrera rapidement ces problèmes :

• Le statut du bon de travail a été modifié à En cours de traitement, mais la notification n’a pas été envoyée ;
• La requête de la base de données a été exécutée, mais les résultats n’ont pas été enregistrés dans l’enregistrement final ;
• Le message a été envoyé au groupe, mais les étapes suivantes ont échoué, mais le monde extérieur a pensé que l’affaire était réglée ;
• Une fois la fenêtre contextuelle tronquée, il n’est pas sûr quelles actions ont été effectuées auparavant lorsque le deuxième tour d’exécution se poursuit.

Il s’agit de le système ne dispose pas d’un mécanisme de convergence des États.

Un agent capable d’effectuer des actions sans machine à états de tâches claire se contente essentiellement d’enchaîner des effets secondaires en plusieurs étapes sur l’inférence en langage naturel.

Cela a fière allure en démo, mais est difficile à mettre en œuvre en production.

Les limites des autorisations ne sont pas claires et l’agent peut facilement passer de « pouvoir faire des choses » à « faire trop de choses »

Un autre malentendu courant consiste à considérer l’accès aux outils comme un inventaire de capacités.

Connectez-le au navigateur et donnez-lui accès à n’importe quel arrière-plan ; Lorsqu’elles sont connectées à Shell, la plupart des commandes peuvent être exécutées par défaut ; Une fois connecté au système de messagerie, vous pouvez notifier de manière proactive n’importe quel groupe par défaut ; Connectez-vous à la base de données et accordez des autorisations mixtes de lecture et d’écriture.

En apparence, cela rend l’Agent plus polyvalent, mais en fait, il mise sur la contrôlabilité du système pour éviter les erreurs lors d’une seule inférence.

Ceci est dangereux car le risque pour l’agent est qu’il fasse appel à un outil à effets secondaires élevés dans un contexte localement raisonnable mais globalement erroné.

Par exemple :

• J’aurais dû simplement vérifier l’état, mais plutôt exécuter le script de réparation ;
• Il était censé répondre uniquement à l’utilisateur actuel, mais la notification a été envoyée au groupe ;
• Il ne devait lire que les données, mais l’interface de mise à jour a été appelée ;
• Elle ne devrait continuer qu’après examen humain, mais l’“action suggérée” a été directement remplacée par “l’action exécutée”.

Par conséquent, l’objectif de la conception des limites d’autorisation est de séparer les actions à effets secondaires élevés du raisonnement à forte incertitude.

Si une action cause de réels dommages si elle est erronée une fois, elle ne doit pas être placée dans la même couche d’automatisation que les actions de requête ordinaires.

Avec davantage d’outils organisés, l’échec n’est plus seulement une “erreur”, mais un état semi-achevé.

Bien entendu, les systèmes logiciels ordinaires échouent également, mais l’échec des systèmes d’agents présente un problème supplémentaire : il s’agit souvent d’un échec à moitié complet au-delà des outils, des systèmes et des frontières sémantiques.

Par exemple :

1. Créez d’abord une tâche de traitement dans Jira ;
2. Accédez à Slack pour envoyer une notification ;
3. Ajustez l’API interne pour extraire à nouveau le journal ;
4. Enfin, rédigez le résumé dans la base de connaissances.

Que doit faire le système si la troisième étape échoue ?

• Rollback une tâche Jira ? -Supprimer la notification qui vient d’être envoyée ?
• Tâche conservée mais traitement des drapeaux interrompu ?
• Laisser un autre agent prendre le relais ?

L’approche la plus taboue ici est de comprendre la « gestion des échecs » comme une nouvelle demande au modèle.

Car de nombreux échecs sont déjà des effets secondaires. Ce qu’il faut vraiment, c’est :

• Quelles étapes peuvent être réessayées ;
• Quelles démarches doivent être idempotentes ;
• Quelles étapes ne peuvent être poursuivies qu’après confirmation manuelle ;
• Quelles actions extérieures doivent laisser une piste d’audit ;
• Après qu’un lien soit interrompu, où sera-t-il reconnecté lors de sa prochaine restauration ?

Si ceux-ci ne sont pas définis, l’agent semble automatiser, mais crée en réalité un travail ultérieur manuel.

Le cœur de la contrôlabilité réside dans “va-t-il converger ?”

Je suis de plus en plus enclin à considérer le système Agent comme un système de workflow doté de capacités de raisonnement, plutôt que comme un portail complet permettant de discuter.

Cela signifie que lors de sa conception, la première chose à laquelle il faut répondre est :

• Si la tâche a clairement démarré, est en cours de traitement, est en attente de confirmation, est terminée ou a échoué ;
• Quels outils peuvent être appelés dans chaque état ;
• Quels résultats peuvent être soumis directement et lesquels doivent être examinés ;
• Une fois le contexte perdu, le système peut-il récupérer de l’état externe au lieu de s’appuyer sur le rappel de modèle ?
• S’il existe des enregistrements comptables d’entrée, de sortie et d’exécution pour chaque action.

Ces choses ne semblent pas sexy, mais elles déterminent si Agent est un système qui peut être progressivement étendu ou un jouet qui ne peut être démontré que dans des coins à faible risque.

Une norme de jugement très simple est la suivante : **Si vous modifiez temporairement le modèle à un niveau plus faible, l’efficacité du système ne fera que diminuer ; si la machine à états, les limites d’autorisation et le mécanisme de restauration sont supprimés, le système ne pourra pas se mettre en ligne immédiatement. **

Cela montre que le véritable fondement est la capacité de convergence du système.

Un contre-exemple courant : traiter l’agent comme un coordinateur universel

De nombreuses plates-formes internes finiront par devenir quelque chose de très similaire à une « plate-forme intermédiaire d’IA » :

• Connectez-vous à n’importe quel système ;
• Je souhaite accepter toute demande ;
• Essayez de terminer toutes les actions automatiquement ;
• Je pensais que tant que je rendais les mots d’invite un peu plus détaillés, je pourrais supprimer le risque.

Le plus gros problème de cette route est que sa complexité marginale est très faible.

Car plus il y a de types de requêtes, plus la sémantique de l’outil est complexe et plus le nombre de combinaisons de chemins de réussite et de chemins d’échec est grand. À l’origine, je n’avais besoin que de “vérifier les enregistrements de sortie”, mais plus tard, c’est devenu :

• Vérifier les dossiers ;
• Jugement d’anomalie ;
• Décidez s’il faut revenir en arrière ;
• Envoyer des notifications ;
• Changer de statut ;
• Générer un avis ;
• Base de connaissances mise à jour.

Cela ressemble à une boucle fermée entièrement automatisée. En fait, à chaque étape supplémentaire, le système ajoute une couche de cohérence des effets secondaires et de coûts d’interprétation des autorisations.

Au final, ce qui prend vraiment du temps à l’équipe, c’est souvent :

• Cette étape sera exécutée toute seule ;
• Le même problème a pris des chemins différents aujourd’hui et hier ;
• Le système externe a été modifié, mais les registres internes n’ont pas suivi ;
• Après l’accident, il est difficile de restaurer ce sur quoi l’Agent comptait à l’époque.

Il s’agit de confier trop d’actions très incertaines à un processus de raisonnement sans limites. **

Une approche plus stable consiste à superposer l’automatisation plutôt que d’empiler les outils à plat.

Si vous souhaitez vraiment rendre le système Agent contrôlable, je vous recommande de le superposer en fonction des risques et des effets secondaires :

1. Couche à faible risque : requête et résumé

Laissez d’abord l’agent faire la lecture, la récupération, le résumé et la rédaction.

Même si le jugement de ce type d’action n’est pas parfait, il ne modifie généralement pas directement l’état extérieur et est plus approprié pour augmenter d’abord le montant.

2. Niveau de risque moyen : action en une seule étape avec contraintes

Par exemple, vous pouvez uniquement modifier un champ dans un statut d’ordre de travail spécifique, vous pouvez uniquement répondre à la session en cours et vous ne pouvez effectuer que des opérations dans la liste verte explicite.

La clé ici est de compresser l’espace d’action afin qu’il soit suffisamment étroit pour rendre le coût des erreurs acceptable.

3. Couche à haut risque : approbation explicite et exécution de la restauration

Chaque fois que la suppression de données, les opérations par lots, l’écriture inter-systèmes, les notifications sortantes et l’exécution de scripts dans l’environnement de production sont impliqués, les mécanismes de révision humaine, d’audit et de restauration doivent être mis au premier plan, plutôt que laissés à une correction ultérieure.

Un agent véritablement mature sait ce qui doit être fait automatiquement, ce qui ne peut être que suggéré et ce qui ne doit jamais être fait directement.

Limites applicables

Cet article traite principalement :

• Un agent interne connecté à de multiples outils ;
• Agent basé sur des processus avec de réels effets secondaires externes ;
• Scénarios d’orchestration impliquant des opérations inter-systèmes telles que des messages, des bons de travail, des bases de données, des scripts, des navigateurs, etc.

Si l’agent est toujours bloqué dans des tâches à faible effet secondaire telles que « aider les utilisateurs à résumer les pages Web » et « aider le service client à rédiger des réponses », disposer de davantage d’outils n’entraînera pas nécessairement une perte de contrôle immédiate, car la plupart des erreurs restent au niveau de la couche de texte.

Le vrai problème survient lorsque le système commence à changer directement d’état externe. À cette époque, nous étions déjà confrontés à une conception contrainte de type système distribué.

Résumé

L’agent peut appeler plus d’outils, ce qui rendra le système plus utile.

Mais « plus utile » et « plus contrôlable » ne sont pas des mots qui vont dans le même sens.

Lorsque la complexité des actions, des effets secondaires et du contexte augmente ensemble, ce qui détermine réellement la limite supérieure du système est souvent de savoir si l’état d’activation peut converger, si les limites d’autorisation sont claires et si l’activation peut être arrêtée et restaurée de manière stable après un échec.

Autrement, plus les outils seront connectés, plus le système deviendra comme un cadre doté de fortes capacités mais difficilement prévisible.