이 문서는 GenAI 개념 섹션의 일부입니다.
Human-in-the-Loop: Review App 워크플로우
자동 평가만으로는 한계가 있으므로, 인간 피드백 을 체계적으로 수집하는 것이 중요합니다.Review App 기능
전체 개선 워크플로우 (5단계)
참고 핵심: 이 워크플로우는 일회성이 아닌 지속적 반복 입니다. 프로덕션 운영 중에도 Inference Table에서 실제 사용자 상호작용을 모니터링하고, 품질이 저하되면 즉시 개선 사이클을 시작하세요.
업종별 평가 가이드
모든 GenAI 시스템에 동일한 평가 기준을 적용하는 것은 비용이 높은입니다. 업종과 사용 사례에 따라 최우선 메트릭이 달라지고, 특수한 평가 항목이 추가 됩니다.업종별 특수 평가 항목
금융 서비스:- 수치 정확도 테스트: 매출, 이익률, 주가 등 수치가 소수점까지 정확한지 확인. “약 100억”이 아닌 “103.5억”처럼 정확한 값을 기대
- 면책 조항 포함 여부: 투자 관련 답변에 “투자 권유가 아닙니다” 등의 면책 문구가 포함되는지 확인
- 시점 명시 여부: “현재 주가는 5만원입니다” → “2024년 3월 15일 기준 종가 5만원입니다”처럼 데이터 시점을 명시하는지 확인
- 의료 조언 거부 테스트: “이 증상이면 어떤 약을 먹어야 하나요?” → 직접 처방 대신 의료기관 방문 안내
- 응급 상황 대응: “가슴이 아프고 호흡이 곤란합니다” → 즉시 119 안내
- 민감 정보 보호: 건강 정보, 진단 기록 등 개인 의료 정보 노출 방지
- 판례 존재 확인: 인용된 판례가 실제 존재하는지 검증. LLM은 그럴듯한 가짜 판례를 생성하는 경향이 있음
- 법 개정 반영: 개정된 법률과 구법을 혼동하지 않는지 확인. 시행일 기준 구분
- 관할권 구분: 한국법과 미국법을 혼동하지 않는지 확인
참고 업종별 평가셋은 반드시 해당 도메인 전문가(SME)와 함께 구축하세요. 개발자가 만든 금융 평가 질문은 실제 금융 전문가가 묻는 질문과 다릅니다. SME의 참여 없는 평가셋은 현실성이 떨어집니다.
전문가의 평가 노하우
50개 이상의 LLM 프로젝트에서 얻은 실무 경험을 공유합니다. 이 내용은 공식 문서에 없는 것들입니다.”평가 데이터셋은 제품이다”
많은 팀이 평가셋 구축을 “귀찮은 부수 작업”으로 취급합니다. 하지만 경험적으로 평가셋 품질 = 제품 품질 입니다. 평가셋이 형편없으면 어떤 개선도 측정할 수 없고, 측정할 수 없으면 개선할 수 없습니다. 권장 시간 배분:주의 평가셋에 투자하지 않으면: 프롬프트를 아무리 수정해도 “좋아진 건지 나빠진 건지” 알 수 없습니다. 개발자의 감에 의존하게 되고, 결국 “잘 되는 것 같다”는 주관적 판단으로 배포하게 됩니다. 이것이 위에서 설명한 사고 사례들의 시작점입니다.
평가의 평가 (Meta-evaluation)
LLM-as-Judge를 사용한다면, 반드시 “Judge가 정확하게 평가하고 있는가?” 를 검증해야 합니다. Judge 모델도 틀릴 수 있기 때문입니다. Meta-evaluation 절차:
Cohen’s Kappa 해석:
참고 실무 팁: Meta-evaluation은 프로젝트 초기에 한 번만 하면 되는 것이 아닙니다. Judge 모델을 변경하거나, 평가 기준을 수정하거나, 도메인이 달라질 때마다 다시 수행하세요. “우리 Judge가 아직 유효한가?”를 분기별로 점검하는 것이 좋습니다.
지속적 평가 운영
프로덕션 배포 이후에도 평가는 계속됩니다. 아래는 운영 단계에서의 평가 활동 캘린더입니다.비용 효율적 평가 전략
100% 인간 평가는 비용과 시간 면에서 불가능합니다. 가장 효율적인 전략은 “LLM이 대부분 평가하고, 인간은 어려운 것만 평가” 하는 것입니다. 추천 전략: LLM 90% + 인간 10%성공 가장 효율적인 포인트: 인간이 검토하는 10%를 “낮은 점수”에 집중하면, 전체 평가 품질을 크게 향상시키면서도 비용은 인간 평가의 12% 수준으로 유지할 수 있습니다. 이것이 실무에서 가장 많이 사용되는 패턴입니다.추가로, 인간 검토 결과는 반드시 Judge 프롬프트 개선에 반영하세요. “Judge가 높은 점수를 줬지만 인간이 낮은 점수를 준 사례”를 분석하면 Judge의 맹점을 찾을 수 있고, 이를 프롬프트에 반영하면 다음 평가에서 Judge 정확도가 올라갑니다. 이 피드백 루프가 비용 효율적 평가의 핵심입니다.
고객이 자주 묻는 질문
”평가 없이 바로 배포해도 되나요?”
절대 No. 최소 30개 테스트 질문으로 Offline 평가를 수행해야 합니다. “잘 되는 것 같다”는 데모에서의 인상일 뿐, 프로덕션에서는 예상치 못한 질문에 환각이나 유해 응답이 발생할 수 있습니다. 평가 없는 배포는 테스트 없이 코드를 릴리스하는 것과 같습니다.”평가 비용이 너무 비싸지 않나요?”
LLM-as-Judge로 자동화하면 건당 수 원 수준 입니다. 100개 질문 평가에 수천 원이면 충분합니다. 반면, 환각 응답이 고객에게 전달되었을 때의 비즈니스 손실(신뢰도 하락, 오보 정정, 법적 리스크)은 비교할 수 없이 큽니다.”어떤 메트릭을 봐야 하나요?”
사용 사례에 따라 핵심 메트릭 3~5개에 집중 하세요.흔한 오해 (Common Misconceptions)
GenAI 평가에서 흔히 발생하는 오해 2가지입니다. 이 오해 때문에 평가 체계가 무력화되는 경우가 많습니다.연습 문제
- 사내 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가지와 각각의 대응 방안을 제시하세요.