LLM 출력 평가 방법: 실제로 퇴보(Regression)를 잡아내는 평가 체계 구축하기

Originally published on prodinit.com

핵심 요약 (Key Takeaways)

대부분의 LLM 평가(Eval) 설정은 세 가지 구조적 이유로 실패합니다: 실제 운영 환경의 실패 모드(Failure modes)를 반영하지 못하는 지표 사용, 조용히 노후화된 골든 데이터셋(Golden datasets) 사용, 그리고 배포와 별개의 일정으로 평가를 실행하는 것입니다.

4계층 평가 스택 — 유닛(Unit), 참조(Reference), 루브릭(Rubric), 행동(Behavioral) — 은 서로 다른 유형의 퇴보(Regression)를 잡아냅니다. 이 네 가지를 모두 갖추지 않고 배포하는 것은 사각지대를 남기는 것과 같습니다.

판사로서의 GPT-4는 일반적인 작업에서 인간 전문가와 85%의 일치율을 보이지만 (Zheng et al., NeurIPS 2023), 전문가 영역에서는 그 일치율이 60~68%로 떨어집니다. 신뢰하기 전에 반드시 보정(Calibrate)하십시오.

2025년 2월 Amazon의 연구에 따르면, INT4 양자화(Quantization)가 Llama-3.3 70B 모델에서 39.46%의 정확도 하락을 유발했습니다. "안전한" 모델 변경으로부터 발생하는 조용한 퇴보는 실재하며 통계적으로 탐지 가능합니다 (Kübler et al., arXiv 2025).

마지막 통과 실행 대비 루브릭(Rubric) 퇴보가 2% 이상 발생하면 배포를 차단하고, 그 외의 모든 경우에는 경고를 발생시키십시오.

왜 대부분의 LLM 평가 설정이 퇴보를 놓치는가

2025년 기업의 42%가 AI 이니셔티브의 대부분을 포기했으며, 이는 2024년의 17%에서 증가한 수치입니다 (S&P Global Market Intelligence, 2025). 기본적으로는 ROI(투자 대비 수익)가 원인으로 설명됩니다. 하지만 대부분의 경우 기술적인 설명은, 시스템이 정상적으로 배포된 후 조용히 성능이 악화되었고, 고객이 발견하기 전까지는 아무도 이를 알아차리지 못했다는 것입니다.

세 가지 구조적 실패 모드(Failure modes)가 운영 중인 LLM 시스템에서 발생하는 대부분의 놓친 퇴보를 설명합니다.

실패 모드 1: 실제 운영 환경의 실패를 예측하지 못하는 대리 지표 (Proxy metrics). 팀들은 계산하기 쉽다는 이유로 BLEU 점수, 완전 일치 (Exact match), 또는 퍼플렉시티 (Perplexity)를 측정 도구로 사용합니다. 고객용 요약 모델의 경우, 검색 (Retrieval) 방식이 변경된 후 요약 내용이 미묘하게 모순되더라도 BLEU 점수는 0.74를 유지할 수 있습니다. BLEU는 토큰 중첩 (Token overlap)을 측정할 뿐, 사실적 일관성 (Factual consistency)을 측정하지 않기 때문입니다. 지표는 통과했지만, 기능은 퇴보(Regression)한 것입니다.

실패 모드 2: 조용히 부패한 골든 데이터셋 (Golden datasets). 초기 평가 단계에서 구축된 골든 데이터셋은 그 시점에 존재하던 입력값의 분포를 포착합니다. 6개월이 지나면 실제 트래픽은 새로운 문서 형식, 새로운 질의 패턴, 기존 세트가 전혀 다루지 못했던 엣지 케이스 (Edge cases) 등으로 인해 드리프트 (Drift)됩니다. 오래된 골든 데이터셋을 기준으로 평가하면, 실제로 해결하려는 문제를 더 이상 대변하지 못하는 테스트에 대해 '통과(Green)' 점수를 받게 됩니다.

