GraphRAG로 지식 그래프 기반 RAG 구현하기
표준 RAG 파이프라인은 청크(chunk) 단위로 문서를 분할하고, 각 청크를 임베딩 벡터로 변환한 뒤 질의와 코사인 유사도가 높은 청크를 검색해 LLM 컨텍스트에 주입합니다.
목차
- 개요
- GraphRAG의 핵심 구조와 동작 원리
- 지식 그래프 구축과 엔티티 추출
- GraphRAG 검색 파이프라인 구현
- 벡터 RAG와의 성능 비교 및 트레이드오프
- 운영 환경 적용 시 고려사항
- 맺음말
개요
문제 배경: 기존 RAG의 한계
**RAG(Retrieval-Augmented Generation)**는 LLM이 학습 데이터에 없는 최신 정보나 기업 내부 문서를 답변에 활용할 수 있게 해주는 기법으로, 현재 AI 애플리케이션에서 가장 보편적인 패턴 중 하나입니다. 그러나 수백만 건의 문서를 다루는 엔터프라이즈 환경에 표준 벡터 RAG를 적용하면, 특정 유형의 질문에서 반복적으로 답변 품질이 저하되는 현상을 경험하게 됩니다. "이 회사에서 가장 핵심적인 기술 역량은 무엇인가?", "이 프로젝트에서 어떤 부서가 가장 많이 협력했는가?"처럼 여러 문서에 걸친 관계와 패턴을 종합해야 하는 질문이 대표적인 예입니다. 벡터 유사도만으로는 이런 전역적 맥락을 포착하기 어렵습니다.
GraphRAG는 이 문제를 해결하기 위해 Microsoft Research가 2024년 공개한 접근법으로, 문서 말뭉치에서 자동으로 지식 그래프를 구축하고 이를 검색의 기반으로 활용합니다. 단순히 벡터 인덱스에 그래프를 추가하는 방식이 아니라, 엔티티(Entity)와 관계(Relationship)를 명시적으로 추출해 계층적 커뮤니티 구조로 조직화하는 것이 핵심입니다. 이 글에서는 GraphRAG의 내부 동작 방식부터 직접 구현하는 방법, 그리고 운영 환경에서 유의해야 할 사항까지 상세히 다룹니다.
기존 방식의 한계
표준 RAG 파이프라인은 청크(chunk) 단위로 문서를 분할하고, 각 청크를 임베딩 벡터로 변환한 뒤 질의와 코사인 유사도가 높은 청크를 검색해 LLM 컨텍스트에 주입합니다. 이 구조는 지역적(local) 질문—특정 개념이나 사실을 찾는—에는 효과적이지만, 다음과 같은 상황에서 한계를 드러냅니다.
첫째, 암묵적 관계 추론이 어렵습니다. "A 기술이 B 시스템에 어떤 영향을 미쳤는가?"처럼 두 엔티티 간의 관계가 여러 문서에 분산되어 있는 경우, 단일 청크 검색으로는 전체 맥락을 파악하기 어렵습니다. 벡터 공간에서 두 개념이 가깝더라도, 그 관계의 방향성과 강도는 표현되지 않습니다.
둘째, 전역적 요약 질문에 취약합니다. "문서 전체에서 가장 자주 등장하는 테마는 무엇인가?"처럼 말뭉치 전체를 아우르는 질문은, top-k 청크 검색 방식으로는 근본적으로 대응하기 어렵습니다. GraphRAG는 커뮤니티 요약(community summary)이라는 개념으로 이 문제를 다룹니다.
GraphRAG의 핵심 구조와 동작 원리
지식 그래프와 커뮤니티 계층
GraphRAG의 근간은 **지식 그래프(Knowledge Graph)**입니다. 지식 그래프는 현실 세계의 개체와 그 관계를 노드와 엣지로 표현하는 데이터 구조로, 오래전부터 온톨로지 기반 시스템에서 사용되어 왔습니다. GraphRAG가 기존 지식 그래프 접근법과 다른 점은, 정적인 스키마를 미리 정의하지 않고 LLM이 문서에서 동적으로 엔티티와 관계를 추출한다는 점입니다. 이 방식은 도메인 전문가가 없어도 대규모 비정형 텍스트에서 구조화된 지식 그래프를 자동으로 만들 수 있게 해줍니다.
지식 그래프가 구축되면, GraphRAG는 Leiden 알고리즘 기반의 커뮤니티 탐지를 적용해 그래프를 계층적으로 클러스터링합니다. 가장 세밀한 수준(Level 0)에서부터 전체 말뭉치를 포괄하는 수준(Level N)까지 여러 계층의 커뮤니티가 형성됩니다. 각 커뮤니티에는 LLM이 생성한 요약 리포트가 붙어, 글로벌 검색 시 이 요약들을 활용합니다.
Leiden 알고리즘으로 탐지된 커뮤니티들이 계층을 형성하고, 각 수준의 커뮤니티에 LLM 요약이 붙어 전역 질문에 대응하는 것이 GraphRAG의 핵심 구조입니다.
로컬 검색과 글로벌 검색
GraphRAG는 두 가지 검색 모드를 제공합니다. **로컬 검색(Local Search)**은 특정 엔티티나 개념에 집중하는 질문에 활용됩니다. 질의에서 관련 엔티티를 찾고, 해당 엔티티와 직접 연결된 관계, 속한 커뮤니티 요약, 그리고 원문 텍스트 청크를 함께 컨텍스트로 구성합니다. 벡터 검색과 그래프 탐색을 결합하기 때문에, 단순 벡터 RAG보다 훨씬 풍부한 맥락을 LLM에 제공할 수 있습니다.
**글로벌 검색(Global Search)**은 커뮤니티 요약 리포트를 활용해 말뭉치 전체에 대한 추상적 질문에 답합니다. 모든 커뮤니티 요약에 대해 중간 답변을 생성하고(map), 이를 다시 취합해 최종 답변을 만드는(reduce) map-reduce 패턴을 따릅니다. 단일 top-k 검색으로는 불가능했던 전역적 통찰이 가능한 이유입니다.
질의 유형에 따라 로컬 검색과 글로벌 검색을 분기하며, 두 경로 모두 지식 그래프를 통해 풍부한 컨텍스트를 구성한다는 점이 핵심입니다.
엔티티와 관계 스키마
GraphRAG에서 추출되는 데이터는 세 가지 핵심 요소로 구성됩니다. **엔티티(Entity)**는 이름, 타입(조직·인물·위치·기술 등), 설명으로 구성됩니다. **관계(Relationship)**는 두 엔티티 간의 연결로, 소스·타겟·설명·가중치를 가집니다. **텍스트 청크(Text Unit)**는 엔티티와 관계가 추출된 원문 문단으로, 엔티티와 양방향으로 연결되어 있어 근거 추적이 가능합니다.
이 세 가지가 상호 참조됨으로써 "어떤 엔티티가 어떤 문서에서 어떤 관계로 등장했는가"를 완전히 추적할 수 있는 구조가 만들어집니다. 이는 할루시네이션 검증과 출처 인용에 직접적으로 활용됩니다.
| 요소 | 속성 | 역할 |
|---|---|---|
| Entity | name, type, description | 지식 그래프 노드, 벡터 인덱스 대상 |
| Relationship | source, target, description, weight | 지식 그래프 엣지, 관계 강도 |
| Text Unit | id, text, entity_ids | 원문 청크, 근거 추적 |
| Community Report | level, title, summary, findings | 커뮤니티 요약, 글로벌 검색 대상 |
지식 그래프 구축과 엔티티 추출
LLM 기반 정보 추출
지식 그래프 구축의 첫 단계는 원문 텍스트에서 엔티티와 관계를 추출하는 것입니다. GraphRAG는 이 과정에 LLM을 사용하며, 이것이 전통적인 NER(Named Entity Recognition) 방식과 가장 크게 다른 점입니다. 사전 정의된 엔티티 타입에만 국한되지 않고, LLM이 문맥을 이해해 도메인에 맞는 엔티티를 유연하게 추출합니다. 예를 들어 법률 문서에서는 "판례", "법조문", "당사자"가, 기술 문서에서는 "API", "라이브러리", "아키텍처 패턴"이 자동으로 엔티티로 인식됩니다.
추출 과정은 **글리밍(gleaning)**이라는 기법을 통해 품질을 높입니다. 첫 번째 추출 후 LLM에게 "놓친 엔티티가 있는가?"를 다시 묻는 반복적 검증 단계를 거칩니다. 이 방식이 단순 one-shot 추출보다 엔티티 완결성을 의미 있게 높인다는 것이 Microsoft의 내부 실험 결과입니다. 다만 각 청크마다 최소 두 번의 LLM 호출이 발생하므로, 대규모 말뭉치에서는 토큰 비용이 상당히 누적됩니다.
글리밍 루프를 통해 단일 청크에서 최대한 많은 엔티티와 관계를 추출하고, 이를 전체 지식 그래프에 점진적으로 누적합니다.
엔티티 해소와 그래프 정규화
동일한 실체가 문서에 따라 다양한 이름으로 등장하는 경우는 빈번합니다. "GPT-4", "GPT4", "OpenAI의 최신 모델"이 모두 같은 엔티티를 가리킬 수 있습니다. 이를 처리하지 않으면 지식 그래프에 중복 노드가 쌓여 검색 품질이 저하됩니다. GraphRAG에서는 **엔티티 해소(Entity Resolution)**를 위해 이름과 설명의 텍스트 임베딩 유사도를 기준으로 후보를 클러스터링하고, 같은 클러스터 내 엔티티를 LLM으로 병합 여부를 판단합니다.
이 과정은 자동으로 처리되지만, 도메인 특화 약어가 많거나 동음이의어가 빈번한 문서에서는 오류 발생 가능성이 있습니다. 예를 들어 IT 분야에서 "Java"는 프로그래밍 언어이지만, 일반 문서에서는 인도네시아 섬을 의미할 수도 있습니다. 현업에서는 이 문제를 다루기 위해 도메인 특화 시드 엔티티 목록(seed ontology)을 프롬프트에 제공하거나, 추출 후 수동 검수 단계를 파이프라인에 포함하는 방식을 사용합니다.
관계 정규화도 중요합니다. 동일한 관계가 "A는 B를 개발했다", "B는 A에 의해 만들어졌다"처럼 역방향으로 표현될 수 있습니다. 무방향 관계로 처리할 것인지, 방향성을 유지할 것인지는 도메인과 질의 패턴에 따라 달라집니다.
엔티티 해소 품질이 지식 그래프 전체의 신뢰도를 결정합니다. 이 단계에서의 오류는 하위 검색 전반에 전파됩니다.
커뮤니티 요약 생성
지식 그래프가 구축되면, Leiden 알고리즘으로 커뮤니티를 탐지하고 각 커뮤니티에 대한 요약 리포트를 LLM으로 생성합니다. 요약 리포트는 단순한 엔티티 나열이 아니라, 해당 커뮤니티를 대표하는 핵심 주제, 구성 엔티티들 간의 주요 관계, 그리고 중요한 발견(findings)을 구조화된 형태로 담고 있습니다.
커뮤니티 수준별로 요약의 추상화 수준이 달라집니다. Level 0의 소규모 커뮤니티는 세밀한 사실 관계를, Level 2 이상의 대형 커뮤니티는 더 추상적인 주제와 패턴을 요약합니다. 글로벌 검색은 질의의 추상화 수준에 맞는 커뮤니티 레벨을 선택해 검색 효율을 높입니다.
| 커뮤니티 레벨 | 노드 수 범위 | 요약 특성 | 적합한 질의 유형 |
|---|---|---|---|
| Level 0 | 3~10개 | 세밀한 사실·관계 | 특정 개념 간 연결 |
| Level 1 | 10~50개 | 중간 주제 클러스터 | 서브 도메인 이해 |
| Level 2+ | 50개 이상 | 전역 주제·패턴 | 전체 말뭉치 통찰 |
GraphRAG 검색 파이프라인 구현
환경 구성과 인덱싱
Microsoft의 graphrag 패키지를 활용하면 GraphRAG 파이프라인을 비교적 빠르게 구축할 수 있습니다. 패키지는 인덱싱(indexing)과 쿼리(query) 두 단계로 구성됩니다. 인덱싱 단계에서 지식 그래프와 커뮤니티 요약을 생성하고, 쿼리 단계에서 로컬 또는 글로벌 검색을 수행합니다.
인덱싱 파이프라인은 설정 파일(settings.yaml)로 제어하며, 청크 크기, 사용할 LLM 모델, 임베딩 모델, 병렬 처리 수준 등을 지정합니다. 입력 데이터는 ./input 디렉토리의 텍스트 파일로 구성하며, .txt와 .csv 형식을 지원합니다.
초기 설정 및 인덱싱 실행 예시입니다. graphrag init 명령이 기본 설정 파일과 디렉토리 구조를 생성합니다.
# 패키지 설치 및 프로젝트 초기화
pip install graphrag
mkdir my-graphrag && cd my-graphrag
python -m graphrag init --root .
# 문서를 input 디렉토리에 배치한 후 인덱싱 실행
python -m graphrag index --root .
# 출력 예시:
# ⠸ GraphRAG Indexer
# ├── Loading Input (text) - 42 files loaded.
# ├── create_base_text_units ✓ (00:00:02)
# ├── create_base_extracted_entities ✓ (00:12:35) ← LLM 호출 집중
# ├── create_summarized_entities ✓ (00:04:12)
# ├── create_base_entity_graph ✓ (00:00:08)
# ├── create_community_reports ✓ (00:08:44) ← 추가 LLM 호출
# └── generate_text_embeddings ✓ (00:02:31)
인덱싱이 완료되면 output 디렉토리에 Parquet 형식의 아티팩트가 생성됩니다. entities.parquet, relationships.parquet, communities.parquet, community_reports.parquet 등의 파일이 핵심입니다.
로컬 검색 구현
로컬 검색은 엔티티 중심 질문에 최적화되어 있습니다. 쿼리에서 관련 엔티티를 벡터 검색으로 찾고, 해당 엔티티의 관계, 속한 커뮤니티 요약, 연결된 텍스트 청크를 함께 컨텍스트로 구성합니다. 각 구성 요소의 컨텍스트 기여 비율은 설정으로 조정할 수 있으며, 이것이 검색 품질에 직접적인 영향을 미칩니다.
다음은 Python SDK로 로컬 검색을 실행하는 예시입니다. 검색 엔진 초기화 시 어떤 데이터를 컨텍스트에 포함할지 결정합니다.
import pandas as pd
from graphrag.query.context_builder.entity_extraction import EntityVectorStoreKey
from graphrag.query.indexer_adapters import (
read_indexer_entities, read_indexer_relationships,
read_indexer_reports, read_indexer_text_units,
)
from graphrag.query.llm.oai.chat_openai import ChatOpenAI
from graphrag.query.llm.oai.embedding import OpenAIEmbedding
from graphrag.query.structured_search.local_search.mixed_context import LocalSearchMixedContext
from graphrag.query.structured_search.local_search.search import LocalSearch
INPUT_DIR = "./output"
COMMUNITY_LEVEL = 2 # 로컬 검색에서 참조할 커뮤니티 레벨
# 아티팩트 로드
entity_df = pd.read_parquet(f"{INPUT_DIR}/entities.parquet")
rel_df = pd.read_parquet(f"{INPUT_DIR}/relationships.parquet")
report_df = pd.read_parquet(f"{INPUT_DIR}/community_reports.parquet")
text_unit_df = pd.read_parquet(f"{INPUT_DIR}/text_units.parquet")
entities = read_indexer_entities(entity_df, entity_embedding_df, COMMUNITY_LEVEL)
relationships = read_indexer_relationships(rel_df)
reports = read_indexer_reports(report_df, entity_df, COMMUNITY_LEVEL)
text_units = read_indexer_text_units(text_unit_df)
# 검색 엔진 설정
context_builder = LocalSearchMixedContext(
entities=entities,
entity_text_embeddings=entity_embedding_store, # 벡터 스토어
text_embedder=OpenAIEmbedding(model="text-embedding-3-small"),
text_units=text_units,
community_reports=reports,
relationships=relationships,
entity_top_size_percent=0.1, # 상위 10% 엔티티만 참조
)
search_engine = LocalSearch(
llm=ChatOpenAI(model="gpt-4o-mini"),
context_builder=context_builder,
token_encoder=tiktoken.get_encoding("cl100k_base"),
context_builder_params={
"use_community_summary": False, # 커뮤니티 전문 대신 요약 사용
"include_community_rank": True,
"community_level": COMMUNITY_LEVEL,
"max_tokens": 12_000,
},
)
result = await search_engine.asearch("GraphRAG에서 커뮤니티 탐지가 어떻게 활용되는가?")
# result.response: "커뮤니티 탐지는 Leiden 알고리즘을 통해..."
# result.context_data["entities"]: 참조된 엔티티 목록
context_builder_params의 max_tokens 설정이 응답 품질에 큰 영향을 줍니다. 이 값이 너무 작으면 관련 컨텍스트가 잘려나가 불완전한 답변이 생성됩니다. 반면 너무 크게 설정하면 불필요한 컨텍스트로 인해 LLM이 핵심에 집중하지 못하는 현상이 발생합니다. 도메인과 문서 특성에 따라 8,000~16,000 토큰 범위에서 조정을 권장합니다.
글로벌 검색과 map-reduce 흐름
글로벌 검색은 구조적으로 로컬 검색과 완전히 다릅니다. 특정 엔티티를 찾는 대신, 관련성이 높은 커뮤니티 요약들을 모두 수집하고 각각에 대해 중간 답변을 생성한 뒤, 최종 답변으로 통합합니다. 이 과정에서 커뮤니티 수가 많을수록 LLM 호출 횟수도 늘어나기 때문에, 글로벌 검색은 응답 지연이 로컬 검색보다 상당히 깁니다.
글로벌 검색은 map 단계에서 커뮤니티 수만큼 LLM 호출이 병렬로 발생하므로, 응답 시간 SLA가 엄격한 서비스에서는 비동기 처리와 캐싱 전략이 필수입니다.
벡터 RAG와의 성능 비교 및 트레이드오프
질의 유형별 성능 특성
Microsoft Research의 논문("From Local to Global: A Graph RAG Approach to Query-Focused Summarization", 2024)에서 GraphRAG는 전역적 요약 질문(global sensemaking questions)에서 기존 naive RAG 대비 유의미한 품질 향상을 보였습니다. 특히 "이 문서에서 가장 중요한 테마는 무엇인가?"와 같은 포괄적 질문에서 포괄성(comprehensiveness) 과 다양성(diversity) 지표가 크게 개선되었습니다.
그러나 모든 유형의 질문에서 GraphRAG가 우세한 것은 아닙니다. 단순 사실 조회나 특정 문장을 찾는 지역적 질문에서는 벡터 RAG가 더 빠르고 비용 효율적입니다. 두 방식의 차이를 이해하고 적절히 선택하는 것이 중요합니다.
| 비교 항목 | 표준 벡터 RAG | GraphRAG (로컬) | GraphRAG (글로벌) |
|---|---|---|---|
| 인덱싱 비용 | 낮음 (임베딩만) | 높음 (LLM 추출) | 높음 (LLM + 요약) |
| 질의 응답 지연 | 낮음 (~1초) | 중간 (~3~5초) | 높음 (~10~30초) |
| 전역 요약 질문 품질 | 낮음 | 중간 | 높음 |
| 특정 사실 검색 품질 | 높음 | 높음 | 낮음 |
| 관계 추론 질문 | 낮음 | 높음 | 중간 |
| 운영 비용 | 낮음 | 중간 | 높음 |
인덱싱 비용과 토큰 소비
GraphRAG의 가장 큰 실용적 제약은 인덱싱 비용입니다. 100만 토큰 분량의 문서를 인덱싱하는 데 드는 OpenAI API 비용은, 표준 벡터 RAG의 수십 배에 달할 수 있습니다. 엔티티 추출과 글리밍, 커뮤니티 요약 생성 모두 LLM 호출이 필요하기 때문입니다.
Microsoft의 공식 문서에 따르면, 300페이지 분량의 문서(약 100만 토큰)를 GPT-4o-mini로 인덱싱하는 데 약 1~2 USD의 비용이 발생합니다. 동일한 작업을 GPT-4o로 수행하면 10배 이상의 비용 차이가 납니다. 따라서 엔티티 추출과 같은 반복적 작업에는 소형 모델을 사용하고, 커뮤니티 요약 생성처럼 품질이 중요한 단계에만 대형 모델을 적용하는 계층적 모델 전략이 비용 최적화에 효과적입니다.
인덱싱 단계별로 모델을 분리하면 품질을 유지하면서 비용을 30~60% 절감할 수 있습니다.
대안 접근법과 선택 기준
GraphRAG 외에도 그래프를 활용한 RAG 변형이 다양합니다. KG-RAG는 사전 구축된 지식 그래프(Wikidata, DBpedia 등)를 SPARQL 쿼리로 검색하는 방식으로, 도메인이 명확하고 정형화된 지식이 있을 때 유리합니다. HippoRAG는 인간의 기억 구조를 모방해 맥락적 연결을 강화한 방식으로, 복잡한 추론 체인이 필요한 QA에 강점을 보입니다. LightRAG는 GraphRAG와 유사하지만 인덱싱 비용을 줄이는 데 초점을 맞춘 오픈소스 대안입니다.
선택 기준은 결국 질의 패턴과 운영 제약의 교차점에서 결정됩니다. 전역 요약과 관계 추론이 핵심이라면 GraphRAG, 빠른 사실 검색이 주라면 표준 벡터 RAG, 비용 절감이 우선이라면 LightRAG 또는 하이브리드 전략을 검토할 수 있습니다.
운영 환경 적용 시 고려사항
흔한 실수와 함정
GraphRAG를 처음 적용하는 팀이 가장 자주 마주치는 문제는 청크 크기 설정 실패입니다. 기본 청크 크기(1200 토큰)는 범용 문서에 맞춰져 있지만, 짧은 뉴스 기사나 길이가 긴 법률 문서에는 최적화되어 있지 않습니다. 청크가 너무 작으면 한 문장에 걸친 관계가 청크 경계에서 잘려 추출에 실패하고, 너무 크면 하나의 청크에 너무 많은 엔티티가 포함되어 추출 품질이 떨어집니다. 도메인별로 300~600 토큰(짧은 문서)부터 1500~2000 토큰(긴 보고서) 범위에서 실험적으로 최적값을 찾아야 합니다.
두 번째 함정은 인코딩 불일치입니다. GraphRAG는 내부적으로 tiktoken의 cl100k_base 인코딩을 기준으로 토큰을 계산합니다. 한국어와 일본어처럼 멀티바이트 문자가 많은 언어에서는 영어 대비 토큰 수가 2~4배 많아지므로, 동일한 청크 크기 설정이 실제로는 매우 짧은 텍스트 단위로 분할되는 결과를 낳을 수 있습니다. 한국어 문서를 처리할 때는 청크 크기를 영어 기준의 1.5~2배로 설정하는 것을 권장합니다.
한국어 문서에서는 청크 크기를 기본값보다 1.5~2배 크게 설정해야 영어 문서와 동등한 추출 품질을 얻을 수 있습니다.
모니터링과 디버깅
GraphRAG 파이프라인은 여러 단계를 거치므로, 어느 단계에서 품질 문제가 발생했는지 추적하기 어렵습니다. 운영 환경에서는 각 단계의 출력물을 체계적으로 모니터링하는 것이 필수입니다.
엔티티 추출 품질 지표로는 청크당 평균 엔티티 수와 관계 수를 추적합니다. 청크당 엔티티가 1~2개 이하라면 추출 프롬프트 또는 LLM 선택에 문제가 있을 수 있습니다. 반대로 30개 이상이라면 무의미한 엔티티(관사, 숫자 등)가 과도하게 포함된 것일 수 있습니다. 도메인에 따라 차이가 있지만 일반적으로 청크당 5~15개 엔티티가 적절합니다.
커뮤니티 요약 품질은 자동화된 지표보다 샘플 기반 사람 검토가 더 효과적입니다. 전체 커뮤니티 중 5~10%를 랜덤 샘플링해 요약이 해당 커뮤니티의 핵심 주제를 정확히 반영하는지 확인합니다. 요약이 지나치게 일반적이거나("이 커뮤니티는 다양한 주제를 다룹니다") 특정 엔티티에 편중되어 있다면, 커뮤니티 크기 파라미터나 요약 생성 프롬프트를 조정해야 합니다.
| 모니터링 지표 | 정상 범위 | 이상 신호 | 조치 방향 |
|---|---|---|---|
| 청크당 평균 엔티티 수 | 5~15개 | <3개 또는 >25개 | 프롬프트 또는 청크 크기 조정 |
| 엔티티 해소율 | 10~30% | >50% | 도메인 특화 엔티티 목록 제공 |
| 커뮤니티당 평균 노드 수 | 레벨별 5~50개 | 단일 노드 커뮤니티 과다 | resolution 파라미터 조정 |
| 로컬 검색 응답 시간 | 2~5초 | >10초 | 컨텍스트 토큰 수 축소 |
| 글로벌 검색 비용/쿼리 | $0.01~0.05 | >$0.20 | 커뮤니티 레벨 필터링 강화 |
증분 업데이트와 확장
GraphRAG의 인덱싱 비용이 높기 때문에, 문서가 추가되거나 변경될 때마다 전체 재인덱싱을 수행하는 것은 현실적이지 않습니다. 이 문제를 다루는 방법은 크게 두 가지입니다.
첫째, 배치 업데이트 전략입니다. 새로운 문서를 주기적으로 모아 별도 인덱스로 구축하고, 기존 인덱스와 쿼리 시에 병합합니다. 이 방식은 구현이 단순하지만, 새 문서의 엔티티가 기존 인덱스의 엔티티와 연결되지 않는 단절 문제가 발생합니다.
둘째, 스트리밍 업데이트 전략입니다. 새 문서에서 엔티티와 관계를 추출한 뒤, 기존 그래프에 점진적으로 추가합니다. 커뮤니티 재탐지는 전체 그래프 대신 변경된 영역의 이웃 그래프에만 적용합니다. 이 방식은 정확도가 더 높지만, 그래프 데이터베이스(Neo4j, Neptune 등)와의 통합 구현이 필요합니다.
증분 업데이트 전략 선택은 데이터 변경 빈도와 구현 복잡도의 트레이드오프입니다. 월 단위 업데이트라면 배치 전략이, 일 단위라면 스트리밍 전략이 현실적입니다.
맺음말
핵심 요약
GraphRAG는 기존 벡터 RAG가 다루기 어려웠던 전역적 요약 질문과 다중 엔티티 관계 추론에서 의미 있는 품질 향상을 제공합니다. 핵심 메커니즘은 세 가지입니다. LLM 기반 엔티티·관계 자동 추출로 도메인 스키마 없이도 지식 그래프를 구축할 수 있으며, Leiden 알고리즘을 통한 계층적 커뮤니티 구성으로 다양한 추상화 수준의 질의에 대응합니다. 그리고 로컬 검색과 글로벌 검색의 이중 파이프라인이 질의 유형에 맞는 최적 경로를 제공합니다.
다만 이 모든 장점은 상당한 인덱싱 비용과 구현 복잡도를 전제로 합니다. 표준 벡터 RAG 대비 인덱싱 비용이 10~50배까지 차이날 수 있으며, 한국어처럼 토큰 효율이 낮은 언어에서는 청크 크기 등 파라미터 튜닝이 추가로 필요합니다.
적용 판단 기준
GraphRAG가 적합한 상황은 다음과 같습니다. 말뭉치 전체를 아우르는 통찰이 필요한 경우—예를 들어 수천 건의 고객 피드백에서 반복 패턴을 파악하거나, 대규모 내부 문서에서 의사결정 계보를 추적하는 용도에 적합합니다. 엔티티 간 관계가 답변의 핵심인 경우—"이 기술과 저 기술의 연관 관계는?"처럼 명시적 관계 추론이 필요할 때 효과적입니다.
반대로 다음 상황에서는 도입을 재고할 필요가 있습니다. 문서가 1만 건 미만으로 소규모이거나 자주 변경된다면 인덱싱 비용 대비 효용이 낮습니다. 응답 속도 SLA가 2초 이하로 엄격하다면 글로벌 검색의 지연이 문제가 됩니다. 단순 FAQ 검색이나 구체적 사실 조회가 주된 용도라면 표준 벡터 RAG가 더 현명한 선택입니다.
GraphRAG는 "모든 RAG 문제를 해결하는 단일 솔루션"이 아닙니다. 벡터 RAG와 GraphRAG를 질의 유형에 따라 동적으로 선택하는 하이브리드 아키텍처가 현실 프로젝트에서 가장 균형 잡힌 접근법으로 확인되고 있습니다.