1 그래프 DB 없이 GraphRAG 구현하기

1.1 기존 GraphRAG의 구조와 문제

전통적인 GraphRAG (Microsoft 방식 등)는 다음 두 개의 시스템을 동시에 운영해야 한다.

[문서] ──→ [LLM으로 엔티티/관계 추출] ──→ [그래프 DB (Neo4j 등)] ──→ [Cypher 쿼리]
                                                    +
[문서] ──→ [임베딩] ──→ [벡터 DB (Chroma 등)] ──→ [코사인 유사도 검색]

두 시스템을 모두 구축해야 하는 부담이 크다.

실무에서 발생하는 문제들:

문제	내용
인프라 비용	Neo4j 설치·운영·백업 추가 필요
데이터 동기화	벡터 DB와 그래프 DB가 항상 일치해야 함
온톨로지 설계	어떤 엔티티, 어떤 관계를 추출할지 도메인 전문가와 협의 필요
추출 정확도	LLM이 엔티티/관계를 잘못 추출하면 전체 그래프가 오염됨

1.2 langchain-graph-retriever의 핵심 아이디어

“관계 정보는 이미 메타데이터에 있다”

대부분의 문서는 저장할 때 이미 관계 정보를 담은 메타데이터를 가지고 있다.

{
  "id": "alpaca",
  "text": "알파카는 남미 원산의 가축화된 포유류로 부드러운 털로 유명하다.",
  "metadata": {
    "type": "mammal",
    "origin": "south america",     ← 여기! 관계 정보
    "habitat": "grassland",        ← 여기! 관계 정보
    "keywords": ["wool", "domesticated"]  ← 여기! 관계 정보
  }
}

같은 origin을 가진 동물들은 “같은 지역 출신”으로 연결할 수 있다. 이 메타데이터가 곧 엣지(Edge)다.

[alpaca]  ←──origin: "south america"──→  [capybara]
[alpaca]  ←──origin: "south america"──→  [llama]
[alpaca]  ←──habitat: "grassland"──→     [bison]

별도 그래프 DB 없이, 기존 벡터 스토어만으로 이 관계를 표현하고 탐색할 수 있다.

1.3 두 방식 비교

[기존 KG 기반 GraphRAG]                [메타데이터 기반 GraphRAG]
────────────────────────               ──────────────────────────
벡터 DB     → 의미적 검색               벡터 DB    → 의미적 검색 + 그래프 탐색
그래프 DB   → 구조적 탐색
             (Neo4j 등 별도)

장점:  관계를 명시적으로 정의            장점:  인프라 추가 불필요
       복잡한 온톨로지 표현 가능                기존 시스템에 바로 적용
       양방향/다단계 관계 풍부                  메타데이터만 잘 설계하면 됨

단점:  인프라 구축 비용 높음             단점:  메타데이터에 정의된 관계만 탐색 가능
       동기화 유지 어려움                       Neo4j 수준의 복잡한 쿼리 불가
       온톨로지 설계 전문성 필요                 메타데이터 설계가 핵심 병목

1.4 langchain-graph-retriever 동작 원리

사용자 질의: "카피바라 주변에서 볼 수 있는 포유류는?"

Step 1: 벡터 유사도 검색
  질의 임베딩 → 벡터 DB 검색 → [capybara] 발견 (depth=0)

Step 2: 메타데이터 엣지 추출
  capybara.metadata["origin"] = "south america"
  capybara.metadata["habitat"] = "wetland"
  → MetadataEdge("origin", "south america") 생성
  → MetadataEdge("habitat", "wetland") 생성

Step 3: 엣지로 인접 노드 탐색
  벡터 DB에서 origin="south america"인 문서 검색
  → [alpaca], [llama], [jaguar] 발견 (depth=1)

Step 4: 반복 탐색 (max_depth까지)
  alpaca의 메타데이터로 추가 엣지 생성 → 다음 레이어 탐색

Step 5: 전체 결과 반환
  [capybara, alpaca, llama, jaguar, ...] + 관계 정보

1.5 패키지 구조

langchain-graph-retriever는 3개 패키지로 구성된다.

graph-retriever/              ← 순수 Python 탐색 엔진 (LangChain 의존성 없음)
  graph_retriever/
    types.py                  ← Node 클래스
    traversal.py              ← 핵심 traverse() 함수
    edges/                    ← MetadataEdge, IdEdge
    strategies/               ← Eager, MMR, Scored

langchain-graph-retriever/    ← LangChain 통합 레이어
  langchain_graph_retriever/
    graph_retriever.py        ← GraphRetriever (LangChain Retriever)
    adapters/                 ← Chroma, PGVector, AstraDB 등 연결
    transformers/             ← ShreddingTransformer, GLiNER, KeyBERT 등

