프롬프트를 반복 개선하는 기본 방식은 프롬프트를 약간 수정하고, 마침 신경 쓰이는 입력값 하나를 실행한 뒤, 출력을 훑어보고, "더 나아진 것 같다"고 판단하여 배포하는 것입니다. 이는 정확히 단 하나의 사례에만 유효하며, 다음 단계로 넘어가는 순간 그 사례는 잊혀집니다. 변경 사항으로 인해 망가진 입력값은 결코 볼 수 없으며, 두 후보군을 공정하게 비교할 수도 없고, "더 낫다"는 기준은 팀원이나 다음 주의 자신에게 방어할 수 없는 단순한 느낌(vibe)일 뿐입니다.

프롬프트 평가(Prompt evals)는 이러한 느낌 확인(vibe check)을 측정으로 대체합니다. 고정된 **테스트 세트(test set)**를 지정하고, 몇 가지 후보 **변형(variants)**을 작성한 뒤, 모든 변형을 모든 테스트에 대해 실행합니다. 그리고 결정론적인 **채점기(graders)**가 각 (variant × test) 셀을 합격/불합격 및 점수로 변환하게 합니다. 이것이 "promptfoo 스타일"의 루프이며, 다른 모든 것의 밑바탕이 되는 규율 계층입니다.

결정론적 채점기(Deterministic graders)에는 LLM이 필요하지 않습니다

대부분의 단언(assertions)은 저렴하고 빠르며 100% 재현 가능합니다. 출력이 정확히 일치하는가, 특정 문자열을 포함하는가, 정규 표현식(regex)과 일치하는가, 또는 JSON으로 파싱되는가? 각각은 {pass, score}를 반환하며, 이진 채점기(binary graders)의 경우 점수는 단순히 1 또는 0입니다.

function grade(type, output, assertion) {
  const out = String(output);
  if (type === "exact_match") { const p = out.trim() === String(assertion).trim(); return { pass:p, score:p?1:0 }; }
...

루브릭 채점기(rubric grader)는 부분 점수(필요한 키워드가 포함된 비율)를 추가하므로, 평균 점수(avg score)를 통해 합격률이 동일한 두 변형을 구분할 수 있습니다.

매트릭스를 실행하고, 승자를 선택한 다음, 방어하세요

하네스 루프(harness loop)는 단순합니다. 모든 변형에 대해 모든 테스트에 프롬프트를 실행하고, 채점한 뒤, 각 열을 합격률과 평균 점수로 축소(reduce)합니다.

async function runEval(variants, tests, callModel) {
  return Promise.all(variants.map(async (v) => {
    const cells = await Promise.all(tests.map(async (t) => {
...

승자는 기계적으로 결정됩니다. 가장 높은 합격률을 가진 것이 승자이며, 합격률이 같으면 평균 점수로 결정합니다. 하지만 그것은 업무의 절반일 뿐이며, 덜 중요한 절반이기도 합니다.

실제로 당신을 구원해 주는 부분

프롬프트 변경 사항이 다른 모든 면에서 완벽하게 우월한 경우(strictly dominates)는 거의 없습니다. 데모에서 V3는 V2가 놓쳤던 긴급한 사례들을 마침내 잡아내는 퓨샷 예시(few-shot examples)를 추가했습니다(통과율 60% → 80%). 하지만 동일한 예시들로 인해 친절한 감사 인사에도 urgent를 과도하게 트리거하게 되었고, 결과적으로 V2가 통과했던 테스트에서 **퇴보(regressed)**했습니다. 헤드라인 수치(headline number)는 _상승_했지만, 특정 동작은 _악화_된 것입니다. 단일 평균값만 사용했다면 이 사실을 숨겼을 것입니다.

해결책은 통과(pass)에서 실패(fail)로 변하는 모든 지점을 차단하는 베이스라인(baseline)과의 셀 단위 차이(cell-by-cell diff)를 확인하는 것입니다:

function regressions(base, cand, tests) {
  return tests.filter((t, i) => base.cells[i].pass && !cand.cells[i].pass);
}
...

이를 CI(지속적 통합)에 연결하십시오. 직접 구현하거나 assert.type 그레이더(grader)가 포함된 promptfooconfig.yaml을 통해 연결할 수 있습니다. 이렇게 하면 순이익(net-positive)을 가져오는 변경 사항이 순손실(net-negative)이라는 뜻밖의 결과를 조용히 배포하는 일을 더 이상 방지할 수 있습니다. 점수가 왜곡되지 않도록 튜닝에 절대 사용하지 않는 홀드아웃(holdout) 데이터를 유지하고, 통과율(게이트, the gate)과 평균 점수(다이얼, the dial)를 모두 보고하면 품질은 오직 상승할 수밖에 없습니다.

그레이더를 토글하며 매트릭스(matrix), 통과율(pass-rates), 승자(winner), 그리고 퇴보 차이(regression diff)가 실시간으로 재계산되는 것을 확인해 보세요: https://dev48v.infy.uk/prompt/day57-prompt-evals.html