Function Calling und Tool Use bei LLMs Erklärt

Was Function Calling bei LLMs wirklich macht

Fragen Sie ein Modell „wie ist das Wetter gerade in Austin" ohne jede Verbindung zur Außenwelt, und es hat zwei Optionen: sagen, dass es das nicht weiß, oder sich etwas ausdenken. Function Calling gibt ihm eine dritte Option. Es beschreibt, was es braucht, gibt diese Beschreibung an Ihren Code weiter und wartet auf eine echte Antwort, bevor es antwortet.

Der Name ist etwas irreführend. Das Modell ruft nichts auf. Es gibt einen Block strukturierter Daten aus, der sagt, welches Tool es möchte und mit welchen Argumenten, und Ihre Anwendung entscheidet, ob sie es ausführt und was sie mit dem Ergebnis macht. „Tool Use" ist der genauere Begriff und der, den Anthropics Dokumentation verwendet; OpenAI und Google sprechen meist von Function Calling. Der Mechanismus ist unter beiden Namen derselbe. Das Modell erzeugt immer nur eine Anfrage, nie den Seiteneffekt.

Warum das Modell Tools anfragt, sie aber nie selbst ausführt

Stellen Sie sich einen Kunden an einem Tresen vor, der auf Gerichte auf der Speisekarte zeigen und sagen kann, wie viele er möchte, aber nie hinter den Tresen geht. Das Modell ist dieser Kunde: Es liest die Speisekarte, die Sie ihm gegeben haben (die Tool-Definitionen), wählt ein Gericht aus und sagt, wie viele es möchte (die Argumente). Ihr Code ist die Person hinter dem Tresen, die die Bestellung zusammenstellt und eine Bestellung ablehnen kann, die keinen Sinn ergibt.

Diese Trennung ist das gesamte Sicherheitsmodell. Ein Tool-Call ist ein Vorschlag, den Ihr Code validieren oder ablehnen kann, genau wie jede andere Eingabe aus einer nicht vertrauenswürdigen Quelle. Denn genau das ist er. Ein Modell, das durch Prompt Injection von einer bösartigen Webseite manipuliert wurde, kann trotzdem nur einen Tool-Call anfragen. Es kann Ihre Validierung nicht überspringen und direkt auf die Datenbank zugreifen.

Wie man ein Tool mit JSON-Schema definiert

Jeder Anbieter will für jedes Tool dieselben drei Dinge: einen Namen, eine Beschreibung, mit der das Modell entscheidet, wann das Tool passt, und ein JSON-Schema für die Argumente. Hier ist ein Wetter-Tool für die OpenAI Chat Completions API:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

weather_tool = {
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Get the current temperature and conditions for a city.",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "City name, e.g. 'Austin, TX'"},
                "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]},
            },
            "required": ["city"],
        },
    },
}

Stecken Sie mehr Zeit in die Beschreibung als in das Schema. Das Modell wählt ein Tool, indem es die Anfrage des Nutzers mit den Beschreibungen in der Liste vergleicht, die Sie ihm geschickt haben. Eine vage Beschreibung („Wetterzeug") wird entweder von einem besser beschriebenen Tool verdrängt, das etwas anderes macht, oder schlägt bei Anfragen zu, die es nicht behandeln sollte. Schreiben Sie sie so, als müssten Sie die Funktion einem Kollegen erklären, der genau einen Satz darüber lesen wird.

Wie der Request-Response-Zyklus beim Function Calling funktioniert

Ein Tool-Call braucht mindestens zwei Requests. Hier ist der komplette Ablauf mit der OpenAI API:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

from openai import OpenAI
import json

client = OpenAI()
messages = [{"role": "user", "content": "What's the weather in Austin?"}]

response = client.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    tools=[weather_tool],
)
message = response.choices[0].message
messages.append(message)

if message.tool_calls:
    for call in message.tool_calls:
        args = json.loads(call.function.arguments)
        result = get_weather(args["city"], args.get("unit", "celsius"))
        messages.append({
            "role": "tool",
            "tool_call_id": call.id,
            "content": json.dumps(result),
        })

    final = client.chat.completions.create(model="gpt-4o", messages=messages)
    print(final.choices[0].message.content)

Die erste Antwort beantwortet die Frage nicht. Sie kommt mit finish_reason gleich tool_calls und ohne Textinhalt zurück, weil das Modell entschieden hat, dass es get_weather braucht, bevor es etwas Nützliches sagen kann. call.function.arguments kommt als JSON-String an, nicht als bereits geparstes Objekt, also ist json.loads nicht optional. get_weather führen Sie selbst aus (es ist eine ganz normale Python-Funktion; das Modell hat keine Möglichkeit, sie auszuführen), und hängen danach das Ergebnis als Nachricht mit role: "tool" und der passenden tool_call_id an.

Erst der zweite Request, der nun dieses Ergebnis enthält, liefert Ihnen einen echten Satz zurück. Wenn Sie die Assistant-Nachricht mit ihren tool_calls anhängen, aber das passende Tool-Ergebnis weglassen, lehnt die API den nächsten Request ab, statt zu raten.

Wie sich Anthropics Tool Use von OpenAIs Function Calling unterscheidet

Gleicher Mechanismus, andere Feldnamen. Wenn Sie zwischen Anbietern wechseln oder beide unterstützen, entstehen Ihre Bugs genau hier:

