Vertex AI Agent Engine Memory Bank: Prouver la portée et le rappel

Vertex AI Agent Engine Memory Bank peut accepter les événements source, générer une mémoire et la retourner plus tard. Cette séquence est utile, mais un appel SDK réussi ne prouve pas que le prochain tour de l'agent a reçu la bonne mémoire pour la bonne identité. Le défaut raisonnable est de traiter la mémoire à long terme comme un petit pipeline de preuves. Attendez que l'opération de génération soit terminée. Vérifiez l'action signalée. Récupérer dans le champ d'application prévu. Corrélatez la mémoire visible avec l'événement ou la révision source. Gardez la qualité de la ressemblance séparée de la persistance de base. Confirmez que les mises à jour et les suppressions ont convergé avant d'injecter un fait dans un prompt. Cet article transforme ces étapes en un reçu de santé sans contenu. Un dispositif exécutable à huit cas produit deux cas sains, un encore en activité, un cas de récupération dégradé et quatre défaillances. Le but n'est pas de classer le service de Google. Il s'agit de faire en sorte que votre propre intégration distingue le travail en attente, un no op valide, une erreur de requête, un état obsolète, une visibilité à travers le champ, et un dyséquilibre du cycle de vie. Une demande remplie n'est que le premier reçu Le Vue d'ensemble de la Banque de mémoire actuel de Google sépare les sessions de la mémoire à long terme. Les événements de session fournissent l'historique de la conversation source. GenerateMemories peut extraire et consolider des faits durables pour une portée, tandis que CreateMemory permet à un agent d'écrire un fait directement. Plus tard, RetrieveMemories fournit la mémoire à portée de main à un autre tour. Ce flux a plusieurs limites observables: 1. l'événement source existe; 2. la génération de mémoire a commencé; 3. son fonctionnement à long terme est effectué; 4. la réponse indique qu'une mémoire était CREATED , UPDATED ou DELETED ; 5. la ressource actuelle est visible dans le champ d'application prévu; 6. le chemin de récupération approprié trouve la révision attendue; 7. l'agent consommateur n'utilise réellement que des preuves qui ont passé ces contrôles. Le documentation de génération décrit explicitement le GenerateMemories comme une opération à long terme. Une réponse complète peut indiquer trois actions différentes. CREATED signifie qu'une nouvelle mémoire a été ajoutée. UPDATED signifie la consolidation modifiée d'une mémoire existante. DELETED signifie que les informations de source plus récentes ont invalidé une mémoire existante. Ne réduisez pas ces actions à un Boolean appelé memory saved . Plus important encore, ne réduisez pas une opération inachevée à l'échec. Si operation.done est faux, le travail est toujours en attente. Enquêter sur l'opération existante dans un délai; démarrer une nouvelle génération de demandes simplement parce que la première n'a pas été terminée peut créer des travaux dupliqués ou une consolidation confuse. Un reçu minimal peut éviter de stocker le contenu de la conversation: La mise en cache d'un identifiant d'opération ou d'étendue réduit l'exposition accidentelle dans un journal de santé; elle ne rend pas un identifiant faible sûr. Gardez les identifiants d'utilisateur bruts, les faits, les instructions, les identifiants et les jetons d'accès hors du reçu. L'application a encore besoin d'une cartographie protégée lorsqu'un opérateur doit enquêter sur une défaillance. Le champ d'application exact et la révision actuelle doivent être d'accord La Banque de mémoire conserve une collection isolée pour chaque champ d'application. Le documentation de récupération actuel dit que la récupération basée sur la portée ne renvoie que des souvenirs avec une portée correspondante exactement, indépendamment de l'ordre de la clé, et que la portée d'une mémoire est immuable. C'est une limite de service forte, mais votre intégration choisit toujours la portée. Un bug de cartographie peut demander l'identité de l'utilisateur, du projet, du locataire ou de l'agent erroné et recevoir un résultat techniquement valide. La santé a donc besoin de deux comparaisons: champ d'application: la portée normalisée exacte de la tâche prévue; Retourné de la portée: la portée attachée à chaque mémoire visible. Toute inadéquation bloque l'injection. La pertinence ne peut pas surpasser l'identité. Un fait très similaire d'un autre utilisateur n'est pas un résultat dégradé; c'est un échec d'isolement. Les révisions fournissent une deuxième comparaison. Le documentation de révision de Google dit que la création de mémoire et la modification enregistrent par défaut des révisions immuables. Une mémoire actuelle est l'état consolidé; ses révisions enfantines préservent les états historiques et, pour les souvenirs générés, les étapes extraites et consolidées. Ajouter un identifiant source sans contenu à l'aide d'étiquettes de révision ou de métadonnées d'application lorsque votre contrat le permet. Ensuite, comparez la révision attendue de la source avec la révision visible après la génération. Si l'opération rapporte UPDATED pour evt 106 mais que la récupération expose toujours evt 099 , l'état de sécurité est obsolète ou incertain. Ce n'est pas sain simplement parce que le fait semble plausible. La suppression a besoin de sa propre règle. La réponse de génération documentée peut dire DELETED , et récupérer cette mémoire supprimée devrait retourner 404 . Les ressources de révision restent vérifiables pour une fenêtre de récupération limitée après la suppression principale. Si un fait supposé supprimé reste visible sur le chemin de la consommation, le garder hors contexte et réconcilier le cycle de vie. À l'inverse, un 404 après une suppression documentée est une preuve de convergence et non un incident de disponibilité. Liste et recherche de similitudes Répondre à différentes questions La Banque de mémoire expose plusieurs chemins de récupération: Get récupère une ressource de mémoire entièrement qualifiée; List énumère les mémoires dans la banque et prend en charge les filtres; le Retrieve basé sur la portée renvoie toutes les mémoires pour une portée exacte lorsqu'aucun paramètre de similitude n'est fourni; similitude Retrieve classe les mémoires dans un champ exact d'une requête. Ces chemins ne doivent pas partager une métrique memory found non différenciée. Supposons que GenerateMemories soit complété par UPDATED . Une liste de champs indique la révision actuelle attendue, mais une requête de similitude ne renvoie pas de lignes. Le plan de persistance est sain: la mémoire existe sous l'identité prévue. La récupération de requête est dégradée pour ce canarien. Les causes possibles comprennent une mauvaise requête de test, une correspondance sémantique inattendue, un filtrage ou un choix top k . Le fait de considérer le défaut comme une perte de persistance envoie l'opérateur vers la mauvaise réparation et peut provoquer une écriture dupliquée. Le conflit inverse est plus grave. Si la récupération de ressemblance renvoie un candidat mais que la mémoire actuelle ne peut pas être trouvée par l'intermédiaire de la preuve de portée ou de ressources attendues, ne l'injectez pas. La pertinence de la recherche ne remplace pas l'origine et la fraîcheur. Un canary utile effectue donc deux lectures: N'utilisez pas de texte de mémoire de production comme canary synthétique. Créer une identité de test dédiée, un fait non sensible, une politique d'expiration et un reçu de nettoyage. Gardez le trafic canarien hors de la portée réelle des utilisateurs. Retournez à huit reçus maladroits avant de faire confiance au vert L'artefact qui accompagne cet article est memory bank health audit.mjs . Il ne contient pas de renseignements personnels, d'informations ou de renseignements sur les clients. Il classe huit reçus d'opération, de portée, de révision, de liste et de récupération synthétiques: La sortie exécutée est: Cas de fixation Le verdict Pourquoi ? async pending travail L'opération de génération n'est pas terminée; sondage sans duplication de travail. clean write santé L'action, la portée exacte, la révision, la liste et la récupération s'accordent. no topic noop santé Aucun sujet admissible n'était attendu et aucune mutation n'était apparue. similarity miss list hit dégradé La persévérance et la fraîcheur passent; le chemin de la requête manque. wrong scope result échec La mémoire visible appartient à un autre domaine. stale revision échec La révision visible ne correspond pas à l'événement source. deleted still visible échec L'opération dit supprimé, mais les lectures consommées exposent toujours la mémoire. created not fetchable échec La création est terminée, mais la mémoire attendue est absente de l'inventaire. L'affaire sans opération compte. La génération de mémoire extrait uniquement des informations qui correspondent aux sujets configurés. Une opération peut être terminée sans générer de mémoire lorsque la source ne contient rien d'éligible. Si votre contrat de test ne prévoyait aucun fait durable, nul souvenir généré est sain. Un détecteur qui page sur chaque réponse vide va faire pression sur les équipes pour qu'elles persistent le bruit. L'affaire de la question manque pour la raison opposée. L'appareil marque sa dégradation, pas son échec, parce qu'une liste actuelle d'impact sur la portée exacte prouve que la persistance a survécu. L'opérateur peut régler la requête, inspecter les filtres ou utiliser la récupération à portée de main sans réécrire la mémoire. Les quatre cas d'échec ne sont pas combinés intentionnellement en erreur de mémoire. Ils impliquent différentes actions sécurisées: arrêter l'injection et revoir la cartographie d'identité pour une violation de champ d'application; inspecter les révisions ou attendre la convergence en cas d'état obsolète; mettre en quarantaine un fait dont la suppression n'a pas convergé; vérifier les noms, les champs d'application et les actions avant de réessayer une écriture complète mais invisible. Cette priorité de décision empêche un fait pertinent, mais dangereux, d'obtenir des preuves d'identité ou de cycle de vie: Mettez le reçu à la limite du contexte Le meilleur endroit pour appliquer cette règle est immédiatement avant que la mémoire récupérée entre dans une demande de modèle, pas seulement dans une vérification de stockage nocturne. Une vérification périodique peut prouver que le service était accessible plus tôt. La frontière contextuelle sait quelle identité, tâche, requête, révision de la source et limite de fraîcheur compte maintenant. Utilisez une séquence limitée: Normalisez l'identité une fois. Construisez la portée exacte à partir de l'identité d'application authentifiée, et non du texte généré par le modèle. Passez la portée normalisée du dossier médical. Portez une corrélation source. Étiquettez la demande de génération ou la révision avec un identifiant d'événement opaque. N'enregistrez pas le contenu de la conversation. Respecter le travail asynchrone. Rechercher le nom de l'opération jusqu'à ce qu'il soit terminé ou que la date limite de la tâche expire. Préserver working , waiting et uncertain ; ne pas produire une défaillance ou une deuxième demande. Concilier l'inventaire avant sa pertinence. Confirmer la mémoire courante attendue dans son champ d'application, son action et sa révision exacts. Puis testez le chemin de similitude que l'agent utilisera. Vérifier les changements du cycle de vie. Pour les mises à jour, la révision actuelle attendue est requise. Pour les suppressions, il est nécessaire d'écarter le parcours de lecture consommateur tout en conservant la référence de récupération autorisée seulement tant que la politique le permet. Faites la décision d'injection explicite. Enregistrer allow , degrade , wait ou block plus les timestamps de preuve. Une réponse modèle réussie après une injection dangereuse ne rend pas rétroactivement la mémoire saine. Ce reçu a encore des limites. Il ne peut pas savoir si un fait extrait est vrai, utile, empoisonné ou conforme à votre politique de conservation. Une étiquette de révision correspondante ne prouve la corrélation que si le producteur écrit les étiquettes honnêtement. La qualité de la similitude nécessite des requêtes spécifiques au domaine et une évaluation humaine. Les contrôles d'accès et les tests adversitaires restent nécessaires, d'autant plus que la vue d'ensemble de Google prévient que la mémoire à long terme peut entraîner des risques d'injection rapide et d'empoisonnement de la mémoire dans les sessions ultérieures. La direction du produit de Sidewisp traite la continuité de mémoire, la fraîcheur, les limites d'identité et la vérification des résultats comme des preuves de santé opérationnelle autour des temps d'exécution existants de l'agent. Il ne remplace pas le Vertex AI Agent Engine, l'IAM, votre application ou votre suite de tests. Sidewisp est actuellement en préversion privée. Le site public et la démonstration interactive sont en direct; la collection des agents de production et de santé et une intégration Vertex AI ne sont généralement pas expédiées.