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 vastgelegde structuur nodig heeft. Voeg schema-guided reasoning (SGR) toe wanneer het programma of een beoordelaar ook tussenliggende gegevens nodig heeft, zoals bewijs uit bronnen 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 het aanroepende programma alleen een categorie en een bron-ID nodig heeft, houd het dan bij die velden. Voeg alleen analysevelden 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
Prompt voor JSON-opmaakInstructies om JSON te retournerenDat het antwoord een schema volgt
Uitvoer beperkt door een schemaEen antwoord dat het ondersteunde schema volgt wanneer de generatie succesvol wordt voltooidDat de waarden waar zijn
SGR-schemaBenoemde tussenliggende velden en een voorgestelde beslissingDat het ene veld correct uit het andere is afgeleid
ApplicatiecontrolesTests van bewijs uit bronnen, berekeningen en toegestane actiesFeiten die de applicatie nooit verifieert

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

Controleer welke onderdelen van het schema de geselecteerde provider ondersteunt en wat de status van de generatie is. Een weigering, een afgebroken antwoord of een mislukte aanvraag heeft een eigen foutafhandeling nodig. De Gemini-handleiding voor structured outputs maakt ook de belangrijkste beperking duidelijk: een correcte JSON-structuur garandeert niet dat de veldwaarden correct zijn.

Een kortingsvoorstel laat het verschil zien

Stel dat een supporttool maximaal 10% korting mag aanbieden. Een minimaal gestructureerd antwoord kan discount_percent en customer_message bevatten. Als een interne beoordelaar bewijs nodig heeft, kan een SGR-antwoord ook policy_source_id en eligibility_evidence bevatten.

Die extra velden geven de beoordelaar 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 de applicatiecode het toepasselijke beleid en de klantgegevens laden, controleren of de klant in aanmerking komt en het toegestane bedrag berekenen. Behandel de uitleg van het model als een bewering die moet worden gecontroleerd. Als een latere modelstap goedgekeurde feiten nodig heeft, valideer die dan voordat je die aanroep uitvoert. De veldvolgorde binnen één JSON-object creëert geen validatiestap.

Wanneer tussenliggende velden helpen

SGR is nuttig wanneer een fout antwoord een preciezere diagnose vereist. Zo kan een documentclassificator een bronpassage en een categorie retourneren. Beoordelaars 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 gevallen en met hetzelfde model. Beoordeel de uiteindelijke beslissing los van de onderbouwing met bronnen en de geldigheid van de velden. Behoud de tussenliggende velden als ze de beslissing verbeteren of de beoordeling nuttig genoeg maken om de extra output te rechtvaardigen. Ga niet uit van een toename in nauwkeurigheid op basis van de naam van het schema.

Verder lezen