Function Calling — Wenn KI Knöpfe drückt

Im vorherigen Artikel hast du gesehen, wie RAG einem Sprachmodell Zugang zu aktuellen Dokumenten gibt. Aber Dokumente lesen ist immer noch passiv — wie jemandem eine Bibliothek zu geben und ihn gleichzeitig am Schreibtisch festzuketten. Was wäre, wenn das Modell tatsächlich handeln könnte — Live-Daten abrufen, Workflows auslösen, Nachrichten senden?

Function Calling ist der Mechanismus, der das ermöglicht. Er macht die KI nicht schlauer — er gibt der KI Hände. Dieser Artikel zeigt genau, wie das funktioniert: warum das Modell Werkzeuge braucht, wie Werkzeuge definiert werden und wie die komplette Schleife von der Frage zur realen Aktion unter der Haube arbeitet.

Die Grenze des Textes — Warum Sprachmodelle keine Arme haben

Stell dir ein superintelligentes Gehirn vor, das in einem Nährstoffglas auf einem Labortisch schwebt. Es kann brillant denken — Strategien entwerfen, Gedichte schreiben, Gleichungen lösen. Aber es hat keine Augen, keine Ohren, keine Hände. Wenn du ihm sagst "Schick eine E-Mail an Sarah", kann es die perfekte Nachricht verfassen, aber es kann den Senden-Knopf nicht drücken. Es hat keine Verbindung zur Außenwelt.

Genau so funktionieren große Sprachmodelle: Text rein, Text raus. Sie sagen das nächste Wort vorher, basierend auf statistischen Mustern aus ihren Trainingsdaten. Sie haben keinen Mechanismus, um auf externe Systeme zuzugreifen, Code auszuführen oder Echtzeitinformationen wahrzunehmen. RAG hat dieses Problem teilweise gelöst, indem es relevante Dokumente in den Kontext injiziert — aber RAG ist passiv: es liefert Wissen, keine Handlungsfähigkeit.

Dieselbe Frage, dasselbe Modell — radikal unterschiedliche Zuverlässigkeit. Im ersten Fall halluziniert das Modell eine statistisch plausible Antwort, weil sein Trainingssignal plausible Textfortsetzung belohnt, nicht epistemische Ehrlichkeit. Im zweiten Fall wird die Halluzination durch echte Daten ersetzt.

Anders als ein echtes Gehirn im Glas, das seine eigenen Grenzen erkennen würde ("Ich kann nicht sehen — ich bin in einem Glas"), fehlt einem LLM diese Selbstwahrnehmung. Es halluziniert, weil sein Trainingssignal die Produktion plausibler Antworten belohnt — nicht das Eingestehen von Unwissen.

Das Werkzeuginventar — JSON Schema als Vertrag

Bevor ein Modell Werkzeuge nutzen kann, muss ein Entwickler sie mittels eines JSON-Schemas deklarieren (JSON ist ein standardisiertes Textformat, mit dem Computer Daten austauschen), das bei jeder API-Anfrage mitgeschickt wird. Jede Werkzeugdefinition hat drei Bestandteile: einen technischen Bezeichner (name), eine natürlichsprachliche Beschreibung (description) und eine Parameterdefinition (parameters). Das Modell liest diese Definitionen und entscheidet dynamisch — bei jeder Nutzernachricht — ob ein Werkzeug gebraucht wird und welches.

{
  "tools": [{
    "name": "get_weather",
    "description": "Gibt das aktuelle Wetter für
      eine Stadt zurück. Verwenden, wenn
      der Nutzer nach Wetter, Temperatur oder
      Outdoor-Bedingungen fragt.",
    "parameters": {
      "type": "object",
      "properties": {
        "city": { "type": "string" },
        "unit": { "enum": ["celsius","fahrenheit"] }
      },
      "required": ["city"]
    }
  }]
}

Die Qualität der Beschreibung bestimmt alles. Eine vage Beschreibung wie "Datenbankfunktion" führt dazu, dass das Modell das Werkzeug ignoriert, selbst wenn der Nutzer eine passende Frage stellt. Eine präzise Beschreibung wie "Führt eine Leseanfrage an die Bestelldatenbank aus. Verwenden, wenn der Nutzer nach Bestellzahlen, Umsatz oder Kundendaten fragt" ermöglicht korrekte Werkzeugauswahl.

Die Ausführungsschleife — Vom JSON zum Agenten

Function Calling allein ist nur die halbe Geschichte. Die vollständige Architektur ist eine vierschrittige Schleife, die sich wiederholen kann — und genau diese Wiederholung macht aus einem Chatbot einen Agenten.

Ein einfaches Beispiel: Der Nutzer fragt "Wie ist das Wetter in Berlin?" Das Modell entscheidet, dass es das get_weather-Werkzeug braucht, und generiert den passenden JSON-Aufruf. Der Entwicklercode empfängt das JSON, ruft die echte Wetter-API auf und erhält "15 Grad, bewölkt". Dieses Ergebnis wird dem Modell als neue Nachricht übergeben. Das Modell formuliert daraus: "In Berlin sind es gerade 15 Grad bei bewölktem Himmel."

Die eigentliche Stärke zeigt sich beim Verketten: "Plane meinen Tag in Berlin morgen." Das Modell ruft nacheinander get_weather ("12 Grad, leichter Regen"), check_calendar ("Keine Termine") und search_indoor_activities ("Museumsinsel, Philharmonie, ...") auf. Jede Schleifeniteration liefert dem Modell neue Informationen, die seine nächste Entscheidung prägen.

Die KI ist wie ein Geschäftsführer im Eckbüro. Dein Entwicklercode ist der Assistent im Vorzimmer. Der Chef sagt: "Ruf Kunden Müller an und frag nach dem Liefertermin." Der Assistent greift zum Telefon, wählt, bekommt die Antwort "Lieferung am Freitag" und gibt sie weiter. Der Chef wendet sich an den Besucher und sagt: "Müller liefert Freitag." Der Besucher glaubt, der Chef wisse alles — aber der Assistent hat die eigentliche Arbeit erledigt.

Dieser Artikel hat gezeigt, wie Function Calling einem Sprachmodell Handlungsfähigkeit verleiht — von der passiven Textgenerierung zur aktiven Weltinteraktion. Der nächste Artikel im Pfad zeigt, wie APIs und MCP dieses Werkzeug-Ökosystem standardisieren und skalieren.

Interaktiv: So läuft ein Function Call ab

Klicke dich Schritt für Schritt durch einen vollständigen Function-Calling-Ablauf — von der Nutzerfrage über die Werkzeugauswahl bis zur finalen Antwort. Beobachte, wie der Call-Stack bei jedem Schritt wächst und schrumpft.

Im nächsten Artikel erfährst du, wie APIs und das Model Context Protocol (MCP) diese Werkzeug-Infrastruktur standardisieren — damit nicht jeder Entwickler das Rad neu erfinden muss.