Mehr Daten und größere Modelle gelten als der sicherste Weg zu leistungsfähigen KI-Agenten. Der Engpass liegt aber in der Reihenfolge, in der die Daten entstehen. Die Arbeit „ToolGrad: Efficient Tool-use Dataset Generation with Textual Gradients“ (ACL 2026) dreht diese Reihenfolge um: Zuerst wird eine funktionierende Kette von API-Aufrufen konstruiert, erst danach die passende Nutzerfrage dazu formuliert.
Das klingt nach einem Detail, ist aber der Kern des Problems. Bisherige Verfahren gehen umgekehrt vor: Sie erfinden eine Anfrage und suchen dann nach einem Werkzeugpfad, der sie erfüllt. Dieser Ansatz ist ineffizient, weil er die Spuren aus einer aufwendigen Agenten-Exploration destillieren muss. ToolGrad erzeugt laut den Autoren komplexere Daten bei geringeren Kosten, und die damit trainierten Modelle schneiden besser ab als die mit den bisherigen Datensätzen.
Warum die übliche Reihenfolge teuer ist
Ein Beispiel: Wer eine Wanderroute dokumentieren will, kann einen Wanderer losschicken und hoffen, dass er unterwegs einen guten Weg findet. So arbeiten ToolBench und ToolACE: Zuerst entsteht eine hypothetische Nutzeranweisung aus einem Stichprobenpool von APIs, danach sucht ein Agent per Tiefensuche nach einer passenden Werkzeugkette. Diese Suche läuft per trial and error. Sie findet Lösungen, kostet aber viele Modellaufrufe, und ein Teil der Versuche bleibt ergebnislos.
Der zweite Weg ist der des Kartografen: erst die Route zeichnen, dann die Frage dazu schreiben. Aus der Werkzeugkette wird die Anfrage abgeleitet, nicht umgekehrt. Die Autoren nennen das answer-first, also lösungszuerst. Der Vorteil ist die Eindeutigkeit: Eine konkrete Abfolge von API-Aufrufen enthält mehr Information als eine vage formulierte Anfrage. Die Zuordnung von Werkzeugnutzung zu Nutzerfrage wird damit zu einem einzigen Modellschritt statt zu einer offenen Suche.
Was mit textuellen Gradienten gemeint ist
Der Begriff stammt aus dem Maschinellen Lernen. Dort berechnen Modelle über Stapel von Trainingsbeispielen einen numerischen Verlust und leiten daraus einen Gradienten ab, der die Gewichte in eine bessere Richtung schiebt. TextGrad hat das Prinzip auf Prompt-Optimierung übertragen: Statt Zahlen liefert ein Modell als Kritiker eine Beschreibung in natürlicher Sprache, was schiefgelaufen ist. Diese Rückmeldung heißt textueller Gradient.
ToolGrad übernimmt den Gedanken, wendet ihn aber auf die Konstruktion von Daten an, nicht auf einen festen Prompt. Optimiert wird keine Zeichenkette, sondern ein Ablauf aus Aufrufen. Aus einer großen Bibliothek von Schnittstellen entsteht Schritt für Schritt ein gültiger API-Workflow. Der textuelle Gradient wirkt dabei als Richtungshinweis: Er sagt nicht „so nicht“, sondern benennt, welche der getesteten Optionen den Ablauf am sinnvollsten erweitert. So wird aus Prompt-Optimierung ein Verfahren, mit dem sich API-Workflows automatisch mit LLMs erstellen lassen.
Die vier Module von ToolGrad
Das Framework besteht aus vier Bausteinen, die in einer Schleife zusammenarbeiten. Der API Proposer wählt in jeder Runde aus einer Stichprobe von Schnittstellen einige Kandidaten aus, die den aktuellen Ablauf erweitern könnten. Die API Executors rufen diese Kandidaten parallel auf und erzeugen Ausführungsberichte. Sie liefern das Material, auf dem die Bewertung beruht, statt einer Vermutung darüber, was funktionieren sollte.
Der API Selector liest die Berichte und entscheidet sich für den Aufruf, der am besten abschneidet. Dieser ausgewählte Aufruf ist der textuelle Gradient im engeren Sinn: Er gibt die Richtung vor und wird an die bestehende Kette angehängt. Der LLM Updater passt die synthetische Nutzerfrage und die Antwort des Agenten an den gewachsenen Werkzeugsatz an. Nach vielen Wiederholungen steht ein fertiges Beispiel: eine Anfrage, ein verifizierter Ablauf und eine Antwort, die darauf beruht.
Das Vorgehen bewertet nicht am Ende einer langen Suche, sondern nach jedem einzelnen Schritt. Fehler werden dadurch früh sichtbar, und die Passrate nähert sich laut den Autoren hundert Prozent. Wer schon einmal einen fehlgeschlagenen Agentenlauf debuggt hat, weiß, was das wert ist: Die Ursache liegt fast nie am Ende der Kette.
Was die Experimente zeigen
Als Werkzeugbibliothek diente ToolBench mit über 16.000 realen Schnittstellen. Verglichen wurde die klassische, fragenerste Generation per Tiefensuche mit dem lösungszuersten ToolGrad. Ergebnis: komplexere Daten, höhere Erfolgsquote, niedrigere Kosten. Aus der Bibliothek entstand der Datensatz ToolGrad-500, mit dem die Autoren Gemma-3-Modelle in den Größen 1B, 4B und 12B nachtrainierten. Getestet wurden diese Varianten auf dem Berkeley Function Calling Leaderboard, also mit einem anderen Werkzeugsatz als dem aus dem Training.
Diese Trennung ist entscheidend. Sie misst nicht, ob ein Modell seine Trainingswerkzeuge auswendig gelernt hat, sondern ob es mit unbekannten Schnittstellen umgehen kann. In dieser Out-of-Distribution-Situation verbesserten sich alle drei Modellgrößen gegenüber ihren nicht nachtrainierten Ausgangsversionen. Das 12B-Modell erreichte 83,1 Punkte und lag laut den Autoren damit auf Augenhöhe mit den damals leistungsfähigsten proprietären Modellen, die sie mit 83,2, 82,8 und 74,4 Punkten auflisten.
Ein zweiter Befund ist für die Praxis wichtiger. Der Datensatz ToolGrad-500 wurde mit einem verhältnismäßig kleinen Modell erzeugt. Das darauf feinabgestimmte Gemma-3-12B übertraf seinen eigenen Lehrer. Dieses Muster ist als Self-evolving bekannt und heißt für LLM Fine-Tuning mit Tool-Nutzungsdaten: Die Qualität des Datensatzes hängt weniger von der Leistungsfähigkeit des Generators ab als von der Struktur des Generierungsprozesses. Auch andere offene Spezialmodelle für Werkzeugnutzung ließ die Variante hinter sich, darunter ToolACE, das auf einer fortgeschritteneren Schnittstellendatenbank trainiert worden war.
Grenzen und offene Fragen
Die Skepsis: Alle Zahlen stammen aus der Veröffentlichung selbst; unabhängige Nachbauten stehen noch aus. Der Ansatz braucht Umgebungen, in denen API-Aufrufe tatsächlich ausgeführt und bewertet werden können. Bei Schnittstellen mit Kosten oder irreversiblen Aktionen – eine Zahlung, ein gelöschter Datensatz – ist paralleles Ausprobieren heikel. Und eine hohe Passrate bei der Datengenerierung sagt nichts über die Robustheit im echten Betrieb, wo Anfragen unvollständig, widersprüchlich oder schlicht falsch formuliert sind.
Die Autoren benennen diese Grenzen selbst und skizzieren, wohin es gehen soll: zu größeren, dynamischeren Schnittstellenlandschaften und einer laufenden Weiterbildung, die sich an individuelle Nutzung anpasst. Ein Modell, das sich im Betrieb ständig verändert, braucht allerdings Kontrolle darüber, was es dazulernt und was nicht.
Effiziente Datensatzgenerierung für Tool-Nutzung ist kein Problem der Rechenleistung, sondern der Konstruktionslogik. Wer synthetische Datensätze baut, sollte zuerst das Ergebnis festlegen und die Aufgabe daraus ableiten – derselbe Rat, den man einem Team gibt, das zu viele unklare Tickets bearbeitet. ToolGrad liefert dafür ein ausgearbeitetes Verfahren samt Auswertung. Ob sich der Ansatz außerhalb kontrollierter Benchmarks durchsetzt, hängt davon ab, ob sich Werkzeugketten auch dort zuverlässig vorab planen lassen, wo jeder einzelne Aufruf echte Konsequenzen hat.
Quelle: research.google
