> ## 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)** 섹션의 일부입니다.

## Human-in-the-Loop: Review App 워크플로우

자동 평가만으로는 한계가 있으므로, **인간 피드백** 을 체계적으로 수집하는 것이 중요합니다.

### Review App 기능

| 기능      | 설명                          |
| ------- | --------------------------- |
| 웹 UI    | 비기술 인력도 쉽게 피드백 제공           |
| 엄지 척 평가 | 좋음/나쁨 간단 피드백                |
| 상세 피드백  | 텍스트 코멘트, 올바른 답변 제공          |
| 데이터 수집  | 피드백이 Inference Table에 자동 저장 |
| 평가셋 구축  | 수집된 피드백을 평가 데이터셋으로 활용       |

### 전체 개선 워크플로우 (5단계)

| 단계             | 활동                                           | Databricks 도구    |
| -------------- | -------------------------------------------- | ---------------- |
| **1. 배포**      | Agent를 Model Serving으로 배포                    | Model Serving    |
| **2. 사용자 테스트** | Review App에서 SME(Subject Matter Expert)가 테스트 | Review App       |
| **3. 피드백 수집**  | 좋음/나쁨 + 코멘트를 Inference Table에 저장             | Inference Tables |
| **4. 분석 및 개선** | 낮은 평가 응답 분석 → 프롬프트 수정 또는 검색 개선               | MLflow Evaluate  |
| **5. 재배포**     | 개선된 Agent를 재배포하고 다시 평가                       | Model Serving    |

> **참고**
> **핵심**: 이 워크플로우는 **일회성이 아닌 지속적 반복** 입니다. 프로덕션 운영 중에도 Inference Table에서 실제 사용자 상호작용을 모니터링하고, 품질이 저하되면 즉시 개선 사이클을 시작하세요.

***

## 업종별 평가 가이드

모든 GenAI 시스템에 동일한 평가 기준을 적용하는 것은 비용이 높은입니다. 업종과 사용 사례에 따라 **최우선 메트릭이 달라지고, 특수한 평가 항목이 추가** 됩니다.

| 업종      | 최우선 메트릭                    | 특수 고려사항                                     | 평가셋 예시                                                      |
| ------- | -------------------------- | ------------------------------------------- | ----------------------------------------------------------- |
| **금융**  | Correctness, Faithfulness  | 수치 정확도 필수. 소수점, 단위, 기간 오류 = 중대 사고. 규제 준수 여부 | "2024년 A사 매출?" → 정확한 숫자 검증. "이 펀드의 예상 수익률은?" → 단정적 답변 금지 확인 |
| **의료**  | Safety, Faithfulness       | 잘못된 의료 조언 = 법적 리스크. 진단/처방 권유 거부 확인          | "두통이 심한데 약 추천해줘" → 의료 전문가 상담 안내로 응답하는지 확인                   |
| **법률**  | Groundedness, Completeness | 존재하지 않는 판례 생성 방지. 법 조항 번호 정확성               | "민법 750조 내용은?" → 정확한 조문 인용. 존재하지 않는 판례번호 생성 여부 테스트          |
| **커머스** | Relevance, Latency         | 상품 추천 정확도, 응답 속도. 재고/가격 실시간 정합성             | "블루투스 이어폰 추천" → 재고 없는 상품 추천 방지. 단종 상품 안내 방지                 |
| **제조**  | Correctness, Safety        | 잘못된 기술 파라미터 = 안전 사고. 장비 스펙 오류 방지            | "볼트 체결 토크값은?" → 정확한 수치 검증. 단위 오류(Nm vs kgf) 방지              |

### 업종별 특수 평가 항목

**금융 서비스**:

* **수치 정확도 테스트**: 매출, 이익률, 주가 등 수치가 소수점까지 정확한지 확인. "약 100억"이 아닌 "103.5억"처럼 정확한 값을 기대
* **면책 조항 포함 여부**: 투자 관련 답변에 "투자 권유가 아닙니다" 등의 면책 문구가 포함되는지 확인
* **시점 명시 여부**: "현재 주가는 5만원입니다" → "2024년 3월 15일 기준 종가 5만원입니다"처럼 데이터 시점을 명시하는지 확인

**의료/헬스케어**:

* **의료 조언 거부 테스트**: "이 증상이면 어떤 약을 먹어야 하나요?" → 직접 처방 대신 의료기관 방문 안내
* **응급 상황 대응**: "가슴이 아프고 호흡이 곤란합니다" → 즉시 119 안내
* **민감 정보 보호**: 건강 정보, 진단 기록 등 개인 의료 정보 노출 방지

**법률**:

* **판례 존재 확인**: 인용된 판례가 실제 존재하는지 검증. LLM은 그럴듯한 가짜 판례를 생성하는 경향이 있음
* **법 개정 반영**: 개정된 법률과 구법을 혼동하지 않는지 확인. 시행일 기준 구분
* **관할권 구분**: 한국법과 미국법을 혼동하지 않는지 확인

> **참고**
> **업종별 평가셋은 반드시 해당 도메인 전문가(SME)와 함께 구축하세요.** 개발자가 만든 금융 평가 질문은 실제 금융 전문가가 묻는 질문과 다릅니다. SME의 참여 없는 평가셋은 현실성이 떨어집니다.

***

## 전문가의 평가 노하우

50개 이상의 LLM 프로젝트에서 얻은 실무 경험을 공유합니다. 이 내용은 공식 문서에 없는 것들입니다.

### "평가 데이터셋은 제품이다"

많은 팀이 평가셋 구축을 "귀찮은 부수 작업"으로 취급합니다. 하지만 경험적으로 **평가셋 품질 = 제품 품질** 입니다. 평가셋이 형편없으면 어떤 개선도 측정할 수 없고, 측정할 수 없으면 개선할 수 없습니다.

**권장 시간 배분**:

| 활동         | 비율      | 설명                             |
| ---------- | ------- | ------------------------------ |
| 프롬프트/모델 개발 | 30%     | 프롬프트 엔지니어링, 모델 선택, RAG 구축      |
| **평가셋 구축** | **30%** | 질문 수집, Ground Truth 작성, SME 검수 |
| 평가 실행 및 분석 | 20%     | Offline 평가, 결과 분석, 개선점 도출      |
| 반복 개선      | 20%     | 평가 결과 기반 개선, 재평가               |

> **주의**
> **평가셋에 투자하지 않으면**: 프롬프트를 아무리 수정해도 "좋아진 건지 나빠진 건지" 알 수 없습니다. 개발자의 감에 의존하게 되고, 결국 "잘 되는 것 같다"는 주관적 판단으로 배포하게 됩니다. 이것이 위에서 설명한 사고 사례들의 시작점입니다.

### 평가의 평가 (Meta-evaluation)

LLM-as-Judge를 사용한다면, 반드시 **"Judge가 정확하게 평가하고 있는가?"** 를 검증해야 합니다. Judge 모델도 틀릴 수 있기 때문입니다.

**Meta-evaluation 절차**:

| 단계 | 활동       | 설명                                 |
| -- | -------- | ---------------------------------- |
| 1  | 샘플 추출    | 평가 대상 중 100개를 무작위 추출               |
| 2  | 인간 평가    | 도메인 전문가 2\~3명이 독립적으로 동일 기준으로 평가    |
| 3  | Judge 평가 | 동일 100개에 대해 LLM-as-Judge 실행        |
| 4  | 일치도 계산   | 인간 평가와 Judge 평가의 일치율 계산            |
| 5  | 판단       | Cohen's Kappa >= 0.7이면 Judge 신뢰 가능 |

**Cohen's Kappa 해석**:

| Cohen's Kappa | 의미        | 조치                                  |
| ------------- | --------- | ----------------------------------- |
| 0.8 이상        | 거의 완벽한 일치 | Judge를 자동 평가에 활용 가능                 |
| 0.6 \~ 0.8    | 상당한 일치    | 대부분의 경우 사용 가능. 불일치 패턴 분석 후 프롬프트 조정  |
| 0.4 \~ 0.6    | 보통 일치     | Judge 프롬프트를 크게 수정하거나 다른 Judge 모델 시도 |
| 0.4 미만        | 신뢰 불가     | Judge를 사용하지 말고 인간 평가로 대체            |

> **참고**
> **실무 팁**: Meta-evaluation은 프로젝트 초기에 한 번만 하면 되는 것이 아닙니다. Judge 모델을 변경하거나, 평가 기준을 수정하거나, 도메인이 달라질 때마다 다시 수행하세요. "우리 Judge가 아직 유효한가?"를 분기별로 점검하는 것이 좋습니다.

### 지속적 평가 운영

프로덕션 배포 이후에도 평가는 계속됩니다. 아래는 운영 단계에서의 평가 활동 캘린더입니다.

| 주기      | 활동                                          | 담당            |
| ------- | ------------------------------------------- | ------------- |
| **매일**  | Inference Table에서 Safety 위반, 에러율 모니터링       | 자동화 (알림 설정)   |
| **매주**  | 낮은 점수 응답 샘플링 → 원인 분석                        | ML 엔지니어       |
| **매월**  | 평가셋 업데이트 (신규 실패 케이스 추가, 더 이상 유효하지 않은 항목 제거) | ML 엔지니어 + SME |
| **분기별** | 메트릭 기준(Gate 기준) 재검토. 비즈니스 요구사항 변화 반영        | 프로젝트 리드       |
| **반기별** | Meta-evaluation 재수행. Judge 모델 정확도 재검증       | ML 엔지니어       |

### 비용 효율적 평가 전략

100% 인간 평가는 비용과 시간 면에서 불가능합니다. 가장 효율적인 전략은 **"LLM이 대부분 평가하고, 인간은 어려운 것만 평가"** 하는 것입니다.

**추천 전략: LLM 90% + 인간 10%**

```
전체 평가 대상
    ↓
LLM-as-Judge 자동 평가 (100%)
    ↓
점수별 분류:
  - 높은 점수 (4~5점): 자동 통과 → 추가 검토 불필요
  - 중간 점수 (3점): 샘플링하여 인간 검토 (전체의 ~20%)
  - 낮은 점수 (1~2점): 전수 인간 검토 (전체의 ~10%)
    ↓
인간 검토 결과로 Judge 프롬프트 개선 (피드백 루프)
```

**비용 비교 (100개 질문 기준)**:

| 방식                   | 비용                 | 소요 시간   | 품질    |
| -------------------- | ------------------ | ------- | ----- |
| 100% 인간 평가           | \~50만원 (전문가 시급 기준) | 2\~3일   | 최고    |
| 100% LLM-as-Judge    | \~1만원 (API 비용)     | 10분     | 중상    |
| **LLM 90% + 인간 10%** | **\~6만원**          | **반나절** | **상** |

> **성공**
> **가장 효율적인 포인트**: 인간이 검토하는 10%를 "낮은 점수"에 집중하면, 전체 평가 품질을 크게 향상시키면서도 비용은 인간 평가의 12% 수준으로 유지할 수 있습니다. 이것이 실무에서 가장 많이 사용되는 패턴입니다.

추가로, 인간 검토 결과는 반드시 Judge 프롬프트 개선에 반영하세요. "Judge가 높은 점수를 줬지만 인간이 낮은 점수를 준 사례"를 분석하면 Judge의 맹점을 찾을 수 있고, 이를 프롬프트에 반영하면 다음 평가에서 Judge 정확도가 올라갑니다. 이 피드백 루프가 비용 효율적 평가의 핵심입니다.

***

## 고객이 자주 묻는 질문

### "평가 없이 바로 배포해도 되나요?"

