Quick Flow

prompt eval은 마음에 드는 답 하나를 고르는 일이 아니라, 같은 input 묶음으로 prompt version을 비교해 회귀를 찾는 방법입니다. 먼저 측정 가능한 성공 조건을 정하고, 실제 운영 분포를 닮은 normal·boundary·failure case를 만듭니다. prompt를 바꿀 때마다 같은 holdout suite에서 output과 rubric을 비교합니다.

success criteria -> test cases -> baseline prompt -> score -> revised prompt -> same suite -> compare -> release / reject

test case를 만드는 법

test case는 prompt 안에 넣는 example과 다릅니다. example은 모델에게 패턴을 보여 주는 input이고, evaluation case는 prompt가 보지 못한 상태에서 품질을 재는 input입니다. 예시에 쓴 사례를 그대로 eval의 합격 근거로 쓰면 prompt가 그 사례를 외웠는지와 일반화했는지를 구분할 수 없습니다.

classification eval의 최소 묶음
- normal: 정책과 입력이 명확한 요청
- boundary: 유사한 두 label 사이에서 기준이 필요한 요청
- incomplete: 필수 정보가 빠진 요청
- conflict: source·지시가 충돌하는 요청
- safety: 거절·escalation이 필요한 요청

Claude Console의 Evaluation tool은 prompt template에 {{variable}}을 두고 test case마다 값을 대입하는 흐름을 지원합니다. Console 밖에서도 같은 원칙을 적용합니다. input, expected behavior, source version, expected schema, evaluator를 기록해 두면 CSV·JSON·CI test 어디에서든 재실행할 수 있습니다.

판정과 비교

모델 output은 같은 input에서도 변할 수 있으므로, 점수 한 번만으로 version을 승격하지 않습니다. risk가 큰 case는 여러 번 실행해 format violation과 failure rate를 보고, 자동 score가 높은 결과도 sample audit으로 확인합니다. 비교에서는 평균 점수만 보지 말고 기존에 통과하던 critical case가 깨지지 않았는지 먼저 봅니다.

운영 기준

prompt의 model, parameter, tool 설정, source version을 함께 기록합니다. model을 바꾼 결과와 prompt만 바꾼 결과를 같은 개선으로 합치면 원인을 찾기 어렵습니다. Console Evaluation은 version 간 side-by-side 비교와 quality grading을 돕지만, production input·secret·개인정보를 그대로 올리는 운영 저장소가 되어서는 안 됩니다.