CDK로 Managed Amazon Bedrock Knowledge Base 기반의 에이전틱 검색 구축하기

이 게시물은 AWS Cloud Development Kit(AWS CDK)을 사용하여 Managed Amazon Bedrock Knowledge Base 위에 엔터프라이즈급 에이전틱 검색을 구축합니다. 이를 구축할 가치가 있는 이유를 이해하려면, 일반적인 검색 증강 생성(Retrieval Augmented Generation, RAG)이 한계에 부딪히는 지점부터 살펴보는 것이 도움이 됩니다. 대부분의 RAG 시스템은 같은 방식으로 시작합니다: 질문을 임베딩하고, 하나의 인덱스에서 가장 가까운 청크를 가져오고, 이를 모델에 전달하고, 답변을 반환합니다. 검색 한 번, 생성 한 번입니다. 광범위한 질문 범주에 대해서는 이것이 올바른 설계이며, 더 복잡한 것을 만들 이유가 없습니다.

하지만 인지 가능한 방식으로 실패합니다. 답이 두 개의 코퍼스에 걸쳐 있는 질문을 하면, 단일 검색은 모델에 필요한 것의 절반만 반환하는데, 이는 아무것도 반환하지 않는 것보다 더 나쁩니다. 답변이 유창하지만 불완전한 상태로 돌아오기 때문입니다. 어떤 소스가 옳은지가 질문에 따라 달라지는질문을 하면, 단일 인덱스에는 선택할 메커니즘이 없습니다. 첫 번째 결과를 본 후 코퍼스를 다시 살펴봐야 하는 질문을 하면, 그 두 번째 살펴보기가 일어날 장소가 없습니다.

엔터프라이즈급 에이전틱 검색은 추론 에이전트를 루프 안에 배치함으로써 이 세 가지 모두에 답합니다. 에이전트는 검색할지 여부, 어느 지식 기반을 참조할지, 그리고 답변을 작성하기 전에 추가 검색을 할지 여부를 결정합니다. 이것이 Amazon Bedrock Knowledge Bases 가 진화해 온 방향입니다. Managed Knowledge Base의 출시와 함께, 검색은 더 이상 단일한 임베드-페치(embed-and-fetch) 호출이 아닙니다. 그것은 에이전틱 기능이 되었습니다: 다중 턴 계획, 도구 기반 검색, 그리고 근거 있는 인용 기반의 답변입니다. AgenticRetrieveStream API는 이를 직접 조립하는 것이 아니라 일급 서비스 기능으로 제공합니다. 이것은 잘 작동하지만, 동시에 본질적으로 더 어려운 운영 문제를 도입합니다. 단일 샷(single-shot) 파이프라인은 코드를 읽음으로써 추론할 수 있는 함수입니다. 루프 안에서 추론하고 검색하는 에이전트는 질문마다 다른 경로를 택합니다. 기본적으로는 에이전트가 취한 경로도, 생성한 답변이 좋았는지 여부도 볼 수 없습니다. 관측 가능성은 더 이상 있으면 좋은 것이 아니라, 시스템이 작동한다는 것을 알 수 있는 유일한 방법이 됩니다.

2024년 8월, Knowledge Bases for Amazon Bedrock와 AWS CDK를 사용하여 엔드투엔드 RAG 솔루션 구축하기 에서는 단일 샷 설계를 CDK 애플리케이션으로 배포했습니다: Amazon Simple Storage Service (Amazon S3) 코퍼스, Amazon OpenSearch Serverless 컬렉션과 인덱스, 지식 기반, 그리고 데이터 소스가 CDK 스택으로 프로비저닝되었으며, 그 순서는 직접 손으로 정렬해야 했습니다. 게시 이후 세 가지가 변했습니다.

1. Amazon Bedrock 는 이제 관리형 지식 기반 (Type: MANAGED)을 제공하며, 이것이 수집(ingestion), 저장, 인덱싱, 검색 자체를 담당합니다. 해당 게시물이 프로비저닝하던 OpenSearch Serverless 컬렉션과 인덱스는 더 이상 OpenSearch Compute Units(OCU)로 생성, 확장하거나 비용을 지불할 필요가 없습니다.
2. Amazon Bedrock AgentCore 는 에이전틱 쪽을 제공합니다. 각 지식 기반을 Model Context Protocol(MCP) 도구로 노출하는 Gateway, 추론 에이전트를 호스팅하는 Runtime, 그리고 내부적으로 재순위화(rerank)를 수행하고 합성된 인용 기반의 답변을 반환하는 AgenticRetrieveStream입니다. 에이전틱 검색은 Managed Knowledge Base에서 만 사용할 수 있습니다.
3. 관측 가능성과 평가는 이제 직접 프로비저닝할 수 있는 것이며, 나중에 덧붙이는 것이 아닙니다. 이 솔루션은 7개 계층의 텔레메트리를 아우르는 두 개의 Amazon CloudWatch 대시보드와, 동일한 배포에서 제공되는 온디맨드 및 지속이라는 두 가지 형태의 평가를 함께 제공합니다.

이 게시물은 그 시스템을 구축합니다: 두 개의 지식 기반 간에 라우팅하고, Gateway를 통해 검색하며, 근거 있는 인용 기반의 답변을 반환하는 에이전트로, 동작의 모든 계층이 계측(instrumentation)되어, 단일 Python AWS CDK 애플리케이션으로 제공됩니다. 명령 한 번으로 전부 배포되며, 순서는 CDK가 도출합니다.

이전에 2024년 게시물을 읽으셨다면, Amazon S3 버킷에서 지식 베이스로 이어지는 경로는 익숙할 것이고, 그 이후의 모든 내용은 새로운 것입니다. 벡터 스토어는 사라졌고, 검색은 에이전틱해졌으며, 앱이 프로비저닝하는 것의 약 절반은 에이전트가 무엇을 했는지 알려주기 위해 존재합니다. 읽지 않으셨더라도 이 게시물은 그 자체로 완결됩니다.

여기서 다루는 서비스들과 하나의 질문이 거치는 경로는 다음과 같습니다: 에이전트는 검색할지 여부와 어느 지식 베이스를 조회할지 결정하고, Gateway는 각 지식 베이스를 호출 가능한 도구로 노출하며, Managed Knowledge Bases는 검색과 인용을 수행하고, 이 루프는 질문에 필요한 만큼 반복됩니다. 에이전트가 이 과정에서 수행하는 모든 작업은 Amazon CloudWatch에 기록됩니다.

그림 1: 관련된 서비스들과 하나의 질문이 거치는 경로

배경

본격적인 워크스루에 앞서 세 가지를 먼저 짚고 넘어가면 도움이 됩니다: 검색을 에이전틱하게 만드는 것이 무엇인지, Managed Knowledge Base가 그에 적합한 기반인 이유는 무엇인지, 그리고 관찰 가능성과 평가가 나중에 덧붙이는 것이 아니라 설계에 포함되어야 하는 이유는 무엇인지입니다.

