🤖 AI

LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents

LedgerAgent est une méthode d'inférence qui améliore les agents d'appel d'outils respectueux des politiques dans les domaines du service client en maintenant les états de tâche dans un registre séparé afin d'assurer une prise de décision cohérente et de bloquer proactivement les violations de politique avant l'exécution des outils.

Auteurs originaux : Md Nayem Uddin, Amir Saeidi, Eduardo Blanco, Chitta Baral

Publié 2026-06-19

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Md Nayem Uddin, Amir Saeidi, Eduardo Blanco, Chitta Baral

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un agent de service client pour une compagnie aérienne ou un magasin de détail. Votre travail consiste à aider les clients à annuler des vols, à retourner des articles ou à modifier des plans. Pour ce faire, vous disposez d'une « ceinture d'outils » composée d'outils numériques que vous pouvez utiliser pour consulter des dossiers, mettre à jour des comptes ou traiter des remboursements.

Le problème, selon cet article, est que les agents IA standards sont comme des amnésiques dotés d'une mémoire très longue. Ils peuvent lire tout l'historique de la conversation (le « transcript »), mais ils n'ont pas de carnet de notes dédié pour y inscrire les faits importants qu'ils viennent de découvrir.

Voici la décomposition de la solution de l'article, LedgerAgent, en utilisant des analogies simples :

Le Problème : L'agent « Perdu dans le Bruit »

Dans une configuration standard, chaque fois que l'IA vérifie une réservation de vol ou le statut d'une commande, cette information est déversée dans un journal de chat géant et défilant.

L'analogie : Imaginez que vous essayiez de trouver un numéro de téléphone spécifique dans une pile de 500 pages de notes manuscrites. Vous devez relire toute la pile à chaque fois que vous avez besoin de décider de la marche à suivre.
L'échec : Parce que l'IA doit « relire » le journal de chat pour se souvenir des faits, elle s'embrouille souvent. Elle peut :
1. Oublier un détail crucial (comme la date du vol).
2. Agir sur la base d'informations obsolètes (pensant qu'un vol est encore réservable alors qu'il ne l'est plus).
3. Effectuer un mouvement « techniquement correct » qui enfreint les règles (comme essayer de rembourser un mode de paiement qui n'existe pas) parce qu'elle n'a pas double-vérifié les faits actuels par rapport à la politique.

La Solution : Le « Ledger » et le « Bouncer » (Le Videur)

Les auteurs ont créé LedgerAgent, qui ajoute deux fonctionnalités simples mais puissantes au flux de travail de l'IA.

1. Le Ledger (Le Carnet de Notes Organisé)

Au lieu de laisser les faits flotter dans le journal de chat, l'IA dispose désormais d'un ledger structuré.

Comment ça marche : Chaque fois que l'IA utilise avec succès un outil pour lire des données (comme « Obtenir les détails du vol »), elle ne se contente pas de laisser ces données dans le chat. Elle les copie immédiatement dans un « carnet de notes » propre et organisé (un dictionnaire typé).
La métaphore : Considérez le journal de chat comme un plan de travail de cuisine en désordre où les ingrédients sont éparpillés partout. Le Ledger est un étagier d'épices étiqueté. Lorsque l'IA a besoin de connaître le prix d'un vol, elle ne fouille pas dans le plan de travail encombré ; elle regarde simplement le bocal « Prix du vol » sur l'étagère.
Le bénéfice : L'IA sait exactement ce qu'elle sait, sans avoir à deviner ou à chercher dans d'anciens textes.

2. La Policy Gate (La Porte de la Politique / Le Videur)

Avant que l'IA ne soit autorisée à effectuer un changement dans le monde réel (comme annuler un vol ou émettre un remboursement), elle doit passer par une Policy Gate.

Comment ça marche : Cette porte est un vérificateur de règles strict. Elle examine l'action proposée par l'IA et la compare aux faits du Ledger et aux règles de l'entreprise.
La métaphore : Imaginez un videur à l'entrée d'un club. L'IA (l'invité) dit : « Je veux annuler ce vol. » Le videur (la porte) vérifie le Ledger (la liste des invités) et le Livre de règles (la politique).
- Scénario : La règle stipule : « Vous ne pouvez annuler que dans les 24 heures. » Le Ledger indique que le vol a été réservé il y a 48 heures.
- Résultat : Le videur arrête l'IA. « Pas d'entrée. Vous violez la règle des 24 heures. » L'IA dit alors au client : « Je suis désolé, je ne peux pas faire cela », au lieu d'essayer aveuglément d'annuler et d'échouer.

