오픈 LLM 자체 평가 워크플로우

오픈 LLM 자체 평가 워크플로우

오픈 LLM을 비교하는 자료는 2026년 현재 2차 출처(블로그·비교 사이트)가 압도적으로 많고, 출처마다 순위가 다르다. 본 문서는 벤치마크 자체를 부정하는 것이 아니라, **"어떤 절차로 검증해야 실무에서 안전하게 선택할 수 있는가"**에 집중한다.

벤치마크가 자주 충돌하는 이유

• 벤치마크 오염(contamination): 학습 데이터에 벤치마크 문제가 포함되어 점수가 부풀려질 수 있다. 검증되지 않은 모델은 의심해야 한다.
• vendor-reported 수치: 회사 자체 평가이며, prompt·temperature·few-shot 등 비공식 재현 환경이 많다.
• 평가 하네스 차이: lm-eval-harness, OpenCompass, HELM 등 평가 프레임워크마다 점수 격차가 발생한다.
• 시점 차이: 같은 모델의 fine-tune/quantization 버전이 동시에 유통되므로 카드 수치가 "어떤 버전"인지 확인해야 한다.
• 체크리스트:
  • 카드에 평가 일자가 명시돼 있는가?
  • 평가 framework가 명시돼 있는가?
  • prompt / decoding 설정이 명시돼 있는가?
  • few-shot / CoT 사용 여부가 명시돼 있는가?

실무 평가 워크플로우 (3단계)

① 1차 스크리닝 (대상 510개 → 23개)

1. Hugging Face Open LLM Leaderboard (https://huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard) 에서 후보 모델 5~10개를 추린다.
2. Artificial Analysis (https://artificialanalysis.ai/) 에서 가격·속도·품질 매트릭스로 1차 압축.
3. 각 모델의 공식 model card에서 벤치마크 일자·평가 환경을 기록한다.

② 2차 자체 평가 (2~3개 → 1개)

자신의 업무 데이터를 모은다.

데이터 구성	권장 규모	예시
골든셋(정답 있음)	50~200건	도메인 QA, 분류, 요약 정답
실사용 로그(옵션)	1,000건+	사람 라벨·자동 메트릭 혼합
안전성 케이스	20~50건	환각·민감 정보·도메인 위반 시나리오

평가 프레임워크:

• lm-evaluation-harness (EleutherAI): 표준 LLM 평가 도구. https://github.com/EleutherAI/lm-evaluation-harness
• OpenCompass: 중국계 모델 다수 포함 시 유리. https://github.com/open-compass/opencompass
• HELM (Stanford): 리더보드급 종합 평가. https://crfm.stanford.edu/helm/

핵심은 동일 prompt·동일 few-shot·동일 temperature로 모든 후보를 돌리는 것이다.

③ 3차 운영 검증 (최종 1개)

• A/B 또는 shadow 평가: 실제 트래픽의 일부에 후보 모델을 흘려보내고 기존 모델과 비교
• 지표: 처리량(latency), 비용(원/요청), 품질(사람 평가·자동 메트릭), 안전성(차단 비율)
• 예시 지표: GPT-4급 70점 → open LLM 65점이면 acceptable일 수 있지만, 도메인 정확도 50% 차이는 대체 불가

자주 사용되는 평가 메트릭

메트릭	무엇을 측정	한계
MMLU	광범위한 학문 지식	contamination 빈번
GSM8K	초등학교 수학 추론	짧은 정답만 평가
HumanEval / MBPP	코드 생성	단순 함수 위주
IFEval	instruction following	자동 채점 한계
MT-Bench	다회 대화 품질	LLM-as-judge 편향
LiveCodeBench	시점 변동 코드 벤치마크	contamination 방지 설계
SWE-bench	실제 GitHub issue 해결	평가 비용 큼

자주 하는 실수

• ❌ "벤치마크 1위 모델을 그대로 채택" → 벤치마크는 일반화 능력의 proxy일 뿐이다. 자신의 데이터가 우선이다.
• ❌ "vendor 점수만 인용" → vendor가 발표하지 않은 평가는 보수적으로 가정. 서드파티 리더보드 2개 이상 교차 확인.
• ❌ "vLLM / TGI 점수를 그대로 API 점수로 가정" → 서빙 스택에 따라 throughput/latency가 크게 다르다. 실측이 우선.
• ❌ "fine-tune 안 한 base 모델이 가장 좋다" → 도메인 fine-tune을 거치면 base 벤치마크 순위가 뒤바뀔 수 있다. fine-tune 후 재평가가 정답.

자체 평가 체크리스트 (출판 전)

• 3개 이상의 후보 모델을 동일 환경에서 비교했는가?
• 골든셋 정답을 사람이 검증했는가?
• 비용·latency·품질 3축을 모두 기록했는가?
• 안전성 실패 사례(환각·민감 정보)를 별도로 집계했는가?
• fine-tune 적용 전·후 점수를 모두 기록했는가?
• 평가 결과를 사내 위키에 공유하고 재현 가능한가?

참고 자료

• Hugging Face Open LLM Leaderboard: https://huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard
• Artificial Analysis: https://artificialanalysis.ai/
• lm-evaluation-harness: https://github.com/EleutherAI/lm-evaluation-harness
• OpenCompass: https://github.com/open-compass/opencompass
• HELM (Stanford CRFM): https://crfm.stanford.edu/helm/
• LiveCodeBench: https://livecodebench.github.io/

상위 문서: ← 오픈 소스 LLM 모델 출처: [주제 가이드 — 오픈 LLM 자체 평가 워크플로우] (자체 조사·작성 2026-10-02) — Hugging Face Leaderboard, lm-evaluation-harness, Artificial Analysis 공식 자료 기준 공급사: 자체 작성 + EleutherAI·Stanford CRFM·OpenCompass 공식 공개 자료

변경 이력

날짜	변경
2026-10-02	초안 작성 — 벤치마크 충돌 원인, 3단계 자체 평가 워크플로우, 체크리스트