LLM-Datenformate: Wie man mit einem Modell spricht – und in welcher Sprache es antwortet

Es ist eine Geschichte voller Leiden, voller langer Tage und noch viel längerer Nächte. Wer in jüngerer Vergangenheit um drei Uhr morgens debuggt hat, warum ein scheinbar perfektes JSON-Schema beim 527. API-Call plötzlich ein falsch platziertes Anführungszeichen schreibt und die ganze Pipeline pulverisiert, der weiß: Die Wahl des Datenformats ist keine kosmetische Entscheidung. Sie ist Architektur.

Drei Fragen zum Thema LLM-Datenformate stellen sich, sobald man ein Modell über die Spielwiese hinaus in Produktion bringt – egal ob im Web-Chat, über die API oder im Agenten-Workflow. Welche Input-Formate kann ich nutzen? Welche erwartet das Modell von mir? Und in welchem Format hätte ich das Ergebnis denn gern, damit ich es ohne schlechtes Gewissen weiterreichen kann?

Die kurze Antwort: Kommt darauf an. Die lange Antwort kommt gleich.

JSON – der ungeliebte Standard, der sich gerade selbst rettet

JSON ist die Lingua Franca jeder API aber 'ne kleine Diva. Jedes Backend versteht es, jeder Parser frisst es, und seit August 2024 zwingen OpenAI und inzwischen alle großen Anbieter ihre Modelle per Constrained Decoding dazu, syntaktisch valides JSON zu liefern. Das hat die Lage fundamental verbessert.

Damals galt: Lass ein Modell frei JSON generieren und du wirst regelmäßig von vergessenen Anführungszeichen, Trailing Commas und unsauber escapten Strings überrascht. Die Folge war die ganze Bibliothek aus Healing-Prompts, Retry-Loops und Backend-Bandagen. Heute sieht das anders aus. Wenn du response_format: json_schema mit strict: true setzt, wird das Modell strukturell keine kaputten Outputs mehr produzieren – die Token-Auswahl wird zur Laufzeit auf die nach Schema gültigen Tokens beschränkt.

Anthropic hat im November 2025 nachgezogen und Constrained Decoding für Claude verfügbar gemacht. Damit ist die Grundbehauptung „JSON ist fragil" für Produktionsumgebungen praktisch erledigt – vorausgesetzt, man nutzt die nativen Modi und schreibt sich nicht aus Trotz oder Bequemlichkeit „antworte mir bitte in JSON" in den Prompt.

Eine wichtige Falle bleibt aber. Eine viel zitierte Studie von Tam et al. aus dem August 2024 zeigt, dass strikter JSON-Mode bei Reasoning-Tasks die Modellqualität spürbar drückt. Bei GSM8K-Mathe-Aufgaben fielen GPT-3.5 und mehrere Open-Source-Modelle deutlich ab, sobald sie das Denken in ein JSON-Korsett zwängen mussten. Bei reinen Klassifikationsaufgaben war der Effekt umgekehrt – da half der enge Output-Raum sogar. Die pragmatische Konsequenz: Reasoning-Schritte und Strukturierung trennen. Erst denken lassen, dann formen. OpenAI empfiehlt das selbst und schlägt explizit ein vorgelagertes reasoning-Feld im Schema vor – Benchmarks von Instructor zeigten dadurch bis zu 60 % Accuracy-Gewinn auf GSM8K. Das ist dieselbe Linie, die ich schon bei Constraint-Based Prompting an Reasoning-Modellen kritisiert habe: zu enge Korsette während des Denkprozesses zerschießen genau die Fähigkeit, für die du das Modell überhaupt nutzt.

YAML – schön für Menschen, gefährlich für Maschinen

YAML ersetzt JSONs syntaktische Last durch Whitespaces und Zeilenumbrüche. Das spart Tokens und ist deutlich angenehmer zu lesen, gerade bei längeren System-Prompts oder Few-Shot-Beispielen. Wer schon einmal versucht hat, drei verschachtelte Few-Shot-Beispiele in JSON zu pflegen, weiß, warum YAML so populär ist.

Der Haken sitzt tief in der Sprache selbst. YAML verzeiht keine Einrückungsfehler – ein Leerzeichen zu viel oder zu wenig und die ganze Objekt-Hierarchie verrutscht. Dazu kommen die berüchtigten unquotierten Werte, bei denen ein freundliches no zu false mutiert, weil der Parser das so gelernt hat. YAML ist also input-spezifisch zumindest ein halber Albtraum. Jeder, der sich beispielsweise mit Docker Compose beschäftigt, kennt das. Das macht YAML für Modell-Outputs riskant, für Inputs aber nach wie vor wertvoll. Mein pragmatischer Take: YAML für Prompts, JSON oder TOON für Outputs.

TOML – der unterschätzte Backend-Held

