[온톨로지 기반 GraphRAG] (5) 검증과 평가

4편까지의 내용은 검증된 근거만 LLM에 사용하는 구조를 만들었다. 남은 문제는 LLM이 그 근거로 답을 만드는 순간이다.

근거에 없는 내용을 생성하거나, 근거 두 개를 잘못 결합하거나, 근거와 반대로 말하는 일은 생성 단계에서 여전히 일어난다.

그리고 더 근본적인 문제로 사람이 "이 답이 왜 이렇게 나왔는지"를 확인할 방법이 없다면, 아무리 내부가 정교해도 시스템 전체는 블랙박스다.

 

이번 편은 그 마지막 조각인 provenance(출처·이력 정보)와 평가에 대한 내용이다. 답변에 "이 답은 이런 쿼리를 실행했고, 이런 공리를 따라 탐색했고, 이런 검증을 통과한 근거에서 나왔다"는 기록을 같이 보여주어 사람이 답을 재검증할 수 있게 만드는 것이 목표이다.

1.기존 RAG와 같이 인용 붙이기

문서 기반 RAG는 attribution이라는 이름으로 몇 년째 연구가 쌓이고 있다. 흐름을 훑어보면 아래와 같다.

• 출발점은 AIS(Attributable to Identified Sources)라는 개념이다. "모델이 생성한 문장이 식별 가능한 출처에 의해 뒷받침되는가"를 평가 기준으로 삼자는 제안인데, 이후 연구들의 공통 어휘가 됐다
• 평가를 자동화하려는 시도가 뒤따랐다. 생성 문장과 인용된 문서 사이의 뒷받침 여부를 NLI(자연어 추론) 모델로 판정하는 AutoAIS 계열, 인용의 정밀도/재현율을 NLI로 채점하는 ALCE 벤치마크 등이다
  • AutoAIS는 "모델이 생성한 문장이 주어진 출처(문서)에 의해 완벽하게 뒷받침되는가?"를 자동으로 평가하기 위한 프레임워크이다. Measuring Attribution in Natural Language Generation Models (Rashkin et al.)
  • ALCE는 LLM의 인용 생성 능력을 자동으로 평가하는 최초의 종합 벤치마크이다. LLM이 질문에 답할 때 올바른 문서를 검색하고, 문장 끝에 인용 표기(예: [1], [2])를 정확히 달았는지 평가   Enabling Large Language Models to Generate Text with Citations (Gao et al., EMNLP 2023) / GitHub 레포지토리
• 최근에는 인용의 품질 자체를 끌어올리는 방법론이 활발하다. 예를 들어 2025년 SIGIR-AP에 나온 VeriCite는 생성된 인용을 엄격한 검증 단계로 걸러 인용 품질을 올리는 프레임워크고, 문장 수준에서 생성 중에 귀속을 다는 접근(SAFE 등), 세밀한 보상으로 인용 생성을 학습시키는 접근까지 다양하다. 이 분야만 모아둔 논문 목록을 깃헙으로 정리한 레포지토리도 존재한다.

그런데 이 계열을 들여다보면 공통된 구조적 한계가 보인다. 인용이 맞는지 확인하는 일 자체가 또 다른 모델의 판단에 기댄다는 점이다. 문서는 자연어라서, "이 문장이 저 단락에 의해 뒷받침되는가"를 기계적으로 확정할 수 없다. 그래서 NLI 모델이나 LLM 심판(LLM-as-judge)을 동원하는데, 그 심판도 확률적이다. 

2. 그래프로 접근하면 달라지는가?

근거가 자연어 단락이 아니라 트리플이면 장점이 있다. 트리플은 ID가 있고, 존재 여부를 결정론적으로 확인할 수 있다.

• "이 주장은 :emp42 :worksIn :deptA 트리플에 근거한다"는 인용은, 그 트리플이 근거 서브그래프에 실제로 있는지 쿼리로 조회할 수 있다.
• 주장 단위가 트리플과 정렬되므로, "답변의 모든 원자적 주장은 인용을 가져야 한다"는 규칙을 기계적으로 강제할 수 있다. 인용 없는 주장은 탈락시키거나 플래그를 단다

