LLM 성능은 어떻게 평가할까? 대표 평가 툴·리더보드·테스트 방식 + 최신 순위(스냅샷)

LLM 성능 ‘등수’는 어떻게 매길까? (평가 툴·사이트·테스트 방식 + 최신 순위 스냅샷)

 

핵심 요약

• LLM 순위는 “절대 등수”가 아니라 어떤 테스트(벤치마크/투표/도메인)를 쓰느냐에 따라 달라집니다.
• 대표 방식은 ① 사용자 투표 기반(예: LMArena/Chatbot Arena) ② 표준 벤치마크 기반(예: Open LLM Leaderboard/HELM) ③ 제품·서비스 품질 평가(DeepEval/Ragas/LangSmith 등)입니다.
• 아래에 평가 사이트/툴 목록, 테스트 설계 방법, 그리고 리더보드 스냅샷 순위(예시)를 한 번에 정리했습니다.

※ 참고: 사용자가 제공한 한겨레 링크는 작성 시점에 자동 열람에서 오류가 발생하여, 본문 직접 인용은 하지 않고 “LLM 등수/리더보드 논점”에 맞춰 공개 자료 중심으로 정리했습니다.

 

LLM 성능 비교

 

I. LLM ‘순위’가 하나로 정해지기 어려운 이유

LLM은 “지식(정답)”뿐 아니라 “추론”, “글쓰기”, “코딩”, “안전성”, “속도/비용”, “사용자 만족도” 등 다양한 능력이 섞여 있습니다. 그래서 어떤 평가를 쓰느냐에 따라 결과가 달라집니다.

 

예: 사용자 선호(투표) 기반

• 두 모델 답변을 나란히 보여주고 더 좋은 답변을 선택
• 승률/레이팅(Elo류)로 순위화
• 장점: “실사용 감” 반영 · 단점: 질문 구성/표본 편향 영향

예: 벤치마크(문제집) 기반

• 고정된 문제 세트에서 정답률/점수 계산
• 장점: 재현성·비교 용이 · 단점: 데이터 오염(이미 학습) 가능

 

II. LLM 평가 사이트·리더보드 “한 번에 보기”

아래는 많이 쓰이는 공개 리더보드(웹)들입니다.

2-1. 사용자 투표(크라우드) 기반 리더보드

• LMArena (Chatbot Arena) — 사용자들이 모델 답변을 비교 투표해 레이팅으로 순위를 매김.
  바로가기: https://lmarena.ai/leaderboard

2-2. 벤치마크 기반 리더보드(주로 오픈소스 모델)

• Hugging Face Open LLM Leaderboard — 오픈소스 LLM을 표준 벤치마크로 비교(백엔드는 lm-eval-harness를 활용하는 것으로 널리 알려짐).
  바로가기: https://huggingface.co/open-llm-leaderboard
• Stanford HELM — 다양한 시나리오/메트릭(역량·안전성 등)을 포괄적으로 평가하려는 프레임워크/리더보드.
  바로가기: https://crfm.stanford.edu/helm/

2-3. 상용 모델 포함 “모델 비교” 성격의 리더보드/모음

• Vellum LLM Leaderboard — 여러 공개 벤치마크/정보를 모아 최신 모델 비교(과제별, 비용/컨텍스트 등).
  바로가기: https://www.vellum.ai/llm-leaderboard

 

III. 개발자가 쓰는 LLM 평가 “툴/프레임워크” 목록

리더보드가 “남이 측정해준 점수”라면, 아래 도구들은 내 서비스/내 데이터로 모델을 직접 테스트하고 품질(정확성·환각·근거충실도·일관성 등)을 수치화하는 데 많이 씁니다.

3-1. 벤치마크 실행 도구(모델/테스크를 정해 자동 채점)

• lm-evaluation-harness (EleutherAI) — 다양한 태스크(벤치마크)를 통합 실행하는 대표 도구.
  GitHub: https://github.com/EleutherAI/lm-evaluation-harness

3-2. LLM 애플리케이션 품질 평가(정답이 없을 때도 “좋은 답”을 평가)

• DeepEval — LLM 출력 품질을 테스트/평가하는 프레임워크(“pytest처럼” 쓰는 컨셉으로 소개되는 경우가 많음).
• Ragas — RAG(검색증강생성) 품질 평가에 특화(faithfulness, relevancy 등).
  Docs: https://docs.ragas.io/en/stable/
• MLflow Evaluate(LLM 평가) — 평가를 파이프라인/실험관리 흐름에 붙이는 용도로 자주 언급됨.

3-3. 관측·로그·A/B 테스트(프롬프트/모델 변경 시 회귀 탐지)

• LangSmith — 체인/에이전트 실행 추적 + 데이터셋 평가 + 실험 관리(주로 LangChain 생태계에서 많이 사용).
• Langfuse — 오픈소스 관측/평가/프롬프트 관리(대화·에이전트 트레이스 중심).

실무 팁

• “모델 자체 성능”과 “내 서비스 성능”은 다를 수 있어요. (내 도메인 데이터/프롬프트/툴체인/RAG 구성 영향)
• 따라서 리더보드로 후보를 좁히고 → 내 데이터로 회귀 테스트하는 흐름이 가장 안전합니다.

 

IV. LLM 테스트는 “어떤 방식”으로 진행될까?

4-1. 사용자 투표 기반(Arena 류): “선호”를 레이팅으로

