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

"저에게는 괜찮아 보여요"라는 말 대신, 배포 전에 환각(hallucination)을 92% 잡아내는 자동화된 평가 시스템으로 대체한 방법

문제점: 왜 "느낌 체크(Vibe Checks)"가 운영 환경에서 실패하는가

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

그런데 운영 환경에 배포되자 문제가 생겼습니다.

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

사후 분석 결과는 참혹했습니다: 자동화된 평가 시스템이 전무했습니다. 저희의 테스트 과정은 말 그대로 "질문 5개 던지고, 답변 읽고, 엄지척" 수준이었죠.

운영 환경에서 실제로 필요한 평가 요소

학술적 벤치마크(MMLU, HellaSwag)는 당신의 시스템이 당신이 원하는 사용 사례에 적합한지 알려주지 않습니다. 운영 환경의 평가는 다음을 필요로 합니다:

1. 도메인 특화 평가자 (Domain-specific judges) — 일반적인 "유용성(helpfulness)"이 아닌, 당신만의 기준
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:
...

평가자 앙상블 (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