그래서 이 시리즈의 구조에서 생성 단계는 이렇게 된다. LLM에게 근거 서브그래프를 트리플 ID와 함께 주고, 주장마다 트리플 ID를 인용하도록 지시한다. 생성이 끝나면 검증기 — LLM이 아니라 단순한 조회·함의 검사 프로그램 — 가 (a) 인용된 트리플이 근거에 실제로 존재하는지, (b) 인용 없는 주장이 없는지 확인한다. 통과 못 한 문장은 제거하거나 "근거 미확인"으로 표시한다.

 

 

문서 진영이 확률적 심판에 기대는 지점을, 그래프는 구조 덕분에 결정론적 검사로 대체한다. 이런 부분이 GraphRAG가 attribution 문제에서 갖는 본질적 이점이라고 생각한다. 

 

3. 트리플 인용의 한계점

한편, "트리플이 존재한다"는 것과 "그 트리플이 어떻게 근거로 채택됐는가"는 다른 문제다. 근거 서브그래프는 그냥 있었던 게 아니라 만들어진 것이다. 쿼리가 실행됐고, 공리가 확장을 허가했고, Shape 검증이 후보를 걸렀고, 규칙이 파생 사실을 더했다. 이 과정 전체가 기록되어야 답을 처음부터 끝까지 재현할 수 있다.

그래서 답변에 딸려 보내는 provenance 객체를 세 부분으로 설계한다.

• Q — 실행된 쿼리 집합. 어떤 SPARQL이 어느 엔드포인트(정적 트리플스토어인지, OBDA 가상 그래프인지)에서 언제 실행됐는지. 하이브리드 구조에서는 실행 시각이 특히 중요하다. OBDA 쪽 결과는 그 시각의 DB 상태라는 뜻이므로
• P — 탐색 경로와 허가 공리. 각 홉이 어느 노드에서 어느 속성으로 확장됐고, 그 확장을 허가한 공리(domain/range, 전이, 역속성)가 무엇이었는지. 파생 트리플이라면 어느 SWRL/SHACL 규칙이 만들었는지
• V — 검증 기록. 근거 서브그래프에 대한 SHACL Validation Report. 이 리포트는 구조화된 RDF라서 그대로 첨부하면 된다

이 세 가지가 있으면 검토자는 LLM 출력과 별개로 전 과정을 재연할 수 있다. Q를 다시 실행해 같은 근거가 나오는지 보고, P의 공리들이 실제로 온톨로지에 선언되어 있는지 확인하고, V를 재검증하면 된다. 감사(audit)가 가능한 파이프라인이 가능해진다.

4. 이걸 어디에 어떻게 저장하고 관리하는가? 표준의 활용

"트리플에 대한 메타데이터를 어떻게 붙이나"는 시맨틱 웹의 오래된 주제라, 여기도 표준이 있다.

• PROV-O — W3C의 출처 표현 온톨로지(W3C Recommendation, 2013). "이 산출물(Entity)은 이 활동(Activity)에 의해, 이 행위자(Agent)가 만들었다"는 구조로 이력을 기술한다. 위의 Q·P·V를 PROV-O 어휘로 직렬화하면, provenance 자체가 표준 RDF가 되어 다른 시스템이 소비할 수 있다
• RDF-star / RDF 1.2 — "트리플에 대한 트리플"을 쓰는 문법. << :emp42 :worksIn :deptA >> :derivedBy :rule7 .처럼 개별 트리플에 직접 주석을 단다. 파생 사실에 규칙 태그를 붙일 때 자연스럽다. RDF 1.2로 표준화가 진행 중이고 주요 트리플스토어들이 이미 지원한다
• Named Graph — 트리플들을 그래프 단위로 묶고 그래프에 메타데이터를 붙이는 고전적 방법. "이번 질의에서 수집된 근거 서브그래프" 하나를 named graph로 만들고 그 그래프에 Q·V를 달면 구현이 단순하다

