Warum reicht gültiges JSON nicht aus?
Eine syntaktisch gültige JSON-Datei kann vom vereinbarten Datenvertrag abweichen. In unserem Offline-Test akzeptiert die Basisprüfung ein zusätzliches Feld; die engere Schlüsselregel lehnt dieselbe Datei ab. Dafür liefen acht künstliche Dateien durch beide Regeln, insgesamt 16 Prüfungen. Kein KI-Modell wurde dabei aufgerufen.
- Umfang
- 8 künstliche Dateien · 16 Prüfungen
- Ausführung
- Python 3.12.10 · Windows
- Vergleich
- Basisregel und engere Schlüsselliste
- Modellleistung
- Nicht gemessen · keine API-Aufrufe
Geprüft werden die hinterlegten Schlüssel und Sollwerte dieser Aufgabe. Freie Aussagen oder beliebige andere Datenverträge sind damit nicht validiert.
Beide Regeln akzeptieren die korrekte Antwort und lehnen die sechs anderen fehlerhaften Dateien ab. Der Unterschied liegt bei der Datei mit Zusatzfeld: Das zusätzliche Feld kommentar wird von der Basisprüfung akzeptiert und von der engeren Regel abgelehnt. Die Tabelle zeigt jede Beobachtung; eine allgemeine Erkennungsquote lässt sich daraus nicht ableiten.
| Künstlicher Testfall | Basisprüfung | Engere Schlüsselregel |
|---|---|---|
| Alle Sollwerte stimmen | akzeptiert | akzeptiert |
| Falsche Summe | abgelehnt | abgelehnt |
| Pflichtfeld fehlt | abgelehnt | abgelehnt |
| Andere Reihenfolge | abgelehnt | abgelehnt |
| Zahl als Zeichenkette | abgelehnt | abgelehnt |
| Zusätzliches Feld | akzeptiert | abgelehnt |
| Ungültige JSON-Syntax | abgelehnt | abgelehnt |
| ID doppelt statt vollständig | abgelehnt | abgelehnt |
Structured Outputs prüfen: drei getrennte Fragen.
Wenn du Structured Outputs weiterverarbeitest, brauchst du drei getrennte Antworten: Ist die Ausgabe lesbares JSON? Entspricht sie dem vereinbarten Datenvertrag? Stimmen die Werte mit dem Ausgangsmaterial überein? Unser Versuch macht eine Grenze der zweiten Prüfung sichtbar.
- 01 / Syntax
- Lässt sich die Datei als JSON lesen?
- 02 / Vertrag
- Sind Schlüssel, Typen und Pflichtfelder wie vereinbart?
- 03 / Inhalt
- Stimmen die Angaben mit den festgelegten Sollwerten überein?
- Grenze
- Unbekannte freie Aussagen bleiben ungeprüft.
Ein eigenes, vereinfachtes Beispiel: Dein Vertrag erlaubt nur das Textfeld ort. Die Antwort {"ort":"Berlin","kommentar":"fertig"} ist lesbares JSON und enthält das Pflichtfeld. Eine Regel mit additionalProperties: false lehnt das Zusatzfeld dennoch ab. Ob Berlin der richtige Ort ist, lässt sich erst mit der Eingabequelle prüfen. Das Beispiel erläutert den Vertrag; es ist kein weiterer gemessener Testfall unseres Acht-Dateien-Pakets.
Das Setup bleibt absichtlich klein.
- Eingaben
- 8 künstliche Dateien mit festen Sollwerten
- Laufzeit
- Python 3.12.10 · Windows · Standardbibliothek
- Ausführung
- Je Datei Basis und engere Regel, getrennte Exit-Codes
- Modell / API
- Kein Aufruf; keine Modellleistung gemessen
Die Basisroutine prüft das Vorhandensein festgelegter Schlüssel, konkrete Werte, Typen und die Reihenfolge der Listen. Sie verbietet zusätzliche Schlüssel nicht. Das ist eine Grenze ihres Auftrags, kein Syntaxfehler im JSON. Die zweite Regel ergänzt nur die Prüfung der obersten Schlüsselmenge.
Auch in JSON Schema haben Pflichtfelder und zusätzliche Eigenschaften unterschiedliche Aufgaben: required fordert Felder, additionalProperties: false schließt zusätzliche Felder aus. Unser kleines Python-Beispiel ist kein vollständiger Schema-Validator.
Alle Dateien. Derselbe Versuch.
Speichere basis_pruefen.py, pruefen.py und testfaelle.json in einem gemeinsamen Übungsordner. Python 3.9 oder neuer reicht; Zusatzpakete, Konten und Schlüssel werden nicht benötigt. Lies die Dateien vor dem Start. Der Aufruf gibt beide Resultate pro Testfall aus und beendet sich bei einer unerwarteten Abweichung.
python pruefen.py --self-test
python pruefen.py antwort.json --strictDer zweite Aufruf prüft nur diese festgelegte Übungsaufgabe. Für eine andere Datenstruktur musst du zuerst die Sollwerte und passenden Regeln ändern. Ein Exit-Code von 0 bedeutet hier „diese Sollprüfung bestanden“, nicht „beliebiger Inhalt ist wahr“.
Herkunft und Prüfsummen
Die Basisdatei wurde unverändert aus der Tokenwerk-Übung für GPT-6.1 Sol übernommen. Der Modellname bezeichnet die Herkunft der Übung, nicht einen ausgeführten Modelltest.
SHA-256 der Basisdatei: 2c4b9b56a8bc4be74133a389780a4dfd65449eb873b1f0fcb4442b44c5b86817
SHA-256 der Testfälle: e148fc497ab05b7efce9a3497d67dc515965f7e1726f5419aee34623027534e4
Die Daten wurden künstlich erstellt, die Skripte lokal ausgeführt und die beobachteten Resultate automatisiert geprüft. Artikel und Diagramme entstanden mit KI-Unterstützung auf Grundlage dieses Protokolls.
Was dieser Versuch nicht misst.
Die Eingaben sind gezielte Beispiele, keine zufällige Stichprobe von Modellantworten. Wir messen damit weder Halluzinationshäufigkeit noch Modellgenauigkeit, Sicherheit oder Zeitersparnis. Ein Zusatzfeld kann in einer Anwendung erlaubt und in einer anderen unerwünscht sein. Entscheidend ist der vorher festgelegte Datenvertrag.
Auch die engere Regel prüft nur diese Schlüssel und Sollwerte. Sie schützt keine nachgelagerten Werkzeuge vor beliebigen Inhalten. Freie Texte, Quellen und externe Aktionen brauchen eigene Kontrollen.
Den Weg zur strukturierten Antwort erklärt unser Guide zum Thema JSON-Ausgaben mit Ollama erzeugen.
Ein korrektes Dateiformat beantwortet keine Sachfrage: Lies dazu die Einordnung zu KI-Halluzinationen und falsche Aussagen.
Mit denselben Sollwerten kannst du anschließend einen eigenen Modellvergleich vorbereiten.
Redaktionell überarbeitet am . Der Versuch stammt unverändert vom 22. Oktober 2026.
Quellen und Teststand.
Technische Dokumentation abgerufen am 22.10.2026. Die Einzelresultate stammen aus dem verlinkten lokalen Testprotokoll. Inhalte und Grafiken wurden mit KI-Unterstützung ausgearbeitet; Messungen und Pläne sind getrennt gekennzeichnet.