실패 모드 3: 배포 시점에 실행되지 않는 평가 (Evals). 코드 배포와 별개의 일정으로 매주 실행되는 평가 스위트 (Evaluation suites)는 퇴보가 발생한 지 며칠이 지난 후에야 이를 감지합니다. 원인이 된 PR (Pull Request)은 이미 머지(Merge)되었고, 그 위에 세 개의 다른 PR이 쌓여 있을 것입니다. 당신에게 필요했던 것은 사후 보고서가 아니라 게이트 (Gate)였습니다.

4계층 평가 스택 (The Four-Layer Eval Stack)

평가 설정에서 가장 강력하게 시도할 수 있는 변화는 계층을 추가하는 것입니다. 각 계층은 서로 다른 실패 모드를 포착하며, 각 계층이 드러내는 문제에 비해 실행 비용이 저렴합니다. 어느 한 계층만 단독으로 배포하면 특정 유형의 퇴보를 놓치게 됩니다.

계층 1: 유닛 평가 (Unit Evals)

유닛 평가는 개별 능력을 독립적으로 테스트합니다. 모델이 구조화된 입력에서 날짜를 정확하게 추출하는가? 주제를 벗어난 요청을 거절하는가? 200단어 제한 지시를 따르는가? 이러한 테스트는 결정론적 (Deterministic)입니다. 즉, 정답이거나 아니거나 둘 중 하나입니다.

유닛 평가는 밀리초 단위로 실행되며, 평가를 위해 별도의 LLM 호출이 필요하지 않습니다. 또한 모델 업데이트로 인해 이전에 보유했던 능력이 깨졌을 때 정확한 신호를 제공합니다. 이는 파이프라인의 첫 번째 게이트입니다. 실패 비용이 저렴하고, 수정 비용도 저렴합니다.

Layer 2: Reference Evals (참조 평가)

Reference evals (참조 평가)는 유사도 지표 (similarity metric)를 사용하여 모델의 출력을 골드 스탠다드 (gold-standard) 정답과 비교합니다. 이 방식은 코드 생성 (code generation), 정답이 알려진 사실 기반 질의응답 (factual Q&A), 스키마 (schema)에 따른 구조화된 추출 (structured extraction)과 같이 출력이 정답 또는 정답에 근접한 형태를 가져야 하는 경우에 적합합니다.

약점: Reference evals는 출력의 다양성 (output diversity)이 높아질수록 성능이 저하됩니다. 정답을 맞혔더라도 참조 정답과 다른 단어를 사용하여 답변하는 모델은 낮은 점수를 받게 됩니다. 정답의 정의가 엄격한 경우에만 이 방식을 사용하십시오. 의역 (paraphrase)이 허용되는 개방형 생성 (open-ended generation) 작업에는 사용을 피해야 합니다.

Layer 3: Rubric Evals (LLM-as-Judge, 루브릭 평가)

Rubric evals (루브릭 평가)는 별도의 LLM에게 정의된 루브릭 (rubric)에 따라 출력을 채점하도록 요청합니다. 이는 일관성 (coherence), 유용성 (helpfulness), 또는 사실적 일관성 (factual consistency)을 대규모로 평가할 수 있는 유일한 실질적인 방법입니다. 인간의 주석 작업 (human annotation)은 지속적 배포 (continuous deployment) 속도를 따라갈 수 없기 때문입니다. Stanford의 HELM 벤치마크는 연구 규모에서 이와 유사한 루브릭 기반 접근 방식을 사용하여 42개의 실제 시나리오에 걸쳐 7가지 평가 지표를 적용합니다.

Rubric evals는 강력하지만 보정 (calibration)이 필요합니다. 문서화된 실패 모드 (failure modes)에 대해서는 아래의 LLM-as-Judge 섹션을 참조하십시오.

Layer 4: Behavioral Evals (행동 평가)

