JSON-Prompt-Generator

Warum Fließtext Code kaputt macht und JSON nicht

Frag ein Modell nach "Name, Gehalt und Startdatum der Kandidatin" und du bekommst einen schön geschriebenen Absatz. Frag zweimal und du bekommst zwei verschiedene Absätze. Einer sagt "rund 85.000 €", der nächste "85000 EUR jährlich", ein dritter beginnt mit "Klar! Das habe ich gefunden:". Dein Parser hat keine Chance.

Das Problem ist nicht die Genauigkeit — das Modell kann jedes Mal recht haben. Es ist, dass freier Text keinen Vertrag hat. Nichts garantiert, dass das Gehalt vor dem Datum steht, dass ein fehlendes Feld weggelassen statt umschrieben wird oder dass die Antwort ohne Vorrede beginnt. Jede Regex, die du dagegen schreibst, ist ein Bug, der auf eine leicht andere Formulierung wartet.

JSON gibt dir den Vertrag. Schlüssel sind fest, Typen sind fest, null heißt jedes Mal "nicht gefunden". Dein Code liest data.salary, statt nach einem Währungszeichen zu suchen. Liegt das Modell falsch, merkst du es beim Parsen und nicht drei Funktionen später.

Liest ein Mensch die Ausgabe, ist Fließtext in Ordnung. Liest Code sie, nimm JSON.

Ein Schema entwerfen, das das Modell auch trifft

Modelle erfüllen einfache Schemata zuverlässig und komplexe nur sporadisch. Regeln, die halten:

• Flach schlägt verschachtelt. Zwei Ebenen sind bequem. Bei vier beginnen Klammern an der falschen Stelle zu schließen. contact_email ist sicherer als contact.channels.email.primary.
• Sei bei Typen eindeutig. Sag "salary muss eine Zahl sein, kein String". Im Zweifel greifen Modelle zu Strings.
• Nutze null, lass nie weg. Fehlende Schlüssel brechen data.x.y auf eine Art, wie fehlende Werte es nicht tun.
• Leg deine Enums fest. "status muss genau eines von open, closed, pending sein" liefert drei Werte. "status: der aktuelle Status" liefert fünfzehn Umschreibungen derselben drei.
• Benenne Schlüssel wie ein Entwickler. snake_case, keine Leerzeichen. Das Modell schreibt ohnehin schon viel JSON.
• Lass Felder weg, die du nicht nutzt. Jeder zusätzliche Schlüssel ist eine weitere Gelegenheit, einen Wert zu erfinden.

Zeig die Form, statt sie zu beschreiben. Ein konkretes Beispiel mit Platzhaltern schlägt einen Absatz Spezifikation:

Anweisungen, die Vorreden und Code-Fences abstellen

Drei Fehlerbilder verursachen fast jede nicht parsebare Antwort: eine Vorrede, ein Markdown-Fence, eine nachgeschobene Erklärung. Setz diese Zeilen ans Ende, wo sie zuletzt gelesen werden:

• "Gib AUSSCHLIESSLICH das JSON-Objekt zurück. Kein Fließtext, keine Erklärung, keine Markdown-Code-Fences."
• "Deine gesamte Antwort muss mit einer öffnenden geschweiften Klammer beginnen und mit einer schließenden enden."
• "Umschließe die Ausgabe nicht mit Backticks."

Die zweite Zeile leistet die meiste Arbeit. Sie ist eine Prüfung, die das Modell gegen sein eigenes erstes Token abgleichen kann — weit zuverlässiger als ein allgemeines "kein zusätzlicher Text".

Hilf dir auch auf der Parser-Seite. Entferne führende und abschließende Fences vor dem Parsen — drei Zeilen defensiver Code, die dir einen Retry sparen. Und stell die Temperatur auf 0. Kreatives Sampling ist hier genau falsch.

Wenn ein bestimmtes Modell ständig Vorreden anhängt, ist das meist eine Formulierungs-Eigenheit und keine fehlende Fähigkeit. Der ChatGPT-Prompt-Generator und der Gemini-Prompt-Generator kümmern sich um modellspezifische Formulierungen, und der Analyzer markiert Anweisungen, die still zu Kommentaren einladen.

Arrays, optionale Felder und der leere Fall

Bei Arrays werden Extraktions-Prompts schlampig. Sag, wie viele — und was passiert, wenn es keine gibt.

"Gib [] zurück, wenn keiner passt" hindert das Modell daran, "keine" in einen Array-Slot zu schreiben. Die Obergrenze hindert es daran, ein kurzes Dokument aufzufüllen, damit es gründlich wirkt. Bei optionalen Objekten ist null dem Weglassen vorzuziehen — ein Zweig im Code statt zwei.

Validieren, wiederholen und wo native Modi hingehören

Vertraue nie dem ersten Parse. Die Schleife, die im Produktivbetrieb überlebt:

1. Parsen. Wirft es einen Fehler, entferne Fences und Whitespace und parse erneut.
2. Gegen ein echtes Schema validieren — Zod, Pydantic, JSON Schema. Typen und Pflichtfelder prüfen, nicht bloß, ob es gültiges JSON ist.
3. Bei Fehlschlag genau einmal wiederholen und die Fehlermeldung anhängen: "Deine vorherige Ausgabe hat die Validierung nicht bestanden: für salary wurde eine Zahl erwartet, es kam ein String. Gib nur korrigiertes JSON zurück."
4. Nach zwei Fehlschlägen die Rohausgabe loggen und auf einen Fallback gehen. Nicht in einer Schleife hängen bleiben.

Dieser eine Retry behebt die meisten Fehler beim ersten Versuch, weil du aus einem vagen Danebenliegen eine konkrete Korrektur gemacht hast.

Und jetzt der Teil, den viele überspringen: Die meisten Anbieter liefern native strukturierte Ausgaben — JSON-Modus, Response-Schemata, Function Calling. Nutz das, wo es existiert. Die API schränkt das Decoding ein, kaputtes JSON wird damit fast unmöglich. Aber sie erzwingt Form, nicht Sinn. Eine schemakonforme Antwort kann trotzdem den Namen des Recruiters in company schreiben. Die Semantik trägt der Prompt: was jedes Feld bedeutet, wann null gilt, welches Enum passt. Beides ergänzt sich. OpenAIs Leitfaden deckt die API-Seite ab; der Grundlagen-Guide erklärt die Muster darunter, und der Optimizer strafft einen aufgeblähten Extraktions-Prompt, ohne die entscheidenden Vorgaben zu verlieren.