Métadonnées structurées pour les mémoires à long terme

Le filtrage des métadonnées dans Amazon Bedrock AgentCore Memory vous permet d'ajouter des attributs structurés à vos enregistrements de mémoire à long terme. Vous pouvez utiliser ces attributs pour affiner les enregistrements renvoyés lors de la récupération. Les espaces de noms isolent déjà les mémoires par entité principale (utilisateur, locataire, patient, client). Cependant, au sein d'un même espace de noms, une recherche sémantique étendue renvoie tout ce qui a un sens proche. Le filtrage des métadonnées vous permet de récupérer uniquement les résultats correspondant à des valeurs d'attributs spécifiques. Par exemple, vous pouvez récupérer uniquement les enregistrements prioritaires, uniquement les enregistrements d'un département en particulier ou uniquement les enregistrements créés dans un intervalle de temps donné.

Grâce au filtrage des métadonnées, vous pouvez :

Prise en main

La configuration du filtrage des métadonnées comprend cinq étapes :

Les sections suivantes décrivent chaque étape en détail.

Concepts clés

Clés de métadonnées indexées

Les clés indexées sont déclarées au niveau des ressources mémoire dans CreateMemory (ou ajoutées ultérieurement viaUpdateMemory). Les clés indexées sont stockées dans un format optimisé pour un filtrage rapide des requêtes. Seules les clés indexées sont interrogeables dans metadataFilters on et. ListMemoryRecords RetrieveMemoryRecords

L'exemple suivant déclare deux clés indexées :

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

typeValeurs prises en charge :STRING,STRINGLIST,NUMBER.

Les clés doivent correspondre ^[a-zA-Z0-9\s._:/=+@-]*$ (128 caractères maximum).

L'ajout d'une clé indexée ne remplace pas les enregistrements existants. Seuls les enregistrements créés ou mis à jour après la déclaration de la clé sont indexés pour cette clé. Pour plus de détails sur l'évolution de votre schéma au fil du temps, consultezÉtape 5 : Faites évoluer votre schéma de métadonnées.

Schéma de métadonnées (par stratégie)

Memory Strategy peut éventuellement avoir un schéma de métadonnées déclaré dansmemoryRecordSchema.metadataSchema. Le schéma de métadonnées indique au LLM quelles métadonnées extraire du contenu conversationnel lors de la génération d'enregistrements de mémoire. Seules les clés définies dans le schéma de métadonnées de la stratégie sont renseignées sur les enregistrements de mémoire obtenus lors de l'extraction pilotée par les événements.

Chaque entrée du schéma définit :

L'exemple suivant montre une entrée de schéma de métadonnées avec validation :

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

Options de validation par type :

