장기 메모리를 위한 구조화된 메타데이터

Amazon Bedrock AgentCore 메모리의 메타데이터 필터링을 사용하면 장기 메모리 레코드에 구조화된 속성을 추가할 수 있습니다. 이러한 속성을 사용하여 검색 중에 반환되는 레코드의 범위를 좁힐 수 있습니다. 네임스페이스는 이미 기본 엔터티(사용자, 테넌트, 환자, 클라이언트)별로 메모리를 격리합니다. 그러나 단일 네임스페이스 내에서 광범위한 의미 체계 검색은 의미가 가까운 모든 것을 반환합니다. 메타데이터 필터링을 사용하면 특정 속성 값과 일치하는 결과만 검색할 수 있습니다. 예를 들어 우선순위가 높은 레코드, 특정 부서의 레코드 또는 지정된 시간 범위 내에 생성된 레코드만 검색할 수 있습니다.

메타데이터 필터링을 사용하면 다음을 수행할 수 있습니다.

시작하기

메타데이터 필터링 설정에는 5단계가 포함됩니다.

후속 섹션에서는 각 단계를 자세히 살펴봅니다.

주요 개념

인덱싱된 메타데이터 키

인덱싱된 키는의 메모리 리소스 수준에서 선언됩니다CreateMemory(또는 나중에를 통해 추가됨UpdateMemory). 인덱싱된 키는 빠른 쿼리 필터링에 최적화된 형식으로 저장됩니다. 인덱싱된 키만 ListMemoryRecords 및의에서 쿼리할 수 metadataFilters 있습니다RetrieveMemoryRecords.

다음 예제에서는 두 개의 인덱싱된 키를 선언합니다.

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

지원되는 type 값: STRING, STRINGLIST, NUMBER.

키는 일치해야 합니다^[a-zA-Z0-9\s._:/=+@-]*$(최대 128자).

인덱싱된 키를 추가해도 기존 레코드는 채워지지 않습니다. 키가 선언된 후 생성되거나 업데이트된 레코드만 해당 키에 대해 인덱싱됩니다. 시간 경과에 따른 스키마 진화에 대한 자세한 내용은 섹션을 참조하세요5단계: 메타데이터 스키마 개선.

메타데이터 스키마(전략별)

Memory Strategy는 선택적으로 에서 선언된 메타데이터 스키마를 가질 수 있습니다memoryRecordSchema.metadataSchema. 메타데이터 스키마는 메모리 레코드를 생성할 때 대화형 콘텐츠에서 추출할 메타데이터를 LLM에 알려줍니다. 이벤트 기반 추출 중에는 전략의 메타데이터 스키마에 정의된 키만 결과 메모리 레코드에 채워집니다.

스키마의 각 항목은 다음을 정의합니다.

다음 예제에서는 검증이 포함된 메타데이터 스키마 항목을 보여줍니다.

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

유형별 검증 옵션:

결정적 메타데이터(STRICTLY_CONSISTENT 추출 유형)

결정적 메타데이터 키에는 애플리케이션이 이벤트를 생성할 때 이미 알고 있는 값이 포함됩니다. 이러한 값은 수정 없이 결과 메모리 레코드에 정확하게 복사됩니다. department, compliance_level또는 같은 조직 분류자는 LLM에서 추론해서는 agent_id 안 됩니다. LLM 추론은 변동성을 유발합니다. 예를 들어, 한 레코드와 다른 레코드"eng"에서 동일한 대화가 생성될 수 "Engineering" 있습니다.

이러한 키의 경우 메타데이터 스키마 항목STRICTLY_CONSISTENT에서를 extractionType로 설정합니다. 이벤트에 제공된 값은 추출 및 통합을 통해 변경되지 않고 전파됩니다. 해당 키에 대해서는 LLM을 참조하지 않습니다.

다음 JSON은 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"
        }
      }
    }
  ]
}

extractionType를 생략하면 기본값은 입니다LLM_INFERRED.

추출 및 통합 격리

STRICTLY_CONSISTENT 키는 LLM 추론을 건너뛰는 것 이상을 수행합니다. 추출 중에 결정적 값을 기준으로 이벤트를 그룹화합니다. 값이 다른 이벤트는 별도로 처리됩니다. 통합은 동일한 규칙을 따릅니다. 한 값 그룹의 레코드는 다른 그룹의 레코드와 병합되지 않습니다.

