Aller au contenu

Traduction automatique

Cet article a été traduit automatiquement depuis la version originale en anglais.

Mémoire des agents IA : État typé guidé par un schéma pour les systèmes à exécution prolongée

Les agents échouent rarement parce qu’ils ont oublié tout ce qu’ils savent. Ils échouent plutôt parce qu’ils se souviennent d’une information ancienne et la traitent comme étant l’état actuel.

Imaginons un assistant fonctionnant en continu qui sert une utilisateur nommée Mira. Lors d’une conversation, Mira indique que la date limite de son passeport est le 15 juillet. Plus tard, elle la corrige en indiquant le 30 juin. Une recherche vectorielle peut retrouver cette ancienne note, mais elle ne peut pas, par elle-même, déterminer quelle date limite est valable actuellement. C’est là la différence entre la capacité de rappel et la véritable mémoire.

En résumé : considérez la mémoire persistante de l’agent comme un état d’application typé. Extraitez les données potentiellement stockables via une interface à sortie structurée, enregistrez les enregistrements avec des paramètres de portée par utilisateur, des plages de validité, des mécanismes de remplacement, des informations sur l’origine des données et une gestion des versions du schéma, puis récupérez la partie la plus récente nécessaire lors de la lecture. La recherche vectorielle peut rester intégrée au système, mais elle ne doit pas servir de source fiable pour les données modifiables.

Le piège de la fenêtre de contexte

La fenêtre de contexte représente un ensemble de données en cours d’utilisation. Ce n’est ni une mémoire persistante, ni une base de données.

Les agents fonctionnant sur le long terme doivent conserver des préférences, l’état des tâches, des informations sur les clients, des décisions relatives aux outils, des notes de conformité ainsi que des erreurs antérieures. La solution la plus simple consiste à ajouter des résumés ou à stocker les anciennes notes dans un stockage vectoriel. Cette approche fonctionne tant que les données mémorisées ne changent pas.

Or, l’agent peut alors avoir deux dates limites différentes, deux formats préférés ou deux décisions liées à un projet. La recherche sémantique peut afficher les deux versions, un résumé peut écraser l’une d’elles, et un contexte trop long peut inclure la version obsolète à côté de la version active. Aucun de ces comportements ne constitue un contrat de mémoire fiable.

Le contrat doit répondre à des questions concrètes :

  • Qu’est-ce qui est vrai actuellement ?
  • Qu’est-ce qui était vrai le 2 juin ?
  • Qui l’a dit ?
  • À quel locataire cela appartient-il ?
  • Quel fait antérieur ce fait a-t-il remplacé ?
  • Puis-je le supprimer ou le faire expirer ?

C’est là que commence la Schema-Guided Agent Memory (SGAM).

Ce que signifie SGAM

Le nom nécessite une petite clarification avant que l’architecture ne devienne compréhensible.

Schema-Guided Dialogue (SGD) est l’ensemble de données de dialogue orienté tâche de Google de 2019. Son schéma décrit les API de service, les intentions et les slots, permettant ainsi à un modèle de dialogue de suivre l’état des services qu’il n’a jamais vus auparavant. C’est un précédent utile, mais dans une couche différente.

Schema-Guided Memory (SGM) est le terme de recherche utilisé par Mei et al. dans According to Me: Long-Term Personalized Referential Memory QA. Cet article compare la Memory descriptive (DM) en texte libre avec des éléments de mémoire clé-valeur à schéma fixe. Les informations sources sont identiques ; seule la représentation change.

Schema-Guided Agent Memory (SGAM) est le pattern d’ingénierie que cet article définit : utiliser des schémas pour gérer les écritures, mises à jour, récupérations et suppressions de la mémoire d’agent persistante. Le schéma n’est pas simplement un format de note plus agréable. C’est le contrat qui définit l’état.

