지식 강화 RAG Knowledge-Enhanced RAG

유사성으로는
닿을 수 없는 질문

RAG는 정보 검색에 접근하는 방식을 근본적으로 바꿨다. 키워드 일치라는 경직된 세계를 넘어 더 유동적이고 직관적인 시맨틱 검색의 영역으로 옮겨왔다. 이 전환으로 문서가 담은 특정 단어만이 아니라 개념적 의미에 근거해 문서를 찾을 수 있게 되었다.

그런 강점에도, 벡터 검색이나 하이브리드 검색만으로 세운 시스템은 실체 사이의 관계를 더 정밀하게 이해해야 하는 질의에서 힘들어할 수 있다. 이 문제가 생기는 이유는 벡터 검색이 확률과 유사성을 다루고 결정론적 사실을 다루지 않기 때문이다. 앞의 세 유형이 그런 예다.

7장에서 논의한 대로 AI 에이전트가 질의를 하위 질의로 세심히 쪼개고 도구를 반복적으로 써서 이 시나리오들을 온전히 다룰 수 있을지도 모른다. 그럼에도 이 장에서 탐색하려는 것은 이 질문이다. AI 에이전트에 의존하지 않고 RAG의 검색 정확도를 개선할 방법이 있는가.

답은 지식 그래프(KG)다. 이런 유형의 질의를 다루는 데 값진 도구가 되며, KG를 만들고 배포하는 프로덕션 복잡성은 이런 복잡한 질의가 흔하고 고품질 응답의 실패가 사업 결과에 실질적 영향을 줄 때 정당화된다.

지식 그래프 개요

지식 그래프는 사실적 지식을 기계가 읽을 수 있는 형태로 부호화한, 상호연결된 실체의 네트워크다.² KG가 실무에서 어떻게 작동하는지 보이기 위해 IMDb 데이터셋을 쓴다. 영화, TV 시리즈, 비디오 게임과 그것에 관여한 사람들에 관한 구조화된 데이터를 제공하며, 각각 고유한 IMDb ID로 식별된다.

KG에 질의하는 일은 벡터 검색처럼 유사성을 찾는 일이 아니다. 알려진 사실이나 실체의 경로를 순회하는 일이다. 앞의 멀티홉 질문에 답하려면 구조화된 질의를 수행한다. Inception 노드를 찾고, DIRECTED 엣지를 거슬러 크리스토퍼 놀런을 찾고, 그에게서 나가는 모든 DIRECTED 엣지를 순회해 다른 영화를 찾고 2014년 것만 남기고, 마지막으로 각 영화 노드에서 ACTED_IN 엣지를 따라 주연 배우를 식별한다.

지식 그래프를 어떻게 검색하는가

그래프 데이터베이스는 데이터를 그래프 구조로 저장하며 데이터 포인트 사이의 관계를 강조하는 특수한 NoSQL 데이터베이스다. 행과 열의 표를 쓰는 전통적 관계형 데이터베이스와 달리 노드와 엣지로 그래프 데이터를 표현하며, 그래프 질의의 효율적 실행을 위해 설계되었다. 대표적인 예로 Neo4j, Amazon Neptune, Kuzu, TigerGraph가 있다. 그래프 데이터베이스와 상호작용해 정보를 얻으려면 Cypher나 SPARQL 같은 그래프 질의 언어를 쓴다.

Cypher

Neo4j를 위해 개발된 Cypher는 그래프 구조 자체를 시각적으로 닮은, 직관적이고 대단히 읽기 좋은 문법으로 알려져 있다. Cypher에서 노드는 소괄호 ()로, 엣지는 대괄호 []로 표현된다. 어떤 사람이 영화를 감독한 패턴을 찾으려면 이렇게 쓴다.

(p:Person)-[:DIRECTED]->(m:Movie)

