Strukturierte Ausgaben erzwingen statt reparieren

TL;DR

Ein Modell zu bitten, JSON zu liefern, erzeugt in einem Teil der Fälle ungültiges JSON — mit einleitendem Satz, fehlender Klammer oder erfundenem Feld. Moderne Inferenzserver können das Format während der Erzeugung erzwingen, sodass ungültige Ausgaben gar nicht erst entstehen. Der Aufwand ist eine Zeile Konfiguration.

Der Reparaturcode, den fast jeder geschrieben hat

Sie kennen ihn vermutlich:

# Die Variante, die man nicht mehr braucht
text = antwort.choices[0].message.content
text = text.strip()
if text.startswith("```"):
    text = text.split("```")[1]
    if text.startswith("json"):
        text = text[4:]
try:
    daten = json.loads(text)
except json.JSONDecodeError:
    # Nachbessern, neu fragen, aufgeben ...
    daten = notfall_parsen(text)

Dieser Code existiert, weil ein Modell, das um JSON gebeten wird, manchmal "Gerne! Hier ist das Ergebnis:" voranstellt, manchmal Code-Zäune setzt, manchmal ein Feld erfindet und manchmal eine Klammer vergisst.

Bei einem interaktiven Assistenten ist das ärgerlich. In einem automatisierten Ablauf, der aus 4.000 Rechnungen Positionen extrahiert, ist es ein Betriebsproblem: Bei 3 Prozent Fehlerquote sind das 120 Fälle, die jemand von Hand nacharbeitet.

Wie das Erzwingen funktioniert

Ein Sprachmodell wählt bei jedem Schritt das nächste Token aus einer Wahrscheinlichkeitsverteilung. Beim eingeschränkten Dekodieren werden vor dieser Auswahl alle Token ausgeschlossen, die zu einer ungültigen Struktur führen würden.

Wenn die Struktur nach einer öffnenden Klammer einen Feldnamen aus dem Schema verlangt, sind alle anderen Token schlicht nicht wählbar. Ungültiges JSON kann dadurch nicht entstehen — es ist nicht unwahrscheinlich, sondern unmöglich.

Lokal mit vLLM

from pydantic import BaseModel, Field
from typing import Literal

class Position(BaseModel):
    artikelnummer: str
    bezeichnung: str
    menge: float
    einzelpreis_eur: float

class Rechnung(BaseModel):
    lieferant: str
    rechnungsnummer: str
    rechnungsdatum: str = Field(pattern=r"^\d{4}-\d{2}-\d{2}$")
    positionen: list[Position]
    waehrung: Literal["EUR", "CHF", "USD"]
    netto_gesamt: float

antwort = client.chat.completions.create(
    model="standard",
    messages=[{"role": "user", "content": f"Extrahiere die Rechnungsdaten:\n\n{text}"}],
    extra_body={"guided_json": Rechnung.model_json_schema()},
    temperature=0,
)

rechnung = Rechnung.model_validate_json(antwort.choices[0].message.content)

Kein Reparaturcode, kein try. Die Antwort entspricht dem Schema, weil sie gar nicht anders entstehen konnte.

Zwei Details, die den Unterschied machen:

Literal["EUR", "CHF", "USD"] erzwingt eine Auswahl. Das Modell kann keine erfundene Währung liefern — und Sie brauchen keine nachgelagerte Prüfung.

Das Muster für das Datum erzwingt das Format. Ohne diese Angabe bekommen Sie mal 2026-08-04, mal 04.08.2026, mal 4. August 2026, und Ihre Weiterverarbeitung stolpert über die Varianten.

Was das Erzwingen nicht leistet

Der wichtige Vorbehalt, der in Anleitungen gern fehlt.

Es garantiert die Struktur, nicht die Richtigkeit. Ein Modell, das den Betrag falsch liest, liefert einen falschen Betrag in gültigem JSON. Sie haben die Parse-Fehler beseitigt und die inhaltlichen Fehler unsichtbarer gemacht — vorher scheiterte die Verarbeitung, jetzt läuft sie mit falschen Daten durch.

Deshalb gehören fachliche Prüfungen dazu, und zwar solche, die das Schema nicht abbilden kann:

# Summenprobe — fängt Lesefehler, die das Schema nicht sieht
summe = sum(p.menge * p.einzelpreis_eur for p in rechnung.positionen)
if abs(summe - rechnung.netto_gesamt) > 0.02:
    zur_pruefung(rechnung, grund=f"Summe {summe:.2f} != {rechnung.netto_gesamt:.2f}")