ATM-Bench rend cette motivation concrète. Il utilise environ quatre ans de données de mémoire personnelle provenant d’e-mails, d’images et de vidéos, puis pose des questions nécessitant des références personnelles, une connaissance de la localisation, plusieurs éléments de preuve ainsi que des mises à jour dans le temps. Les systèmes de mémoire actuels obtiennent de mauvais résultats face à cette complexité, tandis que SGM surpasse DM car des champs tels que le temps, la source, la localisation, les entités et les étiquettes sont mis à disposition du récupérateur et du répondant sous forme structurée plutôt que sous forme de texte libre.

C’est pourquoi la prochaine comparaison porte sur SGAM versus SGR. Le raisonnement guidé par un schéma n’est pas une déviation aléatoire : il constitue précisément la « porte d’écriture » dont a généralement besoin SGAM.

SGR est la porte d’écriture

Le raisonnement guidé par un schéma (SGR) et la mémoire d’agent guidée par un schéma (SGAM) résolvent des parties distinctes du même problème de production.

J’ai utilisé SGR comme élément de base récurrent dans ce blog. L’original vLLM et l’article sur XGrammar ont décrit le mécanisme. Les articles suivants l’ont appliqué à juges structurés, planificateurs et routeurs, et grilles d’évaluation RAG reproductibles. Dans tous ces cas, SGR a restreint l’appel afin que la réponse soit suffisamment valide pour être consommée par le code.

SGAM emprunte cette discipline mais modifie la durée de vie de la réponse. Celle-ci n’est plus simplement un verdict, une route ou un plan relatif à la demande en cours ; elle devient une écriture potentielle dans la mémoire qui peut influencer des sessions futures ainsi que des appels d’outils. C’est pourquoi les similitudes et les différences sont importantes.

SGR limite un appel au modèle. Il oblige le modèle à générer un objet valide pour l’étape d’inférence en cours, généralement via Pydantic, JSON Schema, des sorties structurées propres au fournisseur, ou un environnement de décodage guidé tel que XGrammar.

SGAM décide de ce qui se passe une fois que cet objet existe. Faut-il le stocker ? Remplace-t-il une donnée plus ancienne ? Quel utilisateur en a accès ? S’agit-il d’une donnée actuelle ou historique ? Quel épisode de source le prend en compte ?

Dimension SGR SGAM
Champ d’application Une étape d’inférence ou une appel d’outil Cycle de vie de la mémoire durable
Format Pydantic ou JSON Schema pour la requête Enregistrements structurés, schémas et relations
Application Sortie structurée ou contraintes liées au temps de décodage Validation, contraintes de base de données, règles de conflit
Durée de vie Généralement éliminé après la réponse Persiste entre les sessions et s’exécute
Mode de défaillance Extraction invalide ou sémantiquement faible État obsolète, pollué, non délimité ou non auditable

Le motif est :

structured extraction on write -> typed memory at rest -> scoped retrieval on read

SGR assure que l’extraction soit suffisamment fiable pour être stockée en mémoire. SGAM garantit que cette mémoire soit suffisamment sécurisée pour être réutilisée ultérieurement.

from datetime import datetime
from pydantic import BaseModel, Field


class MemoryDelta(BaseModel):
    tenant_id: str = Field(description="Isolation boundary, e.g. acme")
    subject: str = Field(description="Normalized entity ID, e.g. mira")
    attribute: str = Field(description="Property being updated")
    value: str = Field(description="New value")
    valid_from: datetime
    source_episode_id: str

Cet objet n’est pas le système de mémoire. Il représente la frontière entre une conversation désordonnée et le registre de mémoire.

Les deux flux

Ce flux de travail comporte deux parcours distincts. Leur mélange est la cause principale pour laquelle les diagrammes deviennent complexes et illisibles.

Le parcours d’ingestion représente le chemin d’écriture :

  1. Capturer un épisode brut provenant de messages, des résultats d’outils ou d’événements métier.
  2. Extraire des candidats structurés à partir de ces données brutes.
  3. Valider le schéma et rejeter les enregistrements mal formatés.
  4. Résoudre les conflits, fermer les données obsolètes et conserver la traçabilité.
  5. Enregistrer l’information dans le stockage SGAM.

