프로덕션 환경에서의 LLM 평가: 모든 배포 시 실행되는 평가 파이프라인 구축하기

모두가 RAG (Retrieval-Augmented Generation) 시스템을 출시합니다. 하지만 RAG 시스템이 거짓말을 하기 시작할 때 이를 알려주는 평가 (eval) 시스템을 출시하는 사람은 거의 없습니다.

임베딩 (embedding) 모델을 업데이트했습니다. 시스템 프롬프트 (system prompt)를 미세 조정했습니다. 리랭커 (re-ranker)를 교체했습니다. 지표 (metrics)는 괜찮아 보입니다. 3주 후, 고객 지원 티켓이 도착합니다 — 시스템이 소스 문서에 전혀 없는 추론을 하고 있습니다. 경고는 울리지 않았습니다. 테스트도 실패하지 않았습니다. 시스템이 조용히 드리프트 (drift) 된 것입니다.

이것은 모델 품질의 문제가 아닙니다. 평가 인프라 (evaluation infrastructure)의 문제입니다.

중요한 4가지 지표

충실도 (Faithfulness) — 응답 내의 주장 중 검색된 컨텍스트 (context)에 의해 직접적으로 뒷받침되는 비율은 얼마인가? 주요 환각 (hallucination) 방어 기제입니다. 정답 (ground truth)이 필요하지 않습니다.

답변 관련성 (Answer Relevance) — 응답이 사용자의 질문에 얼마나 직접적으로 답하고 있는가? "기술적으로는 맞지만 쓸모없는" 실패 모드를 잡아냅니다. 정답 (ground truth)이 필요하지 않습니다.

컨텍스트 정밀도 (Context Precision) — 검색된 청크 (chunks) 중 실제로 관련이 있는 비율은 얼마인가? 정답 (ground truth)이 필요합니다. 오프라인 CI 평가에 적합합니다.

답변 정확도 (Answer Correctness) — 참조 답변 (reference answer) 대비 사실적으로 얼마나 정확한가? 가장 비용이 많이 들며, 큐레이션된 정답 (ground truth)이 필요합니다. 배포 전 회귀 테스트 (regression suite)에서만 사용합니다.

운영 규칙: 충실도 (Faithfulness)와 답변 관련성 (Answer Relevance)은 모든 배포 시 및 샘플링된 프로덕션 트래픽에서 실행됩니다. 컨텍스트 정밀도 (Context Precision)와 답변 정확도 (Answer Correctness)는 골든 데이터셋 (golden dataset)을 대상으로 CI에서 실행됩니다.

LLM-as-Judge: 패턴과 함정

RAGAS는 LLM 출력을 평가하기 위해 LLM을 사용합니다 — 이는 대규모로 의미론적 품질 (semantic quality)을 평가할 수 있는 유일한 실질적인 방법입니다.

관리해야 할 함정:

위치 편향 (Positional bias) — 쌍체 비교 (pairwise comparisons) 시 순서를 무작위화하십시오.
장황함 편향 (Verbosity bias) — 판사 (judge)가 정확도가 낮더라도 더 긴 답변에 더 높은 점수를 주는 경향입니다.
자기 선호 (Self-preference) — 답변을 생성하는 모델과 다른 모델 제품군을 판사로 사용하십시오.
교정 드리프트 (Calibration drift) — 판사 모델을 특정 버전에 고정하십시오. 업그레이드는 베이스라인 재설정으로 취급하십시오.

50~100개의 예시에 대해 Cohen's Kappa를 사용하여 인간의 라벨 (human labels)과 대조하여 교정하십시오. 0.4 미만이라면 판사 프롬프트 (judge prompt)를 수정해야 합니다.

CI/CD 통합 (CI/CD Integration)

평가 파이프라인 (eval pipeline)은 RAG 코드, 프롬프트 (prompts), 또는 모델 설정 (model configuration)을 수정하는 모든 PR (Pull Request) 발생 시 트리거됩니다:

