HAQM Bedrock기반에서 Contextual Retrieval 활용한 검색 성능 향상 및 실용적 구성 방안

개요

인공지능 기술의 발전과 함께 대규모 언어 모델(LLM)의 성능 향상을 위한 다양한 방법들이 연구되고 있습니다. 그 중에서도 Retrieval Augmented Generation (RAG)은 외부 지식을 활용하여 모델의 응답 능력을 크게 개선하는 주요 기술로 주목받고 있습니다. RAG는 사용자의 질문에 관련된 정보를 외부 데이터베이스에서 검색하고, 이를 프롬프트에 추가하여 더 정확하고 맥락에 맞는 응답을 생성하는 방식으로 작동합니다.
하지만 기존의 RAG 솔루션들은 정보를 인코딩하는 과정에서 맥락을 제거하여, 종종 관련 정보를 효과적으로 검색하지 못하는 한계를 보였습니다. 이러한 배경에서 Anthropic은 2024년 하반기에, “Introducing Contextual Retrieval”이라는 제목의 기술 보고서를 통해 RAG의 검색 단계를 획기적으로 개선하는 새로운 방법을 소개했습니다.
이 블로그에서는 Anthropic이 발표한 “Contextual Retrieval” 기술과 실무적인 접근방안에 대해서 다뤄보고자 합니다. 이 블로그를 통해서 아래와 같은 사항들을 기대해 볼 수 있습니다.

Retrieval 정확성을 향상시키는 방법에 대한 이해를 높일 수 있습니다.
이 기술을 실무에 적용할 때 고려해야 할 추가적인 사항들을 파악할 수 있습니다.
AWS 환경에서 이 기술을 구현하고 활용하는 방법에 대해 알아볼 수 있습니다.
Bedrock 프롬프트 캐싱을 통해서 비용 효과적인 Contextual Retrieval 아키텍처 구성이 가능합니다.

이제 Contextual Retrieval 기술의 세부 내용과 그 잠재적 영향, 그리고 실제 구현 방법에 대해 더 자세히 살펴보겠습니다.

Contextual Retrieval: 배경과 기본 개념

배경: Gen AI를 이용한 Q&A 시스템

Gen AI의 기술이 발전됨에 따라서, Gen AI가 많은 부분들을 학습해서, 더 많고 정확한 정보를 제공해 주고 있습니다. 하지만, 아무리 똑똑한 Gen AI라고 할 지라도, 기업이 자체적으로 보유한 정보에 대해서는 Gen AI가 해당 내용을 알 수가 없어서 답변을 할 수가 없습니다. 이런 경우에는, Gen AI에게 질문을 할 때, 프롬프트로 추가적으로 고려해야 정보들을 질문의 컨텍스트로 전달해 줄 수 있습니다. 하지만, 프롬프트를 통해서 컨텍스트를 전달하는 방식에도 한계는 존재합니다. 그 이유는 Gen AI의 경우에는 한번에 프롬프트로 입력할 수 있는 토큰 사이즈가 정해져 있습니다. 이 블로그를 작성하는 시점 기준으로 Anthropic의 Claude 모델의 경우에는 최대 입력 가능한 토큰 수는 200,000로 제한되어 있습니다. 결국, 200,000 토큰이 넘는 정보는 컨텍스트로 Gen AI로 전달할 수 없다는 의미입니다.

RAG의 필요성과 한계

이러한 입력 토큰의 한계를 극복하기 위해서, 일반적으로는 Retrieval Augmented Generation (RAG) 기법을 이용합니다. 이 기법은 기본적으로 입력 토큰의 한계를 극복하기 위해서, Vector Database를 이용해서 컨텍스트를 분할 저장해 놓은 다음, 질문에 해당하는 컨텍스트를 질문이 들어올 때마다 조회해서 답변하는 방식입니다. 이런 방식을 사용하게 되면, 매우 큰 컨텍스트라고 할 지라도 Vector DB가 수용할 수 있을 만큼의 많은 데이터를 저장해 놓고 답변을 수행하도록 유도할 수 있습니다.

