스탠포드 CME295: 트랜스포머와 LLM | Lecture 8 - LLM 평가 (2025 가을 학기)
이 강의는 LLM 시스템의 성능을 측정하는 것이 개선을 위한 필수 조건임을 강조하며, 전통적인 인간 평가와 규칙 기반 지표(BLEU, ROUGE 등)의 한계를 넘어 LLM-as-a-Judge(심사위원으로서의 LLM) 방식과 그 편향성을 상세히 다룹니다. 또한, 에이전트 워크플로우에서 발생할 수 있는 다양한 실패 유형들을 도구 예측, 실행, 결과 종합 단계별로 분석하고 이를 해결하는 실질적인 팁을 제공합니다. 마지막으로 MMLU(지식), AIME(수학 추론), SWE-bench(코딩), HarmBench(안전), Tau-bench(에이전트) 등 2025년 현재 널리 쓰이는 주요 벤치마크들을 소개하며 올바른 모델 선택 기준을 제시합니다.
1. 평가의 중요성과 인간 평가의 한계 📊
강의의 시작과 함께 Afshine 교수는 이번 학기 중 가장 중요한 수업 중 하나로 평가(Evaluation)를 꼽습니다. 모델의 성능을 측정할 수 없다면 무엇을 개선해야 할지도 알 수 없기 때문입니다. 지난주에 배운 RAG(검색 증강 생성)나 도구 사용(Tool Use), 에이전트(Agent) 기술들도 결국 얼마나 잘 작동하는지 평가해야만 의미가 있습니다.
여기서 '평가'란 시스템의 속도나 가격보다는 출력 품질(Output Quality), 즉 모델이 얼마나 좋은 답변을 내놓는지를 정량화하는 것에 집중합니다. 가장 이상적인 방법은 모든 답변을 사람이 직접 읽고 평가하는 것이겠지만, 이는 비용과 시간이 너무 많이 듭니다. 게다가 사람의 평가는 주관적일 수 있다는 문제가 있습니다.
"제 LLM에게 '생일 선물로 뭘 살까?'라고 물었을 때, '테디베어는 언제나 사랑스러운 선물이죠'라고 답했다고 칩시다. 어떤 평가자는 '좋은 조언이네'라고 할 수 있지만, 다른 평가자는 '아니, 어떤 테디베어인지(곰? 기린?) 구체적이지 않아서 별로야'라고 할 수도 있죠. 평가 자체가 주관적일 수 있다는 겁니다."
따라서 평가자들 간의 의견이 얼마나 일치하는지를 측정하는 평가자 간 일치도(Inter-rater agreement) 지표가 중요해집니다. 단순히 일치하는 비율만 보면 우연히 일치할 확률을 무시하게 되므로, 이를 보정한 Cohen's Kappa 같은 지표를 사용하여 평가 가이드라인이 얼마나 명확한지 점검해야 합니다.
2. 규칙 기반 지표(Rule-based Metrics)와 한계
매번 사람에게 평가를 맡길 수 없으므로, 미리 정해둔 모범 답안(Reference)과 모델의 출력을 비교하는 자동화된 지표들이 사용됩니다. 번역이나 요약 태스크에서 주로 쓰였던 방법들입니다.
- METEOR: 단어의 순서와 유의어를 고려하여 번역 품질을 평가합니다.
- BLEU: n-gram 정밀도(precision)에 기반하며, 너무 짧은 문장에 페널티를 줍니다.
- ROUGE: 주로 요약 태스크에서 사용되며, 재현율(recall)에 중점을 둡니다.
하지만 이런 지표들은 문체적 변형(Stylistic Variation)을 제대로 반영하지 못한다는 치명적인 단점이 있습니다. 뜻은 같지만 표현이 다를 경우 점수가 낮게 나올 수 있기 때문입니다.
"예를 들어 '폭신한 테디베어는 아이들이 잘 때 위안을 줍니다'라는 문장은 '부드러운 곰 인형은 아이들이 잠들 때 안전함을 느끼게 도와줍니다'라고 다르게 표현될 수 있습니다. 의미는 같지만, 우리가 본 규칙 기반 지표들은 이 경우 점수를 아주 낮게 줄 겁니다."
3. LLM-as-a-Judge: LLM을 심사위원으로 활용하기 ⚖️
이러한 한계를 극복하기 위해 등장한 것이 바로 LLM-as-a-Judge입니다. 이는 방대한 데이터로 사전 학습되고 인간의 선호도에 맞춰 튜닝된 LLM 자체를 평가 도구로 사용하는 방법입니다. 프롬프트, 모델의 응답, 그리고 평가 기준을 입력으로 주면, 평가자 모델은 점수(Score)와 그 점수를 준 근거(Rationale)를 함께 출력합니다.
"LLM은 텍스트를 이해합니다. 그래서 왜 그런 점수를 주었는지 설명할 수 있죠. 이 '설명 가능성'이 이전의 규칙 기반 방식과 가장 큰 차이점입니다. 이전 방식들은 그냥 숫자만 던져줬거든요."
이때 중요한 팁은 모델이 점수보다 근거(Rationale)를 먼저 출력하게 하는 것입니다. 이는 2025년 트렌드인 추론 모델(Reasoning Models)이 답변 전에 생각의 사슬(Chain of Thought)을 먼저 생성하는 것과 같은 원리입니다. 또한, 평가 결과의 형식을 보장하기 위해 구조화된 출력(Structured Output) 기능을 사용하여 JSON 형태로 결과를 받는 것이 좋습니다.
⚠️ LLM 평가의 3가지 편향(Biases)
LLM을 평가자로 쓸 때 주의해야 할 편향들이 있습니다.
- 위치 편향(Position Bias): 모델이 첫 번째로 제시된 답변을 더 선호하는 경향이 있습니다. 순서를 바꿔서(A vs B, B vs A) 두 번 물어보고 다수결을 따르는 식으로 해결합니다.
- 서술 편향(Verbosity Bias): 내용보다 단순히 길고 자세한 답변을 선호하는 경향입니다. 가이드라인에 명시하거나 길이에 대한 페널티를 주어야 합니다.
- 자기 고양 편향(Self-enhancement Bias): 모델이 자신이 생성한 답변을 더 선호하는 현상입니다.
"모델이 그런 문장을 생성했다는 건, 확률적으로 그게 가장 좋은 답변이라고 생각했다는 뜻이겠죠. 그래서 평가할 때도 자기와 비슷한 스타일을 선호하게 됩니다. 이를 피하려면 생성 모델과 평가 모델을 다른 것을 쓰는 게 좋습니다."
4. 사실성(Factuality) 평가 방법 🔍
사실 여부를 판단하는 것은 단순히 좋다/나쁘다로 나누기 어려운 미묘한 문제입니다. 텍스트 안에 여러 사실이 섞여 있고, 그중 일부만 틀릴 수도 있기 때문입니다.
"'테디베어는 1920년대에 처음 만들어졌으며, 시오도어 루즈벨트 대통령이 사냥 여행에서 잡힌 곰을 자랑스럽게 쏘고 싶어 했던 일화에서 유래했다.' 이 문장의 사실성을 어떻게 평가할까요? 사실 여기엔 오류가 두 개 있습니다. 1920년대가 아니라 1900년대이고, 대통령은 곰을 쏘는 걸 거부했지 자랑스럽게 쏘고 싶어 하지 않았습니다."
이런 경우, 최신 기법은 다음과 같은 단계를 따릅니다:
- 긴 텍스트를 원자적인 사실(Atomic Facts) 단위로 쪼갭니다.
- 각 사실에 대해 RAG나 검색을 통해 진위 여부를 확인합니다.
- 각 사실의 중요도에 따라 가중치를 두어 최종 점수를 집계합니다.
5. 에이전트(Agent) 평가와 실패 유형 🤖
이어지는 세션에서 Shervine 교수는 에이전트 시스템의 평가에 대해 설명합니다. 에이전트는 도구 예측(Prediction) → 도구 실행(Execution) → 결과 추론(Inference)의 루프를 돕니다. 이 과정에서 발생할 수 있는 실패 유형을 체계적으로 분류하고 해결해야 합니다.
🛠️ 도구 예측 단계의 실패
- 펀트(Punt): 도구를 써야 하는데 안 쓰고 "모르겠습니다"라고 답하는 경우입니다. 도구 라우터(Router)의 재현율(Recall)을 높여야 합니다.
"질문에 답을 하지 않고 그냥 실패해버리는 걸 어시스턴트 용어로는 '펀트(punt)'라고 합니다. '죄송합니다, 어디서 찾을지 모르겠네요'라고 하는 식이죠."
- 도구 환각(Hallucination): 존재하지 않는 함수 이름을 지어내서 호출하는 경우입니다. 모델이 약하거나, 사용할 수 있는 함수에 대한 설명이 부족할 때 발생합니다.
- 잘못된 도구 선택: 곰을 찾아야 하는데 그냥 메시지 보내기 도구를 쓰는 경우입니다. 도구 간의 사용 범위를 명확히 정의해야 합니다.
- 잘못된 인자(Arguments): 도구는 맞게 골랐는데 입력값(예: 위치 좌표)이 틀린 경우입니다.
💻 도구 실행 및 결과 처리 단계의 실패
- 오류 반환: 도구 코드 자체의 버그입니다.
- 빈 응답(No Response): 실행은 했는데 아무런 리턴값이 없는 경우입니다. 모델은 작업이 성공했는지 실패했는지 알 수 없게 됩니다.
"곰을 못 찾았을 때
None을 반환하는 것보다 빈 JSON{}을 반환하는 게 훨씬 낫습니다. 빈 JSON은 '찾긴 했는데 결과가 없다'는 뜻이지만,None은 아무 정보도 주지 않으니까요." - 정보 과부하: 도구 실행 결과가 너무 길어서 모델이 핵심 정보를 찾지 못하는 경우입니다.
6. 벤치마크(Benchmarks)의 세계 🏆
마지막으로 모델의 성능을 비교하기 위한 다양한 벤치마크들이 소개됩니다. 2025년 기준, 각 영역별로 대표적인 벤치마크는 다음과 같습니다.
📚 지식 (Knowledge)
- MMLU (Massive Multitask Language Understanding): 법률, 의학 등 다양한 주제의 지식을 4지 선다형 문제로 평가합니다. 객관식이라 평가가 명확합니다.
🧠 추론 (Reasoning)
- AIME: 고등학생 수학 올림피아드 문제입니다. 복잡한 추론 과정을 거쳐 정수 답을 내야 하므로 찍어서 맞히기 어렵습니다.
- PIQA: 물리적 상식에 관한 추론입니다.
"'카펫에 잃어버린 물건을 어떻게 찾을까?' 정답은 헤어네트를 씌운 청소기를 쓰는 겁니다. 그냥 청소기를 쓰면 물건이 빨려 들어가 버리겠죠. 이런 일상적인 물리 법칙을 이해하는지 묻는 겁니다."
💻 코딩 (Coding)
- SWE-bench: 실제 GitHub 이슈를 해결하는 능력을 평가합니다. 단순히 코드를 짜는 게 아니라, 수정 전에는 실패하고 수정 후에는 통과하는 테스트 케이스를 기반으로 평가하므로 매우 실질적입니다.
🛡️ 안전 (Safety)
- HarmBench: 저작권 침해나 유해한 행동 유도 등을 평가합니다. 모델이 나쁜 행동을 하려다 실패했더라도, 시도 자체를 위험한 것으로 간주합니다.
🤖 에이전트 (Agents)
- Tau-bench: 항공권 변경이나 쇼핑 같은 시나리오를 시뮬레이션합니다. 여기서 중요한 지표는 Pass^k (Pass hat k)입니다.
"Pass@k는 k번 중 한 번이라도 성공할 확률이지만, 에이전트의 신뢰성을 위해서는 k번 시도해서 k번 모두 성공할 확률인 Pass^k가 중요합니다."
결론 및 마무리
강의를 마치며 Shervine은 며칠 전 발표된 Gemini의 기술 보고서를 예로 들며, 앞서 배운 벤치마크들이 실제 현업에서 어떻게 모델의 성능을 자랑하는 데 쓰이는지 보여줍니다. 하지만 벤치마크 점수가 높다고 무조건 내 서비스에 좋은 것은 아닙니다.
- 파레토 프런티어(Pareto Frontier): 성능뿐만 아니라 가격, 속도 등을 종합적으로 고려하여 자신의 상황에 맞는 모델을 골라야 합니다.
- 데이터 오염(Data Contamination): 모델이 훈련 데이터에서 벤치마크 문제를 미리 봤을 수도 있다는 점을 항상 경계해야 합니다.
- 굿하트의 법칙(Goodhart's Law): 특정 측정 지표가 목표가 되는 순간, 그 지표는 더 이상 좋은 측정 수단이 아니게 됩니다.
결국 벤치마크는 참고용일 뿐, 여러분의 실제 유스케이스에 맞춰 직접 테스트해보는 것이 가장 중요하다는 조언과 함께 강의는 마무리됩니다. 🦃