Behavioral evals (행동 평가)는 단일 출력 점수로 환원되지 않는 시스템 수준의 속성을 테스트합니다. 예를 들어, 시스템이 10회 차 대화 내내 캐릭터를 유지하는가? 사용자가 고통을 호소할 때 적절하게 대응(escalate)하는가? 검색 증강 생성 (RAG)이 실제로 검색한 소스만을 인용하는가? 등을 확인합니다.

이 방식은 엔드 투 엔드 (end-to-end) 테스트 하네스 (test harnesses) 또는 정교하게 설계된 통합 테스트 (integration tests)를 필요로 합니다. 실행 비용은 더 높지만, 다른 세 가지 레이어가 잡아낼 수 없는 유형의 퇴보 (regression)를 포착할 수 있습니다. 즉, 상호작용을 통해서만 나타나거나 특정 시스템 조건 하에서만 발생하는 실패를 잡아냅니다. 또한 실행 속도가 더 느리며, 이는 아래에서 다룰 CI 차단 정책 (CI blocking policy)에 영향을 미칩니다.

Golden Datasets: 데이터셋의 부패와 갱신 방법

골든 데이터셋 (Golden dataset)은 평가 파이프라인이 보유한 가장 가치 있는 산출물이며, 아무도 기록하지 않는 만료 날짜를 가지고 있습니다.

데이터셋은 세 가지 방식으로 부패합니다. 입력 드리프트 (Input drift): 실제 사용자 쿼리가 진화함에 따라 — 새로운 용어, 새로운 의도, 새로운 엣지 케이스(edge cases) — 골든 세트가 이를 더 이상 대변하지 못하게 됩니다. 레이블 부패 (Label rot): 정답이 변합니다. 고객 서비스 봇의 골든 데이터셋에는 더 이상 존재하지 않는 제품 기능을 참조하는 이상적인 답변이 포함되어 있을 수 있습니다. 커버리지 격차 (Coverage gaps): 초기 데이터셋은 해피 패스 (happy path)만을 포착했습니다. 실제 운영 트래픽은 결국 한 번도 표현되지 않았던 롱 테일 (long tail)을 드러냅니다.

실질적인 해결책은 두 가지 트랙의 갱신 전략입니다.

트랙 1: 정기 검토 (Scheduled review). 90일마다 실제 운영 입력값에서 층화 표본 (stratified sample)을 추출하십시오. 최소한 주요 의도 클러스터(intent cluster)당 200개의 예시를 추출하여 골든 레이블이 여전히 정확한지 수동으로 확인해야 합니다. 이상적인 답변이 변경된 행은 플래그를 표시하십시오. 더 이상 사용되지 않는 흐름(flow)에서 발생한 행은 폐기하십시오. 골든 데이터셋 유지 관리에 관한 Statsig의 연구에 따르면, 재검증되지 않은 행은 90일 후에 오래된 것(stale)으로 표시할 것을 권장합니다. 지속적인 드리프트는 데이터셋이 더 이상 현실을 반영하지 못한다는 신호입니다.

트랙 2: 실패 기반 갱신 (Failure-driven refresh). 고객이 보고한 퇴보 (regression) 현상이 접수되면, 이를 평가 스위트 (eval suite)까지 추적하십시오. 만약 실패한 케이스가 골든 세트에 없었다면, 왜 실패했는지와 올바른 출력이 무엇이었어야 하는지를 주석(annotation)과 함께 추가하십시오. 운영 환경에 도달한 퇴보 현상은 최소한 골든 데이터셋에 기여할 수 있는 요소입니다. 이 신호를 낭비하지 마십시오.

실행해 볼 만한 진단 방법이 하나 있습니다: 만약 평가 스위트의 점수가 지속적으로 90% 이상을 기록하지만 고객 지원 티켓(support tickets)은 증가하고 있다면, 데이터셋이 실제 문제 영역을 벗어나 드리프트된 것입니다. 그 90%는 무언가를 측정하고 있는 것이지만, 더 이상 올바른 것을 측정하고 있지는 않은 것입니다.

