> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# 평가 파이프라인

> 이 문서는 **[GenAI 개념](/blog/guides/genai-concepts/overview)** 섹션의 일부입니다.

## 평가 데이터셋 설계 가이드

"어떤 질문으로 테스트할 것인가"는 평가에서 가장 중요한 결정입니다. 아무리 좋은 메트릭과 도구를 사용하더라도, 평가 데이터셋이 실제 사용 패턴을 반영하지 못하면 의미 없는 결과를 얻게 됩니다.

### 커버리지 원칙

* **주요 사용 사례별 최소 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 시스템은 "한 번 평가하고 끝"이 아닙니다. **코드 변경 → 자동 평가 → 단계별 배포 → 지속 모니터링** 의 파이프라인을 구축해야 합니다.

### 전체 흐름

```
코드/프롬프트 변경
    ↓
CI/CD에서 자동 Offline 평가 실행
    ↓
Gate 기준 통과 여부 확인
    ↓ (통과)                    ↓ (실패)
Shadow 배포                  자동 롤백 + 알림
    ↓
Online 메트릭 수집 (1~3일)
    ↓
기존 대비 개선 확인
    ↓ (개선)                    ↓ (저하)
A/B 테스트 (5% → 25% → 50%)   롤백 + 원인 분석
    ↓
Production 전환 (100%)
```

### 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이란?**

* 프로덕션에서 **정확하게 답변한 것이 검증된 질문-답변 쌍**
* 새 버전이 이 질문들에 대해 동일하거나 더 나은 답변을 하는지 확인
* 시간이 지날수록 누적되어 회귀 테스트의 핵심 자산이 됨

**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건 이상의 요청** 이 있어야 통계적으로 의미 있는 비교가 가능합니다. 트래픽이 적은 서비스라면 기간을 더 길게 잡으세요.