Query claims in natural language with Amazon Bedrock Knowledge Bases

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock Knowledge Bases와 AgenticRetrieveStream을 이용해 분산된 보험 청구 문서를 검색하고, 반복 검색·메타데이터 필터·근거 검증을 거쳐 출처가 표시된 자연어 답변을 구성하는 합성 데이터 기반 구현 안내다.

📌 핵심 요약

• 보험 청구 답변은 손해사정 기록, 수리 견적, 경찰 보고서, 지급 내역과 첨부 문서에 흩어져 있으며, 수정 견적이나 취소된 잠정 지급처럼 서로 대체되거나 충돌하는 기록 중 현재 유효한 근거를 식별해야 한다. 규제 대상인 청구 업무에서는 답변을 원문에 근거해 작성하고 인용을 제공해야 한다.
• Amazon Bedrock Knowledge Bases는 Amazon S3의 문서와 메타데이터를 수집하고 파싱·청킹·임베딩·벡터 저장을 관리한다. AgenticRetrieveStream은 질문을 하위 질의로 나누고 maxAgentIteration 한도 내에서 근거가 충분해질 때까지 검색을 반복하며, Amazon Bedrock Guardrails의 문맥적 근거 검사는 검색 기록이 뒷받침하지 않는 답변을 차단한다.
• 예제는 실제 고객의 운영 배포가 아닌 합성 청구 데이터로 구성된다. 구현에는 Amazon Bedrock과 Amazon S3에 대한 IAM 권한, 기반 모델 접근 권한, 지원 AWS 리전, 해당 API를 지원하는 Boto3와 S3 버킷이 필요하며, 예제 리전은 US West (Oregon), us-west-2다.
• 청구별 문서에는 .metadata.json 파일을 연결하며, claim_id·claim_type·status·amount·date_filed 등의 속성으로 검색 범위를 제한한다. date_filed는 YYYYMMDD 정수, amount는 비교 가능한 단일 금액으로 저장하고 준비금·지급액·보류액은 문서 본문에서 구분한다. 메타데이터 파일은 10 KB 이하여야 하며, 실제 PII나 보호 대상 건강정보는 필요한 통제와 승인 없이 넣지 않아야 한다.
• 관리형 지식 베이스와 S3 데이터 소스를 생성한 뒤 수집 작업을 실행하고, 문서가 추가되거나 수정되면 다시 동기화한다. AgenticRetrieveStream 요청은 대화 메시지, 최대 5개 지식 베이스, 지식 베이스별 1–100개의 검색 결과 한도와 계획 설정을 포함한다. generateResponse=True이면 자연어 답변을 생성하며, traceEvent·responseEvent·result로 실행 추적, 점진적 답변, 최종 검색 결과와 인용을 전달한다.

🧩 주요 포인트

1. 기록 충돌과 인용 의무 → 검색된 문서 중 현재 유효한 견적·지급·상태를 판별하고 답변의 출처를 추적할 수 있어야 한다.
2. 관리형 문서 처리와 반복 검색 → 저장·검색 기반 구축 부담을 줄이면서 복합 질문을 처리하되, maxAgentIteration과 검색 결과 한도가 근거 수집 범위를 제한한다.
3. 메타데이터의 자료형·검색 범위와 문서 동기화 → 금액·기간 조건의 정확성과 검색 근거의 최신성은 데이터 표현 및 수집 작업에 달려 있다.

🧠 상세 정리

1. 분산된 청구 기록과 유효한 근거 판별

보험 청구에 관한 답은 손해사정 담당자의 일지, 수리 견적, 경찰 보고서, 지급 장부와 스캔 첨부 자료에 흩어져 있어 하나의 검색 가능한 필드에서 바로 찾기 어렵다. 보험계약자는 CLM-100482의 견적 승인 여부와 수표 발행 시점을 묻고, 상담원은 고객이 기다리는 동안 다른 담당자에게 전화를 넘기지 않고 빠르고 정확하게 답해야 한다. 손해사정 담당자는 지난달 접수된 10,000달러 초과의 미종결 자동차 청구와 각 청구의 남은 작업을 함께 확인하는 복합 질문을 제기한다. 수정 견적이 이전 견적을 대체하거나 잠정 지급이 나중에 취소될 수 있으므로, 관련 문서를 찾는 것과 함께 어느 기록이 현재 판단을 지배하는지 식별해야 한다. 원문은 청구 업무가 규제 대상이라는 점을 들어 모든 답변에 문서 근거와 인용이 필요하며, 상담원은 출처를 확인하고 감독자는 답변 도출 과정을 감사할 수 있어야 한다고 설명한다.

2. 관리형 RAG와 에이전트형 검색의 구조