Le parcours de demande correspond au chemin de lecture :

  1. Partir de la question posée par l’utilisateur.
  2. Déterminer si la question nécessite l’état actuel ou l’état à un instant donné.
  3. Filtrer les données en fonction du locataire, du type de mémoire, du sujet, des attributs et de la fenêtre de validité.
  4. Ajouter une expansion vectorielle ou graphique uniquement lorsque la recherche de l’état exact n’est pas suffisante.
  5. Assembler le contexte le plus réduit possible à fournir au modèle.

Architecture de mémoire d’agent guidée par un schéma

Consultez ce diagramme de gauche à droite en deux voies. La voie supérieure écrit dans la mémoire. La voie inférieure lit dans la mémoire. Le stockage est partagé, mais les responsabilités ne le sont pas.

Ce qui doit figurer dans un schéma de mémoire

Un enregistrement SGAM minimal nécessite plus que text.

tenant_id
memory_id
subject
attribute
value
memory_type
schema_version
valid_from
valid_to
supersedes_memory_id
source_episode_id
confidence
retention_policy

Ce format rend explicites les opérations ordinaires. Une nouvelle date limite de passeport peut remplacer l’ancienne sans supprimer l’historique. Une requête peut demander l’état actuel ou un état à un instant donné. Une réponse peut citer l’épisode source correspondant. Une migration peut déterminer quelle version du schéma a généré un enregistrement. Un processus de suppression peut identifier quels index nécessitent un nettoyage.

SGAM n’est pas anti-vecteur. Les vecteurs sont utiles pour le rappel flou, le clustering et l’expansion. Cependant, la valeur actuelle de mira.passport_deadline Il doit provenir d’un enregistrement de mémoire ciblé, et non du premier morceau qui se trouve être classé en tête.

Un exemple de fait obsolète

La démonstration SGAM la plus concise et utile est un registre pour cet exemple Mira comprenant deux épisodes.

e1: Mira prefers concise answers. Her passport deadline is 2026-07-15.
e2: Mira corrected the deadline. It is now 2026-06-30.

Une recherche dans la mémoire de texte peut restituer e1 car il contient les mots appropriés. Un magasin enregistré par saisie doit renvoyer e2 pour l'état actuel et conserver e1 pour une requête historique.

Le comportement du côté écriture est mineur :

def close_previous_fact(db: sqlite3.Connection, fact: MemoryFact) -> int | None:
    row = db.execute(
        """
        select fact_id
        from memory_facts
        where tenant_id = ?
          and subject = ?
          and attribute = ?
          and valid_to is null
        order by valid_from desc
        limit 1
        """,
        (fact.tenant_id, fact.subject, fact.attribute),
    ).fetchone()
    if not row:
        return None

    db.execute(
        "update memory_facts set valid_to = ? where fact_id = ?",
        (fact.valid_from, row["fact_id"]),
    )
    return int(row["fact_id"])

Le comportement attendu est précisément l’objectif principal.

Naive text memory:
  returned episode: e1 -> passport deadline is 2026-07-15

SGAM current state:
  mira.passport_deadline = 2026-06-30
  valid_from=2026-06-03T10:00:00Z, source=e2

SGAM point-in-time state:
  on 2026-06-02, mira.passport_deadline = 2026-07-15

En environnement de production, associez cette transaction à une extraction structurée au niveau du chemin d’écriture. La base de données élimine ainsi les états obsolètes. Le modèle n’a pas besoin de deviner quelle note ancienne est encore applicable.

