GraphRAG가 일반 RAG보다 성능이 낮게 나왔다고요? — 지식 그래프의 치명적 함정과 하이브리드 전략

단순한 엔티티 추출만으로는 부족합니다. GraphRAG의 성능 저하 원인을 분석하고 LlamaIndex를 활용한 최적의 통합 경로를 제시합니다.

최근 여러 벤치마크 테스트 결과를 보면서 참 흥미로운 점을 발견했어요. 이론적으로는 관계를 캡처하는 GraphRAG가 훨씬 똑똑해야 할 것 같은데, 실제로는 일반적인 벡터 검색 기반의 RAG보다 검색 품질이 오히려 떨어지는 결과가 나타나더라고요 [2]. “관계가 곧 컨텍스트인데, 왜 결과가 더 나쁘지?”라는 의문이 드는 게 당연합니다.

사실 여기서 우리가 놓치고 있는 핵심이 있어요. GraphRAG는 복잡한 다단계 추론에는 정말 강력하지만, 그래프를 구축하는 과정에서 엔티티 해소나 품질 검증 같은 ‘기초 공사’가 부실하면 오히려 일반 RAG보다 못한 성능을 내게 됩니다. 결국 무조건적인 도입보다는 두 방식의 적응적 통합이 필수적이라는 결론에 이르게 되죠.

RAG vs GraphRAG: 무엇이 다른가

먼저 우리가 흔히 쓰는 전통적인 RAG와 GraphRAG가 어떻게 다른지 짚고 넘어갈게요. 쉽게 말해, RAG는 ‘유사한 조각 찾기’이고, GraphRAG는 ‘연결된 지도 따라가기’라고 보시면 됩니다.

전통적인 RAG는 텍스트를 적당한 크기의 청크로 나누고 벡터화해서 저장합니다. 사용자가 질문을 하면 벡터 공간에서 가장 유사한 조각들을 가져오는 방식이죠. 반면 GraphRAG는 텍스트에서 엔티티(개체)와 그들 사이의 관계를 추출해서 지식 그래프(Knowledge Graph)를 먼저 만듭니다 [8]. 그리고 이 그래프 구조를 타고 정보를 검색해요.

여기서 중요한 건, 두 방식이 잘하는 영역이 완전히 다르다는 점입니다.

RAG: 단일 홉(single-hop)의 사실 중심 쿼리에 강합니다. “A의 출시일이 언제야?” 같은 정밀한 정보 검색에 유리하죠 [3].
GraphRAG: 다단계 추론(multi-hop)이나 주제 전반을 아우르는 광범위한 쿼리에 강합니다. 고립된 답변이 아니라 연결된 정보를 가져오기 때문에 더 깊은 통찰력을 제공할 수 있어요 [4].

실제로 관련 연구에서도 이런 차이가 명확히 드러납니다.

“RAG consistently performs well on single-hop, fact-centric queries… while GraphRAG excels on reasoning-intensive, multi-hop queries” [3]

(RAG는 단일 홉의 사실 중심 쿼리에서 일관되게 좋은 성능을 보이지만, GraphRAG는 추론 집약적인 다단계 쿼리에서 탁월한 성능을 보인다.)

왜 GraphRAG가 기대보다 성능이 안 나올까?

그럼 왜 어떤 경우에는 GraphRAG가 일반 RAG보다 성능이 낮게 나올까요? 제가 보기엔 많은 개발자가 GraphRAG를 구현할 때 너무 단순하게 접근하기 때문입니다.

보통 이런 식으로 구현하곤 하죠. “LLM한테 텍스트 던져주고 ‘여기서 엔티티랑 관계 좀 뽑아줘’라고 한 다음, 나온 결과를 그대로 그래프 DB에 넣으면 끝!” 하지만 여기엔 치명적인 함정들이 숨어 있습니다.

가장 큰 문제는 엔티티 해소(Entity Resolution)의 부재예요. 예를 들어, 어떤 문서에는 ‘Hilton Hotels’라고 적혀 있고 다른 문서에는 ‘Hilton Worldwide Holdings’라고 적혀 있다고 칩시다. 사람이 보면 같은 회사지만, 단순 추출 시스템은 이를 서로 다른 두 개의 노드로 생성합니다 [2]. 결국 연결되어야 할 정보가 끊어지면서 그래프의 최대 장점인 ‘연결성’이 무너지는 거죠.

