Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Des 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 qui correspondent à des valeurs d'attributs spécifiques. Par exemple, vous pouvez récupérer uniquement les enregistrements prioritaires, uniquement les enregistrements d'un service particulier ou uniquement les enregistrements créés au cours d'une période donnée.

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

Prise en main

La configuration du filtrage des métadonnées comporte 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 de la ressource 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 peuvent être interrogées dans metadataFilters on and. 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 dans les enregistrements de mémoire résultants 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 résultants sans modification. Les classificateurs organisationnels tels que departmentcompliance_level, ou ne agent_id devraient pas être déduits par le LLM. L'inférence LLM introduit la variabilité. Par exemple, la même conversation peut donner lieu "eng" à un enregistrement et "Engineering" à 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 sur l'événement se propage inchangée par extraction et consolidation. Le LLM n'est pas consulté pour cette clé.

Le code JSON suivant présente un schéma de métadonnées avec STRICTLY_CONSISTENT les deux types LLM_INFERRED 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.

Isolation par extraction et consolidation

STRICTLY_CONSISTENTles touches 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 informations urgentes relatives à la double facturation. Les autres événements se trouvent dans des partitions séparées. Les enregistrements provenant de différentes combinaisons de valeurs ne sont jamais fusionnés lors de la consolidation.

Contraintes

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 entre les événements et les enregistrements de mémoire

Les métadonnées de l'événement n'acceptent que stringValue les entrées. Supports et numberValue types stringValue d'stringListValueenregistrements de mémoire : renseignés par le LLM lors de l'extraction ou fournis directement via les API Batch. 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'entrée, voirQuotas.

System-generated métadonnées

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

Vous n'avez pas besoin 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 par plage de temps sans que vous ayez à déclarer des clés indexées par date et 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 qu'il n'est pas déclaré en tant que clé indexée : le LLM tire sa valeur des conversations et la remplit dans les enregistrements, mais elle ne peut pas être utilisée dans les expressions de filtre. tags(STRINGLIST), channel (STRING) et ticket_id (STRING) sont déclarés en tant que clés indexées mais ne figurent pas dans le schéma. Ils ne sont pas renseignés lors de l'extraction pilotée par des événements mais peuvent être fournis 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 : Ajouter des métadonnées lors de l'ingestion

Il existe deux méthodes pour obtenir des métadonnées dans des enregistrements de mémoire. Avec l'ingestion basée sur l'extraction (CreateEventouIngestData), le LLM remplit les métadonnées des enregistrements qu'il extrait. Avec la création directe d'enregistrements (BatchCreateMemoryRecordsouBatchUpdateMemoryRecords), vous fournissez des métadonnées de manière explicite.

Event-driven ingestion

Joignez 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 remplir les métadonnées des enregistrements de mémoire résultants. Seules les clés définies dans les stratégies metadataSchema sont renseignées dans les enregistrements résultants. Les clés de métadonnées des événements ne figurant 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 la stratégiemetadataSchema, donc sa valeur se propage à l'enregistrement mémoire. channelet ne ticket_id figurent pas dans le schéma, ils sont donc ignorés lors de l'extraction. Le LLM infère é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 en tant que métadonnées d'événement.

Extraction implicite de métadonnées à partir du contenu des conversations

Les métadonnées d'événement 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érive la valeur entièrement à partir du contenu de la conversation. Il utilise la clé 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 n'aient à les fournir au moment de la création de l'événement.

En utilisant la même mémoire de support client que celle utilisée à l'étape 1, l'événement suivant ne contient 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 — priorityagent_type, et sentiment — même si aucune n'a été fournie comme métadonnée 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 des métadonnées de l'événement ou de l'inférence de contenu.

Comment le LLM résout les conflits entre les événements

Lorsque plusieurs événements d'une session comportent 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.

Par exemple, considérez une session d'assistance au cours de laquelle le premier événement a priority: "low" eu lieu et où un événement ultérieur dégénère. priority: "critical" Le LLM résout ce problème en se basant sur les instructions suivantes :

Autre exemple : pour agent_type avec 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 démarre avec un bot et passe à un agent de niveau 2, l'enregistrement mémoire est enregistré. agent_type: "tier2"

Ingestion déterministe de métadonnées

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

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 s'opère au sein de ces groupes. Un enregistrement qui ne fusionne compliance_level: "hipaa" 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, celle-ci 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 les 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 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 varie selon que vous fournissez : 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 priorityagent_type, etsentiment, elle channel est supprimée silencieusement de l'enregistrement stocké.

Mettre à jour les enregistrements avec BatchUpdateMemoryRecords

BatchUpdateMemoryRecordssuit le même comportement de filtrage des memoryStrategyId 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 groupe de candidats en premier. Par conséquent, la recherche de K-nearest voisins (KNN) s'effectue 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" } }
}

Il est possible de combiner jusqu'à 5 filtres 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 ne sont ListEvents filtrées que sur le support EXISTS NOT_EXISTSEQUALS_TO, et, et uniquementstringValue.

Récupérez avec des 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 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é et d'un horodatage généré par le système permet de réduire l'ensemble des candidats selon deux dimensions, à savoir la priorité commerciale et la 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 correspondant à des critères de métadonnées spécifiques, par exemple pour répertorier tous les enregistrements prioritaires pour un client ou extraire tous les enregistrements créés après une date précise.

ActivéListMemoryRecords, metadataFilters est un paramètre de niveau supérieur :

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 permet de retrouver les discussions sur les actions du troisième trimestre 2026 dans 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 en UTC (format ISO 8601). Le service normalise tous les horodatages stockés en UTC avant la comparaison, donc exprimez 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 des schémas 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 de mémoire. Les enregistrements existants ne sont pas remplis : 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 toute 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 permet de contrôler les métadonnées que le LLM extrait des conversations à venir.

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 des nouveaux enregistrements mais n'affecte pas les métadonnées déjà présentes sur les enregistrements existants.

Les enregistrements de mémoire existants ne reçoivent pas de nouveaux LLM-extracted champs rétroactivement. Toutefois, lorsque des mémoires plus anciennes 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 en utilisant le schéma actuel et inclut les nouveaux champs de métadonnées.

Quotas

Bonnes pratiques

Anti-patterns à éviter