[AI설계] GraphRAG - 지식그래프로 확장한 RAG

RAG의 한계에서 출발

RAG는 질문과 벡터가 "직접 비슷한" 문서만 찾는다.
그런데 실제 질문은 종종 여러 단계를 거쳐야 답이 나오는 경우가 있다.

e.g) "해외배송 상품을 환불하면 위약금은 얼마인가?

1. 먼저 "해외배송 상품의 환불 정책이 무엇인지"를 찾고
2. 그다음 "그 환불 정책이 참조하는 위약금 산정 조항"을 찾아야 한다

이 두 조각이 임베딩 공간에서 서로 가깝지 않을 수 있다. "위약금 산정 조항"이라는 텍스트는 "해외배송 환불 정책"이라는 텍스트와 단어도 다르고 문맥도 다를 수 있다.
벡터 검색만으로는 이런 "간접적으로 연결된" 정보를 놓치기 쉽다.

GraphRAG는 문서 조각들 사이의 명시적인 관계(어떤 조항이 어떤 조항을 참조하는지, 어떤 정책이 어떤 정책을 인용하는지)를 그래프로 미리 저장해두고, 검색할 때 이 그래프를 따라가며 관련 정보를 추가로 찾아낸다.

지식그래프란

노드(node)와 엣지(edge)로 이루어진 구조. 여기서는 노드가 문서 조각(정책 조항 등)이고, 엣지가 "이 조항이 저 조항을 참조한다" 같은 관계다. 이 구조를 저장하고 탐색하는 데 그래프 데이터베이스를 쓴다.

e.g) PostgreSQL 확장인 Apache AGE는 그래프를 Cypher라는 질의언어로 다룰 수 있게 해준다.

MATCH (a:조항)-[:참조]->(b:조항) WHERE a.id = $start RETURN b

이런 식으로 "이 조항에서 참조로 연결된 다른 조항들을 찾아라"는 질의를 던질 수 있다.

동작 방식

1. 진입(entry) 단계: 일반 RAG처럼 벡터/키워드 검색으로 질문과 직접 관련된 조항을 먼저 찾음(예: 점수 1.0으로 취급)
2. 확장(expand) 단계: 찾은 조항에서 그래프를 따라 1~2단계(multi-hop) 떨어진 연결 조항들도 추가로 가져옴(예: 점수 0.5로 취급 — 직접 검색된 것보다는 신뢰도를 낮게 매김)
3. 확장 범위가 너무 넓어지지 않도록 가져올 연결 노드 수에 상한(예: 최대 6개)을 둠

이렇게 모은 "직접 검색 결과 + 그래프로 확장한 결과"를 합쳐서 LLM에게 근거로 넘긴다.

확장 범위: multi-hop

"1-hop"은 진입 노드에서 엣지 하나만 따라간 직접 이웃, "2-hop"은 그 이웃의 이웃까지 가는 것이다.

hop 수를 $h$, 한 노드의 평균 연결 수(차수, degree)를 $D$라 하면, 이론상 도달 가능한 노드 수는 최대 $D^h$로 늘어나는데,
KMeans나 룰베이스에서 봤던 "경우의 수가 기하급수적으로 늘어나는" 패턴이 여기서도 똑같이 나타난다.

그래서 실전에서는 보통 2-hop을 넘기지 않고, 위에서 말한 "최대 6개" 같은 상한을 같이 걸어서 폭주를 막는다.

왜 점수를 다르게 매기는가

진입 노드(질문과 직접 관련)는 확실하니까 점수 1.0, 확장 노드(간접적으로 연결됨)는 관련성이 약할 수 있으니 점수 0.5로 낮춰서 LLM에게 "이건 직접 관련된 게 아니라 참고로 따라온 정보"라는 신호를 준다.

이후 LLM이 답변에서 어떤 근거를 더 신뢰할지 판단하는 데 도움이 된다.

그래프 구축 방법

GraphRAG를 쓰려면 "어떤 노드가 어떤 노드와 연결되는가"를 미리 정해서 그래프를 만들어야 한다.
이 과정이 GraphRAG의 핵심 선행 작업.

규칙 기반 추출

문서의 구조나 언어 패턴으로 관계를 추출한다.

