Metadati strutturati per memorie a lungo termine

Il filtraggio dei metadati in Amazon Bedrock AgentCore Memory consente di aggiungere attributi strutturati ai record di memoria a lungo termine. Puoi utilizzare questi attributi per restringere i record restituiti durante il recupero. I namespace isolano già le memorie per entità principale (utente, tenant, paziente, cliente). Tuttavia, all'interno di un unico namespace, un'ampia ricerca semantica restituisce tutto ciò che ha un significato simile. Con il filtraggio dei metadati, puoi recuperare solo i risultati che corrispondono a valori di attributi specifici. Ad esempio, è possibile recuperare solo i record ad alta priorità, solo i record di un particolare reparto o solo i record creati in un determinato intervallo di tempo.

Con il filtraggio dei metadati, puoi:

Nozioni di base

L'impostazione del filtro dei metadati prevede cinque passaggi:

Le sezioni successive illustrano in dettaglio ogni passaggio.

Concetti chiave

Chiavi di metadati indicizzate

Le chiavi indicizzate vengono dichiarate a livello di risorsa di memoria in CreateMemory (o aggiunte successivamente tramite). UpdateMemory Le chiavi indicizzate vengono archiviate in un formato ottimizzato per il filtraggio rapido delle query. Solo le chiavi indicizzate possono essere interrogate in on and. metadataFilters ListMemoryRecords RetrieveMemoryRecords

L'esempio seguente dichiara due chiavi indicizzate:

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

typeValori supportati:STRING,,. STRINGLIST NUMBER

Le chiavi devono corrispondere ^[a-zA-Z0-9\s._:/=+@-]*$ (max 128 caratteri).

L'aggiunta di una chiave indicizzata non riempie i record esistenti. Solo i record creati o aggiornati dopo la dichiarazione della chiave vengono indicizzati per quella chiave. Per ulteriori dettagli sull'evoluzione dello schema nel tempo, consulta. Fase 5: Evolvi lo schema dei metadati

Schema di metadati (per strategia)

La strategia di memoria può facoltativamente avere uno schema di metadati dichiarato in. memoryRecordSchema.metadataSchema Lo schema dei metadati indica all'LLM quali metadati estrarre dal contenuto conversazionale durante la generazione di record di memoria. Solo le chiavi definite nello schema dei metadati della strategia vengono inserite nei record di memoria risultanti durante l'estrazione basata sugli eventi.

Ogni voce dello schema definisce:

L'esempio seguente mostra una voce dello schema di metadati con convalida:

{
  "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"]
            }
          }
        }
      }
    }
  ]
}

Opzioni di convalida per tipo:

Metadati deterministici (tipo di estrazione STRICTLY_CONSISTENT)

Le chiavi di metadati deterministiche contengono valori che l'applicazione conosce già durante la creazione di un evento. Questi valori vengono copiati esattamente nei record di memoria risultanti senza modifiche. I classificatori organizzativi comedepartment, o non agent_id dovrebberocompliance_level, essere dedotti dal LLM. L'inferenza LLM introduce la variabilità. Ad esempio, la stessa conversazione può produrre risultati "eng" su un disco e su un altro. "Engineering"

Per queste chiavi, impostate su extractionType STRICTLY_CONSISTENT nella voce dello schema dei metadati. Il valore fornito nell'evento si propaga invariato attraverso l'estrazione e il consolidamento. L'LLM non viene consultato per quella chiave.

Il seguente codice JSON mostra uno schema di metadati con entrambi STRICTLY_CONSISTENT i tipi di estrazione: LLM_INFERRED

{
  "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"
        }
      }
    }
  ]
}

Quando si ometteextractionType, l'impostazione predefinita è. LLM_INFERRED

Estrazione e consolidamento, isolamento

STRICTLY_CONSISTENTle chiavi fanno molto di più che saltare l'inferenza LLM. Raggruppano gli eventi in base ai loro valori deterministici durante l'estrazione. Gli eventi con valori diversi vengono elaborati separatamente. Il consolidamento segue la stessa regola. I record di un gruppo di valori non si fondono mai con i record di un altro gruppo.