TOML wird oft als „YAML ohne Drama“ verkauft und das stimmt sogar halbwegs. Sektionen mit eckigen Klammern, Key-Value-Paare, multiline Strings ohne Escape-Hölle. In der direkten Kommunikation mit dem Modell spielt TOML keine Rolle – Modelle wurden auf weniger TOML trainiert als auf YAML oder JSON, und Outputs in TOML zu erzwingen, ist meist sinnlos.

Wofür TOML brilliert, ist das Prompt-Management im Code-Repository. Wer eine prompts.toml führt, in der System-Prompts, Few-Shot-Beispiele und Konfigurationen sauber liegen, hat eine wartbare Basis. Das ist Infrastruktur-Komfort, kein Modell-Format. Verwechslung der beiden Ebenen ist häufig und vermeidbar.

Markdown – die Muttersprache der Modelle

Markdown ist das Format, mit dem Modelle aufgewachsen sind. Sie haben es millionenfach im Training gesehen und beherrschen es fast fehlerfrei. Kennt außerdem jeder, der sich schon mal auf GitHub verirrt hat. Markdown-Syntax ist so wunderbar einfach verständlich und auch ohne Parser gut lesbar. Ich oute mich hier mal als echter Markdown-Fan.

Für drei Szenarien ist Markdown die ideale Wahl. RAG-Dokumente, die du in den Kontext injizierst. Freie Modell-Antworten an menschliche Endnutzer. Und alles, was zwischen Reasoning-Schritten und finaler Strukturierung liegt.

Was Markdown nicht kann: striktes Parsing. Eine Markdown-Tabelle ist keine Datenbank-Zeile, und der Versuch, aus Markdown-Outputs direkt SQL-Inserts zu generieren, endet im Tränental. Für die Mensch-Schnittstelle perfekt, für die Maschine-Maschine-Schnittstelle die falsche Wahl.

XML – Anthropics offene Geheimwaffe

Hier wird es interessant. Anthropic empfiehlt in der offiziellen Prompting-Doku konsequent XML-Tags für die Strukturierung komplexer Prompts: <document>, <example>,  <instructions>, <thinking>. Claude wurde explizit darauf trainiert, diese Tags zu erkennen und konsistent zu verarbeiten. In der offiziellen Doku wird XML als primäre Methode für komplexe Prompts empfohlen, mit dem Argument deutlich konsistenterer Outputs.

Auch XML ist wunderbar einfach gestrickt und schnell weggeschrieben – kennt man, hat man schon mal gesehen, kann man. Der Mechanismus dahinter ist simpel und stabil. XML-Tags öffnen und schließen sich. Das LLM hat ein fast schon mathematisches Gespür dafür, was zwischen <context> und </context> gehört und was nicht. Damit löst XML zwei Probleme auf einmal. Erstens die saubere Trennung von Systeminstruktion und Nutzerdaten – Nutzer-Input in <user_input>-Tags zu kapseln ist eine elegante Verteidigungslinie gegen Prompt Injection. Zweitens das saubere Herauslösen strukturierter Antworten, etwa „denke laut in <thinking> und gib das Ergebnis in  <output>“. Ein simpler Regex-Parser zieht dann pixelgenau das raus, was das Backend braucht, und der Rest darf Modell-Geplänkel bleiben. Das ist auch der Grund, warum ich Rollen-Anweisungen im Prompt für überschätzt halte: Strukturelle Klarheit über XML-Tags bringt mehr als die fünfzehnte Variante von „du bist ein erfahrener Experte für …“.

Für GPT und Gemini gilt: funktioniert auch, aber weniger zuverlässig. Wer mit Claude arbeitet und keinen XML-Layer baut, lässt Konsistenz auf der Straße liegen.

TOON – der Hipster mit echtem Kern

TOON, Token-Oriented Object Notation, ist seit Oktober 2024 unterwegs und kombiniert die Einrückung von YAML mit dem Header-Schema von CSV. Die Idee dahinter ist simpel. Keys werden nur einmal deklariert, danach folgen kommagetrennte Datenzeilen. Klingt clever, ist es bei tabellarischen Daten auch.

Die Marketing-Zahlen lauten meist „30 bis 60 Prozent weniger Tokens als JSON“ und in vielen Blogposts wird das unkritisch durchgereicht. Wer genauer hinschaut, sieht ein anderes Bild. Die offiziellen Benchmarks selbst gestehen ein, dass TOON bei tief verschachtelten oder nicht-uniformen Strukturen mehr Tokens braucht als minified JSON. Für reine flache Tabellen ist CSV ungefähr sechs Prozent kompakter als TOON. Und eine arxiv-Studie vom Februar 2026 zeigt: Beim freien Generieren liefert plain JSON oft die beste Accuracy, weil das Modell schlicht JSON kennt und TOON nicht.

Das heißt nicht, dass TOON unbrauchbar wäre. Es heißt: Der Sweet Spot ist eng. Wenn du große, uniforme Tabellen-Arrays an ein LLM übergeben musst – Produktkataloge, Logs, RAG-Ergebnisse mit gleichförmigen Datensätzen – dann ist TOON ein ernsthafter Kandidat und die Einsparung real. Bei verschachtelten Strukturen, dynamischen Schemata oder kleinen Datenmengen ist der Schema-Overhead höher als der Gewinn. Wie immer gilt: an deinen eigenen Daten messen, nicht der Marketing-Folie glauben.