여기에 LLM의 환각(Hallucination)까지 더해지면 상황은 더 심각해집니다. 존재하지 않는 관계를 LLM이 임의로 만들어내고, 이를 검증 없이 그래프에 포함시키면 검색 결과에 노이즈가 섞이게 됩니다 [5]. 결국 데이터 품질이 곧 검색 품질로 직결되는 구조인데, 구축 단계의 노이즈를 방치하면 다음과 같은 상황이 벌어집니다.

“A bad graph makes answers worse than plain RAG.” [5]

(잘못 만들어진 그래프는 답변의 질을 일반 RAG보다 더 나쁘게 만든다.)

LlamaIndex로 구축하는 고성능 GraphRAG 파이프라인

그렇다면 어떻게 해야 제대로 된 GraphRAG를 만들 수 있을까요? 저는 LlamaIndex의 PropertyGraph 추상화와 Neo4J 조합을 추천합니다. 단순히 트리플(주어-술어-목적어)만 뽑는 게 아니라, 노드와 엣지에 속성(Property)을 부여해 훨씬 풍부한 모델링이 가능하기 때문이죠 [6, 10].

특히 Neo4J를 통합하면 대규모 그래프에서도 쿼리 최적화가 가능하고, 임베딩 기반 검색과 그래프 탐색을 유연하게 결합할 수 있습니다. 또한, 최근 주목받는 ‘커뮤니티 기반 요약(Community-GraphRAG)’ 방식을 쓰면, 그래프 전체를 매번 탐색하는 대신 미리 요약된 커뮤니티 수준에서 매칭을 수행해 검색 지연 시간을 획기적으로 줄일 수 있습니다 [3].

실제로 LlamaIndex를 활용해 Neo4J 기반의 PropertyGraph를 구축하는 기본 구조는 다음과 같습니다.

from llama_index.core import PropertyGraphIndex
from llama_index.graph_stores.neo4j import Neo4jPropertyGraphStore
from llama_index.llms.openai import OpenAI

# 1. Neo4J 저장소 설정 (실제 DB 연결 정보 입력)
graph_store = Neo4jPropertyGraphStore(
    username="neo4j", 
    password="your_password", 
    url="bolt://localhost:7687"
)

# 2. LLM 설정 (엔티티 및 관계 추출용)
llm = OpenAI(model="gpt-4")

# 3. PropertyGraphIndex 구축 
# documents는 LlamaIndex의 Document 객체 리스트입니다.
index = PropertyGraphIndex.from_documents(
    documents,
    property_graph_store=graph_store,
    llm=llm,
    # 여기서 추출 전략을 세밀하게 조정하여 엔티티 해소 및 품질을 높여야 합니다.
)

# 4. 하이브리드 쿼리 실행 (벡터 검색 + 그래프 탐색 결합)
query_engine = index.as_query_engine(include_text=True)
response = query_engine.query("A 서비스의 장애가 B 모듈에 어떤 영향을 미치나요?")
print(response)

이 코드는 단순히 텍스트를 저장하는 게 아니라, Neo4J라는 강력한 그래프 DB 위에 지식 구조를 세우고, 질문이 들어왔을 때 벡터 유사도와 그래프의 관계를 동시에 활용해 답변을 생성하게 합니다.

짚고 넘어갈 한계와 안티패턴

여기서 주의할 점이 있습니다. GraphRAG를 모든 문제를 해결해 주는 ‘만능 도구’로 생각하는 건 정말 위험한 안티패턴이에요.

우선 리소스 소모가 엄청납니다. LLM을 이용해 엔티티를 확장하고 다단계로 그래프를 탐색하는 과정은 일반 벡터 검색보다 훨씬 느립니다. 실제로 KG-GraphRAG 방식은 다단계 탐색 때문에 검색 지연 시간이 가장 높게 나타나는 경향이 있죠 [3].

