AI Engineer 발표자는 평가 점수가 100점이면 모델이 아니라 평가가 틀렸다고 말합니다 | DAKER 커뮤니티

AI Engineer 채널에 11월 1일 올라온 발표 「If Your AI Scores 100%, Your Eval Is Wrong」(약 19분)에서 AI 안전 연구자 Ramakrishnan Lokanathan은 자기 평가에서 100점이 나오면 모델이 훌륭한 것이 아니라 평가가 너무 쉬운 것이라고 말합니다. 발표자는 85~90점에 이르면 문제를 더 어렵게 바꿔야 한다고 덧붙입니다. 에이전트를 만드는 해커톤 팀이라면 오늘 할 일은 하나입니다. 지금 쓰는 테스트 문항 가운데 우리 에이전트가 이미 다 맞히는 문항을 골라내고, 그 자리에 아직 틀리는 문항을 채워 넣는 것입니다.

평가는 시험이고 시험은 신호 하나일 뿐입니다

발표는 평가(eval)를 사람의 시험에 빗대며 시작합니다. SAT가 대학 준비도를 알려 주는 여러 신호 중 하나이듯, SWE-bench나 Humanity's Last Exam 점수도 에이전트 능력의 한 단면일 뿐이라는 설명입니다. 발표자가 정리한 평가의 목적은 「제품이 사용자에게 한 약속을 실제 성능이 지키고 있는가」를 확인하는 일입니다.

점수가 100점 만점에 100점인 평가가 있다면 그 평가는 틀린 것이고, 충분히 야심 차지 않으며, 충분히 시험하지 않는 것입니다. — 발표 중(06:19 무렵, 번역)

발표자는 공개 모델 평가에서도 85~86점이 최고 수준이고 100점은 나오지 않는다고 짚습니다. 그래서 평가를 설계하기 전에 「가장 야심 찬 성공」을 먼저 정의하라고 권합니다. 질문은 세 가지입니다. 반드시 일어나야 하는 일은 무엇인지, 절대 일어나면 안 되는 일은 무엇인지, 언제 멈춰야 하는지입니다.

최종 답만 보면 놓치는 실패가 있습니다

발표에는 컵 사진의 배경만 바꿔 달라고 요청한 예시가 나옵니다. 결과물의 배경은 크림색으로 바뀌었지만 컵 손잡이가 두 개가 됐습니다. 입력과 최종 출력만 비교하면 「배경 변경 성공」으로 채점될 수 있는 실패입니다. 발표자는 워크플로가 100단계라면 단계마다 들어가는 것, 나오는 것, 기대 결과를 따로 확인해야 한다고 설명합니다. 도구 호출을 맡은 단계라면 그 단계의 평가는 도구 호출 정확도를 재도록 설계해야 한다는 점도 덧붙입니다.

점수 하나 대신 세 겹으로 확인합니다

발표자가 말하는 종합 평가 체계는 다음 세 층입니다.

• 자동 점검: 평가 문항을 CI 파이프라인에 넣어 배포할 때마다 다시 돌립니다. 모델을 고를 때 한 번 받은 점수로 끝내지 않습니다.
• 사람 검토: 에이전트가 평가 과정을 빠르게 만들 수는 있지만 평가 결과의 최종 검토자를 에이전트에게 맡기지 말라고 강조합니다.
• 적대적 테스트: 워크플로를 어디서 깨뜨릴 수 있는지 일부러 어려운 상황을 만들어 봅니다.

발표자는 여기에 게임을 평가 수단으로 더하는 오픈소스 Python 패키지 eSlams도 소개합니다. 체스·바둑(보이는 상태에서의 계획), 포커(숨은 정보 아래의 결정), 협동 게임 등 약 50종의 게임을 지원하고, 기존 에이전트와 새 모델을 서로 대국시켜 승패보다 전략을 바꾸는 방식과 실수에서 빠져나오는 과정을 관찰하자는 제안입니다. 발표자가 직접 만든 도구라는 점은 감안해서 보면 좋겠습니다.

예전에 되던 기능도 계속 시험합니다

발표자는 자신이 쓰던 Google Assistant가 Gemini로 바뀐 뒤 알림을 설정하지 못하고 「언어 모델이라 알림을 설정할 수 없다」고 답한 경험을 예로 듭니다. 새 모델이 전반적으로 훨씬 좋아도 이전 모델이 잘하던 일 하나를 못 할 수 있다는 것입니다. 그래서 모델이나 프롬프트를 바꿀 때마다 회귀 사례, 이미 알려진 과제, 과거 실패 사례를 다시 돌리라고 권합니다.

마지막 원칙은 실제 사용자의 실패를 새 테스트로 바꾸는 것입니다. 관측 도구나 좋아요·싫어요 피드백으로 실패를 모으고, 소프트웨어 QA처럼 재현한 뒤, 도구 호출이 문제였는지처럼 어느 단계가 실패했는지 확인하고 평가 문항으로 추가하는 흐름입니다. 발표자는 기존 평가가 잡지 못하는 마지막 5%의 예외 사례가 여기서 나온다고 말합니다.

해커톤 팀이 오늘 해 볼 수 있는 일

대회에서 에이전트나 LLM 서비스를 만들고 있다면 발표의 다섯 원칙을 작은 규모로 옮길 수 있습니다.

1. 지금 쓰는 테스트 문항을 돌려 이미 모두 통과하는 문항을 따로 표시합니다. 통과율이 85~90%를 넘으면 아직 틀리는 문항을 새로 만듭니다.
2. 최종 답만 채점하는 문항이 있다면 중간 단계(검색 결과, 도구 호출 인자, 생성 파일)를 확인하는 항목을 하나 붙입니다.
3. 프롬프트나 모델을 바꾸기 전에 지금 잘 되는 기능 목록을 회귀 테스트로 남겨 둡니다.
4. 시연이나 팀원 테스트에서 나온 실패를 바로 문항으로 옮깁니다.

진행 중인 대회와 해커톤은 DACON 대회 목록과 DAKER에서 확인할 수 있습니다. 평가 기준을 먼저 정하는 방법은 앞서 정리한 Arize 에이전트 평가 워크숍 글도 함께 참고할 수 있습니다.

한계

이 글은 발표 영상의 음성과 영상 설명란을 바탕으로 정리했습니다. 발표에 나온 수치(공개 모델 최고 85~86점, 게임 약 50종)는 발표자의 설명이며 별도로 검증하지 않았습니다. 발표 속 모델 간 대국 예시와 eSlams 관련 일정은 이 글에서 다루지 않았습니다.

출처: AI Engineer 채널, 「If Your AI Scores 100%, Your Eval Is Wrong - Ramakrishnan Lokanathan, eslams.com」(2026년 11월 1일 게시)