Strukturierte Ausgabe und Function Calling

Eine Chat-Antwort ist für Menschen geschrieben. Ihr Code braucht etwas anderes: Felder, die er lesen kann, Werte, die er prüfen kann, und Aktionen, die er ausführen kann. Strukturierte Ausgabe (Structured Output) und Function Calling sind die beiden Techniken, die aus einem Textgenerator einen verlässlichen Teil Ihrer Software machen.

Dies ist Teil 3 von Level 2. Sie lernen, wie Sie mit einem Schema gültiges JSON bekommen, wie Sie prüfen und wiederholen, wie der Ablauf beim Function Calling funktioniert, wie Sie Tool-Beschreibungen schreiben, die ein Modell versteht, und welche Sicherheitsprüfungen um jeden Aufruf gehören. Der Teil baut auf Prompt-Design für Entwickler aus Level 1 auf.

Warum freier Text Ihren Code bricht

Stellen Sie sich ein Support-Tool vor, das eingehende Tickets sortiert. Sie fragen das Modell nach Kategorie und Priorität. Am Montag antwortet es: „Gern! Das sieht nach einem Rechnungsproblem mit hoher Priorität aus.“ Am Dienstag schreibt es: „Kategorie: Rechnung (dringend)“. Ihr Code muss raten, wo die Werte stehen, und früher oder später rät er falsch.

Strukturierte Ausgabe löst das. Das Modell antwortet in einem festen Format, meist JSON, und ein JSON Schema beschreibt dieses Format. JSON Schema ist ein Standard, um festzulegen, welche Felder es gibt, welchen Typ sie haben und welche Werte erlaubt sind (json-schema.org).

Die Form mit einem JSON Schema festlegen

So sieht ein Schema für das Ticket-Beispiel aus:

{
  "type": "object",
  "properties": {
    "category":    { "type": "string", "enum": ["billing", "shipping", "technical", "other"] },
    "priority":    { "type": "string", "enum": ["low", "normal", "high"] },
    "summary":     { "type": "string", "description": "Ein Satz, höchstens 25 Wörter" },
    "needs_human": { "type": "boolean" }
  },
  "required": ["category", "priority", "summary", "needs_human"],
  "additionalProperties": false
}

Vier Details leisten die meiste Arbeit:

• enum beschränkt ein Feld auf feste Werte. „Rechnung (dringend)“ sieht Ihr Code nie wieder.
• required stellt sicher, dass kein Feld fehlt.
• additionalProperties: false verbietet zusätzliche Felder, mit denen Ihr Code nicht rechnet.
• description sagt dem Modell, was ein Feld bedeutet. Das Modell liest sie wie einen Teil des Prompts.

Geben Sie dem Modell immer einen Ausweg, etwa die Kategorie other. Ohne ihn muss das Modell jedes Ticket in eine Kategorie zwängen, auch wenn keine passt.

Es gibt drei Wege, das Modell an das Schema zu binden. Erstens beschreiben Sie das Format im Prompt und fügen ein Beispiel hinzu. Das klappt meistens, aber nicht immer. Zweitens bieten viele APIs einen JSON-Modus, der syntaktisch gültiges JSON garantiert, aber nicht Ihre Felder. Drittens erzwingen manche APIs und Open-Source-Server das vollständige Schema, während das Modell seine Antwort erzeugt. Das heißt oft Constrained Decoding oder einfach Structured Outputs. Nutzen Sie die strengste Option, die Ihr Anbieter unterstützt.

Prüfen, wiederholen, ausweichen

Auch eine Antwort, die zum Schema passt, kann falsch sein. Das Modell kann shipping für ein Rechnungsproblem wählen oder eine Zusammenfassung mit 80 Wörtern schreiben. Ihr Code prüft deshalb jede Antwort in drei Stufen, bevor er sie verwendet:

1. Parsen: Ist es gültiges JSON?
2. Schema: Sind alle Felder da, mit richtigem Typ und erlaubten Werten?
3. Geschäftsregeln: Ergibt es für Ihren Fall Sinn? Eine Erstattung darf zum Beispiel nicht höher sein als der Bestellwert.

Schlägt eine Prüfung fehl, schicken Sie die Fehlermeldung an das Modell zurück und fragen erneut. Begrenzen Sie das auf ein oder zwei Wiederholungen. Klappt es dann immer noch nicht, greift ein Ausweichweg: ein sicherer Standardwert, eine Warteschlange für Menschen oder eine klare Fehlermeldung. Protokollieren Sie jeden Fehlschlag. Eine steigende Fehlerquote ist ein frühes Warnsignal, dass eine Änderung an Prompt oder Modell etwas kaputt gemacht hat.

In Python kann die Schleife so aussehen. call_model(), check_business_rules() und send_to_human_queue() stehen für Ihren eigenen Code. validate() stammt aus dem Paket jsonschema:

import json
from jsonschema import validate, ValidationError