RAG는 검색된 문서를 이용해 모델 응답의 근거를 제공하며, Amazon Bedrock Knowledge Bases는 문서를 대상으로 하는 완전 관리형 RAG 기능이다. 수집 경로에서는 PDF·Word·텍스트 청구 문서와 대응하는 메타데이터 파일이 Amazon S3에 저장되고, 수집 작업이 이를 지식 베이스와 동기화한다. 지식 베이스는 문서를 파싱하고 청크로 나눈 뒤 임베딩을 생성해 메타데이터와 함께 관리형 벡터 저장소에 색인한다. 검색 경로에서는 애플리케이션이 질문, 대화 이력과 선택적 메타데이터 필터를 AgenticRetrieveStream에 보내면, 기반 모델이 하위 질의를 만들고 maxAgentIteration 한도 안에서 근거가 충분해질 때까지 검색을 반복한다. 이어 Amazon Bedrock Guardrails의 문맥적 근거 검사가 검색 기록으로 뒷받침되지 않는 답변을 차단하고, 서비스는 답변·추적 이벤트·인용을 스트리밍해 애플리케이션이 도착하는 대로 표시할 수 있게 한다.

3. 합성 데이터 예제의 범위와 사전 조건

이 글은 합성 청구 기록을 사용하는 기술 구현 안내이며, 실제 고객의 운영 환경에 배포된 사례를 설명하지 않는다. 구현을 시작하려면 Amazon Bedrock과 Amazon S3를 사용할 IAM 권한이 있는 AWS 계정, Amazon Bedrock에서 활성화된 기반 모델 접근 권한, 청구 문서와 메타데이터를 저장할 S3 버킷이 필요하다. 선택한 기반 모델과 Amazon Bedrock Knowledge Bases를 모두 지원하는 AWS 리전을 사용해야 하며, 예제는 US West (Oregon)의 us-west-2를 기준으로 작성되어 있다. 원문은 배포 전에 리전별 지원 모델을 확인하고, 자격 증명이 설정되어 있으며 사용 API를 지원하는 버전의 AWS SDK for Python인 Boto3를 준비하도록 안내한다. Python과 기본 RAG 개념에 대한 이해도 전제로 제시되므로, 설명된 구성의 적용 가능성은 권한·모델 접근·리전 지원·SDK 조건을 충족하는지에 달려 있다.

4. 청구 문서와 메타데이터 파일의 연결

문서 준비 단계에서는 청구마다 하나의 문서를 Amazon S3에 저장하며, 지식 베이스가 PDF 손해사정 보고서, Word 서신과 텍스트 메모를 직접 읽으므로 원래 파일 형식을 유지할 수 있다. 검색 필터에 사용할 속성은 문서 이름 뒤에 .metadata.json을 붙인 별도 파일에 저장하며, CLM-100482.pdf에는 CLM-100482.pdf.metadata.json이 대응한다. 예제 메타데이터는 claim_id가 CLM-100482, claim_type이 auto, status가 open, date_filed가 20260709, amount가 14250인 청구를 나타낸다. 같은 예제에는 region, 담당 손해사정인과 보험계약자, 보험증권·고객·가구 식별자, 문서 유형, 보험사, 구상권 행사 및 소송 여부와 복잡도 등급도 포함된다. 합성 기록의 증거 색인은 더 최신 버전으로 대체된 팩스 초안을 식별하며, 문서의 현재 예상 총비용과 파일 관리 정보는 답변에서 참조할 근거를 해석하는 데 사용된다.

5. 필터 자료형, 금액 의미와 민감정보 제약

메타데이터는 문자열·숫자·불리언의 단일 값으로 구성되며, 각 값의 자료형에 따라 사용할 수 있는 필터가 달라진다. claim_id는 단일 청구 조회의 equals 조건에, claim_type은 업무 분야의 equals 또는 in 조건에, status는 진행 중 업무의 in 조건에 활용되며, region과 customer_id는 세션에 따른 검색 범위 제한에 사용된다. date_filed는 날짜 문자열이 아닌 YYYYMMDD 정수로 저장해야 숫자 비교를 통해 지난달 접수 같은 기간 조건을 표현할 수 있고, amount는 수치 범위 비교가 가능하도록 비교 가능한 하나의 금액만 담아야 한다. 준비금은 예상 청구 비용을 위해 확보한 돈이고 보류액은 일시적으로 지급을 유보한 금액이므로, 준비금·지급액·보류액은 문서 본문에 남겨 각 명칭과 의미를 분명히 유지한다. 메타데이터 파일의 크기 한도는 10 KB이며, 원문은 합성 데이터 예제에 실제 개인식별정보나 보호 대상 건강정보를 넣으려면 필요한 통제와 승인이 선행되어야 한다고 명시한다.

6. 관리형 지식 베이스 생성과 수집 동기화