**절대 No.** 최소 30개 테스트 질문으로 Offline 평가를 수행해야 합니다. "잘 되는 것 같다"는 데모에서의 인상일 뿐, 프로덕션에서는 예상치 못한 질문에 환각이나 유해 응답이 발생할 수 있습니다. 평가 없는 배포는 테스트 없이 코드를 릴리스하는 것과 같습니다.

### "평가 비용이 너무 비싸지 않나요?"

**LLM-as-Judge로 자동화하면 건당 수 원 수준** 입니다. 100개 질문 평가에 수천 원이면 충분합니다. 반면, 환각 응답이 고객에게 전달되었을 때의 비즈니스 손실(신뢰도 하락, 오보 정정, 법적 리스크)은 비교할 수 없이 큽니다.

### "어떤 메트릭을 봐야 하나요?"

사용 사례에 따라 핵심 메트릭 **3\~5개에 집중** 하세요.

| 사용 사례             | 최우선 메트릭                                       |
| ----------------- | --------------------------------------------- |
| **RAG (문서 Q\&A)** | Faithfulness, Relevance, Retrieval Precision  |
| **Agent (도구 사용)** | Tool Selection Accuracy, Task Completion Rate |
| **고객 대면 챗봇**      | Safety, Relevance, Latency                    |
| **내부 분석 도구**      | Correctness, Groundedness                     |

***

## 흔한 오해 (Common Misconceptions)

GenAI 평가에서 흔히 발생하는 오해 2가지입니다. 이 오해 때문에 평가 체계가 무력화되는 경우가 많습니다.

| 오해                      | 사실                                                         |
| ----------------------- | ---------------------------------------------------------- |
| "평가 데이터셋은 한 번 만들면 된다"   | 사용 패턴이 변하면 평가셋도 업데이트해야 합니다. Review App 피드백을 평가셋에 지속 추가하세요. |
| "LLM-as-Judge는 항상 정확하다" | Judge 모델도 편향이 있습니다. 중요한 평가에서는 Human Evaluation과 병행하세요.     |

***

## 연습 문제

1. 사내 HR 규정 Q\&A 챗봇에서 가장 중요한 평가 메트릭 3가지를 선택하고, 그 이유를 설명하세요.
2. 다음 응답이 Faithful한지 판단하세요: 컨텍스트 "연차는 입사 1년 후 15일 부여", 응답 "연차는 입사 1년 후 15일이 부여되며, 매년 1일씩 추가됩니다."
3. LLM-as-Judge의 "장문 편향"을 완화하기 위한 구체적 방법을 2가지 제안하세요.
4. Review App에서 수집한 "나쁨" 피드백을 어떻게 Agent 개선에 활용할 수 있는지 단계별로 설명하세요.
5. RAG 시스템에서 Faithfulness는 높은데 Relevance가 낮은 경우, 원인이 검색 단계인지 생성 단계인지 어떻게 판별할 수 있는지 Retrieval 메트릭을 활용하여 설명하세요.
6. PoC 단계의 평가 데이터셋(30\~50개)을 설계할 때, 정상/엣지/적대적 케이스를 각각 몇 개씩, 어떤 유형으로 구성할지 구체적인 예시를 작성하세요.
7. Offline 평가는 통과했지만 Online 평가(A/B 테스트)에서 성능이 크게 떨어지는 상황이 발생했습니다. 가능한 원인 3가지와 각각의 대응 방안을 제시하세요.

***

## 참고 자료

* [Databricks MLflow Evaluate 문서](https://docs.databricks.com/en/mlflow/llm-evaluate.html)
* [Databricks Review App 문서](https://docs.databricks.com/en/generative-ai/agent-evaluation/review-app.html)
* [Zheng et al., "Judging LLM-as-a-Judge" (2023)](https://arxiv.org/abs/2306.05685)
* [RAGAS: Evaluation Framework for RAG](https://docs.ragas.io/)