Strukturierte Ausgabe erzwingen

Drei Stufen: bitten, prüfen, erzwingen

Wenn Code die Antwort liest, gibt es genau drei Verlässlichkeitsstufen, und sie werden regelmäßig verwechselt. Bitten heißt, das Format im Prompt zu beschreiben — billig, wirksam, ohne Garantie. Prüfen heißt, die Antwort nach der Generierung gegen ein Schema zu validieren und ungültige zu verwerfen — erkennt jede Verletzung, verhindert keine. Erzwingen heißt, die Generierung selbst so zu beschränken, dass ungültige Ausgaben nicht entstehen können.

Die Reihenfolge in der Pipeline ist keine Leiter, auf der man aufhört, sobald es reicht — die Stufen leisten Verschiedenes und ergänzen sich. Der hervorgehobene letzte Schritt ist der, der in Produktionssystemen am häufigsten fehlt, und er ist derjenige, der die teuersten Fehler fängt.

Wie Schema-Zwang technisch funktioniert

Der Mechanismus ist einfacher, als der Begriff klingen lässt. Ein Sprachmodell wählt bei jedem Schritt das nächste Token aus einer Wahrscheinlichkeitsverteilung über das ganze Vokabular. Bei erzwungener Struktur wird diese Auswahl eingeschränkt: Verfügbar bleiben nur Tokens, die eine gültige Fortsetzung des verlangten Dokuments sein können.

Schema-gebundene Dekodierung — Ein Verfahren, das die Tokenauswahl während der Generierung auf gültige Fortsetzungen beschränkt. Willard und Louf formulieren Textgenerierung dafür als Übergänge zwischen Zuständen eines endlichen Automaten und bauen einen Index über das Vokabular des Modells — der Zustand sagt in jedem Schritt, welche Tokens zulässig sind.

