GraphRAG: 로컬에서 글로벌 쿼리 중심 요약까지

Microsoft의 GraphRAG 논문은 2024년 4월에 발표되었으며, 지식 그래프가 특정 구절을 검색하는 대신 전체 코퍼스를 종합해야 하는 질문, 즉 RAG가 가장 명백하게 실패하는 모드에서 RAG를 구제할 수 있는지 묻는 모든 이들에게 빠르게 기준점이 되었습니다. 제가 지금 이 논문을 읽는 이유는 이전 FinAuditing 로그에서 LLM이 다중 문서 XBRL 구조를 처리하는 데 어려움을 겪는다는 점이 드러났기 때문이며, GraphRAG의 커뮤니티 요약 방식이 바로 이러한 종류의 글로벌 추론 문제에 대한 가장 유력한 해답이기 때문입니다.

논문

Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Dasha Metropolitansky, Robert Osazuwa Ness, Jonathan Larson(Microsoft, arXiv:2404.16130)이 작성한 "From Local to Global: A Graph RAG Approach to Query-Focused Summarization"은 저자들이 "글로벌 의미 파악 질문(global sensemaking questions)"이라 부르는 것들 — 예컨대 "이 데이터셋의 주요 주제는 무엇인가?"와 같이 단일 구절에 답이 없어 표준 벡터 RAG로는 대답할 수 없는 쿼리들 — 에 답하기 위한 2단계 LLM 구동 파이프라인을 제안합니다.

이 접근 방식은 두 단계로 진행됩니다. 인덱싱 단계에서 LLM은 모든 텍스트 청크에서 엔티티, 관계 및 클레임을 추출하고 이를 가중치 엔티티 그래프로 조립한 다음, Leiden 커뮤니티 탐지를 실행하여 그래프를 관련 클러스터의 계층 구조로 분할하고 각 레벨의 각 커뮤니티에 대해 자연어 요약을 생성합니다. 쿼리 단계에서는 각 커뮤니티 요약이 독립적으로 부분 답변을 생성하고(map 단계), 이러한 부분 답변은 유용성 점수에 따라 순위가 매겨져 컨텍스트 창 제한까지 조립되며(reduce 단계), 그 결과 최종 종합 응답이 도출됩니다.

핵심 개념

• Leiden 계층적 커뮤니티 탐지는 코퍼스를 4단계의 조밀도(C0–C3)로 구조화하여 사용자가 응답 깊이와 토큰 비용을 절충할 수 있게 합니다. 루트 수준 요약은 소스 텍스트를 직접 처리하는 것보다 97% 적은 토큰을 필요로 했습니다.
• 두 가지 테스트 코퍼스 — 팟캐스트 스크립트(약 100만 토큰, 엔티티 8,564개, 관계 엣지 20,691개) 및 뉴스 기사(약 170만 토큰, 엔티티 15,754개, 엣지 19,520개) — 에서 GraphRAG는 LLM 판사 기반의 쌍체 비교를 통해 벡터 RAG 대비 7283%의 포괄성 승률과 6282%의 다양성 승률을 달성했습니다.
• 맵-리듀스(map-reduce) 설계는 쿼리 시 긴 컨텍스트의 LLM 호출을 피합니다. 커뮤니티 요약이 사전 계산되어 있으므로, 검색은 원시 문서를 재처리하는 대신 요약을 가져오는 과정이 됩니다.
• 이 논문은 여섯 가지 조건을 벤치마킹합니다: 네 단계의 GraphRAG 계층, 텍스트 요약(TS), 시맨틱 검색(SS). 글로벌 GraphRAG 조건은 의미 파악 질문에서 SS를 지속적으로 능가하며, SS는 특정 조회 쿼리에서 더 나은 성능을 보입니다.
• 클레임 추출 실험 결과, 글로벌 조건은 응답당 평균 3134개의 클레임을 추출한 반면 벡터 RAG는 2526개에 그쳐, LLM 판사의 점수 선호도와 무관하게 더 넓은 주제 범위를 다루고 있음을 시사했습니다.
• 이 파이프라인은 도메인별 스키마나 온톨로지를 필요로 하지 않습니다. 엔티티 추출, 관계 라벨링, 커뮤니티 요약은 모두 프롬프트 기반 추론만으로 수행됩니다.

유지되는 것과 그렇지 않은 것

핵심 아키텍처적 통찰은 정확합니다. 코사인 유사도 RAG는 전체를 대표하는 단일 청크가 없기 때문에 코퍼스 수준의 질문에 답할 수 없습니다. GraphRAG의 사전 계산된 커뮤니티 요약은 원칙적인 해결책이며, Leiden 기반 계층 구조는 비용 허용 범위에 따라 대략적인 글로벌 요약부터 세밀한 클러스터 요약까지 탐색할 수 있게 해주는 실제적인 설계 선택입니다.

하지만 평가에는 심각한 문제가 있습니다. 최근의 독립적인 연구(arXiv:2506.06331)는 GraphRAG와 그 후속 모델들이 사용한 LLM 판사 방법론을 감사하여 세 가지 체계적인 편향을 발견했습니다: 위치 편향(프롬프트에서 어떤 답변이 먼저 나오느냐에 따라 승률이 30% 이상 변함), 길이 편향(200자 답변에서 25자 차이가 승률 50포인트 변동을 일으킴), 시행 편향(동일한 평가가 실행마다 상충되는 결과를 냄). 이를 보정한 후에는 주장된 성능 우위가 무너집니다. LightRAG의 보고된 66.7% 승률은 보정 후 39.06%로 떨어집니다. GraphRAG 자체의 72~83% 포괄성 수치도 거의 확실히 동일한 방법론적 결함을 겪고 있을 것입니다.

인덱싱 비용 또한 실질적인 장애물입니다. 한 실무자 분석에 따르면 중간 규모 코퍼스에 대해 GPT-4o를 사용한 인덱스 구축 비용이 47.9달러에 달했습니다. Microsoft가 후속으로 발표한 LazyGraphRAG 변형은 그래프 추출을 쿼리 시점으로 미룸으로써 이를 전체 GraphRAG 비용의 0.1%로 줄였습니다. 이는 원래의 인덱싱 예산이 많은 실제 배포 환경에서 비실용적임을 암시적으로 인정한 것입니다.

두 가지 평가 코퍼스 또한 범위가 좁습니다. 저자들은 다른 도메인과 규모로의 일반화 가능성이 미지수임을 인정합니다. 금융 공시나 장부 내보내기 데이터와 같은 구조화 또는 반구조화된 데이터의 경우, 내러티브 텍스트에 최적화된 엔티티 추출 프롬프트가 실제 실무에서 가장 중요한 표 형식 및 계층적 관계를 놓칠 수 있습니다.

금융 AI에 중요한 이유

Beancount 장부는 글로벌 의미 파악 질문이 자연스럽게 발생하는 바로 그 코퍼스입니다: "지난 3년 동안 가장 지출이 컸던 카테고리는 무엇인가?" 또는 "어떤 거래처 계정의 성장률이 전년 대비 20%를 넘었는가?" 표준 RAG는 단일 항목에 답이 없기 때문에 수천 개의 거래를 종합해야 하는 이러한 질문에 답할 수 없습니다.

GraphRAG의 커뮤니티 요약 방식은 이와 잘 맞물립니다. 지식 그래프의 노드가 계정, 수취인(payee), 거래 카테고리이고 엣지가 동시 발생 또는 부모 계정 관계라면, 커뮤니티 요약은 장부에 대해 사전 계산된 집계 뷰가 됩니다. 계층 구조 또한 Beancount의 계정 트리가 이미 데이터를 구조화하는 방식인 Assets, Expenses, Income의 재귀적 분해와 자연스럽게 일치합니다.

그렇긴 하지만 평가 편향에 대한 발견은 경고를 줍니다. 논문의 인상적인 승률은 엄격한 통제 테스트에서 유지되지 않을 수 있으며, 인덱싱 비용으로 인해 이 방식은 겉보기보다 더 무거운 엔지니어링 투자가 될 수 있습니다. 특히 Beancount의 경우, 결정론적 분석을 위해서는 SQL 스타일의 쿼리나 내보낸 장부에 대한 pandas 처리가 LLM 기반 커뮤니티 요약보다 성능이 뛰어날 수 있습니다. GraphRAG의 가치는 구조화된 쿼리가 해결할 수 없는 진정한 모호함이 존재하는 대규모 거래 메모와 거래처 이름에 대한 추론과 같은 내러티브 비중이 높은 질문에서 가장 높을 것입니다.

다음 읽을거리

• LazyGraphRAG (Microsoft Research blog, 2024) — 그래프 추출을 미루는 Microsoft의 비용 절감 변형 모델로, 과도한 인덱싱 비용 없이 실제 장부 규모에서 GraphRAG의 접근 방식을 배포할 수 있는지와 직결됩니다.
• "How Significant Are the Real Performance Gains? An Unbiased Evaluation Framework for GraphRAG" (arXiv:2506.06331) — 체계적인 편향 감사 논문으로, 요약 방법론에 대한 LLM 판사 평가의 승률 수치를 무비판적으로 받아들이기 전에 반드시 읽어야 할 필독서입니다.
• "Towards Verifiably Safe Tool Use for LLM Agents" (arXiv:2601.08012, ICSE 2026) — 다음 읽기 목록 항목으로, 요약에서 쓰기 작업의 안전성으로 초점을 옮깁니다. 이는 Beancount 에이전트에게 있어 보다 시급하고 해결되지 않은 문제입니다.