Strukturierte Ausgaben und Function Calling: Muster für den Produktivbetrieb

Der Übergang vom „LLM-Chatbot“ zum „LLM-gestützten System, das Aufgaben ausführt“ findet auf der Ebene strukturierter Ausgaben und des Function Calling statt. Hier erzeugt das LLM nicht mehr nur Fließtext, sondern liefert Daten, entscheidet über Aktionen und wird in Ihre übrige Infrastruktur integriert.

Im Produktivbetrieb bedeutet „strukturierte Ausgabe“ nicht: „Der JSON-Modus hat in meinem Test einmal funktioniert.“ Gemeint ist eine robuste Pipeline, die Modellvarianz, fehlerhafte Ausgaben, Teilausfälle, Schemaänderungen und die Realität bewältigt, dass LLMs Anweisungen nicht immer befolgen.

Dieser Artikel behandelt Muster, die sich im Produktivbetrieb bewähren. Wir setzen voraus, dass Sie die Grundlagen kennen und beispielsweise OpenAIs tool_choice, Anthropics Tool Use sowie JSON-Schema-Einschränkungen eingesetzt haben. Nun betrachten wir genauer, was solche Systeme zuverlässig macht.

Die beiden Modi

Zwei verwandte, aber unterschiedliche Fähigkeiten:

Strukturierte Ausgabe: Das LLM erzeugt eine Ausgabe, die einem Schema entspricht (meist JSON). Wird verwendet, wenn Sie die Antwort des LLM in einem programmatischen Format benötigen.

Function/Tool Calling: Das LLM erhält eine Reihe aufrufbarer Funktionen. Es entscheidet, welche davon gegebenenfalls aufgerufen wird, und erzeugt die Aufrufparameter. Das Hostsystem führt die Funktion aus und gibt das Ergebnis zurück. Anschließend kann das LLM weitere Funktionen aufrufen oder eine abschließende Antwort erzeugen.

Modell-APIs stellen diese Fähigkeiten üblicherweise folgendermaßen bereit:

• Ein Parameter wie response_format, der für einfache strukturierte Ausgaben ein JSON-Schema entgegennimmt – etwa OpenAIs „Structured Outputs“ oder Google Geminis responseSchema.
• Ein tools-Array zur Beschreibung verfügbarer Funktionen sowie eine Tool-Call-Antwort, wenn eine Funktion aufgerufen wird. Anthropics Tool-Use-API dient zugleich dazu, Ausgaben auf ein Schema zu beschränken: Sie definieren ein einzelnes Tool mit dem gewünschten Schema und erzwingen dessen Aufruf.

Beide Methoden funktionieren und sind miteinander verwandt. Ein „Funktionsaufruf“ ist im Kern eine strukturierte Ausgabe, deren Schema der Funktionssignatur entspricht.

Muster 1: Präzise, explizite Schemata

Der größte Gewinn an Zuverlässigkeit liegt in Ihren Schemata.

Ein lockeres Schema:

{
  "type": "object",
  "properties": {
    "category": { "type": "string" },
    "priority": { "type": "string" }
  }
}

Ein präzises Schema:

{
  "type": "object",
  "properties": {
    "category": {
      "type": "string",
      "enum": ["billing", "technical", "account", "feature_request", "complaint"],
      "description": "The ticket category. Use 'technical' for product bugs and 'account' for login/password issues."
    },
    "priority": {
      "type": "string",
      "enum": ["low", "medium", "high", "urgent"],
      "description": "Use 'urgent' only for outages or business-critical impact. 'high' for blocking issues on important customers. 'medium' for standard impact. 'low' for nice-to-haves."
    }
  },
  "required": ["category", "priority"],
  "additionalProperties": false
}

Das präzise Schema:

• Beschränkt Werte auf bekannte Enum-Werte (keine unkontrollierte Abweichung).
• Enthält Beschreibungen, die als Inline-Prompts dienen (das Modell verwendet sie).
• Definiert Pflichtfelder (keine unvollständigen Antworten).
• Verbietet zusätzliche Felder (keine frei erfundenen Schlüssel).

Im Produktivbetrieb sollte jedes Schemafeld beschrieben, jeder Enum explizit und jedes Pflichtfeld entsprechend markiert sein. Das ist „Schema als Prompt“: Das Schema übernimmt einen Teil des Prompt Engineering.

Muster 2: Constrained Generation

Die großen Anbieter unterstützen inzwischen Constrained Generation: Das Decoding wird so eingeschränkt, dass das Modell ausschließlich gültige Ausgaben erzeugen kann.