Outil ou framework Couche de stockage principale Gestion temporelle Mécanisme de schéma Niche pratique
Zep / Graphiti Neo4j, FalkorDB, Neptune, prise en charge des systèmes Kuzu anciens Élevé Entité Pydantic et types d’arêtes, arêtes temporelles, provenance Mémoire de graphe temporel
LangGraph / LangMem LangGraph stores, stores basés sur Postgres Moyen JSON permet de stocker des profils Pydantic ou d’extraire des collections Les applications d’agent déjà développées sur LangGraph
Mem0 Stack gérée, backends Valkey / Redis / vector dans des configurations OSS Moyen Types de mémoire, catégories personnalisées, prompts d’extraction Mémoire utilisateur, d’agent et de session en tant que service
Letta / MemGPT État de l’agent et blocs de mémoire gérés par une base de données Faible Agents à état disposant d’une gestion du contexte de type système d’exploitation
Cognee Backends graphiques, vectoriels et relationnels Moyen Extraction et validation orientées ontologie Mémoire du graphe de connaissances d’entreprise
Graphe de propriétés LlamaIndex Les entrepôts de graphes de propriétés et les entrepôts vectoriels Faible à moyen SchemaLLMPathExtractor avec les entités et relations autorisées Extraction de graphes à partir de documents et de traces

Graphiti constitue la référence open source la plus pertinente lorsque votre mémoire est de nature relationnelle et temporelle. Il permet de suivre l’évolution des faits au fil du temps, de conserver l’historique des épisodes sources, et prend en charge des méthodes de récupération hybrides. LangGraph représente une bonne couche d’application, car elle sépare les points de contrôle par thread des stockages inter-thread. Mem0 s’avère utile lorsque l’on souhaite des opérations de mémoire gérées, plutôt que de devoir gérer soi-même toute l’infrastructure de stockage. Letta se rapproche davantage des blocs de contexte modifiables que des systèmes SGAM au niveau des champs, mais son cadre basé sur des agents à état reste pertinent.

Ne commencez pas par le graphique le plus sophistiqué à moins que le domaine ne l’exige. Pour de nombreuses équipes, une table relationnelle contenant des en-têtes JSON, des colonnes de validité, des index de locataire, ainsi qu’un sidecar vectoriel suffit pour la première version.

Guide de mise en œuvre

La première décision d’implémentation n’est pas « stockage graphique ou vectoriel ? », mais plutôt ce que le produit est autorisé à mémoriser.

Un agent de support peut conserver en mémoire le niveau du compte, les cas ouverts ainsi que les préférences de contact durables. Il ne doit pas transformer systématiquement chaque demande frustrée en un enregistrement dans le profil utilisateur. Un agent de codage peut mémoriser les conventions de dépôt et les tâches non résolues. Il ne doit pas conserver indéfiniment une note privée simplement parce qu’elle a été consultée une seule fois.

Commencez par le flux d’écriture et considérez la mémoire comme une petite mutation d’état :

  1. Nommez le type de mémoire, le sujet, la portée du locataire et la classe de conservation.
  2. Extraitez les enregistrements candidats avec une sortie structurée.
  3. Validez le payload à l’aide de Pydantic ou de la couche de schéma déjà utilisée dans votre stack.
  4. Résolvez les conflits avant insertion, y compris pour déterminer si le nouvel enregistrement remplace l’ancien.
  5. Conservez un pointeur vers la source brute : l’épisode, le résultat de l’outil, le fichier, le ticket ou la confirmation de l’utilisateur ayant généré l’enregistrement.
  6. Enregistrez la version du schéma avec l’enregistrement, et ce, non seulement dans le code de l’application.

Pour de nombreuses équipes, le premier stockage SGAM peut être une table relationnelle contenant une colonne JSON et quelques index. Il n’est pas nécessaire de commencer par un graphe de connaissances temporel. Le graphe devient utile lorsque les relations sont importantes : client–compte, compte–politique, tâche–artefact, utilisateur–préférence, projet–décision.

Flux principal et écritures en arrière-plan

L’extraction immédiate est pertinente lorsque la prochaine action dépend de cette nouvelle mémoire. Si l’utilisateur demande de « se souvenir que je préfère des réponses courtes », le système ne doit pas attendre une tâche nocturne pour modifier son comportement.

