LLM 기능은 배포 전 평가 기준이 있어야 안정됩니다

LLM을 붙인 챗봇, 사내 검색, 문서 요약, 고객 응대 자동화는 처음 데모에서는 잘 동작하는 것처럼 보입니다. 하지만 운영에 들어가면 같은 질문에도 답변 형식이 달라지고, 검색된 근거를 놓치거나, 금지한 문장을 다시 말하거나, 새 모델로 바꾼 뒤 품질이 조용히 떨어지는 문제가 생깁니다. 이런 문제는 프롬프트를 더 길게 쓰는 것만으로 해결되지 않습니다. 제품 기능처럼 테스트셋, 채점 기준, 회귀 점검을 만들어야 변경의 영향을 확인할 수 있습니다.

실무에서 LLM 평가는 거창한 연구 프로젝트로 시작할 필요가 없습니다. 먼저 자주 들어오는 질문 30개에서 100개를 모으고, 각 질문에 대해 반드시 지켜야 할 조건을 적습니다. 예를 들어 고객센터 봇이라면 환불 정책을 틀리게 말하지 않아야 하고, 내부 문서 검색이라면 근거 문서 제목과 날짜를 함께 제시해야 하며, 개발 보조 기능이라면 실행 가능한 코드와 주의사항을 함께 제공해야 합니다. 이 조건을 사람이 읽을 수 있는 테스트 케이스로 만들고, 배포 전 자동 실행하면 모델, 프롬프트, 검색 파이프라인 변경에 따른 품질 저하를 빠르게 잡을 수 있습니다.

1. 평가 대상을 기능 단위로 좁힙니다

처음부터 모든 대화를 평가하려고 하면 기준이 흐려집니다. 먼저 실제 서비스에서 사고가 나면 비용이 큰 기능을 하나 고릅니다. 추천 답변, 약관 안내, 장애 대응 요약, 견적 문의 분류, RAG 기반 문서 질의처럼 결과를 비교하기 쉬운 기능이 좋습니다. 각 기능마다 입력, 기대 행동, 금지 행동, 필요한 근거, 출력 형식을 분리해서 적으면 평가 기준이 명확해집니다.

• 입력: 사용자의 질문, 대화 이력, 검색된 문서 조각, 시스템 지시문을 구분합니다.
• 기대 행동: 답변해야 할 핵심 사실, 필요한 단계, 말투와 형식을 정합니다.
• 금지 행동: 추측, 정책 위반 문장, 없는 링크, 내부 정보 노출을 적습니다.
• 판정 방식: 사람이 직접 볼 항목과 자동으로 검사할 항목을 나눕니다.

평가 기준은 정답 문장 하나와 완전히 같아야 한다는 식으로 잡으면 실패하기 쉽습니다. LLM은 표현이 달라질 수 있으므로 핵심 조건을 만족했는지 확인하는 방식이 실무에 더 맞습니다. 다만 주문 번호, 금액, 날짜, 법적 문구처럼 정확히 맞아야 하는 값은 정규식이나 문자열 검사로 강하게 검증해야 합니다.

2. 테스트셋은 운영 사례에서 만듭니다

좋은 테스트셋은 상상한 질문보다 실제 사용자의 질문에서 나옵니다. 로그를 그대로 복사하기 전에 개인정보와 회사 기밀을 제거하고, 비슷한 질문은 하나로 묶습니다. 단순 성공 사례만 넣으면 배포 전 품질이 좋아 보이는 착시가 생기므로 애매한 질문, 짧은 질문, 오타가 있는 질문, 정책 경계에 걸린 질문, 검색 결과가 부족한 질문도 포함해야 합니다.

cases:
  - id: refund-policy-001
    input: 배송 전 주문 취소하면 수수료가 있나요?
    expects:
      - 배송 전 취소 가능 여부를 설명한다
      - 수수료가 있는지 정책 기준으로 답한다
      - 확인이 필요한 경우 고객센터 연결을 안내한다
    forbids:
      - 근거 없이 전액 환불을 확정한다
      - 존재하지 않는 약관 링크를 만든다
    required_citations:
      - 환불 정책
  - id: internal-search-007
    input: 2025년 보안 점검 절차가 바뀐 부분만 알려줘
    expects:
      - 변경된 항목을 목록으로 정리한다
      - 문서명과 개정일을 함께 표시한다
    forbids:
      - 검색 결과에 없는 절차를 추측한다

이런 형태의 YAML이나 JSON 파일은 개발자와 현업 담당자가 함께 읽기 쉽습니다. 현업 담당자는 expects와 forbids를 보며 정책 기준을 검토하고, 개발자는 이 파일을 자동 평가 스크립트에 연결할 수 있습니다. 처음에는 20개만 만들어도 충분합니다. 중요한 것은 완벽한 테스트셋을 한 번에 만드는 것이 아니라 장애가 생길 때마다 케이스를 추가하는 운영 습관입니다.

3. 자동 검사는 규칙 기반과 LLM 채점을 섞습니다

LLM 평가를 모두 다른 LLM에게 맡기면 비용이 늘고 판정이 흔들릴 수 있습니다. 반대로 문자열 검사만 사용하면 의미는 맞지만 표현이 다른 답변을 놓칩니다. 그래서 실무에서는 규칙 기반 검사를 먼저 돌리고, 의미 판단이 필요한 항목만 LLM 심사 모델에 맡기는 혼합 방식이 효율적입니다. 예를 들어 답변에 문서 출처가 포함됐는지, JSON 형식이 깨지지 않았는지, 금지어가 나왔는지는 코드로 확인합니다. 설명이 충분한지, 사용자의 질문에 맞게 범위를 제한했는지는 LLM 채점으로 확인합니다.