• (p:Person)은 Person 라벨의 모든 노드를 선택하며, p라는 변수명을 주었다.
• (m:Movie)는 Movie 라벨의 모든 노드를 선택하며, m이라는 변수명을 주었다.
• [:DIRECTED]는 엣지를 서술하며 관계 유형이 DIRECTED임을 지정한다.
• ->는 관계의 방향을 나타낸다. 사람이 영화를 감독했다는 뜻이다.

MATCH (p:Person)-[:DIRECTED]->(m:Movie)
WHERE m.title = 'Oppenheimer'
RETURN p.name

이 질의는 데이터베이스에 지정된 패턴을 MATCH하고, 영화 제목이 오펜하이머인 곳을 WHERE로 걸러내고, 찾아낸 사람 노드의 name 속성을 RETURN하라고 지시한다.

SPARQL

SPARQL은 지식 그래프의 특수한 유형인 RDF 트리플 스토어의 표준 질의 언어다. 그래프를 구성하는 세 부분 진술인 트리플에 질의하기 위해 선언적 패턴 매칭 문법을 쓴다.

SELECT ?personName
WHERE {
  ?movie  :title     "Oppenheimer" .
  ?person :directed  ?movie .
  ?person :name      ?personName .
}

?person, ?movie, ?personName은 변수다. WHERE 절의 각 줄은 데이터베이스가 맞춰야 할 트리플 패턴이다. Cypher만큼 시각적으로 매력적이지는 않지만 SPARQL은 그래프의 연결 데이터에 질의하는 강력한 W3C 표준이며, 필요한 데이터를 정확히 지정하도록 설계되었다. 그래프 이론의 탐색보다는 데이터 전달의 형태와 최적화에 관한 것이다.

실무에서는 둘 다 비슷한 결과를 얻을 수 있고, 그래프 데이터베이스가 무엇을 제공하는지와 무엇에 익숙한지에 정말로 달려 있다. 이 장의 나머지는 Cypher로 예제를 제공하지만 SPARQL로도 손쉽게 할 수 있으며, 어느 하나를 선호한다는 표시는 아니다.

온톨로지와 스키마

지식 그래프의 세계에서 온톨로지와 스키마라는 용어를 자주 듣게 된다. 둘은 밀접히 관련되지만 시스템 설계에서 서로 다른 목적을 갖는다.

RAG에서 지식 그래프 쓰기

KG를 RAG에 어떻게 쓸 수 있는지 보이기 위해 영화 세계의 예를 확장해, 상호보완적인 두 데이터 소스로 영화 지식 그래프를 만든다.

영화 지식 그래프 구축하기

시작하려면 먼저 Neo4j를 설치하고 사용자명과 비밀번호로 계정을 설정한다(다시 말하지만 어떤 그래프 데이터베이스든 괜찮다). 다음 단계는 각본 자체의 처리다. 각 각본에서 먼저 XML 태그를 정리한 뒤 LangChain으로 청크로 쪼갠다.

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=CHUNK_SIZE,
    chunk_overlap=CHUNK_OVERLAP,
    length_function=len,
    is_separator_regex=False,
)

cleaned_script = re.sub(r'<[^>]+>', ' ', script_content)
cleaned_script = re.sub(r'\s+', ' ', cleaned_script).strip()
chunks = text_splitter.split_text(cleaned_script)

이 청크를 Chunk 노드로 그래프에 넣기 전에, 명명 실체 인식(NER)의 한 형태로 각본의 Character 실체를 식별한다. 다행히 영화 각본에는 등장인물 이름이 대문자로 쓰이는 공통 구조가 있어 정규식으로 비교적 쉽게 식별할 수 있다.

# 패턴 1: 등장인물 이름으로 시작하는 줄 (전부 대문자, 콜론이나 줄바꿈이 뒤따른다)
# 예: "JOHN:", "MARY\n"
char_pattern1 = re.findall(
    r'^([A-Z][A-Z\s]{2,20}?)(?::|$)', script_text, re.MULTILINE
)
characters.update(
    [name.strip() for name in char_pattern1 if len(name.strip()) > 2]
)

