도구 사용 에이전트는 과제 수보다 도구와 데이터베이스 다양성을 늘려야 성능이 오른다

무엇인가

이 논문은 복잡한 다단계 작업을 수행하는 LLM 도구 사용 에이전트를 어떻게 학습시킬지 다룬다. 이런 에이전트는 여러 단계에 걸쳐 도구를 선택하고 조합하며 상태 변화를 추적하고 새로운 API 환경으로 일반화해야 한다. 그런데 다단계 도구 상호작용은 인터넷 텍스트에 드물고, 현실적인 과제와 다양한 도구, 풍부한 환경 데이터가 필요해 고품질 학습 데이터를 만들기 어렵다. 기존 연구는 LLM으로 도구 사용 데이터를 합성하거나 실행 가능한 환경을 만들었지만, 데이터 양을 늘리는 데 치중했고 어떤 데이터 속성이 다운스트림 성능을 이끄는지는 충분히 분리해 연구하지 않았다. 이 논문은 도구, 과제, 데이터베이스 상태의 다양성과 복잡성을 통제해 데이터 구성이 일반화에 미치는 영향을 정량화하려 한다.

어떻게 동작하나

제안 방법인 SynthAPI는 두 단계로 동작한다. 첫째, 빌더 LLM이 앱을 Python 코드로 처음부터 구현한다. 앱은 앱 이름과 설명, 분류, 기능 목록 같은 메타데이터, 데이터베이스 스키마를 정의하는 db.py, 데이터베이스 객체를 읽거나 수정하는 함수들로 구성된 apis.py를 갖는다. 논문은 Gemini-3.1 Pro를 인터넷 접근 없이 빌더 LLM으로 사용했고 쇼핑, 음악, 생산성, 금융, 피트니스, 메시징, 유틸리티, 소셜의 8개 분류를 수동으로 정의했다. 둘째, 앱의 기능 목록에서 일부를 샘플링해 과제 지시문을 만들고, 성공 여부를 판정하는 Python 검증기와 초기 데이터베이스 상태, 그리고 정답 해결 프로그램인 오라클 솔버를 생성한다. 초기 데이터베이스는 과제 수행에 필요한 최소 상태에 더해 D-1개의 방해 데이터 묶음을 추가해 구성하며, 검증기가 초기 상태에서는 실패하고 오라클 솔버 실행 후에는 성공하는 과제만 남긴다. 에이전트는 Gymnasium 형식 환경에서 Python 코드 블록으로 상호작용하고, list_apps, list_tools, get_tool_documentation, complete_task 같은 메타 도구로 필요한 도구를 탐색한다.

무엇과 다른가

SynthAPI의 핵심은 A개의 앱, 앱당 T개의 과제, 과제 지시문당 S개의 초기 데이터베이스 인스턴스, 초기 데이터베이스당 D개의 데이터 묶음이라는 네 가지 통제 변수다. 총 과제 수는 N=A×T×S로 결정되고, D는 과제 수를 바꾸지 않으면서 데이터 복잡성을 조절한다. 실험은 64개 앱, 10,472개 API로 458,752개 과제를 생성해 진행했다. API 중 6,266개는 쓰기, 4,206개는 읽기였고 앱당 API 중앙값은 144개, 범위는 51개에서 443개였다. 데이터 스키마의 데이터 클래스 정의는 앱당 중앙값 55개였고, 앱 기능은 31개에서 143개, 과제가 쓰는 기능은 중앙값 2개였다. GLM-5.2 전문가가 최대 4회 시도해 성공 궤적을 모았고, 이를 Qwen3.5 계열의 네 가지 크기 학생 모델에 SFT로 증류해 총 849개 모델을 학습했다. 학습 데이터는 5.9B 토큰, 그중 721M 토큰이 에이전트 추론과 행동 출력에 대한 감독이다.

어떻게 쓰나

