Résumé Technique : Évolution Unifiée du Contexte pour les Agents LLM

Énoncé du Problème

Les agents basés sur les Grands Modèles de Langage (LLM) excellent dans la résolution de tâches interactives multi-étapes en entremêlant le raisonnement et le retour d'information de l'environnement. Cependant, une limitation critique persiste : chaque épisode de tâche commence généralement par un contexte fixe (instructions du système, démonstrations de type few-shot), rendant les stratégies ou les enseignements découverts lors d'un épisode spécifique éphémères. Une fois la tâche terminée, ces découvertes sont perdues.

Les approches existantes pour résoudre ce problème d'« oubli » se divisent en deux catégories, présentant toutes deux des inconvénients significatifs :

1. Apprentissage par Renforcement (RL) : Des méthodes qui mettent à jour les poids du modèle via la descente de gradient. Bien qu'efficaces, elles nécessitent l'accès aux paramètres du modèle et une infrastructure de calcul substantielle, ce qui les rend inapplicables aux LLM fermés (closed-source).
2. Adaptation Intra-Tâche : Des méthodes telles que l'auto-critique verbale (Reflexion) ou l'affinement itératif (Self-Refine) qui améliorent les performances au cours d'une seule tâche, mais rejettent les améliorations une fois la tâche terminée.
3. Bibliothèques de Connaissances Inter-Tâches : Des systèmes qui accumulent des connaissances à travers diverses tâches, mais qui stockent souvent ces informations dans des réservoirs non typés (mélangeant tous les enseignements) ou se concentrent sur une forme unique de connaissance (par exemple, uniquement les compétences ou uniquement les flux de travail). De plus, ces systèmes reposent souvent sur une évaluation ponctuelle pour juger la qualité des connaissances plutôt que de suivre leur utilité par un usage répété.

Le défi central abordé est de savoir comment maintenir une bibliothèque de connaissances persistante et évolutive qui distingue différents types fonctionnels de connaissances, suit la qualité par l'usage et alloue dynamiquement les ressources de génération aux zones les plus faibles de la bibliothèque, le tout sans mettre à jour les poids du LLM sous-jacent.

Méthodologie : Évolution Unifiée du Contexte (UCE)

Les auteurs proposent l'Évolution Unifiée du Contexte (UCE), un cadre sans gradient où le contexte de l'agent devient le lieu même de l'apprentissage. L'UCE externalise l'expérience de l'agent dans une bibliothèque évolutive d'Unités de Contexte Évolutives (ECU).

1. Unités de Contexte Évolutives (ECU)

La bibliothèque décompose l'expérience en quatre entrées de connaissances fonctionnellement complémentaires et typées :

• Mémoire (Memory) : Énoncés factuels sur les mécanismes de l'environnement découverts par essais et erreurs au sein d'une instance de tâche unique (ex: « Un évier peut nettoyer des objets sans actionner de robinet »).
• Stratégie (Strategy) : Règles de décision conditionnelles (SI-ALORS) pour les points de branchement au sein d'un type de tâche spécifique (ex: « Si 'poser' échoue, ouvrir le réceptacle et réessayer »).
• Flux de Travail (Workflow) : Séquences d'exécution canoniques généralisées pour un type de tâche spécifique (ex: « Trouver la cible $\to$ Transformer $\to$ Placer dans le réceptacle »).
• Compétence (Skill) : Sous-opérations multi-étapes réutilisables applicables à différents types de tâches (ex: « Chercher des réceptacles, ouvrir des contenants, prendre la cible »).

Chaque ECU est un tuple $(z_e, \tau_e, w_e, c_e, f_e)$, où $z_e$ est le type, $\tau_e$ est le type de tâche applicable, $w_e$ est une condition de récupération, $c_e$ est le contenu injecté, et $f_e$ est un score de fitness.

2. Cycle de Vie et Récupération

Le cadre opère par cycles d'évolution, chacun composé de cinq phases :

• Évaluer (Evaluate) : L'agent est testé sur un ensemble d'évaluation tenu à l'écart en utilisant la bibliothèque actuelle. Les taux de succès sont enregistrés, mais aucun score de fitness n'est mis à jour pour éviter la fuite de données.
• Collecter (Collect) : L'agent s'exécute sur un ensemble de collecte disjoint. Les trajectoires sont stockées, et les scores de fitness sont mis à jour en fonction des résultats.
• Planifier (Schedule - Knowledge Yield Scheduling - KYS) : Un module analyse l'état de la bibliothèque (écarts de couverture, distributions de fitness) pour allouer un budget de génération ($B$) entre les quatre types d'ECU. Il donne la priorité aux types où la bibliothèque est la plus faible (ex: types de tâches non couverts ou fitness moyen faible).
• Générer (Generate) : Des générateurs spécifiques au type distillent des candidats ECU à partir des trajectoires collectées. Crucialement, les générateurs utilisent un test de mélange (reshuffle test) pour filtrer les observations spécifiques à une instance (ex: « La pomme de terre est sur le Comptoir 1 ») au profit de mécanismes généralisables (ex: « Le frigo fonctionne quand il est fermé »). Ils utilisent également les retours de qualité provenant des ECU à haut et bas fitness pour guider la génération.
• Nettoyer (Cleanup) : Les ECU de faible valeur ou redondants sont élagués. Un score de fitness avec lissage de Laplace ($f_e = \frac{s_e + 1}{u_e + 2}$) suit la contribution empirique, où $s_e$ est le crédit de résultat cumulé et $u_e$ est le nombre d'utilisations.

