Apple-Studie: Bei Anfragen mit mehreren Tools schlägt erst planen, dann suchen das umgekehrte Vorgehen
Apple-Forscher berichten, dass der beste Weg für einen LLM-Agenten, Tools zu finden, von der Komplexität der Anfrage abhängt. In einer Studie auf Basis von ToolBench funktionierte bei Anfragen mit einem Tool die vorgeschaltete Suche besser, bei Anfragen mit mehreren Tools dagegen die vorgeschaltete Planung durch das Modell.
- Apple-Forscher verglichen Retrieve-then-Plan (RtP) mit Plan-then-Retrieve (PtR) für die Tool-Suche von LLMs.
- Auf ToolBench (46.984 API-Endpunkte) gewann RtP bei Anfragen mit einem Tool, PtR bei Anfragen mit mehreren Tools.
- Der Wendepunkt zeigte sich für k=1 bis 20, bei Verzeichnisgrößen von 1.000 bis 47.000 APIs sowie bei Gemini 2.5 Flash und gpt-oss-120b.
- Der zusätzliche Discovery-Aufruf von PtR verdoppelt laut den Autoren die Inferenzkosten ungefähr.
- Die Autoren schlagen komplexitätsadaptives Routing auf Basis des Top-1-Retrieval-Scores von RtP vor.
Zwei Wege zum passenden Tool
LLM-Agenten, die externe Tools aufrufen, müssen meist aus umfangreichen API-Verzeichnissen auswählen. Laut der Veröffentlichung ist es wegen der begrenzten Kontextfenster unmöglich, sämtliche Tool-Definitionen in einen einzigen Prompt zu packen. Agenten müssen daher relevante Tools finden, bevor sie planen, wie sie eine Aufgabe ausführen.
Der vorherrschende Ansatz ist nach Angaben der Autoren Retrieve-then-Plan (RtP). Dabei wird die Nutzeranfrage eingebettet und ähnliche Tools werden per Approximate-Nearest-Neighbor-Suche abgerufen. Das Team untersucht eine Alternative, Plan-then-Retrieve (PtR): Hier erzeugt das LLM zunächst Abstract Tool Stubs. Das sind hypothetische Funktionssignaturen, die die benötigten Fähigkeiten beschreiben und anschließend als Suchanfragen an das Verzeichnis dienen.
Ein Wendepunkt, der von der Komplexität abhängt
Die Forscher bewerteten beide Paradigmen auf ToolBench, das 46.984 einzelne API-Endpunkte in 50 Kategorien umfasst. Die Anfragen teilten sie in drei Teilmengen auf: ein Tool (G1), mehrere Tools innerhalb einer Kategorie (G2) und mehrere Tools über Kategorien hinweg (G3).
Das Ergebnis war ein klarer, von der Komplexität abhängiger Wendepunkt. RtP schnitt bei Anfragen mit einem Tool besser ab als PtR, während PtR bei Anfragen mit mehreren Tools vorne lag. Den Autoren zufolge gilt das für jedes Abrufbudget von k=1 bis 20, ist robust über Verzeichnisgrößen von 1.000 bis 47.000 APIs und zeigt sich konsistent bei zwei Modellfamilien, Gemini 2.5 Flash und gpt-oss-120b.
Stub-Halluzinationen wirken in beide Richtungen
Die Studie beschreibt einen Fehlermodus, den sie Stub-Halluzination nennt: Das LLM erfindet plausibel klingende, aber nicht existierende API-Namen. Die Autoren bezeichnen das als zweischneidiges Schwert.
- Bei einfachen Anfragen abstrahieren die Stubs von PtR Eigennamen-Signale weg, die RtP direkt abgleichen kann.
- Bei komplexen Anfragen zerlegt derselbe Mechanismus eine vielschichtige Absicht in funktionale Teilbedarfe, was die Suche verbessert.
Kosten und Ausblick
PtR erfordert einen zusätzlichen Discovery-Aufruf. Die Autoren analysieren den Token-Mehraufwand und zeigen, dass sich die Inferenzkosten dadurch ungefähr verdoppeln. Dieser Mehraufwand lohnt sich bei Anfragen mit mehreren Tools, schadet aber bei Anfragen mit nur einem Tool.
Deshalb nennt die Studie komplexitätsadaptives Routing als praktische Richtung. Laut den Autoren lässt sich ein solches Routing mit einem Signal steuern, das in der Pipeline ohnehin vorhanden ist und nichts kostet: dem Top-1-Retrieval-Score von RtP. In der Praxis legt das nahe, dass Entwickler von Agenten mit Tool-Nutzung sich womöglich nicht für eine einzige Architektur für alle Anfragen entscheiden müssen, sondern einfache Anfragen über den günstigeren Retrieval-Pfad und komplexe zuerst über die Planung leiten könnten.
Die Studie stammt von Mingfei Zhang, Amit Surana, Ziauddin Majid, Chenxi Wang und Michael Xu und ist auf der Website von Apples Machine-Learning-Forschung unter der Konferenz EMNLP aufgeführt.
