LLM 평가 방법론: 자사 사용 사례를 위한 신뢰할 수 있는 평가 구축하기
LLM 평가 방법론
모델을 바꾸고, 프롬프트를 고치고, 버전을 올렸을 때 — 좋아졌는지 나빠졌는지 어떻게 판단합니까? 공개 벤치마크 점수는 테스트 데이터가 자사 실시나리오와 크게 다르므로 거의 쓸모가 없습니다. 이 글에서는 자사 업무를 위한 평가 체계(평가 세트, 채점 방식, A/B 비교, 회귀 테스트)를 설명합니다. 이것이 있으면 모델 변경이 감각이 아니라 근거로 판단할 수 있습니다.
30초 요약
평가의 핵심은 점수 하나를 고르는 것이 아니라 고정된 평가 세트를 만드는 것입니다. 실업무에서 30~100개 대표 입력을 샘플링 → '좋은 답' 기준 정의 → 변경 전후 같은 문제 실행 → 사람 또는 LLM-as-judge로 채점 → 결과 비교. 평가 세트 자체를 코드처럼 버전 관리하세요.
공개 점수가 부족한 이유
MMLU나 MTEB 같은 공개 벤치마크에는 가치가 있지만 3가지 본질적 한계가 있습니다.
- 데이터 분포가 다르다: 범용 지식이나 학술 문제를 재지만 자사는 내부 문서·특정 형식·업계 용어일 수 있습니다.
- 자사 제약이 없다: 출력 형식, 톤, 컴플라이언스 요구, 거부 경계는 측정되지 않습니다.
- 최적화 가능하다: 학습 시 유사 문제를 본 가능성이 있어 높은 점수가 일반화를 보장하지 않습니다.
공개 점수의 올바른 용도는 후보를 좁히는 것입니다. 최종 선택은 반드시 자사 평가 세트로 해야 합니다.
평가 세트는 자산이며 일회용 스크립트가 아닙니다
좋은 평가 세트는 반복 사용합니다. 모델 교체, 프롬프트 수정, 엔진 업그레이드, 온도 변경 — 모두 같은 문제로 실행합니다. 사업의 진화에 따라 새 문제를 추가하고 코드처럼 버전 관리합니다. 반나절 투자로 이후 모든 결정이 빨라집니다.
1단계: 평가 세트 구축
1. 실업무에서 샘플링. 프로덕션 로그나 이해관계자 요구에서 30~100개 대표 입력을 고르고 다음을 포함합니다.
| 카테고리 | 비율 권장 | 예 |
|---|---|---|
| 고빈도 전형 작업 | 50-60% | 가장 흔한 일상 질문 |
| 엣지/어려운 케이스 | 20-30% | 긴 입력, 모호함, 다중 제약 |
| 거부/경계 | 10-20% | 답하면 안 되는 것, 정보 부족 |
2. 각 항목에 '좋은 답' 기준 정의. 유일한 정답을 고정하는 것이 아니라(많은 작업에 정답은 없습니다) 체크포인트를 나열합니다: 사실이 맞는가, 요점을 포함하는가, 형식이 요구사항에 맞는가(JSON 필드, 길이, 톤), 절대 만들어내면 안 되는 것을 만들어내지 않았는가.
3. 구조화된 파일로 저장. id, 입력, 체크포인트, 카테고리. JSONL이나 CSV 모두 좋고 스크립트가 안정적으로 읽을 수 있는 것이 중요합니다.
{
"id": "case-001",
"input": "이 제품 설명을 이미지 생성 프롬프트로 다시 작성하세요",
"checkpoints": ["주체와 스타일 묘사 포함", "단일 문단 출력", "원문에 없는 숫자 추가하지 않음"],
"category": "high_frequency"
}
2단계: 채점 방식 선택
| 방식 | 방법 | 적합한 작업 | 한계 |
|---|---|---|---|
| 사람 채점 | 체크포인트별 평가 | 품질 민감·소규모 | 느리고 비싸고 주관적 |
| LLM-as-judge | 강한 모델이 루브릭으로 채점 | 중간 규모·빠른 반복 | judge 자체 편향 |
| 자동 지표 | 정확 일치, JSON 검증, 정규식 | 구조화 출력 | 개방형 품질 못 재 |
실무에서는 조합합니다. 구조화 작업은 자동 지표로 바닥을 깔고, 개방 작업은 LLM-as-judge로 1차 스크리닝 후 judge가 어긋난 샘플을 사람이 추출 확인합니다.
LLM-as-judge의 두 가지 규율
① judge는 피평가 모델과 다른 패밀리의 강한 모델을 써 자기 선호 편향을 피합니다. ② 채점 루브릭은 파일로 고정하고 실행마다 말을 바꾸지 마세요. judge 점수는 상대 비교용이지 절대 품질 결론이 아닙니다 — 표면의 유창함에 이끌릴 수 있습니다. 사람 추출 확인은 필수 안전망입니다.
3단계: A/B 비교
두 모델·두 프롬프트를 비교할 때 도구보다 규율이 중요합니다.
- 같은 문제·같은 파라미터 고정(온도, max_tokens, 시스템 프롬프트. 피시험 변수 외 전부 동일)
- 변수는 하나만 — 모델과 프롬프트를 동시에 바꾸면 결과를 귀속할 수 없습니다
- 블라인드 채점: A/B 출력 순서를 섞어 채점자에게 넘기고 위치 편향 회피
- 항목별 결과 기록, 평균만 보지 않기 — 긴 입력에서 A가 확실히 좋고 짧은 입력에서 B가 약간 좋은 경우가 흔합니다
- 분포 보기, 평균만 아니라: 평균이 가까울 때는 실패의 심각도 비교 — 심각한 환각 하나가 가벼운 스타일 차이 열 개보다 중요합니다
# 최소 A/B 골격: 같은 문제를 두 구성으로 실행해 저장
import json
cases = [json.loads(l) for l in open("eval_set.jsonl")]
results = []
for case in cases:
for variant in ["model_a", "model_b"]:
out = call_model(variant, case["input"]) # 자사 호출 래퍼
results.append({"id": case["id"], "variant": variant, "output": out})
json.dump(results, open("run_001.json", "w"), ensure_ascii=False, indent=2)
4단계: 회귀 테스트 흐름
평가를 변경 흐름에 엮습니다.
- 모델 교체/버전 업그레이드: 평가 세트 전체 실행, 전 버전 기준선과 비교
- 프롬프트 수정: 평가 세트 + 해당 프롬프트 관련 서브셋
- 엔진/양자화 등급 변경: 평가 세트 실행, 지연과 VRAM도 함께 기록
- 판정 규칙: 핵심 체크포인트는 열화 불가, 평균의 소폭 변동은 분포로 판단
회귀의 가치는 조용한 열화를 잡는 것입니다. 상류 모델 업데이트 후 에러는 안 나는데 출력 스타일이 변한다 — 고정 평가 세트만 이를 발견합니다. 클라우드 API 모델은 플랫폼 업데이트에 따라 변하므로 월 1회 회귀를 권장하고, 로컬 모델은 업그레이드 전마다 실행합니다.
평가는 일회성이 아닙니다
평가 세트는 사업과 함께 새 문제를 추가하고 옛 문제는 유지합니다. 각 실행 결과(날짜, 모델/버전, 파라미터, 점수)를 아카이브합니다. 3개월 뒤 "왜 이 모델을 골랐는지" 회고할 때 그 기록이 답입니다. 모델 버전 관리 가이드와 같은 규율을 평가에도 적용하세요.
일반적 오해
오해 1: 샘플이 많을수록 좋다. 엣지를 덮는 고품질 30개가 중복된 500개 고빈도보다 정보가 많습니다. 먼저 커버리지, 다음 양.
오해 2: 평균만 보면 된다. 평균은 분포를 숨깁니다. 심각한 오류 하나가 소폭 변동 열 개보다 중요 — 실패에 심각도 부여.
오해 3: 프롬프트와 함께 평가 세트를 고친다. 평가 세트는 자입니다. 점수를 좋아 보이게 문제를 고치는 것은 금지, 변경 시 명시적 버전 기록과 기준선 재구축.
오해 4: LLM-as-judge 결론을 진리로 다룬다. 상대 비교 도구이며 사람 추출 확인으로 교정해야 합니다. 고위험 장면에서는 필수입니다.
FAQ
평가 세트는 몇 개?
LLM-as-judge를 믿을 수 있나요?
클라우드 모델은 업데이트됩니다. 열화를 막으려면?
A/B 비교 시 주의점은?
평가 데이터와 파인튜닝 데이터는 분리해야 하나요?
가격은 어디서 보나요?
관련 글
- Qwen 모델 선택 가이드 — 패밀리 사용 구분
- RAG 지식베이스 구축 실전 — 평가가 필요한 전형 장면
- 로컬 배포 완전 플레이북 — 배포 흐름
- Qwen API 문제 해결 — 호출 디버깅
- 요금 — 클라우드 실시간 가격