ToolGrad: Tool-Use-Datensätze nach dem Answer-First-Prinzip mit textuellen Gradienten erzeugen

Warum ist es schwierig, Tool-Use-Datensätze zu erzeugen?

Damit ein Sprachmodell lernt, Tools aufzurufen, braucht es viele Beispiele, die eine Nutzeranfrage mit genau der Folge von API-Aufrufen verbinden, die sie beantwortet. Menschliche Annotation skaliert nicht, daher erzeugen die meisten Pipelines solche Paare synthetisch, und der übliche Weg dorthin verschwendet einen Großteil seines Aufwands.

Das gängige Rezept, das unter anderem ToolBench und ToolACE nutzen, arbeitet nach dem Query-First-Prinzip. Ein LLM wählt einige APIs aus und erfindet eine Anfrage, der sie dienen könnten; danach erkundet ein Such-Agent Tool-Aufrufe nach dem Prinzip Versuch und Irrtum, oft per Tiefensuche, bis er eine Antwort findet oder aufgibt.

Die Autoren nennen zwei Kosten. Die Erkundung ist von Natur aus teuer, weil der nützliche Lösungsweg aus einer großen Suche herausdestilliert werden muss, und nichts garantiert einen Erfolg, sodass gescheiterte Suchen Agentenaufrufe verbrauchen, ohne ein Beispiel zu liefern. Außerdem stellten sie fest, dass erfundene Anfragen mit den verfügbaren Tools teils unlösbar sind und erfolgreiche Suchpfade mitunter falsche Schritte enthalten, die dann zu Trainingszielen werden.

Was ändert die Answer-First-Generierung?

Sie kehrt die Reihenfolge um. ToolGrad baut zuerst eine Kette von API-Aufrufen, die tatsächlich erfolgreich gelaufen ist, und lässt dann ein LLM eine passende Nutzeranfrage und eine abschließende Antwort schreiben. Eine bekannte Lösung zu beschreiben ist weit einfacher, als eine zu finden, und erfordert nur einen einzigen LLM-Schritt.

Die Autoren vergleichen diese Umkehrung mit dem Zusammenfassen: Ein detaillierter Workflow wird in die kürzere, vagere Nachricht übersetzt, die ein Mensch eintippen würde. Da jedes Beispiel mit mindestens einem funktionierenden Tool-Aufruf beginnt und gescheiterte Schritte nie in die Daten gelangen, ist jedes Beispiel schon durch seine Entstehung verifiziert.

Daraus ergibt sich die Frage, wie sich nützliche mehrstufige Ketten direkt aus einer großen API-Bibliothek zusammensetzen lassen, ohne dass eine Anfrage die Richtung vorgibt. Genau das leistet die iterative Schleife von ToolGrad.

Textuelle Gradienten aus der Prompt-Optimierung

ToolGrad übernimmt die Idee textueller Gradienten von TextGrad, einem Framework zur Prompt-Optimierung. Bei TextGrad formuliert ein LLM als Kritiker Feedback in natürlicher Sprache zu einer Vorhersage, und ein weiteres LLM überarbeitet daraufhin den Prompt, frei angelehnt an den Gradientenabstieg.

Die Autoren betonen, dass es sich nicht um mathematische Gradienten handelt. Bei ToolGrad ist das Feedback eine Auswahl statt einer Kritik: In jeder Iteration bestimmt ein Selektor die eine API, deren Hinzufügen sich lohnt, und diese diskrete Wahl übernimmt die Rolle des Gradienten, der das Datenbeispiel voranbringt.

Die Analogie hat eine Grenze, die die Autoren einräumen. Einen Datensatz und das darauf trainierte Modell gleichzeitig zu optimieren wäre ein zweistufiges Optimierungsproblem, deshalb stützt sich ToolGrad beim Aufbau der Daten auf LLM-Feedback, ohne innerhalb der Schleife ein Modell zu trainieren.

Wie baut ToolGrad eine Tool-Use-Kette auf?

Jede Iteration durchläuft nacheinander vier Module: vorschlagen, ausführen, auswählen und aktualisieren. Ausgehend vom aktuellen Beispiel, einem Tripel aus Nutzeranfrage, API-Workflow und Antwort, fügt die Schleife pro Schritt höchstens eine API hinzu und wiederholt das über 10 Iterationen.

