Strukturierte Metadaten für Langzeitgedächtnisse

Mit der Metadatenfilterung in Amazon Bedrock AgentCore Memory können Sie Ihren Langzeitspeicherdatensätzen strukturierte Attribute hinzufügen. Sie können diese Attribute verwenden, um einzugrenzen, welche Datensätze beim Abrufen zurückgegeben werden. Namespaces isolieren Speicher bereits nach primärer Entität (Benutzer, Mandant, Patient, Kunde). Innerhalb eines einzigen Namespaces gibt eine breit angelegte semantische Suche jedoch alles zurück, was einer ähnlichen Bedeutung entspricht. Mit der Metadatenfilterung können Sie nur Ergebnisse abrufen, die bestimmten Attributwerten entsprechen. Sie können beispielsweise nur Datensätze mit hoher Priorität, nur Datensätze aus einer bestimmten Abteilung oder nur Datensätze abrufen, die innerhalb eines bestimmten Zeitraums erstellt wurden.

Mit der Metadatenfilterung können Sie:

Erste Schritte

Die Einrichtung der Metadatenfilterung umfasst fünf Schritte:

In den folgenden Abschnitten werden die einzelnen Schritte im Detail beschrieben.

Die wichtigsten Konzepte

Indizierte Metadatenschlüssel

Indizierte Schlüssel werden auf Speicherressourcenebene in deklariert CreateMemory (oder später überUpdateMemory) hinzugefügt. Indizierte Schlüssel werden in einem Format gespeichert, das für eine schnelle Abfragefilterung optimiert ist. Nur indizierte Schlüssel können in on und abgefragt werden. metadataFilters ListMemoryRecords RetrieveMemoryRecords

Im folgenden Beispiel werden zwei indizierte Schlüssel deklariert:

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

Unterstützte type Werte:STRING,,STRINGLIST. NUMBER

Die Schlüssel müssen übereinstimmen ^[a-zA-Z0-9\s._:/=+@-]*$ (max. 128 Zeichen).

Durch das Hinzufügen eines indizierten Schlüssels werden bestehende Datensätze nicht aufgefüllt. Nur Datensätze, die nach der Deklaration des Schlüssels erstellt oder aktualisiert wurden, werden für diesen Schlüssel indexiert. Weitere Informationen zur Weiterentwicklung Ihres Schemas im Laufe der Zeit finden Sie unterSchritt 5: Entwickeln Sie Ihr Metadatenschema.

Metadatenschema (pro Strategie)

Bei Memory Strategy kann optional ein Metadatenschema deklariert memoryRecordSchema.metadataSchema werden. Das Metadatenschema teilt dem LLM mit, welche Metadaten bei der Generierung von Speicherdatensätzen aus Konversationsinhalten extrahiert werden sollen. Bei der ereignisgesteuerten Extraktion werden nur Schlüssel, die im Metadatenschema der Strategie definiert sind, in die resultierenden Speicherdatensätze übernommen.

Jeder Eintrag im Schema definiert:

Das folgende Beispiel zeigt einen Metadaten-Schemaeintrag mit Validierung:

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

Validierungsoptionen nach Typ:

Deterministische Metadaten (Extraktionstyp STRICTLY_CONSISTENT)

Deterministische Metadatenschlüssel enthalten Werte, die Ihre Anwendung bereits kennt, wenn sie ein Ereignis erstellt. Diese Werte werden ohne Änderung exakt in die resultierenden Speicherdatensätze kopiert. Organisatorische Klassifikatoren wie departmentcompliance_level, oder agent_id sollten vom LLM nicht abgeleitet werden. Die LLM-Inferenz führt zu Variabilität. Zum Beispiel kann dieselbe Konversation bei einem Datensatz und "eng" "Engineering" bei einem anderen auftreten.

