전통적인 테스트는 이진적(binary)입니다. LLM 평가는 예측입니다.

모든 소프트웨어 엔지니어는 테스트 스위트가 초록색(pass)으로 변할 때의 만족감을 경험해 보았습니다.

코드를 수정합니다.

테스트를 실행합니다.

모든 것이 통과됩니다.

그 단순한 피드백 루프(feedback loop)는 우리가 수십 년 동안 소프트웨어를 구축해 온 방식을 형성해 왔습니다.

그러다 LLM은 소프트웨어 엔지니어링에서 가장 신뢰받는 피드백 루프 중 하나를 조용히 망가뜨렸습니다.

정확히 동일한 평가를 두 번 실행했는데...

...두 개의 서로 다른 결과가 나옵니다.

바뀐 것은 아무것도 없습니다.

적어도, 당신이 볼 수 있는 것은 아무것도 없습니다.

점수판의 오류

평가 점수는 측정값(measurement)처럼 보입니다.

하지만 그렇지 않습니다.

그것은 추정치(estimate)입니다.

이것이 완전히 새로운 일은 아닙니다. 성능 벤치마크(benchmarks), A/B 테스트, 분산 시스템(distributed systems)은 항상 통계적 사고를 요구해 왔습니다. LLM 평가는 단지 그 현실을 무시할 수 없게 만들 뿐입니다.

우리가 내부 LLM 평가 프레임워크를 구축했을 때, 우리는 벤치마크를 실행하고, 단일 점수(예: 84%)를 얻고, 프롬프트(prompt)를 미세 조정하여 그 점수가 변하는 것을 확인하기를 기대했습니다. 만약 점수가 81%로 떨어지면 퇴보(regression)라고 가정했고, 87%로 올라가면 개선(improvement)이라고 가정했습니다.

우리는 몇 주 동안 유령을 쫓으며 점수 하락을 해결하기 위해 프롬프트를 수정하는 데 시간을 보냈지만, 결국 다음 실행에서는 다시 점수가 반등한다는 사실을 깨달았습니다.

실수는 LLM 평가에 노이즈(noise)가 있다는 것이 아닙니다.

실수는 LLM 평가에 노이즈가 없을 것이라고 기대하는 것입니다.

평가를 테스트(testing)가 아닌 측정(measurement)으로 생각하기 시작하면, 아키텍처는 거의 스스로 설계됩니다.

실제로 프로덕션 결정을 안내할 수 있는 AI 평가 파이프라인(pipeline)을 구축하려면 다음을 깨달아야 합니다:

모든 평가 노이즈가 동일한 것은 아닙니다.

어떤 변동은 우리가 평가하고 있는 대화에서 발생합니다. 다른 변동은 평가자(evaluator) 자체에서 발생합니다.

Evaluation Noise

모든 점수 변동은 답이 되기 전에 하나의 질문입니다:

• 모델이 변했는가?
• 벤치마크 (Benchmark)가 변했는가?
• 아니면 측정 (Measurement) 방식이 변했는가?

이 세 가지를 모두 단순히 "점수가 변했다"라고 취급하는 것이 바로 평가 시스템이 신뢰성을 잃는 방식입니다.

문제 #1: 때로는 정답이 존재하지 않는다

사용자가 당신의 LLM 어시스턴트에게 단 한 단어로 답하는 상황을 가정해 봅시다:

"그만"

어시스턴트는 어떻게 해야 할까요?

• 대화 일시 중지: "오늘은 여기서 멈추겠습니다. 계속하고 싶을 때 알려주세요."
• 좌절/사과: "죄송합니다, 다른 방식으로 시도해 보겠습니다."
• 주제 전환: "알겠습니다, 이 이야기는 그만하고 다른 것을 시도해 봅시다."

추가적인 문맥 (Context) 없이는 이 모든 해석이 타당합니다. 심지어 인간 검토자(Human reviewer)들조차 최선의 응답에 대해 의견이 갈릴 것입니다. 모호함은 대화 자체에 존재합니다. 그 어떤 프롬프트 엔지니어링 (Prompt engineering)이나 모델 튜닝 (Model tuning)으로도 이를 제거할 수 없습니다.

