2026-06-20 · Mis à jour 2026-07-22

[!NOTE] Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

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

Les agents fonctionnant sur de longues périodes récupèrent souvent des faits obsolètes, car la mémoire sémantique ordinaire ne dispose d’aucune règle permettant de déterminer quelles valeurs sont actuelles.

Lorsqu’un utilisateur modifie la date limite d’un passeport de 15 juillet à 30 juin, la recherche vectorielle peut restituer les deux affirmations. Une couche de mémoire à état doit alors enregistrer que la valeur du 30 juin prend le pas sur l’ancienne.

En résumé : Traitez la mémoire durable des agents comme un état d’application typé. Extraitez les candidats mémoire via une frontière d’ sortie structurée, stockez les enregistrements avec un champ de porteur, des fenêtres de validité, des informations de suppression, des données de provenance ainsi que des versions de schéma, puis récupérez la partie actuelle la plus récente lors de la lecture. Réservez la recherche vectorielle aux recherches floues. Lisez les faits modifiables à partir des enregistrements actuels et ciblés.

Le piège de la fenêtre de contexte

La fenêtre de contexte correspond aux données disponibles pour une seule appelation de modèle. Une application peut transmettre des messages dans des appels ultérieurs, mais c’est la politique de l’application qui doit décider quels faits anciens restent valables et qui peut y accéder.

Les agents à exécution prolongée doivent conserver en mémoire des préférences, l’état des tâches, des informations 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 ces anciennes notes dans un entrepôt vectoriel. Cette approche fonctionne tant que l’un des faits mémorisés ne change pas.

Dès lors, l’agent dispose de deux dates limites de passeport, de deux formats préférés ou de deux décisions de projet. La recherche sémantique peut restituer les deux versions. Un résumé peut écraser l’une d’elles. Un contexte trop long peut afficher la version obsolète à côté de la version active. De telles architectures permettent de récupérer du texte sans pour autant garantir l’application de la valeur actuelle.

Le contrat doit permettre de 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 affirmé ?
• À quel porteur appartient cette information ?
• Quel fait antérieur a été remplacé par celui-ci ?
• Puis-je le supprimer ou le rendre périmé ?

La mémoire des agents guidée par un schéma (SGAM) stocke ces réponses sous forme de champs et de relations, plutôt que de les laisser implicites dans du texte narratif.

Ce que signifie SGAM

Trois concepts portant des noms similaires définissent le champ d’application de SGAM.

Le dialogue guidé par un schéma (SGD) désigne le 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 de services qu’il n’a jamais rencontrés auparavant. Il constitue un précédent utile pour le suivi basé sur des schémas, bien que son champ d’application soit limité aux services de dialogue.

La mémoire guidée par un schéma (SGM) est le terme utilisé par Mei et al. dans According to Me: Long-Term Personalized Referential Memory QA. Cet article compare la mémoire descriptive (DM) à texte libre avec des éléments de mémoire clé-valeur à schéma fixe. Les deux représentations contiennent les mêmes informations sources, mais sous des structures différentes.

Dans cet article, j’utilise l’expression la mémoire des agents guidée par un schéma (SGAM) pour désigner un pattern d’ingénierie dans lequel les schémas régissent les écritures, mises à jour, récupérations et suppressions. Le schéma définit ainsi l’état de l’application et son cycle de vie.

ATM-Bench illustre pourquoi cette représentation est importante. Il utilise environ quatre ans de données personnelles issues d’e-mails, d’images et de vidéos. Les questions posées exigent des références personnelles, une localisation, plusieurs preuves ainsi que des mises à jour au fil du temps. Les performances chutent avec une approche basée sur du texte libre, tandis que SGM améliore les résultats par rapport à DM, car le moteur de recherche peut interroger directement des champs tels que la date, la source, la localisation, les entités et les étiquettes.

