AWS 서비스 파트너와 함께 구축한 타이거컴퍼니의 Amazon Bedrock 기반 문서 질의 챗봇 사례

타이거컴퍼니는 쉽게 일하는 방법을 고민하고 업무에 필요한 모든 서비스를 하나의 플랫폼에서 제공하는 SaaS 협업 전문기업입니다. 기업은 물론 공공기관까지 폭넓은 서비스를 제공하고 있으며 SaaS, 구축형, 하이브리드 방식까지 고객이 원하는 어떠한 방식도 수용 가능한 기술과 전문가들을 보유하고 있습니다.

최근 AI 기술들이 협업 툴에도 많은 시도가 이뤄지고 있으며 타이거컴퍼니도 RAG(검색 증강 생성, Retrieval-Augmented Generation)와 생성형 AI를 활용하여 기업의 데이터와 결합하고 조직과 개인의 업무를 혁신할 수 있는 AIDX (Artificial Intelligence Digital Transformation) 서비스를 2024년 하반기에 오픈할 예정입니다. 해당 AIDX 서비스는 전국 18개 시도의 지자체와 기업, 대학이 협력해 지역산업을 육성하고 일자리를 창출하며, 인재를 양성하는 지역상생발전 생태계인 지산학과 타이거컴퍼니의 현재 고객(누적 사용자 20만 이상)을 대상으로 하고 있습니다.

본 글은 타이거컴퍼니가 AWS 서비스 파트너사인 메가존클라우드와 함께 구축한 자연어로 질의하고 업로드한 문서에 기반한 답변을 하는 챗봇 서비스 프로젝트를 소개합니다. 그리고 Amazon Bedrock에 기반한 전체 아키텍처와 답변 품질 향상을 위해 데이터 전처리를 진행한 과정, 그리고 기술 선택 이유를 공유합니다.

솔루션 개요

타이거컴퍼니는 Amazon Bedrock과 Amazon SageMaker Studio를 활용하여 문서에 대한 전처리를 통해 문서로부터 텍스트를 추출하고, 이렇게 추출한 텍스트를 벡터로 임베딩하여 Amazon OpenSearch Service에 저장합니다. 고객이 문서로부터 검색하고 싶은 질문을 전달하면 해당 질문을 벡터화하고 저장되어 있는 텍스트와 비교하여 가장 적절한 내용을 가져옵니다. 아래 그림은 각각 챗봇 서비스의 흐름도와 전반적인 아키텍처를 보여줍니다.

그림 1: 챗봇 서비스 흐름도

그림 2: 전반적인 아키텍처

챗봇 형태의 서비스라는 점을 고려해 높은 사용량이 예상되었고, 증가하는 트래픽에 유연하게 대응하기 위해 Amazon Bedrock을 멀티 리전으로 호출하는 방안을 검토하게 되었습니다. 사용량에 따라 Provisioned Throughput을 고려할 수도 있으나 서비스 초기에는 사용량 예측이 어려워 유연하게 확장이 가능한 멀티 리전 호출을 선택하게 되었습니다. 따라서 Amazon Bedrock을 이용 가능한 N.Virginia (us-east-1) 리전과 Oregon (us-west-2) 리전에서 VPC Endpoint를 이용해도록 구성하였습니다. 이와 같은 확장을 위한 멀티 리전 구축을 신규 기능인 cross-region inference를 통해 쉽게 구현 및 운영할 수 있기 때문에 추후 적용을 고려하고 있습니다. 또한 서울 리전의 VPC와 VPC Peering을 통해서 안전하게 서울 리전의 API 서버에서 Amazon Bedrock 리전으로 프라이빗한 네트워크 통신이 이뤄질 수 있으므로, 보안적으로도 안전하게 통신할 수 있는 아키텍처 구성이 가능했습니다. 마지막으로, 질의를 실행할 애플리케이션 레이어는 일반적으로 많이 사용하는 3티어 아키텍처에 기반하여 설계되었습니다.

