.png)
벡터 유사도를 넘어 관계와 규칙을 검색하다
GraphRAG·Ontology·KAG는 기존 RAG를 어떻게 보완하는가
기획연재 2편: 의미적으로 가까운 청크를 찾는 것만으로는 여러 문서에 흩어진 관계·시간·수치·업무 규칙을 연결하기 어렵습니다. GraphRAG, Ontology, KAG는 같은 기술의 다른 이름이 아니라 서로 다른 지식 문제를 해결하는 계층입니다. 다음 3편에서는 이 계층들을 실제 제품에서 Agentic AI가 호출할 KB·KG·Zero-Copy 지식 도구 계층으로 어떻게 조합할지 다룹니다.
📚 연재 안내 | 이 글은 「Agent 시대의 RAG 재설계」 3부작의 2편입니다. ① 벡터 DB에 문서를 복사하지 않는 RAG — Zero-Copy RAG의 설계와 운영 · ② 벡터 유사도를 넘어 관계와 규칙을 검색하다 — GraphRAG·Ontology·KAG의 역할(현재 글) · ③ Agentic AI를 위한 온톨로지 기반 RAG 시스템 구축하기 — KB·KG·Zero-Copy를 조합하는 프로덕션 지식 도구 계층. 이후에는 Agent Harness 연재로 이어집니다.
지난 1편에서는 RAG의 데이터 위치와 권한 책임을 다뤘습니다. 문서·웹·PDF처럼 검색과 재사용이 중요한 데이터는 복제 인덱스를 쓰되, 현재값과 권한 일관성이 중요한 운영 데이터는 소스네이티브 조회로 읽는 혼합 구조를 살펴봤습니다.
그렇게 원문·권한·스코프의 책임 위치를 정해도, 검색 품질 문제가 모두 해결되는 것은 아닙니다.
예를 들어 다음 질문을 생각해 보겠습니다.
최근 30일 동안 쿠폰을 두 번 받은 VIP 고객에게 신규 캠페인의 15% 쿠폰을 지급할 수 있는가? 가능하지 않다면 어떤 정책이 충돌하는가?
이 질문에 답하려면 한 문장과 비슷한 청크 하나를 찾는 것으로는 부족합니다.
- VIP 고객의 정의를 알아야 합니다.
- 최근 30일이라는 시간 범위를 계산해야 합니다.
- 쿠폰 발급 이력과 현재 캠페인의 조건을 연결해야 합니다.
- 중복 발급 제한과 VIP 예외 정책을 함께 봐야 합니다.
- 두 정책이 서로 충돌한다면 어느 정책이 우선하는지 알아야 합니다.
- 최종 답변을 실제 원문 조항과 연결해야 합니다.
이것은 검색 문제이면서 동시에 관계·규칙·시간·추론 문제입니다.
벡터 RAG는 여전히 중요한 기본기입니다. 하지만 모든 지식을 평평한 텍스트 청크로만 다루면, 업무 시스템이 이미 알고 있는 구조를 검색 과정에서 다시 잃어버립니다.
이번 글의 핵심은 “벡터 RAG를 버리고 그래프로 바꾸자”가 아닙니다.
질문의 종류에 따라 텍스트, 관계, 개념, 규칙을 서로 다른 구조로 검색하고 다시 원문 근거로 합쳐야 한다.
이 글은 “어떤 구조가 필요한가”를 정리합니다. 이어지는 3편 「Agentic AI를 위한 온톨로지 기반 RAG 시스템 구축하기」에서는 그 구조들을 AI 인사이트 스튜디오 같은 실제 제품에서 Agent가 호출할 KB·KG·Zero-Copy 지식 도구 계층으로 어떻게 조합하는지, 여섯 가지 구현 패턴으로 옮깁니다.
💡 TL;DR · 3줄 요약
① 벡터 유사도는 '가까운 표현'을 찾지만, 업무 질문은 관계·규칙·시간으로 '연결된 근거'를 요구합니다.
② GraphRAG·Ontology·KAG는 경쟁 기술이 아니라 검색 구조·의미 계약·추론 프레임워크라는 서로 다른 계층입니다.
③ 거대한 그래프부터 만들지 말고, 질문 유형으로 검색기를 라우팅하며 검증된 질문에만 Global GraphRAG·KAG를 적용하세요.
벡터 유사도는 '가까운 표현'을 찾지만, 업무 질문은 관계·규칙·시간으로 '연결된 근거'를 요구합니다.
벡터 유사도는 ‘가까운 표현’을 찾지만, 업무 질문은 ‘연결된 근거’를 요구한다
벡터 임베딩은 문장의 의미를 수치 공간에 표현하고, 의미적으로 가까운 텍스트를 찾는 데 강합니다. 다음과 같은 질문에는 매우 잘 맞습니다.
- 환불 정책에서 배송비 기준을 알려줘.
- 지난 회의에서 제품 A 출시 일정에 대해 뭐라고 했어?
- 이 장애와 비슷한 과거 인시던트를 찾아줘.
- 특정 기능의 사용 방법을 설명한 문서를 찾아줘.
이 질문들은 대체로 답이 한두 개의 지역적 텍스트 영역에 존재합니다. 적절한 청크를 찾고, 리랭킹하고, 원문을 충분히 넣으면 좋은 답을 만들 수 있습니다.
하지만 다음 질문은 성격이 다릅니다.
Microsoft GraphRAG 논문도 전통적인 RAG가 데이터셋 전체의 주요 주제처럼 전체 코퍼스를 대상으로 하는 global question에는 약하다고 지적합니다. 이런 질문은 특정 텍스트 조각을 찾는 검색이라기보다 질의 중심의 전체 요약에 가깝기 때문입니다[1].
그렇다고 벡터 검색이 실패한 모든 곳에 지식 그래프를 붙여야 하는 것은 아닙니다.
- 키워드·메타데이터 필터가 부족한 문제일 수 있습니다.
- 청크 크기와 문서 구조 보존이 잘못됐을 수 있습니다.
- query decomposition이나 reranking으로 해결될 수 있습니다.
- 현재 상태는 GraphRAG가 아니라 SQL·API로 읽어야 할 수 있습니다.
- 규칙은 LLM 추론보다 정책 엔진이 직접 판정해야 할 수 있습니다.
그래서 먼저 기술 이름보다 어떤 종류의 구조를 잃고 있는가를 봐야 합니다.
💡 핵심 요약 · 벡터 RAG의 한계는 벡터 자체보다 ‘모든 지식을 청크로만 보는 것’에서 생긴다
① 지역적 사실과 유사 문서 검색에는 벡터 RAG가 강하다.
② 다중 관계·전체 주제·시간·수치·규칙은 별도의 구조가 필요하다.
③ GraphRAG·Ontology·KAG는 같은 대체재가 아니라 서로 다른 구조를 보완한다.
같은 기술의 다른 이름이 아니라, 관계 구조(GraphRAG)·업무 의미의 계약(Ontology)·그래프+원문+논리(KAG)라는 서로 다른 계층입니다.
GraphRAG·Ontology·KAG는 서로 다른 계층이다
세 용어가 함께 언급되다 보니 종종 같은 기술의 발전 단계처럼 설명됩니다. 하지만 역할은 다릅니다.
이를 세 개의 계층으로 보면 이해하기 쉽습니다.
- GraphRAG는 검색과 요약 구조에 가깝습니다.
- Ontology는 도메인 의미와 제약의 스키마에 가깝습니다.
- KAG는 그래프·원문·논리 형식을 결합한 전문 지식 서비스 프레임워크에 가깝습니다.
따라서 “GraphRAG를 도입했으니 Ontology도 있다”거나, “KAG는 외부 검색 없이 모델에 지식을 넣는 방식”이라고 설명하면 정확하지 않습니다.
GraphRAG: 청크가 아니라 엔티티와 커뮤니티를 통해 전체를 본다
GraphRAG는 넓게는 그래프 구조를 검색과 생성에 활용하는 접근을 뜻합니다. 구현마다 그래프를 만드는 방식과 질의 방식이 다릅니다.
여기서는 가장 널리 알려진 Microsoft GraphRAG를 기준으로 설명하겠습니다.
Microsoft GraphRAG의 기본 파이프라인
Microsoft GraphRAG는 원문에서 LLM으로 엔티티와 관계를 추출하고, 이를 그래프의 노드와 엣지로 구성한 뒤, 밀접하게 연결된 엔티티 집합을 커뮤니티로 묶어 요약합니다[1].
논문의 흐름을 조금 더 풀면 다음과 같습니다.
1. 원문을 청크로 나눕니다.
2. 각 청크에서 엔티티, 관계, 필요하면 claim을 추출합니다.
3. 동일하거나 유사한 엔티티·관계 설명을 요약합니다.
4. 그래프 커뮤니티를 계층적으로 탐지합니다.
5. 각 커뮤니티를 리포트 형태로 요약합니다.
6. 질의 유형에 따라 그래프와 원문 청크를 조합합니다.
이 구조가 특히 유용한 질문은 다음과 같습니다.
- 문서 전체에서 반복되는 핵심 주제는 무엇인가?
- 여러 사건과 조직 사이의 공통 연결 고리는 무엇인가?
- 특정 엔티티를 중심으로 어떤 관계와 claim이 존재하는가?
- 전체 데이터셋에서 서로 충돌하는 관점은 무엇인가?
Local Search와 Global Search는 질문이 다르다
현재 Microsoft GraphRAG 공식 문서는 검색 방식을 Local, Global, DRIFT, Basic Search로 구분합니다[2].
여기서 중요한 점은 GraphRAG가 단순히 “벡터 DB 대신 그래프 DB를 조회하는 RAG”가 아니라는 것입니다. Microsoft 구현의 Global Search는 사전에 만든 커뮤니티 리포트를 여러 번 요약하는 map-reduce 구조이며, Local Search는 그래프의 구조화 데이터와 원문 청크를 함께 사용합니다[2].
GraphRAG가 잘하는 것
전체 코퍼스의 패턴을 본다
일반 벡터 검색은 질문과 가장 가까운 청크를 우선합니다. 반면 global question은 데이터셋의 여러 영역에 약하게 분산된 신호를 모아야 합니다. 커뮤니티 리포트는 전체 구조를 미리 요약해 이런 질문의 진입점을 제공합니다.
엔티티 중심으로 근거를 확장한다
한 엔티티를 찾은 뒤 직접 연결된 관계, 관련 claim, 동일 커뮤니티의 다른 엔티티로 범위를 확장할 수 있습니다. 단일 top-k 검색에서 놓친 중간 연결을 찾는 데 유리합니다.
탐색 가능한 중간 구조를 만든다
엔티티·관계·커뮤니티가 저장되므로 사용자가 답변만 보는 것이 아니라 “어떤 연결을 통해 이 결론이 나왔는가”를 탐색할 수 있습니다. 다만 이 구조가 곧 사실 보장을 의미하지는 않습니다.
GraphRAG의 비용과 실패 지점
GraphRAG는 무료 추론 계층이 아닙니다.
- 모든 청크에서 엔티티와 관계를 추출해야 합니다.
- 같은 엔티티의 표기 변형을 통합해야 합니다.
- 커뮤니티를 다시 요약해야 합니다.
- 원문이 바뀌면 그래프와 리포트를 갱신해야 합니다.
- global search는 여러 커뮤니티 응답을 생성하고 다시 합치는 만큼 리소스가 큽니다. 공식 문서도 이를 resource-intensive한 방식으로 설명합니다[2].
그리고 그래프의 엣지가 원문에 명시된 사실만으로 만들어진다는 보장도 없습니다. Microsoft GraphRAG 논문은 엔티티와 관계 설명 자체가 LLM의 추상적 요약이며, 원문에 암시된 관계가 생성될 수 있다고 설명합니다[1]. 즉 그래프는 더 구조적인 근거가 될 수 있지만, LLM이 만든 파생 지식이기도 합니다.
따라서 고위험 업무에서는 다음이 필요합니다.
- 모든 노드·엣지를 원문 span과 연결
- entity resolution 결과의 confidence 저장
- 관계의 시작·종료 시점과 출처 저장
- 그래프에서 만든 결론을 원문으로 다시 검증
- 삭제·수정 시 파생 노드·커뮤니티 리포트 무효화
- 그래프 요약만으로 정책 실행을 확정하지 않기
Microsoft Research가 LazyGraphRAG를 별도로 제안한 것도 사전 그래프 인덱싱의 품질·비용 트레이드오프가 크기 때문입니다. LazyGraphRAG는 매우 가벼운 인덱싱과 질의 시점의 relevance test budget을 활용하며, Microsoft 역시 모든 graph-enabled RAG가 lazy해야 하는 것은 아니라고 설명합니다[3].
GraphRAG는 관계를 ‘사실’로 만들어 주는 기술이 아니라, 관계를 검색 가능한 후보 구조로 만들어 주는 기술이다.
Ontology: 그래프에 업무의 문법과 제약을 부여한다
GraphRAG가 문서에서 엔티티와 관계를 추출해 그래프를 만든다면, Ontology는 한 단계 다른 질문을 합니다.
이 업무 도메인에는 어떤 개념이 존재하고, 어떤 관계가 허용되며, 각 개념은 무엇을 의미하는가?
W3C는 온톨로지를 특정 도메인의 용어를 형식화한 vocabulary로 설명하며, 용어의 정의를 다른 용어와의 관계를 통해 명시한다고 정의합니다. OWL 2는 클래스, 속성, 개체, 데이터 값을 표현하고, reasoner가 일관성·포함 관계·인스턴스 검색 등을 수행할 수 있도록 형식적 의미를 제공합니다[4].
쉽게 말하면 다음과 같습니다.
- Knowledge Graph는 “현재 어떤 사실과 관계가 존재하는가”를 담습니다.
- Ontology는 “어떤 종류의 사실과 관계가 존재할 수 있으며, 그 의미와 제약은 무엇인가”를 정의합니다.
마케팅 도메인 예시
앞선 Agent 연재의 쿠폰 캠페인 사례를 온톨로지 관점에서 보면 다음과 같은 개념이 있습니다.
Customer
├─ hasSegment → Segment
├─ hasConsent → MarketingConsent
├─ madePurchase → Purchase
├─ receivedCoupon → CouponIssuance
└─ hasTier → CustomerTier
Campaign
├─ targets → Segment
├─ offers → Coupon
├─ governedBy → CampaignPolicy
└─ consumes → Budget
여기에 의미와 제약을 붙일 수 있습니다.
- MarketingConsent가 유효한 고객만 MessageRecipient가 될 수 있다.
- CouponIssuance는 하나의 고객·캠페인·쿠폰 정책과 연결되어야 한다.
- VIPCustomer는 Customer의 하위 개념이다.
- HighRiskCampaign은 사람 승인이 필요하다.
- CouponPolicy의 적용 기간이 캠페인 실행 시각을 포함해야 한다.
- 동일 캠페인에서 같은 고객에게 동일 쿠폰을 두 번 발급할 수 없다.
이런 정의는 단순 텍스트 유사도가 아니라 업무 시스템의 계약입니다.
Ontology는 분류 체계 이상의 것이다
온톨로지를 단순한 카테고리 트리로 이해하면 역할이 축소됩니다.
형식적 온톨로지는 reasoner를 통해 명시하지 않은 지식을 도출하거나 모순을 찾을 수 있습니다. 다만 모든 프로덕션 시스템이 OWL reasoner를 도입해야 한다는 뜻은 아닙니다.
현실에서는 다음처럼 단계적으로 적용할 수 있습니다.
1. 업무 용어 사전과 canonical ID를 정의합니다.
2. 엔티티 타입과 관계 타입을 스키마로 제한합니다.
3. 필수 속성과 허용 가능한 관계를 검증합니다.
4. 중요 규칙은 정책 엔진이나 SQL 제약으로 실행합니다.
5. 정말 필요한 도메인에만 OWL·SHACL·rule reasoner를 도입합니다.
Graph DB 없이도 Ontology는 존재할 수 있다
Ontology는 저장 엔진이 아닙니다. 관계형 DB 위에서도 고객·캠페인·정책의 의미 모델을 정의할 수 있고, API schema·데이터 카탈로그·정책 엔진과 결합할 수도 있습니다.
반대로 그래프 DB를 쓴다고 자동으로 온톨로지가 생기는 것도 아닙니다. A -[RELATED_TO]-> B 같은 자유로운 관계를 많이 저장해도, RELATED_TO의 의미와 허용 범위가 정의되지 않았다면 그것은 연결 데이터이지 엄격한 도메인 모델은 아닙니다.
좋은 구조는 둘 중 하나를 고르는 것이 아니라, Ontology를 가드레일과 정렬 기준으로 사용해 GraphRAG의 추출 결과를 정규화하는 것입니다.
예를 들어 LLM이 Customer, User, Buyer, Member를 각각 다른 엔티티 타입으로 추출했다면 Ontology의 canonical concept에 맞춰 매핑할 수 있습니다. 허용되지 않은 관계나 필수 속성이 빠진 노드는 검증 단계에서 격리할 수 있습니다.
💡 핵심 요약 · 그래프와 온톨로지는 무엇이 다른가
① 그래프는 사실과 연결을 담고, 온톨로지는 그 연결의 의미와 허용 규칙을 정의한다.
② GraphRAG는 관계 구조를 빠르게 만들지만 추출 잡음이 생길 수 있다.
③ Ontology는 일관성을 높이지만 설계·합의·유지 비용이 든다. → 프로덕션에서는 자동 추출 그래프를 Ontology로 정렬하고, 최종 판단은 원문과 정책으로 검증하는 구조가 유용하다.
KAG: 그래프와 원문 청크, 논리 추론을 함께 사용한다
KAG(Knowledge Augmented Generation)는 자주 잘못 설명되는 개념입니다.
일부 글에서는 KAG를 “도메인 지식을 모델에 사전학습하거나 파인튜닝해 외부 검색 없이 답하는 방식”으로 소개합니다. 하지만 KAG 원 논문이 제안한 구조는 다릅니다.
KAG는 벡터 유사도와 지식 추론의 관련성 사이에 간극이 있고, 수치·시간 관계·전문가 규칙 같은 지식 논리에 벡터 RAG가 둔감하다는 문제에서 출발합니다. 이를 해결하기 위해 지식 그래프와 벡터 검색을 결합하고, 다음 다섯 요소를 제안합니다[5].
1. LLM-friendly knowledge representation — LLM이 이해하고 사용할 수 있는 지식 표현
2. Mutual indexing — 지식 그래프와 원문 청크의 상호 인덱싱
3. Logical-form-guided hybrid reasoning — 논리 형식이 이끄는 혼합 검색·추론
4. Knowledge alignment — 의미 추론을 통한 지식 정렬
5. Model capability enhancement — KAG 작업에 맞춘 모델 역량 강화
핵심은 지식 그래프만 보거나 원문 청크만 보는 것이 아니라, 그래프에서 찾은 구조를 원문으로 확장하고 원문에서 찾은 근거를 그래프의 개념과 규칙으로 정렬하는 것입니다.
예시: 캠페인 정책 질문을 KAG식으로 풀면
질문:
최근 30일 동안 쿠폰을 두 번 받은 VIP 고객에게 신규 캠페인의 15% 쿠폰을 지급할 수 있는가?
가능한 흐름은 다음과 같습니다.
1. 질문을 구조화합니다.
CustomerTier = VIP
CouponIssuance.count(window=30d) >= 2
NewCoupon.discount = 15%
2. Ontology에서 개념과 관계를 정렬합니다.
VIPCustomer ⊆ Customer
receivedCoupon(Customer, CouponIssuance)
3. 지식 그래프에서 관련 정책·예외·캠페인 관계를 탐색합니다.
4. 각 정책 노드와 연결된 원문 조항을 가져옵니다.
5. 시간·수치 조건은 코드나 규칙 엔진으로 계산합니다.
6. 충돌하는 규칙의 우선순위를 적용합니다.
7. 최종 답변에 원문 조항, 정책 버전, 계산 결과를 함께 제시합니다.
이 구조에서 LLM은 질문을 분해하고 결과를 설명하지만, 30일, 2회, 15%, 정책 우선순위를 기억으로 판정하지 않습니다. 시간 계산과 정책 검증은 결정론적 계층이 담당합니다.
KAG의 연구 결과는 가능성을 보여 주지만 일반 법칙은 아니다
KAG 논문은 multi-hop QA 실험에서 기존 RAG 방식 대비 F1 기준으로 2Wiki에서 19.6%, HotpotQA에서 33.5%의 상대 개선을 보고했습니다[5]. 이는 그래프·원문·논리 형식을 결합하는 접근의 가능성을 보여 줍니다.
하지만 이 수치를 모든 기업 데이터와 질문에 그대로 적용해서는 안 됩니다.
- 벤치마크 질문과 실제 업무 질문은 다릅니다.
- 온톨로지와 지식 그래프 품질이 성능에 큰 영향을 줍니다.
- 수치·시간·규칙 추론의 구현 수준에 따라 결과가 달라집니다.
- 인덱싱·정렬·추론 계층이 늘어나 운영 복잡도도 커집니다.
따라서 KAG는 “RAG보다 무조건 우월한 차세대 기술”보다 전문 도메인에서 구조와 논리를 함께 다루기 위한 상위 아키텍처로 이해하는 편이 좋습니다.
질문의 종류에 따라 텍스트·관계·개념·규칙을 서로 다른 구조로 검색하고, 마지막에 다시 원문 근거로 합칩니다.
무엇을 선택해야 하는가: 기술이 아니라 질문 유형으로 결정하라
프로덕션에서는 하나의 RAG가 모든 질문을 처리하게 하기보다, 질문 유형에 따라 검색 경로를 나누는 편이 낫습니다.
여기서 중요한 것은 RAG를 하나의 제품 이름으로 보지 않는 것입니다.
검색은 단일 파이프라인이 아니라 증거를 구성하는 여러 도구의 집합이다.
권장 Hybrid Retrieval 구조
Evidence Pack은 단순한 텍스트 묶음이 아니라 구조화된 근거 계약이어야 합니다.
{
"question_type": ["temporal", "policy_conflict"],
"facts": [
{
"subject": "customer:123",
"predicate": "coupon_issue_count_30d",
"value": 2,
"computed_by": "campaign-policy-service"
}
],
"relations": [
{
"source": "policy:vip-exception-v3",
"relation": "overrides",
"target": "policy:coupon-frequency-v5"
}
],
"evidence": [
{
"source_id": "sharepoint:policy-882",
"version": "17",
"section": "3.2",
"content_hash": "sha256:..."
}
],
"validation": {
"acl_checked": true,
"policy_engine_result": "DENY",
"reason_code": "FREQUENCY_LIMIT_EXCEEDED"
}
}
LLM은 이 구조를 바탕으로 사람이 이해할 수 있는 답변을 만듭니다. 하지만 실행 가능 여부의 최종 값은 policy_engine_result가 결정합니다.
벡터 기본기 → canonical ID → 제한된 관계 추출 → 핵심 개념에 Ontology → 검증된 질문에만 Global GraphRAG·KAG.
처음부터 거대한 Knowledge Graph를 만들지 마라
GraphRAG와 Ontology가 매력적으로 보이기 시작하면 모든 문서를 한 번에 그래프로 만들고 싶은 유혹이 생깁니다. 하지만 운영에서는 작은 구조부터 시작하는 편이 안전합니다.
단계 1. Vector RAG의 기본기를 먼저 고친다
- 문서 구조를 보존한 청킹
- 키워드·벡터 hybrid search
- metadata filtering
- reranking
- 원문 citation
- 권한·버전·삭제 처리
- 질문 유형별 평가셋
이 단계가 약하면 그래프를 붙여도 파생 구조의 근거가 약합니다.
단계 2. canonical entity ID를 만든다
가장 중요한 업무 개념부터 표기 변형을 통합합니다.
- Customer / User / Member
- Product / SKU / Item
- Campaign / CampaignRun
- Coupon / CouponPolicy / CouponIssuance
- Consent / Subscription Status
이 단계만으로도 검색 필터와 엔티티 연결 품질이 크게 좋아질 수 있습니다.
단계 3. 관계를 제한된 스키마로 추출한다
처음부터 모든 관계를 허용하지 말고, 실제 질문에 필요한 관계만 정의합니다.
Customer -[RECEIVED]-> CouponIssuance
Campaign -[GOVERNED_BY]-> Policy
Policy -[OVERRIDES]-> Policy
Incident -[AFFECTED]-> Service
Decision -[SUPPORTED_BY]-> Evidence
각 관계는 원문 위치와 confidence를 가져야 합니다.
단계 4. 중요한 업무 개념에 Ontology와 정책을 붙인다
- 타입 계층
- 필수 속성
- 허용 관계
- 유효기간
- 정책 우선순위
- 민감도·권한 분류
모든 지식을 형식 논리로 옮기기보다, 오류 비용이 큰 개념부터 시작합니다.
단계 5. Global GraphRAG나 KAG는 검증된 질문에만 적용한다
도입 기준은 “최신 기술인가”가 아니라 다음이어야 합니다.
- 실제 사용자 질문 중 global·multi-hop·rule reasoning 비율이 충분한가?
- 현재 RAG의 실패 원인이 관계 단절로 확인됐는가?
- 그래프 인덱싱과 갱신 비용을 감당할 수 있는가?
- 원문 provenance를 끝까지 유지할 수 있는가?
- graph extraction 오류를 평가할 gold set이 있는가?
GraphRAG는 질문이 없는 데이터 호수 위에 먼저 올리는 기반 시설이 아니라, 반복적으로 실패하는 질문 유형을 해결하기 위한 선택적 인덱스가 되어야 합니다.
RAG 평가는 지표 나열이 아니라 실패 경로를 분리하는 일이다
일반적인 RAG 평가는 “질문에 맞는 문서를 찾았는가”와 “답변이 근거에 충실한가”를 주로 봅니다. Ragas 같은 평가 도구도 faithfulness, answer relevancy, context recall, context precision처럼 검색기와 생성기를 나눠 보는 지표를 제공합니다[6]. 이 관점은 기본입니다. 다만 GraphRAG·Ontology·KAG가 들어오면 한 단계 더 나눠야 합니다.
문제는 지표의 수가 부족한 것이 아닙니다. 어느 계층이 실패했는지 분리하지 못하는 것입니다. 답변이 틀렸을 때 검색기가 틀린 것인지, 엔티티 병합이 틀린 것인지, 관계 엣지가 근거 없이 만들어진 것인지, 정책 엔진 결과를 LLM이 잘못 설명한 것인지가 구분되어야 합니다.
평가셋은 질문 유형으로 먼저 나눈다
지표는 계층별 경보로 묶는다
이 표의 목적은 숫자를 많이 수집하는 것이 아니라 수정 위치를 빠르게 좁히는 것입니다. 예를 들어 global question의 답변 품질은 좋아졌지만 p95 latency와 query token cost가 크게 늘었다면 모든 질문을 GraphRAG로 라우팅해서는 안 됩니다. 반대로 answer correctness가 낮은데 context recall은 높다면 검색기보다 Context Composer, 정책 판정 해석, 혹은 LLM 응답 단계가 문제일 수 있습니다.
Ontology 평가는 더 주의가 필요합니다. schema violation rate가 낮아도 좋은 모델이라는 뜻은 아닙니다. 현업 용어 변화가 반영되지 않아 unmapped concept rate가 높다면, 추론 알고리즘보다 온톨로지 변경 관리 프로세스를 먼저 고쳐야 합니다. SHACL처럼 RDF 그래프를 조건 집합에 대해 검증하는 표준도 이런 “데이터가 의미 모델의 제약을 만족하는가”를 확인하는 도구로 볼 수 있습니다[7].
평가 없는 Knowledge Graph는 검색 자산이 아니라 구조화된 추측 모음이 될 수 있다. 좋은 평가는 점수판이 아니라 어느 계층을 고쳐야 하는지 알려 주는 알람이다.
GraphRAG가 환각을 자동으로 없애 주지는 않는다
그래프는 관계가 명시적이기 때문에 설명 가능성을 높일 수 있습니다. 하지만 “그래프를 사용하면 환각이 줄어든다”를 일반 법칙처럼 말하면 안 됩니다.
환각이 발생할 수 있는 지점은 더 늘어납니다.
1. LLM이 원문에서 존재하지 않는 엔티티를 추출
2. 동일 엔티티를 여러 노드로 분리
3. 다른 엔티티를 하나로 병합
4. 암시된 관계를 사실 관계로 과도하게 생성
5. 커뮤니티 요약에서 세부 조건 누락
6. global answer에서 여러 요약을 다시 추상화하며 왜곡
7. 그래프 경로는 맞지만 현재 버전에는 무효한 정책 사용
따라서 GraphRAG의 답변에는 두 종류의 근거가 구분되어야 합니다.
- Derived evidence — 엔티티 요약, 관계, 커뮤니티 리포트
- Primary evidence — 실제 원문 span, DB 계산 결과, 정책 엔진 판정
Derived evidence는 탐색과 질의 확장에 유용합니다. 그러나 고위험 결정은 Primary evidence로 다시 확인해야 합니다.
이 원칙은 Ontology와 KAG에도 동일하게 적용됩니다. 온톨로지가 논리적으로 일관돼도 입력 인스턴스가 틀리면 결론도 틀립니다. 논리 추론은 사실 오류를 정정하는 마법이 아니라, 주어진 사실과 규칙으로부터 일관된 결론을 만드는 과정입니다.
최근 RAG의 변화: 하나의 검색기에서 여러 증거 도구로
RAG의 최근 흐름을 “Naive RAG → GraphRAG → KAG” 같은 일렬의 세대로 보는 것은 정확하지 않습니다. 실제로는 서로 다른 계층이 동시에 발전하고 있습니다.
이 중 마지막의 Agentic RAG는 GraphRAG나 KAG와 같은 지식 저장 방식이 아닙니다. Agent가 질문을 분해하고, 검색 도구를 선택하고, 근거가 부족하면 다시 검색하고, 언제 멈출지를 결정하는 실행 제어 방식입니다.
검색 도구가 하나일 때는 고정 파이프라인으로 충분합니다.
질문 → 벡터 검색 → 답변
하지만 도구가 늘어나면 문제가 달라집니다.
질문
→ 원문 검색을 할까?
→ Graph Local Search를 할까?
→ Global Search가 필요한가?
→ SQL로 현재 상태를 읽을까?
→ Ontology에서 개념을 정렬할까?
→ 정책 엔진을 호출할까?
→ 근거가 부족하면 몇 번 다시 검색할까?
이 선택은 더 이상 RAG 인덱스만의 문제가 아닙니다.
다음 3편으로 넘길 질문: 지식 구조를 Agent가 호출할 도구 계층으로 어떻게 조합할 것인가
여기까지가 2편의 역할입니다. 1편이 데이터 위치와 권한 책임을 다뤘다면, 2편은 관계·개념·규칙을 어떤 구조로 검색할지 분해했습니다. 이제 3편은 이 구조들을 실제 제품에서 어떻게 묶을지로 넘어갑니다.
RAG 1편과 2편을 정리하면 다음과 같습니다.
- 1편은 데이터를 어디에 두고 누구의 권한으로 읽을 것인가를 다뤘습니다.
- 2편은 텍스트·관계·개념·규칙을 어떤 구조로 검색할 것인가를 다뤘습니다.
그런데 실제 제품에서는 문서, 운영 지표, 정책, 엔티티 관계가 한 질문 안에 섞입니다. 문서는 KB에 있고, 현재값은 RDB에 있고, 관계는 KG에 있으며, 이 모두를 하나의 업무 의미 아래에서 설명해야 합니다.
그래서 다음 질문은 “GraphRAG가 좋은가, Ontology가 좋은가”가 아닙니다.
온톨로지를 지도로 두고, KB·KG·Zero-Copy 조회를 어떤 조합으로 묶을 것인가?
이것이 다음 3편에서 다룰 제품 구현 계층입니다. 그리고 이 조합이 만들어 낸 여러 지식 도구를 언제 어떤 순서로 호출하고, 언제 멈추며, 어떤 근거를 컨텍스트에 남길지는 RAG 3부작 이후의 Agent Harness 연재에서 다룰 문제입니다.
마치며: 벡터 RAG를 대체할 하나의 정답은 없다
벡터 RAG는 사라지지 않습니다. 특정 문장과 유사 사례를 찾는 가장 실용적인 기본 도구 중 하나입니다.
GraphRAG는 관계와 전체 패턴이 필요한 질문을 보완합니다. Ontology는 업무 개념과 관계의 의미를 명시하고, 자동 추출 그래프를 정렬하는 계약이 됩니다. KAG는 원문 청크·지식 그래프·논리 추론을 결합해 전문 도메인의 다중 관계·시간·수치·규칙 문제를 다루려는 프레임워크입니다.
하지만 각각 새로운 비용을 만듭니다.
- GraphRAG는 인덱싱·entity resolution·커뮤니티 요약 비용
- Ontology는 도메인 합의·모델링·변경 관리 비용
- KAG는 복수 검색·정렬·추론 계층의 구현 비용
- Agentic retrieval은 반복 호출·토큰·지연·중단 통제 비용
그래서 좋은 아키텍처는 가장 복잡한 RAG를 쓰는 시스템이 아닙니다.
질문의 성격에 맞는 가장 단순한 검색 구조를 선택하고, 고위험 결론은 원문과 결정론적 시스템으로 다시 검증하는 시스템이 좋은 RAG다.
정리하면 다음과 같습니다.
- 특정 사실은 키워드·벡터 검색으로 찾습니다.
- 현재 상태는 SQL·API로 읽습니다.
- 관계와 전체 주제는 GraphRAG로 탐색합니다.
- 도메인 의미와 제약은 Ontology로 정렬합니다.
- 복합 전문 질문은 그래프·원문·규칙을 결합합니다.
- 최종 답변은 파생 지식이 아니라 원문 근거와 계산 결과를 함께 보여 줍니다.
- 어떤 도구를 언제 사용할지는 Agent Harness가 통제합니다.
RAG의 다음 단계는 더 큰 벡터 DB가 아닙니다. 업무의 의미 구조와 실행 환경에 맞춰 여러 증거 도구를 조합하는 것입니다.
🚀 다음 글 예고 · 3편 「Agentic AI를 위한 온톨로지 기반 RAG 시스템 구축하기」
다음 3편에서는 온톨로지를 “지도이자 도구 계약”으로 두고, KB·KG·Zero-Copy 조회를 Agentic AI가 호출할 프로덕션 지식 도구 계층으로 조합하는 여섯 가지 구현 패턴을 다룹니다. 2편이 “어떤 검색 구조가 필요한가”를 설명했다면, 3편은 “그 구조를 실제 제품에서 어디에 저장하고, 언제 원본에서 읽고, 어떤 권한·근거·도구 계약으로 묶을 것인가”를 설명합니다. 이 연결이 곧 이후 Harness 연재의 출발점입니다.
참고자료
[1] Darren Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization, Microsoft Research, 2024
https://arxiv.org/abs/2404.16130
[2] Microsoft GraphRAG Documentation, Query Engine — Local, Global, DRIFT, Basic Search
https://microsoft.github.io/graphrag/query/overview/
[3] Microsoft Research, LazyGraphRAG: Setting a new standard for quality and cost, 2024
https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/
[4] W3C, OWL 2 Web Ontology Language Document Overview, W3C Recommendation
https://www.w3.org/TR/owl2-overview/
[5] Lei Liang et al., KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation, 2024
https://arxiv.org/abs/2409.13731
[6] Ragas Documentation, Metrics for RAG Evaluation
https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/
[7] W3C, Shapes Constraint Language (SHACL), W3C Recommendation
https://www.w3.org/TR/shacl/
[8] 기획연재 3편, Agentic AI를 위한 온톨로지 기반 RAG 시스템 구축하기 — KB·KG·Zero-Copy를 조합하는 프로덕션 지식 도구 계층