하지만, RAG에도 다음과 같은 한계가 있습니다:

컨텍스트 손실: RAG시스템에서 Vector DB에 정보를 저장하는 시점은, 질문이 제공되기 이전 시점입니다. 그리고 사전에 저장되는 정보의 사이즈가 크기 때문에, 해당 정보를 잘라서(청킹)해서 저장합니다. 그러다보니, 사용자가 질의하는 질문과 독립적으로 처리하여 정보를 잘라서 저장하는 성격으로 인해서, 사용자의 질문에 맞는 컨텍스트 형태로 답변이 제공되지 않는 경우들이 종종 발생합니다.
청크의 독립성: 문서를 작은 단위(청크)로 분할하는 과정에서 각 청크는 독립적인 정보 단위가 되어, 전체 맥락을 이해하기 어려워질 수 있습니다. 해당 전체 문서의 컨텍스트가 맞는 정보로 답변이 될려면, 모든 청크를 순서대로 연결해서 해당 정보를 전체 맥락에서 파악해야만 해당 정보를 이해할 수가 있습니다. 하지만, RAG에서는 개별 청크들을 독립적으로 처리한 다음에 조합하여 답변하기 때문에 답변의 정확성이 떨어질 수 있는 부분이 발생할 수 있습니다.

예를 들어 원본 청크가 “회사의 수익은 전 분기 대비 3% 증가했습니다.” 일 때, 이 정보만으로는 어느 회사인지, 어떤 시기인지 알 수 없어 정확한 검색과 활용이 어렵습니다.

Contextual Retrieval의 제안

이러한 문제를 해결하기 위해 Anthropic은 “Contextual Retrieval”을 제안합니다. 이 방법의 핵심은 각 청크에 맥락 정보를 추가하는 것입니다. 이 방식을 컨텍스트 청크 프리펜딩(Chunk Prepending)이라고 합니다. 아래와 같은 청크를 통해서 예를 들어보겠습니다.:

원본 청크: “회사의 수익은 전 분기 대비 3% 증가했습니다.”
컨텍스트 추가 후의 청크: “이 정보는 ACME 기업의 2023년 2분기 SEC 보고서에서 발췌되었습니다. 이전 분기의 수익은 3억 1400만 달러였습니다. 회사의 수익은 전 분기 대비 3% 증가했습니다.”

이렇게 컨텍스트가 추가된 청크를 통해서 RAG를 구성하게 되면, 전체적인 맥락을 이해하면서 답변하는데, 큰 도움을 줄 수가 있습니다. 이렇게 전체적인 맥락을 이해하는 컨텍스트를 어떻게 추가할 수 있는지를 설명하겠습니다.

Gen AI를 이용해서 컨텍스트 생성

특정 청크를 이용해서 답변을 수행하는데, 필요한 정보는 각 청크가 포함하고 있는 맥락에 따라서, 달라질 수 있습니다. 그래서 각 청크별로 답변에 필요한 컨텍스트를 만들어내는 과정이 필요합니다. 그리고 이러한 정보는 아래 그림과 같이 Gen AI를 통해서 만들어내도록 유도할 수 있습니다.

이 과정에서 프롬프트를 통해서 청크에서 원하는 정보와 전체적인 맥락을 고려하는 컨텍스트를 만들어 내도록 유도할 수 있습니다. 이러한 컨텍스트를 또한 “situated context”라고 합니다. Anthropic에서는 아래와 같은 프롬프트를 통해서 “situated context”를 각 청크별로 만들어 낼 수 있다고 하고 있습니다.

<document> 
{{WHOLE_DOCUMENT}} 
</document> 
Here is the chunk we want to situate within the whole document 
<chunk> 
{{CHUNK_CONTENT}} 
</chunk> 
Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else.

또한, 이러한 과정을 모든 청크에 대해서 수행해야 하므로, 응답속도가 빠르고, 비용이 저렴한 Gen AI가 필요합니다. Anthropic은 Claude Haiku가 이러한 과정에서 사용할 수 있는 최적의 Gen AI로 권고하고 있습니다. 또한, “전체 문서”(Whole document)의 크기가 200,000 토큰 보다 작다면, 프롬프트 캐시를 사용해서, 컨텍스트로 입력되는 프롬프트 토큰 사용 비용도 감소시키고, LLM 응답시간도 빠르게 개선할 수 있습니다.

