Mémoire persistante pour agents IA

Présentation

Persistent Memory est une bibliothèque Python pour conserver les informations utilisées par des agents IA, retrouver leurs sources et écarter celles qui ont été corrigées ou retirées. Elle associe une mémoire versionnée à un registre de politiques indépendant. Cette version alpha sous licence MIT fonctionne sous Linux sans modèle ni base externe.

Résultats publics

Garder le fil entre les sessions
Retrouver les informations utiles quand une mission reprend, en tenant compte des corrections et des changements intervenus depuis la session précédente.
Sur huit historiques synthétiques, la mémoire obtient 77 réussites sur 96, contre 29/96 pour une référence lexicale avec contrôle de validité. Le décompte inclut neuf résultats inconnus par configuration.
Lire l’étude sur la continuité entre sessions
Réutiliser l’expérience d’une autre tâche
Une tâche est exécutée, son résultat est vérifié et une leçon en est extraite. La mémoire conserve cette expérience avec ses sources pour la retrouver lors d’une autre tâche, dans une nouvelle session.
Dans l’étude synthétique, Luna réussit 22 tâches sur 24 avec la leçon, contre 13/24 avec la trace complète et le retour, et 7/24 sans expérience.
Lire l’étude sur l’apprentissage entre tâches
Garder une mémoire cohérente après une correction ou une panne
Conserver la trace des sources et de leurs versions, exclure les informations retirées et contrôler une ancienne sauvegarde avant de la réutiliser.
Sur 100 scénarios de cycle de vie, les 751 lectures valides sont conservées et les 389 lectures interdites sont bloquées. La référence SQLite qui conserve une autorité actuelle obtient le même résultat. Les mesures détaillées comprennent les reprises après arrêt de processus.
Lire l’étude sur les corrections et la reprise

Consulter les mesures détaillées et les essais d’intégration

Le noyau 0.3.0a5 est distribué avec ses fichiers d’installation, sommes de contrôle et guides français et anglais ; le registre de politiques indépendant reste en version 0.2.0a2. Le code, les données synthétiques, les protocoles et les calculs hors ligne sont publics.

Sur 100 scénarios de cycle de vie définis à l’avance, les 751 lectures valides sont conservées et les 389 lectures interdites sont bloquées, à égalité avec une référence SQLite conservant une autorité actuelle. Après la modification du noyau, quatre scénarios d’interruption par SIGKILL passent sur chacun des deux hôtes Linux, avec une reprise observée entre 0,227 et 0,383 seconde.

Sur huit historiques synthétiques de développement conservés entre sessions, la mémoire obtient 77 réussites sur 96, contre 29 pour une référence lexicale avec contrôle de validité. Chaque configuration conserve neuf résultats inconnus au dénominateur. La campagne comprend 192 générations sans relance ; deux lecteurs Codex ont évalué les réponses à l’aveugle, sans connaître la configuration.

À 1 000 sources et 50 recherches, une optimisation ciblée du noyau réduit la durée de la charge instrumentée de 28,01 % sur un hôte et de 27,68 % sur l’autre, avec les mêmes résultats vérifiés et les mêmes tailles de fichiers stockés. Chaque chiffre provient d’une seule observation avant et après par hôte.

Une étude complémentaire mesure le chargement initial de 1 000 sources synthétiques, puis le cycle suivant : ajouts, recherches, lectures et retrait. Sur trois comparaisons appariées, la durée du cycle baisse de 2,35 % en médiane et celle du chargement initial de 29,13 %, avec les mêmes résultats vérifiés.

Sur une charge de 1 500 sources suivie de dix ajouts et 50 recherches, une modification ciblée de la validation des identifiants réduit la durée instrumentée de 6,79 % en médiane et le temps CPU de 6,77 %. Les trois nouvelles comparaisons appariées conservent les lectures et les retraits attendus, avec les mêmes tailles de stockage final dans les six exécutions.

Dans une étude distincte, un modèle exécute une tâche A, reçoit un retour sur le fichier réellement produit et en extrait une leçon avant de tenter une tâche B différente dans une nouvelle session.

Sur 48 épisodes et 288 appels aux modèles, Luna réussit 22 tâches B sur 24 avec la leçon, 13 avec la trace complète et le retour, et sept sans expérience. Sol réussit 24 tâches sur 24 avec la leçon comme avec la trace complète, et 12 sans expérience. Les fichiers produits par les 192 tâches B ont été rouverts et vérifiés indépendamment, y compris ceux des deux échecs avec leçon.

Deux sessions d’un agent réel réussissent sept tests sur les mêmes treize scénarios, avec des résultats de qualité identiques. Le message système confirme la transmission automatique des enseignements. Un second agent retrouve l’expérience et produit, sur une mission, un code qui réussit les mêmes tests sans retouche. Le rapport conserve cette proposition non déployée et un défaut situé hors des assertions testées : certaines métriques et un texte secondaire utilisent False ou 0 pour des informations absentes.