Ein vollständiger Durchlauf ergibt ein Trainingsbeispiel: eine natürlich klingende Anfrage, eine verifizierte Menge von API-Ketten samt Ein- und Ausgaben sowie eine abschließende Antwort, die sich auf diese Ausgaben stützt.

• API-Vorschlagsmodul. Liest einen zufälligen Mini-Batch von 50 API-Beschreibungen und nominiert bis zu 3, die den Workflow erweitern könnten, jeweils mit einer Anweisung zur Nutzung. Es kann selbst keine Tools aufrufen, was diesen Filterschritt günstig hält.
• API-Ausführungsagenten. Pro Vorschlag führt ein Agent mit Tool-Zugriff die API parallel aus und liefert einen Bericht mit dem vollständigen Anfrageverlauf und einem Erfolgsflag. Das ist der teuerste Schritt, weshalb das Vorschlagsmodul zuvor filtert. Aufrufe brechen nach 10 Sekunden ab.
• API-Selektor. Prüft die erfolgreichen Berichte, wählt die eine wertvollste API und entscheidet, ob sie eine bestehende Kette verlängert oder eine neue beginnt. Gescheiterte Ausführungen bleiben unberücksichtigt.
• Workflow-Aktualisierung. Hängt die gewählte API ohne LLM an die ausgewählte Kette an und lässt dann ein LLM Nutzeranfrage und Antwort neu schreiben, damit das Beispiel zum erweiterten Workflow passt.

Von ToolGrad-500 zu feinabgestimmten Gemma-3-Modellen

Die Autoren ließen die Schleife 500-mal mit unterschiedlichen Seeds laufen und setzten für jede LLM-Rolle gemini-2.5-flash-lite ein, weil es günstig ist und schnell antwortet. Das Ergebnis ist ToolGrad-500, ein Satz von 500 Beispielen auf Basis der API-Bibliothek von ToolBench, die nach zwei Filterrunden 15.368 nutzbare APIs umfasste.

Um eine realistische Lage nachzubilden, in der ein Modell mehr Tools sieht als nötig, wird jedes Beispiel mit ähnlichen, aber unnötigen APIs ergänzt, die per Embedding-Ähnlichkeit gefunden werden, sodass 10 Kandidaten-Tools entstehen. Zusätzlich fügten die Autoren 20 % mehr Negativbeispiele hinzu, in denen keines der angebotenen Tools passt und die richtige Ausgabe eine leere Liste ist.

Die Daten sind für Tool-Nutzung in einem einzigen Zug formatiert: Auf Basis von Tool-Definitionen im OpenAI-Stil muss das Modell alle nötigen Aufrufe auf einmal als Funktionsaufrufe im Python-Stil ausgeben, statt wie ReAct-Agenten einen Aufruf pro Runde. Anschließend wurden Gemma-3-Modelle mit 1B, 4B und 12B Parametern überwacht feinabgestimmt, die beiden größeren über LoRA-Adapter.

Das Training war schlank. Die Autoren berichten 1, 1,67 und 2,67 GPU-Stunden auf vier A100-GPUs für die drei ToolGrad-Modelle, verglichen mit 29, 68 und 370 GPU-Stunden auf acht H100-GPUs für die entsprechenden Modelle, die auf ToolBench-Daten trainiert wurden.

Wie effizient ist die Datengenerierung von ToolGrad?

Im Vergleich der Autoren mit der Tiefensuche-Pipeline von ToolBench lieferte ToolGrad in 99,8 % der Fälle ein brauchbares Beispiel, gegenüber 63,8 %, und erzeugte dabei längere Ketten mit weniger Tool-Aufrufen.

Die Ketten umfassten im Schnitt 3,4 Ground-Truth-Tool-Aufrufe gegenüber 2,1 bei der Tiefensuche. Die Zahl der LLM-Aufrufe blieb mit 63,9 gegenüber 64,5 etwa gleich, während die Tool-Aufrufe von 34,3 auf 20,0 sanken. Die seltenen Fehlschläge, 0,2 % der Läufe, traten auf, wenn keine der 3 ausgewählten APIs in allen 10 Iterationen eine erfolgreiche Antwort lieferte und ein leeres Beispiel zurückblieb.

