Der Werkzeugkasten ist das Problem, nicht das Modell
Wir haben immer mehr Werkzeuge ergänzt, weil jedes einzeln begründet war. Irgendwo jenseits von dreißig begann der Agent, plausibel falsche zu wählen, und keine Prompt-Arbeit half. ToolLLM beschreibt die Größenordnung, die wir anstrebten — unsere Antwort war, es nicht mehr zu versuchen.
Wie wir auf vierzig kamen
Niemand entscheidet, einem Agenten vierzig Werkzeuge zu geben. Es sammelt sich an. Jede Anforderung ist für sich vernünftig: Der Agent soll auch einen Vertrag nachschlagen können, auch den Lieferstatus prüfen, auch ein Ticket öffnen. Jede Ergänzung war durch einen echten Nutzerbedarf begründet.
Der Fehler kam nicht als Fehlermeldung. Er kam als langsamer Anstieg von Antworten, die selbstsicher aus der falschen Quelle abgeleitet waren — die Vertragsabfrage dort verwendet, wo die Auftragsabfrage gemeint war, und mit einem echten Wert zur falschen Frage zurück.
Warum Prompting es nicht behoben hat
Wir haben getan, was alle zuerst tun: bessere Werkzeugbeschreibungen, ausdrückliche Abgrenzungsregeln, Beispiele im System-Prompt. Jede Runde behob eine bestimmte Verwechslung und ließ die allgemeine bestehen, denn das Problem ist nicht, dass eine einzelne Beschreibung unklar wäre.
Das Problem ist, dass die Auswahlqualität sinkt, wenn die Optionsmenge wächst und Optionen sich überschneiden. Zwei Werkzeuge, die beide plausibel auf eine Frage antworten, werden gelegentlich verwechselt — und die Zahl solcher Paare wächst schneller als die Zahl der Werkzeuge.
Was die Forschungsrichtung sagt
Qin und Kollegen sind den umgekehrten Weg gegangen, und das ist lehrreich. ToolLLM baut ein Instruction-Tuning-Framework mit dem Ziel, große Mengen realer REST-APIs zu beherrschen, mit Daten über eine sehr breite API-Fläche.
Das ist ein legitimes und interessantes Ziel. Es ist zugleich eine Aussage darüber, wo die Schwierigkeit liegt: Wenn es eigene Datenerhebung und Feinabstimmung braucht, um ein Modell auf tausende APIs zu bringen, dann ist es kein Plan, einem ungetunten Modell vierzig sich überschneidende hinzulegen und zu hoffen.
Was wir geändert haben
Wir schneiden den Werkzeugkasten nicht mehr nach System, sondern nach Aufgabe. Der Agent für Lieferfragen bekommt die neun Werkzeuge, die eine Lieferfrage brauchen kann. Der Agent für Verträge bekommt seinen eigenen Satz. Keiner sieht den des anderen.
Wo eine Anfrage beides berührt, entscheidet ein Router vorab, um welche Aufgabe es geht, bevor irgendein Werkzeug sichtbar ist. Der Router ist ein kleiner Klassifikator mit fester Ausgabemenge, kein Agent — er hat eine Aufgabe und lässt sich vollständig testen.
| Schnitt nach System | Schnitt nach Aufgabe |
|---|---|
| Alle Werkzeuge der Plattform | Nur was diese Aufgabe braucht |
| Wächst mit der Plattform | Wächst mit der Aufgabe, also begrenzt |
| Überschneidung per Prompt gelöst | Überschneidung baulich entfernt |
| Falsches Werkzeug liefert echten Wert | Falsches Werkzeug ist nicht erreichbar |
Was es kostet
Ein Routing-Schritt kostet einen Aufruf und bringt einen eigenen Fehlermodus mit: Routet er falsch, ist das richtige Werkzeug unerreichbar. Wir nehmen den Tausch in Kauf, weil ein Routing-Fehler sichtbar und testbar ist, während ein Auswahlfehler in einem großen Werkzeugkasten wie eine plausible Antwort aussieht.
Der Pflegeaufwand ist ebenfalls real. Aufgabenschnitte müssen bei Produktänderungen überprüft werden, und ein Werkzeug, das für eine zweite Aufgabe relevant wird, muss bewusst ergänzt werden, statt ohnehin da zu sein.
Was wir nicht behaupten
Wir behaupten nicht, dass neun eine magische Zahl ist. Es war das, was diese Aufgabe brauchte. Entscheidend ist nicht die Anzahl, sondern die Überschneidung: Zwei Werkzeuge, die dieselbe Frage beantworten, sind schlechter als zehn, die zehn Fragen beantworten.
Wir behaupten auch nicht, große Werkzeugkästen könnten nicht funktionieren. Mit einer darauf ausgerichteten Feinabstimmung können sie es, wie die Forschung zeigt. Wir behaupten, dass die meisten Produkte diese Abstimmung nicht haben und nicht so entwerfen sollten, als hätten sie sie.