Customizing your knowledge base on Amazon Bedrock for large and complex documents using Amazon Textract

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Textract로 복잡한 공과금 청구서를 전처리하고 Amazon Bedrock 지식 기반에 연결해, 원본 문서를 직접 사용하는 RAG의 정보 누락과 환각 문제를 줄이는 구축 방법을 설명한다.

📌 핵심 요약

• 고객 서비스팀이 원본 공과금 청구서를 RAG에 직접 입력했을 때 납부 기한·금액·계좌번호 누락, 환각, 문서 형식별 성능 편차가 발생했다.
• 제안한 방식은 Amazon Textract를 활용한 정보 추출에 데이터 정제·보강과 표의 라벨·태그 부여를 결합해 Amazon Bedrock이 활용할 문서를 준비한다.
• AWS CloudFormation 배포 스크립트는 Lambda 함수 2개, S3 버킷 1개, OpenSearch Serverless 클러스터 1개, Amazon Bedrock 지식 기반과 관련 역할·계층을 생성한다.
• S3의 raw_files에 업로드한 문서는 두 Lambda 함수를 거쳐 parsed_files와 parsed_kb_documents에 저장되며, 지식 기반 데이터 소스를 동기화한 뒤 Amazon Nova Micro로 질의를 시험한다.
• 운영 환경에서는 Amazon Bedrock Guardrails와 검색 문서에 대한 근거 검증을 권장하며, 원문은 응답 정확도나 처리 속도의 정량적 개선 수치를 제시하지 않는다.

🧩 주요 포인트

1. 원본 청구서에서 정보 누락과 환각 발생 → 검색·생성에 앞서 문서 추출과 정제 품질을 확보하는 것이 핵심이다.
2. CloudFormation 배포와 두 Lambda 함수의 문서 변환 연결 → 반복 가능한 인프라 구성과 업로드 이후의 자동 처리를 지원한다.
3. Amazon Nova Micro 질의 시험과 Guardrails·근거 검증 제시 → 기능 확인과 운영 시 출력 신뢰성 확보를 함께 다루지만, 개선 효과의 크기는 확인되지 않는다.

🧠 상세 정리

1. 복잡한 공과금 청구서와 고객 응대의 어려움

원문은 매달 수천 건의 공과금 청구서를 처리하는 고객 서비스팀이 여러 페이지로 구성된 복잡한 문서에서 필요한 정보를 빠르게 찾기 어렵다는 문제로 시작한다. 일정하지 않은 서식, 정보가 밀집된 표, 서로 다른 배치가 추출을 어렵게 만들고, 수작업으로 내용을 확인하는 과정은 응답 지연과 청구 오류, 고객 불만으로 이어진다. 문의 범위도 청구 내역뿐 아니라 사용량, 납부, 고객 서비스 전반에 걸쳐 있어 문서의 일부 내용만 추출해서는 충분하지 않다. 문서량이 증가할수록 이러한 비효율이 누적되므로, 글은 복잡한 PDF와 이미지의 내용을 분석하고 관련 표에 태그를 부여해 문서에 질의하는 방식을 구축 목표로 제시한다.

2. 원본 문서를 직접 투입한 RAG의 한계

고객은 처음에 공과금 청구서를 원본 상태로 RAG에 입력해 필요한 정보를 얻으려 했지만, 모델이 중요한 내용을 놓치거나 잘못된 답변을 생성하는 문제를 겪었다. 구체적으로 납부 기한, 납부 금액, 계좌번호처럼 응대에 필요한 항목이 누락됐고, 일부 답변에는 부정확하거나 질문과 관련 없는 정보가 포함됐다. PDF, DOCX, TXT, HTML, XLSX처럼 입력 형식이 다양하다는 점도 문서 유형별 성능 편차의 원인으로 제시된다. 이 사례에서 도출한 요구사항은 단순한 문서 적재를 넘어, 청구서 내용을 먼저 추출하고 보강해 계좌번호·청구 내역·납부 안내를 모델이 안정적으로 활용할 수 있게 만드는 것이다.

3. 문서 형식과 전처리 접근

원문은 지원 대상 파일 형식으로 PDF, DOCX, TXT, HTML, XLSX, PNG를 열거하고, 각 형식에서 텍스트나 표 데이터를 추출하는 작업을 설명한다. PDF는 여러 페이지와 복잡한 배치 및 삽입 이미지, DOCX는 표와 삽입 객체, HTML은 태그 내부의 구조화된 정보, XLSX는 셀 내용과 표 데이터가 설명의 대상이다. 이어 Amazon Textract를 활용한 추출에 정제와 보강을 결합해 불필요한 정보와 잡음을 줄이고, 관련 내용을 RAG가 사용할 수 있도록 준비하는 접근을 제안한다. 추출 데이터에 라벨과 태그를 부여하는 과정도 포함되며, 여러 파일 형식을 처리하는 목적은 고객 질문에 필요한 내용을 모델이 더 정확하게 파악하도록 입력을 개선하는 데 있다.

4. CloudFormation을 통한 인프라 배포

배포 절차는 GitHub 저장소를 복제한 뒤 custom-knowledge-base 디렉터리로 이동하고, bash custom_kb_deployment_setup.sh 명령을 실행하는 방식으로 제시된다. 이 셸 스크립트가 AWS CloudFormation 스택을 생성하고 솔루션에 필요한 의존 리소스를 배포하므로, 문서 처리와 지식 기반 구성에 필요한 인프라를 함께 준비할 수 있다. 생성 목록에는 Lambda 실행 역할과 계층, Lambda 함수 2개, S3 버킷 1개, OpenSearch Serverless 클러스터 1개, Amazon Bedrock 지식 기반과 해당 지식 기반용 IAM 역할이 포함된다. 원문은 이러한 배포 방식의 의미를 서로 다른 환경에서도 일관되고 반복 가능한 인프라를 구성하는 데 두며, 배포 완료 후에는 문서 업로드와 지식 기반 설정을 이어서 수행하도록 안내한다.

