Wenn über Halluzinationen gesprochen wird, klingt es oft, als sei das Modell selbst das eigentliche Problem. Es weiß zu wenig, verwechselt Fakten oder redet zu glatt über Unsicherheiten hinweg. Das ist nicht falsch. Aber es ist nur die halbe Wahrheit.

In vielen produktiven Systemen liegt der Fehler an einer anderen Stelle. Das Modell wird überhaupt erst in eine Lage gebracht, in der es raten muss. Es soll Preise nennen, obwohl die Preise in einer Datenbank liegen. Es soll API-Aufrufe erraten, obwohl eine Dokumentation existiert. Es soll Verfügbarkeiten formulieren, obwohl eine Schnittstelle die exakten Werte liefern könnte. Dann erscheint das Problem als Halluzination. In Wirklichkeit ist es oft ein Routing-Fehler.

Gerade deshalb ist Tool Use mehr als ein Zusatzfeature. Es ist eine architektonische Antwort auf die falsche Erwartung, ein Sprachmodell müsse die Welt im Alleingang erklären.

Viele Halluzinationen sind Routing-Fehler

Je allgemeiner man ein Modell fragt, desto eher beginnt es, fehlende Gewissheit mit plausibler Sprache zu kaschieren. Das ist nicht böswillig. Es ist die Logik freier Textgenerierung. Wer ein Modell bittet, eine SQL-Antwort, einen API-Parameter oder eine aktuelle Bestandszahl aus dem Nichts zu formulieren, fordert nicht Intelligenz, sondern Improvisation.

Darum ist die erste Gegenmaßnahme gegen Halluzinationen oft erstaunlich unspektakulär. Nicht ein noch größeres Modell, sondern eine bessere Zuordnung von Aufgabe und Werkzeug. Rechnen gehört in einen Rechner. Dokumentation gehört in Suche oder Retrieval. Zustandsdaten gehören in Datenbanken, APIs oder Event-Systeme. Ein Modell bleibt wichtig, aber in einer anderen Rolle: Es liest die Absicht, wählt das passende Werkzeug, formatiert Ein- und Ausgabe und hält den Arbeitsfluss zusammen.

Dann verschiebt sich die Frage. Nicht mehr: “Weiß das Modell genug?” Sondern: “Ist das System so gebaut, dass es möglichst wenig raten muss?”

Was die Forschung dazu inzwischen zeigt

Ein früher und bis heute wichtiger Schritt ist Toolformer. Schick et al. beschreiben dort ein Modell, das lernt, wann ein Tool aufgerufen werden sollte, welches Tool sinnvoll ist und wie das Ergebnis wieder in die weitere Generierung eingeht. Zentral ist dabei eine nüchterne Beobachtung: Sprachmodelle sind in freier Formulierung stark, tun sich aber gerade bei Aufgaben wie Arithmetik oder Faktensuche schwer, obwohl dafür viel kleinere Spezialsysteme genügen. Tool Use verbindet genau diese beiden Welten.

Spätestens mit API-Bank wird daraus nicht nur eine schöne Idee, sondern ein messbares Forschungsfeld. Li et al. stellen einen ausführbaren Benchmark mit 73 Tools vor und zeigen, dass selbst starke Modelle bei Planung, API-Auswahl und korrektem Aufruf noch deutliche Schwächen haben. Das ist wichtig, weil es den Nebel etwas lichtet: Tool Use ist kein magischer Prompt-Trick, sondern eine eigenständige Fähigkeit mit klaren Fehlerbildern.

Besonders aufschlussreich ist Gorilla. Patil et al. beschreiben ein feinabgestimmtes LLaMA-basiertes Modell, das GPT-4 beim Schreiben von API-Aufrufen übertrifft. Das Ergebnis ist deshalb so interessant, weil es gegen einen verbreiteten Reflex spricht. Nicht immer gewinnt das größere, allgemeinere Modell. In eng umrissenen, strukturierten Werkzeugaufgaben kann ein spezialisierteres und kleineres System robuster sein, gerade wenn es mit Dokumentretrieval kombiniert wird und dadurch weniger API-Nutzung halluziniert.

