brunch

RAG 시스템 설정별 응답 정확도 비교

by 최재철

■ 실험 개요

이번 실험에서는 RAG 시스템의 4 가지 주요 구성 요소를 변경해보며, 질문에 대해 얼마나 정확한 답변을 생성하는지(응답 정확도)를 비교했습니다. 실험에는 LangChain 공식 문서를 데이터로 활용하였으며, 총 10개의 자연어 질문을 통해 각 설정을 평가했습니다.

(* 굉장히 제한적인 실험을 한것이기에, 다른 도메인과 다른 데이타셋에 일관된 결과가 나오지 않음을 미리 알려드립니다. )


우선,

RAG 으로 사용한 데이터셋은 LangChain 공식 문서(python.langchain.com)로 정했습니다. 참고로, 이 사이트는 대형 언어 모델(LLM) 기반 응용 프로그램 개발을 돕는 LangChain 프레임워크의 사용 방법과 예제를 담고 있습니다. 이 사이트는 기술문서형 데이터셋에 해당하며, 사용한 질문은 사이트의 내용을 검색하고 올바르게 답변을 잘 생성하는지를 테스트 해 보았습니다. (* 질문은 모두 영어로 번역해서 실시함)

( 질문 10개)

Q: "LangChain에서 ConversationBufferMemory 이란?"

Q: "LangChain의 VERSION 0.3 의 특징은?"

Q: "LangChain에서 호환하는 채팅모델은?"

Q: "LangChain에서 사용하는 'Agent'의 개념과 주요 기능은?"

Q: "LangChain에서 'PromptTemplate'는 무엇이며, 어떻게 활용되나요?"

Q: "LangChain에서 지원하는 벡터 저장소의 종류에는 어떤 것이 있나요?"

Q: "LangChain의 'RetrievalQA' 체인은 어떤 역할을 하나요?"

Q: "LangChain에서 'Tool'이란 무엇이며, 대표적인 예시는 어떤 것이 있나요?"

Q: "LangChain을 통해 OpenAI의 GPT 모델을 사용하는 방법은 무엇인가요?"

Q: "LangChain에서 'FewShotPromptTemplate'의 목적과 사용 예시는?"


간단하게 실험환경 준비작업을 설명하면,

문서 전체를 청크(chunk) 단위로 분할하여 임베딩하고 벡터 DB에 저장한 뒤, 사용자의 자연어 질문에 관련 청크를 검색하여 답변을 생성하는 Retrieval-Augmented Generation (RAG) 시스템을 구성하였습니다.


실험 구성 및 방법


RAG 시스템의 성능에 영향을 미치는 여러 요소를 분리하여 평가하였습니다. (중첩x)

각 실험은 위에서 제시한 동일한 10개의 자연어 질문 세트에 대해 수행되었고, 생성된 답변이 데이터셋 문서에 기반해 정확한지 여부를 수작업으로 평가하였습니다.

각 질문별로 10점의 정확도 점수를 부여하고 합산하여 (총 100점) 해당 설정의 정확도를 측정하였습니다.

총점에 따라 S/A/B/C 등급을 분류하였으며 (S: 90~100점, A: 80~89점, B: 70~79점, C: 70점 미만),


실험에서는 다음 네 가지 조건을 독립적으로 변화시켰습니다. 한 번에 하나의 조건을 변경하고 나머지 요소는 기준 설정을 유지함으로써, 각 요인의 영향도를 비교하였습니다.


1. 문서 청크 크기 및 겹침: 문서를 임베딩하기 전에 일정 길이로 분할하는 청크 크기와 인접 청크 간

겹치는 영역의 크기 조정. (기준 임베딩 모델/벡터 DB/생성 모델을 사용하여 비교)

2. 임베딩 모델: 임베딩 생성에 사용하는 모델 선택. (기준 청크 설정/벡터 DB/생성 모델을 사용하여 비교)

3. 벡터 저장소: 벡터 검색에 사용하는 벡터 DB 또는 라이브러리 변경. (기준 청크/임베딩/생성 모델을

사용하여 비교)

4. 생성 모델: 최종 답변 생성을 위한 언어 모델 변경. (기준 청크/임베딩/벡터 DB를 사용하여 비교)


기준 설정은 청크 크기 500토큰 (100토큰 겹침), 임베딩 모델 all-MiniLM-L6-v2, 벡터 저장소 FAISS, 생성 모델 Falcon-7B로 정하였습니다. 아래에서 각 실험별 상세 결과를 제시하겠습니다.


실험 결과


1. 청크 크기와 겹침 조정에 따른 영향

