Promptfoo는 평가 (Eval) 프레임워크가 아니라 CI 게이트입니다. 이를 평가 프레임워크처럼 다루었다가 4,200달러를 낭비했습니다.

지난 월요일, 저는 결제 대시보드에 로그인했다가 주말 동안 발생한 4,200달러의 LangSmith 급증을 확인했습니다. 우리의 자동 평가 (auto-eval) 파이프라인이 새로운 프롬프트 변경 사항에 대해 밤새 실행되고 있었습니다. Promptfoo 회귀 테스트 (regression suite)는 300개의 질문 중 91%를 통과했습니다. 릴리스는 월요일 오전 9시에 진행되었습니다.

화요일 저녁이 되었을 때

그것은 프롬프트 변경이 기존에 알려진 케이스를 망가뜨렸을 때를 알려줄 뿐입니다. 그 이상은 아닙니다.

두 번째 조각: 프로덕션 트레이스(production traces)에 대한 별도의 판사-검증 파이프라인

이전에 존재하지 않았던 부분은 지난주 프로덕션 트레이스(production traces)의 샘플을 가져와서, 인간 라벨러(human labelers)에게 점수를 매기도록 요청하고, 인간과 판사(judge)를 비교하는 CI 단계입니다.

# weekly_judge_validation.py (매주 월요일 오전 9시에 실행)
from datadog import statsd
from sklearn.metrics import cohen_kappa_score
...

우리 GitHub Actions 내부의 연결 구조:

# .github/workflows/judge-validation.yml
name: Judge validation (weekly)
on:
...

8주 전에 이것을 연결했을 때 카파(kappa) 계수는 0.47이었습니다. 오늘날에는 0.68입니다.

판사(judge)에서 변경한 사항

해결책은 구조적입니다. 세 가지 변경 사항이 있습니다:

1. 점수 기준을 분리합니다. 하나의 1-5점 점수 대신 세 가지 항목을 사용합니다: 환불 금액, 거절 사유, 고객 대상 어조(tone). 기준별 카파(Kappa)는 0.65에서 0.74 사이로 실행됩니다.
2. 판사에게 인용을 강제합니다. 판사는 자신의 점수를 정당화하는 예상 답변 부분을 반드시 인용해야 합니다.
3. 느낌(vibes)이 아닌 루브릭(rubric)에 따라 점수를 매깁니다. 기준당 4페이지 분량의 루브릭(rubric)을 사용합니다.

이 세 가지 변경을 통해 6주 만에 카파(kappa)가 0.47에서 0.68로 상승했습니다.

위치 편향(Position bias) 및 장황함 편향(Verbosity bias)

위치 편향(Position bias): 답변 순서를 섞고 다시 점수를 매겼을 때, 자기 일치도(self-agreement)는 71%였습니다. 판단의 29%가 순서에 따라 뒤집혔습니다.

장황함 편향(Verbosity bias): 50개의 무해한 토큰(tokens)을 추가하여 응답을 채웠습니다. 채워진 응답은 평균적으로 0.4점 더 높게 점수를 받았습니다.

완화 방법: 답변 순서를 무작위화하고 평균을 냅니다. 판단하기 전에 최대 길이에 맞춰 자릅니다(Truncate).

교훈

Promptfoo는 CI 게이트(gate)이지, 평가 프레임워크(eval framework)가 아닙니다. 실제 평가(eval)는 그 옆에 존재하는 판사-검증 파이프라인(judge-validation pipeline)입니다.

만약 Promptfoo만 가지고 있다면, 당신은 보정되지 않은 믿음에 의존해 비행하고 있는 것입니다. 판사는 당신이 가장 잡고 싶어 하는 실패 사례들을 아주 자신 있게 통과시켜 버릴 것입니다. 왜냐하면 판사와 실패 사례들이 동일한 학습 분포(training distribution)를 공유하기 때문입니다.

제가 대화하는 대부분의 팀은 두 번째 조각을 놓치고 있습니다. 그들은 Promptfoo(또는 DeepEval, 혹은 커스텀 하네스(custom harness))를 가지고 있습니다. CI 임계값(thresholds)도 있고, 고정된 테스트 세트(frozen test set)도 있습니다. 하지만 프로덕션 트레이스(production traces)에 대한 판사 검증(judge-validation) 단계는 없습니다. 따라서 그들은 검증되지 않은 함수를 실행하면서 그 출력을 "평가(eval)"라고 부르고 있는 것입니다.

수정 비용 총계: 엔지니어 시간 약 20시간 및 API 호출 비용 월 $180. $4,200를 날린 주말이 훨씬 더 큰 수치였습니다.

제가 여전히 작업 중인 세 가지

첫 번째는 보정 세트(calibration set)의 크기입니다. 저는 매주 200개의 트레이스(traces)를 사용합니다. 더 엄격한 층화(stratification)를 적용한 100개의 트레이스가 동일한 CI를 제공할 것이라고 의심하고 있지만, 아직 분산 실험(variance experiment)을 실행해 보지는 않았습니다.

두 번째는 판사 간의 일치도(cross-judge agreement)가 인간의 라벨(human labels)을 대신하는 노이즈가 섞인 대리 지표(noisy proxy)로 기능할 수 있는지 여부입니다. 세 명의 LLM 판사가 동의한다면, 인간의 검토 단계를 건너뛰기에 충분할까요? 제 직감으로는 명백한 사례의 경우 그렇지만, 평가가 가장 필요한 엣지 케이스(edge cases)의 경우 그렇지 않습니다. 그리고 이는 최악의 실패 모드(failure mode)입니다.

세 번째이자 가장 어렵다고 느끼는 것은, 판사가 통과시킨 사례에서 프로덕션이 깨졌을 때 상실된 사용자 신뢰에 달러 가치를 매기는 일입니다. $4,200는 송장에 명확히 나타났습니다. 하지만 신뢰의 타격은 그렇지 않았습니다. 엔지니어링 직군이 아닌 리더십과의 예산 협상에서 이를 어떻게 프레임화해야 할지 모르겠습니다.

만약 여러분이 이 중 하나라도 해결하셨다면, 의견을 나누고 싶습니다.