개념
평가 지형
평가는 세 범주로 나눌 수 있으며, 각 범주는 비용과 신호 품질(signal quality)이 다릅니다.
벤치마크(Benchmark)는 표준화된 테스트 스위트입니다. MMLU, HumanEval, SWE-bench, MATH, ARC, HellaSwag 같은 것들입니다. 모델을 벤치마크에 실행하고 점수를 얻습니다. 장점은 모두가 같은 테스트를 쓰므로 모델을 비교할 수 있다는 점입니다. 단점은 모델과 학습 데이터가 점점 벤치마크를 오염시킨다는 점입니다. 연구소는 벤치마크 질문이 포함된 데이터를 학습할 수 있습니다. 점수는 오릅니다. 능력은 꼭 오르지 않을 수 있습니다.
커스텀 평가(Custom eval)는 특정 사용 사례를 위해 직접 만드는 테스트 스위트입니다. 입력, 기대 출력, 채점 함수를 정의합니다. 법률 문서 요약기는 법률 문서로 평가합니다. SQL 생성기는 실제 데이터베이스 스키마로 평가합니다. 만들기는 비싸지만, 프로덕션 성능을 예측하는 유일한 평가입니다.
인간 평가(Human eval)는 유용성(helpfulness), 정확성(correctness), 유창성(fluency), 안전성(safety) 같은 기준으로 유료 라벨러(annotator)가 모델 출력을 평가하는 방식입니다. 자동 채점이 실패하는 열린 응답 작업의 금 표준(gold standard)입니다. Chatbot Arena는 100개 이상 모델에 대해 200만 개가 넘는 인간 선호 투표를 수집했습니다. 단점은 비용, 즉 판단당 약 $0.10-$2.00, 그리고 속도입니다. 몇 시간에서 며칠이 걸릴 수 있습니다.
graph TD
subgraph Eval["평가 지형(Evaluation Landscape)"]
direction LR
B["벤치마크\n(MMLU, HumanEval)\n저렴하고 표준화됨\n공략 가능하고 오래됨"]
C["커스텀 평가\n내 작업, 내 데이터\n가장 높은 신호\n구축 비용 높음"]
H["인간 평가\n(Chatbot Arena)\n금 표준\n느리고 비쌈"]
end
B -->|"대략적 모델 선택"| C
C -->|"애매한 사례"| H
style B fill:#1a1a2e,stroke:#ffa500,color:#fff
style C fill:#1a1a2e,stroke:#51cf66,color:#fff
style H fill:#1a1a2e,stroke:#e94560,color:#fff
벤치마크가 깨지는 이유
세 가지 메커니즘 때문에 벤치마크 점수는 실제 능력을 반영하지 못하게 됩니다.
데이터 오염(Data contamination). 학습 말뭉치(training corpus)는 인터넷을 긁어옵니다. 벤치마크 질문도 인터넷에 있습니다. 모델은 학습 중 정답을 볼 수 있습니다. 전통적 의미의 부정행위는 아닙니다. 연구소가 의도적으로 벤치마크 데이터를 넣는다고 단정할 수는 없습니다. 하지만 웹 규모 수집(web-scale scraping)에서는 이를 배제하기가 거의 불가능합니다.
시험 대비식 학습(Teaching to the test). 연구소는 벤치마크 성능을 위해 학습 혼합(training mixture)을 최적화합니다. 학습 데이터의 5%가 MMLU식 객관식이면 모델은 형식과 답 분포를 배웁니다. MMLU는 4지선다입니다. 모델은 답이 A/B/C/D에 거의 균등하게 분포한다는 사실을 배웁니다. 이는 답을 모를 때도 도움이 됩니다.
포화(Saturation). 모든 프런티어 모델이 한 벤치마크에서 85-90%를 기록하면 벤치마크는 구분력을 잃습니다. 남은 10-15% 질문은 애매하거나, 라벨이 틀렸거나, 매우 희귀한 도메인 지식을 요구할 수 있습니다. MMLU에서 87%에서 89%로 오른 것이 모델이 더 똑똑해졌다는 뜻이 아닐 수 있습니다. 단지 더 희귀한 질문 두 개를 외웠다는 뜻일 수 있습니다.
Perplexity: 빠른 건강 점검
퍼플렉서티(perplexity)는 모델이 토큰 시퀀스에 얼마나 놀라는지를 측정합니다. 형식적으로는 평균 음의 로그 가능도(negative log-likelihood)에 지수를 취한 값입니다.
PPL = exp(-1/N * sum(log P(token_i | context)))
퍼플렉서티가 10이라는 것은 모델이 평균적으로 각 토큰 위치에서 10개 선택지 중 균등하게 고르는 정도의 불확실성을 가진다는 뜻입니다. 낮을수록 좋습니다. GPT-2는 WikiText-103에서 약 30의 퍼플렉서티를 기록합니다. GPT-3는 약 20입니다. Llama 3 8B는 약 7입니다.
퍼플렉서티는 같은 테스트 세트에서 모델을 비교할 때 유용하지만, 사각지대가 있습니다. 모델은 흔한 패턴 예측을 잘해서 낮은 퍼플렉서티를 얻을 수 있지만, 드물지만 중요한 패턴에는 형편없을 수 있습니다. 또한 지시 따르기(instruction following), 추론(reasoning), 사실 정확성(factual accuracy)에 대해서는 아무 말도 해주지 않습니다. 최종 판정이 아니라 간단한 건전성 점검(sanity check) 용도로 사용합니다.
LLM-as-Judge
강한 모델로 약한 모델의 출력을 평가합니다. 아이디어는 단순합니다. GPT-4o나 Claude Sonnet에게 응답을 정확성, 유용성, 안전성 기준으로 1-5점 척도로 평가하게 합니다. GPT-4o-mini를 기준으로 판단당 약 $0.01이 들고, 인간 판단과 놀랄 만큼 잘 맞습니다. 대부분의 작업에서 약 80% 일치합니다.
채점 프롬프트(scoring prompt)는 모델보다 더 중요할 수 있습니다. "이 응답을 평가하라" 같은 모호한 프롬프트는 노이즈가 큰 점수를 만듭니다. "정답이고 출처를 인용하면 5점, 정답이지만 출처가 없으면 4점, 부분적으로 맞으면 3점..."처럼 구조화된 루브릭(rubric)을 주면 일관되고 재현 가능한 점수를 얻습니다.
실패 모드도 있습니다. 심사 모델(judge model)은 위치 편향(position bias)을 보입니다. 쌍별 비교에서 첫 번째 응답을 선호할 수 있습니다. 장황성 편향(verbosity bias)도 있습니다. 긴 응답을 더 선호합니다. 자기 선호(self-preference)도 있습니다. GPT-4는 동등한 Claude 출력보다 GPT-4 출력을 더 높게 평가할 수 있습니다. 완화책은 순서를 무작위화하고, 길이를 정규화하고, 평가 대상 모델과 다른 심사 모델을 쓰는 것입니다.
쌍별 비교에서 ELO 등급 만들기
Chatbot Arena 방식입니다. 같은 프롬프트에 대한 서로 다른 모델의 두 응답을 보여줍니다. 사람 또는 LLM 심사 모델이 더 나은 쪽을 고릅니다. 수천 번의 비교에서 각 모델의 ELO 등급(ELO rating)을 계산합니다. 체스에서 쓰는 방식과 같습니다.
ELO의 장점은 상대 순위(relative ranking)가 절대 점수보다 신뢰할 수 있고, 무승부를 자연스럽게 다루며, 모든 출력을 독립적으로 채점하는 방식보다 적은 비교로 수렴한다는 점입니다. 2026년 초 기준 Chatbot Arena 순위에서는 GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro가 최상위에서 20 ELO 포인트 안에 모여 있었습니다.
graph LR
subgraph ELO["ELO 등급 파이프라인"]
direction TB
P["프롬프트"] --> MA["모델 A 출력"]
P --> MB["모델 B 출력"]
MA --> J["Judge\n(사람 또는 LLM)"]
MB --> J
J --> W["A 승 / B 승 / 무승부"]
W --> E["ELO 업데이트\nK=32"]
end
style P fill:#1a1a2e,stroke:#0f3460,color:#fff
style J fill:#1a1a2e,stroke:#e94560,color:#fff
style E fill:#1a1a2e,stroke:#51cf66,color:#fff
평가 프레임워크
lm-evaluation-harness(EleutherAI): 표준 오픈소스 평가 프레임워크입니다. 200개 이상 벤치마크를 지원합니다. Hugging Face 모델을 MMLU, HellaSwag, ARC 등에 한 명령으로 실행할 수 있습니다. Open LLM Leaderboard에서 사용됩니다.
RAGAS: RAG 파이프라인 전용 평가 프레임워크입니다. 충실성(faithfulness), 관련성(relevance), 답변 정확성(answer correctness)을 측정합니다. 즉 답이 검색된 문맥과 일치하는지, 검색된 문맥이 질문과 관련 있는지, 답이 맞는지를 봅니다.
promptfoo: 프롬프트 엔지니어링을 위한 설정 기반(config-driven) 평가 도구입니다. YAML로 테스트 케이스를 정의하고, 여러 모델에 실행하고, 통과/실패 보고서를 얻습니다. 프롬프트 회귀 테스트(prompt regression testing)에 유용합니다. 프롬프트 변경이 기존 테스트를 깨지 않는지 확인할 수 있습니다.
커스텀 평가 만들기
프로덕션에 정말 중요한 유일한 평가입니다. 절차는 다음과 같습니다.
-
작업을 정의합니다. 모델이 정확히 무엇을 해야 합니까? 구체적이어야 합니다. "질문에 답한다"는 너무 모호합니다. "고객 불만 이메일이 주어지면 제품명, 이슈 카테고리, 감성을 추출한다"는 평가할 수 있는 작업입니다.
-
테스트 케이스를 만듭니다. 프로토타입 평가에는 최소 50개, 프로덕션에는 200개 이상이 필요합니다. 각 테스트 케이스는 (input, expected_output) 쌍입니다. 빈 입력, 적대적 입력, 애매한 입력, 다른 언어 입력 같은 엣지 케이스를 포함합니다.
-
채점 방식을 정의합니다. 구조화 출력에는 정확 일치가 적합합니다. 텍스트 유사도에는 BLEU/ROUGE가 쓰일 수 있습니다. 열린 응답 품질에는 LLM-as-judge가 필요합니다. 추출 작업에는 F1이 적합합니다. 여러 지표는 가중치로 결합합니다.
-
자동화합니다. 모든 평가는 하나의 명령으로 실행되어야 합니다. 수동 단계가 없어야 합니다. 결과는 시간에 따라 비교할 수 있는 형식으로 저장합니다.
-
시간에 따라 추적합니다. 단일 평가 점수는 홀로 의미가 없습니다. 추세선(trendline)이 필요합니다. 마지막 프롬프트 변경 뒤 점수가 좋아졌습니까? 모델을 바꾼 뒤 회귀했습니까? 평가를 프롬프트와 함께 버전 관리합니다.
| 평가 유형 | 판단당 비용 | 인간과의 일치 | 가장 적합한 용도 |
|---|
| 정확 일치(exact match) | 약 $0 | 적용 가능한 경우 100% | 구조화 출력, 분류 |
| BLEU/ROUGE | 약 $0 | 약 60% | 번역, 요약 |
| LLM-as-judge | 약 $0.01 | 약 80% | 열린 응답 생성 |
| 인간 평가 | $0.10-$2.00 | N/A, 정답 기준 자체 | 애매하거나 고위험인 작업 |
직접 만들기
Step 1: 최소 평가 프레임워크
핵심 추상화를 정의합니다. 평가 케이스(eval case)는 입력, 기대 출력, 선택적 메타데이터 딕셔너리를 가집니다. 채점기(scorer)는 예측과 참조 답을 받아 0과 1 사이 점수를 반환합니다.
import json
from collections import Counter
class EvalCase:
def __init__(self, input_text, expected, metadata=None):
self.input_text = input_text
self.expected = expected
self.metadata = metadata or {}
class EvalSuite:
def __init__(self, name, cases, scorers):
self.name = name
self.cases = cases
self.scorers = scorers
def run(self, model_fn):
results = []
for case in self.cases:
prediction = model_fn(case.input_text)
scores = {}
for scorer_name, scorer_fn in self.scorers.items():
scores[scorer_name] = scorer_fn(prediction, case.expected)
results.append({
"input": case.input_text,
"expected": case.expected,
"prediction": prediction,
"scores": scores,
})
return results
Step 2: 채점 함수
정확 일치, 토큰 F1, 시뮬레이션된 LLM-as-judge 채점기를 만듭니다.
def exact_match(prediction, expected):
return 1.0 if prediction.strip().lower() == expected.strip().lower() else 0.0
def token_f1(prediction, expected):
pred_tokens = set(prediction.lower().split())
exp_tokens = set(expected.lower().split())
if not pred_tokens or not exp_tokens:
return 0.0
common = pred_tokens & exp_tokens
precision = len(common) / len(pred_tokens)
recall = len(common) / len(exp_tokens)
if precision + recall == 0:
return 0.0
return 2 * (precision * recall) / (precision + recall)
def llm_judge_simulated(prediction, expected):
pred_words = set(prediction.lower().split())
exp_words = set(expected.lower().split())
if not exp_words:
return 0.0
overlap = len(pred_words & exp_words) / len(exp_words)
length_penalty = min(1.0, len(prediction) / max(len(expected), 1))
return round(overlap * 0.7 + length_penalty * 0.3, 3)
Step 3: ELO 등급 시스템
ELO 업데이트로 쌍별 비교(pairwise comparison)를 구현합니다. Chatbot Arena가 모델 순위를 매길 때 쓰는 방식과 같습니다.
class ELOTracker:
def __init__(self, k=32, initial_rating=1500):
self.ratings = {}
self.k = k
self.initial_rating = initial_rating
self.history = []
def _ensure_player(self, name):
if name not in self.ratings:
self.ratings[name] = self.initial_rating
def expected_score(self, rating_a, rating_b):
return 1 / (1 + 10 ** ((rating_b - rating_a) / 400))
def record_match(self, player_a, player_b, outcome):
self._ensure_player(player_a)
self._ensure_player(player_b)
ea = self.expected_score(self.ratings[player_a], self.ratings[player_b])
eb = 1 - ea
if outcome == "a":
sa, sb = 1.0, 0.0
elif outcome == "b":
sa, sb = 0.0, 1.0
else:
sa, sb = 0.5, 0.5
self.ratings[player_a] += self.k * (sa - ea)
self.ratings[player_b] += self.k * (sb - eb)
self.history.append({
"a": player_a, "b": player_b,
"outcome": outcome,
"rating_a": round(self.ratings[player_a], 1),
"rating_b": round(self.ratings[player_b], 1),
})
def leaderboard(self):
return sorted(self.ratings.items(), key=lambda x: -x[1])
Step 4: 퍼플렉서티 계산
토큰 확률에서 퍼플렉서티를 계산합니다. 실제로는 모델의 로짓(logits)에서 이 값을 얻습니다. 여기서는 확률 분포를 시뮬레이션합니다.
import numpy as np
def perplexity(log_probs):
if not log_probs:
return float("inf")
avg_neg_log_prob = -np.mean(log_probs)
return float(np.exp(avg_neg_log_prob))
def token_log_probs_simulated(text, model_quality=0.8):
np.random.seed(hash(text) % 2**31)
tokens = text.split()
log_probs = []
for i, token in enumerate(tokens):
base_prob = model_quality
if len(token) > 8:
base_prob *= 0.6
if i == 0:
base_prob *= 0.7
prob = np.clip(base_prob + np.random.normal(0, 0.1), 0.01, 0.99)
log_probs.append(float(np.log(prob)))
return log_probs
Step 5: 결과 집계
평가 실행 전체의 요약 통계를 계산합니다. 평균, 중앙값, 임계값 기준 통과율(pass rate), 지표별 세부 분해(breakdown)를 만듭니다.
def summarize_results(results, threshold=0.8):
all_scores = {}
for r in results:
for metric, score in r["scores"].items():
all_scores.setdefault(metric, []).append(score)
summary = {}
for metric, scores in all_scores.items():
arr = np.array(scores)
summary[metric] = {
"mean": round(float(np.mean(arr)), 3),
"median": round(float(np.median(arr)), 3),
"std": round(float(np.std(arr)), 3),
"min": round(float(np.min(arr)), 3),
"max": round(float(np.max(arr)), 3),
"pass_rate": round(float(np.mean(arr >= threshold)), 3),
"n": len(scores),
}
return summary
def print_summary(summary, suite_name="Eval"):
print(f"\n{'=' * 60}")
print(f" {suite_name} 요약(Summary)")
print(f"{'=' * 60}")
for metric, stats in summary.items():
print(f"\n {metric}:")
print(f" 평균(Mean): {stats['mean']:.3f}")
print(f" 중앙값(Median): {stats['median']:.3f}")
print(f" 표준편차(Std): {stats['std']:.3f}")
print(f" 범위(Range): [{stats['min']:.3f}, {stats['max']:.3f}]")
print(f" 통과율(Pass rate): {stats['pass_rate']:.1%} (threshold >= 0.8)")
print(f" 표본 수(N): {stats['n']}")
Step 6: 전체 파이프라인 실행
모든 조각을 연결합니다. 작업을 정의하고, 테스트 케이스를 만들고, 두 모델을 시뮬레이션하고, 평가를 실행하고, 쌍별 비교에서 ELO를 계산하고, 리더보드를 출력합니다.
def demo_model_good(prompt):
responses = {
"What is the capital of France?": "Paris",
"What is 2 + 2?": "4",
"Who wrote Hamlet?": "William Shakespeare",
"What language is PyTorch written in?": "Python and C++",
"What is the boiling point of water?": "100 degrees Celsius",
}
return responses.get(prompt, "I don't know")
def demo_model_bad(prompt):
responses = {
"What is the capital of France?": "Paris is the capital city of France",
"What is 2 + 2?": "The answer is four",
"Who wrote Hamlet?": "Shakespeare",
"What language is PyTorch written in?": "Python",
"What is the boiling point of water?": "212 Fahrenheit",
}
return responses.get(prompt, "Unknown")
cases = [
EvalCase("What is the capital of France?", "Paris"),
EvalCase("What is 2 + 2?", "4"),
EvalCase("Who wrote Hamlet?", "William Shakespeare"),
EvalCase("What language is PyTorch written in?", "Python and C++"),
EvalCase("What is the boiling point of water?", "100 degrees Celsius"),
]
suite = EvalSuite(
name="General Knowledge",
cases=cases,
scorers={
"exact_match": exact_match,
"token_f1": token_f1,
"llm_judge": llm_judge_simulated,
},
)
results_good = suite.run(demo_model_good)
results_bad = suite.run(demo_model_bad)
print_summary(summarize_results(results_good), "Model A (간결하고 정확)")
print_summary(summarize_results(results_bad), "Model B (장황한 바꿔쓰기)")
"좋은" 모델은 정확한 답을 냅니다. "나쁜" 모델은 장황한 바꿔쓰기(paraphrase)를 냅니다. 정확 일치는 장황한 모델을 심하게 벌합니다. 토큰 F1과 LLM-as-judge는 더 관대합니다. 이것은 지표 선택이 왜 중요한지 보여줍니다. 같은 모델도 채점 방식에 따라 훌륭해 보이거나 형편없어 보일 수 있습니다.
Step 7: ELO 토너먼트
여러 라운드에 걸쳐 모델 사이의 쌍별 비교를 실행합니다.
elo = ELOTracker(k=32)
for case in cases:
pred_a = demo_model_good(case.input_text)
pred_b = demo_model_bad(case.input_text)
score_a = token_f1(pred_a, case.expected)
score_b = token_f1(pred_b, case.expected)
if score_a > score_b:
outcome = "a"
elif score_b > score_a:
outcome = "b"
else:
outcome = "tie"
elo.record_match("model_a_concise", "model_b_verbose", outcome)
print("\nELO 리더보드(ELO Leaderboard):")
for name, rating in elo.leaderboard():
print(f" {name}: {rating:.0f}")
Step 8: 퍼플렉서티 비교
품질 수준이 다른 "모델"들의 퍼플렉서티를 비교합니다.
test_text = "The quick brown fox jumps over the lazy dog in the garden"
for quality, label in [(0.9, "강한 모델(Strong model)"), (0.7, "중간 모델(Medium model)"), (0.4, "약한 모델(Weak model)")]:
log_probs = token_log_probs_simulated(test_text, model_quality=quality)
ppl = perplexity(log_probs)
print(f" {label} (quality={quality}): perplexity = {ppl:.2f}")
사용해보기
lm-evaluation-harness(EleutherAI)
임의의 모델에서 벤치마크를 실행하는 표준 도구입니다.
promptfoo
프롬프트 엔지니어링을 위한 설정 기반 평가입니다. YAML에 테스트를 정의하고 여러 공급자(provider)에 실행합니다.
providers:
- openai:gpt-4o-mini
- anthropic:claude-3-haiku
prompts:
- "Answer in one word: {{question}}"
tests:
- vars:
question: "What is the capital of France?"
assert:
- type: contains
value: "Paris"
- vars:
question: "What is 2 + 2?"
assert:
- type: equals
value: "4"
RAGAS로 RAG 평가하기
RAGAS는 일반 평가가 놓치는 것을 측정합니다. 모델의 답이 추상적으로 "맞는지"만 보는 것이 아니라, 검색된 문맥(retrieved context)에 근거하는지를 봅니다.
산출물 만들기
이 레슨은 outputs/prompt-eval-designer.md를 만듭니다. 이 재사용 가능한 프롬프트는 어떤 작업에 대해서도 커스텀 평가 스위트를 설계합니다. 작업 설명을 주면 테스트 케이스, 채점 함수, 통과/실패 임계값 추천을 생성합니다.
또한 outputs/skill-evaluation.md를 만듭니다. 이 스킬은 작업 유형, 예산, 지연 시간 요구사항을 기준으로 적절한 평가 전략을 고르는 의사결정 프레임워크입니다.
연습문제
-
"일관성(consistency)" 채점기를 추가합니다. 같은 입력을 모델에 5번 넣고 출력이 얼마나 자주 일치하는지 측정합니다. 결정적 입력에서 답이 흔들리면 프롬프트가 취약하거나 온도(temperature) 설정이 높다는 뜻입니다.
-
ELO 추적기(ELO tracker)를 확장해 여러 심사 함수(judge function), 즉 정확 일치, F1, LLM-as-judge를 지원하고 가중치를 줄 수 있게 만듭니다. 정확 일치에 높은 가중치를 줄 때와 F1에 높은 가중치를 줄 때 리더보드가 어떻게 바뀌는지 비교합니다.
-
특정 작업을 위한 평가 스위트를 만듭니다. 예를 들어 이메일을 5개 카테고리로 분류하는 작업입니다. 엣지 케이스를 포함해 다양한 예시 100개를 만듭니다. 여러 카테고리에 속할 수 있는 이메일, 빈 이메일, 다른 언어 이메일을 포함합니다. 서로 다른 "모델", 즉 규칙 기반, 키워드 매칭, 시뮬레이션 LLM의 성능을 측정합니다.
-
오염 탐지(contamination detection)를 구현합니다. 평가 질문 집합과 학습 말뭉치가 주어졌을 때, 평가 질문 또는 가까운 바꿔쓰기가 학습 데이터에 얼마나 등장하는지 확인합니다. 연구자들은 이런 방식으로 벤치마크 유효성을 감사합니다.
-
"모델 diff" 도구를 만듭니다. 두 모델 버전의 평가 결과가 주어졌을 때 어떤 테스트 케이스가 개선되었고, 어떤 것이 회귀했으며, 어떤 것이 그대로인지 강조합니다. 이는 평가의 코드 diff와 같습니다. 변경이 도움이 되었는지 해쳤는지 이해하는 데 필수입니다.
핵심 용어
| 용어 | 흔한 설명 | 실제 의미 |
|---|
| MMLU | "그 벤치마크" | Massive Multitask Language Understanding. 57개 과목의 15,908개 객관식 질문이며, 2025년에는 88% 이상에서 포화되었습니다. |
| HumanEval | "코드 평가" | OpenAI의 164개 Python 함수 완성 문제입니다. 고립된 함수 생성만 테스트합니다. |
| SWE-bench | "진짜 코딩 평가" | 12개 Python 저장소의 GitHub 이슈 2,294개로 구성되며, 테스트 생성까지 포함한 종단 간(end-to-end) 버그 수정을 측정합니다. |
| Perplexity | "모델이 얼마나 헷갈리는가" | exp(-avg(log P(token_i given context)))입니다. 낮을수록 실제 토큰에 높은 확률을 부여한다는 뜻입니다. |
| ELO rating | "모델용 체스 순위" | 쌍별 승패 기록으로 계산한 상대 능력 등급입니다. Chatbot Arena가 100개 이상 모델 순위에 사용합니다. |
| LLM-as-judge | "AI로 AI 채점하기" | 강한 모델이 루브릭에 따라 약한 모델 출력을 채점합니다. 판단당 약 $0.01이고 인간 판단과 약 80% 일치합니다. |
| Data contamination | "모델이 시험을 봤다" | 학습 데이터에 벤치마크 질문이 포함되어 실제 능력 향상 없이 점수가 부풀려지는 현상입니다. |
| Eval suite | "테스트 묶음" | 특정 능력을 측정하는 (input, expected_output, scorer) 삼중항의 버전 관리된 컬렉션입니다. |
| Pass rate | "몇 퍼센트 맞혔는가" | 임계값 이상 점수를 받은 평가 케이스 비율입니다. 평균 점수보다 신뢰성을 더 직접적으로 보여줍니다. |
| Chatbot Arena | "모델 순위 사이트" | 200만 개 이상 인간 선호 투표를 가진 LMSYS 플랫폼입니다. ELO 등급으로 가장 신뢰받는 LLM 리더보드를 만듭니다. |
더 읽을거리