최종 Contextualized 청크

이렇게 “Situated Context”를 원본 청크에 프리펜딩하여 최종 Contextualized Chunk를 생성합니다.

검색 정확성을 높이기 위해서 최적으로 권고하는 전체 아키텍처

Anthropic은 “Contextual Retrieval”이 높은 효율로 동작하기 위해서는 Contextualized Chunk를 생성하는 것이에도 효과적으로 사용할 수 있는 여러가지 기법들을 제공하였고, 이러한 부분들을 종합적으로 고려하여 최적으로 권고하는 아키텍처를 제시하였습니다.

그림 출처: Anthropic Contextual Retrieval

여기에서 언급하는 주요 요소들을 살펴보면 다음과 같습니다.

청크 경계 (Chunks Boundary): 문서를 적절한 크기의 청크로 분할 및 청크 크기, 경계, 중복 범위 최적화
컨텍스트 생성 (Context Generation): 각 청크에 맞춤형 컨텍스트 추가 및 도메인 특화 프롬프트 사용 가능. 프롬프트 캐싱을 통해서 반복적으로 입력되는 컨텍스트에 대한 프롬프트 토큰 비용을 획기적으로 감소
Contextual Hybrid Search: 벡터 임베딩 기반 의미론적 검색과 TF-IDF 기반 키워드 검색(BM25) 결합
리턴 청크의 수 (Number of Return Chunks): 실험 결과 20개 청크가 효과적이며 사용 사례에 따라 조정 필요
리랭킹 (Reranking): 리랭커 (Reranker) 엔진을 통해서 초기 검색 결과 재정렬 함으로써 가장 관련성 높은 청크만 선별하여 모델에 전달

이 방식은 전처리 단계에서 Contextual Retrieval을 적용하고, 런타임에서 리랭킹을 수행하여 검색 정확도를 크게 향상시킵니다. 이러한 단계적 접근을 통해, Contextual Retrieval 기술은 각 청크에 풍부한 컨텍스트를 제공하고, 하이브리드 검색 방식으로 검색의 정확도를 높이며, 리랭킹을 통해 가장 관련성 높은 정보만을 선별하여 최종적으로 답변에 사용될 컨텍스트로 전달합니다. 이 아키텍처는 검색의 정확도를 극대화하면서도, 처리해야 할 정보량을 효율적으로 관리하여 성능과 비용 사이의 균형을 맞추는 것을 목표로 합니다.

HAQM Bedrock 기반 Contextual Retrieval 구성 아키텍처와 샘플 코드

지금까지 설명드린 Contextual Retrieval 개념은 AWS 환경을 이용해서 손쉽게 구현이 가능합니다. HAQM Bedrock에서 Contextual Retrieval 아키텍처를 구현할 경우에는 아래와 같은 특징이 있습니다.

Anthropic에서 제공하는 다양한 Gen AI 모델을 API 형태로 편리하게 사용할 수 있고, 고객이 별도로 관리할 필요가 없는 관리형 서비스로 제공합니다.
RAG 환경에서 사용하는 Vector DB는 HAQM Bedrock Knowledge Base로 구성이 가능합니다. HAQM Bedrock Knowledge Base를 사용하게 되면, 별도로 HAQM Opensearch 클러스터를 구성하지 않고도 서버리스 형태로 편리하게 구성이 가능합니다.
리랭커 (Reranker)에 사용되는 엔진을 HAQM Bedrock에서 제공하는 리랭커 (Reranker) API를 통해서 사용이 가능합니다.
AWS Private Network 내에서만 사용해야 하는 업무 요건이 있을 경우에도 HAQM Bedrock 서비스를 AWS Private Link로 구성하여 사설 네트워크 내에서 안전하게 구성하여 사용이 가능합니다.

