평가는 한 번 만들고 끝나는 산출물이 아니야
실제 프로젝트에서 가장 흔한 평가 실패는 '출시를 준비할 때 평가를 만들고 다시는 보지 않았어'라는 상황이야. 3개월 뒤에도 평가는 계속 통과하지만 사용자는 Slack에서 불만을 쏟아내지. 데이터셋은 그 시점에 머물러 있는데 제품은 계속 변했기 때문이야.
건강한 평가는 다음 단계를 계속 순환해야 해:
- 정의 — 보호할 동작을 고르고 성공의 기준을 적어.
- 정제 — 그 동작을 대표하는 데이터셋을 모아. 실패하기 쉬운 경계 사례도 포함해야 해.
- 측정 — 시스템을 실행하고, 출력을 채점하고, 결과를 요약해.
- 진단 — 무언가 실패하면 종합 점수만 보지 말고 실제 출력을 살펴봐.
- 개선 — 프롬프트, 모델, 검색, 도구를 바꾸고 다시 측정해.
- 관찰 — 운영 요청에서 표본을 뽑아. 운영 환경의 분포가 오프라인 데이터셋과 달라지면 데이터셋을 갱신해.
팀이 가장 자주 건너뛰는 진단 단계
'통과율이 92%에서 88%로 떨어졌네'라는 결과를 보면 바로 프롬프트를 손보고 싶어져. 그러지 마. 실패 사례를 열어 출력을 직접 읽어 봐. 종합 점수는 화재경보기일 뿐이고, 실패 사례가 실제 불이야. 10번 중 9번은 회귀가 특정 입력 묶음에 몰려 있어. 새로운 사용자 유형, 더 긴 문서, 새로운 언어 같은 사례 말이야. 이때 필요한 건 문제를 겨냥한 수정이지, 프롬프트 전체를 다시 쓰는 일이 아니야.
원칙: 종합 점수는 답이 아니라 질문이야. 항상 실패 사례를 직접 읽어.
팀이 멈추기 쉬운 관찰 단계
갱신하지 않는 평가 모음은 박물관 전시품이 돼. 추억만 불러일으킬 뿐 쓸모는 없지만, 조직 내부의 이해관계 때문에 없애기도 어렵지. 분기마다 검토 일정을 잡아. 최근 운영 대화 50건을 표본으로 뽑고, 오프라인 데이터셋이 여전히 그 표본을 제대로 대표하는지 확인해. 닮지 않았다면 갱신해.