Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

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 singolo namespace, un'ampia ricerca semantica restituisce tutto ciò che ha un significato vicino. Con il filtro 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 determinato reparto o solo i record creati in un determinato intervallo di tempo.

Con il filtro dei metadati, puoi:

Nozioni di base

L'impostazione del filtro dei metadati prevede cinque passaggi:

Le sezioni successive illustrano ogni passaggio in dettaglio.

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 un rapido filtraggio delle query. È possibile interrogare solo le chiavi indicizzate in on e. 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._:/=+@-]*$ (massimo 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 maggiori dettagli sull'evoluzione dello schema nel tempo, consulta. Passaggio 5: evolvi lo schema dei metadati

Schema dei metadati (per strategia)

Memory Strategy 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 guidata dagli eventi.

Ogni voce nello 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. Classificatori organizzativi simili department o non agent_id devono essere dedotti dal LLM. compliance_level L'inferenza LLM introduce la variabilità. Ad esempio, la stessa conversazione può produrre "eng" su un record 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 tramite estrazione e consolidamento. L'LLM non viene consultato per quella chiave.

Il seguente JSON mostra uno schema di metadati con entrambi i tipi di estrazione: STRICTLY_CONSISTENT 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 in 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 per raggruppare gli eventi. Una ricerca con department=billing AND priority=high restituisce solo i dati di addebito duplicati urgenti. Gli altri eventi si trovano in partizioni separate. I record provenienti da diverse combinazioni di valori non si fondono 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 voci. stringValue Supporto stringValue e numberValue tipi di record di memoria: compilati dal 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 nella strategia metadataSchema vengono compilate nei record estratti: le chiavi dei metadati degli eventi non presenti nello schema vengono ignorate. Per i limiti di ingresso, consulta. 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 su intervalli di tempo senza dover dichiarare chiavi indicizzate con data e ora.

Prerequisiti

Prima di configurare il filtro dei metadati, verifica di avere:

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. prioritye sentiment sono definiti nello schema dei metadati della strategia: l'LLM ne estrae i valori dai contenuti delle conversazioni. agent_type Notate che sentiment è presente nello schema ma non è dichiarato come chiave indicizzata: il LLM trae il suo valore dalle conversazioni e lo compila 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 sono presenti nello schema: non vengono popolate 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"]
                    }
                  }
                }
              }
            }
          ]
        }
      }
    }
  ]'

Passaggio 2: verifica la configurazione

GetMemoryUsalo 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: Aggiungere i metadati durante l'inserimento

Esistono due modi per inserire i metadati nei record di memoria. Con l'ingestione basata sull'estrazione (CreateEventorIngestData), l'LLM popola i metadati sui record che estrae. Con la creazione diretta dei record (or), fornisci i metadati in modo esplicito. BatchCreateMemoryRecords BatchUpdateMemoryRecords

Event-driven ingestione

Allega i stringValue metadati agli eventi al momento della creazione. L'LLM utilizza lo schema dei metadati della strategia per estrarre e popolare i metadati sui 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 inoltre 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 di 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, il LLM ricava il valore interamente dal contenuto della conversazione. Utilizza la chiave definition e llmExtractionInstruction per determinare il valore. Ciò è utile per dimensioni che esistono solo nella conversazione stessa, senza che sia necessario che i chiamanti le forniscano 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 compila tutte e tre le chiavi dello schema nel record di memoria estratto (,, e) priorityagent_type, anche se nessuna è stata fornita come metadata dell'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"}
  }
}

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 gli eventi

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

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

Un altro esempio: 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 salvato. agent_type: "tier2"

Inserimento di metadati deterministici

Le chiavi configurate STRICTLY_CONSISTENT seguono un percorso di inserimento diverso. Il valore fornito nell'evento è il valore che compare 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 contrassegnati department: "engineering" vengono elaborati separatamente dagli eventi contrassegnatidepartment: "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) bypassano l'estrazione. Il tipo STRICTLY_CONSISTENT di estrazione non ha alcun effetto su di essi. Fornisci direttamente i metadati come già fai per quelle API.

Creazione diretta di record con le API Batch

Per le importazioni da knowledge base, le strategie autogestite o i contenuti preelaborati, utilizzate BatchCreateMemoryRecords (o) per fornire metadati in modo esplicito. BatchUpdateMemoryRecords Questo bypassa completamente l'estrazione LLM: il chiamante controlla i valori dei metadati.

Il modo in cui i metadati vengono gestiti nei record creati in batch dipende dal fatto che tu fornisca: 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 il. memoryStrategyId In questo caso, memoryRecordSchema vengono conservate 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 solo e priority agent_typesentiment, allora channel viene eliminato silenziosamente dal record archiviato.

Aggiornamento dei record con BatchUpdateMemoryRecords

BatchUpdateMemoryRecordssegue lo stesso comportamento di filtraggio dei memoryStrategyId 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 di metadati

I filtri per i metadati vengono applicati prima dell'esecuzione della ricerca per similarità vettoriale (prefiltro). Questo riduce innanzitutto il set di candidati. Di conseguenza, la ricerca K-nearest vicino (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. Vengono applicati più filtri con AND logica.

Operatori supportati

Nota: i metadati degli eventi vengono filtrati solo in base al ListEvents supporto, e EXISTSNOT_EXISTS, e EQUALS_TO solo. stringValue

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

SìRetrieveMemoryRecords, è annidato all'interno. metadataFilters searchCriteria L'esempio seguente assegna i risultati ai record ad alta priorità dell'anno corrente prima che la ricerca semantica corrisponda a «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 lungo due dimensioni, priorità aziendale e attualità, prima che venga eseguita la ricerca per similarità.

Elenco con filtri per metadati (nessuna ricerca semantica)

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

Sì, è un parametro di primo livello: ListMemoryRecords 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 query riguarda il recupero delle discussioni azionarie del terzo trimestre 2026 all'interno di uno specifico namespace dei clienti:

{
  "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 dei filtri 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 dei filtri in UTC.

Passaggio 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 entrata e i record di memoria. I record esistenti non vengono riempiti nuovamente: solo i record nuovi o aggiornati contengono la nuova chiave. Non è possibile rimuovere una chiave indicizzata in precedenza, il che impedisce la perdita accidentale della capacità di filtraggio sui dati esistenti.

Modificare lo schema dei metadati di una strategia

Puoi aggiungere, rimuovere o aggiornare liberamente le voci nello schema dei metadati di una strategia. Questo controlla quali metadati il 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 dei 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 campi. LLM-extracted Tuttavia, quando le memorie più vecchie vengono consolidate con memorie 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