#!/usr/bin/env node
const result = {
  answer: process.env.ANSWER || '',
  citations: (process.env.CITATIONS || '').split(',').filter(Boolean)
};

const checks = [
  {
    name: '출처 문서 포함',
    pass: result.citations.length > 0
  },
  {
    name: '없는 확정 표현 금지',
    pass: !/무조건|항상 전액|100% 보장/.test(result.answer)
  },
  {
    name: '고객센터 안내 포함',
    pass: /고객센터|상담|문의/.test(result.answer)
  }
];

for (const check of checks) {
  console.log(`${check.pass ? 'PASS' : 'FAIL'} ${check.name}`);
}

if (checks.some((check) => !check.pass)) {
  process.exit(1);
}

위 예시는 단순하지만 배포 파이프라인에 넣기 좋습니다. 실제 환경에서는 각 테스트 케이스마다 필수 정규식, 금지 정규식, 필수 출처 개수, 최대 응답 길이, JSON 스키마 검증을 붙일 수 있습니다. LLM 채점은 1점부터 5점까지 점수를 주게 하는 것보다 통과와 실패를 명확히 나누는 기준이 운영에 유리합니다. 점수 평균만 보면 치명적인 한 케이스 실패가 묻힐 수 있기 때문입니다.

4. RAG 기능은 검색 품질과 생성 품질을 분리합니다

문서 기반 답변이 틀렸을 때 원인이 검색인지 생성인지 구분하지 않으면 개선 방향을 잡기 어렵습니다. 검색 단계에서 필요한 문서가 상위 결과에 없었다면 임베딩 모델, 청킹, 메타데이터 필터, 재랭킹을 점검해야 합니다. 반대로 검색 결과에는 정답이 있었는데 답변이 틀렸다면 프롬프트, 컨텍스트 압축, 답변 형식, 출처 강제 규칙을 봐야 합니다. 평가 리포트에는 최종 답변 점수뿐 아니라 검색된 문서 목록과 순위를 함께 남기는 것이 좋습니다.

• 검색 평가: 정답 문서가 top 3 또는 top 5 안에 들어왔는지 확인합니다.
• 생성 평가: 검색 결과에 없는 내용을 말하지 않았는지 확인합니다.
• 출처 평가: 답변의 핵심 문장과 출처 문서가 서로 맞는지 확인합니다.
• 거절 평가: 근거가 부족할 때 모른다고 말하고 추가 확인을 안내하는지 봅니다.

특히 내부 지식 검색에서는 최신 문서와 폐기된 문서가 섞이는 문제가 자주 생깁니다. 테스트 케이스에 문서 개정일, 부서, 제품 버전 같은 메타데이터 조건을 넣으면 오래된 문서가 답변에 섞이는 회귀를 잡을 수 있습니다.

5. 배포 파이프라인에 품질 기준선을 둡니다

평가 자동화의 목적은 보고서를 예쁘게 만드는 것이 아니라 나쁜 변경을 막는 것입니다. 모델 버전, 프롬프트, 검색 인덱스, 청킹 규칙, 시스템 메시지가 바뀔 때마다 같은 테스트셋을 실행하고 이전 결과와 비교해야 합니다. 전체 통과율이 95% 이상이어도 결제, 보안, 개인정보, 법무 관련 케이스가 하나라도 실패하면 배포를 막는 식으로 위험도별 기준을 다르게 두는 것이 좋습니다.

npm run build
node scripts/run-llm-evals.js --cases evals/customer-support.yml --report reports/eval.json
node scripts/check-eval-threshold.js --min-pass-rate 0.92 --block-critical true

평가 결과는 날짜, 모델명, 프롬프트 버전, 인덱스 버전, 실패 케이스, 실제 답변을 함께 저장합니다. 그래야 나중에 장애가 발생했을 때 어느 변경부터 품질이 흔들렸는지 추적할 수 있습니다. 또한 실패 케이스를 고친 뒤에는 해당 사례를 테스트셋에 영구 추가해야 같은 문제가 다시 들어오지 않습니다.

운영 체크리스트

LLM 품질 평가는 한 번의 성능 측정이 아니라 지속적인 운영 장치입니다. 작게 시작하려면 핵심 기능 하나를 고르고, 실제 로그에서 개인정보를 제거한 질문 30개를 만들고, 각 케이스마다 기대 행동과 금지 행동을 적습니다. 그다음 정규식, 출처 개수, JSON 스키마 같은 규칙 기반 검사를 먼저 붙이고, 의미 판단이 필요한 항목만 LLM 채점으로 보강합니다. 배포 전에는 같은 테스트셋을 반복 실행해 이전 결과와 비교하고, 치명 케이스 실패는 통과율과 무관하게 배포를 중단해야 합니다.

• 기능 단위로 평가 범위를 좁혔는지 확인합니다.
• 운영 로그에서 나온 실제 질문을 테스트셋에 반영합니다.
• 기대 행동, 금지 행동, 필수 출처를 케이스마다 명시합니다.
• 검색 품질과 생성 품질을 따로 기록합니다.
• 모델, 프롬프트, 인덱스 변경 때마다 같은 평가를 실행합니다.
• 실패한 운영 사례는 다음 배포부터 회귀 테스트에 포함합니다.