So machen Sie strukturierte LLM-Ausgaben über OpenAI, Anthropic und Gemini portierbar

Strukturierte LLM-Ergebnisse werden fragil, wenn Teams den Anbietersupport als austauschbar betrachten. OpenAI, Anthropic und Gemini können alle strukturierte Daten erzeugen, stellen jedoch nicht denselben Vertrag bereit. Schemasyntax, Tool-Call-Envelopes, Striktheitsgarantien, Ablehnungsverhalten, Streaming-Verhalten und Validierungsfehlermodi unterscheiden sich so stark, dass ein Parser, der mit einem Modell arbeitet, bei einem anderen Modell stillschweigend fehlschlagen kann.

Die praktische Lösung besteht darin, anbieterspezifische strukturierte Ausgabefunktionen nicht mehr als Geschäftsvertrag zu behandeln. Definieren Sie einen kanonischen Ausgabevertrag für jeden Workflow, kompilieren Sie ihn in das von jedem Anbieter unterstützte Anforderungsformat, validieren Sie jede Antwort anhand des kanonischen Schemas und testen Sie jedes Modell, bevor es den Produktionsverkehr bedienen darf.

Was ist eine tragbare strukturierte Ausgabe?

Portable strukturierte Ausgabe bedeutet, dass die Anwendung auf die gleiche Antwortform auf Geschäftsebene zurückgreifen kann, selbst wenn sich der zugrunde liegende Modellanbieter ändert. Dies bedeutet nicht, dass jeder Anbieter genau das gleiche JSON-Schema erhält. Dies bedeutet auch nicht, dass die anbieterseitige Validierung ausreicht.

Ein tragbarer Vertrag besteht aus fünf Ebenen:

• Kanonisches Schema: die anbieterneutrale Datenform des Workflows.
• Portabilitäts-Linting: prüft, ob das Schema Konstrukte vermeidet, die nicht unterstützt, schwach durchgesetzt oder anbieterübergreifend riskant sind.
• Anbieterkompilierung: Übersetzung aus dem kanonischen Vertrag in OpenAI, Anthropic, Gemini oder die native strukturierte Ausgabeoberfläche eines anderen Anbieters.
• Laufzeitvalidierung: Anwendungsseitige Validierung des zurückgegebenen Objekts anhand des kanonischen Schemas.
• Vertragstests: Wiederholbare Tests, die beweisen, dass jedes Modell erforderliche Felder, Aufzählungen, Ablehnungen, Kürzungen, fehlerhafte Anforderungen und semantische Randfälle verarbeitet, bevor sich das Produktionsrouting ändert.

Dieses Muster ist besonders wichtig für ein Unternehmens-LLM API, bei dem mehrere Teams, Mandanten oder Partner-Workflows von vorhersehbaren Ausgabeverträgen abhängen.

Fakten: Die strukturierte Ausgabe von Anbietern ist kein Standard

Bevor Sie die Portabilitätsschicht entwerfen, trennen Sie das dokumentierte Anbieterverhalten von den Annahmen.

OpenAI

OpenAI dokumentiert strukturierte Ausgaben im Unterschied zum JSON-Modus. Der JSON-Modus soll ein gültiges JSON-Schema sicherstellen, während strukturierte Ausgaben einem bereitgestellten JSON-Schema entsprechen sollen. OpenAI unterstützt strukturierte Ausgabe durch Antwortformatierung und durch Funktionsaufrufe mit strikter Schema-Einhaltung, aber das dokumentierte Verhalten umfasst Modell- und Versionseinschränkungen und eine unterstützte Schema-Teilmenge. Nicht unterstützte Schemata im strikten Modus können zu API Fehlern führen und Anwendungen müssen weiterhin Randfälle verarbeiten.

Anthropic

Anthropic dokumentiert die Verwendung von Claude-Tools als strukturierte Toolaufrufe basierend auf vom Entwickler bereitgestellten Tools mit einem input_schema. Das Modell gibt einen tool_use-Block zurück und die Anwendung führt das angeforderte Tool aus. Dies ähnelt einem Funktionsaufruf, ist jedoch nicht derselbe Vertrag wie eine Schemaantwort im OpenAI-Antwortformat JSON. In den technischen Leitlinien von Anthropic wird außerdem darauf hingewiesen, dass das JSON-Schema Struktur, erforderliche Felder und Aufzählungen definieren kann, jedoch keine Verwendungsmuster ausdrücken kann, z. B. wann optionale Parameter enthalten sein sollten oder welche Feldkombinationen geschäftlich sinnvoll sind.

