„Antworte bitte nur als JSON.” Dieser Satz im Prompt ist der Grund, warum so viele KI-Anwendungen in der Demo glänzen und im Betrieb kippen. Er funktioniert meistens. Und „meistens” ist genau das Problem: Die eine Antwort, die ein „Hier ist dein JSON:” davorsetzt, ein Feld erfindet oder ein Komma vergisst, kommt nicht in der Vorführung, sondern nachts um drei, wenn niemand hinschaut — und legt die Pipeline lahm.
Der Unterschied zwischen einem Spielzeug und einem Produkt ist, ob die Ausgabe garantiert weiterverarbeitbar ist. Das erreicht man nicht durch höfliches Bitten, sondern durch Zwang, Prüfung und ein bisschen Demut gegenüber dem, was ein Modell so anstellt. Diese Seite zeigt, wie.
Warum „bitte als JSON” nicht reicht
Per Prompt um ein Format zu bitten, lässt das Modell entscheiden, ob es sich daran hält. Meistens tut es das. Aber im langen Schwanz der Fälle hängt es eine Erklärung davor, packt die Ausgabe in Markdown-Zäune, erfindet ein Feld, das du nie wolltest, schreibt „k. A.” wo ein Leerwert hingehört oder einen Wert, den deine Liste gar nicht kennt. Jeder dieser Fälle bricht das Parsen.
Und das Tückische: In der Entwicklung siehst du genau diese Fälle nicht, weil sie selten sind. Du baust auf einem Format, das zu 97 Prozent stimmt, und die fehlenden 3 Prozent sind die, die dir den Produktivbetrieb zerlegen. Verlässlichkeit entsteht nicht aus einem guten Prompt, sondern aus den Schichten dahinter.
Die Stufen, von schwach bis robust
Es gibt eine klare Rangfolge, wie hart du das Format erzwingst.
Die schwächste Stufe ist der reine Prompt — „gib nur JSON aus”. Bequem, und genau so unzuverlässig wie beschrieben.
Die nächste ist das Schema oder der Tool-Use-Modus: Du gibst dem Modell eine feste Struktur vor, und die Schnittstelle zwingt die Ausgabe in genau diese Form. Das ist um Klassen verlässlicher, weil das Modell gar nicht erst frei formulieren kann. Was dein Stack an erzwungener Struktur anbietet, solltest du nutzen.
Die dritte ist Prüfung und Nachfassen: Selbst mit Schema validierst du die Ausgabe gegen deine eigenen Regeln und lässt das Modell bei einem Fehler korrigieren. Diese Stufe ist nicht optional, egal wie gut die darüber ist.
Wie ich das angehe
Schema oder Tool-Use, das die Ausgabe in Form zwingt, statt nur im Prompt darum zu bitten. Das eliminiert den Großteil der Brüche von vornherein.
Tief verschachtelte Strukturen verwirren das Modell und brechen häufiger. Wenige, klare Felder sind verlässlicher als ein verschachtelter Baum.
Gegen die eigenen Regeln validieren: Typen, Wertebereiche, erlaubte Werte, Pflichtfelder. Auch eine erzwungene Ausgabe kann inhaltlich danebenliegen.
Dem Modell genau sagen, was falsch war, damit es gezielt korrigiert. Eine stumme Ablehnung hilft nicht, eine erklärende schon.
Eine Korrekturschleife ja, aber gedeckelt. Sonst dreht das Modell Runden und verbrennt Tokens, ohne je fertig zu werden.
Struktur ist nicht Wahrheit
Hier liegt der Denkfehler, der auch Erfahrene erwischt: Eine Ausgabe kann perfektes JSON sein, exakt dem Schema entsprechen — und inhaltlich frei erfunden. Die Struktur garantiert, dass du es verarbeiten kannst, nicht dass es stimmt. Ein gut typisierter Wert, der aus der Luft gegriffen ist, sieht genauso sauber aus wie ein richtiger.
Deshalb ist die Format-Prüfung nur die halbe Miete. Wo es auf die Richtigkeit ankommt — Beträge, Zuordnungen, alles Verbindliche — gehört die inhaltliche Prüfung dazu, gegen die Quelle oder durch einen Menschen. Verarbeitbar und korrekt sind zwei verschiedene Garantien, und nur die erste gibt dir das Schema.
JSON ist nicht immer die Antwort
Ein praktisches Detail, das mir viel Ärger erspart hat: Bei Feldern, die langen Fließtext enthalten — ein Beitrag, eine Beschreibung, ein Brief —, wird JSON zur Falle. Anführungszeichen, Zeilenumbrüche und Sonderzeichen im Text müssen escaped werden, und genau da entstehen die kaputten Antworten.
Für solche textlastigen Inhalte sind Tags oder ein klar abgegrenztes Format oft robuster als JSON. Die Regel, die sich bei mir bewährt hat: Wähle das Format nach der Fracht. Strukturierte Felder als JSON oder Schema, langer Text in Tags. Nicht jedes Problem ist ein JSON-Problem.
Wo es in der Praxis kippt
Die »meistens«-Falle. Prompt-only läuft in der Demo und bricht im langen Schwanz. Wer auf „klappt ja fast immer” baut, baut auf Sand.
Erfundene Felder und Werte. Das Modell ergänzt ein Feld, nutzt einen Wert außerhalb deiner Liste, setzt Text wo ein Leerwert hingehört. Erzwingen und prüfen fängt das.
Escaping-Hölle. Sonderzeichen in Textfeldern zerlegen JSON. Für lange Texte das Format wechseln, statt gegen das Escaping zu kämpfen.
Zu tief verschachtelt. Komplexe, verschachtelte Schemata brechen häufiger. Flach halten.
Endlose Korrekturschleifen. Ein ungedeckeltes „korrigier das nochmal” verbrennt Tokens und Zeit. Versuche begrenzen.
Was es kostet — und woran
In Euro fast nichts — der Preis ist Disziplin. Schema, Prüfung und eine begrenzte Korrekturschleife sind überschaubarer Mehraufwand beim Bauen. Ihn zu sparen ist billig, bis es das nicht mehr ist: Eine kaputte Antwort zur falschen Zeit kostet einen Ausfall, eine falsche Buchung, einen verlorenen Vorgang. Das ist der teuerste Sparposten in jeder KI-Anwendung.
Wer dir eine Lösung zeigt, deren Verlässlichkeit auf einem gut formulierten Prompt beruht, zeigt dir eine Demo, kein Produkt. Die Schichten dahinter sind unsichtbar und genau das, was trägt.
Wie ein ehrlicher Einstieg aussieht
Nimm die eine Stelle, an der deine Anwendung heute die Ausgabe eines Modells weiterverarbeitet, und härte genau die ab: erzwungenes Schema statt Prompt-Bitte, eine Prüfung gegen deine Regeln, eine begrenzte Korrekturschleife mit erklärendem Fehler. Dann wirf bewusst unsaubere und ungewöhnliche Eingaben darauf und schau, ob die Bruchrate fällt. Hält diese eine Stelle, hast du das Muster, das du überall anwendest.
Worauf du achtest, wenn dir das jemand baut
- Wird Schema oder Tool-Use genutzt, oder hängt alles an einem Prompt? Prompt-only ist das Warnsignal.
- Wird die Ausgabe unabhängig validiert, oder dem Modell blind geglaubt?
- Gibt es eine begrenzte Korrekturschleife mit führenden Fehlern — statt endlos oder gar nicht?
- Ist klar, dass valide nicht korrekt heißt, und wird der Inhalt dort geprüft, wo es zählt?
- Passt das Format zur Fracht — Tags für langen Text statt JSON-Escaping-Schlacht?
Die Prompt-Schicht ist nur ein Teil — aber ein strenger Prompt macht den Rest leichter. Dieses Gerüst kannst du anpassen:
Du gibst NUR strukturierte Daten zurück, exakt in diesem Format — kein Fließtext, keine Erklärung,
keine Markdown-Zäune.
Felder (alle Pflicht):
- <feld_1>: <Typ / erlaubte Werte>
- <feld_2>: <Typ / erlaubte Werte>
Regeln:
1. Erfinde KEINE zusätzlichen Felder. Halte dich exakt an die Liste.
2. Nutze nur die erlaubten Werte. Kennst du einen Wert nicht, setze ausdrücklich null — nicht "k. A.",
nicht raten.
3. Gib ausschließlich die strukturierte Ausgabe zurück, nichts davor, nichts danach.
[deine Aufgabe und Eingabe hier]Im Code kommt darüber, was wirklich trägt: erzwungenes Schema, eine Validierung gegen deine Regeln und eine gedeckelte Korrekturschleife mit erklärendem Fehler.
Du baust etwas, das die Ausgabe eines Modells weiterverarbeitet, und ab und zu bricht die Pipeline an einer kaputten Antwort? Dann reden wir über die eine Stelle, an der du parst — und ich sage dir, wie du sie mit Schema, Prüfung und begrenztem Nachfassen so absicherst, dass sie auch um drei Uhr nachts hält.