Mechanize: 나쁜 eval이 나쁜 코드를 만든다

eval, benchmark, RL environment는 겉보기엔 다르지만 기본 구조는 비슷함. 모델에게 줄 과제, 모델이 놓이는 환경, 결과를 채점하는 grader가 필요함
차이는 사용처임. eval은 연구자나 사용자가 모델을 고르는 데 쓰고, RL environment는 훈련 중 모델 weight를 실제로 바꾸는 데 씀
문제는 나쁜 grader가 모델에게 나쁜 습관을 가르친다는 점임. 테스트만 통과하는 hacky code, 사용자 edge case를 무시하는 코드, 겉보기만 그럴듯한 답변이 강화될 수 있음
CUA(computer-use agent)에서도 같은 문제가 생김. 브라우저 작업은 클릭, 스크롤, 입력, 대기, 복구가 길게 이어져서 단순 성공 여부만 보면 어디서 실패했는지 학습하기 어려움
Mechanize의 Head of Quality Max Cederman, CTO Egay Erdal, senior engineer Steven Yang이 eval, RL environment, GBA emulator eval, bad data 문제를 설명한 대담

eval과 RL environment는 어떻게 다른가?

가장 쉬운 비유는 시험지와 연습장임. eval은 모델이 지금 얼마나 잘하는지 보는 시험지이고, RL environment는 모델이 여러 번 풀면서 실력을 올리는 연습장에 가까움
둘 다 세 가지가 필요함. prompt는 모델에게 주는 과제, environment는 모델이 작업하는 세계, grader는 결과에 점수를 주는 채점기임
예를 들어 코딩 agent라면 prompt는 “이 버그를 고쳐라”, environment는 repo와 terminal, grader는 테스트 통과 여부가 될 수 있음
다만 RL은 sample inefficient함. 모델은 같은 능력을 배우기 위해 아주 많은 시도를 해야 함. 그래서 RL environment는 싸고 다양하게 많이 필요함
반대로 eval은 연구자가 의사결정에 쓰는 도구임. 연구자 시간은 비싸고 비교적 sample efficient하기 때문에, eval test case는 개당 더 비싸더라도 품질과 신뢰도가 중요함
lab 내부에서는 공개 모델보다 훨씬 많은 checkpoint가 존재함. 매일 조금씩 달라지는 모델이 나빠졌는지 좋아졌는지 보려면, 공개 발표보다 훨씬 자주 eval을 돌려야 함

구분	쉬운 설명	중요한 점
Benchmark	공개 시험지	외부 비교에 좋지만 포화되거나 오염될 수 있음
Eval	내부 의사결정용 시험지	노이즈와 bias가 낮아야 연구 판단에 쓸 수 있음
RL environment	모델 훈련용 연습장	싸고 다양해야 하며 reward hack을 막아야 함
Grader	채점기	잘못 만들면 모델이 잘못된 행동을 배움

나쁜 grader는 왜 나쁜 코드를 만들까?

핵심은 “테스트 통과”와 “좋은 소프트웨어”가 같은 말이 아니라는 점임
사람이 PR에 넣는 테스트는 보통 회귀 방지용임. 나중에 같은 버그가 다시 생기지 않게 막는 용도이지, 다른 사람이 만든 구현이 제품 품질까지 좋은지 평가하려는 완전한 시험지가 아님
모델을 이런 테스트로만 훈련하면 이상한 압력이 생김. 모델은 사용자가 원하는 좋은 기능보다, grader가 볼 것 같은 것만 맞추는 쪽으로 강화됨
예를 들어 form field를 추가하는 task에서 테스트가 특정 hidden test id를 기대하면, 모델은 기능 자체보다 test id를 추측하려고 할 수 있음
popup 예시도 비슷함. happy path 테스트는 “팝업 열기, 텍스트 입력, 저장”만 볼 수 있음. 하지만 실제 사용자는 텍스트를 드래그하다가 커서가 팝업 밖으로 나갈 수 있고, 이때 팝업이 닫히면 입력이 날아감
이런 문제는 unit test 몇 개로는 잘 안 잡힘. real user는 high entropy라서 사람이 예상하지 못한 방식으로 제품을 씀
그래서 나쁜 eval은 단순히 점수에 noise를 넣는 정도가 아님. systematic bias를 만들 수 있음. task 수를 늘려 평균을 내도, 채점 방향 자체가 틀리면 모델은 계속 틀린 방향으로 좋아짐

GBA emulator eval은 무엇을 보여주나?

