Filtrado de memoria estructurada con metadatos en AgentCore Memory

Supongamos que su agente de atención al cliente pregunta por "problemas de facturación" y recibe tickets de soporte técnico, conversaciones de ventas con problemas de recibos y disputas de facturación, todo mezclado. Este es el muro de precisión de recuperación que los equipos tocan una vez que sus agentes acumulan semanas de historial de interacción: la búsqueda de similitud encuentra todo lo que es semánticamente cercano para este cliente, pero no lo ajusta a las dimensiones relevantes que realmente necesita: tipo de problema, estado o tiempo.

Amazon Bedrock AgentCore Memory es un servicio de memoria totalmente administrado que brinda a los agentes de IA la capacidad de recordar y recuperar información a través de conversaciones. Organiza los registros de memoria del agente en espacios de nombres que definen ámbitos aislados como clientes/cliente-123, de modo que los datos de cada entidad permanezcan separados. Puede leer el blog sobre Organización de la memoria de los agentes a escala: Patrones de diseño de espacios de nombres en AgentCore Memory para comprender más sobre la organización de los espacios de nombres. A medida que los recuerdos crecen, las señales relevantes se ahogan en resultados semánticamente similares pero contextualmente irrelevantes, y el alcance del espacio de nombres por sí solo no puede separarlos.

El filtrado de metadatos cierra esta brecha. Ahora puede aplicar filtros detallados basados ​​en atributos además del aislamiento del espacio de nombres, lo que ayuda a determinar el alcance de la recuperación por dimensiones comerciales como prioridad, departamento o rango de tiempo antes de que se ejecute la búsqueda de similitudes. En nuestras evaluaciones de un conjunto de pruebas de 151 preguntas basadas en un punto de referencia de memoria a largo plazo (conversación de varias sesiones estilo LoCoMo), mostró una mejora. La precisión general de las respuestas a las preguntas (QA) aumentó del 40 % al 64 % con el filtrado de metadatos habilitado en todos los tipos de preguntas. La ganancia se concentra en el subconjunto de preguntas que dependen de límites contextuales, como búsquedas con límite de tiempo, filtrado basado en prioridades o búsquedas con alcance departamental. Para esas preguntas, la precisión saltó del 16% al 69%.

En esta publicación, aprenderá cómo funcionan los metadatos en la configuración, la ingesta y la recuperación, explorará casos de uso empresarial, incluidas arquitecturas multiagente y multiinquilino, y descubrirá las mejores prácticas para la implementación.

AgentCore Memory utiliza espacios de nombres para organizar y aislar recuerdos a lo largo de los límites de la entidad primaria. La recuperación se limita a un espacio de nombres específico, como clientes/cliente-123/sesiónABC o pacientes/paciente-456, para que su agente no recupere accidentalmente los datos de otro cliente o paciente. Los espacios de nombres proporcionan la capa fundamental de separación. Lea más sobre esto en el blog sobre patrones de diseño de espacios de nombres.

A medida que las implementaciones escalan, la búsqueda semántica dentro de un espacio de nombres alcanza algunos límites. Considere un agente de servicios financieros con un espacio de nombres por cliente que ha acumulado seis meses de historial de interacción. Cuando un gerente de relaciones le pide al agente que recuerde “discusiones sobre reequilibrio de cartera” para un cliente específico, el espacio de nombres enfoca correctamente la búsqueda de los recuerdos de ese cliente. Pero los resultados abarcan diferentes estrategias de inversión, períodos de tiempo y niveles de prioridad dentro del historial de ese cliente. El agente no puede distinguir una conversación de reequilibrio de alta prioridad de la semana pasada de una consulta de rutina de hace tres meses. La información es semánticamente similar, pero el contexto es completamente diferente.