SGM contre DM répond à une question de stockage : la mémoire doit-elle rester sous forme de texte libre, ou doit-elle utiliser des champs nommés ? Un agent en production se heurte à un autre problème avant le stockage : il doit déduire, à partir d’une conversation non structurée, une mise à jour potentielle de la mémoire. Le Schema-Guided Reasoning (SGR) définit ce parcours décisionnel : examiner les preuves, identifier le sujet et l’attribut, vérifier si le fait modifie l’état existant, puis produire une proposition d’écriture. SGAM applique ensuite les règles de stockage et de cycle de vie suite à cet appel du modèle.

Séparer l’extraction du modèle de la propriété de la mémoire

L’écriture dans la mémoire traverse trois couches. Structured Output (SO) impose la structure de l’objet candidat. Schema-Guided Reasoning (SGR) encode les étapes ainsi que l’ordre que le modèle doit suivre pour parvenir à cet objet candidat. Schema-Guided Agent Memory (SGAM) gère cet objet candidat en le conservant comme état durable après l’appel du modèle.

Un verdict, une route ou un plan expire généralement avec la requête en cours. Une nouvelle exécution peut lire cet objet candidat des jours plus tard ou l’utiliser pour choisir une appel d’outil. Cette durée de vie plus longue exige des règles de stockage que SGR ne fournit pas.

SGR restreint un appel du modèle en définissant sa topologie de raisonnement. Pour une écriture dans la mémoire, le schéma peut exiger des preuves sources, un sujet et un attribut normalisés, une comparaison avec l’état actuel, et uniquement ensuite la mise à jour proposée. Pydantic ou JSON Schema décrit ce parcours. L’Structured Output natif du fournisseur ou un environnement de décodage guidé tel que XGrammar empêchent le modèle de sauter des champs ou de retourner une structure différente.

Le schéma ne peut pas garantir une conclusion correcte. Il rend le parcours décisionnel requis explicite et inspectable, y compris les preuves et les comparaisons qui ont conduit à la proposition d’écriture.

SGAM décide de ce qui se passe une fois que l’objet existe. Doit-il être stocké ? Remplace-t-il un fait antérieur ? Quel utilisateur en a accès ? Est-il actuel ou historique ? Quel épisode source le justifie ?

Le tableau indique la propriété ainsi que les modes de défaillance de chaque couche :

Sur le chemin d’écriture, la séquence est :

SGR reasoning schema + Structured Output -> candidate write -> SGAM policy and persistence

L’extrait illustratif suivant issu de memory_models.py définit l’objet transmis depuis l’extraction vers le service d’écriture SGAM :

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

MemoryDelta montre ce que le modèle a extrait. Le service d’écriture SGAM décide ensuite s’il faut le rejeter, le fusionner ou le stocker.

Les chemins d’écriture et de lecture ont des fonctions distinctes

SGAM dispose d’un chemin d’écriture et d’un chemin de lecture. Seul le chemin d’écriture modifie l’état stocké. Le chemin de lecture sélectionne les enregistrements nécessaires à la demande actuelle.

Le flux d’ingestion correspond au chemin d’écriture :

1. Capturer une épisode brut provenant de messages, de résultats d’outils ou d’événements métier.
2. Extraire des candidats structurés via une sortie formatée.
3. Valider le schéma et rejeter les écritures mal formées.
4. Réconcilier les conflits, fermer les faits obsolètes et conserver la provenance.
5. Enregistrer l’enregistrement dans le stockage SGAM.

Le flux de demande correspond au chemin de lecture :

1. Partir de la question de l’utilisateur.
2. Déterminer si la question nécessite l’état actuel ou un état à un instant donné.
3. Filtrer selon le locataire, le type de mémoire, le sujet, l’attribut et la fenêtre de validité.
4. Ajouter une expansion vectorielle ou graphique uniquement si la recherche d’état exact n’est pas suffisante.
5. Assembler le contexte minimal nécessaire pour le modèle.

Lisez ce diagramme de gauche à droite en deux volets. Le volet supérieur écrit dans la mémoire, tandis que le volet inférieur la lit. Les deux utilisent le même stockage.