def triage(ticket, messages):
    for attempt in range(3):                      # erster Versuch + 2 Wiederholungen
        raw = call_model(messages, schema=TICKET_SCHEMA)
        try:
            data = json.loads(raw)                # 1. parsen
            validate(data, TICKET_SCHEMA)         # 2. Schema
            check_business_rules(data)            # 3. eigene Regeln, werfen ValueError
            return data
        except (ValueError, ValidationError) as err:
            messages += [
                {"role": "assistant", "content": raw},
                {"role": "user", "content": f"Ungültige Ausgabe: {err}. Antworte nur mit korrigiertem JSON."},
            ]
    return send_to_human_queue(ticket)            # Ausweichweg

Solche Prüfungen sagen Ihnen nur, ob das Format stimmt. Wie oft der Inhalt stimmt, ist eine andere Frage. Die beantworten Sie mit einem Testsatz, wie Teil 4 zeigt: KI-Funktionen mit Evals testen.

So funktioniert Function Calling

Beim Function Calling, auch Tool Calling oder Tool Use genannt, beschreiben Sie dem Modell Funktionen: ihre Namen, was sie tun und welche Parameter sie erwarten. Braucht eine Frage eine davon, antwortet das Modell nicht mit Text. Stattdessen liefert es eine Anfrage wie „rufe get_order_status mit order_id 4711 auf“. Das Modell führt selbst nie etwas aus. Ihr Code entscheidet, ob die Funktion läuft, führt sie aus und schickt das Ergebnis zurück. Dann schreibt das Modell die Antwort.

Eine Tool-Definition sieht in den meisten APIs ähnlich aus. Auch hier beschreibt ein JSON Schema die Parameter:

{
  "name": "get_order_status",
  "description": "Ruft den Versandstatus einer Bestellung ab. Nutzen, wenn der Kunde eine Bestellnummer nennt. Nicht für Erstattungen verwenden.",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string", "description": "Bestellnummer mit 4 bis 10 Ziffern, z. B. \"4711\"" }
    },
    "required": ["order_id"]
  }
}

Manche Fragen brauchen mehrere Aufrufe hintereinander: Bestellung nachschlagen, Lagerbestand prüfen, Antwort entwerfen. Dann führt die Anwendung diesen Ablauf in einer Schleife aus. Diese Schleife ist der Kern eines KI-Agenten, den Level 3 in KI-Agenten bauen: Tools, Schleifen und Gedächtnis behandelt.

Die Schleife müssen Sie nicht selbst programmieren. No-Code-Plattformen für Agenten und Automatisierungen verbinden Modelle für Sie mit Aktionen. Laut den Anbietern bauen Sie einen Agenten oder beschreiben einen Ablauf in Alltagssprache, statt Code zu schreiben:

MindStudioAgenten & Automatisierung · KI ist der KernNo-Code-Plattform zum Bauen eigener KI-Agenten. TurboticAgenten & Automatisierung · KI ist der KernBaut Automatisierungen aus einer Beschreibung in natürlicher Sprache, ohne Code. Devs.aiApp-Bau & Tests · KI ist der KernPlattform, auf der Teams KI-Anwendungen und eigene Agenten mit ihren Daten bauen und betreiben.

Kurzbeschreibungen aus unserem Tool-Vergleich, nach Angaben der Anbieter — nicht von ABXK getestet.

Die Sicherheitsregeln im letzten Abschnitt gelten genauso, egal wer die Schleife schreibt.

Tool-Beschreibungen, die das Modell versteht

Das Modell wählt ein Tool nur anhand von Name, Beschreibung und Parametern. Ihren Code kann es nicht lesen. Jede Beschreibung ist also ein kleiner Prompt und verdient dieselbe Sorgfalt:

Halten Sie die Zahl der Tools klein und ihre Aufgaben klar getrennt. Zwei Tools mit ähnlicher Beschreibung, etwa find_order und search_orders, verwirren das Modell. Verbinden Sie viele Tools über mehrere Anwendungen, helfen offene Standards: Das Model Context Protocol (MCP), 2024 von Anthropic vorgestellt, beschreibt Tools in einem gemeinsamen Format, das viele KI-Anwendungen verstehen.

Nie ohne Prüfung ausführen

Ein Tool-Aufruf des Modells ist ein Vorschlag, kein Befehl. Behandeln Sie ihn wie eine Nutzereingabe. Die Argumente können schlicht falsch sein, und Angreifer können versuchen, sie über Prompt-Injection zu steuern: Anweisungen, die in einer Nutzernachricht oder in einem abgerufenen Dokument versteckt sind. Unser Bereich AI Security erklärt diesen Angriff und die Abwehr. Für Ihren Code ergeben sich fünf Schutzschichten:

Wie viel Kontrolle Sie brauchen, hängt davon ab, was ein Tool bewirken kann. Nutzen Sie diese Tabelle als Ausgangspunkt für Ihre eigenen Regeln: