LLM 평가 벤치마크의 함정과 재현성 확보 방법 — 엔비디아 평가 팀이 파이토치 콘퍼런스에서 밝힌 실무 사례 정리

핵심 메시지

• 최신 모델 공개 때마다 20개가 넘는 벤치마크 점수가 발표되지만, 프롬프트·설정·코드가 공개되지 않아 논문끼리 숫자를 비교하기 어렵다.
• 코딩 벤치마크는 어떤 에이전트 하네스를 썼는지, 어려운 과제를 뺐는지, 추론 기능을 켰는지에 따라 점수가 달라진다.
• 평균값 하나만 보고하는 관행 대신 표준오차·신뢰구간·반복 횟수·유의성 검정을 함께 제시해야 한다는 것이 발표의 핵심 주장이다.
• 평가 도구가 다루는 대상이 정적인 문제 풀이에서 도구를 쓰는 다중 턴 에이전트, 나아가 기억을 가진 상태형 에이전트로 옮겨가고 있다.
• 평가 인프라 자체가 점수를 왜곡할 수 있어, 실패한 샘플의 재시도 방식이나 시간 제한 같은 운영 조건까지 기록해야 한다.

쉽게 이해하기

파이토치 콘퍼런스 유럽 발표에서 엔비디아의 평가 담당 매니저가 대규모 언어모델 평가(eval)의 현주소를 짚었다. 그는 최근 모델 공개 사례를 보면 보통 20개 이상, 많게는 80개가 넘는 벤치마크를 돌린 결과가 함께 발표되지만 정작 그 숫자를 다시 만들어낼 방법은 공개되지 않는 경우가 대부분이라고 지적했다. 모델 카드에는 점수만 남고 프롬프트, 설정 파일, 실행 코드는 빠져 있어 같은 이름의 벤치마크라도 서로 다른 논문의 숫자를 나란히 놓고 비교하기가 사실상 어렵다는 것이다.

구체적인 예로 코딩 능력을 재는 벤치마크가 언급됐다. 같은 벤치마크라도 어떤 코딩 에이전트 하네스를 썼는지, 실행이 까다로운 일부 과제를 빼고 돌린 것인지, 추론 기능을 켜고 잰 것인지에 따라 결과가 달라진다. 도구를 쓰는 평가에서는 어떤 검색 제공자를 붙였는지, 도구 호출 횟수를 몇 번으로 제한했는지가 영향을 미치고, 긴 문맥을 다루는 평가에서는 최대 출력 토큰 한도와 답변이 잘렸을 때의 처리 방식(0점 처리인지 제외인지)까지 점수를 좌우한다.

발표자가 제시한 해법은 모델과 가중치뿐 아니라 평가 레시피 자체를 공개하는 것이다. 엔비디아는 자사 개방형 모델 계열에서 학습 데이터와 학습 절차에 더해 평가에 쓴 설정과 도구까지 함께 내놓고 있으며, 시간과 연산 자원만 있으면 다른 사람이 같은 명령으로 숫자를 재현해 볼 수 있게 하는 것이 목표라고 설명했다. 평가가 복잡하더라도 사용자 입장에서는 도구를 설치하고 설정 파일 하나로 명령을 한 번 실행하는 수준을 넘어서지 않아야 한다는 원칙도 함께 제시됐다.

현장에서 반복되는 나쁜 관행도 열거됐다. 자기 모델에 유리한 프롬프트만 골라 쓰는 것, 여러 번 돌린 결과 중 가장 좋은 값 하나만 보고하는 것, 표준오차나 신뢰구간 없이 평균만 내놓는 것, 재현에 필요한 로그와 설정을 남기지 않는 것, 그리고 학습 데이터에 평가 문제가 섞여 들어갔는지(오염) 확인하지 않는 것이다. 벤치마크 자체가 표본 수가 적거나 난도가 높아 결과가 크게 흔들리는 경우도 많은데, 이런 상황에서 숫자 하나만으로는 성능 차이가 의미 있는 것인지 판단할 수 없다.

평가 대상이 달라지고 있다는 점도 강조됐다. 정적인 문제와 정답을 맞춰 보던 1세대, 명령줄 하나로 여러 과제를 표준적으로 돌리는 2세대를 지나, 지금은 모델이 도구를 통해 환경과 상호작용하는 다중 턴 환경이 중심이 됐다. 여기에 기억을 갖고 세션을 넘나드는 상태형 에이전트까지 등장하면서, 평가 도구도 환경을 제공하고 채점 함수를 붙이는 방식으로 구조가 바뀌고 있다는 설명이다. 모델이 만든 코드를 안전하게 실행하기 위한 샌드박스, 문맥 압축 전략, 도구 호출 상한 같은 운영 설계가 평가의 일부가 됐다.

주요 인사이트

• 평가 결과를 볼 때 확인해야 할 것은 점수가 아니라 조건이다. 어떤 도구를 줬는지, 몇 번 반복했는지, 실패한 응답을 어떻게 처리했는지가 빠져 있으면 그 숫자는 다른 숫자와 비교할 수 없다.
• 발표자는 평가 인프라 자체가 점수를 바꾼 사례를 공유했다. 클러스터의 실행 시간 제한 때문에 끝나지 못한 샘플이 처음부터 다시 돌아가면서, 일부 문제만 여러 번 시도한 셈이 되어 점수가 왜곡됐다.
• 도구 사용 평가에서는 상한선이 안전장치 역할을 한다. 검색 도구를 주지 않은 상태에서 모델이 직접 웹 요청을 시도하다 봇으로 차단당한 뒤에도 계속 재시도해, 단 두 개의 샘플 때문에 평가가 7일간 멈추고 500시간이 넘는 GPU 시간이 낭비된 사례가 소개됐다.
• 회귀 검사는 모델뿐 아니라 프레임워크에도 필요하다. 새 버전의 프레임워크나 추론 엔진이 정확도를 떨어뜨리지 않았는지 기준선과 비교해 자동으로 통과·불통과를 판정하는 방식이 CI 파이프라인에 쓰인다.
• 평가 실패를 사람이 일일이 들여다보는 대신 로그를 읽는 에이전트에게 맡기는 시도도 진행 중이다. 다만 내부 인프라 맥락을 함께 제공하지 않으면 유용한 진단이 나오지 않는다는 단서가 붙었다.

자주 묻는 질문

관련 AI 소식