Function Calling in der Praxis: Die häufigsten Fehlerbilder und ihre Behandlung

Function Calling ist der Mechanismus, der aus einem Sprachmodell ein handelndes System macht: Das Modell bekommt eine Liste von Werkzeugen mit Beschreibung und Parametern, entscheidet selbst, wann es eines aufruft, und die Anwendung führt den Aufruf aus. In der Demo wirkt das verblüffend zuverlässig. Im Dauerbetrieb zeigt sich ein anderes Bild: Das Modell ruft Werkzeuge auf, die es nicht gibt, füllt Parameter mit plausiblen Erfindungen, ruft dasselbe Werkzeug doppelt auf oder ignoriert es genau dann, wenn es gebraucht würde.

Der entscheidende Perspektivwechsel ist derselbe wie bei allen Modellausgaben: Ein Tool-Aufruf ist keine Anweisung, sondern ein Vorschlag. Zwischen diesem Vorschlag und der tatsächlichen Ausführung gehört eine Schicht, die prüft, korrigiert und im Zweifel ablehnt. Wer diese Schicht sauber baut, macht aus einem launischen Verhalten ein beherrschbares.

Die typischen Fehlerbilder im Katalog

Es lohnt sich, die Fehlerbilder einzeln zu kennen, weil jedes eine andere Behandlung braucht:

• Halluzinierte Tool-Namen: Das Modell ruft ein Werkzeug auf, das nie definiert wurde, oft eine plausible Variante eines echten Namens. Tritt gehäuft auf, wenn viele ähnlich benannte Werkzeuge angeboten werden.
• Erfundene Parameter: Der Aufruf ist formal korrekt, aber ein Pflichtwert wurde geraten statt erfragt, etwa eine Kundennummer, die nirgends im Gespräch vorkam. Das gefährlichste Fehlerbild, weil es unauffällig ist.
• Falsche Typen und Formate: Datum im falschen Format, Zahl als Text, Enum-Wert frei formuliert.
• Doppelte Aufrufe: Dasselbe Werkzeug wird mit denselben Parametern mehrfach aufgerufen, besonders kritisch bei schreibenden Operationen wie dem Anlegen eines Datensatzes.
• Unterlassene Aufrufe: Das Modell beantwortet aus dem Gedächtnis, was es über ein Werkzeug hätte nachschlagen müssen, und halluziniert dabei Fakten.
• Text statt Aufruf: Das Modell beschreibt den Aufruf im Fließtext, statt den Mechanismus zu nutzen.

Viele dieser Bilder lassen sich schon im Design entschärfen: wenige, klar abgegrenzte Werkzeuge mit sprechenden Namen, präzise Beschreibungen, die auch sagen, wann ein Werkzeug nicht zu verwenden ist, und strenge Parameterschemata mit Enums statt freier Texte.

Validierung vor der Ausführung

Die erste Verteidigungslinie ist deterministischer Code, der jeden vorgeschlagenen Aufruf prüft, bevor irgendetwas ausgeführt wird. Drei Stufen haben sich bewährt. Zuerst die Existenzprüfung: Gibt es das Werkzeug überhaupt? Dann die Schemaprüfung: Stimmen Parameter, Typen und Pflichtfelder, liegen Werte in erlaubten Bereichen? Und schließlich die fachliche Prüfung: Ergibt der Aufruf im aktuellen Zustand Sinn? Ein Storno für eine Bestellung, die nicht existiert, ist schemakonform und trotzdem falsch.

Für schreibende Operationen kommt eine vierte Stufe dazu: Idempotenz. Die Anwendung sollte erkennen, wenn derselbe Aufruf innerhalb kurzer Zeit wiederholt wird, und die Wirkung nur einmal eintreten lassen, etwa über einen Schlüssel aus den Aufrufparametern. Damit verliert das Fehlerbild der doppelten Aufrufe seinen Schrecken: Der zweite Aufruf läuft ins Leere, statt einen zweiten Datensatz anzulegen. Bei besonders folgenreichen Operationen bleibt zusätzlich die bewährte Freigabe durch einen Menschen die letzte Stufe.

Retry-Strategien mit Augenmaß

