Warum halluzinieren kleine lokale Modelle bei der JSON-Ausgabe häufiger?

Kleine lokale Modelle halluzinieren bei der JSON-Ausgabe häufiger, weil sie die Aufgabe lösen und gleichzeitig ein starres Schema sowie eine gültige Syntax einhalten müssen.

Ein lokaler KI-Workflow kann ein kompaktes Modell auffordern, Dateinamen, Daten, Tags, Gerätezustände oder Automatisierungsargumente zu extrahieren und als maschinenlesbares JSON zurückzugeben. Das Modell erledigt dabei nicht nur eine Aufgabe. Es muss die richtigen Fakten identifizieren, sie den vorgesehenen Feldern zuordnen, erforderliche Datentypen und Enumerationen beachten, Satzzeichen und Verschachtelungen korrekt beibehalten und ohne zusätzliche Kommentare aufhören. Wenn die Modellkapazität begrenzt ist, konkurrieren diese Anforderungen mit der nötigen Schlussfolgerung, um die Werte an den tatsächlichen Informationen auszurichten.

JSON macht Korrektheit zu einem Problem auf zwei Ebenen

Die Antwort muss gleichzeitig semantisch korrekt und strukturell gültig sein. Eine frei formulierte Antwort kann Unsicherheit ausdrücken oder einen fehlenden Wert erklären, während ein JSON-Vertrag das Modell oft zwingt, einen Feldwert auszuwählen, selbst wenn die Belege dafür schwach sind.

Forschungen zum Spannungsfeld zwischen Gültigkeit und Korrektheit zeigen, warum diese Messgrößen getrennt bleiben müssen: Strengere Ausgabebeschränkungen können die Schemagültigkeit verbessern, während die ausgewählten Werte ungenauer werden.

Bei einem kleinen lokalen Modell ist dieser Druck deutlicher sichtbar, weil ihm weniger Kapazität für die Befolgung von Anweisungen, die Extraktion und die Serialisierung zur Verfügung steht. Auch ein größeres Modell kann ein Feld erfinden, aber bei einem kompakten Modell verdrängt die Formatkonformität die Antwortqualität früher.

Ein gültiges Objekt kann trotzdem eine halluzinierte Antwort enthalten

Constrained Decoding kann verhindern, dass eine unzulässige geschweifte Klammer, ein unbekannter Schlüssel oder eine ungültige Enumeration ausgegeben wird. Es kann jedoch nicht beweisen, dass die ausgewählte Kunden-ID, das Datum, der Pfad oder der Status im Ausgangsmaterial enthalten ist.

vLLM beschreibt JSON-Schema-Beschränkungen als Möglichkeit, die Form der generierten Ausgabe einzuschränken. Der Decoder reduziert die Anzahl der Token, die als Nächstes zulässig sind, aber die Bedeutung dieser zulässigen Token liefert weiterhin das Modell.

Dadurch entsteht ein gefährlicher Fehler bei Automatisierungen: Das Objekt lässt sich erfolgreich parsen, sodass nachgelagerter Code ihm vertraut, obwohl ein Feld erfunden ist. Prüfe Geschäftsregeln und Belege aus der Quelle nach der Schemavalidierung, anstatt einen erfolgreichen Parse-Vorgang mit faktischer Korrektheit gleichzusetzen.

Verschachtelte Schemas erhöhen Verzweigungen und Anforderungen an die Zustandsverfolgung

Jede erforderliche Eigenschaft, jeder optionale Zweig, jedes verschachtelte Array, jedes nullable Feld und jede Enumeration fügt Zustände hinzu, die das Modell während der Generierung verfolgen muss. Ähnliche Schlüsselnamen oder wiederholte Objektstrukturen erleichtern es, einen korrekten Wert an der falschen Stelle zu platzieren.

Der llama.cpp-Leitfaden zu grammatikbeschränktem JSON unterscheidet zwischen der erlaubten Ausgabeggrammar und dem Prompt, der die Bedeutung der Felder erklärt. Eine Grammatik kann die Struktur erzwingen, aber das Schema benötigt weiterhin klare semantische Anweisungen.

Reduziere die Anzahl gleichzeitiger Entscheidungen. Vereinfache tief verschachtelte Objekte, entferne ungenutzte optionale Felder, verwende eindeutige Schlüsselnamen und teile eine große Extraktion in kleinere Objekte auf, wenn das lokale Modell wiederholt Felder vertauscht oder irrelevante Felder ausfüllt.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

JSON-only-Prompts können nützliche Schlussfolgerungen unterdrücken

