💬 NLP

PolicyBank: Evolving Policy Understanding for LLM Agents

Le papier présente PolicyBank, un mécanisme de mémoire qui permet aux agents LLM d'affiner autonomement leur compréhension des politiques organisationnelles grâce à des interactions et des retours correctifs, comblant ainsi jusqu'à 82 % des écarts d'interprétation que les méthodes existantes ne parviennent pas à résoudre.

Auteurs originaux : Jihye Choi, Jinsung Yoon, Long T. Le, Somesh Jha, Tomas Pfister

Publié 2026-04-20

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jihye Choi, Jinsung Yoon, Long T. Le, Somesh Jha, Tomas Pfister

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 embauchez un assistant virtuel très intelligent (un agent IA) pour gérer les réclamations de votre compagnie aérienne ou d'un magasin. Ce robot est très doué, mais il a un problème majeur : il suit les règles à la lettre, même si ces règles sont mal écrites ou incomplètes.

Voici l'histoire de PolicyBank, une nouvelle méthode pour apprendre à ce robot à devenir plus sage, racontée simplement.

1. Le Problème : Le Robot qui suit un manuel défectueux

Imaginez que vous donnez à votre assistant un manuel d'instructions (la politique) écrit en langage naturel.

La règle écrite : « Si un client se plaint d'un retard de vol ET qu'il veut changer son billet, alors offrez-lui un bon de compensation de 50 $. »
La réalité (ce que vous vouliez vraiment) : « Si un client se plaint d'un retard, offrez-lui un bon, qu'il change son billet ou non. »

Le robot lit le manuel et dit : « Désolé, vous ne voulez pas changer votre billet, donc pas de bon. »
Il a parfaitement suivi les instructions, mais il a échoué à satisfaire le client. C'est ce que les chercheurs appellent un « écart de politique » : le texte officiel ne correspond pas à la vraie intention de l'entreprise.

Les anciens systèmes d'IA essayaient de corriger le robot en lui disant : « Tu as mal calculé, recommence ! » Mais ici, le calcul était juste, c'est la recette qui était fausse.

2. La Solution : PolicyBank (La Banque de Mémoire Vivante)

Les auteurs proposent PolicyBank, qui fonctionne comme un journal de bord intelligent ou une mémoire évolutive.

Au lieu de traiter le manuel initial comme une vérité absolue et immuable, PolicyBank permet à l'agent de mettre à jour sa compréhension au fil du temps grâce aux erreurs.

Voici comment cela se passe, étape par étape, avec une analogie culinaire :

A. La Cuisine Initiale (Le Manuel)

Au début, l'agent suit une recette de base (le manuel écrit). Il cuisine des plats (répond aux clients).

B. Le Goût du Chef (Le Feedback)

Un jour, le chef (un développeur ou un testeur) goûte le plat et dit : « Attends, ce client voulait juste une compensation pour le retard, pas pour un changement de billet ! Tu as suivi la recette, mais le plat n'est pas bon. »

C. Le Journal de Recettes (PolicyBank)

C'est là que PolicyBank intervient. Au lieu de simplement dire « Recette ratée », l'agent écrit dans son Journal de Recettes (PolicyBank) :

« Note importante : La règle sur le "changement de billet" n'est pas obligatoire pour les membres or. La vraie règle est : Retard + Membre Or = Compensation. »