Die praktische Folge: Ein einleitender Satz vor dem JSON ist nicht unwahrscheinlich, sondern unmöglich — das erste Token kann nur { sein. Ein unbekannter Feldname kann nicht entstehen, weil der Automat ihn nicht zulässt. Deshalb ist die Zusage hier von anderer Art als eine Prompt-Formulierung: Sie hängt nicht daran, dass das Modell sich an eine Bitte hält.

Was Zwang garantiert — und was nicht

Hier liegt die wichtigste Abgrenzung des Moduls. Schema-Zwang garantiert, dass die Antwort parsebar und schema-konform ist. Er garantiert nicht, dass die Werte stimmen. Ein Feld service_id mit Schema-Typ String bekommt einen String — auch wenn diese ID in eurem Katalog nie existiert hat.

Fehlerart

Fängt Schema-Zwang das?

Vorspann vor dem JSON, Codeblock-Zäune

Ja — kann nicht entstehen.

Unbekannter oder falsch benannter Feldname

Ja, sofern das Schema die Felder abschließend benennt.

Falscher Typ, etwa Zahl als Zeichenkette

Ja — der Automat lässt nur den zulässigen Typ zu.

Erfundene ID, die dem Format entspricht

Nein. Formal gültig, inhaltlich falsch.

Ein geschätztes Datum, wo keines im Dokument stand

Nein. Ein Datum ist ein Datum.

Die letzten beiden Zeilen sind der Grund, warum Schema-Zwang ein Sicherheitsgefühl erzeugt, das nicht gedeckt ist. Vorher brachen Fehler laut im Parser; nachher fließen sie still durch die Pipeline, weil alles wohlgeformt aussieht. Ein Team, das nach der Einführung von Schema-Zwang die semantische Prüfung streicht, hat seine Fehlerrate nicht gesenkt, sondern seine Fehlersichtbarkeit.

Das Format hat Kosten — und die sind gemessen

Struktur ist nicht gratis, und der Preis ist nicht nur Token-Overhead. Tam und Kollegen haben in einer EMNLP-Arbeit von 2024 systematisch verglichen, wie Modelle abschneiden, wenn sie an strukturierte Formate gebunden sind, gegenüber freier Antwort — über gängige Aufgaben und Formate wie JSON, XML und YAML.

Der Befund: ein deutlicher Rückgang der Reasoning-Leistung unter Formatbeschränkung, und je strenger die Beschränkung, desto größer im Allgemeinen der Verlust. Das ist die unbequeme Nachricht für Pipelines, in denen ein Modell erst überlegen und dann in ein engmaschiges Schema antworten soll: Man bezahlt die Struktur mit einem Teil der Urteilsqualität.

• Für reine Extraktion und Klassifikation ist der Preis klein und die Struktur ihn wert — es gibt kaum Reasoning zu verlieren.
• Für Aufgaben mit echtem Abwägen lohnt es, das Reasoning außerhalb des Schemas laufen zu lassen und nur das Ergebnis strukturiert zu verlangen.
• Für freie Prosa als Produkt ist eine Struktur um den Text herum sinnvoll, eine Struktur im Text meist nicht.

Die Form des Schemas ist eine Entscheidung

Ein Schema wird gern aus dem Datenmodell abgeleitet, das intern schon existiert — tief verschachtelt, mit dreißig Feldern, von denen der Konsument sechs liest. Das ist die Standardquelle für zwei Probleme gleichzeitig: Die Ausgabe wird lang und teuer, und jedes zusätzliche Feld ist eine weitere Stelle, an der ein Wert erfunden werden kann.

Die tragfähige Regel ist unspektakulär: flach halten und auf das reduzieren, was real konsumiert wird. Verschachtelung braucht das Modell nur, wenn die Struktur der Sache verschachtelt ist — eine Liste von Positionen mit je zwei Feldern, nicht ein Objektbaum, der eine Klassenhierarchie abbildet.

Schema-Entscheidung

Wirkung

Nur konsumierte Felder aufnehmen

Weniger Ausgabe-Tokens, weniger Gelegenheiten zur Erfindung.

Flach statt tief verschachteln

Einfacher zu erzwingen, einfacher zu validieren, robuster gegen Teilfehler.

Enums statt Freitext, wo die Menge geschlossen ist

Macht ungültige Werte unmöglich statt unwahrscheinlich.

null als erlaubten Wert ausweisen

Gibt dem Modell einen Ausgang für den leeren Fall statt einer Erfindung.

Ein strenges Schema braucht zwei Angaben

Ein häufiger, stiller Fehler: Ein Schema wird geschrieben, der Zwang wird aktiviert, und trotzdem kommen Antworten mit fehlenden oder zusätzlichen Feldern. Der Grund ist, dass ein Objekt-Schema von sich aus großzügig ist — es beschreibt, welche Felder es geben kann, nicht welche es geben muss und welche verboten sind.

• `required` — welche Felder vorhanden sein müssen. Ohne diese Angabe ist ein leeres Objekt schema-konform.
• `additionalProperties: false` — dass keine weiteren Felder erlaubt sind. Ohne diese Angabe darf das Modell beliebige Felder ergänzen.

Anthropic verlangt für strenge Werkzeug-Parameter (strict: true) genau diese beiden Angaben im Schema. Das ist kein Sonderwunsch der Plattform, sondern die Konsequenz daraus, wie JSON Schema definiert ist: Was nicht ausgeschlossen ist, ist erlaubt. Wer beides vergisst, hat ein Schema, das seinen Vertrag nicht abbildet — und Zwang setzt nur durch, was im Schema steht.

Enums in einer offenen Welt

Ein Enum ist das stärkste Werkzeug in einem Schema: Es macht ungültige Werte unmöglich. Genau daraus entsteht sein Risiko. Ein geschlossenes Enum zwingt bei jedem Fall, der nicht hineinpasst, eine falsche Wahl — das Modell kann nicht „passt nicht“ antworten, wenn dieser Wert nicht existiert.

Bei einer Klassifikation über sechs Kategorien ohne Restklasse heißt das: Die siebte Art von Anfrage, die es in der Realität gibt, landet in einer der sechs, ohne Spur. Nicht als Fehler — als reguläres Ergebnis. Deshalb gehört zu jedem Enum, das eine offene Welt beschreibt, ein ausdrücklicher Ausgang: ein Wert für „keine der genannten“ oder für „nicht entscheidbar“.

Validieren, nicht vertrauen

Die Prüfkette hat drei Stufen, und sie kosten sehr unterschiedlich viel Arbeit. Die ersten beiden sind fast geschenkt, die dritte ist die eigentliche Aufgabe — und die, die fehlt, wenn ein Team von „wir validieren“ spricht.

Stufe

Prüft

Syntaktisch

Lässt sich der Text überhaupt parsen? Eine Zeile Code.

Schematisch

Stimmen Felder, Typen, Pflichtfelder, Wertebereiche? Ein Schema-Validator.

Semantisch

Stimmen die Werte gegen die Welt? Existiert die ID, ist sie aktiv, passt das Datum in den Zeitraum?

Für die semantische Stufe gibt es keine allgemeine Bibliothek, weil sie fachlich ist. Sie besteht aus Abfragen gegen echte Quellen: Existiert dieser Service? Ist dieser Kunde aktiv? Liegt dieser Betrag in einer plausiblen Größenordnung für diesen Vertragstyp? Genau diese Prüfungen sind das, was einen erfundenen aber wohlgeformten Wert stoppt.

Repair-Loops mit Budget

Was passiert, wenn die Prüfung anschlägt? Der naheliegende Weg ist ein Repair-Loop: die Antwort samt Fehlermeldung zurückgeben und um Korrektur bitten. Das funktioniert gut — und wird gefährlich, sobald es keine Grenze hat. Ein systematischer Fehler wird durch Wiederholung nicht behoben; er wird zu einer Schleife, die Latenz und Kosten multipliziert und irgendwann in einen Timeout läuft.

• Harte Obergrenze — zwei, höchstens drei Versuche. Danach ist es kein Ausrutscher mehr.
• Definierter Endzustand — was gilt nach Erschöpfung? Ablehnen mit Grund, Fallback, oder Vorgang zur manuellen Bearbeitung. Nie: leer durchlassen.
• Die Fehlermeldung mitgeben — eine Korrekturbitte ohne Angabe des Verstoßes ist eine Wiederholung, kein Repair.
• Die Repair-Rate messen — sie ist eine der aussagekräftigsten Kennzahlen über die Gesundheit eines Prompts.

Zur Repair-Rate gehört eine Interpretation, sonst ist sie nur eine Zahl. Steigt sie plötzlich, hat sich etwas an einer der Eingangsgrößen geändert — ein Modellwechsel, ein neuer Dokumenttyp, ein geändertes Schema. Bleibt sie dauerhaft auf niedrigem, aber merklichem Niveau, ist meist das Schema zu eng oder eine Fallunterscheidung fehlt: Das Modell scheitert reproduzierbar an derselben Stelle und wird jedes Mal zur Korrektur geschickt. Beide Fälle sind Befunde am Prompt oder am Schema, nicht am Repair-Loop — der macht sie nur sichtbar.

Teilweise gültige Antworten

Sobald eine Ausgabe eine Liste enthält, stellt sich eine Frage, die kein Schema beantwortet: Was gilt, wenn 8 von 10 Einträgen die semantische Prüfung bestehen und 2 nicht? Die Antwort muss vorher festgelegt sein, sonst entscheidet sie derjenige, der den Verarbeitungscode schreibt — meist unbewusst und meist zugunsten der bequemen Variante.

Strategie

Wann sie richtig ist

Alles verwerfen

Wenn die Liste als Ganzes eine Aussage ist — eine Rechnungsaufstellung mit 8 von 10 Positionen ist falsch, nicht unvollständig.

Gültige übernehmen, ungültige markieren

Wenn die Einträge unabhängig sind — 8 zugeordnete Tickets sind 8 zugeordnete Tickets.

Gültige übernehmen, Rest zur Nacharbeit

Wenn Vollständigkeit nötig, aber Teilfortschritt wertvoll ist.

Ganze Liste in den Repair-Loop

Nur mit Budget — und nur, wenn die Fehlermeldung den konkreten Eintrag benennt.

Die stille Fehlentscheidung ist immer dieselbe: die ungültigen Einträge weglassen und den Rest durchlassen, ohne es festzuhalten. Dann verschwinden zwei Positionen aus einer Aufstellung, die Summe stimmt nicht mehr, und niemand kann später sagen, ob sie nie da waren oder unterwegs verworfen wurden.

Wann Struktur die falsche Antwort ist

Zum Abschluss die Gegenrichtung, damit die Empfehlung nicht zur Gewohnheit wird. Struktur lohnt sich dort, wo eine Maschine liest. Wo ein Mensch liest, kostet ein engmaschiges Schema Qualität — und der gemessene Reasoning-Verlust unter Formatzwang ist genau dieser Preis in Zahlen.

Zusammenfassung — gleich im Check

Du kennst jetzt die Stufen und ihre Grenzen: Bitten ist billig und ohne Garantie, Zwang garantiert die Form und nichts über die Werte, Prüfen braucht drei Stufen, von denen nur die semantische einen erfundenen Wert stoppt. Ein strenges Schema braucht required und additionalProperties: false. Ein Enum über einer offenen Welt braucht einen Restwert. Ein Repair-Loop braucht ein Budget und einen definierten Endzustand. Und Formatzwang kostet messbar Urteilsqualität — also bindet man nur, was gebunden werden muss.