Warum die JSON-Schema-Validierung für LLM-Ausgaben unerlässlich ist

Das mentale Modell: Syntax vs. Schema

Um das Problem unzuverlässiger LLM-Ausgaben zu lösen, muss man zwischen Syntax und Schema unterscheiden. Syntax bezieht sich auf die Regeln des JSON-Formats selbst: Jede öffnende Klammer muss eine schließende Klammer haben, und Schlüssel müssen in doppelte Anführungszeichen eingeschlossen sein. Ein Parser wie Pythons json.loads() prüft nur diese Regeln.

Ein Schema hingegen definiert die semantische Bedeutung und Struktur der Daten. Während die Syntax sicherstellt, dass die Datei lesbar ist, stellt das Schema sicher, dass der Inhalt nutzbar ist. Ein LLM kann problemlos ein JSON-Objekt erzeugen, das syntaktisch perfekt ist, aber logisch nutzlos, weil es die spezifischen Informationen nicht liefert, die Ihre Anwendung benötigt.

Beispiel: null, fehlendes Feld und gültige Zeichenkette

Betrachten Sie eine Anwendung, die ein Benutzerprofil erwartet. Das System erfordert ein Feld 'email' als String. Ein LLM könnte das folgende JSON generieren:

Input JSON: {"name": "John Doe", "email": null}

In diesem Fall ist das JSON syntaktisch perfekt. Der Parser wird dies erfolgreich in ein Python-Dictionary umwandeln. Wenn Ihr Code jedoch versucht,.split('@') auf das E-Mail-Feld aufzurufen, wird die Anwendung mit einem AttributeError abstürzen, da sie einen NoneType anstelle eines Strings erhalten hat.

Durch die Anwendung eines JSON Schemas, das 'email' als erforderlichen String definiert, würde der Validierungsschritt diesen Fehler abfangen, bevor die Daten die Geschäftslogik erreichen.

# Install in your environment: python -m pip install jsonschema
import json
from jsonschema import Draft202012Validator

schema = {
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "email": {"type": "string"}
    },
    "required": ["name", "email"],
    "additionalProperties": False
}
Draft202012Validator.check_schema(schema)
validator = Draft202012Validator(schema)
samples = [
    '{"name": "Ada", "email": null}',
    '{"name": "Ada"}',
    '{"name": "Ada", "email": "ada@example.com"}'
]
for text in samples:
    data = json.loads(text)
    print("accepted" if validator.is_valid(data) else "rejected")
# Expected illustrative output:
# rejected
# rejected
# accepted

Erwartetes Ergebnis

Für die drei Eingaben lautet die illustrative Ausgabe rejected, rejected, accepted. Im ersten Objekt existiert email, aber JSON null wird in Python zu None und verletzt die string-Bedingung. Im zweiten fehlt email; required lehnt es ab. Das dritte erfüllt dieses Schema. Auch "not-an-email" würde bestehen: Das Beispiel prüft eine Zeichenkette, keine E-Mail-Adresse. Bei Python jsonschema aktiviert die Angabe format allein keine Formatprüfung; konfigurieren Sie bei Bedarf einen Formatprüfer.

Diagnose: Warum LLMs die Validierung fehlschlagen lassen

LLMs scheitern aus mehreren Gründen an der Validierung. Erstens können sie Feldnamen halluzinieren, indem sie beispielsweise 'user_email' anstelle des erwarteten 'email' verwenden. Zweitens können sie Schwierigkeiten mit komplexen Typen haben, wie etwa die Rückgabe eines Strings '10', wenn eine Zahl 10 erforderlich ist. Drittens können sie Felder komplett weglassen, wenn der Prompt mehrdeutig ist. Schließlich können sie nicht-standardmäßige Werte wie NaN oder Infinity enthalten, die zwar von bestimmten Parsern akzeptiert werden, aber nicht der strengen JSON-Spezifikation (RFC 7159) entsprechen.

Häufige Fehler

Ein häufiger Fehler besteht darin, anzunehmen, dass die Daten sicher zu verwenden sind, nur weil ein Parser keinen Fehler ausgegeben hat. Ein weiterer Fehler ist das Versäumnis, den 'null'-Wert zu berücksichtigen; in JSON kann ein Schlüssel existieren, aber den Wert null haben, was sich grundlegend davon unterscheidet, dass der Schlüssel gar nicht vorhanden ist. Entwickler vergessen zudem oft, die Anzahl der Eigenschaften zu begrenzen, wodurch das LLM massive, aufgeblähte Objekte zurückgeben kann, die während der Verarbeitung übermäßigen Speicher und CPU verbrauchen.

Entscheidungskriterien für die Validierung

Beginnen Sie mit dem tatsächlichen Vertrag: Pflichtfelder und ausdrückliche Typen. Unerwartete Felder lassen sich mit additionalProperties: false ablehnen; properties allein verbietet sie nicht. Ergänzen Sie Grenzen oder Muster nur für konkrete Anforderungen. Begrenzen Sie die Antwortgröße separat vor dem Parsen. Python json.loads akzeptiert standardmäßig NaN und Infinity; lassen Sie parse_constant einen Fehler auslösen, wenn striktes JSON erforderlich ist. Diese Prüfungen ersetzen weder Berechtigungen noch fachliche Validierung.

Geltungsbereichsbeschränkungen

Die JSON-Schema-Validierung ist eine strukturelle Prüfung, keine logische. Sie kann sicherstellen, dass ein 'price'-Feld eine Zahl ist, aber sie kann nicht sicherstellen, dass der Preis korrekt ist oder mit dem Preis in Ihrer Datenbank übereinstimmt. Darüber hinaus schützt die Schema-Validierung nicht vor Denial-of-Service-Angriffen (DoS) durch Ressourcenerschöpfung, wenn das LLM eine mehrere Gigabyte große JSON-Zeichenfolge erzeugt; Sie müssen Größenbeschränkungen für den Eingabe-String implementieren, bevor das Parsing beginnt.

Zusammenfassung der Anforderungen

Um dies effektiv umzusetzen, stellen Sie sicher, dass Sie Folgendes haben: 1. Ein definiertes JSON Schema für jede erwartete LLM-Antwort. 2. Eine Validierungsbibliothek (wie jsonschema für Python). 3. Eine Strategie für den Umgang mit Validierungsfehlern (z. B. erneutes Ausführen des LLM-Prompts oder Rückgabe einer Fehlermeldung an den Benutzer). 4. Eingabegrößenbeschränkungen, um eine Speichererschöpfung während der initialen Parsing-Phase zu verhindern.