Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Metadatos estructurados para memorias a largo plazo

El filtrado de metadatos de Amazon Bedrock AgentCore Memory le permite añadir atributos estructurados a sus registros de memoria a largo plazo. Puede usar esos atributos para restringir los registros que se devuelven durante la recuperación. Los espacios de nombres ya aíslan las memorias por entidad principal (usuario, inquilino, paciente, cliente). Sin embargo, dentro de un único espacio de nombres, una búsqueda semántica amplia devuelve todo lo que tiene un significado similar. Con el filtrado de metadatos, solo puedes recuperar los resultados que coincidan con valores de atributos específicos. Por ejemplo, puede recuperar solo los registros de alta prioridad, solo los registros de un departamento en particular o solo los registros creados dentro de un intervalo de tiempo determinado.

Con el filtrado de metadatos, puede:

Introducción

La configuración del filtrado de metadatos implica cinco pasos:

En las secciones siguientes se describe cada paso en detalle.

Conceptos clave

Claves de metadatos indexadas

Las claves indexadas se declaran a nivel de recurso de memoria en CreateMemory (o se agregan más adelante). UpdateMemory Las claves indexadas se almacenan en un formato optimizado para un filtrado rápido de las consultas. Solo se pueden consultar las claves indexadas en y. metadataFilters ListMemoryRecords RetrieveMemoryRecords

En el siguiente ejemplo, se declaran dos claves indexadas:

{
  "indexedKeys": [
    { "key": "priority", "type": "STRING" },
    { "key": "tags",     "type": "STRINGLIST" }
  ]
}

typeValores admitidos:STRING,STRINGLIST,NUMBER.

Las claves deben coincidir ^[a-zA-Z0-9\s._:/=+@-]*$ (máximo 128 caracteres).

La adición de una clave indexada no rellena los registros existentes. Solo los registros creados o actualizados después de declarar la clave se indexan para esa clave. Para obtener más información sobre la evolución de su esquema a lo largo del tiempo, consultePaso 5: Evoluciona tu esquema de metadatos.

Esquema de metadatos (por estrategia)

La estrategia de memoria puede tener, de forma opcional, un esquema de metadatos declarado enmemoryRecordSchema.metadataSchema. El esquema de metadatos indica al LLM qué metadatos extraer del contenido conversacional al generar registros de memoria. Durante la extracción basada en eventos, solo las claves definidas en el esquema de metadatos de la estrategia se rellenan en los registros de memoria resultantes.

Cada entrada del esquema define:

El siguiente ejemplo muestra una entrada de esquema de metadatos con validación:

{
  "metadataSchema": [
    {
      "key": "priority",
      "type": "STRING",
      "extractionConfig": {
        "llmExtractionConfig": {
          "definition": "Issue priority level based on customer impact. Values range from critical (most severe) to low (least severe).",
          "llmExtractionInstruction": "LATEST_VALUE",
          "validation": {
            "stringValidation": {
              "allowedValues": ["critical", "high", "medium", "low"]
            }
          }
        }
      }
    }
  ]
}

Opciones de validación por tipo:

Metadatos deterministas (tipo de extracción STRICTLY_CONSISTENT)

Las claves de metadatos deterministas contienen valores que la aplicación ya conoce al crear un evento. Estos valores se copian exactamente en los registros de memoria resultantes sin modificarlos. Los clasificadores organizacionales son similares department o no agent_id deberían inferirse del LLM. compliance_level La inferencia del LLM introduce variabilidad. Por ejemplo, la misma conversación puede producirse "eng" en un registro y "Engineering" en otro.

Para estas claves, extractionType establézcalas STRICTLY_CONSISTENT en en la entrada del esquema de metadatos. El valor proporcionado en el evento se propaga sin cambios durante la extracción y la consolidación. No se consulta al LLM para obtener esa clave.

El siguiente JSON muestra un esquema de metadatos con ambos tipos STRICTLY_CONSISTENT de LLM_INFERRED extracción:

{
  "metadataSchema": [
    {
      "key": "department",
      "type": "STRING",
      "extractionType": "STRICTLY_CONSISTENT"
    },
    {
      "key": "compliance_level",
      "type": "STRING",
      "extractionType": "STRICTLY_CONSISTENT"
    },
    {
      "key": "topic",
      "type": "STRING",
      "extractionType": "LLM_INFERRED",
      "extractionConfig": {
        "llmExtractionConfig": {
          "definition": "Primary topic of the conversation",
          "llmExtractionInstruction": "Identify the main topic discussed"
        }
      }
    }
  ]
}

