Agents IA : 5 modèles pour une mémoire et un état optimisés

Mémoire et État pour les Agents IA

Créer un agent d'intelligence artificielle est une tâche complexe qui devient encore plus ardue lorsqu'il s'agit de maintenir son efficacité sur une période prolongée, comme six mois. Les modèles de langage de grande taille, ou LLMs, sont conçus pour être sans état. Cela signifie que chaque interaction avec le modèle commence à partir de zéro, sans souvenir des échanges précédents. Au début, les développeurs ont tenté de contourner ce problème en intégrant l'historique complet des conversations dans la fenêtre de contexte, espérant ainsi que le modèle pourrait s'en servir efficacement.

Cependant, cette méthode a rapidement montré ses limites. Les modèles souffrent de latences accrues et leur capacité à utiliser les informations du contexte se dégrade. Les faits pertinents peuvent être noyés dans un flot d'informations, et lorsqu'il existe plusieurs versions d'un même fait, rien ne garantit que le modèle choisira la version la plus récente. De plus, les coûts en tokens augmentent considérablement, bien que la mise en cache des invites ait permis de réduire ce problème pour les préfixes stables. La solution ne réside pas dans l'augmentation de la taille de la fenêtre de contexte, mais plutôt dans une approche architecturale délibérée de la gestion de la mémoire et de l'état.

Avant de plonger dans les différents modèles, il est crucial de clarifier les termes "mémoire" et "état", souvent confondus. L'état est une photographie instantanée de ce que l'agent sait actuellement sur une tâche donnée : l'étape en cours, le dernier appel d'outil effectué, et les variables suivies. Il peut être comparé à un tableau blanc qui est constamment mis à jour au fur et à mesure de l'avancement de la tâche. À la fin de la session, cet état disparaît, sauf si l'on choisit de le conserver, ce qui est l'objet du Modèle 2.

La mémoire, en revanche, est le mécanisme qui permet de transporter l'information au-delà des frontières immédiates : vers le tour suivant, la session suivante, ou même un agent différent exécuté ultérieurement. La mémoire de travail concerne le court terme (tour à tour), tandis que la mémoire sémantique et épisodique s'étend sur plusieurs sessions.

Ces deux concepts interagissent dans un cycle spécifique. Au début d'une tâche, l'agent consulte la mémoire pour établir son état initial, en chargeant les faits pertinents, les règles comportementales applicables et les enregistrements d'échecs passés sur des tâches similaires. Pendant la tâche, l'état est continuellement mis à jour. À mesure que la tâche progresse et se termine, l'agent écrit des fragments sélectionnés de cet état dans la mémoire pour que le tour ou la session suivante puisse bénéficier des événements passés. La mémoire alimente l'état, et l'état enrichit la mémoire.

Cette distinction est cruciale car les modes de défaillance diffèrent. Un état défaillant signifie que l'agent perd le fil de sa tâche en cours. Une mémoire défaillante empêche l'agent d'apprendre, de personnaliser, et le force à traiter chaque interaction comme une nouvelle page blanche. Ces deux types de défaillances sont courants dans les systèmes de production et nécessitent des solutions distinctes.

Les cinq modèles suivants abordent ces problématiques : les Modèles 1 et 2 se concentrent sur la gestion de l'état, tandis que les Modèles 3 et 4 construisent la couche de mémoire qui persiste entre les sessions, et le Modèle 5 contraint les deux.

1. Le Tampon de Travail en Contexte (Exécution à Court Terme)

Le Concept

La mémoire de travail est responsable de la gestion de l'état éphémère de la session en cours. Elle inclut l'invite active, les échanges récents et les sorties d'outils en direct. On peut la comparer à l'espace de travail à court terme de l'agent, qui est vidé à la fin de la session.

Comment ça fonctionne

Au lieu de laisser la liste des messages s'allonger indéfiniment, le tampon de travail fonctionne comme une fenêtre glissante. L'agent consigne les étapes de raisonnement immédiates sur un bloc-notes. Lorsque le tampon atteint une limite de tokens, un processus de résumé compresse les échanges plus anciens en un résumé dense, conservant les conclusions logiques et éliminant les sorties brutes des outils. À la fin de la tâche, le tampon est vidé : les informations précieuses sont extraites vers des stockages à long terme, tandis que le reste est supprimé.

