Korrektur, Oktober 2026: Eine frühere Version dieses Artikels nannte Zahlen aus einem angeblichen Vergleich von sechs Modellen und verwies auf einen Testaufbau, den ich weder bereitstellen noch verifizieren kann. Diese Zahlen und die daraus abgeleiteten Empfehlungen sind zurückgezogen. Die neue Fassung zeigt ein ausführbares Beispiel und trennt Schema-Konformität von inhaltlicher Richtigkeit.

Wenn ein Agent seine Ausgabe an Programmcode übergibt, ist gültiges JSON wichtig. Doch strukturierte Ausgabe beantwortet nicht nur eine Frage, sondern drei: Lassen sich die Bytes parsen? Erfüllen die Felder den Vertrag? Und sind die Werte durch den Eingabetext gedeckt? Ein Modell kann die ersten beiden Bedingungen erfüllen und bei der dritten scheitern.

Zuerst der Datenvertrag

Ein Programm soll aus einem kurzen Bericht die Priorität, die Anzahl betroffener Personen und eine Zusammenfassung extrahieren. Das folgende Beispiel verwendet Pydantic 2; zum Ausprobieren genügt python -m pip install 'pydantic>=2,<3':

from typing import Literal
from pydantic import BaseModel, ConfigDict, Field, ValidationError

class Extraction(BaseModel):
    model_config = ConfigDict(strict=True, extra="forbid")
    priority: Literal["low", "medium", "high"]
    affected_users: int = Field(ge=0)
    summary: str

source = "The report says no users were affected. Priority is low."
shape_valid_but_wrong = (
    '{"priority":"low","affected_users":12,'
    '"summary":"No users were affected."}'
)
record = Extraction.model_validate_json(shape_valid_but_wrong)
print(record.affected_users)              # 12: das Schema akzeptiert den Wert
print(record.affected_users == 0)         # False: der Bericht sagt etwas anderes

try:
    Extraction.model_validate_json(
        '{"priority":"low","affected_users":"twelve",'
        '"summary":"No users were affected."}'
    )
except ValidationError:
    print("Type validation rejected the string count")

Das erste Objekt hat die geforderten Felder und Typen. Trotzdem widerspricht 12 dem Bericht. Pydantic erfüllt seine Aufgabe: Es prüft den definierten Vertrag, nicht die Belege. Das zweite Objekt wird abgelehnt, weil die Anzahl als Zeichenkette übergeben wird. Mit extra="forbid" scheitern auch unerwartete Felder. Die Dokumentation zum strikten Modus erklärt, warum die Standardregeln zur Typumwandlung wichtig sind.

Der Code ist eine Illustration, kein Modell-Benchmark. Es wird hier kein Sprachmodell ausgeführt.

Was die Grammatik leistet

Bei beschränkter Generierung lässt ein Decoder nur Tokens zu, die zu einer Grammatik oder einem Schema passen. Outlines beschreibt JSON-Schema-Ausgabetypen; llama.cpp dokumentiert seine Grammatiken. Das hilft, wenn nachgelagerter Code eine feste Form erwartet. Es beweist aber nicht, dass eine Zahl im Quelltext steht, eine Zusammenfassung treu ist oder eine Priorität begründet wurde.

Ein Prompt mit der Bitte „antworte als JSON“ ist außerdem nicht dasselbe wie eine Decoder-Beschränkung. Der Prompt ist eine Aufforderung; die Grammatik begrenzt die möglichen nächsten Tokens. Ein Test muss angeben, welche Methode verwendet wurde. Die fertige Ausgabe sollte am Übergang zur Anwendung erneut validiert werden.

Was ein echter Modellvergleich bräuchte

Für einen nachvollziehbaren Vergleich gehören Eingaben, erwartete Antworten, Schema, exakte Modelldateien und Quantisierungen, Inferenz-Engine und Version, Decoding-Einstellungen, Validierungscode und Roh-Ausgaben dazu. Ebenso die Anzahl Versuche und Regeln für mehrdeutige Antworten. Unterscheidet mindestens diese Fehler:

  1. Parse-Fehler: Die Ausgabe ist kein gültiges JSON.
  2. Vertragsfehler: Sie ist parsebar, verletzt aber Felder, Typen, Wertebereiche oder erlaubte Werte.
  3. Belegfehler: Sie erfüllt das Schema, enthält aber eine unbelegte oder widersprochene Aussage.
  4. Betriebsfehler: Die Anfrage läuft in einen Timeout, wird abgeschnitten oder endet vor einer vollständigen Antwort.

Eine Erfolgsquote beim ersten Versuch ist nur sinnvoll, wenn Zähler, Nenner und Fehlerdefinition offenliegen. Schema-Konformität und korrekte Extraktion sind verschiedene Metriken. Wenn eine Grammatik Syntaxfehler verhindert, muss die Bewertung umso genauer auf die inhaltlichen Belege schauen.

Für die Praxis

Definiert ein kleines Schema, begrenzt die Generierung, sofern das gewählte Backend es unterstützt, und validiert am Übergang zur Anwendung erneut. Prüft folgenreiche Felder anhand der Quelle oder eines vertrauenswürdigen Systems. Macht Fehler sichtbar und entscheidet je nach Risiko über Wiederholung oder Eskalation. „Wohlgeformt“ ist nicht gleich „wahr“.

Ohne reproduzierbaren Vergleich empfehle ich für diesen Zweck kein bestimmtes lokales Modell. Die belastbare Erkenntnis ist enger: Struktur ist eine Eigenschaft des Ausgabe-Vertrags; Korrektheit ist eine Aussage über die Welt. Testet beides.