Cuando se omiteextractionType, el valor predeterminado esLLM_INFERRED.

Aislamiento de extracción y consolidación

STRICTLY_CONSISTENTlas claves hacen más que omitir la inferencia de un LLM. Agrupan los eventos por sus valores deterministas durante la extracción. Los eventos con valores diferentes se procesan por separado. La consolidación sigue la misma regla. Los registros de un grupo de valores nunca se combinan con los registros de otro grupo.

El siguiente ejemplo de Python muestra una sesión de soporte con dos claves deterministas (departmentypriority):

# Event 1: high-priority billing inquiry
agentcore_client.create_event(
    memoryId="mem-support-abc123",
    actorId="customer-123",
    sessionId="session-escalation-001",
    payload=[{"conversational": {"role": "USER",
        "content": {"text": "I'm seeing duplicate charges on my invoice and it's blocking our deployment."}}}],
    metadata={
        "department": {"stringValue": "billing"},
        "priority": {"stringValue": "high"}
    }
)

# Event 2: also high-priority billing (same deterministic values as Event 1)
agentcore_client.create_event(
    memoryId="mem-support-abc123",
    actorId="customer-123",
    sessionId="session-escalation-001",
    payload=[{"conversational": {"role": "USER",
        "content": {"text": "The charges appeared after we upgraded from standard to enterprise tier last week."}}}],
    metadata={
        "department": {"stringValue": "billing"},
        "priority": {"stringValue": "high"}
    }
)

# Event 3: high-priority engineering (same priority, different department)
agentcore_client.create_event(
    memoryId="mem-support-abc123",
    actorId="customer-123",
    sessionId="session-escalation-001",
    payload=[{"conversational": {"role": "USER",
        "content": {"text": "Your team found a provisioning bug that triggered the duplicate charge."}}}],
    metadata={
        "department": {"stringValue": "engineering"},
        "priority": {"stringValue": "high"}
    }
)

# Event 4: low-priority billing (same department as Events 1-2, different priority)
agentcore_client.create_event(
    memoryId="mem-support-abc123",
    actorId="customer-123",
    sessionId="session-escalation-001",
    payload=[{"conversational": {"role": "USER",
        "content": {"text": "Also, can you update the billing contact email on file when you get a chance?"}}}],
    metadata={
        "department": {"stringValue": "billing"},
        "priority": {"stringValue": "low"}
    }
)

El sistema agrupa los eventos según la combinación exacta de todos los valores clave deterministas:

Todos los valores clave deterministas deben coincidir para que los eventos se agrupen. Una consulta con department=billing AND solo priority=high devuelve los datos urgentes de los cargos duplicados. Los demás eventos están en particiones separadas. Los registros de diferentes combinaciones de valores nunca se combinan durante la consolidación.

Restricciones

Cómo interactúan las claves indexadas y las claves de esquema

La relación entre las claves indexadas y las claves de esquema determina el comportamiento de los metadatos:

Cómo fluyen los metadatos de los eventos a los registros de memoria

Los metadatos de los eventos solo aceptan stringValue entradas. Los registros stringValuestringListValue, el soporte y los numberValue tipos de memoria los rellena el LLM durante la extracción o los suministra directamente a través de las API de procesamiento por lotes. El dateTimeValue tipo está reservado para los campos generados por el sistema (x-amz-agentcore-memory-createdAty). x-amz-agentcore-memory-updatedAt En los registros extraídos solo se metadataSchema rellenan las claves definidas en la estrategia; las claves de metadatos de los eventos que no figuran en el esquema se ignoran. Para conocer los límites de entrada, consulteCuotas.

System-generated metadatos

Todos los registros de memoria contienen los siguientes campos del sistema, que se pueden consultar con los mismos operadores de filtro:

No es necesario declararlas como claves indexadas, ya que siempre están disponibles para filtrarlas. Estos dateTimeValue campos generados por el sistema admiten AFTER operadores tipo BEFORE Y, por lo tanto, permiten realizar consultas por intervalos de tiempo sin necesidad de declarar claves indexadas de fecha y hora.

Requisitos previos

Antes de configurar el filtrado de metadatos, compruebe que tiene:

Paso 1: Cree una memoria con claves indexadas y un esquema de metadatos