# 패턴 2: 괄호 안의 등장인물 이름
# 예: "(JOHN enters)", "(MARY speaking)"
char_pattern2 = re.findall(
    r'\(([A-Z][A-Z\s]{2,15}?)(?:\s+[a-z]|\))', script_text
)
characters.update(
    [name.strip() for name in char_pattern2 if len(name.strip()) > 2]
)

이 정규식으로 추출된 이름 일부는 틀리므로, 더 견고하게 만들기 위한 임시 파싱 로직을 추가한다. 유효한 등장인물 이름은 각본에 최소 세 번 나타나야 하고, THE·AND·WITH·HIM처럼 이름으로 오인될 수 있는 흔한 단어를 제거한다.

마지막 단계는 그래프의 관계를 만드는 일이다. 여기서는 Chunk 노드를 Movie 노드와 Character 노드에 연결한다. 「골든아이」의 어떤 청크에서 KOLKHAZHNA, MARINA, BOND라는 등장인물이 언급되었다면, 그 청크에 대해 다음 관계를 그래프 구조에 추가할 수 있다.

(Chunk)-[:MENTIONS]->(Character)
(Character)-[:APPEARS_IN]->(Movie)

(Person)-[:DIRECTED]->(Movie)
(Person)-[:ACTED_IN]->(Movie)
(Movie)-[:HAS_GENRE]->(Genre)
(Character)-[:PORTRAYED_BY]->(Person)

이제 필요한 것을 갖췄다. 영화 각본의 청크와 메타데이터를 IMDb의 추가 정보와 관계와 통합한 지식 그래프다.

질의 시점에 지식 그래프를 쓰는 법

KG가 노드와 관계로 채워지면 두 가지 흔한 사용 패턴 가운데 하나로 질의 흐름에 통합할 수 있다. 청크 보강과 하이브리드 그래프 검색이다.

패턴 1 — 청크 보강

이 접근에서 검색 과정은 사용자 질의에 의미적으로 가장 관련된 텍스트 청크를 찾는 표준 벡터 검색으로 시작한다. 그러나 원시 청크 텍스트는 흔히 “얇은” 참조를 담고 있다. 잘못 표기된 이름이나 “그”라는 대명사처럼, LLM이 사실적 답변을 제공하는 데 필요한 온전한 맥락이 결여된 것들이다.

KG로 이 청크를 동적으로 보강한다. 텍스트에서 발견된 실체에 대해 그래프 조회를 수행하는 방식이다. 다음 질의를 생각해 보자. “‘They call it a Royale with Cheese’라고 말한 배우는 누구이고, 어떤 영화였는가?”

먼저 표준 벡터 검색으로 “Royale with Cheese” 텍스트를 담은 청크를 찾는다. 최상위 일치로 다음 청크가 검색될 수 있다.

벡터 검색은 성공했다. 정확한 대사 줄을 찾아냈다. 그러나 원시 텍스트를 보면 이것으로는 사용자 질문에 답할 수 없다. 영화 이름이 없고, 배우 이름도 없고, 등장인물 이름(Vincent)만 있다.

그래프 보강 단계는 청크 텍스트에서 Character: Vincent 실체를 식별하고, KG로 텍스트에 없는 추가 맥락을 얻는다.

원시 청크 텍스트만 LLM에 보내는 대신, 청크와 이 추가 정보를 담은 지식 맥락 패킷을 함께 보낸다. 그러면 LLM이 100% 확실하게 답할 수 있고, 모호한 조각이 데이터가 풍부한 사실로 변한다.

패턴 2 — 하이브리드 그래프 검색

이 접근에서는 먼저 LLM에게 사용자의 자연어 질문을 그래프 데이터베이스가 실행할 수 있는 형식적 그래프 질의 언어로 직접 변환하도록 요청한다. 그래프에서 관련 청크를 추출해 벡터 기반 검색이 가져온 청크와 결합하려는 의도다.