셋은 배타적이지 않다. 실용적으로는 근거 서브그래프를 named graph로 묶고, 파생 트리플엔 RDF-star 주석을 달고, 전체 이력을 PROV-O로 감싸는 조합이 무난하다고 본다. 참고로 학계에서는 이런 provenance 표현을 어떻게 통합할지가 지금도 활발한 주제고(2026년에도 Provenance-Enhanced Statements in Knowledge Graphs 표현을 다루는 논문이 계속 나온다, ), 그래프의 주장을 외부 텍스트 출처와 대조해 검증하는 ProVe 같은 연구 계열도 있다.

• Full Traceability and Provenance for Knowledge Graphs (FOIS 2024)
• Easy and complex: new perspectives for metadata modeling using RDF-star and Named Graphs (arXiv, 2022)

5. 최근 KG+LLM 연구에서의 위치

그래프 추론 경로를 설명으로 쓰자는 발상 자체는 KG+LLM 연구에서 이미 주류다. Think-on-Graph는 부제부터 "deep and responsible reasoning"인데, LLM이 따라간 그래프 경로가 곧 답의 설명이 된다는 게 responsible의 근거다. KAG(Knowledge Augmented Generation)처럼 전문 도메인에서 논리 형식과 그래프를 결합하는 프레임워크, 추론 실패를 감지하고 경로를 수정하는 self-correction 계열(Plan-on-Graph 등)도 같은 문제의식 위에 있다.

 

다만 내가 보기에 이 계열 다수는 "경로를 보여준다"에서 멈춘다. 경로 제시와 기계 검증 가능한 provenance는 다르다. 경로가 있어도 그 경로가 (a) 스키마상 허용된 확장이었는지, (b) 검증을 통과한 데이터 위였는지, (c) 지금 다시 실행해도 재현되는지가 기록되어야 재현할 수 있는 구조라고 생각한다.

6. 평가의 필요성

provenance는 "이 답을 재검증할 수 있는가"에 대한 답이지, "이 시스템이 잘하는가"에 대한 답이 아니다. 잘하는지를 재려면 평가 방법이 필요한데, 이 파이프라인은 층이 여러 개라 평가도 층별로 나눠야 한다. 스키마가 좋은지, 쿼리를 잘 만드는지, 답을 잘 찾는지는 서로 다른 질문이고, 뭉뚱그려 재면 어디가 문제인지 알 수 없기 때문이다.

6-1. 스키마를 잘 만들었는가 - 온톨로지 평가

가장 어려운 층이다. 온톨로지에는 유일한 정답이 없어서(같은 도메인을 클래스 중심으로도, 속성 중심으로도 타당하게 모델링할 수 있다) "정답과의 일치율" 같은 단순 지표가 성립하지 않는다. 그래서 이 분야는 여러 관점의 평가를 조합한다.

