LLM과 함께하는 진리를 찾기 위한 네 가지 규칙

Eunbin Park·2026년 9월 5일

LLM LLM as a Judge

르네 데카르트는 방법서설에서 진리를 찾기 위한 4가지 규칙을 이야기한다. 이 문서에서는 이 네 가지 규칙을 Quality Check/Judge에 전이해보고자 한다.

명증의 규칙 (Rule of Evidence)
1. 의심할 여지가 없을 만큼 명료하고 판명한 것만을 진리로 받아들이고, 성급한 판단과 편견을 피할 것
분해의 규칙 (Rule of Analysis)
1. 복잡한 문제를 해결하기 위해 가능한 한 작은 부분으로 많이 나눌 것
순서의 규칙 (Rule of Synthesis / Order)
1. 가장 단순하고 쉬운 대상에서부터 시작해 단계적으로 복잡한 인식으로 질서있게 나아갈 것
2. 조각들 사이에 논리적 순서와 의존관계를 세우는 규칙
열거의 규칙 (Rule of Enumeration / Review)
1. 모든 경우를 충분히 열거하고 전체 과정을 검토하여 빠뜨린 것이 없는지 확인할 것

들어가며

LLM의 출력 quality를 어떻게 점수화할까?

보다

정답이 전부 존재하지 않는 대규모 데이터에 대해, LLM을 활용하되 LLM의 판단 자체를 정답으로 간주하지 않고 품질을 어떻게 추정할 것인가?

그리고.. 대규모 QC에서 LLM 사용량을 줄이는 자체가 Quality 개선이 아닌가 싶다.

그러니까 LLM에게 최종 품질점수 하나를 맡기지 않는다. 이것을 골조로 이 문서를 작성한다.

이 문서는 오롯이 나(은빈이)를 위한 문서다 !

Quality를 LLM이 알 수 있나?

LLM에 의한 Quality = 4.36 을 만들려 하지 말자. $\fbox{검증 가능한 여러 개의 Quality Signal}$ 을 만들자 !

출발점을 LLM으로 잡지 말고 Measurement-측정으로 옮겨야 한다.

Quality Signal Layer

라고 쓰고 시무 5조라 읽는다

Deterministic Check
Evidence / Source Check
LLM Verifier
Cross-model / Disagreement Check
Human Audit

4, 5번은 별도의 문서로 다룬다.

데이터 $x$ 마다 알고싶은 latent한 품질을 $Q(x)$ 라고 하자. 여기서 문제는 $Q(x)$ 를 직접 관측할 수 없다는 것이다. 그래서 여러 관측 가능한 Quality Signal을 만들어야 한다.

S_1(x), S_2(x), S_3(x), ...

명증의 규칙 (Rule of Evidence)

의심할 여지가 없을 만큼 명료하고 판명한 것만을 진리로 받아들이고, 성급한 판단과 편견을 피할 것

이것은 정말 참인가? → 명제의 질을 검사한다 → 무엇을 사실로 받아들일지 걸러낸다.

다른 말로는… LLM에게 묻지 말아야 할 것 !

{
  "column": "user_id",
  "description": "사용자를 고유하게 식별하는 ID",
  "source": ["wiki", "DDL"]
}

LLM 없이 확인 가능한 것부터 확인한다.

값이 비었나?
Schema에 Column이 존재하는가?
Source Document가 존재하는가?
동일한 Column Description이 반복되고 있는가?
- 동일한 설명이라면 Join 가능한가? 여부도 따져야할까?
길이가 비정상적으로 긴가?
- 정상적인 길이는 무엇인가?
$Q_{deterministic}$ 은 코드로 검사한다.

분해의 규칙 (Rule of Analysis)

복잡한 문제를 해결하기 위해 가능한 한 작은 부분으로 많이 나눌 것

이것은 무엇으로 이루어져있는가? → 문제의 구조를 만든다 → 큰 문제를 작은 부분으로 분해한다.

Quality는 Scalar가 아니라 Vector

당신은 어쩌구저쩌구의 전문가입니다. 
이 설명 Description이 올바른지 0~5 중 몇 점인지 평가하세요.

로 하지 않는다.

예를 들어

항목	설명	의문점
Groundedness	이 설명의 각 주장에 source evidence가 존재하는가?
Contradiction	source와 충돌하는 내용이 있는가?	충돌은 의미인가 표면인가?
Coverage	source에 있는 중요한 정보를 빠뜨렸는가?	“중요한” 정보는 무엇인가?
Consistency	너무 generic해서 다른 데이터에도 그대로 적용되는 설명인가?
Specificity	같은 entity에 대한 다른 description과 모순되는가?	어떻게 같음을 보장하는가?
Fluency	읽기에 자연스러운 설명인가?	자연스러움이란 무엇인가?

~~여기서 의문점은 차치한다…~~

다시 한 번 말하지만 Quality는 Scalar가 아니라 Vector다. 그러므로

