Schema-guided reasoning versus structured outputs voor LLMs

Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Gebruik structured outputs wanneer je programma velden met een gedefinieerde vorm nodig heeft. Voeg schema-guided reasoning (SGR) toe wanneer het programma of een reviewer ook intermediate records nodig heeft, zoals bronbewijs en een voorgestelde beslissing. SGR gebruikt structured output om deze stappen uit te drukken; het is geen afzonderlijke garantie dat het antwoord juist is.

Als de consumer alleen een categorie en een source ID nodig heeft, houd het dan bij die velden. Voeg alleen analysis fields toe als je kunt uitleggen hoe ze worden gecontroleerd of gebruikt.

Laatst gecontroleerd: 2026-09-08.

Wat elke laag doet

LaagWat deze biedtWat deze niet kan vaststellen
JSON formatting promptInstructies om JSON te retournerenDat de response een schema volgt
Schema-constrained outputEen response die het ondersteunde schema volgt wanneer generation succesvol voltooitDat de waarden waar zijn
SGR schemaBenoemde intermediate fields en een voorgestelde beslissingDat het ene veld correct uit het andere is afgeleid
Application checksTests van bronbewijs, berekeningen en toegestane actiesFeiten die de application nooit verifieert

Rinat Abdullins beschrijving van SGR gebruikt schema’s als checklist voor het werk dat het model retourneert. In een self-hosted setup kunnen vLLM structured outputs JSON Schema afdwingen via een decoding backend zoals XGrammar. Alleen een Pydantic-model definiëren in Python schakelt constrained decoding op de server niet in.

Controleer welke subset van het schema de geselecteerde provider ondersteunt en wat de completion status is. Een refusal, truncated response of failed request heeft een eigen error path nodig. De Gemini structured-output guide maakt ook de belangrijkste beperking duidelijk: een correcte JSON-structuur garandeert niet dat de veldwaarden correct zijn.

Een discountvoorstel laat het verschil zien

Stel dat een supporttool maximaal 10% korting mag aanbieden. Een minimale structured reply kan discount_percent en customer_message bevatten. Als een interne reviewer bewijs nodig heeft, kan een SGR-reply ook policy_source_id en eligibility_evidence bevatten.

Die extra velden geven de reviewer iets om te inspecteren. Ze maken een voorgestelde korting van 15% niet geldig. Zelfs een schema dat het percentage beperkt tot 10 kan niet bewijzen dat deze klant hiervoor in aanmerking komt.

Voordat je het aanbod gebruikt, moet application code het toepasselijke beleid en klantrecord laden, de eligibility controleren en het toegestane bedrag berekenen. Behandel de uitleg van het model als een claim die moet worden gecontroleerd. Als een latere modelstap goedgekeurde feiten nodig heeft, valideer die dan voordat je die call uitvoert. De veldvolgorde binnen één JSON-object creëert geen validation step.

Wanneer de extra velden hun plek verdienen

SGR is nuttig wanneer een fout antwoord een preciezere diagnose vereist. Zo kan een documentclassifier een bronpassage en een categorie retourneren. Reviewers kunnen dan onderscheid maken tussen een slechte passagekeuze en een verkeerde categorie bij goed bewijs.

Het is minder nuttig wanneer elk resultaat een lange uitleg krijgt die niemand leest of beoordeelt. Extra output verbruikt tokens, en een overtuigende uitleg kan nog steeds onjuist zijn.

Vergelijk het kleine schema met het SGR-schema op dezelfde gelabelde cases en met hetzelfde model. Beoordeel de final decision afzonderlijk van source support en field validity. Behoud de intermediate fields als ze de beslissing verbeteren of review nuttig genoeg maken om de extra output te rechtvaardigen. Ga niet uit van een accuracy gain op basis van de naam van het schema.

Verder lezen