Hoe u gestructureerde LLM-uitvoer draagbaar kunt maken in OpenAI, Anthropic en Gemini

Gestructureerde LLM-uitvoer wordt kwetsbaar wanneer teams de ondersteuning van providers als uitwisselbaar beschouwen. OpenAI, Anthropic en Gemini kunnen allemaal gestructureerde gegevens produceren, maar ze leggen niet hetzelfde contract bloot. Schemasyntaxis, tool-call-enveloppen, striktheidsgaranties, weigeringsgedrag, streaminggedrag en validatiefoutmodi verschillen zo sterk dat een parser die met het ene model werkt stilletjes kan mislukken met een ander model.

De praktische oplossing is om te stoppen met het behandelen van providerspecifieke gestructureerde uitvoerfuncties als het zakelijke contract. Definieer één canoniek uitvoercontract voor elke workflow, compileer dit in het ondersteunde aanvraagformaat van elke provider, valideer elk antwoord aan de hand van het canonieke schema en test elk model voordat het productieverkeer mag bedienen.

Wat is draagbare gestructureerde uitvoer?

Draagbare gestructureerde uitvoer betekent dat de applicatie kan vertrouwen op dezelfde responsvorm op bedrijfsniveau, zelfs als de onderliggende modelaanbieder verandert. Dit betekent niet dat elke provider exact hetzelfde JSON Schema ontvangt. Het betekent ook niet dat validatie aan de providerzijde voldoende is.

Een draagbaar contract bestaat uit vijf lagen:

• Canoniek schema: de provider-neutrale gegevensvorm van de workflow.
• Portabiliteitslinting: controleert of het schema constructies vermijdt die niet worden ondersteund, zwak worden afgedwongen of riskant zijn voor alle providers.
• Providercompilatie: vertaling van het canonieke contract naar OpenAI, Anthropic, Gemini of het eigen gestructureerde uitvoeroppervlak van een andere provider.
• Runtime-validatie: validatie aan de applicatiezijde van het geretourneerde object aan de hand van het canonieke schema.
• Contracttests: herhaalbare tests die bewijzen dat elk model de vereiste velden, opsommingen, weigeringen, afkapping, verkeerd ingedeelde verzoeken en semantische randgevallen verwerkt voordat de productieroutering wordt gewijzigd.

Dit patroon is vooral belangrijk voor een onderneming LLM API waar verschillende teams, tenants of partnerworkflows afhankelijk zijn van voorspelbare outputcontracten.

Feiten: gestructureerde output van aanbieders is niet één standaard

Voordat u de portabiliteitslaag ontwerpt, moet u het gedocumenteerde gedrag van de provider scheiden van de aannames.

OpenAI

OpenAI documenten Gestructureerde uitvoer in tegenstelling tot de JSON-modus. JSON-modus is bedoeld om geldige JSON te garanderen, terwijl gestructureerde uitvoer bedoeld is om overeen te komen met een opgegeven JSON-schema. OpenAI ondersteunt gestructureerde uitvoer via responsopmaak en via functieaanroepen met strikte schema-naleving, maar het gedocumenteerde gedrag omvat model- en versiebeperkingen en een ondersteunde schema-subset. Niet-ondersteunde schema's in de strikte modus kunnen API fouten veroorzaken, en applicaties moeten nog steeds edge cases afhandelen.

Anthropic

Anthropic documenteert Claude toolgebruik als gestructureerde toolaanroepen op basis van door ontwikkelaars geleverde tools met een input_schema. Het model retourneert een blok tool_use en de applicatie voert het gevraagde hulpmiddel uit. Dit lijkt op het aanroepen van een functie, maar is niet hetzelfde contract als een OpenAI response-format JSON schemarespons. In de technische richtlijnen van Anthropic wordt ook opgemerkt dat JSON Schema de structuur, vereiste velden en opsommingen kan definiëren, maar geen gebruikspatronen kan uitdrukken, zoals wanneer optionele parameters moeten worden opgenomen of welke veldcombinaties zakelijk zinvol zijn.

Gemini

Google kan gestructureerde uitvoer worden geconfigureerd voor JSON reacties en dat Gemini de gestructureerde uitvoermodus een subset van de JSON Schema-specificatie ondersteunt. Dat is van belang omdat een schema dat geldig is JSON Het schema kan nog steeds ongeschikt zijn als verzoekschema voor een draagbare provider.

Waarneembaarheid