• OpenAI: response_format: { type: "json_schema", json_schema: { ..., strict: true } }
• Anthropic: Tools mit strengen Schemata.
• Open Source: outlines, lm-format-enforcer, jsonformer, grammatikbasiertes Decoding von vLLM.

Verwenden Sie diese Funktionen konsequent. Sie beseitigen eine ganze Fehlerklasse: fehlerhaftes JSON, halluzinierte Felder und fehlende Pflichtfelder. Der Performance-Overhead ist vernachlässigbar.

Ist Constrained Generation nicht verfügbar – etwa bei einigen offenen Modellen oder Konfigurationen –, dient Validierung mit erneutem Versuch als Fallback (siehe Muster 4).

Muster 3: Schemaversionierung

Schemata entwickeln sich weiter. Sie fügen Felder hinzu. Sie deaktivieren Felder. Sie ändern Enums.

Eine Schemaänderung ist eine Codeänderung. Sie sollte:

• Versioniert werden. Jedes Schema sollte mit einer Versionsnummer versehen werden.
• Getestet werden. Die Eval-Suite wird vor der Bereitstellung gegen das neue Schema ausgeführt.
• Kommuniziert werden. Nachgelagerte Verbraucher der Ausgabe müssen die Änderung kennen.
• Wo möglich rückwärtskompatibel sein. Neue optionale Felder hinzufügen; keine erforderlichen Felder entfernen.

Ein bewährtes Muster: Speichern Sie Schemata als TypeScript-Typen oder Pydantic-Modelle, versionieren Sie diese in der Versionsverwaltung und generieren Sie daraus JSON Schema. Die Typen dienen sowohl der Modell-API als auch Ihrem Anwendungscode.

class TicketClassificationV2(BaseModel):
    category: Literal["billing", "technical", "account", "feature_request", "complaint"]
    priority: Literal["low", "medium", "high", "urgent"]
    confidence: float = Field(ge=0, le=1, description="Confidence in this classification, 0-1")
    needs_human_review: bool = Field(description="True if any field has low confidence or unusual signal")
    reasoning: str = Field(description="Brief reasoning for the classification, especially for non-obvious cases")

Ein Pydantic-Modell definiert das Schema, validiert die Ausgabe und dient als Typ in Ihrem Python-Code. Eine einzige Quelle der Wahrheit.

Muster 4: Validierung und erneute Versuche

Validieren Sie die Ausgabe auch bei Constrained Generation, bevor Sie sie verwenden:

from pydantic import ValidationError

def call_with_validation(prompt, schema, max_retries=2):
    for attempt in range(max_retries + 1):
        response = llm_call(prompt, response_format=schema)
        try:
            parsed = schema.model_validate_json(response.content)
            return parsed
        except ValidationError as e:
            if attempt < max_retries:
                prompt = build_retry_prompt(prompt, response.content, e)
                continue
            raise

Der Prompt für den erneuten Versuch sollte die ursprünglichen Anweisungen, die vorherige Modellausgabe und eine konkrete Beschreibung des Validierungsfehlers enthalten:

Your previous response had a validation error:
{error message}

Your previous output:
{previous output}

Please correct the issue and produce a valid response.

Erneute Versuche funktionieren überraschend gut – meist genügt einer, um einen Modellfehler zu beheben.

Grenzen: Versuchen Sie es nicht unbegrenzt erneut (höchstens 2–3 Mal). Wiederholen Sie Aufrufe nicht bei Fehlern, die nichts mit der Validierung zu tun haben, etwa Rate Limits oder Inhaltsfiltern. Protokollieren Sie erneute Versuche, um deren Quote zu überwachen; ein Anstieg weist auf Modelldrift oder Promptprobleme hin.

Muster 5: Ergebnisreflexion

Lassen Sie das Modell bei risikoreichen Funktionsaufrufen über Tool-Ergebnisse reflektieren, bevor es diese weiterverwendet.

Eine einfache Schleife:

1. Call LLM with tools available.
2. Model decides to call tool X.
3. Execute X.
4. Pass result back to model.
5. Model produces final response.

Eine Reflexionsschleife:

1. Call LLM with tools available.
2. Model decides to call tool X.
3. Execute X.
4. Pass result back to model.
5. Model evaluates: does this result match what I expected? Should I act on it?
6. If yes, model produces final response. If no, model calls another tool or asks for clarification.

