품질 측정하기: 기본 eval 구축하는 법

언어 모델로 무언가를 만드는 사람 대부분은 같은 방식으로 품질을 측정합니다. 변경을 시도하고, 출력 한두 개를 보고, "더 나은 것 같다"고 판단하는 것이죠. 그건 통하다가 통하지 않게 됩니다. 두 개의 프롬프트가 있는데 어느 쪽이 실제로 더 나은지 말할 방법이 없을 때, 혹은 한 경우를 고치면서 다른 다섯 경우를 조용히 망가뜨리는 수정을 배포할 때 말이죠. 해결책은 eval입니다. 막연한 품질 감각을 비교할 수 있는 숫자로 바꾸는 작고 반복 가능한 테스트죠. 시작하는 데 프레임워크나 플랫폼이 필요하지 않습니다. 예시 몇 개와 그것을 두 번 똑같은 방식으로 채점하는 규율이 필요할 뿐입니다. 이 글은 그것을 맨바닥에서 만듭니다.

왜 "더 나은 것 같다"는 실패하는가

단일 출력으로 모델을 판단하는 데는 세 가지 문제가 있고, 각각이 그 자체로 치명적입니다. 그것은 일반화되지 않습니다. 인상적인 시연은 다음 백 개의 입력에 대해 아무것도 말해주지 않습니다. 반복 가능하지 않습니다. 당신의 인상은 마침 어떤 예시를 봤는지, 어떤 기분이었는지에 달려 있습니다. 그리고 회귀(regression)를 탐지할 수 없습니다. 변경이 한 경우를 개선하고 다른 경우를 악화시킬 때, 한 번에 출력 하나씩 눈으로 보는 방식은 그 거래를 결코 보여주지 않습니다. eval은 입력을 고정하고, 채점을 고정하고, 운 좋은 표본이 아니라 집합 전체를 봄으로써 이 셋을 모두 해결합니다.

목표는 완벽한 과학적 벤치마크가 아닙니다. 감보다 나은 무언가입니다. 버전 B가 버전 A를 이긴다고 말할 때 당신이 믿을 만큼 솔직한 측정 말이죠.

1단계: 실제 예시로 이루어진 데이터셋

eval은 당신의 시스템이 실제로 하는 일을 대표하는 입력 집합에서 시작합니다. 이것이 가장 중요한 단계이자 사람들이 가장 건너뛰고 싶어 하는 단계입니다. 시작하기엔 20~50개 예시면 충분합니다. 양보다 질이 훨씬 더 중요하죠. 중요한 것은 그것들이 대표적이라는 점입니다. 실제 혹은 현실적인 사용에서 가져와, 쉬운 경우, 흔한 경우, 그리고 특히 어렵고 이상한 경우를 아울러야 합니다.

까다로운 입력을 의도적으로 포함하세요. 빈 입력, 모호한 질문, 거절되어야 할 요청, 지난주에 깨진 경우. 쉬운 예시만으로 만든 eval은 실제 사용자가 어려운 무언가를 보내는 바로 그 순간까지 모든 게 괜찮다고 보고할 것입니다. 당신의 데이터셋은 제대로 해내고 싶은 상황들의 작은 박물관이며, 두려운 상황을 과대 대표해야 합니다.

2단계: "좋다"가 무엇을 뜻하는지 정하라

무언가를 채점하기 전에, 당신의 과제에서 좋은 출력이 무엇인지 말해야 합니다. 이건 들리는 것보다 더 어렵고 더 가치 있습니다. 기준을 명시적으로 만들도록 강제하기 때문이죠. 과제마다 다른 정의를 요구합니다:

• 정확 일치 과제는 하나의 옳은 답을 가집니다. 분류 라벨, 추출된 필드, 예/아니오 같은 것이죠. 좋다는 건 출력이 기대한 답과 같다는 뜻입니다.
• 구조화 과제는 형식을 따집니다. 유효한 JSON, 필수 필드의 존재, 올바른 형태 같은 것이죠. 좋다는 건 파싱되고 규격에 맞는다는 뜻입니다.
• 열린 과제, 즉 요약, 설명, 초안에는 하나의 옳은 답이 없습니다. 좋음은 기준으로 정의됩니다. 정확한가, 주제에서 벗어나지 않는가, 사실을 지어내지 않는가, 적절한 길이와 어조인가?

결과를 보기 전에 당신의 정의를 적어두세요. 출력을 본 뒤에 "좋다"가 무엇을 뜻하는지 정하는 것은 원했던 결론으로 스스로를 설득하는 방식입니다. 정의는 당신의 고정된 잣대이며, 답에 맞춰 휘어지는 잣대는 아무것도 측정하지 못합니다.

3단계: 채점 방법을 고르라

정의를 손에 쥐었으면, 그것을 모든 예시에 일관되게 적용할 방법이 필요합니다. 솔직한 선택지가 셋 있으며, 대략 비용이 적은 순서대로입니다.

