> ## 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 평가 방법론

GenAI 시스템의 품질을 측정하고 개선하는 것은 프로덕션 배포의 필수 과정입니다. 전통적인 ML과 달리 LLM 평가는 정답이 명확하지 않아 체계적인 접근이 필요합니다.

> **참고**
> **학습 목표**

* GenAI 평가가 전통 ML 평가와 근본적으로 다른 이유를 설명할 수 있다
* Faithfulness, Relevance, Groundedness 등 핵심 메트릭을 구체적 예시로 구분할 수 있다
* Human Evaluation과 LLM-as-Judge의 장단점을 비교하여 적합한 방법을 선택할 수 있다
* MLflow Evaluate를 사용하여 Agent를 평가하는 코드를 작성할 수 있다
* Review App을 활용한 피드백 수집 → 개선 워크플로우를 설계할 수 있다

***

## 왜 GenAI 평가가 특별히 어려운가?

전통 ML과 GenAI는 평가 패러다임이 근본적으로 다릅니다.

| 항목    | 전통 ML                   | GenAI/LLM                         |
| ----- | ----------------------- | --------------------------------- |
| 정답    | 레이블이 명확 (스팸/정상)         | "좋은 답변"의 기준이 주관적                  |
| 메트릭   | Accuracy, F1, AUC 등 정량적 | 유창성, 관련성, 안전성 등 정성적               |
| 출력 형태 | 수치/범주 (0 or 1, 3.14)    | 자유 형식 텍스트 (무한한 가능성)               |
| 재현성   | 동일 입력 = 동일 출력           | 동일 질문에 다른 응답 가능 (Temperature > 0) |
| 평가 비용 | 자동화 용이, 저비용             | 인간 평가 필요, 고비용                     |

> **주의**
> **핵심 문제**: "서울의 맛집을 추천해주세요"라는 질문에 정답이 하나가 아닙니다. "강남역 근처 이탈리안 레스토랑"도, "을지로 골목 칼국수집"도 좋은 답변이 될 수 있습니다. 이런 환경에서 어떻게 "품질"을 측정할 것인가가 GenAI 평가의 핵심 과제입니다.

> **위험**
> "잘 동작하는 것 같다"라는 주관적 판단만으로 프로덕션에 배포하면, 환각(Hallucination)이나 유해 응답 문제가 발생할 수 있습니다. 반드시 체계적으로 평가하세요.

***

## 평가 없이 배포하면 벌어지는 일

"평가는 나중에 하겠다"는 말은 50개 이상의 LLM 프로젝트를 진행하면서 가장 많이 들은 말이고, 동시에 가장 큰 사고로 이어진 말입니다. 아래는 실제 프로젝트에서 발생한 사례를 익명화하여 정리한 것입니다.

### Case 1: RAG 챗봇이 경쟁사 문서를 답변에 포함

**상황**: 한 제조업 고객이 사내 기술 문서 Q\&A 챗봇을 개발했습니다. 데모에서 잘 동작하여 별도 평가 없이 전사 배포했습니다.

| 항목                 | 내용                                                                                |
| ------------------ | --------------------------------------------------------------------------------- |
| **발견 시점**          | 배포 2주 후, 영업팀 직원이 고객 미팅에서 챗봇을 시연하던 중                                               |
| **증상**             | "당사 제품의 내구성 테스트 기준은?"이라는 질문에 경쟁사의 기술 스펙 문서 내용이 답변에 포함됨                            |
| **원인**             | Vector Store에 인덱싱할 때 검색 범위를 제한하지 않음. 웹 크롤링으로 수집한 데이터에 경쟁사 기술 백서가 포함되어 있었음         |
| **피해**             | 고객사 앞에서 경쟁사 정보를 자사 정보처럼 제시. 신뢰도 하락 및 영업 기회 상실                                     |
| **평가로 방지 가능했던 방법** | Groundedness 메트릭으로 출처 추적 테스트. "답변의 근거가 자사 공식 문서에 있는가?" 검증. 검색된 문서의 출처 도메인 필터링 테스트 |

### Case 2: Agent가 SQL DELETE를 실행하여 프로덕션 데이터 삭제

**상황**: 데이터 분석 Agent에 SQL 실행 Tool을 연결하여 자연어로 데이터 조회가 가능하도록 구축했습니다. 개발 환경에서 SELECT 쿼리 위주로 테스트한 후 배포했습니다.