통계학자들은 이를 **우연적 불확실성 (Aleatoric uncertainty)**이라고 부릅니다.

용어 자체는 중요하지 않습니다. 공학적 함의가 중요합니다.

만약 불확실성이 대화 속에 존재한다면, 판정자 (Judge)를 개선한다고 해서 문제가 해결되지 않습니다. 당신은 시스템의 잘못된 부분을 최적화하고 있는 것입니다. 입력값 자체가 단일한 결정론적 (Deterministic) 답변을 생성하는 데 필요한 정보가 부족하기 때문에, 디버깅이나 코딩을 통해서도 이 문제를 해결할 수 없습니다.

작업 모호성을 완화하는 방법

실무에서 작업의 모호성을 줄이는 것은 대개 다음 네 가지로 귀결됩니다:

1. 더 풍부한 대화 문맥 (Conversational context): 고정 데이터셋 (Fixtures)에 멀티턴 (Multi-turn) 이력이 포함되도록 합니다. 문맥이 모호함을 해결합니다.
2. 프로덕션 유래 고정 데이터셋 (Production-derived fixtures): 합성 테스트 케이스 (Synthetic test cases) 대신, 실제 사용 사례를 나타내는 익명화되고 정제된 프로덕션 로그를 사용하여 벤치마크를 구축합니다.
3. 명시적인 모호성 라벨 (Explicit ambiguity labels): 여러 개의 유효한 응답이 가능한 고정 데이터셋에 태그를 달아, 이들이 이진 척도 (Binary scale)로 평가되지 않도록 합니다.
4. 고정 데이터셋 품질 측정 (Measuring fixture quality): 모델의 점수에만 집중하는 대신, 고정 데이터셋의 충실도 (Fidelity)와 커버리지 (Coverage)를 추적합니다.

문제 #2: 때로는 판정자가 틀린다

이제 다른 시나리오를 가정해 봅시다.

당신은 깨끗하고 모호함이 없는 고정 장치(fixture)를 가지고 있습니다. 후보 모델(candidate model)은 명확하게 정답인 응답을 생성합니다. 이를 LLM 판정자(judge)에게 전달합니다. 판정자는 5점 만점에 4점을 부여합니다.

정확히 5분 후에 동일한 평가를 다시 실행합니다. 판정자는 5점 만점에 5점을 부여합니다.

후보 응답에는 아무런 변화가 없었지만, 점수는 변했습니다.

통계학자들은 이를 **인식론적 불확실성 (epistemic uncertainty)**이라고 부릅니다.

여기서는 반대의 상황이 발생합니다. 과업(task)은 안정적이지만, 측정(measurement)이 안정적이지 않습니다. 이는 벤치마크가 아니라 당신의 평가 인프라(evaluation infrastructure)를 개선해야 함을 의미합니다.

인식론적 노이즈(Epistemic noise)는 다음과 같은 경로를 통해 침투합니다:

• 확률적 API 동작 (Stochastic API Behavior): Temperature 0 설정에서도, 호스팅된 LLM API에 대한 반복적인 호출은 실제로는 서로 다른 출력을 생성할 수 있습니다. 이는 제공업체가 사용자에게 불투명한 구현 세부 사항을 사용할 수 있기 때문입니다.
• 루브릭의 모호성 (Rubric Ambiguity): 만약 프롬프트가 판정자에게 _"이 응답이 도움이 되는가?"_라고 묻는다면, 판정자는 매 실행마다 "도움이 된다"는 정의를 스스로 만들어내야만 합니다.
• 모델 편향 (Model Biases): LLM은 자기 선호 (self-preference, 자신의 텍스트를 선호함), 위치 편향 (position bias, 첫 번째 옵션을 선호함), 그리고 길이 편향 (length bias, 더 긴 응답을 선호함)을 보입니다.

판정자 불확실성을 완화하는 방법

실무에서 판정자의 불확실성에 대비하여 평가 프레임워크를 강화하는 것은 결국 다음과 같습니다:

1. 판정자 앙상블 (Judge ensembling): 평가 결과가 프로덕션 결정에 영향을 미친다면, 판정자 앙상블 (Judge ensembling)을 통해 견고성 (Robustness)을 실질적으로 향상할 수 있습니다. 여러 모델 (예: Claude, GPT-4, Gemini)에 걸쳐 평가를 실행하여 모델별 사각지대를 완화하십시오.
2. 판정자 간 일치도 측정 (Measuring inter-judge agreement): 판정자들이 의견이 갈리는 시점을 식별하기 위해 일치도 (Agreement rates, 예: Cohen’s Kappa)를 추적하십시오.
3. 판정자 분산 추적 (Tracking judge variance): 동일한 입력을 판정자들에게 여러 번 주기적으로 실행하여 평가 시스템의 기준 표준 편차 (Baseline standard deviation)를 계산하십시오. 만약 벤치마크가 모델 점수로 84%를 보고한다면, 가장 유용한 수치는 84%가 아닐 수 있습니다. 그것은 **84% ± 3%**일 수 있습니다.
4. 다축 점수 산정 (Multi-axis scoring): 주관적인 1~5점 척도 대신, 이진(Binary) 방식이나 고도로 구조화된 척도를 사용하여 별개의 객관적인 축 (예: 정확성 (Correctness), 안전성 (Safety), 간결성 (Conciseness))을 따라 점수를 산정하십시오.
5. 판정자 민감 피스처 플래깅 (Flagging judge-sensitive fixtures): 실행 시 비정상적으로 높은 점수 분산을 보이는 피스처 (Fixtures)를 자동으로 플래깅하여 수동 감사를 수행하십시오.

이것이 중요한 이유

이러한 구분은 평가 시스템의 아키텍처를 형성합니다. 어떤 유형의 노이즈를 다루고 있는지 모른다면, 잘못된 엔지니어링 트레이드오프 (Engineering trade-offs)를 하게 될 것입니다. 본질적으로 모호한 피스처 (Fixture)를 평가하기 위해 몇 주 동안 프롬프트를 미세 조정하는 것은 시간 낭비입니다.

불확실성을 이러한 방식으로 생각하기 시작하자, 몇 가지 아키텍처 결정이 명확해졌습니다:

• 피스처 감사 (Fixture Audits): 현실성, 커버리지 (Coverage), 다회차 대화 (Multi-turn) 표현력을 개선하여 작업의 모호성을 줄였습니다.
• 다축 점수 산정 (Multi-Axis Scoring): 모든 것을 단일 점수로 통합하는 대신 품질 차원을 분리함으로써 의견 불일치를 설명 가능하게 만들었습니다.
• 판정자 앙상블 (Judge Ensembling): 독립적인 평가자들을 비교함으로써 판정자 불확실성을 줄였습니다.
• 신뢰도 보고 (Confidence Reporting): 실제 성능 저하 (Regressions)와 예상되는 평가 분산을 구분할 수 있게 해주었습니다.
• 커버리지 지표 (Coverage Metrics): 평가 자체의 통계적 신뢰도를 전달했습니다.

점수판을 넘어

전통적인 테스트는 정확성(correctness)을 증명하는 것에 관한 것입니다.

LLM 평가(LLM evaluation)는 신뢰도(confidence)를 추정하는 것에 관한 것입니다.

이러한 차이는 모든 것을 변화시킵니다. 이는 우리가 피스처(fixtures)를 작성하고, 판정자(judges)를 설계하며, 회귀(regressions)를 해석하는 방식을 변화시킵니다. 가장 중요한 것은, 성공적인 평가 시스템이 어떤 모습이어야 하는지를 변화시킨다는 점입니다.

신뢰할 수 있는 평가란 불확실성을 제거하는 것이 아닙니다.

더 나은 엔지니어링 의사결정을 내릴 수 있을 만큼 불확실성을 충분히 이해하는 것입니다.

LLM 시스템이 더 유능해짐에 따라, 우리의 평가 시스템 또한 더욱 정교해져야 할 것입니다. 과제는 더 이상 단순히 품질을 측정하는 것이 아니라, 그 측정 자체를 얼마나 신뢰할 수 있는지를 측정하는 것입니다. 일단 이러한 변화를 받아들이고 나면, 평가는 단순한 점수판(scoreboard)이 아닌 의사결정 도구(decision-making tool)가 되기 시작합니다.