• "제3조 제2항에 의하면..." → "제3조 제2항"을 참조 관계로 추출
• "위 조항에서 정한 바에 따라..." → 앞에서 언급된 조항을 참조
• 정규식 또는 NLP 파서(spaCy 등)로 "참조", "인용", "준용" 같은 키워드를 찾아 엣지로 변환

장점: 빠르고 저렴, 결정적(같은 입력 → 같은 그래프). 단점: 명시적으로 드러난 참조만 잡고 암묵적 관계는 놓침.

LLM 기반 추출

LLM에게 문서를 읽게 하고 "이 문서에서 중요한 엔티티와 관계를 추출해줘"라고 지시한다.

입력: "해외배송 상품의 환불은 수령일로부터 7일 이내에 신청해야 하며,
      위약금은 상품가격의 10%로 한다."

LLM 출력:
- 노드: [해외배송 환불 정책, 위약금 규정]
- 엣지: 해외배송 환불 정책 --[위약금 기준 참조]--> 위약금 규정

• 장점: 명시적이지 않은 암묵적 관계까지 포착 가능.
• 단점: 비용이 크고(문서마다 LLM 호출), 결과가 일관적이지 않을 수 있음.

실전에서는 두 방식을 섞거나(규칙으로 기본 그래프를 만들고 LLM으로 보완), 도메인 특성에 따라 선택한다.

Microsoft GraphRAG 방식 — 커뮤니티 기반

Microsoft에서 공개한 GraphRAG는 위에서 설명한 "진입 + 확장" 방식과 다른 접근법을 쓴다.

핵심 아이디어: 그래프에서 연결이 밀한 노드들을 커뮤니티(community)로 묶고, 각 커뮤니티를 LLM으로 요약해서 미리 저장해둔다.

그래프 구축 단계:
문서 → LLM으로 엔티티·관계 추출 → 그래프 생성
→ 커뮤니티 감지(Leiden 알고리즘 등)
→ 각 커뮤니티 요약 LLM으로 생성 → 저장

검색 단계:
질문 → 관련 커뮤니티 요약들을 검색 → LLM에 넣어 답변 생성

이 방식이 유리한 상황: "전체 문서에 걸쳐 종합적인 이해가 필요한 질문"(Global Query).

e.g) "이 약관에서 소비자 보호 관련 조항들의 공통점은 무엇인가?"
→ 벡터 검색으로 특정 조항 하나를 찾는 게 아니라, 전체를 아울러 요약해야 하는 경우.

Local Query vs Global Query

	Local Query	Global Query
예시	"해외배송 환불 기간은?"	"전체 약관에서 소비자 보호 원칙은?"
방식	벡터 검색 + 그래프 확장	커뮤니티 요약 활용
답변 범위	특정 조항 몇 개	문서 전체의 흐름
GraphRAG 적용	이 글에서 주로 다룬 방식	Microsoft GraphRAG가 강점

비용과 트레이드오프

• 속도·복잡도: 그래프 탐색을 위한 추가 질의가 필요해서 일반 RAG보다 느리고 복잡하다
• 선행 작업 필요: 문서를 미리 분석해서 참조 관계를 추출하고 그래프로 저장하는 별도 파이프라인이 선행되어야 한다
• 적용 도메인: 간접 연결이 자주 중요한 도메인(정책 문서처럼 조항끼리 참조가 많은 경우)에만 선택적으로 적용한다 — 모든 RAG 시스템에 쓰는 게 아니다

정리

• GraphRAG는 RAG에 지식그래프 멀티홉 탐색을 더해서, 벡터로는 안 가깝지만 그래프로는 연결된 정보를 찾아냄
• 진입(직접 검색) + 확장(그래프 탐색) 두 단계로 동작하고, 확장 노드는 점수를 낮춰서 "간접 정보"라는 신호를 LLM에 전달
• hop 수가 늘수록 도달 가능한 노드 수가 기하급수적으로 늘어서 보통 2-hop 이내로 제한
• 그래프 구축이라는 선행 작업이 필요해서, 간접 연결이 자주 중요한 도메인에 선택적으로 적용

---

RAG와 GraphRAG는 모두 "검색→LLM"이라는 단일 경로였다. 그런데 모든 질문에 똑같이 무거운 처리(비싼 모델, 긴 검색)를 쓰는 건 비효율적이다.

쉬운 질문은 가볍게, 어려운 질문만 무겁게 처리하고 싶다. 이걸 가능하게 하는 설계가 신뢰도 기반 에스컬레이션이다.