Graph RAG의 모든 것: 디자인 패턴 다섯 가지와 구현체 세 갈래¶
- 출처: Graph RAG의 모든 것
- 저자: Jonas Kim (
bits-bytes-nn) - 발행: 2025-04-21, dev.to
- 분량: 본문 약 28,900자 (표기는 6분)
- 태그: graphrag, graphql, graphdb, ai
- 읽은 날짜: 2026-09-10
- 태그: #GraphRAG #KnowledgeGraph #RAPTOR #DRIFT #Neo4j #Neptune #AWS #RAG
한 줄 요약¶
Graph RAG를 디자인 패턴 다섯 가지와 구현체 세 갈래(RAPTOR, Microsoft GraphRAG, AWS GraphRAG Toolkit)로 지형도를 그린 서베이. 개별 논문을 읽기 전에 전체 판을 잡는 용도로 좋고, 마지막 비교표 하나가 글 전체를 압축한다.
이 글의 쓸모¶
개별 기법 설명은 다른 데도 있다. 이 글의 값어치는 같은 축으로 여러 접근법을 늘어놓은 것이다. 인덱싱, 사전 검색, 검색, 사후 검색 네 단계로 나눠 여덟 가지 접근법을 한 표에 넣었다. 어떤 기법이 어느 단계에 개입하는지가 한눈에 보인다.
그래프 DB 기초부터 시작하는 것도 실용적이다. Graph RAG를 붙이려면 결국 그래프 모델과 질의 언어를 골라야 하는데, 그 결정을 다루는 자료가 의외로 드물다.
1. 전통 RAG의 한계¶
Microsoft Research의 문제 제기를 인용한다. 두 가지다.
- 정보 연결의 어려움: 흩어진 청크를 논리적으로 이어 새로운 통합 인사이트를 만들어야 할 때 약하다. 여러 문서에 걸친 공유 속성이나 관계를 합쳐야 하는 상황에서 두드러진다.
- 대규모 정보의 종합적 이해 부족: 큰 데이터 컬렉션 전체에 걸친 의미적 개념을 파악하고 요약하는 작업에서 성능이 떨어진다.
두 번째가 핵심이다. "이 데이터셋의 주요 주제는 무엇인가" 같은 질문은 청크 몇 개를 꺼내오는 방식으로는 답이 안 나온다.
2. 기반 지식: 그래프 모델과 질의 언어¶
Graph RAG를 실제로 붙이려면 먼저 정해야 하는 선택지들이다.
프로퍼티 그래프와 RDF¶
| 구분 | 프로퍼티 그래프 | RDF |
|---|---|---|
| 표현 | 노드·엣지에 속성 직접 부여, 라벨로 분류 | 주어-술어-목적어 트리플 |
| 식별자 | 내부 ID | URI 기반 표준 식별자 |
| 강점 | 단일 지식 소스에서 단순하고 직관적 | 여러 지식 소스 간 통합과 표준화 |
| 대표 구현 | Neo4j | W3C 표준 계열 |
| 질의 언어 | OpenCypher, Gremlin | SPARQL |
같은 질의를 세 언어로¶
"서울에 사는 사람의 이름"을 각각 이렇게 쓴다. 언어의 성격 차이가 그대로 드러난다.
# Cypher: 시각적 패턴 매칭
MATCH (p:Person)-[:LIVES_IN]->(c:City)
WHERE c.name = "Seoul"
RETURN p.name
# SPARQL: 트리플 패턴
SELECT ?person
WHERE {
?person rdf:type ex:Person .
?person ex:livesIn ex:Seoul .
}
# Gremlin: 명령형 순회
g.V().hasLabel('Person').
out('LIVES_IN').
has('name', 'Seoul').
in('LIVES_IN').
values('name')
Cypher는 그림을 그리듯 선언하고, SPARQL은 사실 패턴을 나열하며, Gremlin은 걸어갈 경로를 명령한다.
Neo4j와 Amazon Neptune¶
| 특성 | Neo4j | Amazon Neptune |
|---|---|---|
| 제공 방식 | AWS 마켓플레이스 | AWS 관리형 서비스 |
| 데이터 모델 | 프로퍼티 그래프 | 프로퍼티 그래프, RDF |
| 질의 언어 | Cypher | Gremlin, SPARQL, OpenCypher |
| 운영 | 사용자 관리 | 완전 관리형 |
| LangChain, LlamaIndex | 둘 다 지원 | 둘 다 지원 |
3. 디자인 패턴 다섯 가지¶
표준 구현이 없는 영역이라 패턴으로 정리한다. 그래프가 파이프라인의 어느 지점에 개입하느냐가 구분 기준이다.
| 패턴 | 그래프의 위치 | 활용 사례 |
|---|---|---|
| 지식 그래프와 의미 기반 클러스터링 | 검색 후 결과를 의미 클러스터로 조직 | 데이터 분석, 지식 발견, 연구 |
| 지식 그래프와 벡터 DB 통합 | 벡터로 찾은 청크 주변의 구조 정보를 그래프가 보강 | 고객 지원, 의미적 검색, 추천 |
| 그래프 강화 하이브리드 검색 | 벡터·키워드·그래프 질의를 병렬 실행 후 융합 | 기업 검색, 문서 검색 |
| 지식 그래프 강화 Q&A 파이프라인 | 벡터 검색 이후 그래프에서 사실을 추가 | 의료, 법률처럼 표준 정보를 함께 실어야 하는 경우 |
| 지식 그래프 기반 질의 확장 | 벡터 검색 이전 그래프에서 개체·관계를 먼저 탐색 | 제품 조회, 금융 보고서 생성 |
뒤의 두 패턴 대비가 특히 유용하다. 그래프를 검색 앞에 두느냐 뒤에 두느냐로 성격이 갈린다. 앞에 두면 질의를 다듬는 도구가 되고, 뒤에 두면 답변에 근거를 붙이는 도구가 된다.
4. RAPTOR: 재귀 요약으로 트리를 쌓는다¶
Stanford, 2024 (arXiv:2401.18059). 그래프가 아니라 트리를 쓴다.
색인은 재귀다. 문서를 약 100토큰 청크로 자르고, SBERT로 임베딩한 뒤 가우시안 혼합 모델로 군집화한다. 소프트 클러스터링이라 한 노드가 여러 군집에 속할 수 있다. 각 군집을 LLM으로 요약해 새 노드를 만들고, 그 요약을 다시 임베딩해 같은 과정을 반복한다. 더 이상 군집이 안 될 때까지 올라가면 다층 트리가 된다. 문서 규모에 선형인 계산 복잡도라고 밝힌다.
청킹에서 문장을 자르지 않는 처리가 눈에 띈다. 토큰 한도를 넘으면 문장 중간을 끊지 않고 통째로 다음 청크로 넘긴다.
검색은 두 가지다.
- 트리 순회: 루트부터 계층마다 상위 k개를 고르고 그 자식으로 내려간다. 계층별 정보량이 균일하게 유지된다.
- 축소 트리: 트리 전체를 한 층으로 눌러 놓고 유사도 순으로 토큰 한도까지 채운다.
실험에서는 축소 트리가 일관되게 나았다. 모든 노드를 동시에 놓고 고르므로 질문에 맞는 세부 수준을 유연하게 잡을 수 있기 때문이라고 설명한다. 계층 구조를 만들어놓고 검색할 때는 평평하게 펴는 쪽이 낫다는 결과라 흥미롭다.
5. Microsoft GraphRAG¶
arXiv:2404.16130. 색인 4단계는 청킹, 개체·관계 추출, 그래프 구축, 커뮤니티 탐지와 요약이다. Leiden으로 계층 분할하고 하위 커뮤니티 요약을 상위 요약 생성에 재사용한다.
이 글에서 새로 얻은 건 검색 모드가 셋이라는 점이다.
정적 글로벌 검색¶
특정 레벨의 커뮤니티 보고서를 전부 가져와 맵-리듀스한다. 맵 단계에서 보고서마다 답변과 관련성 점수를 만들고, 리듀스에서 점수 순으로 통합한다. 단순하지만 토큰을 많이 쓰고 질의와 무관한 보고서까지 들어간다.
동적 글로벌 검색¶
정적 방식의 낭비를 줄인 접근이다. 루트에서 시작해 커뮤니티 보고서의 관련성을 LLM으로 평가하고, 관련성이 낮으면 그 하위 노드까지 통째로 쳐낸다. 높으면 아래로 내려가며 평가를 이어간다. 계층 구조를 가지치기에 쓰는 셈이다.
DRIFT 검색¶
로컬 검색의 한계를 넘으려는 하이브리드다. 3단계로 돈다.
- Primer: 질의를 HyDE로 확장해 재현율을 올린다. 확장된 질의를 임베딩해 커뮤니티 보고서 상위 K개를 고르고, 초기 답변과 후속 질문들을 함께 생성한다.
- Follow-Up: 각 후속 질문에 로컬 검색을 돌려 중간 답변을 만든다. 거기서 다시 질문이 파생될 수 있고, 보통 2회 반복 후 끝낸다.
- Output Hierarchy: 모든 질문과 답변을 원 질의와의 관련성으로 순위 매겨 계층화하고 맵-리듀스로 합친다.
고수준 개요에서 시작해 점차 세부로 내려가는 구조다. 저장소의 Microsoft GraphRAG 해부 노트가 Drift Search를 다루지 않고 넘어갔는데, 그 빈칸이 여기서 메워진다. 두 글을 같이 읽으면 좋다.
자동 튜닝¶
새 도메인 적응을 위한 장치다. 전체 데이터의 약 1%를 샘플로 LLM에 보내 도메인과 페르소나를 식별하고, 그걸로 색인 프롬프트를 자동 생성한다. 기본 개체 유형(인물, 조직, 지역)을 넘어 도메인 특화 개체(화학이면 분자, 반응)를 잡아내는 것이 목적이다.
6. AWS GraphRAG Toolkit¶
awslabs/graphrag-toolkit. LlamaIndex 기반 파이썬 프레임워크다. 그래프 모델을 세 계층으로 나눈 설계가 이 구현의 특징이다.
| 계층 | 노드 | 역할 |
|---|---|---|
| 계통(Lineage) | Source, Chunk | 원본 메타데이터와 텍스트. 출처 추적과 검증 |
| 개체-관계 | Entity, Relation | 실세계 개체와 관계. 키워드 검색의 진입점 |
| 요약 | Topic, Statement, Fact | 추상화 수준별 구조화 |
요약 계층의 역할 분담이 잘 짜여 있다. Topic은 문서 안의 지역 연결성을 담당하고, Fact는 문서 간 글로벌 연결성을 담당한다. 여러 문서에서 언급된 같은 사실을 노드 하나로 합쳐 문서 사이의 다리를 놓는다. Statement는 LLM에 실제로 넘어가는 기본 컨텍스트 단위다.
검색기는 둘이다.
- TraversalBasedRetriever: 청크에서 출발하는 하향식(벡터 유사도로 청크를 찾고 주제, 서술, 사실로 확장)과 키워드에서 출발하는 상향식(개체를 찾고 사실을 거쳐 서술과 주제로 확장)을 함께 쓴다. 서술 재순위화는 TF-IDF와 모델 기반 중 고를 수 있고, 복잡 질의를 하위 질의로 분해하는 옵션도 있다.
- SemanticGuidedRetriever: 서술 임베딩 코사인 유사도, 키워드 매칭 순위, 빔 서치 기반 그래프 탐색 셋을 조합한다.
상향식과 하향식을 둘 다 두는 설계는 ROGRAG 노트의 dual-level 검색과 같은 발상이다.
7. 종합 비교¶
글의 마지막 표가 전체를 압축한다. 네 단계로 나눈 것이 핵심이다.
| 접근법 | 인덱싱 | 사전 검색 | 검색 | 사후 검색 |
|---|---|---|---|---|
| KG + 의미 클러스터링 | 그래프 구축 | 그래프 탐색 | 의미적 클러스터링 | |
| KG + 벡터 DB | 벡터화, 그래프 구축 | 벡터 검색, 그래프 탐색 | ||
| 그래프 강화 하이브리드 | 벡터화, 키워드 색인, 그래프 구축 | 벡터, 키워드, 그래프 | 리랭킹 또는 랭크 퓨전 | |
| KG 강화 Q&A | 벡터화, 그래프 구축 | 청크 벡터 검색, 개체 그래프 탐색 | ||
| KG 질의 확장 | 그래프 구축, 노드 속성 벡터화 | 개체·관계 추출, 질의 확장 | 벡터 검색, 그래프 탐색 | |
| RAPTOR | 벡터화, 클러스터링, LLM 요약, 재귀 구조화 | 질의 벡터화 | 트리 순회 또는 축소 트리 | |
| Microsoft GraphRAG | 개체·관계 추출, 그래프 구축, Leiden, 커뮤니티 요약 | HyDE 질의 확장, 후속 질문 | 정적·동적 글로벌, DRIFT | 맵-리듀스, 출력 계층화 |
| AWS Toolkit | 명제·개체·관계·주제·서술·사실 추출, 그래프 구축, 벡터화 | 키워드 추출, 복잡 질의 분해 | Traversal, SemanticGuided | 서술 재순위화, 다양성, 소스 강화 |
저자가 뽑은 공통점 다섯 가지 중 셋이 특히 눈에 띈다. 거의 모두 하이브리드라는 것, RAPTOR와 두 GraphRAG 모두 계층적 추상화를 쓴다는 것, LLM이 생성뿐 아니라 개체 추출·요약·질의 확장에 두루 쓰인다는 것이다.
읽을 때 감안할 것¶
- 수치가 하나도 없다. 전부 구조 설명이다. 어느 패턴이 어떤 질의에서 얼마나 나은지 정량 근거가 없어서, 선택 근거로 삼기에는 부족하다. 지형도로만 쓰는 것이 맞다.
- 비용 논의가 빠져 있다. 인덱싱 단계에 LLM 호출이 대량으로 들어가는 방식들인데 그 비용을 다루지 않는다. Microsoft GraphRAG의 커뮤니티 요약이나 AWS 툴킷의 명제 추출은 문서량에 비례해 호출이 늘어난다.
- AWS 툴킷 비중이 크다. 섹션 4가 글의 3분의 1가량이고 그래프 DB 비교도 AWS 기준이다. 저자 관심사가 반영된 구성이라 보고 읽는 편이 낫다.
- 제목만큼 전부는 아니다. LightRAG, HippoRAG, KAG처럼 자주 인용되는 구현이 빠져 있다. 저장소에 있는 ROGRAG나 LogicRAG 계열의 문제의식도 다루지 않는다.
- 2025년 4월 기준이다. GraphRAG는 변화가 빠른 영역이라 세부는 지금과 다를 수 있다.
가져갈 지점¶
- 저장소의 GraphRAG 노트들을 꿰는 지도
Microsoft GraphRAG 해부가 코드 레벨 각론이고, LogicRAG는 사전 그래프를 없애자는 반론이며, ROGRAG는 검색을 여러 겹으로 쌓자는 개선안이다. 이 글은 그 셋이 어느 자리에 있는지 보여주는 좌표계다.
- 그래프를 검색 앞에 둘지 뒤에 둘지 먼저 정한다
패턴 다섯 중 넷째와 다섯째의 대비가 설계 판단에 바로 쓰인다. 질의를 다듬는 데 쓸 것인지, 답변에 근거를 붙이는 데 쓸 것인지에 따라 필요한 그래프 품질과 지연 예산이 달라진다.
- DRIFT의 후속 질문 생성 구조
Primer에서 초기 답변과 후속 질문을 함께 만들고 2회 반복 후 종료하는 방식은, 반복 검색의 종료 조건을 정하는 실용적인 해법이다. LogicRAG의 sampling without replacement와 같은 문제를 다른 방식으로 푼다.
- Fact 노드로 문서 간 다리를 놓는 발상
AWS 툴킷이 여러 문서의 같은 사실을 노드 하나로 합치는 방식은 개체 중의성 문제를 우회하는 한 가지 답이다. Microsoft GraphRAG가 개체 중의성 해소를 하지 않는다는 점과 대비해서 볼 만하다.
결론¶
Graph RAG를 처음 훑을 때 읽기 좋은 지도다. 그래프 모델 선택부터 질의 언어, 디자인 패턴, 주요 구현까지 한 번에 늘어놓았고, 마지막 비교표는 따로 떼어 참조할 값어치가 있다.
다만 수치와 비용이 없어서 이것만으로 무엇을 쓸지 정할 수는 없다. 후보를 좁힌 뒤에는 각 논문과 구현체로 내려가야 한다. 지도이지 판단 근거는 아니다.