From Zero to Leaderboard: Agent Evaluation — Wolfram Ravenwolf, Weights & Biases

한 줄 핵심

에이전트 성능은 단일 평균점수가 아니라 벤치마크·하네스·모델·설정·샌드박스 조건을 고정한 뒤 여러 번 반복 측정해 신뢰성, 변동성, 비용까지 함께 봐야 제대로 비교할 수 있다.

시간별 요약

1. 0:00
   워크숍 준비 W&B 계정과 무료 추론 크레딧, 샌드박스 접근을 준비하면 실습을 그대로 따라갈 수 있고, 다른 provider를 쓰더라도 같은 흐름으로 적용할 수 있다.
2. 0:52
   Wolfram Ravenwolf 소개 이 워크숍은 WolfBench를 만든 배경과 함께, 제로에서 시작해 자신만의 모델·에이전트 평가 체계를 만드는 방법을 배우는 자리로 구성된다.
3. 3:31
   평가에 대한 사고방식과 방법론 도구는 자주 바뀌지만 사고방식이 가장 중요하며, 평가는 어떤 도구를 쓰느냐보다 무엇을 어떻게 재현 가능하게 측정하느냐가 핵심이다.
4. 4:12
   평균 하나가 신뢰성을 가리는 이유 한 번의 평균 점수는 분포를 숨기기 때문에, 운 좋은 실행과 실제 안정성을 구분하지 못하고 모델·에이전트의 숨은 trade-off도 놓치게 된다.
5. 5:48
   WolfBench의 다섯 가지 지표 평가에서는 평균뿐 아니라 최악·최고 성능, 해결 비율, 일관성, 토큰 사용량과 비용까지 함께 봐야 실제 사용 적합성을 판단할 수 있다.
6. 6:30
   같은 조건에서 반복 실행 조건을 하나라도 바꾸면 사실상 다른 벤치마크가 되므로, 동일한 설정으로 여러 번 실행해 우연성을 줄이고 결과를 공개해야 한다.
7. 7:24
   모델이 아니라 구성 전체를 평가하기 실제로는 모델 하나가 아니라 데이터셋, inference endpoint, agent version, sandbox, 설정까지 포함한 특정 구성 전체를 평가하게 되므로 변경 사항을 엄격히 고정해야 한다.
8. 9:53
   평가 파이프라인의 여섯 계층 벤치마크, evaluation harness, sandbox, agent harness, 모델, 서비스와 라우팅까지 여섯 계층을 각각 교체 가능한 요소로 보고 조합을 명확히 정의해야 한다.
9. 10:50
   벤치마크 선택과 고정 에이전트 평가에는 Terminal Bench 같은 agentic benchmark가 적합하며, 버전이 바뀌면 비교가 깨지므로 사용 중인 버전을 고정해야 한다.
10. 12:37
    Harbor와 평가 러너 버전 평가 실행 도구로 Harbor, Inspector, LM Evaluation harness 등을 고를 수 있지만, 비교 가능성을 위해 한 버전을 유지하고 필요하면 포크를 관리하는 편이 안전하다.
11. 14:31
    격리된 샌드박스 로컬 환경을 직접 바꾸지 않으려면 각 작업마다 격리된 sandbox가 필요하며, Docker보다 클라우드 sandbox가 병렬화와 안정성 면에서 유리하다.
12. 16:37
    에이전트 하네스 비교 Cursor, Claude, Codex, Open Claude, Hermes agent, Terminus 2처럼 서로 다른 agent harness를 비교할 수 있으며, 선택한 agent와 모델 provider를 명확히 적어야 결과 해석이 가능하다.
13. 18:38
    결과를 바꾸는 설정들 context window, thinking/reasoning 수준, system prompt, tool access, sandbox 자원은 모두 성능을 크게 바꾸므로 모델 비교보다 먼저 설정 고정이 필요하다.
14. 20:00
    프롬프트·도구·자원 제한 시스템 프롬프트와 도구 권한이 달라지면 에이전트 행동이 완전히 달라지고, CPU·메모리 부족이나 웹 접근 허용 여부도 점수에 직접 영향을 준다.
15. 21:33
    타임아웃·동시성·재시도 타임아웃, concurrency, retry policy, temperature, top_p, max tokens를 어떻게 정하느냐에 따라 비용과 결과가 크게 달라지므로 실험 목적에 맞는 균형이 필요하다.