다음 Python 예제는 두 개의 결정적 키(department 및 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"}
    }
)

시스템은 모든 결정적 키 값의 정확한 조합을 기준으로 이벤트를 그룹화합니다.

이벤트를 그룹화하려면 모든 결정적 키 값이 일치해야 합니다. department=billing AND가 있는 쿼리는 긴급 중복 요금 사실만 priority=high 반환합니다. 다른 이벤트는 별도의 파티션에 있습니다. 서로 다른 값 조합의 레코드는 통합 중에 병합되지 않습니다.

제약 조건

인덱싱된 키와 스키마 키가 상호 작용하는 방법

인덱싱된 키와 스키마 키 간의 관계에 따라 메타데이터의 동작 방식이 결정됩니다.

메타데이터가 이벤트에서 메모리 레코드로 흐르는 방식

이벤트 메타데이터는 stringValue 항목만 허용합니다. 메모리 레코드는 추출 중에 LLM에 의해 채워지거나 배치 APIs를 통해 직접 제공되는 stringValuestringListValue, 및 numberValue 유형을 지원합니다. dateTimeValue 유형은 시스템 생성 필드(x-amz-agentcore-memory-createdAt 및 )용으로 예약되어 있습니다x-amz-agentcore-memory-updatedAt. 전략의에 정의된 키만 추출된 레코드에 채워metadataSchema집니다. 스키마에 없는 이벤트 메타데이터 키는 무시됩니다. 항목 제한은 섹션을 참조하세요할당량.

시스템 생성 메타데이터

모든 메모리 레코드에는 동일한 필터 연산자로 쿼리할 수 있는 이러한 시스템 필드가 들어 있습니다.

인덱싱된 키로 선언할 필요는 없습니다. 항상 필터링에 사용할 수 있습니다. 이러한 시스템 생성 dateTimeValue 필드는 BEFORE 및 AFTER 연산자를 지원하므로 날짜/시간 인덱싱된 키를 선언할 필요 없이 시간 범위 쿼리를 사용할 수 있습니다.

사전 조건

메타데이터 필터링을 구성하기 전에 다음이 있는지 확인합니다.

1단계: 인덱싱된 키와 메타데이터 스키마를 사용하여 메모리 생성

다음은 인덱싱된 키 5개와 메타데이터 스키마가 있는 고객 지원 메모리를 생성합니다. priority, agent_type및는 전략의 메타데이터 스키마에 정의되어 있습니다. LLMsentiment은 대화 콘텐츠에서 해당 값을 추출합니다. sentiment는 스키마에 있지만 인덱싱된 키로 선언되지는 않습니다. LLM은 대화에서 값을 추출하여 레코드에 채우지만 필터 표현식에는 사용할 수 없습니다. tags (STRINGLIST), channel (STRING) 및 ticket_id (STRING)는 인덱싱된 키로 선언되지만 스키마에는 없습니다. 이벤트 기반 추출 중에는 채워지지 않지만 배치 APIs를 통해 제공할 수 있습니다.

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

2단계: 구성 확인

GetMemory를 사용하여 인덱싱된 키 및 메타데이터 스키마가 수락되었는지 확인합니다.

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

3단계: 메타데이터로 데이터 수집

메타데이터를 메모리 레코드로 가져오는 두 가지 경로가 있습니다.

이벤트 기반 수집

생성 시 stringValue 메타데이터를 이벤트에 연결합니다. LLM은 전략의 메타데이터 스키마를 사용하여 결과 메모리 레코드에서 메타데이터를 추출하고 채웁니다. 전략의에 정의된 키만 결과 레코드에 채워metadataSchema집니다. 스키마에 없는 이벤트 메타데이터 키는 추출 중에 무시됩니다.

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

이 예제에서 priority는 전략의에 metadataSchema있으므로 값이 메모리 레코드로 전파됩니다. channel 및 ticket_id는 스키마에 없으므로 추출 중에 무시됩니다. 또한 LLM은 대화 콘텐츠"frustrated"에서 agent_type ( 에스컬레이션을 "specialist" 기반으로 할 수 있음) 및 sentiment ()를 유추합니다. 이러한 스키마 키는 이벤트 메타데이터로 제공되지 않았더라도 채워집니다.

대화 콘텐츠에서 암시적 메타데이터 추출

