Types de mémoire d'agent IA : donnez à chacun un test de santé

La réponse utile à la question « De quel type de mémoire d’agent IA ai je besoin ? » n’est pas « tous ». Choisissez la plus petite mémoire qui franchit la limite requise par votre tâche, puis donnez à cette mémoire son propre test d'acceptation. Un objectif actuel qui doit survivre à la prochaine étape du graphique est la mémoire de travail . Un fait qui doit rester disponible au fil des sessions est la mémoire sémantique . Une tentative passée qui est précieuse en raison de ce qui s'est passé est la mémoire épisodique . Une règle qui modifie la manière dont les travaux futurs seront effectués est la mémoire procédurale . Ces quatre tâches échouent différemment. Une vérification générique « la recherche vectorielle a renvoyé un résultat » peut manquer un point de contrôle perdu, un fait périmé, un épisode sans résultat ou une procédure non approuvée. Le défaut opérationnel est donc : 1. déclarer la frontière que la mémoire doit franchir ; 2. conserver un accusé de réception d'écriture et de lecture sans contenu ; 3. vérifier la portée, la fraîcheur, la provenance et l'activation ; 4. appliquer un invariant spécifique au type ; 5. vérifier la tâche externe séparément. Cet article transforme la taxonomie courante des types de mémoire d'agent IA en ce contrat testable. Commencez par la limite, pas par la base de données Le Architecture CoALA sépare la mémoire de travail à court terme de la mémoire épisodique, sémantique et procédurale à long terme. Il distingue également la récupération, qui lit la mémoire à long terme dans la mémoire de travail, du raisonnement au sein de la mémoire de travail et de l'apprentissage qui écrit la mémoire à long terme. Cette séparation est plus utile sur le plan opérationnel qu’une liste de produits de stockage. Une ligne PostgreSQL, un fichier JSON, un vecteur et un point de contrôle peuvent chacun implémenter plusieurs types de mémoire. La banque de données ne vous indique pas quel échec est important. Documentation sur la mémoire de LangGraph rend la distinction de portée concrète : l'état à court terme est attaché à un thread, tandis que les éléments à long terme peuvent vivre dans des espaces de noms personnalisés et entre les threads. La même documentation décrit la mémoire sémantique comme des faits, la mémoire épisodique comme des expériences et la mémoire procédurale comme des règles ou des instructions. Ce sont des contrats différents, même lorsqu’un magasin détient les trois. Utilisez une question pour choisir la première limite : Qu'est ce qui doit encore être disponible, dans quelle mesure et pour quelle décision future ? « Mémoriser le résultat actuel de l'outil pendant cette exécution » nécessite un contrat plus petit que « mémoriser cette préférence du client le mois prochain ». « Rappeler un incident similaire » est plus faible que « activer uniquement la procédure de récupération approuvée ». L'ajout de mémoire à long terme là où l'état de fonctionnement serait suffisant crée des obligations supplémentaires de conservation, de suppression, de confidentialité et de récupération. Guide de mise en œuvre actuel de Redis recommande de commencer par le besoin à court terme plutôt qu'à long terme et d'ajouter de la mémoire spécialisée lorsque sa valeur opérationnelle justifie la complexité. Il s'agit d'une bonne valeur par défaut, que Redis soit ou non le magasin choisi. Donnez à chaque type de mémoire un test d'acceptation différent Les quatre types peuvent partager une enveloppe de preuves, mais ils ne doivent pas partager leur règle de verdict final. Type de mémoire Emploi Limite à prouver Défaillance spécifique au type Fonctionnement Transportez des objectifs actifs, des résultats intermédiaires et des dépendances La prochaine étape requise, le point de contrôle ou le redémarrage contrôlé L'élément a été écrit et lu, mais n'a pas franchi la limite de continuité requise Sémantique Fournir des faits et des concepts actuels La portée prévue du locataire, de l'utilisateur, du projet ou de l'agent à travers les sessions Le fait récupéré est périmé, remplacé ou provient d'une mauvaise portée Épisodique Réutiliser une expérience passée D'une tentative enregistrée à une décision ultérieure qui nécessite son résultat L'épisode n'a pas de résultat observé, de sorte que l'agent ne peut pas distinguer le succès de l'activité. De procédure Contrôler la façon dont le travail est effectué D'une version approuvée à l'invite, à la règle, au chemin de code ou au comportement de modèle actif La procédure active n'est pas approuvée, n'est pas versionnée ou n'a pas de restauration limitée Mémoire de travail : prouver la continuité La mémoire de travail n’est pas synonyme de « tout ce qui rentre dans le contexte du modèle ». CoALA le décrit comme les variables actives disponibles pour le cycle de décision actuel. Dans un environnement d'exécution, cet état peut être assemblé à partir de messages, d'un point de contrôle graphique, de métadonnées de tâche, de résultats d'outils ou d'un enregistrement d'état externe. Testez le avec un canari opaque lié à une limite requise : écrivez l'ID de l'objectif actif et la version du point de contrôle ; avancer d'un pas réel ou effectuer le redémarrage contrôlé dont le runtime promet de survivre ; lire l'état dans le même thread attendu ou dans la même portée d'exécution ; confirmez que l'ID de l'objectif et la dépendance en attente sont toujours disponibles ; prouver la valeur restaurée entrée dans la décision suivante. Le dernier chèque compte. Un point de contrôle peut contenir le canari tandis que l'assemblage rapide l'omet silencieusement. Le stockage est vert ; le comportement ne l’est pas. Mémoire sémantique : prouver son actualité et sa portée La mémoire sémantique stocke des faits plutôt qu'un événement particulier. Une lecture saine a besoin de plus que de similitudes. Conservez l'ID de mémoire opaque, la version source, le hachage de portée, l'heure d'écriture, l'heure de lecture et l'état d'invalidation. Vérifiez ensuite que le fait effectif est à jour pour le moment de la décision et appartient à l'espace de noms attendu. Un score de similarité élevé ne peut pas rendre actuelle une adresse remplacée ou une autorisation révoquée. La réponse sûre à des faits contradictoires est généralement incertaine , et non « choisissez le vecteur le plus proche ». Résolvez la provenance ou demandez à un humain avant de permettre au fait de conduire à une action irréversible. Mémoire épisodique : prouver le résultat Un épisode est utile car il relie une situation, une action et ce qui a suivi. Un journal d'événements contenant de nombreux appels d'outils ne constitue pas automatiquement une mémoire épisodique. Pour un agent de réponse aux incidents, un épisode tel que « nouvelle tentative d'exportation » est incomplet. L'enregistrement utile indique également si la destination a reçu exactement une exportation valide, si la nouvelle tentative a épuisé son budget et si un humain est intervenu. Le reçu sans contenu peut conserver un identifiant d'épisode, un hachage de classe d'action, un identifiant de reçu de résultat, des horodatages et un état de vérification. Testez la récupération avec un cas connu dont le résultat modifie l'action suivante correcte. Si l'épisode est renvoyé mais que le résultat est absent, classez le comme OUTCOMELESS EPISODE . Ne laissez pas l’activité se faire passer pour une expérience. Mémoire procédurale : prouver l’autorité La mémoire procédurale comprend les règles utilisées pour effectuer les tâches. CoALA inclut à la fois des procédures implicites dans les poids du modèle et des procédures explicites dans le code de l'agent ; Le guide de LangGraph comprend également du code, des poids de modèle et des invites dans cette catégorie. Il s’agit du souvenir le plus risqué à modifier, car il modifie le comportement futur. Sa réception doit comprendre : la version de la procédure active ; la version approuvée ; l'acteur ou la politique qui a autorisé la promotion ; une suite de tests ou une référence d'évaluation ; un temps d'activation ; une référence de restauration ; le périmètre dans lequel la procédure peut se dérouler. Si les versions actives et approuvées diffèrent, l’état de récupération n’a pas d’importance. Le verdict correct est UNSAFE PROCEDURE , et la prochaine étape est une décision d’autorisation ou de libération, et non une réécriture automatique. Utilisez un reçu sans contenu L'enveloppe partagée ci dessous enregistre les preuves opérationnelles sans stocker le fait, l'épisode, l'invite ou le contenu de l'utilisateur : Sept contrôles forment le chemin commun : 1. Disponible : Le sous système de mémoire était il observable ou le verdict est il inconnu ? 2. Écrire : Le magasin concerné a t il accusé réception de l'écriture ? 3. Lire : Une décision ultérieure a t elle récupéré le même élément opaque ? 4. Portée : Les identifiants de portée attendus et observés correspondent ils ? 5. Fraîcheur : Les preuves étaient elles conformes à l'âge déclaré ? 6. Provenance : Le système peut il identifier l'origine de cet élément ou de cette version ? 7. Activation : L'élément a t il pris la décision souhaitée, plutôt que d'apparaître simplement dans les résultats de recherche ? Appliquez ensuite la règle spécifique au type : continuité pour la mémoire de travail, devise source pour la mémoire sémantique, lien de résultat pour la mémoire épisodique, ou approbation et restauration pour la mémoire procédurale. L'ordonnance évite des verdicts trompeurs. Par exemple, une incompatibilité de portée doit arrêter l’évaluation avant l’activation. Une lecture manquante ne doit pas devenir « non activée », car la première couche échouée est la récupération. Exécutez le classificateur à neuf cas L'artefact de publication inspectable contient memory health cases.json et classify memory health.mjs . La priorité de décision est suffisamment petite pour être reproduite dans n'importe quel environnement d'exécution : Le luminaire couvre un cas de mémoire de travail saine plus une perte de continuité, des données sémantiques obsolètes, une violation de la portée, un épisode sans résultat, un épisode récupéré mais non activé, une procédure non approuvée, un échec de récupération et des preuves indisponibles. Courir: Le résultat enregistré pour cet article était : Cette réussite prouve que le classificateur suit sa priorité déclarée. Cela ne prouve pas qu'un backend de mémoire active est sain. Séparez la santé de la mémoire de la réussite des tâches Un reçu mémoire peut prouver qu'un élément opaque a franchi sa limite déclarée. Il ne peut pas prouver qu'un fait est vrai, que l'épisode rappelé constitue le meilleur précédent ou qu'une procédure approuvée réussira dans tous les environnements. Conservez un deuxième reçu de résultat déterministe autant que possible. Un agent d’assistance peut récupérer correctement les préférences d’expédition actuelles d’un client et ne pas toujours mettre à jour la commande. Un agent de codage peut restaurer l'objectif actif exact après le redémarrage tout en omettant le fichier demandé. Un agent de récupération peut activer le runbook approuvé tout en produisant un effet externe en double. L'état opérationnel doit refléter les deux grands livres : mémoire saine, résultat vérifié : résolvez le problème lié à la mémoire ; mémoire saine, résultat manquant : enquêter sur l'exécution ou la vérification de la destination ; échec de la mémoire, résultat vérifié : enregistre une dépendance dégradée ; l'exécution a peut être réussi par repli ; échec de la mémoire, résultat manquant : corrigez la première couche de mémoire défaillante avant d'approuver une nouvelle tentative ; preuve non disponible : restez incertain plutôt que de fabriquer de manière verte. Cette séparation limite également la collecte de données. Les preuves de santé peuvent conserver des hachages, des identifiants, des versions, des horodatages, des portées, des booléens et des verdicts. Il n'est pas nécessaire que le texte d'invite, les faits personnels, le contenu de l'épisode, les arguments de l'outil et les secrets soient quittés par l'hôte simplement pour montrer qu'un contrat a été conclu. Choisissez le plus petit contrat qui peut fonctionner Pour un nouvel agent, commencez par le résultat et remontez : 1. Si des informations sont nécessaires uniquement pendant le cycle de décision en cours, conservez les dans la mémoire de travail. 2. Si un fait doit traverser des sessions, ajoutez de la mémoire sémantique avec des règles de source, de portée, de mise à jour et d'invalidation. 3. Si une tentative passée doit influencer un choix ultérieur, ajoutez de la mémoire épisodique uniquement lorsque la tentative a un résultat. 4. Si le comportement lui même doit changer, traitez ce changement comme une mémoire procédurale et entourez le de promotion, d'approbation, de tests et de restauration. N'ajoutez pas de type de mémoire car un framework propose une classe portant ce nom. Ajoutez le lorsqu'une limite de tâche observable l'exige. Ne l'appelez pas sain car le magasin répond. Appelez cela sain lorsque les preuves correctes ont été écrites, rappelées dans le bon champ d'application, toujours d'actualité, activées lors de la décision prévue et transmises à l'invariant spécifique à ce type. Sidewisp est actuellement en préversion privée. Son modèle d'intégrité prévu inclut les lectures ou écritures de mémoire manquantes, les échecs de persistance, les synchronisations obsolètes et les décisions perdues, mais les adaptateurs de collecte d'intégrité et d'exécution de l'agent de production ne sont pas livrés aujourd'hui. Le reçu présenté dans cet article est une conception que vous pouvez exécuter localement dès maintenant ; cela ne veut pas dire que Sidewisp surveille ou répare actuellement vos agents.