청크 크기는 문서를 몇 토막으로 쪼갤지 결정하며, 겹침은 청크 사이에 중복되는 부분을 얼마나 둘지 정하는 것입니다. 작은 청크는 더 많은 조각으로 나누어지므로 질문과의 매칭 정확도를 높일 수는 있지만, 반면에 너무 작으면 문맥이 잘려나가 중요한 정보를 놓칠 위험이 있습니다. 이에 비해 큰 청크는 더 풍부한 문맥을 보존하지만, 불필요한 내용까지 포함되어 정확한 검색에 방해가 될 수가 있습니다. (트레이드오프가 발생)

겹침을 두면 청크 경계의 내용이 이어져 문맥 단절을 줄일 수 있는데, 일반적으로 청크 길이의 10~20% 정도를 겹치게 설정하는 것이 바람직하다고 보고되어 있습니다.

본 실험에서는 500토큰 청크 with 100토큰 겹침과 1000토큰 청크 with 200토큰 겹침 두 가지를 비교하였습니다 (겹침은 각각 청크의 20%에 해당).


청크 500/겹침 100: 작은 크기의 청크를 많이 생성하여 세밀한 단위로 임베딩함으로써, 질문과 정확히 맞는 조각을 찾을 확률이 높았다. 겹침 100토큰을 줘서 문단 경계의 문맥도 유지했다.

청크 1000/겹침 200: 더 큰 청크로 적게 쪼갬으로써 문맥은 풍부했으나, 각 청크에 포함된 내용 범위가 넓어져 질문과 부분적으로만 관련된 내용까지 함께 검색되는 경우가 늘어났다.


이 두 설정에 동일한 질문 세트를 적용한 결과, 작은 청크(500)가 큰 청크(1000) 보다 약간 더 높은 정확도를 보였습니다. 작은 청크는 필요한 정보만을 정확히 짚어주는 경향이 있었고, 겹침으로 인해 문맥 손실도 최소화되어 답변의 정확성이 향상되었습니다. 반면 큰 청크는 일부 질문에서 불필요한 맥락까지 포함하여 답변이 다소 흐려지는 경우가 있었습니다.


500토큰 (겹침 100토큰) → (A)
1000토큰 (겹침 200토큰) → (B)

청크 크기는 RAG 시스템의 정보단위를 결정하는 중요한 요소입니다. 본 실험에서 청크를 더 잘게 쪼갠 설정이 정확도를 높이는 데 유리했지만, 차이는 크지 않았습니다.


2. 임베딩 모델 변경에 따른 영향

문서 청크를 벡터로 임베딩하는 임베딩 모델의 선택은 RAG 파이프라인의 검색 성능을 좌우하는 핵심 요소 중 하나입니다. 임베딩 모델마다 문서를 벡터화하는 품질이 다르기 때문에, 동일한 질문에도 관련 청크를 찾아내는 정확도(Recall)에서 차이가 발생합니다.


본 실험은 다음 세 가지 임베딩 모델을 비교하였다.

all-MiniLM-L6-v2 (약 22M 파라미터, 384차원 임베딩): 소형 SentenceTransformer 계열 모델로, 속도가 빠르고 가벼우나 임베딩의 정밀도가 상대적으로 낮을 수 있다.

E5-small (약 30M 파라미터, 384차원 임베딩): 문서 검색 태스크에 특화해 학습된 E5 계열의 소형 모델. 작은 크기 덕에 빠르지만, 성능은 상위 E5 모델에 비해 떨어진다.

Instructor-XL (약 335M 파라미터, 768차원 임베딩): 대형 임베딩 모델로, 다양한 작업 지시에 따라 임베딩을 생산하도록 미세조정된(Instructor 튜닝된) 모델. 파라미터 수가 많아 속도는 느리지만 보다 풍부한 의미 표현을 학습했다.


각 임베딩 모델로 동일한 문서와 질문 세트를 적용한 결과, 모델 간 검색 정확도에 뚜렷한 격차가 나타났습니다. 아래는 각 임베딩 모델 사용 시 10개 질문에 대한 정확도 총점입니다.


all-MiniLM-L6-v2 → 70점 (B)
E5-small → 60점 (C)
Instructor-XL → 80점 (A)


3. 벡터 저장소 변경에 따른 영향

임베딩된 벡터를 저장하고 유사도 검색을 수행하는 벡터 DB/저장소의 종류를 변경하여 응답 정확도의 변화를 관찰했습니다. 대표적인 오픈소스 벡터 데이터베이스인 FAISS, Chroma, Weaviate 세 가지를 비교하였습니다.

세 제품 모두 코사인 유사도 등의 벡터 검색(최근접 이웃 탐색) 기능을 제공하지만, 내부 구현과 최적화 방식에 차이가 있습니다. 예를 들어 FAISS는 Meta(페이스북)에서 개발한 라이브러리로 IVF, HNSW 등 다양한 근사 최근접탐색 알고리즘을 지원하고 GPU 가속이 가능합니다. Chroma는 파이썬 환경에서 많이 사용하는 벡터 DB로, 기본적으로 FAISS/HNSW 기반의 인덱스를 활용하며 부가적인 메타데이터 필터링 기능을 갖추고 있습니다. Weaviate는 별도 서버형 DB로 동작하며 기본 알고리즘으로 HNSW를 사용하고 확장성, 필터링에서 강점을 보이는 솔루션입니다.