Il seguente esempio di Python mostra una sessione di supporto con due chiavi deterministiche (departmente): priority

# 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"}
    }
)

Il sistema raggruppa gli eventi in base alla combinazione esatta di tutti i valori chiave deterministici:

Tutti i valori chiave deterministici devono corrispondere affinché gli eventi possano essere raggruppati. Una query con department=billing AND priority=high restituisce solo i dati urgenti relativi all'addebito duplicato. Gli altri eventi si trovano in partizioni separate. I record di diverse combinazioni di valori non si uniscono mai durante il consolidamento.

Vincoli

Come interagiscono le chiavi indicizzate e le chiavi dello schema

La relazione tra chiavi indicizzate e chiavi dello schema determina il comportamento dei metadati:

In che modo i metadati fluiscono dagli eventi ai record di memoria

I metadati degli eventi accettano solo stringValue voci. Supporto stringValue e numberValue tipi di record di memoria: popolati dall'LLM durante l'estrazione o forniti direttamente tramite le API Batch. stringListValue Il dateTimeValue tipo è riservato ai campi generati dal sistema (e). x-amz-agentcore-memory-createdAt x-amz-agentcore-memory-updatedAt Solo le chiavi definite nelle strategie metadataSchema vengono inserite nei record estratti, mentre le chiavi dei metadati degli eventi non presenti nello schema vengono ignorate. Per i limiti di ingresso, vedi. Quote

System-generated metadati

Ogni record di memoria contiene questi campi di sistema, interrogabili con gli stessi operatori di filtro:

Non è necessario dichiararle come chiavi indicizzate: sono sempre disponibili per il filtraggio. Questi dateTimeValue campi generati dal sistema supportano AFTER gli operatori BEFORE e consentono di eseguire interrogazioni in intervalli di tempo senza richiedere la dichiarazione di chiavi indicizzate con data e ora.

Prerequisiti

Prima di configurare il filtraggio dei metadati, verifica di disporre di:

Fase 1: Creare una memoria con chiavi indicizzate e uno schema di metadati

Quanto segue crea una memoria per l'assistenza clienti con cinque chiavi indicizzate e uno schema di metadati. priorityagent_type, e sentiment sono definiti nello schema dei metadati della strategia: l'LLM estrae i loro valori dal contenuto della conversazione. Si noti che sentiment è presente nello schema ma non è dichiarato come chiave indicizzata: l'LLM ricava il suo valore dalle conversazioni e lo inserisce nei record, ma non può essere utilizzato nelle espressioni di filtro. tags(STRINGLIST), channel (STRING) e ticket_id (STRING) sono dichiarate come chiavi indicizzate ma non fanno parte dello schema: non vengono compilate durante l'estrazione basata sugli eventi ma possono essere fornite tramite le API Batch.

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"]
                    }
                  }
                }
              }
            }
          ]
        }
      }
    }
  ]'

Fase 2: Verificare la configurazione

Utilizza GetMemory per confermare che le chiavi indicizzate e lo schema dei metadati sono stati accettati:

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

Fase 3: Inserimento di dati con metadati

Esistono due modi per inserire i metadati nei record di memoria.

Event-driven ingestione

Allega stringValue i metadati agli eventi al momento della creazione. L'LLM utilizza lo schema di metadati della strategia per estrarre e popolare i metadati nei record di memoria risultanti. Solo le chiavi definite nella strategia metadataSchema vengono inserite nei record risultanti: le chiavi dei metadati degli eventi non presenti nello schema vengono ignorate durante l'estrazione.

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."}}}
  ]'