D. La Nouvelle Recette (L'Évolution)

La prochaine fois qu'un client arrive, l'agent ne regarde pas seulement le vieux manuel. Il consulte son Journal de Recettes qu'il a lui-même enrichi. Il se souvient de la leçon apprise et applique la nouvelle règle.

3. Comment ça marche techniquement (sans les mots compliqués)

Le système utilise trois ingrédients magiques :

Des "Sœurs" de tâches (Les Tests) : Pour s'assurer que l'agent a vraiment compris, ils créent des variations du même problème.
- Exemple : Si l'agent apprend à donner une compensation à un client nommé "Paul", on lui donne un client nommé "Marie" dans une situation similaire. Si l'agent réussit avec Marie, c'est qu'il a compris le principe, pas juste mémorisé le nom "Paul".
L'Agent de Politique (Le Chef de Cuisine) : C'est un second robot, plus sage, qui analyse les erreurs du premier robot après chaque tâche. Il ne se contente pas de noter l'erreur ; il écrit la leçon dans le journal pour que le robot ne la refasse plus jamais.
La Mémoire Structurée : Au lieu de stocker des tonnes de texte, PolicyBank stocke des règles précises (ex: "Si X, alors Y, sauf si Z"). C'est comme transformer un roman flou en une liste de règles claires.

4. Les Résultats : Pourquoi c'est génial ?

Dans les tests, les robots classiques (qui ne peuvent pas changer leurs règles) échouaient presque totalement quand la règle écrite était imparfaite (0 % de réussite sur les nouveaux cas).

Avec PolicyBank :

L'agent apprend de ses erreurs.
Il comble jusqu'à 82 % de l'écart entre ce qui était écrit et ce qui était vraiment nécessaire.
Il devient plus fiable et constant, comme un employé qui apprend de ses erreurs au lieu de répéter bêtement un manuel obsolète.

En résumé

PolicyBank, c'est comme donner à un robot un cahier de notes où il peut écrire ses propres corrections. Au lieu d'être coincé dans un manuel mal écrit, il devient capable de comprendre l'esprit de la loi plutôt que de se contenter de lire les lettres de la loi.

C'est la différence entre un robot qui dit « Je ne peux pas faire ça, c'est interdit par le manuel » et un robot qui dit « Ah, j'ai appris que dans ce cas précis, le manuel avait une erreur, je vais vous aider quand même ! ».

1. Problématique : Le fossé entre spécification et exigence

Les agents basés sur les grands modèles de langage (LLM) opèrent souvent dans des environnements contraints par des politiques organisationnelles (règles d'entreprise, conformité réglementaire, logique métier). Ces politiques sont généralement spécifiées en langage naturel (NL).

L'article identifie un problème fondamental : les spécifications en langage naturel sont intrinsèquement ambiguës, incomplètes ou contiennent des contradictions logiques. Cela crée un écart entre :

La politique spécifiée ( $\pi_{spec}$ ) : Ce qui est écrit dans les documents ou les prompts système.
La politique requise ( $\pi_{req}$ ) : La véritable logique métier ou l'intention réelle des développeurs.

Cet écart conduit à deux types d'échecs distincts :

Échec d'exécution (Type I) : L'agent ne parvient pas à suivre les règles écrites (problème de capacité de raisonnement).
Échec d'alignement (Type II) : L'agent suit scrupuleusement les règles écrites, mais le résultat est incorrect par rapport à l'intention réelle. C'est le cas où l'agent est « conforme mais faux ».

Les mécanismes de mémoire existants pour les agents (comme Synapse, AWM, ReasoningBank) traitent la politique comme une vérité immuable. Ils apprennent à exécuter des tâches correctement selon $\pi_{spec}$ , mais ils renforcent involontairement les comportements erronés (Type II) lorsqu'il y a un écart de spécification, car ils ne remettent jamais en question la politique elle-même.

2. Méthodologie : PolicyBank

Pour résoudre ce problème, les auteurs proposent PolicyBank, un mécanisme de mémoire conçu pour permettre aux agents d'évoluer leur compréhension des politiques de manière autonome grâce à l'interaction et aux retours correctifs.

Architecture et Fonctionnement

Mémoire structurée au niveau des outils : Contrairement aux mémoires qui stockent des trajectoires brutes, PolicyBank maintient une banque de connaissances structurée au niveau des capacités des outils (ex: cancel_reservation). Chaque entrée contient un identifiant, un outil, une capacité et un champ spec_nl (spécification en langage naturel).
Format des entrées : Les entrées décomposent les règles ambiguës en logique d'autorisation exécutable :
- TRIGGER : Quand la capacité s'applique.
- PRECONDITIONS : Étapes de vérification.
- ELIGIBILITY : Conditions de permission.
- KEY INSIGHT : La différence apprise entre la spécification initiale et la réalité.
Agent de Politique (Policy Agent) : Un agent dédié (fonctionnant hors ligne après chaque tâche) analyse la trajectoire de l'agent et le feedback du développeur. Il identifie si l'échec provient d'une erreur de raisonnement ou d'un écart de spécification.
Boucle de rétroaction :
1. L'agent exécute une tâche en interrogeant dynamiquement PolicyBank via un outil retrieve_policy().
2. Un développeur fournit un feedback (signal binaire + explication en langage naturel).
3. L'Agent de Politique met à jour la mémoire (Ajout, Révision ou Suppression d'entrées) pour corriger l'interprétation de la politique sans réécrire manuellement les règles.

3. Contributions Clés

Formalisation du problème : L'article définit mathématiquement le problème de « mise à jour de politique avec un agent évolutif », distinguant clairement les échecs d'exécution des échecs d'alignement.
Nouveau Benchmark ( $\tau$ -Bench étendu) : Les auteurs ont étendu le benchmark $\tau$ -Bench (domaines aérien et retail) en y injectant des écarts de politique contrôlés. Ils ont créé des tâches « sœurs » (simplified, different instance, complex variant) pour isoler les échecs d'alignement des échecs d'exécution.
Classification des écarts : Identification de trois classes structurelles d'écarts courants :
- Portée ambiguë (interprétation de l'ensemble).
- Exceptions sous-spécifiées (manque de limites).
- Contradictions logiques (fausses dépendances).
Performance : Démonstration qu'un agent peut autonomiquement affiner son interprétation des politiques imparfaites pour se rapprocher d'un oracle humain.

4. Résultats Expérimentaux

Les expériences ont été menées sur des modèles de pointe (Gemini-3.0-Pro, Claude-4.5-Opus) avec une évaluation en flux continu.

Échec des méthodes de base : Les mécanismes de mémoire existants (Synapse, AWM, ReasoningBank) obtiennent un taux de réussite proche de zéro sur les tâches « sœurs » (qui testent spécifiquement la correction des écarts de politique). Ils échouent car ils ne peuvent pas corriger une spécification erronée qu'ils considèrent comme une vérité absolue.
Performance de PolicyBank :
- PolicyBank comble jusqu'à 82 % de l'écart par rapport à un oracle humain.
- Dans le domaine aérien avec Gemini-3-Pro, le taux de réussite passe de ~0,01 (No Memory) à 0,74 sur les tâches sœurs.
- La méthode améliore également la consistance (mesurée par pass^k), réduisant la variabilité des performances d'un agent, ce qui est crucial pour les applications de production.
Granularité du feedback : Les résultats montrent que le feedback binaire seul est insuffisant pour corriger les écarts de politique (Type II). La combinaison d'un signal de récompense et d'une explication en langage naturel est nécessaire pour que l'agent comprenne quelle clause de la politique est incorrecte.

5. Signification et Impact

Ce travail marque un changement de paradigme dans la conception des agents LLM :

De la conformité statique à l'adaptation dynamique : Au lieu de simplement vérifier si un agent respecte une règle fixe, PolicyBank permet à l'agent d'apprendre que la règle elle-même peut être mal formulée et de l'ajuster.
Robustesse opérationnelle : Dans des environnements réels où les politiques évoluent ou contiennent des ambiguïtés, PolicyBank offre un mécanisme pour corriger les « conformités erronées » sans intervention humaine massive sur le code ou les prompts.
Complémentarité : L'approche ne remplace pas les couches de vérification (guardrails) mais les complète : PolicyBank affine l'interprétation de la politique, tandis que les couches de vérification appliquent les contraintes finales.

En résumé, PolicyBank démontre que les agents LLM peuvent devenir autonomes dans la gestion des imperfections des spécifications en langage naturel, transformant les erreurs d'alignement en opportunités d'apprentissage pour affiner leur compréhension du monde réel.