Was führt dazu, dass die Ausgabe eines lokalen LLM ein gültiges JSON-Schema verletzt?

Die Ausgabe eines lokalen LLM verletzt ein gültiges JSON-Schema, wenn Generierung, Constraint-Verarbeitung, Abbruchregeln und Validierung nicht denselben Vertrag durchsetzen.

Ein selbst gehosteter Workflow kann ein standardkonformes Schema für Dateimetadaten, Smart-Home-Aktionen, Dokumentextraktion oder Tool-Argumente bereitstellen und trotzdem eine fehlerhafte oder abgelehnte Ausgabe erhalten. „Gültiges Schema“ beschreibt das Schema-Dokument, nicht den gesamten Ausführungspfad. Das Modell muss die Aufgabe verstehen, der Decoder die relevanten Schemafunktionen unterstützen, die Generierung muss vor dem Abbruch vollständig abgeschlossen sein, der Parser muss einen vollständigen JSON-Wert wiederherstellen, und der Anwendungsvalidator muss die erwarteten Draft- und Umwandlungsregeln anwenden.

Gültiges JSON und schema-konformes JSON sind unterschiedliche Ergebnisse

Ein Objekt kann erfolgreich geparst werden und trotzdem erforderliche Felder, Typen, Enumerationswerte, Array-Begrenzungen oder bedingte Zweige verletzen. Es kann auch korrekte Feldnamen enthalten und dennoch Eigenschaften hinzufügen, die das Schema verbietet.

Das JSON-Modul von Python definiert die Syntaxebene zum Dekodieren eines JSON-Dokuments, aber das Parsen wendet keinen separaten JSON-Schema-Vertrag an.

Diese Ursache ist erkennbar, wenn die Ausgabe ohne Syntaxfehler geladen wird, aber erst nach der Schema-Validierung fehlschlägt. Eine fehlende geschweifte Klammer oder eine nachfolgende Erklärung ist ein Serialisierungsfehler; eine Zeichenkette, obwohl eine Ganzzahl erforderlich ist, ist ein Vertragsfehler.

Schema-Komposition kann schwer erfüllbare Zweige erzeugen

Schlüsselwörter wie allOf, anyOf, oneOf und not kombinieren Einschränkungen. Ein Zweig kann für sich gültig sein, während das kombinierte Objekt keine oder mehrere der erlaubten Alternativen erfüllt.

Die Anleitung zu JSON Schema erklärt, wie Schlüsselwörter zur Schema-Komposition beeinflussen, ob ein oder mehrere Unterschemata übereinstimmen müssen.

Ein lokales Modell verarbeitet eine flache Liste von Eigenschaften oft zuverlässiger als verschachtelte bedingte Logik. Wenn sich Fehler bei Vereinigungen oder sich gegenseitig ausschließenden Objektformen häufen, liegt die Hauptbelastung eher bei der Auswahl des Zweigs als bei der grundlegenden JSON-Syntax.

Der Constraint-Decoder unterstützt möglicherweise nur einen Teil des Schemas

Engines für strukturierte Ausgaben übersetzen Schemata in Token-Einschränkungen, Grammatiken, reguläre Ausdrücke oder backend-spezifische Regeln. Nicht alle implementieren jeden JSON-Schema-Draft oder jedes Schlüsselwort.

vLLM stellt mehrere Backends für strukturierte Ausgaben bereit und zeigt damit, dass JSON-Schema-, Grammatik-, Regex- und Auswahlbeschränkungen separate Ausführungsmodi sind.

Diese Ursache tritt auf, wenn dasselbe Schema in einem standardkonformen Validator korrekt validiert wird, aber nur unter einem bestimmten Inference-Backend fehlschlägt. Nicht unterstützte Rekursionen, Referenzen, Muster oder bedingte Schlüsselwörter können vereinfacht, ignoriert oder abgelehnt werden, bevor das Modell überhaupt etwas generiert.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prompt-Anweisungen können mit dem Schema in Konflikt stehen

Der Benutzerprompt kann Kommentare, Zitate, Erklärungen, das Weglassen optionaler Angaben oder natürlichsprachliche Unsicherheit verlangen, während das Schema ein einzelnes Objekt mit festen Feldern fordert.

Das Modell hat dann zwei konkurrierende Erfolgskriterien: Es soll dem Benutzer im Dialog antworten und ausschließlich Tokens ausgeben, die unter dem maschinellen Vertrag zulässig sind. Ein kleineres lokales Modell folgt möglicherweise der jüngeren oder hervorstechenderen Anweisung, anstatt beide miteinander in Einklang zu bringen.

Diese Fehler fügen häufig eine Einleitung, einen Markdown-Codeblock, eine Erklärung nach dem Objekt oder einen Wert hinzu, der zwar die Bitte im Fließtext erfüllt, aber die deklarierte Enumeration verletzt. Das Schema ist gültig; die Anweisungshierarchie ist inkonsistent.

