[LLM Wiki 7] Graph RAG: 관계를 따라가며 답하는 검색

Graph RAG는 일반 RAG에 관계 그래프를 더한 방식이다. 일반 RAG가 관련 문서 조각을 찾는 데 집중한다면, Graph RAG는 문서 안에 등장하는 사람, 회의, 결정, 액션, 프로젝트, 주제 사이의 관계를 따라가며 답한다.

일반 RAG 복습

일반 RAG는 질문을 받으면 관련 문서 조각을 찾고, 그 조각을 LLM이 읽어 답을 만든다.

예를 들어 질문이 다음과 같다고 하자.

• SSO 관련 고객 미팅 요약해줘

일반 RAG는 SSO와 관련된 회의록 조각을 찾고, LLM은 그 조각을 읽고 요약한다. 이 방식은 좋지만, 관계의 흐름을 명시적으로 다루지는 않는다.

Graph RAG의 기본 개념

Graph RAG는 문서에서 중요한 대상과 관계를 뽑아 그래프로 만든다. 대상은 Meeting, Decision, Action, Person, Project 같은 node가 되고, 관계는 creates, assigns, affects, owned_by 같은 edge가 된다.

회의록 예시는 위 도식처럼 회의가 결정을 만들고, 결정이 프로젝트에 영향을 주고, 액션이 사람에게 할당되는 구조다.

질문이 들어오면 Graph RAG는 관련 노드를 찾고, 연결된 노드를 따라가며 필요한 근거를 모은다.

회의록은 원래 그래프 구조다

회의록은 문서처럼 보이지만 사실 관계 데이터다.

회의 하나에는 보통 다음 관계가 들어 있다.

• 누가 참석했는가
• 무슨 주제를 논의했는가
• 무슨 결정을 했는가
• 누가 어떤 일을 맡았는가
• 어떤 프로젝트에 영향이 있는가
• 어떤 리스크가 나왔는가
• 어떤 질문이 아직 열려 있는가

이 정보들은 자연스럽게 node와 edge로 표현된다.

일반 RAG와 Graph RAG의 차이

차이는 위 비교 도식처럼 문서 chunk 중심인지, node와 edge 중심인지에서 갈린다.

예를 들어 다음 질문을 보자.

• 가격정책이 왜 seat-based에서 usage-based로 바뀌었어?

일반 RAG는 가격정책 관련 문서를 찾는다. Graph RAG는 결정의 흐름을 따라간다.

관계는 누가 정의하나

관계의 종류는 사람이 정의하는 것이 좋다. 무엇이 중요한 관계인지는 도메인마다 다르기 때문이다.

회의록 MVP에서는 Meeting, Decision, Action, Person, Project, Topic, Customer, Risk, OpenQuestion 정도의 node type이면 충분하다. edge type은 creates, assigns, owned_by, affects, mentions, supersedes, blocks, raised, related_to 정도로 시작할 수 있다.

LLM에게 아무 관계나 만들게 하면 그래프가 금방 지저분해진다. 허용된 관계 타입 안에서만 추출하게 해야 한다.

관계는 누가 추출하나

실제 관계 추출은 여러 방법을 섞는다. LLM은 문맥을 이해해 결정, 액션, 리스크 관계를 뽑고, 규칙 기반 추출은 frontmatter와 템플릿 필드를 안정적으로 읽는다. NER은 사람, 회사, 날짜, 프로젝트명을 잡고, validator는 잘못된 관계와 누락 필드를 점검한다.

Graph RAG는 관계와 흐름이 중요한 질문에서 강하다. 단순히 특정 회의록을 찾는 질문에는 qmd나 BM25 검색으로 충분할 수 있다.