Pourquoi cela importe

L'article a testé ce système à travers quatre mondes différents de service client : Airlines (Compagnies aériennes), Retail (Vente au détail), Telecom et Telehealth (Télésanté). Ils ont utilisé diverses modèles d'IA (à la fois open-source et de grands modèles commerciaux).

Les résultats : LedgerAgent était bien meilleur pour accomplir les tâches, surtout lorsque la tâche nécessitait de changer quelque chose dans le monde réel (comme un remboursement ou une annulation).
Consistance : Le plus grand gain était la consistance. Si vous demandiez à l'IA standard d'effectuer la même tâche 4 fois, elle pourrait réussir une fois et échouer trois fois parce qu'elle s'est embrouillée dans son propre historique de chat. LedgerAgent réussissait de manière beaucoup plus constante sur les 4 essais.
Pas de coût supplémentaire : Contra-irement à d'autres méthodes qui tentent de rendre l'IA « plus intelligente » en l'entraînant sur plus de données ou en utilisant plusieurs cerveaux d'IA, LedgerAgent ne modifie pas du tout le cerveau de l'IA. Il lui donne simplement une meilleure façon d'organiser ses notes et un videur pour vérifier son travail.

Résumé

LedgerAgent est comme donner à un assistant chaotique et amnésique un classeur structuré (le Ledger) et un superviseur strict (la Policy Gate).

Le Classeur garantit que l'assistant connaît toujours les faits actuels sans avoir à fouiller dans de vieux e-mails.
Le Superviseur garantit que l'assistant ne tente jamais de transgresser les règles avant d'effectuer l'action.

L'article affirme que ce changement simple rend les agents d'IA beaucoup plus fiables, précis et polis lorsqu'ils gèrent des tâches complexes de service client.

Résumé Technique : LedgerAgent : État Structuré pour des Agents d'Appel d'Outils Adhérents aux Politiques

Énoncé du Problème

Dans les domaines du service client, les agents linguistiques doivent maintenir des états de tâche à travers de multiples tours d'interaction avec les utilisateurs, tout en récupérant des enregistrements et en exécutant des outils. Ces agents sont tenus d'adhérer à des politiques de domaine strictes (par exemple, l'éligibilité aux remboursements, les fenêtres d'annulation) qui dépendent de l'état actuel de l'interaction.

Les agents d'appel d'outils standards reposent sur une conception uniquement basée sur le prompt, où les observations, les retours d'outils et les instructions de politique sont entrelacés dans un historique de conversation croissant. Cette conception crée deux modes de défaillance principaux :

Ancrage d'État Implicite : Les agents doivent reconstruire les faits pertinents à partir du transcript brut à chaque fois qu'ils décident d'une action. Cela conduit à des décisions basées sur des informations obsolètes, manquantes ou incorrectement reconstruites, même si les enregistrements corrects ont été précédemment récupérés.
Violations de Limites de Politique : Les agents peuvent générer des appels d'outils syntaxiquement valides qui violent les politiques de domaine car la vérification de la politique n'est pas découplée de l'état actuel. Par exemple, un agent pourrait tenter d'annuler une réservation en dehors de la fenêtre autorisée parce qu'il a échoué à croiser la date actuelle avec la date de réservation stockée dans l'historique.

Les solutions existantes se concentrent souvent sur l'amélioration du modèle lui-même (via le fine-tuning ou l'apprentissage par renforcement) ou sur l'ajout d'échafaudages au moment de l'inférence (planification/réflexion). Cependant, ces approches préservent largement la nature implicite de la représentation de l'état au sein du prompt, laissant l'agent récupérer l'état à partir d'un transcript non structuré.