Métadonnées déterministes (type d'extraction STRICTLY_CONSISTENT)

Les clés de métadonnées déterministes contiennent des valeurs que votre application connaît déjà lors de la création d'un événement. Ces valeurs sont copiées exactement dans les enregistrements de mémoire obtenus sans modification. Les classificateurs organisationnels aiment department ou ne agent_id devraient pas être déduits par le LLM. compliance_level L'inférence LLM introduit de la variabilité. Par exemple, la même conversation peut se produire "eng" sur un enregistrement et "Engineering" sur un autre.

Pour ces clés, définissez sur STRICTLY_CONSISTENT dans extractionType l'entrée du schéma de métadonnées. La valeur fournie lors de l'événement se propage telle quelle lors de l'extraction et de la consolidation. Le LLM n'est pas consulté pour cette clé.

Le JSON suivant montre un schéma de métadonnées comprenant à la fois des types LLM_INFERRED d'extraction STRICTLY_CONSISTENT et des types d'extraction :

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

Lorsque vous omettezextractionType, la valeur par défaut estLLM_INFERRED.

Extraction et consolidation, isolation

STRICTLY_CONSISTENTles clés ne se contentent pas d'ignorer l'inférence LLM. Ils regroupent les événements en fonction de leurs valeurs déterministes lors de l'extraction. Les événements ayant des valeurs différentes sont traités séparément. La consolidation suit la même règle. Les enregistrements d'un groupe de valeurs ne sont jamais fusionnés avec les enregistrements d'un autre groupe.

L'exemple Python suivant montre une session de support avec deux clés déterministes (departmentetpriority) :

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

Le système regroupe les événements selon la combinaison exacte de toutes les valeurs clés déterministes :

Toutes les valeurs clés déterministes doivent correspondre pour que les événements soient regroupés. Une requête avec department=billing AND priority=high renvoie uniquement les faits urgents relatifs à la double accusation. Les autres événements se trouvent dans des partitions séparées. Les enregistrements issus de différentes combinaisons de valeurs ne sont jamais fusionnés lors de la consolidation.

Constaintes

Comment les clés indexées et les clés de schéma interagissent

La relation entre les clés indexées et les clés de schéma détermine le comportement des métadonnées :

Comment les métadonnées circulent des événements vers les enregistrements en mémoire

Les métadonnées de l'événement n'acceptent que stringValue les entrées. Support stringValue et numberValue types d'enregistrements en mémoire : renseignés par le LLM lors de l'extraction ou fournis directement via les API Batch. stringListValue Le dateTimeValue type est réservé aux champs générés par le système (x-amz-agentcore-memory-createdAtetx-amz-agentcore-memory-updatedAt). Seules les clés définies dans les stratégies metadataSchema sont renseignées sur les enregistrements extraits ; les clés de métadonnées des événements qui ne figurent pas dans le schéma sont ignorées. Pour les limites d'inscription, voirQuotas.

System-generated métadonnées

Chaque enregistrement de mémoire contient les champs système suivants, interrogeables avec les mêmes opérateurs de filtre :

Il n'est pas nécessaire de les déclarer en tant que clés indexées : elles sont toujours disponibles pour le filtrage. Ces dateTimeValue champs générés par le système prennent en charge les AFTER opérateurs BEFORE et permettent d'effectuer des requêtes temporelles sans que vous ayez à déclarer des clés indexées date/heure.

Conditions préalables

Avant de configurer le filtrage des métadonnées, vérifiez que vous disposez des éléments suivants :

Étape 1 : Création d'une mémoire avec des clés indexées et un schéma de métadonnées

Ce qui suit crée une mémoire de support client avec cinq clés indexées et un schéma de métadonnées. priorityagent_type, et sentiment sont définis dans le schéma de métadonnées de la stratégie : le LLM extrait leurs valeurs du contenu de la conversation. Notez que cela sentiment figure dans le schéma mais n'est pas déclaré en tant que clé indexée : le LLM tire sa valeur des conversations et la renseigne sur des enregistrements, mais il ne peut pas être utilisé dans des expressions de filtre. tags(STRINGLIST), channel (STRING) et ticket_id (STRING) sont déclarées comme des clés indexées mais ne figurent pas dans le schéma. Elles ne sont pas renseignées lors de l'extraction pilotée par des événements mais peuvent être fournies via les 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"]
                    }
                  }
                }
              }
            }
          ]
        }
      }
    }
  ]'

Étape 2 : vérifier la configuration

GetMemoryÀ utiliser pour confirmer que les clés indexées et le schéma de métadonnées ont été acceptés :

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

Étape 3 : Ingérer des données avec des métadonnées

Il existe deux méthodes pour transférer les métadonnées dans les enregistrements en mémoire.

Event-driven ingestion

Attachez stringValue des métadonnées aux événements au moment de leur création. Le LLM utilise le schéma de métadonnées de la stratégie pour extraire et renseigner les métadonnées sur les enregistrements de mémoire obtenus. Seules les clés définies dans les stratégies metadataSchema sont renseignées sur les enregistrements obtenus ; les clés de métadonnées d'événements qui ne figurent pas dans le schéma sont ignorées lors de l'extraction.

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

