Résumé Technique : SodaMem

Problématique

Les agents LLM à long terme assistant les utilisateurs sur plusieurs semaines font face à quatre modes de défaillance critiques que les journaux RAG plats, les logs Markdown et les simples banques de vecteurs ne parviennent pas à résoudre :

1. Actualité/Conflit : Les journaux en mode ajout uniquement (append-only) peinent à déterminer l'état actuel lorsque les préférences s'inversent (ex: « J'adore les plats épicés » vs « Je réduis ma consommation d'épices »), laissant souvent le LLM deviner quel segment est le plus récent.
2. Structure Temporelle : Les systèmes échouent lors de requêtes de dates relatives (« récemment », « il y a deux mois ») lorsqu'ils manquent d'une chronologie comparable ou lorsque les expressions relatives manquent d'un ancrage clair.
3. Provenance : La confiance est affaiblie par des résumés qui perdent de l'information et des hits vectoriels opaques qui manquent de citations vers des segments de dialogue spécifiques.
4. Association : La synthèse multi-sauts peut s'effondrer en raison d'une confusion de contexte, récupérant des souvenirs sémantiquement similaires mais présentant un décalage épisodique, plutôt que d'établir de véritables liens entre entités et affirmations.
   Le domaine est passé de la question « le modèle peut-il trouver une aiguille ? » à « l'agent peut-il maintenir un modèle cohérent et actualisable de l'utilisateur et l'utiliser dans les bonnes conditions ? ».

Méthodologie : SodaMem

SodaMem est une infrastructure de mémoire de graphe temporel fondée sur des preuves, conçue pour maintenir un état utilisateur citable et actualisable. Elle fonctionne via un pipeline Ingestion–Stockage–Planificateur–Lecteur.

1. Structure de Données Centrale : FactEvents

La mémoire est structurée en FactEvents, définis comme des tuples $f = (\kappa, \pi, m, \tau, \rho, S, \sigma)$ :

• Type ($\kappa$) et Prédicat ($\pi$) : Faits typés.
• Modalité ($m$) et Champs Temporels ($\tau$) : Inclut le temps de mention, le temps d'occurrence et les intervalles de validité.
• Rôles d'Entité ($\rho$) : Rôles structurés pour les entités.
• Segments de Source ($S$) : Liens de provenance obligatoires vers des « MessagePieces » spécifiques dans le dialogue brut.
• Statut ($\sigma$) : Actif, supplanté ou invalide.

2. Ingestion et Maintenance

• Extraction : Un LLM extrait les candidats des sessions de dialogue, imposant une contrainte stricte selon laquelle toutes les affirmations doivent être liées à des segments de source littéraux.
• Résolution Temporelle : Un post-traitement optionnel résout les dates relatives (ex: « il y a deux jours ») en horodatages comparables basés sur le temps de la session.
• Logique de Supplantation : Lorsqu'un nouveau fait met à jour un créneau sujet-prédicat concurrent, le système crée des liens SUPERSEDES (supplante), CONTRADICTS (contredit) ou UPDATES (met à jour). L'intervalle de validité du fait ancien est fermé et son statut est marqué comme supplanté.

3. Stockage et Indexation

• Persistance : Les faits sont stockés dans SQLite avec une indexation hybride :
  • Lexicale : BM25 sur le texte des faits, les segments et les tours bruts.
  • Dense : Embeddings vectoriels (ex: MiniLM/GTE) pour la similitude sémantique.
  • Graphe : Liens entre les faits via des voisins sémantiques et des relations typées.
• Relations de Graphe : Inclut des liens DERIVED FROM (dérivé de) vers les segments et des liens temporels (SUPERSEDES, etc.).

4. Récupération : Multi-Tunnel et Fusion de Densité de Connexion

La récupération évite de reposer sur un seul signal (ex: la similitude cosinus seule) en utilisant une approche à trois tunnels :

1. Tunnel Graphe/Entité (Fort) : Atteint les entités ou les faits en tant que têtes de recherche et s'étend via des sauts de 1 ou de plusieurs niveaux par des liens sémantiques/relationnels.
2. Tunnel BM25 (Fort) : Hits lexicaux sur les faits, les segments ou les tours bruts, s'étendant aux tours temporellement adjacents pour le contexte.
3. Tunnel Embedding (Faible) : Voisins denses avec des modèles d'expansion similaires au BM25 mais avec des poids de base plus faibles pour éviter de récupérer des épisodes liés mais non pertinents.