Gemini

Google heißt es, dass die strukturierte Ausgabe für JSON-Antworten konfiguriert werden kann und dass der strukturierte Ausgabemodus Gemini eine Teilmenge der JSON-Schemaspezifikation unterstützt. Das ist wichtig, weil ein gültiges Schema JSON möglicherweise immer noch ungeeignet als Anforderungsschema eines portablen Anbieters ist.

Beobachtbarkeit

Zu den semantischen Konventionen von OpenTelemetry GenAI gehören Attribute für Anbieter, angefordertes Modell, Antwortmodell, Ausgabetyp, Abschlussgründe, Token-Nutzung, Tooldefinitionen, Toolaufrufargumente und zugehörige GenAI-Anfrage- und Antwortfelder. Diese Felder können das anbieterübergreifende Debugging unterstützen, wenn Fehler bei der strukturierten Ausgabe schwer von Eingabeaufforderungs-, Schema-, Modell- oder Anbieterproblemen zu unterscheiden sind.

Schritt 1: Definieren Sie das kanonische Geschäftsschema

Beginnen Sie mit dem Geschäftsworkflow, nicht mit dem Anbieter API. Ein Support-Triage-Workflow, ein Rechnungsextraktions-Workflow, eine Genehmigungsempfehlung oder ein Partner-bezogener Automatisierungsendpunkt sollten jeweils über ein kanonisches Schema verfügen, das darstellt, was die Anwendung nachgelagert benötigt.

Zum Beispiel könnte ein Support-Triage-Workflow diese kanonische Form verwenden:

{
  "type": "object",
  "additionalProperties": false,
  "required": ["category", "priority", "summary", "requires_human_review"],
  "properties": {
    "category": {
      "type": "string",
      "enum": ["billing", "technical", "security", "account", "other"]
    },
    "priority": {
      "type": "string",
      "enum": ["low", "normal", "high", "urgent"]
    },
    "summary": {
      "type": "string",
      "minLength": 1,
      "maxLength": 500
    },
    "requires_human_review": {
      "type": "boolean"
    },
    "customer_risk_signals": {
      "type": "array",
      "items": { "type": "string" },
      "maxItems": 5
    }
  }
}

Dieses Schema ist der Vertrag, dem der Rest der Anwendung vertraut. Daraus werden anbieterspezifische Anfrageformate generiert; Sie sind nicht die Quelle der Wahrheit.

Verwenden Sie explizite erforderliche Felder, begrenzte Arrays, begrenzte Zeichenfolgen, geschlossene Aufzählungen und additionalProperties: false dort, wo Ihr Validator dies unterstützt. Vermeiden Sie die Annahme beliebig verschachtelter Objekte, es sei denn, das Downstream-System ist für die Verarbeitung beliebiger Schlüssel ausgelegt.

Schritt 2: Hinzufügen eines Schema-Portabilitäts-Lint-Schritts

Ein Portabilitäts-Linter sollte Schemata ablehnen, die technisch gültig sind. JSON Schema, aber riskant für die Verwendung mit mehreren Modellen. Das Ziel ist nicht die volle Ausdruckskraft des JSON Schemas. Das Ziel ist ein stabiler Ausgabevertrag, der in mehreren Anbieteroberflächen kompiliert werden kann, ohne die Anwendungsgarantie zu schwächen.

Nützliche Flusenprüfungen umfassen:

• Nicht unterstützte Kompositionsschlüsselwörter ablehnen, es sei denn, Ihr Compiler verfügt über explizite Anbieterzuordnungen für sie.
• Uneingeschränkte object Felder ablehnen, die beliebige Eigenschaften zulassen.
• Erfordern Sie Aufzählungen für Klassifizierungsfelder, die Routing, Abrechnung, Genehmigungen oder den Partnersichtbarkeitsstatus steuern.
• Erforderlich maxItems für Arrays, die in der Automatisierung oder UI-Anzeige verwendet werden.
• Erforderlich maxLength für Textfelder, die in Datenbanken, Warteschlangen oder Partner-APIs eingegeben werden.
• Optionale Felder kennzeichnen, deren Abwesenheit die Geschäftsbedeutung verändert.
• Schemata ablehnen, deren Verschachtelung oder Größe die bekannten Anbietergrenzen in Ihrer Fähigkeitsmatrix überschreitet.