스키마 키가 값을 생성하는 데는 이벤트 메타데이터가 필요하지 않습니다. 스키마 키에 원본 이벤트에 일치하는 메타데이터가 없는 경우 LLM은 전적으로 대화 콘텐츠에서 값을 도출합니다. 키의 definition 및를 사용하여 값을 llmExtractionInstruction 결정합니다. 이는 호출자가 이벤트 생성 시 제공할 필요 없이 대화 자체에만 존재하는 차원에 유용합니다.

1단계의 동일한 고객 지원 메모리를 사용하면 다음 이벤트에 메타데이터가 전혀 없습니다.

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

LLM은 이벤트 메타데이터로 제공되지 않았sentiment더라도 대화 콘텐츠를 분석하고 추출된 메모리 레코드의 세 스키마 키 priority, 및 agent_type를 모두 채웁니다.

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

검증 규칙은 여전히 적용됩니다. 값이 이벤트 메타데이터에서 왔는지 콘텐츠 추론에서 왔는지에 관계없이 LLM의 출력이 지정된 허용 값으로 제한됩니다.

LLM이 이벤트 간 충돌을 해결하는 방법

세션의 여러 이벤트가 동일한 메타데이터 키에 대해 서로 다른 값을 갖는 경우 LLM은를 사용합니다llmExtractionInstruction. 이렇게 하면 결과 메모리 레코드에 유지할 값이 결정됩니다.

예를 들어 첫 번째 이벤트에가 priority: "low" 있고 이후 이벤트가 로 에스컬레이션되는 지원 세션을 가정해 보겠습니다priority: "critical". LLM은 지침에 따라이 문제를 해결합니다.

또 다른 예: agent_type "가장 특수한 에이전트 유형을 선호합니다. 계층 구조: 전문가 > tier3 > tier2 > tier1 > bot", 세션이 봇으로 시작하고 tier2 에이전트로 에스컬레이션하면 메모리 레코드가를 가져옵니다agent_type: "tier2".

결정적 메타데이터 수집

로 구성된 키는 다른 수집 경로를 STRICTLY_CONSISTENT 따릅니다. 이벤트에 제공하는 값은 결과 레코드에 있는 값입니다. LLM 추론과 충돌 해결은 없습니다.

AgentCore 메모리는 추출 전에 결정적 키 값을 기준으로 이벤트를 그룹화합니다. 예를 들어 태그가 지정된 이벤트department: "engineering"는 태그가 지정된 이벤트와 별도로 처리됩니다department: "finance".

통합은 이러한 그룹 내에서 작동합니다. 가 있는 레코드는 레이블이 지정된 레코드와 병합compliance_level: "hipaa"되지 않습니다compliance_level: "standard". 따라서 다음과 같은 경우에 결정론적 키가 이상적입니다.

이벤트에 결정적 키에 대한 값이 없는 경우 결과 레코드에 키가 없습니다.

직접 쓰기 경로(BatchCreateMemoryRecords 및 BatchUpdateMemoryRecords)는 추출을 우회합니다. STRICTLY_CONSISTENT 추출 유형은 영향을 미치지 않습니다. 해당 APIs에 대해 이미 하고 있는 것처럼 메타데이터를 직접 제공합니다.

배치 APIs 사용한 직접 레코드 생성

지식 기반 가져오기, 자체 관리형 전략 또는 사전 처리된 콘텐츠의 경우 BatchCreateMemoryRecords (또는 BatchUpdateMemoryRecords)를 사용하여 메타데이터를 명시적으로 제공합니다. 이렇게 하면 LLM 추출이 완전히 우회되어 호출자가 메타데이터 값을 제어합니다.

배치 생성 레코드에서 메타데이터를 처리하는 방법은를 제공하는지 여부에 따라 달라집니다memoryStrategyId.

다음 예제에서는를 사용하지 않고 레코드를 생성memoryStrategyId하여 제공된 모든 메타데이터를 저장합니다.

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

스키마 일관성을 적용하려면를 포함합니다memoryStrategyId. 이 경우 해당 전략의에 있는 키만 유지됩니다memoryRecordSchema.

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

두 번째 예에서 전략의 스키마가 , priority agent_type및 만 정의하는 경우 sentimentchannel는 저장된 레코드에서 자동으로 삭제됩니다.

BatchUpdateMemoryRecords를 사용하여 레코드 업데이트