Nicht jeder fehlerhafte Aufruf ist ein Grund zum Abbruch. Formatfehler und erkennbar falsche Parameter lassen sich oft heilen, indem man dem Modell den Fehler zurückmeldet und es den Aufruf korrigieren lässt. Dabei gelten drei Regeln. Erstens: eine harte Obergrenze an Versuchen, typischerweise zwei bis drei, danach ein definierter Abbruchpfad. Ohne Obergrenze entstehen Schleifen, in denen das Modell denselben Fehler in Varianten wiederholt und dabei Kosten produziert. Zweitens: Der Wiederholungsversuch braucht neue Information. Denselben Aufruf unverändert noch einmal anzustoßen, ändert bei einem deterministischen Fehler nichts. Drittens: Wiederholungen nur bei Fehlern, die das Modell beheben kann. Ein abgelaufener API-Schlüssel oder ein nicht erreichbares System ist kein Fall für das Modell, sondern für die Anwendung.

Der Abbruchpfad verdient dieselbe Sorgfalt wie der Erfolgsfall. Wenn die Versuche erschöpft sind, sollte das System dem Nutzer ehrlich sagen, was nicht funktioniert hat, statt eine halbe Antwort zu improvisieren.

Fehler richtig an das Modell zurückgeben

Wie ein Fehler an das Modell zurückgemeldet wird, entscheidet darüber, ob der nächste Versuch besser wird. Eine nackte Fehlermeldung aus dem Backend, etwa ein technischer Stacktrace, hilft dem Modell wenig und verwirrt es im schlechtesten Fall. Wirksam sind Rückgaben, die drei Dinge enthalten: was falsch war, und zwar konkret auf Parameterebene, was stattdessen erwartet wird, und was das Modell als Nächstes tun soll. Statt einer generischen Meldung über eine ungültige Eingabe also die Aussage, dass das Feld für den Zeitraum ein Datum im ISO-Format erwartet und der übergebene Wert nicht geparst werden konnte.

Auch der Erfolgsfall gehört gestaltet: Werkzeugantworten sollten kompakt und strukturiert sein, keine ungefilterten Rohdaten. Ein Werkzeug, das hunderte Zeilen zurückliefert, flutet das Kontextfenster und verschlechtert alle folgenden Entscheidungen des Modells. Die Werkzeugantwort ist Teil des Prompts und sollte so behandelt werden.

Grenzen bei mehrstufigen und parallelen Aufrufen

Mit der Zahl der Schritte steigt die Fehlerwahrscheinlichkeit schneller, als einem lieb ist. Bei mehrstufigen Abläufen, in denen das Ergebnis eines Aufrufs den nächsten bestimmt, pflanzen sich frühe Fehler fort: Ein falsch geratener Parameter im ersten Schritt macht alle folgenden Schritte wertlos, und das System merkt es erst am Ende, wenn überhaupt. Deshalb gilt: Zwischenstände validieren, nicht nur Endergebnisse, und bei Ketten mit schreibenden Operationen definieren, wie ein halb ausgeführter Ablauf zurückgerollt oder gekennzeichnet wird.

Parallele Aufrufe, bei denen das Modell mehrere Werkzeuge in einem Zug anfordert, sparen Latenz, bringen aber eigene Probleme: Aufrufe, die voneinander abhängen, obwohl sie parallel angefordert wurden, und Konflikte, wenn zwei Aufrufe denselben Datensatz verändern. Eine pragmatische Linie für den Einstieg: Lesende Aufrufe dürfen parallel laufen, schreibende werden serialisiert und einzeln validiert. Und wo ein Ablauf wirklich stabil sein muss, ist es oft die bessere Entscheidung, die Schrittfolge fest im Code zu verdrahten und dem Modell nur die Entscheidungen zu überlassen, die tatsächlich offen sind.

Fazit

Function Calling wird produktionstauglich durch eine unspektakuläre Zutat: eine Prüfschicht zwischen Modellvorschlag und Ausführung. Wer die typischen Fehlerbilder kennt, Aufrufe vor der Ausführung auf Existenz, Schema und fachlichen Sinn prüft, Wiederholungen begrenzt und mit konkreten Fehlermeldungen füttert, schreibende Operationen idempotent macht und bei mehrstufigen Abläufen Zwischenstände kontrolliert, bekommt ein System, das mit den Launen des Modells rechnet, statt an ihnen zu scheitern. Das Modell schlägt vor, der Code entscheidet.