운영 환경용 LLM 평가 파이프라인 구축하기: 느낌에서 지표로

"저에게는 괜찮아 보인다"라는 말 대신 배포 전 환각(hallucination)의 92%를 포착하는 자동화된 평가 시스템을 구현한 방법

문제점: 왜 '느낌만으로 판단하기'(Vibe Checks)가 운영 환경에서 실패하는가

3개월 전, 저희 팀은 RAG 기반 고객 지원 어시스턴트를 출시했습니다. 테스트 환경에서는 아주 잘 작동했습니다. 저희는 질문을 던지고 답변을 읽어보면서 "응, 이거 맞는 것 같아"라고 생각했죠.

하지만 실제 운영 환경에 투입되자 상황이 달라졌습니다.

한 고객은 청구 주기(billing cycle)에 대해 물었습니다. 어시스턴트는 존재하지 않는 정책을 자신 있게 인용했습니다. 또 다른 고객은 API 호출 제한(rate limits)에 대해 문의했고, 경쟁사 문서에서 가져온 숫자를 받았습니다. 저희가 이 문제를 발견했을 때는 이미 500명 이상의 사용자가 환각된 답변을 본 후였습니다.

사후 분석 결과는 혹독했습니다: 자동화된 평가 시스템이 전무했습니다. 저희의 테스트 과정은 말 그대로 "질문 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) — 버전이 지정되고, 계층화되며, 지속적으로 성장하는 테스트 케이스

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

┌─────────────┐     ┌──────────────┐     ┌────────────────────┐     ┌──────────────┐
│ 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