API 1,000개 중 하나를 고르자 성공률 5%: 아마존 SLATE 벤치마크 리뷰

원문 정보

Rongzhe Wei, Ge Shi, Min Cheng, Sarthak Ghosh, Vaibhav Gorde, Leman Akoglu, Pan Li, Na Zhang, "SLATE: A Large-Scale Benchmark for Long-Horizon API Selection in E-commerce Tool Use", arXiv:2611.03982 [cs.CL], 2026-11-02 제출. 소속: Amazon(7명), Georgia Institute of Technology(Pan Li). NeurIPS 부속 워크숍 "Agentic AI Benchmarks and Applications for Enterprise Tasks" 발표 논문. 데이터·시뮬레이터·평가 하니스 공개(geshijoker.github.io/slate/).

동료심사를 완전히 거치지 않은 워크숍 논문입니다(arXiv 등재 자체는 동료심사와 무관). 저자 8명 중 7명이 아마존 소속이고 나머지 1명(Pan Li)은 조지아공대 소속으로, 소속·자금이 아마존에 집중돼 있습니다. 다만 본문의 핵심 결론이 "현재 모델은 기업용 대규모 도구 선택에 크게 못 미친다"는 비판적 결과이고, 평가 대상도 아마존 자체 모델이 아니라 Qwen·Gemma·SmolLM·Tulu 계열 오픈 모델뿐이어서 자사 상용 에이전트를 홍보하는 방향의 이해상충은 약하다고 판단됩니다.

연구 개요

연구 질문은 "수백~수천 개 내부 API를 가진 기업이 LLM 에이전트에게 표준운영절차(SOP)를 맡길 때, 긴 호라이즌에 걸쳐 올바른 도구를 선택·조합할 수 있는가"입니다. 저자들은 기존 벤치마크가 이 조건을 충족하지 못한다고 지적합니다 — 도구 수가 적은 환경(τ-bench, AlfWorld)은 통제된 평가는 되지만 대규모 도구 공간을 반영하지 못하고, 도구 라이브러리가 큰 벤치마크는 단일 단계 호출이나 검색만 평가하거나 LLM 심판의 주관적 채점에 의존한다는 것입니다. SLATE는 약 1,000개 가상 e커머스 API 라이브러리와, 질의를 계층적 하위 단계로 분해한 100개 과제로 구성됩니다. 실제 API 1,000개를 구현하는 대신 Claude로 생성한 '맥락 인지 시뮬레이터'가 각 도구 호출의 결정론적 출력을 반환하고, 과제는 모든 참조 결과에 도달해야만 성공으로 채점됩니다 — LLM 심판 없이 자동·재현 가능한 평가를 노린 설계입니다.

핵심 결과

아래 수치는 모두 원문 표에서 직접 대조한 값입니다. 과제 성공률(Task success)과 단계별 정확도(Step-wise accuracy)는 기준이 다른 수치이므로 구분해 표기합니다 — 전자는 과제 전체가 끝까지 맞아야 100%, 후자는 개별 단계 하나의 정답률입니다.

원문 Table 2·Table 3. 과제 100개에 도구 1,000개(실사용 417개 + 방해용 583개)가 딸려 있고, 과제당 평균 세부 단계는 10.8개(7~14 범위), 단계마다 정답을 포함한 52개 선택지 중 하나를 고릅니다. 단계별 정확도는 36.6~74.8%로 나쁘지 않지만, 평균 10.6개 단계를 연쇄로 통과해야 과제가 성공하는 구조라 오차가 누적됩니다. 논문은 단계별 정확도 p=0.75를 10.6번 연속 통과할 확률이 약 4.7%라고 산술로 보이는데, 최고 과제 성공률 5.0%(Gemma-4-12B-it)가 바로 이 수준입니다.

결정 모델(선택 전용으로 파인튜닝한 모델) 도입 효과는 일관되지 않았습니다. 6개 쌍 중 4개 쌍은 결정 모델이 백본보다 단계별 정확도가 6.6~15.7%포인트 높았지만, Strands 계열 결정 모델 2개는 오히려 자신의 백본(Gemma)보다 17.8%포인트·20.3%포인트 낮았습니다. 원문 Table 5(오류 유형별 분해)로 교차 검산하면 이 수치들은 서로 맞아떨어집니다 — 예를 들어 Gemma-4-12B-it의 오류 비중(잘못된 도구 선택 22.6% + 누락 2.1% + 불필요한 호출 0.9%)을 100에서 빼면 74.4%로, Table 3의 단계별 정확도(74.4%)와 정확히 일치합니다. 원문 Table 6의 과제 범주별 결과는 범주당 과제가 6~13건뿐이라 편차가 컸습니다 — 범주별 최고 과제 성공률은 3.0%(구매자 사전 질문)부터 22.2%(선물·할인코드)까지 벌어졌는데, 표본이 작아 한두 건의 성패가 비율을 크게 흔든 결과로 읽어야 합니다.