Il est important de noter que ce processus de résumé en cours de conversation peut modifier le préfixe de l'invite, ce qui invalide le cache KV et provoque un pic de latence lors de l'appel suivant. Ce compromis doit être pris en compte lors de la conception.

Quand l'utiliser

Chaque agent a besoin de ce mécanisme. C'est la base pour gérer le raisonnement multi-étapes au sein d'une session.

2. Point de Contrôle d'Exécution (Tolérance aux Pannes et Pause)

Une fois que l'on a une stratégie pour gérer ce que l'agent conserve en mémoire pendant une session, la question suivante est de savoir comment gérer les interruptions de session.

Le Concept

Les tâches de longue durée sont sujettes à l'échec. Un agent peut expirer, atteindre une limite de taux, ou être mis en pause en attendant l'approbation d'une action par un humain. Le point de contrôle sauvegarde l'état de travail de l'agent dans une base de données, permettant ainsi de reprendre l'exécution exactement là où elle s'était arrêtée, sans avoir à répéter le travail déjà accompli.

Comment ça fonctionne

Les frameworks basés sur des graphes modélisent les flux de travail sous forme de nœuds et d'arêtes. Après chaque étape, le framework enregistre l'état du flux de travail, y compris les variables, l'historique et la position actuelle, dans un stockage durable tel que PostgreSQL ou SQLite. Si l'agent plante, il recharge le dernier point de contrôle et reprend à partir de là.

Un défi fréquent pour les praticiens est que la reprise ne garantit pas une exécution unique. Si un nœud a été partiellement exécuté avant de planter (par exemple, en envoyant un e-mail ou en écrivant une ligne dans la base de données), il peut être réexécuté lors de la reprise. Les nœuds ayant des effets secondaires doivent être idempotents. Il est également important de noter que les poignées de fichiers ouverts et les objets client ne peuvent pas être enregistrés, ce qui limite ce qui peut être sécurisé dans l'état.

Quand l'utiliser

Essentiel pour les systèmes nécessitant une intervention humaine, les flux de travail réglementés où les actions nécessitent une approbation, et toute tâche de longue durée sujette à des pannes réseau.

3. Mémoire Sémantique (Connaissances Inter-Sessions)

Le point de contrôle gère la continuité au sein d'une tâche. Mais qu'en est-il des connaissances qui doivent survivre à des sessions complètement distinctes ?

Le Concept

La mémoire sémantique représente ce que l'agent sait : les faits, les préférences utilisateur et les connaissances de domaine qui persistent à travers des sessions indépendantes.

Comment ça fonctionne

Les faits sont extraits de manière asynchrone et stockés dans une base de données externe, généralement un magasin vectoriel avec filtrage de métadonnées, parfois associé à un graphe de connaissances où la traversée des relations est cruciale. Lorsqu'une requête arrive, le système récupère les faits les plus pertinents et les injecte dans l'invite avant que le modèle ne les traite. Il est important de noter que l'extraction peut nécessiter un appel LLM supplémentaire ou plus, selon l'architecture, souvent un par tour.

Un défi à prendre en compte lors de la conception est la gestion des faits contradictoires : si un utilisateur mentionne "J'utilise Postgres" en mars et "nous avons migré vers Snowflake" en juillet, les deux faits se retrouvent dans le magasin. La récupération pourrait faire surface l'un ou l'autre. L'invalidation des faits, par le biais de pondération de récence, de logique de supplantation ou de TTL, est essentielle pour résoudre le problème des faits obsolètes.

Il est également crucial de préciser que les identifiants et secrets ne sont pas de la mémoire sémantique. Ne stockez pas les clés API dans un magasin récupérable. Une injection d'invite ou une récupération excessive pourrait les divulguer dans une réponse du modèle. Les secrets doivent être stockés dans un gestionnaire de secrets, où l'agent obtient un identifiant de credential sans jamais voir la valeur.

