ThinkingBox: 에이전트 태스크를 한 번 해결하는 것과 20번/20번 해결하기 비교: 터미널 데이터베이스 상태로 평가된 507개 상태

논문 Figure 1b에서 발췌했습니다. 저는 이 논문의 저자 중 한 명입니다 (Microsoft). 해당 논문, 코드, 데이터셋은 공개되어 있으며 ThinkingBox는 Hugging Face OpenEnv에서도 이용 가능합니다. 원시 평가 궤적(Raw evaluation trajectories)은 공개되지 않습니다. 하단에 링크가 있습니다.

저희는 단일 에이전트 성공률이 반복 시 얼마나 유지되는지, 그리고 '에이전트가 태스크를 완료했다'는 것이 백엔드/데이터베이스가 실제로 올바른 상태로 끝났다는 것을 의미하는지 알고 싶었습니다. Thinkingbox-Bench 설정에는 5개 도메인(소매업, 여행/호텔업, 자동차 보험, 네오뱅크 내부 IT, 컨설팅 IT/HR)에 걸쳐 507개의 정책 기반 비즈니스 워크플로우가 포함되어 있습니다. 각 태스크는 독립적으로 실행된 20번의 시도(attempt)로 실행되며, 각각 동일한 깨끗한 백엔드 상태에서 시작합니다: 모델당 총 10,140회의 시도가 이루어집니다.

시뮬레이션된 사용자가 개인적인 컨텍스트를 보유하고 요청받을 때만 이를 공개하는 방식으로 평가가 진행됩니다. 평가는 터미널 백엔드 상태와 부작용(side effects)이 요구되는 최종 상태와 일치하는지 비교합니다. 올바른 결과를 산출하는 모든 궤적은 통과하며, 잘못되거나 누락되었거나 추가적인 효과를 가진 것은 실패합니다. 507개 태스크 중 477개는 오직 상태만으로 평가되며, 30개는 최종 응답의 좁은 속성(narrow property)도 확인합니다.

세 가지 지표가 있습니다. 이들은 끊임없이 혼동되기 쉽습니다:

• pass@1: 모든 시도 중 성공한 비율 (fraction of all attempts that succeed)
• pass@20: 20번의 시도 중 적어도 한 번 해결된 태스크의 비율 (fraction of tasks solved at least once across the 20 attempts)
• all-20: 20번의 시도 모두에서 해결된 태스크의 비율 (fraction of tasks solved on every one of the 20 attempts). 이는 고정된 시도 예산에 대한 관찰된 카운트일 뿐, 추정치(estimator)는 아닙니다.

두 가지 발견 사항이 있습니다. 발견 가능성(Discovery)과 반복 가능성(repeatability)은 모델을 매우 다르게 순위화합니다. 첨부된 그림에는 9개 모델에 대한 세 가지 지표가 모두 플롯되어 있으며, 주황색에서 녹색으로 퍼지는 범위 전체가 핵심입니다.

Kimi-K3는 측정된 범위 중 가장 넓어, 적어도 한 번 태스크를 해결한 비율은 93.89% (476/507)이지만, 20번 모두 해결한 비율은 13.41% (68/507)에 불과합니다. Claude Opus 5는 발견하는 비율이 더 적고(79.09%), 반복하는 비율은 훨씬 높습니다(47.53%, 즉 241개 태스크). Qwen3.8-27B의 경우, 적어도 한 번 해결한 비율은 89.35%이지만, 매번 해결한 비율은 7.50%입니다. pass@20으로 순위화하는 것과 all-20으로 순위화하는 것은 거의 반대되는 리더보드를 제공합니다. 실패는 종종 깔끔하게 보입니다.

12개 모델에 걸친 121,680개의 유효 트라이얼을 대상으로 한 회고적 제거(retrospective ablation) 분석에서, 79,853개가 실행 가능성 검사(executable checks)를 통과하지 못했습니다. 이 실패 사례 중 67.24%는 여전히 깔끔하게 종료되었고, 상태 변경 도구(state changing tool)를 호출했으며, 최종 도구 오류 없이 끝났기 때문에 완료 스타일의 프록시(completion-style proxy)로는 '완료됨'으로 점수화했을 것입니다. 이처럼 깔끔하게 종료된 실패 사례들에서 상태 검사 결과는 (카테고리 중복): 잘못된 필드 값: 77.61%, 의도치 않은 추가 효과: 43.30%, 필수 효과 누락: 25.36%입니다. 이것이 보여주지 않는 것: 태스크들은 엔터프라이즈 워크플로우 패턴의 합성 재구성물이며, 실제 운영 트래픽(production traffic)은 아닙니다. 저희 트라이얼 예산 내에서 20/20이라는 수치는 관찰된 카운트일 뿐, 미래 신뢰성을 보장하는 것은 아닙니다. 시뮬레이션된 사용자는 고정된 LLM입니다. 이것이 우리가 부록에서 논의할 변동성의 원천입니다. 실패 카테고리는 인과적 설명(causal explanations)이 아니라 결정론적 진단 레이블(deterministic diagnostic labels)입니다. 여러분은 507개 태스크 중 어떤 것을든 HF OpenEnv 환경을 통해 여러분 자신의 모델에 실행해 볼 수 있으며, 이것이 우리와 의견이 다를 경우 가장 빠르게 반박할 수 있는 방법입니다. 저희는 관찰된 전체 20회 카운트(observed all-20 count)와 플러그인 패스 k 추정치(plug-in pass k estimate)를 모두 부록에 보고합니다. 이들은 서로 다른 질문에 답하며 상당히 다를 수 있습니다: 하나는 고정된 20회 시도 캠페인에서 발생한 일을 기록하는 반면, 다른 하나는 추가적인 가정을 바탕으로 반복 성공을 추정합니다. 신뢰성 리더보드에서 어느 것에 중점을 두기를 원하시나요, 아니면 둘 다 보여주어야 할까요? 논문: https://arxiv.org/abs/2608.19741 코드: https://github.com/microsoft/thinkingbox 벤치마크 데이터: https://github.com/microsoft/thinkingbox-data OpenEnv 환경: https://huggingface.co/docs/openenv/environments/thinkingbox Hugging Face 블로그: https://huggingface.co/blog/microsoft/thinkingbox /u/tuhin_k 제출 [링크] [댓글]