16. 25:35
    추론 provider 라우팅 고정 OpenRouter처럼 여러 provider로 라우팅되는 환경에서는 한 벤치마크 실행 중 provider가 섞이지 않도록 라우팅을 고정해야 결과가 비교 가능해진다.
17. 27:39
    Git 복구 작업 실행 실제 실행은 env 파일을 불러와 Harbor run을 돌리는 방식이며, 샌드박스가 생성되고 agent가 Git 복구 작업을 수행한 뒤 trajectory와 결과가 수집된다.
18. 30:41
    점수보다 증거를 남기기 단일 점수만 남기지 말고 실행 기록과 trajectory를 함께 보관해야 하며, 여러 번 실행한 뒤에야 평균과 완주율 같은 의미 있는 지표를 계산할 수 있다.
19. 31:49
    WolfBench 수집 도구 WolfBench Toolkit은 여러 실행 결과를 모아 분석하는 수집기 역할을 하며, 공개 저장소와 대량의 실행 결과를 통해 비교·재사용 가능한 형태로 정리된다.
20. 34:19
    Marimo 대시보드에서 실행 검토 Marimo 기반 대시보드에서 로컬 실행과 VM 실행을 함께 보고, 업로드된 trace와 결과를 한 곳에서 확인할 수 있다.
21. 34:59
    불완전하고 잘못된 실행 필터링 모든 테스트를 끝내지 못했거나 에러·타임아웃이 많은 실행은 제외해야 하며, 실제로 사용한 thinking 설정과 모델 이름도 기록과 일치하도록 맞춰야 한다.
22. 36:09
    결과 내보내기와 차트 생성 여러 실행 결과를 하나의 JSON으로 저장한 뒤 차트를 생성하고, 필요하면 웹 사이트로 업로드해 다른 사람과 같은 스냅샷을 공유할 수 있다.
23. 36:50
    한 작업에서의 만점 단일 작업에서는 점수 1.0으로 성공할 수 있지만, 이것만으로는 전체 벤치마크 성능을 대표하지 않으므로 정식 실행으로 보기 어렵다.
24. 37:18
    인터랙티브 리더보드 읽기 리더보드는 단순 순위표가 아니라 필터링·재정렬·스크린샷 공유가 가능한 분석 도구이며, 모델 성능뿐 아니라 무엇을 측정 중인지 질문하게 만든다.
25. 39:06
    일관성·평균·상한 매번 성공하는 비율은 일관성, 흔히 보는 값은 평균, 한 번이라도 도달한 최고치는 ceiling이며, 세 지표가 함께 봐야 모델의 신뢰도를 판단할 수 있다.
26. 41:22
    토큰 사용량과 총비용 비슷한 점수라도 토큰과 비용이 크게 다를 수 있어, 성능이 좋은 모델이 오히려 더 비싸거나 느릴 수 있다는 점을 반드시 비교해야 한다.
27. 45:24
    추론을 더 늘리면 점수가 낮아질 때 thinking을 max로 올리면 항상 좋아지는 것이 아니라, 과도한 추론으로 행동이 늦어져 오히려 점수가 떨어질 수 있으며 trace로 그 원인을 확인해야 한다.
28. 47:39
    Weave trace 들여다보기 bar chart는 주장이고 trace는 증거이므로, 각 점수의 배경이 되는 5회 실행과 세부 행동을 Weave에서 직접 확인해야 결과를 신뢰할 수 있다.
29. 49:13
    구성과 실패 원인 점검 벤치마크 버전, agent 버전, provider 라우팅, sandbox 자원, retry와 timeout, inference 엔진 상태까지 점검해야 실패가 모델 탓인지 인프라 탓인지 구분할 수 있다.

실무 인사이트

• 실무에서는 단일 평균점수 대신 최소한 일관성, 평균, 최고치, 비용을 함께 비교하는 대시보드를 만들어야 의사결정이 쉬워진다.
• 평가 재현성을 높이려면 벤치마크·하네스·provider·agent·sandbox 버전을 모두 명시하고, 실행 로그와 trace를 함께 보관해야 한다.
• agent 평가에서 점수가 낮을 때는 모델 개선을 먼저 하기보다 timeout, concurrency, routing, sandbox 자원 같은 환경 요인을 먼저 의심하는 편이 효율적이다.