LLM-as-a-Judge 기초: RAGAS 5개 지표부터
RAG를 만들다 보면 어느 순간 이런 벽에 부딪힌다.
"이 답이 진짜로 맞는지 사람이 매번 볼 수 없다"
"근데 정답이 하나로 딱 정해지지도 않는다"
객관식이면 채점기가 쉽다. 하지만 RAG의 답은 문장이고, 문장은 "맞다/틀리다"로 이분되지 않는다. 그래서 등장한 게 LLM-as-a-Judge다. LLM에게 "이 답이 어느 정도 근거 있는가"를 스코어링하게 시키는 방식.
이번 글은 그 판정자를 처음 세울 때 알아야 할 개념들을 정리한다. RAGAS라는 프레임워크가 표준화한 5개 지표부터 시작한다.
왜 judge가 필요한가
RAG의 결과물은 두 가지가 섞여 있다.
1) 검색 결과: 어떤 문서를 컨텍스트로 뽑아왔는가
2) 생성 결과: 그 문서로부터 어떤 답을 만들었는가
검색은 rag-retriever 시리즈의 recall/precision/nDCG 같은 지표로 평가할 수 있다. 하지만 생성은 다르다.
Q. "A사 3분기 매출은?"
컨텍스트: [실적 발표 문서 전문]
답1: "A사 3분기 매출은 2조 원입니다." ← 사실 O
답2: "A사 3분기 매출은 2조 원으로, 전년 대비 ← 사실 O + 근거 X
15% 증가했습니다." (컨텍스트에 15% 없음)
답3: "A사 3분기 매출은 3조 원입니다." ← 사실 X (환각)
세 답 모두 문장으로는 유창하다. 그런데 셋의 "품질"은 완전히 다르다. 사람 눈으로 골라내면 되지만, 매일 돌리는 파이프라인에서 100건씩 사람이 본다는 건 불가능하다.
Judge는 이걸 자동화한다.
RAGAS 5개 지표 정식 명명
여기서부터가 오늘의 본론. 판정 항목을 마음대로 이름 붙이면 나중에 프레임워크와 비교할 때 헷갈린다. 그래서 RAGAS 라는 프레임워크가 정리한 5개 지표를 표준으로 삼자.
1. faithfulness
"답이 컨텍스트에 근거를 두는가"
컨텍스트에 없는 사실을 답이 지어내면 faithfulness가 떨어진다. 위 예시의 답2가 faithfulness 실패다 — 매출 숫자는 맞지만 "전년 대비 15%"라는 근거 없는 진술이 붙었다.
이게 환각(hallucination) 감지의 정식 이름이다.
2. answer_relevance
"답이 질문에 대답하는가"
컨텍스트를 잘 인용해도 질문과 상관없는 얘기를 하면 relevance가 떨어진다.
Q. "3분기 매출은?"
A. "A사는 반도체 사업을 주력으로 하는 기업입니다." ← relevance 낮음
3. context_precision
"뽑아온 컨텍스트가 답에 실제로 필요한 것들인가"
Top-k로 10개 문서를 넣었는데 그 중 답에 실제 쓰인 건 1개뿐이라면 precision이 낮다. 노이즈 컨텍스트가 얼마나 섞였는지 본다.
4. context_recall
"답에 필요한 정보가 컨텍스트에 다 들어있었는가"
컨텍스트에 답의 근거가 부분적으로만 있고 나머지는 없었다면 recall 실패. 답이 좋아 보여도 반쪽짜리라는 뜻이다.
5. answer_correctness
"답이 정답과 일치하는가" (정답 라벨이 있을 때)
라벨링된 evaluation dataset이 있어야 계산할 수 있다. 위 4개와 달리 "정답" 이 필요하다.
실무에서 5개 다 재나?
아니. 시스템 단계에 따라 다르다.
평가셋 없이 시작: faithfulness + answer_relevance 두 개
(컨텍스트와 답만 있으면 잴 수 있음)
Retriever 튜닝: context_precision + context_recall 추가
배포 전: answer_correctness까지 (정답 라벨 필요)
특히 첫 단계의 faithfulness는 가성비가 최고다. 정답 라벨 없이도 "환각 여부"만은 잴 수 있다.
오늘 코드의 groundedness는 사실상 faithfulness다
여기서 이름 정리 하나. 실제 프로젝트에서 판정 지표를 이렇게 만들었다.
groundedness_score:
- LLM에게 (컨텍스트, 답) 을 주고
- "답의 각 문장이 컨텍스트로 뒷받침되는가"를 0~1로 판정
- N회 median으로 안정화
이건 이름만 groundedness지, 사실상 RAGAS의 faithfulness와 같다.
G-Eval 논문이나 DeepEval에서는 이걸 faithfulness 또는 groundedness로
혼용해서 쓰지만, 표준 명명은 faithfulness가 맞다.
앞으로 팀 내에서는 지표 이름을 다음처럼 정리하자.
groundedness → faithfulness
hallucination_count → 1 - faithfulness (혹은 그 임계치 위반 건수)
answer_quality → answer_relevance + answer_correctness의 조합
이름 하나 통일하면 나중에 RAGAS/DeepEval/Ragas Phoenix 같은 오픈소스로 갈아탈 때 지표 매핑이 무료가 된다.
G-Eval: 판정자가 rubric도 만든다
RAGAS가 지표 명명의 표준이라면, G-Eval(Liu et al., NAACL 2023)은 판정 방식의 진화판이다.
기본 아이디어:
- 사람이 "faithfulness를 이렇게 판정하라"는 rubric을 짧게 준다
- LLM이 그 rubric을 CoT(Chain-of-Thought)로 스스로 확장한다
- 확장된 rubric으로 실제 점수를 매긴다
예를 들어 사람이 준 rubric은 이 정도.
faithfulness: 답의 모든 사실 진술이 컨텍스트로 뒷받침되어야 한다.
G-Eval은 이걸 CoT로 이렇게 확장한다.
1. 답을 문장 단위로 분해한다
2. 각 문장이 사실 진술인지, 의견/보조 표현인지 구분한다
3. 사실 진술이면 컨텍스트에서 근거 문장을 찾는다
4. 근거를 찾으면 1점, 부분적이면 0.5점, 없으면 0점
5. 평균을 최종 점수로 낸다
이걸 사람이 매번 rubric으로 쓰기엔 지치니까 LLM에게 확장을 맡기는 것이다. 짧은 rubric으로 시작해도 실제 판정은 세밀해진다.
프레임워크 vs 자체 구현
지금 실무에서 자체 구현으로 굴리고 있는데, 오픈소스 상황은 이렇다.
RAGAS - 5개 지표 표준. Python. LangChain 통합 좋음
DeepEval - pytest 스타일. CI에 붙이기 편함
Phoenix - Arize의 관측 툴. Trace와 evaluation을 한 곳에서
LangSmith - LangChain 진영. dataset·evaluator 관리
셋 다 내부적으론 "LLM에게 rubric을 주고 스코어를 받는다"는 같은 패턴이다. 자체 구현이 잘못된 건 아니다. 오히려 지금처럼 지표를 직접 만들어보면 프레임워크 채택 시점에 "이건 왜 이렇게 짰지"가 이해가 된다.
다만 결정 포인트가 몇 개 있다.
1. 지표 이름을 RAGAS 표준으로 맞춘다 → 나중에 갈아타기 쉬움
2. rubric은 별도 파일로 분리한다 → 여러 지표를 조합할 때 편함
3. LLM 응답을 JSON으로 강제한다 → 파싱 로직 복잡도가 확 줄어듦
세 번째는 이 시리즈 다음 편에서 좀 더 파겠지만, 지금은 "정답이 아닌 답을 판정하는 방법"에 오늘의 초점이 있다.
실측: 판정자가 파이프라인을 어떻게 바꾸는가
프로젝트에서 faithfulness(그때는 groundedness라고 부르던 지표) 판정을 파이프라인에 붙인 뒤 관측한 숫자다.
판정 도입 전: grounded score = 0.919 (샘플 15종목 평균)
1주 튜닝 후: grounded score = 0.942
숫자만 보면 "2.3%p 올랐네"지만, 판정이 없었다면 이 2.3%p 이동을 관측할 방법이 없었다. 환각 발생 건수는 3건 → 0건으로 떨어졌는데 이 역시 판정이 있어서 세어졌다.
정리하자면 판정자의 가장 큰 가치는 점수 그 자체가 아니라 "어제 대비 오늘 파이프라인이 나빠졌는지 좋아졌는지를 즉시 안다"는 데 있다. 회귀 감지기가 무료로 붙는 셈이다.
다음 편 예고
Judge가 있으면 파이프라인이 좋아진다 — 는 여기까지는 다 맞다. 문제는 그 다음이다.
같은 (컨텍스트, 답) 쌍을 판정자에게 5번 물어보면
매번 다른 점수가 나온다.
판정자 자체가 흔들리는데 그걸 어떻게 신뢰할 수 있나?
다음 편에서는 판정자의 **편향(bias)**과 **안정성(stability)**을 다룬다. N회 median, σ 임계 재판정, position/verbosity bias 같은 것들이다.