Banco de memória do motor de agente Vertex AI: Prove Scope and Recall

O Vertex AI Agent Engine Memory Bank pode aceitar eventos de origem, gerar uma memória e devolvê la mais tarde. Essa sequência é útil, mas uma chamada bem sucedida do SDK não prova que o próximo turno de agente recebeu a memória certa para a identidade certa. O padrão razoável é tratar a memória a longo prazo como um pequeno pipeline de evidências. Esperem que a operação de geração termine. Verifique as ações reportadas. Recuperar no escopo exato previsto. Correlacionar a memória visível com o evento ou revisão de origem. Mantém a qualidade de semelhança separada da persistência básica. Confirme que as atualizações e exclusões convergem antes de injetar um fato em um prompt. Este artigo transforma esses passos em um recibo de saúde sem conteúdo. Uma fixação executável de oito casos produz dois casos saudáveis, um ainda em funcionamento, um caso de recuperação degradado e quatro falhas. O ponto não é avaliar o serviço do Google. É fazer a sua própria integração distinguir trabalho pendente, um no op válido, uma falta de consulta, estado obsoleto, visibilidade transversal, e um desajuste do ciclo de vida. Um pedido preenchido é apenas o primeiro recibo O Visão geral do Banco de Memória atual do Google separa sessões da memória de longo prazo. Os eventos da sessão fornecem histórico de conversação fonte. A GenerateMemories pode extrair e consolidar fatos duradouros para um escopo, enquanto a CreateMemory permite que um agente escreva um fato diretamente. Mais tarde, o RetrieveMemories fornece memória de alcance para outro turno. Esse fluxo tem vários limites observáveis: 1. O evento de origem existe; 2. a geração de memória foi iniciada; 3. a sua operação a longo prazo é efetuada; 4. A resposta diz que a memória foi CREATED , UPDATED ou DELETED ; 5. O recurso atual é visível no âmbito previsto; 6. O caminho de recuperação adequado encontra a revisão esperada; 7. O agente consumidor só utiliza provas que tenham passado esses controlos. O Documentação de geração descreve explicitamente o GenerateMemories como uma operação de longo prazo. Uma resposta completa pode relatar três ações diferentes. CREATED significa que uma nova memória foi adicionada. UPDATED significa consolidação alterada de uma memória existente. DELETED significa que a informação de origem mais recente invalidou uma memória existente. Não aplanem essas ações em um Boolean chamado memory saved . Mais importante ainda, não deixe cair uma operação inacabada em fracasso. Se o operation.done for falso, o trabalho ainda está pendente. Pesquisar a operação existente dentro de um prazo; iniciar uma nova geração de pedido simplesmente porque a primeira não terminou pode criar trabalho duplicado ou consolidação confusa. Um recibo mínimo pode evitar o armazenamento de conteúdo da conversa: O encobrimento de um identificador de operação ou de alcance reduz a exposição incidental num registro de saúde; não torna um identificador fraco seguro. Mantenha as identidades de usuário, fatos, instruções, credenciais e tokens de acesso fora do recibo. A aplicação ainda precisa de um mapeamento protegido quando um operador deve investigar uma falha. O escopo exato e a revisão atual devem concordar O Banco de Memória mantém uma coleção isolada para cada escopo. O Documentação de recolha atual diz que a recuperação baseada em escopo retorna apenas memórias com um escopo exatamente correspondente, independente da ordem da chave, e que o escopo de uma memória é imutável. Isso é um forte limite de serviço, mas a sua integração ainda escolhe o escopo. Um bug de mapeamento pode pedir a identidade errada do usuário, projeto, inquilino ou agente e receber um resultado tecnicamente válido. A saúde precisa, portanto, de duas comparações: Cálculo de solicitação: o escopo normalizado exato da tarefa prevista; Returned scope: o escopo ligado a cada memória visível. Qualquer desajuste bloqueia a injecção. A relevância não pode anular a identidade. Um facto muito semelhante de outro utilizador não é um resultado degradado; é uma falha de isolamento. As revisões fornecem uma segunda comparação. O Documentação de revisão do Google diz que a criação de memória e a modificação guardam revisões imutáveis por padrão. Uma memória atual é o estado consolidado; suas revisões infantis preservam estados históricos e, para memórias geradas, os passos extraídos e consolidados. Anexar uma identificação de fonte livre de conteúdo usando rótulos de revisão ou metadados de aplicativos quando o seu contrato o permitir. Em seguida, compare a revisão esperada da fonte com a revisão visível após a geração. Se a operação relatar o UPDATED para o evt 106 , mas a recuperação ainda expõe o evt 099 , o estado de segurança é obsoleto ou incerto. Não é saudável apenas porque o fato parece plausível. A exclusão precisa de uma regra própria. A resposta de geração documentada pode dizer DELETED , e buscar essa memória excluída deve devolver 404 . Os recursos de revisão continuam a ser verificáveis para uma janela de recuperação limitada após a exclusão principal. Se um fato supostamente apagado permanece visível ao caminho de consumo, mantenha o fora de contexto e conciliar o ciclo de vida. Por outro lado, um 404 após uma exclusão documentada é prova de convergência, não de um incidente de disponibilidade. Pesquisa de lista e semelhanças responde a diferentes perguntas O Banco de Memória expõe vários caminhos de buscas: O Get recupera um recurso de memória totalmente qualificado; O List enumera memórias no banco e suporta filtros; O Retrieve baseado em alcance retorna todas as memórias para um alcance exato quando não são fornecidos parâmetros de semelhança; semelhança Retrieve classifica memórias dentro de um escopo exato para uma consulta. Estes caminhos não devem compartilhar uma métrica memory found não diferenciada. Suponha que o GenerateMemories seja completado com o UPDATED . Uma lista com escopo mostra a revisão atual esperada, mas uma consulta de semelhança não retorna linhas. O plano de persistência é saudável: a memória existe sob a identidade pretendida. A pesquisa de recuperação está degradada para este canário. Causas possíveis incluem uma pergunta de teste ruim, uma correspondência semântica inesperadamente fraca, filtragem ou uma escolha top k . Tratar a falha como perdida persistência envia o operador para a reparação errada e pode provocar uma escrita dupla. O conflito inverso é mais grave. Se a recuperação de semelhanças retornar um candidato, mas a memória atual não puder ser encontrada através da evidência de alcance ou recurso esperado, não a injetar. A relevância da pesquisa não substitui a proveniência e a frescura. Um canário útil, portanto, faz duas leituras: Não utilize texto de memória de produção como canário sintético. Criar uma identidade de teste específica, um fato não sensível, uma política de validade e um recibo de limpeza. Mantenha o tráfego de canários fora do alcance dos usuários reais. Repete oito recibos estranhos antes de confiar no verde . O artefacto que acompanha este artigo é memory bank health audit.mjs . Não contém credenciais, indicações ou dados de clientes. Classifica oito recibos de operação, escopo, revisão, lista e recuperação sintéticos: A saída executada é: Caixa de fixação O veredicto Porquê? async pending Trabalhar A operação de geração não é feita; enquete a sem duplicar o trabalho. clean write saudável Ação, escopo exato, revisão, lista e recuperação concordam. no topic noop saudável Não se esperava qualquer assunto elegível e não apareceu nenhuma mutação. similarity miss list hit degradados A persistência e a frescura passam; o caminho da consulta falha. wrong scope result falha A memória visível pertence a outro escopo. stale revision falha A revisão visível não corresponde ao evento de origem. deleted still visible falha A operação diz que foi apagada, mas as leituras consumidas ainda expõem a memória. created not fetchable falha A criação foi concluída, mas a memória esperada está ausente do inventário. O caso de não operação importa. A geração de memória extrai apenas informações que correspondem a tópicos configurados. Uma operação pode terminar sem gerar memória quando a fonte não contém nada elegível. Se o seu contrato de teste não esperava fatos duradouros, zero memórias geradas é saudável. Um detector que faz páginas em cada resposta vazia pressionará as equipes a persistirem no ruído. O caso da questão da falta importa pela razão oposta. A fixação marca que ele degradado, não falhou, porque um actual exato escopo de lista hit prova que a persistência sobreviveu. O operador pode ajustar a consulta, inspecionar os filtros ou usar a recuperação com alcance sem reescrever a memória. Os quatro casos de falha não são intencionalmente combinados em erro de memória. Eles implicam diferentes ações de segurança: Interromper a injeção e rever o mapeamento de identidade em caso de violação de âmbito; inspeccionar revisões ou esperar a convergência para verificar o estado em que se encontra; quarentena um facto cuja exclusão não tenha convergido; Verificar nomes, escopo e ações antes de tentar novamente uma escrita completa, mas invisível. Esta prioridade de decisão impede que um facto relevante, mas inseguro, obtenha provas de identidade ou de ciclo de vida: Colocar o recibo no limite do contexto O melhor lugar para aplicar esta regra é imediatamente antes da memória recuperada entrar em um modelo de solicitação, não apenas em uma verificação de armazenamento noturno. Uma verificação periódica pode provar que o serviço foi acessível anteriormente. A fronteira contextual sabe qual a identidade, tarefa, consulta, revisão da fonte e limitação de frescura são importantes agora. Use uma sequência limitada: Normalizar identidade uma vez. Construir o escopo exato a partir de identidade de aplicação autenticada, não de texto gerado por modelo. A normalização dos registos de saúde. Também uma correlação de fonte. Etiquete a solicitação de geração ou revisão com um ID de evento opaco. Não registar o conteúdo da conversa. Respect asíncrono trabalho. Pesquisar o nome da operação até que seja feito ou o prazo da tarefa expira. Preservar o working , o waiting e o uncertain ; não produzir uma falha ou um segundo pedido. Reconciliar o inventário antes da relevância. Confirmar a memória atual esperada sob seu escopo exato, ação e revisão. Então teste o caminho de semelhança que o agente vai usar. Verificar as alterações do ciclo de vida. Para atualizações, exigir a revisão atual esperada. Para as exclusões, exigir a ausência do caminho de leitura de consumo, mantendo a referência de recuperação autorizada apenas enquanto a política o permitir. Faça a decisão de injecção explícita. Regista allow , degrade , wait ou block mais os selos de tempo da prova. Uma resposta modelo bem sucedida após uma injecção insegura não torna retroativamente a memória saudável. Este recibo ainda tem limites. Não pode dizer se um fato extraído é verdadeiro, útil, envenenado ou conforme com a sua política de retenção. Um rótulo de revisão correspondente só demonstra correlação se o produtor escrever os rótulos honestamente. A qualidade de semelhança requer consultas específicas de domínio e revisão humana. Os controles de acesso e os testes adversários continuam a ser necessários, especialmente porque a visão geral do Google adverte que a memória de longo prazo pode levar o risco de injeção rápida e envenenamento de memória para sessões posteriores. A direção do produto da Sidewisp trata a continuidade da memória, a frescura, os limites de identidade e a verificação de resultados como evidências de saúde operacional em torno dos tempos de execução do agente existente. Não substitui o Vertex AI Agent Engine, o IAM, a sua aplicação ou o seu conjunto de testes. A Sidewisp está atualmente em prévia privada. O local público e a demonstração interativa são em directo; coleção de agentes de produção e saúde e integração Vertex AI geralmente não são enviados.