골든 데이터셋 (golden dataset, 100개 이상의 큐레이션된 질문)을 대상으로 RAG 파이프라인 실행
RAGAS를 사용하여 점수 산정 (충실도 (faithfulness), 관련성 (relevance), 정밀도 (precision), 정확성 (correctness))
베이스라인 (baseline)과 비교 — 성능 저하 (regression)가 임계값을 초과하면 배포 차단
지표별 점수 및 통과/실패 (pass/fail) 상태를 포함하여 PR 댓글로 결과 게시

비용: Claude Sonnet 가격 기준, 전체 평가 실행 1회당 약 $0.50~$2.00 소요. PR 단계에서는 가장 저렴한 충실도 (faithfulness) + 관련성 (relevance)만 실행합니다. 전체 스위트 (full suite)는 매일 밤 실행됩니다.

프로덕션 샘플링 (Production Sampling)

CI는 코드 변경으로 인한 성능 저하 (regressions)를 포착합니다. 프로덕션 샘플링 (Production sampling)은 코퍼스 (corpus)의 노후화, 쿼리 분포 변화 (query distribution shift), 그리고 모델 동작 변화로 인한 드리프트 (drift)를 포착합니다.

비동기 평가 (async evaluation)를 위해 라이브 트래픽의 5%를 샘플링하십시오. 절대 동기식 (synchronously)으로 평가하지 마십시오. 판사 호출 (judge calls)은 요청당 2~5초를 추가합니다. 7일 이동 평균 (7-day rolling) 충실도 (faithfulness)와 답변 관련성 (answer relevance)을 추적하십시오. 월간 베이스라인 (monthly baseline)에서 0.05 이상 하락하면 알림을 보냅니다.

핵심 통찰 (The Key Insight)

LLM 시스템은 안정적이고 결정론적인 (deterministic) 동작을 하지 않습니다. 코퍼스 변경, 모델 업데이트, 프롬프트 진화, 그리고 쿼리 분포 변화를 통해 드리프트 (drift)가 발생합니다. 평가는 단순한 체크포인트가 아니라, 지속적인 인프라 (continuous infrastructure)입니다.

평가 시스템이 필요해지기 전에 구축하십시오. 시스템이 필요해진 시점에는 이미 너무 늦었습니다. 과거의 베이스라인도 없고 자동화된 탐지 기능도 없는 상태에서 프로덕션 품질 저하 (production quality regression) 문제를 디버깅하게 될 것입니다.

전체 기사 읽기

이 글은 LLM 평가 인프라에 대한 저의 심층 분석을 요약한 것입니다. 전체 기사에서는 구현 예시와 함께 전체 평가 스택 (eval stack)을 다룹니다:

👉 LLM Evaluation in Production — Full Article

전체 기사에는 다음 내용이 포함되어 있습니다:

평가 스택 아키텍처 (Evaluation stack architecture) (검색 레이어 (retrieval layer) vs 생성 레이어 (generation layer))
RAGAS Python 구현을 활용한 4가지 지표
클레임 수준 점수 산정 (claim-level scoring)을 포함한 LLM-as-Judge 충실도 (faithfulness) 프롬프트
인간 레이블에 대한 판사 보정 (Judge calibration) (Cohen's Kappa)
Claude를 판사 모델 (judge model)로 사용하는 RAGAS 설정
회귀 임계값 프레임워크 (Regression threshold framework) (절대값 + 베이스라인 대비 변화량 (delta))
골든 데이터셋 (Golden dataset) 생성, 버전 관리 및 홀드아웃 파티션 (holdout partitions)
전체 GitHub Actions 평가 파이프라인 (YAML + 러너 스크립트)
비동기 평가 큐 워커 (async eval queue worker)를 활용한 프로덕션 샘플링
평가 관측성 대시보드 스키마 (Eval observability dashboard schema) (PostgreSQL)
평가 시스템의 8가지 실패 모드 (failure modes) 및 완화 방법
프로덕션 배포 체크리스트