Die Falle liegt im Format der Argumente. Anthropic gibt Ihnen input schon als geparstes Python-Dict oder JS-Objekt; OpenAI gibt Ihnen einen String, den Sie selbst durch json.loads schicken müssen. Code, der für den einen Anbieter geschrieben und auf den anderen gerichtet wird, lässt sich problemlos importieren und scheitert dann beim ersten Tool-Call. Wenn Sie beide unterstützen, schreiben Sie eine einzige Normalisierungsfunktion, durch die beide Pfade laufen, bevor Ihre Tool-Implementierungen die Argumente überhaupt sehen.

Wie parallele Tool-Calls und mehrstufige Schleifen funktionieren

Beide APIs können in einer einzigen Antwort mehr als einen Tool-Call zurückgeben. Fragen Sie nach dem Wetter in drei Städten, und Sie erhalten drei Einträge in tool_calls, nicht drei separate Hin- und Rückfahrten. Führen Sie sie aus (parallel, wenn sie unabhängig sind) und hängen Sie alle drei Ergebnisse an, bevor der Folge-Request geht. Jede vom Modell ausgegebene Call-ID braucht ein Ergebnis; schicken Sie nur eines von drei zurück, und der Request schlägt fehl.

Manche Aufgaben brauchen mehrere Runden: einen Nutzer nachschlagen, dann dessen Bestellverlauf, dann die überfällige Bestellung markieren. Schreiben Sie das als Schleife, die so lange das Modell aufruft und ausführt, was es verlangt, bis eine Antwort ohne Tool-Calls zurückkommt. Setzen Sie dann eine Obergrenze. Nichts in der API hindert ein Modell daran, neunmal hintereinander dasselbe Tool anzufragen, wenn die Ergebnisse es keiner Antwort näherbringen. Ein festes Limit, etwa 10 oder 20 Iterationen, macht daraus einen klaren Fehler statt einer außer Kontrolle geratenen Rechnung.

Häufige Fehler beim Function Calling

Argumente als vertrauenswürdige Eingabe behandeln. args["city"] stammt aus einem Modell, was bedeutet, dass es aus jedem Text stammt, der die Konversation gefüttert hat, einschließlich einer gescrapten Webseite oder eines Dokuments, das das Modell zusammenfassen sollte. Validieren Sie es, bevor es eine Datenbankabfrage oder einen Shell-Befehl erreicht. Ein Tool, das SQL durch Interpolieren der Modellargumente baut, hat dieselbe Injection-Angriffsfläche wie eines, das SQL aus einem Webformular baut.

Dem Schema wie einer Garantie vertrauen. Das Modell hält sich meist an required und enum, aber nicht perfekt. Früher oder später übergibt es "unit": "F" statt "fahrenheit" oder lässt ein Pflichtfeld weg. Validieren Sie, und geben Sie als Tool-Ergebnis eine klare Fehlermeldung zurück, statt abzustürzen. Sagen Sie dem Modell, was falsch war, und es kann in der nächsten Runde oft mit korrigierten Argumenten erneut versuchen.

Das Modell destruktive Tools allein auswählen lassen. Wenn ein Tool Daten löscht oder eine E-Mail verschickt, ist tool_choice auf automatisch zu lassen die falsche Standardeinstellung. Halten Sie destruktive Tools aus der Liste heraus, bis ein Mensch die konkrete Aktion genehmigt hat, oder machen Sie den Effekt umkehrbar (einen Entwurf statt einer versendeten E-Mail) und lassen Sie einen separaten Schritt ihn bestätigen.

Wann man Function Calling nicht einsetzen sollte

Jeder Tool-Call fügt dem Modell eine zusätzliche Hin- und Rückfahrt hinzu, plus die Latenz, die das Tool selbst mitbringt. Wenn das „Tool" ohnehin nur eine statische Tatsache zurückgeben würde, legen Sie diese Tatsache in den Prompt oder in den abgerufenen Kontext und sparen Sie sich die Hin- und Rückfahrt; dafür ist das RAG-Retrieval da. Und wenn die Entscheidung eigentlich eine Klassifikation mit einer kleinen, festen Menge an Ergebnissen ist (dieses Ticket an eine von vier Warteschlangen weiterleiten), antwortet ein typisierter, nicht generativer Aufruf schneller und günstiger, als ein allgemeines Chat-Modell ein Tool auswählen zu lassen. Genau dafür sind System-One-Modelle gebaut.

Function Calling rechtfertigt seine Kosten, wenn die Aktion von Laufzeitdaten abhängt, die das Modell nicht im Prompt haben kann, und die Menge möglicher Aktionen zu offen ist, um sie als Zustandsmaschine festzulegen. Es ist außerdem die Schleife hinter jedem CLI-Coding-Agenten: eine Datei lesen, einen Test ausführen, entscheiden, was als Nächstes kommt, ein weiteres Tool aufrufen.

Beginnen Sie mit einem Tool, einer fest codierten Python-Funktion dahinter und einer Schleife, die nach einer einzigen Hin- und Rückfahrt stoppt. Bringen Sie Argumentvalidierung und Fehlerpfad in Ordnung, bevor Sie ein zweites Tool hinzufügen. Die meisten Bugs in einem Setup mit mehreren Tools stellen sich als das erste Tool heraus, das Argumente falsch behandelt, mit denen es nicht gerechnet hat.

Verwandte Artikel

• Was ist RAG: Retrieval-Augmented Generation Erklärt
• Wie CLI-Coding-Agenten funktionieren und welchen Sie wählen
• Was ist ein System-One-Modell und wann Sie eines einsetzen
• Was Sind Embeddings und die Vektorsuche