한국어 LLM 직접 벤치마크하는 법: 평가셋·지표·재현 가능한 측정 설계

한국어 LLM을 제대로 고르려면, 공개 리더보드 순위를 그대로 믿지 말고 당신의 실제 작업과 데이터로 직접 측정해야 합니다. 리더보드 1위 모델이 당신의 고객 상담 로그, 사내 문서, 법무 검토 요청에서도 1위라는 보장은 없습니다. 평가의 핵심 질문은 "어떤 모델이 제일 잘하나"가 아니라 "내 작업에서, 내가 정한 기준으로, 재현 가능하게 어떤 모델이 나은가"입니다.

이 글은 점수나 순위를 발표하는 글이 아닙니다. 검증된 공개 한국어 벤치마크(KMMLU, KoBEST, KLUE, HAE-RAE Bench, LogicKor)의 정확한 구성과 출처를 출발점으로 삼되, 거기서 멈추지 않고 당신이 직접 평가셋을 설계하고, 지표를 고르고, 재현 가능한 파이프라인으로 측정하는 방법을 다룹니다.

빠르게 정리하면 측정 설계는 다음 5단계입니다.

단계	핵심 결정	흔한 실수
1. 평가셋	공개 벤치마크 + 내 도메인 셋 병행	공개 셋만 보고 끝냄
2. 지표	정확도 / LLM-as-judge / 지연·비용	정확도 하나로 모든 작업 판단
3. 실행 환경	시드·온도·프롬프트·버전 고정	매번 다른 설정으로 재실행
4. 재현	코드·데이터·해시를 버전 관리	결과만 저장하고 조건 분실
5. 오류 통제	오염·심사자 편향·표본 크기 점검	0.3%p 차이를 유의미하게 해석

핵심 원칙 하나만 기억한다면: "측정 조건을 적어두지 않은 점수는 점수가 아니다." 같은 모델도 프롬프트 한 줄, 온도 0.1 차이, few-shot 예시 순서에 따라 점수가 흔들립니다. 재현 불가능한 측정은 의사결정 근거가 될 수 없습니다.

직접 평가셋을 만들기 전에, 신뢰할 수 있는 공개 한국어 벤치마크의 구성을 정확히 알아야 합니다. 아래는 논문·데이터셋 출처가 모두 확인된 것만 추렸습니다. (점수·순위는 시점에 따라 변하므로 여기서는 구성과 측정 방식만 다룹니다.)

벤치마크	무엇을 재나	구성	출처
KMMLU	한국어 전문지식(45개 과목)	35,030 객관식, 번역 아닌 한국 원시험 수집	arXiv:2402.11548, HF HAERAE-HUB/KMMLU
KoBEST	한국어 자연어이해(NLU)	5개 과제: BoolQ·COPA·WiC·HellaSwag·SentiNeg, 사람 주석	arXiv:2204.04541, HF skt/kobest_v1
KLUE	한국어 NLU 종합	8개 과제(주제분류·STS·NLI·NER·관계추출·의존구문·MRC·DST), 저작권 고려 신규 구축	arXiv:2105.09680 (NeurIPS 2021)
HAE-RAE Bench	한국 문화·상식·어휘	6개 과제 / 4개 영역(어휘·역사·일반상식·독해)	arXiv:2309.02706 (LREC-COLING 2024)
LogicKor	다중턴 추론·생성 품질	42개 다중턴 프롬프트, 6개 범주, LLM-as-judge	MT-Bench 한국어 적응판

2-1. 왜 '번역이 아닌' 점이 중요한가

KMMLU와 KLUE, HAE-RAE Bench가 공통적으로 강조하는 차별점은 영어 벤치마크의 번역·재구현이 아니라 한국어 원본에서 구축했다는 것입니다. HAE-RAE Bench 논문(arXiv:2309.02706)은 기존 다국어 벤치마크가 역번역(back translation)에 의존해 "문화적·언어적 고유성을 포착하지 못한다"고 지적합니다. 번역 평가셋은 영어로 학습된 능력이 한국어로 '전이'되는지를 잴 뿐, 한국어 고유 능력을 분리해 측정하지 못합니다.

2-2. 공개 벤치마크의 역할과 한계

공개 벤치마크는 베이스라인으로 훌륭합니다. 모델 후보를 1차로 걸러내고, 일반적인 한국어 능력 수준을 가늠하는 데 씁니다. 하지만 두 가지 한계가 있습니다.