구현 상세

데이터 전처리

Amazon SageMaker Studio는 엔드 투 엔드 ML 개발을 위한 다양한 전용 도구를 제공하는 서비스입니다. 데이터 준비 및 전처리 과정부터 ML 모델 빌드, 훈련, 배포, 모니터링에 이르기까지 모든 과정을 수행할 수 있습니다. 생성형 AI를 활용한 챗봇을 만드는 과정에서 환각을 최소화하기 위해 RAG 기법을 고려하게 되었으며 구현을 위해 문서의 텍스트 데이터를 사전에 벡터 데이터베이스에 인덱싱을 해야 했습니다. 즉, 데이터 전처리 및 임베딩이 필요했습니다.

또한 데이터 전처리 및 임베딩은 챗봇의 답변 품질에도 큰 영향을 미칠 수 있기 때문에 해당 부분의 최적화를 위해 많은 테스트가 필요했습니다. 이러한 전처리 과정에서 SageMaker Studio를 활용하여 편리하게 전처리 결과를 확인하거나 VPC 내의 Amazon Bedrock의 임베딩 모델 및 LLM 모델과 OpenSearch 데이터베이스를 연결해서 테스트할 수 있었습니다.

특히 PDF 파일로부터 데이터를 추출하고 전처리하는 과정은, PDF 파일이 텍스트와 테이블 등 다양한 요소로 구성되어 있어 문서의 구조를 이해하고 데이터를 추출하는 데 난이도가 높고, PDF 파일의 전체 맥락을 파악하는 것도 어렵습니다. PyPDF, PyMuPDF, PDFPlumber 등 다양한 전처리 도구들이 존재하며 원하는 기능에 따라 도구를 선택하고 테스트하는 과정이 필요합니다. PyPDF는 PDF 파일을 전처리 하기 위한 오픈소스 모듈 중 하나이며, 다음과 같은 코드처럼 PyPDF를 활용하여 PDF 파일을 전처리하게 되었습니다.

Code :

import PyPDF2
import re

def extract_pdf_info(pdf_path):
    with open(pdf_path, 'rb') as file:
        pdf_reader = PyPDF2.PdfReader(file)
        num_pages = len(pdf_reader.pages)
        print(f"Total number of pages: {num_pages}")

        for page_num in range(num_pages):
            page = pdf_reader.pages[page_num]
            print(f"\nPage {page_num + 1}:")

            # Extract text
            text = page.extract_text()
            print(f"Text content (first 100 characters): {text[:100]}...")

            # Check for images
            if '/XObject' in page['/Resources']:
                xObject = page['/Resources']['/XObject'].get_object()
                for obj in xObject:
                    if xObject[obj]['/Subtype'] == '/Image':
                        print(f"Image found: {obj}")

            # Check for tables (this is a basic check and may not be accurate for all PDFs)
            if re.search(r'\b(table|tabular)\b', text, re.IGNORECASE):
                print("Possible table detected")

            # Get page size
            media_box = page.mediabox
            width = media_box.width
            height = media_box.height
            print(f"Page size: {width} x {height}")

if __name__ == "__main__":
    pdf_path = "./copy.pdf"
    extract_pdf_info(pdf_path)

실행결과 :

위와 같이 전처리하게 되면 텍스트 형식 외에도 첨부된 이미지, 페이지에 대한 정보들이 나오게 되며 해당 정보들을 통해 얻은 문서에 대한 인사이트를 기반으로 전처리 과정을 개선해나가게 됩니다. PDF 외에도 타이거컴퍼니의 고객사 중에는 공공기관 및 대학교가 있어 HWP 형식의 문서가 많이 존재했지만, 오픈소스 전처리 도구를 활용하여 HWP 파일에 대한 전처리르도 쉽게 진행할 수 있었습니다.

