7장. 평가를 테스트처럼 실행하라

평가도 코드의 한 종류다

“지난주에 몇 개 질문해 봤는데 괜찮았다”는 검증은 반복할 수 없다. 누가 무엇을 물었는지, 어떤 버전이었는지, 통과 기준이 무엇인지 남지 않기 때문이다. 평가를 명령 한 번으로 실행하고 결과를 파일로 저장하면 코드 변경과 같은 검토 흐름에 넣을 수 있다.

npm run lab:eval

이 명령은 여섯 fixture를 실행해 build/eval-report.json을 만든다. 각 행에는 요청 ID, 기대 결과, 실제 결과와 마스킹된 트레이스가 있다. 요약 지표만 저장하지 않는 이유는 실패한 한 건을 바로 조사하기 위해서다.

평가기의 세 층

첫 층은 결정적 검사다. JSON 스키마, 필수 필드, 금액 범위, 정확한 상태처럼 코드로 단정할 수 있는 조건을 확인한다. 둘째는 업무 규칙 검사다. 정책 엔진이나 승인된 기대 결과와 비교한다. 셋째는 모델 기반 평가다. 설명의 명료성, 고객 응대 톤처럼 단순 문자열 비교가 어려운 항목을 평가한다.

모델 기반 평가를 가장 먼저 사용하면 불필요한 변동과 비용이 생긴다. decision이 네 값 중 하나인지 확인하는 데 또 다른 모델은 필요 없다. 결정적 검사로 걸러지지 않는 주관적 품질에만 모델 평가기를 사용한다.

모델 평가기도 평가해야 한다

LLM 심사위원은 근거가 아니라 의견을 낼 수 있다. 순서 편향, 길이 편향, 같은 공급자 편향도 생긴다. 사람이 합의한 작은 검증 세트에서 심사위원의 일치율을 먼저 측정한다. 두 답안의 순서를 바꿔도 결과가 안정적인지, 판단 이유가 루브릭의 어느 항목을 가리키는지도 본다.

ClaimOps의 고객 메시지 루브릭 예시는 다음과 같다.

• 결정 상태를 과장하지 않는다.
• 필요한 증거가 있으면 항목을 구체적으로 말한다.
• 내부 정책 전문이나 위험 점수를 노출하지 않는다.
• 수동 검토를 자동 승인처럼 표현하지 않는다.
• 이의 제기 또는 다음 행동을 안내한다.

통계가 말해 주지 않는 것

fixture 여섯 건의 100% 정확도는 신뢰 구간이 넓다. 실제 배포 판단에서는 주요 사유와 금액 구간별 최소 사례 수를 정하고 결과를 나눠 본다. 전체 정확도가 유지되어도 배송 파손 그룹만 크게 나빠질 수 있다.

또한 온라인 트래픽 분포가 평가 세트와 달라지면 점수가 실제 경험을 대표하지 않는다. 프로덕션에서 새 실패 유형을 발견하면 비식별·승인 과정을 거쳐 회귀 세트에 추가한다. 평가 세트는 한 번 만든 시험지가 아니라 운영 지식의 저장소다.

완료 기준

• 결정적, 업무 규칙, 모델 기반 평가를 구분할 수 있다.
• 모델 심사위원이 필요한 항목과 불필요한 항목을 나눴다.
• 평가 실패 한 건에서 관련 트레이스까지 찾아갔다.