A continuación, se crea una memoria de soporte al cliente con cinco claves indexadas y un esquema de metadatos. priorityagent_type, y sentiment se definen en el esquema de metadatos de la estrategia: el LLM extrae sus valores del contenido de la conversación. Tenga en cuenta que sentiment está en el esquema pero no se declara como una clave indexada: el LLM obtiene su valor de las conversaciones y lo rellena en los registros, pero no se puede usar en expresiones de filtro. tags(STRINGLIST), channel (STRING) y ticket_id (STRING) se declaran como claves indexadas, pero no están en el esquema; no se rellenan durante la extracción basada en eventos, sino que se pueden proporcionar mediante las API por lotes.

aws bedrock-agentcore-control create-memory \
  --name "CustomerSupportMemory" \
  --event-expiry-duration 30 \
  --indexed-keys '[
    {"key": "priority",   "type": "STRING"},
    {"key": "agent_type", "type": "STRING"},
    {"key": "tags",       "type": "STRINGLIST"},
    {"key": "channel",    "type": "STRING"},
    {"key": "ticket_id",  "type": "STRING"}
  ]' \
  --memory-strategies '[
    {
      "semanticMemoryStrategy": {
        "name": "SupportSemanticStrategy",
        "description": "Captures support interaction details",
        "namespaceTemplates": ["support/{actorId}"],
        "memoryRecordSchema": {
          "metadataSchema": [
            {
              "key": "priority",
              "type": "STRING",
              "extractionConfig": {
                "llmExtractionConfig": {
                  "definition": "Issue priority level based on customer impact. Values range from critical (most severe) to low (least severe).",
                  "llmExtractionInstruction": "LATEST_VALUE",
                  "validation": {
                    "stringValidation": {
                      "allowedValues": ["critical", "high", "medium", "low"]
                    }
                  }
                }
              }
            },
            {
              "key": "agent_type",
              "type": "STRING",
              "extractionConfig": {
                "llmExtractionConfig": {
                  "definition": "Support agent classification.",
                  "llmExtractionInstruction": "Prefer the most specialized agent type. Hierarchy: specialist > tier3 > tier2 > tier1 > bot."
                }
              }
            },
            {
              "key": "sentiment",
              "type": "STRING",
              "extractionConfig": {
                "llmExtractionConfig": {
                  "definition": "Customer sentiment during the interaction.",
                  "llmExtractionInstruction": "LATEST_VALUE",
                  "validation": {
                    "stringValidation": {
                      "allowedValues": ["positive", "neutral", "negative", "frustrated"]
                    }
                  }
                }
              }
            }
          ]
        }
      }
    }
  ]'

Paso 2: Verificar la configuración

GetMemoryUtilícelo para confirmar que se han aceptado las claves indexadas y el esquema de metadatos:

aws bedrock-agentcore-control get-memory --memory-id "<memory-id>"

Paso 3: Agregue metadatos durante la ingestión

Hay dos maneras de incorporar los metadatos a los registros de memoria. En el caso de la ingestión (CreateEventoIngestData) basada en la extracción, el LLM rellena los metadatos de los registros que extrae. Con la creación directa de registros (BatchCreateMemoryRecordsoBatchUpdateMemoryRecords), los metadatos se suministran de forma explícita.

Event-driven ingestión

Adjunte stringValue metadatos a los eventos en el momento de la creación. El LLM utiliza el esquema de metadatos de la estrategia para extraer y completar los metadatos de los registros de memoria resultantes. En los registros resultantes solo se metadataSchema rellenan las claves definidas en la estrategia; las claves de metadatos de los eventos que no figuran en el esquema se ignoran durante la extracción.

aws bedrock-agentcore create-event \
  --memory-id "<memory-id>" \
  --actor-id "customer-123" \
  --session-id "session-001" \
  --event-timestamp "$(date -u +"%Y-%m-%dT%H:%M:%S.%3NZ")" \
  --metadata '{
    "priority":  {"stringValue": "high"},
    "channel":   {"stringValue": "email"},
    "ticket_id": {"stringValue": "TKT-5001"}
  }' \
  --payload '[
    {"conversational": {"role": "USER",      "content": {"text": "I have a billing issue that is blocking my production deployment"}}},
    {"conversational": {"role": "ASSISTANT", "content": {"text": "I understand this is urgent. Let me escalate to our billing specialist team."}}}
  ]'

En este ejemplo, priority está en la estrategiametadataSchema, por lo que su valor se propaga al registro de memoria. channely no ticket_id están en el esquema, por lo que se ignoran durante la extracción. El LLM también deduce agent_type (probablemente "specialist" basándose en el escalamiento) y sentiment (probablemente"frustrated") del contenido de la conversación: estas claves de esquema se rellenan aunque no se hayan proporcionado como metadatos del evento.