Quelles informations doivent 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

Grâce à ces champs, une nouvelle date limite de passeport peut remplacer l’ancienne sans effacer l’historique. La même table permet de répondre aux requêtes actuelles ainsi qu’à des requêtes ponctuelles, puis de tracer le résultat jusqu’à l’épisode source correspondant. schema_version prend en charge les migrations, tandis que retention_policy indique aux tâches de suppression quels autres éléments ils doivent également supprimer.

On utilise RAG pour récupérer les documents et SGAM pour gérer un état mutable. La recherche vectorielle reste indispensable dans le système afin d’assurer la récupération approximative, le clustering et l’expansion des résultats. La valeur actuelle de mira.passport_deadline doit provenir d’un enregistrement de mémoire ciblé, et non du premier chunk classé par ordre.

Exemple de fait obsolète

Considérons un suivi synthétique composé de deux épisodes, représenté par une ligne de base DM et un registre SGAM :

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

Une ligne de base DM conserve les deux épisodes sous forme de texte libre, ce qui permet à une recherche textuelle de retourner e1, car ce dernier contient les mots appropriés. SGAM extrait un fait structuré à partir de chaque épisode, identifié par le locataire, le sujet et l’attribut. Il devrait retourner e2 comme état actuel et conserver e1 pour les requêtes historiques.

La fonction suivante correspond au code de chemin d’écriture de SGAM. Elle serait placée dans un module de stockage tel que sgam_store.py. DM ne dispose pas d’équivalent, car il ne maintient pas de ligne actuelle par attribut. Avant que l’appelant n’insère une valeur de remplacement, cette fonction ferme la ligne actuelle :

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"])

Lorsque e2 arrive, la fonction définit valid_to sur le fait extrait à partir de e1 à la date horaire indiquée par e2. L’appelant insère ensuite le nouveau fait avec un valid_to non finalisé. Comme DM ne possède pas d’étape d mise à jour équivalente, le texte ancien peut encore avoir une priorité supérieure à la correction.

La réalisation de requêtes sur les dates limites actuelles et historiques avec ces deux représentations produit des résultats différents :

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, il convient d’associer cette transaction à une extraction structurée lors du chemin d’écriture. La transaction de base de données met à jour la validité temporelle, tandis que le modèle extrait un fait candidat sans décider quelle ligne stockée reste actuelle.

Les choix de stockage suivent le schéma de récupération

Les projets emploient plusieurs termes pour désigner les différentes composantes de ce schéma : stores de mémoire, graphes de contexte, profils, stores à long terme, RAG graphique et agents à état.

Graphiti constitue une implémentation concrète en open source de mémoire relationnelle temporelle. Il suive l’évolution des faits, conserve des pointeurs vers les épisodes sources et prend en charge la recherche hybride. LangGraph sépare les points de contrôle par thread des stockages inter-thread. Mem0 encapsule les opérations de mémoire sous forme de service géré. Letta utilise des blocs de contexte modifiables plutôt qu’un SGAM au niveau des champs, tout en traitant néanmoins l’état de l’agent comme des données persistantes.

Commencez par le modèle de données. Si la recherche précise de faits constitue l’opération principale, une table relationnelle contenant des payloads JSON, des colonnes de validité, des index par locataire ainsi qu’un sidecar vectoriel suffit généralement. Ajoutez un graphique uniquement lorsque la navigation entre relations fait partie des fonctionnalités attendues, et non parce que la démonstration graphique semble impressionnante.

Construire le chemin d’écriture avant le graphe

Il convient d’abord de définir ce que le produit est autorisé à mémoriser. Le choix entre graphe et vecteurs sera abordé ultérieurement.

Un agent de support peut conserver l’échelon du compte, les tickets en cours et les préférences de contact persistantes. Il ne doit pas transformer chaque remarque négative en entrée dans le profil utilisateur. Un agent de codage, quant à lui, peut retenir les conventions du dépôt ainsi que 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 chemin d’écriture et considérez la mémoire comme une petite mutation d’état :

