[LLM Observability] Day 2: LLM 평가(Evaluation) - 오프라인 벤치마크와 온라인 A/B

서론: 지연은 낮지만 답은 틀릴 수 있다

LLM 시스템은 인프라 지표가 정상이어도 응답 품질이 저하될 수 있다. 모델 교체, 프롬프트 변경, RAG 인덱스 갱신 후에 “좋아졌는가”를 측정하는 체계가 없으면 배포 결정이 감에 의존하게 된다.

1. 오프라인 평가와 온라인 평가

구분	오프라인 평가	온라인 평가
시점	배포 전	배포 후
데이터	큐레이션된 테스트셋	실제 프로덕션 트래픽
피드백 속도	빠름 (자동화 가능)	느림 (사용자 행동 반영)
대표성	제한적	높음

두 방식은 보완 관계다. 오프라인이 통과해야 온라인 검증으로 이어진다.

2. 오프라인 평가 구성

2.1 골든 테스트셋

• 실제 사용 사례를 커버하는 대표 질문-답변 쌍
• 엣지 케이스, 도메인 특화 질의, 실패 이력 포함
• 정기적으로 갱신하지 않으면 커버리지가 줄어든다

2.2 평가 지표 선택

유형	지표 예시
참조 기반	ROUGE, BLEU, 정확일치율
LLM-as-Judge	GPT/Claude 기반 점수
태스크 특화	정보 추출 F1, 코드 실행 정확도
안전성	거부율, 정책 위반 탐지율

LLM-as-Judge는 사람 평가와 상관관계가 높지만, 판정 모델 자체의 편향에 주의해야 한다.

3. 온라인 평가 구성

3.1 암묵적 신호

사용자가 별도 피드백 없이 남기는 행동 패턴이다.

• 재질의율(사용자가 같은 주제를 다시 물어보는 비율)
• 복사·공유 비율
• 대화 이탈 시점

3.2 명시적 신호

• 좋아요/싫어요
• 오류 신고
• 수동 평가 샘플링(Human-in-the-Loop)

명시적 신호는 수량이 적지만 품질이 높다. 샘플 크기를 통계적으로 계획해야 한다.

3.3 A/B 실험 설계

Traffic Splitter
  ├─ 50% -> Model/Prompt Version A
  └─ 50% -> Model/Prompt Version B
       └─ Metric Comparison (평균 품질 점수, 이탈률, 오류율)

실험 단위는 사용자 세션이어야 한다. 요청 단위로 분리하면 동일 사용자가 두 경험을 섞어 받아 결과가 오염된다.

4. 평가 파이프라인 자동화

Code Change -> CI Trigger
  -> Golden Test Evaluation
  -> Pass/Fail Gate
  -> (Pass) -> Staging Canary
  -> (Fail) -> Block Merge

배포 게이트에 오프라인 평가를 통합하면 품질 저하를 조기 차단할 수 있다.

5. 운영 관측 지표

• 오프라인 테스트셋 통과율 추이
• LLM-as-Judge 평균 점수 변동
• 온라인 재질의율 / 이탈률 이상 탐지
• A/B 실험 유의성(p-value) 도달 속도

6. Day 2 체크리스트

1. 골든 테스트셋을 구축하고 정기 갱신 일정을 정했다.
2. 오프라인 평가를 CI 파이프라인 게이트로 연결했다.
3. 온라인 암묵적/명시적 신호를 수집하고 대시보드에 통합했다.
4. A/B 실험 설계 시 사용자 세션 단위 분리를 적용했다.

다음 글 예고

Day 3에서는 분산 추적(Distributed Tracing) 을 다룬다. 에이전트 체인과 멀티스텝 RAG 파이프라인에서 span 추적을 어떻게 설계하는지 살펴본다.