Im Produktiveinsatz habe ich um TOON bisher einen großen Bogen gemacht. Die Verbreitung ist überschaubar, was bedeutet, dass das Output-Format jedes Mal explizit im Prompt beschrieben werden muss – inklusive Schema-Erklärung und Few-Shot-Beispielen. Dieser Overhead frisst einen Teil der Token-Ersparnis sofort wieder auf, und der Rest des Gewinns war mir den Aufwand bisher schlicht nicht wert. Wenn man dann mal größere Datenmengen über viele Calls schickt, rechnet man anders. Für meine Pipelines reicht JSON mit Structured Outputs.

CSV und TSV – brachial, aber gut

Für rein tabellarische Bulk-Inputs an ein LLM sind CSV und TSV unschlagbar. Null syntaktischer Overhead, keine wiederholten Keys, maximal kompakt. Wenn du 500 Produkte zur Kategorisierung an das Modell schickst, ist eine CSV mit Semikolon-Separator oder Tabs die token-effizienteste Wahl überhaupt. Das war 1985 so und ist 2026 noch immer so.

Die Grenzen kommen, sobald Verschachtelung ins Spiel kommt. Ein Feld, das selbst ein Array enthält, sprengt das Format – und Workarounds wie JSON-in-CSV-Zellen machen die ganze Token-Ersparnis sofort zunichte. CSV ist also kein generelles Format, sondern eine eng zugeschnittene Antwort auf eine eng zugeschnittene Frage.

HTML – der wiederauferstandene

Hier wird die Geschichte interessant und unerwartet. Im Mai 2026 veröffentlichte Thariq Shihipar, Engineer im Claude-Code-Team bei Anthropic, einen X-Thread mit dem Titel „The Unreasonable Effectiveness of HTML“. Acht Millionen Views, ausgiebige Debatten auf Hacker News und LinkedIn. Die These: HTML schlägt Markdown als Output-Format für moderne KI-Agenten.

Die Begründung ist ungewöhnlich, weil sie nicht primär technisch ist. Shihipars Argument lautet sinngemäß: Markdown-Dateien jenseits von 100 Zeilen liest niemand mehr. Weder er selbst noch sein Team. Wenn ein Agent einen Spec-Plan oder ein Code-Review als 300-Zeilen-Markdown-Wand abliefert, wandert das Ding ungelesen ins Repository und niemand kontrolliert mehr, was die KI eigentlich gerade entschieden hat. HTML mit Tabellen, farbcodierten Severity-Tags, Inline-Diagrammen und interaktiven Elementen löst genau dieses Problem – nicht weil das Modell HTML besser kann als Markdown, sondern weil Menschen es eher lesen. Die Companion-Site mit 20 generierten Beispiel-HTML-Dateien ist als Demonstration sehenswert.

Kritik gibt es reichlich. Markdown ist token-effizienter, HTML kostet pro Output messbar mehr Geld. Nicht jeder Use Case lebt von visueller Aufbereitung. Und die Übertragbarkeit auf GPT oder Gemini ist nicht systematisch belegt – einzelne Tests deuten an, dass es auch dort funktioniert, aber das ist keine Studienlage.

Was natürlich auch niemand offen erzählt, dass Anthropic-intern der Token-Verbrauch relativ schnurzegal ist, zumindest in ihren internen Testreihen.

Drei Architektur-Lehren für die Wahl deiner LLM-Datenformate

Wer das alles in eine produktive Pipeline gießen will, sollte drei Punkte mitnehmen.

Erstens: Reasoning und Strukturierung trennen. Lass das Modell in Markdown frei nachdenken oder gib ihm ein dediziertes reasoning-Feld vor dem answer-Feld. Niemals beides gleichzeitig in ein striktes JSON-Korsett zwingen, das kostet messbar Qualität.

Zweitens: Das richtige Format für die richtige Ebene. YAML und XML für Prompts. JSON oder TOON (aktuell eher noch JSON) für strukturierte Outputs. Markdown für RAG und Mensch-Schnittstelle. HTML für komplexe Artefakte, die jemand wirklich anschauen soll. CSV für reine Bulk-Tabellen. Das ist kein Glaubenskrieg, das ist Werkzeugauswahl.

Drittens: Jeder LLM-Output ist unbereinigter Input. Auch mit Constrained Decoding kann ein Wert semantisch falsch sein. Pydantic, Zod oder gleichwertige Schema-Validierung im Backend, mit Retry-Mechanismus bei Fehlschlag. Wer ohne diese Lage in Produktion geht, debuggt früher oder später um drei Uhr morgens.

Und nein, ein universelles Best-Format gibt es nicht, da bin ich mir zumindest Stand heute sehr sicher.