즉, 어떤 전처리 도구를 활용할지도 중요하지만 전처리 이후에 문서에 대한 전반적인 텍스트 및 추출된 데이터에 기반하여 문서 형식을 살펴 보며, 어떤 방식으로 전처리를 하고 청크를 구성해야 할지 고민하는 것이 필요합니다. 따라서 다루고자 하는 문서와 문서 내에서 추출된 데이터를 살펴보고 얻은 인사이트를 바탕으로 지속적인 테스트를 통해 데이터 품질을 높여나가는 것이 중요합니다.

이미지 OCR

위에서 살펴본 것처럼 PDF, HWP 등 문서라고 해도 텍스트 형태의 데이터만 존재하지 않습니다. 문서 내에는 표, 이미지와 같은 여러 형태의 데이터가 있으며 이미지 안의 텍스트를 추출하는 것이 필요하면 이미지 OCR 모델이 필요할 수 있습니다. 따라서 다음과 같은 OCR 도구를 검토해 볼 수 있습니다.

1. Amazon Textract

Amazon Textract는 스캔한 문서에서 텍스트, 필기, 레이아웃 요소 및 데이터를 자동으로 추출하는 기계 학습(ML) 서비스입니다. 영어 문서 및 다국어 문서 인식률이 높은 것으로 알려져 있으나 한국어 지원이 되지 않아 아쉽게도 이번 프로젝트에서는 다른 방법을 고려하게 되었습니다.

2. Upstage Document OCR

업스테이지(Upstage)는 한국의 인공지능(AI) 스타트업으로, 다양한 언어와 이미지 품질에서 높은 정확도와 범용성을 보장하는 Document OCR을 제공하고 있습니다. 특히 Upstage Document OCR은 AWS Marketplace에서 제공되고 있으며 빠른 기간 내의 프로젝트 완성을 위해 Upstage Document OCR을 고려하게 되었습니다. 프로덕션에서는 아래와 같이 Claude Sonnet을 활용해 OCR을 진행할 예정입니다.

3. Amazon Bedrock, Anthropic Claude Sonnet 3, 3.5

Amazon Bedrock의 Claude Sonnet 3과 3.5 모델은 멀티모달을 지원하기 때문에 이미지 혹은 표로부터 데이터를 추출할 수 있습니다. 다음은 Amazon Bedrock을 활용하여 문서의 표와 이미지로부터 어떻게 전처리 했는지 프롬프트와 결과를 포함한 예시입니다.

예시1 – 표 형식의 이미지

Prompt :

You're an expert in image analysis. This is an image of a table. Look at it, the top line is the column name, the bottom is the content.
For each line, you'll see 
<table>
column: value, column: value, column: value, column: value, ...
column: value, column: value, column: value, column: value, ...
column: value, column: value, column: value, column: value, ...
</table>
so that it all fits in one <table>.
Please take your time, think it through, and be thorough.

Result :

<table>
구분: 전국, '20년: 51,888, '25년: 51,448, '30년: 51,199, '35년: 50,889,
'40년: 50,193, '45년: 49,030, '50년: 47,359
구분: 대학 학령인구 (만 18-21세), '20년: 2,410, '25년: 1,888, '30년: 1,874, '35년: 1,723,
'40년: 1,176, '45년: 1,020, '50년: 1,237
구분: 비수도권 인구, '20년: 25,815, '25년: 25,276, '30년: 24,865, '35년: 24,455,
'40년: 23,915, '45년: 23,196, '50년: 22,273
</table>

예시2 – 도형 형식의 이미지

Prompt :

You're an expert in image analysis. In the image below, detail the relationship between each circle and arrow with a description. Take your time and think it through step-by-step. answer in korean. 
Example: 
<xml>
  <shapes>
    (circle) -> arrow (description) -> (circle)
    (circle) -> arrow (description) -> (circle)
    …
  </shapes>
  <description>description for detail</description>
</xml>

Result :