Dans cet exemple, priority se trouve dans celui de la stratégiemetadataSchema, de sorte que sa valeur se propage à l'enregistrement en mémoire. channelet ne ticket_id figurent pas dans le schéma, ils sont donc ignorés lors de l'extraction. Le LLM déduit également agent_type (probablement en "specialist" fonction de l'escalade) et sentiment (probablement"frustrated") à partir du contenu de la conversation : ces clés de schéma sont renseignées même si elles n'ont pas été fournies sous forme de métadonnées d'événement.

Extraction de métadonnées implicites à partir du contenu d'une conversation

Les métadonnées des événements ne sont pas requises pour que les clés de schéma produisent des valeurs. Lorsqu'une clé de schéma ne possède aucune métadonnée correspondante sur les événements d'origine, le LLM déduit la valeur entièrement du contenu de la conversation. Il utilise les clés definition et llmExtractionInstruction pour déterminer la valeur. Cela est utile pour les dimensions qui n'existent que dans la conversation elle-même, sans que les appelants aient à les fournir au moment de la création de l'événement.

En utilisant la même mémoire de support client que lors de l'étape 1, l'événement suivant n'a aucune métadonnée :

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

Le LLM analyse le contenu de la conversation et remplit les trois clés de schéma de l'enregistrement mémoire extrait —priority,agent_type, et sentiment — même si aucune n'a été fournie sous forme de métadonnées d'événement :

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

Les règles de validation s'appliquent toujours : la sortie du LLM est limitée aux valeurs autorisées que vous avez spécifiées, que la valeur provienne de métadonnées d'événements ou d'une inférence de contenu.

Comment le LLM résout les conflits liés aux événements

Lorsque plusieurs événements d'une session portent des valeurs différentes pour la même clé de métadonnées, le LLM utilise lellmExtractionInstruction. Cela détermine la valeur à conserver dans l'enregistrement mémoire obtenu.

Imaginons, par exemple, une session d'assistance au cours de laquelle le premier événement a priority: "low" atteint le stade. priority: "critical" Le LLM résout ce problème en fonction de l'instruction suivante :

Autre exemple : pour agent_type l'instruction « Préférez le type d'agent le plus spécialisé ». Hiérarchie : spécialiste > niveau 3 > niveau 2 > niveau 1 > bot ». Si une session commence par un bot et passe à un agent de niveau 2, l'enregistrement mémoire est enregistré. agent_type: "tier2"

Ingestion déterministe des métadonnées

Les clés configurées STRICTLY_CONSISTENT suivent un chemin d'ingestion différent. La valeur que vous fournissez lors de l'événement est la valeur qui apparaît sur l'enregistrement obtenu. Il n'y a pas d'inférence LLM ni de résolution de conflits.

AgentCore La mémoire regroupe les événements en fonction de leurs valeurs clés déterministes avant l'extraction. Par exemple, les événements balisés department: "engineering" sont traités séparément des événements balisésdepartment: "finance".

La consolidation fonctionne au sein de ces groupes. Un enregistrement qui compliance_level: "hipaa" ne fusionne jamais avec un enregistrement étiquetécompliance_level: "standard". Les clés déterministes sont donc idéales pour :

Si un événement n'a aucune valeur pour une clé déterministe, la clé est absente de l'enregistrement obtenu.

Les chemins d'écriture directe (BatchCreateMemoryRecordsetBatchUpdateMemoryRecords) contournent l'extraction. Le type STRICTLY_CONSISTENT d'extraction n'a aucun effet sur eux. Fournissez des métadonnées directement, comme vous le faites déjà pour ces API.

Création directe d'enregistrements avec les API Batch

Pour les importations de bases de connaissances, les stratégies autogérées ou le contenu prétraité, utilisez BatchCreateMemoryRecords (ouBatchUpdateMemoryRecords) pour fournir des métadonnées de manière explicite. Cela permet de contourner complètement l'extraction du LLM : l'appelant contrôle les valeurs des métadonnées.

La façon dont les métadonnées sont gérées sur les enregistrements créés par lots dépend de la fourniture ou non d'un : memoryStrategyId

L'exemple suivant crée un enregistrement sans memoryStrategyId stocker toutes les métadonnées fournies :

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

Pour renforcer la cohérence du schéma, incluez lememoryStrategyId. Dans ce cas, seules les clés présentes dans cette stratégie memoryRecordSchema sont conservées :

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

Dans le second exemple, si le schéma de la stratégie définit uniquement priority agent_typesentiment, puis channel est supprimé silencieusement de l'enregistrement stocké.

Mise à jour des enregistrements avec BatchUpdateMemoryRecords

BatchUpdateMemoryRecordssuit le même comportement de filtrage memoryStrategyId des métadonnées queBatchCreateMemoryRecords. L'exemple suivant met à jour le contenu et les métadonnées d'un enregistrement existant :

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

Étape 4 : Requête à l'aide de filtres de métadonnées

Les filtres de métadonnées sont appliqués avant l'exécution de la recherche de similarité vectorielle (préfiltrage). Cela réduit le nombre de candidats sélectionnés en premier. Par conséquent, la recherche de K-nearest voisins (KNN) fonctionne sur un sous-ensemble plus petit et plus pertinent.

Structure Filtre

Chaque filtre est une { left, operator, right } expression :

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

Jusqu'à 5 filtres peuvent être combinés par requête. Plusieurs filtres sont appliqués de manière AND logique.

Opérateurs pris en charge

Remarque : les métadonnées des événements ListEvents filtrent uniquement sur support EXISTSNOT_EXISTS, etEQUALS_TO, et uniquementstringValue.

Récupération à l'aide de filtres de métadonnées (recherche sémantique + préfiltre)

ActivéRetrieveMemoryRecords, metadataFilters est imbriqué à l'intérieursearchCriteria. L'exemple suivant étend les résultats aux enregistrements hautement prioritaires de l'année en cours avant que la recherche sémantique ne corresponde à des « problèmes de facturation » :

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 combinaison d'un filtre de métadonnées personnalisé avec un horodatage généré par le système permet de compacter l'ensemble de candidats selon deux dimensions (priorité commerciale et récence) avant que la recherche de similarité ne soit lancée.

Liste avec filtres de métadonnées (pas de recherche sémantique)

ListMemoryRecordsfournit un filtrage des métadonnées sans recherche sémantique. Cela est utile lorsque vous devez énumérer des enregistrements répondant à des critères de métadonnées spécifiques, par exemple, répertorier tous les enregistrements hautement prioritaires pour un client ou extraire tous les enregistrements créés après une date précise.

ActivéListMemoryRecords, metadataFilters il s'agit d'un paramètre de premier niveau :

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

Combinaison de plusieurs filtres

Cette requête porte sur les discussions sur les actions du troisième trimestre 2026 au sein d'un espace de noms client spécifique :

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

Les valeurs de filtre pour les horodatages doivent être au format UTC (format ISO 8601). Le service normalise tous les horodatages enregistrés en UTC avant la comparaison. Exprimez donc toujours les valeurs des filtres en UTC.

Étape 5 : Faites évoluer votre schéma de métadonnées

AgentCore La mémoire prend en charge l'évolution du schéma afin que vous puissiez adapter la configuration de vos métadonnées en fonction de l'évolution de vos besoins.

Ajouter des clés indexées

Vous pouvez ajouter de nouvelles clés indexées à une mémoire à tout moment :

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

Les nouvelles clés sont immédiatement disponibles pour les événements entrants et les enregistrements en mémoire. Les enregistrements existants ne sont pas complétés : seuls les enregistrements nouveaux ou mis à jour portent la nouvelle clé. Vous ne pouvez pas supprimer une clé précédemment indexée, ce qui empêche la perte accidentelle de la capacité de filtrage des données existantes.

Modifier le schéma de métadonnées d'une stratégie

Vous pouvez librement ajouter, supprimer ou mettre à jour des entrées dans le schéma de métadonnées d'une stratégie. Cela contrôle les métadonnées que le LLM extrait des conversations à l'avenir.

Par exemple, pour ajouter un nouveau resolution_type champ à une stratégie existante :

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

Vous pouvez également supprimer une clé du schéma de métadonnées d'une stratégie si vous ne souhaitez plus que le LLM extrait ce champ. La suppression d'une entrée de schéma arrête l'extraction pour les nouveaux enregistrements mais n'affecte pas les métadonnées déjà présentes dans les enregistrements existants.

Les enregistrements de mémoire existants ne reçoivent pas de nouveaux LLM-extracted champs rétroactivement. Toutefois, lorsque les anciennes mémoires sont consolidées avec des mémoires plus récentes au cours du cycle de vie normal de la mémoire, l'enregistrement consolidé est réextrait à l'aide du schéma actuel et inclut les nouveaux champs de métadonnées.

Quotas

Bonnes pratiques

Anti-patterns pour éviter