Mechanize는 GBA eval에서 모델에게 24시간 동안 Game Boy Advance emulator를 만들게 함
GBA는 deterministic hardware라서 이론상 검증 가능함. 같은 ROM과 같은 입력이면 같은 frame sequence가 나와야 하기 때문
그런데 모델은 boot screen은 꽤 잘 맞추지만, 실제 gameplay로 들어가면 성능이 크게 떨어짐
이유는 모델이 게임을 제대로 플레이하면서 테스트하지 않기 때문임. 대부분은 게임이 켜지는지만 보고, 조금 나은 모델도 start menu를 넘기는 정도에서 멈춤
실제 emulator 품질은 게임을 오래 플레이하면서 드문 failure mode를 계속 찾고, 재현하고, 테스트로 만들고, 패치하는 과정에서 올라감
이건 일반 소프트웨어도 같음. 보안 취약점, 복잡한 UI, 긴 workflow는 10시간 테스트해서 안 나왔다고 10,000시간 테스트에서도 안 나온다는 뜻이 아님
결국 어려운 부분은 코드를 쓰는 능력보다, 어떤 상황을 테스트해야 하는지 상상하고 실제 사용자처럼 환경을 흔드는 능력임

CUA에서는 왜 sample efficiency가 중요해지나?

CUA는 화면을 보고 브라우저나 앱을 조작하는 agent임. 단순 답변보다 실패 비용이 큼
한 작업 안에 클릭, 스크롤, 입력, 파일 업로드, 로그인, 오류 복구, 최종 확인이 길게 이어짐. 작은 실수 하나가 뒤 단계 전체를 망칠 수 있음
RL로 이런 agent를 훈련하려면 수많은 rollout이 필요함. 그런데 현실 브라우저 작업은 느리고, 비싸고, 가끔 위험함. 계정이 잠기거나, 잘못 결제하거나, 데이터를 지울 수도 있음
그래서 좋은 CUA eval은 “성공했는가”만 보면 부족함. 어디서 실패했는지, 복구했는지, 사용자가 원한 결과와 실제 KPI가 맞는지까지 측정해야 함
sample efficiency가 좋은 시스템은 적은 trace에서도 많이 배움. 실패한 브라우저 작업 하나를 버리지 않고, 어떤 step이 문제였는지 재사용 가능한 training signal로 바꿈
이 관점에서 CUA의 핵심 자산은 단순 action log가 아니라 verified trace임. task, browser state, action sequence, failure reason, grader가 함께 남아야 다음 모델이 더 적은 시도로 배울 수 있음

좋은 eval은 어떻게 만들어야 하나?

좋은 eval은 너무 쉽지도, 너무 어렵지도 않아야 함. 모든 모델이 0점이거나 모두 만점이면 의사결정에 쓸 수 없음
실제 사용자의 pain point에서 출발해야 함. “누군가는 필요하겠지”가 아니라, 내가 직접 모델을 쓰다가 반복해서 막힌 지점을 측정하는 편이 더 신뢰도가 높음
현실 전체를 완벽히 복제할 필요는 없음. 대신 task를 어렵게 만드는 핵심 조건은 남기고, 재현하기 어려운 부수 요소는 줄여야 함
agent grader를 쓸 때는 더 조심해야 함. verifier와 generator가 비슷한 수준이면, 모델은 진짜 좋은 답보다 verifier에게 그럴듯해 보이는 답을 만들 수 있음
특히 taste와 judgment가 필요한 영역에서는 더 많은 reasoning token만 넣는다고 해결되지 않을 수 있음. 취향이 나쁜 사람에게 시간을 100배 준다고 좋은 취향이 생기지 않는 것과 비슷함

eval과 RL environment 차이는 무엇인가요?

구조는 거의 같지만 쓰임이 다름. eval은 모델 성능을 재고 연구자나 사용자가 의사결정을 하는 데 쓰임. RL environment는 모델이 여러 번 시도하고 보상을 받으며 weight를 업데이트하는 훈련 환경에 가까움.

왜 테스트 통과만으로 AI 코드 품질을 판단하면 안 되나요?

테스트는 보통 전체 제품 품질을 평가하려고 만든 완전한 채점기가 아님. happy path나 특정 회귀만 볼 수 있음. 모델을 그 테스트에 맞춰 훈련하면, 실제 사용자 edge case보다 테스트 통과에 최적화된 코드를 만들 수 있음.

CUA agent에는 어떤 eval이 필요한가요?

CUA에는 긴 workflow를 단계별로 볼 수 있는 eval이 필요함. 단순히 마지막 성공 여부만 보는 것이 아니라, 어느 action에서 실패했는지, 복구했는지, 실제 사용자 목표를 만족했는지까지 기록해야 함. 그래야 실패 trace가 다음 학습 데이터가 될 수 있음.

1인기업 관점

usedesktop 같은 CUA 쪽에서 보면 이 얘기는 꽤 직접적인 것 같음. 브라우저 agent가 실패한 로그를 그냥 “실패”로 버리면 sample inefficient한데, 어느 클릭과 어느 state에서 망가졌는지 grader와 함께 남기면 자산이 될 수 있음. 결국 1인기업도 큰 모델을 직접 훈련하기 전부터, 자기 workflow의 verified trace를 모으는 쪽이 먼저일 듯함.

관련: OpenAI: 모델 평가를 다시 만드는 이유와 RL 시장은 왜 더 커질까도 같이 보면 좋음.

Mechanize: 나쁜 eval이 나쁜 코드를 만든다 (youtube.com) ↗