Diese fünf Zeilen fangen in der Praxis mehr echte Fehler als jede Schemaverschärfung.

Es kostet etwas Geschwindigkeit. Die Einschränkung der Tokenauswahl bei jedem Schritt ist Rechenaufwand. Bei vLLM ist er gering, aber messbar — bei sehr großen Schemata mit vielen verschachtelten Objekten spürbar.

Es kann die Qualität senken, wenn das Schema zu eng ist. Wenn Sie ein Feld erzwingen, das im Dokument gar nicht vorkommt, füllt das Modell es trotzdem — mit etwas Erfundenem. Machen Sie optionale Felder auch im Schema optional.

Bei Cloud-Modellen

Die meisten größeren Anbieter unterstützen inzwischen einen Modus für schemakonforme Ausgaben. Die Bezeichnungen und der genaue Funktionsumfang unterscheiden sich — teils wird das Schema hart erzwungen, teils nur nachdrücklich nahegelegt.

Prüfen Sie für Ihren Anbieter zwei Dinge: ob die Einhaltung garantiert oder nur wahrscheinlich ist, und welche Schema-Merkmale unterstützt werden. Manche Anbieter erlauben keine regulären Ausdrücke als Muster, andere keine tiefe Verschachtelung.

Praktisch heißt das: Behalten Sie den Validierungsschritt auch bei zugesicherter Einhaltung. Er kostet nichts und fängt den Fall ab, dass ein Anbieter das Verhalten ändert.

Wenn Sie beide Wege parallel betreiben — lokal und Cloud —, gehört die Unterscheidung ins Gateway und nicht in die Anwendung. Die Systematik dazu steht im Beitrag zum Modellwechsel über das Gateway.

Häufig gestellte Fragen

Wie bringe ich ein LLM dazu, zuverlässig gültiges JSON zu liefern?

Über eingeschränktes Dekodieren: Der Inferenzserver schließt bei jedem Schritt alle Token aus, die zu einer ungültigen Struktur führen würden. Damit kann ungültiges JSON nicht entstehen. In vLLM aktivieren Sie das mit einer Angabe des Schemas im Aufruf, bei Cloud-Anbietern über den jeweiligen Modus für strukturierte Ausgaben.

Garantiert Schema-Zwang auch inhaltlich richtige Werte?

Nein, und diese Verwechslung ist gefährlich. Erzwungen wird ausschließlich die Struktur — ein falsch gelesener Betrag steht danach als gültige Zahl im gültigen JSON. Vorher scheiterte die Verarbeitung an einem Parse-Fehler, jetzt läuft sie mit falschen Daten durch. Ergänzen Sie deshalb fachliche Prüfungen wie Summenproben.

Kostet erzwungenes JSON Geschwindigkeit?

Etwas. Die Einschränkung der Tokenauswahl bei jedem Erzeugungsschritt ist zusätzlicher Rechenaufwand, bei modernen Inferenzservern aber gering. Spürbar wird es bei sehr großen Schemata mit vielen verschachtelten Objekten — dort lohnt es sich, das Schema auf die tatsächlich benötigten Felder zu reduzieren.

Was passiert, wenn ein erzwungenes Feld im Dokument gar nicht vorkommt?

Das Modell füllt es trotzdem, weil das Schema es verlangt — mit etwas Erfundenem. Machen Sie deshalb Felder, die nicht immer vorhanden sind, auch im Schema optional. Ein zu enges Schema erzeugt Halluzination an genau den Stellen, an denen eine ehrliche Leerstelle die richtige Antwort wäre.

Unterstützen alle Modelle strukturierte Ausgaben?

Die gängigen Inferenzserver für offene Modelle unterstützen eingeschränktes Dekodieren unabhängig vom Modell, weil es auf der Serverseite eingreift. Bei Cloud-Anbietern unterscheidet sich der Funktionsumfang: Manche garantieren die Einhaltung, andere legen sie nur nahe, und nicht alle Schema-Merkmale werden überall unterstützt. Behalten Sie den Validierungsschritt in jedem Fall.

Der nächste Schritt

Suchen Sie in Ihrem Code nach dem Reparaturmuster mit Code-Zaun-Entfernung und try-Block um json.loads. Jede Fundstelle lässt sich durch eine Schema-Angabe im Aufruf ersetzen — und der nachgelagerte Fehlerpfad entfällt. Bei der Umstellung helfen wir gern.