RAG 란?
RAG(Retrieval-Augmented Generation)는 LLM의 정보 한계와 환각(Hallucination) 문제를 해결하기 위해 나온 기술입니다.
LLM은 기본적으로 학습된 데이터를 기반으로 답변을 생성합니다. 하지만 다음과 같은 근본적인 제약이 존재합니다.
- 개인 문서나 사내 자료처럼 사전 학습에 포함되지 않은 정보에 대한 응답 불가
- 환각 현상 발생
이러한 문제를 보완하기 위해 외부 데이터를 검색(Retrieval)하고 그 결과를 LLM의 프롬프트에 추가(Augmented)하여 더 나은 답변을 생성(Generation)하는 방식이 바로 RAG입니다.
RAG의 구현
RAG에서 가장 중요한 것은 LLM에게 어떤 컨텍스트를 제공하느냐입니다.
방대한 외부 데이터 중에서 질문에 대한 근거가 될 만한 정보를 선별하고, 이를 LLM의 프롬프트로 활용하는 것이 RAG 성능에서 가장 중요한 부분입니다.
이를 구현하기 위해서는 먼저 외부 문서를 적절한 크기로 분할(chunking)하고, 각 조각을 벡터 임베딩(embedding)하여 벡터 데이터베이스(Vector DB)에 저장해야 합니다.
질문이 들어오면, 이 벡터 DB에서 가장 유사한 조각을 검색(retrieval)하여 LLM의 입력 프롬프트에 포함시키는 구조로 동작합니다.
Chunking
chunking에 있어서 가장 중요한 부분은 문맥 보존입니다.
예를 들어 하나의 chunk에 대명사나 설명이 없는 특정 용어가 반복적으로 등장하게 되면 LLM은 해당 Chunk에서 정확한 정보를 얻을 수 없고 답변의 퀄리티 또한 떨어지게 됩니다.
또한 chunk의 크기가 너무 작으면 문장이 중간에 잘려 문맥이 끊기고, 너무 크면 벡터 검색의 정밀도가 떨어지거나 LLM의 입력 길이를 초과할 수 있습니다.
이를 해결하기 위해 보통 오버랩 기법을 사용합니다.
오버랩 기법이란, 각 chunk간 일정 분량의 문장을 겹쳐, 문맥을 공유하는 방법입니다.
오버랩 기법이란, 인접한 chunk들 사이에 일정 분량의 텍스트를 겹쳐 포함시키는 방식으로, 이를 통해 각 chunk가 앞뒤 문맥을 일정 부분 공유하게 하여 문맥 단절을 줄이고 의미 연결성을 높일 수 있습니다.
효율적인 chunking을 하기 위해서는 단순히 토큰 수가 아니라, 문장이나 문단 단위로 끊어내는 방법이 필요합니다.
Embedding & Vector DB
임베딩은 텍스트를 의미 기반으로 수치화된 벡터 형태로 변환하는 과정입니다.
임베딩 모델은 텍스트를 받아 의미적으로 유사한 문장끼리는 가까운 벡터, 의미가 다른 문장끼리는 먼 벡터로 변환합니다.
모델 성능이 높을수록 더 정교하게 의미를 구분하고, 높은 차원의 벡터 공간에서 더 풍부한 의미 정보를 담아낼 수 있습니다.
이렇게 반환받은 벡터값은 Vector DB에 저장됩니다.
임베딩된 벡터는 원문 텍스트와 함께 Vector DB에 저장되며, 사용자가 질문을 입력하면 동일한 임베딩 모델로 질문도 벡터화한 뒤, 벡터 DB에서 가장 유사한 벡터를 검색하여 해당 원문을 컨텍스트로 LLM에 전달합니다. LLM은 이렇게 전달받은 컨텍스트를 바탕으로 답변을 생성하게 됩니다.
Graph-RAG
Graph-RAG는 그래프 구조를 활용하여 데이터를 저장하고, 텍스트 내 개체(Entity)와 관계(Relation)를 튜플(triple) 형태로 구성하여 지식 그래프로 표현합니다.
예를 들어 "강아지가 사과를 먹었다"라는 문장은 (강아지, 먹었다, 사과)와 같은 튜플 구조로 변환되어, 그래프에 저장됩니다. 이러한 그래프는 Neo4j 같은 그래프 DB에 저장되며, 사용자의 질문이 들어오면 내부적으로 Cypher 쿼리를 통해 질문과 관련된 노드를 탐색합니다. 이후 검색된 부분의 그래프는 데이터 전처리 과정을 거쳐 LLM의 컨텍스트로 활용됩니다.
예를 들어 "강아지가 무엇을 먹었나요?"라는 질문이 들어오면, 그래프에서 (강아지) <-[먹혔다]- (사과)와 같은 관계를 추론하고, 이를 바탕으로 컨텍스트를 생성하여 LLM에 전달합니다.
Graph-RAG vs RAG [성능 비교]
RAG vs. GraphRAG: A Systematic Evaluation and Key Insights 논문을 참고해 Q/A데이터 셋에 따른 Graph-RAG와 RAG의 성능을 비교해 보겠습니다.
위 표는 단일 홉(NQ), Hotpot(멀티 홉이 포함된 Q/A)질문에 대한 답변 성능을 나타낸 표 입니다.
단일 홉이란 하나의 문서만 참조하면 답변을 할 수 있는 질의 유형입니다.
멀티 홉이란 두 개 이상의 문서에서 정보를 결합해야 답변을 할 수 있는 질의 유형입니다.
Hotpot는 멀티 홉 질문으로 구성된 대표적인 데이터셋으로, 다양한 문서 간의 정보를 종합해 정답을 도출해야 합니다.
표에는 4가지 방식의 Graph-RAG가 있는데 각각 간단히 설명하겠습니다.
- KG-GraphRAG : (강아지, 먹었다, 사과) 와 같은 Triplets only 방식
- KG-GraphRAG (Triplet + Text) : 위와 같은 Triplet과 원문도 함께 제공하는 방식
- Community-GraphRAG (Local) : 질문과 관련 있는 노드와 연결된 노드들의 정보도 같이 제공하는 방식 (Triplet + Text 형태로 제공)
- Community-GraphRAG (Global) : 질문과 관련 있는 노드가 포함된 영역의 전체 노드들의 정보도 같이 제공하는 방식 (Triplet + Text 형태로 제공)
성능 평가지표로는 P (Precision), R (Recall), F1이 사용되며, 모델은 각각 Llama 3.1-8B와 Llama 3.1-70B입니다.
여기서 P는 모델이 "정답이다"라고 판단한 것들 중 실제로 정답인 비율, R은 실제 정답 중에서 모델이 올바르게 찾아낸 비율, F1은 P와 R의 조화평균 입니다.
표를 보면 RAG방식이 간단한 질문 즉 단일 홉 질문에 좋은 성능을 나타내는 것을 볼 수 있습니다.
Community-GraphRAG (Local) 방식은 복잡한 추론이 필요한 멀티 홉 질문에 좋은 성능을 나타내는 것을 볼 수 있습니다.
정리
Graph-RAG는 질문이 복잡해질수록, 특히 여러 문서를 종합해야 하는 멀티 홉 질의에서 기존 RAG 방식보다 더 나은 성능을 보입니다. 반면, 일반적인 Chunk + Vector 기반 RAG는 하나의 문서만으로 답할 수 있는 단순한 질의에서는 여전히 뛰어난 성능을 유지하지만, 복잡한 논리적 추론이 필요한 상황에서는 Graph-RAG에 비해 성능이 떨어지는 한계를 보입니다.
참고 문헌 : RAG vs. GraphRAG: A Systematic Evaluation and Key Insights
Haoyu Han, Harry Shomer, Yu Wang, Yongjia Lei, Kai Guo, Zhigang Hua, Bo Long, Hui Liu, Jiliang Tang
https://arxiv.org/abs/2502.11371v1
'RAG' 카테고리의 다른 글
Graph-RAG 구현 : [Brain Trace] (2) | 2025.07.10 |
---|