이것이 성공하려면 LLM에 먼저 그래프의 스키마를 주어야 한다. 가용한 노드 라벨(Person, Movie, Chunk), 관계 유형(:DIRECTED, :ACTED_IN), 속성의 청사진이다. 이 스키마가 유효한 그래프 질의를 쓰기 위해 필요한 “어휘”와 “문법”을 LLM에 제공한다. 예로 이 질문을 생각해 보자. “골든아이의 모든 등장인물은 누구인가? 그중 누가 본드와 상호작용했는가?”

// 1단계: 골든아이의 모든 등장인물을 찾는다
MATCH (m:Movie)
WHERE toLower(m.title) CONTAINS 'goldeneye'
WITH m
MATCH (c:Character)-[:APPEARS_IN]->(m)
WITH m, collect(DISTINCT c.name) AS all_characters, m.title AS movie_title

// 2단계: 본드와 상호작용한 인물을 찾는다 (같은 청크에 함께 언급된 경우)
MATCH (m2:Movie)
WHERE toLower(m2.title) CONTAINS 'goldeneye'
MATCH (ch:Chunk)-[:BELONGS_TO]->(m2)

// 본드를 언급하는 청크를 찾는다 (퍼지 매칭: 'bond')
MATCH (ch)-[:MENTIONS]->(bond_char:Character)
WHERE toLower(bond_char.name) CONTAINS 'bond'

// 같은 청크에 언급된 다른 인물을 찾는다
MATCH (ch)-[:MENTIONS]->(other_char:Character)
WHERE other_char <> bond_char

WITH movie_title, all_characters,
     collect(DISTINCT other_char.name) AS interacted_with_bond,
     collect(DISTINCT ch.text)[0..10] AS chunks
RETURN movie_title, all_characters, interacted_with_bond, chunks

벡터 검색의 청크만 쓰면 정보가 부족해 RAG는 “이 질문에는 답할 수 없다”고 응답한다. 그러나 벡터 검색의 청크와 그래프 DB의 청크를 결합해 생성 LLM에 함께 보내면 훨씬 나은 응답을 얻는다.

보강과 하이브리드 검색 중에 고르기

둘 다 KG의 힘을 활용하지만 서로 다른 문제를 풀고 서로 다른 운영 비용을 안고 온다.

청크 보강은 “메타데이터 우선” 전략이다. 벡터 검색이 관련 텍스트를 찾는 데 이미 효과적이지만 그 텍스트 자체에 더 넓은 맥락이 없다고 가정한다. 질의는 의미론적이면서(영화의 특정 대사를 묻는 것처럼) 답에는 조각에 없는 외부 사실(배우 이름 같은)이 필요할 때 이상적인 선택이다. 검색된 청크 ID의 색인된 단순 조회이므로 지연이 사실상 없고 프로덕션에서 대단히 안정적이다.

하이브리드 그래프 검색은 반대로 “발견 우선” 전략이다. 사용자 질의가 구조적이거나 관계적이어서 벡터 검색이 놓칠 연결을 순회해야 할 때 뛰어나다(“세 장면 이상에서 본드와 상호작용한 모든 인물을 찾아라”). 그러나 이 힘에는 무시할 수 없는 프로덕션 복잡성이 따른다. LLM이 자연어를 데이터베이스 질의로 번역하는 “text-to-Cypher” 파이프라인을 관리해야 하고, LLM이 유효하지 않은 문법을 환각하는 등의 추가 위험이 생긴다. 안전하게 돌리려면 질의 타임아웃과 재시도 전략을 고려해야 한다.

임베딩을 어디에 둘 것인가

프로덕션에서 위 패턴을 구현할 때의 또 하나의 중요한 결정은 벡터 임베딩이 어디에 상주할지다. 이 선택은 시스템의 일관성, 지연, 운영 오버헤드에 영향을 준다.

지식 그래프 구축

영화 KG를 만든 일반적 접근은 이렇다. 먼저 그래프 스키마를 설계했다. Person, Movie, Character, Genre, Chunk 노드와 ACTED_IN, PORTRAYED_BY, DIRECTED 같은 관계를 포함하기로 정했다. 그다음 IMDb와 MovieSum 데이터셋의 맞춤 전처리로 그래프 자체를 채웠다.

