LLM 품질 평가 기준 설계

Summary

모델 순위나 일반 벤치마크 점수만으로는 업무 품질을 판단할 수 없습니다. 실제 사용자가 겪는 입력, 필요한 근거, 허용할 오류, 사람의 최종 판단을 포함한 평가 세트를 만들어야 합니다. 모델·프롬프트·도구를 바꿀 때마다 같은 기준으로 다시 측정하세요.

평가를 시작하는 질문

질문	예시
성공은 무엇인가	답변이 공식 문서의 근거를 빠뜨리지 않는다
실패는 무엇인가	근거 없는 정책·가격·법률 주장을 사실처럼 쓴다
누가 판단하는가	도메인 담당자와 실제 사용자
얼마나 자주 보는가	배포 전, 모델·프롬프트 변경 시, 정기 표본 검토

네 단계 평가 흐름

flowchart LR
  A[대표 작업 수집] --> B[기대 결과·금지 결과 정의]
  B --> C[자동 검사와 사람 검토]
  C --> D[실패 원인 분류]
  D --> E[프롬프트·도구·데이터·UI 개선]
  E --> C

품질 차원 선택하기

모든 항목을 한 번에 측정하지 말고 업무에 중요한 세 가지에서 시작하세요.

차원	확인 방법
사실성	원문 URL·숫자·인용을 담당자가 대조
충실성	제공한 문서 밖의 정보를 사실처럼 더하지 않는지 확인
완결성	필요한 필드와 예외가 빠지지 않았는지 체크리스트 검사
실행 가능성	다음 행동·담당자·승인 지점이 분명한지 검토
안전성	민감 정보·유해 표현·권한 초과 행동을 막는지 확인
사용성	실제 사용자가 이해하고 고칠 수 있는 형식인지 평가

현재 배포된 앱을 기준으로 한 평가 예시

Agent Lab의 콘텐츠 최신화 보조를 평가한다고 가정합니다. 대표 원고 열 개와 공식 출처 URL을 준비합니다.

테스트	통과 기준	실패 예시
오래된 주장 찾기	변할 수 있는 모델·가격·기능 문장을 표시	기억에 의존해 새 사양을 지어냄
출처 제안	공식 원문 URL 또는 ‘확인 필요’를 남김	검색 결과 요약을 근거처럼 제시
수정 초안	원문의 의도를 보존하고 단정을 피함	원문에 없는 성과·출시일을 추가
화면 검토	검토일과 출처가 실제 페이지에 보임	빌드만 통과하고 배포 화면은 확인하지 않음

점수 하나보다 실패 사례의 분류가 더 중요합니다. 실패를 “입력 부족”, “평가 기준 모호”, “도구 권한”, “모델 응답”, “화면·운영 문제”로 나누면 다음 개선이 구체적이 됩니다.

자동 평가와 사람 검토의 역할

방식	맡길 일	주의할 점
규칙 검사	필수 필드, URL 형식, 금지어, JSON 구조	통과해도 의미·사실성은 보장하지 않음
모델 기반 평가	분류·누락 후보 찾기	장황함·자기 선호 같은 편향을 점검
사람 검토	사실, 맥락, 위험, 실제 사용성 판단	평가 기준과 샘플링 방법을 문서화

OpenAI의 최신 모델 가이드는 변경을 한 번에 많이 하지 말고 대표 작업으로 기준선을 만들고 다시 평가하라고 권합니다. 평가는 배포 전의 관문이면서, 운영 중 개선을 위한 관측 장치입니다.

최소 평가 템플릿

작업 이름:
입력과 허용한 근거:
기대 결과:
절대 허용하지 않는 결과:
자동 검사:
사람 검토자와 판정 기준:
실패 분류:
변경 후 재평가 날짜:

공식 자료

• OpenAI 최신 모델 가이드
• OpenAI 프롬프트 엔지니어링 가이드