1. 동일한 질문에 대해 모델 A/B 답변을 블라인드로 제시
2. 사용자가 더 나은 답변을 선택
3. 대규모 투표를 집계해 승률/레이팅(예: Elo 유사)으로 순위화

장점: 실제 사용자가 “더 낫다”고 느끼는 답을 반영. 단점: 질문 분포, 사용자 집단, UI/프롬프트 정책에 따라 결과가 달라질 수 있음.

4-2. 벤치마크 기반: “문제집 + 채점”

1. 목표 능력 정의(추론/코딩/수학/독해/안전성 등)
2. 해당 능력을 대표하는 데이터셋(벤치마크) 선정
3. 동일 조건(프롬프트, few-shot 수, 온도 등)으로 일괄 실행
4. 정답 비교(또는 자동 채점기)로 점수 산출
5. 태스크별 점수/가중합으로 종합 점수화

4-3. 내 서비스(제품) 기준 평가: “정답이 없을 때” 어떻게 점수화?

고객지원 챗봇, 사내 문서 Q&A, 쇼핑 추천 등은 정답이 애매하거나 여러 정답이 가능합니다. 이때는 아래 방식을 조합합니다.

• 휴먼 평가: 샘플을 뽑아 기준표(정확/친절/근거/금지사항 준수 등)로 채점
• LLM-as-a-judge: “평가용 모델”이 출력 품질을 기준에 맞춰 채점(주의: 편향/기준 누수 가능)
• RAG 지표: 근거 문서와의 일치(faithfulness), 문서 회수의 적합성(recall/precision) 등을 별도 계산
• 운영 지표: 해결률, 재질문율, CS 전환율, 처리시간, 비용(토큰), 응답 지연 등

// (개념 예시) 평가 루프의 전형적인 흐름
1) 테스트셋 준비: (질문, 기대요건, 금지요건, 근거문서)
2) 후보 모델/프롬프트로 일괄 실행
3) 자동평가(정답/규칙/근거충실도) + 휴먼 샘플링
4) 점수 하락(회귀) 구간 탐지 → 프롬프트/검색/가드레일 수정
5) 재실행 → 배포

 

V. LLM 성능별 “순위” 예시: LMArena 최신 스냅샷(텍스트)

아래는 LMArena 리더보드(Overview 페이지의 Text 탭)에 표시된 “상위권” 스냅샷 예시입니다. (리더보드는 수시로 바뀌므로, 이 글은 작성일 기준 공개 페이지에 보이는 순위를 옮겨 적은 형태입니다.)

 

텍스트(Text) 상위 10 (스냅샷)

 

순위	모델	Score(레이팅)	Votes
1	gemini-3-pro	1490	21,938
2	gemini-3-flash	1480	7,020
3	grok-4.1-thinking	1477	22,618
4	claude-opus-4-5-20251101-thinking-32k	1470	14,992
5	claude-opus-4-5-20251101	1467	15,914
6	grok-4.1	1466	24,682
7	gemini-3-flash (thinking-minimal)	1464	5,631
8	gpt-5.1-high	1458	19,416
9	gemini-2.5-pro	1451	82,231
10	claude-sonnet-4-5-20250929-thinking-32k	1450	33,533

* 위 수치는 LMArena 공개 페이지의 “Overview → Text” 영역에 표시된 값(페이지에 ‘5 days ago’로 표기된 최신 갱신) 기준입니다. 최신 순위는 아래 링크에서 확인하세요: LMArena Leaderboard

오픈소스 모델 순위는 어디서 보나?

오픈소스 LLM만 놓고 비교하려면 Hugging Face Open LLM Leaderboard가 가장 많이 참조됩니다. 다만 “오픈소스” 범위(가중치 공개/라이선스), 평가 태스크, 프롬프트 정책에 따라 상위 모델이 달라질 수 있으니 내 목적(예: 코딩, 수학, 장문요약)에 맞는 필터/태스크를 기준으로 보는 것을 권장합니다.

 

VI. 내 목적에 맞게 “평가를 설계”하는 방법

① 모델 선정(1차)

• 리더보드로 후보 3~5개 압축
• 비용/지연/컨텍스트(토큰) 제약 확인
• 규제/보안(데이터 저장 정책) 확인

② 내 서비스 평가(2차)

• 실제 유저 질문 100~500개 샘플링
• 정답/기대요건/금지요건 정의
• 회귀 테스트(버전업 시 품질 하락 방지)

추천 체크리스트

• 정확성: 중요한 사실/수치/정책을 틀리지 않는가?
• 근거 충실도(특히 RAG): 답이 근거 문서에 기반하는가?
• 환각(Hallucination): 모르면 모른다고 말하는가?
• 지시 준수: 포맷/금지요건/브랜드 톤을 지키는가?
• 운영성: 비용, 지연, 실패율, 모니터링 가능성

 

LLM 성능, 어떻게 평가하는 것일까? (feat. lm-eval-harness)

 

VII. 자주 하는 오해 3가지

1. “1등 모델이면 내 서비스도 무조건 최고” → 내 데이터/프롬프트/RAG/가드레일에 따라 결과가 달라집니다.
2. “벤치마크 점수 = 진짜 지능” → 데이터 오염/출제 편향/태스크 편중이 있을 수 있어요.
3. “순위 하나만 보면 된다” → 최소한 “목표 과제(추론/코딩/글쓰기/안전)”별로 따로 보세요.