짧은 답변

LLM은 정확성을 기준으로 유닛 테스트(unit-test)를 할 수 없습니다. 왜냐하면 동일한 입력이라도 다음 실행 시 다른 경로를 거칠 수 있기 때문입니다. 평가(Evals)는 확률적 시스템(probabilistic systems)을 위한 테스트 스위트입니다. 즉, 시스템이 단 한 번 정확한 문자열을 반환했는지가 아니라, 여러 번의 실행에 걸쳐 수용 가능한 결과에 도달했는지를 점수를 매겨 반복적으로 확인하는 것입니다.

핵심 도구 모음은 간단합니다. 입력 대 예상 결과(input-to-expected-outcome) 사례로 구성된 큐레이션된 골든 세트(golden set), CI에서의 해당 세트 오프라인 실행 및 라이브 트래픽에 대한 온라인 체크, 그리고 각 작업에 적합한 스코어러(scorer) — 단언(assertion), 골든 세트(golden set), LLM-as-judge, 또는 인간 검토(human review) — 가 필요합니다. 이를 CI에 회귀 게이트(regression gate)로 연결하여 품질 저하가 발생하면 빌드가 실패하도록 구성하십시오.

유닛 테스트가 아닌 평가(evals)를 사용하는 이유

유닛 테스트는 결정론적 함수(deterministic function)가 하나의 정확한 값을 반환하는지 단언(assert)합니다. 하지만 LLM은 결정론적이지 않습니다. 온도(temperature), 모델 업데이트, 그리고 모델 자체의 샘플링(sampling)으로 인해 동일한 프롬프트라도 실행할 때마다 다르고 표현 방식이 다른 출력을 생성할 수 있습니다. 단 하나의 예상 문자열에 고정하는 방식은 테스트를 불안정하게(flakes) 만들거나 아무런 유용한 정보도 제공하지 못하게 만듭니다.

평가는 그 단언을 다른 질문으로 대체합니다: 시스템이 여러 번의 실행에 걸쳐 수용 가능한 비율로 수용 가능한 결과에 도달했는가? 이는 테스트를 측정 문제(measurement problem)로 재정의합니다. 타겟에 대해 출력을 점수화하고, 세트에 대해 집계하며, 시간에 따른 점수를 추적합니다. 이는 합격/불합격 방식의 유닛 테스트보다는 에러 예산(error budget)을 가진 SLO(Service Level Objective)에 더 가깝습니다. 또한 이는 프롬프트를 변경하거나 모델을 교체할 때 눈을 감고 작업하지 않도록 해주는 규율입니다.

골든 세트 (Golden sets)

골든 세트(golden set, 레퍼런스 또는 eval 세트라고도 함)는 입력 대 예상 결과 사례를 큐레이션하여 모아놓은 컬렉션입니다. 각 행은 시스템이 실제로 보게 될 입력과 당신이 정답 또는 수용 가능하다고 간주하는 결과를 쌍으로 묶습니다. 결과는 때로는 정확한 답변일 수도 있고, 더 빈번하게는 루브릭(rubric)이나 답변이 충족해야 하는 속성(properties)의 집합일 수도 있습니다.

가장 가치 있는 골든 셋 (golden sets)은 사전에 만들어지는 것이 아니라, 실제 실패 사례로부터 성장합니다. 모든 프로덕션 버그, 놓친 엣지 케이스 (edge case), 그리고 "모델이 여기서 이상한 행동을 했다"라고 느끼는 모든 순간이 새로운 행 (row)이 됩니다. 시간이 흐름에 따라 이 셋은 실제 트래픽의 형태와 가장 까다로운 케이스들을 인코딩하게 되며, 따라서 평가 (eval) 실행을 통과했다는 것은 구체적인 의미를 갖게 됩니다. 이 셋을 버전 관리 (version-controlled)하고, 단순히 규모를 키우기보다 대표성을 갖도록 유지하며, 장애 발생 후 케이스를 추가하는 것을 수정 과정의 일부로 취급하십시오.

오프라인 (Offline) vs 온라인 (online)

오프라인 평가 (Offline evaluation)는 무언가를 배포하기 전, 주로 CI (지속적 통합) 환경에서 고정된 골든 셋 (golden set)을 대상으로 시스템을 실행합니다. 이는 반복 가능하고, 변경 사항에 따라 비교가 가능하며, 모든 커밋 (commit)마다 실행하기에 비용이 저렴합니다. 한계점은 당신이 포함시키기로 생각한 케이스들만 측정한다는 것입니다.

온라인 평가 (Online evaluation)는 출시 후 실제 트래픽 및 실제 결과에 대해 동작을 측정합니다. 즉, 프로덕션 실행을 샘플링하고, 점수를 매기며, 작업 완료, 사용자 수정 또는 다운스트림 (downstream) 성공과 같은 실제 신호를 관찰합니다. 이는 분포 변화 (distribution shift)와 골든 셋이 전혀 예상하지 못했던 입력값들을 포착합니다. 오프라인 평가는 변경 사항을 배포해도 안전한지 알려주며, 온라인 평가는 그것이 실제로 작동했는지를 알려줍니다. 당신은 두 가지 모두가 필요하며, 온라인에서의 실패는 새로운 오프라인 케이스를 만드는 가장 좋은 원천입니다.

