AI 평가를 만들 때 빠지기 쉬운 함정
안녕하세요! 재니미입니다.
AI에게 일을 맡기다 보면 프롬프트를 고칠 때마다 정말 나아졌는지 확인할 방법이 필요합니다. 보통 미리 준비해 둔 문제를 풀게 하고 점수를 매기는데, 이걸 평가(eval)라고 부릅니다. 그런데 평가가 잘못 만들어져 있으면 점수가 70점에서 80점으로 올라도 믿을 수 없습니다. 이번 글에서는 Anthropic이 정리한 평가 설계 기준을 소개합니다. 좋은 평가에는 네 가지 조건이 있고, 지금 모델이 틀리는 문제만 모아서 만들면 평가가 엉뚱한 것을 재게 됩니다.
이 글은 Anthropic 블로그 글 Automating eval design and hillclimbing with Claude의 평가 설계 부분을 읽고 정리한 것입니다.
예시로는 고객 문의 메일을 읽고 담당 부서로 보내는 AI를 쓰겠습니다. 원문에 나오는 예시도 이런 메일 분류기입니다. 평가 문제 하나가 메일 한 통이고, 정답은 그 메일을 받아야 할 부서입니다.
좋은 평가의 네 가지 조건
1. 실제로 들어오는 메일로 만든다
평가에 쓰는 메일은 실제로 들어오는 메일과 닮아야 합니다. “환불해 주세요” 한 줄짜리 메일처럼 만들기 쉽고 채점하기 쉬운 것만 모으면 점수는 높게 나옵니다. 하지만 실제로는 환불 요청과 배송 문의가 한 메일에 섞여 오고, 앞선 메일을 인용한 긴 답장도 옵니다. 이런 메일을 못 다루는데 평가 점수만 높다면 그 평가는 쓸모가 없습니다.
2. 더 좋은 모델을 넣으면 점수가 올라야 한다
더 강한 모델로 바꾸거나 노력(effort) 단계를 올리면 점수가 오르는 게 정상입니다. 그런데 오르지 않는다면 모델이 아니라 평가를 먼저 봐야 합니다. 정답 자체가 애매한 메일이 섞여 있거나 채점 기준이 잘못된 경우가 많습니다.
3. 최고 모델도 다 맞히지 못해야 한다
가장 좋은 모델을 가장 높은 노력 단계로 돌려도 100점이 나오면 안 됩니다. 이미 다 맞히는 평가로는 프롬프트를 바꿔도 좋아졌는지 알 수 없습니다.
그렇다고 틀린 문제가 아무거나여서는 안 됩니다. 몇 번을 돌려도 매번 틀리는 메일이 있다면, 모델이 못하는 게 아니라 문제가 잘못됐을 가능성이 큽니다. 예를 들어 “환불 부서와 배송 부서 중 어디로 가도 이상하지 않은 메일”에 정답을 하나만 정해 두면 어떤 모델도 맞힐 수 없습니다. 원문이 제시하는 기준은 두 가지입니다. 담당자 두 명이 봐도 같은 부서를 골라야 하고, 채점에서 따지는 조건은 문제에 다 적혀 있어야 합니다.
4. 다시 돌려도 점수가 비슷해야 한다
같은 평가를 다시 돌렸는데 점수가 크게 달라진다면 원인은 대개 평가 쪽에 있습니다.
- 정답이 애매한 메일이라 모델이 매번 다른 부서를 고릅니다.
- 다른 모델에게 채점을 맡겼는데, 같은 답에 어떨 때는 맞다고 하고 어떨 때는 틀리다고 합니다.
- 노력 단계 같은 설정이 실행마다 다르게 들어갑니다.
- 앞선 실행이 남긴 파일이나 git 기록에 답이 남아 있어서 다음 실행이 그걸 보고 맞힙니다.
마지막 경우는 점수가 올라도 눈치채기 어렵습니다. 모델이 잘한 게 아니라 답을 본 것이기 때문입니다.
지금 모델이 틀리는 문제만 모으면
평가를 만들 때 쉽게 떠오르는 방법이 있습니다. 지금 쓰는 모델에 메일을 잔뜩 넣어 보고, 틀린 것만 모아서 평가로 쓰는 겁니다. 원문은 이 방법을 적대적 샘플링(adversarial sampling)이라고 부르고 피하라고 합니다.
모델마다 잘하는 것과 못하는 것이 다릅니다. 지금 모델이 틀린 메일만 모으면, 메일 분류에서 정말 어려운 메일이 아니라 그 모델이 유독 약한 메일이 모입니다. 예를 들어 지금 모델이 영어가 섞인 메일에 약하다면 평가가 그런 메일로 가득 찹니다. 다른 모델로 바꾸면 이 평가는 더 이상 어려운 문제를 재지 않습니다.
대신 원문은 이렇게 하라고 합니다.
- 사람이 보기에 어려운 메일을 고릅니다. 넣기 전에 이 메일이 왜 어려운지 한 문장으로 말할 수 있어야 합니다.
- 실제로 사고가 났던 메일을 넣습니다. 잘못 배정돼서 항의가 들어왔던 메일, 버그 리포트로 올라온 메일이 좋은 재료입니다.
- 실제 메일만 믿지는 않습니다. 사람들은 될 것 같은 요청 위주로 보내기 때문에, 실제 메일만으로 만들면 쉬운 문제가 많아집니다.
채점부터 검증한다
평가를 다 만들었다면 점수를 보기 전에 채점이 맞는지부터 확인합니다. 채점 결과가 붙은 답 몇 개를 직접 읽어 보는 겁니다. 원문은 평가가 잘못 만들어지는 가장 흔한 원인 중 하나로 채점 오류를 꼽습니다.
채점 방식은 단순한 것부터 고릅니다. 메일 분류기처럼 정답이 정해진 부서 목록 중 하나라면 코드로 일치하는지만 보면 됩니다. 답장 초안 쓰기처럼 정답이 여러 개일 수 있는 일이라면 다른 모델에게 채점을 맡깁니다. 이때 “친절도 1~5점” 같은 척도 대신 “환불 기한을 언급했다”, “사과 문장이 있다”처럼 맞다, 틀리다로 답할 수 있는 기준을 줍니다. 채점하는 모델은 시험 보는 모델과 다른 모델을 씁니다.
같은 답을 두 번 채점해서 결과가 같은지도 봅니다. 결과가 다르면 4번 조건부터 깨진 상태입니다.
도구를 쓰더라도
Claude Code의 claude-api 스킬에는 이 기준대로 평가를 만들어 주는 /claude-api build-eval 명령이 있습니다. 메일 같은 사례를 모으고, 채점 방식을 고르고, 중간에 사례 목록과 채점 결과를 사람에게 보여 주고 확인을 받습니다. 그래도 마지막에 볼 것은 같습니다. 이 평가에 실제로 들어오는 일이 담겨 있는지, 그리고 점수가 오른 이유가 정말 나아졌기 때문인지입니다.
감사합니다.