Ähnlich weist ToolLLM in diese Richtung. Die Arbeit konstruiert mit ToolBench einen großen Trainings- und Evaluationsrahmen für reale APIs und zeigt, dass ein feinabgestimmtes offenes Modell über viele Werkzeuge hinweg generalisieren kann. Die Pointe liegt nicht nur in der Größe des API-Raums. Wichtiger ist die Einsicht, dass Tool-Nutzung gelernt, strukturiert und evaluiert werden kann. Sie ist also keine Randbegabung, sondern ein eigenes architektonisches Feld.

Noch einen Schritt weiter geht Acting Less is Reasoning More! Teaching Model to Act Efficiently. Wang et al. zeigen, dass auch das Gegenteil zum Problem werden kann: zu viele Tool-Aufrufe. Das Papier spricht von cognitive offloading. Wenn ein Modell bei jeder Unsicherheit hektisch nach draußen greift, steigen Kosten, Latenz und Komplexität. Die Autoren reduzieren Tool-Aufrufe in ihren Experimenten deutlich, ohne die Antwortqualität zu verschlechtern. Das ist für Produktivsysteme eine wichtige Lektion. Guter Tool Use heißt nicht: immer ein Tool aufrufen. Guter Tool Use heißt: das richtige Werkzeug nur dann verwenden, wenn es wirklich nötig ist.

Schließlich ist für kleine Systeme besonders relevant, was Small Models, Big Tasks untersucht. Kavathekar et al. zeigen, dass kleine Sprachmodelle bei Function Calling durchaus Potenzial haben, insbesondere mit Few-Shot-Setup oder Fine-Tuning, zugleich aber noch Mühe mit strikten Ausgabeformaten haben. Das Ergebnis ist weder Euphorie noch Abgesang. Es zeigt etwas Nüchterneres: Kleine Modelle können in diesem Feld praktisch werden, wenn man ihre Umgebung sauber baut.

Warum kleine, schnelle Inference-Stacks hier punkten können

Gerade bei Tool Use zählt nicht nur die Qualität eines einzelnen Modellaufrufs, sondern die Qualität des gesamten Kreislaufs. Eine Anfrage wird verstanden, ein Tool ausgewählt, Parameter erzeugt, eine Antwort geprüft, vielleicht nachgebessert und dann in eine verständliche Form gebracht. Dieser Ablauf ist häufig seriell. Jede zusätzliche Latenz vervielfacht sich. Genau hier können kleine, schnelle Inference-Engines einen sehr realen Vorteil haben.

Ein lokaler oder edge-naher Stack mit kleinem Modell reagiert oft schneller, billiger und häufiger. Das klingt zunächst banal, hat aber Folgen. Wenn ein Modell nur 100 oder 200 Millisekunden für einen kleinen Routing- oder Verifikationsschritt braucht, kann man sich mehr davon leisten: einen zusätzlichen Prüfschritt, eine zweite Parametervalidierung, einen kurzen Selbstcheck oder eine erneute API-Auswahl. Bei einem schweren Modell in der Cloud wird aus derselben Idee rasch ein träger und teurer Prozess.

Gerade deshalb kann ein kleines Modell in Tool-Architekturen strukturell im Vorteil sein. Es muss nicht die Welt wissen. Es muss die Welt nur gut ansprechen. Wenn seine Hauptaufgabe darin besteht, Werkzeuge auszuwählen, Argumente sauber zu formen, Ergebnisse kurz zu bewerten und die Antwort lesbar zu verpacken, dann ist Breite oft weniger entscheidend als Schnelligkeit, Formatdisziplin und niedrige Betriebskosten. Das ist keine direkte Behauptung eines einzelnen Papers, sondern eine Synthese aus den genannten Arbeiten und ihrer Systemlogik.

Hinzu kommt ein zweiter Vorteil: lokale Kontrolle. Kleine Inference-Engines lassen sich näher an den Daten betreiben, besser beobachten und leichter einschränken. Gerade wenn Tools auf interne Dateien, Suchindizes, Git-Repositories, Datenbanken oder Edge-Hardware zugreifen, ist das kein Nebenaspekt. Weniger Netzabhängigkeit bedeutet oft nicht nur mehr Datenschutz, sondern auch weniger Systemreibung.