La plupart des interactions ne se déroulent pas de cette manière. La solution la plus économique consiste à écrire rapidement l’épisode brut, à y ajouter les métadonnées relatives au locataire/session/outil, puis à laisser un travailleur en arrière-plan extraire ultérieurement des souvenirs potentiels. La consolidation basée sur la récurrence est une version de cette politique : on stocke temporairement les interactions à faible signal et on ne présente un fait que lorsque des preuves similaires se reproduisent ou que l’utilisateur le confirme explicitement. Le compromis réside dans un léger retard en termes de fraîcheur des informations. Cela est acceptable dans les cas où « l’utilisateur demande fréquemment des exportations en CSV », mais moins acceptable pour des situations comme « le client a modifié son adresse de livraison ».

Le chemin de lecture doit être moins sophistiqué que le chemin d’écriture. Il faut d’abord répondre à la question « quel état suis-je autorisé à utiliser ? », puis demander si la recherche floue peut apporter du contexte utile.

  1. Filtrer par locataire, type de souvenir et fenêtre de validité.
  2. Récupérer d’abord l’état structuré exact, avant les voisins sémantiques.
  3. Utiliser l’expansion vectorielle ou graphique pour obtenir des preuves complémentaires, des entités liées et des exemples, mais pas comme source d’autorité pour les faits actuels.
  4. Assembler le plus petit ensemble de contexte cité capable de répondre à la question.

Traiter la migration des schémas comme une tâche liée au produit. Lorsqu’un enregistrement de souvenir change de structure, le comportement de l’agent change également : ce qu’il peut se remémorer, ce qu’il peut citer, ce qu’il peut supprimer, ainsi que quels anciens faits restent considérés comme actuels. Il convient de placer les scripts de migration, les données de rattrapage, les fenêtres de lecture doubles et le comportement de suppression dans le même plan de déploiement que la modification du produit.

Où SGAM trouve son utilité

SGAM est particulièrement adapté lorsque les souvenirs sont étatiques et évoluent dans le temps :

  • Préférences de l’utilisateur qui peuvent être mises à jour ou révoquées ;
  • Données clients ou relatives au compte soumises à des exigences d’audit ;
  • État des tâches pour les assistants à exécution prolongée ;
  • Mémoire de projet du code-agent ;
  • État partagé entre plusieurs agents ;
  • Notes de conformité où l’origine des données est cruciale ;
  • Questions temporelles telles que « en quoi croyions-nous avant la migration ? »

C’est un surdimensionnement lorsque la mémoire est éphémère, exploratoire ou facile à recalculer. Si l’agent n’a besoin que de quelques étapes de continuité, un point de contrôle ainsi qu’un historique de messages affiné suffisent. Pour le contrôle qualité de documents statiques, RAG peut être suffisant. Si votre schéma change tous les jours en raison d’un domaine encore flou, SGAM ralentira vos travaux.

Liste de vérification d’évaluation

Ne jugez pas la mémoire uniquement en lisant la réponse finale. Un système de mémoire peut répondre poliment même s’il a écrit une information incorrecte, récupéré une donnée obsolète ou franchi une limite entre différents utilisateurs au cours de sa recherche.

Sa structure est proche de la répartition utilisée dans mon Article d’évaluation RAG: mesurer l’étape du pipeline où la défaillance peut survenir, et non seulement le texte généré à la fin. Cela recoupe également les principes de traçabilité provenant de L’article d’évaluation des agents: une erreur de mémoire apparaît souvent dans l’historique d’exécution avant de se manifester dans la réponse.

Pour SGAM, le test le plus fiable est la réexécution. Fournissez une séquence fixe d’épisodes au writeur de mémoire, examinez le registre après chaque tour significatif, puis posez des questions relatives à l’état actuel et à un instant donné en vous basant sur le stockage résultant.