Dies erkennt Fälle wie:

• Tool gibt 0 Ergebnisse zurück, obwohl Daten erwartet wurden → Modell erkennt den leeren Fall.
• Tool gibt einen Fehler zurück → Modell behandelt ihn explizit anstelle ihn zu ignorieren.
• Tool gibt unerwartete Daten zurück → Modell bemerkt und passt sich an.

Umsetzung: Fordern Sie das Modell auf, Tool-Ergebnisse ausdrücklich zu bewerten, beispielsweise über ein strukturiertes Muster „erst bewerten, dann handeln“.

Dies erhöht Latenz und Tokenverbrauch. Bei risikoreichen Aktionen – E-Mails versenden, Zahlungen verarbeiten oder Datensätze ändern – lohnt sich der Aufwand. Bei risikoarmen Informationsabfragen können Sie darauf verzichten.

Muster 6: Idempotenz

LLMs rufen manchmal dieselbe Funktion zweimal auf oder wiederholen Aufrufe, die bereits erfolgreich waren. Ohne Idempotenz entstehen Duplikate: zwei Rückerstattungen, zwei E-Mails, zwei Datensätze.

Muster für Idempotenz:

Idempotenzschlüssel. Jeder Funktionsaufruf erhält einen eindeutigen Schlüssel, der clientseitig erzeugt und in den Aufruf aufgenommen wird. Die nachgelagerte API oder Ihr Tool-Wrapper erkennt damit Duplikate und gibt das vorhandene Ergebnis zurück.

Get-or-create-Semantik. Tools, die Datensätze erstellen, führen zunächst eine Suche aus. „Kunden mit E-Mail X erstellen“ prüft zuerst, ob bereits ein Kunde mit dieser Adresse existiert. Ist dies der Fall, gibt das Tool den vorhandenen Datensatz zurück, statt ein Duplikat anzulegen.

Operationsprotokolle. Tools protokollieren jede Operation. Der Wrapper prüft das Protokoll vor der Ausführung; wurde die Operation bereits ausgeführt, gibt er das zwischengespeicherte Ergebnis zurück.

Konservatives Tooldesign. Tools für folgenreiche Aktionen werden so gestaltet, dass sie eine ausdrückliche Bestätigung oder menschliche Freigabe erfordern. Das LLM darf sie nicht versehentlich in einer engen Schleife auslösen können.

Gestalten Sie jedes Tool mit Nebenwirkungen idempotent. Andernfalls entstehen häufig Fehler im Produktivbetrieb.

Muster 7: Observability für Tool-Aufrufe

Sie müssen nachvollziehen können, was bei Tool-Aufrufen geschieht. Protokollieren Sie für jeden Aufruf:

• Zeitstempel.
• Toolname und Argumente.
• Ergebnis (oder Fehler).
• Dauer.
• Den zugehörigen Nutzer und die zugehörige Sitzung.
• Die Aufrufkette in diesem Durchlauf (war der Tool-Aufruf Teil einer längeren Kette?).

Erstellen Sie Dashboards auf dieser Datenbasis. Typische Ansichten:

• Aufrufvolumen je Tool.
• Fehlerquote pro Tool.
• Durchschnittliche Dauer pro Tool.
• Muster von Funktionsketten (“welche Tools werden häufig zusammen aufgerufen?”).
• Halluzinierte Tool-Aufrufe (das LLM versucht, ein nicht vorhandenes Tool aufzurufen).

Diese Daten zeigen, wo Ihr System fehlschlägt und wo es teuer ist.

Muster 8: Halluzinierte Argumente

LLMs erfinden mitunter Werte für Toolparameter. Sie rufen beispielsweise search_customers(email="...") mit einer E-Mail-Adresse auf, die nicht zur tatsächlichen Nutzerfrage gehört, oder book_meeting(date="...") mit einem Datum, das nie genannt wurde.

Gegenmaßnahmen:

Strenges Schema mit Beschreibungen. „Die user_id muss zuvor in der Konversation erwähnt worden sein. Erfinden Sie keine IDs.“

Validierung im Tool-Wrapper. Ist ein Wert nicht plausibel – etwa weil die user_id nicht existiert oder das Datum in der Vergangenheit liegt –, gibt das Tool einen strukturierten Fehler zurück und das Modell bewertet die Situation neu.

Reflexion. „Bestätigen Sie vor dem Aufruf dieses Tools, dass die verwendeten Werte durch die Konversation belegt sind.“

