Build observable enterprise agentic retrieval using Managed Amazon Bedrock Knowledge Base with AWS CloudFormation

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock Managed Knowledge Base와 Amazon Bedrock AgentCore를 활용해 여러 지식 기반을 선택·반복 검색하고, 7개 관측 계층과 평가 기능을 AWS CloudFormation으로 함께 배포하는 구성을 소개한다.

📌 핵심 요약

• 에이전트는 질문에 따라 금융·날씨 지식 기반을 선택하고, AgenticRetrieveStream은 선택된 지식 기반 내부에서 하위 질의 생성과 반복 검색을 수행해 출처가 포함된 답변을 생성한다.
• Amazon Bedrock Managed Knowledge Base는 수집·저장·인덱싱·검색과 기본 임베딩·재순위화를 관리하며, 원문의 비교표는 에이전트형 검색과 AgentCore Gateway 연동을 관리형에서 지원하는 기능으로 구분한다.
• 솔루션은 지식 기반, AgentCore Gateway, 에이전트 런타임, 대시보드를 구성하는 4개 AWS CloudFormation 스택으로 배포되며, Gateway는 지식 기반마다 별도의 MCP 검색 도구를 노출한다.
• 2개 Amazon CloudWatch 대시보드와 7개 관측 계층이 지식 기반 상태, 수집 결과, 검색 품질, 도구 호출, 실행 추적, 토큰 사용량, 평가 점수를 다루며, 온디맨드 평가와 지속 평가를 함께 제공한다.
• 데이터는 합성 Octank Financial 10-K와 실제 미국 의회조사국 토네이도 보고서로 구성된다. 배포에는 관련 AWS 서비스 권한과 에이전트 모델 접근이 필요하며, 제공된 본문은 CloudWatch Transaction Search 항목에서 끝나 실제 배포 명령과 확인 절차는 제시되지 않는다.

🧩 주요 포인트

1. 지식 기반 간 선택과 내부 반복 검색의 역할 분리 → 에이전트의 도구 선택과 AgenticRetrieveStream의 검색 과정을 구분해 이해할 수 있다.
2. 관리형 데이터 처리와 지식 기반별 MCP 도구 제공 → 벡터 데이터베이스 운영 부담과 검색 도구 연결에 필요한 별도 실행 구성요소를 줄인다.
3. 분리된 금융·날씨 지식 기반과 7개 관측 계층 → 주제별 검색 경로, 운영 상태, 토큰 사용량, 답변 품질을 함께 검토할 수 있다.

🧠 상세 정리

1. 단일 검색에서 에이전트형 검색으로의 전환

일반적인 검색 증강 생성은 하나의 지식 기반에서 한 번 검색한 뒤 답변을 생성하는 방식으로 시작하지만, 질문이 복잡해지거나 답변의 근거가 여러 출처에 흩어지면 이 방식만으로 처리하기 어려워진다. 원문은 에이전트가 질문을 해석하고 적절한 지식 기반을 선택하며, 필요한 경우 검색을 반복한 뒤 출처가 포함된 답변을 구성하는 방식으로 이 문제에 접근한다. 앞선 게시물이 고객이 직접 관리하는 벡터 저장소 기반의 단일 검색 흐름을 자동화했다면, 이번 구성은 관리형 지식 기반과 추론 에이전트로 범위를 확장한다. 검색과 추론이 반복될수록 실행 경로와 답변 품질을 파악하기 어려워진다는 점도 함께 제기한다. 따라서 관측과 평가는 완성 이후에 추가하는 부가 기능이 아니라 처음부터 배포 구성에 포함되는 요소로 설명된다.

2. 관리형 지식 기반의 기능과 운영 범위

Amazon Bedrock Managed Knowledge Base는 MANAGED 유형의 지식 기반으로, 문서 수집부터 저장·인덱싱·검색까지 서비스가 관리하는 구조다. 기본적으로 서비스 관리 모델을 이용한 임베딩과 재순위화가 포함되며, Amazon Bedrock에서 제공하는 다른 모델을 선택할 수도 있다고 설명한다. 이에 따라 사용자는 별도의 벡터 데이터베이스를 프로비저닝하거나 확장하고 패치하는 작업을 맡지 않아도 된다. 원문의 비교표는 AgenticRetrieveStream 기반 에이전트형 검색과 AgentCore Gateway 통합을 관리형에서 지원하고 고객 관리형에서는 지원하지 않는 기능으로 구분한다. 이러한 기능 차이와 저장소 운영 부담의 감소가 이번 솔루션에서 관리형 지식 기반을 기반 서비스로 선택한 이유다.