De semantische conventies van OpenTelemetry GenAI omvatten kenmerken voor provider, aangevraagd model, responsmodel, uitvoertype, eindredenen, tokengebruik, tooldefinities, tooloproepargumenten en gerelateerde GenAI-verzoek- en antwoordvelden. Deze velden kunnen foutopsporing tussen providers ondersteunen wanneer fouten in de gestructureerde uitvoer moeilijk te onderscheiden zijn van problemen met prompts, schema's, modellen of providers.

Stap 1: definieer het canonieke bedrijfsschema

Begin met de zakelijke workflow, niet met de provider API. Een workflow voor ondersteuningstriage, een workflow voor het extraheren van facturen, een goedkeuringsaanbeveling of een op een partner gericht automatiseringseindpunt moeten elk een canoniek schema hebben dat weergeeft wat de applicatie downstream nodig heeft.

Een workflow voor ondersteuningstriage kan bijvoorbeeld deze canonieke vorm gebruiken:

{
  "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
    }
  }
}

Dit schema is het contract dat de rest van de applicatie vertrouwt. Hieruit worden providerspecifieke aanvraagformaten gegenereerd; ze zijn niet de bron van de waarheid.

Gebruik expliciete verplichte velden, begrensde arrays, begrensde tekenreeksen, gesloten enums en additionalProperties: false waar uw validator dit ondersteunt. Vermijd het accepteren van willekeurige geneste objecten, tenzij het stroomafwaartse systeem is ontworpen om willekeurige sleutels te verwerken.

Stap 2: Voeg een Schema Portability Lint toe Stap

Een portabiliteitslinter moet schema's afwijzen die technisch geldig zijn. JSON Schema maar riskant voor gebruik met meerdere modellen. Het doel is niet volledige JSON Schema-expressiviteit. Het doel is een stabiel outputcontract dat kan worden samengevoegd in verschillende provideroppervlakken zonder de applicatiegarantie te verzwakken.

Nuttige pluisjescontroles zijn onder meer:

• Weiger niet-ondersteunde compositiezoekwoorden, tenzij uw compiler er expliciete providertoewijzingen voor heeft.
• Weiger onbeperkte object velden die willekeurige eigenschappen toestaan.
• Vereist opsommingen voor classificatievelden die de routing, facturering, goedkeuringen of de zichtbaarheid van partners bepalen.
• Vereist maxItems voor arrays die worden gebruikt in automatisering of UI-weergave.
• Vereist maxLength voor tekstvelden die databases, wachtrijen of partner-API's invoeren.
• Markeer optionele velden waarvan de afwezigheid de zakelijke betekenis verandert.
• Weiger schema's waarvan de nesting of grootte de bekende providerlimieten in uw mogelijkhedenmatrix overschrijdt.

De linter moet worden uitgevoerd in CI en vóór de schema-implementatie. Wacht niet tot er bij een productieverzoek een providerfout optreedt omdat een schemazoekwoord niet wordt ondersteund.

Stap 3: compileren in providerspecifieke aanvraagformaten

Provider-compilatie vertaalt het canonieke schema naar het API oppervlak dat elk model feitelijk ondersteunt. De compiler moet deterministisch zijn en een versiebeheer hebben. Het zou ook een audittrail moeten achterlaten die laat zien welke canonieke schemaversie welke provider-verzoekpayload heeft geproduceerd.

OpenAI compilatie

Voor OpenAI kan de compiler gestructureerde uitvoer targeten via antwoordopmaak voor extractie- en classificatietaken, of strikte functies die actiegerichte workflows oproepen. De gecompileerde payload moet de ondersteunde subset van het schema en providerspecifieke striktheidsinstellingen bevatten, indien beschikbaar.

Anthropic compilatie

Voor Anthropic zal de compiler de gewenste uitvoer vaak weergeven als een tool met een input_schema. De applicatie verwacht dan een blok voor het gebruik van tools en valideert de toolinvoer aan de hand van het canonieke schema. Dit betekent dat de adapter de antwoordenvelop moet normaliseren, en niet alleen maar JSON.

Gemini compilatie

Voor Gemini moet de compiler zijn gestructureerde JSON antwoordconfiguratie targeten met alleen de ondersteunde schemasubset. Als een canoniek schema beperkingen gebruikt die Gemini niet native worden afgedwongen, moet de compiler deze beperkingen registreren als validatie aan de applicatiezijde.

De adapteruitvoer moet worden genormaliseerd in één intern resultaattype:

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;
};

Deze normalisatie zorgt ervoor dat de downstream-workflowcode niet afhankelijk is van de enveloppen van de provider.