• 당신의 작업과 분포가 다르다. KMMLU의 객관식 전문지식은 당신의 고객센터 요약 작업과 거의 무관할 수 있습니다.
• 오염 위험이 누적된다. 공개된 지 오래된 셋일수록 모델 학습 데이터에 섞여 들어갔을(test-set leakage) 가능성이 커집니다(8장 참고).

그래서 공개 셋은 출발점이고, 결정은 내 도메인 평가셋에서 나야 합니다.

영어 평가 방법론을 그대로 한국어에 적용하면 조용히 틀린 결론에 도달합니다. 한국어 특수성에서 비롯된 세 가지 함정을 먼저 알아야 평가셋과 지표를 올바르게 설계할 수 있습니다.

3-1. 토큰화 함정 — 같은 문장, 다른 비용·맥락창

한국어는 교착어이고 한글은 음절 문자라, BPE 기반 토크나이저에서 fertility(단어/문자당 토큰 수)가 모델마다 크게 다릅니다. 같은 한국어 문장이라도 토크나이저에 따라 토큰 수가 1.5~2.3배까지 벌어진다는 보고가 있습니다(예: 형태소 인지 토큰화 연구 arXiv:2311.03928). 이것이 평가에 미치는 영향은 세 갈래입니다.

• 비용 비교가 왜곡된다. 토큰당 단가가 같아도, 토큰을 더 잘게 쪼개는 모델은 같은 작업에 더 많은 토큰 → 더 비싼 실측 비용이 듭니다.
• 맥락창이 실질적으로 다르다. "128K 토큰"이 한국어로는 더 적은 글자 수를 의미합니다.
• few-shot 예시가 잘릴 수 있다. 동일한 프롬프트가 어떤 모델에선 맥락창을 초과합니다.

→ 대응: 비용·지연은 토큰 수가 아니라 "같은 한국어 입력 글자 수" 기준으로 비교하고, 실제 토큰 수를 함께 로깅하세요.

3-2. 종결어미·격식 함정 — 채점 기준이 흔들린다

한국어는 종결어미(-습니다/-어요/-다)와 높임법이 의미가 아니라 격식·관계를 바꿉니다. 자동 채점에서 두 가지 문제가 생깁니다.

• 문자열 정확도(exact match)가 정답을 오답 처리. "환불됩니다"와 "환불돼요"는 같은 정답인데 string match로는 불일치입니다.
• LLM-as-judge가 격식을 품질로 착각. 심사 모델이 격식체를 무조건 "더 전문적"으로 가산하면, 반말로 정확히 답한 응답이 부당하게 감점됩니다.

→ 대응: 정규화(공백·종결어미·문장부호) 후 비교하거나, 객관식·정답 후보 추출로 평가를 구조화하세요. LLM-as-judge에는 "격식이 아니라 사실 정확성·완결성을 채점하라"고 명시하세요.

3-3. 문화상식 함정 — 영어 능력 전이로 가려진다

"세종대왕", "4대 보험", "전세"처럼 한국 고유 개념은 영어 학습 능력의 전이로 풀리지 않습니다. HAE-RAE Bench가 비한국어 모델에 더 어려운 이유가 바로 이것입니다. 당신의 도메인이 한국 제도·문화·규정에 의존한다면, 영어권 벤치마크 상위 모델이 당신 작업에서 무너질 수 있습니다.

→ 대응: 도메인 평가셋에 한국 고유 맥락 항목(법령·제도·지역·관용표현)을 의도적으로 포함해, 전이로 가려진 약점을 노출시키세요.

직접 측정의 심장은 당신의 작업을 대표하는 평가셋입니다. 거창할 필요 없습니다. 잘 설계된 50~200개 항목이 출처 불명의 1만 개보다 낫습니다.

4-1. 작업 유형부터 정의한다

평가셋 형식은 작업 유형이 결정합니다.

작업 유형	정답 형태	권장 지표
분류·라우팅	라벨(고정 집합)	정확도·F1
추출(엔티티·필드)	구조화 값	정확도·필드별 일치율
요약·생성	자유 텍스트	LLM-as-judge + 루브릭
QA·RAG	정답 + 근거	정확도 + 근거 충실성
다중턴 대화	대화 흐름	LLM-as-judge(다중턴)

4-2. 황금셋(gold set) 구축 체크리스트

