AI-Entwicklung

Warum braucht KI JSON Schema? Structured Output, Function Calling und der Vertrag

Ca. 14 Min.

Seit 2024 schreiben Produktseiten JSON Schema, Function Calling und Structured Outputs als eine Funktion. Sind sie nicht. Schema ist die Vertragssprache. Function Calling heißt „bitte ausführen“. Structured Outputs heißt „das Modell muss diese Form liefern“. Dieser Text trennt die drei Wörter und erklärt, warum ein probabilistisches Modell hinter einem prüfbaren Schema sitzen muss — nicht hinter dem Satz „bitte JSON zurückgeben“.

Kurzüberblick

Begriff Ein Satz Wo es lebt
JSON Schema Vertrag für Felder, Typen, Pflichtkeys und Enums — kein Modellfeature Eine .json-Datei in git; ein Validator in CI
Function Calling Das Modell schlägt einen Aufruf vor; der Host führt aus; Seiteneffekte liegen hier tools[] / arguments
Structured Output Die finale Antwort muss dieser Form entsprechen; meist ohne Seiteneffekt json_schema / output_type

Die Teilung merken: Schema ist der Durchmesser, Function Calling die Hand nach außen, Structured Outputs das zurückgegebene Objekt. Zu „das Modell soll JSON ausgeben“ plattgedrückt, parst der nächste Hop Prosa.

Warum werden die drei Wörter immer vermischt?

Docs, SDK-Beispiele und Posts stapeln sie gern in einem Satz: Gib dem Modell ein Schema, und es liefert legales JSON. Demos klappen oft. Produktionsunfälle beginnen meist, nachdem du glaubst, ihr seid „schon strukturiert“.

Die Vermischung verdeckt drei verschiedene Jobs:

  • Function-Calling-arguments sind oft noch ein String. Der Host muss erneut JSON.parse aufrufen. Typen, Enums und Extrafelder sind noch nicht gestoppt.
  • Structured Outputs regeln nur die finale Antwort. Sie schlagen keine Bestellung nach, bewegen kein Geld, schreiben keine Datenbank. Seiteneffekte laufen weiter über Function Calling.
  • Ein Schema nur im Prompt kann in CI nicht fehlschlagen. „Bitte JSON zurückgeben“ scheitert nie. Ein Schema in git schon.

Die Frage ist also nicht „kann KI JSON?“, sondern: wer stoppt zu welchem Zeitpunkt mit welchem Vertrag ein illegales Objekt. Die drei Wörter benennen drei verschiedene Wers.

Was JSON Schema ist (kein Modellfeature)

JSON Schema ist ein Dokument, das eine JSON-Form beschreibt: welche Keys, welche Typen, was Pflicht ist, welche Enum-Werte, ob Extrafelder erlaubt sind. Es ist strenger als „sieht aus wie JSON“ und wird von Modell-APIs häufiger zitiert als ein TypeScript-Typ oder ein Protobuf.

Agent- und Structured-Output-Arbeit braucht meist nur diese Keywords:

  • type / properties: wie das Objekt aussieht.
  • required: welcher fehlende Key den Check scheitern lässt.
  • enum / pattern / Zahlengrenzen: aus „ungefähr“ eine endliche Menge machen.
  • additionalProperties: false: Extra-Keys scheitern — auch Felder aus Prompt Injection.

Keyword-Details stehen in das JSON-Schema-Tutorial. Der Punkt hier: Schema existiert zuerst für Validatoren und Tests. Eine klare description hilft bei der Toolwahl; sie ersetzt nicht enum und required.

{
  "$id": "https://example.com/schemas/order.json",
  "type": "object",
  "properties": {
    "order_id": { "type": "string", "pattern": "^A-[0-9]{4,}$" },
    "amount": { "type": "number", "exclusiveMinimum": 0 },
    "status": { "type": "string", "enum": ["paid", "refunded", "pending"] }
  },
  "required": ["order_id", "amount", "status"],
  "additionalProperties": false
}