Stap 4: Valideer elke reactie op basis van het canonieke schema

De structuur aan de aanbiederzijde is de eerste verdedigingslinie, niet de uiteindelijke correctheidscontrole. Valideer altijd de geparseerde uitvoer aan de hand van het canonieke schema nadat het model heeft gereageerd.

Runtimevalidatie zou gestructureerde fouten moeten opleveren, zoals:

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

Houd structurele validatie gescheiden van semantische validatie. JSON Schema kan de vorm, vereiste eigenschappen, opsommingen en basistypebeperkingen controleren. Het kan geen bedrijfsregels volledig uitdrukken, zoals geldige statusovergangen, goedkeuringsdrempels, klantspecifiek beleid of onderling afhankelijke veldcombinaties.

Dit is bijvoorbeeld een semantische validatie, geen schemaregel:

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

Plaats deze controles in de applicatiecode, zodat ze de klantconfiguratie, workflowstatus, autorisatiecontext en beleidsversiebeheer kunnen gebruiken.

Stap 5: Gebruik Bounded Repair en vervolgens Fail Closed

Een reparatiepad kan herstellen van kleine uitvoerdefecten, maar kan ook systematische schema- en promptproblemen verbergen. Gebruik één gerichte reparatiepoging inclusief de validatiefout. Als het gerepareerde antwoord nog steeds niet kan worden gevalideerd, kunt u het afsluiten of doorsturen naar beoordeling.

Een praktisch reparatiebeleid ziet er als volgt uit:

• Probeer alleen reparaties uit te voeren voor in aanmerking komende fouttypen, zoals ontbrekende verplichte velden, ongeldige opsommingen of onjuiste opmaak JSON.
• Repareer geen weigeringen van providers, veiligheidsblokkeringen, autorisatiefouten of beleidsgevoelige uitvoer.
• Neem de canonieke schemaversie en validatiefout op in de reparatieprompt.
• Sta maximaal één reparatiepoging toe voor voor de klant zichtbare of actie-triggerende workflows.
• Log het aantal reparaties, het succes van de reparatie, het tokengebruik en de uiteindelijke status.

Voor interne extractietaken met een laag risico kan een tweede reparatiepoging acceptabel zijn als de latentie niet belangrijk is. Voor workflows die betalingen, toegangswijzigingen, reacties van partners API of nalevingsacties activeren, is een fail-closed-beleid meestal veiliger.

Stap 6: Contracttests opstellen voor elk productiemodel

Contracttests bepalen of een model in aanmerking komt voor een workflow. Ze moeten worden uitgevoerd vóór de eerste lancering, vóór modelupgrades en vóór het routeren van beleidswijzigingen.

Test minimaal elk model en elke provideradapter op:

• Geldige uitvoer van een gelukkig pad.
• Ontbrekende verplichte velden.
• Ongeldige opsommingswaarden.
• Extra eigenschappen als het schema gesloten is.
• Te veel array-items.
• Te lange tekenreeksen.
• Weigering of onvermogen om hieraan te voldoen.
• Afgekapte uitvoer.
• Tool-call komt niet overeen of ontbreekt tool-call.
• Structureel geldige maar semantisch verkeerde uitvoer.

Gebruik vijandige aanwijzingen die het model onder druk zetten om het contract te schenden. Vraag het bijvoorbeeld om een ​​extra verklarend veld toe te voegen, een prioriteit buiten de enum terug te geven, of een vereiste booleaanse waarde weg te laten. De test slaagt alleen als de provider plus adapter plus validator de verwachte applicatiestatus opleveren.

Houd voor elke workflow een eenvoudig compatibiliteitsrecord bij:

{
  "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"]
}

Deze mogelijkhedenmatrix hoort thuis in het besturingsvlak, niet in verspreide applicatieconstanten.

Stap 7: Betrouwbaarheid van gestructureerde output van instrumenten

Zonder telemetrie kunnen teams niet vaststellen of fouten het gevolg zijn van incompatibiliteit met providers, modeldrift, schemadefecten, promptdefecten, afkapping of downstream-validators.

Log deze velden voor elk gestructureerd uitvoerverzoek:

• Workflownaam en schemaversie.
• Provider, aangevraagd model en responsmodel.
• Uitvoermodus, zoals antwoordschema, toolaanroep of JSON-modus.
• Validatiestatus en fouttype.
• Reparatietelling en reparatieresultaat.
• Reden en weigeringsstatus voltooien.
• Prompttokens, voltooiingstokens, totale kosten en latentie.
• Adapterversie en compilerversie.

