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