Vertex AI Agent Engine Memory Bank: Scopo di prova e richiamo

Vertex AI Agent Engine Memory Bank può accettare gli eventi sorgenti, generare una memoria e restituirla in seguito. Questa sequenza è utile, ma una chiamata SDK di successo non dimostra che il prossimo turno dell'agente abbia ricevuto la memoria giusta per l'identità giusta. La ragionevole ipotesi è quella di trattare la memoria a lungo termine come una piccola pipeline di prove. Aspettate che l'operazione di generazione finisca. Controlla l'azione segnalata. Riprendiamo nell'esatto ambito previsto. Correlazione della memoria visibile con l'evento o revisione sorgente. Tenere la qualità della somiglianza separata dalla persistenza di base. Confirmare che gli aggiornamenti e le cancellazioni sono convergenti prima di iniettare un fatto in un prompt. Questo articolo trasforma questi passaggi in un ricevimento sanitario senza contenuti. Un dispositivo eseguibile a otto casi produce due casi sani, uno ancora funzionante, uno di recupero degradato e quattro fallimenti. Il punto non è di valutare il servizio di Google. È per rendere la propria integrazione distingue tra lavoro in sospeso, un no op valido, un errore di query, stato obsoleto, visibilità transversale e una disadeguatezza del ciclo di vita. Una richiesta completata è solo la prima ricevuta L'attuale Presentazione generale della Banca della Memoria di Google separa le sessioni dalla memoria a lungo termine. Gli eventi della sessione forniscono la storia della conversazione fonte. GenerateMemories può estrarre e consolidare fatti duraturi per un ambito, mentre CreateMemory consente ad un agente di scrivere un fatto direttamente. Successivamente, RetrieveMemories fornisce la memoria scope a un altro turno. Questo flusso ha diversi confini osservabili: 1. l'evento sorgente esiste; 2. la generazione della memoria è iniziata; 3. il suo funzionamento a lungo termine è svolto; 4. la risposta dice che una memoria è stata CREATED , UPDATED o DELETED ; 5. la risorsa corrente è visibile nell'ambito di applicazione previsto; 6. il percorso di recupero appropriato trova la revisione attesa; 7. l'agente di consumo utilizza effettivamente solo le prove che hanno superato tali controlli. La documentazione di generazione descrive esplicitamente la GenerateMemories come un'operazione di lunga durata. Una risposta completa può riportare tre azioni diverse. CREATED significa che è stata aggiunta una nuova memoria. UPDATED significa consolidamento modificato di una memoria esistente. DELETED significa che le informazioni di fonte più recenti hanno invalidato una memoria esistente. Non appiattire queste azioni in un solo Boolean chiamato memory saved . Ancora più importante, non rovesciare un'operazione non terminata in un fallimento. Se operation.done è falso, il lavoro è ancora in sospeso. Indagine sull'operazione esistente entro una scadenza; avviare un'altra generazione di richieste semplicemente perché la prima non è finita può creare lavori duplicati o consolidamento confuso. Una ricevuta minima può evitare di memorizzare il contenuto della conversazione: La messa in cache di un identificatore di funzionamento o di portata riduce l'esposizione incidentale in un registro sanitario; non rende sicuro un identificatore debole. Mantenere l'ID dell'utente grezzo, i fatti, le richieste, le credenziali e i token di accesso fuori dalla ricevuta. L'applicazione ha ancora bisogno di una mappatura protetta quando un operatore deve indagare su un fallimento. La portata esatta e l'attuale revisione devono concordare. La Memory Bank mantiene una raccolta isolata per ogni ambito. L'attuale Documentazione di ritiro dice che la ricerca basata sul campo di applicazione restituisce solo ricordi con un campo di applicazione esattamente corrispondente, indipendentemente dall'ordine chiave, e che il campo di applicazione di una memoria è immutabile. Questo è un forte limite di servizio, ma la tua integrazione sceglie comunque la portata. Un bug di mappatura può chiedere l'identità dell'utente, del progetto, del tenente o dell'agente sbagliato e ricevere un risultato tecnicamente valido. La salute ha quindi bisogno di due paragoni: L'ambito di applicazione della richiesta: l'esatto campo di applicazione normalizzato del compito previsto; Returned scope: il campo di applicazione collegato a ogni memoria visibile. Qualsiasi discrepanza blocca l'iniezione. La rilevanza non può superare l'identità. Un fatto molto simile da un altro utente non è un risultato degradato; è un fallimento di isolamento. Le revisioni forniscono un secondo confronto. documentazione di revisione di Google dice che la creazione e la modifica della memoria salvano le revisioni immutabili per impostazione predefinita. Una memoria corrente è lo stato consolidato; le sue riviste infantili conservano gli stati storici e, per le memorie generate, i passi estratti e consolidati. Aggiungere un ID di fonte senza contenuti utilizzando etichette di revisione o metadati di applicazione quando il contratto lo consente. Poi confrontare la revisione attesa della fonte con la revisione visibile dopo la generazione. Se l'operazione segnala UPDATED per evt 106 , ma il recupero espone ancora evt 099 , lo stato di sicurezza è antiquato o incerto. Non è salutare solo perché il fatto sembra plausibile. La cancellazione ha bisogno di una sua regola. La risposta di generazione documentata può dire DELETED , e recuperare quella memoria cancellata dovrebbe restituire 404 . Le risorse di revisione rimangono verificabili per una finestra di recupero limitata dopo la cancellazione principale. Se un fatto presumibilmente cancellato rimane visibile al percorso di consumo, tenerlo fuori contesto e conciliare il ciclo di vita. Al contrario, un 404 dopo una cancellazione documentata è prova di convergenza, non di un incidente di disponibilità. Lista e similitudine Risposte a domande diverse La Memory Bank espone diversi percorsi di ritiro: Get riprende una sola risorsa di memoria pienamente qualificata; List elenca le memorie nella banca e supporta i filtri; il Retrieve basato sul campo di applicazione restituisce tutte le memorie per un campo di applicazione esatto quando non sono forniti parametri di somiglianza; similitudine Retrieve classifica le memorie all'interno di un ambito esatto per una query. Questi percorsi non devono condividere una metrica memory found indifferenziata. Supponiamo che GenerateMemories sia completato con UPDATED . Un elenco scope mostra la revisione corrente attesa, ma una query di somiglianza non restituisce righe. Il piano di persistenza è sano: la memoria esiste sotto l'identità prevista. Il recupero delle richieste è degradato per questo canario. Le possibili cause includono una domanda di test scadente, una corrispondenza semantica inaspettatamente debole, il filtraggio o una scelta top k . Trattare il fallimento come perseveranza persa spinge l'operatore verso la riparazione sbagliata e può provocare una doppia scrittura. Il conflitto inverso è più grave. Se la ricerca di similitudine restituisce un candidato ma la memoria corrente non può essere trovata attraverso l'ambito o la prova delle risorse attese, non iniettarla. La rilevanza della ricerca non sostituisce la provenienza e la freschezza. Un canaglio utile effettua quindi due letture: Non utilizzare il testo della memoria di produzione come canario sintetico. Crea un'identità di prova dedicata, un fatto non sensibile, una politica di scadenza e una ricevuta di pulizia. Mantenere il traffico canario fuori dalla vera portata dell'utente. Riproduci otto ricevute imbarazzanti prima di fidarti del verde . L'artefatto che accompagna questo articolo è memory bank health audit.mjs . Non contiene credenziali, richieste o dati sui clienti. Esso classifica otto ricevute sintetiche di operazione, ambito, revisione, elenco e recupero: L' output eseguito è: Caso di fissatura Verdicto Perché? async pending lavoro L'operazione di generazione non è fatta; la sondaggio senza duplicare il lavoro. clean write salute Azione, ambito esatto, revisione, lista e recupero concordano. no topic noop salute Nessun argomento idoneo era atteso e nessuna mutazione è emersa. similarity miss list hit degradazione La perseveranza e la freschezza passano; il percorso di ricerca manca. wrong scope result fallimento La memoria visibile appartiene ad un altro ambito. stale revision fallimento La revisione visibile non corrisponde all'evento sorgente. deleted still visible fallimento L'operazione dice che è stata cancellata, ma le letture consumate espongono ancora la memoria. created not fetchable fallimento La creazione è completata, ma la memoria attesa è assente dall'inventario di scope. Il caso di no op conta. La generazione di memoria estrage solo informazioni che corrispondono a argomenti configurati. Un'operazione può finire senza generare una memoria quando la fonte non contiene nulla di idoneo. Se il contratto di prova non prevedeva fatti duraturi, zero ricordi generati sono sani. Un rilevatore che pagina ogni risposta vuota pressiona le squadre a mantenere il rumore. Il caso della domanda missa conta per il motivo opposto. Il dispositivo segna che si è degradato, non ha fallito, perché un'attuale lista di accise di ambito esatto dimostra che la persistenza è sopravvissuta. L'operatore può regolare la query, ispezionare i filtri o utilizzare il scope retrieval senza riscrivere la memoria. I quattro casi di fallimento non sono intenzionalmente combinati in errore di memoria. fermare l'iniezione e rivedere la mappatura dell'identità per una violazione del campo di applicazione; ispezionare le revisioni o attendere la convergenza per lo stato di obsolescenza; quarantena un fatto la cui cancellazione non è convergente; verificare i nomi, gli ambiti e le azioni prima di riprovare una scrittura completata ma invisibile. Questa priorità decisionale impedisce che un dato rilevante ma non sicuro possa ottenere prove di identità o di ciclo di vita: Metti la ricevuta al confine del contesto Il posto migliore per far rispettare questa regola è immediatamente prima che la memoria recuperata entri in un modello di richiesta, non solo in un controllo di archiviazione notturno. Una verifica periodica può dimostrare che il servizio era raggiungibile in precedenza. Il confine di contesto sa quale identità, compito, query, revisione della fonte e limite di freschezza sono importanti ora. Utilizzare una sequenza limitata: Normalizzare l'identità una volta. Costruire l'ambito esatto dall'identità di applicazione autenticata, non dal testo generato dal modello. Sulla scala normalizzata della cartella di salute. Correlazione di una fonte. Etichettare la richiesta di generazione o revisione con un ID di evento opaco. Non registrare il contenuto della conversazione. Respect asynchronous work. Scollare il nome dell'operazione fino a quando non sarà eseguita o scade la scadenza del compito. Preservare working , waiting e uncertain ; non produrre un guasto o una seconda richiesta. Conciliare l'inventario prima della rilevanza. Confirmare la memoria corrente attesa sotto la sua esatta portata, azione e revisione. Poi testare il percorso di somiglianza che l'agente usera'. Verifica le modifiche del ciclo di vita. Per gli aggiornamenti, richiede la revisione corrente attesa. Per le cancellazioni, richiedere l'assenza dal percorso di lettura consumante mantenendo il riferimento di recupero autorizzato solo per il periodo consentito dalla politica. Fare esplicita la decisione di iniezione. Registrare allow , degrade , wait o block più i timestamp della prova. Una risposta di modello di successo dopo un'iniezione non sicura non rende retroattivamente la memoria sana. Questa ricevuta ha ancora dei limiti. Non può dire se un fatto estratto sia vero, utile, avvelenato o conforme alla tua politica di conservazione. Un'etichetta di revisione corrispondente dimostra la correlazione solo se il produttore scrive le etichette onestamente. La qualità della somiglianza richiede richieste specifiche di dominio e revisione umana. I controlli di accesso e i test di contraddizione rimangono necessari, soprattutto perché la panoramica di Google avverte che la memoria a lungo termine può portare il rischio di iniezione rapida e avvelenamento della memoria in sessioni successive. La direzione del prodotto di Sidewisp tratta la continuità della memoria, la freschezza, i confini di identità e la verifica dei risultati come prove di salute operativa intorno ai tempi di esecuzione degli agenti esistenti. Non sostituisce Vertex AI Agent Engine, IAM, la tua applicazione o la tua suite di test. Sidewisp è attualmente in anteprima privata. Il sito pubblico e la dimostrazione interattiva sono in diretta; generalmente non vengono spedite le collezioni agenti di produzione sanità e un'integrazione Vertex AI.