Extracción implícita de metadatos del contenido de la conversación

Los metadatos de los eventos no son necesarios para que las claves de esquema generen valores. Cuando una clave de esquema no tiene metadatos coincidentes en los eventos de origen, el LLM obtiene el valor por completo del contenido de la conversación. Utiliza las claves definition y llmExtractionInstruction para determinar el valor. Esto es útil para las dimensiones que solo existen en la conversación en sí, sin necesidad de que las personas que llaman las proporcionen en el momento de crear el evento.

Al utilizar la misma memoria de atención al cliente utilizada en el paso 1, el siguiente evento no contiene ningún tipo de metadatos:

aws bedrock-agentcore create-event \
  --memory-id "<memory-id>" \
  --actor-id "customer-789" \
  --session-id "session-002" \
  --event-timestamp "$(date -u +"%Y-%m-%dT%H:%M:%S.%3NZ")" \
  --payload '[
    {"conversational": {"role": "USER",      "content": {"text": "My production deployment is down because of a billing hold on our account"}}},
    {"conversational": {"role": "ASSISTANT", "content": {"text": "I understand the urgency. Let me connect you with our billing specialist team right away."}}}
  ]'

El LLM analiza el contenido de la conversación y rellena las tres claves de esquema del registro de memoria extraído (priority, y)agent_type, aunque no se proporcionó ninguna como metadato del eventosentiment:

{
  "content": {"text": "Customer reported a production outage caused by a billing hold. Escalated to billing specialist."},
  "metadata": {
    "priority":   {"stringValue": "critical"},
    "agent_type": {"stringValue": "specialist"},
    "sentiment":  {"stringValue": "frustrated"}
  }
}

Las reglas de validación aún se aplican: los resultados del LLM se limitan a los valores permitidos que especifiques, independientemente de si el valor proviene de los metadatos del evento o de la inferencia del contenido.

Cómo resuelve el LLM los conflictos entre eventos

Cuando varios eventos de una sesión contienen valores diferentes para la misma clave de metadatos, el LLM utiliza el. llmExtractionInstruction Esto determina qué valor se debe conservar en el registro de memoria resultante.

Por ejemplo, piense en una sesión de soporte en la que el primer evento tenga lugar priority: "low" y otro posterior se intensifique. priority: "critical" El LLM resuelve este problema basándose en la siguiente instrucción:

Otro ejemplo: agent_type con la instrucción «Prefiere el tipo de agente más especializado». Jerarquía: especialista > nivel 3 > nivel 2 > nivel 1 > bot». Si una sesión comienza con un bot y se convierte en un agente de nivel 2, se conserva el registro de memoria. agent_type: "tier2"

Ingestión determinista de metadatos

Las claves configuradas para STRICTLY_CONSISTENT seguir una ruta de ingesta diferente. El valor que proporciones en el evento es el valor que aparece en el registro resultante. No hay ninguna inferencia de LLM ni resolución de conflictos.

AgentCore La memoria agrupa los eventos según sus valores clave deterministas antes de la extracción. Por ejemplo, los eventos etiquetados department: "engineering" se procesan por separado de los eventos etiquetadosdepartment: "finance".

La consolidación opera dentro de estos grupos. Un registro que compliance_level: "hipaa" nunca se fusiona con un registro etiquetadocompliance_level: "standard". Esto hace que las claves deterministas sean ideales para:

Si un evento no tiene ningún valor para una clave determinista, la clave no aparece en el registro resultante.

Las rutas de escritura directa (BatchCreateMemoryRecordsyBatchUpdateMemoryRecords) evitan la extracción. El tipo STRICTLY_CONSISTENT de extracción no tiene ningún efecto sobre ellas. Proporcione los metadatos directamente como ya lo hace para esas API.

Creación directa de registros con las API por lotes

En el caso de las importaciones de bases de conocimiento, las estrategias de autogestión o el contenido preprocesado, utilice BatchCreateMemoryRecords (oBatchUpdateMemoryRecords) para proporcionar metadatos de forma explícita. Esto evita por completo la extracción de LLM: la persona que llama controla los valores de los metadatos.

La forma en que se gestionan los metadatos en los registros creados por lotes depende de si se proporciona un: memoryStrategyId

En el siguiente ejemplomemoryStrategyId, se crea un registro sin almacenar todos los metadatos proporcionados:

aws bedrock-agentcore batch-create-memory-records \
  --memory-id "<memory-id>" \
  --records '[{
    "requestIdentifier": "import-001",
    "namespaces": ["support/customer-456"],
    "content": {"text": "Customer prefers phone support for urgent billing issues"},
    "timestamp": "2026-01-15T10:00:00Z",
    "metadata": {
      "priority":   {"stringValue": "high"},
      "agent_type": {"stringValue": "billing_agent"},
      "channel":    {"stringValue": "phone"},
      "ticket_id":  {"stringValue": "TKT-7890"}
    }
  }]'

Para garantizar la coherencia del esquema, incluyamemoryStrategyId. En este caso, solo se conservan las claves presentes en esa estrategia: memoryRecordSchema

aws bedrock-agentcore batch-create-memory-records \
  --memory-id "<memory-id>" \
  --records '[{
    "requestIdentifier": "import-002",
    "namespaces": ["support/customer-456"],
    "memoryStrategyId": "<strategy-id>",
    "content": {"text": "Billing dispute resolved after account credit applied"},
    "timestamp": "2026-01-16T14:00:00Z",
    "metadata": {
      "priority":   {"stringValue": "medium"},
      "agent_type": {"stringValue": "billing_agent"},
      "channel":    {"stringValue": "phone"}
    }
  }]'

En el segundo ejemplo, si el esquema de la estrategia solo define y priority agent_typesentiment, luego channel se elimina silenciosamente del registro almacenado.

Actualización de registros con BatchUpdateMemoryRecords

BatchUpdateMemoryRecordssigue el mismo comportamiento de filtrado de memoryStrategyId metadatos queBatchCreateMemoryRecords. El siguiente ejemplo actualiza el contenido y los metadatos de un registro existente:

aws bedrock-agentcore batch-update-memory-records \
  --memory-id "<memory-id>" \
  --records '[{
    "memoryRecordId": "<record-id>",
    "namespaces": ["support/customer-456"],
    "content": {"text": "Customer prefers phone support for urgent billing issues. Account credit applied."},
    "metadata": {
      "priority":   {"stringValue": "critical"},
      "agent_type": {"stringValue": "billing_agent"},
      "channel":    {"stringValue": "phone"}
    }
  }]'

Paso 4: Consulta con filtros de metadatos

Los filtros de metadatos se aplican antes de que se ejecute la búsqueda por similitud vectorial (prefiltrado). Esto reduce primero el conjunto de candidatos. Como resultado, la búsqueda de K-nearest vecinos (KNN) se realiza en un subconjunto más pequeño y relevante.

Estructura Filter

Cada filtro es una { left, operator, right } expresión:

{
  "left":     { "metadataKey": "priority" },
  "operator": "EQUALS_TO",
  "right":    { "metadataValue": { "stringValue": "high" } }
}

Se pueden combinar hasta 5 filtros por consulta. Se aplican varios filtros con AND lógica.

Operadores admitidos

Nota: Los metadatos de los eventos solo se ListEvents filtran en función de la compatibilidad EXISTS NOT_EXISTSEQUALS_TO, y y únicamente. stringValue

Recupera con filtros de metadatos (búsqueda semántica y prefiltro)

ActivadoRetrieveMemoryRecords, metadataFilters está anidado en su interior. searchCriteria En el siguiente ejemplo, los resultados se clasifican en registros de alta prioridad del año en curso antes de que la búsqueda semántica coincida con los «problemas de facturación»:

aws bedrock-agentcore retrieve-memory-records \
  --memory-id "<memory-id>" \
  --namespace "support/customer-123" \
  --search-criteria '{
    "searchQuery": "billing issues",
    "topK": 10,
    "metadataFilters": [
      {
        "left":     {"metadataKey": "priority"},
        "operator": "EQUALS_TO",
        "right":    {"metadataValue": {"stringValue": "high"}}
      },
      {
        "left":     {"metadataKey": "x-amz-agentcore-memory-createdAt"},
        "operator": "AFTER",
        "right":    {"metadataValue": {"dateTimeValue": "2026-01-01T00:00:00Z"}}
      }
    ]
  }'

Al combinar un filtro de metadatos personalizado con una marca de tiempo generada por el sistema, se compacta el conjunto de candidatos en dos dimensiones (prioridad empresarial y actualidad) antes de que se ejecute la búsqueda por similitud.

Lista con filtros de metadatos (sin búsqueda semántica)

