Ch 9. GraphRAG란 — 아키텍처와 인덱싱¶
이 챕터에서 배우는 것
- GraphRAG의 두 단계 — 인덱싱(오프라인)과 쿼리(온라인)
- 인덱싱이 하는 일: 그래프 구축 → 커뮤니티 탐지 → 커뮤니티 요약
- 왜 인덱싱이 비싼가, 그리고 그 비용을 정당화하는 질문 유형
- Microsoft GraphRAG 파이프라인을 큰 그림으로
1. 개념 — GraphRAG는 두 단계다¶
Ch 1에서 GraphRAG를 "그래프를 RAG에 붙여 연결을 검색 가능하게 만든 것"이라 했다. 구조는 벡터 RAG와 마찬가지로 오프라인 인덱싱과 온라인 쿼리 두 단계로 갈린다. 다른 건 인덱싱이 임베딩만 만드는 게 아니라 그래프와 그 요약까지 만든다는 점이다.
[ 인덱싱 (오프라인, 한 번 · 비쌈) ]
문서 → 청크 → (LLM) 엔티티·관계 추출 → 지식 그래프
→ 커뮤니티 탐지 → (LLM) 커뮤니티별 요약
[ 쿼리 (온라인, 매 질문) ]
질문 → 관련 엔티티/커뮤니티 찾기 → 그래프로 컨텍스트 모으기 → LLM 답변
2. 인덱싱이 하는 일¶
세 단계가 핵심이다.
① 그래프 구축. Part 3에서 한 그대로 — 청크에서 엔티티·관계를 뽑아 지식 그래프를 만든다. 이게 GraphRAG의 뼈대다.
② 커뮤니티 탐지. 그래프를 촘촘히 연결된 덩어리(커뮤니티)로 나눈다. Leiden 같은 알고리즘이 "서로 많이 연결된 노드들"을 한 묶음으로 찾는다. 한 커뮤니티는 대략 하나의 주제·집단에 대응한다(예: "아스피린 관련 약·성분·질병" 묶음).
③ 커뮤니티 요약. 각 커뮤니티를 LLM이 미리 요약해 둔다. 이게 Ch 1에서 말한 "전역 질문"의 비밀이다 — "전체 주제는?" 같은 질문이 오면, 모든 문서를 다시 읽는 대신 미리 만든 커뮤니티 요약들을 종합하면 된다.
3. 왜 비싼가, 그리고 언제 그만한가¶
인덱싱은 비싸다. 전체 코퍼스를 LLM으로 훑어 엔티티·관계를 뽑고, 커뮤니티마다 요약까지 생성하니, 문서량에 비례해 LLM 호출이 쌓인다. 벡터 RAG의 인덱싱(임베딩만)보다 훨씬 무겁다.
그래서 GraphRAG는 공짜 점심이 아니다. 질문이 대부분 "비슷한 문서 찾기"라면 이 비용은 낭비다. 인덱싱 비용을 정당화하는 건 Ch 1의 그 질문들 — 멀티홉, 종합, 그리고 특히 전역 요약이다. 이 가치/비용 판단은 Ch 11에서 직접 비교하고, 비용 관리는 Part 5의 프로덕션 챕터에서 다룬다.
Microsoft GraphRAG
이 인덱싱→커뮤니티→요약 파이프라인을 대중화한 게 Microsoft Research의 GraphRAG(2024)다. 오픈소스 구현이 있고, 많은 후속 도구가 이 구조를 따른다. 세부는 구현마다 다르지만 "그래프 + 커뮤니티 요약"이라는 골격은 공통이다.
4. 자주 깨지는 포인트¶
인덱싱을 매번 다시 돌린다. 인덱싱은 오프라인 배치다. 문서가 조금 바뀔 때마다 전체를 재인덱싱하면 비용이 폭발한다. 증분 갱신 전략이 필요하다(→ Part 5, 프로덕션).
커뮤니티 요약을 건너뛴다. 그래프만 만들고 커뮤니티 요약을 안 하면, 전역 질문이라는 GraphRAG의 가장 큰 강점을 버리는 것이다. 멀티홉만 필요하면 괜찮지만, "전체 주제" 류 질문이 있다면 요약이 핵심이다.
5. 연습 & 다음 챕터¶
확인 문제¶
- 내 도메인의 질문을 "로컬(특정 엔티티 주변)"과 "글로벌(전체 종합)"으로 나눠 보라. 어느 쪽이 더 많은가?
- 인덱싱 비용이 문서량에 비례한다면, 어떤 코퍼스 규모·갱신 빈도에서 GraphRAG가 부담스러워지는가?
다음¶
인덱스가 준비됐다면, 질문이 왔을 때 그래프를 어떻게 검색하나? 로컬·글로벌·커뮤니티 전략으로 간다 → Ch 10.
원전¶
- Microsoft Research (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130
- Traag et al. (2019). From Louvain to Leiden: guaranteeing well-connected communities. (community detection)