Los entornos multiinquilino ilustran claramente la estratificación. Los espacios de nombres ya le brindan una separación completa de datos entre inquilinos. Dentro del espacio de nombres de cada inquilino, los agentes de su servicio de asistencia técnica de TI aún necesitan filtrar el tipo de ticket antes de buscar patrones de resolución. Los espacios de nombres son la separación lógica de quién. El filtrado de metadatos maneja el subgrupo dentro de esos límites: la categoría, el estado de la resolución, la fecha, la prioridad y las etiquetas.

Los metadatos en AgentCore Memory operan en la memoria a corto y largo plazo, siguiendo un ciclo de vida de tres fases: configuración, ingesta y recuperación. Las siguientes secciones explican cómo funcionan los metadatos en cada capa de memoria, comenzando con la memoria a corto plazo y luego sumergiéndose en el ciclo de vida completo de tres fases de la memoria a largo plazo.

Metadatos en la memoria a corto plazo.

En la capa de memoria a corto plazo, se adjuntan pares clave-valor basados ​​en cadenas a los eventos, etiquetando las interacciones con información contextual que no forma parte de la conversación en sí, pero que es fundamental para su recuperación posterior.

Los metadatos de la memoria a corto plazo admiten pares clave-valor basados ​​en cadenas en eventos, que se pueden usar para filtrar. Estas etiquetas pasan a la memoria a largo plazo durante la extracción y consolidación, donde se convierten en dimensiones filtrables.

Metadatos en la memoria a largo plazo

La memoria a largo plazo es donde los metadatos generan todo su impacto. Las tres fases que se describen a continuación le brindan un control preciso sobre cómo se declara, propaga y consulta el contexto estructurado. En resumen, usted declara qué claves importan en el momento de la configuración. Adjunte o deje que el modelo infiera sus valores durante la ingesta y filtrelos en el momento de la recuperación. Cuando varios eventos en una sesión llevan la misma clave, AgentCore Memory los fusiona en un valor usando el comportamiento de resolución que definió en llmExtractionInstruction.

Fase 1: Configuración

Cuando crea un recurso de memoria, declara qué claves de metadatos indexar para un filtrado y recuperación rápidos en los registros de memoria. Definir un esquema de metadatos en cada estrategia de memoria que indique a AgentCore Memory cómo extraer y resolver valores de metadatos. Las claves indexadas se almacenan en un formato optimizado para el filtrado de consultas, mientras que las claves no indexadas se almacenan junto con los registros de memoria con fines informativos.

Lo siguiente crea un recurso de memoria de soporte al cliente con configuración de metadatos:

La extracciónConfig de cada entrada del esquema guía el modelo de lenguaje grande (LLM) durante la extracción de metadatos. El campo de definición describe lo que representa el campo, mientras que llmExtractionInstruction proporciona orientación de extracción adicional y comportamiento de resolución de conflictos. La operación LATEST_VALUE incorporada proporciona resolución basada en lo reciente, mientras que las instrucciones personalizadas en lenguaje natural manejan la lógica específica del dominio. El campo de validación opcional restringe los valores extraídos, como AllowValues ​​para STRING y STRINGLIST, maxItems para STRINGLIST o min-max para NUMBER. Esto mantiene valores consistentes para el filtrado posterior. Observe (en el ejemplo de código anterior) que el sentimiento se define en el esquema pero no se declara como una clave indexada. Por lo tanto, el LLM derivará su valor únicamente del contenido de la conversación y lo completará en los registros extraídos, pero no se puede utilizar en expresiones de filtro de metadatos.

Observe que ticket_id se declara como una clave indexada en el nivel de memoria pero no se incluye en el MemoryRecordSchema de la estrategia. Esta clave no se completará en los registros de memoria extraídos. Solo las claves definidas en el MemoryRecordSchema de la estrategia aparecen en los registros después de la extracción. Las claves indexadas que no aparecen en el esquema se omiten, incluso si existen valores coincidentes en los eventos de origen. Si necesita que una clave aparezca en los registros extraídos, debe tener una entrada de esquema.