Couche Échec que vous recherchez Mesures
Écrire l’extraction L’agent a manqué un fait, en a inventé un, ou a généré une forme invalide. Taux d’écriture conforme au schéma, précision/recouvrement de l’extraction, couverture des épisodes sources
Gestion des conflits Un fait obsolète est resté en vigueur, ou un fait ancien valide a été écrasé. Correctitude de la suppression, taux de doublons, correctitude de l’invalidation des faits obsolètes
Isolation et politiques Fuite de mémoire entre utilisateurs ou persistance au-delà de la fenêtre de validité prévue Échecs d’isolation des tenants, correction des opérations de suppression, conformité en matière de conservation des données
Recherche de lecture Le enregistrement correspondant existe bien, mais le lecteur ne l’a pas récupéré. Précision à l’état courant, précision au moment donné, rappel@k sur les enregistrements de mémoire
Ancrage des réponses La réponse a utilisé de la mémoire sans justification ni référence à une source appropriée. Demander un soutien concernant les épisodes sources, la précision des citations et la correction de la résolution des conflits
Opérations Le chemin mémoire est trop lent, trop obsolète ou trop coûteux. p95 de latence d’écriture, retard de fraîcheur, latence de lecture, coût par requête

Des benchmarks tels que LoCoMo, LongMemEval, et ATM-Bench Fournir des signaux externes utiles. Ceux-ci ne remplacent pas un ensemble de tests de domaine. La mémoire est déterminée par la charge de travail : un assistant de codage, un bot de support client et un copilote de conformité nécessitent des schémas, des filtres, des règles de conservation et des tests d’échec différents.

Précautions à prendre

SGAM est mon étiquette pour un motif, et non une norme. Le secteur utilise déjà des noms superposés pour des éléments appartenant au même espace de conception : Mémoire LangGraph et LangMem Abordons les mémoires à court et long terme, les profils, les collections, les écritures sur les chemins fréquents, ainsi que les gestionnaires de mémoire en arrière-plan. Zep Graphiti il qualifie la version en forme de graphe de Graphe de contexte temporel. Letta il modélise le système comme des agents à état disposant de blocs de mémoire persistants. Mem0 elle se présente comme une couche de gestion de la mémoire. Microsoft GraphRAG, Les graphes de propriétés LlamaIndex et Cognee utilisent le langage des graphes de connaissances pour résoudre des problèmes de récupération d’informations et d’ontologie associés.

Ces noms ne sont pas interchangeables. Certains systèmes gèrent les profils d’utilisateurs, d’autres gèrent les épisodes. D’autres encore construisent un contexte graphique à partir de documents, tandis que d’autres fournissent à l’agent des outils pour modifier sa propre mémoire. SGAM représente une version plus stricte de cette approche : lorsque la mémoire durable représente l’état actuel de l’application, elle nécessite un schéma, une validation, une traçabilité, un mécanisme de gestion des conflits, des règles de conservation et de migration.

Une mémoire structurée peut tout de même contenir des erreurs. Un schéma permet de détecter plus facilement les écritures erronées, mais il ne garantit pas leur fiabilité. Il reste nécessaire de faire confiance à la source, d’obtenir la confirmation de l’utilisateur pour les informations sensibles, de disposer d’une politique de gestion des conflits, de pouvoir supprimer des données et de surveiller leur état.

La migration de schémas est une tâche complexe. Une fois que la mémoire devient un état persistant, vous êtes responsable de la gestion des versions, du remplacement des anciennes données, des enregistrements obsolètes ainsi que du comportement de suppression. C’est le prix à payer pour obtenir un état actuel fiable, plutôt qu’un amas de notes plausibles.

Points clés

  1. Le contexte correspond à un ensemble de travail. La mémoire d’un agent durable nécessite un contrat d’état distinct.
  2. SGR et SGAM se complètent : il faut d’abord valider l’écriture, puis préserver le cycle de vie typé de la mémoire en état de repos.
  3. Le rappel vectoriel est utile, mais les faits actuels exigent une définition de portée, une validation, une possibilité de suppression et une traçabilité de provenance.
  4. Commencez par un registre de mémoire relationnel simple ou basé sur JSON avant de recourir à un graphe.
  5. Évaluez la mémoire en fonction de la correction des écritures, du retraitement temporel, du rattachement aux données réelles, de l’isolation des utilisateurs et du comportement de suppression.

Références