프로덕션급 LLM 평가 파이프라인 구축: 느낌(Vibes)에서 지표(Metrics)로

배포 전 환각(Hallucinations)의 92%를 잡아내는 자동화된 평가를 통해 "좋아 보이네요"라는 말을 어떻게 대체했는가

문제점: 왜 프로덕션 환경에서 "느낌 체크(Vibe Checks)"가 실패하는가

3개월 전, 우리 팀은 RAG(Retrieval-Augmented Generation) 기반의 고객 지원 어시스턴트를 출시했습니다. 테스트 단계에서는 아주 잘 작동했습니다. 질문을 던지고, 답변을 읽고, "네, 맞는 것 같네요"라고 말하면 그만이었죠.

하지만 프로덕션에 배포되자 상황이 달라졌습니다.

한 고객이 결제 주기에 대해 물었을 때, 어시스턴트는 존재하지 않는 정책을 자신 있게 인용했습니다. 또 다른 고객이 API 속도 제한(rate limits)에 대해 물었을 때는 경쟁사의 문서에서 가져온 숫자를 답변했습니다. 우리가 이를 파악했을 때는 이미 500명 이상의 사용자가 환각(hallucinated)된 응답을 본 상태였습니다.

사후 분석(Post-mortem) 결과는 처참했습니다. 우리에게는 자동화된 평가가 전혀 없었습니다. 우리의 테스트 프로세스는 말 그대로 "질문 5개 던지기, 답변 읽기, 엄지 척"이었습니다.

프로덕션 평가에 실제로 필요한 것

학술적 벤치마크(MMLU, HellaSwag)는 당신의 시스템이 당신의 사용 사례에 맞게 작동하는지 알려주지 않습니다. 프로덕션 평가에는 다음이 필요합니다:

1. 도메인 특화 판사 (Domain-specific judges) — 일반적인 "도움이 되는 정도"가 아닌, 당신만의 기준
2. 속도 (Speed) — 평가는 밤새 돌아가는 것이 아니라 CI/CD 내에서 실행되어야 함
3. 회귀 탐지 (Regression detection) — 프롬프트 변경이 문제를 일으키는 즉시 파악
4. CI/CD 통합 (CI/CD integration) — 품질을 저하시키는 머지(merge)를 차단
5. 골든 데이터셋 관리 (Golden dataset management) — 버전 관리되고, 층화(stratified)되며, 계속 성장하는 테스트 케이스

아키텍처: 평가 파이프라인

┌─────────────┐     ┌──────────────┐     ┌────────────────────┐     ┌──────────────┐
│ Test Cases  │────▶│  LLM Under   │────▶│   Judge Ensemble   │────▶│  Metrics &   │
│ (Golden Set)│     │   Test       │     │  - Faithfulness    │     │  Regression  │
...

핵심 추상화 (Core Abstractions)

# eval/base.py
@dataclass(frozen=True)
class TestCase:
...

판사 앙상블 (The Judge Ensemble): RAGAS를 넘어서

RAGAS는 충실도(faithfulness)와 답변 관련성(answer relevance)을 제공합니다. 하지만 프로덕션에는 그 이상의 것이 필요합니다:

Few-Shot을 활용한 커스텀 LLM 판사 (Custom LLM Judge with Few-Shot)

# eval/judges.py
class LLMJudge(Judge):
    def __init__(self, name, criteria, model="gpt-4o-mini", few_shot_examples=None):
...

충실도 판사 (Faithfulness Judge) (프로덕션 준비 완료)

def create_faithfulness_judge() -> LLMJudge:
    return LLMJudge(
        name="faithfulness",
...

골든 데이터셋 전략 (Golden Dataset Strategy)

1,000개의 케이스로 시작하지 마세요. 실제 프로덕션 케이스 50개로 시작하세요.

# eval/golden_set.jsonl
{"id": "support-001", "input": {"question": "How do I reset my password?", "context": "..."}, "expected": {"answer": "Use the 'Forgot Password' link..."}, "tags": ["basic", "auth"]}
{"id": "support-042", "input": {"question": "Why was I charged twice?", "context": "..."}, "expected": null, "tags": ["billing", "edge-case"]}

층화 (Stratification)가 중요합니다:

• 40% 기본/해피 패스 (basic/happy-path)
• 30% 엣지 케이스 (edge cases) (모호함, 다단계)
• 20% 적대적 사례 (adversarial) (인젝션, 주제 이탈)
• 10% 다국어/긴 컨텍스트 (multilingual/long-context)

데이터셋의 버전을 관리하세요: Git으로 추적하세요. 모든 프로덕션 실패 사례는 새로운 테스트 케이스가 됩니다.

실효성 있는 회귀 탐지 (Regression Detection That Works)

def regression_report(self, baseline: dict[str, float]) -> dict[str, Any]:
    current = self.summary()
    report = {}
...

CI/CD 통합: GitHub Actions

# .github/workflows/llm-eval.yml
name: LLM Evaluation
on:
...

결과: 6개월간의 프로덕션 평가

우리가 구축한 오픈 소스 도구들 (Open Source Tooling We Built)

모두 MIT 라이선스이며, 프로덕션 환경에 맞춰 강화되었습니다:

• llm-eval-harness — 핵심 프레임워크 (본 기사의 코드)
• prompt-registry — 평가 이력이 포함된 Git 기반 프롬프트 버전 관리
• eval-dashboard — 알림 기능이 포함된 실시간 모니터링

지금 바로 시작하기 (5분 소요)

pip install llm-eval-harness

from eval.harness import EvaluationHarness
from eval.judges import create_faithfulness_judge, create_instruction_following_judge
from eval.base import TestCase
...

사고방식의 전환 (The Mental Shift)

평가는 사후 고려 사항이 아니라 인프라입니다.

• 판사 (Judges)를 일급 코드 (First-class code)로 취급하세요 (버전 관리, 테스트, 리뷰 수행)
• 골든 데이터셋 (Golden dataset) = 당신의 가장 가치 있는 지식재산 (IP) (철저하게 큐레이션하세요)
• 모든 프롬프트 변경 = 평가 실행 (CI에 의해 강제됨)
• 회귀 (Regression) 알림 = 페이징 알림 (이메일 요약본이 아닌 즉각적인 알림)

사용자는 당신의 프롬프트 엔지니어링 (Prompt engineering) 기술이 얼마나 영리한지에는 관심이 없습니다. 그들은 답변이 정확한지에 관심이 있습니다. 자동화된 평가 (Automated evaluation)는 대규모 환경에서 이를 보장하는 방법입니다.

코드: github.com/yourname/llm-eval-harness |
토론: Hacker News |
팔로우: @yourname