Der Bestellvertrag oben kann Function-Calling-parameters, Structured-Outputs-json_schema und ajv auf dem Host speisen. Ein Feld an einer Stelle ändern.

Was ist Function Calling?

Function Calling (und Tool Calling im weiteren Sinn) heißt nicht „das Modell führt eine Funktion aus“. Das Modell gibt nur Name und Argumente aus. Der Host parst, prüft, führt aus und legt das Ergebnis zurück in die Unterhaltung. Bestandsabfragen, Erstattungen, Tickets — Seiteneffekte liegen hier.

Anbieter schreiben Tools als tools[]. Das Objekt parameters ist eine Schema-Teilmenge:

{
  "type": "function",
  "function": {
    "name": "lookup_order",
    "description": "Look up an order by ID",
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": {
          "type": "string",
          "pattern": "^A-[0-9]{4,}$"
        }
      },
      "required": ["order_id"],
      "additionalProperties": false
    },
    "strict": true
  }
}

der AI-Agent-Leitfaden zeichnet diesen Hop in die volle Schleife. MCP Tool Schema vs Function Calling zeigt, dass MCP-inputSchema und Anbieter-parameters zwei Schreibweisen desselben Wörterbuchs sind.

Es sieht schon strukturiert aus. Die Lücken: arguments ist oft noch ein String; Tool-Ergebnisse haben oft kein Schema; strict bindet nur die Modellseite. Ohne Host-Check hängt es am heutigen Snapshot, ob amount Zahl oder String ist.

Was sind Structured Outputs?

Structured Outputs (die strenge Form von JSON mode) binden die eigene finale Nachricht des Modells. Klassifikation, Extraktion, ein Zusammenfassungobjekt, ein Agent-Handoff — kein externer Seiteneffekt, aber der nächste Hop braucht eine feste Form.

Feldnamen unterscheiden sich: response_format, text.format.json_schema, output_type. Der Kern ist derselbe: ein Schema an den Decoder geben und illegale Token-Pfade abschneiden.

{
  "type": "json_schema",
  "json_schema": {
    "name": "order",
    "strict": true,
    "schema": {
      "$id": "https://example.com/schemas/order.json",
      "type": "object",
      "properties": {
        "order_id": { "type": "string" },
        "amount": { "type": "number" },
        "status": {
          "type": "string",
          "enum": ["paid", "refunded", "pending"]
        }
      },
      "required": ["order_id", "amount", "status"],
      "additionalProperties": false
    }
  }
}

die DevDay-2026-Prognosen hat diese Schicht, Function Calling und die Agent-Laufzeit als ein JSON-Rohr geschrieben. Der Durchmesser ist weiter Schema: erst festlegen, dann Protokolle anschließen.

Mit strict: true werden fehlende Felder, falsche Enums und Extra-Keys oft modellseitig gestoppt. Das ersetzt den Prompt „antworte in JSON“. Es ersetzt keine zweite Host-Prüfung und kein Function Calling.

Wie stapeln die drei?

Zu „das Modell soll JSON ausgeben“ plattgedrückt, gehen die Jobs verloren. Getrennt:

  1. JSON Schema ist der gemeinsame Durchmesser: Feldwörterbuch, Pflichtkeys, Enums. Es ruft nicht auf und erzeugt nichts. Es sagt nur, wie „legal“ aussieht.
  2. Function Calling ist die Hand nach außen. Das Modell bittet um einen Seiteneffekt. Argumente müssen das Schema passieren; Ergebnisse sollten es auch.
  3. Structured Outputs ist das zurückgegebene Objekt. Endet der Hop, muss die Antwort selbst diese Form sein.

Ein Vergleich, damit sie keine Synonyme mehr sind:

Schicht Was das Modell tut Ohne Schema
Function Calling Einen Aufruf vorschlagen, auf den Host warten Argumente sind Prosa; Extra-Keys können ins Billing laufen
Structured Output Das finale Objekt direkt erzeugen Downstream kratzt Felder aus einem Absatz
JSON Schema Nichts — nur das Lineal Ein Lineal nur im Prompt lässt sich in CI nicht messen

