breakinglog
Microsoft와 Hugging Face가 10월 3일 공개한 공동 글은 AI 에이전트 평가 환경 ThinkingBox를 Hugging Face와 OpenEnv를 통해 직접 실행하는 경로를 안내했습니다. 같은 일을 한 번 성공하는 것과 반복해서 매번 성공하는 것을 분리해 측정하며, 최신 비교에서는 Claude Opus 5.5도 507개 업무 가운데 241개, 47.53%만 20회 연속 성공했습니다.
다만 ThinkingBox-Bench 자체가 10월 3일 처음 나온 것은 아닙니다. 벤치마크 v1.0은 8월 17일 공개됐고, Microsoft의 기술 설명은 8월 19일, 논문 초판은 8월 20일 나왔습니다.
이번에 새로 확인된 것은 10월 3일 Microsoft와 Hugging Face 공동 글을 통해 Hugging Face에서 이용할 수 있게 되고 OpenEnv 실행 경로가 공개됐으며, Claude Opus 5.5, GPT-6 Astra, GPT-5.6 Sol 등을 포함한 최신 비교 결과가 함께 정리됐다는 점입니다.
에이전트가 “완료”라고 말해도 실제 데이터가 틀릴 수 있습니다
ThinkingBox의 평가 방식은 최종 답변이 자연스러운지보다 에이전트가 작업 뒤 데이터베이스와 시스템 상태를 실제로 어떻게 바꿨는지를 확인합니다. 각 시도는 동일한 초기 상태에서 격리된 MCP 세션으로 시작하고, 종료 뒤 필요한 변경이 빠졌는지, 잘못된 값이 들어갔는지, 예상하지 않은 부작용이 생겼는지를 실행 가능한 검사로 판정합니다.
공동 글의 대표 사례도 이 차이를 보여 줍니다. 에이전트가 주문, 배송, 정책을 확인하고 여러 도구 호출을 정상적으로 마친 뒤 티켓을 해결 상태로 닫았지만, 실제 요구된 최종 상태는 아직 보류여야 했습니다. 대화와 도구 호출만 보면 그럴듯해도 최종 데이터 상태를 보면 실패인 셈입니다.
| 시점 | 확인된 내용 |
|---|---|
| 8월 17일 | ThinkingBox-Bench v1.0 태그 공개. 507개 실행 가능한 업무 과제 포함 |
| 8월 19~20일 | Microsoft 기술 글과 arXiv 논문 초판 공개 |
| 10월 1일 | arXiv 논문 v4 업데이트 |
| 10월 3일 | Microsoft와 Hugging Face 공동 글 공개. Hugging Face 제공과 OpenEnv 실행 절차, 최신 프론티어 모델 결과 정리 |
단일 성공률과 ‘20번 모두 성공’은 순위가 크게 달랐습니다
벤치마크는 소매, 여행과 숙박, 자동차보험, 네오뱅크 내부 IT, 컨설팅 IT와 HR 등 5개 영역의 507개 상태 기반 업무를 다룹니다. 각 모델은 같은 업무를 20번 독립적으로 실행했습니다. 공동 글의 현재 표에서 Claude Opus 5.5는 전체 단일 시도 성공률인 pass@1이 67.16%로 가장 높았지만, 20회 모두 성공한 업무는 241개였습니다.
| 모델 | pass@1 | 20회 모두 성공한 업무 |
|---|---|---|
| Claude Opus 5.5 | 67.16% | 241/507 (47.53%) |
| GPT-6 Astra | 58.31% | 231/507 (45.56%) |
| GPT-5.4 | 65.36% | 128/507 (25.25%) |
| GPT-5.6 Sol | 61.91% | 82/507 (16.17%) |
| Kimi-K3 | 57.37% | 68/507 (13.41%) |
Kimi-K3는 반대로 20번 중 한 번이라도 성공한 업무 범위는 476개, 93.89%로 가장 넓었지만 20번 모두 성공한 업무는 68개뿐이었습니다. 즉 “재시도하면 언젠가는 할 수 있는가”와 “매번 같은 품질로 해낼 수 있는가”는 서로 다른 지표입니다.
실패했는데도 67%는 겉으로 정상 종료됐습니다
더 중요한 결과는 실패가 겉으로 잘 드러나지 않는다는 점입니다. 연구진이 12개 LLM의 공통 집합에서 분석한 121,680개의 유효 시도 가운데 79,853개가 실행 가능한 검사에 실패했습니다. 그런데 이 실패 시도 중 67.24%는 상태를 바꾸는 도구까지 호출하고 마지막 도구 오류 없이 정상적으로 종료됐습니다.
실패한 시도에서는 잘못된 필드 값이 77.61%, 의도하지 않은 추가 변경이 43.30%, 필요한 변경 누락이 25.36%에서 발견됐습니다. 이 항목들은 서로 겹칠 수 있으므로 합계가 100%가 되는 분류는 아닙니다. 연구진이 별도로 붙인 실패 시그니처에서도 평균적으로 79.9%가 도구 사용 단계와 연결됐지만, 이것 역시 관찰 가능한 분류이지 단일한 원인이라고 단정한 수치는 아닙니다.
실제 에이전트를 운영한다면 ‘답변’보다 마지막 상태를 확인해야 합니다
이 결과가 바로 모든 실제 에이전트의 실패율을 의미하는 것은 아닙니다. 507개 과제는 가상의 조직과 합성 데이터를 사용한 벤치마크이고, 공개 수치는 연구진이 보고한 결과로 독립 재현 결과와는 구분해야 합니다. 507개 중 477개는 상태만으로 판정하고 30개는 최종 답변의 의미를 확인하는 추가 루브릭을 사용합니다.
그럼에도 실제 업무 자동화에서 확인할 지점은 명확합니다. 메일을 보냈다는 답변, 티켓을 닫았다는 문장, 성공한 것처럼 보이는 도구 호출만으로 완료를 판단하지 않고 실제 레코드와 부작용을 마지막에 다시 읽어 확인하는 검사가 필요합니다. 같은 업무를 여러 번 반복해 성공 편차를 확인하고, 되돌리기 어려운 변경에는 사람 승인을 두는 방식도 공동 글이 제안하는 운영 방향입니다.
ThinkingBox는 현재 Hugging Face의 OpenEnv 환경과 Microsoft의 오픈소스 저장소를 통해 직접 재현할 수 있습니다. 다만 OpenEnv가 모델 실행을 대신 제공하는 관리형 서비스는 아니며, 공식 안내대로 모델 엔드포인트와 필요한 로컬 인프라는 사용자가 준비해야 합니다.
따라서 이번 공개의 의미는 새로운 호스팅형 에이전트 제품 출시보다, 에이전트의 “말”이 아니라 실제 결과 상태와 반복 신뢰성을 검증하는 평가 경로가 더 쉽게 공개됐다는 데 있습니다.