Legen Sie extractionType für diese Schlüssel STRICTLY_CONSISTENT im Metadaten-Schemaeintrag den Wert auf fest. Der für das Ereignis angegebene Wert wird durch Extraktion und Konsolidierung unverändert weitergegeben. Das LLM wird für diesen Schlüssel nicht konsultiert.

Die folgende JSON-Datei zeigt ein Metadatenschema mit beiden STRICTLY_CONSISTENT LLM_INFERRED Extraktionstypen:

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

Wenn Sie es weglassenextractionType, ist LLM_INFERRED die Standardeinstellung.

Extraktion und Konsolidierung, Isolierung.

STRICTLY_CONSISTENTSchlüssel können mehr, als die LLM-Inferenz zu überspringen. Sie gruppieren Ereignisse während der Extraktion nach ihren deterministischen Werten. Ereignisse mit unterschiedlichen Werten werden separat verarbeitet. Die Konsolidierung folgt derselben Regel. Datensätze aus einer Wertgruppe werden niemals mit Datensätzen aus einer anderen Gruppe zusammengeführt.

Das folgende Python-Beispiel zeigt eine Support-Sitzung mit zwei deterministischen Schlüsseln (departmentundpriority):

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

Das System gruppiert Ereignisse nach der exakten Kombination aller deterministischen Schlüsselwerte:

Alle deterministischen Schlüsselwerte müssen übereinstimmen, damit Ereignisse gruppiert werden können. Eine Abfrage mit department=billing AND priority=high gibt nur die dringenden Fakten zu doppelten Gebühren zurück. Die anderen Ereignisse befinden sich in separaten Partitionen. Datensätze aus unterschiedlichen Wertekombinationen werden während der Konsolidierung niemals zusammengeführt.

Beschränkungen

Wie interagieren indizierte Schlüssel und Schemaschlüssel

Die Beziehung zwischen indizierten Schlüsseln und Schemaschlüsseln bestimmt, wie sich Metadaten verhalten:

Wie Metadaten von Ereignissen zu Speicherdatensätzen fließen

Event-Metadaten akzeptieren nur stringValue Einträge. Unterstützung stringValue von Speicherdatensätzen und numberValue Typen — vom LLM während der Extraktion aufgefüllt oder direkt über die Batch-APIs bereitgestellt. stringListValue Der dateTimeValue Typ ist für vom System generierte Felder (x-amz-agentcore-memory-createdAtund) reserviert. x-amz-agentcore-memory-updatedAt Nur Schlüssel, die in den Strategien definiert metadataSchema sind, werden in die extrahierten Datensätze übernommen. Event-Metadatenschlüssel, die nicht im Schema enthalten sind, werden ignoriert. Informationen zu Einreisebeschränkungen finden Sie unterKontingente.

System-generated Metadaten

Jeder Speicherdatensatz enthält diese Systemfelder, die mit denselben Filteroperatoren abgefragt werden können:

Sie müssen diese nicht als indizierte Schlüssel deklarieren — sie stehen immer zum Filtern zur Verfügung. Diese vom System generierten dateTimeValue Felder unterstützen AFTER AD-Operatoren BEFORE und ermöglichen Zeitbereichsabfragen, ohne dass Sie indizierte Datetime-Schlüssel deklarieren müssen.

Voraussetzungen

Bevor Sie die Metadatenfilterung konfigurieren, stellen Sie sicher, dass Sie über Folgendes verfügen:

Schritt 1: Erstellen Sie einen Speicher mit indizierten Schlüsseln und einem Metadatenschema

Im Folgenden wird ein Speicher für den Kundensupport mit fünf indizierten Schlüsseln und einem Metadatenschema erstellt. priorityagent_type, und sentiment sind im Metadatenschema der Strategie definiert — das LLM extrahiert ihre Werte aus dem Konversationsinhalt. Beachten Sie, dass dies zwar im Schema enthalten sentiment ist, aber nicht als indizierter Schlüssel deklariert ist: Das LLM leitet seinen Wert aus Konversationen ab und fügt ihn in Datensätze ein, er kann jedoch nicht in Filterausdrücken verwendet werden. tags(STRINGLIST), channel (STRING) und ticket_id (STRING) werden als indizierte Schlüssel deklariert, sind aber nicht im Schema enthalten — sie werden bei der ereignisgesteuerten Extraktion nicht aufgefüllt, können aber über die Batch-APIs bereitgestellt werden.

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