Eine Kürzung kann einen korrekten Plan in eine ungültige Ausgabe verwandeln

Verschachtelte Arrays und Objekte benötigen genügend generierte Tokens, um jede Struktur zu schließen. Ein Token-Limit, eine Stoppzeichenkette, eine abgebrochene Anfrage oder ein unterbrochener Stream kann die Antwort beenden, bevor die abschließenden Begrenzungszeichen eintreffen.

Transformers stellt Steuerungen für maximale Tokenzahl und Abbruch bereit, die bestimmen, wann die Generierung endet.

Diese Ursache ist an gültigen Präfixen erkennbar, die abrupt enden, insbesondere bei größeren Arrays oder langen Zeichenkettenfeldern. Wiederholte Typverletzungen am Anfang deuten auf eine andere Ursache hin; fehlende schließende Klammern nahe dem Ausgabelimit weisen auf eine unvollständige Generierung hin.

Die Semantik des Validators kann Werte ablehnen, die das Modell als gleichwertig betrachtet

Ein Modell kann "3" für eine Ganzzahl, null für ein ausgelassenes Feld, eine kleingeschriebene Enumeration oder ein ISO-Datum ausgeben, das die Anwendung in einem anderen Format erwartet.

Pydantic dokumentiert unterschiedliche Kategorien von Validierungsfehlern für fehlende Werte, ungültiges JSON, nicht übereinstimmende Enumerationen, verbotene zusätzliche Felder und inkompatible Typen.

Wenn jeder Fehler dasselbe Feld mit einem parsbaren, aber abgelehnten Wert betrifft, handelt es sich nicht um einen zufälligen Schemafehler. Ursache ist eine abweichende Auffassung von Umwandlung, Striktheit, Null-Zulässigkeit, Groß- und Kleinschreibung oder anwendungsspezifischen Formaten.

Grammatikbeschränkungen können die Syntax, aber nicht die fachliche Bedeutung bewahren

Eine Grammatik kann ungültige geschweifte Klammern und Schlüssel blockieren und dennoch eine semantisch unmögliche Kombination zulassen, etwa ein Enddatum vor einem Startdatum oder einen nicht vorhandenen Dateipfad.

llama-cpp-python bietet grammatikbeschränkte Generierung als Inference-Steuerung, aber die Grammatik regelt die zulässige Tokenstruktur und nicht die externe Realität.

Ein durch Regeln zwischen mehreren Feldern verursachter Schemafehler kann erst in einer zweiten Validierungsebene auftreten. Die Ausgabe kann syntaktisch und strukturell gültig und für den Home-Server-Workflow dennoch unbrauchbar sein.

Nachbearbeitung kann eine ansonsten gültige Modellausgabe beschädigen

Anwendungen entfernen mitunter Markdown, extrahieren den ersten Block zwischen geschweiften Klammern, fügen Stream-Chunks zusammen, reparieren Kommas oder konvertieren Werte vor der Validierung.

Eine gültige Modellantwort kann ungültig werden, wenn ein Stream-Chunk dupliziert, Unicode falsch dekodiert, eine Escape-Sequenz entfernt oder eine Reparaturfunktion verschachtelte Inhalte verändert. Umgekehrt kann ein Reparaturschritt verbergen, dass die rohe Modellausgabe ungültig war.

Die Erklärung von ZimaSpace, warum kleine lokale Modelle bei der JSON-Ausgabe halluzinieren, beschreibt die angrenzende Grenze: Schema-Konformität und faktische Korrektheit müssen getrennt gemessen werden, und die rohe Antwort sollte vor Anwendungstransformationen aufbewahrt werden.

FAQ

Beweist gültiges JSON, dass die Ausgabe dem Schema entspricht?

Nein. Das Parsen von JSON prüft die Syntax. Die Schema-Validierung prüft separat erforderliche Eigenschaften, Typen, Enumerationen, Zweige, Begrenzungen und andere deklarierte Einschränkungen.

Verhindert Temperatur null Schemafehler?

Nein. Dadurch kann ein Dekodierungspfad wiederholbarer werden, aber es werden keine nicht unterstützten Schemafunktionen ergänzt, keine Kürzungen verhindert und keine widersprüchlichen Anweisungen aufgelöst.

Garantiert beschränktes Dekodieren einen nutzbaren Automatisierungsdatensatz?

Nein. Es kann unterstützte strukturelle Einschränkungen garantieren, aber Geschäftsregeln, Quellennachweise, das Vorhandensein von Dateien, Berechtigungen und die Konsistenz zwischen Feldern erfordern weiterhin eine Validierung durch die Anwendung.