데이터 구성을 바꾼 결과, 낮은 과제 예산에서는 앱 수가 적은 쪽이 유리했지만 예산이 커지면 앱 수가 많은 쪽이 유리했다. 9B 모델에서 A=8은 64~512개 과제 구간에서 가장 좋았고, A=64는 4,096개 과제부터 분명히 가장 좋았다. 앱당 과제를 1,024개까지 늘려도 사용된 도구 비율의 중앙값은 51%에 그쳐, 앱 다양성의 이득이 단순히 기능을 소진해서 생긴 것이 아님을 보였다. 초기 데이터베이스 인스턴스 S는 32~512개 학습 인스턴스에서는 1개, 512~4,096개에서는 2개, 4,096개를 넘으면 4개가 가장 좋았다. 방해 데이터가 많은 D=4는 높은 과제 예산에서 D=1이나 D=2보다 큰 향상을 냈다. 즉 예산이 커질수록 같은 도구 집합에 과제만 더 만드는 것보다 도구와 데이터베이스 상태의 다양성을 늘리는 것이 더 효과적이고, 데이터 복잡성을 높이는 것도 이득이 커진다.

전제와 한계

이 논문은 이 관계를 하나의 스케일링 법칙으로 정리한다. 적합한 식은 시그모이드 두 항을 곱한 형태로, 상한은 A×S×D에 로그로 의존하고 T는 상한에 도달하는 속도를 조절한다. 849개 모델을 모두 사용해 적합했고, 상위 25% 학습 FLOPs 구간을 홀드아웃해 최대 16배 큰 연산 예산까지 외삽했다. 정규화된 다운스트림 점수에서 홀드아웃 평균 절대 오차는 0.0285였고, 과제 수만 사용하는 기존 스케일링 모델은 0.1706이었다. 저자들은 이 차이가 단순한 데이터 양이 아니라 데이터 구성을 반영해야 함을 보여준다고 주장한다.

베이스라인 비교도 데이터 구성의 효과를 보여준다. 같은 32,768개 과제 예산에서 A=32, T=1,024, S=1, D=2로 둔 SynthAPI-SubOpt보다 A=64, T=128, S=4, D=4로 앱과 데이터베이스 다양성을 높인 SynthAPI-Opt가 일관되게 더 좋았고, 특히 SynthAPI-Holdout과 4B 모델에서 차이가 컸다. 전체 SynthAPI 데이터로 4에포크 학습한 SynthAPI-Big은 기존 대규모 도구 사용 데이터인 Nemotron-Agentic으로 학습한 모델보다 세 벤치마크 평균 30.5%포인트 높았다. Nemotron 모델은 8개 설정 중 5개에서 제로샷 시작 모델보다도 낮았다. AppWorld Test-Challenge에서 SynthAPI-Big은 4B 모델 66.4%, 9B 모델 77.0%로 SimSAT보다 각각 7.6%포인트, 11.6%포인트 높았다. BFCL에서는 4B에서 EnvFactory보다 2.0%포인트, 8B에서 EnvScaler보다 3.7%포인트 높았다. 다만 비교 대상들이 SFT와 RL을 섞는 등 학습 방식이 달라 합성 방법 자체나 데이터 효율성을 분리한 비교는 아니라고 저자들은 밝힌다.

개발자 관점에서 이 논문은 도구 사용 에이전트 데이터를 만들 때 과제 수만 늘리는 전략이 규모가 커질수록 비효율적일 수 있음을 시사한다. 실행 가능한 데이터베이스 기반 환경과 검증기를 두고, 예산이 커지는 단계에 맞춰 앱과 도구, 데이터베이스 상태, 방해 데이터의 비중을 조정하는 방식이 실무 파이프라인 설계에 참고가 된다. 한계도 분명하다. SynthAPI는 사용자와 상호작용하는 사용자 인더 루프를 시뮬레이션하지 않고, 긴 이메일 체인이나 노트 문서처럼 길고 복잡한 문서 검색 과제에는 덜 초점을 둔다. 모든 내용을 LLM이 처음부터 합성하므로 의미적 깊이가 부족하고, 스케일링 법칙도 하나의 데이터 파이프라인에서만 검증되어 다른 파이프라인이나 학습 설정으로 전이된다고 보장하지 않는다. 모든 실험은 연구용 시뮬레이션 환경에서 수행됐다.