참고 학습 목표
- 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% 미만 입니다.
서브 페이지
| 페이지 | 내용 |
|---|---|
| 핵심 평가 메트릭 | Faithfulness, Relevance, Groundedness, Correctness, Context Relevance, Completeness, 안전성, 검색 메트릭, 운영 메트릭 |
| Human vs LLM-as-Judge | Human Evaluation vs LLM-as-Judge 비교, LLM-as-Judge 패턴과 한계, MLflow Evaluate, MLflow 3 Scorer |
| 평가 파이프라인 | 평가 데이터셋 설계, Offline vs Online 평가, CI/CD Gate, A/B 테스트 |
| 실전 적용 | Review App 워크플로우, 업종별 평가, 전문가 노하우, 고객 FAQ, 연습문제 |