Zudem testeten die Autoren Läufe mit 4, 8, 12 und 16 Iterationen. Die Erfolgsquote flachte zwischen 8 und 12 ab, was die Wahl von 10 stützt, doch der Anteil einzigartiger Tool-Aufrufe offenbarte eine Schwäche: Der Generator erzeugt über Beispiele hinweg tendenziell ähnliche Tool-Aufrufe.

Wie schneiden ToolGrad-Modelle auf BFCL und ToolBench ab?

Laut den Autoren verbesserte das Feintuning auf ToolGrad-500 jede Gemma-3-Größe auf beiden Benchmarks. Auf dem Berkeley Function Calling Leaderboard (BFCL), dessen Tools sich kaum mit denen von ToolBench überschneiden, legten die Modelle mit 1B, 4B und 12B gegenüber ihren Basismodellen um 8,1, 8,0 und 6,3 Punkte zu.

ToolGrad-12B erreichte laut den Autoren 83,1 auf den Single-Turn-Tracks von BFCL, 0,1 Punkte unter gemini-2.5-pro mit 83,2 und vor Claude 4.5 Opus mit 82,8 sowie GPT-5 mit 74,4. Es übertraf außerdem die spezialisierten Tool-Use-Modelle ToolACE und Hammer-2.1-7B sowie gemini-2.5-flash-lite, das Modell, das seine Trainingsdaten erzeugt hatte.

Am größten fielen die Zuwächse in den synthetischen Non-Live-Kategorien von BFCL aus, mit 14,19, 11,34 und 8,37 Punkten, doch auch die Live-Kategorien mit echten Nutzerdaten verbesserten sich, um 1,93, 4,74 und 4,22. Als deutlichsten Gewinner nennen die Autoren die Kategorie Multiple Parallel, die die Auswahl zwischen Tools mit mehreren gleichzeitigen Aufrufen verbindet.

Auf dem schwierigsten kategorieübergreifenden Track von ToolBench, bewertet von LLM-Gutachtern, belegten ToolGrad-12B und ToolGrad-4B mit 19,6 und 17,6 die ersten beiden Plätze, vor allen getesteten proprietären Modellen. Eine Prüfung mit zwei menschlichen Bewertern an 8 Anfragen ergab, dass die gemittelten Gutachterwerte eng mit den menschlichen Bewertungen übereinstimmten.

Die Autoren betonen einen Selbstverbesserungseffekt: Selbst das 1B-Modell übertraf auf ToolBench sein Lehrermodell, mit 14,1 gegenüber 6,9. Aus ihrer Sicht kann ein Schülermodell dank Answer-First-Daten seinen Lehrer übertreffen, weil das Training nicht auf Probleme beschränkt ist, die der Lehrer per Suche lösen konnte.

Grenzen, Skalierungsplateau und offene Fragen

Die Autoren nennen vier Grenzen. Die Feintuning-Daten enthalten keine Reasoning-Schritte, daher eignen sich die Modelle nicht für Inferenz mit ReAct oder Tiefensuche; getestet wurde nur überwachtes Feintuning, kein Reinforcement Learning; generierte Anfragen klingen womöglich nicht wie echte Menschen; und die Leistung hörte bei kleiner Datensatzgröße auf zu steigen.

Besonders auffällig ist das Skalierungsergebnis. Als die Autoren den Trainingsdatensatz für Gemma-3-4B von 100 bis 2k Beispielen variierten, mit Zwischenstufen bei 500, 1k und 1,5k, schlug jede Version das Basismodell, doch die BFCL-Genauigkeit stieg mit wachsendem Datensatz erst an und fiel dann. Als einen Hauptgrund nennen sie fehlendes Gedächtnis zwischen den Läufen: Jedes Beispiel entsteht unabhängig, daher schlägt das Framework immer wieder ähnliche Tool-Aufrufe vor.

Auch der Umfang ist begrenzt. Die Bewertung umfasst die Single-Turn-Tracks v1 und v2 von BFCL; Multi-Turn- und Agenten-Tracks bleiben künftiger Arbeit überlassen, ebenso die Nachbearbeitung generierter Anfragen für natürlichere, vielfältigere Formulierungen.

Unsere Analyse: Der Großteil des BFCL-Zuwachses entfällt auf die synthetischen Non-Live-Kategorien, die den generierten Trainingsdaten ähneln, während die Zuwächse in den Live-Kategorien mit echten Nutzeranfragen kleiner ausfallen. Teams, die das Rezept übernehmen, sollten die Ergebnisse am eigenen Anfrageaufkommen messen, auch daran, wie oft ein feinabgestimmtes Modell ein Tool aufruft, obwohl es ablehnen sollte.