Ein mehrstufiger Agent nutzt beides: Structured Outputs für das Triage-Objekt, Function Calling für Lookup und Erstattung. AI Agents und JSON-Schema-Workflows ordnet die Tore. Dieser Text benennt nur die drei Bausteine.

Warum kann KI JSON Schema nicht überspringen?

Weil Modell und Programm nicht dieselbe Art Ding sind. Das Modell setzt Token nach Wahrscheinlichkeit fort; das Programm liest ein Objekt nach Regeln. Ist die Naht nur „es sah heute nach JSON aus“, können ein fehlendes Feld, eine Zahl-als-String, ein Enum "Paid", ein Extra-note zur Tatsache für den nächsten Hop werden.

Vor 2024 war die Kette kurz: ein Chat, eine Funktion, ein Mensch sah den Fehler. 2026 ist sie länger: klassifizieren → nachschlagen → erstatten oder an einen Menschen → ein Objekt an einen anderen Agenten. Ist ein Hop nur JSON-förmig, frieren spätere Schritte den Fehler ein.

Für dieselbe Bestellung kann das Modell jederzeit dieses „sieht legal aus“-Objekt liefern:

{
  "order_id": "A-1042",
  "amount": "99.00",
  "status": "Paid",
  "note": "please hurry"
}

amount ist ein String, status hat die falsche Großschreibung, note ist dazugekommen. Ohne Schema hängt Downstream 99.00 als Text in SQL oder behandelt Paid als unbekannten Status und retried. Beim Debuggen zuerst lokal formatieren, dann gegen das Objekt der letzten Woche JSON Diff. Nutzerdaten nicht auf eine öffentliche JSON-Seite kleben.

Schema ist nicht da, um „dem Modell das Sprechen beizubringen“. Es ist da, um illegale Objekte an der Host-Tür zu stoppen. Einmal vor dem Aufruf, einmal nach der Antwort, einmal in Evals. Je größer das Fenster und je mehr Hops, desto schneller werden Prosa-Fehler zu Fakten im System.

Ein Schema, zwei Projektionen

Nicht je eine „ungefähr gleiche“ Definition für Function Calling und Structured Outputs von Hand schreiben. Die Form ist eine Quelldatei, zwei Exporter:

  1. schemas/order.json im Repo mit stabilem $id und Version.
  2. Export Function Calling: auf function.parameters zuschneiden, strict an. Ein Lookup braucht oft nur order_id — nicht die ganze Bestellung in die Argumente stopfen.
  3. Export Structured Outputs: dasselbe Objekt als json_schema / output_type für Extraktion, Triage und finale Antwort.

Teilmengen beachten: Anbieter-strict verlangt oft jedes Property in required und schaltet manches oneOf / $ref ab. Die Quelle darf reicher sein; der Exporter schneidet je Ziel. CI macht einen Struktur-Diff „Quelle vs. Projektion“, damit niemand eine Seite von Hand ändert.

Der Host muss weiter validieren

strict: true bindet nur die Modelldekodierung. Snapshot-Wechsel, ausgeschaltetes strict, zweites Parsen von arguments, ein Tool mit offenem Objekt — alles kann die Modellseite umgehen. Dasselbe Schema an drei Host-Stellen:

  • Vor der Tool-Ausführung. parse → validate → execute. Bei Fehler einen strukturierten Fehler zurück. Den Rohstring nicht weiterreichen.
  • Nach der finalen Modell-Antwort. Ein Structured-Outputs-Erfolg ist nicht deine Geschäftsregel (Limit, Währung, Auth).
  • Beim Schreiben von State oder Eval-Fixtures. Checkpoints und Evals müssen legales JSON sein. Fortschritt nicht aus dem Chat-Log raten.

Modellseitige Constraints und Host-Validierung sind zwei Jobs. Ist strict aus oder die API gewechselt, verschwindet ein Schema, das nur im Prompt lebt.