5. S3 업로드에서 지식 기반용 문서까지

스택 배포가 끝나면 S3 콘솔에서 document-<stack-name>-<partial-stack-id> 형식으로 생성된 버킷을 찾아 raw_files 폴더를 만들고, 저장소에서 제공하는 공과금 청구서를 업로드한다. 파일 업로드는 document-parser Lambda 함수를 실행하는 계기가 되며, Amazon Textract 작업이 원본 파일을 처리하고 그 결과를 parsed_files 폴더에 저장한다. 이후 두 번째 Lambda 함수가 처리된 파일을 TXT 형식으로 변환하고, 최종 결과는 parsed_kb_documents 폴더에 기록된다. 이 흐름은 원본 업로드부터 지식 기반에 사용할 문서 생성까지의 변환을 자동으로 연결하며, 사용자가 질문하기 전에 청구서 내용을 추출하고 가공하는 단계가 존재함을 보여준다.

6. 지식 기반 동기화와 질의 시험

문서 변환 이후에는 Amazon Bedrock 콘솔의 Knowledge Bases에서 새로 생성한 지식 기반을 선택하고, 데이터 소스에서 Sync를 실행한 뒤 동기화가 완료될 때까지 기다린다. 시험 단계에서는 해당 지식 기반의 Text Knowledge Base를 선택하고 설정에서 Amazon Nova Micro 모델을 지정한 다음, 오른쪽 입력창에 공과금 청구서 관련 질문을 입력한다. 원문은 모델의 AWS 리전별 제공 여부를 별도 지원 문서에서 확인하도록 안내하므로, 모델 선택은 사용 리전에서의 가용성을 함께 확인하는 절차로 제시된다. 사용자 지정 지식 기반을 사용한 경우와 사용하지 않은 경우의 출력 그림이 제시되지만, 제공된 본문에는 정확도나 응답 시간의 수치 비교가 없어 개선 정도를 정량적으로 판단할 근거는 없다.

7. 운영 환경의 출력 신뢰성 확보

원문은 구축과 시험 절차를 설명한 뒤, RAG를 운영 환경에 배포할 때 신뢰할 수 있는 출력을 위한 보호 장치를 적용해야 한다고 강조한다. Amazon Bedrock Guardrails는 유해 콘텐츠 필터링, 금지 주제 차단, 입력과 출력의 민감 정보 가림을 설정할 수 있는 기능으로 소개된다. 여기에 모델의 답변이 검색된 원본 문서로 뒷받침되는지를 평가하는 근거 검증을 더해 환각을 탐지하고 줄이는 접근을 권장한다. 이러한 통제는 운영 시 정확성과 규정 준수, 사용자 신뢰를 유지하기 위한 권고이며, 문서 전처리와 별도로 출력 단계의 신뢰성을 다루는 요소로 설명된다. 다만 앞서 제시한 배포 스택에 이 통제들이 자동으로 활성화된다고 명시하지는 않는다.

8. 활용 가치와 향후 확장 방향

결론은 이 구성을 여러 AWS 서비스를 결합한 지능형 문서 처리·질의 시스템의 출발점으로 제시하며, 공과금 청구서처럼 구조화된 문서를 대량으로 다루는 조직에 특히 유용할 수 있다고 설명한다. CloudFormation을 통한 반복 가능한 배포와 원본 업로드에서 지식 기반 연결까지 이어지는 자동 처리 흐름은 대규모 문서 집합을 효율적으로 다룰 가능성을 보여주는 근거로 제시된다. 기대하는 가치는 정보 추출·처리·질의를 간소화해 운영 효율과 더 정교한 데이터 분석을 지원하는 것이며, 실제 개선 폭을 보여주는 측정 결과는 본문에 포함되지 않는다. 향후 확장 후보로는 처리 문서 종류 확대, 추가 AWS 서비스와의 통합을 통한 복잡한 분석, 지식 기반에 쉽게 접근할 수 있는 사용자 친화적 화면 개발이 언급된다.

🧾 핵심 주장 / 시사점

• 이 사례의 핵심은 모델 변경보다 문서 입력의 개선에 있다. 누락과 환각을 관찰한 뒤 추출·정제·태그 부여를 추가하는 방향으로 해결책이 전개된다.
• 문서 업로드와 변환은 자동으로 연결되지만, 제시된 사용 절차에는 지식 기반 데이터 소스의 동기화가 별도 단계로 포함된다.
• 원문은 구축 가능한 예제와 운영 보호 장치를 제시하지만, 정량 평가가 없어 정확도 향상이나 처리 효율의 크기까지 입증한 사례로 해석할 수는 없다.

✅ 액션 아이템

• 원본 청구서의 납부 기한·금액·계좌번호 누락을 기준으로 Amazon Textract 추출과 데이터 정제·보강 결과 확인.
• raw_files에서 parsed_kb_documents까지 문서 변환과 데이터 소스 동기화를 수행한 뒤 Amazon Nova Micro 질의 시험.
• 운영 환경의 Amazon Bedrock Guardrails와 검색 문서에 대한 근거 검증 적용 검토.

❓ 열린 질문

• Amazon Textract 전처리 이후 납부 기한·금액·계좌번호 누락과 환각은 얼마나 줄어드는가?
• 두 Lambda 함수를 거치는 문서 변환과 지식 기반 동기화에 소요되는 시간은 어느 정도인가?
• Amazon Bedrock Guardrails와 검색 문서에 대한 근거 검증은 운영 환경에서 출력 신뢰성 확보에 얼마나 기여하는가?