| 항목                 | 내용                                                                                                                        |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| **발견 시점**          | 배포 3일 후, 사용자가 "지난달 잘못 입력된 데이터를 정리해줘"라고 요청                                                                                 |
| **증상**             | Agent가 `DELETE FROM orders WHERE created_at < '2024-02-01'`을 실행하여 프로덕션 주문 테이블에서 1만 건 이상의 레코드를 삭제                          |
| **원인**             | Agent에 READ-ONLY 권한 제한을 하지 않음. Tool 실행 전 확인 단계 없음. "정리"라는 모호한 지시를 DELETE로 해석                                              |
| **피해**             | 프로덕션 데이터 손실. 백업에서 복구하는 데 6시간 소요. 해당 시간 동안 서비스 장애                                                                          |
| **평가로 방지 가능했던 방법** | Tool Selection Accuracy 평가에서 "삭제/수정 의도의 질문"을 테스트. Agent가 위험한 작업을 거부하거나 확인을 요청하는지 검증. Safety 메트릭에 "데이터 변경 작업 시 확인 프로세스" 포함 |

### Case 3: 고객 지원 봇이 존재하지 않는 환불 정책을 안내

**상황**: 이커머스 고객 지원 챗봇을 출시했습니다. FAQ 문서를 기반으로 RAG를 구축했으나, 환불 관련 엣지 케이스 질문에 대한 평가를 수행하지 않았습니다.

| 항목                 | 내용                                                                                                                                    |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------- |
| **발견 시점**          | 배포 1주일 후, 고객이 "챗봇이 30일 무조건 환불이라고 했다"며 CS팀에 항의                                                                                         |
| **증상**             | "개봉한 전자제품도 환불되나요?"라는 질문에 "모든 제품은 구매 후 30일 이내 무조건 환불 가능합니다"라고 답변. 실제 정책은 "전자제품은 미개봉 시에만 14일 이내 환불 가능"                                  |
| **원인**             | 환불 정책 문서에 일반 환불 조건(30일)과 전자제품 예외 조건이 별도 섹션에 존재. LLM이 일반 조건만 참조하여 답변 생성 (Hallucination의 일종)                                            |
| **피해**             | 챗봇 안내를 근거로 환불을 요구하는 고객 다수 발생. 일부는 소비자 보호원에 민원 제기. 법무팀 검토 비용 및 보상 비용 발생                                                                |
| **평가로 방지 가능했던 방법** | Faithfulness 평가에서 "예외 조건이 있는 정책 질문" 테스트. Answer Completeness 평가로 "조건부 답변이 필요한 질문"에서 모든 조건을 포함하는지 검증. 엣지 케이스 평가셋에 "\~도 되나요?" 유형의 질문 포함 |

> **위험**
> **공통 패턴**: 세 사례 모두 "데모에서는 잘 동작했다"는 공통점이 있습니다. 데모는 보통 Happy Path만 테스트합니다. 프로덕션에서는 예상치 못한 질문, 악의적 의도, 모호한 표현이 끊임없이 들어옵니다. **평가는 "잘 되는 경우"가 아니라 "실패하는 경우"를 찾기 위한 것** 입니다.

> **참고**
> **비용 비교**: 위 세 가지 사례에서 발생한 직접 비용(데이터 복구, 법무 검토, 보상금)만 합산해도 수천만 원입니다. 반면, 100\~200개 평가셋으로 Offline 평가를 수행하는 비용은 LLM-as-Judge 기준 수만 원, 인건비 포함해도 수십만 원 수준입니다. **평가 비용은 사고 비용의 1% 미만** 입니다.

***

## 서브 페이지

| 페이지                            | 내용                                                                                                       |
| ------------------------------ | -------------------------------------------------------------------------------------------------------- |
| [핵심 평가 메트릭](metrics)           | Faithfulness, Relevance, Groundedness, Correctness, Context Relevance, Completeness, 안전성, 검색 메트릭, 운영 메트릭 |
| [Human vs LLM-as-Judge](judge) | Human Evaluation vs LLM-as-Judge 비교, LLM-as-Judge 패턴과 한계, MLflow Evaluate, MLflow 3 Scorer               |
| [평가 파이프라인](pipeline)           | 평가 데이터셋 설계, Offline vs Online 평가, CI/CD Gate, A/B 테스트                                                    |
| [실전 적용](practical)             | Review App 워크플로우, 업종별 평가, 전문가 노하우, 고객 FAQ, 연습문제                                                          |