<xml>
    <shapes>
        (지방대학) -> 대학지원 (주문형 인력양성) -> (도시군)
        (도시군) -> 기업지원 (정책지원) -> (지역기업) 
        (지역기업) -> 일자리 제공 -> (지방대학) 
    </shapes>
     <description> 
        이 이미지는 지방대학, 도시군, 지역기업 간의 상호 관계를 보여줍니다. 지방대학은 도시군에 주문형 인력을 양성하여 제공하고, 도시군은 지역기업에 정책을 지원합니다. 지역기업은 다시 지방대학 졸업생들에게 일자리를 제공하는 순환 구조를 나타냅니다. 이는 주력산업 우수인재양성을 위한 협력 체계로 보입니다.
    </description>
 </xml>

위와 같이 간단한 프롬프트를 통해 표와 도형 형식의 이미지로부터 데이터를 추출할 수 있었으며, 더 높은 정확도와 응답 품질을 위해 프로젝트 이후에도 응답 품질을 관리하고 지속적인 테스트를 통해 개선해 나가는 노력이 필요합니다.

임베딩 모델

Amazon Bedrock에서 여러 임베딩 모델을 제공하고 있지만, 그중에서 Amazon Titan Text Embedding V2와 Cohere Embed Multilingual v3를 테스트하게 되었습니다.

1. Amazon Titan Text Embedding V2

Amazon Titan Text Embedding V2는 현재 Amazon Bedrock에서 사용할 수 있는 Amazon의 2세대 텍스트 임베딩 모델로, 검색 증강 생성(RAG)에 최적화되어 있습니다. 100개 이상의 언어와 코드에 대해 사전 훈련되어 있으며 다양한 언어를 지원하고, 다양한 사용 사례에 적합합니다.

2. Cohere Embed Multilingual v3

Cohere는 다양한 언어 모델 및 임베딩 모델을 만들어서 제공하는 회사로 Amazon Bedrock에서도 여러 모델을 사용할 수 있게 지원하고 있습니다. 다국어 임베딩 모델인 Embed Multilingual v3는 Amazon Bedrock에서 사용할 수 있을 뿐더러, 한국어도 지원하고 있습니다.

RAG는 임베딩을 사용해서 정보를 찾으며, 고품질의 임베딩 모델은 각 문서의 요점을 정확하게 파악할 수 있는 임베딩(또는 벡터)를 생성할 수 있습니다. 즉 더 좋은 성능의 임베딩 모델을 사용한다면, RAG가 LLM에 가장 관련성이 높은 정보를 검색하여 보다 정확하고 핵심적인 답변을 얻을 수 있게 도와줄 수 있습니다. 따라서 응답을 생성하는 모델에 대한 평가 뿐 아니라 임베딩 모델에 대한 평가도 지속적으로 할 필요가 있습니다. 관련하여 실제로 모델 평가를 위해 내부 사용자 테스트를 진행했고, 전반적으로 Titan Text Embedding V2의 검색 결과가 좀 더 좋다는 의견이 많아, Titan Text Embedding V2를 이번 프로젝트의 기본 임베딩 모델로 사용하게 되었습니다.

이와 같은 모델 응답에 대한 사람의 평가가 모델 선택에 도움이 되었기 때문에 추후에는 파운데이션 모델에 대한 평가를 진행할 수 있는 Amazon Bedrock Model Evaluation을 사용하는 것도 고려하고 있습니다.

기술 선택 이유

1. Amazon Bedrock 서비스와 Claude 3.5 Sonnet 모델을 선택한 이유

Amazon Bedrock은 AI21 Labs, Anthropic, Cohere, Meta, Stability AI 및 Amazon과 같은 선도적인 AI 회사의 고성능 파운데이션 모델(FM)을 API를 통해 사용할 수 있게 해주는 완전관리형 서비스입니다. 특히 다양한 최신 모델을 지속적으로 제공하고 있습니다. Llama 3.1, Mistral 2 Large 등 최신 모델이 빠르게 제공되고 있으며, 프로젝트를 진행하던 시기에는 Claude 3.5 Sonnet 모델이 출시되었고 Claude 3 Opus 가격의 5분의 1로 당시 LLM 모델 중에서도 뛰어난 성능을 보여주기도 했습니다. 앞으로도 계속 모델이 출시될 것이므로, 다양한 모델을 API 파라미터만 변경하여 이용 가능한 부분이 큰 장점이 될 거 같아 Amazon Bedrock을 선택하게 되었습니다.

