CI에서 LLM-as-judge를 5단계 분류에서 이진 분류로 전환하기: 유지한 패턴들

몇 달 전, 우리의 LLM-as-judge는 1점에서 5점 사이의 유용성 척도로 작동했습니다. 우리는 그 점수의 평균을 사용했기 때문에 CI 게이트(CI gate)는 계속 초록색(통과)을 유지했습니다. 인간과의 스팟 체크(Spot-checking) 결과 Cohen's kappa 계수는 0.47로 나타났습니다. 문제는 도구가 아니라 루브릭(Rubric, 평가 기준)이었습니다. 동일한 라벨러(Labeller)들이 기준별 이진(Binary) 평가로 재평가했을 때 0.78에 도달했습니다. CI 파이프라인(CI pipeline)은 새로운 형태를 학습해야 했습니다. 이 포스트는 방법론적 결정 이후에 이루어진 엔지니어링 작업에 관한 것입니다.

전쟁 이야기가 아닙니다. 패턴 공유입니다.

Promptfoo 설정에서 변경된 점

# 이전: 단일 5단계 분류 어설션(assertion)
assertions:
  - type: llm-rubric
...

가장 먼저 깨지는 부분은 기존의 통과 임계값(pass-threshold) 로직입니다. 이전 게이트는 "평균 점수가 3.5 미만이면 실패"였습니다. 새로운 게이트는 4개의 별도 신호를 가집니다.

임계값 문제

우리는 세 가지 임계값 패턴을 시도했습니다:

1. 결합(Conjunction): 어떤 기준이라도 통과율(pass rate)이 90% 미만으로 떨어지면 실패 처리. 엄격함. 회귀(Regression)를 30% 더 많이 잡아냈지만, 노이즈에도 민감하게 반응했습니다.
2. 가중 합계(Weighted sum): 가중치 부여 (정확도 0.4, 근거성(groundedness) 0.3, 형식 0.2, 질문 답변 여부 0.1), 가중 점수가 임계값 미만이면 실패. 튜닝하기 더 쉬움.
3. 기준별 임계값(Per-criterion thresholds): 각 기준마다 고유한 통과율 임계값을 가짐. 기준별 회귀를 잡아냄. 유지 관리해야 할 코드가 가장 많음.

우리는 일일 CI 게이트로는 옵션 2를, 주간 심층 점검(weekly deep check)으로는 옵션 3을 선택했습니다. 옵션 1은 일주일간의 오탐(false positives) 발생 이후 폐기했습니다.

더 어려워진 점

(a) 대시보드(Dashboards). 이전 Datadog 패널은 한 줄이었습니다. 새로운 패널은 4개의 줄에 가중 점수(weighted-score) 줄이 추가되었습니다. 운영자들은 새로운 레이아웃을 익혀야 합니다.

(b) 심판 프롬프트(Judge prompt) 자체. 각 이진 기준은 고유한 프롬프트가 필요합니다. 우리는 복사해서 붙여넣고 수정하는 방식으로 시작했는데, 그것은 실수였습니다. 기준들에 대해 사전에 논의가 이루어져야 하며 프롬프트가 신중하게 작성되어야 합니다. 그렇지 않으면 프롬프트 수준에서 평가자 드리프트(rater drift)가 다시 스며들게 됩니다.

(c) 캘리브레이션 세트(Calibration set) 라벨링 비용. 트레이스(trace)당 라벨 수가 4배로 늘어났습니다. 우리는 캘리브레이션 세트를 200개 트레이스에서 100개 트레이스로 줄임으로써 이를 보완했습니다. 그럼에도 안정적인 kappa 값을 얻었습니다.

더 쉬워진 점

(a) 회귀(Regressions) 디버깅. 근거성(Groundedness)은 유지되는데 정확도(Accuracy)의 kappa 값이 떨어진다면, 프롬프트 변경이 검색(Retrieval)이 아닌 생성(Generation)을 망가뜨렸음을 의미합니다. 단일 점수 방식은 이러한 신호를 평균화하여 없애버렸습니다.

(b) 기준별 알림(Per-criterion alerting). 새벽 3시에 형식 준수(Format compliance)의 kappa 값이 급락했다면 JSON 파서(Parser)가 고장 났음을 의미합니다. 전용 알림을 설정하고, 해당 이슈로 페이징(Page)을 보냅니다.

(c) 인간의 스팟 체크(Spot-check) 루프. 기준별로 검토하는 것이 5단계 전체 루브릭(Rubric)을 다시 읽는 것보다 빠릅니다. 우리의 주간 캘리브레이션(Calibration) 작업 시간은 90분에서 50분으로 단축되었습니다.

전환을 진행 중인 친구에게 해주고 싶은 말

CI 파이프라인(Plumbing)을 구축하는 것은 간단한 부분입니다. 진짜 어려운 작업은 판사(Judge) 프롬프트 자체에 들어갑니다. 각 이진 기준(Binary criterion)은 기능 프롬프트(Feature prompt)와 동일한 정성을 들여야 합니다. 의도적으로 작성하고, git에서 버전 관리하며, 인간과 비교하여 캘리브레이션하고, 시간이 지남에 따라 기준별 kappa 값을 모니터링하세요.

기본적으로 3개 또는 4개의 기준을 설정하세요. 우리는 6개를 시도해 보았으나 라벨링 비용(Labelling cost) 때문에 큰 어려움을 겪었습니다. 2개는 너무 많은 정보를 숨깁니다. 우리의 데이터에서는 4개가 최적의 지점(Sweet spot)이었지만, 여러분의 트레이스(Traces)에는 다를 수 있습니다.

토론

이런 전환을 해보신 다른 분이 계신가요? 어떤 기준들로 결정하셨나요? 그리고 임계값 튜닝(Threshold tuning)은 어떻게 진행되었나요?