1. Déterminez le type de mémoire, le sujet, la portée par tenant et la classe de conservation.
2. Extraire les enregistrements candidats via une sortie structurée.
3. Valider la charge utile à l’aide de Pydantic ou du layer de schéma déjà utilisé dans votre stack.
4. Résoudre les conflits avant insertion, y compris pour déterminer si le nouvel enregistrement remplace l’ancien.
5. Conserver un pointeur source vers l’épisode brut, le résultat de l’outil, le fichier, le ticket ou la confirmation de l’utilisateur ayant généré l’enregistrement.
6. Indiquer la version du schéma avec chaque enregistrement, plutôt que de la laisser uniquement dans le code applicatif.

Le premier stockage SGAM peut être une table relationnelle comportant une colonne JSON et quelques index. Le graphe devient utile lorsque le produit doit parcourir des relations telles que client→compte, compte→politique, tâche→artefact ou projet→décision.

Chemin en temps réel et écritures en arrière-plan

L’extraction immédiate est justifiée lorsque la prochaine interaction dépend de la 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 n’ont pas besoin d’une écriture immédiate. Sauvegardez l’épisode brut accompagné des métadonnées relatives au tenant, à la session et à l’outil, puis laissez un travailleur en arrière-plan extraire les candidats plus tard. Grâce à une consolidation basée sur la récurrence, ce travailleur stocke temporairement des signaux faibles et ne transforme une information en fait confirmé que lorsque des preuves similaires se reproduisent ou que l’utilisateur le confirme. Cela entraîne un léger retard dans la mise à jour des données. Cela est acceptable pour des cas comme « l’utilisateur demande fréquemment des exportations CSV », mais risqué pour des situations comme « le client a modifié son adresse de livraison ».

Assurez-vous que le chemin de lecture reste déterministe. Appliquez d’abord les contraintes liées au tenant et à la validité, puis utilisez la recherche floue uniquement lorsque cela permet d’ajouter du contexte utile.

1. Filtrez selon le tenant, le type de mémoire et la fenêtre de validité.
2. Récupérez d’abord l’état structuré exact, avant les voisins sémantiques.
3. Utilisez l’expansion vectorielle ou graphique pour obtenir des preuves complémentaires, des entités associées ou des exemples, mais pas comme source d’autorité pour les faits actuels.
4. Assemblez le plus petit ensemble de contexte suffisant pour répondre à la question.

Traitez la migration de schéma comme une modification du produit, car elle affecte ce que l’agent peut se rappeler, citer ou supprimer. Elle peut également changer les faits historiques considérés comme actuels. Planifiez les scripts de migration, les remplacements, les périodes de lecture double et le comportement de suppression dans la même version.

Lorsque SGAM justifie la complexité

Utilisez SGAM lorsque les faits peuvent évoluer dans le temps :

• des préférences utilisateur pouvant être mises à jour ou annulées
• des informations sur les clients ou comptes nécessitant un suivi d’audit
• l’état des tâches pour des assistants fonctionnant sur de longues durées
• la mémoire des projets gérés par des agents de codage
• un état partagé entre plusieurs agents
• des notes de conformité où l’origine des données est importante
• des questions temporelles telles que « en quoi croyions-nous avant la migration ? »

SGAM constitue un surcoût inutile lorsque la mémoire est à durée de vie limitée, utilisée à des fins exploratoires ou dont le recomputation est peu coûteux. Lorsque l’agent n’a besoin que de quelques étapes de continuité, un point de contrôle ainsi qu’un historique de messages réduit suffisent. Pour le contrôle qualité de documents statiques, RAG peut parfois suffire. De plus, dans un domaine en constante évolution où le schéma change chaque jour, l’utilisation d’une mémoire structurée ralentira considérablement l’équipe.

Liste de vérification pour l’évaluation

Il convient d’évaluer non seulement le cycle de vie de la mémoire mais aussi la réponse finale. Un système peut produire une réponse plausible même après avoir écrit un fait erroné, récupéré une information obsolète ou franchi les limites définies pour un utilisateur spécifique.