graph-rag-example-helpers/    ← 예제용 데이터셋 유틸리티
  graph_rag_example_helpers/
    datasets/                 ← animals, wikimultihop 데이터셋

1.6 언제 이 방식이 적합한가

적합한 경우:

이미 벡터 스토어를 사용 중이고, 추가 인프라 없이 그래프 탐색을 원할 때
문서에 구조화된 메타데이터(카테고리, 태그, 원산지, 연도 등)가 이미 있을 때
1~3 depth 수준의 관계 탐색이 필요할 때
프로토타이핑 단계에서 빠르게 GraphRAG를 검증하고 싶을 때

한계 (KG 방식이 더 적합한 경우):

복잡한 온톨로지와 다양한 관계 타입이 필요할 때
관계 자체에 속성이 있어야 할 때 (예: “2020년부터 근무”)
Cypher 같은 그래프 쿼리 언어로 복잡한 패턴 매칭이 필요할 때

1.7 이 라이브러리는 GraphRAG의 어느 수준인가

langchain-graph-retriever는 잘 설계된 라이브러리지만, “GraphRAG의 전부”는 아니다. 스펙트럼에서의 위치를 정직하게 짚고 넘어갈 필요가 있다.

1.7.1 본질을 한 줄로 표현하면

“메타데이터 필터링 벡터 검색 + BFS 확장”

그래프 DB도 없고, LLM 엔티티 추출도 없고, 명시적 지식 그래프 구축도 없다. 관계 정보가 이미 메타데이터에 있어야만 동작한다.

1.7.2 학술/산업 GraphRAG와의 격차

기능	이 라이브러리	Microsoft GraphRAG	Neo4j GraphRAG
그래프 DB	❌ 없음	✅ 내부 구축	✅ Neo4j
LLM으로 엔티티/관계 추출	❌ 없음	✅ 핵심 기능	✅
커뮤니티 감지 (전체 그래프)	❌ 없음	✅ Leiden 알고리즘	✅
계층적 요약 (Global/Local)	❌ 없음	✅	부분
관계 자체에 속성 부여	❌ 불가	✅	✅ Cypher
복잡한 그래프 쿼리	❌ 불가	✅	✅
전체 그래프 알고리즘	❌ 불가	✅	✅ PageRank 등

1.7.3 핵심 한계 3가지

1. 메타데이터 없으면 무용지물

# 이런 문서는 그래프 탐색 불가 → 일반 Vector RAG와 동일
doc.metadata = {"source": "some_pdf"}

2. 관계 타입이 단순함

# 할 수 있는 것: "같은 값을 가진 문서끼리 연결"
edges=[("origin", "origin")]

# 할 수 없는 것
# (A) -[근무함, since=2020]-> (B)  ← 관계 자체에 의미/속성 불가

3. BFS의 방향 없는 확장

depth=3 탐색 시 관련 없는 문서가 대량 포함될 수 있음
→ 정교한 경로 선택 없이 모든 방향으로 확산

1.7.4 GraphRAG 스펙트럼에서의 위치

일반 Vector RAG
    │
    ▼  ← 이 라이브러리
메타데이터 기반 그래프 탐색 RAG
    │
    ▼
Microsoft GraphRAG (LLM 엔티티 추출 + 커뮤니티 요약)
    │
    ▼
Neo4j 기반 Full GraphRAG (완전한 그래프 DB + Cypher)
    │
    ▼
PathRAG / GFM-RAG (최신 연구)

1.7.5 그럼에도 이 라이브러리를 공부하는 이유

이 라이브러리가 나쁜 것이 아니라, 목적에 맞는 실용적 선택이다.

구축 비용: Neo4j + LLM 추출 없이 벡터 스토어만으로 즉시 적용
기존 시스템 통합: 이미 메타데이터가 있는 데이터에 바로 적용
GraphRAG 핵심 개념 학습: 노드, 엣지, 탐색 전략의 실제 작동 방식 이해
LazyGraphRAG: 커뮤니티 기반 클레임 추출은 실제로 정교한 기법

이 시리즈는 이 라이브러리를 통해 GraphRAG의 기초 개념을 익히고, 이후 Microsoft GraphRAG 같은 풀 스택 접근으로 확장하기 위한 발판으로 삼는다.

1.8 정리

항목	내용
핵심 아이디어	벡터 스토어 메타데이터 = 그래프 엣지
추가 인프라	불필요
핵심 설계 결정	어떤 메타데이터 필드를 엣지로 사용할 것인가
탐색 방식	벡터 유사도 → 시작 노드 → 메타데이터로 인접 노드 → 반복
지원 Vector Store	Chroma, AstraDB, Cassandra, OpenSearch, PGVector, In-memory
실제 수준	메타데이터 BFS 확장 (Full GraphRAG와는 다름)

다음 파일에서는 실제 설치와 첫 번째 GraphRAG 실행을 해본다.