AWS 환경에서 구성된 Contextual Retrieval 아키텍처를 도식화하면 아래와 같은 아키텍처로 구성이 됩니다.

AWS 환경에서 구성되는 Contextual Retrieval 아키텍처는 크게 Contextual Chunk를 만드는 Pre-processing Area와 실제로 사용자가 질의를 수행하는 Runtime Area로 구성됩니다. 각 Area에 대해서는 아래와 같이 설명될 수 있습니다.

전처리 영역 (Pre-processing Area)

전처리영역(Pre-processing Area_에서는 RAG에서 사용할 Vector DB를 임베딩하는 단계입니다. 이 단계에서는 검색의 정확성을 높이기 위해서 Gen AI를 활용해서 Contexualized Chunk를 생성합니다. 각각의 스텝에 대해서는 아래와 같이 설명될 수 있습니다.

청킹 (Chunking): 우선 지식 기반에 사용할 다큐먼트를 Vector 임베딩을 하여 조회하기에 적절한 크기로 자릅니다.
Contextualized Chunk를 생성: Bedrock에서 제공되는 Claude Haiku 모델을 이용해서 Contextualized Chunk를 생성합니다.
벡터 임베딩 (Vector Embedding): Bedrock Titan 모델로 임베딩해서 Bedrock Knowledge Base에 임베딩된 데이터를 저장합니다.

실시간 처리 영역 (Runtime Area)

실시간 처리 영역 (Runtime Area)에서는 실제로 사용자가 질의를 수행하고, Gen AI를 통해서 답변하는 과정을 처리하는 아키텍처 영역입니다. 사용자가 질의하고 답변하는 과정에서 HAQM Bedrock 콤포넌트가 어떤 식으로 서비스를 제공하는지에 대해서 단계별로 설명하겠습니다.

질문 (Question): 우선 사용자가 Gen AI에게 질의합니다.
질문 임베딩 (Question Embedding): 사용자의 질문을 HAQM Bedrock Titan으로 임베딩합니다.
하이브리드 서치 (Hybrid Search): 사용자가 질의된 질문에 가장 유사한 컨텍스트를 찾기 위해서, 임베딩된 질문 벡터를 이용해서 Knowledge Base에서 Hybrid Search 수행합니다.
청크 리턴 (Chunk Return): Hybrid Search를 통해서 사용자가 지정한 갯수 만큼인 Top K(갯수) 갯수의 청크를 리턴합니다.
리랭킹 (Reranking): 위에서 리턴된 Top k 청크에 대해서, 질문과 더 연관성이 높을 수 있는 청크순으로 재정렬하도록 Bedrock Reranker로 리랭킹 (Reranking)합니다.
Conxext와 함께 Gen AI에게 질의: 리랭킹 (Reranking)을 통해서 추려진 Top n개의 청크를 컨텍스트로 활용해서 Claude에게 질의합니다.
답변 (Answer): 최종 답변을 사용자에게 전달합니다.

HAQM Bedrock 기반 Contextual Retrieval 코드 예시

HAQM Bedrock 기반으로 구성된 Contextual Retrieval 코드에 대해서 환경을 구성하고 경험을 해 볼 수 있는 코드를 작성하여 아래 Sample Repository로 공유합니다.

Contextual Retrieval 샘플 레파지토리 (Sample Repository):
- http://github.com/aws-samples/aws-ai-ml-workshop-kr/tree/master/genai/aws-gen-ai-kr/20_applications/20_contextual_rag

실용적 구성을 위해서 고려해야 하는 사항들

지금까지 Contextual Retrieval이 어떻게 동작하는지와 AWS기반에서는 어떻게 구성할 수 있는지에 대해서 설명드렸습니다.
하지만, 실용적으로 측면에서 Contextual Retrieval을 효과적으로 사용하려면, 몇 가지 고려해야 사항들이 있습니다.

슬라이드 윈도우나 Parent-document 사용

Anthropic에서 설명하는 Contextual Retrieval 방식에서는 Contextual Chunk를 생성하는 과정에서 전체 문서의 맥락을 정확하게 파악하여 해당 청크를 생성할 때는 전체 문서를 프롬프트에 입력하는 것으로 설명하고 있습니다. 하지만, 현실에서는 전체 document를 하나의 프롬프트로 입력하려면, 해당 프롬프트의 사이즈가 사용하는 모델이 허용하는 인풋 토큰 사이즈(ex. 200,000)보다 작아야 합니다. 그래서 이러한 부분을 해소하기 위해서는 해당 문서를 처리가 가능한 사이즈로 잘라서 처리하는 방식을 구현해야 합니다. 대표적인 방식이 슬라이드 윈도우 사이즈로 문서를 잘라서 활용하거나, 정확한 목차 구분이 있다면, parent-document 방식을 이용해서 큰 대분류 목차 단위로 잘라서 처리하도록 할 수 있습니다.

아래 sample repository로 제공하는 예시는 이러한 실용적인 측면을 고려해서, 용량이 큰 문서를 처리할 때, 슬라이드 윈도우 사이즈를 간편하게 지정해서 Contexual Retrieval 을 구현한 예시를 제공하고 있습니다.

Contextual Retrieval 샘플 레파지토리 (Sample Repository):
- http://github.com/aws-samples/aws-ai-ml-workshop-kr/tree/master/genai/aws-gen-ai-kr/20_applications/20_contextual_rag

적절한 청크 사이즈 선택 필요

Contextual Retrieval로 구성할 때, 적절한 크기로 청크 사이즈를 설정하는 것이 중요합니다.
어떤 사이즈로 설정할지에 대한 사항은 요건에 따라서 다를 수가 있지만, 여기에서는 Contextual Retrieval 구성환경에서 청크 사이즈를 달리했을 때, 어떤 인사이트들이 있을지에 대해서 테스트를 수행한 결과를 공유합니다.

아래는 Contexual Retrieval에서 전처리단계에서 청크 사이즈를 달리하면서 측정한 “Pre-processing 단계 처리시간”과 “전체 처리 토큰 수”를 도식화한 내용입니다.

이 그래프를 통해서 확인된 내용을 요약하면 아래와 같습니다.

전처리 (Pre-processing) 단계 수행 시, 청크 사이즈가 작을 수록 시간과 비용이 많이 증가
청크사이즈가 클수록 RAG시 개별 토큰 사용량 증가합니다. 하지만, 전처리 단계에서 Contextualized Token을 전체적으로 합산하게 되면 전체 처리된 토큰수는 줄어듦. 그 이유는 청크 사이즈가 클수록 전체 처리해야 하는 청크 갯수가 줄어들기 때문임.
(결론) 청크 사이즈는 청크 작업의 시간과 비용에 직접적인 영향을 줌. 또한 정확도에도 영향을 줄 수 있으므로, 적절한 사이즈의 문서 청킹이 필요 (Contextual Retrieval 처리상 청크사이즈가 클수록 처리되는 토큰 수가 줄어듦).

아래는 Contextual Retrieval을 적용하지 않는 경우와 적용한 경우에 대해서, “전체 토큰 사용량”과 “처리 시간”에 대해서 테스트를 통해서 비교를 수행한 그래프입니다.

이 그래프를 통해서 알 수 있는 내용은 아래와 같습니다.

Contextual RAG를 사용할 경우 토큰 사용량이 40% 가량 증가 (청크 사이즈 1,000 기준)
Contextual RAG를 사용할 경우 전체 연산 시간 또한 20% 가량 증가
(결론) Contextual RAG를 사용할 경우, 토큰 사용량과 전체 연산 시간이 유의미하게 증가. 이러한 부분은 프롬프트 캐시가 지원되는 환경에서는 비용증가에 대한 부담이 해소가 가능할 것으로 보임.

아래는 Contextual Retrieval 적용시의 리랭커 (Reranker)를 적용했을 경우와, 적용하지 않았을 경우에 대해서 “전체 처리 토큰 수”와 “처리 시간”에 대해서 테스트를 통해서 비교한 그래프입니다.

이 그래프를 통해서 알 수 있는 사항은 아래와 같습니다.

Reranker의 사용 여부에 따라 RAG에 필요한 토큰 및 연산 시간은 유의미한 차이를 보이지 않습니다.
Reranking 자체에 대한 연산 시간과 추가 토큰이 발생하지만, 더 높은 Retrieval 정확도가 필요한 경우 Reranker를 사용하는 것을 권장합니다.

복잡한 질문 수행시에 더 효과적

Contextual Retrieval은 위에서 검토된 것처럼 전처리 과정을 수반하기 때문에, 기본의 “Standard RAG” 보다 더 많은 토큰 사용과 Gen AI 사용량이 증가하게 됩니다. 그래서 Contextual Retrieval가 더 효과적이라고 판단되는 경우에 한해서 적용하는 것이 좋습니다.
그래서 여기에서는 Contextual Retrieval이 어떤 경우에 더 효과적일지를 판단해 보기 위해서, 복잡한 질문을 수행하는 경우와 간단한 질문을 수행하는 경우를 가정하여 Contextual Retrieval이 더 효과적인지를 테스트하여 비교한 사항을 공유합니다.

아래 그래프는 “복잡한 질문”과 “간단한 질문”에 대해서 각각 “Contextual Retrieval RAG”의 성능과 “Standard RAG”의 성능을 RAGAS 평가 방식을 이용하여 비교한 것입니다.

“복잡한 질문”과 “간단한 질문”의 예시
- 단순한 질문 예시
  - “HAQM EC2의 다양한 요금 옵션은 무엇입니까?”
- 복잡한 질문 예시
  - “HAQM EC2와 HAQM Lightsail의 주요 차이점은 무엇이며, 내 웹 애플리케이션 요구사항에 더 적합한 서비스를 선택하려면 어떤 점을 고려해야 합니까?”
“Contextual Retrieval RAG”의 성능과 “Standard RAG”의 성능 비교

추가적으로 질문세트는 여기에 있으니 참조해 주세요.

http://github.com/aws-samples/aws-ai-ml-workshop-kr/blob/master/genai/aws-gen-ai-kr/20_applications/20_contextual_rag/notebook/data/questions.jsonl

질문을 생성하기 위한 소스코드는 여기 입니다.

http://github.com/aws-samples/aws-ai-ml-workshop-kr/blob/master/genai/aws-gen-ai-kr/20_applications/20_contextual_rag/notebook/2_qustion_generator.ipynb

위의 그래프를 통해서 알 수 있듯이, “Contextual Retrieval RAG”는 복잡한 질문이 사용될 경우에 두드러지게 효과가 잘 나타나는 것으로 확인되고 있습니다. 복잡한 문장이 더 효과적인 이유는 Gen AI를 통해서 답변을 수행할 때, 여러 문장에 걸친 답변을 종합적으로 검토하여야 답변이 되기 때문입니다.

결론

지금까지는 저희는 Contextual Retrieval이 무엇인지를 살펴보았고, 해당 기능을 실제로 활용할려고 할 때, 어떠한 사항들을 고려해 볼 수 있는지에 대해서 살펴 보았습니다. 요약하자면, Contextual Retrieval을 사용하게 되면, RAG에서 조회 (Retrieval)의 품질이 좋아집니다. 그리고 기본적인 Contextual Retrieval 이외에도 TF-IDF기반의 BM25를 혼합하여 검색하는 Hybrid search를 활용하면 검색 품질이 더 올라갑니다. 또한 리랭커 기술을 조합해서 사용한다면, 해당 조회 (Retrieval)품질은 훨씬 더 좋아질 수 있습니다. 그리고 Contextual Retrieval를 적용한다고 해서 비용이 부담될 수준으로 비싸지는 것도 아니기 때문에 많은 RAG 아키텍처에서 손쉽게 적용해 볼 수 있습니다. 또한 프롬프트 캐싱까지 적용한다면, Contextual Retrieval를 적용했을 때의 레이턴시도 향상되고, 비용도 더 많이 절감할 수 있습니다. 이를 경험하실 수 있는 코드는 aws samples 레포지토리에 이 링크를 통해서 공개되어 있습니다.

AWS 기술 블로그