J’applique la même segmentation par étapes que dans mon article d’évaluation RAG. Il faut mesurer les étapes où une défaillance peut survenir, plutôt que de se limiter à évaluer uniquement le texte généré. La méthode de suivi décrite dans l’article d’évaluation des agents s’applique également, car les bugs liés à la mémoire apparaissent souvent dans l’historique des exécutions avant même d’atteindre la réponse.

Je testerais SGAM en mode replay. Il s’agit d’alimenter l’outil de gestion de mémoire avec une séquence fixe d’épisodes, d’examiner le registre après chaque étape significative, puis de poser des questions relatives à l’état actuel ou à un instant donné en s’appuyant sur le stockage résultant.

Des benchmarks tels que LoCoMo, LongMemEval et ATM-Bench fournissent des cas de test publics. Cependant, ils ne remplacent pas un ensemble de tests adapté au domaine spécifique. Un assistant de codage, un bot de support client ou un copilote de conformité nécessitent des schémas, des filtres, des règles de conservation et des tests de défaillance différents.

Précautions

SGAM est ma désignation pour un schéma de données, et non une norme officielle. D’autres projets abordent ce problème sous des angles différents. LangGraph memory ainsi que LangMem décrivent respectivement les mémoires à court et long terme, les profils, les collections, les écritures sur les chemins fréquemment utilisés, ainsi que les gestionnaires de mémoire en arrière-plan. Zep Graphiti emploie quant à lui l’expression « graphique contextuel temporel ». Letta permet de conserver des blocs de mémoire modifiables, tandis que Mem0 propose une couche de mémoire gérée. Microsoft GraphRAG, les graphes de propriétés de LlamaIndex, et Cognee modélisent les aspects correspondants du problème sous forme de graphes de connaissances.

Un profil d’utilisateur, un journal d’épisodes, un graphe de documents et un bloc de mémoire modifiable par l’agent résolvent des problèmes de récupération et de mise à jour distincts. J’ai réservé le terme SGAM à la mémoire persistante qui représente l’état actuel de l’application, et qui nécessite donc un schéma bien défini, des mécanismes de validation, de traçabilité de l’origine des données, de gestion des conflits, de politique de conservation et de migration.

Même une mémoire structurée peut contenir des erreurs. Un schéma facilite l’inspection des écritures incorrectes, mais ne garantit pas leur fiabilité. Il reste nécessaire de s’appuyer sur la fiabilité de la source, d’obtenir la confirmation de l’utilisateur pour les informations sensibles, de mettre en œuvre des politiques de gestion des conflits, de procéder à des suppressions et d’assurer un suivi continu.

La migration de schémas représente un travail important. Une fois que la mémoire devient un élément constitutif de l’état de l’application, il faut gérer la versionning, les données de remplacement, les anciens enregistrements ainsi que le comportement de suppression. En omettant ces étapes, les anciens enregistrements survivront souvent aux politiques de semantique ou de conservation qui les ont initialement créés.

Références

• According to Me: Long-Term Personalized Referential Memory QA - Article de Mei et al. présentant ATM-Bench et Schema-Guided Memory.
• Towards Scalable Multi-Domain Conversational Agents: The Schema-Guided Dialogue Dataset - Article de Rastogi et al. concernant le dataset SGD.
• LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory - Benchmark de Wu et al. évaluant les capacités de mémoire à long terme des assistants conversationnels.
• Graphiti: Build Temporal Context Graphs for AI Agents
• Zep: A Temporal Knowledge Graph Architecture for Agent Memory
• Mem0 Platform Overview
• Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
• LangGraph Memory Overview
• LangGraph Persistence
• LangMem documentation
• Letta: Introduction to Stateful Agents
• Microsoft GraphRAG documentation
• LlamaIndex: Using a Property Graph Index
• Cognee Documentation
• Pydantic model validation docs
• Python sqlite3 documentation