Système d'exploitation mémoire de l'agent AI : auditer chaque transition de niveau

Un système d'exploitation de mémoire pour un agent IA n'est sain que lorsque l'opérateur peut suivre une version de mémoire via le stockage, la mise à jour, la récupération et la génération sous la même portée d'utilisateur et d'assistant. Une réponse cohérente est un résultat utile, mais elle ne constitue pas la preuve que toutes les transitions antérieures ont été réalisées. La méthode pratique par défaut est donc simple : joindre un reçu de lignée sans contenu à chaque limite. Conservez le contenu de la mémoire sur l'hôte. Enregistrez uniquement les identifiants stables, la portée, la version source, le niveau de destination, les horodatages, l'état de transition et la version utilisée pour la génération. Si une limite est manquante ou contradictoire, signalez waiting , at risk , stale ou uncertain au lieu du vert. Cette règle est importante pour l'architecture spécifique derrière la requête de recherche système de mémoire de l'agent ai . Le document MemoryOS définit trois niveaux de stockage et quatre modules fonctionnels. Sa mise en œuvre expose également une fenêtre d’échec étroite qu’un benchmark de qualité de réponse ne peut pas identifier. Ce que MemoryOS établit Le Papier MemoryOS décrit quatre modules : 1. Le stockage organise la mémoire à court terme (STM), la mémoire à moyen terme (MTM) et la mémoire personnelle à long terme (LPM). 2. La mise à jour déplace les pages de dialogue de STM vers MTM, puis dérive un profil ou des connaissances plus anciennes de MTM. 3. Récupération sélectionne le matériel pertinent dans les niveaux. 4. Génération crée une réponse à partir du contexte actuel et récupéré. Le document est inhabituellement concret sur les mouvements entre les niveaux. La mise à jour STM vers MTM utilise un processus FIFO en chaîne de dialogue. La mise à jour MTM vers LPM utilise des pages segmentées avec une sélection basée sur la chaleur. C'est une structure suffisante pour définir des limites de transition observables au lieu de traiter la « mémoire » comme une base de données opaque. Les auteurs rapportent des améliorations moyennes de 49,11 % en F1 et de 46,18 % en BLEU 1 par rapport à leurs lignes de base sur LoCoMo avec GPT 4o mini. Ce sont les résultats de référence des auteurs ; Je n'ai pas réexécuté LoCoMo pour cet audit. Plus important encore, l’exactitude et la cohérence des réponses répondent à une question différente de celle de l’intégrité opérationnelle. Un score élevé ne prouve pas que : un dossier STM était durablement présent avant l'expulsion ; une destination MTM validée avant la disparition de la source ; la même portée utilisateur et assistant a survécu à chaque transition ; la récupération a renvoyé la version attendue la plus récente ; la génération finale dépendait en réalité de cette version. L’architecture du journal fournit les limites. L'opérateur a toujours besoin de reçus pour eux. L'intervalle à risque apparaît avant le commit de destination J'ai inspecté le projet lors du commit épinglé 587ed7755c7aed179965792830ff1b5ad9a6fa92 . L'épinglage compte : le référentiel est actif, et une conclusion opérationnelle sans version source deviendra ambiguë après le prochain changement. Le chemin add memory actuel vérifie si le deque à court terme est plein et exécute la promotion avant d'ajouter un autre élément. La source qualifie explicitement cela de correctif pour empêcher l'expulsion automatique silencieuse ( memoryos.py , lignes 226 à 244). Il s’agit d’une garantie utile, mais qui ne rend pas la promotion transactionnelle. La séquence de promotion est importante : 1. process short term to mid term appelle pop oldest alors que STM est plein ( updater.py , lignes 100 à 105). 2. pop oldest supprime l'enregistrement et enregistre immédiatement le deque STM le plus court ( short term.py , lignes 33 à 37). 3. Le programme de mise à jour appelle ensuite les fonctions de continuité et de résumé basées sur LLM. 4. L'insertion MTM et sa sauvegarde finale ont lieu plus tard ( updater.py , lignes 130 à 207). Ce flux de contrôle crée un intervalle de source à risque. Si le processus se termine ou si une opération en aval non interceptée échoue après la sauvegarde STM mais avant la validation MTM, l'opérateur ne dispose d'aucune preuve de promotion terminée. Il s'agit d'une fenêtre d'échec dérivée de la source, et non d'une affirmation selon laquelle chaque déploiement MemoryOS perd des données. L’état de santé correct n’est tout simplement pas vert jusqu’à ce que le reçu de destination existe ou que la source reste récupérable. Il existe une deuxième limite de continuité, plus étroite. last evicted page for continuity démarre en tant que valeur None en mémoire, est transférée dans le lot suivant et est mise à jour après le traitement ( updater.py , lignes 35 et 115 158). Un redémarrage du processus réinitialise cet indice de report particulier. D'autres logiques de similarité MTM peuvent encore reconnecter du matériel, ce n'est donc pas une preuve d'une perte totale de continuité. C'est une raison pour enregistrer la page ou la version source précédente dans le reçu de transition au lieu de supposer que le processus s'en est souvenu. Utilisez un seul reçu sans contenu pour tous les niveaux Le reçu n'a pas besoin d'invites, de réponses, de résumés, d'intégrations ou de faits personnels. Un événement minimal peut ressembler à ceci : Transportez six champs à chaque étape : runId rejoint une tentative de stockage à génération sans révéler le contenu. userScope et assistantScope détectent les erreurs entre locataires ou assistants partagés. version identifie l'état de la mémoire attendu. sourceVersion épingle le contrat d'implémentation ou d'adaptation. status sépare started , waiting , committed , verified et les travaux échoués. atUtc permet au vérificateur de faire expirer les preuves périmées. MemoryOS crée déjà des fichiers à court, moyen et long terme spécifiques à l'utilisateur, ainsi qu'un fichier à long terme distinct spécifique à l'assistant ( memoryos.py , lignes 71 à 78). Le reçu doit conserver les deux dimensions, car « bon utilisateur, mauvais assistant partagé » reste un conflit de portée. Pour la génération, ajoutez un dependsOnVersion et un outcomeReceipt . dependsOnVersion indique quelle version de mémoire récupérée est entrée dans l'invite finale. outcomeReceipt doit identifier une vérification de résultat déterministe lorsque cela est possible : un hachage de fichier, un identifiant de ligne, un résultat de test, une recherche de destination ou toute autre preuve que le travail prévu existe. Il ne doit pas s’agir d’un hachage de contenu de conversation sensible simplement pour donner un aspect rigoureux au dossier. Rejouez les états gênants avant de faire confiance au vert J'ai construit et exécuté un luminaire à huit cas sans contenu. Le classificateur a renvoyé les huit états attendus : Cas Preuve État Lignée complète Portée, version, fraîcheur, validations de niveau, récupération et réception de génération d'accord healthy Seuil de capacité non atteint STM est durable et la fenêtre d'attente déclarée est ouverte waiting STM supprimé, MTM non validé Source disparue avant la preuve de destination source at risk STM retenue, aucun événement promotionnel La transition MTM attendue n'est jamais apparue promotion missing Changements d'utilisateur pendant la promotion Un événement appartient à une portée différente scope conflict La récupération renvoie v21 , attendu v22 Un vrai souvenir existe, mais il est périmé stale retrieval Réponse fluide, pas de reçu de dépendance Génération terminée sans lignée vérifiée generation unverified Aucune version d'implémentation Les preuves ne peuvent pas être interprétées en toute sécurité uncertain La distinction importante est entre en attente et manquant . Un enregistrement STM qui reste durable alors qu’un seuil de capacité documenté n’a pas été atteint n’est pas bloqué. Une source supprimée sans validation de destination n’attend pas ; c'est en danger. Les champs d'horodatage et de présence de la source rendent cette différence inspectable. Utilisez une priorité explicite afin qu'un succès ultérieur ne puisse pas masquer un conflit antérieur : Cet ordre est délibérément conservateur. Les conflits de portée l’emportent sur une réponse réussie. Le risque à la source dépasse l’activité ultérieure. Une récupération obsolète n'est pas rachetée par une génération fluide. Les preuves manquantes restent incertaines plutôt que d’être converties en preuves saines. Transformez le reçu en porte d'entrée Commencez avec une mémoire Canary qui ne contient aucun contenu personnel ou de production. Donnez lui un identifiant aléatoire et la version attendue, puis exercez le véritable chemin de stockage, de promotion, de récupération et de génération. Avant l'adoption ou après une mise à niveau du système de mémoire : 1. Épinglez l'implémentation. Enregistrez la version du package ou la validation du référentiel et la configuration qui modifie les limites de capacité, de chaleur, de similarité ou de récupération. 2. Prouvez l'isolement de la portée. Exécutez deux portées utilisateur et, le cas échéant, deux portées assistant. Traversez délibérément chaque requête et n'exigez aucune récupération sur la mauvaise voie. 3. Forcer les transitions de capacité. Remplissez le STM jusqu'à la limite configurée. Vérifiez que chaque suppression de source possède un commit MTM correspondant. 4. Exercez la solution de secours. Le programme de mise à jour dispose d'une solution de secours de résumé général lorsque la sortie multi résumés n'est pas disponible. Étiquetez ce chemin dégradé et vérifiez la récupération séparément au lieu de traiter l'achèvement du repli comme une qualité normale. 5. Redémarrez entre les lots. Vérifiez la continuité après le redémarrage du processus, car le transfert en mémoire ne constitue pas une preuve durable. 6. Expire les reçus. Une promotion qui était saine hier n'établit pas que le processus, l'index ou les fichiers actuels sont sains maintenant. 7. Vérifiez le résultat. La réussite de la récupération indique qu'un souvenir a été renvoyé. Il n’est pas indiqué que l’agent a utilisé la bonne version ou qu’il a accompli la tâche prévue. Ne réessayez pas automatiquement une promotion de source à risque si la mise à jour a déjà été partiellement validée. Réconciliez d'abord la source et la destination par runId et la version. La relecture aveugle peut transformer l'incertitude en pages dupliquées ou en faits contradictoires à long terme. La limitation est tout aussi importante : ce reçu prouve la lignée, la portée, la fraîcheur et les contrôles déterministes des résultats de la transition. Cela ne prouve pas qu’un résumé rédigé par LLM soit sémantiquement correct. Cela nécessite une évaluation distincte, un examen humain des faits personnels à fort impact ou une comparaison déterministe spécifique à une tâche. La limite sanitaire pour Sidewisp Cet audit correspond au modèle de santé de la mémoire et du contexte de Sidewisp : les lectures ou écritures manquantes, les échecs de persistance, les synchronisations obsolètes, les réinitialisations inattendues et les décisions perdues doivent être visibles plutôt que déduites d'un processus écologique. Sidewisp est actuellement en préversion privée. Son site public et son système d'articles sont en direct, tandis que la collecte de l'état de l'agent de production, les adaptateurs d'exécution et l'exécution de la récupération ne sont généralement pas livrés. Le reçu ci dessus est un modèle d'opérateur que vous pouvez implémenter dès maintenant ; ce n’est pas une affirmation selon laquelle Sidewisp surveille actuellement MemoryOS. La règle résolue est stricte mais utilisable : ne faites confiance au système de mémoire que lorsque la même version étendue est durablement stockée, promue, récupérée, utilisée et vérifiée. Une réponse fluide peut être encourageante. Il ne peut remplacer le reçu manquant.