Der Linter sollte in CI und vor der Schemabereitstellung ausgeführt werden. Warten Sie nicht, bis eine Produktionsanforderung auf einen Anbieterfehler stößt, weil ein Schema-Schlüsselwort nicht unterstützt wurde.

Schritt 3: In anbieterspezifische Anforderungsformate kompilieren

Die Anbieterkompilierung übersetzt das kanonische Schema in die API Oberfläche, die jedes Modell tatsächlich unterstützt. Der Compiler sollte deterministisch und versioniert sein. Es sollte auch einen Prüfpfad hinterlassen, der zeigt, welche kanonische Schemaversion welche Anbieteranforderungsnutzlast erzeugt hat.

OpenAI Zusammenstellung

Für OpenAI kann der Compiler durch Antwortformatierung für Extraktions- und Klassifizierungsaufgaben oder durch strikten Funktionsaufruf für aktionsorientierte Workflows auf strukturierte Ausgaben abzielen. Die kompilierte Nutzlast sollte die unterstützte Teilmenge des Schemas und die anbieterspezifischen Strenge-Einstellungen enthalten, sofern verfügbar.

Anthropic Zusammenstellung

Für Anthropic stellt der Compiler die gewünschte Ausgabe häufig als Tool mit einem input_schema dar. Die Anwendung erwartet dann einen Tool-Use-Block und validiert die Tool-Eingabe anhand des kanonischen Schemas. Das bedeutet, dass der Adapter den Antwortumschlag normalisieren und nicht nur JSON.

Gemini Zusammenstellung

Für Gemini sollte der Compiler seine strukturierte Antwortkonfiguration JSON nur mit der unterstützten Schema-Teilmenge als Ziel verwenden. Wenn ein kanonisches Schema Einschränkungen verwendet, die Gemini nicht nativ erzwingt, sollte der Compiler diese Einschränkungen so aufzeichnen, dass sie eine anwendungsseitige Validierung erfordern.

Die Adapterausgabe sollte in einen internen Ergebnistyp normalisiert werden:

type StructuredResult = {
  provider: "openai" | "anthropic" | "gemini";
  model: string;
  schema_version: string;
  status: "ok" | "refusal" | "truncated" | "provider_error" | "invalid";
  raw_response: unknown;
  parsed_output?: unknown;
  finish_reason?: string;
};

Diese Normalisierung verhindert, dass nachgelagerter Workflow-Code von Anbieterumschlägen abhängig ist.

Schritt 4: Validieren Sie jede Antwort anhand des kanonischen Schemas

Die anbieterseitige Struktur ist die erste Verteidigungslinie, nicht die endgültige Richtigkeitsprüfung. Validieren Sie die geparste Ausgabe immer anhand des kanonischen Schemas, nachdem das Modell antwortet.

Die Laufzeitvalidierung sollte strukturierte Fehler erzeugen wie:

• missing_required_field
• invalid_enum
• unexpected_property
• type_mismatch
• array_too_long
• string_too_long
• semantic_rule_failed

Halten Sie die strukturelle Validierung von der semantischen Validierung getrennt. JSON Schema kann Form, erforderliche Eigenschaften, Aufzählungen und grundlegende Typeinschränkungen überprüfen. Geschäftsregeln wie gültige Statusübergänge, Genehmigungsschwellenwerte, kundenspezifische Richtlinien oder voneinander abhängige Feldkombinationen können nicht vollständig ausgedrückt werden.

Dies ist beispielsweise ein semantischer Validator, keine Schemaregel:

if (output.priority === "urgent" && output.requires_human_review !== true) {
  throw new SemanticValidationError(
    "urgent tickets must require human review"
  );
}

Fügen Sie diese Prüfungen in den Anwendungscode ein, wo sie Kundenkonfiguration, Workflow-Status, Autorisierungskontext und Richtlinienversionierung verwenden können.

Schritt 5: Begrenzte Reparatur verwenden, dann „Fail Closed“

Ein Reparaturpfad kann kleine Ausgabefehler beheben, aber auch systematische Schema- und Eingabeaufforderungsprobleme verbergen. Nutzen Sie einen gezielten Reparaturversuch inklusive Validierungsfehler. Wenn die reparierte Antwort die Validierung immer noch nicht besteht, schließen Sie sie nicht oder leiten Sie sie zur Überprüfung weiter.

Eine praktische Reparaturrichtlinie sieht so aus:

• Versuchen Sie die Reparatur nur bei geeigneten Fehlertypen, z. B. fehlenden Pflichtfeldern, ungültigen Aufzählungen oder fehlerhaften JSON.
• Reparieren Sie keine Provider-Ablehnungen, Sicherheitsblockaden, Autorisierungsfehler oder richtliniensensible Ausgaben.
• Fügen Sie die kanonische Schemaversion und den Validierungsfehler in die Reparaturaufforderung ein.
• Erlauben Sie höchstens einen Reparaturversuch für für den Kunden sichtbare oder aktionsauslösende Workflows.
• Reparaturanzahl, Reparaturerfolg, Token-Nutzung und Endstatus protokollieren.

Bei internen Extraktionsjobs mit geringem Risiko kann ein zweiter Reparaturversuch akzeptabel sein, wenn die Latenz keine Rolle spielt. Für Workflows, die Zahlungen, Zugriffsänderungen, Antworten von Partnern API oder Compliance-Aktionen auslösen, ist eine Fail-Closed-Richtlinie normalerweise sicherer.

Schritt 6: Erstellen Sie Vertragstests für jedes Produktionsmodell

Vertragstests entscheiden darüber, ob ein Modell für einen Workflow geeignet ist. Sie sollten vor dem ersten Start, vor Modellaktualisierungen und vor Routing-Richtlinienänderungen ausgeführt werden.

Testen Sie mindestens jedes Modell und jeden Anbieteradapter auf Folgendes:

• Gültige Happy-Path-Ausgabe.
• Erforderliche Felder fehlen.
• Ungültige Enum-Werte.
• Zusätzliche Eigenschaften, wenn das Schema geschlossen ist.
• Zu viele Array-Elemente.
• Überlange Zeichenfolgen.
• Verweigerung oder Unfähigkeit zur Einhaltung.
• Abgeschnittene Ausgabe.
• Tool-Aufruf stimmt nicht überein oder fehlender Tool-Aufruf.
• Strukturell gültige, aber semantisch falsche Ausgabe.

Verwenden Sie kontroverse Aufforderungen, die das Modell unter Druck setzen, gegen den Vertrag zu verstoßen. Bitten Sie es beispielsweise, ein zusätzliches erklärendes Feld hinzuzufügen, eine Priorität außerhalb der Aufzählung zurückzugeben oder einen erforderlichen booleschen Wert wegzulassen. Der Test besteht nur dann, wenn der Anbieter plus Adapter plus Validator den erwarteten Anwendungsstatus erzeugen.

Behalten Sie für jeden Workflow einen einfachen Kompatibilitätseintrag bei:

{
  "workflow": "support_triage",
  "schema_version": "2026-09-24",
  "model": "provider-model-name",
  "supports_strict_schema": true,
  "supports_tool_calling": true,
  "supports_streaming_structured_output": false,
  "refusal_signal_normalized": true,
  "contract_tests_passed": true,
  "known_limitations": ["max schema depth 4"]
}

Diese Fähigkeitsmatrix gehört in die Steuerungsebene, nicht in verstreute Anwendungskonstanten.

Schritt 7: Zuverlässigkeit der strukturierten Ausgabe des Instruments

Ohne Telemetrie können Teams nicht sagen, ob Fehler auf Anbieterinkompatibilität, Modellabweichung, Schemafehler, Eingabeaufforderungsfehler, Kürzung oder nachgelagerte Validatoren zurückzuführen sind.

Protokollieren Sie diese Felder für jede strukturierte Ausgabeanforderung:

• Workflow-Name und Schemaversion.
• Anbieter, angefordertes Modell und Antwortmodell.
• Ausgabemodus, z. B. Antwortschema, Toolaufruf oder JSON Modus.
• Validierungsstatus und Fehlertyp.
• Reparaturanzahl und Reparaturergebnis.
• Grund und Ablehnungsstatus beenden.
• Prompt-Tokens, Abschluss-Tokens, Gesamtkosten und Latenz.
• Adapterversion und Compilerversion.

Verwenden Sie diese Daten, um Modelle zu vergleichen, bevor Sie das Routing ändern. Ein günstigeres Modell ist nicht billiger, wenn dadurch Reparaturversuche, manuelle Überprüfungen, Ausfälle von Partner API oder nachgelagerte Vorfallbearbeitung erhöht werden.

Kompromisse zur expliziten Entscheidung

Schemas mit dem kleinsten gemeinsamen Nenner verbessern die Portabilität, schwächen jedoch Einschränkungen. Wenn das Anbieteranforderungsschema vereinfacht werden muss, behalten Sie strengere Prüfungen in der kanonischen Validierung und semantischen Validatoren bei.