Puede leer más sobre las restricciones de configuración en la documentación de AgentCore Memory. Además de las claves de metadatos configuradas, el filtrado temporal (para tener en cuenta la pérdida de memoria, si es relevante) está disponible a través de los campos dateTimeValue generados por el sistema, x-amz-agentcore-memory-createdAt y x-amz-agentcore-memory-updatedAt, que admiten los operadores ANTES y DESPUÉS sin necesidad de declarar claves indexadas de fecha y hora.

Metadatos estrictamente consistentes para valores conocidos

Algunas claves de metadatos son clasificadores organizacionales como departamento, nivel de cumplimiento o tipo de interacción. Estos contienen valores que la aplicación que realiza la llamada ya conoce en el momento de la creación del evento y deben aterrizar en los registros de memoria resultantes exactamente como se proporcionaron. La extracción LLM introduce variabilidad para estas claves: la misma conversación puede producir "eng" en un registro e "Ingeniería" en otro, y un valor proporcionado en el evento puede volver a inferirse durante la extracción. AgentCore Memory soluciona esto con el tipo de extracción STRICTLY_CONSISTENT, una opción para el tipo de extracción LLM_INFERRED. Cuando una clave se configura de esta manera, el valor proporcionado en el evento se propaga sin cambios durante la extracción y consolidación, y no se consulta al LLM para esa clave.

Las claves STRICTLY_CONSISTENT hacen más que omitir la inferencia. Particionan la extracción. Los eventos que comparten los mismos valores siempre se extraen juntos y se aíslan de los eventos con valores diferentes, por lo que no hay ambigüedad sobre qué valor pertenece a un registro.

Este aislamiento también rige la consolidación. Los registros producidos a partir de un conjunto de valores deterministas solo se consolidan con registros que comparten esos mismos valores. Un departamento que lleva registros: "facturación" no se fusionará con un departamento que lleva registros: "ingeniería", independientemente de cuán semánticamente similar pueda ser su contenido.

Considere una sesión de soporte en la que el problema de un cliente abarque varios departamentos:

Sin un aislamiento determinista, los tres acontecimientos se extraerían juntos. El LLM podría asignar departamento: "facturación", departamento: "ingeniería" o incluso departamento: "administración de cuentas" a los hechos resultantes de forma no determinista. Con STRICTLY_CONSISTENT configurado en el departamento:

Los eventos 1 y 2 comparten los mismos valores deterministas (departamento=facturación, prioridad=alta) y se extraen juntos. Los registros de memoria resultantes llevan esos valores exactos. El evento 3 tiene diferentes valores deterministas (departamento=ingeniería, prioridad=alta) y se extrae de forma independiente. Sus registros llevan departamento: "ingeniería" exactamente.

Un agente de facturación que consulta con departamento=facturación recupera solo los datos sobre los cargos duplicados y la actualización del nivel, no los detalles del error de aprovisionamiento del contexto de ingeniería. La consolidación respeta la misma separación: los registros de facturación y los registros de ingeniería no se fusionan, incluso si su contenido está semánticamente relacionado.

Esto hace que las claves deterministas sean ideales para el aislamiento de cumplimiento (los registros HIPAA y los registros estándar no se mezclan), el enrutamiento organizacional (recuperación en el ámbito del departamento sin contaminación cruzada) y cualquier escenario en el que la aplicación que llama conoce un valor en el momento del evento y necesita conservarlo exactamente en las memorias resultantes.

Una clave configurada como STRICTLY_CONSISTENT también debe declararse como clave indexada en el recurso de memoria. Los alcances de consolidación mediante filtros de metadatos en claves indexadas, y ese alcance es lo que evita que se fusionen registros con diferentes valores deterministas. Los eventos a los que les faltan valores para una clave de metadatos determinista aún se procesan y la clave simplemente no está en el registro resultante.

AgentCore Memory admite hasta tres claves STRICTLY_CONSISTENT por estrategia. Cada una de estas claves consume una de las diez ranuras para claves indexadas en el recurso de memoria y las claves indexadas no se pueden eliminar una vez agregadas. Reserve espacios con anticipación si planea utilizar esta función.

Fase 2: Ingestión