Sur 16 missions où la règle précédente restait valable, la mémoire en réussit 10, contre 7 pour une adaptation locale d’ECC. Sur 16 missions soumises à une nouvelle règle, les résultats sont de 11 et 14. Les critères fixés avant les essais ne permettent pas de conclure à un avantage. Le rapport présente les 128 résultats des quatre conditions, les corrections et les ressources consommées.

Rôle et périmètre

Je conçois et développe les mécanismes de stockage, de recherche et de reprise, les interfaces Python et les intégrations HTTP et MCP facultatives. Je maintiens aussi les packages publics, la documentation bilingue, les exemples autonomes et les tests de panne, d’accès concurrents et de retrait des informations.

Problème et contraintes

Un index de recherche ou une sauvegarde restaurée peut encore contenir des preuves corrigées ou retirées. La mémoire doit distinguer les preuves actuelles, les versions périmées et une validation indisponible avant de fournir du contexte à une application.

Architecture

SQLite conserve des versions immuables et les liens entre les sources et les informations qui en découlent. Une autorité séparée et un témoin de fraîcheur déterminent quelles informations restent utilisables. Les index FTS5 reconstruisibles proposent des résultats, vérifiés à nouveau avant leur restitution.

Les enregistrements typés distinguent documents, observations, hypothèses, procédures, tâches et retours d’expérience. Le contexte peut inclure des références sources immuables : chaque ensemble complet texte-référence et les séparateurs comptent dans le même budget. Le texte seul reste le comportement par défaut. La façade HTTP facultative propose aussi un mode limité aux routes typées, avec un espace de travail et un jeton fixes, configurés par l’hôte.

Un module de rendu facultatif transforme des faits fournis et déjà revus en texte, à partir de formulations françaises prédéfinies, en conservant les versions et passages sources. Le module d’admission vérifie l’autorité de l’hôte et le contenu final à transmettre, puis signale les informations inconnues, contradictoires ou retirées.

Choix et compromis

L’autorité valide les preuves ; l’index propose les résultats de recherche. Les écritures utilisent un contrôle compare-and-swap. Une ancienne sauvegarde de contenu est d’abord placée en quarantaine, puis contrôlée par rapport à l’autorité actuelle conservée séparément. Le registre facultatif distingue proposition de politique, preuves, admission et retour arrière. L’hôte contrôle l’activation des politiques et l’attribution des droits.

Tests et vérification

Le noyau 0.3.0a5 et le registre 0.2.0a2 ont passé 215 méthodes de test distinctes : 166 pour le noyau et 49 pour le registre. Les tests des wheels installés, puis de wheels reconstruits depuis les archives source, représentent 430 exécutions par environnement Linux, 860 au total sur deux hôtes. Les téléchargements publics sont identiques à l’octet près aux archives testées. Des études synthétiques distinctes portent sur les corrections, les retraits, les pannes de processus, le temps d’exécution et l’apprentissage entre tâches.

Ressources et liens

Utilisation et intégration

La bibliothèque est distribuée en version alpha. La reprise utilise une autorité actuelle et un témoin de fraîcheur conservés hors de la sauvegarde de contenu restaurée. Le retrait contrôle les lectures ultérieures de la bibliothèque. Les copies exportées et les informations déjà transmises sont gérées par le système destinataire.

Le rendu et l’admission facultatifs reçoivent des faits fournis et revus, sous une autorité d’hôte authentifiée. Pour l’intégration, l’hôte prend en charge l’extraction et la vérification du sens des faits, l’isolation et les délais des fonctions de rappel, ainsi que le journal durable des remises. Il coordonne l’autorisation et la publication.

Le contrat d’intégration distingue l’accusé de réception et le suivi d’utilisation des informations par le destinataire. Un effet dont l’issue est incertaine est signalé à l’hôte pour décision, sans relance automatique. La documentation fournit les contrats de reprise et d’admission.

L’étude d’apprentissage porte sur six familles de tâches et douze mondes synthétiques. Les mesures de reprise couvrent huit interruptions de processus. Le protocole de performance à 1 000 sources laisse l’état du cache non contrôlé. Chaque rapport lié fournit ses conditions d’exécution, observations et calculs.

L’essai initial d’intégration porte sur huit tâches, avec une génération par condition, une intention imposée et un catalogue réduit. Des juges IA ont évalué les réponses. Le banc a interrompu une condition lors de recherches parallèles ; le rapport conserve les réponses disponibles et cette interruption.

Persistent Memory

Présentation

Résultats publics

Garder le fil entre les sessions

Réutiliser l’expérience d’une autre tâche

Garder une mémoire cohérente après une correction ou une panne