In questo esempio, priority è nella strategiametadataSchema, quindi il suo valore si propaga al record di memoria. channele non ticket_id sono nello schema, quindi vengono ignorati durante l'estrazione. L'LLM deduce anche agent_type (probabilmente in "specialist" base all'escalation) e sentiment (probabilmente"frustrated") dal contenuto della conversazione: queste chiavi dello schema vengono compilate anche se non sono state fornite come metadati degli eventi.

Estrazione implicita dei metadati dal contenuto della conversazione

I metadati degli eventi non sono necessari affinché le chiavi dello schema producano valori. Quando una chiave dello schema non ha metadati corrispondenti sugli eventi di origine, LLM ricava il valore interamente dal contenuto della conversazione. Utilizza i tasti definition e per determinare il valorellmExtractionInstruction. Ciò è utile per le dimensioni che esistono solo nella conversazione stessa, senza richiedere ai chiamanti di fornirle al momento della creazione dell'evento.

Utilizzando la stessa memoria di assistenza clienti della Fase 1, il seguente evento non contiene affatto metadati:

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."}}}
  ]'

L'LLM analizza il contenuto della conversazione e inserisce tutte e tre le chiavi dello schema nel record di memoria estratto: priorityagent_type, e sentiment — anche se nessuna è stata fornita come metadata dell'evento:

{
  "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"}
  }
}

Le regole di convalida sono ancora valide: l'output del LLM è vincolato ai valori consentiti specificati indipendentemente dal fatto che il valore provenga dai metadati degli eventi o dall'inferenza del contenuto.

In che modo l'LLM risolve i conflitti tra eventi

Quando più eventi in una sessione hanno valori diversi per la stessa chiave di metadati, LLM utilizza il. llmExtractionInstruction Ciò determina quale valore conservare nel record di memoria risultante.

Ad esempio, si consideri una sessione di supporto in cui si verifica il primo evento priority: "low" e a cui si aggiunge un evento successivo. priority: "critical" L'LLM risolve questo problema in base alle istruzioni:

Un altro esempio: perché agent_type con l'istruzione «Preferisci il tipo di agente più specializzato». Gerarchia: specialist > tier3 > tier2 > tier1 > bot», se una sessione inizia con un bot e passa a un agente tier2, il record di memoria viene ripristinato. agent_type: "tier2"

Inserimento deterministico di metadati

Le chiavi configurate STRICTLY_CONSISTENT seguono un percorso di ingestione diverso. Il valore fornito per l'evento è il valore che viene inserito nel record risultante. Non esiste alcuna inferenza LLM e nessuna risoluzione dei conflitti.

AgentCore La memoria raggruppa gli eventi in base ai loro valori chiave deterministici prima dell'estrazione. Ad esempio, gli eventi etichettati department: "engineering" vengono elaborati separatamente dagli eventi etichettatidepartment: "finance".

Il consolidamento opera all'interno di questi gruppi. Un record che non si fonde compliance_level: "hipaa" mai con un record etichettato. compliance_level: "standard" Ciò rende le chiavi deterministiche ideali per:

Se un evento non ha alcun valore per una chiave deterministica, la chiave è assente nel record risultante.

I percorsi di scrittura diretta (BatchCreateMemoryRecordseBatchUpdateMemoryRecords) ignorano l'estrazione. Il tipo STRICTLY_CONSISTENT di estrazione non ha alcun effetto su di essi. Fornisci i metadati direttamente come già fai per quelle API.

Creazione diretta di record con API Batch

Per le importazioni da knowledge base, le strategie autogestite o i contenuti preelaborati, utilizza BatchCreateMemoryRecords (o) fornisci i metadati in modo esplicito. BatchUpdateMemoryRecords Ciò ignora completamente l'estrazione LLM: il chiamante controlla i valori dei metadati.

Il modo in cui i metadati vengono gestiti sui record creati in batch dipende dal fatto che si fornisca o meno un: memoryStrategyId

L'esempio seguente crea un record senza memoryStrategyId memorizzare tutti i metadati forniti:

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"}
    }
  }]'

Per imporre la coerenza dello schema, includi. memoryStrategyId In questo caso, memoryRecordSchema vengono mantenute solo le chiavi presenti in quella strategia:

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"}
    }
  }]'

Nel secondo esempio, se lo schema della strategia definisce solopriority, e agent_typesentiment, allora channel viene eliminato silenziosamente dal record archiviato.

Aggiornamento dei record con BatchUpdateMemoryRecords