Una vez que haya configurado su esquema de metadatos, el siguiente paso es ingerir datos con metadatos adjuntos. Los metadatos ingresan al sistema a través de dos vías. La ruta basada en eventos adjunta metadatos a los eventos y AgentCore Memory los propaga automáticamente mediante extracción y consolidación (según instrucciones de extracción) en registros de memoria a largo plazo:

Cuando varios eventos en una sesión tienen valores diferentes para la misma clave, el LLM resuelve los conflictos utilizando llmExtractionInstruction en esa entrada del esquema. Por ejemplo, si un evento de ticket posterior aumenta la prioridad de "media" a "alta", la instrucción LATEST_VALUE mantiene el valor de prioridad "alta" (figura 3). Una jerarquía personalizada, como la del campo tipo_agente, retiene al agente más especializado en la cadena de manejo (figura 3). Tenga en cuenta que solo las claves de metadatos definidas en el MemoryRecordSchema de la estrategia se completan en los registros de memoria resultantes. Las claves de metadatos de eventos que no están en el esquema se ignoran durante la extracción.

Las claves deterministas siguen una ruta de ingesta diferente. El valor que proporciona en el evento es el valor que aparece en el registro resultante. No hay inferencia LLM ni resolución de conflictos, porque AgentCore Memory agrupa los eventos por sus valores clave deterministas antes de la extracción. Los eventos etiquetados departamento: "ingeniería" y los eventos etiquetados departamento: "finanzas" se procesan en lotes independientes y la consolidación opera dentro de estos grupos. Como resultado, un registro que lleva nivel_de_cumplimiento: "hipaa" no se fusiona con uno etiquetado nivel_de_cumplimiento: "estándar". Eso es lo que hace que la extracción determinista sea adecuada para el aislamiento de cumplimiento y las claves de enrutamiento.

Si llega un evento sin un conjunto de claves determinista, la clave se omite de la agrupación de ese evento y no aparece en el registro resultante. Las rutas de escritura directa (BatchCreateMemoryRecords y BatchUpdateMemoryRecords) omiten la extracción por completo, por lo que el tipo de extracción STRICTLY_CONSISTENT no tiene ningún efecto sobre ellas. Proporcione metadatos directamente como ya lo hace para esas API.

Los metadatos de eventos no son estrictamente necesarios para que las claves de esquema produzcan valores. Cuando una clave de esquema no tiene metadatos coincidentes en los eventos de origen, el LLM deriva el valor completamente del contenido de la conversación utilizando la definición de la clave y llmExtractionInstruction. Considere un esquema con tres claves; ninguno de los cuales se proporciona en eventos:

El registro de memoria extraído se completa con los tres campos inferidos del contenido:

Las reglas de validación aún se aplican: la salida del LLM está restringida a los valores permitidos declarados, independientemente de si el valor proviene de metadatos del evento o de inferencia de contenido. Esta extracción implícita es útil para dimensiones que solo existen en la conversación misma, como la clasificación del tema, el sentimiento o la importancia, sin necesidad de que las personas que llaman las proporcionen en el momento de la creación del evento.

Para la creación directa de registros de memoria, como la importación de bases de conocimiento o la ingesta de registros preprocesados ​​de sistemas externos, usted proporciona metadatos explícitamente:

El comportamiento de los metadatos en registros creados por lotes depende de si proporciona un MemoryStrategyId opcional en cada registro.

Cuando se proporciona MemoryStrategyId, el servicio filtra los metadatos de entrada según el MemoryRecordSchema de esa estrategia. Sólo las claves definidas en el esquema se almacenan en el registro. Otras claves se eliminan silenciosamente, incluidas las claves indexadas que no están en el esquema y las claves que no están declaradas en ninguna parte. Esto le brinda coherencia impuesta por el esquema, asegurándose de que los registros creados por lotes tengan la misma forma de metadatos que los registros producidos mediante extracción basada en eventos.