프로그래밍 검사는 적용될 때 최선입니다. 옳은 답이나 필수 형식이 있다면, 코드 몇 줄로 출력을 기대 결과와 비교하거나 JSON이 파싱되고 올바른 필드를 가졌는지 확인할 수 있습니다. 이것은 빠르고, 무료이며, 완벽하게 반복 가능하고, 누구의 기분에도 좌우되지 않습니다. 과제가 허락하는 곳이라면 어디서든 쓰세요.

사람의 판단은 자동 검사를 거부하는 열린 작업의 대안입니다. 각 출력을 읽고 당신의 적힌 기준에 비추어 채점하죠. 솔직함을 유지하려면 흐릿한 인상이 아니라 단순하고 정의된 척도로 채점하세요. 각각에 한 줄 규칙을 붙인 "통과 / 애매 / 실패"조차 직감보다 낫습니다. 함정은 비일관성입니다. 같은 사람이 피곤한 오후에는 같은 출력을 다르게 채점하죠. 기준을 적어두는 것이 한 세션 내내 채점을 안정적으로 붙들어 줍니다.

모델을 심판으로(Model-as-judge) 쓰는 방식은 두 번째 언어 모델로 당신의 기준에 비추어 출력을 채점하는데, 사람 같은 판단을 많은 예시로 저렴하게 확장합니다. 이건 진짜 유용하면서 진짜 오류에 취약합니다. 심판은 자신만의 편향을 가지며 자신만만하고 유창하지만 틀린 답에 속을 수 있습니다. 쓴다면 검증하세요. 사람이 표본을 채점하게 하고 심판이 동의하는지 확인하세요. 한 번도 확인하지 않은 심판은 신뢰해서는 안 되는 숫자입니다.

4단계: 돌려보고 실패를 읽어라

이제 조각들이 갖춰졌습니다. 데이터셋, 좋음의 정의, 채점 방법. 모든 예시를 시스템에 통과시키고, 각각을 채점하고, 단순한 요약을 계산하세요. 몇 퍼센트가 통과했는지, 평균 점수가 얼마인지, 당신의 방법이 집계하는 방식이 무엇이든 말이죠. 그 하나의 숫자가 당신의 기준선(baseline)입니다. 그 자체로는 별 의미가 없습니다. 그 가치는 무언가를 바꿔 다시 돌리는 순간 나타납니다. 이제 "더 나은 것 같다"가 "71%에서 78%로 올랐다"가 되고, 그건 당신이 떳떳이 내세울 수 있는 주장이기 때문입니다.

하지만 숫자는 보상의 작은 절반입니다. 큰 절반은 실패를 읽는 것입니다. 낮게 채점된 모든 예시를 꺼내 패턴을 찾으세요. 시스템이 잘못 다루는 입력 범주, 반복되는 실수, 일관되게 더듬는 종류의 질문. 집계 점수는 일이 잘 돌아가는지를 말해주고, 실패는 무엇을 고칠지를 말해줍니다. 실패를 숨기는 기준선은 진단 없는 체온계입니다. 평균만이 아니라 분포의 바닥을 항상 읽으세요.

5단계: 한 번에 하나씩 바꿔라

eval은 당신이 그것을 비교에 쓸 때 제값을 합니다. 단 하나의 변경을, 즉 다른 프롬프트, 새 지시문, 다른 모델을 만들고 같은 데이터셋을 같은 채점으로 다시 돌리세요. 숫자가 오르고 어떤 실패 범주도 악화되지 않았다면 변경을 유지하세요. 내려간다면, 사용자보다 먼저 회귀를 잡은 것이고, 그게 핵심 전부입니다.

규율은 한 번 돌릴 때 한 변수만 바꾸는 것입니다. 한꺼번에 세 가지를 바꾸면 더 나아진 점수가 어느 것이 도움이 됐는지, 혹은 둘이 도움이 되고 셋째가 해를 끼쳤는지 아무것도 말해주지 않습니다. 한 번의 변경, 한 번의 재실행, 한 번의 비교. 마땅히 그래야 할 것보다 느리게 느껴지지만, 그것이 숫자가 의미 있게 유지되는 유일한 방법입니다.

정리

기본 eval은 솔직한 네 조각입니다. 작고 대표적인 예시 집합, 좋음이 무엇인지에 대한 적힌 정의, 일관된 채점 방법, 그리고 한 번에 하나씩 바꿔 다시 돌리는 습관. 스프레드시트 하나와 오후 한나절이면 만들 수 있습니다. 완벽한 벤치마크는 아닐 것이고, 그럴 필요도 없습니다. 그저 감보다 낫고, 신뢰할 만큼 반복 가능하고, 실패가 어디에 모이는지 보여줄 만큼 드러내기만 하면 됩니다. "더 나은 것 같다"가 당신이 변호할 수 있는 숫자가 되고 나면, 이후의 모든 결정이 더 쉽고 더 솔직해집니다.