SchemaSafe Blog
JSON-Schema-Validierung ohne LLM
Schema-Validierung gehört in deterministische Werkzeuge: dieselbe Eingabe produziert das gleiche Bestehen oder Nicht-Bestehen, jedes Mal. Ein LLM kann erklären, warum ein Dokument fehlgeschlagen ist oder ein Schema aus einem Beispiel entwerfen, aber das Bestehen oder Nicht-Bestehen sollte von einem echten Validator kommen. Wenn die Grenze zwischen Erklärung und Entscheidung klar bleibt, bleibt der Vertrag etwas, das Sie testen und vertrauen können.
Determinismus ist das Produkt
Wenn ich einen Validator entwerfe, konzentriere ich mich auf den Durchlauf durch den Instanzbaum. Jeder Schritt produziert ein Fehlerobjekt, das einen JSON-Pointer-Pfad, das fehlgeschlagene Keyword und eine kurze Meldung enthält. Da der Durchlauf für dieselben Daten dem gleichen Algorithmus folgt, ist die Fehlerliste bei jedem Durchlauf identisch. Diese Wiederholbarkeit ermöglicht es Teams, die Validierung als ein Tor zu behandeln, das nie sein Urteil ohne eine echte Änderung im Schema oder in der Eingabe ändert.
JSON-Pointer-Pfade ordnen sich direkt Formularfeldern oder API-Antwortschlüsseln zu. Ein Frontend kann den Pointer /items/2/name nehmen und das Namensfeld des dritten Elements hervorheben, ohne dass eine zusätzliche Übersetzungsebene erforderlich ist. Diese Zuordnung ist deterministisch, sodass der gleiche Pointer immer auf die gleiche Position im gleichen Dokumentenformat zeigt.
Im CI führe ich den Validator gegen den Testsuite und gegen jede generierte Fixtur aus. Wenn der Validator ein leeres Fehlerarray zurückgibt, wird der Build fortgesetzt; jedes nicht-leere Array verursacht ein Build-Fehlschlagen und die Fehlernutzlast wird als Artefakt veröffentlicht. Da die Ausgabe maschinenlesbar ist, können nachgelagerte Schritte Fehler zählen, sie nach Pointer gruppieren oder einen Kommentar auf dem Pull-Request veröffentlichen, der die exakten fehlgeschlagenen Pfade zeigt.
Wo ein LLM seinen Platz verdient
Ich verwende ein Sprachmodell nur für Aufgaben, die kein wahr/falsch-Urteil erfordern. Das Modell entscheidet nie über Bestehen oder Nichtbestehen; es produziert lediglich Vorschläge, die ein Mensch oder ein Werkzeug überprüfen kann.
Gegeben sei eine Handvoll von Beispiel-JSON-Dokumenten, ich fordere das Modell auf, einen Draft 2020‑12-Schema auszugeben, das die beobachteten Typen, erforderlichen Felder und grundlegenden Muster erfasst. Die Ausgabe ist ein Ausgangspunkt; ich führe sie durch den Validator aus, um zu sehen, ob sie die Beispiele akzeptiert, und dann manuell die Einschränkungen verschärfen oder lockern.
Wenn der Validator ein Array von Fehlern zurückgibt, gebe ich jedes Fehlerobjekt an das Modell mit der Anfrage weiter, die Meldung in einfacher Sprache umzuschreiben. Das Modell kann „failed keyword „required“ at pointer /user/profile/age“ in „Das Benutzerprofil fehlt ein Alter-Feld, das Ihr Service als Ganzzahl erwartet“ umwandeln. Dies hilft API-Verbrauchern, die nicht mit JSON-Schema-Schlüsselwörtern vertraut sind.
Indem ich dem Modell eine Liste häufiger Validierungsfehler zeige, kann ich es auffordern, zusätzliche Einschränkungen vorzuschlagen, wie z. B. eine Mindestlänge für eine Zeichenfolge oder ein Muster für einen Identifikator. Ich überprüfe jeden Vorschlag, füge diejenigen hinzu, die Sinn machen, und führe den Validator erneut aus, um zu bestätigen, dass das neue Schema immer noch die bekannten guten Beispiele passiert.
Aus Sicherheitsgründen halte ich das Modell hinter einer internen API und protokolliere jeden Prompt und jede Antwort. Das Protokoll ermöglicht es mir, zu überprüfen, ob das Modell jemals versucht hat, die Entscheidungsgrenze zu beeinflussen, was es nicht kann, da ich seine Ausgabe nie als Regel an den Validator weitergebe.
Validierung in CI und am Rand ausführen
Das gleiche Schema sollte das Code-Repository und den Live-Service schützen. Ich führe den Validator an zwei Stellen aus:
Die Validierung nur an einem Gateway auszuführen, lässt den internen Service anfällig für Drift; wenn das Gateway-Schema aktualisiert wird, aber ein nachgelagerter Service die Änderung nicht übernimmt, kann schlechte Daten durchkommen. Indem ich den Validator in den Service einbaue, gewährleiste ich, dass der Vertrag überall, wo der Code lebt, durchgesetzt wird.
Wenn die Validierung fehlschlägt, gebe ich HTTP 400 mit einem JSON-Body zurück, der ein Array von Fehlerobjekten enthält. Jedes Fehlerobjekt enthält:
Clients können dieses Array parsen und inline-Formularerror-Anzeigen anzeigen, was die Integrationsarbeit im Vergleich zu einem generischen „Validierung fehlgeschlagen“-String beschleunigt.
Da der Validator zustandslos und deterministisch ist, kann ich die gleiche Binärdatei oder Bibliothek an beiden Stellen verwenden, ohne mir Sorgen über versteckten Zustand machen zu müssen, der zu Abweichungen führen könnte.
Erstellung von Entwürfen versus Governance
SchemaSafe trennt Bedenken klar:
Diese Aufteilung hält den Vertrag überprüfbar. Ich kann auf eine bestimmte Schema-Datei im Repository verweisen, die Validator-Version notieren und zeigen, dass die gleiche Eingabe immer das gleiche Ergebnis liefert. Der Beitrag des Modells lebt in separaten Protokollen oder in Kommentaren, die an den Pull-Request angehängt sind; er wird niemals Teil des unveränderlichen Entscheidungsprotokolls.
Wenn ich das Schema aktualisieren muss, folge ich diesen Schritten:
Während dieses Flows ist der Validator der Gatekeeper; das Modell bekommt niemals das letzte Wort.
Was dies nicht ist
Dieser Ansatz ist keine Garantie dafür, dass jedes ungültige Dokument erfasst wird, bevor es einen Benutzer erreicht. Wenn ein Entwickler das Middleware bewusst umgeht oder wenn ein Fehler im Validator einen Fehler durchlassen lässt, kann schlechte Daten dennoch auftreten. Ich behaupte nicht, 100 % Abdeckung zu haben; ich behaupte nur, dass die Überprüfung deterministisch und wiederholbar ist.
Es ist kein Ersatz für eine sorgfältige API-Entwicklung. Ein Schema kann Form und grundlegende Einschränkungen beschreiben, aber es kann keine Geschäftsregeln ausdrücken, die von externem Zustand oder komplexer Cross-Feld-Logik abhängen. Diese Regeln benötigen immer noch Einheitstests oder Laufzeit-Schutz.
Es ist keine Garantie dafür, dass das LLM immer hilfreiche Erklärungen liefert. Das Modell kann gelegentlich Nuancen übersehen oder eine irreführende Neufassung produzieren. Ich behandele seine Ausgabe als Vorschlag, den ein Mensch akzeptieren, bearbeiten oder verwerfen kann.
Schließlich ist es kein Allheilmittel für Sicherheit. Obwohl die Validierung von Eingaben viele Injektionsrisiken reduziert, folge ich immer noch den Richtlinien von OWASP zu Prompt-Injektion ( https://genai.owasp.org/llmrisk/llm01-prompt-injection ) und zu Anmeldeinformationen-Hygiene in CI/CD ( https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene ), um die umgebende Pipeline sicher zu halten.
Referenzen
https://genai.owasp.org/llmrisk/llm01-prompt-injection
https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene
https://ajv.js.org/json-schema.html
https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
Häufig gestellte Fragen
Die Validierung muss reproduzierbar sein: gleiche Eingabe, gleiche Ergebnis. Die Beurteilung eines Modells kann zwischen den Durchläufen variieren, was für einen Vertrag, der eine Bereitstellung steuert, inakzeptabel ist. Der Validator entscheidet; das Modell erklärt.
Ein Schema aus einem Beispiel erstellen, einen Validierungsfehler für einen Menschen umschreiben oder vorschlagen, warum ein Feld weggelassen wurde. Das sind Assistenten auf einem echten Validator, kein Ersatz für einen.
Nein. Validieren Sie eingehende Anfragen im Dienst, den Sie kontrollieren, damit Fehlermeldungen den Kontext der Domäne enthalten. Führen Sie das gleiche Schema in CI gegen Fixtures aus und behandeln Sie Schemaänderungen als potenzielle brechende Änderungen.
Der Entwurf 2020-12 ist die stabile Version, die von modernen Validatoren wie Ajv v8 unterstützt wird und mit OpenAPI 3.1 übereinstimmt. Binden Sie die $schema-URL in jeder Datei, damit das Verhalten nicht abweicht.
Probieren Sie das Produkt: SchemaSafe
2026-09-16 · nur primäre Quellen · keine gefälschten Traffic-Metriken
Verwandte Artikel
Häufige Fehler beim Erstellen von JSON-Schemata
Erkunden Sie die vollständige AI-Micro-SaaS-Themenmatrix →
Warum sollte man nicht einem LLM überlassen, zu entscheiden, ob JSON gültig ist?
Die Validierung muss reproduzierbar sein: gleiche Eingabe, gleiche Ergebnis. Die Beurteilung eines Modells kann zwischen den Durchläufen variieren, was für einen Vertrag, der ein Deployment steuert, inakzeptabel ist. Der Validator entscheidet; das Modell erklärt.
Wo ist ein LLM wirklich nützlich für Schemata?
Beim Erstellen eines Schemas aus einem Beispiel, beim Umformulieren einer Validierungsfehlermeldung für einen Menschen oder beim Vorschlagen, warum ein Feld weggelassen wurde. Das sind Assistenten auf einem echten Validator aufgesetzt, kein Ersatz für einen.
Sollte die Validierung nur am Gateway ausgeführt werden?
Nein. Validieren Sie eingehende Anfragen im von Ihnen kontrollierten Dienst, damit Fehlermeldungen den Kontext der Domäne enthalten. Führen Sie das gleiche Schema in CI gegen Fixtures aus und behandeln Sie Schemataänderungen als potenzielle brechende Änderungen.
Welcher ist der aktuelle JSON-Schema-Entwurf, den man festlegen sollte?
Der Entwurf 2020-12 ist die stabile Version, die von modernen Validatoren wie Ajv v8 unterstützt wird und mit OpenAPI 3.1 übereinstimmt. Legen Sie die $schema-URL in jeder Datei fest, damit das Verhalten nicht driftet.
Nur zur Entscheidungsunterstützung. Kein Ersatz für eine formale Schema-Überprüfung oder zertifizierte Audits.