참고 학습 목표
- GenAI 평가가 전통 ML 평가와 근본적으로 다른 이유를 설명할 수 있다
- Faithfulness, Relevance, Groundedness 등 핵심 메트릭을 구체적 예시로 구분할 수 있다
- Human Evaluation과 LLM-as-Judge의 장단점을 비교하여 적합한 방법을 선택할 수 있다
- MLflow Evaluate를 사용하여 Agent를 평가하는 코드를 작성할 수 있다
- Review App을 활용한 피드백 수집 → 개선 워크플로우를 설계할 수 있다
왜 GenAI 평가가 특별히 어려운가?
전통 ML과 GenAI는 평가 패러다임이 근본적으로 다릅니다.주의 핵심 문제: “서울의 맛집을 추천해주세요”라는 질문에 정답이 하나가 아닙니다. “강남역 근처 이탈리안 레스토랑”도, “을지로 골목 칼국수집”도 좋은 답변이 될 수 있습니다. 이런 환경에서 어떻게 “품질”을 측정할 것인가가 GenAI 평가의 핵심 과제입니다.
위험 “잘 동작하는 것 같다”라는 주관적 판단만으로 프로덕션에 배포하면, 환각(Hallucination)이나 유해 응답 문제가 발생할 수 있습니다. 반드시 체계적으로 평가하세요.
평가 없이 배포하면 벌어지는 일
“평가는 나중에 하겠다”는 말은 50개 이상의 LLM 프로젝트를 진행하면서 가장 많이 들은 말이고, 동시에 가장 큰 사고로 이어진 말입니다. 아래는 실제 프로젝트에서 발생한 사례를 익명화하여 정리한 것입니다.Case 1: RAG 챗봇이 경쟁사 문서를 답변에 포함
상황: 한 제조업 고객이 사내 기술 문서 Q&A 챗봇을 개발했습니다. 데모에서 잘 동작하여 별도 평가 없이 전사 배포했습니다.Case 2: Agent가 SQL DELETE를 실행하여 프로덕션 데이터 삭제
상황: 데이터 분석 Agent에 SQL 실행 Tool을 연결하여 자연어로 데이터 조회가 가능하도록 구축했습니다. 개발 환경에서 SELECT 쿼리 위주로 테스트한 후 배포했습니다.Case 3: 고객 지원 봇이 존재하지 않는 환불 정책을 안내
상황: 이커머스 고객 지원 챗봇을 출시했습니다. FAQ 문서를 기반으로 RAG를 구축했으나, 환불 관련 엣지 케이스 질문에 대한 평가를 수행하지 않았습니다.위험 공통 패턴: 세 사례 모두 “데모에서는 잘 동작했다”는 공통점이 있습니다. 데모는 보통 Happy Path만 테스트합니다. 프로덕션에서는 예상치 못한 질문, 악의적 의도, 모호한 표현이 끊임없이 들어옵니다. 평가는 “잘 되는 경우”가 아니라 “실패하는 경우”를 찾기 위한 것 입니다.
참고 비용 비교: 위 세 가지 사례에서 발생한 직접 비용(데이터 복구, 법무 검토, 보상금)만 합산해도 수천만 원입니다. 반면, 100~200개 평가셋으로 Offline 평가를 수행하는 비용은 LLM-as-Judge 기준 수만 원, 인건비 포함해도 수십만 원 수준입니다. 평가 비용은 사고 비용의 1% 미만 입니다.