저장 공간 문제도 무시 못 합니다. 특히 커뮤니티 기반의 요약을 저장하는 방식은 커뮤니티 표현과 요약본을 모두 가지고 있어야 하므로 저장 용량이 크게 늘어납니다 [3]. 결국 단순 벡터 DB를 구축하는 것보다 파이프라인 관리가 훨씬 까다롭다는 뜻입니다.

“GraphRAG isn’t a magic upgrade. It adds complexity everywhere” [5]

(GraphRAG는 마법 같은 업그레이드가 아니다. 모든 단계에 복잡성을 추가한다.)

최적의 전략: Selection과 Integration

결국 정답은 “상황에 맞게 섞어 쓰는 것”에 있습니다. 저는 두 가지 전략을 제안합니다.

첫째는 Selection(선택) 전략입니다. 쿼리가 들어오면 LLM이 먼저 판단하게 하는 거죠. “이 질문은 단순 사실 확인인가, 아니면 복잡한 관계 추론인가?” 단순 질문이면 일반 RAG로, 복잡한 질문이면 GraphRAG로 보내는 방식입니다. 효율성 측면에서 매우 유리합니다.

둘째는 Integration(통합) 전략입니다. 매 쿼리마다 두 방식을 모두 실행하고 그 결과를 결합하는 거예요. 비용은 더 들지만, 성능은 가장 일관되게 높게 나옵니다 [3].

가장 추천하는 하이브리드 접근법은 벡터 검색 + 풀텍스트 검색 + 인접 노드 탐색을 조합하는 것입니다. 실제로 이런 방식이 나이브한 RAG보다 훨씬 뛰어난 결과를 냈다는 경험 사례가 많습니다 [2].

핵심 요약

RAG는 단순 사실 확인에, GraphRAG는 복잡한 관계 추론에 유리합니다.
GraphRAG의 성능은 ‘그래프 구축 품질(엔티티 해소, 검증)’에 전적으로 달려 있습니다. 대충 뽑아서 넣으면 오히려 성능이 떨어집니다.
무조건적인 도입보다는 쿼리 유형에 따라 하나만 선택(Selection)하거나 둘을 통합(Integration)하는 전략이 필요합니다.
LlamaIndex와 Neo4J 조합을 쓰면 구현 복잡도를 낮추고 고성능 파이프라인을 구축할 수 있습니다.
구축 비용(시간, 저장소, 지연시간)과 성능 향상 폭 사이의 트레이드오프를 반드시 계산하세요.

결론적으로 GraphRAG 도입 전에는 내 데이터가 정말로 ‘관계’ 기반의 추론을 필요로 하는지, 그리고 엔티티 해소와 같은 데이터 정제 과정을 감당할 수 있는지 먼저 검토하시길 권합니다. 무조건적인 최신 기술 도입보다는, 쿼리 패턴에 맞춘 하이브리드 아키텍처를 설계하는 것이 실제 서비스 환경에서 훨씬 안정적인 성능을 보장하는 길입니다.

참고 자료 (References)

1. [medium.com] RAG and GraphRAG on LlamaIndex with one database — SynapCores — https://medium.com/@cto_louism/rag-and-graphrag-on-llamaindex-with-one-database-synapcores-0a4870b3619e 2. [reddit.com] Why do GraphRAGs perform worser than standard vector-based RAGs? : r/Rag — https://www.reddit.com/r/Rag/comments/1pi2q68/why_do_graphrags_perform_worser_than_standard 3. [arxiv.org] RAG vs. GraphRAG: A Systematic Evaluation and Key Insights — https://arxiv.org/html/2502.11371v3 4. [youtube.com] GraphRAG vs. Traditional RAG: Higher Accuracy & Insight with LLM — https://www.youtube.com/watch?v=Aw7iQjKAX2k 5. [puppygraph.com] GraphRAG Architecture: Components, Workflow & Implementation Guide — https://www.puppygraph.com/blog/graphrag-architecture 6. [developers.llamaindex.ai] GraphRAG Implementation with LlamaIndex – V2 | Developer Documentation — https://developers.llamaindex.ai/python/examples/cookbooks/graphrag_v2 7. [en.wikipedia.org] Retrieval-augmented generation — https://en.wikipedia.org/wiki/Retrieval-augmented_generation 8. [en.wikipedia.org] Knowledge graph — https://en.wikipedia.org/wiki/Knowledge_graph 9. [llamaindex.ai] LlamaIndex | AI Agents for Document OCR + Workflows — https://www.llamaindex.ai/ 10. [developers.llamaindex.ai] GraphRAG Implementation with LlamaIndex – V2 — https://developers.llamaindex.ai/python/examples/cookbooks/graphrag_v2/

