평가 데이터셋 설계 가이드
“어떤 질문으로 테스트할 것인가”는 평가에서 가장 중요한 결정입니다. 아무리 좋은 메트릭과 도구를 사용하더라도, 평가 데이터셋이 실제 사용 패턴을 반영하지 못하면 의미 없는 결과를 얻게 됩니다.커버리지 원칙
- 주요 사용 사례별 최소 10개 질문 을 포함하세요
- 비율 가이드: 정상 케이스 60%+ 엣지 케이스 30%+ 적대적 케이스 10%
엣지 케이스 유형
| 유형 | 예시 | 왜 중요한가 |
|---|---|---|
| 모호한 질문 | ”그거 얼마예요?” | 컨텍스트 부족 시 행동 확인 |
| 다국어 혼용 | ”Delta Lake의 time travel 기능 알려줘” | 한영 혼용 처리 확인 |
| 도메인 밖 질문 | ”오늘 날씨 어때?” (HR 챗봇에) | 범위 밖 질문 거절 능력 |
| 최신 정보 질문 | ”이번 달 신제품은?” | 학습 데이터 이후 정보 처리 |
| 수치/계산 질문 | ”지난 3분기 평균 매출은?” | 정확한 수치 계산 능력 |
데이터셋 크기 가이드
| 단계 | 권장 크기 | 목적 |
|---|---|---|
| PoC 단계 | 30~50개 | 기본 동작 확인, 주요 시나리오 커버 |
| 파일럿 단계 | 100~200개 | 엣지 케이스 포함, 메트릭 기반 비교 |
| 프로덕션 단계 | 500개 이상 | 포괄적 커버리지, 회귀 테스트 포함 |
Ground Truth 작성 원칙
- 도메인 전문가(SME)가 작성: 개발자가 아닌 실제 업무 전문가가 정답을 만들어야 합니다
- 단일 정답이 아닌 “허용 가능한 답변 범위” 정의: “연차는 15일입니다”도, “입사 1년 후 15일의 연차가 부여됩니다”도 정답으로 인정
- 정답에 근거 문서 출처 포함: 어떤 문서에서 답을 찾을 수 있는지 함께 기록
주의 평가셋은 살아있는 문서입니다: 프로덕션 운영 중 Review App에서 수집된 실패 케이스를 지속적으로 평가셋에 추가하세요. 시간이 지날수록 평가셋의 품질이 높아지고, 회귀 테스트 역할을 합니다.
Offline vs Online 평가
Offline 평가 (배포 전)
고정된 평가 데이터셋으로 반복 테스트하는 방식입니다. 개발 중 빠른 피드백 루프 를 제공합니다.| 특징 | 설명 |
|---|---|
| 데이터 | 고정 평가셋 (사전 준비) |
| 속도 | 빠름 (분 단위) |
| 실행 시기 | 프롬프트 변경, 모델 교체, 검색 설정 변경 시마다 |
| 도구 | MLflow Evaluate |
| 장점 | 빠른 실험, 재현 가능, 비용 낮음 |
| 한계 | 실제 사용 패턴을 완전히 반영하지 못함 |
Online 평가 (배포 후)
실제 사용자 트래픽으로 평가하는 방식입니다. 프로덕션 환경에서의 실제 성능 을 측정합니다.| 특징 | 설명 |
|---|---|
| 데이터 | 실제 사용자 트래픽 |
| 속도 | 느림 (일~주 단위) |
| A/B 테스트 | 기존 모델(A) vs 새 모델(B)에 트래픽 분배하여 비교 |
| Shadow Deployment | 새 모델이 실제 응답하지 않고, 기존 모델과 결과만 비교 |
| 도구 | Inference Table, Model Serving |
| 장점 | 높은 현실성, 실제 사용자 반응 측정 |
| 한계 | 시간 소요, 실 서빙 비용 발생 |
Offline vs Online 비교
| 항목 | Offline | Online |
|---|---|---|
| 데이터 | 고정 평가셋 | 실제 사용자 트래픽 |
| 속도 | 빠름 (분) | 느림 (일~주) |
| 현실성 | 제한적 | 높음 |
| 비용 | 낮음 | 높음 (실 서빙 비용) |
| 적합 시기 | 개발/실험 중 | 배포 전 최종 검증, 배포 후 모니터링 |
참고 권장 순서: Offline 평가를 통과한 모델만 Online 평가로 진행하세요. Online 평가는 실제 사용자에게 영향을 미치므로, shadow deployment부터 시작하는 것을 권장합니다.
평가 파이프라인 설계
프로덕션 수준의 GenAI 시스템은 “한 번 평가하고 끝”이 아닙니다. 코드 변경 → 자동 평가 → 단계별 배포 → 지속 모니터링 의 파이프라인을 구축해야 합니다.전체 흐름
Gate 기준 설정
평가 파이프라인에서 가장 중요한 것은 “통과/실패를 결정하는 기준” 입니다. 기준 없는 평가는 보고서일 뿐, 품질 관리가 아닙니다.| 메트릭 | 최소 기준 (예시) | 근거 |
|---|---|---|
| Faithfulness | >= 0.85 | 15%의 답변이 문서에 없는 내용을 포함하면 프로덕션에서 신뢰도 문제 |
| Relevance | >= 0.80 | 5개 중 1개가 관련 없는 답변이면 사용자 이탈 |
| Safety | >= 0.99 | 안전성은 거의 100%에 가까워야 함. 1%의 유해 응답도 브랜드 리스크 |
| Latency P95 | < 5초 (대화형) | 5초 이상 대기 시 사용자 50%가 이탈 |
| Regression | 0건 | 기존에 맞던 질문을 새 버전에서 틀리면 안 됨 |
주의 기준은 사용 사례에 따라 조정하세요. 위 수치는 일반적인 출발점입니다. 의료/법률 도메인은 Faithfulness >= 0.95, Safety = 1.0이 필요할 수 있고, 내부 도구는 Faithfulness >= 0.75로도 충분할 수 있습니다. 중요한 것은 기준을 명시적으로 정의하고 자동화하는 것 입니다.
Regression 테스트와 Golden Set
새 버전을 배포할 때 가장 위험한 것은 기존에 잘 되던 것이 깨지는 것 입니다. 이를 방지하기 위해 “Golden Set”을 관리합니다. Golden Set이란?- 프로덕션에서 정확하게 답변한 것이 검증된 질문-답변 쌍
- 새 버전이 이 질문들에 대해 동일하거나 더 나은 답변을 하는지 확인
- 시간이 지날수록 누적되어 회귀 테스트의 핵심 자산이 됨
| 원칙 | 설명 |
|---|---|
| 지속 추가 | Review App에서 “좋음” 평가를 받은 응답을 Golden Set에 추가 |
| 버전 관리 | Golden Set 자체도 git으로 관리. 변경 이력 추적 |
| 정기 검토 | 분기별로 더 이상 유효하지 않은 항목 제거 (정책 변경 등) |
| 최소 크기 | 주요 사용 사례당 최소 20개. 전체 100개 이상 권장 |
A/B 테스트 설계
Shadow 배포를 통과한 후, 실제 사용자 트래픽으로 비교 실험을 수행합니다.| 단계 | 트래픽 비율 | 기간 | 확인 사항 |
|---|---|---|---|
| 1단계 | 새 버전 5% | 2~3일 | 심각한 오류 없는지 확인. 에러율, Safety 메트릭 |
| 2단계 | 새 버전 25% | 3~5일 | 핵심 메트릭 비교. 기존 대비 유의미한 차이 확인 |
| 3단계 | 새 버전 50% | 5~7일 | 통계적 유의성 확보 (p-value < 0.05) |
| 전환 | 새 버전 100% | - | 기존 버전은 즉시 롤백 가능하도록 유지 |
- Faithfulness가 기존 대비 5% 이상 하락
- Safety 위반 건수가 1건이라도 증가
- P95 Latency가 기존 대비 2배 이상 증가
- 사용자 부정 피드백 비율이 기존 대비 10% 이상 증가
참고 통계적 유의성: A/B 테스트에서 “새 버전이 더 좋다”고 결론내리려면 충분한 샘플이 필요합니다. 일반적으로 각 그룹에 최소 1,000건 이상의 요청 이 있어야 통계적으로 의미 있는 비교가 가능합니다. 트래픽이 적은 서비스라면 기간을 더 길게 잡으세요.