• 실제 분포에서 표집. 인위적 예제 말고, 실제 로그·티켓·문서에서 샘플링합니다(개인정보는 익명화).
• 난이도·범주 균형. 쉬운 항목만 있으면 모델 간 변별이 안 됩니다. 엣지케이스·실패 사례를 의도적으로 포함합니다.
• 사람이 정답을 합의. 정답(reference)은 2인 이상 교차 검수. 합의 안 되는 항목은 "모호"로 분리합니다.
• 한국 고유 맥락 포함. 3장 3-3의 함정을 노출시킬 항목을 의도적으로 넣습니다.
• 메타데이터를 단다. 각 항목에 범주·난이도·출처·작성일을 붙여, 나중에 슬라이스별 분석이 가능하게 합니다.

4-3. 평가셋 데이터 포맷 예시 (JSONL)

재현성을 위해 평가셋은 사람이 읽고 diff 가능한 텍스트 포맷(JSONL)으로 버전 관리합니다.

{"id": "cs-001", "category": "refund", "difficulty": "hard", "locale_specific": true, "input": "전세 보증금 반환 지연 시 임차인이 받을 수 있는 지연이자는 어떻게 되나요?", "reference": "주택임대차보호법에 따른 법정 지연이자(연 5%, 소송 시 12%)를 적용...", "rubric": ["지연이자율 언급", "근거 법령 정확", "소송 단계 구분"]}
{"id": "cs-002", "category": "classification", "difficulty": "easy", "locale_specific": false, "input": "환불하고 싶어요", "reference": "REFUND_REQUEST"}

locale_specific 플래그를 두면, "한국 고유 항목에서만 점수가 떨어지는 모델"을 슬라이스 분석으로 즉시 잡아낼 수 있습니다.

단일 지표로 모델을 고르면 반드시 후회합니다. 품질·속도·비용은 트레이드오프이고, 작업마다 비중이 다릅니다.

5-1. 정확도 계열 (객관식·분류·추출)

정답이 고정된 작업은 자동 채점이 가능합니다. 핵심은 공정한 정답 추출입니다.

• 객관식 채점 방식 두 가지: ① 로그 우도(log-likelihood) — 각 선택지의 확률을 비교(EleutherAI lm-evaluation-harness 기본 방식). ② 생성 후 파싱 — 모델이 텍스트로 답하게 한 뒤 정답 후보를 추출. 두 방식은 점수가 다르게 나옵니다. 어느 쪽을 썼는지 반드시 기록하세요.
• 한국어 정규화 필수: 비교 전 공백·문장부호·종결어미를 정규화(3장 3-2).

5-2. LLM-as-judge (요약·생성·다중턴)

자유 텍스트는 사람 채점이 이상적이지만 느리고 비쌉니다. LLM-as-judge는 강력한 모델을 심사자로 써서 응답 품질을 점수화합니다(LogicKor가 쓰는 방식, HRET 툴킷도 partial-match LLM-judge 지원). 단, 다음을 지켜야 신뢰할 수 있습니다.