• 피트폴 검사. 피트폴 카탈로그 = 온톨로지에서 자주 나오는 실수 패턴(역속성 누락, 순환 계층, 정의 없는 클래스, 잘못된 disjointness 등)을 자동 검출한다. 대표 도구가 OOPS!(OntOlogy Pitfall Scanner)로, 40여 개 피트폴 카탈로그를 기준으로 스캔해준다. 코드 린터의 온톨로지판이라고 보면 된다
• 메타속성 검사 - OntoClean. Guarino와 Welty가 제안한 고전적 방법론. 클래스에 rigidity(본질적 속성인가), identity(개체 식별 기준을 주는가) 같은 메타속성을 부여하고, "rigid 클래스가 anti-rigid 클래스의 하위가 될 수 없다" 같은 규칙 위반을 찾는다. 예를 들어 Student ⊑ Person은 괜찮지만 Person ⊑ Student는 OntoClean 위반이다(사람은 본질적으로 사람이지만, 학생은 그만둘 수 있는 역할이므로). 계층 설계의 논리적 건전성을 보는 도구다
• Competency Question(CQ) 충족도. 실용주의적 접근이고 개인적으로 제일 중요하다고 보는 방법. 온톨로지가 답할 수 있어야 하는 질문 목록("어떤 설비가 어떤 센서를 갖는가?", "이 정비 규정이 적용되는 설비는?")을 요구사항 단계에서 먼저 정의하고, 각 질문이 SPARQL로 표현 가능한지·실제로 답이 나오는지를 검사한다. 스키마 평가를 "잘 만들었나"라는 막연한 질문에서 "필요한 질문에 답하나"라는 검사 가능한 질문으로 바꿔준다
• 어휘 재사용률과 표준 정렬. 신규 URI를 만드는 대신 기존 표준 어휘(W3C 권고안들, LOV 저장소의 공용 어휘)를 재사용한 비율. 상호운용성의 대리 지표다
• 구조 지표. 클래스 수, 계층 깊이, 속성 밀도 같은 통계. 그 자체로 좋고 나쁨을 말하진 못하지만, LLM이 생성한 스키마가 이상하게 평탄하거나 과세분화됐는지를 잡는 스크리닝용으로 유용하다

LLM으로 스키마를 자동 생성하는 요즘 연구에서 평가가 특히 병목인 이유가 여기 있다. 위 방법들은 대부분 "결함을 찾는" 평가지 "품질을 점수화하는" 평가가 아니라서, 방법 간 정량 비교가 어렵다. 이 공백은 그 자체로 연구 주제라고 생각한다.

6-2. 쿼리를 잘 만들었는가 - text2SPARQL 평가

3편의 주제였던 쿼리 생성은 평가가 상대적으로 정립되어 있다. 다만 함정이 하나 있다.

• 문자열 일치(Exact Match)는 위험하다. 같은 답을 내는 서로 다른 쿼리가 얼마든지 있다(변수명, 트리플 패턴 순서, OPTIONAL 구조...). 정답 쿼리와 문자열이 다르다고 감점하면 멀쩡한 시스템을 저평가한다
• 그래서 표준은 실행 기반 평가다. 생성 쿼리와 정답 쿼리를 둘 다 실행해서 결과 집합을 비교한다(집합 단위 정밀도/재현율/F1). KGQA 벤치마크인 QALD 계열이 쓰는 macro F1이 대표적이고, LC-QuAD 2.0도 같은 계열이다. LPG 쪽의 Text2Cypher 벤치마크들도 3편에서 봤듯 실행 기반 채점으로 수렴하고 있다
• 보조 지표로 문법 유효율(파싱 통과 비율)과 실행 성공률(에러 없이 결과 반환)을 함께 본다. 3편의 타입 검사 같은 장치가 개선하는 게 정확히 이 지표들이다

하지만, 여전히 의미적으로 쿼리를 잘 만들었는가에 대한 평가는 어려운 부분이 많다.

이 시리즈에서 제안하는 추가 지표 중 하나는 검사 통과율 지표와 같은 것이다. 생성된 쿼리가 domain/range 타입 검사를 몇 회의 self-correction 안에 통과하는가. 시스템 내부 품질을 보는 프로세스 지표다.

6-3. 답을 잘 찾아왔는가 - 종단 간 평가

마지막 층은 사용자가 받는 최종 답변의 평가다.

• 생성형 답변(설명, 요약, 추천 근거)은 표현이 다양해서 문자열 비교가 무의미해진다
• 그래서 RAG 평가 프레임워크들(RAGAS 등)이 보는 것이
  • 충실성(faithfulness) - 답변의 주장들이 검색된 근거에 의해 뒷받침되는가
  • 관련성(answer relevance) - 사용자의 원래 질문에 대해 얼마나 직접적이고 적절하게 응답하는지
  • 컨텍스트 정밀도/재현율 - 그리고 검색 자체의 품질
