GraphRAG vs 기본 RAG: 지식 그래프 기반 검색 증강의 실전 적용 가이드

AI

GraphRAG지식 그래프RAG검색 증강 생성LLM

이 글은 누구를 위한 것인가

  • 기존 RAG 시스템의 답변 품질에 한계를 느끼는 AI 엔지니어
  • 엔터프라이즈 문서의 복잡한 관계를 추론할 수 있는 RAG를 구축하려는 팀
  • GraphRAG를 들었는데 기존 RAG와 무엇이 다른지 이해하고 싶은 개발자

들어가며

기본 RAG의 한계는 명확하다. "A와 B의 관계는?"이나 "전체 문서에서 가장 중요한 테마는?"과 같은 관계적 질문에 약하다. 벡터 유사도 검색은 개별 청크를 찾는 데는 좋지만, 문서 전체를 아우르는 패턴을 파악하지 못한다.

Microsoft Research가 2024년 공개한 GraphRAG는 이 문제를 지식 그래프로 해결한다. 문서에서 엔티티와 관계를 추출하여 그래프를 구성하고, 이를 기반으로 더 복잡한 쿼리에 답할 수 있게 한다.

이 글은 bluefoxdev.kr의 RAG 시스템 설계 가이드 를 참고하고, GraphRAG 실전 적용 관점에서 확장하여 작성했습니다.


1. 기본 RAG vs GraphRAG 핵심 차이

1.1 처리 방식 비교

[기본 RAG]
문서 → 청크 분할 → 임베딩 → 벡터 DB
쿼리 → 유사 청크 검색 → LLM 답변

[GraphRAG]
문서 → 엔티티/관계 추출 → 지식 그래프 구성
              ↓
         커뮤니티 탐지 → 커뮤니티 요약 생성
              ↓
쿼리 → 로컬/글로벌 검색 → LLM 답변

1.2 질문 유형별 성능 비교

질문 유형기본 RAGGraphRAG
사실 검색 "X의 설명은?"★★★★★★★★★☆
관계 추론 "A와 B의 관계는?"★★☆☆☆★★★★★
글로벌 요약 "전체 트렌드는?"★★☆☆☆★★★★★
다중 홉 추론★★☆☆☆★★★★☆
속도★★★★★★★☆☆☆
비용★★★★★★★☆☆☆

2. GraphRAG 작동 원리

2.1 인덱싱 파이프라인

# Microsoft GraphRAG 설정 예시
# settings.yml

encoding_model: cl100k_base
skip_workflows: []

llm:
  api_key: $GRAPHRAG_API_KEY
  type: openai_chat
  model: gpt-4o
  model_supports_json: true

parallelization:
  stagger: 0.3
  num_threads: 50

async_mode: threaded

embeddings:
  async_mode: threaded
  llm:
    api_key: $GRAPHRAG_API_KEY
    type: openai_embedding
    model: text-embedding-3-small

chunks:
  size: 1200
  overlap: 100
  group_by_columns: [id]

entity_extraction:
  prompt: "prompts/entity_extraction.txt"
  entity_types: [organization, person, geo, event]
  max_gleanings: 1

2.2 커뮤니티 탐지

GraphRAG는 Leiden 알고리즘으로 엔티티 그래프에서 커뮤니티(밀접하게 연결된 엔티티 그룹)를 탐지한다. 각 커뮤니티에 대한 요약이 생성된다.

[지식 그래프 예시: 테크 뉴스 문서]

커뮤니티 1: AI 기업
  엔티티: OpenAI, Anthropic, Google DeepMind
  관계: 경쟁, 기술 제휴, 인재 이동

커뮤니티 2: LLM 모델
  엔티티: GPT-4, Claude, Gemini
  관계: 벤치마크 비교, 출시 순서

커뮤니티 3: 투자
  엔티티: Microsoft, SoftBank, a16z
  관계: 투자 금액, 투자 시기

3. 로컬 vs 글로벌 검색

3.1 로컬 검색

특정 엔티티나 사실에 관한 질문. 관련 엔티티와 그 관계를 직접 검색한다.

# GraphRAG 로컬 검색
import graphrag.query.structured_search.local_search as local

search_engine = local.LocalSearch(
    llm=llm,
    context_builder=context_builder,
    token_encoder=token_encoder,
    llm_params={"max_tokens": 2000},
    context_builder_params={"top_k_mapped_entities": 10},
)

result = await search_engine.asearch(
    "Anthropic의 주요 투자자들은 누구인가?"
)

3.2 글로벌 검색

전체 말뭉치에 걸친 광범위한 패턴 파악. 커뮤니티 요약을 활용한다.

# GraphRAG 글로벌 검색
import graphrag.query.structured_search.global_search as global_s

search_engine = global_s.GlobalSearch(
    llm=llm,
    context_builder=context_builder,
    token_encoder=token_encoder,
    max_data_tokens=12000,
    map_llm_params={"max_tokens": 1000},
    reduce_llm_params={"max_tokens": 2000},
)

result = await search_engine.asearch(
    "2024~2026년 AI 업계의 주요 트렌드는 무엇인가?"
)

4. 구축 비용과 현실적 고려사항

4.1 비용 구조

GraphRAG의 가장 큰 단점은 높은 인덱싱 비용이다.

문서 1,000페이지 인덱싱 기준 (GPT-4o 사용):

기본 RAG 인덱싱: $1~5
GraphRAG 인덱싱: $20~100
  (엔티티 추출 + 관계 추출 + 커뮤니티 요약 생성)

쿼리 비용:
기본 RAG: $0.01~0.05 / 쿼리
GraphRAG 로컬: $0.05~0.20 / 쿼리
GraphRAG 글로벌: $0.20~1.00 / 쿼리

4.2 GraphRAG가 적합한 경우

  • ✅ 복잡한 엔터프라이즈 문서 (계약서, 규정집, 기술 문서)
  • ✅ 엔티티 간 관계 추론이 핵심인 쿼리
  • ✅ 전체 문서의 패턴 파악이 필요한 경우
  • ❌ 단순한 사실 검색이 주요 사용 사례
  • ❌ 비용에 민감한 대량 쿼리
  • ❌ 자주 업데이트되는 문서 (인덱싱 재실행 필요)

5. 하이브리드 접근: RAG + GraphRAG

실무에서는 두 방식을 혼합하는 것이 가장 효율적이다.

async def hybrid_search(query: str) -> str:
    # 쿼리 분류
    query_type = classify_query(query)
    
    if query_type == "factual":
        # 단순 사실 → 기본 벡터 RAG
        return await vector_rag.search(query)
    elif query_type == "relational":
        # 관계 질문 → GraphRAG 로컬
        return await graph_rag.local_search(query)
    elif query_type == "analytical":
        # 전체 분석 → GraphRAG 글로벌
        return await graph_rag.global_search(query)
    else:
        # 기본 → 벡터 RAG 우선, 품질 낮으면 GraphRAG
        result = await vector_rag.search(query)
        if result.confidence < 0.7:
            return await graph_rag.local_search(query)
        return result

마무리: 언제 GraphRAG를 선택해야 하나

GraphRAG는 만능 해결책이 아니다. 복잡한 관계 추론이 필요하고, 비용을 감당할 수 있는 경우에만 선택해야 한다.

대부분의 엔터프라이즈 RAG 프로젝트는 먼저 기본 RAG로 시작하고, 품질 한계에 부딪혔을 때 GraphRAG를 검토하는 것이 현실적인 접근이다.