La récupération (Retrieval) intervient au moment de la décision. Un récupérateur évalue les ECU selon la similitude sémantique avec la description de la tâche, un boost de correspondance avec le type de tâche, et le score de fitness de l'ECU. Les $K$ meilleurs ECU par type sont injectés dans des sections dédiées du prompt système de l'agent.

Contributions Clés

1. Représentation de Connaissance Typée : L'introduction des ECU, qui décomposent l'expérience de l'agent en quatre types distincts et fonctionnellement complémentaires (Mémoire, Stratégie, Flux de travail, Compétence), chacun ayant ses propres conditions de génération et limites de récupération.
2. Cadre d'Évolution Unifiée du Contexte : Un système complet de gestion du cycle de vie comprenant la Planification du Rendement des Connaissances (KYS) pour allouer dynamiquement les ressources de génération, et un score de fitness basé sur l'usage pour suivre la qualité par une application répétée plutôt que par une extraction ponctuelle.
3. Validation Empirique : Démonstration que l'UCE améliore significativement les performances des agents sur des benchmarks interactifs et que la bibliothèque de connaissances accumulée est transférable entre différents noyaux de raisonnement (ex: ReAct, Plan-and-Act, NoThinking) sans réentraînement des modèles.

Résultats Expérimentaux

Le cadre a été évalué sur deux benchmarks interactifs textuels : ALFWorld (tâches domestiques) et WebShop (achats en ligne).

• Gains de Performance :
  • ALFWorld : L'UCE a augmenté le taux de succès global de 75,4 % (baseline ReAct) à 96,3 % à son apogée. Des améliorations significatives ont été observées dans les types de tâches plus faibles, comme « Look » (50,0 % $\to$ 100,0 %).
  • WebShop : L'UCE a amélioré le score moyen des tâches de 45,1 % à 61,3 % et le taux de succès d'achat de 30,0 % à 42,0 %.
• Transférabilité : La bibliothèque d'ECU générée par l'UCE a été transférée avec succès vers d'autres noyaux d'acteurs. Par exemple, l'application de la bibliothèque UCE au noyau « Plan-and-Act » a fait passer son taux de succès de 73,1 % à 97,8 %.
• Études d'Ablation :
  • Sur ALFWorld, les ECU de type Flux de travail (Workflow) seuls ont représenté la majorité des gains, suggérant que les squelettes procéduraux sont très efficaces pour ce domaine.
  • Sur WebShop, aucun type d'ECU seul n'a égalé la performance de la bibliothèque complète. La tâche d'achat nécessite une combinaison de Flux de travail (guidage procédural), de Stratégie (récupération après des pièges de navigation) et de Mémoire (faits sur les mécanismes de page), soulignant la nécessité de l'approche multi-type.
• Significativité Statistique : Les améliorations par rapport à la baseline ReAct sont statistiquement significatives ($p < 0,05$) sur les deux benchmarks.

Signification et Revendications

L'article affirme que l'UCE offre une alternative pratique, sans gradient, à l'apprentissage par renforcement pour améliorer les agents LLM, particulièrement pour les modèles fermés où les mises à jour de poids sont impossibles. En traitant le contexte comme une entité apprenante et évolutive, l'UCE comble le fossé entre l'exécution de tâches isolées et l'apprentissage persistant.

Les auteurs soulignent que la capacité du cadre à distinguer les types de connaissances et à suivre la qualité par l'usage répond aux limitations spécifiques des systèmes de connaissances inter-tâches précédents, qui traitent souvent tous les enseignements comme égaux ou échouent à adapter les ressources de génération en fonction de la maturité de la bibliothèque. Les résultats suggèrent que pour les tâches interactives, le « quoi savoir » (contexte récupéré) est aussi crucial que le « comment agir » (noyau de raisonnement), et qu'une bibliothèque structurée et évolutive peut efficacement capturer et réutiliser le « comment savoir » dérivé de l'expérience.

L'article reste modeste quant aux implications futures, notant que les types d'ECU actuels sont conçus à la main et que la capacité de l'UCE à passer à l'échelle vers des ensembles de tâches plus vastes ou des espaces d'actions continus (ex: AndroidWorld) reste une question ouverte. Il reconnaît également que l'évaluation actuelle repose sur des paires de modèles spécifiques et des espaces d'actions discrets, laissant le désenchevêtrement entre la conception du framework et la capacité du générateur comme sujet d'investigation future.