Die strikte Anweisung „Gib nur JSON zurück“ drängt das Modell dazu, eine Antwort sofort zu verpacken. Bei einer schwierigen Extraktion kann das zu einer frühen Feldauswahl führen, bevor das Modell konkurrierende Textstellen verglichen oder ein mehrdeutiges Datum geklärt hat.

Evaluierungen von Hugging Face zeigen eine Empfindlichkeit gegenüber dem Prompt-Format: Wenn sich die erwartete Struktur und der für Schlussfolgerungen verfügbare Raum ändern, kann sich die Aufgabenleistung verändern, obwohl die zugrunde liegende Frage gleich bleibt.

Gib keine privaten Gedankengänge aus, sondern trenne die interne Aufgabenklärung von der abschließenden Serialisierung. Der Workflow kann zunächst einen kompakten Belegdatensatz extrahieren oder eine deterministische Abfrage durchführen und das Modell anschließend nur die verifizierten Felder ausgeben lassen.

Prompt-basiertes JSON und Constrained Decoding scheitern auf unterschiedliche Weise

Prompt-only-JSON kann Codeblöcke, Kommentare, doppelte Schlüssel, nachgestellte Kommas oder ein unvollständiges Objekt erzeugen. Constrained Decoding beseitigt viele Syntaxfehler, kann das Modell aber dazu zwingen, zwischen gültigen Werten zu wählen, wenn „unbekannt“ nicht erlaubt ist.

Fireworks erklärt, wie Schema-beschränkte Token-Auswahlen die Generierung innerhalb eines Ausgabevertrags halten, während der Prompt weiterhin die beabsichtigten Daten genau beschreiben muss.

Verfolge beide Fehlergruppen. Miss bei Prompt-only-Ausgaben zunächst Parse-Fehler und anschließend nach Aktivierung von Constrained Decoding falsche, aber gültige Felder, unerwünschte Standardwerte und eine ungerechtfertigte Gewissheit.

Sampling und Abschneiden verstärken kleine Fehler

Eine höhere Temperatur kann die Auswahl von Schlüsseln und Feldwerten variieren, während ein unzureichendes Token-Limit Arrays oder schließende Klammern abschneiden kann. Eine niedrigere Temperatur reduziert die Variation, macht einen nicht belegten Wert jedoch nicht wahr.

Eine praktische Untersuchung zu einer Pipeline für strukturierte Ausgaben mit lokalen Modellen zeigt, warum Validierung und beschränkte Generierung getrennte Komponenten und kein einzelner Prompting-Trick sind.

Reserviere ausreichend Ausgabetoken für das größte zulässige Objekt, begrenze die Array-Länge und wiederhole nur den fehlerhaften Teil. Wenn du das gesamte Objekt neu generierst, können bereits korrekte Felder durch neue Halluzinationen ersetzt werden.

Verwende eine lokale JSON-Pipeline in zwei Stufen

Löse die Aufgabe zunächst in einem minimalen typisierten Datensatz auf: die genaue Textstelle aus der Quelle, das normalisierte Datum, die ausgewählte Kennung, der Vertrauensstatus und jeder ausdrücklich fehlende Wert. Diese Stufe sollte die Anfrage ablehnen dürfen, anstatt erforderliche Daten zu erfinden.

Gib diesen Datensatz anschließend über einen schema-beschränkten Decoder aus, parse ihn und führe semantische Prüfungen durch, etwa auf das Vorhandensein von Dateien, den Datumsbereich, die Kompatibilität mit Enumerationen und die Konsistenz zwischen Feldern. Ein Validator sollte gezielte Fehler zurückgeben, die das zu korrigierende Feld benennen.

ZimaSpaces Erklärung, warum ein kleineres Modell zuverlässiger sein kann, setzt den Rahmen: Kompakte Modelle funktionieren am besten, wenn Aufgabe, Kontext, Werkzeugsatz und Ausgabevertrag eng genug gefasst sind, um überprüft werden zu können.

FAQ

Bedeutet gültiges JSON, dass das Modell nicht halluziniert hat?

Nein. Gültiges JSON beweist, dass das Objekt Syntax- oder Schemoregeln einhält. Es beweist nicht, dass die Feldwerte aus der Quelle stammen oder dem tatsächlichen Systemzustand entsprechen.

Werden JSON-Halluzinationen durch eine Temperatur von null behoben?

Nein. Dadurch kann die Ausgabe wiederholbarer werden, aber ein konsequent ausgewählter, nicht belegter Wert bleibt eine Halluzination.

Reicht Constrained Decoding für Automatisierungen aus?

Nein. Verwende es zusammen mit quellenbasierter Extraktion, Schemavalidierung, semantischer Prüfung und einem sicheren Ablehnungspfad für fehlende oder mehrdeutige Daten.