Michael Kanda Logo

Function Calling: Vom Modellvorschlag zur geprüften Aktion

Von

Function Calling ermöglicht einem Sprachmodell, einen strukturierten Werkzeugaufruf vorzuschlagen: Funktionsname und Argumente. Die Anwendung oder ein von ihr verwendetes Framework führt die Funktion aus. Ein Aufruf kann zusammen mit Text erscheinen; er ist noch kein Beleg dafür, dass die Aktion erfolgreich ausgeführt wurde.

Der Ablauf in vier Schritten

Die Anwendung übergibt dem Modell nicht nur die Frage, sondern auch eine Liste verfügbarer Funktionen mit Namen, Zweck und erwarteten Parametern.

  1. Der Nutzer fragt: „Wie ist das Wetter heute in Wien?“
  2. Das Modell schlägt einen strukturierten Aufruf vor; zusätzlicher Text ist je nach API möglich.
  3. Die Anwendung prüft den Vorschlag, ruft die Funktion auf und bekommt ein Ergebnis.
  4. Das Ergebnis geht zurück ins Gespräch, das Modell formuliert daraus die Antwort.

Der Vorschlag aus Schritt zwei sieht in etwa so aus:

Die folgenden JSON-Beispiele veranschaulichen das Prinzip. Die genaue Einbettung und das Antwortformat unterscheiden sich je nach Anbieter und API.

{
  "name": "wetter_abfragen",
  "arguments": {
    "ort": "Wien",
    "einheit": "celsius"
  }
}

Und die Beschreibung, die die Anwendung vorher übergeben hat, so:

{
  "name": "wetter_abfragen",
  "description": "Liefert die aktuelle Temperatur und Wetterlage für einen Ort. Nur für aktuelle Werte, nicht für Vorhersagen.",
  "parameters": {
    "type": "object",
    "properties": {
      "ort":     { "type": "string", "description": "Stadtname, z. B. Wien" },
      "einheit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
    },
    "required": ["ort"]
  }
}

Die Beschreibung ist Teil des Prompts

Die Beschreibung, der Funktionsname und das Parameterschema helfen dem Modell bei der Werkzeugauswahl. Auch Nutzerfrage, Gesprächskontext, übergeordnete Anweisungen und API-Einstellungen beeinflussen die Entscheidung. Die Beschreibung ist deshalb ein Teil des Prompts und keine isolierte Garantie für richtiges Verhalten.

Beschreibe Zweck und Grenzen möglichst konkret. „Liefert aktuelle Wetterwerte, keine Vorhersagen“ ist eindeutiger als „Liefert das Wetter“. Solche Hinweise können Fehlaufrufe reduzieren, verhindern sie aber nicht zuverlässig. Die Anwendung muss Grenzen technisch durchsetzen.

Überlappende Beschreibungen können die Auswahl erschweren. Fehler können ebenso am Modell, am Kontext, an unklaren Nutzerfragen oder an unpassenden Schemas liegen. Prüfe typische und mehrdeutige Anfragen, bevor du die Ursache auf einen einzelnen Faktor zurückführst.

Der Kontrollpunkt zwischen Vorschlag und Ausführung

Der wichtige Kontrollpunkt liegt zwischen Vorschlag und Ausführung. Auch wenn ein SDK den Ablauf automatisiert, muss die Anwendung festlegen, welche Funktionen mit welchen Berechtigungen erreichbar sind.

Das ist keine Formalie, sondern der Ort, an dem Sicherheit stattfindet. Ein Modell kann einen Aufruf mit unsinnigen Parametern vorschlagen, mit Parametern aus einem anderen Zusammenhang, oder einen Aufruf, den ein Text in einem zuvor gelesenen Dokument nahegelegt hat. Wer Vorschläge ungeprüft ausführt, hat die Steuerung an alles abgegeben, was jemals in den Kontext gelangt.

Praktisch heißt das: Funktionsnamen erlaubnisbasiert auswählen, Parameter und Wertebereiche validieren, Berechtigungen serverseitig prüfen und Zeit- sowie Kostenlimits setzen. Schreibende Aktionen brauchen je nach Wirkung eine Bestätigung oder einen klar begrenzten Auftrag. Wiederholungen dürfen keine doppelten Buchungen oder Zahlungen auslösen. Auch Werkzeugergebnisse sind als potenziell nicht vertrauenswürdige Inhalte zu behandeln.

Abgrenzung zu MCP

Function Calling beschreibt die Werkzeugauswahl auf der Modellseite. MCP standardisiert die Kommunikation zwischen Anwendung und Werkzeugserver, einschließlich Werkzeugliste und Aufrufen. Beides lässt sich kombinieren. Das Protokoll verlangt jedoch kein bestimmtes Modell und keine bestimmte Function-Calling-API.

Eine Funktionsliste kann auch ohne MCP dynamisch aufgebaut werden. MCP bietet dafür ein gemeinsames Protokoll: Der Client kann Werkzeuge auflisten und ihre Aufrufe vermitteln. Neue Werkzeuge werden nur nutzbar, wenn der Client Aktualisierungen verarbeitet und seine Freigaben sie zulassen.

Als Merkhilfe: Function Calling liefert den Aufrufvorschlag, MCP kann den standardisierten Transport zu einem Werkzeug übernehmen.

Abgrenzung zu einer REST-API

Eine REST-API stellt Ressourcen und Operationen über HTTP bereit. Sie kann von festem Anwendungscode oder von einem Werkzeug angesprochen werden, das ein Modell auswählt. Die Anwendung übersetzt dann geprüfte Argumente in einen HTTP-Aufruf.

Beschreibung und Schema erfüllen unterschiedliche Aufgaben: Die Beschreibung erklärt, wann ein Werkzeug passt; das Schema legt die erwartete Struktur fest. Beides ist wichtig. Ein aus OpenAPI erzeugtes Werkzeugangebot ist ein möglicher Ausgangspunkt, sollte aber auf verständliche Namen, begrenzte Zuständigkeiten und Berechtigungen geprüft werden.

Typische Fehlerbilder

Zu viele Funktionen gleichzeitig. Große Werkzeuglisten belegen Kontext und können die Auswahl erschweren. Ob eine kleinere oder dynamisch gefilterte Liste hilft, muss mit dem verwendeten Modell getestet werden.

Überlappende Zuständigkeiten. Zwei Funktionen, die dasselbe können, sind eine Einladung zum Raten.

Fehler ohne Erklärung. Eine verständliche Rückmeldung zu fehlenden oder unzulässigen Argumenten erleichtert eine Korrektur. Sie garantiert keinen richtigen zweiten Versuch; Wiederholungen brauchen ein Limit.

Ergebnis nicht zurückgegeben. Das Modell sollte nur über einen Erfolg berichten, wenn ein entsprechendes Werkzeugergebnis vorliegt. Fehlt es, muss der Ablauf abbrechen oder den fehlenden Status kenntlich machen.

Verwandte Begriffe

Quellen und weiterführende Dokumentation