Le risque inverse est également important : un contenu non fiable (une page récupérée, un message utilisateur, une sortie d'outil) extrait dans la mémoire sémantique comme un "fait" peut orienter l'agent de manière persistante dans la mauvaise direction. Comme il n'existe pas d'équivalent d'invite pour la paramétrisation, pas de séparation stricte entre instructions et contenu, le marquage de provenance est crucial : suivez d'où vient un fait et limitez son influence en conséquence.

Quand l'utiliser

Assistants personnels, copilotes de codage, ou agents d'entreprise qui doivent se souvenir du style de code préféré d'un utilisateur, des directives architecturales ou des conventions de schéma de base de données entre les sessions.

4. Journaux Événementiels Épisodiques (Réflexion Historique)

La mémoire sémantique stocke ce que l'agent sait ; la mémoire épisodique stocke ce que l'agent a fait.

Le Concept

La mémoire épisodique agit comme un registre chronologique de la trajectoire d'exécution de l'agent : Objectif, Plan, Appels d'Outils, Résultat.

Comment ça fonctionne

Lorsque le flux de travail se termine, un processus en arrière-plan enregistre cette trajectoire complète. Avant que l'agent ne s'attaque à une tâche similaire, il interroge ce journal. S'il a précédemment échoué à une requête de base de données en raison d'une erreur de syntaxe, la mémoire épisodique fait remonter ce contexte afin que l'agent ne répète pas l'erreur.

Une mise en garde : les traces d'échec récupérées sont consultatives, pas contraignantes. Le modèle peut les ignorer. Il y a aussi un risque de contamination : si un échec environnemental unique est enregistré comme un échec de stratégie, vous enseignez de manière persistante à l'agent la mauvaise leçon. Enregistrez cela à l'esprit.

Quand l'utiliser

Agents de codage autonomes, pipelines d'ingénierie des données, et systèmes de planification qui doivent apprendre des erreurs passées sans intervention humaine.

5. Ségrégation Multi-Portée (Confidentialité d'Entreprise)

Une fois que la mémoire persiste, la question est de savoir qui peut la voir. Dès que votre système sert plus d'un utilisateur, la mémoire doit être isolée.

Le Concept

La mémoire n'est pas un seul seau partagé. Un fait appris en aidant l'Utilisateur A ne doit jamais apparaître pour l'Utilisateur B.

Comment ça fonctionne

Chaque écriture en mémoire est étiquetée avec des portées d'identité : user_id, session_id, org_id. La récupération filtre strictement en fonction du jeton d'authentification de l'utilisateur actif. Lorsque cela est possible, appliquez cela au niveau de stockage, à travers des espaces de noms par locataire ou une sécurité au niveau des lignes, plutôt que de se fier uniquement aux filtres de requête au niveau de l'application. Une clause WHERE oubliée échoue en mode ouvert ; l'isolation au niveau du stockage échoue en mode fermé.

C'est une condition préalable à la conformité en matière de confidentialité des données, pas la ligne d'arrivée. Le problème plus difficile est la suppression : lorsque un utilisateur exerce son droit à l'effacement, vous devez supprimer non seulement ses données brutes, mais aussi les embeddings, résumés et faits extraits qui en découlent.

Quand l'utiliser

Tout produit SaaS, système multi-locataire, ou déploiement d'entreprise où les frontières des données doivent être respectées.

Résumé

Ces modèles ne couvrent pas à eux seuls les limites de croissance. Sur un déploiement de six mois, les magasins sémantiques et épisodiques accumuleront des quasi-duplicatas, des entrées obsolètes et du bruit. La qualité de récupération se dégrade à mesure que les magasins se remplissent, et le coût augmente avec eux. Les TTL, les travaux de consolidation et les politiques de taille sont des éléments essentiels ; ils font partie de l'exploitation de la mémoire à grande échelle.

La fenêtre de contexte n'est pas une base de données. Lorsque vous découplez la mémoire en composants distincts, les tampons à court terme pour l'exécution, la mémoire épisodique et sémantique doivent être gérées avec soin pour éviter les problèmes de performance et de coût.