신뢰도 평가

믿을 근거는 세 가지입니다. ① 평가가 결정론적 시뮬레이터와 end-to-end 과제 성공 지표로 구성돼 LLM 심판의 주관성이 없고, 모든 참조 해법이 시뮬레이터를 통과하도록 사전 검증했습니다. ② 선택지 순서를 3회 바꿔 반복해도 표준편차가 최대 1.3%포인트로 작아 결과가 순서 편향에 흔들리지 않습니다. ③ 추론 단계에서 정답 도구가 항상 선택지 52개 안에 포함되도록 설계해(검색 실패로 인한 혼선을 배제), 순수한 "선택" 능력만 분리해 측정했습니다.

감안할 점도 분명합니다. 동료심사를 완전히 거치지 않은 워크숍 논문이고, 질의·시뮬레이션 출력 모두 Claude가 생성한 합성 데이터라 실제 기업 API의 변칙성을 온전히 반영하지 못할 수 있습니다. 저자들은 생성 모델과의 편향을 피하려 평가 대상에서 Claude 계열을 제외했는데, 그 결과 GPT·Claude 등 현재 실무에서 널리 쓰는 폐쇄형 프런티어 모델의 성능은 이 논문만으로는 알 수 없습니다 — 평가 범위는 3B~12B 오픈 모델 6쌍뿐입니다. 또한 저자들은 "정답 도구 이름이 단계 설명문에 그대로 나오는 경우(전체의 16.1%)조차 정확도가 다른 단계보다 높지 않다"는 반직관적 결과를 스스로 보고했는데, 이는 모델이 명시적 힌트조차 일관되게 활용하지 못한다는 뜻일 수도 있고, 데이터 구성상 그 힌트가 선택에 실질적 도움이 되지 않게 만들어졌을 가능성도 배제할 수 없어 해석에 주의가 필요합니다.

관련 연구

세션 egress 차단으로 아래 관련 문헌의 원문은 이번 실행에서 재열람하지 못해 WebSearch로 제목·저자·venue·핵심 수치를 독립 확인했습니다. 아래 수치는 관계 서술에만 사용하고, 위 '핵심 결과'에는 포함하지 않았습니다.