Ein dritter Punkt wird leicht unterschätzt: Kleine Modelle zwingen zu Disziplin. Wer mit einem kleineren Modell arbeitet, baut eher klare Prompts, stabile Tool-Schemata, präzise JSON-Ausgaben und saubere Rechte. Große Modelle verzeihen viel und verdecken damit oft schlechte Architektur. Kleine Modelle sind strenger. Das kann unbequem sein, führt aber oft zu besseren Systemen.

Wo kleine Systeme sogar einen Vorteil haben

Der verbreitete Irrtum lautet, kleine Modelle seien bloß die billigere Notlösung. Für freie Essayistik oder breite Weltkenntnis stimmt das oft nicht. Für Tool Use kann das Bild anders aussehen.

Wenn die Aufgabe stark strukturiert ist, die relevante Wahrheit außerhalb des Modells liegt und das System vor allem korrekt routen, parametrisieren und prüfen muss, dann wird ein großes Modell schnell zu einer teuren Universalmaschine für eine vergleichsweise nüchterne Aufgabe. Ein kleineres, spezialisiertes oder feinabgestimmtes Modell kann dort mithalten oder sogar gewinnen, weil es schneller im Kreis läuft, häufiger kontrolliert werden kann und weniger dazu neigt, seine Unsicherheit mit einer großen Geste zu überdecken.

Gerade in lokalen oder hybriden Architekturen ist das attraktiv. Das kleine Modell übernimmt Klassifikation, Tool-Selektion, Argumentbildung und knappe Nachprüfung. Erst wenn der Fall offen, mehrdeutig oder sprachlich anspruchsvoll wird, eskaliert das System an ein größeres Modell. So wird Größe zur Ausnahme, nicht zur Grundannahme.

Was das für geisten bedeutet

Für geisten spricht deshalb vieles für eine Architektur, in der das Modell nicht als allwissender Erzähler auftritt, sondern als präziser Operator zwischen Werkzeugen. Suchindex, Dateizugriff, Git, Shell, SQL, RAG, API-Calls oder kleine Rechenfunktionen sollten nicht als Zubehör erscheinen, sondern als erste Klasse des Systems.

Das passt besonders gut zu lokalen und CPU-effizienten Setups. Ein kleines oder mittleres Modell kann dort Analyse, Routing, Review und Formatierung übernehmen. Die exakte Wahrheit kommt, wo immer möglich, aus einem Tool. Das reduziert Halluzinationen nicht durch moralische Appelle an das Modell, sondern durch eine veränderte Arbeitsteilung.

Ebenso wichtig ist die Rechtefrage. Nicht jedes Modell braucht sofort Zugriff auf write, run oder weitreichende Seiteneffekte. Ein System, das search, read und calc sauber von schreibenden oder ausführenden Werkzeugen trennt, reduziert nicht nur Risiko, sondern oft auch Halluzinationen. Denn aus vager Sprache wird dann nicht so leicht unmittelbare Wirkung.

Anders gesagt: Das Ziel ist nicht, eine Maschine zu bauen, die alles weiß. Das Ziel ist ein System, das weiß, wann es lieber nachschauen, nachrechnen oder nachfragen sollte.

Fazit

Viele Halluzinationen entstehen nicht, weil Modelle grundsätzlich unbrauchbar wären. Sie entstehen, weil wir sie zu oft auf die falsche Bühne stellen. Wer ein Sprachmodell dort reden lässt, wo ein Werkzeug genauer wäre, bekommt häufig stilvolle Unsicherheit.

Tool Use ist deshalb keine Randfunktion, sondern eine der wichtigsten architektonischen Antworten auf das Halluzinationsproblem. Und gerade kleine, schnelle Inference-Stacks können hier stark sein. Nicht weil sie mehr Weltwissen mitbringen, sondern weil sie in einem gut gebauten System schneller routen, billiger prüfen, leichter begrenzen und näher an den eigentlichen Werkzeugen laufen.

Die eigentliche Zukunft liegt daher vermutlich nicht im einen Modell, das alles kann. Sie liegt in Systemen, die gut unterscheiden können, wann Sprache genügt und wann die Welt besser durch ein Werkzeug spricht.

Weiterführende Quellen

Wenn Sie Tool Use, lokale Inference und kleine Modelle für robuste Arbeitsabläufe zusammendenken möchten, sprechen Sie uns gerne an: info@geisten.com