Gebruik deze gegevens om modellen te vergelijken voordat u de route wijzigt. Een goedkoper model is niet goedkoper als het aantal reparatiepogingen, handmatige beoordeling, partner API-fouten of downstream-incidentafhandeling toeneemt.

Afwegingen om expliciet te beslissen

Schema's met de kleinste gemene deler verbeteren de overdraagbaarheid maar verzwakken de beperkingen. Als het verzoekschema van de provider vereenvoudigd moet worden, moet u strengere controles handhaven bij canonieke validatie en semantische validatie.

Provider-specifieke compilatie behoudt de eigen sterke punten, maar voegt onderhoud toe. Dit is meestal de moeite waard voor productieworkflows, maar alleen als compilers een versie hebben en gedekt zijn door contracttests.

Strikte schema's verminderen parserfouten, maar vereisen een beter taakontwerp. Als de taak ondergespecificeerd is, legt striktheid de dubbelzinnigheid eerder bloot. Dat is handig, maar het kan de initiële ontwikkeling vertragen.

Reparatie verbetert de voltooiingspercentages, maar verhoogt de kosten en latentie. Gebonden reparatie is een herstelmechanisme en geen vervanging voor schemaontwerp.

Toolaanroepen en responsformaten JSON bedienen verschillende workflows. Toolaanroepen passen vaak beter bij actiegerichte workflows. Antwoordformaat JSON is eenvoudiger voor extractie, classificatie en samenvatting. Een platform met meerdere modellen kan beide ondersteunen, maar het workflowbeleid moet expliciet zijn.

Voorspellingen: waar de portabiliteit van gestructureerde uitvoer naartoe gaat

De ondersteuning van providers voor gestructureerde uitvoer zal waarschijnlijk blijven verbeteren, maar volledige JSON Schemaportabiliteit tussen modellen mag niet worden aangenomen. Aanbieders hebben verschillende modelarchitecturen, API geschiedenis, gebruikspatronen van tools en veiligheidsgedrag. Zelfs als de schema-ondersteuning sterker wordt, zullen applicaties nog steeds canonieke validatie nodig hebben, omdat zakelijke correctheid van meer dan JSON vorm.

Teams mogen verwachten dat gestructureerde uitvoerrouteringsbeslissingen meer datagestuurd worden. Betrouwbaarheid, reparatiesnelheid, afhandeling van weigeringen, latentie en kosten zijn naast de modelkwaliteit van belang. De operationele vraag zal verschuiven van "ondersteunt dit model JSON?" tot "voldoet dit model aan het contract van deze workflow tegen aanvaardbare kosten en een acceptabel percentage mislukkingen?"

Implementatiechecklist

• Definieer één canoniek schema per workflow.
• Versieschema's en de payloads van providerverzoeken reproduceerbaar houden.
• Voeg CI-linting toe voor niet-ondersteunde of risicovolle schemafuncties.
• Compileer canonieke schema's in providerspecifieke formaten.
• Normaliseer providerenveloppen in één intern resultaattype.
• Valideer elk geparseerd antwoord aan de hand van het canonieke schema.
• Voeg semantische validaties toe voor bedrijfsregels.
• Alleen begrensde reparatiepogingen toestaan.
• Mislukt afgesloten of route voor beoordeling voor workflows met een hoog risico.
• Voer contracttests uit voordat u productiemodellen toevoegt of upgradet.
• Houd een modelcapaciteitsmatrix bij op het besturingsvlak.
• Logboekvalidatie, reparatie, kosten, latentie, provider en modelvelden voor elk verzoek.

Conclusie waar actie op ondernomen kan worden

Gestructureerde uitvoerportabiliteit is een API contractprobleem, geen probleem met de promptopmaak. Het betrouwbare patroon is het definiëren van een canoniek bedrijfsschema, het ophangen ervan voor portabiliteit, het compileren ervan in de eigen interface van elke provider, het valideren van elk antwoord nadat de provider het heeft geretourneerd, en het gebruiken van contracttests om te beslissen welke modellen in aanmerking komen voor productie.

Dit ontwerp voegt wat technisch werk vooraf toe, maar voorkomt de duurdere foutmodus: downstream-systemen gaan uit van een stabiel contract, terwijl modelroutering, providergedrag of schemahandhaving daaronder stilletjes veranderen.

Gerelateerd lezen

• fallback-routering die gestructureerde uitvoercontracten beschermt