LLM 평가지표와 벤치마크 정리

왜 LLM 평가는 어려운가

전통적인 소프트웨어는 단위 테스트로 "기능대로 동작하는가"를 확인하면 됩니다. 분류·회귀 모델도 정답이 있어서 맞았는지 틀렸는지 비교할 수 있습니다. LLM은 사정이 다릅니다.

• 자유 형식의 텍스트를 생성하기 때문에 정답을 하나로 정하기 어렵습니다.
• 평가 기준이 다차원적입니다. 사실성, 관련성, 유창성, 안전성, 지시 준수 중 무엇을 보느냐에 따라 같은 답의 평가가 달라집니다.
• 같은 프롬프트에도 매번 다른 답이 나올 수 있어서 한 번의 평가로 능력을 확정하기 어렵습니다.

결국 여러 지표를 함께 보고, 반복해서 측정해야 합니다.

평가 방법 세 가지

1. 자동 평가 지표

사람 없이 수치로 측정하는 방법입니다. 빠르고 재현 가능하지만 의미 수준의 판단에는 한계가 있습니다.

지표	무엇을 보나	한계
Perplexity(혼란도)	모델이 텍스트의 다음 토큰을 얼마나 잘 예측하는지. 낮을수록 "덜 놀람"	질문에 맞는 답인지는 판단 못 함 (유창하지만 엉뚱한 답)
BLEU	생성문과 참조문의 n-gram 겹침, 정밀도 중심	동의어를 처리하지 못해 같은 의미라도 점수가 낮아짐
ROUGE	요약 품질 평가, 재현율 중심	표면 형태 비교라는 한계는 BLEU와 같음
BERTScore	BERT 임베딩으로 토큰 간 의미 유사도를 비교해 정밀도·재현율의 F1 계산	임베딩 모델 성능에 의존

2. LLM을 평가자로 쓰기 (LLM-as-a-Judge)

평가 기준이 담긴 프롬프트를 주고 다른 LLM이 응답을 채점하게 하는 방식입니다. 무엇을 평가할지, 점수 범위와 각 점수의 의미를 구체적으로 써 주고, 점수와 함께 근거를 출력하게 합니다. 사람보다 싸고 빠르지만 편향이 있습니다.

• 자기 선호 편향: 자기가 만든 응답에 높은 점수
• 장문 편향: 긴 응답에 높은 점수
• 위치 편향: 비교할 때 먼저 제시된 응답에 높은 점수

judge를 고르고 검증하는 방법은 llm-as-a-judge-in-practice에서 따로 다룹니다.

3. 인간 평가

가장 정확하고 신뢰할 수 있어서 기준선(gold standard) 역할을 합니다. 대신 비싸고 느립니다. 현실적으로는 소규모 인간 평가로 기준선을 만들고, 자동 지표와 LLM judge가 그 기준선과 얼마나 일치하는지 확인하는 조합이 좋다고 생각합니다.

주요 벤치마크

벤치마크는 모델을 같은 조건에서 비교하기 위한 데이터셋과 평가 절차의 묶음입니다.

벤치마크	측정 대상	특징
MMLU	여러 분야의 지식·추론	약 1만 4천 개 객관식 문제
HumanEval	코드 생성	164개 Python 문제, 테스트 통과 여부를 pass@k로 측정
MT-Bench	멀티턴 대화	2턴 대화 시나리오 80개, LLM judge가 8개 카테고리에 1~10점 채점
Chatbot Arena	종합 선호도	익명 두 모델의 응답을 사람이 블라인드로 고르고 Elo 레이팅 부여
GSM8K → MATH	수학·다단계 추론	GSM8K는 포화되어 더 어려운 MATH로 이동
IFEval	지시 이행	"정확히 3개의 bullet"처럼 규칙으로 채점 가능한 제약

G-Eval은 벤치마크가 아니라 LLM judge 프레임워크입니다. Chain-of-Thought로 judge가 평가 기준을 스스로 세분화한 뒤 점수를 매기게 해서 사람과의 일치도를 높입니다.

벤치마크를 믿기 전에 알아야 할 것

Hugging Face의 LLM Evaluation Guidebook 요약을 읽으면서 특히 와닿았던 부분입니다.

• 누구를 위한 평가인가: 모델을 만드는 사람은 학습 레시피 변경을 빠르게 비교할 벤치마크가 필요하고, 모델을 쓰는 사람은 자기 사용 사례에 맞는 맞춤 평가가 필요합니다. 애플리케이션 개발자는 대부분 후자입니다. 막연한 "AGI 수준"보다 보고서 요약, 코드 리팩토링처럼 구체적인 작업 능력을 재는 편이 타당하다는 관점도 좋았습니다.
• 포화(Saturation)와 오염(Contamination): 모두가 고득점을 받아 변별력이 사라지거나, 벤치마크 데이터가 학습 데이터에 섞여 "외워서" 맞히는 문제입니다. 그래서 GPQA, MuSR처럼 더 어려운 문제나, LiveCodeBench처럼 계속 새 문제를 수집하는 동적 벤치마크로 옮겨 가고 있습니다.
• 토큰화의 영향: 대부분의 토크나이저가 영어 위주라 한국어는 더 많은 토큰으로 쪼개집니다. 비용이 늘 뿐 아니라 생성 길이 제한에 걸려 답이 잘리는 불이익도 생깁니다. 숫자를 쪼개는 방식이 모델마다 달라 수학 점수가 흔들리기도 합니다.
• 대화 템플릿과 추론 모델: System/User/Assistant 역할 구분을 지키지 않으면 성능이 급감합니다. 사고 과정을 태그로 출력하는 모델은 그 부분을 제거하고 최종 답만 채점해야 합니다.
• 로그 우도 vs 생성형 평가: 객관식은 후보별 확률을 비교하는 로그 우도 방식이 빠르고 싸지만, logit을 주지 않는 API 모델이 늘면서 생성형 평가가 필수가 됐습니다.
• 사소한 설정이 점수를 흔든다: 평가 라이브러리의 전처리, 정밀도(FP16/FP32), 배치 크기, 심지어 선택지를 A로 쓰느냐 (A)로 쓰느냐에 따라 점수가 달라집니다.
• 안전성과 유용성의 트레이드오프: 안전성을 지나치게 높이면 무해한 질문까지 거부하는 과잉 거부(over-refusal)가 생기므로 둘을 함께 봐야 합니다.

정리: 평가 데이터셋 설계 원칙

벤치마크 점수가 높다고 내 서비스에서 잘 동작한다는 보장은 없습니다. 특정 도메인이 빠져 있거나 언어가 다를 수 있기 때문입니다. 배포 전에는 자기 데이터로 평가해야 하고, 그 데이터셋은 다음을 지켜야 합니다.

1. 실제 사용 사례를 반영한다
2. 경계에 있는 모호한 질문 같은 엣지 케이스를 포함한다
3. 정답(gold set)의 품질이 높아야 한다
4. 충분한 크기를 확보한다

다음 글 rag-evaluation-ragas-deepeval에서는 검색과 생성이 결합된 RAG 파이프라인을 평가하는 방법을 다룹니다.

참조

• 위키독스 - LLM 평가 지표와 벤치마크
• The LLM Evaluation Guidebook (Hugging Face) 소개 - 파이토치 한국 사용자 모임