• 이 글에서 고안하는 구조의 검증 가능률(verifiability rate)은 답변의 statement 중 provenance를 통해 기계적으로 확인된 비율이 된다.결정론적 검사가 있기에 가능한 지표이고, LLM 없이 계산할 수 있다.
• 그리고 이 시리즈의 가설(제약이 환각을 줄이는가)을 검증하려면 결국 주장 수준 환각률(근거에 없는 주장의 비율)을 조건별(vanilla RAG vs 무제약 GraphRAG vs 제약 GraphRAG)로 비교해야 한다. 이건 자동 지표만으로는 부족해서 사람 주석이 어느 정도 필요한 영역이다

층위	질문	주요 방법	대표 지표
스키마	잘 만들었는가	OOPS!, OntoClean, CQ 충족도	피트폴 수, 위반 수, CQ 통과율
쿼리	잘 변환하는가	실행 기반 비교 (QALD 방식)	결과 집합 F1, 문법 유효율
답변	잘 답하는가	충실성 평가 + 결정론적 검증	환각률, 인용 P/R, 검증 가능률

 

층을 나누는 이유는 답변의 품질 원인이 스키마인지, 쿼리인지, 생성인지 구별할 수 있어야하기 때문이다

7. 한계점

 

첫째, 원자 주장 검증은 결합 오류를 못 잡는다. 문장 하나하나가 트리플에 근거해도, 문장들을 잇는 논리 전개가 비약일 수 있다. "A는 B다(근거 있음), B는 C다(근거 있음), 따라서 A는 반드시 C를 해야 한다(?)" 같은 규범적 비약은 트리플 존재 검사 바깥의 일이다. 다중 트리플에 걸친 추론의 타당성 검증은 열린 문제로 남는다.

둘째, provenance의 UX. Q·P·V를 다 보여주면 사용자는 부담을 느낄 수 있다. 감사 가능성은 유지하되 기본 화면에는 요약만 보여주는 점진적 공개(progressive disclosure)가 필요한데, 어느 수준의 요약이 신뢰를 만드는지는 실험해봐야 아는 영역이다.

셋째, 비용. 홉마다 공리를 기록하고 리포트를 보존하면 저장·전송량이 늘고, 인용 강제는 생성 토큰을 늘린다. 규제 산업(금융·법률·의료)처럼 감사 가능성이 요구사항인 곳에서는 당연한 비용이지만, 캐주얼한 용도에서는 과할 수 있다. 어디까지 기록할지도 결국 설계의 문제가 된.

 

참고

• PROV-O : W3C Recommendation (2013)
• RDF 1.2 (RDF-star) : W3C 작업 문서
• ALCE (Gao et al., 2023) : 인용 품질을 NLI로 채점하는 대표 벤치마크, https://arxiv.org/abs/2305.14627
• VeriCite (Qian et al., SIGIR-AP 2025) : 인용의 검증 프레임워크, arXiv:2510.11394
• LLM Attribution 논문 모음: awesome-llm-attributions
• Think-on-Graph (Sun et al., 2023): arXiv:2307.07697
• OOPS! 온톨로지 피트폴 스캐너 : oops.linkeddata.es
• OntoClean : An Overview of OntoClean Guarino & Welty의 온톨로지 평가 방법론 (Communications of the ACM, 2002 소개 논문이 입문으로 적당), Using Large Language Models for OntoClean-based Ontology Refinement (arXiv, 2024)
• QALD : KGQA 평가 캠페인 시리즈, 실행 기반 macro F1의 원류, 9th Challenge on Question Answering over Linked Data (QALD-9)
• Dynamic-KGQA 논문 (arXiv, 2025.03) : 고정된 질문-정답 쌍을 제공하는 대신 지식 그래프에서 동적으로 QA 데이터셋과 서브그래프를 생성해 내는 최신 평가 프레임워크
• LOV(Linked Open Vocabularies) : 공용 어휘 저장소, 어휘 재사용의 출발점