Eval 은 한 번 만들고 끝나는 deliverable 이 아니야
실제 프로젝트에서 가장 흔한 eval 실패는 'launch sprint 때 eval 만들고 다신 안 봤어' 야. 3개월 뒤 eval 은 여전히 pass 하는데 사용자는 Slack 에서 불평해. dataset 은 시간에 얼어붙었는데 product 는 움직였어.
건강한 eval 은 연속 loop 으로 돌아:
- Define — 보호할 만한 동작 골라서 success 가 뭔지 적어.
- Curate — 그 동작을 대표하는 dataset 모으기, 실패 잘 나오는 edge case 포함.
- Measure — system 돌리고, output score 매기고, 결과 요약.
- Diagnose — 뭐가 실패하면 aggregate 만 보지 말고 실제 output 들 봐.
- Improve — prompt, model, retrieval, tool 바꾸고 다시 측정.
- Monitor — production traffic sample. live distribution 이 offline dataset 에서 drift 하면 refresh.
diagnose 단계가 팀이 컨닝하는 곳
'pass rate 가 92% 에서 88% 로 떨어졌네' 보고 prompt 만지작거리고 싶은 유혹 생겨. 하지마. 실패 열어. output 읽어. aggregate score 는 화재경보지 — 실패는 진짜 불이야. 열에 아홉, regression 은 특정 input cluster 에 몰려 있어 (새로운 entity 타입, 더 긴 document, 새 언어) — 그리고 옳은 fix 는 targeted 야, global prompt rewrite 가 아니야.
원칙: Aggregate score 는 답이 아니라 질문이야. 항상 실패를 읽어.
monitor 단계가 팀이 멈추는 곳
refresh 안 되는 eval suite 는 박물관 전시품이 돼: 향수 자극하지만 무의미하고, 정치적으로 제거 비용 비싸. 분기별 review 잡아. 최근 production 대화 50개 sample. offline dataset 이 여전히 그것들 닮았는지 체크. 아니면 refresh.