5장까지의 답사가 전각을 세우는 일이었다면, 이제 단청을 올릴 차례다. 3부의 첫 장은 텍스트 검색의 천장을 깨는 장이다. 아무리 좋은 임베딩도, 아무리 정교한 캐스케이드도 답하지 못하는 질문이 있다 — 답이 어느 문서 안에도 없고 오직 문서들 사이의 관계에만 사는 질문이다. 서까래와 서까래를 잇는 단청의 문양처럼, 지식 그래프는 낱낱의 문서를 잇는 관계의 무늬를 그려 넣는다.
한 글로벌 자산운용사의 컴플라이언스 팀이 세 시간이면 될 질문에 3주를 썼다. "우리 포트폴리오 기업 중, 최근 영국 금융감독청(FCA)에 제재받은 회사의 이사회에서 일한 적 있는 이사를 둔 곳은 어디인가." 회사 내규가 포트폴리오 기업과 규제 제재 대상 사이의 간접 연결에 강화된 실사를 요구했으므로 질문은 중대했고, 컴플라이언스 책임자는 다음 화요일 이사회 전까지 답이 필요했다.
회사는 그전 여섯 달 동안 사내 문서 230만 건 — 투자 각서, 이사회 회의록, 실사 보고서, 규제 서류, 공개 보도, 법인 등기 데이터 — 위에 최신 RAG 시스템을 배포해 둔 터였다. 최상급 임베딩 모델을 썼고, 재순위화를 갖춘 하이브리드 검색을 썼고, 공들여 조율했다. 팀이 정의한 모든 검색 품질 지표에서 시스템은 잘 돌고 있었다.
컴플라이언스 책임자가 질문을 쳤다. 시스템은 문서 열두 건을 돌려주었다. 어느 것에도 답이 없었다. 포트폴리오 기업 정보는 한 무리의 문서에, FCA 제재 통지는 다른 무리에, 이사회 명단은 — 상당수가 수년 전 공시된 연차보고서에 — 또 다른 무리에 있었다. 책임자에게 필요한 연결은 어느 단일 문서에도 존재하지 않았다. 그것은 오직 문서들 사이의 관계에만 존재했고, 그 관계는 벡터 유사도에도 어휘 일치에도 똑같이 보이지 않았다.
팀은 모든 것을 시도했다. 질의를 확장하고, 여러 하위 질의로 재구성해 병렬로 돌리고, top-k를 키우고, 후보 문서를 늘리고, HyDE도 써 봤다. 아무것도 통하지 않았다 — 통할 수가 없었다. 답은 텍스트가 아니라 구조였기 때문이다. 책임자는 결국 시스템이 생기기 전에 하던 대로 했다. 포트폴리오 기업 목록과 최근 12개월의 FCA 집행 조치 목록을 뽑아, 주니어 애널리스트에게 이사회 명부 데이터베이스를 3주간 손으로 대조시킨 것이다. 그의 일을 빠르게 해 주려던 시스템은, 정작 가장 잘 받쳐 줄 위치에 있던 과제에 아무 기여도 하지 못했다.
사후 분석은 아키텍처의 구멍을 정확히 짚었다. 텍스트 매칭이 아무리 정교해도, 검색 시스템은 문서를 고립된 단위로 다루고 있었다. 엔티티 사이의 관계 — 누가 어느 이사회에서 일했고, 누가 어느 회사를 소유하고, 누가 어느 회사의 감사인이었는지 — 는 문서들에 암묵적으로 걸쳐 있었으되 질의 가능한 구조로 추출된 적이 없었다. 처방은 텍스트 검색의 개선이 아니었다. 텍스트 검색이 대신할 수 없는 층 — 말뭉치에서 추출된, 텍스트 유사도가 근본적으로 흉내 낼 수 없는 방식으로 질의 가능한 지식 그래프 — 를 짓는 것이었다. 여섯 달 뒤, 같은 책임자가 GraphRAG로 보강된 시스템에 같은 질의를 던졌다. 4초 안에 간접 연결 열일곱 건이 나왔다. 셋은 강화 실사감으로 표시할 만큼 중대했고, 나머지 열넷은 해당 기간 전에 끝난 과거 선임으로 쉽게 해명되었다. 3주 걸리던 일이 오후 한나절이 되었고, 그 한나절은 대조가 아니라 판단에 쓰였다.
2부에서 살핀 모든 검색 방법 — 벡터 유사도, BM25, 하이브리드 융합, 재순위화, 질의 변환 — 은 같은 바탕 가정 위에서 돈다. 질의의 답이 적어도 암묵적으로는 어떤 문서 하나 혹은 작은 문서 집합 안에 담겨 있고, 검색 시스템이 질의를 말뭉치에 맞춰 그것을 찾을 수 있다는 가정이다. 이 가정이 성립할 때 2부의 기법들은 비상하게 효과적이다. 성립하지 않을 때 — 답이 어느 문서에도 없고 오직 문서들 사이의 관계에만 있을 때 — 그 기법들은 발 디딜 곳이 없다. 이것이 구조적 천장이고, GraphRAG가 존재하는 이유다.
자산운용사의 컴플라이언스 질문이 천장을 깨는 정전의 예다. 질의가 무엇을 요구하는지 뜯어 보자. 회사의 포트폴리오 기업을 식별하고(문서 한 무리), 해당 기간 FCA에 제재받은 회사를 식별하고(다른 무리), 양쪽 집합의 모든 엔티티의 이사회 구성을 식별하고(수년에 걸친, 잠재적으로 수백 건의 별개 문서), 교집합을 계산해야 한다. 어느 단일 문서도 답을 담지 않는다. 문서들을 가로지르는 관계가 곧 답이다.
텍스트 검색은 이를 풀 수 없다. 질의가 아무리 잘 다듬어져도 포트폴리오 기업에 관한 문서, FCA 조치에 관한 문서, 이사회 구성에 관한 문서를 따로 맞출 뿐, 회수된 문서들이 모여서 언어 모델에 필요한 구조 정보를 주지는 못한다. 설령 관련 문서가 전부 회수되어도, 모델은 컨텍스트 창 안에서 그들을 가로지르는 교집합 추론을 해내야 한다. 엔티티가 한 줌을 넘으면 이는 언어 모델이 믿음직하게 하는 일의 범위를 벗어난다 — 없는 연결을 지어내고, 있는 연결을 놓친다.
이 패턴 — 여러 문서를 가로지르는 관계 추론을 요구하는 멀티홉 질문 — 은 모든 진지한 응용 도메인에 나타난다. 의료에서 "이 약을 복용 중인 환자 중 금기 질환의 병력이 기록된 이는 누구인가"는 환자 기록, 투약 이력, 임상 가이드라인을 가로지르는 추론을 요구한다. 법률에서 "우리 진행 사건 중, 최근 합의된 선례 가치 있는 사건의 당사자를 당사자로 둔 것은 무엇인가"는 사건 기록, 당사자 데이터베이스, 합의 기록을 가로지른다. 공급망 리스크에서 "최근 조업 차질을 겪은 경쟁사가 쓰는 부품의 상류에 있는 우리 공급업체는 어디인가"는 공급업체 목록, BOM 데이터, 사고 보고서를 가로지른다.
일반 패턴은 식별 가능하다 — 질문이 여러 엔티티 유형을 끌어들이고, 답이 그 엔티티들 사이의 관계 순회를 요구하고, 관계는 말뭉치에 존재하되 어느 단일 문서에도 명시적이지 않고, 사용자는 한 번의 최선 답이 아니라 빠짐없는 열거를 기대한다. 이 패턴을 일찍 — 프로젝트의 요구사항 단계에서 — 알아보는 것이, 자산운용사가 순수 텍스트 검색으로 여섯 달을 돌아간 우회로를 막는 건축가의 안목이다. 천장은 특정 임베딩 모델이나 리랭커의 한계가 아니라 문서를 고립된 단위로 다루는 것의 한계다. 처방은 문서를 더 잘 회수하는 것이 아니라, 문서들이 집합적으로 부호화한 관계 구조를 추출해 관계 질의를 받치는 형태로 저장하고, 관계 검색을 텍스트 검색과 통일된 아키텍처로 결합하는 것이다. GraphRAG가 그 처방의 프로덕션급 구현이다.
텍스트 검색은 내용이 질의와 유사한 문서를 찾을 수 있다. 그러나 일반적으로, 답이 여러 문서에 흩어진 사실들의 교집합이나 합성인 질문에는 답하지 못한다.
질문이 관계에 대한 추론 — 멀티홉 순회, 간접 연결의 빠짐없는 열거, 서로 다른 문서 유형의 사실 합성 — 을 요구할 때, 텍스트 검색 단독에는 구조적 천장이 있다. 더 나은 임베딩도, 더 나은 청킹도, 더 나은 재순위화도 이를 넘지 못한다. 처방은 아키텍처다 — 관계를 명시적으로 표상하고 그 위의 질의를 받치는 층을 더하는 것.
GraphRAG의 첫 공학 난제는 지식 그래프 자체의 구축이다. 지식 그래프는 엔티티(노드)와 그들 사이의 관계(간선)의 집합이며, 노드와 간선 모두 통상 유형화된 메타데이터를 지닌다. 기업 말뭉치라면 회사, 사람, 계약, 규정, 제품 같은 엔티티가 employed-by, signed, regulated-under, supplies-to 등 수십 가지 관계로 이어질 것이다. 난제는 원본 문서가 이 구조를 이미 추출된 채로 도착하지 않는다는 것 — 그래프를 지으려면 비구조 텍스트에서 엔티티를 식별하고 그들 사이의 관계를 추론해야 한다. 프로덕션을 지배하는 접근은 셋이고, 비용·품질·맞는 말뭉치가 서로 다르다.
손으로 짠 패턴 — 정규표현식, 의존 구문 분석, 레이블 데이터로 훈련된 개체명 인식기 — 으로 엔티티와 관계를 찾는다. 빠르고 결정론적이며 규모에서 돌리기에 싸다. 대가는 응용이 필요로 하는 모든 엔티티·관계 유형마다 규칙을 써야 하고, 그 규칙이 자연어의 변주 앞에서 부서지기 쉽다는 것이다.
적소 — 고도로 구조화된 말뭉치(일관된 형식의 규제 서류), 좁고 잘 정의된 엔티티 유형(금융 문서에서 회사명과 날짜만 추출), 추출이 감사 가능하고 설명 가능해야 하는 컴플라이언스 사유(추출 방법이 방어 가능해야 하는 법률·의료 도메인).
2026년의 지배적 접근 — 언어 모델에 텍스트 청크와 함께 지정된 유형의 엔티티와 지정된 술어의 관계를 추출해 JSON 같은 구조화 형식으로 반환하라는 프롬프트를 준다. 규칙 기반을 부수는 자연어 변주를 감당하고, 사소한 프롬프트 수정으로 새 유형에 일반화된다. 비용은 실재한다 — 청크마다 모델 호출 — 그러나 현대 API 가격에서 말뭉치 규모 추출은 성립한다. 청크 1,000개당 50센트로 잡으면 문서 100만 건 말뭉치의 추출에 대략 5,000달러 — 결과 그래프가 주는 가치의 일부에 지나지 않는다. 자체 호스팅 오픈소스 모델은 운영 복잡성을 대가로 비용을 더 낮춘다.
규율 — 자유 추출 대신 명시적 스키마(엔티티 유형, 관계 유형, 각 유형의 속성)를 주고, 출력을 스키마에 대해 검증하고, 어긋난 것은 걸러 내거나 검토로 돌린다. 많은 프로덕션이 2패스를 쓴다 — 빠르고 싼 모델의 1패스가 후보 트리플을 뽑고, 더 유능한 모델의 2패스가 후보를 검증하고 모호성을 푼다.
가장 정교한 프로덕션 시스템은 둘을 결합한다. 규칙이 스키마의 잘 정의된 고volume 부분 — 규제 서류의 구조화 데이터, 표 내용, 표준화된 코드와 식별자 — 을 맡고, 언어 모델이 열린 부분 — 산문의 관계 추출, 문서 간 엔티티 언급 해소, 규칙이 감지할 수 없는 암묵적 연결의 추론 — 을 맡는다.
적소 — 말뭉치에 구조·비구조 요소가 공존하고, 추출 품질이 공학 투자를 정당화할 만큼 중요하고, 규칙 집합과 프롬프트 엔지니어링을 함께 유지할 역량이 있는 진지한 기업 배포. 대부분의 응용이 지향할 만한 패턴이다.
# 스키마 검증을 갖춘 언어 모델 기반 추출 from pydantic import BaseModel, Field from typing import List, Literal import json class Entity(BaseModel): name: str type: Literal['Company', 'Person', 'Regulation', 'Contract'] aliases: List[str] = Field(default_factory=list) class Relationship(BaseModel): subject: str # 엔티티 이름 predicate: Literal['employs', 'signed', 'regulated_by', 'subsidiary_of', 'serves_on_board_of'] object: str # 엔티티 이름 evidence_chunk_id: str # 감사를 위한 출처 class ExtractionResult(BaseModel): entities: List[Entity] relationships: List[Relationship] EXTRACTION_PROMPT = """Extract entities and relationships from this text. Use only the entity types and predicates defined in the schema. Each relationship must reference entities you have extracted. Return JSON only; do not include explanatory text. Schema: - Entities: Company, Person, Regulation, Contract - Predicates: employs, signed, regulated_by, subsidiary_of, serves_on_board_of Text: {chunk_text}""" def extract_from_chunk(chunk, llm): response = llm.complete(EXTRACTION_PROMPT.format(chunk_text=chunk.text)) try: result = ExtractionResult.model_validate_json(response) # 모든 관계에 하류 감사를 위한 출처를 태그한다 for r in result.relationships: r.evidence_chunk_id = chunk.chunk_id return result except ValueError as e: log.warning(f'Extraction validation failed: {e}; skipping chunk') return ExtractionResult(entities=[], relationships=[])
출처(provenance) — 추출된 모든 관계에 그것이 나온 청크를 태그하는 것 — 는 실험적 그래프 추출을 프로덕션급 기반으로 바꾸는 운영 규율이다. 사용자가 그래프를 질의해 시스템이 연결 하나를 돌려주었을 때, 사용자는 왜냐고 물을 수 있다. 출처가 있으면 시스템은 그 주장을 받치는 원문을 보여 줄 수 있다. 출처 없는 그래프는 사용자가 믿어 주어야 하는 불투명한 단언이고, 출처 있는 그래프는 질의 가능하고 감사 가능한 말뭉치의 표상이다.
엔티티 해소(entity resolution) — "International Business Machines Corporation"과 "IBM"과 "IBM Corp."가 같은 엔티티임을 알아보는 문제 — 가 그래프 구축의 또 하나의 운영 난제다. 순진한 추출은 같은 엔티티가 여러 노드로 나타나는 그래프를 낳고, 이어져야 할 관계들을 조각낸다. 프로덕션은 해소를 추출 후 단계로 둔다 — 식별자 코드가 있을 때의 결정론적 규칙, 근사 중복 이름을 군집화하는 임베딩 유사도, 두 언급이 문맥상 같은 엔티티인지 모델에 묻는 언어 모델 추론. 대부분의 기업 GraphRAG 배포는 결국 셋을 결합해 쓰게 된다.
지식 그래프가 생기면 물음은 그것을 5장의 텍스트 검색 캐스케이드 곁에서 어떻게 쓰느냐가 된다. 지배적 아키텍처 패턴은 셋이고, 저마다 맞는 질의 유형이 다르다. 프로덕션급 GraphRAG는 셋 모두를 구현하고 질의의 구조적 필요에 따라 알맞은 패턴으로 라우팅한다.
가장 단순한 패턴 — 그래프로 텍스트 검색을 대체하지 않고 보강한다. 질의가 오면 텍스트 검색이 평소처럼 후보 청크를 내고, 생성 전에 시스템이 후보 청크에 언급된 엔티티들을 식별해 그래프에서 그들의 이웃 — 관련 엔티티, 최근 연결, 중요 속성 — 을 질의한다. 보강된 그래프 정보가 텍스트 청크와 나란히 언어 모델의 컨텍스트에 들어간다. 모델은 텍스트 내용과 구조적 맥락을 둘 다 얻는다. 기존 텍스트 RAG에 그래프 능력을 더하는 대부분의 팀에게 옳은 출발점이다 — 비파괴적이고, 구조 맥락이 중요한 질의에서 즉각적인 품질 개선을 낸다.
한계 — 순수 구조 질문에는 답하지 못한다. 텍스트 검색이 먼저 엔티티를 찾아 줘야 하고, 그것이 실패하면 그래프 보강은 일할 재료가 없다.
아키텍처를 뒤집는다. 질의에서 구조 요소 — 개체명, 관계 유형, 순회 제약 — 를 파싱해 그래프 질의로 번역해 먼저 돌린다. 그래프 질의가 관련 엔티티와 관계의 집합을 내면, 그 엔티티들로 필터링해 구조적 답을 부연하는 텍스트 청크를 회수한다. 자산운용사의 컴플라이언스 질문이 바로 그래프 우선형이다 — 그래프가 연결을 찾고, 텍스트가 그 연결을 상술하는 문서를 띄운다. 2026년의 표준 구현은 언어 모델로 자연어 질의를 그래프 질의 — 통상 Cypher(Neo4j)나 SPARQL류 — 로 번역한다. 모델에 그래프 스키마와 질문을 주고 구조화 질의를 만들게 하는 이 패턴, 이른바 text-to-Cypher는 Neo4j가 프로덕션화했고 여러 그래프 데이터베이스가 관리형 기능으로 제공하기 시작했다.
한계 — 그래프 증강보다 정교한 질의 파싱이 필요하고, 내용 중심 질의에서는 그르다.
가장 정교한 아키텍처 — 각 질의를 동적으로 알맞은 패턴에 배정한다. 가벼운 분류기 — 질의 특징에 대한 규칙일 때도, 레이블 예제로 훈련된 소형 언어 모델일 때도 있다 — 가 질의를 살펴 주로 내용 지향(텍스트 우선, 그래프 증강 가능)인지, 구조적(그래프 우선)인지, 진정 혼합(병렬 검색 후 결과 융합)인지 판정한다. 관계형 질의에서 그래프 우선의 품질 이득을 얻으면서, 필요 없는 내용 질의에 그래프 질의의 공학·지연 부담을 지우지 않는다.
한계 — 라우터 자체가 새 실패 양식이다. 잘못 배정된 질의는 그른 패턴으로 가서 답이 상한다. 다만 라우터 정확도를 감시하는 운영 규율은 대부분의 프로덕션이 기를 만큼 단순하다.
기존 텍스트 RAG에 GraphRAG를 더하는 대부분의 팀은 그래프 증강 검색으로 시작해야 한다. 비파괴적이고, 즉각적인 품질 개선을 내며, 더 정교한 패턴이 의지하기 전에 그래프 자체를 검증해 준다. 워크로드에서 관계형 질의가 흔하고 그래프 증강이 구조적 재현율을 탁자에 버려두고 있음이 측정으로 드러나면 그래프 우선으로 졸업하라. 라우팅 하이브리드는 두 패턴을 다 재 보았고 입증 가능한 정확도의 라우터를 지을 수 있을 때만 — 때 이른 라우팅은 들쭉날쭉한 검색 품질의 흔한 근원이다.
2024년 공개되어 2025년을 거쳐 2026년까지 급속히 채택된 Microsoft Research의 GraphRAG 구현은 현재 프로덕션에서 가장 영향력 있는 GraphRAG 패턴이다. 중심 기여는 커뮤니티 요약 기법 — 지금까지의 패턴들이 풀 수 없는 문제, 곧 특정 엔티티나 관계가 아니라 말뭉치 전체를 가로지르는 패턴의 이해를 요구하는 질의에 답하는 법이다.
전역 질문의 문제. 6.3절의 패턴들 — 그래프 증강, 그래프 우선, 라우팅 하이브리드 — 은 모두 그래프 안의 국소 이웃에서 돈다. 출발 엔티티나 관계가 주어지면 가까운 엔티티와 연결로 바깥을 향해 순회한다. "X에 무엇이 연결되어 있나", "누가 Y를 했나", "속성 W를 공유하는 Z 유형 엔티티는" 같은 질문에는 탁월하다. 그러나 "이 말뭉치를 가로지르는 주요 테마는 무엇인가", "회사의 전략적 초점은 어떻게 진화해 왔나", "고객 피드백 전반에 나타난 지배적 우려는" 같은 질문에는 답하지 못한다. 특정 출발점에서의 순회가 아니라 말뭉치 전체의 종합을 요구하는 전역 질문이기 때문이다. 순수 텍스트 검색이 시도할 수는 있으나 — 많은 청크를 회수해 모델에 종합을 시키는 식으로 — 결과는 컨텍스트 창에 제약되고, 말뭉치 전체가 아니라 가장 많이 회수된 청크 쪽으로 기운다.
커뮤니티 요약 접근. Microsoft GraphRAG의 해법은 그래프에서 출발해 세 구축 단계를 더 지난다. 첫째, 커뮤니티 검출 알고리즘 — 통상 그래프를 밀집 연결 군집들로 계층 분해하는 Leiden — 으로 지식 그래프의 커뮤니티를 찾는다. 각 커뮤니티는 그래프의 나머지보다 서로에게 더 이어진 엔티티 무리다. 기업 말뭉치라면 사업부, 프로젝트 팀, 제품군, 규제 도메인을 표상할 수 있다. 둘째, 언어 모델로 각 커뮤니티의 요약을 생성한다 — 커뮤니티의 엔티티와 관계, 각각의 선별된 원문 청크를 주고 그 커뮤니티가 무엇에 관한 것인지의 서사적 요약을 쓰게 한다. 이 요약들은 여러 문서에 걸친 테마와 패턴 — 어느 단일 문서가 아니라 말뭉치의 창발적 구조에 사는 내용 — 을 붙잡는다. 셋째, 질의가 오면 시스템은 커뮤니티 요약과 바탕 텍스트 청크를 함께 쓴다. 국소 질의는 앞서의 패턴대로 그래프를 순회하고, 전역 질의는 커뮤니티 요약 위에서 검색한다 — 테마와 패턴에 관한 질문에 그것을 표상하는 요약을 읽어 답하는 것이다. 이 결합이 국소 전용 패턴이 감당 못 하는 질의 스펙트럼의 양 끝을 다 다룬다.
실무적 고려. 커뮤니티 요약 패턴은 상당한 선행 투자를 요구한다. 규모에서의 커뮤니티 검출은 계산이 만만치 않고, 요약 생성은 여러 계층 수준에서 커뮤니티당 언어 모델 호출 — 큰 말뭉치라면 통상 수천 번 — 을 요구하며, 말뭉치가 변하면 주기적으로 재생성해야 한다. 문서 100만 건 말뭉치에 Microsoft식 GraphRAG를 짓는 총비용은 구축 주기당 수천 달러에, 결과 구조를 유지하는 저장·운영 비용이 더해진다. 이 비용은 전역 종합이 가치 있는 응용 — 전략 분석, 트렌드 식별, 테마·패턴 보고, 대형 말뭉치의 임원 요약 — 에서 정당화되고, 특정 엔티티 질의가 지배하는 응용에는 과잉 공학이다. 커뮤니티 요약의 가치가 그 비용을 정당화하는 때를 알아보는 것이 건축가의 안목이다 — 많은 프로덕션에서 정당화되지만, 결정은 의도적이어야 한다.
1단 — 그래프 구축. 언어 모델 기반 추출로 문서에서 엔티티와 관계를 뽑아 지식 그래프를 만든다.
2단 — 커뮤니티 검출. 계층적 커뮤니티 검출(Leiden 알고리즘)로 여러 입도에서 밀집 연결 엔티티 군집을 찾는다.
3단 — 커뮤니티 요약. 각 커뮤니티의 언어 모델 요약을 생성해, 군집의 집합적 내용에서 창발하는 테마와 패턴을 붙잡는다. 질의 시점에 국소 질의는 평소처럼 그래프를 순회하고, 전역 질의는 커뮤니티 요약 위에서 검색한다.
프로덕션의 GraphRAG는 텍스트 RAG와 근본적으로 다른 운영 규율이다. 텍스트 파이프라인은 문서 변경을 증분으로 흡수한다 — 새 문서 하나는 앞서의 모든 것과 독립적으로 임베딩되고 인덱싱되는 새 청크 한 벌이다. 지식 그래프는 그렇지 않다. 새 문서 하나는 엔티티·관계의 재추출, 기존 엔티티에 대한 해소, 커뮤니티 요약을 쓴다면 커뮤니티 구조의 갱신, 영향받은 요약의 재생성을 뜻한다. 운영 아키텍처는 처음부터 이를 감안해야 한다. 프로덕션이 씨름하는 축은 셋이다.
그래프를 최신으로 지키는 패턴은 셋이 지배한다. 주기적 전체 재구축 — 말뭉치 변화율에 따라 주간·월간·분기 일정으로 그래프 전체를 처음부터 다시 짓는다. 증분 갱신 — 전체 재구축 사이에 새 문서에서 추출해 기존 그래프에 병합한다. 하이브리드 — 추가분은 증분으로, 해소 표류를 청소하고 묵은 엔티티를 쳐내는 것은 주기적 전체 재구축으로. 대부분의 프로덕션이 하이브리드를 쓴다 — 증분 갱신이 새 문서의 일상적 흐름을 감당하고, 주기적 재구축이 증분 사이 누적된 엔티티 해소 오류와 묵은 연결을 바로잡으며 현재 말뭉치 상태로 커뮤니티 요약을 재생성한다. 알맞은 재구축 주기는 말뭉치 변화 속도와 응용이 견딜 수 있는 해소 표류에 달렸다 — 활발한 말뭉치는 주간, 안정된 말뭉치는 분기가 흔하다.
텍스트 검색의 품질 감시는 재현율·정밀도에 집중한다. GraphRAG는 한 층을 더한다 — 표상으로서의 그래프의 품질이다. 추출 오류, 빠진 관계, 부실한 엔티티 해소를 지닌 그래프는 검색 캐스케이드가 아무리 잘 조율돼도 오답을 낸다. 프로덕션은 그래프 고유 지표를 추적한다 — 엔티티 중복률(같은 실세계 엔티티가 여러 노드로 나타나는 빈도), 관계 커버리지(있어야 할 관계가 빠진 빈도), 출처 무결성(관계가 유효한 원문 청크를 지닌 비율), 커뮤니티 안정성(재구축 사이 커뮤니티 구조가 변하는 정도). 이 지표들은 선택이 아니다 — 소리 없이 퇴화하는 그래프(누적되는 추출 오류, 겹쳐 붇는 해소 표류, 자의적이 되어 가는 커뮤니티)는 어느 것도 고장 나 보이지 않으면서 서서히 틀려 가는 검색 시스템을 낳는다. 규율은 그래프를 일급 산출물로 감시하는 것 — 퇴화가 사용자 가시적이 되기 전에 드러내는 대시보드와 경보다.
GraphRAG는 텍스트 RAG보다 의미 있게 비싸다. 추출은 수집 중 청크당 모델 호출을, 해소는 모호한 엔티티에 대한 추가 호출을, 커뮤니티 검출과 요약은 더 많은 호출과 상당한 계산을 요구한다. 추출·해소·요약에 바탕 그래프 데이터베이스 운영까지 더한 총 지속 비용은 비교 가능한 텍스트 RAG의 5~10배에 이를 수 있다. 대부분의 응용에서 품질 개선이 그 값을 하고, 어떤 응용에서는 그렇지 않다 — 어느 쪽인지 알아보는 것이 GraphRAG 아키텍처에 매이기 전의 건축가의 안목이다. 다행한 소식은 그래프가 한번 서면 비용이 말뭉치 크기에 준선형 이하로 붙는다는 것이다. 증분 갱신은 새 문서만 건드리고, 커뮤니티 구조는 천천히 변하며, 비싼 연산은 대부분 주기적 재구축이다. GraphRAG를 성공적으로 운영하는 팀은 이 재구축을 배경에서 몰래 돌아야 할 과정이 아니라 계획된 운영 이벤트 — 일정 잡고, 감시하고, 검증하는 — 로 다룬다.
초기 GraphRAG 구현들은 추출 품질에 몰두하느라 출처 — 추출된 각 관계에서 그것을 받치는 원문 청크로의 연결 — 를 담는 것을 잊곤 한다. 출처 없는 그래프는 불투명한 단언이 된다. 사용자는 연결을 보지만 감사할 길이 없다. 답이 행동으로 이어지는 어떤 프로덕션 배포에서도 이는 용납되지 않는다. 출처는 협상의 여지가 없다 — 처음부터 추출 스키마에 설계해 넣어라.
GraphRAG는 관계형 질의가 지배하는 응용에 옳은 아키텍처다. 사용자가 주로 텍스트 RAG가 잘 다루는 내용 회수형 질문을 하는 응용에는 비싸고 부당한, 그른 아키텍처다. 많은 팀이 유행이라는 이유로 GraphRAG를 도입해 비싼 인프라를 짓고는, 질의 분포가 그래프 추론에 의지하지 않아 투자를 영영 회수하지 못한다.
처방 — 질의 분포부터 감사하라. 관계형 질의가 작은 소수라면 텍스트 RAG에 머물러라.
중복 해소 없는 추출은 'Apple Inc.', 'Apple Computer', 'Apple, Inc.'가 별개 노드로 나타나는 조각난 그래프를 낳는다 — 이어져야 할 관계들이 세 개의 단절된 하위 그래프에 흩어지고, 조각난 엔티티에 의지하는 질의는 불완전한 결과를 돌려준다.
처방 — 해소는 미래의 개선이 아니라 추출 파이프라인의 일급 단계여야 한다. 프로덕션은 여러 해소 방법을 결합해 쓰고 중복률을 품질 지표로 상시 감시한다.
대부분의 GraphRAG 구현은 초기 설계 때 엔티티·관계 스키마를 정하고 고정된 것으로 취급한다. 스키마는 곧 시스템이 벗어날 수 없는 족쇄가 된다 — 말뭉치가 진화하며 떠오르는 새 엔티티 유형은 표상될 수 없고, 새 관계 유형은 안 맞는 기존 술어에 억지로 끼워지며, 그래프는 말뭉치의 실재에서 점점 갈라진다.
처방 — 스키마를 살아 있는 산출물로 다뤄라. 분기마다 검토하고, 응용의 필요가 진화하는 대로 엔티티·관계 유형을 더하는 공식 절차를 두어라.
텍스트 검색에는 멀티홉·관계형 질의에 대한 구조적 천장이 있다. 답이 문서들 사이의 관계에만 존재하는 질문은 캐스케이드를 아무리 조율해도 답할 수 없다. GraphRAG는 관계를 질의 가능한 그래프에 명시적으로 표상해 그 천장을 깨는 프로덕션 아키텍처다.
지식 그래프는 스키마 검증과 출처 추적을 갖춘 언어 모델 기반 추출로 비구조 텍스트에서 뽑는다. 규칙 기반은 고도 구조화 말뭉치에, 언어 모델은 열린 자연어에 맞고, 하이브리드 추출이 프로덕션급 기업 배포를 위해 둘을 결합한다.
텍스트 검색과 그래프 순회를 엮는 하이브리드 아키텍처는 셋이다. 그래프 증강은 기존 텍스트 RAG에 구조 맥락을 더하고, 그래프 우선은 관계형 질의를 위해 아키텍처를 뒤집으며, 라우팅 하이브리드는 질의 특성에 따라 동적으로 고르는 — 성숙한 프로덕션의 지배 패턴이다.
Microsoft GraphRAG의 커뮤니티 요약 패턴은 국소 그래프 순회가 답할 수 없는 전역 종합 질문으로 GraphRAG를 확장한다. 짓기에 비싸지만, 대형 말뭉치를 가로지르는 테마·패턴 추론이 필요한 응용에는 고유하게 값지다.
프로덕션의 GraphRAG 운영에는 텍스트 RAG에 없는 규율이 필요하다 — 증분+재구축 주기의 그래프 최신성, 일급 운영 관심사로서의 그래프 품질 감시, 그리고 명시적 비용 관리(GraphRAG는 비교 가능한 텍스트 RAG의 5~10배 운영 비용이다). 맞는 응용에서는 품질 개선이 값을 하며, 그 응용을 알아보는 것이 건축가의 안목이다.
위 문헌 목록은 원서 6장의 Further Reading을 그대로 옮긴 것이다. 서지 사항의 최종 확인은 원 출처를 통해 하는 것이 옳다.
7장은 3부의 에이전틱 패턴을 자기교정 검색으로 이어 간다. 5장에서 지은 하이브리드 검색 캐스케이드와 이 장의 GraphRAG 아키텍처가 함께 검색의 기층을 이루고, 다음 층이 성찰을 더한다 — 자신이 무엇을 회수했는지 평가하고, 증거가 충분한지 판정하고, 다른 접근으로 재시도하거나 답변을 거부하는 시스템의 능력이다. 검색이 참으로 에이전틱해지는 곳, 1장에서 말한 건축적 전환이 마침내 구현으로 구체화되는 곳이 여기다. 단청의 무늬를 그렸으니, 이제 그 전각에 사람을 — 스스로 살피고 고쳐 나가는 마음을 — 들일 차례다.