지식 베이스는 bedrock-agent 클라이언트로 생성하며, knowledgeBaseConfiguration.type과 embeddingModelType을 모두 MANAGED로 설정한다. 이 구성에서는 Amazon Bedrock이 임베딩 모델을 선택하고 운영하므로 별도의 벡터 저장소 설정이 필요하지 않으며, 예제 지식 베이스 이름은 insurance-claims-kb다. roleArn으로 지정하는 서비스 역할은 S3 버킷 읽기와 관리형 임베딩 모델 사용 권한을 제공하고, 고객 관리형 AWS KMS 키로 벡터 저장소를 암호화하려면 serverSideEncryptionConfiguration에 키 ARN을 전달한다. 이어 S3 버킷을 데이터 소스로 연결하고 inclusionPrefixes를 claims/로 지정해 해당 경로의 문서로 수집 범위를 제한한다. start_ingestion_job은 문서 파싱·청킹·임베딩·색인을 수행하며, 문서가 추가되거나 변경될 때 다시 실행해야 검색 색인이 동기화되고 get_ingestion_job 또는 Amazon Bedrock 콘솔에서 완료 상태를 확인할 수 있다.

7. AgenticRetrieveStream 요청과 검색 한도

문서 수집이 끝나면 bedrock-agent-runtime 클라이언트의 AgenticRetrieveStream을 호출하며, 요청은 messages, retrievers와 agenticRetrieveConfiguration이라는 세 부분으로 구성된다. messages에는 user 또는 assistant 역할과 content.text를 가진 대화 턴을 넣고, retrievers에는 최대 5개의 지식 베이스를 지정하면서 각 지식 베이스의 메타데이터 필터와 maxNumberOfResults를 설정할 수 있다. 검색 결과 한도는 1–100이며, 원문은 여러 청구에 걸친 질문에서는 이 한도를 늘리도록 안내한다. 계획 모델은 foundationModelType을 MANAGED로 설정해 서비스 모델을 사용하거나 CUSTOM과 모델 ARN을 지정해 특정 모델을 선택하고, maxAgentIteration으로 계획과 검색의 반복 횟수를 제한한다. CLM-100482의 상태를 묻는 예제는 MANAGED 모델과 maxAgentIteration=5를 사용하며, generateResponse=True를 지정해 검색 결과를 바탕으로 자연어 답변을 생성한다.

8. 스트리밍 이벤트, 인용과 제공 자료의 한계

AgenticRetrieveStream의 응답은 response의 stream을 순회하면서 처리하며, 원문은 traceEvent, responseEvent와 result라는 세 가지 이벤트 유형을 설명한다. traceEvent는 계획, 검색, 전체 문서 확장, 가드레일 동작, 상태와 단계별 하위 질의를 보고하므로 검색 계획과 실행 과정을 확인할 수 있다. responseEvent는 점진적으로 생성되는 답변 텍스트를 제공하고, result는 중복이 제거된 검색 결과와 generateResponse=True일 때의 완성된 답변 및 인용을 포함한다. 각 인용은 답변의 일부를 원본 청구 문서와 연결하며, 소개된 처리 방식은 답변 조각을 도착하는 대로 표시하고 최종 결과를 인용 표시에 활용하도록 보관하는 것이다. 다만 제공된 source_body는 이 반복문 코드의 시작 부분에서 끊겨 있으므로, 다중 턴 후속 질문과 구체적인 필터·가드레일 구현은 도입부에서 제시된 기능 범위까지만 확인할 수 있고 이후 상세 코드는 이 자료만으로 검증할 수 없다.

🧾 핵심 주장 / 시사점

• 청구 문서를 검색했다는 사실만으로 답변의 정확성이 확보되지는 않는다. 이전 견적이나 취소된 지급이 함께 존재할 수 있어, 현재 유효한 기록을 판별하는 일이 인용 제공과 함께 중요하다.
• 관리형 지식 베이스는 문서 처리와 벡터 저장 운영을 맡지만, 날짜·금액의 의미를 일관되게 표현하고 변경된 문서를 재수집하는 책임까지 없애지는 않는다.
• 추적 이벤트와 인용은 서로 다른 검증 정보를 제공한다. 전자는 계획과 검색 과정을 보여주고, 후자는 답변의 각 부분이 어떤 청구 문서에 근거하는지 확인하게 한다.

✅ 액션 아이템

• claim_id·claim_type·status의 검색 범위와 date_filed의 YYYYMMDD 정수 형식, amount의 단일 금액 기준, 10 KB 메타데이터 한도 확인.
• 청구 문서 추가·수정 시 Amazon S3 수집 작업을 다시 실행하고 지식 베이스 동기화 완료 여부 확인.
• AgenticRetrieveStream의 maxAgentIteration과 검색 결과 한도를 질문 범위에 맞춰 검토하고, 인용 및 Amazon Bedrock Guardrails의 근거 검증 동작 확인.

❓ 열린 질문

• 수정 견적이나 취소된 잠정 지급이 충돌할 때 현재 유효한 기록을 어떤 기준으로 판별할 것인가?
• 여러 청구를 다루는 질문에서 maxAgentIteration과 1–100개의 검색 결과 한도가 필요한 근거를 확보하기에 충분한가?
• 청구 문서가 추가되거나 수정될 때 Amazon S3 수집 작업을 언제 다시 실행해 검색 근거의 최신성을 유지할 것인가?