LLM-as-judge (및 그 함정)

주관적인 품질 — 이 요약이 충실한가, 이 톤이 적절한가, 답변이 질문에 답했는가 — 에 대해서는 대조할 정확한 문자열이 없는 경우가 많습니다. LLM-as-judge는 모델을 사용하여 루브릭 (rubric)에 따라 출력을 채점합니다. 이는 모든 행에 사람이 필요했을 채점 과정을 확장 가능하게(scale) 만들어 주며, 많은 작업에서 인간의 판단과 충분히 높은 상관관계를 보여 유용하게 쓰입니다.

하지만 이것 또한 실제 실패 모드 (failure modes)를 가진 구성 요소이며, 당신은 판사 (judge) 자체를 평가해야 하는 대상으로 취급해야 합니다:

• 위치 편향 (Position bias): 쌍체 비교 (pairwise comparisons) 시, 판사 (judge)가 품질과 관계없이 먼저 보는 답변을 선호할 수 있습니다.
• 장황함 편향 (Verbosity bias): 더 길고 자신감 있게 들리는 답변은 실제로는 더 낫지 않더라도 더 높은 점수를 받는 경향이 있습니다.
• 불일치성 (Inconsistency): 판사 자체도 확률적 (probabilistic)이기 때문에, 동일한 쌍이라도 실행할 때마다 점수가 다르게 매겨질 수 있습니다.
• 게임 가능성 (Gameable): 출력이 사용자가 아닌 판사를 만족시키도록 최적화될 수 있으며, 자기 평가 모델 (self-judging model)은 자신의 스타일을 치켜세울 수 있습니다.

완화 방법은 판사를 신뢰하기 전에 사람이 라벨링한 데이터 샘플을 통해 판사를 검증하고, 판사의 점수가 해당 라벨과 얼마나 잘 일치하는지 측정하며, 판사 모델이나 평가 기준 (rubric)을 변경할 때 그 일치성을 다시 확인하는 것입니다. 검증되지 않은 판사는 측정이 아니라 점수가 매겨지지 않은 가정일 뿐입니다.

회귀 방지 게이트로서의 평가 (Evals as regression gates)

평가 스위트 (eval suite)는 자동으로 실행될 때 그 가치를 발휘합니다. 오프라인 골든 세트 (golden-set) 실행을 CI (지속적 통합)에 연결하여, 품질 저하가 임계값 아래로 떨어지면 실패하는 유닛 테스트 (unit test)나 커버리지 (coverage) 수치 하락이 머지 (merge)를 막는 것과 동일한 방식으로 빌드를 실패하게 만드세요. 이를 통해 "이 프롬프트 변경이 더 나을 것 같다"라는 추측을 측정 가능한 주장으로 바꿀 수 있으며, 누군가 프롬프트를 수정하거나, 모델을 업그레이드하거나, 하네스 (harness)를 리팩터링할 때 발생하는 조용한 품질 저하가 배포되는 것을 방지할 수 있습니다.

가장 중요한 원칙 하나는 다음과 같습니다: 단순히 문자열 유사도 (string similarity)가 아니라, 작업의 성공이나 결과의 정확성을 반영하는 지표를 선택하십시오. 두 답변은 표현 방식이 완전히 다를 수 있지만 둘 다 정답일 수 있습니다. 완전 일치 (exact-match) 점수는 정답을 실패로 처리할 수 있고, 유사도 점수는 유창하지만 틀린 답변을 통과시킬 수 있습니다. 실제로 중요하게 생각하는 것, 즉 "제대로 일을 수행했는가"를 점수화하고 게이트가 이를 강제하도록 하십시오.

평가 접근 방식 선택하기

규모를 키우기 전에 평가(Evals)를 구축하십시오
사용 규모를 확장한 후가 아니라, 확장하기 전에 평가 하네스 (eval harness)를 구축하십시오. 평가 체계가 없다면 프롬프트 변경, 모델 업그레이드, 또는 새로운 도구의 도입이 상황을 개선했는지 악화시켰는지 알 방법이 없습니다. 즉, 단순히 느낌 (vibes)에 의존하여 배포하게 됩니다. "품질이 올라갔는가 내려갔는가, 그리고 얼마나 변했는가"라는 질문에 답할 수 있는 팀만이 안전하게 반복 (iterate)할 수 있습니다. 그렇지 못한 팀은 결국 운영 환경 (production)에서 퇴보하게 되고 그 이유조차 알지 못할 것입니다. 또한 평가 설계 능력은 해당 인원이 실제로 LLM을 사용하여 제품을 출시해 본 경험이 있는지를 보여주는 가장 강력한 신호이기도 합니다.

실제 사례: aiarch.dev에서 코치를 평가하는 방법