• 루브릭을 명시한다. "잘 썼나"가 아니라 "① 사실 정확 ② 질문 충족 ③ 근거 제시"처럼 항목별 채점.
• 위치·길이 편향을 통제한다. 심사 모델은 먼저 나온 답·긴 답을 선호하는 경향이 있습니다. A/B 순서를 뒤집어 두 번 채점하거나, 점수제(절대평가)를 씁니다.
• 심사자를 피심사자와 분리한다. 같은 계열 모델을 심사자로 쓰면 자기 출력에 가산 편향이 생길 수 있습니다.
• 사람 채점과 상관을 검증한다. 소규모 표본(예: 30개)을 사람이 채점해, judge 점수와의 일치율(예: Cohen's kappa)을 1회 확인하세요.

5-3. 지연·비용 (운영 현실)

품질이 비슷하면 지연과 비용이 결정합니다.

지표	측정 방법	주의
TTFT(첫 토큰 지연)	요청→첫 토큰 시간	스트리밍 UX의 체감 속도
총 지연	요청→완료 시간	출력 길이에 비례
처리량(tok/s)	출력 토큰 / 시간	동시 요청 수에 민감
실측 비용	(입력+출력 토큰) × 단가	한국어 토큰 수로 환산(3장 3-1)

지연·비용은 한 번이 아니라 여러 번(예: p50·p95) 측정하세요. 동시 부하·시간대에 따라 크게 변합니다.

측정이 재현 가능하려면 결과뿐 아니라 조건 전체를 고정·기록해야 합니다. 아래는 최소 골격입니다(의사 코드에 가깝게 단순화).

6-1. 무엇을 고정하는가

• 모델 버전: claude-..., gpt-...처럼 정확한 스냅샷 ID. "latest"는 금지(언제든 바뀜).
• 샘플링: 온도·top_p·max_tokens. 채점 일관성을 위해 보통 temperature=0.
• 프롬프트: 템플릿·시스템 메시지·few-shot 예시와 그 순서.
• 평가셋: 파일 + 내용 해시(SHA-256).
• 환경: 라이브러리 버전·실행 일시.

6-2. 실행 스크립트 골격 (Python)

import json, hashlib, time, datetime

RUN_CONFIG = {
    "model": "claude-sonnet-4-5-20250929",  # 정확한 스냅샷 ID 고정
    "temperature": 0.0,
    "max_tokens": 1024,
    "prompt_template_version": "v3",
    "eval_set": "data/eval_cs_v1.jsonl",
}

def sha256_file(path: str) -> str:
    h = hashlib.sha256()
    with open(path, "rb") as f:
        h.update(f.read())
    return h.hexdigest()

def normalize_ko(s: str) -> str:
    # 한국어 채점용 정규화: 공백/문장부호 제거 (종결어미는 작업에 따라 추가)
    import re
    return re.sub(r"[\s\.,!?·…\"'()]", "", s.strip())

def run_eval(client):
    items = [json.loads(l) for l in open(RUN_CONFIG["eval_set"], encoding="utf-8")]
    results, correct = [], 0
    for it in items:
        t0 = time.time()
        out = client.generate(it["input"], **{k: RUN_CONFIG[k]
             for k in ("model", "temperature", "max_tokens")})
        latency = time.time() - t0
        # 분류·추출 작업: 정규화 후 정확 일치
        is_correct = normalize_ko(out.text) == normalize_ko(it["reference"])
        correct += int(is_correct)
        results.append({
            "id": it["id"], "category": it.get("category"),
            "locale_specific": it.get("locale_specific", False),
            "output": out.text, "correct": is_correct,
            "latency_s": round(latency, 3),
            "input_tokens": out.usage.input_tokens,
            "output_tokens": out.usage.output_tokens,
        })
    return {
        "config": RUN_CONFIG,
        "eval_set_sha256": sha256_file(RUN_CONFIG["eval_set"]),
        "run_at": datetime.datetime.utcnow().isoformat() + "Z",
        "n": len(items),
        "accuracy": round(correct / len(items), 4),
        "results": results,  # 원본 출력 전부 보존 → 사후 재채점 가능
    }

6-3. 결과 저장과 슬라이스 분석

전체 결과(results)에 모델 원본 출력을 그대로 보존하는 게 핵심입니다. 채점 기준이 바뀌어도 모델을 다시 호출하지 않고 재채점할 수 있기 때문입니다. 저장 후 category·locale_specific별로 정확도를 쪼개 보면, 평균에 가려진 약점(예: "한국 고유 항목에서만 -12%p")이 드러납니다.

6-4. 공개 벤치마크는 표준 하네스를 쓴다

KMMLU·KoBEST 같은 공개 셋은 직접 채점기를 짜기보다 EleutherAI lm-evaluation-harness나 HAERAE Evaluation Toolkit(HRET) 같은 표준 도구를 쓰세요. 채점 방식(로그 우도 vs 생성)이 표준화돼 있어, 같은 조건이면 남의 결과와도 비교 가능합니다. 직접 짠 채점기는 미묘한 정답 추출 차이로 점수가 달라지기 쉽습니다.

점수가 나왔다고 끝이 아닙니다. 다음을 점검하지 않으면 존재하지 않는 차이를 진짜로 착각합니다.

7-1. 표본이 너무 작다

50개 평가셋에서 정확도 84% vs 86%는 사실상 같은 성능일 수 있습니다. 항목 수가 적으면 신뢰구간이 넓습니다. 모델 간 차이가 신뢰구간 안에 들어오면, 그 차이로 의사결정하지 마세요. 최소한 부트스트랩으로 신뢰구간을 잡거나, 차이가 작으면 "유의미하지 않음"으로 결론 내세요.

7-2. 벤치마크 오염 (test-set leakage)

공개된 지 오래된 벤치마크는 모델 학습 데이터에 섞였을 수 있어, 점수가 실력이 아니라 암기를 반영할 수 있습니다. 간단한 점검:

• 질문 문구를 살짝 바꾸거나(패러프레이즈) 선택지 순서를 섞었을 때 점수가 급락하면 오염을 의심합니다(permutation·n-gram 계열 점검).
• 가장 확실한 방어는 모델이 본 적 없는 당신만의 비공개 평가셋입니다(4장).

7-3. 프롬프트·few-shot 민감도

같은 모델도 시스템 프롬프트 한 줄, few-shot 예시 순서, 지시문 어투에 따라 점수가 흔들립니다. 모델을 비교할 때는 모든 후보에 동일한 프롬프트를 쓰되, 프롬프트 자체의 민감도도 한 번은 측정해 두세요(예: 3가지 프롬프트 변형의 점수 분산).

7-4. LLM-as-judge 자체의 편향

5장 5-2에서 다룬 위치·길이·자기선호 편향에 더해, 심사 모델이 바뀌면 순위가 뒤집힐 수 있습니다. judge 모델·버전·프롬프트도 RUN_CONFIG에 고정·기록하세요.

7-5. 정답 자체가 틀렸을 때

자동 채점에서 점수가 이상하게 낮으면, 모델이 아니라 당신의 reference가 틀렸을 가능성을 먼저 의심하세요. 오답 처리된 항목을 사람이 직접 읽어보면, 정답 라벨 오류·모호 항목이 상당수 발견되곤 합니다.

지금까지의 내용을 한 번에 실행 가능한 순서로 묶었습니다.

8-1. 8단계 측정 워크플로

1. 작업 정의 — 무엇을 평가하나(분류/추출/요약/QA/대화)와 성공 기준.
2. 공개 벤치마크 1차 스크리닝 — KMMLU·KoBEST·KLUE·LogicKor를 표준 하네스로 돌려 후보 압축.
3. 도메인 황금셋 구축 — 실제 데이터에서 50~200개, 교차 검수, locale_specific 태깅.
4. 지표 확정 — 정확도 / LLM-judge(루브릭) / 지연·비용 비중 결정.
5. 조건 고정 — 모델 스냅샷·온도·프롬프트·평가셋 해시를 RUN_CONFIG에.
6. 측정 실행 — 원본 출력 전부 보존, 지연·토큰 함께 로깅.
7. 오류 통제 — 표본 크기·오염·프롬프트 민감도·judge 편향·정답 오류 점검.
8. 슬라이스 분석·결정 — 범주·고유성별로 쪼개 보고, 트레이드오프로 결정.

8-2. 재현성 체크리스트

• 모델 스냅샷 ID를 적었는가 ("latest" 금지)
• 온도·top_p·max_tokens를 고정·기록했는가
• 프롬프트 템플릿과 few-shot 순서를 버전 관리하는가
• 평가셋 **내용 해시(SHA-256)**를 저장했는가
• 모델 원본 출력을 보존해 재채점이 가능한가
• 한국어 정규화(공백·종결어미·문장부호)를 적용했는가
• 채점 방식(로그 우도 vs 생성 파싱)을 명시했는가
• LLM-judge면 judge 모델·루브릭·순서 편향 통제를 기록했는가
• 비용을 한국어 토큰 수 기준으로 환산했는가
• 표본 크기 대비 차이가 유의미한지 확인했는가

이 체크리스트를 통과한 측정만이 "이 모델을 우리 서비스에 쓰겠다"는 의사결정의 근거가 됩니다.

8-3. 자주 묻는 질문

공개 리더보드 점수만 보고 모델을 고르면 안 되나요?

1차 스크리닝으로는 유용하지만 최종 결정 근거로는 부족합니다. 리더보드의 작업 분포가 당신의 실제 작업과 다르고, 오래된 공개 셋은 오염 위험이 있습니다. 당신의 비공개 도메인 평가셋에서 한 번 더 검증해야 합니다.

평가셋은 몇 개나 만들어야 하나요?

잘 설계된 50~200개로 시작하세요. 핵심은 개수가 아니라 실제 분포 대표성·난이도 균형·정답 신뢰성입니다. 모델 간 차이가 표본의 신뢰구간보다 작으면 항목을 늘리거나 "차이 없음"으로 판단합니다.

LLM-as-judge 점수를 그대로 믿어도 되나요?

조건부로요. 루브릭을 명시하고, 위치·길이 편향을 통제하고, 심사자를 피심사자와 분리하고, 소규모 표본으로 사람 채점과의 상관을 한 번 검증한 경우에만 신뢰하세요. judge 모델이 바뀌면 순위가 뒤집힐 수 있습니다.

왜 한국어는 토큰 수로 비용을 비교하면 안 되나요?

토크나이저마다 한국어 fertility(문자당 토큰 수)가 1.5~2.3배까지 달라, 같은 문장도 모델별 토큰 수가 다릅니다. 토큰당 단가가 같아도 실측 비용은 크게 차이 납니다. 따라서 같은 한국어 입력 글자 수를 기준으로 실측 토큰·비용을 함께 비교해야 공정합니다.

측정 결과가 재현이 안 됩니다. 무엇부터 봐야 하나요?

순서대로 의심하세요: ① 모델 ID가 "latest"여서 바뀌었는가 ② 온도가 0이 아니어서 출력이 변하는가 ③ 프롬프트·few-shot 순서가 달라졌는가 ④ 평가셋 파일이 바뀌었는가(해시 비교). 이 네 가지를 고정하면 대부분 재현됩니다.

공개 리더보드 점수만 보고 한국어 LLM을 골라도 되나요?

1차 후보 압축에는 유용하지만 최종 결정 근거로는 부족합니다. 리더보드의 작업 분포가 당신의 실제 작업과 다르고, 오래된 공개 벤치마크는 학습 데이터 오염 위험이 있습니다. 모델이 본 적 없는 비공개 도메인 평가셋에서 다시 검증한 뒤 결정하세요.

KMMLU, KoBEST, KLUE, HAE-RAE Bench의 차이는 무엇인가요?

KMMLU(arXiv:2402.11548)는 한국 원시험에서 수집한 45개 과목 전문지식 객관식, KoBEST(arXiv:2204.04541)는 5개 한국어 NLU 과제, KLUE(arXiv:2105.09680)는 저작권을 고려해 신규 구축한 8개 NLU 과제, HAE-RAE Bench(arXiv:2309.02706)는 한국 문화·역사·어휘 등 고유 지식을 재는 셋입니다. 공통점은 영어 벤치마크의 번역이 아니라 한국어 원본 기반이라는 점입니다.

왜 한국어는 토큰 수로 비용을 비교하면 안 되나요?

토크나이저마다 한국어 fertility(문자당 토큰 수)가 1.5~2.3배까지 달라, 같은 문장도 모델별 토큰 수가 크게 차이 납니다. 토큰당 단가가 같아도 실측 비용이 달라지므로, 같은 한국어 입력 글자 수를 기준으로 실측 토큰과 비용을 함께 비교해야 공정합니다.

LLM-as-judge 채점 점수를 신뢰해도 되나요?

조건부로 신뢰할 수 있습니다. 채점 루브릭을 명시하고, 위치·길이·자기선호 편향을 통제하고(순서 뒤집어 재채점 등), 심사 모델을 피심사 모델과 분리하고, 소규모 표본으로 사람 채점과의 상관을 한 번 검증한 경우에만 의사결정에 쓰세요. 심사 모델이 바뀌면 순위가 뒤집힐 수 있습니다.

벤치마크 오염(test-set leakage)은 어떻게 확인하나요?

질문을 패러프레이즈하거나 선택지 순서를 섞었을 때 점수가 급락하면 오염을 의심합니다(permutation·n-gram 계열 점검). 가장 확실한 방어는 모델이 학습 시 본 적 없는 비공개 평가셋을 직접 만드는 것입니다.

도메인 평가셋은 몇 개나 만들어야 하나요?

잘 설계된 50~200개로 시작하면 충분합니다. 개수보다 중요한 건 실제 데이터 분포의 대표성, 난이도 균형, 교차 검수된 정답 신뢰성입니다. 모델 간 차이가 표본의 신뢰구간보다 작으면 항목을 늘리거나 차이 없음으로 판단하세요.

객관식 채점에서 로그 우도와 생성 파싱 중 무엇을 써야 하나요?

정답은 작업에 따라 다르지만, 둘은 점수가 다르게 나오므로 어느 방식을 썼는지 반드시 기록해야 합니다. 로그 우도(선택지 확률 비교)는 EleutherAI lm-evaluation-harness의 기본이고 재현이 깔끔합니다. 실제 서비스가 텍스트 생성이라면 생성 후 정답을 파싱하는 방식이 실사용에 더 가깝습니다.

측정 결과가 매번 달라 재현이 안 됩니다. 무엇을 고정해야 하나요?

① 모델 스냅샷 ID("latest" 금지) ② 온도·top_p·max_tokens ③ 프롬프트 템플릿과 few-shot 예시 순서 ④ 평가셋 파일(내용 해시 비교) — 이 네 가지를 고정하면 대부분 재현됩니다. 결과에는 모델 원본 출력을 보존해 채점 기준이 바뀌어도 재호출 없이 재채점할 수 있게 하세요.