LLM-as-Judge: 작동할 때와 거짓말할 때

LLM-as-judge는 대규모의 개방형 출력(open-ended outputs)을 평가하기 위해 필수적인 도구입니다. 하지만 동시에 특정하고 문서화된 방식으로 신뢰할 수 없는 면도 있습니다. 이러한 방식들을 이해하지 못한 채 LLM-as-judge를 사용한다면, 여러분의 루브릭 평가(rubric evals)는 잘못된 확신을 줄 것입니다.

작동하는 부분. 판사(judge)로서의 GPT-4는 일반 작업 벤치마크(MT-Bench)에서 인간 전문가 평가자와 85%의 일치도를 보였으며, Chatbot Arena 평가에서는 83~87%의 일치도를 보였습니다 (Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena," NeurIPS 2023, via Eugene Yan). 전문가가 필요하지 않은 범용적인 작업의 경우, LLM-as-judge를 배포하기 전에 여러분의 특정 루브릭(rubric)에 대해 판사를 검증한다면 인간의 주석(human annotation)을 대신할 수 있는 방어 가능한 대안이 됩니다.

거짓말하는 부분.

장황함 편향 (Verbosity bias). GPT-3.5와 Claude (v1) 모두 정답 여부와 상관없이 90% 이상의 확률로 짧은 답변보다 긴 답변을 선호했습니다 (Zheng et al., NeurIPS 2023). 만약 여러분의 출력물이 길고 장황한 경향이 있다면, 장황함 편향이 있는 판사는 내용이 틀렸을 때조차 높은 점수를 줄 것입니다. 이를 완화하려면 루브릭 프롬프트에서 출력 길이를 정규화(normalising)하거나, 길이를 통제한 쌍체 평가(paired length-controlled evaluations)를 수행하십시오.

자기 선호 편향 (Self-preference bias). 판사로서의 GPT-4는 GPT-4가 생성한 출력물에 대해 10%의 승률 우위를 주었으며, Claude v1은 25%의 자기 선호 편향을 보였습니다 (Zheng et al., NeurIPS 2023). 만약 여러분의 프로덕션 모델과 판사가 동일한 모델 제품군(model family)을 공유한다면, 점수가 부풀려질 것을 예상해야 합니다. 판사로는 다른 모델 제품군을 사용하십시오.

전문 영역 성능 저하 (Expert domain degradation). LLM 판사와 인간 도메인 전문가 사이의 일치도는 영양학이나 정신 건강과 같은 분야에서는 60~68%로 떨어집니다 (ACL/EMNLP 2024, via ACM DL). 만약 헬스케어, 법률, 또는 고도로 전문화된 기술 애플리케이션을 평가하고 있다면, LLM-as-judge는 가장 중요한 루브릭 차원(rubric dimensions)에 대한 도메인 전문가의 주석을 대체할 수 없습니다.

교정 프로세스 (Calibration process). CI(지속적 통합)에 루브릭 평가를 배포하기 전에: (1) 각 점수 수준에 대해 레이블이 지정된 예시(labelled examples)와 함께 명시적인 채점 기준을 정의합니다; (2) 사람이 주석을 단(human-annotated) 50~100개의 예시에 대해 판사(judge)를 실행하고 일치도(agreement)를 측정합니다; (3) 특정 루브릭에 대한 일치도가 75% 미만이라면, 루브릭을 수정하거나 판사 모델을 변경합니다. LLM-as-a-Judge에 관한 2024년 조사는 교정 체크리스트로 유용한 포괄적인 편향 분류 체계(bias taxonomy)를 제공합니다. LLM-as-judge를 정답(ground truth)이 아니라, 여러분이 검증한 확률적 도구(probabilistic instrument)로 취급하십시오.

CI에 평가를 연결하기: 무엇을 차단하고, 무엇을 경고할 것인가

차단 정책(blocking policy) 없이 CI에서 평가를 실행하는 것은 게이트(gate)가 아닌 보고서만을 생성할 뿐입니다. CI 평가 통합의 목적은 배포 결정(shipping decision)을 내리는 것입니다. 즉, 이 차이(diff)가 퇴보 임계값(regression threshold)을 넘어서는 방식으로 동작을 변화시키는가? 를 판단하는 것입니다.

실제 운영 환경에서 작동하는 통합 패턴은 다음과 같습니다:

# eval_pipeline.py — 프레임워크에 구애받지 않는 평가 실행기(eval runner)
# main 브랜치에 대한 모든 PR에서 실행되며, BLOCK 조건이 실패하면 머지를 차단함

...

차단해야 할 항목 (What to block on). 모든 유닛 평가(unit eval) 실패. 정의된 하한선(floor) 아래로 떨어지는 참조 정확도(reference accuracy). main 브랜치의 마지막 통과 실행 대비 루브릭 점수가 2% 이상 하락하는 경우. 이러한 신호들은 신호 대 잡음비(signal-to-noise ratio)가 높습니다. 즉, 이 신호가 발생하면 측정 변동성(measurement variance)이 아닌 퇴보(regression)를 신뢰성 있게 나타냅니다.

경고해야 할 항목 (What to warn on). 행동 평가(behavioral eval)의 퇴보(모든 PR을 차단하기에는 너무 느리고 변동성이 큼), 전체 임계값을 넘지 않는 단일 차원 루브릭 하락, 그리고 SLO(서비스 수준 목표)를 초과하는 지연 시간(latency) 증가. 경고는 머지 게이트(merge gate)가 아닌 PR 리뷰 단계로 전달됩니다.

기준점 문제 (The baseline problem). 차단 임계값에는 참조점이 필요합니다. 평가 결과를 영구 저장소(persistent store)에 저장하십시오. 저장소 내의 JSON 파일도 작동하지만, 목적에 맞게 구축된 평가 추적 시스템(eval tracking system)이 더 효과적입니다. 그리고 각 실행을 main 브랜치의 마지막 통과(green) 실행과 비교하십시오. 고정된 절대값과 비교하지 마십시오. 의도적인 품질 개선과 함께 전진하는 이동 기준선(rolling baseline)과 비교하십시오.

저희의 AI Infrastructure & LLMOps 서비스는 평가 파이프라인 (eval pipelines)을 배포 워크플로우 (deployment workflows)에 직접 연결하여, 모델 업데이트, 검색 (retrieval) 변경, 프롬프트 (prompt) 수정 사항이 모두 프로덕션 (production)에 도달하기 전 동일한 게이트를 통과하도록 합니다.

놓쳐버린 퇴보 (그리고 이를 잡아냈을 평가 체계)

검색 증강 (retrieval-augmented) 임상 문서화 시스템이 테스트 단계에서는 정확한 출력을 생성하고 있었습니다. 프로덕션에서의 ROUGE-L 점수는 0.81로 안정적이었습니다. 인프라 팀은 벡터 데이터베이스 (vector database)를 업데이트하고 임베딩 코퍼스 (embeddings corpus)를 재색인 (reindexed)했습니다. 모델 가중치 (model weights)는 변경되지 않았습니다. 이 마이그레이션 (migration)은 중단 없는 (non-breaking) 작업으로 표시되었습니다.

2주 후: 의료진의 불만이 급증했습니다. 요약문들이 멀티 테넌트 (multi-tenant) 환경에서 인접한 환자 기록의 사실을 인용하기 시작했습니다. 새로운 릴리스 (release)에서 발생한 인덱스 파티셔닝 (index partitioning) 버그로 인해, 검색 (retrieval) 과정에서 인근 테넌트 파티션으로부터 더 높은 코사인 유사도 (higher-cosine-similarity) 결과를 반환하기 시작한 것입니다.

기존 평가 스위트 (eval suite)가 보유했던 것: 골든 요약문 (golden summaries)에 대한 ROUGE-L 점수 (Layer 2).