RAG에서 엔터프라이즈 에이전틱 검색으로

기존의 Retrieval Augmented Generation(RAG)은 한 번의 검색과 한 번의 생성을 수행합니다. 엔터프라이즈 에이전틱 검색 은 추론 에이전트를 루프 안에 배치합니다. 에이전트는 무엇을 그리고 어떻게 검색할지 결정하고, 정제를 위해 여러 번 검색할 수 있으며, 어느 지식 베이스 가 관련 있는지 선택(시맨틱 라우팅)한 후에야 인용과 함께 근거 있는 답변을 작성합니다. Managed Knowledge Base에서는 이것이 일급 서비스 기능으로 제공되며, AgenticRetrieveStream API가 멀티턴 계획을 수행하고 검색을 실행하며 인용이 포함된 답변을 반환합니다. 이는 원시 벡터 검색 위에 직접 구축하고 유지보수하는 오케스트레이션 계층이 아닙니다. 복잡한 질문에 대해 더 나은 답변을 만들어내지만, 운영하기 더 복잡한 시스템이 된다는 의미이기도 하며, 이것이 바로 관찰 가능성과 평가가 처음부터 내장되어 있는 이유입니다.

Managed 방식과 자체 구축 Knowledge Base 비교

Amazon Bedrock은 이제 Managed Knowledge Base (유형: MANAGED)를 제공합니다. Amazon Bedrock이 수집, 저장, 색인 및 검색 을 대신 처리하며, 기본적으로 서비스 관리 모델을 사용한 임베딩 및 리랭킹을 포함하므로 프로비저닝, 확장 또는 패치할 벡터 데이터베이스가 필요 없습니다. 이는 벡터 스토어(예: Amazon OpenSearch Serverless)를 직접 선택하고 운영하는 고객 관리형 (DIY) Knowledge Base와 다릅니다.

이 솔루션에서 가장 중요한 두 가지 차이점은 다음과 같습니다:

에이전틱 검색(agentic retrieval)과 AgentCore Gateway 커넥터는 관리형 지식 베이스에서만 사용할 수 있으므로, 이것이 기업용 에이전틱 검색에 가장 자연스러운 기반입니다. 또한 Amazon Bedrock이 스토리지와 색인을 대신 관리해 주기 때문에, 이 설계에서는 OpenSearch Serverless 컬렉션이나 OCU 용량을 프로비저닝할 필요가 없습니다. 고객 관리형 옵션은 자체 벡터 스토어를 선택하고 운영하려는 경우, 예를 들어 기존 OpenSearch Serverless 컬렉션을 재사용하거나 특정 데이터 상주지, 튜닝 또는 규정 준수 요건을 충족해야 하는 경우에 여전히 적합한 선택입니다. 기업용 에이전틱 검색의 경우, 관리형 지식 베이스가 이 기능을 가능하게 만드는 핵심입니다.

왜 관찰 가능성과 평가인가

다음과 같은 에이전트형 시스템으로서, 답변을 반환합니다 프로덕션에는 부족합니다. 시스템이 어떻게 동작하는지(지연 시간, 호출량, 토큰 사용량), 검색과 답변의 품질이 어느 정도인지 확인해야 하며, 이러한 신호를 지속적으로 파악해야 합니다. 이 솔루션 선박들 seven개 계층의 텔레메트리를 아우르는 두 개의 CloudWatch 대시보드와 두 가지 형태의 평가(온디맨드 및 지속적)가 모두 동일한 CDK 애플리케이션으로 프로비저닝됩니다. 그라운딩, 인용, 평가 계층은 또한 책임 있는 사용도 지원합니다. 인용된 답변은 출처 문단까지 추적할 수 있어 응답의 감사 가능성이 유지되며, 충실도와 정확성 점수를 통해 답변이 출처에서 벗어나는 것을 프로덕션 환경에서 뒤늦게 발견하는 대신 미리 잡아낼 수 있습니다.

왜 이 특정 솔루션에 CDK를 사용하는가

어떤 infrastructure-as-code 도구로도 이러한 리소스를 생성할 수 있습니다. CDK가 여기서 자리를 차지한 데에는 이 아키텍처에 특유의 이유가 있습니다: 네 개의 스택은 서로 빽빽하게 교차 참조되어 있습니다. 게이트웨이는 두 knowledge base id가 모두 필요합니다. 에이전트는 게이트웨이의 URL과 ARN이 필요합니다. 대시보드에는 KB id, 게이트웨이 ARN이 필요하며, 및 에이전트 런타임 ID, 스택 경계를 넘나드는 일곱 개의 값, 각각은 메트릭의 차원이거나 커넥터의 대상입니다.

원시 템플릿으로 작성하면, 그것은 수동으로 일관성을 유지해야 하는 스택 익스포트와 크로스 스택 조회의 집합이며, 더하여 올바른 순서로 배포하고 출력값을 다음 단계로 전달하는 스크립트가 필요하고, 무언가 이름이 바뀌는 순간 둘 다 어긋납니다. CDK에서는 컨스트럭트를 전달하기만 하면, 익스포트와 의존성 엣지가 그 전달이라는 단일 행위로부터 파생됩니다. 2024년 솔루션은 세 개의 스택과 대체로 선형적인 의존성 체인을 가지고 있었습니다. 스택이 네 개가 되고 그 사이를 오가는 값이 일곱 개가 되면, 이 차이는 더 이상 스타일의 문제가 아닙니다.

솔루션 개요

다음은 하나의 질문이 시스템을 통해 처음부터 끝까지 통과하는 경로입니다. 이 글의 나머지 부분이 이를 왼쪽에서 오른쪽으로 설명하므로, 천천히 살펴볼 가치가 있습니다.

다음 다이어그램은 엔드투엔드 에이전트형 검색 워크플로를 추적합니다. 사용자의 질문은 AgentCore Runtime의 에이전트에 들어와, AgentCore Gateway를 통해 두 개의 AgenticRetrieveStream 도구 중 하나로 라우팅되며, 도구는 관리형 지식 베이스마다 하나씩 있고 각각 금융과 날씨 지식 베이스로 Amazon S3에서 수집됩니다. 선택된 도구는 근거가 있는 인용된 답변을 반환하고, 모든 단계는 Amazon CloudWatch와 AWS X-Ray로 스트리밍됩니다. 번호가 매겨진 배지는 다음 설명과 대응됩니다.

그림 2: 단일 질문에 대한 엔드투엔드 에이전트형 검색 워크플로

다이어그램의 번호가 매겨진 단계는 다음과 같은 워크플로에 대응합니다.