Schritt 2: Überprüfen Sie die Konfiguration

Verwenden Sie diese Option, GetMemory um zu bestätigen, dass die indizierten Schlüssel und das Metadatenschema akzeptiert wurden:

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

Schritt 3: Daten mit Metadaten aufnehmen

Es gibt zwei Möglichkeiten, Metadaten in Speicherdatensätze zu übertragen.

Event-driven Einnahme

Hängen Sie stringValue Metadaten bei der Erstellung an Ereignisse an. Das LLM verwendet das Metadatenschema der Strategie, um Metadaten aus den resultierenden Speicherdatensätzen zu extrahieren und aufzufüllen. Nur Schlüssel, die in der Strategie definiert metadataSchema sind, werden in den resultierenden Datensätzen aufgefüllt. Event-Metadatenschlüssel, die nicht im Schema enthalten sind, werden bei der Extraktion ignoriert.

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 diesem Beispiel priority ist der Wert in der Strategie enthaltenmetadataSchema, sodass sein Wert auf den Speicherdatensatz übertragen wird. channelund ticket_id sind nicht im Schema enthalten, sodass sie bei der Extraktion ignoriert werden. Das LLM leitet außerdem agent_type (wahrscheinlich "specialist" basierend auf der Eskalation) und sentiment (wahrscheinlich"frustrated") vom Inhalt der Konversation ab — diese Schemaschlüssel werden aufgefüllt, obwohl sie nicht als Event-Metadaten bereitgestellt wurden.

Implizite Extraktion von Metadaten aus Konversationsinhalten

Event-Metadaten sind nicht erforderlich, damit Schemaschlüssel Werte erzeugen. Wenn ein Schemaschlüssel keine passenden Metadaten zu den ursprünglichen Ereignissen enthält, leitet das LLM den Wert vollständig aus dem Konversationsinhalt ab. Es verwendet das definition und des SchlüsselsllmExtractionInstruction, um den Wert zu bestimmen. Dies ist nützlich für Dimensionen, die nur in der Konversation selbst existieren, ohne dass die Anrufer sie bei der Erstellung des Ereignisses angeben müssen.

Unter Verwendung des gleichen Kundensupport-Speichers wie in Schritt 1 hat das folgende Ereignis überhaupt keine Metadaten:

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

Das LLM analysiert den Inhalt der Konversation und füllt alle drei Schemaschlüssel im extrahierten Speicherdatensatz — priorityagent_type, und sentiment — auf, obwohl keine als Ereignismetadaten bereitgestellt wurden:

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

Die Validierungsregeln gelten weiterhin — die Ausgabe des LLM ist auf die von Ihnen angegebenen zulässigen Werte beschränkt, unabhängig davon, ob der Wert aus Ereignismetadaten oder Inhaltsinferenzen stammt.

Wie das LLM ereignisübergreifende Konflikte löst

Wenn mehrere Ereignisse in einer Sitzung unterschiedliche Werte für denselben Metadatenschlüssel enthalten, verwendet das LLM den. llmExtractionInstruction Dies bestimmt, welcher Wert im resultierenden Speicherdatensatz beibehalten werden soll.

Stellen Sie sich zum Beispiel eine Support-Sitzung vor, in der das erste Ereignis stattgefunden hat priority: "low" und ein späteres Ereignis eskaliert. priority: "critical" Das LLM löst dieses Problem auf der Grundlage der folgenden Anweisung:

