Vertex AI Agent Engine Memory Bank: demostrar alcance y retirada

Vertex AI Agent Engine Memory Bank puede aceptar eventos de origen, generar una memoria y devolverla más tarde. Esa secuencia es útil, pero una llamada SDK exitosa no prueba que el siguiente turno del agente haya recibido la memoria correcta para la identidad correcta. Lo razonable por defecto es tratar la memoria a largo plazo como una pequeña fuente de evidencia. Espere a que finalice la operación de generación. Verifique la acción reportada. Recuperar bajo el alcance exacto previsto. Correlacione la memoria visible con el evento o revisión fuente. Mantenga la calidad de similitud separada de la persistencia básica. Confirme que las actualizaciones y eliminaciones hayan convergido antes de insertar un hecho en un mensaje. Este artículo convierte esos pasos en un recibo sanitario sin contenido. Un dispositivo ejecutable de ocho casos produce dos casos en buen estado, uno que aún funciona, un caso de recuperación degradado y cuatro fallas. El punto no es calificar el servicio de Google. Es para hacer que su propia integración distinga el trabajo pendiente, una no operación válida, una consulta perdida, un estado obsoleto, una visibilidad entre alcances y una discrepancia en el ciclo de vida. Una solicitud completa es solo el primer recibo. Actualidad de Google Descripción general de Memory Bank separa las sesiones de la memoria a largo plazo. Los eventos de sesión proporcionan el historial de conversaciones de origen. GenerateMemories puede extraer y consolidar hechos duraderos para un alcance, mientras que CreateMemory permite que un agente escriba un hecho directamente. Más tarde, RetrieveMemories suministra memoria con alcance a otro turno. Ese flujo tiene varios límites observables: 1. el evento fuente existe; 2. ha comenzado la generación de memoria; 3. su operación a largo plazo ha terminado; 4. la respuesta dice que una memoria era CREATED , UPDATED o DELETED ; 5. el recurso actual es visible en el alcance previsto; 6. la ruta de recuperación adecuada encuentra la revisión esperada; 7. en realidad, el agente consumidor sólo utiliza pruebas que pasaron esos controles. El documentación de generación describe explícitamente GenerateMemories como una operación de larga duración. Una respuesta completa puede informar tres acciones diferentes. CREATED significa que se agregó una nueva memoria. UPDATED significa que la consolidación cambió una memoria existente. DELETED significa que la información de fuente más reciente invalidó una memoria existente. No combine esas acciones en un booleano llamado memory saved . Más importante aún, no aplaste una operación inconclusa hasta convertirla en un fracaso. Si operation.done es falso, el trabajo aún está pendiente. Sondear la operación existente dentro de un plazo; iniciar otra solicitud de generación simplemente porque la primera no ha terminado puede crear trabajo duplicado o una consolidación confusa. Un recibo mínimo puede evitar almacenar el contenido de la conversación: El hash de una operación o identificador de alcance reduce la exposición incidental en un registro de salud; no hace que un identificador débil sea seguro. Mantenga los ID de usuario sin procesar, los datos, las indicaciones, las credenciales y los tokens de acceso fuera del recibo. La aplicación aún necesita un mapeo protegido cuando un operador debe investigar una falla. El alcance exacto y la revisión actual deben coincidir Memory Bank mantiene una colección aislada para cada ámbito. La corriente buscar documentación dice que la recuperación basada en el alcance devuelve solo recuerdos con un alcance que coincida exactamente, independientemente del orden de las claves, y que el alcance de una memoria es inmutable. Se trata de un límite de servicio sólido, pero su integración aún elige el alcance. Un error de mapeo puede solicitar la identidad de usuario, proyecto, inquilino o agente incorrecto y recibir un resultado técnicamente válido. Por lo tanto, la salud necesita dos comparaciones: alcance de la solicitud: el alcance normalizado exacto que pretendía la tarea; alcance devuelto: el alcance adjunto a cada memoria visible. Cualquier discrepancia bloquea la inyección. La relevancia no puede anular la identidad. Un hecho muy similar de otro usuario no es un resultado degradado; es un fallo de aislamiento. Las revisiones proporcionan una segunda comparación. Google documentación de revisión dice que la creación y modificación de la memoria guardan revisiones inmutables de forma predeterminada. Una memoria actual es el estado consolidado; sus revisiones secundarias preservan los estados históricos y, para los recuerdos generados, los pasos extraídos y consolidados. Adjunte una identificación de fuente sin contenido utilizando etiquetas de revisión o metadatos de la aplicación cuando su contrato lo permita. Luego compare la revisión fuente esperada con la revisión visible después de la generación. Si la operación informa UPDATED para evt 106 pero la recuperación aún expone evt 099 , el estado seguro es obsoleto o incierto. No es saludable simplemente porque el hecho parezca plausible. La eliminación necesita su propia regla. La respuesta de generación documentada puede decir DELETED , y al recuperar esa memoria eliminada debería devolverse 404 . Los recursos de revisión permanecen inspeccionables durante un período de recuperación limitado después de la eliminación principal. Si un hecho supuestamente eliminado permanece visible para la ruta de consumo, manténgalo fuera de contexto y concilie el ciclo de vida. Por el contrario, un 404 después de una eliminación documentada es evidencia de convergencia, no un incidente de disponibilidad. La búsqueda de listas y similitudes responde a diferentes preguntas Memory Bank expone varias rutas de recuperación: Get recupera un recurso de memoria completamente calificado; List enumera memorias en el banco y admite filtros; Retrieve basado en alcance devuelve todas las memorias para un alcance exacto cuando no se proporcionan parámetros de similitud; similitud Retrieve clasifica los recuerdos dentro de un alcance exacto para una consulta. Estas rutas no deben compartir una métrica memory found indiferenciada. Supongamos que GenerateMemories se completa con UPDATED . Una lista de alcance muestra la revisión actual esperada, pero una consulta de similitud no devuelve filas. El plano de persistencia es saludable: la memoria existe bajo la identidad prevista. La recuperación de consultas está degradada para este canario. Las posibles causas incluyen una consulta de prueba deficiente, una coincidencia semántica inesperadamente débil, un filtrado o una elección top k . Tratar el fallo como persistencia perdida envía al operador hacia la reparación incorrecta y puede provocar una escritura duplicada. El conflicto inverso es más grave. Si la recuperación de similitud devuelve un candidato pero la memoria actual no se puede encontrar a través del alcance esperado o la evidencia de recursos, no lo inyecte. La relevancia de la búsqueda no sustituye la procedencia y la frescura. Por lo tanto, un canario útil realiza dos lecturas: No utilice texto de la memoria de producción como canario sintético. Cree una identidad de prueba dedicada, un hecho no confidencial, una política de vencimiento y un recibo de limpieza. Mantenga el tráfico canary fuera del alcance de los usuarios reales. Vuelva a reproducir ocho recibos incómodos antes de confiar en el verde El artefacto que acompaña a este artículo es memory bank health audit.mjs . No contiene credenciales, indicaciones ni datos del cliente. Clasifica ocho recibos sintéticos de operación, alcance, revisión, listado y recuperación: La salida ejecutada es: Caja de accesorios Veredicto Por qué async pending laboral La operación de generación no se realiza; sondearlo sin duplicar el trabajo. clean write saludable Acción, alcance exacto, revisión, lista y recuperación están de acuerdo. no topic noop saludable No se esperaba ningún tema elegible y no apareció ninguna mutación. similarity miss list hit degradado Pasa la persistencia y la frescura; la ruta de consulta falla. wrong scope result fallar La memoria visible pertenece a otro ámbito. stale revision fallar La revisión visible no coincide con el evento fuente. deleted still visible fallar La operación dice eliminada, pero las lecturas que consumen aún exponen la memoria. created not fetchable fallar La creación se completó, pero la memoria esperada no está en el inventario con alcance. El caso sin operación importa. La generación de memoria extrae solo información que coincide con los temas configurados. Una operación puede finalizar sin generar una memoria cuando la fuente no contiene nada elegible. Si su contrato de prueba no esperaba ningún hecho duradero, los recuerdos generados cero son saludables. Un detector que busque cada respuesta vacía presionará a los equipos para que persistan en el ruido. El caso de consulta perdida es importante por la razón opuesta. El dispositivo lo marca degradado, no fallido, porque una lista actual de alcance exacto demuestra que la persistencia sobrevivió. El operador puede ajustar la consulta, inspeccionar filtros o utilizar la recuperación de ámbito sin reescribir la memoria. Los cuatro casos fallidos no se combinan intencionalmente en "error de memoria". Implican diferentes acciones seguras: detener la inyección y revisar el mapeo de identidad para detectar una violación del alcance; inspeccionar las revisiones o esperar la convergencia para el estado obsoleto; poner en cuarentena un hecho cuya supresión no haya convergido; verifique los nombres, alcances y acciones antes de volver a intentar una escritura completa pero invisible. Esta precedencia de decisión evita que un hecho relevante pero inseguro gane la identidad o la evidencia del ciclo de vida: Poner el recibo en el límite del contexto. El mejor lugar para hacer cumplir esta regla es inmediatamente antes de que la memoria recuperada ingrese a un mensaje del modelo, no solo en una verificación de almacenamiento nocturna. Una verificación periódica puede demostrar que se pudo acceder al servicio antes. El límite del contexto sabe qué identidad, tarea, consulta, revisión de fuente y límite de actualización importan ahora. Utilice una secuencia acotada: Normalice la identidad una vez. Cree el alcance exacto a partir de la identidad de la aplicación autenticada, no del texto generado por el modelo. Hash el alcance normalizado del registro médico. Lleve una correlación de origen. Etiquete la solicitud de generación o revisión con un ID de evento opaco. No registre el contenido de la conversación. Respete el trabajo asincrónico. Sondee el nombre de la operación hasta que finalice o expire la fecha límite de la tarea. Preservar working , waiting y uncertain ; no fabrique una falla o una segunda solicitud. Conciliar el inventario antes de la relevancia. Confirmar la memoria actual esperada según su alcance, acción y revisión exactos. Luego pruebe la ruta de similitud que utilizará el agente. Verifique los cambios en el ciclo de vida. Para actualizaciones, solicite la revisión actual esperada. Para las eliminaciones, exija la ausencia de la ruta de lectura de consumo y, al mismo tiempo, conserve la referencia de recuperación autorizada solo mientras la política lo permita. Haga explícita la decisión de inyección. Registre allow , degrade , wait o block más las marcas de tiempo de las pruebas. Una respuesta modelo exitosa después de una inyección insegura no hace que la memoria sea saludable de manera retroactiva. Este recibo todavía tiene límites. No puede determinar si un hecho extraído es verdadero, útil, envenenado o cumple con su política de retención. Una etiqueta de revisión coincidente demuestra correlación sólo si el productor escribe las etiquetas honestamente. La calidad de similitud necesita consultas de dominio específico y revisión humana. Los controles de acceso y las pruebas adversas siguen siendo necesarios, especialmente porque la descripción general de Google advierte que la memoria a largo plazo puede conllevar un riesgo de inyección rápida y envenenamiento de la memoria en sesiones posteriores. La dirección de producto de Sidewisp trata la continuidad de la memoria, la frescura, los límites de identidad y la verificación de resultados como evidencia de salud operativa en torno a los tiempos de ejecución de agentes existentes. No reemplaza a Vertex AI Agent Engine, IAM, su aplicación ni su conjunto de pruebas. Sidewisp se encuentra actualmente en versión preliminar privada. El sitio público y la demostración interactiva están en vivo; La recopilación de estado del agente de producción y la integración de Vertex AI generalmente no se envían.