Fusion et Classement :

• Portes de Validité : Des filtres stricts excluent les faits marqués comme invalides/supplantés ou hors d'une fenêtre de validité déclarée.
• Densité de Connexion : Les preuves sont classées par l'accumulation de « masse » provenant de multiples hits (directs et dérivés) à travers les tunnels.
• Score Temporel Souple : Au lieu de filtres temporels rigides, un « bonus de temps » est ajouté à la confiance du classement si le fait tombe dans la fenêtre de requête de l'utilisateur. Cela permet au système de se rétablir d'un mauvais datage de l'utilisateur (ex: « il y a deux mois » pour un fait vieux de 3 mois).

5. Réponse : Boucle Planificateur–Lecteur

• Planificateur : Un agent LLM peut appeler de manière itérative des outils (recherche, inspection, extension de session) pour accroître le pool de preuves si le classement de densité initiale est insuffisant.
• Lecteur : Un LLM distinct compose la réponse finale en utilisant les identifiants d'évidence sélectionnés, imposant des citations obligatoires aux enregistrements sources. Cette séparation garantit que la discipline de citation est distincte de la politique d'outil.

Contributions Clés

1. Cadrage du Problème : Le papier synthétise la recherche sur la mémoire des agents pour isoler l'actualité, la structure temporelle, la provenance et l'association comme les modes de défaillance spécifiques laissés non résolus par le RAG plat et les logs Markdown.
2. Architecture du Système : SodaMem introduit un pipeline comprenant un schéma de FactEvent typé, une récupération hybride (graphe + lexicale + dense), une sémantique de supplantation pour la résolution de conflits, et une boucle planificateur–lecteur pour une réponse fondée sur des preuves.
3. Évaluation Coût–Précision : Les auteurs compilent les systèmes publics avec des coûts d'API estimables dans une carte unifiée coût–précision, analysant la région « dominée » (coût plus élevé, précision plus faible) par rapport à leur propre système.

Résultats

Évalué sur LongMemEval-S (500 questions, ~115k tokens d'historique) :

• Précision : SodaMem a atteint une précision de 92,8 % (464/500) dans une configuration de registre de référence (meilleur de N=3).
• Efficacité des Coûts :
  • Coût Moyen : 0,00161 $ par question (~18,3k tokens) en utilisant deepseek-v4-flash.
  • Coût Médian : 0,00111 $ par question (~14,6k tokens).
• Comparaison :
  • SodaMem se situe près de la frontière de précision tout en opérant à un niveau de dépense de type « Flash ».
  • Il domine strictement plusieurs systèmes publiés (ex: Cersei Embed/Hybrid, AgentOS, MemoryBank) qui offrent une précision moindre pour des coûts nettement plus élevés (utilisant souvent des modèles de classe GPT-4o ou Opus).
  • Bien que les systèmes de haut niveau comme agentmemory V4 (96,2 %) et Mem0 (94,4 %) atteignent des scores plus élevés, ils le font avec un coût estimé d'un ordre de grandeur supérieur (utilisant Opus/GPT-4o).

Signification et Revendications

Le papier affirme que SodaMem démontre qu'une mémoire personnelle de haute précision et fondée sur des preuves ne nécessite pas de modèles massifs aux contextes coûteux ou des logs non structurés. En traitant la mémoire comme un graphe de connaissances temporel avec une logique de supplantation explicite et une boucle planificateur–lecteur, le système permet :

• État Maintenable : Un modèle cohérent et actualisable de l'utilisateur qui gère les inversions de préférences de manière déterministe.
• Auditabilité : Chaque affirmation est appuyée par un segment de source, répondant au manque de provenance des systèmes RAG actuels.
• Efficacité des Coûts : Il atteint une précision proche de la frontière (92,8 %) pour une fraction du coût des systèmes reposant sur des modèles haut de gamme, « sous-coupant » efficacement les systèmes à haut budget de type Opus/GPT-4o d'un facteur de ~10 à 40x en coût estimé par question.

Les auteurs notent des limites, notamment le recours à l'auto-évaluation (utilisation du même modèle Flash comme juge) et le fait que les comparaisons de coûts sont des estimations compilées plutôt qu'un test direct unifié. Cependant, les résultats suggèrent que les graphes temporels structurés et fondés sur des preuves constituent une voie viable pour les agents à long terme.