Cuando se omite MemoryStrategyId, el servicio almacena claves de metadatos en la carga útil tal como están en el registro. Esto incluye claves indexadas, claves que están en un esquema de estrategia y claves que no lo son. Sin embargo, sólo las claves indexadas son filtrables. Intentar filtrar por una clave no indexada devuelve una ValidationException. Las claves no indexadas aún son visibles en las respuestas getMemoryRecord y listMemoryRecords, pero no se pueden usar en expresiones de filtro.

Fase 3: Recuperación

Con los metadatos indexados y completados en sus registros de memoria, ahora puede combinar la búsqueda semántica con filtros de metadatos para determinar el alcance de los resultados. AgentCore Memory utiliza una arquitectura de filtrado previo: los filtros de metadatos se aplican antes de que se ejecute la búsqueda de similitud de vectores. Esto reduce primero el conjunto de candidatos, por lo que la búsqueda de K-vecino más cercano (KNN) opera en un subconjunto más pequeño y relevante. Observe el siguiente ejemplo en el que los resultados se limitan únicamente a registros de alta prioridad del año en curso antes de que la búsqueda semántica coincida con "problemas de facturación".

Observe cómo la combinación de un filtro de metadatos personalizado con una marca de tiempo generada por el sistema compacta el conjunto de candidatos en dos dimensiones, prioridad empresarial y actualidad, antes de que se ejecute la búsqueda de similitud. AgentCore Memory proporciona múltiples operadores para cubrir patrones de consulta comunes.

AgentCore Memory también agrega campos de metadatos generados por el servicio utilizando el prefijo x-amz-agentcore-memory-*, que puede consultar con los mismos operadores de filtro para admitir consultas de rango de tiempo sin claves de fecha y hora personalizadas.

Por qué el filtrado temporal ofrece las mayores ganancias en precisión

En nuestros experimentos, las consultas con limitaciones de tiempo mostraron la mayor mejora con el filtrado de metadatos. El filtrado estructurado DATETIME con los operadores ANTES y DESPUÉS convierte esto en una búsqueda de índice determinista, evitando ambigüedades.

Para la recuperación no basada en búsquedas, ListMemoryRecords proporciona filtrado de metadatos sin búsqueda semántica. Esto resulta útil cuando necesita enumerar registros que coinciden con criterios de metadatos específicos en lugar de encontrar contenido semánticamente similar. Por ejemplo, puede enumerar registros de alta prioridad para un cliente o extraer registros etiquetados con un departamento específico.

El siguiente ejemplo enumera registros de alta prioridad creados después de una fecha específica:

Casos de uso empresarial

Los siguientes ejemplos muestran cómo el filtrado de metadatos aborda los desafíos comunes de recuperación empresarial en todas las industrias.

Aplicaciones SaaS multiinquilino

Si dirige una empresa SaaS con asistentes de IA para varios clientes empresariales, los espacios de nombres ya proporcionan aislamiento de inquilino principal, donde las memorias de cada inquilino viven en un espacio de nombres dedicado como /tenants/{actorId}/. Los metadatos agregan filtrado detallado dentro de esos límites para agregar dimensiones comerciales. Al indexar claves de metadatos como segmento_cliente, departamento o nivel_suscripción, asigna la recuperación directamente a su jerarquía empresarial sin mantener almacenes de memoria separados por dimensión organizativa.

Filtrado organizacional jerárquico: dentro del espacio de nombres de un inquilino, los metadatos permiten una recuperación detallada dirigida a departamentos, equipos o proyectos específicos. Por ejemplo, puede recuperar recuerdos solo con departamento: "ingeniería" y equipo: "plataforma" cuando un ingeniero de plataforma pregunta sobre problemas con el servicio de autenticación. Esto se asigna directamente a los organigramas empresariales sin requerir espacios de nombres separados por unidad organizativa.

