점수 뒤의 시험부터 살펴봅니다
어떤 모델은 1위를 했고 다른 모델은 9점이 올랐습니다. 팀에서는 무엇을 쓸지 묻습니다. 답하기 전에 시험 설명을 열어 봅니다. 점수는 모델뿐 아니라 문제와 프롬프트, 도구, 허용 시간, 채점 규칙에 따라 달라집니다. 이 조건이 바뀌면 결과도 달라질 수 있습니다.
PaperBench를 보면 이해하기 쉽습니다. AI 에이전트에 논문 20편의 연구 결과를 재현하게 하고, 작업을 채점 가능한 8,316개 과제로 나눕니다. 제출물을 채점하는 AI의 성능도 따로 시험합니다.[1] 여기서 얻은 점수는 그 연구·개발 과제 묶음을 얼마나 잘 수행했는지 알려 줍니다. 연구자가 할 수 있는 모든 일을 측정하지는 않습니다.
점수를 보고할 때는 의미를 알 수 있는 조건을 붙입니다. 어느 모델 버전이 어떤 과제를 무슨 도구와 제한 아래 수행했고, 어떻게 채점했나요? 독자는 그 결과가 자기 질문에 답하는지, 다른 점수와 비교해도 되는지 판단할 수 있습니다.
점수를 모델 선택의 근거로 삼기 전에 시험 조건을 읽습니다.
AI가 해 줘야 할 일을 먼저 정합니다
고객지원 답장 초안을 쓸 AI가 필요하다고 해 보겠습니다. 사실 질문 시험으로는 특정 사실을 아는지 확인할 수 있습니다. 하지만 회사의 환불 규정을 따르는지, 빠진 정보를 묻는지, 사람에게 넘겨야 할 때를 알아보는지는 알 수 없습니다. 필요한 업무에 맞춰 시험을 고릅니다.
“고객이 이해할 수 있는 답장이 필요합니다”는 목표입니다. “검토자가 이 답장을 골랐습니다”는 관찰 결과 하나일 뿐, 고객도 이해했다는 뜻은 아닙니다. 평가 연구에서는 측정하려는 능력이나 개념을 construct, 이를 수치로 나타내는 지표를 metric이라고 부릅니다. 이 관찰을 목표 달성의 근거로 삼으려면 무엇을 더 확인해야 할지 물어봅니다.
HELM은 정확성, 조건이 바뀌어도 유지되는 성능, 공정성, 효율성 등 여러 측면을 함께 평가합니다.[2] 한 측면의 개선과 다른 측면의 손해를 함께 볼 수 있습니다. 더 많은 문제를 맞히는 시스템이 비용은 더 들거나 특정 집단에는 잘 작동하지 않을 수 있습니다. 내 용도에 필요한 지표를 고르고 각각 무엇을 뜻하는지 구분합니다.
어떤 과제와 사용자를 시험했는지 봅니다
‘코딩’ 시험의 대부분이 짧은 함수 작성일 수 있습니다. 내 팀에서는 규모가 큰 기존 프로젝트의 여러 부분을 함께 고쳐야 할 수 있습니다. ‘추론’ 시험은 짧은 영어 질문을 쓰는데 내 서비스는 긴 일본어 대화를 다룰 수도 있습니다. 이름만 믿지 말고 실제 과제를 읽어 봅니다.
비슷한 틀의 문제가 반복되는지, 질문이 모호한지, 정답표가 틀렸는지, 중요한 사례가 몇 개뿐인지 확인합니다. 모델 간 작은 점수 차이는 어떤 과제를 뽑았느냐에 따른 변동과 구분하기 어려울 수 있습니다. Bowman과 Dahl은 벤치마크를 개선하려면 정확한 정답·라벨, 우연한 점수 변동과 실제 성능 차이를 구분할 수 있는 통계적 검정력, 난이도와 편향에 대한 검토가 필요하다고 설명합니다.[3] 문제를 더 어렵게 만드는 것만으로는 부족합니다.
실제로 할 일을 기준으로 간단한 목록을 만듭니다. 시험에 어떤 과제 유형과 언어, 사용자, 도구, 작업 길이가 들어 있나요? 적거나 빠진 것은 무엇인가요? 의도적으로 제외한 조건도 기록합니다. 중요한 사용 조건이 빠졌다면 결과를 그 조건까지 확대하기 전에 따로 시험합니다.
언제 만든 시험인지, 지금도 쓸 만한지 확인합니다
공개된 시험 문제가 학습 자료에 들어갈 수 있습니다. 그러면 높은 점수에 새로운 과제를 푸는 능력뿐 아니라 문제를 미리 접한 효과가 섞일 수 있습니다. 시험 자료가 학습에 섞이는 이런 문제를 benchmark contamination이라고 부릅니다. 똑같은 문제를 보지 않았어도 비슷한 문제를 반복 연습하면 익숙한 시험만으로 낯선 업무의 성능을 판단하기 어려워집니다.
시험을 만든 날짜와 공개한 날짜, 평가한 모델 버전과 평가 날짜를 확인합니다. 가능하면 예전 문항의 결과를 새 문항이나 공개하지 않은 문항의 결과와 비교합니다. 표현을 그대로 복제한 흔적이 있으면 의심할 수 있지만, 흔적을 못 찾았다고 처음 보는 문제였다고 입증되지는 않습니다. 사전 노출이 결과에 영향을 줬는지 알 수 없다면 그렇게 밝힙니다.
LiveBench는 최근 자료의 문제를 정기적으로 추가하고 객관적인 정답으로 채점해 이 위험을 줄입니다.[4] 시험이 갱신되면 비교 조건도 달라집니다. 새 문제의 점수를 지난달 점수와 곧바로 비교할 수는 없습니다. 시험 버전을 기록하고 필요하면 공통 문항을 활용합니다. 새 모델, 바뀐 업무 절차, 사전 노출 징후 중 무엇이 생기면 다시 평가할지도 정합니다.
예전 점수는 지금 업무에 필요한 질문에 답하지 못할 수 있습니다.
답변만큼 채점도 꼼꼼히 봅니다
채점 규칙이 중요한 부분을 놓칠 수 있습니다. 글자가 정확히 일치해야 정답으로 처리하면 같은 뜻의 다른 표현도 오답이 됩니다. 코드 테스트는 작성된 검사 항목만 확인합니다. 전문가 검토는 더 복잡한 결과를 평가할 수 있지만 명확한 기준이 필요합니다. AI 채점기는 많은 답을 빠르게 검토하는 대신 내용뿐 아니라 제시 방식에도 영향을 받을 수 있습니다.
모델 이름을 놓고 비교하기 전에 채점 기준부터 씁니다. 해당 분야를 아는 사람이 통과와 실패 사례를 모두 일부씩 검토하고 의견이 갈린 부분을 살핍니다. 두 답을 나란히 비교할 때는 순서를 바꿔 봅니다. 채점 지시의 표현도 조금 바꿔 봅니다. 이런 변화로 순위가 뒤집힌다면 안정적인 승자를 발표하기보다 불확실성을 밝힙니다.
Chatbot Arena는 두 답을 비교하는 방식으로 사람들의 선호를 모으고 그 신뢰성을 검토합니다.[5] 그 환경에서 어떤 답을 선호했는지에 관한 근거입니다. 선호된 시스템이 더 안전하고 사실에 충실하며 내 전문 업무에도 잘 맞는다는 것까지 입증하지는 않습니다. 누가 답을 평가했고 무엇을 판단하도록 요청받았는지 확인합니다.
실패가 어디에 몰렸는지 확인합니다
전체 평균에는 특정 과제나 집단에 몰린 실패가 가려질 수 있습니다. 계산 방법도 중요합니다. 범주마다 같은 비중을 주는 방식과 모든 문항에 같은 비중을 주는 방식은 결과가 다릅니다. 여러 번 시도해 한 번이라도 통과하면 성공으로 세는 것과 첫 시도의 성공률을 재는 것도 서로 다른 질문에 답합니다.
아래 그림은 각각 스무 사례로 만든 두 가상 결과입니다. 성공률은 둘 다 80%지만 한쪽은 실패 대부분이 한 집단에 몰려 있습니다. 그래서 중요한 집단과 과제별 결과를 불확실성, 반복 실행의 변동과 함께 보여 줘야 합니다. 모델을 비교할 때는 같은 과제에 낸 답과 실수의 심각성도 살펴봅니다.
전체 점수는 같아도 실패가 쏠리는 곳은 다릅니다
가상 사례 · 각 20건 중 4건 실패 · 전체 성공률 80%
분산된 실패
한 집단에 집중된 실패
실패한 실행 기록을 읽고 무엇을 고쳐야 할지 찾습니다. 지식이 부족했는지, 지시를 놓쳤는지, 도구 오류인지, 채점 기준이 모호한지 구분합니다. 통과한 결과도 봅니다. METR의 연구에서는 자동 테스트를 통과한 코드 중에도 유지보수자가 사용하려면 수정이 더 필요한 제출물이 있었습니다.[8] 시험이 작업의 한 부분은 정확히 검사해도 다른 요구사항은 놓칠 수 있습니다.
전체 점수가 같아도 실패의 양상은 전혀 다를 수 있습니다.
후보 시스템을 실제 업무에 써 봅니다
벤치마크로 후보를 추릴 수 있습니다. 그다음은 시험에서 잘한 일이 실제 업무에서도 통하는지 확인할 차례입니다. 현장에는 비공개 도구, 불완전한 요청, 작업 중단, 바뀌는 정보, 자동 검사로는 확인하지 못하는 품질 기준이 있을 수 있습니다.
PaperBench의 재현 과제에는 연구 이해와 구현, 실험 실행이 포함됩니다.[1] METR은 time horizon이라는 기준으로 과제의 길이에 따른 AI의 성공률을 살폈습니다. 과제의 길이는 사람이 같은 일을 끝내는 데 걸리는 시간으로 정합니다.[6] 이 시간은 사람 기준의 과제 길이이며 AI 실행 시간이 아닙니다. 두 방식 모두 짧은 답변 시험보다 많은 것을 보여 주지만, 여전히 연구한 과제와 조건에 관한 결과입니다.
시스템에 의존하기 전에 실제 업무에서 쓰는 도구로 대표 과제를 수행하게 하고, 해당 분야를 아는 사람이 결과를 검토합니다. 사용자에게 영향을 주지 않고 결과를 검토할 수 있는 일부터 시작합니다. 완료 시간과 수정 작업, 중요한 오류, 결과를 실제로 쓸 수 있는지를 측정합니다. METR이 2025년 초의 AI로 숙련된 오픈소스 개발자를 조사했을 때, 참여자들은 AI가 속도를 높였다고 생각했지만 측정한 완료 시간은 늘었습니다.[7] 그 환경의 결과를 모든 업무에 적용할 수는 없습니다. 점수나 느낌으로 추측하지 말고 필요한 결과를 직접 재 봐야 한다는 교훈으로 삼을 수 있습니다.
점수를 보고 결정하기 전에 적용 범위를 확인하는 질문입니다. 답하지 못한 항목은 아직 필요한 근거를 알려 줍니다.
결과로 결정할 수 있는 범위를 밝힙니다
마지막에는 다른 사람이 검토할 수 있는 결정을 제시합니다. 예를 들어 “일상적인 영어 답장은 사람이 검토하는 시범 운영을 해 볼 근거가 있습니다. 환불 예외와 다른 언어는 아직 시험하지 않았습니다”라고 쓸 수 있습니다. 가상의 결론이지만 모델이 ‘최고’라는 말보다 용도와 한계, 다음 단계를 분명히 알려 줍니다.
평가를 이해하고 반복할 정보를 저장합니다. 모델 버전, 프롬프트, 도구와 권한, 과제 묶음, 시간·비용 제한, 채점 규칙, 검토자나 채점 모델 버전, 반복 시도의 집계 방식을 남깁니다. 종합 점수를 계산한 방법도 보관합니다. 중요한 설정이 바뀌면 새 결과에 달라진 조건을 표시합니다.
새 근거를 검토할 사람과 다시 시험할 조건을 정합니다. 모델이나 사용자 집단이 바뀌거나, 도구가 수정되거나, 시험에서 다루지 않은 실패가 생겼을 때 재평가가 필요할 수 있습니다. 결과는 시범 운영, 특정 업무 절차의 변경, 추가 시험, 현재 시스템 유지 중 하나를 뒷받침할 수 있습니다. 어느 결정에 근거가 되는지 밝힙니다.