GraphRAG란? 전체 자료의 공통 주제를 물을 때 달라지는 검색

실로 연결한 돌들이 세 묶음으로 놓인 모습. 이해를 돕기 위한 AI 생성 개념 이미지입니다.

“이 제품은 언제 출시됐나요?”와 “이 자료들에서 반복되는 관심사는 무엇인가요?”는 필요한 검색 범위가 다릅니다. GraphRAG는 두 번째처럼 자료의 관계와 전체 주제를 다루는 접근을 이해할 때 유용한 이름입니다.

한 문서의 사실을 찾는 질문인지, 자료 전체의 관계와 주제를 묻는 질문인지 먼저 나누세요.

가까운 문단 몇 개로는 전체를 대표하기 어렵습니다

벡터 검색으로 질문과 가까운 문단을 찾는 방법은 구체적인 사실을 찾는 데 사용할 수 있습니다. 하지만 일부 문단이 자료 전체의 공통 주제를 대표한다고 보기는 어렵습니다.

Microsoft GraphRAG의 질의 엔진 설명은 Local Search와 Global Search를 구분합니다. Local Search는 추출한 그래프 정보와 원문 조각을 함께 사용하고, Global Search는 여러 커뮤니티 보고서를 map-reduce 방식으로 검색해 전체 수준의 질문에 답합니다. Global Search는 자료 전체를 다루는 대신 자원 사용량이 큰 경로라고 문서에 적혀 있습니다.

현재 문서에는 Local Search를 넓히는 DRIFT Search도 별도 경로로 소개됩니다. 커뮤니티 정보를 이용해 후속 질문을 만들고 더 다양한 사실을 찾는 방식이므로, Local과 Global만 있는 고정된 분류로 외우지 말고 사용하는 GraphRAG 버전의 질의 경로를 확인해야 합니다. Basic Search는 비교를 위한 기초 벡터 RAG로, 상위 k개 텍스트 청크를 문맥에 넣는 경로입니다.

여기서 커뮤니티는 온라인 커뮤니티가 아니라 그래프에서 서로 연결이 밀접한 항목의 묶음입니다. 보고서는 그 묶음에 관한 생성 요약이며 원문 자체와는 다릅니다.

공개 전시 자료를 예로 들어봅니다

가상의 전시 소개문 200개가 있다고 합시다. “작가 A가 참여한 전시는?”은 특정 인물과 전시의 연결을 찾는 질문입니다. “여러 전시에서 반복되는 환경 주제는?”은 자료 전반의 경향을 묻습니다.

이 경우 인물·전시·주제의 관계를 추출하고, 연결된 묶음을 요약해 두는 방식이 전체 질문에 도움이 되는지 검토할 수 있습니다. 200개라는 수는 설명용이며 이 규모부터 GraphRAG가 필요하다는 기준이 아닙니다.

인덱싱 개요가 다루듯 원문을 처리하고 개체·관계·주장(claim) 추출, 커뮤니티 탐지, 여러 수준의 커뮤니티 요약·보고서 생성, 임베딩 생성 같은 중간 결과를 만드는 준비 과정이 있습니다. 기본 출력은 Parquet 테이블에 저장되고 임베딩은 설정한 벡터 저장소에 기록됩니다. 검색 시점의 답변만 비교하면 이 준비 비용과 오류를 놓칩니다.

공식 문서의 CLI 예시는 다음과 같습니다. 실제 실행에는 데이터 루트와 구성 파일, 의존성이 필요합니다.

uv run poe index --root <data_root>

이 명령이 실행된다는 사실이 특정 데이터에서 좋은 답을 보장하지는 않습니다. 어떤 workflow와 prompt를 사용했는지, 실패한 입력과 산출물 버전을 함께 기록해야 합니다.

그래프가 사실을 보증해주지는 않습니다

“작가 A가 전시 B를 비판했다”는 문장을 “A가 B에 참여했다”로 잘못 추출하면, 이후 검색은 잘못된 연결을 이용할 수 있습니다. 그림으로 연결되어 있으면 그럴듯해 보이지만 생성한 관계는 여전히 원문 대조 대상입니다.

같은 이름의 다른 사람을 하나로 합치는 경우, 부정문이나 시기를 빠뜨리는 경우도 따로 확인해야 합니다. 이는 이 글에서 제안하는 검수 질문입니다. 특정 도구에서 그런 오류가 발생했다고 측정한 주장은 아닙니다.

최종 답변에서 원문 조각으로 돌아갈 수 있어야 하며, 생성된 커뮤니티 보고서를 다시 원출처처럼 인용하지 않는 것이 중요합니다.

단순 검색도 비교군으로 남깁니다

공식 질의 엔진에는 기본 벡터 검색 방식도 포함됩니다. 전체 질문이 아닌데 모든 질의를 복잡한 그래프 경로로 보내면 필요하지 않은 준비와 계산을 추가할 수 있습니다.