Recuperación basada en niveles de suscripción: los modelos SaaS pueden usar metadatos para diferenciar el comportamiento de la memoria por nivel de cliente. Un inquilino de nivel empresarial puede obtener una recuperación completa del historial, mientras que un inquilino de nivel inicial obtiene una recuperación limitada únicamente a los recuerdos recientes (usando filtros DESPUÉS de fecha y hora en x-amz-agentcore-memory-createdAt). Esto admite la activación de funciones en la capa de memoria sin una infraestructura separada por nivel.

Dominios sensibles a la atención sanitaria y al cumplimiento

Si su agente de IA de atención médica gestiona las interacciones de los pacientes en varios departamentos, los espacios de nombres como pacientes/paciente-123 ya aíslan los recuerdos de cada paciente. Pero dentro del espacio de nombres de un solo paciente, una búsqueda amplia de "historial de medicación" arroja resultados de todos los departamentos: cardiología, endocrinología y atención primaria. Al indexar claves de metadatos como departamento, tipo de registro, gravedad y síntomas, su agente puede limitar la recuperación a lo largo de múltiples dimensiones clínicas dentro del espacio de nombres de un paciente.

El operador CONTAINS en los síntomas STRINGLIST verifica si la lista incluye el valor especificado, lo que limita la recuperación a indicadores clínicos específicos.

Para el cumplimiento, el filtrado de metadatos ayuda a alinearse con los requisitos reglamentarios.

HIPAA: el filtrado a nivel de departamento garantiza que la consulta de un cardiólogo solo recupere registros relevantes para la cardiología, lo que reduce el riesgo de que surjan datos clínicos no relacionados. GDPR: los filtros de metadatos en x-amz-agentcore-memory-createdAt ayudan a identificar registros fuera de las ventanas de retención. La eliminación se gestiona mediante DeleteMemoryRecord o la eliminación en el ámbito del espacio de nombres. SOC 2: las marcas de tiempo generadas por el sistema proporcionan un rastro verificable de que la recuperación tuvo el alcance correcto. También puede indexar una clave de clasificación de datos (con valores como PII, confidencial o general) para una recuperación teniendo en cuenta la sensibilidad.

Atención al cliente con enrutamiento basado en prioridades

Si su organización de soporte maneja miles de tickets, necesita agentes que prioricen el contexto según la urgencia y el estado de escalamiento. Los metadatos admiten patrones de recuperación como "buscar recuerdos de facturación de alta prioridad de los últimos 30 días" combinando filtros de metadatos personalizados con filtros de marca de tiempo del sistema. Durante una sesión en vivo, su agente extrae el contexto de alta prioridad más relevante sin tener que analizar problemas resueltos de baja prioridad. A medida que los tickets pasan de bajo a crítico, las reglas de fusión mantienen los metadatos de las memorias consolidadas alineados con el último estado de escalada en lugar de con la clasificación inicial.

Servicios financieros y precisión temporal

Los datos financieros son inherentemente urgentes. Una consulta sobre “discusiones de cartera del tercer trimestre” debe devolver registros específicos del tercer trimestre, no registros de otros trimestres. Un agente de gestión patrimonial puede combinar el filtrado DATETIME con metadatos personalizados para determinar el alcance de la recuperación con precisión, lo que le ayuda a evitar el ruido de otras clases de activos y períodos de tiempo:

Sistemas multiagente y coordinación de la memoria.

A medida que los sistemas agentes maduran y se vuelven más prominentes, los metadatos se vuelven críticos para determinar cómo múltiples agentes comparten y coordinan a través de una capa de memoria común.