영화 각본에서는 등장인물 이름이 비교적 쉽게 식별되기에 이 과정의 일부를 자동화할 수 있었다. 그러나 그 단순화에도 “her”나 “his”처럼 이름으로 오인된 단어를 제거하는 수작업이 필요했다. IMDb 데이터셋은 이미 만들어지고 정제되어 있었다. 그 데이터셋의 제작자들이 어려운 일을 전부 해준 것이다.

지식 그래프 구축의 자동화

수작업으로 KG를 선별하면 깨끗하고 정확한 결과를 낼 수 있지만, 전문가 주도의 이 접근은 노동 집약적이고 빠르게 심각한 병목이 된다. 실제로 KG 구축은 현대 엔터프라이즈 애플리케이션의 요구를 충족할 만큼 확장되는 일이 드물다. 새롭고 비정형인 정보가 끊임없이 흘러드는 동적 RAG와 에이전틱 시스템에서 특히 그렇다. 대신 텍스트에서 그래프를 만드는 자동화 접근이 점점 흔해지고 있으며, 세 단계를 따른다.

1. 핵심 “사물”을 찾는다 (엔티티 식별). 텍스트를 훑어 중요한 명사를 찾고 범주화한다. “Apple”을 “조직”으로, “Steve Jobs”를 “사람”으로 식별하는 식이다. 이 사물들이 그래프의 노드가 된다.
2. 연결을 찾는다 (관계 추출). 문장을 분석해 이 사물들이 어떻게 관계되는지 알아낸다. “Apple was founded by Steve Jobs”라는 문장을 보고 (Apple, FOUNDED_BY, Steve Jobs)로 표현되는 연결을 만든다.
3. 중복을 정리한다 (엔티티 링킹). 마지막으로 같은 사물의 다른 이름들이 모두 하나의 항목이나 노드를 가리키도록 데이터를 정리한다. “Apple”, “Apple Inc.”, “아이폰을 만드는 회사”가 모두 같은 실체임을 학습한다.

LLM을 쓰면 이 단계들이 극적으로 정돈된다. 과제마다 별도의 구식 전문 NLP 모델을 쓰는 대신, 강력한 LLM 하나가 문서를 읽고 구조화된 실체–관계 트리플 집합을 직접 출력하도록 프롬프트를 받을 수 있다. 엔지니어링 복잡성이 단순해지고, LLM의 방대한 세계 지식과 섬세한 맥락 이해 덕에 결과도 흔히 개선된다.

엔티티 링킹 — 하나의 사물, 여러 이름

LLM을 써도 핵심 난제가 남는다. 실세계 엔터프라이즈 데이터는 지저분하고 일관되지 않으며, 하나의 실세계 “사물”이 여러 다른 이름이나 식별자로 참조될 수 있다.

엔티티 링킹을 효과적으로 다루려면 명확한 온톨로지를 정의하는 데서 시작해야 한다. 도메인에 존재하는 “사물”(사람·회사·약물 같은 실체의 클래스나 유형)과 그것들이 가질 수 있는 속성과 관계를 정의하는 것이다. 엔티티 링킹의 맥락에서 온톨로지는 “하나의 사물, 여러 이름” 문제를 풀 기본 구조를 제공한다. 회사 실체가 하나의 정규 명칭(“International Business Machines Corp.”)과 별칭 목록(“IBM”, “I.B.M.”)을 갖는다고 정의할 수 있다. 나중에 시스템이 “IBM Inc.”를 만나면 새 노드를 만드는 것이 아니라 그것을 별칭으로 인식해 기존 정규 노드에 연결하는 것이 자기 과제임을 안다.

온톨로지를 목표 구조로 손에 쥐고 나면, 엔티티 링킹 과정은 실체를 능동적으로 맞추고 연결하고 병합하는 일이 된다. 이는 단일 알고리즘이 아니라 다단계 파이프라인이며 보통 두 단계를 포함한다.

