LLM 답변 품질 평가 운영 가이드: 골든셋과 자동 채점으로 회귀를 막기

LLM 기능은 배포 후에도 계속 평가해야 합니다

LLM을 붙인 검색, 상담, 문서 작성 기능은 처음 데모가 잘 보였다고 해서 운영 품질이 보장되지 않습니다. 프롬프트 한 줄, 검색 대상 문서, 모델 버전, 온도 값, 후처리 로직이 바뀌면 같은 질문에도 다른 답이 나올 수 있습니다. 그래서 AI 기능은 일반 API처럼 단위 테스트만으로 끝내기 어렵고, 실제 사용 질문을 모은 골든셋과 자동 채점 흐름을 함께 운영해야 합니다. 목표는 모델을 완벽하게 통제하는 것이 아니라, 중요한 실패가 배포 전에 드러나도록 만드는 것입니다.

먼저 골든셋을 작게 시작합니다

골든셋은 품질 기준이 붙은 대표 질문 묶음입니다. 처음부터 수천 건을 만들 필요는 없습니다. 실제 고객 문의, 내부 직원이 자주 묻는 업무 질문, 장애가 났던 질문, 법무나 금액처럼 틀리면 위험한 질문을 우선으로 30건에서 100건 정도만 고릅니다. 각 항목에는 질문만 넣지 말고 기대 답변의 핵심 사실, 금지해야 할 표현, 참조해야 할 문서, 허용 가능한 답변 범위를 같이 기록합니다. 정답 문장 하나에 과도하게 묶으면 LLM의 자연스러운 표현 차이를 실패로 오판할 수 있으므로 핵심 조건 중심으로 적는 것이 좋습니다.

• 빈번한 질문: 실제 사용량이 많은 질문을 우선 포함합니다.
• 고위험 질문: 가격, 계약, 개인정보, 보안, 정책 관련 질문을 별도로 표시합니다.
• 검색 의존 질문: 답변 근거 문서와 문서 버전을 기록합니다.
• 과거 실패 질문: 환각, 누락, 잘못된 링크가 발생했던 질문을 회귀 테스트로 남깁니다.

평가 데이터는 기계가 읽기 쉬운 형식으로 둡니다

운영에서는 스프레드시트보다 JSONL이나 데이터베이스 테이블이 재현성과 자동화에 유리합니다. 한 줄에 한 테스트 케이스를 담고, 테스트 ID를 바꾸지 않으면 과거 결과와 비교하기 쉽습니다. 기대 답변 전체를 긴 문장으로 저장하기보다 mustContain, mustNotContain, expectedSources, riskLevel 같은 필드를 나누면 규칙 기반 채점과 LLM 채점을 섞어 쓰기 쉽습니다.

{'id':'price-policy-001','question':'유지보수 계약 해지 시 환불 기준을 알려주세요','mustContain':['계약서 기준','남은 기간','서면 요청'],'mustNotContain':['무조건 전액 환불','즉시 환불 보장'],'expectedSources':['contract/refund-policy.md'],'riskLevel':'high'}
{'id':'rag-source-014','question':'관리자 비밀번호 초기화 절차는 무엇인가요?','mustContain':['본인 확인','관리자 승인','임시 비밀번호 만료'],'mustNotContain':['DB에서 직접 변경'],'expectedSources':['ops/account-reset.md'],'riskLevel':'high'}

자동 채점은 규칙 기반부터 붙입니다

LLM 평가라고 해서 모든 판단을 다시 LLM에게 맡길 필요는 없습니다. 반드시 포함되어야 하는 단어, 금지어, 출처 URL, JSON 스키마, 응답 길이, 개인정보 마스킹 여부는 규칙으로 먼저 검사하는 편이 빠르고 일관됩니다. 특히 업무 시스템에서는 형식 오류가 실제 장애로 이어집니다. 예를 들어 상담 요약 API가 JSON을 반환해야 한다면 답변의 설득력보다 먼저 JSON 파싱 성공 여부와 필수 필드 존재 여부를 검사해야 합니다.

const tests = [
  {
    id: 'account-reset-001',
    mustContain: ['본인 확인', '관리자 승인'],
    mustNotContain: ['DB에서 직접 변경']
  }
];

function scoreAnswer(answer, test) {
  const missing = test.mustContain.filter(term => !answer.includes(term));
  const forbidden = test.mustNotContain.filter(term => answer.includes(term));
  return {
    id: test.id,
    pass: missing.length === 0 && forbidden.length === 0,
    missing,
    forbidden
  };
}

LLM 채점은 기준표를 고정해야 합니다

규칙으로 잡기 어려운 정확성, 맥락 적합성, 과도한 추측 여부는 LLM 채점기를 보조로 사용할 수 있습니다. 다만 채점 프롬프트가 매번 바뀌면 평가 결과도 흔들립니다. 채점 기준표를 1점부터 5점까지 명확히 정의하고, 답변이 근거 문서 밖의 내용을 단정하면 감점한다는 규칙을 명시합니다. 고위험 질문은 평균 점수만 보지 말고, 근거 없음, 금지 표현 포함, 정책 위반 같은 실패 사유를 별도 컬럼으로 저장해야 합니다. 그래야 다음 프롬프트 수정 때 무엇을 고쳐야 하는지 보입니다.

배포 파이프라인에 회귀 기준을 겁니다

평가가 진짜 효과를 내려면 사람이 기억날 때만 실행하는 방식이 아니라 CI나 배포 전 점검에 들어가야 합니다. 모든 케이스를 매번 돌리기 어렵다면 빠른 스모크셋과 전체 회귀셋을 분리합니다. 스모크셋은 배포마다 실행하고, 전체 회귀셋은 야간 배치나 모델 변경 전에 실행합니다. 기준은 단순해야 합니다. 예를 들어 전체 통과율 92퍼센트 이상, high 위험 케이스 100퍼센트 통과, 이전 배포 대비 평균 점수 0.2점 이상 하락 금지처럼 정합니다.

• 프롬프트 변경: 스모크셋과 관련 도메인 골든셋을 실행합니다.
• 검색 문서 변경: expectedSources가 있는 RAG 케이스를 우선 실행합니다.
• 모델 변경: 전체 회귀셋을 실행하고 비용과 지연 시간도 함께 비교합니다.
• 후처리 변경: JSON 스키마, 링크, 마스킹, 금지어 규칙을 집중 확인합니다.

운영 로그를 다음 골든셋으로 되돌립니다

초기 골든셋은 완성품이 아니라 시작점입니다. 운영 중 사용자가 다시 질문한 사례, 상담원이 수동으로 고친 답변, 출처가 없어서 신뢰하지 못한 답변, 답변은 맞지만 너무 길어서 사용되지 않은 사례를 주기적으로 골든셋에 추가해야 합니다. 이때 원문 질문과 답변을 그대로 저장하기 전에 개인정보와 고객 식별자를 제거하는 절차가 필요합니다. 평가 데이터 자체가 민감 정보 저장소가 되면 운영 리스크가 커집니다.

실전 체크리스트

• 대표 질문 30건 이상으로 시작하고, 고위험 질문을 별도 표시합니다.
• 기대 답변은 문장 하나가 아니라 포함 조건, 금지 조건, 참조 문서로 나눕니다.
• 형식, 금지어, 출처, 필수 키워드는 규칙 기반으로 먼저 채점합니다.
• LLM 채점기는 고정된 기준표와 실패 사유 컬럼을 사용합니다.
• 배포 전 스모크셋, 모델 변경 전 전체 회귀셋을 실행합니다.
• 운영 실패 사례를 개인정보 제거 후 골든셋에 계속 추가합니다.