BatchUpdateMemoryRecords는와 동일한 memoryStrategyId 메타데이터 필터링 동작을 따릅니다BatchCreateMemoryRecords. 다음 예시에서는 기존 레코드의 콘텐츠와 메타데이터를 업데이트합니다.

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

4단계: 메타데이터 필터를 사용한 쿼리

메타데이터 필터는 벡터 유사성 검색이 실행되기 전에 적용됩니다(사전 필터링). 이렇게 하면 후보 세트가 먼저 줄어듭니다. 따라서 KNN(K-Nearest Neighbor) 검색은 더 작고 관련성이 높은 하위 집합에서 작동합니다.

Filter 구조

모든 필터는 { left, operator, right } 표현식입니다.

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

쿼리당 최대 5개의 필터를 결합할 수 있습니다. 여러 필터가 AND 로직과 함께 적용됩니다.

지원되는 연산자

참고:의 이벤트 메타데이터 필터는 EXISTS, NOT_EXISTS및 EQUALS_TO만 ListEvents 지원합니다stringValue.

메타데이터 필터로 검색(시맨틱 검색 + 사전 필터)

에서 RetrieveMemoryRecordsmetadataFilters는 내부에 중첩됩니다searchCriteria. 다음 예제에서는 의미 체계 검색이 "결제 문제"와 일치하기 전에 올해의 우선순위가 높은 레코드로 결과의 범위를 지정합니다.

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

사용자 지정 메타데이터 필터를 시스템 생성 타임스탬프와 결합하면 유사성 검색이 실행되기 전에 비즈니스 우선 순위와 최신성이라는 두 가지 차원을 따라 후보 세트를 압축합니다.

메타데이터 필터가 있는 목록(시맨틱 검색 없음)

ListMemoryRecords는 의미 체계 검색 없이 메타데이터 필터링을 제공합니다. 이는 고객의 우선순위가 높은 모든 레코드를 나열하거나 특정 날짜 이후에 생성된 모든 레코드를 가져오는 등 특정 메타데이터 기준과 일치하는 레코드를 열거해야 하는 경우에 유용합니다.

에서 ListMemoryRecordsmetadataFilters는 최상위 파라미터입니다.

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

여러 필터 결합

이 쿼리는 특정 클라이언트 네임스페이스 내에서 2026년 Q3 주식 논의로 검색 범위를 지정합니다.

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

타임스탬프의 필터 값은 UTC(ISO 8601 형식)여야 합니다. 이 서비스는 비교 전에 저장된 모든 타임스탬프를 UTC로 정규화하므로 항상 UTC로 필터 값을 표현합니다.

5단계: 메타데이터 스키마 개선

AgentCore 메모리는 스키마 진화를 지원하므로 필요에 따라 메타데이터 구성을 조정할 수 있습니다.

인덱싱된 키 추가

언제든지 메모리에 새 인덱싱된 키를 추가할 수 있습니다.

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

수신 이벤트 및 메모리 레코드에 새 키를 즉시 사용할 수 있습니다. 기존 레코드는 백필되지 않습니다. 새 레코드 또는 업데이트된 레코드에만 새 키가 포함됩니다. 기존 데이터에 대한 필터링 기능의 우발적 손실을 방지하는 이전에 인덱싱된 키는 제거할 수 없습니다.

전략의 메타데이터 스키마 수정

전략의 메타데이터 스키마에서 항목을 자유롭게 추가, 제거 또는 업데이트할 수 있습니다. 이렇게 하면 LLM이 향후 대화에서 추출하는 메타데이터가 제어됩니다.

예를 들어 기존 전략에 새 resolution_type 필드를 추가하려면:

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

LLM이 더 이상 해당 필드를 추출하지 않도록 하려면 전략의 메타데이터 스키마에서 키를 제거할 수도 있습니다. 스키마 항목을 제거하면 새 레코드에 대한 추출이 중지되지만 기존 레코드에 이미 있는 메타데이터에는 영향을 주지 않습니다.

기존 메모리 레코드는 새 LLM 추출 필드를 소급하여 수신하지 않습니다. 그러나 일반 메모리 수명 주기 동안 이전 메모리를 최신 메모리와 통합하면 현재 스키마를 사용하여 통합 레코드가 다시 추출되고 새 메타데이터 필드가 포함됩니다.

할당량

모범 사례

피해야 할 안티 패턴