ListMemoryRecordsproporciona filtrado de metadatos sin búsqueda semántica. Esto resulta útil cuando necesita enumerar los registros que coinciden con criterios de metadatos específicos, por ejemplo, enumerar todos los registros de alta prioridad de un cliente o extraer todos los registros creados después de una fecha específica.

ActivadoListMemoryRecords, metadataFilters es un parámetro de nivel superior:

aws bedrock-agentcore list-memory-records \
  --memory-id "<memory-id>" \
  --namespace "support/customer-123" \
  --metadata-filters '[
    {
      "left":     {"metadataKey": "priority"},
      "operator": "EQUALS_TO",
      "right":    {"metadataValue": {"stringValue": "high"}}
    },
    {
      "left":     {"metadataKey": "x-amz-agentcore-memory-createdAt"},
      "operator": "AFTER",
      "right":    {"metadataValue": {"dateTimeValue": "2026-01-20T00:00:00Z"}}
    }
  ]'

Combinación de varios filtros

Esta consulta permite acceder a las discusiones sobre renta variable del tercer trimestre de 2026 dentro de un espacio de nombres de cliente específico:

{
  "searchQuery": "portfolio rebalancing strategy",
  "topK": 10,
  "metadataFilters": [
    {
      "left":     {"metadataKey": "asset_class"},
      "operator": "EQUALS_TO",
      "right":    {"metadataValue": {"stringValue": "equities"}}
    },
    {
      "left":     {"metadataKey": "x-amz-agentcore-memory-createdAt"},
      "operator": "AFTER",
      "right":    {"metadataValue": {"dateTimeValue": "2026-07-01T00:00:00Z"}}
    },
    {
      "left":     {"metadataKey": "x-amz-agentcore-memory-createdAt"},
      "operator": "BEFORE",
      "right":    {"metadataValue": {"dateTimeValue": "2026-09-30T23:59:59Z"}}
    }
  ]
}

Los valores de filtro para las marcas de tiempo deben estar en UTC (formato ISO 8601). El servicio normaliza todas las marcas de tiempo almacenadas a UTC antes de compararlas, por lo que siempre debes expresar los valores de los filtros en UTC.

Paso 5: Evoluciona tu esquema de metadatos

AgentCore La memoria permite la evolución del esquema para que pueda adaptar la configuración de los metadatos a medida que cambien sus necesidades.

Agregue claves indexadas

Puede añadir nuevas claves indexadas a una memoria en cualquier momento:

aws bedrock-agentcore-control update-memory \
  --memory-id "<memory-id>" \
  --add-indexed-keys '[
    {"key": "customer_segment", "type": "STRING"}
  ]'

Las nuevas claves están disponibles de inmediato para los eventos entrantes y los registros de memoria. Los registros existentes no se rellenan; solo los registros nuevos o actualizados contienen la nueva clave. No puede eliminar una clave previamente indexada, lo que evita la pérdida accidental de la capacidad de filtrado de los datos existentes.

Modifique el esquema de metadatos de una estrategia

Puedes añadir, eliminar o actualizar entradas libremente en el esquema de metadatos de una estrategia. Esto controla qué metadatos extrae el LLM de las conversaciones futuras.

Por ejemplo, para añadir un resolution_type campo nuevo a una estrategia existente:

aws bedrock-agentcore-control update-memory \
  --memory-id "<memory-id>" \
  --memory-strategies '{
    "modifyMemoryStrategies": [
      {
        "memoryStrategyId": "<strategy-id>",
        "memoryRecordSchema": {
          "metadataSchema": [
            {
              "key": "resolution_type",
              "type": "STRING",
              "extractionConfig": {
                "llmExtractionConfig": {
                  "definition": "How the customer support issue was resolved",
                  "validation": {
                    "stringValidation": {
                      "allowedValues": ["refund", "replacement", "escalation", "self-resolved"]
                    }
                  }
                }
              }
            }
          ]
        }
      }
    ]
  }'

También puedes eliminar una clave del esquema de metadatos de una estrategia si ya no quieres que el LLM extraiga ese campo. La eliminación de una entrada del esquema detiene la extracción de nuevos registros, pero no afecta a los metadatos que ya se encuentran en los registros existentes.

Los registros de memoria existentes no reciben LLM-extracted campos nuevos de forma retroactiva. Sin embargo, cuando las memorias antiguas se consolidan con las más nuevas durante el ciclo de vida normal de la memoria, el registro consolidado se vuelve a extraer con el esquema actual e incluirá los nuevos campos de metadatos.

Cuotas

Prácticas recomendadas

Anti-patterns para evitar