Was das für Teams bedeutet, die KI-Agenten entwickeln

Für Organisationen mit eigenen internen APIs liegt der Reiz in den Kosten: Einige hundert verifizierte Beispiele, erzeugt von einem günstigen Modell und in wenigen GPU-Stunden trainiert, brachten kleine offene Modelle auf einem öffentlichen Benchmark nahe an große proprietäre Modelle heran. Answer-First-Generierung bedeutet zudem, dass jedes Trainingsbeispiel auf tatsächlich ausgeführten Aufrufen beruht.

Unsere Analyse: Die Methode braucht während der Generierung echte, aufrufbare Tools, weil jede vorgeschlagene API ausgeführt wird. Das passt zu abgeschotteten oder rein lesenden internen Diensten; Tools mit Nebenwirkungen, etwa solche, die Nachrichten senden oder Datensätze ändern, bräuchten dagegen eine sichere Testumgebung, bevor ein Generator sie erkunden kann.

Zusammen mit dem Skalierungsplateau und dem Abstand zwischen synthetischen und Live-Zuwächsen spricht das dafür, ToolGrad als Ausgangspunkt für einen Tool-Use-Datensatz zu sehen statt als vollständige Pipeline, ergänzt um echte Nutzeranfragen und gezielte Tests, ob irrelevante Tools abgelehnt werden.

Sind Code, Datensatz und Modelle von ToolGrad verfügbar?

Ja. Die Autoren haben den Quellcode auf GitHub unter der Lizenz Apache 2.0 veröffentlicht, dazu ein Python-Paket. Der Datensatz ToolGrad-500 und die feinabgestimmten Modelle ToolGrad-1B, ToolGrad-4B und ToolGrad-12B liegen auf Hugging Face, wo die Modellseiten die Gemma-Lizenz angeben.

Die Datensatzkarte nennt 600 Trainingssitzungen, davon 500 positive und 100 negative, sowie 110 Testsitzungen. Das Repository enthält eine Demo auf einem Dateisystemdienst über das Model Context Protocol (MCP), die keine GPU braucht, Skripte zur Reproduktion der BFCL-Ergebnisse und eine Anleitung zur Erzeugung neuer Daten, für die ein ToolBench-API-Schlüssel nötig ist.

Das Paper von Zhongyi Zhou, Ruofei Du und sechs Mitautoren von Google, der Universität Tokio, RIKEN AIP und der Universität Tohoku erscheint in den Findings der ACL 2026.

Fragen und Antworten

Quellen

1. Zhou, Z., Uehara, K., Zhang, H., Zhou, J., Gu, L., Du, R., Xu, Z., & Harada, T. (2026). ToolGrad: Efficient tool-use dataset generation with textual "gradients". Findings of the Association for Computational Linguistics: ACL 2026. arXiv:2508.04086. https://aclanthology.org/2026.findings-acl.950/ (externe Website)
2. Zhou, Z. (2026). ToolGrad [Computer software]. GitHub. https://github.com/zhongyi-zhou/toolgrad (externe Website)
3. Zhou, Z. (2026). ToolGrad-500 [Data set]. Hugging Face. https://huggingface.co/datasets/zhongyi-zhou/toolgrad-500 (externe Website)
4. Yuksekgonul, M., Bianchi, F., Boen, J., Liu, S., Huang, Z., Guestrin, C., & Zou, J. (2024). TextGrad: Automatic "differentiation" via text. arXiv:2406.07496. https://arxiv.org/abs/2406.07496 (externe Website)
5. Qin, Y., Liang, S., Ye, Y., Zhu, K., Yan, L., Lu, Y., Lin, Y., Cong, X., Tang, X., Qian, B., Zhao, S., Hong, L., Tian, R., Xie, R., Zhou, J., Gerstein, M., Li, D., Liu, Z., & Sun, M. (2023). ToolLLM: Facilitating large language models to master 16000+ real-world APIs. arXiv:2307.16789. https://arxiv.org/abs/2307.16789 (externe Website)
6. Gorilla project, University of California, Berkeley. (n.d.). Berkeley Function Calling Leaderboard (BFCL). https://gorilla.cs.berkeley.edu/leaderboard.html (externe Website)