Méthodologie : LedgerAgent

Les auteurs introduisent LedgerAgent, une méthode d'inférence qui découple la gestion de l'état de l'historique brut du prompt. Elle introduit deux composants déterministes qui opèrent sans modifier les poids du modèle ni nécessiter d'appels LLM supplémentaires pour la construction de l'état :

1. Grand Livre Ancré par Schéma (Schema-Anchored Ledger)

L'agent maintient un dictionnaire typé séparé (le grand livre ou ledger) qui stocke les états de tâche observés.

Mécanisme : Lorsqu'un outil de lecture (read-tool) réussit, la valeur de retour est analysée et projetée dans le grand livre en fonction d'une carte de chemin d'outil spécifique au domaine pré-définie (ex: orders.1234, reservations.UX789).
Propriétés : Le grand livre est une représentation compacte et typée des faits observés, des identifiants et des conditions. Ce n'est pas un résumé ou une mémoire à long terme, mais une vue structurée de l'état du système externe tel qu'observé par l'agent.
Règle de Mise à Jour : Le grand livre se met à jour uniquement à partir des retours réussis des outils de lecture. Les retours des outils d'écriture (write-tools) ne mettent pas à jour le grand livre ; l'agent doit émettre un appel de lecture ultérieur pour observer le nouvel état, garantissant que le grand livre reste ancré dans le système externe.
Intégration : Avant chaque génération du modèle, le grand livre complet est rendu de manière déterministe et injecté dans le prompt. Cela permet au modèle de rechercher l'état actuel via des chemins stables plutôt que de chercher dans l'historique du transcript.

2. Porte de Politique (Policy Gate)

Une porte de politique opère immédiatement avant l'exécution de tout appel d'outil modifiant l'environnement (ex: remboursements, annulations, mises à jour).