Q(x)=[q_{grounded}, q_{coverage}, q_{contradiction}, q_{specificity}, q_{consistency}]

라는 Vector로 볼 수 있다.

판단과 Evidence

{
  "criterion": "groundedness",
  "verdict": "FAIL",
  "claim": "이 컬럼은 회원의 가입일을 의미한다.",
  "evidence": "DDL에는 DATETIME 타입만 존재하며 의미 설명은 없음",
  "reason": "가입일이라는 의미를 뒷받침하는 source가 없음"
}

Closed Model API의 seed는 더이상 지원하지 않고, 지원한다고 해도 신뢰할 수 없다.

LLM 판단의 주 목적은 $\text{claim} \leftrightarrow \text{evidence}$ 이다. 이 항목을 기입하도록 명령하고 기록하면, 나중에 LLM Judge가 틀렸는지 다시 검사할 수 있다.

여기서 {score: 4} 로 진행하게 된다면 아무것도 audit할 수 없다.

Hallucination or … Creativity ?

우리는 이 문제에 분해의 규칙을 대입하기로 했다. 분해의 규칙 맹점은 “가능한 한 작은 부분으로 많이 나눌 것”.

그러니 환각인지 아닌지 판단은 문장 전체가 아니라 Individual/Atomic Fact 단위로 쪼개야 한다.

Grounding (SAFE: Search-Augmented Factuality Evaluator)

검색과 관련하여 당연하겠지만 가장 중요한 요소로 취급
Deepmind에서 연구한 결과로 긴 패러그래프를 타겟으로한 팩트체크를 이론적으로 집대성하여 체계화하였다는데에서 의미있는 연구
- 입력된 텍스트를 작은 명제들로 분절
- 각 분절된 명제들의 연관성을 분석
- 구글 검색을 이용하여 연관있는 것으로 판단된 명제들이 사실인지 검토
다만 relevance와 관련해서는 이전 파트에서 언급했던 Thematic Search와 상충되는 부분이 있어 SAFE가 얼마나 AI Mode에 활용되는지는 미지수임

이제 예를 들어보자.

m_id는 회원을 고유하게 식별하는 bigint PK이며 주문 테이블과 연결된다.

이 설명에는 4개의 Claim이 존재할 때 Claim을 다음과 증명/검사해 볼 수 있다.

$c_1=회원 식별자 \rightarrow \text{wiki evidence 존재}$
$c_2=고유성 \rightarrow \text{PK evidence 존재}$
$c_3=\text{bigint type} \rightarrow \text{DDL evidence 존재}$
$c_4=\text{주문테이블과 연결} \rightarrow \text{evidence 없음}$

이 때, Hallucination Rate는 다음과 같이 정의할 수 있다.