Procedencia del agente: en flujos de trabajo de múltiples agentes, saber qué agente creó una memoria es esencial para la confianza, la depuración y el enrutamiento. Al indexar claves como source_agent, agent_role y flow_step, el agente supervisor puede filtrar los recuerdos almacenados por un agente específico. Por ejemplo, puede filtrar agente_fuente: "agente_facturación" dentro del espacio de nombres del cliente para responder "¿Qué concluyó el agente de facturación en la última sesión?" Visibilidad de la memoria en el ámbito del agente: en una canalización de múltiples agentes (desde un robot de clasificación hasta un agente de nivel 1 y un especialista), puede usar metadatos para controlar qué recuerdos recupera cada agente. El robot de clasificación escribe recuerdos con flow_step: "triage". Un especialista que maneja una escalada filtra por flujo de trabajo_paso: "triage" para comprender la clasificación inicial, o por agente_role: "tier1" para revisar lo que ya se intentó, evitando trabajo duplicado. La llmExtractionInstruction personalizada para agent_role habría consolidado recuerdos para reflejar el manejo con mayor experiencia, no solo el toque más reciente. Recuperación controlada por metadatos en canales de recuperación de generación aumentada (RAG): un agente de recuperación filtra por tipo_fuente: "base_de_conocimiento" para una base objetiva, un agente de personalización filtra por tipo_interacción: "preferencia" para el contexto específico del usuario, y un agente de seguridad filtra por bandera_contenido: "revisado" para contenido examinado. Los tres consultan el mismo espacio de nombres pero reciben conjuntos de resultados completamente diferentes sin administrar múltiples almacenes de memoria.

Sus sistemas de memoria de producción no son estáticos y los esquemas de metadatos deben evolucionar junto con las aplicaciones a las que sirven. AgentCore Memory admite la evolución del esquema a través de un modelo de actualización solo aditivo. Puede agregar nuevas claves de metadatos indexados a un recurso de memoria existente según sea necesario:

Nuevas claves quedan inmediatamente disponibles para eventos entrantes y registros de memoria. Los registros existentes no reciben retroactivamente el nuevo campo, pero a medida que los recuerdos más antiguos se consolidan con los más nuevos, adquieren naturalmente los nuevos metadatos. No puede eliminar una clave previamente indexada, lo que ayuda a evitar la pérdida accidental de la capacidad de filtrado de los datos existentes. Puede agregar, eliminar o modificar libremente claves no indexadas en esquemas de metadatos a nivel de estrategia a medida que evolucionen sus necesidades de extracción.

Mejores prácticas

Comience con las dimensiones de filtrado que sus agentes necesitan. Evite indexar todos los campos de metadatos imaginables por adelantado. Cada campo indexado consume una de sus ranuras de clave indexada y agrega costos en ambas rutas: más trabajo por escritura durante la ingesta y compactación de consultas en las lecturas. Comience con tres a cinco claves que afecten directamente a la calidad de la recuperación y agregue más a medida que surjan necesidades concretas.

Escriba definiciones claras y específicas. El campo de definición y llmExtractionInstruction juntos son la instrucción principal que recibe el LLM para la extracción de metadatos. En lugar de "La prioridad del ticket", escriba "Nivel de prioridad del problema basado en el impacto en el cliente. Utilice 'crítico' para interrupciones del servicio que afectan la producción, 'alto' para rendimiento degradado, 'medio' para solicitudes de funciones, 'bajo' para documentación o problemas cosméticos".

Elija reglas de combinación que coincidan con la semántica del dominio. LATEST_VALUE es un valor predeterminado seguro para la mayoría de los campos, pero no siempre es correcto. Para agent_type en un flujo de trabajo de escalada de soporte, se debe conservar el tipo de agente más antiguo, no el más reciente. Las instrucciones de fusión personalizadas expresarían esta lógica de dominio.

Restrinja la salida de LLM con reglas de validación. Defina los valores permitidos en el campo de validación para imponer un vocabulario controlado. Sin validación, el LLM podría producir "Alto", "alto", "ALTO" o "crítico" para el mismo concepto, rompiendo la coincidencia de filtros posteriores.

Diseñe la ruta basada en eventos para claves cuyos valores se conocen en el momento del evento y permanecen constantes en todos los eventos de una sesión, como departamento o inquilino_tier. Adjunte metadatos a los eventos y permita que AgentCore Memory los propague mediante extracción para la resolución automática de conflictos y el manejo de la consolidación. Reserve la ruta API por lotes directa para importaciones masivas y contenido preprocesado donde ya conoce los valores de metadatos correctos.