Fonction : La porte évalue l'appel d'outil proposé par rapport à un ensemble de prédicats exécutables ( $\Pi$ ) définis sur les champs du grand livre actuel.
Résultats :
- AUTORISER (ALLOW) : L'appel est cohérent avec le grand livre et la politique ; il procède sans changement.
- RÉVISER (REVISE) : L'appel viole une politique (ex: manque de preuves). L'appel est supprimé, et le modèle reçoit un feedback identifiant le prédicat violé.
- BLOQUER (BLOCK) : L'appel est explicitement interdit (ex: tentative d'une action violant la politique). L'action est refusée, et l'agent est empêché de modifier l'environnement.
Implémentation : Les politiques sont encodées sous forme de prédicats de code sur les champs du grand livre (par exemple, vérifier si une date de vol est à moins de 24 heures de l'heure actuelle), plutôt que de s'appuyer sur un raisonnement en langage naturel dans le prompt.

Boucle de l'Agent

La méthode enveloppe la boucle d'agent standard. Elle absorbe les retours d'outils dans le grand livre, rend le grand livre dans le prompt, génère une réponse et filtre les appels modifiant l'environnement à travers la porte de politique. Crucialement, cela n'ajoute aucun appel LLM supplémentaire au processus d'inférence ; l'overhead est limité au formatage de chaînes déterministe et à l'évaluation de prédicats.

Contributions Clés

Identification de l'Ancrage d'État comme Mode de Défaillance : L'article identifie que les agents échouent souvent non pas parce qu'ils ne peuvent pas récupérer des enregistrements, mais parce qu'ils agissent sur un état obsolète ou incorrectement reconstruit lorsque cet état reste implicite dans le prompt.
Framework LedgerAgent : Une nouvelle méthode d'inférence qui sépare la représentation de l'état (via un grand livre typé) de l'exécution de l'action (via une porte de politique), garantissant que les politiques dépendantes de l'état sont vérifiées par rapport aux preuves observées avant les changements d'environnement.
Validation Empirique : Démonstration que LedgerAgent améliore les métriques de cohérence ( $pass^k$ ) à travers divers domaines de service client et différents modèles de base sans modifier les poids du modèle.

Résultats Expérimentaux

Les auteurs ont évalué LedgerAgent à travers quatre domaines (Compagnie aérienne, Commerce de détail, Télécom, Télésanté) en utilisant un mélange de modèles à poids ouverts et fermés (incluant GPT-4.1, GPT-5.2, Kimi K2.5, GLM-5, MiniMax M2.5, et Qwen3).

Gains de Performance : LedgerAgent a systématiquement amélioré les scores moyens de $pass^1$ $p a s s^{1}$ et $pass^4$ $p a s s^{4}$ par rapport aux bases d'appel de fonctions standard.
- Sur les modèles non-GPT (ex: Kimi-K2.5), le $pass^1$ moyen s'est amélioré de 3,4 points et le $pass^4$ de 5,6 points.
- Sur les modèles GPT, les améliorations sont encore plus prononcées, avec des gains moyens de $pass^1$ de 12,2 (GPT-4.1) et 15,5 (GPT-5.2) points.
Cohérence : Les gains les plus importants ont été observés dans le $pass^4$ (cohérence sur quatre essais indépendants), indiquant que LedgerAgent réduit significativement la variance du comportement de l'agent.
Tâches Modifiant l'Environnement : La méthode a montré une force particulière dans les tâches nécessitant des actions d'écriture (ex: annulations, remboursements), où la prévention des violations de politique est critique. Dans le domaine des Télécoms (cadre de double contrôle), LedgerAgent a considérablement augmenté la fiabilité au niveau de l'action.
Efficacité : Contra-irement aux méthodes d'ingénierie de contexte comme IRMA (qui utilisent des agents auxiliaires et engendrent un overhead de jetons > 50%), LedgerAgent a atteint une meilleure performance avec 0,0 % d'overhead de jetons par rapport à la base, car il n'ajoute pas d'appels LLM supplémentaires.

Analyse d'Erreur

L'analyse des trajectoires échouées a révélé que les erreurs restantes dans LedgerAgent sont principalement :

Actions Requises Manquées (70,3 %) : L'agent termine les recherches initiales mais échoue à exécuter les étapes nécessaires suivantes (ex: transférer prématurément vers un support humain au lieu de tenter une exécution partielle valide).
Mauvais Arguments d'Action (20,4 %) : Erreurs d'extraction ou de formatage d'arguments, particulièrement dans les domaines avec des schémas complexes comme la Télésanté.
Spécificité du Domaine : Les échecs varient selon le domaine (ex: les échecs de Télécom sont presque exclusivement des actions manquées ; la Télésanté présente un taux d'erreur d'argument plus élevé), suggérant que bien que le grand livre résolve l'ancrage de l'état, la planification spécifique au domaine et la conscience du schéma restent des défis.

Signification et Revendications

L'article affirme que LedgerAgent répond à une lacune architecturale fondamentale des agents d'appel d'outils : la dépendance à un état implicite au sein d'un prompt croissant. En rendant l'état observé explicite et en vérifiant les actions par rapport à un grand livre structuré avant l'exécution, la méthode :

Déplace la limite de défaillance de la correction post-hoc (corriger les erreurs après qu'elles se produisent) vers la prévention (bloquer les violations de politique avant qu'elles ne surviennent).
Fournit un mécanisme de système pour l'adhérence aux politiques qui complète les capacités de raisonnement du modèle sans nécessifier de réentraînement ou d'orchestration multi-agents complexe.
Démontre que la représentation de l'état est aussi critique que la capacité du modèle pour un usage d'outils fiable dans des environnements dynamiques et contraints par des politiques.

Les auteurs concluent que bien que LedgerAgent ne remplace pas le besoin de planification ou de construction robuste d'arguments, il élimine efficacement une source majeure d'imprévisibilité : agir sur un état obsolète ou non ancré. L'approche est plus efficace dans les domaines d'utilisation d'outils structurés où l'état peut être mappé à un schéma et les politiques peuvent être encodées comme des prédicats exécutables.