Ein anderes Beispiel: für agent_type mit der Anweisung „Bevorzugen Sie den spezialisiertesten Agententyp. Hierarchie: Spezialist > Tier3 > Tier2 > Tier1 > Bot“, wenn eine Sitzung mit einem Bot beginnt und zu einem Tier2-Agenten eskaliert, wird der Speicherdatensatz abgerufen. agent_type: "tier2"

Deterministische Erfassung von Metadaten

Schlüssel, die so konfiguriert sind, dass sie einem anderen Aufnahmepfad STRICTLY_CONSISTENT folgen. Der Wert, den Sie für das Ereignis angeben, ist der Wert, der im resultierenden Datensatz landet. Es gibt keine LLM-Inferenz und keine Konfliktlösung.

AgentCore Der Speicher gruppiert Ereignisse vor der Extraktion nach ihren deterministischen Schlüsselwerten. Beispielsweise department: "engineering" werden markierte Ereignisse getrennt von department: "finance" markierten Ereignissen verarbeitet.

Die Konsolidierung erfolgt innerhalb dieser Gruppen. Ein Datensatz, der compliance_level: "hipaa" nie mit einem Datensatz mit der Bezeichnung compliance_level: "standard" zusammengeführt wird. Dadurch eignen sich deterministische Schlüssel ideal für:

Wenn ein Ereignis keinen Wert für einen deterministischen Schlüssel hat, fehlt der Schlüssel im resultierenden Datensatz.

Die Direct-Write-Pfade (BatchCreateMemoryRecordsundBatchUpdateMemoryRecords) umgehen die Extraktion. Der STRICTLY_CONSISTENT Extraktionstyp hat keine Auswirkung auf sie. Geben Sie Metadaten direkt ein, wie Sie es bereits für diese APIs tun.

Direkte Datensatzerstellung mit Batch-APIs

Verwenden Sie BatchCreateMemoryRecords (oderBatchUpdateMemoryRecords) für Wissensdatenbank-Importe, selbstverwaltete Strategien oder vorverarbeitete Inhalte, um Metadaten explizit anzugeben. Dadurch wird die LLM-Extraktion vollständig umgangen — der Aufrufer kontrolliert die Metadatenwerte.

Wie Metadaten in stapelweise erstellten Datensätzen behandelt werden, hängt davon ab, ob Sie Folgendes angeben: memoryStrategyId

Das folgende Beispiel erstellt einen Datensatz ohnememoryStrategyId, wobei alle bereitgestellten Metadaten gespeichert werden:

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

Um die Konsistenz des Schemas zu gewährleisten, fügen Sie den hinzumemoryStrategyId. In diesem Fall werden nur Schlüssel beibehalten, die in diesen Strategien enthalten memoryRecordSchema sind:

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

Im zweiten Beispiel wirdchannel, wenn das Schema der Strategie nur priorityagent_type, undsentiment, definiert, automatisch aus dem gespeicherten Datensatz gelöscht.

Aktualisierung von Datensätzen mit BatchUpdateMemoryRecords

BatchUpdateMemoryRecordsfolgt dem gleichen Verhalten memoryStrategyId beim Filtern von Metadaten wieBatchCreateMemoryRecords. Das folgende Beispiel aktualisiert den Inhalt und die Metadaten eines vorhandenen Datensatzes:

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

Schritt 4: Abfrage mit Metadatenfiltern

Metadatenfilter werden angewendet, bevor die Vektorähnlichkeitssuche ausgeführt wird (Vorfilterung). Dadurch wird zuerst die Kandidatenmenge reduziert. Das hat zur Folge, dass die K-nearest Nachbarsuche (KNN) auf einer kleineren, relevanteren Teilmenge basiert.

Filter-Struktur

Jeder Filter ist ein { left, operator, right } Ausdruck:

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

Pro Abfrage können bis zu 5 Filter kombiniert werden. Mehrere Filter werden AND logisch angewendet.

Unterstützte Operatoren