• Yao et al.(2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains — 선행 연구(prior). 소매·항공 두 도메인에서 에이전트-사용자 대화와 정책 준수를 평가하는 초기 도구 사용 벤치마크로, 도구 수가 적고 단일 도메인입니다. SLATE는 같은 "도구 사용" 축을 도구 1,000개·11개 과제 범주로 확장합니다.
• Trivedi et al.(2024, ACL, Best Resource Paper). AppWorld: A Controllable World of Apps and People for Benchmarking Interactive Coding Agents — 선행 연구(prior). 9개 앱·457개 API를 실제로 구현한 환경에서 750개 과제를 상태 기반 단위 테스트로 채점하며, 최고 모델(GPT-4o)이 일반 과제의 약 49%를 해결했습니다. SLATE는 라이브 API 구현 대신 시뮬레이터를 쓰고 도구 수를 2배 이상(1,000개)으로 늘렸는데, 성공률이 49%에서 5.0%로 급락한 것은 도구 공간·단계 수 확장이 난이도에 미치는 영향이 크다는 것을 보여줍니다.
• He et al.(2025, ICLR 2026). TRAJECT-Bench: A Trajectory-Aware Benchmark for Evaluating Agentic Tool Use — 확장·대조 연구(extension). SLATE와 같은 Amazon 소속 저자가 참여했고, 10개 실세계 도메인에서 1,000개 이상 도구로 궤적(순서·병렬 호출) 단위 정확도를 채점합니다. 다만 SLATE 자신의 Table 1 분류에 따르면 TRAJECT-Bench는 end-to-end 과제 성공 지표를 쓰지 않아, "궤적이 맞는가"와 "과제가 끝까지 성공했는가"라는 서로 다른 채점 철학을 보여주는 대조군입니다.

세 선행 연구를 종합하면, 도구 사용 벤치마크는 '작은 도구 공간에서의 대화·정책 준수(τ-bench)' → '수백 개 라이브 API에서의 코딩 과제(AppWorld)' → '수천 개 도구에서의 궤적 정확도(TRAJECT-Bench)'로 확장돼 왔습니다. SLATE는 이 흐름에서 "도구 공간을 더 키우면서도 end-to-end 성공만으로 엄격히 채점"하는 조합을 택해, AppWorld 대비 성공률이 급락하는 결과로 도구 공간 확장의 비용을 수치화했습니다 — 선행 연구와 결론이 충돌하지는 않습니다.

리뷰어 판단

첫째, 5.0%라는 헤드라인 수치 자체보다 "단계별 정확도 65~75%가 누적되면 과제 성공률이 한 자릿수로 떨어진다"는 구조가 더 중요한 발견이라고 판단합니다. 벤더들이 흔히 보여주는 "도구 호출 정확도 OO%" 같은 단일 단계 지표는, 10단계 이상 체이닝되는 실제 SOP 자동화의 체감 성공률을 크게 과대평가할 위험이 있습니다.

둘째, 결정 모델(선택 전용 파인튜닝) 도입이 항상 이득이라고 가정하면 안 된다고 판단합니다. Strands 계열 두 쌍 모두 백본보다 17.8~20.3%포인트 낮아졌다는 결과는 "선택 전용으로 파인튜닝하면 무조건 좋아진다"는 업계의 암묵적 가정에 반례를 제공합니다. 도구 선택기를 도입하기 전에는 반드시 백본 단독 성능과 A/B로 비교해야 합니다.

셋째, 과제 범주별 분산이 3.0~22.2%로 컸다는 점은 이 벤치마크의 헤드라인 숫자를 자사 SOP에 그대로 대입하면 안 된다는 신호로 읽습니다. 범주당 과제가 6~13건뿐이라 통계적으로는 약하지만, 좁고 반복적인 SOP(할인코드·선물)가 개방형 SOP(사전 구매 질문)보다 상대적으로 다루기 쉬울 수 있다는 방향성은 실무 우선순위 설정에 참고할 만합니다.

실무 적용

• 단계별 체크포인트 설계 — 10단계 이상 체인에서는 중간 단계마다 검증 지점을 둬, 오류가 끝까지 누적되기 전에 사람이 개입하게 합니다.
• 도구 선택기 도입 전 A/B 필수 — 결정 모델·선택 전용 파인튜닝을 바로 적용하지 말고 백본 단독 성능과 비교해, Strands 사례처럼 역효과(최대 -20.3%포인트)가 없는지 확인합니다.
• 방해 도구 비율로 난이도 가늠 — 임베딩 유사도가 높은 유사 기능 API가 많을수록 선택 실패율이 올라가므로, 사내 API 네이밍·설명을 구분하기 쉽게 재정비합니다.
• SOP 범주별 파일럿 우선순위화 — 전체 평균이 아니라 범주별 성공률을 추적해, 상대적으로 좁고 반복적인 SOP부터 자동화하고 개방형 SOP는 사람 검토를 유지합니다.
• 폐쇄형 프런티어 모델 별도 검증 — 이 논문은 오픈 3B~12B 모델만 다뤘으므로, 실제 배포할 GPT·Claude 계열 모델의 성능은 자체 벤치마크로 다시 확인해야 합니다.

결론

SLATE는 "도구가 많고 단계가 길어지면 에이전트 성공률이 급격히 떨어진다"는, 실무자들이 체감으로는 알던 현상을 100개 과제·1,000개 API 규모에서 수치로 못박았습니다. 단계별로는 65~75%까지 맞히는 모델도 평균 10.6단계를 연쇄로 통과해야 하는 순간 5.0%까지 떨어진다는 결과는, 벤더가 공개하는 단일 지표만으로 기업용 에이전트의 실전 성공률을 가늠하기 어렵다는 뜻입니다. 동료심사 전 워크숍 논문이고 오픈 소형 모델만 다뤘다는 한계를 감안해, 수치는 "프런티어 모델이라면 더 나을 가능성이 있는 방향 신호"로 읽고 자사 SOP·API 환경에서 재검증하는 것이 안전합니다. 도구 수가 많아질 때 노출 전략을 어떻게 재설계할지는 Cloudflare의 Code Mode 전환 체크리스트에서 운영 관점으로 이어서 다룹니다 — 그 글은 도구 수를 줄이는 쪽(2,594개 → 2개)에서, SLATE는 도구가 많을 때 고르는 능력 자체를 측정하는 쪽에서 같은 문제를 다룹니다.

참고 링크

• SLATE: A Large-Scale Benchmark for Long-Horizon API Selection in E-commerce Tool Use — arXiv 초록(원문)
• 같은 논문 HTML 전문 — 표·수치 대조에 사용
• τ-bench(Yao et al., 2024) — 관련 연구 원문
• AppWorld(Trivedi et al., 2024) — 관련 연구 원문
• TRAJECT-Bench(He et al., 2025) — 관련 연구 원문
• 도구 2,594개가 2개로 줄었다: Cloudflare Code Mode 전환 체크리스트 — sunny34.com 블로그