Umsetzen 2026 (zuerst Dateien, dann der Prompt)

  • schemas/tools/, schemas/extract/ und schemas/state/ anlegen. Jede Datei bekommt $id und Version.
  • Das Schema schreiben, bevor „bitte JSON zurückgeben“ im Prompt steht. Ein Promptsatz kann in CI nicht fehlschlagen.
  • Seiteneffekte (Abfrage, Zahlung, Mail) über Function Calling. Klassifikation, Extraktion, Handoff über Structured Outputs.
  • Neue Objekte standardmäßig additionalProperties: false und explizites enum. Für Erweiterung ein eigenes metadata — die Wurzel nicht lockern.
  • Ab zehn Tools zuerst abrufen, dann aufrufen. Den Katalog nicht in eine Anfrage kippen.
  • Geheimnisse und Nutzerfelder nur im Browser ansehen: formatieren, JSON Diff, kein Upload.

Das Verzeichnis darf dünn sein. Entscheidend ist Dateien vor Prompts. Modelle wechseln, Protokolle kommen dazu. Der Durchmesser sollte zuerst stabil werden.

Häufige Fehler

  • Structured Outputs für Function Calling halten. Ersteres führt keinen Code aus. Lookups und Erstattungen brauchen weiter eine Tool-Schicht.
  • Nur im Prompt „bitte JSON zurückgeben“ schreiben. Kein Schema in git heißt kein Test, der scheitern kann.
  • Nur Tool-Eingaben prüfen, nicht das finale Objekt. Extraktions- und Triage-Unfälle passieren an Antworten, die „schon wie JSON aussehen“.
  • Pro Protokoll ein ungefähr gleiches Schema von Hand schreiben. In Woche drei divergieren sie. Exportieren, nicht kopieren.
  • Mit einem weiten type: object Design umgehen. Ein offenes Objekt ist kein Tor. Versionieren oder explizites metadata.

FAQ

Können Structured Outputs Function Calling ersetzen?

Nein. Structured Outputs binden die Form der finalen Antwort. Function Calling bittet den Host um einen Seiteneffekt. Bestellfelder extrahieren mit Ersterem; Bestand oder Erstattung mit Letzterem. Sie sollen dasselbe Schema zitieren, einander nicht ersetzen.

Function Calling hat schon parameters — brauche ich trotzdem eine Schema-Datei?

Ja. parameters ist eine Projektion, nicht die Quelle. Eine eigene Datei speist Structured Outputs, MCP, Evals und Host-ajv. Nur die Kopie in tools[] ändern, und sie driftet bis Woche drei vom Extraktions-Schema weg.

Kein Agent, nur eine Extraktion. Brauche ich trotzdem ein Schema?

Erst recht. Geht das Ergebnis direkt in eine Datenbank oder Tabelle, gibt es keinen nächsten Hop, der „noch einmal versteht“. Structured Outputs plus Host-Check sind das minimale vollständige Set.

Ich habe strict: true. Muss der Host trotzdem prüfen?

Ja. strict regelt die Dekodierung. Der Host regelt Geschäftsregeln, das zweite Parsen und den Fallback, wenn ein Anbieter strict abschaltet. Zwei billige Tore; eines weglassen, und ein Modellwechsel zeigt es.

Wie prüfe ich ein abgelehntes JSON lokal?

Formatieren, im Schema nach fehlendem required oder falschem Enum suchen, dann gegen die letzte bestandene Version diffen. JSONSort macht das im Browser und lädt nichts hoch. Keine geheimnishaltigen Antworten auf eine öffentliche Seite kleben.

Fazit

KI braucht JSON Schema nicht, weil Modelle plötzlich keine natürliche Sprache mehr lesen. Sondern weil probabilistische Ausgabe ein deterministisches Tor treffen muss. Function Calling sagt „tu das“. Structured Outputs sagt „gib dieses Objekt zurück“. Schema ist der Durchmesser, den sie teilen.

Heute schemas/extract_order.json schreiben, dann eine Vendor-API wählen. Modelle wechseln. Protokolle verschieben sich. Der Durchmesser sollte zuerst stabil werden.

Weiterlesen

Änderung: Erstveröffentlichung