작은 질문 묶음을 사실 조회, 관계 조회, 전체 주제로 나누고 각 방식이 어떤 근거를 가져왔는지 비교하세요. 자료가 자주 바뀐다면 그래프와 요약을 갱신하는 비용도 포함해야 합니다. 답이 길고 풍부해졌다는 이유만으로 정답성이 높아졌다고 판단하지 않습니다.

인덱스를 만들 때 생성되는 중간 산출물을 봅니다

GraphRAG 도입은 검색 API 하나를 바꾸는 작업보다 인덱싱 파이프라인을 추가하는 작업에 가깝습니다. 공식 인덱싱 개요가 설명하는 개체·관계·커뮤니티 관련 산출물은 원문에서 바로 주어진 정답이 아니라 추출과 요약을 거친 결과입니다.

원문 문서
  → 텍스트 단위 분할
  → 개체·관계·주장 추출
  → 그래프 구성
  → 커뮤니티 탐지
  → 커뮤니티 보고서 생성
  → 텍스트·구조 데이터 임베딩
  → 질의 시 원문·그래프·보고서 조합

각 화살표에서 오류가 생길 수 있습니다. 이름이 같은 두 사람을 하나로 합치거나, “참여하지 않았다”의 부정을 잃거나, 기간이 다른 관계를 같은 시점으로 묶거나, 원문에 없는 주장을 추출할 수 있습니다. 최종 답만 검사하면 어떤 단계가 잘못됐는지 찾기 어렵기 때문에 개체·관계·주장이 어느 원문 위치에서 왔는지 추적 정보를 남기는 것이 중요합니다.

질문 라우팅을 먼저 설계합니다

질문	우선 검토할 경로	이유
작가 A의 전시 날짜는?	Basic 또는 Local	특정 사실과 원문 조각이 중요
작가 A와 기관 B의 관계는?	Local	개체 주변 관계와 원문을 함께 봄
전체 전시에서 반복되는 주제는?	Global	여러 커뮤니티 보고서를 종합
특정 문장의 원문은?	기본 검색	생성 요약보다 직접 위치가 중요

모든 질문을 Global Search로 보내면 간단한 사실 조회에도 넓은 요약 비용이 들어갈 수 있습니다. 반대로 전체 경향 질문을 가까운 청크 몇 개로만 답하면 일부 자료가 전체를 대표하는 것처럼 보일 수 있습니다. 질문 유형을 분류하고 기본 검색을 비교군으로 유지해야 합니다.

라우팅이 틀릴 가능성도 있으므로 사용자가 근거를 확인할 수 있는 출처와 경로를 제공합니다. Global 응답에는 어떤 커뮤니티 보고서가 사용됐는지뿐 아니라 가능한 범위에서 원문으로 돌아갈 연결이 필요합니다.

갱신 전략이 없으면 그래프는 빠르게 낡습니다

원문 문서가 추가·수정·삭제될 때 개체, 관계, 커뮤니티와 생성 보고서 가운데 무엇을 다시 계산할지 정해야 합니다. 삭제된 문서에서 온 관계가 남거나, 새 이름을 기존 개체와 잘못 합치면 검색 결과가 조용히 어긋날 수 있습니다.

작은 시험에서는 다음을 기록합니다.

• 인덱스에 사용한 문서 목록과 버전
• 개체·관계마다 원문 근거 위치
• 생성된 커뮤니티 보고서 버전
• 갱신 시작·완료 시간과 실패 항목
• 삭제 문서의 파생 산출물이 제거됐는지
• 같은 질문의 갱신 전후 근거 변화

이 기록은 그래프가 항상 정확하다는 증명이 아니라 오류를 원문과 연결해 고칠 수 있게 하는 운영 장치입니다.

평가 질문을 세 묶음으로 나눕니다

사실 조회, 관계 조회, 전체 주제 질문을 섞어 평균 정확도 하나로 만들지 않습니다. 각 질문에 허용되는 근거 범위와 정답 또는 검토 기준을 둡니다. 전체 주제 질문은 표현이 다양할 수 있으므로 핵심 근거 커버리지와 근거 없는 일반화도 함께 봅니다.

비교 대상은 단순 벡터 검색, GraphRAG의 Basic·Local·Global 경로입니다. 답변 길이, 인용 수, 준비 비용이 늘어난 것을 품질 향상으로 간주하지 않습니다. 원문 근거, 누락, 잘못 합쳐진 관계, 인덱스 비용과 지연을 함께 기록한 뒤 질문 유형별로 필요한 경로만 선택합니다.

이 글이 다루지 않는 것

2026년 9월 7일 확인한 Microsoft GraphRAG 문서의 구조 설명입니다. GraphRAG라는 이름으로 불리는 모든 제품이 같은 구현은 아닙니다. 실제 인덱스를 구축하거나 비용·정확도를 측정하지 않았으며, 그래프 도입은 질문 종류와 갱신 요구를 보고 결정해야 합니다.