전체 과정은 초기 부트스트랩 단계를 포함한다. 기존 데이터 전체에 대규모 작업을 돌려 정규 실체의 최초 집합을 만든다. 그 뒤에는 증분 모드를 쓰는 것이 일반적이다. 새 비정형 데이터가 도착하면 엔티티 링킹 모델이 새 표면형(“Tylenol”)을 그래프의 기존 정규 실체(“acetaminophen”의 Drug 노드)에 맞춘다.

여기에 인간 개입을 더할 수도 있다. 시스템의 일치 신뢰도가 낮으면(“Christian”이 “Christopher”와 같은지 반반이라면) 전문가 검토를 위해 모호성에 표시를 단다. 희소한 인간 노력을 가장 어려운 경우에만 집중시켜, 시스템이 확장하면서도 전문가 피드백으로 정확도를 계속 학습하고 개선하게 한다. 엔티티 링킹(전산학 문헌에서 레코드 연결이라고도 한다)은 대규모와 지저분한 데이터에서 특히 어렵고, LLM의 막대한 힘을 활용해도 텍스트에서 KG를 생성하는 자동화가 어렵다는 사실을 부각시킨다.

표준 온톨로지와 기성 지식 그래프를 활용하기

지식 그래프를 맨땅에서 만드는 일은 위험이 큰 사업이다. 한 추정에 따르면 그런 프로젝트의 50% 이상이 실패한다.³ 기술적 이유는 흔히 관련된 복잡성, 특히 엔티티 링킹의 복잡성을 과소평가하는 것이다. 그러나 또 하나의 흔한 이유는 초점을 맞춘 사용 사례 주도 접근을 택하는 대신 도메인의 “모든 것”을 모델링하려는 시도다.

표준 온톨로지는 이 불필요한 함정을 피하게 돕는 출발점을 제공한다. 금융이나 의료 같은 특정 도메인의 핵심 개념과 관계를 정의하는 형식적이고 표준화된 구조를 제공한다. 온톨로지를 충분히 생각해 두면 개발 시간을 절약하는 것만이 아니라 데이터 모델이 올바르고 일관되고 상호운용 가능하도록 보장해, 지나치게 넓고 쓸 수 없는 그래프를 만드는 흔한 함정을 막는다.

온톨로지를 쓰는 일은 지식 그래프의 청사진을 제공하므로 도움이 되지만, 데이터로 채워야 하는 일은 여전히 남는다. Dun & Bradstreet, Refinitiv(현 LSEG), S&P Global 같은 기업은 엔티티 링킹이라는 어려운 일에 수백만 시간을 투자했고, 최근에는 D-U-N-S 번호나 PermID 같은 정규 식별자를 부여해 실체를 고유하게 식별하고 복잡한 기업 위계를 사상하는 선별 데이터 피드로 이 데이터를 라이선스하는 방향으로 움직이고 있다.

이런 데이터를 라이선스하는 일차적 가치는 고품질의, 이미 해소된 핵심 지식 그래프를 제공한다는 점이다. 모든 것을 스스로 해소하는 막대한 노력을 면하게 된다. 과제는 훨씬 작고 다루기 쉬운 문제로 축소된다. 새롭고 지저분한 내부 데이터를 제공자의 확립된 정규 실체에 연결하는 일이다. 그러면 우리 시스템의 “IBM”이나 “I.B.M.”을 “International Business Machines Corp.”의 단일 골든 레코드에 연결할 수 있다. 다만 이런 라이선스 KG에도 단점이 있다. 라이선스 비용에 더해, 이 특정 형태의 KG를 쓰겠다는 약속과 다른 모든 데이터 시스템이 그것에 맞춰야 한다는 점을 고려해야 한다.

GraphRAG

기술적 용어로 이 과정은 질의 초점 요약(QFS, query-focused summarization)이라 알려져 있다. 몇 개의 구체적 조각이나 청크를 검색하는 것이 아니라, 데이터의 전역적 조망에 근거해 포괄적 답변을 생성하는 것이 목표다.