\text{Unsupported Claim Rate} = \frac{\text{\# of unsupported claims}}{\text{\# of all generated claims}}

“이 설명은 hallucination이 몇 점인가요? → 3점입니당!” 보다 측정량으로서 해석 가능하다.

Coverage Failure

Hallucination ⇒ 생성했는데 Evidence, Source 없음

Coverage Failure ⇒ Source에 있는데 생성하지 않은 것

생성된 설명이 “회원 식별용 bigint값” 일 때, 기존 Source에서 추출해둔 주요 Fact로 파악한다

Source	Description	Coverage
Fact 1	user_id는 PK (is_pk: True)	x
Fact 2	type- bigint	o
Fact 3	user table identifier	o
Fact 4	order.user_id와 FK relationship	x

Coverage = \frac{\text{\# of coverage source facts}}{\text{\# of important source facts}}

The other way around

Hallucination과 Coverage는 서로 반대방향이다.

보수적으로 생성하면 환각과 커버리지 둘 다 같이 떨어지고 🔽
Source에 있는 것 같은 내용을 많이 쓰면 환각과 커버리지 둘 다 같이 올라간다. 🔼

Quality를 하나의 숫자로 합치면 이 상충 관계가 사라진다.

순서의 규칙 (Rule of Synthesis / Order)

가장 단순하고 쉬운 대상에서부터 시작해 단계적으로 복잡한 인식으로 질서있게 나아갈 것

무엇부터 알아야하는가? → 명제 순서를 세운다 → 무엇이 무엇에 선행하는지 정한다

Triage

“우리 응급으로 왔는데 언제 봐 주나요?” 응급실에 온 모든 환자는 정말로 응급환자이거나 스스로 응급이라고 생각하는 환자이다. 따라서 이 질문은 의미가 없다. 환자의 중증도와 응급도를 따져 부여하는 KTAS(Korean Triage and Acuity Scale)에 따라 달라진다.

모든 걸 인간에게 보내지 않고 먼저 분류한다.

High-confidence PASS

evidence 있음
deterministic check 통과
LLM verifier agreement 높음

→ 자동 통과

High-confidence FAIL

source contradiction 명확
schema mismatch
unsupported claim 명확

→ 자동 reject / regenerate.

Uncertain

Judge disagreement
evidence 애매함
boundary case
새로운 패턴

→ stronger verifier 또는 human

→ 응급환자 !!! 여기용 !!!

열거의 규칙 (Rule of Enumeration / Review)

모든 경우를 충분히 열거하고 전체 과정을 검토하여 빠뜨린 것이 없는지 확인할 것

빠뜨린 것은 없는가? → 명제 집합의 범위를 검사한다 → 빠뜨린 부분이나 경우가 없는지 점검한다.

사람이 검토하자…

이제 사람이 각 컬럼을 모두 검토한다.

사람이 하루에 하나 씩 해도 7000일이 걸리는 작업, 혹은 7천명이 하루만에 할 수 있는 작업이다.

한 사람이 7천개 분량의 지식을 가지고 있거나, 7천명이 모두 동일하게 퀄리티를 보장할 수 있는 지식이 있을까?

없다 !

2가지 문제

개별 샘플 판정

이 데이터 하나가 좋은가? 나쁜가?

데이터셋 전체 품질 추정

100만 건 중 얼마나 문제가 있는가?
어떤 종류의 문제가 어디에 몰려있는가?

모든 100만 건에 완벽한 PASS/FAIL을 붙이는 것보다,

hallucination 약 몇 %
source coverage가 어디에서 급격히 낮아지는가
어떤 source/table/domain에서 failure가 집중되는가
자동검사가 놓치는 오류가 얼마나 되는가

통계적으로 신뢰할 수 있게 추정하는 것이 더 현실적이다.

HITL 근데 이제 sampling을 곁들인…

엔터누르미 말고 ! 인간은 쓸모있다 ! 하지만 100만건을 금시에 볼 수는 없다 !

Sampling은 목적 별로 추출한다.

Random Sample
1. 실제 전체 quality를 추정
LLM Fail Sample
1. False Positive 확인
LLM Pass Sample
1. False Negative, 숨어있던 Hallucination 확인
Low-Confidence / Disagreement Sample
1. Decision Boundary 확인
New Distribution Sample
1. 새로운 table/domain/source 유형에서 drift 확인
Outlier Sample
1. 새로운 Failure 를 확인

D = D_{random} \cup D_{LLM Fail} \cup D_{LLM pass}\cup D_{Low Confidence}\cup D_{New Distribution} \cup D_{Outlier}

Human의 역할

사람은 LLM을 대체하는 것이 아니라!

자동 signal들이 얼마나 믿을 만한지 calibration하는 anchor로 움직여야한다 !!

Disagreement?

Evaluation system의 epistemic boundary

Sample	Rule	Retrieval	LLM A	LLM B
A	정상	정상	PASS	PASS
B	정상	약함	PASS	FAIL
C	정상	정상	FAIL	PASS
D	오류	충돌	FAIL	FAIL

사람을 B/C에 집중 투입하면

기존 rubric에서 빠진 오류 유형
source가 애매한 경우
LLM의 systematic bias
새로운 데이터 distribution

을 발견할 수 있다.

Failure Taxonomy

예를 들어 10만 건을 분석했다고 가정하자. $AVG(Quality) = 4.27$ ….

흠터레스팅… 굳!

이건 더 이상의 액션이 나올 수 없다.

반대로

Unsupported factual claim → 2.8%
Source contradiction → 0.9%
Missing critical information → 6.2%
Over-generalized description → 8.7%
Wrong entity association → 0.7%
Near-duplicate output → 11.4%
Unclassified / novel failure → 1.1%

로 귀결될 경우, 다음과 같은 작업으로 연결될 수 있다.

retrieval을 고칠 것인가?
generation을 고칠 것인가?
entity resolution을 고칠 것인가?
prompt를 고칠 것인가?

끝내며…

LLM을 어디에 써야할까?

Extractor

문장에서 Atomic fact나 claim을 추출하도록 한다. 여기서는 맞다/틀리다 개념이 없다.

text \rightarrow \{c_1, c_2, ... , c_3\}

Matcher

Source Fact와 Output Claim이 대응되는지 후보를 찾는다. 두 표현이 같은 의미인지 판단?

이 역시 최종 truth라기보다 alignment 후보 생성 역할이다.

Failure Classifier

이미 사람이 정의한 failure taxonomy에 따라 오류 유형을 분류한다.

Critic / Hypothesis Generator

“왜 이 샘플이 이상할 가능성이 있는가?” 를 제안하는 역할

최종 verdict라기보다는 검사할 가설을 생성하는 역할로 사용.

문제를 먼저 크게 나눠보면 조금 다르다 !

Selection / Ranking 문제

→ 좋은 continuous verifier score가 중요할 수 있음

Dataset Quality Control 문제

→ multi-signal measurement + failure taxonomy + sampling + human calibration이 더 중요함

Eunbin Park

이전 포스트

왜 LLM의 0~5점 Rating을 믿지 못하는가

다음 포스트