Planificar esquemas de metadatos a nivel de estrategia. Cada estrategia de memoria puede tener su propio esquema de metadatos, lo que permite que diferentes estrategias extraigan y manejen las mismas claves de manera diferente. Una estrategia semántica podría utilizar instrucciones de extracción personalizadas para clasificar la prioridad a partir del contexto de la conversación, mientras que una estrategia de resumen podría utilizar una definición diferente adaptada a metadatos específicos del resumen. Esta flexibilidad admite el manejo optimizado de metadatos por estrategia sin comprometer la infraestructura de claves indexadas compartidas.

Sea intencional con MemoryStrategyId en registros creados por lotes. Cuando incluye MemoryStrategyId en una solicitud de creación por lotes, el servicio filtra los metadatos de entrada solo para las claves del esquema de esa estrategia, y otras claves se eliminan silenciosamente. Esto es útil para hacer cumplir la coherencia con los registros producidos por extracción. Cuando lo omite, los metadatos de la carga útil se almacenan tal cual. Elija según su caso de uso: coherencia impuesta por el esquema para registros que deberían parecerse a los extraídos, o control total para importaciones masivas en las que administra metadatos externamente.

Utilice claves de esquema no indexadas para enriquecer el contexto. No todas las claves de metadatos necesitan poder filtrarse. Las claves de esquema que no se declaran como claves indexadas aún se completan en los registros extraídos y son visibles en las respuestas de obtención y lista, pero no se pueden usar en expresiones de filtro. Esto es útil para los metadatos que enriquecen el registro para el consumo posterior (por ejemplo, sentimiento, notas_resumen o URL_fuente) sin consumir su presupuesto de claves indexadas. Reserve claves indexadas para las dimensiones que filtra activamente.

Utilice la extracción determinista para valores que ya conoce. Si una clave representa un atributo organizacional fijo que tiene el agente en el momento de la creación del evento, como departamento, nivel de inquilino o alcance de cumplimiento, configúrelo como STRICTLY_CONSISTENT y proporciónelo en cada evento. Esto garantiza valores exactos en los registros resultantes y elimina la deriva de normalización (“eng” en comparación con “Ingeniería”) que puede introducir la extracción LLM. Reserve llmExtractionConfig para dimensiones que deben inferirse del contenido de la conversación, como sentimiento o tema.

Evite estos antipatrones:

No indexe campos de texto libre de alta cardinalidad, como descripciones o nombres completos, ya que inflan el índice sin límites de filtro útiles. No utilice metadatos para valores que cambian en cada interacción; Los metadatos son más eficaces para atributos estables o que cambian lentamente. No replique el aislamiento del espacio de nombres únicamente a través de metadatos. Un campo de metadatos Tenent_id sin aislamiento de espacio de nombres es un modelo de seguridad mediante convención que se rompe ante cualquier filtro omitido.

Conclusión

El filtrado de metadatos en AgentCore Memory aborda un desafío de recuperación fundamental. Los espacios de nombres ya aíslan los recuerdos de entidades primarias como usuarios, inquilinos o proyectos. Con el filtrado de metadatos estructurados superpuesto al alcance del espacio de nombres, puede limitar la recuperación de su agente a límites contextuales precisos antes de que se ejecute la coincidencia de similitudes, lo que ofrece una precisión mensurablemente mejor y una base práctica para el cumplimiento, la gestión del contexto basada en prioridades y el filtrado organizacional detallado. La extracción impulsada por LLM evita la carga del etiquetado manual, mientras que las instrucciones de extracción configurables manejan la propagación de metadatos y la resolución de conflictos a escala.

Para comenzar, identifique de tres a cinco dimensiones de filtrado que impacten más directamente en la calidad de recuperación para su caso de uso. Comience con una prueba de concepto (PoC) utilizando un recurso de memoria ficticia para probar las estrategias relevantes y luego amplíe el esquema a medida que surjan necesidades concretas. Los siguientes recursos proporcionan orientación práctica:

Sobre los autores