Graph RAG는 검색 증강 생성(RAG)의 한계를 극복하기 위해 지식을 벡터 청크 대신 연결된 그래프로 구조화하는 방법론이다. 전통적인 RAG가 “의미적으로 유사한 청크를 찾아라”라고 묻는다면, Graph RAG는 “관계를 따라 연결된 지식을 탐색하라”고 묻는다. 단일 문서에 답이 없는 멀티홉 질문에 특히 효과적이다.
전통적 RAG의 한계
전통 RAG는 지식을 독립된 청크의 평면 집합으로 취급한다. 각 청크는 고립되어 있고, 검색은 의미적 유사도에만 의존한다. 이 방식은 다음 상황에서 실패한다.
- 멀티홉 질문: “SuperApp을 배포할 때 소스 코드를 공개해야 하는가?”는 (1) SuperApp이 Lib-X를 사용하고, (2) Lib-X는 GPL v2 라이선스이며, (3) GPL v2는 소스 공개를 요구한다는 세 문서를 연결해야 답할 수 있다.
- 분산 컨텍스트: 관련 정보가 여러 문서에 흩어져 있을 때 단일 청크 검색으로는 불충분하다.
- 구조적 관계 손실: 개념 간 명시적 관계(인과·의존·포함)를 벡터 유사도가 포착하지 못한다.
Graph RAG의 핵심 구조
그래프 구성 요소
- 노드(Node): 청크, 엔티티, 개념 (예: 소프트웨어 컴포넌트, 라이선스, 제약 조건)
- 엣지(Edge): 노드 간 관계 (예: USES, GOVERNED_BY, IMPLIES)
라이선스 컴플라이언스 예시:
SuperApp --[USES]--> Lib-X --[GOVERNED_BY]--> GPL_v2 --[IMPLIES]--> Must_Disclose_Source
--[USES]--> FFmpeg --[GOVERNED_BY]--> LGPL_v2.1 --[IMPLIES]--> Allow_Library_Replacement파이프라인 흐름
| 단계 | 전통 RAG | Graph RAG |
|---|---|---|
| 문서 처리 | 청크 분리 → 벡터 임베딩 | 청크 분리 → 엔티티·관계 추출 |
| 저장 | 벡터 DB | 그래프 DB (Neo4j 등) |
| 검색 | 쿼리 임베딩 → 코사인 유사도 | 쿼리 → 시작 노드 식별 → 멀티홉 그래프 탐색 |
| 결과 | 유사 청크 top-k | 구조적으로 연결된 컨텍스트 집합 |
멀티홉 그래프 탐색
“SuperApp”으로 시작하는 쿼리에 대해 두 방식의 검색 결과를 비교하면 차이가 명확하다.
전통 RAG: doc1만 반환 (“SuperApp” 키워드 포함)
Graph RAG: 관계 체인을 따라 6개 문서 반환
SuperApp → [USES] → Lib-X → [GOVERNED_BY] → GPL_v2 → [IMPLIES] → Must_Disclose_Source
→ [USES] → FFmpeg → [GOVERNED_BY] → LGPL_v2.1 → [IMPLIES] → Allow_Library_Replacement첫 번째 노드 이후 어떤 문서도 “SuperApp”이라는 키워드를 포함하지 않아도 탐색된다.
PageRank 유추
Graph RAG와 구글의 PageRank 알고리즘은 같은 원리적 도약을 공유한다. 초기 검색 엔진이 키워드 빈도에만 의존했다면, Google은 웹 링크 구조(하이퍼링크 = 신뢰 신호)를 활용해 품질을 혁신했다. Graph RAG도 마찬가지로 텍스트 표면 유사도를 넘어 지식 그래프의 관계 위상(topology)을 활용해 검색 품질을 높인다.
LLM과의 통합
Graph RAG는 LLM 앞에 구조적 추론 레이어를 삽입한다.
- 쿼리 해석 → 관련 엔티티 식별
- 그래프 탐색으로 멀티홉 컨텍스트 수집
- 직접 관련 + 구조적으로 연결된 정보를 통합해 LLM에 전달
결과: LLM이 더 풍부하고 일관된 컨텍스트를 바탕으로 답변을 생성해 할루시네이션이 줄고 멀티스텝 추론의 신뢰도가 높아진다.
Graph RAG가 특히 유용한 경우
- 교차 참조가 많은 기술 문서
- 컴포넌트 간 의존 관계가 있는 API 에코시스템
- 법률·규정 텍스트 (조문 간 참조)
- 기업 지식 베이스
- 다단계 추론이 필요한 과학 논문
- 소프트웨어 라이선스 컴플라이언스
구현 기술 스택
| 레이어 | 선택지 |
|---|---|
| 그래프 DB | Neo4j (프로덕션), NetworkX (프로토타입) |
| 엔티티 추출 | LLM 기반 또는 regex 패턴 매칭 |
| 그래프 탐색 | BFS/DFS, 관계 타입 필터링 |
| 임베딩 (선택) | Gemini Embedding 2, OpenAI Embedding 3 |
엔티티와 관계 타입 설계가 시스템 품질을 결정한다. 도메인에 어떤 개념(노드)과 관계(엣지)가 존재하는지 사전에 명확히 정의해야 한다.
관련 문서
- rag — 전통적 RAG 기술 개요 및 고급 기법
- lightrag — 지식 그래프 기반의 그래프 RAG 구현체
- mass-rag — 멀티 에이전트 합성 RAG 프레임워크
- skill-rag — 실패 상태 인식 검색 증강 에이전트
- gemini-embedding-2 — 멀티모달 임베딩으로 그래프 노드 표현 강화
참고 자료
- Graph RAG explained: Relationship-aware retrieval — LogRocket Blog (2026-04-29)
- rosdec/graph_rag — GitHub 예제 코드