3. 질문 처리 흐름과 두 단계의 검색 판단

사용자의 질문은 Amazon Bedrock AgentCore 런타임에 호스팅된 에이전트로 전달되고, 에이전트의 추론 모델은 질문의 주제에 맞는 금융 또는 날씨 검색 도구를 선택한다. 선택된 호출은 MCP를 사용하는 AgentCore Gateway를 거쳐 해당 지식 기반의 AgenticRetrieveStream API로 전달된다. 이 API는 지식 기반 내부에서 질문을 하위 질의로 나누고 관리형 저장소를 반복 검색하며, 근거와 출처를 포함한 답변을 생성해 스트리밍으로 반환한다. 에이전트는 반환된 문맥이 충분한지 확인하고, 부족하면 다음 반복에서 다시 검색한 뒤 최종 답변을 작성한다. 따라서 지식 기반 사이의 선택은 에이전트가 담당하고, 선택된 지식 기반 안에서의 질의 분해와 검색은 AgenticRetrieveStream이 담당하는 두 단계 구조다.

4. 네 개의 CloudFormation 스택 구성

솔루션은 앞선 스택의 출력을 다음 스택에 연결하는 네 개의 AWS CloudFormation 스택으로 구성된다. 첫 번째 스택은 Amazon S3 버킷, 금융·날씨 관리형 지식 기반, 데이터 소스와 IAM을 만들고, 사용자 지정 리소스로 문서를 업로드하고 최초 동기화를 실행한다. 두 번째 스택은 AWS_IAM 인증과 MCP를 사용하는 AgentCore Gateway를 구성하며, 기본 지식 기반 커넥터로 각 지식 기반의 검색 도구를 노출하므로 이 연결을 위한 별도 Lambda 함수나 컨테이너가 필요하지 않다. 세 번째 스택은 Amazon ECR 저장소와 AWS CodeBuild 프로젝트를 생성해 OpenTelemetry 계측이 적용된 Strands 에이전트 이미지를 빌드하고, 런타임·로그·추적 전달 및 온라인 평가 설정을 마련한다. 네 번째 스택은 두 개의 Amazon CloudWatch 대시보드를 생성하며, 전체 구성은 관측과 지속 평가까지 동일한 템플릿 체인으로 재현하도록 설계된다.

5. 일곱 계층의 관측과 지표 생성 방식

관측 체계의 첫 번째 계층은 지식 기반별 검색 호출·오류·제한을 확인하고, 두 번째 계층은 수집 작업 상태와 문서별 처리 결과를 확인한다. 세 번째 계층은 참조 정답 없이 측정하는 활용도, 근거 기반 포괄도, 중복률로 검색 품질을 살피며, 네 번째 계층은 Gateway 도구 호출량과 지연 시간을 다룬다. 다섯 번째 계층은 OpenTelemetry 스팬 트리로 에이전트의 추론·행동 과정을 추적하고, 여섯 번째 계층은 세션 및 모델별 토큰 사용량을 보여준다. 일곱 번째 계층은 정확성, 충실성, 도구 선택, 응답 관련성 등의 평가 점수를 제공한다. 원문은 첫 번째·네 번째·다섯 번째 계층이 자동으로 생성되는 반면, 세 번째·여섯 번째·일곱 번째 계층은 실행용 노트북이 사용자 지정 지표로 게시한다고 구분하므로 모든 관측 지표가 같은 방식으로 수집되는 것은 아니다.

6. 실행 추적과 답변 품질 평가의 결합

원문은 운영 환경에서 에이전트가 답변을 반환한다는 사실만으로는 충분하지 않으며, 응답 지연·호출량·토큰 사용량과 검색 및 답변 품질을 지속적으로 확인해야 한다고 설명한다. AgentCore 런타임은 첫 호출부터 실행 단계에 OpenTelemetry 스팬을 자동으로 남겨, 추론 모델 호출과 도구 사용이 반복되는 과정을 관찰할 수 있게 한다. 실행 중 생성되는 스팬과 사용량 및 지표는 Amazon CloudWatch와 AWS X-Ray로 전달되며, 관측 계층과 온디맨드·지속 평가에 활용된다. 두 개의 대시보드는 이러한 신호를 제공하고, 런타임 스택에는 온라인 평가 설정도 포함된다. 이 구성은 검색 도구 계층의 속도와 신뢰성, 실제 에이전트 행동, 최종 답변의 품질을 서로 다른 관측 대상으로 다루면서 하나의 솔루션 안에서 함께 검토하도록 한다.

