Apple 연구, 다중 도구 LLM 에이전트에서 Plan-then-Retrieve가 Retrieve-then-Plan보다 우수

도구 기반 LLM 에이전트는 대규모 레지스트리에서 관련 API를 찾아야 하지만, 제한된 컨텍스트 윈도우 때문에 모든 정의를 한 번에 프롬프트에 넣을 수 없다. Apple 연구진은 사용자 쿼리를 임베딩해 근사 최근접 이웃 검색을 수행하는 주류 방식인 **Retrieve-then-Plan(RtP)**과, LLM이 먼저 필요한 기능을 설명하는 Abstract Tool Stubs(가상 함수 시그니처)를 생성해 이를 검색 쿼리로 사용하는 Plan-then-Retrieve(PtR) 패러다임을 비교했다.

복잡도에 따른 성능 교차점

ToolBench(50개 카테고리, 46,984개 고유 API 엔드포인트) 평가 결과, 쿼리 복잡도에 따라 명확한 성능 교차점이 나타났다. RtP는 단일 도구 쿼리(G1)에서 PtR보다 우수한 성능을 보인 반면, PtR는 동일 카테고리(G2) 및 교차 카테고리(G3)의 다중 도구 쿼리에서 RtP를 앞섰다. 이 추세는 검색 예산(k=1~20), 레지스트리 크기(1k~47k API), Gemini 2.5 Flash 및 gpt-oss-120b 등 모델 계열 전반에서 일관되게 유지됐다.

스텁 환각 및 비용 영향

연구진은 LLM이 존재하지 않지만 그럴듯한 API 이름을 만들어내는 stub-hallucination 실패 모드를 규명했다. 단순 쿼리에서는 이 메커니즘 때문에 PtR가 RtP가 직접 매칭했을 고유 명사를 놓친다. 그러나 복잡한 다중 도구 작업에서는 스텁의 기능 설명이 올바른 도구 검색에 도움이 된다. PtR은 추가 LLM 호출로 인해 RtP 대비 지연 시간과 토큰 사용량이 두 배로 증가하는 비용 부담이 있다. 저자들은 RtP의 초기 검색 점수를 무비용 신호로 활용해 어려운 쿼리에서만 PtR로 전환하는 복잡도 인식 라우팅을 실용적인 해결책으로 제안했다.