단계 0 — 배포 시 일회성. 질문이 요청되기 전에, Amazon S3의 각 코퍼스는 자체 관리형 지식 베이스(Managed Knowledge Base)로 수집됩니다: Amazon Bedrock이 자동으로 파싱, 청킹, 임베딩, 인덱싱합니다. 이는 스택이 배포될 때 한 번 발생하며 질문별 경로의 일부가 아니므로, 점선 화살표로 그려지고 단계 0으로 표시됩니다. 이후 모든 질문은 단계 1–6을 따릅니다:

1. 사용자가 에이전트에 질문을 보냅니다 에이전트는 Amazon Bedrock AgentCore Runtime에서 호스팅됩니다. Runtime은 전체 추론-행동(reason-and-act) 루프를 OpenTelemetry(OTEL) 스팬으로 자동 계측하므로, 첫 호출부터 시스템을 관측할 수 있습니다.
2. 에이전트의 추론 모델이 지식 베이스 간에 계획하고 라우팅합니다. 각 지식 베이스가 자체 검색 도구로 노출되기 때문에, 에이전트는 하나의 블렌딩된 인덱스를 검색하는 대신 질문의 주제, 즉 금융 또는 날씨에 일치하는 도구를 선택합니다.
3. 선택된 도구 호출은 AgentCore Gateway가 MCP를 통해 중개합니다호출은 에이전트의 IAM 작업 역할로 권한이 부여되고 SigV4로 서명되며, 관리형 지식 베이스에서 해당 지식 베이스의 AgenticRetrieveStream API를 호출합니다.
4. AgenticRetrieveStream은 지식 베이스 내부 작업을 수행합니다: 질문을 하위 쿼리로 분해하고, Amazon Bedrock이 관리하는(Amazon S3의 코퍼스에서 수집된) 데이터 스토어에서 반복적으로 검색하며, Gateway를 통해 스트리밍되는 근거가 있는 인용된 답변을 합성합니다.
5. 에이전트는 반환된 컨텍스트가 충분한지 확인합니다. 충분하지 않으면 최종 답변을 작성하기 전에 루프를 돌며 다시 라우팅하고 검색합니다. 충분하면 인용된 답변을 사용자에게 반환합니다.
6. 전체 과정에서 Runtime은 스팬, 토큰 수, 메트릭을 내보냅니다 이것은 Amazon CloudWatch와 AWS X-Ray로 전송되어 일곱 개의 관측성 계층을 채우고 온디맨드 및 지속 평가 점수 모두에 데이터를 공급합니다.

내부적으로 이 워크플로는 하나의 CDK 앱이며, app.py네 개의 스택을 선언합니다. 순서를 직접 선택하지 않아도, CDK가 전달된 컨스트럭트 참조로부터 이를 도출합니다:

kb_stack = KnowledgeBasesStack(app, f"{project}-kb", env=env)

gateway_stack = AgenticGatewayStack(
    app, f"{project}-gateway", env=env,
    financial_kb=kb_stack.financial_kb,  # ← the reference creates the dependency
    weather_kb=kb_stack.weather_kb,
)

agent_stack = AgentRuntimeStack(
    app, f"{project}-agent", env=env,
    gateway=gateway_stack.gateway,
)

DashboardsStack(
    app, f"{project}-dashboards", env=env,
    financial_kb=kb_stack.financial_kb,
    weather_kb=kb_stack.weather_kb,
    gateway=gateway_stack.gateway,
    agent_runtime=agent_stack.agent_runtime,
)

이것이 전체 배선입니다. 이 네 개의 생성자 호출이 익스포트/임포트 관리 작업과 배포 스크립트를 대체하는 것입니다.

에이전트는 추론-행동(reason-and-act) 루프를 실행합니다. 즉, 생각하고(대규모 언어 모델(LLM) 호출), 어떤 KB 도구를 호출할지 결정하고, Gateway를 통해 반환된 내용을 읽고, 최종적으로 인용이 포함된 답변을 작성하기 전에 종종 다시 검색합니다. 모든 단계는 Runtime에 의해 자동으로 계측되므로, 7개의 관찰 가능성 레이어가 실제 트래픽으로 채워집니다.

7개의 레이어. L1 KB 네이티브 메트릭, L2 수집(ingestion), L3 에이전트형 검색 품질, L4 Gateway/MCP 메트릭, L5 OTEL 스팬 트리, L6 토큰 사용량, 그리고 L7 평가 점수입니다. 레이어 1, 4, 5는 자동으로 생성됩니다. 레이어 3, 6, 7은 드라이버 노트북이 사용자 지정 메트릭으로 게시합니다.

모든 조정 가능한 항목은 한 파일에 있습니다. config.py:

변화하는 PROJECT_NAME 전체 솔루션의 별도 이름을 가진 복사본을 제공하므로, 두 배포가 하나의 계정에서 공존할 수 있습니다. 드라이버 노트북은 동일한 상수를 읽기 때문에 이름 변경을 자동으로 따라가며, 손으로 동기화해야 하는 스택 이름이 없습니다.

데이터셋을 설명하세요

이 솔루션은 저장소의 data/ 아래에 번들로 포함된 두 개의 소규모 코퍼스와 함께 제공됩니다:

• 금융 — 합성으로 생성된 Octank Financial 10-K 파일(octank_financial_10K.pdf, 약 198 KB).
• 날씨 — A 실제로 공개적으로 이용 가능한 미국 의회조사국의 토네이도 관련 보고서("IF12695, tornadoes_report.pdf, 약 560 KB).

⚠️ 데이터 정보: 해당 금융 코퍼스는 합성. Octank은 가상의 회사이며, 10-K는 모델이 생성한 샘플 데이터(CC0 라이선스)입니다. 그것은않는 실제 금융 데이터입니다. 날씨 코퍼스는 실제로 존재하는 퍼블릭 도메인 미국 정부 저작물로, Congressional Research Service 보고서이며 다음에서 공개적으로 이용할 수 있습니다. sgp.fas.org/crs/misc/IF12695.pdf (미국 정부 저작물은 저작권의 대상이 아닙니다). 자신의 데이터를 사용하려면 data/ 아래에 파일을 넣고 그 안의 접두어를 조정하면 됩니다 config.py, 그 외에는 다른 변경이 필요하지 않습니다.

두 코퍼스는 의도적으로 서로 구분되어 있으므로, 에이전트는 각 질문을 올바른 지식 베이스로 라우팅해야 합니다. 이것이 바로 시맨틱 라우팅 시나리오입니다. 이들은 Managed Knowledge Base이기 때문에 청킹(chunking), 임베딩(embedding), 인덱스를 구성할 필요가 없습니다. 데이터를 수집하면 Amazon Bedrock이 각 PDF를 파싱하고, 청크로 나누고, 자체 관리형 모델로 임베딩한 후 자동으로 인덱싱합니다.

우리는 두 개의 별도 지식 베이스를 사용하며, 각각은 Gateway를 통해 자체 검색 도구로 노출됩니다. 두 코퍼스를 모두 담은 단일 지식 베이스를 사용하지 않는데, 이는 의도적인 선택입니다. 에이전트에게 이름이 지정된 두 개의 도구를 제공하면 라우팅이 에이전트가 수행하는 모습을 관찰할 수 있는 명시적인 추론 행위가 되며, 스팬 트리(span tree)에는 다음 내용이 표시됩니다 어느 주어진 질문에 대해 에이전트가 선택한 도구가 명확하고, 레이어 3의 검색 품질 지표는 지식 베이스별로 분리된 상태로 유지되므로 금융 정밀도와 날씨 정밀도가 하나의 숫자로 뭉개지는 일은 없습니다. 두 코퍼스를 모두 다루는 단일 도구는 이 구분을 무너뜨리고, 라우팅 결정이 하나의 인덱스의 랭킹 내부로 숨겨져 보이지 않게 되며, 모든 품질 신호가 서로 관련 없는 두 도메인에 걸친 평균값이 되어버릴 것입니다. 코퍼스와 그에 해당하는 도구를 분리해 두는 것이야말로 에이전트의 행동을 판독 가능하게 만드는 것이며, 이것이 바로 이 작업의 핵심입니다.

CDK에서는 S3에 코퍼라를 넣는 작업이 BucketDeployment로 처리됩니다:

s3deploy.BucketDeployment(
    self, "FinancialCorpus",
    sources=[s3deploy.Source.asset(str(ROOT / "data" / "financial"))],
    destination_bucket=self.source_bucket,
    destination_key_prefix=KbConfig.FINANCIAL_PREFIX,
)

BucketDeployment를 알아둘 가치가 있는 것은 바로 그 대안이 너무 유혹적이기 때문입니다: 이것이 없으면 수집(ingestion)을 트리거하는 커스텀 리소스에 업로드 단계가 붙어버리기 쉽고, 그러면 하나의 리소스가 서로 관련 없는 두 가지 작업을 담당하게 됩니다. 여기서는 그저 ~만 하면 됩니다. 수집.

관리형 수집(ingestion)은 각 문서를 자동으로 스캔, 청크 분할, 임베딩 및 인덱싱합니다: 지식 베이스당 하나의 문서가 인덱싱되며, 실패는 없습니다.

그림 3: 관리형 수집 결과, 지식 베이스당 문서 1개가 색인되었으며 실패 0건

솔루션 배포

이 섹션에서는 명령 한 번으로 전체 솔루션을 배포하는 과정을 안내합니다. 사전 요구 사항이 충족되면, cdk deploy --all CDK의 파생 의존성 순서에 따라 네 개의 스택을 모두 프로비저닝하고 모든 교차 스택 값을 자동으로 전달합니다.

사전 요구 사항

• Amazon Bedrock, AgentCore(Runtime + Gateway)에 대한 권한을 가진 AWS 계정, AWS Identity and Access Management(IAM), CloudWatch, AWS X-Ray, Amazon Elastic Container Registry(Amazon ECR), AWS CodeBuild, Amazon S3, AWS Lambda, 그리고 AWS CloudFormation.
• 계정에서 사용 가능한 에이전트의 모델(기본값 us.anthropic.claude-haiku-4-5-20251001-v1:0).
• Layers 5–7을 위해 OTEL 스팬이 aws/spans에 저장되도록 CloudWatch Transaction Search 활성화.
• Node.js 18+ 및 CDK CLI(npm install -g aws-cdk), 그리고 Python 3.13+.
• 계정/리전당 한 번, CDK용으로 부트스트랩된 계정 및 리전(cdk bootstrap).
• 로컬 Docker 불필요 — 에이전트 이미지는 CodeBuild(ARM64)로 빌드됩니다.

한 개의 명령어

솔루션을 배포하려면 리포지토리를 복제하고, 가상 환경을 생성하고, 종속성을 설치한 후 cdk deploy --all를 실행하세요. 터미널에서 다음 명령을 실행합니다:

git clone https://github.com/aws-samples/amazon-bedrock-samples.git
cd rag/managed-knowledge-bases/07-IaaC/managed-kb-observability-cdk/
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cdk bootstrap  # once per account/region
cdk deploy --all

처음 두 명령은 샘플을 복제하고 프로젝트 디렉터리로 이동합니다. 다음 두 명령은 Python 가상 환경을 생성 및 활성화하고 CDK 앱의 종속성을 설치합니다. cdk bootstrap 는 계정과 리전을 CDK에 맞게 준비하고(계정/리전당 한 번만 필요), cdk deploy --all 는 네 개의 스택을 모두 프로비저닝합니다.

계정과 리전은 AWS 프로파일(CDK_DEFAULT_ACCOUNT / CDK_DEFAULT_REGION)에서 가져오므로, 수정 없이 앱을 배포할 수 있습니다.

리전 가용성: 관리형 지식 베이스, 에이전틱 검색(AgenticRetrieveStream), Amazon Bedrock AgentCore(Runtime 및 Gateway)는 모든 AWS 리전에서 사용할 수 있는 것은 아닙니다. 배포하기 전에 대상 리전에서 이 모든 기능이 제공되는지 확인하고 ACCOUNT_REGION 을 config.py 에 맞게 설정하세요. 기본값은 us-west-2입니다. 최신 가용성은 Amazon Bedrock 및 Amazon Bedrock AgentCore 문서와 AWS Regional Services List.

이 버전에는 배포 스크립트가 없으며, 그것이 바로 핵심입니다: cdk deploy --all 에서 파생된 의존성 그래프를 탐색하고, app.py네 개의 스택을 순서대로 배포하며, 모든 크로스 스택 값을 자동으로 전달합니다. 터미널은 각 스택이 완료될 때마다 보고하는데, bmkb-obs-cdk-kb [1/4](기본 PROJECT_NAME), 그다음 gateway [2/4], agent [3/4], dashboards [4/4] 순이며, 이 순서는 선언된 것이 아니라 파생된 것입니다. 즉, 스택 간의 construct 참조에서 자연스럽게 도출되므로 기존 출력을 소비하는 다섯 번째 스택을 추가하면 배포 순서가 스스로 재정렬됩니다.

Stack -agent는 CodeBuild로 에이전트 컨테이너를 빌드하므로 해당 단계에 약 8–10분 정도 걸린다고 보면 됩니다. 나머지 세 개는 빠릅니다. 각 스택은 완료 시 출력값을 출력하며, 여기에서 지식 베이스 id, Gateway URL, 런타임 ARN, 그리고 두 개의 대시보드 URL을 확인할 수 있습니다. 배포가 완료되면 네 개의 스택이 모두 완료 상태가 됩니다. 다음 스크린샷은 성공적인 cdk deploy --all.

그림 4: 성공적인 배포 후 네 개의 스택이 모두 CREATE_COMPLETE 상태인 AWS CloudFormation 콘솔

콘솔에서 네 개의 스택인 kb, gateway, agent, dashboards가 모두 CREATE_COMPLETE 상태로 표시되며, 각 스택의 설명에 파생된 의존성 순서에서의 [n/4] 위치가 함께 표시됩니다.

장기 실행 리소스에 대한 참고 사항

이 솔루션에는 단순 폴링 방식으로는 AWS Lambda 함수의 15분 제한 시간보다 훨씬 오래 걸리는 두 가지가 있습니다. 바로 KB ingestion 동기화와 CodeBuild 이미지 빌드입니다. AWS CDK Provider 프레임워크는 이를 다음과 같은 방식으로 처리합니다. on_event / is_complete 분리 구조를 사용합니다. 즉, 한 핸들러가 작업을 시작하고, 두 번째 핸들러가 완료를 보고할 때까지 폴링됩니다.

cr.Provider(
    self, "IngestSyncProvider",
    on_event_handler=on_event,        # StartIngestionJob, return the job id
    is_complete_handler=is_complete,  # GetIngestionJob, report IsComplete
    query_interval=Duration.seconds(30),
    total_timeout=Duration.minutes(30),
)

어떤 것도 블로킹되지 않고, CloudFormation으로의 응답 프로토콜은 각 핸들러에 직접 작성하는 것이 아니라 프레임워크가 소유하며, 30분 예산은 속성(property)으로 설정되는 것이지 우회해서 해결해야 할 문제가 아닙니다.

실행 및 테스트

notebooks/01-drive-and-observe.ipynb를 열고 처음부터 끝까지 실행합니다(pip install -r requirements-notebook.txt 먼저 실행). 이 노트북은 스택 출력값을 읽은 다음, 배포된 에이전트에게 주제별 프롬프트를 전송합니다. KB당 하나의 세션으로 진행되므로 답변과 의미 기반 라우팅을 한 곳에서 모두 확인할 수 있습니다. 금융 질문은 Octank 10-K에서, 날씨 질문은 토네이도 보고서에서 답변되며, 각각 자동으로 일치하는 AgenticRetrieveStream 도구로 라우팅됩니다.

노트북은 스택 출력값으로부터 모든 것을 자동으로 찾아내므로, 수동으로 붙여넣을 것이 없습니다:

# Stack names are derived from the same PROJECT_NAME the CDK app uses, so renaming the
# project in config.py cannot leave this notebook pointing at stale stacks.
from config import EnvSettings

PROJECT = EnvSettings.PROJECT_NAME
STACKS = {suffix: f'{PROJECT}-{suffix}'
          for suffix in ('kb', 'gateway', 'agent', 'dashboards')}

def outputs(stack_name):
    s = cfn.describe_stacks(StackName=stack_name)['Stacks'][0]
    return {o['OutputKey']: o['OutputValue'] for o in s.get('Outputs', [])}

노트북은 앱과 동일한 config.py 것을 임포트하므로, 스택 이름에 대해 두 코드가 서로 불일치할 수 없습니다.

드라이버는 배포된 에이전트를 통해 KB별 프롬프트를 전송합니다. 금융 질문은 금융 KB로, 날씨 질문은 날씨 KB로 라우팅되며, 각각 근거가 있고 인용이 포함된 답변을 받습니다.

그림 5: 일치하는 지식 베이스로 라우팅되는 KB별 프롬프트, 각각 근거가 있고 인용이 포함된 답변을 반환

노트북은 또한 에이전트가 실제로 검색하고 인용한 내용을 기반으로 참조 불필요(reference-free)인 Layer 3 검색 품질 신호를 계산합니다. 정답(ground truth)도, 별도의 저지(judge)도 없이 계산되며, 그 결과를 CloudWatch에 게시합니다.

그림 6: 지식 베이스별 참조 불필요(reference-free) Layer 3 검색 품질 신호

관측: 7계층 대시보드

두 개의 대시보드는 7개 계층이 가시화되는 곳입니다. 스택이 두 대시보드를 모두 생성하며, 트래픽을 유입하면 대시보드에 데이터가 채워집니다. 다음 스크린샷은 CloudWatch 콘솔에서 표시되는 두 대시보드의 모습입니다.

그림 7: CloudWatch 콘솔의 두 대시보드, 엔드투엔드 에이전틱 관측성 및 KB별 관측성

두 대시보드 모두 CloudWatch 콘솔에 표시됩니다: 하나는 엔드투엔드 에이전틱 관측성용, 다른 하나는 KB별 관측성용(BMKB, Bedrock Managed Knowledge Base)입니다. 이 섹션의 나머지 부분에서는 각 계층이 무엇을 보여주는지 살펴봅니다.

이 버전에서 대시보드는 JSON 문자열이 아닌 타입이 지정된 객체로 구성됩니다. 지표는 Metric이고, 위젯은 GraphWidget이며, 레이아웃은 Row의 리스트입니다:

cw.GraphWidget(
    title="L4 — Gateway metrics (MCP)",
    width=12, height=6, period=PERIOD, statistic="Sum",
    left=[
        self._gateway_metric("Invocations", gateway_arn, "tools/call Invocations"),
        self._gateway_metric("SystemErrors", gateway_arn, "SystemErrors"),
        self._gateway_metric("UserErrors", gateway_arn, "UserErrors"),
        self._gateway_metric("Throttles", gateway_arn, "Throttles"),
    ],
)

실질적인 이점은 코드 줄 수가 적다는 것이 아니라, dashboards_stack.py 400줄에 달하며, 이는 동등한 DashboardBody JSON보다 깁니다. 핵심은 잘못 입력된 속성이나 유효하지 않은 위젯 조합이 cdk synth시점에, 노트북에서 약 1초 만에 실패한다는 것입니다. DashboardBody 문자열 내부에서 동일한 실수를 하면 배포는 성공하지만 AWS Management Console에서 깨진 위젯으로 렌더링되어, 직접 눈으로 확인해야 발견할 수 있습니다.

Row는 어떤 위젯이든 받아들일 수 있으므로, 문서는 흩어지기 쉬운 위키 페이지가 아니라 레이아웃의 일부가 됩니다. 각 대시보드는 그래프와 TextWidget을 교차 배치합니다:

[cw.TextWidget(width=24, height=7, markdown=self._l3_explainer())],
[
    self._quality_widget("L3 · Financial KB — agentic quality (reference-free, 0–1)", fin_id),
    self._quality_widget("L3 · Weather KB — agentic quality (reference-free, 0–1)", wx_id),
],

_l3_explainer()는 각 비율의 정의와 읽는 방법을 담은 마크다운 테이블을 반환하므로, grounded_coverage를 설명하는 위젯이 해당 지표를 플롯하는 위젯과 동일한 커밋에 함께 포함되며, 대시보드를 아무런 사전 지식 없이 열어본 독자도 참조 메트릭(reference-free metric)이 무엇인지 추측할 필요가 없습니다.

대시보드 A — 에이전틱 관측성(엔드투엔드). 이 보드는 각 계층이 서로 다른 것을 어떻게 계수하는지 설명하는 안내로 시작합니다( N 개의 쿼리에 대해 약N 개의 에이전트 호출, 약 2N 개의 검색, 약 3N 개의 LLM 호출, 그리고 약 5N 개의 Gateway MCP 작업이 발생하며, 이것이 가시화된 에이전틱 루프입니다). 이어서 KB 지표(L1), Gateway 지표 및 지연 시간(L4), 토큰 사용량(L6)을 보여주며, 에이전트가 청크별 점수가 아닌 합성되고 인용이 포함된 답변을 반환하는 AgenticRetrieveStream을 사용하기 때문에, 인라인으로 정의되고 KB별로 플롯되는 참조 불필요(Layer 3) 품질 신호도 함께 표시됩니다.

대시보드 A에서 Layer 3 참조 불필요 품질 신호는 지식 베이스별로 플롯됩니다. 먼저 금융 KB입니다. 다음 차트는 이 KB의 retrieval_utilization, grounded_coverage, duplicate_rate를 플롯합니다.

그림 8: 금융 KB Layer 3 품질, 검색 활용도, 근거 커버리지, 중복률 플롯

날씨 KB도 동일한 세 가지 신호를 보여주며, 두 도메인이 하나의 숫자로 뭉개지지 않도록 별도로 추적합니다.

그림 9: 날씨 KB Layer 3 품질, 금융 KB와 별도로 추적

두 차트는 금융 KB(왼쪽)와 날씨 KB(오른쪽)에 대해 retrieval_utilization, grounded_coverage, duplicate_rate를 플롯하여, 각 지식 베이스의 검색 품질이 하나의 숫자로 평균화되지 않고 구분 가능한 상태로 유지됩니다.

대시보드 B — KB별(BMKB) 관측성. 지출에도 영향을 미치는 운영 신호들을 KB별로 표시합니다: 인덱스 크기(S3 소스 바이트 기준), 검색(retrieve) 볼륨, 에이전틱 도구 호출, 세션 토큰 사용량, 모델별 생성 토큰 사용량이며, 각 항목에는 인라인 설명이 포함됩니다.

다음 스크린샷들은 실행 후 데이터가 채워진 대시보드 B의 네 가지 지표 위젯을 보여줍니다. 첫 번째 위젯은 S3 소스 바이트에서 도출된 지식 베이스별 인덱스 크기를 보고합니다.

그림 10: 대시보드 B의 지식 베이스별 인덱스 크기, Amazon S3 소스 바이트에서 도출

두 번째 위젯은 지식 베이스별 검색(retrieve) 호출 횟수를 계수합니다.

Figure 11: 대시보드 B의 지식 베이스별 검색 호출 수

세 번째 위젯은 Gateway를 통해 수행되는 에이전틱 툴 콜을 집계합니다. 이 항목은 분할되지 않고 두 KB에서 공유됩니다.

Figure 12: 두 지식 베이스에서 공유되는 AgentCore Gateway를 통한 대시보드 B의 에이전트 도구 호출 수

네 번째 위젯은 지식 베이스별 세션 토큰 사용량을 보고합니다.

그림 13: 대시보드 B의 지식 베이스별 세션 토큰 사용량

네 개의 위젯은 인덱스 크기(S3 소스 바이트 기준), retrieve 호출 볼륨, Gateway를 통한 에이전트 도구 호출 수, 세션 토큰 사용량을 보여줍니다. Gateway 도구 호출 횟수는 두 지식 베이스에서 공유되며, 그 외 각 항목은 지식 베이스별로 구분됩니다.

한 가지 차원(크기) 세부 사항은 짚고 넘어갈 가치가 있는데, 타입이 지정된 API가 이를 잡아주지 못하기 때문입니다: 바로 AWS/Bedrock/KnowledgeBases 네임스페이스에는 접두사가 붙은 id가 필요합니다. knowledge-base/<id>, 한편 솔루션 자체의 BMKB/* 네임스페이스는 bare id를 사용합니다. 둘 다 CDK 관점에서는 단지 문자열일 뿐입니다.

# L1 — AWS/Bedrock/KnowledgeBases wants the prefixed form.
dimensions_map={"Operation": "Retrieve", "KnowledgeBaseId": f"knowledge-base/{kb_id}"}

# BMKB/* — our own namespaces use the bare id.
dimensions_map={"KnowledgeBaseId": kb_id}

레이어 5: 스팬 트리

Layer 5은 aws/spans에 있는 raw OTEL span tree이며, agentic loop를 직접 보여주는 계층입니다. nesting이 직관적이지 않기 때문에 주의 깊게 읽어볼 가치가 있습니다. LLM call 하나가 세 개의 span을 생성합니다. The Strands invoke_agent span이 턴을 감싸며, 내부 chat span이 모델 호출을 감싸며, chat <model> 종류의 범위 CLIENT 실제 호출이며, 세 가지 모두 동일한 gen_ai.usage.* 토큰 속성.

다음 스크린샷은 aws/spans의 스팬 트리를 보여주며, 상단 행에서 세 개의 스팬으로 이루어진 중첩 구조가 확인됩니다.

그림 14: aws/spans의 레이어 5 span 트리, 단일 LLM 호출의 3단 span 중첩 구조를 보여줌

상위 세 행을 읽어보면: invoke_agent Strands Agents 집계, 그 다음 내부 chat 스팬, 그 다음 CLIENT chat 스팬이 모두 동일한 입력 7,299 토큰과 출력 268 토큰을 보고하고 있습니다. 이는 동일한 LLM 호출이 트리의 세 계층에 걸쳐 나타나는 것으로, 그래서 집계 시 주의가 필요합니다.

그 구조는 집계하는 순간 중요해집니다. 각 LLM 호출을 한 번만 세려면 다음으로 필터링하십시오. CLIENT leaf:

fields attributes.gen_ai.request.model as model,
       attributes.gen_ai.usage.input_tokens as in_tok,
       attributes.gen_ai.usage.output_tokens as out_tok
| filter ispresent(in_tok) and kind = 'CLIENT' and name like /^chat /
| stats sum(in_tok) as input_tokens, sum(out_tok) as output_tokens,
        count(*) as llm_calls by model

해당 필터가 없으면 동일한 쿼리가 토큰 수와 호출 수를 세 배로 보고합니다.

해당 CLIENT-leaf 필터를 적용하면, 다음 스크린샷은 각 LLM 호출을 한 번씩 계산하여 모델별 생성 토큰 사용량을 보여줍니다.

그림 15: 모델별 생성 토큰 사용량, 각 LLM 호출을 한 번씩 계산

필터를 적용하면 실행 결과 14회의 LLM 호출이 표시되며, 총 입력 60,472 토큰, 출력 2,709 토큰이 사용되었습니다. 필터가 없으면 동일한 쿼리에서 호출 수와 토큰 수가 세 배로 보고될 것입니다.

평가: 온디맨드 및 지속적

품질은 두 가지 방식으로 측정되며, 두 방식 모두 앱에서 제공됩니다.

주문형: 드라이버 노트북이 AgentCore를 호출합니다 이 버전에는 배포 스크립트가 없으며, 그것이 바로 핵심입니다: (LLM-as-judge)를 각 세션의 스팬에 대해 내장 평가기인 Correctness, Faithfulness, Tool-Selection Accuracy로 실행하고 그 점수를 CloudWatch에 게시하여 Dashboard A에서 Layer 7로 표시됩니다.

다음 스크린샷은 대시보드 A의 Layer 7을 보여줍니다: 지식 베이스별 온디맨드 평가 점수이며, 동일한 대시보드에 Layer 5 OTEL 스팬 테이블이 함께 표시되어 있습니다.

그림 16: Layer 5 스팬 테이블 옆, 지식 베이스별 Layer 7 온디맨드 평가 점수

Layer 7은 지식 베이스별 온디맨드 평가 점수를 보여주며, 그 옆에 Layer 5의 OTEL 스팬 테이블이 함께 표시되므로 점수와 그 점수를 생성한 스팬을 한 화면에서 함께 확인할 수 있습니다.

지속적(온라인): 에이전트 스택은 또한 AWS::BedrockAgentCore::OnlineEvaluationConfig 라이브 세션을 샘플링하여 노트북 실행 없이 자동으로 점수를 매기는 기능입니다. 이 설정 자체는 다음에서 확인할 수 있습니다. Assess → Evaluations → Evaluation configurations 아래의 Bedrock AgentCore 콘솔. 결과는 로그 그룹에 기록됩니다. /aws/bedrock-agentcore/evaluations/results/<config-id>, 그리고 모든 점수는 Bedrock-AgentCore/Evaluations 네임스페이스에 CloudWatch 지표로도 게시되며, 평가기(evaluator) 이름과 구성 id로 키가 지정되므로 로그를 파싱하지 않고도 점수를 그래프로 표시하거나 알람을 설정할 수 있습니다.

다음 스크린샷은 AgentCore 콘솔에서 Assess, 그다음 Evaluations, 그다음 Evaluation configurations 아래의 온라인 평가 구성을 보여줍니다.

그림 17: AgentCore 콘솔의 온라인 평가 구성, 100 퍼센트 샘플링으로 설정된 4개의 내장 평가기

이 구성에는 Tool-Selection Accuracy, Faithfulness, Correctness, Response Relevance의 4개 내장 평가기가 나열되어 있으며, 100 퍼센트 샘플링으로 설정되어 있고 ACTIVE 상태이며 활성화된 것으로 표시됩니다.

점수가 일반적인 CloudWatch 지표이기 때문에 로그 파싱 없이 다른 지표처럼 그래프로 표시할 수 있으며, 동일한 위젯에 알람을 설정할 수도 있습니다. 다음 스크린샷은 이 4개 평가기 점수가 일반적인 CloudWatch 지표로 그래프에 표시된 모습을 보여줍니다.

그림 18: 일반적인 CloudWatch 지표로 그래프에 표시된 4개의 지속 평가기 점수

4개 평가기 점수는 Bedrock-AgentCore/Evaluations 네임스페이스의 지표로 나타나며, 각각 평가 구성 id와 에이전트의 서비스 이름으로 키가 지정되므로 로그를 파싱하지 않고도 그래프로 표시하거나 알람을 설정할 수 있습니다.

온라인 결과는 세션이 종료된 후에만 도착합니다. 점수 산정은 완료된 세션에 대해 실행되므로, 트래픽을 발생시킨 후 결과 로그 그룹은 대략 세션 유휴 타임아웃(~30분) 동안 비어 있게 됩니다. 실행 직후 그룹이 비어 있는 것은 예상된 현상이며 구성 오류가 아닙니다. 각 결과 이벤트에는 session.id이 포함되어 있어 다른 모든 계층과 조인됩니다. 노트북의 온디맨드 경로에는 이러한 대기가 없는데, 그래서 둘 다 여기에 있는 것입니다.

이 실행에서 4개 내장 평가기 전반에 걸쳐, 지속 경로는 Correctness, Faithfulness, Response Relevance, Tool-Selection Accuracy에서 1.00 점수를 기록했으며, 평가기당 5개의 점수가 매겨진 트레이스가 있고 각 결과에 서면 설명이 포함되어 있습니다.

⚠️ 샘플링과 비용. 이 앱은 블로그 실험을 위해 순수하게 SAMPLING_PERCENTAGE = 100 으로 설정되어 있습니다, 따라서 모든 세션이 채점되고 결과가 즉시 표시됩니다. 이것은 프로덕션 권장 사항이 아닙니다. 온라인 평가는 샘플링된 세션마다 LLM-as-judge를 호출하므로 비용이 샘플링 비율과 트래픽 양에 비례하여 증가합니다. 실제 배포에서는 품질 모니터링 필요 사항과 예산에 맞는 샘플링 비율을 선택하고, 활성화하기 전에 조직의 고유 정책 및 비용 거버넌스 요구 사항에 맞춰 구성을 조정하십시오. 비율은 단일 상수이며, EvalConfig.SAMPLING_PERCENTAGE, in config.py.

정리

작업을 마친 후에는 요금이 계속 청구되지 않도록 솔루션을 제거하십시오. 저장된 KB 데이터, ECR의 에이전트 이미지, 그리고 아직 활성 상태인 온라인 평가는 스택이 유휴 상태인 동안에도 비용이 발생합니다. 명령 하나로 모든 것을 삭제할 수 있습니다:

cdk destroy --all

CDK는 스택을 역의존성 순서로 스스로 삭제합니다. 대시보드, 그다음 에이전트, 그다음 게이트웨이, 그다음 kb 순입니다. 배포 시 도출한 것과 동일한 그래프를 거꾸로 걷는 것입니다. 배포 스크립트와 일치하도록 유지해야 하는 별도의 삭제 스크립트가 없다는 점이, 의존성을 한 번만 모델링하면 얻을 수 있는 조용히 큰 가치 중 하나입니다.

두 가지 제거 동작을 알아두면 좋은데, 둘 다 손으로 작성한 정리 코드를 대체하기 때문입니다:

self.source_bucket = s3.Bucket(
    self, "SourceBucket",
    removal_policy=RemovalPolicy.DESTROY,
    auto_delete_objects=True,  # replaces a list_object_versions delete loop
)

self.repository = ecr.Repository(
    self, "AgentImageRepo",
    removal_policy=RemovalPolicy.DESTROY,
    empty_on_delete=True,  # replaces an image-delete loop
)

둘 다 샘플 위생을 위해 설정되어 있습니다. 중요한 데이터가 있는 경우 버킷을 다음으로 전환하십시오: RemovalPolicy.RETAIN.

CDK 부트스트랩 스택(CDKToolkit)과 해당 스테이징 버킷은 제거되지 않습니다. 이들은 다른 CDK 앱이 의존할 수 있는 계정 전체의 공유 인프라입니다.

단일 실행(single-shot) 솔루션 이후 변경된 사항

이 게시물과 2024 솔루션 모두 Python으로 작성된 CDK 애플리케이션이며, 다음으로 배포됩니다 cdk deploy. 여기서 작성 도구는 변하지 않는 부분이며, 바뀐 것은 그 아래의 아키텍처이고, 대부분의 변화는 제거(subtraction)입니다:

이 트레이드오프는 양방향으로 실재합니다. 단일 색인이 단발성 질문에 답하는 방식은 쿼리당 비용이 더 저렴하고, 이해하기 더 간단하며, 하나의 코퍼스에 답이 있을 때는 충분합니다. 그렇지 않다면 이 설계를 선택하세요.

작업을 수행하는 CDK 구성 요소(construct)

이 앱에서 네 개의 구성 요소가 대부분의 역할을 하며, 각각 사람들이 직접 작성해야 하는 것을 대체하기 때문에 이름을 언급할 가치가 있습니다:

• Provider – AWS Lambda 함수의 15분 상한보다 오래 지속되는 커스텀 리소스를 위한 것입니다. 이 on_event / is_complete 분리 구조 덕분에 폴링 루프에서 잠자는 코드가 없으며, CloudFormation으로의 응답 프로토콜은 모든 핸들러에 벤더링된 urllib 콜백이 아니라 프레임워크의 몫입니다.
• BucketDeployment – 코퍼스를 업로드하므로, ingestion 커스텀 리소스는 수집(ingest)만 담당합니다.
• auto_delete_objects=True 그리고 empty_on_delete=True, 수작업으로 작성된 list_object_versions 스택이 최소한 삭제 가능하려면 필요로 하는 이미지 삭제(image-delete) 루프도 말입니다.
• repository.grant_pull_push(project) – CodeBuild에 필요한 여덟 가지 ecr:* 액션을 한 줄로 처리하며, 철자는 구조적으로 올바르게 보장됩니다.

그리고 Observe 섹션의 타입화된 대시보드도 있습니다. DashboardBody JSON 문자열 대신 Metric / GraphWidget / Row 객체를 사용하면, 잘못된 위젯 조합이 “콘솔에서 깨진 상태로 렌더링됨”에서 “ cdk synth.”

CDK가 바꾸지 않는 두 가지가 있으며, 시작하기 전에 둘 다 알아두는 것이 좋습니다:

• 자유 형식 JSON은 camelCase 그대로 유지됩니다. connector_parameters 안의 내용은 parameter_values 그대로 전달되므로, AWS CDK의 snake_case에서 PascalCase로의 변환이 그 안에는 적용되지 않습니다. bucketName 과 같은 키는 API가 기대하는 대로 정확히 써야 하며, 리소스가 실패하기 전까지는 그렇게 하라고 알려주는 것은 아무것도 없습니다. inclusionPrefixes 문자열 타입 값은 여전히 문자열입니다.
• Observe 섹션의 차원과 bare knowledge-base/<id> 차원의 차이는 타입 시스템에는 보이지 않습니다. 타입화된 구성(construct)은 <id> Observe 섹션과의 차원(dimension) 차이는 타입 시스템에 보이지 않습니다. 타입화된 구조는 검사합니다 를 검사하지의미론 은 검사하지 않습니다..

어느 쪽도 한 도구를 다른 도구보다 선호할 이유는 아닙니다. 이것들은 “타입화”가 얻어주는 것의 경계이며, 그 경계가 어디에 있는지 아는 것이야말로 CDK를 놀라움이 아니라 즐겁게 만드는 것의 대부분입니다.

결론

우리는 Managed Amazon Bedrock Knowledge Base와 AgentCore 위에 완전한 엔터프라이즈 에이전틱 검색 솔루션을 구축했습니다. 다중 KB 시맨틱 라우팅, 추론 에이전트, 일곱 계층의 관측 가능성, 온디맨드 및 지속 평가를 모두 갖추고, 이를 단일 AWS CDK 애플리케이션으로 배포했습니다.

기억할 만한 두 가지가 있습니다. 관리형 지식 베이스는 인프라를 더하는 것이 아니라 제거했습니다. 프로비저닝할 벡터 스토어도, 생성하고 기다릴 인덱스도, 시스템이 유휴 상태일 때 누적되는 OCU 비용 항목도 없습니다. 또한 에이전틱 검색과 AgentCore Gateway 커넥터를 지원하는 지식 베이스 유형이기도 합니다. 자세한 내용은 Amazon Bedrock 문서에 설명되어 있습니다. 그리고 검색이 에이전틱이 된 순간부터 관측 가능성은 선택 사항이 아니게 되었습니다. 이 앱이 프로비저닝하는 것의 약 절반이 에이전트가 실제로 무엇을 했고 그 답이 좋은지 아닌지를 알려주기 위해 존재하며, 이것은 에이전틱 시스템에 대한 오버헤드가 아닙니다. 시스템을 운영 가능하게 만드는 부분입니다.

CDK 작성 모델은 경계(seam)에서 그 가치를 입증했습니다. 이 아키텍처에서 일곱 개의 값이 스택 경계를 넘는데, 그 모든 것이 export/import 쌍이 아니라 구성 참조이며, 그렇기 때문에 배포 스크립트도, 해체 스크립트도, 기억해야 할 고정된 순서도 없는 것입니다.

여기서부터는 데이터 소스가 여러분 자신의 코퍼스를 가리키도록 하거나, 에이전트를 가상 프라이빗 클라우드(VPC)에 배치하거나, 온라인 평가 샘플링 비율을 예산과 정책에 맞게 조정하거나, 라우터에 더 많은 지식 베이스를 추가할 수 있습니다. 자세한 내용은 다음을 참조하세요: Amazon Bedrock 상세 페이지와 Amazon Bedrock 문서입니다. 앱, 드라이버 노트북, 자체 포함 유틸리티는 모두 함께 제공되는 GitHub 리포지토리에 있으므로, 복제하여 한 번의 명령으로 자신만의 사본을 배포할 수 있습니다.

저자 소개