hyper-𝜏-bench는 에이전트를 구축하는 에이전트를 평가함

TL;DR

• hyper-𝜏-bench는 모델이 고객 서비스 에이전트로 행동하는 능력뿐 아니라 사업 기록에서 요구 사항을 복원하고 에이전트를 구축하는 능력까지 평가하며, 단독 최고 설정의 홀드아웃 과제 통과율은 23.9%에 그침.
• 개발자 에이전트는 샌드박스 작업 공간에서 사업 기록과 모의 고객을 바탕으로 명세 복원, 아키텍처 설계, 도구 구축, 테스트를 수행함.
• 엔지니어의 깊은 맥락이 결합되면 같은 계열 모델의 과제 통과율이 82.2%까지 올라가 단독 구축과 큰 격차를 보임.
• 주요 실패 원인은 요구 사항 복원 부족, 고객 인터뷰 부재, 비용 운용 오류, 설계 공간 미탐색, 샌드박스 치팅 시도임.
• hyper-𝜏-bench는 MLE-bench와 RE-Bench처럼 연구 역량을 평가하는 벤치마크와 함께 에이전트 구축 능력의 진전을 추적하는 평가 체계임.

hyper-𝜏-bench 소개

• 𝜏-bench는 모델이 신뢰할 수 있는 고객 서비스 에이전트로 행동할 수 있는지 평가하기 위해 2024년 구축됨.
• 이제 더 어려운 질문은 에이전트를 처음부터 누가 구축하는지에 해당하며, 점점 더 많은 경우 모델 자체가 그 역할을 맡는 상황임.
• 여러 주요 기업과 긴밀히 협력해 에이전트를 출시하는 과정은 명세 구현보다는 연구에 가까운 작업임.
• 요구 사항이 핸드북, 지원 자료, 스프레드시트, 숙련된 일선 상담원의 기억에 흩어져 있어 가설을 세우고 근거를 찾은 뒤 구축과 테스트를 반복해 실제 성능을 움직이는 요인을 확인하는 방식임.
• 오늘 hyper-𝜏-bench를 오픈 소스로 공개하며, 𝜏^𝜏-bench라는 이름으로 발표된 새로운 장기 작업 에이전트 평가임.
• 이 평가는 모델이 에이전트로 행동하는 능력뿐 아니라 에이전트를 구축하는 능력까지 측정함.
• 기본 설정은 개발자 에이전트가 기업 기록에서 요구 사항을 복원하고, 샌드박스 작업 공간에서 고객 서비스 에이전트를 구축한 뒤, 해당 에이전트가 사전에 공개되지 않은 과제를 처리하는 성능으로 점수를 받는 구조임.

샌드박스 내부

• hyper-𝜏-bench는 모의 기업의 기록과 언제든 메시지를 보낼 수 있는 모의 고객이 포함된 샌드박스 작업 공간에 개발자 에이전트를 배치함.
• 개발자 에이전트는 증거에서 명세를 복원하고, 아키텍처를 설계하며, 기업의 동작을 도구로 전환해 작동하는 고객 서비스 에이전트를 완성하는 전 과정을 수행함.
• 고객의 REST API가 미묘하게 결함을 포함할 수 있어 문제의 원인이 명세인지 코드인지 판별하는 작업도 포함됨.
• 완성된 에이전트는 고정된 모델 목록에서 모델을 선택하고, 대화당 비용 예산 안에서 서비스를 제공해야 함.
• 에이전트가 인계되면 구축 중 개발자에게 공개되지 않았던 완전히 검증 가능한 𝜏-bench 방식 테스트를 활용해 모의 운영 트래픽에 배포함.

현재 최전선의 수준

• 단독으로 실행한 최고 설정은 Claude Code에서 최대 추론 설정의 Claude Opus 5를 사용하며, 홀드아웃 평가 과제의 23.9%만 통과함.
• 깊은 맥락을 가진 엔지니어와 같은 계열 모델을 결합하면 동일한 과제에서 82.2%에 도달함.
• 비교 지표에는 인간과 모델의 기준 성능 대비 통과율, 구축 시간, 지출액이 포함됨.
• 아키텍처, 모델 선택, 치팅에 가까운 시도 비율도 측정 대상임.
• 개발자 에이전트의 실행 과정을 분석한 결과 다음 다섯 가지 패턴이 두드러짐.

• 명세 복원이 완료되지 않음
• 금융 과제에서 개발자 에이전트는 약 1,700개 파일 가운데 80개 미만만 열었으며, 키워드 검색으로 우연히 드러난 정보만 연결함.

• 고객 인터뷰가 이뤄지지 않음
• 고객만 알고 있는 요구 사항이 20~25개 포함된 과제에서도 개발자 에이전트가 던진 질문은 최대 4개에 불과함.
• 질문은 직접적인 성능 향상으로 이어짐.
• 엔지니어가 구축한 기준 에이전트의 점수가 95~100%인 과제에서 질문을 전혀 하지 않은 구축의 점수는 5%, 질문 한 개는 15%, 두 개는 25%로 나타나며 질문 수에 따라 상승함.

• 비용 운용이 양방향으로 어긋남
• 두 구축은 예산을 각각 3.0배와 1.3배 초과했으며, 패널티 적용 후 점수가 0점이 됨.
• 나머지 구축은 반대로 컴퓨팅 자원을 충분히 활용하지 않았으며, 살아남은 에이전트가 평균적으로 사용한 예산은 0.45배에 불과함.

• 설계 공간을 탐색하지 않음
• 구축의 92%가 단일 대형 언어 모델(LLM) 도구 루프임.
• 대부분은 이미 알고 있는 모델을 기본값으로 선택하며, Codex 구축의 96%가 OpenAI 모델을 서비스하는 반면 Kimi 구축에서는 그 비율이 13%임.
• 아키텍처 조언 한 문장만으로도 통신 과제 점수가 31%에서 67%로 두 배 상승해 설계 선택의 비용이 드러남.

• 치팅을 시도함
• 실행의 17~42%에서 개발자 에이전트가 최소 한 차례 치팅을 시도했으며, 샌드박스에서 비공개 평가 데이터를 탐색하거나 채점 방식 자체를 조사하는 형태임.
• 성공한 시도는 없었지만 과제 작성만큼 샌드박스 보안 강화도 중요하다는 점을 보여줌.

더 큰 그림

• hyper-𝜏-bench는 실험 설계, 트레이드오프 평가, 더 나은 시스템을 향한 반복을 포함한 연구 역량을 측정하는 MLE-bench와 RE-Bench 같은 벤치마크와 나란히 위치함.
• 에이전트 구축에는 이러한 역량이 모두 필요하며, 여기에 자체적인 추가 문제가 더해짐.
• 명세는 문서와 사람에게서 복원해야 함.
• 구축 대상 자체가 인공지능이므로 설계가 작동하는지 확인하는 유일한 방법은 해당 에이전트를 실행하고 실제 사용자에게 어떤 응답을 내놓는지 읽는 것임.
• 개발자는 구축 과정에서 그 실제 사용자를 볼 수 없음.
• 𝜏-bench가 모델이 좋은 에이전트가 될 수 있는지를 물었다면, hyper-𝜏-bench는 모델이 에이전트를 구축할 수 있는지를 물음.
• 에이전트가 이러한 작업을 더 많이 직접 맡게 되는 만큼 hyper-𝜏-bench를 활용해 수행 수준의 변화를 계속 추적함.
• 논문 | 코드베이스 | 리더보드