GraphRAG는 LLM으로 원본 문서에서 그래프를 자동 구축한다. 그 그래프로 클러스터(커뮤니티)를 식별하고, 그것을 요약하고, 이 과정을 그래프 최상위까지 반복해 전역적 맥락의 이해를 가능하게 한다.

실제로 돌려 보기 — 비용과 시간

마이크로소프트의 graphrag 패키지는 오픈소스다. MovieSum 데이터셋에 적용해 본다. GraphRAG는 색인 시점에 모든 문서를 처리하기 위해 아주 많은 LLM 호출을 하므로 꽤 비싸고 시간이 걸린다. 그래서 비용이 합리적인 수준이 되도록 무작위로 영화 20편을 고른다.

import pandas as pd
import numpy as np
from datasets import load_dataset

moviesum_dataset = load_dataset("rohitsaxena/MovieSum")
moviesum_df = pd.DataFrame(moviesum_dataset['train'])

np.random.seed(42)
SAMPLE_SIZE = 20
indices = np.linspace(0, len(moviesum_df) - 1, SAMPLE_SIZE, dtype=int)
filtered_df = moviesum_df.iloc[indices].copy()

from datetime import datetime

input_docs = []
current_date = datetime.now()
for idx, row in filtered_df.iterrows():
    input_docs.append({
        'id': row['imdb_id'],
        'title': row['movie_name'],
        'text': row['script'],
        'creation_date': current_date
    })
input_df = pd.DataFrame(input_docs)

from graphrag.api import build_index
from graphrag.config.load_config import load_config

GRAPHRAG_DIR = Path("./graphrag_workspace")
config = load_config(root_dir=GRAPHRAG_DIR)

results = await build_index(
    config=config,
    input_documents=input_df,
    verbose=True
)

이것은 한참 걸린다. GraphRAG 색인이 단순한 일회 통과 과정이 아니기 때문이다. 시스템은 모든 텍스트 청크마다 수십 번의 순차적 LLM 호출을 해야 한다. 먼저 실체와 주장을 추출하고, 그 실체를 해소하고 병합하고, 마지막으로 여러 계층의 커뮤니티 요약을 생성한다. 이 단계 각각이 연산이 비싸고 LLM의 추론 속도에 의존하므로, 적은 데이터셋에서도 누적 지연이 커진다.

GraphRAG는 출력 폴더에 build_index 과정의 결과를 담은 파케이 파일들을 생성한다. 질의를 돌리려면 먼저 이 데이터셋을 판다스 데이터프레임으로 로드한다.

config = load_config(root_dir=GRAPHRAG_DIR)

entities_df      = pd.read_parquet(OUTPUT_DIR / "entities.parquet")
relationships_df = pd.read_parquet(OUTPUT_DIR / "relationships.parquet")
communities_df   = pd.read_parquet(OUTPUT_DIR / "communities.parquet")
reports_df       = pd.read_parquet(OUTPUT_DIR / "community_reports.parquet")
text_units_df    = pd.read_parquet(OUTPUT_DIR / "text_units.parquet")

예로 “모든 영화 각본에 걸친 주요 주제와 서사 패턴은 무엇인가?”라는 질의로 global_search를 돌리면 다음과 같은 결과를 얻는다.

주목할 점은 응답이 [Data: Reports (…)] 형태로 어떤 커뮤니티 보고서에 근거했는지 표시한다는 것이다. 전체 응답은 꽤 방대하다.

GraphRAG가 잘못된 도구인 경우

의미 파악 질문에 답하는 힘에도 GraphRAG의 일차적 단점은 앞서 본 대로 선행 전처리의 막대한 비용과 시간이다. 표준 RAG 시스템이 텍스트를 청킹하고 벡터 임베딩을 생성하는 비교적 빠르고 저렴한 과정만 필요한 반면, GraphRAG는 다단계의 연산 집약적 전처리 파이프라인에 들어간다. 강력한 LLM이 먼저 코퍼스 전체를 읽어 실체와 관계를 추출하고, 방대한 지식 그래프를 만들고, 복잡한 커뮤니티 검출 알고리즘을 그 그래프에 돌리고, 마지막으로 다시 LLM으로 식별된 모든 주제의 계층 요약을 생성한다.