Hinweis: Event-Metadatenfilter werden nur ListEvents unterstützt EXISTSNOT_EXISTS, undEQUALS_TO, und nurstringValue.

Mit Metadatenfiltern abrufen (semantische Suche + Vorfilter)

OnRetrieveMemoryRecords, metadataFilters ist im Inneren verschachtelt. searchCriteria Im folgenden Beispiel werden die Ergebnisse auf Datensätze mit hoher Priorität aus dem aktuellen Jahr beschränkt, bevor die semantische Suche mit „Abrechnungsproblemen“ übereinstimmt:

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

Durch die Kombination eines benutzerdefinierten Metadatenfilters mit einem vom System generierten Zeitstempel wird die Kandidatengruppe anhand von zwei Dimensionen — Geschäftspriorität und Aktualität — komprimiert, bevor die Ähnlichkeitssuche ausgeführt wird.

Liste mit Metadatenfiltern (keine semantische Suche)

ListMemoryRecordsbietet Metadatenfilterung ohne semantische Suche. Dies ist nützlich, wenn Sie Datensätze auflisten müssen, die bestimmten Metadatenkriterien entsprechen, z. B. um alle Datensätze mit hoher Priorität für einen Kunden aufzulisten oder alle Datensätze abzurufen, die nach einem bestimmten Datum erstellt wurden.

On metadataFilters ist ein ListMemoryRecords Parameter der obersten Ebene:

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

Kombination mehrerer Filter

Diese Abfrage bezieht sich auf Aktiendiskussionen im 3. Quartal 2026 innerhalb eines bestimmten Client-Namespaces:

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

Filterwerte für Zeitstempel müssen im UTC-Format (ISO 8601-Format) angegeben werden. Der Dienst normalisiert alle gespeicherten Zeitstempel vor dem Vergleich auf UTC, sodass Filterwerte immer in UTC ausgedrückt werden.

Schritt 5: Entwickeln Sie Ihr Metadatenschema

AgentCore Der Speicher unterstützt die Schemaentwicklung, sodass Sie Ihre Metadatenkonfiguration an sich ändernde Anforderungen anpassen können.

Fügen Sie indizierte Schlüssel hinzu

Sie können einem Speicher jederzeit neue indizierte Schlüssel hinzufügen:

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

Neue Schlüssel werden sofort für eingehende Ereignisse und Speicherdatensätze verfügbar. Bestehende Datensätze werden nicht aufgefüllt — nur neue oder aktualisierte Datensätze enthalten den neuen Schlüssel. Sie können einen zuvor indizierten Schlüssel nicht entfernen, wodurch ein versehentlicher Verlust der Filterfähigkeit vorhandener Daten verhindert wird.

Ändern Sie das Metadatenschema einer Strategie

Sie können Einträge im Metadatenschema einer Strategie nach Belieben hinzufügen, entfernen oder aktualisieren. Dadurch wird gesteuert, welche Metadaten das LLM aus zukünftigen Konversationen extrahiert.

Um beispielsweise einer bestehenden Strategie ein neues resolution_type Feld hinzuzufügen:

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

Sie können auch einen Schlüssel aus dem Metadatenschema einer Strategie entfernen, wenn Sie nicht mehr möchten, dass das LLM dieses Feld extrahiert. Durch das Entfernen eines Schemaeintrags wird die Extraktion neuer Datensätze gestoppt, die Metadaten, die sich bereits in vorhandenen Datensätzen befinden, jedoch nicht beeinträchtigt.

Bestehende Speicherdatensätze erhalten nicht rückwirkend neue LLM-extracted Felder. Wenn jedoch ältere Speicher während des normalen Speicherlebenszyklus mit neueren konsolidiert werden, wird der konsolidierte Datensatz unter Verwendung des aktuellen Schemas erneut extrahiert und enthält die neuen Metadatenfelder.

Kontingente

Bewährte Methoden

Anti-patterns um zu vermeiden