Eingeschränkte Toolbeschreibungen. Tools, die bestimmte Entitäten bearbeiten, erhalten ausschließlich Entitäts-IDs, die zuvor in der Konversation abgerufen wurden. Stellen Sie keine uneingeschränkte Suche bereit.

Audit-Logs. Erkennen Sie Muster halluzinierter Argumente und passen Sie Prompts oder Schemata entsprechend an.

Muster 9: Kontrollierte Degradation

Tools fallen aus. APIs sind nicht verfügbar. Rate Limits werden erreicht. Die richtige Reaktion besteht selten darin, dem Nutzer lediglich mitzuteilen, dass nichts funktioniert.

Muster:

Zwischengespeicherte oder veraltete Daten. Ist die Live-Datenquelle nicht verfügbar, geben Sie Cache-Daten mit einem klaren Hinweis auf deren möglichen veralteten Stand zurück.

Teilergebnisse. Wenn 3 von 5 Teilaufgaben erfolgreich sind, berichten Sie klar, was erledigt wurde und was nicht.

Fallback-Pfade. Fällt das primäre Tool aus, kennt das Modell eine Alternative. Schlägt beispielsweise search_documents fehl, kann es mit geeigneten Vorbehalten auf search_web ausweichen.

Nutzersichtbare Fehlerzustände. Kann ein Tool den Vorgang tatsächlich nicht abschließen, erzeugt das Modell eine klare Fehlermeldung – niemals eine halluzinierte Erfolgsmeldung.

Das Modell muss über diese Muster informiert sein. Dokumentieren Sie sie im System-Prompt:

If a tool returns an error:
- Try the alternate tool if one exists.
- Report partial results clearly if the user has already provided information.
- Never claim success when a tool returned an error.

Muster 10: Streaming von strukturierten Ausgaben

Für die UX ist das Streaming teilweise vorliegender strukturierter Ausgaben sehr hilfreich: Der Nutzer sieht die Ergebnisse in Echtzeit entstehen, statt bis zum Ende warten zu müssen.

Umsetzung:

• Die meisten modernen Modell-APIs streamen JSON-Ausgabe tokenweise.
• Parsen Sie das unvollständige JSON schrittweise – mit Bibliotheken wie partial-json-parser oder einem kleinen Streaming-Parser.
• Aktualisieren Sie die UI, sobald Felder eintreffen.

Dies funktioniert besonders gut bei Ausgaben mit mehreren Abschnitten. Eine lange Produktbeschreibung, eine Analyse mit mehreren Erkenntnissen oder ein Code-Review mit mehreren Befunden wirkt beim Streaming deutlich reaktionsschneller.

Wichtig: Treffen Sie keine Entscheidungen auf Grundlage unvollständiger Ausgaben. Streamen Sie für die Darstellung, aber warten Sie den Abschluss ab, bevor Sie anhand des strukturierten Ergebnisses handeln.

Muster 11: Function Calling vs. expliziter Entscheidungsaufruf

Natives Function Calling ist bequem: Das Modell „entscheidet“, wann ein Tool aufzurufen ist. Bei einigen Workflows ist ein expliziter Entscheidungsaufruf jedoch zuverlässiger.

Beispiel: Ein Kundensupport-Workflow, bei dem das Modell zwischen mehreren Aktionen entscheiden muss.

Natives Function Calling: Stellen Sie dem Modell 5 Tools bereit (Rückerstattung, Artikel senden, an einen Menschen eskalieren, Rückfrage stellen, Ticket schließen) und lassen Sie es entscheiden.

Expliziter Entscheidungsaufruf: Rufen Sie das Modell zunächst mit einem einzigen Tool namens decide_action auf, dessen Parameter die gewünschte Aktion angibt. Rufen Sie das Modell anschließend auf Grundlage dieser Entscheidung erneut auf – diesmal ausschließlich mit dem relevanten Tool.

Der explizite Ansatz ist langsamer und ausführlicher, aber zuverlässiger. Das Modell konzentriert sich in jedem Schritt auf eine engere Aufgabe, und das Hostsystem behält mehr Kontrolle über den Workflow.

Bei risikoreichen Workflows ist der explizite Ansatz häufig überlegen. Für explorative oder einfache Workflows genügt natives Function Calling.

Muster 12: Formatierung von Tool-Ergebnissen

Wie Sie Tool-Ergebnisse zurückgeben, spielt eine Rolle. Das Modell liest das Ergebnis; das Format ist wichtig.

Schlecht:

{"id": "cus_123", "n": "John", "p": "12345"}

Besser:

{
  "customer_id": "cus_123",
  "name": "John Doe",
  "phone": "+1-555-0123",
  "tier": "premium",
  "open_tickets": 0
}

Am besten (in einigen Fällen):

Customer found:
- ID: cus_123
- Name: John Doe
- Tier: Premium
- Phone: +1-555-0123
- Open tickets: 0

This customer is in the premium tier and has no open tickets.

Das „beste“ Format ist menschenlesbar, enthält Kontext und lässt sich vom Modell bei der anschließenden Generierung leichter nutzen. Das „bessere“ Format ist stärker strukturiert und maschinenlesbar. Testen Sie, welches Format das Modell für Ihre nachgelagerten Aufgaben am zuverlässigsten verarbeitet.

Bei einigen Tools bewährt es sich, sowohl strukturierte als auch beschreibende Ergebnisse zurückzugeben („Hier ist das Ergebnis: [Beschreibung]. Rohdaten: [JSON]“).

Muster 13: Schemabewusste erneute Versuche

Einige Validierungsfehler sind nicht behebbar (das Modell hat die Aufgabe grundlegend missverstanden). Andere sind einfache Korrekturen.

Ein nützliches Muster: Klassifizieren Sie den Fehler und reagieren Sie entsprechend.

def handle_validation_error(error):
    if "missing required field" in str(error):
        return retry_with_message("You omitted required field X. Please include it.")
    elif "value not in enum" in str(error):
        return retry_with_message("Value X is not in the allowed set. Choose from: ...")
    elif "type mismatch" in str(error):
        return retry_with_message("Field X must be a number, not a string.")
    else:
        # Unknown error — single generic retry
        return retry_with_message("There was an error in your response. Please try again.")

Auf den konkreten Fehler zugeschnittene erneute Versuche sind häufiger erfolgreich als generische.

Muster 14: Komponierbarkeit

Tools sollten komponierbar sein. Kleine, fokussierte Tools, die jeweils eine Sache tun, können vom Modell zu komplexen Workflows kombiniert werden.

Ein monolithisches Tool namens process_customer_request(query), das alles erledigt, ist eine Blackbox. Das Modell kann die interne Logik weder beobachten noch steuern.

Eine Gruppe fokussierter Tools – search_customer(email), get_recent_orders(customer_id), check_subscription_status(customer_id), escalate_to_human(reason) – kann das Modell für jede Situation zum passenden Ablauf kombinieren.

Entwerfen Sie Tools mit der richtigen Granularität. Jedes Tool erfüllt genau eine Aufgabe; gemeinsam lassen sie sich zu Workflows kombinieren.

Muster 15: Schema für “Ich weiß es nicht”

Ein subtiles Muster: Modellieren Sie Unsicherheit ausdrücklich im Schema.

class CustomerInfo(BaseModel):
    name: str
    name_confidence: Literal["high", "medium", "low"]
    needs_clarification: bool
    clarification_question: Optional[str] = None

Das Modell kann eine „niedrige Konfidenz“ zusammen mit einer Rückfrage ausgeben, statt fehlende Informationen zu erfinden.

Dies ist wesentlich besser als ein Modell, das Felder stets selbstsicher ausfüllt – mitunter mit erfundenen Daten.

Ein vollständiges Beispiel: Rechnungsverarbeitung

Um die Muster zusammenzuführen, betrachten wir ein produktionsreifes System zur Rechnungsverarbeitung.

Eingaben: PDF-Rechnung, angehängt an eine E-Mail. Ziel: Strukturierte Daten extrahieren, an das Buchhaltungssystem weiterleiten.

Schema:

class LineItem(BaseModel):
    description: str
    quantity: float
    unit_price: float
    total: float
    confidence: Literal["high", "medium", "low"]

class Invoice(BaseModel):
    vendor_name: str
    vendor_id: Optional[str] = None  # null if not found in our records
    invoice_number: str
    invoice_date: date
    due_date: Optional[date] = None
    line_items: List[LineItem]
    subtotal: float
    tax: float
    total: float
    currency: str  # ISO 4217
    confidence: Literal["high", "medium", "low"]
    needs_review: bool
    review_reasons: List[str]  # Specific reasons review is needed

Workflow:

1. OCR-Schritt: Vision-Modell extrahiert Text aus dem PDF.
2. Extraktionsschritt: LLM-Aufruf mit dem obigen Schema und aktivierter Constrained Generation.
3. Validierungsschritt: Pydantic validiert die Ausgabe. Validierungsfehler lösen einen erneuten Versuch mit konkretem Fehlerfeedback aus.
4. Abgleichschritt: Ein Tool-Aufruf sucht den Lieferanten in unseren Datensätzen. Stimmt vendor_name mit einem bekannten Lieferanten überein, wird dessen vendor_id ergänzt. Andernfalls wird needs_review=true gesetzt.
5. Rechenprüfung: Prüfen Sie sum(line_items.total) ≈ subtotal und subtotal + tax ≈ total. Bei Abweichungen wird needs_review=true gesetzt.
6. Konfidenzprüfung: Ist confidence niedrig oder weist eine Position eine niedrige Konfidenz auf, wird needs_review=true gesetzt.
7. Weiterleitung: Bei needs_review=true geht der Vorgang in die menschliche Prüfwarteschlange. Andernfalls wird er an das Buchhaltungssystem weitergeleitet.
8. Protokollierung: Für jeden Schritt werden Eingabe, Ausgabe, Dauer und Fehler protokolliert.

Behandelte Fehlerszenarien:

• Fehlerhaftes JSON: Constrained Generation verhindert es; ein erneuter Versuch deckt Randfälle ab.
• Halluzinierte Felder: Schema ist streng.
• Rechenfehler: werden validiert.
• Unbekannte Lieferanten: werden markiert.
• Niedrige Konfidenz: wird markiert.
• Toolfehler: werden ausdrücklich behandelt.

Leistung im Produktivbetrieb: Rund 95 % der Rechnungen werden ohne manuellen Eingriff verarbeitet; 5 % werden zur Prüfung markiert. Bei den automatisch verarbeiteten Rechnungen liegt die Fehlerquote unter 0,5 % und damit deutlich innerhalb des akzeptablen Bereichs. Von den Fällen in der Prüfwarteschlange werden rund 80 % als korrekt bestätigt; 20 % erfordern Korrekturen.

So sehen produktionsreife strukturierte Ausgaben aus: nicht nur ein einmal erfolgreich ausgeführter JSON-Modus, sondern eine Pipeline, die reale Fehlerszenarien beherrscht.

Häufige Fehler

Einige Muster, die wir häufig sehen:

Fehler 1: Keine Validierung. Ob Pydantic, Zod oder ein anderes Werkzeug: Validieren Sie die Ausgabe. Vertrauen Sie dem Modell nicht ungeprüft.

Fehler 2: Vage Beschreibungen. “category: string” hilft dem Modell nicht. “category: eine von billing, technical, account_access, wobei billing … abdeckt” hilft.

Fehler 3: Zu viele Tools. 30 Tools verfügbar, das Modell wählt die falschen. Kuratieren Sie auf <10 relevante Tools pro Aufruf.

Fehler 4: Kein erneuter Versuch nach einem Validierungsfehler. Eine einzige fehlerhafte Ausgabe beendet den gesamten Ablauf. Versuchen Sie es mit Fehlerfeedback einmal erneut.

Fehler 5: Keine Observability. Schlagen Tool-Aufrufe im Produktivbetrieb fehl, ist ohne Traces keine Diagnose möglich.

Fehler 6: Keine Idempotenz bei Tools mit Nebenwirkungen. Doppelte Rückerstattungen, doppelte E-Mails. Vorhersehbare Fehler.

Fehler 7: Vom LLM gewählte Argumente ungeprüft übernehmen. Halluzinierte Nutzer-IDs und Datumsangaben sind die Folge. Validieren Sie Toolargumente vor der Ausführung.

Fehler 8: Keine Schemaversionierung. Schemaänderungen können nachgelagerte Verbraucher beschädigen. Versionieren Sie das Schema.

Von der Demo zum Produktivsystem

Strukturierte Ausgaben und Function Calling bilden die Brücke vom „LLM, das spricht“ zum „LLM, das Aufgaben ausführt“. Gut umgesetzt ermöglichen sie produktionsreife KI; schlecht umgesetzt führen sie zu ungewöhnlichen und kostspieligen Fehlern.

Entscheidend sind präzise Schemata, Constrained Generation, Validierung mit erneutem Versuch, Reflexion über Tool-Ergebnisse, Idempotenz, kontrollierte Degradation, schemabewusste Fehlerbehandlung und durchgängige Observability.

Jedes dieser Muster unterscheidet eine Demo von einem Produktivsystem. Berücksichtigen Sie sie von Anfang an.