궁극적으로 질의가 대부분 단순한 사실 검색(“X의 가격은 얼마인가?”)이라면, GraphRAG의 상당한 투자는 표준 시맨틱 검색에 비해 거의 아무 투자수익도 주지 않는다.

그래프 데이터베이스 인프라

지식 그래프를 애플리케이션에 통합하는 일은 아키텍처 결정에 그치지 않는다. 장기적인 운영·시스템 수준의 약속이다. 고정밀하고 설명 가능한 답변의 잠재력이 큰 만큼, 그래프 데이터베이스를 만들고 확장하고, 무엇보다 유지하는 복잡성도 크다. 먼저 그래프 데이터베이스를 어떻게 고를지 본다. 이 선택이 운영 지침 전체를 좌우한다.

일상적 운영의 네 가지 난제

유지 오버헤드가 그래프 데이터베이스의 지속적이고 흔히 과소평가되는 운영 비용이라는 점을 다시 강조할 만하다. 핵심 난제는 데이터 신선도와 일관성의 보장이다. 원천 데이터가 변하면 그래프도 새 현실을 반영하도록 갱신되어야 한다.

그래프 갱신 패턴과 진화

프로덕션에서 원천 데이터는 좀처럼 정적이지 않다. 살아 있는 데이터와 KG를 동기화하려면 “전면 재구축” 접근을 넘어 증분 유지로 나아가야 한다. 보통 두 가지 주요 패턴을 포함한다.

엔티티 병합과 만료되는 사실

오래 돌아가는 KG의 흔한 예외 사례는 서로 다르다고 여겼던 두 실체가 같은 것으로 발견될 때다(“Twitter”와 “X”). 이를 다루려면 “병합” 로직을 구현해야 한다. 한 노드의 관계를 “살아남는” 노드로 재사상하고 다른 노드를 삭제하는 방식이다.

또 하나의 난제는 사실이 “만료될” 때다. 어떤 사람이 회사를 떠났다면 WORKS_AT 관계를 반드시 삭제할 필요는 없지만(역사적 맥락을 보존하기 위해), status: "inactive" 라벨로 툼스토닝해야 한다. 그러면 RAG 질의도 :WORKS_AT {status: "active"}를 필터하도록 갱신되어야 한다.

정확도와 비용의 교환

애플리케이션을 만들 때 근본적인 아키텍처 선택을 마주한다. “바닐라” RAG 구성을 유지할지, 지식 그래프 통합에 투자할지다. 이 결정은 바닐라 RAG의 상대적으로 낮은 비용과 단순성 대 잠재적이지만 보장되지는 않은 정확도 향상 사이의 고전적 엔지니어링 교환이다.

바닐라 RAG를 과소평가하지 말아야 한다. 추가 복잡성 없이 이미 요구사항을 충족할 수도 있고, 구현이 비교적 직관적이며 운영이 비용 효율적이다. 범용 질의응답이나 대규모 문서 집합의 요약 같은 많은 애플리케이션에서는 “방향이 맞는” 또는 “의미적으로 관련된” 맥락을 찾는 것만으로 LLM이 고품질 응답을 제공하는 데 충분하다.

GraphRAG나 KG 통합의 다른 접근을 구현하는 일은 사소한 추가가 아니다. 주요한 약속이다. 비용은 재무적인 것만이 아니고 개발과 운영 자원에 무거운 세금이다. 그래프 데이터 모델링에 크게 투자하고, 새 그래프 데이터베이스 인프라를 세우고 유지하고, 진화하는 원천 데이터와 그래프를 최신으로 유지할 복잡한 데이터 파이프라인을 만들고 유지해야 한다. 진실은 이 지속적 유지 부담이 흔히 과소평가되고 심각한 자원 유출이 될 수 있다는 것이다.