Gültiges JSON reicht nicht aus: Strukturierte LLM-Ausgaben auswerten

Aktuelle Studien trennen Formatierung von Bedeutung

Ein Software-Engineering-Preprint vom Juni 2026 unterscheidet Syntax-, Struktur- und Semantikfehler in generierten Ausgaben. Eine Studie vom August 2026 untersucht, wie Schemabeschreibungen das Klassifizierungsverhalten beeinflussen. Beide motivieren dazu, den Inhalt strukturierter Ausgaben und Versionierungsschemata mit Eingabeaufforderungen auszuwerten. Keiner von beiden etabliert ein universelles bestes Schemadesign.

Beweis: Empirische Studie zur strukturierten Ausgabesteuerung in LLMs für Software Engineering [1]Ihre Eingabeaufforderung ist nicht die einzige Eingabeaufforderung: Wie stark gewichten LLMs Schemabeschreibungen mit strukturierter Ausgabe? [2]

Schreiben Sie den Vertrag, den der Verbraucher tatsächlich benötigt

Rubrex empfiehlt, zulässige Typen, erforderliche Felder, Aufzählungen, Nullverhalten und feldübergreifende Regeln zu definieren. Definieren Sie dann, wie Werte in der Eingabe geerdet werden müssen. Ein gültiges Datum ist nicht unbedingt das richtige Datum. Ein zulässiger Statuscode kann dennoch für den Beweis ungeeignet sein.

Geben Sie an, wie fehlende Informationen dargestellt werden sollen. Wenn jedes Feld obligatorisch ist, der Quelle jedoch ein Wert fehlt, kann das Modell unter Druck gesetzt werden, einen Wert zu erfinden. Das Schema und die Anwendung sollten zwischen fehlenden, unbekannten, nicht anwendbaren und Extraktionsfehlern unterscheiden, wenn diese Zustände unterschiedliche Bedeutungen haben.

Kombinieren Sie Validatoren mit semantischen Beweisen

Verwenden Sie einen Parser und Schemavalidator für strukturelle Anforderungen. Fügen Sie nach Möglichkeit deterministische feldübergreifende Prüfungen hinzu, z. B. konsistente Summen oder gültige Bezeichnerbeziehungen. Vergleichen Sie für extrahierte Fakten Werte mit kommentierten Quellenbereichen oder einer anderen zuverlässigen Referenz.

Melden Sie Ergebnisse pro Feld und die Richtigkeit aller Pflichtfelder. Ein Datensatz mit neun korrekten Feldern und einem falschen Zahlungsziel wird nicht sinnvollerweise nur als 90 % genau beschrieben. Behalten Sie die Fehlerschwere und die nachgelagerten Konsequenzen bei der Auslesung bei.

Anschauliches Beispiel: das fehlende Verlängerungsdatum

Ein Vertragsextraktor muss ein Verlängerungsdatum zurückgeben, das Dokument gibt jedoch nur eine Kündigungsfrist an. Das Modell gibt ein plausibles Datum aus, das dem Schema entspricht. Die Strukturschicht verläuft; Die Evidence-Grounding-Schicht versagt.

Überarbeiten Sie den Ausgabevertrag, um gegebenenfalls einen expliziten unbekannten Status zuzulassen, und fügen Sie die für die Überprüfung erforderlichen Quellennachweise hinzu. Testen Sie sowohl Dokumente mit expliziten Verlängerungsdaten als auch Dokumente ohne diese. Ein Fix sollte nicht unterstützte Werte vermeiden, ohne dass extrahierbare Informationen verloren gehen.

Behandeln Sie Eingabeaufforderungs- und Schemaänderungen als eine Release-Oberfläche

Überprüfen Sie die Feldbeschreibungen auf Widersprüche mit Systemanweisungen. Versionieren Sie Schema, Eingabeaufforderung, Modell und Verbraucher gemeinsam. Testen Sie alte und neue Dokumentvorlagen, verschachtelte Objekte, leere Sammlungen und Teilfehler. Eine Schemamigration sollte beinhalten, wie vorhandene Datensätze und nachgelagerter Code neue Zustände interpretieren.

Häufige Fragen