Anbieterspezifische Kompilierung bewahrt native Stärken, fügt aber Wartung hinzu. Dies lohnt sich normalerweise für Produktionsworkflows, aber nur, wenn Compiler versioniert und durch Vertragstests abgedeckt sind.

Strikte Schemata reduzieren Parserfehler, erfordern jedoch ein besseres Aufgabendesign. Wenn die Aufgabe nicht spezifiziert ist, wird die Mehrdeutigkeit durch die Striktheit früher aufgedeckt. Das ist nützlich, kann aber die anfängliche Entwicklung verlangsamen.

Reparatur verbessert die Abschlussraten, erhöht jedoch die Kosten und die Latenz. Die begrenzte Reparatur ist ein Wiederherstellungsmechanismus und kein Ersatz für das Schemadesign.

Tool-Aufrufe und Antwortformate JSON dienen unterschiedlichen Arbeitsabläufen. Tool-Aufrufe eignen sich oft besser für aktionsorientierte Arbeitsabläufe. Das Antwortformat JSON ist einfacher für die Extraktion, Klassifizierung und Zusammenfassung. Eine Plattform mit mehreren Modellen kann beides unterstützen, aber die Workflow-Richtlinie muss explizit sein.

Vorhersagen: Wohin die strukturierte Ausgabeportabilität führt

Die Anbieterunterstützung für strukturierte Ausgaben wird sich wahrscheinlich weiter verbessern, eine vollständige JSON Schema-Portabilität über Modelle hinweg sollte jedoch nicht angenommen werden. Anbieter haben unterschiedliche Modellarchitekturen, API-Verläufe, Werkzeugnutzungsmuster und Sicherheitsverhalten. Auch wenn die Schemaunterstützung stärker wird, benötigen Anwendungen weiterhin eine kanonische Validierung, da die geschäftliche Korrektheit von mehr als JSON der Form abhängt.

Teams sollten damit rechnen, dass Entscheidungen zur strukturierten Ausgabeweiterleitung stärker datengesteuert werden. Neben der Modellqualität spielen auch Zuverlässigkeit, Reparaturrate, Ablehnungsbehandlung, Latenz und Kosten eine Rolle. Die operative Frage verschiebt sich von „Unterstützt dieses Modell JSON?“ zu „Erfüllt dieses Modell den Vertrag dieses Workflows zu akzeptablen Kosten und einer akzeptablen Fehlerrate?“

Implementierungs-Checkliste

• Definieren Sie ein kanonisches Schema pro Workflow.
• Versionieren Sie Schemata und sorgen Sie dafür, dass die Payloads von Anbieteranfragen reproduzierbar bleiben.
• CI-Linting für nicht unterstützte oder riskante Schemafunktionen hinzufügen.
• Kompilieren Sie kanonische Schemata in anbieterspezifische Formate.
• Anbieterumschläge in einen internen Ergebnistyp normalisieren.
• Validieren Sie jede analysierte Antwort anhand des kanonischen Schemas.
• Semantische Validatoren für Geschäftsregeln hinzufügen.
• Nur begrenzte Reparaturversuche zulassen.
• Fehler geschlossen oder Weiterleitung zur Überprüfung für Hochrisiko-Workflows.
• Führen Sie Vertragstests durch, bevor Sie Produktionsmodelle hinzufügen oder aktualisieren.
• Pflege einer Modellfähigkeitsmatrix in der Steuerungsebene.
• Log-Validierung, Reparatur, Kosten, Latenz, Anbieter und Modellfelder für jede Anfrage.

Umsetzbare Schlussfolgerung

Strukturierte Ausgabeportabilität ist ein API Vertragsproblem, kein Problem bei der Formatierung von Eingabeaufforderungen. Das zuverlässige Muster besteht darin, ein kanonisches Geschäftsschema zu definieren, es für die Portabilität zu linten, es in die native Oberfläche jedes Anbieters zu kompilieren, jede Antwort zu validieren, nachdem der Anbieter sie zurückgegeben hat, und Vertragstests zu verwenden, um zu entscheiden, welche Modelle für die Produktion geeignet sind.

Dieses Design erfordert einige technische Vorabarbeiten, verhindert aber den teureren Fehlermodus: Downstream-Systeme gehen von einem stabilen Vertrag aus, während sich unter ihnen Modellrouting, Anbieterverhalten oder Schemadurchsetzung stillschweigend ändern.

Verwandte Lektüre

• Fallback-Routing, das strukturierte Ausgabeverträge schützt