AI 평가: 무엇을 어떻게 측정할 것인가

벤치마크의 역할과 한계, GSM8K와 SWE-bench의 평가 사례를 살펴보고 점수를 비교할 때 확인해야 할 조건을 정리한다.

고친 내용: 독자에게 보이는 문장과 용어를 다듬고 기존 근거 연결을 유지했다.

평가는 왜 어려운가

언어모델은 다양한 일을 할 수 있어 하나의 기준으로 평가하기 어렵다. 수학 문제를 잘 푼다고 해서 고객 응대를 잘한다는 보장이 없고, 영어 시험 점수가 한국어 실무 능력을 대신하지 못한다. 그럼에도 평가는 필요하다. 무엇을 시도할지, 무엇을 버릴지 정하려면 잴 수 있는 기준이 있어야 하기 때문이다. 평가 결과를 읽을 때는 확인하고 싶은 능력과 실제로 측정한 능력이 얼마나 일치하는지 살펴야 한다.

SWE-bench 논문의 첫 문장은 이 사정을 단적으로 드러낸다. 언어모델의 발전 속도가 이를 효과적으로 평가하는 우리의 능력을 앞질렀다는 문제의식이다. 이 글은 이런 문제에 대응하기 위해 제안된 평가 방법들을 정리한다.

벤치마크의 역할과 한계

벤치마크는 정해진 문제 모음으로 능력을 평가하는 방식이다. 다만 이 문제들로 모든 능력을 측정할 수는 없다. 문제의 분포가 실무의 분포와 다를 수 있고, 정답의 형식이 실제 쓰임과 동떨어질 수 있으며, 모델이 문제를 통째로 외웠을 가능성도 있다. 그럼에도 벤치마크는 비교의 공통 언어가 된다. 같은 문제를 같은 조건으로 풀게 하면 적어도 상대적 위치는 잴 수 있기 때문이다.

벤치마크를 읽을 때는 무엇을 어떤 조건에서 측정했는지, 무엇은 측정하지 못했는지 함께 본다. 모델 규모와 프롬프트 방식, 허용된 도구와 시도 횟수가 주요 조건이다. 같은 점수도 조건이 다르면 의미가 달라진다. 이 원칙은 아래의 모든 사례에 적용된다.

추론 평가의 사례: GSM8K와 chain-of-thought

수학 문장제 벤치마크 GSM8K는 추론 평가의 대표 사례로 자주 인용된다. Chain-of-thought 논문은 540B 파라미터 모델에 8개의 예시를 주는 것만으로 이 벤치마크에서 당시 최고 정확도를 달성했다고 보고했다. 풀이의 정확성을 평가하는 검증 모델인 verifier를 붙인 파인튜닝 GPT-3보다도 높은 점수였다. 산술과 상식, 기호 추론 과제에서도 개선을 확인했다고 한다. 같은 모델이라도 푸는 방식을 바꾸자 점수가 달라졌으므로, 평가를 통해 풀이 방식의 효과를 확인한 사례다.

다만 이 사례가 말해주지 않는 것도 있다. GSM8K 점수가 일상적 추론 전반을 대신하지는 못하며, 중간 단계를 잘 적는 것과 진짜 이유를 밝히는 것은 다르다. 평가로 특정 방법의 효과를 확인할 수 있어도, 그것만으로 모델의 추론 능력 전반을 입증할 수는 없다. 이 구분은 추론 주제 글의 faithfulness, 즉 제시한 풀이가 실제 답을 도출한 과정을 반영하는지에 관한 논의와 연결된다.

실제 과제로 재기: SWE-bench의 발상

SWE-bench는 실제 개발 과제를 평가에 사용한 사례다. 12개 인기 Python 저장소의 실제 GitHub 이슈와 그에 대응하는 pull request에서 뽑은 2,294개의 문제로 이루어진다. 모델은 코드베이스와 이슈 설명을 받아 이슈를 해결하도록 코드를 수정해야 한다. 여러 함수와 클래스, 파일에 걸친 변경과 실행 환경과의 상호작용, 매우 긴 컨텍스트의 처리, 복잡한 추론을 요구한다고 논문은 설명한다.

2023년 평가에서는 가장 성능이 좋았던 Claude 2도 1.96%의 이슈만 해결했다. 당시 최신 비공개 모델과 파인튜닝 모델 모두 가장 쉬운 이슈만 풀 수 있었다고 논문은 보고했다. 이 수치는 2023년 당시의 결과이며 이후 점수는 이 글에서 다루는 출처 범위에 없다. 이 글에서는 점수 자체보다 평가용으로 만든 문제 대신 실제 개발 작업의 기록을 사용했다는 점에 주목한다.

점수 읽는 법

점수를 비교하기 전에 모델 규모와 프롬프트, 도구, 시도 횟수를 확인한다. 하나의 벤치마크가 모든 능력을 대표한다고 보기는 어렵다. 평가 시점도 중요하다. 2023년의 1.96%는 그 당시의 결과다. 무엇을 측정하지 못했는지, 실제 업무와 어떤 차이가 있는지도 살펴야 한다. 이는 특정 출처의 직접 주장이 아닌 여러 출처를 검토해 정리한 편집자의 의견이다.

마지막으로, 평가의 한계를 안다고 평가를 버려서는 안 된다. 잴 수 없는 것을 잴 수 있는 것으로 착각하는 일과, 잴 수 있는 것마저 버리는 일은 둘 다 해롭다. 평가의 한계를 밝히면서도 확인할 수 있는 능력은 측정해야 한다.

남은 과제

평가에는 여전히 해결할 문제가 많다. 학습 데이터에 평가 문제가 섞이는 오염, 벤치마크에 맞춘 과적합, 실제 쓰임과의 괴리, 여러 단계에 걸친 작업의 평가, 평가 자체의 비용이다. 특히 에이전트처럼 여러 구성 요소를 결합한 시스템에서는 각 요소의 점수가 높아도 전체 작업에 성공한다고 보장할 수 없다. 이 글은 이런 과제를 정리하며 특정 평가 체계의 우열을 판단하지 않는다.

평가를 설계하는 입장

직접 평가를 설계할 때도 같은 원칙을 적용한다. 측정할 능력을 먼저 정하고, 그 능력을 확인할 과제를 고른다. 점수를 비교할 수 있도록 모델 규모, 프롬프트, 허용된 도구와 시도 횟수를 같은 조건으로 맞춘다. 이 평가에서 측정하지 못한 능력도 함께 적어둔다.

설계의 어려움은 대표성에 있다. 고른 과제가 실제 쓰임을 얼마나 닮았는가. 평가용 문제는 조건을 통제하기 쉽지만 실무와 차이가 날 수 있다. 실제 이슈를 쓰는 SWE-bench도 선택한 과제의 분포가 치우칠 수 있고 채점이 복잡하다. 어떤 방식을 택하든 이런 한계를 함께 밝혀야 한다.

평가 결과에 함께 적을 정보

평가 결과는 실제로 측정한 범위 안에서 해석해야 한다. 실험 조건과 평가 시점을 밝히고, 측정하지 못한 능력도 함께 적는다. 그래야 결과를 어떤 판단에 사용할 수 있는지 알 수 있다.