7. 금융·날씨 데이터를 분리한 설계 의도

예제 데이터는 약 198KB의 합성 Octank Financial 10-K PDF와 약 560KB의 실제 미국 의회조사국 토네이도 보고서 IF12695로 구성되며, 저장소의 data 디렉터리에 포함된다. 원문은 두 자료 묶음을 합성 자료라고 소개하는 표현도 사용하지만, 개별 설명에서는 날씨 보고서를 실제 공개 자료로 명시한다. 주제가 뚜렷하게 다른 자료를 별도 지식 기반에 넣는 목적은 에이전트가 질문에 맞춰 서로 다른 검색 도구 중 하나를 실제로 선택하게 하는 데 있다. 하나의 지식 기반에 데이터 소스 두 개를 넣으면 에이전트에는 도구 하나만 제공되고 자료별 신호가 합쳐지는 반면, 분리하면 KnowledgeBaseId를 기준으로 관측 결과를 구별할 수 있다. 관리형 수집에서는 Amazon Bedrock이 PDF 분석, 청크 분할, 임베딩과 인덱싱을 자동 처리하며, 제시된 수집 결과는 지식 기반마다 문서 하나가 인덱싱되고 실패가 없음을 보여준다.

8. 배포 사전 조건과 제공된 본문의 범위

배포 설명은 단일 스크립트 명령으로 솔루션을 구성할 수 있다고 소개한 뒤, 필요한 계정 권한과 모델 접근 조건을 제시한다. 요구 권한에는 Amazon Bedrock, AgentCore 런타임과 Gateway, IAM, CloudWatch, X-Ray, ECR, CodeBuild, S3, Lambda, CloudFormation이 포함되며, 검색 도구 연결에 별도 Lambda가 필요 없다는 설명과 전체 배포 권한 목록은 구분해서 읽어야 한다. 에이전트에 사용할 모델이 계정에서 이용 가능해야 하고 Amazon Bedrock 모델 접근도 활성화되어 있어야 하며, 기본 모델 식별자는 us.anthropic.claude-haiku-4-5-20251001-v1:0으로 제시된다. 그러나 제공된 본문은 CloudWatch Transaction Search라는 항목명에서 종료되어 해당 항목의 세부 요구사항은 확인할 수 없다. 실제 배포 명령과 스택 생성 확인 절차 역시 제공 범위에 없으므로, 이 요약에서 구체적인 실행 방법이나 배포 성공 여부를 확정할 수는 없다.

🧾 핵심 주장 / 시사점

• 에이전트의 지식 기반 선택과 지식 기반 내부 검색이 분리되어 있으므로, 실행 추적을 해석할 때 두 단계의 역할을 구분하는 것이 중요하다.
• 금융·날씨 지식 기반의 분리는 검색 경로 선택을 시연하는 동시에 자료별 운영·품질 신호가 합쳐지는 것을 방지하는 설계다.
• 관리형 서비스가 저장소 운영과 일부 계측을 자동화하더라도, 검색 품질·토큰 사용량·평가 점수의 사용자 지정 지표 게시 경로는 별도로 존재한다.

✅ 액션 아이템

• 금융·날씨 지식 기반 선택과 AgenticRetrieveStream 내부 반복 검색의 역할 구분 확인.
• 7개 관측 계층을 기준으로 운영 상태·토큰 사용량·답변 품질의 관측 범위 검토.
• 배포에 필요한 AWS 서비스 권한과 에이전트 모델 접근 확인 및 누락된 실제 배포 명령·확인 절차 확보.

❓ 열린 질문

• 금융·날씨 지식 기반 중 검색 대상을 선택한 결과는 7개 관측 계층에서 어떻게 확인할 수 있는가?
• 온디맨드 평가와 지속 평가는 답변 품질 검토에서 각각 어떻게 활용되는가?
• 제공된 본문에서 누락된 실제 배포 명령과 4개 AWS CloudFormation 스택의 확인 절차는 무엇인가?