BatchUpdateMemoryRecordssegue lo stesso comportamento di filtraggio memoryStrategyId dei metadati di. BatchCreateMemoryRecords L'esempio seguente aggiorna il contenuto e i metadati di un record esistente:

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"}
    }
  }]'

Fase 4: Interrogazione con filtri per i metadati

I filtri per i metadati vengono applicati prima dell'esecuzione della ricerca per similarità vettoriale (prefiltraggio). Ciò riduce innanzitutto il set di candidati. Di conseguenza, la ricerca dei K-nearest vicini (KNN) opera su un sottoinsieme più piccolo e pertinente.

Struttura filtro

Ogni filtro è un'espressione: { left, operator, right }

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

È possibile combinare fino a 5 filtri per query. I filtri multipli vengono applicati con AND logica.

Operatori supportati

Nota: i metadati degli eventi vengono filtrati solo sul ListEvents supporto EXISTS NOT_EXISTSEQUALS_TO, e e solo. stringValue

Recupera con filtri per i metadati (ricerca semantica + prefiltro)

AttivoRetrieveMemoryRecords, metadataFilters è annidato all'interno. searchCriteria L'esempio seguente analizza i risultati in base ai record ad alta priorità dell'anno in corso prima che la ricerca semantica corrisponda ai «problemi di fatturazione»:

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"}}
      }
    ]
  }'

La combinazione di un filtro di metadati personalizzato con un timestamp generato dal sistema compatta il set di candidati in base a due dimensioni, priorità aziendale e attualità, prima che venga eseguita la ricerca per analogia.

Elenco con filtri per i metadati (nessuna ricerca semantica)

ListMemoryRecordsfornisce il filtraggio dei metadati senza ricerca semantica. Ciò è utile quando è necessario enumerare i record che soddisfano criteri di metadati specifici, ad esempio elencando tutti i record ad alta priorità per un cliente o recuperando tutti i record creati dopo una data specifica.

ListMemoryRecordsOn, è un parametro di primo livello: metadataFilters

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"}}
    }
  ]'

Combinazione di più filtri

Questa interrogazione analizza le discussioni sulle azioni del terzo trimestre 2026 all'interno di uno specifico namespace del cliente:

{
  "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"}}
    }
  ]
}

I valori del filtro per i timestamp devono essere in UTC (formato ISO 8601). Il servizio normalizza tutti i timestamp memorizzati in UTC prima del confronto, quindi esprimi sempre i valori del filtro in UTC.

Fase 5: Evolvi lo schema dei metadati

AgentCore La memoria supporta l'evoluzione dello schema in modo da poter adattare la configurazione dei metadati al variare delle esigenze.

Aggiungi chiavi indicizzate

Puoi aggiungere nuove chiavi indicizzate a una memoria in qualsiasi momento:

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

Le nuove chiavi diventano immediatamente disponibili per gli eventi in arrivo e i record di memoria. I record esistenti non vengono riempiti: solo i record nuovi o aggiornati contengono la nuova chiave. Non è possibile rimuovere una chiave precedentemente indicizzata, il che impedisce la perdita accidentale della capacità di filtraggio sui dati esistenti.

Modifica lo schema dei metadati di una strategia

Puoi aggiungere, rimuovere o aggiornare liberamente le voci nello schema di metadati di una strategia. Questo controlla quali metadati l'LLM estrae dalle conversazioni future.

Ad esempio, per aggiungere un nuovo resolution_type campo a una strategia esistente:

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"]
                    }
                  }
                }
              }
            }
          ]
        }
      }
    ]
  }'

Puoi anche rimuovere una chiave dallo schema di metadati di una strategia se non desideri più che l'LLM estragga quel campo. La rimozione di una voce dello schema interrompe l'estrazione di nuovi record ma non influisce sui metadati già presenti nei record esistenti.

I record di memoria esistenti non ricevono retroattivamente nuovi LLM-extracted campi. Tuttavia, quando le memorie più vecchie vengono consolidate con quelle più recenti durante il normale ciclo di vita della memoria, il record consolidato viene riestratto utilizzando lo schema corrente e includerà i nuovi campi di metadati.

Quote

Best practice

Anti-patterns da evitare