이외에도 실제 개발 시에 직접 개발해야 하는 부분들을 많이 줄여주는 다양한 기능들을 지속적으로 업데이트하고 있다는 점도 선택에 큰 영향을 끼쳤습니다. Converse API와 같이 대화형 앱을 쉽게 구성 가능할 수 있도록 인터페이스를 제공해주거나, Bedrock Agents에서 대화의 히스토리를 보관할 수 있는 메모리 보존 및 코드 해석(Preview), Knowledge Bases for Amazon Bedrock에서 RAG 기반의 애플리케이션의 성능을 높일 수 있는 다양한 기능들(고급 구문 분석, 청킹 및 쿼리 재구성)이 추가되어 추후 생성형 AI를 활용하는 프로젝트에서 더 빠르고 쉽게 구축할 수 있게 되었습니다.

2. Amazon OpenSearch Service를 선택한 이유

Amazon OpenSearch Service는 확장성과 고가용성, 모니터링을 지원하는 완전 관리형 서비스입니다. OpenSearch의 경우, 이미 기존에 검색엔진으로도 이용하고 있었기 때문에 추가적으로 벡터 데이터베이스 운영 및 모니터링을 위해 학습해야 하는 러닝커브가 작았습니다. 또한 별도로 벡터 데이터베이스를 구성하지 않아도 되었기 때문에 운영 및 실제 비용적인 부담이 적어 OpenSearch를 벡터 데이터베이스로 활용하게 되었습니다.

정리 및 향후 계획

타이거 컴퍼니는 다음과 같은 단계로 프로젝트를 발전시킬 계획입니다:

프롬프트 엔지니어링 최적화: Amazon Bedrock의 파운데이션 모델을 사용하여 PDF와 같은 비정형 데이터를 효과적으로 처리할 수 있도록 프롬프트 엔지니어링 기법을 개선합니다. 이를 통해 사용자가 다양한 질의를 했을 때 더욱 정확하고 관련성 높은 답변을 제공할 수 있도록 시스템을 고도화합니다.
더 나은 Multi-Modal 문서 처리: 단일 텍스트 기반 문서 외에도 이미지, 표 등 다양한 형태의 데이터를 포함하는 Multi-Modal 문서에 대해 더 나은 RAG 기법을 적용할 수 있도록 Amazon Bedrock과의 통합을 강화합니다. 이를 통해 문서의 복잡한 정보를 처리하고 응답 정확도를 향상시킵니다.
실시간 피드백 시스템 구축: 사용자가 질의하는 내용에 실시간으로 응답할 수 있는 시스템을 구축하여, 사용자 경험을 개선하고 서비스의 신뢰성을 높이는 방향으로 발전시킬 계획입니다. 이를 통해 고객사의 피드백을 즉각 반영하고, 지속적으로 서비스 품질을 향상시킬 수 있는 기틀을 마련합니다.
지속적인 성능 모니터링 및 개선: 서비스 론칭 후에도 지속적인 성능 모니터링을 통해 AI 모델의 답변 정확도와 사용자 만족도를 평가하고, 이를 바탕으로 추가적인 개선 작업을 이어 나갈 예정입니다.

추가적으로, Amazon Bedrock를 사용하여 RAG에서의 데이터 전처리를 고민하고 있다면, Amazon Bedrock의 파운데이션 모델을 활용한 효과적인 PDF 파싱을 위한 프롬프트 엔지니어링 기법과 Amazon Bedrock으로 Multi Modal 문서에 대해 RAG 적용 하기 같은 자료를 참고하시길 바랍니다.

AWS 기술 블로그