Skip to main content
LLMtool callingAI automation

Self-Assist: Ziel zuerst, dann Tool Calling

In der neuen Self-Assist-Arbeit zeigen die Autoren: Wenn man das Modell zwingt, zuerst das Ziel zu formulieren, bevor es ein Werkzeug auswählt, steigt die Genauigkeit des Tool Callings spürbar. Für die KI-Automatisierung ist das wichtig, weil Agenten dann seltener unnötige Werkzeuge aufrufen und mehrschrittige Szenarien besser bewältigen.

Technischer Kontext

Ich mag solche Arbeiten nicht wegen schöner Grafiken, sondern weil man sie direkt in der KI-Automatisierung im Einsatz anwenden kann. Die Idee ist sehr bodenständig: Das Modell nicht sofort aus einer rohen Anfrage ein Werkzeug auswählen zu lassen, sondern es zunächst zu zwingen, das Ziel des Benutzers zu verstehen.

Im Paper wird das Self-Assist genannt. Im Wesentlichen ist es ein zweistufiges Verfahren: Zuerst liefert der Retriever die top-k Kandidaten, dann analysiert das LLM die Anfrage, die Werkzeugbeschreibungen und die Kandidaten selbst und wählt erst danach aus, wie es handelt.

Mir gefiel hier nicht der Name, sondern die ingenieurtechnische Logik. Wenn ein Agent direkt aus der Nutzerphrase in einen Tool Call springt, klammert er sich oft an Schlüsselwörter. Füge ich jedoch einen Zwischenschritt mit einer expliziten Zielformulierung ein, wird die Auswahl weniger zappelig und überlegter.

Die Autoren berichten von einer Steigerung der Werkzeugauswahlgenauigkeit auf bis zu 97 % gegenüber 80 % beim Basisansatz. Wichtig ist, nicht zu verallgemeinern: Der Haupteffekt wurde an großen Modellen beobachtet, darunter Claude Opus 4.x-Niveau, aber für kleine Modelle wird ein solcher Prompt im Kontext schnell zu Rauschen.

Das überrascht mich nicht. Ein kleines Modell neigt dazu, entweder Begründungen zu halluzinieren oder umgekehrt ein Werkzeug aufzurufen, selbst wenn es ohne antworten könnte. Zusätzliches Nachdenken ist für es keine Hilfe, sondern eine zusätzliche kognitive Belastung.

Was das in der Produktion ändert

Erstens: Wenn Sie einen Agenten mit 20–100 Werkzeugen bauen, kann ein zielorientierter Schritt günstiger sein, als das Chaos nach fehlerhaften Aufrufen zu beheben. Besonders dort, wo ein Fehler nicht zu schlechtem Text, sondern zu einem überflüssigen API-Aufruf, einem CRM-Eintrag oder einem Prozessstart führt.

Zweitens: Die Architektur des Agenten wird klarer. Ich würde die Zielanalyse in einen eigenen Pipeline-Knoten auslagern, anstatt sie in einem riesigen System-Prompt zu verstecken. So lässt sich leichter debuggen und messen, wo genau der Agent scheitert.

Die Verlierer sind hier vor allem diejenigen, die hoffen, mit demselben Schema sowohl leistungsstarke Modelle als auch kleine lokale Modelle abzudecken. Das funktioniert nicht. Bei der Integration künstlicher Intelligenz muss man die Denktiefe an die Modellklasse anpassen, sonst fressen Kosten und Rauschen den gesamten Gewinn auf.

Wir bei Nahornyi AI Lab lösen solche Dinge praktisch: wo ein expliziter Zielschritt nötig ist, wo gutes Routing genügt und wo es besser ist, ganz auf Tool Calling zu verzichten. Wenn Ihr Agent bereits in einem CRM, Support oder internen Abläufen läuft und sich unvorhersehbar verhält, kann ich mit meinem Team eine KI-Lösungsentwicklung ohne Magie, mit solider Architektur und messbarem Geschäftsnutzen aufbauen.

Wir haben bereits darüber berichtet, wie man die Zuverlässigkeit eines LLM-Richters mit IRT-Metriken misst, um Automatisierungsrisiken zu reduzieren und eine stabile Qualitätskontrolle zu gewährleisten. Dieser Ansatz zur Bewertung der Modellgenauigkeit steht in direktem Zusammenhang damit, wie man einen Prompt richtig formuliert, um maximale Genauigkeit bei der Werkzeugauswahl zu erreichen.

Diesen Artikel teilen