이러한 구현 차이가 실제 정확한 문서 조각 검색 성능에 영향을 줄지 실험한 결과, 세 벡터 저장소 간 답변 정확도에는 큰 차이가 없었습니다. 동일한 임베딩과 동일한 검색 파라미터(예: 상위 3개 벡터 검색)를 사용한 한, 10개 질문 중 정답이 포함된 관련 청크를 찾아내는 비율은 세 시스템 모두 유사했다. 정확도 총점을 보면 아래와 같습니다.


FAISS / Chroma /Weaviate → 모두 80점 (A)

벡터 저장소 종류 자체는 응답 정확도에 결정적 영향을 주지 않았습니다.


4. 생성 모델 변경에 따른 영향

마지막으로, 사용자의 질문과 검색된 문서를 바탕으로 최종 답변을 생성하는 언어 모델을 교체하여 정확도 변화를 살펴보았습니다. 생성 모델로는 최근 오픈소스로 주목받는 Falcon-7B, Mistral-7B, 그리고 Meta가 공개한 LLaMA2-13B-chat를 비교하였습니다.


Falcon-7B (미세튜닝 버전): 2023년 공개된 7억 파라미터급 모델로, 당시 오픈소스 중 강력한 성능을 보였으나, 최신 모델들에 비해서는 응답의 정확성이나 추론 능력이 다소 떨어질 수 있다.

Mistral-7B (v0.1): 2024년 공개된 7B 모델로, 적은 파라미터임에도 불구하고 아키텍처 최적화를 통해 뛰어난 성능 향상을 이룬 모델이다. 특히 기존 Falcon 등 7B 모델들보다 다양한 벤치마크에서 향상된 결과를 보인 것으로 알려져 있다medium.com.

LLaMA2-13B-chat: Meta AI가 2023년 발표한 130억 파라미터 모델의 대화 튜닝 버전으로, 공개된 중형 모델 중에서는 가장 높은 수준의 언어 이해 및 생성 능력을 갖춘 것으로 평가된다medium.com. 특히 사실 기반 질문에 대한 정확도가 우수하며, 오픈소스 7B 모델들을 상회하는 성능을 보인다.


생성모델의 테스트의 경우, 기존 실험과 다르게 얼마나 자연스러운지를 추가했습니다. 동일한 질문 세트에 대해 위 세 가지 모델로 답변을 생성하고 정확도 및 인간이 대답하는 것처럼 자연스러운지를 수작업으로 평가했습니다.

LLaMA2-13B-chat (상) > Mistral-7B(중) > Falcon-7B (하)

LLaMA2-13B-chat 이 가장 뛰어난 성능을 보였습니다. 대부분의 질문에 대해 문서 기반으로 정확하게 답변했고, 문서에 없는 내용을 지어내는 환각(hallucination) 현상은 거의 없었습니다. 이는 LLaMA2가 가진 언어 이해 능력과, 대화형 미세조정을 통해 주어진 자료에 충실하게 답변하는 성향이 강화된 덕분으로 판단됩니다.


■ 마치며...

RAG 시스템의 정확도를 극대화하기 위해서는 임베딩 모델, 벡터 검색, 생성 모델이 균형 있게 구성되어야 합니다. 위 실험결과로는,

임베딩 품질이 높을수록, 질문에 적합한 문서를 더 잘 검색.

생성 모델이 강력할수록, 주어진 정보를 정확하고 자연스럽게 표현.

벡터 저장소는 성능 최적화나 개발 편의성 기준으로 선택하면 충분.


특히, 이번 실험에서 LLaMA2-13B-chat 모델은 다른 요소의 부족함을 상쇄할 정도로 우수한 정확도를 보였습니다. 반대로, 임베딩이나 생성 모델 중 하나라도 성능이 떨어지면 전체 시스템 성능이 쉽게 저하되었습니다.


■ 향후 고도화 방향

이번 실험은 기본적인 설정 비교였지만, 향후 다음과 같은 요소를 도입하면 RAG 성능을 더 높일 수 있을 것으로 예상됩니다.

재순위(Reranking) 모델 도입: 검색된 문서를 중요도 순으로 정렬

피드백 루프 구축: 사용자 평가 기반의 성능 향상


이번 비교 실험에서 도출된 결과를 바탕으로, 주어진 예산과 요구사항에 맞는 최적의 RAG 시스템 설정을 선택하는 데 도움이 되기를 기대합니다.

keyword
작가의 이전글NVIDIA의 생태계 확장과 Cosmos