FAQ

일반 RAG와 GraphRAG의 주요 차이점은 무엇인가요?

일반 RAG는 텍스트를 청크로 나누어 벡터 공간에서 유사한 조각을 찾는 '유사한 조각 찾기' 방식이며, 단일 홉의 사실 중심 쿼리에 강합니다. 반면 GraphRAG는 엔티티와 관계를 추출해 지식 그래프를 만드는 '연결된 지도 따라가기' 방식이며, 다단계 추론이나 광범위한 주제의 쿼리에 강점이 있습니다.

GraphRAG가 일반 RAG보다 성능이 낮게 나오는 이유는 무엇인가요?

주로 그래프 구축 단계의 '기초 공사'가 부실하기 때문입니다. 특히 'Hilton Hotels'와 'Hilton Worldwide Holdings'를 서로 다른 노드로 인식하는 것과 같은 엔티티 해소(Entity Resolution)의 부재, 그리고 LLM이 존재하지 않는 관계를 만들어내는 환각 현상으로 인해 데이터 품질이 떨어지면 검색 결과에 노이즈가 섞여 성능이 저하됩니다.

고성능 GraphRAG 파이프라인을 구축하기 위해 추천하는 도구 조합은 무엇인가요?

LlamaIndex의 `PropertyGraph` 추상화와 Neo4J 조합을 추천합니다. 이를 통해 노드와 엣지에 속성을 부여하는 풍부한 모델링이 가능하며, 대규모 그래프에서도 쿼리 최적화와 임베딩 기반 검색 및 그래프 탐색의 유연한 결합이 가능합니다.

GraphRAG 도입 시 주의해야 할 한계점이나 단점은 무엇인가요?

리소스 소모가 매우 큽니다. 일반 벡터 검색보다 검색 지연 시간이 더 길고, 특히 커뮤니티 기반 요약 방식을 사용할 경우 저장 용량이 크게 늘어납니다. 또한 파이프라인 관리가 일반 벡터 DB보다 훨씬 까다롭다는 복잡성이 있습니다.

RAG와 GraphRAG를 효율적으로 활용하기 위한 전략은 무엇인가요?

두 가지 전략이 있습니다. 첫째는 'Selection(선택) 전략'으로, LLM이 질문을 판단해 단순 사실 확인은 일반 RAG로, 복잡한 추론은 GraphRAG로 보내는 방식입니다. 둘째는 'Integration(통합) 전략'으로, 두 방식을 모두 실행해 결과를 결합하는 것입니다. 특히 벡터 검색, 풀텍스트 검색, 인접 노드 탐색을 조합하는 하이브리드 접근법이 효과적입니다.

정보로부자되세요(정보부자:Infobuza.com)

태그 보관물: LlamaIndex

GraphRAG가 일반 RAG보다 성능이 낮게 나왔다고요? — 지식 그래프의 치명적 함정과 하이브리드 전략

GraphRAG가 일반 RAG보다 성능이 낮게 나왔다고요? — 지식 그래프의 치명적 함정과 하이브리드 전략

RAG vs GraphRAG: 무엇이 다른가

왜 GraphRAG가 기대보다 성능이 안 나올까?

LlamaIndex로 구축하는 고성능 GraphRAG 파이프라인

짚고 넘어갈 한계와 안티패턴

최적의 전략: Selection과 Integration

핵심 요약

참고 자료 (References)

관련 글 추천

FAQ

일반 RAG와 GraphRAG의 주요 차이점은 무엇인가요?

GraphRAG가 일반 RAG보다 성능이 낮게 나오는 이유는 무엇인가요?

고성능 GraphRAG 파이프라인을 구축하기 위해 추천하는 도구 조합은 무엇인가요?

GraphRAG 도입 시 주의해야 할 한계점이나 단점은 무엇인가요?

RAG와 GraphRAG를 효율적으로 활용하기 위한 전략은 무엇인가요?