"RAG 핵심 학습 (23/26) — Graph RAG: Knowledge Graph + Vector"
문서 조각의 의미 유사도만으로는 "누가 누구와 어떤 관계인가"를 안정적으로 찾기 어렵다. 그래서 그래프가 등장한다.
Graph RAG는 문서에서 추출한 개체(entity) 와 관계(relation) 를 그래프로 저장하고, 벡터 검색과 함께 활용하는 접근이다. 전통적 RAG가 "비슷한 문단"을 찾는 데 강했다면, Graph RAG는 "연결 관계를 따라가는 질문"에 강하다.
0. Prerequisites
- 22편 corrective RAG
- 7편 메타데이터 설계
- 9편 벡터DB 비교
1. 학습 목표
- Graph RAG가 왜 필요한지 설명한다.
- entity, relation, multi-hop retrieval의 의미를 이해한다.
- vector retrieval과 graph traversal의 역할 차이를 안다.
- 언제 Graph RAG가 과한 선택인지 구분한다.
2. 핵심 요약
Graph RAG는 문서 속 개체와 관계를 구조화해, 단순 유사도 검색이 놓치기 쉬운 관계형 질의를 더 잘 다루려는 시도다. 예를 들어 "A 정책을 승인한 부서와 그 예외 절차를 관리하는 팀은?" 같은 질문은 여러 문서를 넘나드는 관계 탐색이 필요하다. Graph RAG는 보통 entity extraction → relation graph 저장 → graph + vector 결합 검색 구조를 가진다. 강력하지만, 구축 비용과 정합성 관리가 어렵다.
3. 직관 — multi-hop 질문에서 왜 그래프가 필요한가
질문: "외부 공유 예외를 승인하는 부서와, 그 절차를 마지막으로 개정한 위원회는?"
이 질문은: 1. 승인 부서 문서 2. 절차 문서 3. 개정 이력 문서
세 문서의 연결을 따라가야 한다. 단순 벡터 검색은 각각을 찾을 수 있어도, 연결 구조를 명시적으로 갖고 있지 않다.
4. 정의 — graph RAG의 핵심 용어
| 용어 | 정의 |
|---|---|
| Entity | 사람, 조직, 정책, 제품 같은 개체 |
| Relation | 개체 사이 연결 (승인한다, 소속된다, 개정했다 등) |
| Triple | (주어, 관계, 목적어) 형태의 관계 단위 |
| Multi-hop Retrieval | 하나의 관계가 아니라 여러 연결을 따라가는 검색 |
| Graph Traversal | 그래프 위에서 노드와 엣지를 따라 탐색 |
5. 구조 — graph와 vector는 무엇이 다른가
- Vector retrieval: 의미가 비슷한 문장을 찾는다.
- Graph traversal: 연결 구조를 따라간다.
둘은 경쟁자가 아니라 보완재다. 흔한 구조는 이렇다.
- vector로 관련 문서 후보를 좁힌다
- 문서에서 entity를 추출한다
- graph에서 관련 연결을 따라간다
- 최종 context를 조합한다
6. 원리 워크스루 — 최소 Graph RAG 파이프라인
6.1 triple 추출 개념
triples = [
("외부 공유 예외", "승인한다", "보안 책임자"),
("외부 공유 예외 절차", "개정했다", "정보보호위원회"),
]
6.2 graph query 예시
MATCH (p:Policy {name: "외부 공유 예외"})-[:APPROVED_BY]->(team)
MATCH (p)-[:REVISED_BY]->(committee)
RETURN team, committee
6.3 vector와 graph 결합
seed_docs = vector_store.search(query, k=5)
seed_entities = extract_entities(seed_docs)
graph_context = graph.expand(seed_entities, hops=2)
자기 설명: graph RAG가 "더 좋은 vector DB"가 아닌 이유를 한 문장으로 설명해 보라.
7. 변형과 사례
7.1 Entity-centric Graph
사람, 조직, 제품 같은 핵심 개체를 중심으로 그래프를 구축한다. 설명이 쉽고 유지가 비교적 단순하다.
7.2 Document-Entity Hybrid Graph
문서 노드와 entity 노드를 함께 두어, 문서와 관계 구조를 동시에 탐색한다.
7.3 Global Summary Graph
장문 보고서 전체를 요약한 상위 노드와 세부 노드를 연결해 계층적으로 탐색하는 패턴도 있다.
8. 한계와 실패 양상
8.1 graph 구축 비용이 크다
entity와 relation 추출 품질이 낮으면 잘못된 그래프가 생긴다.
8.2 업데이트가 어렵다
문서가 바뀔 때 그래프도 함께 갱신해야 한다. re-indexing보다 관리가 까다롭다.
8.3 모든 문제에 graph가 필요한 것은 아니다
단순 FAQ나 짧은 정책 질의에는 vector + metadata만으로 충분할 수 있다.
8.4 다음 단계 — 여러 단계 추론을 계획적으로 묶는 구조
graph까지 왔다면 이제 retrieval이 단일 단계가 아니다. 다음 24편은 agentic RAG다.
8.5 입문자가 자주 빠지는 함정 5선
| # | 함정 | 증상 | 빠른 점검 |
|---|---|---|---|
| 1 | 단순 FAQ에도 graph 도입 | 과설계 | 질의 유형 점검 |
| 2 | entity 추출 품질 미검증 | 잘못된 관계 연결 | 샘플 triple 검수 |
| 3 | 그래프 갱신 전략 없음 | stale graph | update pipeline 정의 |
| 4 | vector와 graph를 대체 관계로 봄 | 검색 품질 불안정 | 역할 분리 명시 |
| 5 | hops를 과하게 확장 | 노이즈 증가 | hop 제한 실험 |
9. 정리된 결론 — 보지 않고 답해 보라
Q1. Graph RAG의 핵심 목적은?
정답 관계형, multi-hop 질문을 더 잘 다루는 것이다.
왜 단순 의미 유사도만으로는 연결 구조를 안정적으로 표현하기 어렵기 때문이다.
Q2. vector retrieval과 graph traversal의 차이는?
정답 vector는 비슷한 문장을 찾고, graph는 연결 관계를 따라간다.
왜 표현 구조 자체가 다르기 때문이다.
Q3. Graph RAG가 과한 선택일 수 있는 경우는?
정답 FAQ처럼 관계 구조가 단순한 질의가 대부분일 때다.
왜 구축 비용에 비해 추가 이득이 작을 수 있기 때문이다.
Cheat Sheet — 이 편의 식·정의 1페이지
정의 - Entity: 개체 - Relation: 관계 - Triple: (주어, 관계, 목적어) - Multi-hop: 여러 연결을 따라가는 질의
최소 코드
seed_entities = extract_entities(seed_docs)
graph_context = graph.expand(seed_entities, hops=2)
언제 무엇을 | 상황 | 선택 | |---|---| | 단순 의미 검색 | vector 중심 | | 관계형 질의 | graph 결합 | | 다중 문서 연결 필요 | graph + vector |
참고 자료
1차 자료
- Edge, D. et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. 2024.
보조 자료
- 사용자 노트 20장 graph rag
다음 편으로 이어지는 흐름
관계 구조까지 들어오면 retrieval은 사실상 여러 단계를 계획적으로 수행하는 문제에 가까워진다. 다음 24편은 agentic RAG를 다룬다.
댓글
댓글 쓰기