이 페이지에서는 평가를 CI (지속적 통합)에 연결하고, 인간의 라벨 (human labels)을 기준으로 판사 (judge)를 검증할 것을 권장했습니다. 하지만 저희는 그 두 가지 모두를 수행하지 않습니다. 다음은 aiarch.dev에서 코치 변경을 실제로 제한하는 방식이며, 여기에는 앞서 언급한 조언에 미치지 못하는 부분도 포함되어 있습니다.

두 단계로 나뉩니다. npm run eval은 모킹된 모델 (mocked model)을 대상으로 골든 세트 (golden set)를 점수화하며, 이는 저렴하고 로컬에서 실행되며 코치가 변경될 때마다 수행됩니다. 그 위에는 라이브 게이트 (live gate)가 있습니다: 실제 호출을 수행하고, 이곳에서 중요한 행동들(정답을 알려주는 대신 힌트를 점진적으로 줄이기, 오개념 명명하기, 두 번의 정체된 턴 이후 단계 높이기)에 대해 점수를 매깁니다. 코치 프롬프트나 배포가 이루어지기 전에는 반드시 80%를 통과해야 합니다. 이 과정은 최대 3번 실행되어 그중 최댓값을 취하며, 2번의 실행이 통과되면 조기에 종료됩니다. 점수 산출 방식이 확률적이지 않은 경우에도 코치는 확률적(probabilistic)으로 동작하므로, 단일 샘플에서 얻은 판결은 노이즈에 불과합니다.

CI는 없습니다. 저장소에 .github/workflows/가 없으며, git push를 한다고 해서 아무것도 배포되지 않습니다. 배포는 의도적인 wrangler deploy를 통해 이루어지며, 사람이 먼저 실행하는 명령으로서 게이트 (gates)가 존재합니다. 이는 설계상의 선택이 아니라 공백 (gap)입니다. 또한 오프라인 단계가 빠르게 유지되어야 하는 이유이기도 합니다. 설명하는 게이트보다 직접 실행하는 게이트가 더 강력하기 때문입니다.

두 번째 격차는 더욱 뚜렷합니다. 라이브 게이트(live gate)는 루브릭(rubric)에 따라 모든 답변을 점수화합니다. 어떤 모델도 이를 읽지 않습니다.

점수 산정은 결정론적 단언(deterministic assertions)입니다. 코치의 텍스트에 대한 11개의 정규 표현식(regex), 해당 턴에서 실제로 어떤 도구(tool)를 호출했는지 확인하는 4개의 체크(레슨 컨텍스트를 가져왔는지, 학습자가 시도조차 하지 않은 항목을 채점했는지 등), 2개의 최소 길이 제한, 그리고 stop_reason 확인이 포함됩니다. 테스트 하네스(harness)는 자체 주석을 통해 이러한 방식의 한계를 솔직하게 밝히고 있습니다. 체크 항목 중 2개는 "필요하지만 충분하지는 않은 증거(necessary-but-not-sufficient evidence)"로 주석이 달려 있으며, 실제 튜터링 품질을 확인하기 위해서는 인간 또는 LLM 심사위원(LLM judge)이 필요하다고 명시하고 있습니다. 즉, 80%는 인간의 레이블(human labels)에 맞춰 조정된 것이 아니라 우리가 선택한 임계값(threshold)에 따라 관찰 가능한 준수 여부를 측정합니다. 이는 회귀(regression)를 잡아냅니다. 하지만 품질을 보증하지는 않으며, 이를 보증하는 것처럼 해석하는 것이 바로 앞 섹션에서 경고한 실수입니다. 이것이 릴리스 파이프라인(release pipeline)에 어떻게 끼워 맞춰지는지는 eval-gate 패턴을 참조하십시오.

출처 및 근거 (Sources & provenance)

• 강의 자료: aiArch Track B (eval design) — 골든 세트(golden sets), 오프라인 vs 온라인, 심사위원(judges), 그리고 CI 게이트(CI gates).
• 평가 설계 가이드: 도구 사용 에이전트 구축 및 평가에 관한 Anthropic의 문서.
• Anthropic — 평가(evals 설계 및 실행)에 관한 플랫폼 문서.
• LLM-as-judge의 한계(위치 편향(position bias), 장황함 편향(verbosity bias), 일관성 부족, 게임 가능성(gameability), 그리고 인간의 레이블에 대한 검증 필요성)는 평가 문헌에 널리 기록되어 있습니다.

본 내용은 개념적인 개요입니다. 특정 벤치마크나 수치를 주장하지 않으며, API 형태는 변경될 수 있으므로 구현 전 현재 제공업체의 문서를 확인하십시오. 수정 사항: hello@aiarch.dev.

원문은 aiarch.dev/llm-evaluation-guide에 게시되었으며, 해당 위치에서 최신 상태로 유지됩니다.

에세이 대신 스켈레톤 (skeleton) 코드가 필요하신가요? aiarch-templates에는 src/lib/ 인터페이스 (seams), 임계값 기반 게이트가 적용된 평가 스텁 (eval stub), 그리고 비용 모델 (cost-model) 스켈레톤이 포함되어 있습니다. 이 템플릿은 의도적으로 비어 있습니다. 구조를 잡아두었으니 구현은 직접 작성하시면 됩니다. Apache-2.0 라이선스.