Strukturierte Ausgaben
Wer Ergebnisse weiterverarbeiten will, braucht vorhersagbare Formate. LLMs können ihre Antworten gezielt strukturieren - als Tabelle, JSON, Markdown oder nach einer Vorlage.
Solange du die Antwort selbst liest, ist Fließtext in Ordnung. Sobald aber ein Programm die Antwort weiterverarbeitet - eine Tabelle füllt, eine Datenbank beschreibt, eine Website baut - wird Fließtext zum Problem. Dann brauchst du Struktur.
Warum Struktur mehr als Kosmetik ist
Merksatz
Ein Format ist nicht nur eine Darstellungsform - es ist ein Denkraster. Wer neun Felder eines Canvas vorgibt, zwingt das Modell, an alle neun zu denken.
Ein vorgegebenes Format bewirkt gleich dreierlei:
- Vollständigkeit - leere Felder fallen sofort auf.
- Vergleichbarkeit - zwei Antworten lassen sich nebeneinanderlegen.
- Weiterverarbeitbarkeit - Python kann das Ergebnis direkt einlesen.
Vier bekannte Formate
Wofür: Vergleiche, Bewertungen, alles mit gleichen Merkmalen über mehrere Objekte.
Vergleiche die drei Vertriebskanäle in einer Markdown-Tabelle
...mit den Spalten: Kanal | Reichweite | Kosten | Aufwand.
...Eine Zeile pro Kanal, keine Erklärung davor oder danach.
✅ Sehr lesbar für Menschen · ❌ mühsam maschinell auszuwerten, wenn Zellen Kommas enthalten.
Wofür: alles, was ein Programm weiterverarbeiten soll.
Antworte ausschließlich mit gültigem JSON, ohne Markdown-Codeblock
...und ohne Erklärung. Schema:
...
...{
... "idee": "<string>",
... "risiken": [{"titel": "<string>", "schwere": "hoch|mittel|niedrig"}],
... "bewertung": <zahl 1-10>
...}
✅ Direkt in Python einlesbar · ❌ kleine Modelle produzieren gern fast gültiges JSON (siehe Labor unten).
Wofür: Dokumentation, Berichte, Website-Inhalte - Text mit Gliederung.
Gib das Ergebnis als Markdown aus:
...- eine H2-Überschrift pro Abschnitt
...- darunter maximal 3 Stichpunkte
...- Fachbegriffe **fett**
...Keine Einleitung.
✅ Menschenlesbar und strukturiert · ❌ kein festes Schema erzwingbar.
Wofür: wiederkehrende Dokumente mit fester Gliederung.
Fülle exakt diese Vorlage aus. Ersetze nur die <Platzhalter>,
...ändere nichts an der Struktur:
...
...PRODUKT: <name>
...ZIELGRUPPE: <eine Zeile>
...NUTZEN: <maximal 20 Wörter>
...PREIS: <zahl> EUR
...RISIKO: <ein Satz>
✅ Funktioniert auch bei sehr kleinen Modellen ⭐ · ❌ unflexibel bei variabler Feldanzahl.
Der Preis der Struktur ⚖️
Struktur ist nicht gratis. Tam et al.2 haben gemessen, was passiert, wenn man Modelle zu striktem JSON zwingt: Auf Denkaufgaben fiel die Leistung teilweise deutlich ab - je enger das Format, desto stärker der Einbruch.
Die Erklärung ist einleuchtend: Beim freien Antworten kann ein Modell „laut mitdenken" und sich über Zwischenschritte zur Lösung vorarbeiten. Ein festes Schema erzwingt die Antwort sofort, ohne Umweg.
👉 Praktische Regel: Erst denken lassen, dann formatieren. Nutze zwei Schritte (Prompt Chaining) - Schritt 1 analysiert frei, Schritt 2 gießt das Ergebnis in JSON. Das ist zuverlässiger als beides in einem Prompt zu verlangen.
Die Format-Rangfolge für kleine Modelle
Je kleiner das Modell, desto einfacher muss das Format sein:
Vorlage (am robustesten) → Markdown → Tabelle → JSON (am fehleranfälligsten)
Wenn gemma3:1b an deinem JSON scheitert: nimm eine SCHLÜSSEL: Wert-Vorlage und wandle sie in Python selbst in JSON um. Das ist fast immer schneller als drei weitere Prompt-Iterationen.
Der Ollama JSON-Modus
Ollama kann das Modell technisch dazu zwingen, gültiges JSON zu erzeugen - mit der Option --format json:
ollama run --format json gemma3:1b "Nenne 3 Risiken für einen Bio-Lieferdienst. Antworte als JSON mit dem Schlüssel 'risiken', jeder Eintrag mit 'titel' und 'schwere' (hoch, mittel oder niedrig)."
{
"risiken": [
{"titel": "Kühlkette bei der Zustellung", "schwere": "hoch"},
{"titel": "Verderb bei schwankender Nachfrage", "schwere": "mittel"},
{"titel": "Preisdruck durch Supermärkte", "schwere": "hoch"}
]
}
Diese Option erzwingt syntaktisch gültiges JSON auf Ebene der Token-Auswahl: Tokens, die das JSON ungültig machen würden, werden gar nicht erst zur Auswahl zugelassen. Das Modell kann damit kein kaputtes JSON mehr erzeugen.1
Gültig ≠ richtig
--format json garantiert nur die Syntax, nicht das Schema. Du bekommst garantiert gültiges JSON - aber vielleicht so:
{
"risks": [
{"name": "Kühlkette", "severity": "sehr hoch"}
]
}
Englische Schlüssel, andere Feldnamen, ein Wert außerhalb der drei erlaubten. Syntaktisch einwandfrei, für die Weiterverarbeitung wertlos.
👉 Beschreibe das Schema trotzdem im Prompt - und prüfe die Ausgabe.
🔬 Ollama-Lab
Alles ab hier drehst du an deiner eigenen Geschäftsidee. Die Beispiele oben im Kapitel zeigen das Verfahren - hier wendest du es an. Terminal auf, ollama run gemma3:1b, los.
Erst die Messbedingungen
Dieses Lab besteht fast nur aus Zähllaufen. Damit du Formattreue misst und nicht irgendwelche Zufallsergebnisse bekommst, gilt hier durchgehend die Regel aus dem Setup: /set parameter temperature 0.2 und /clear vor jedem Lauf.
Und du brauchst ein Prüfmittel. „Sieht nach JSON aus" reicht nicht - genau die subtilen Fehler (ein Komma zu viel, eine fehlende Klammer) übersieht das Auge. Lass die Maschine urteilen:
ollama run gemma3:1b --format json "Nenne 3 Ursachen für Schlaflosigkeit" | python -m json.tool
Kommt eingerücktes JSON zurück, war die Antwort gültig. Kommt Expecting value oder Extra data, war sie es nicht - unabhängig davon, wie gut sie aussah.
Übung 1: Wie zuverlässig ist JSON?
Lass dir drei Risiken deiner Geschäftsidee als JSON ausgeben - Schlüssel risiken, je Eintrag titel und schwere.
Führe das fünfmal ohne und fünfmal mit --format json aus.
Zähle: Wie oft ist das Ergebnis wirklich gültiges JSON? Achte besonders auf einleitende Sätze, umschließende Codeblöcke und Kommas zu viel.
Übung 2: Der Reparatur-Prompt
Wenn ein Format nicht stimmt, fang nicht von vorn an. Sag im selben Chat, was falsch war:
Deine Antwort enthielt einleitenden Text.
...Gib das JSON erneut aus - ohne jeden Text davor oder danach.
Probiere aus: Wie oft brauchst du diese Korrekturrunde? Und reicht eine, oder musst du nachfassen?
Die Abbruchregel: Nach zwei erfolglosen Reparaturversuchen hörst du auf zu bitten und baust den Prompt um. Wer dreimal nachfasst, hat den Chat mit lauter fehlerhaften Beispielen gefüllt - und die stehen jetzt als Kontext im Fenster und machen den nächsten Fehler wahrscheinlicher. /clear und neu formulieren ist ab da schneller.
Übung 3: Dein Canvas in mehreren Formaten
Erzeuge dein Business Model Canvas in zwei Formaten deiner Wahl - eines für Menschen (Tabelle oder Markdown), eines für Maschinen (JSON oder Vorlage).
Führe jedes Format fünfmal aus und notiere die Fehlversuche.
Speichere den zuverlässigsten Prompt im lab_log.md unter ## 03 Canvas strukturiert.
🐍 Optional (Python): JSON einlesen und Schema prüfen
Der Punkt von JSON ist die Weiterverarbeitung. So sieht sie aus:
import json
import ollama
ERLAUBTE_SCHWERE = {"hoch", "mittel", "niedrig"}
antwort = ollama.chat(
model="gemma3:1b",
messages=[{"role": "user", "content":
"Nenne 3 Risiken für einen Bio-Lieferdienst. JSON mit "
"Schlüssel 'risiken', je Eintrag 'titel' und 'schwere'."}],
format="json",
options={"temperature": 0.1},
)["message"]["content"]
daten = json.loads(antwort)
for i, eintrag in enumerate(daten.get("risiken", []), start=1):
titel = eintrag.get("titel", "???")
schwere = str(eintrag.get("schwere", "")).lower()
ok = "✅" if schwere in ERLAUBTE_SCHWERE else "❌"
print(f"{ok} [{schwere:>9}] {titel}")
✅ [ hoch] Kühlkette bei der Zustellung
✅ [ mittel] Verderb bei schwankender Nachfrage
❌ [sehr hoch] Preisdruck durch Supermärkte
Beachte den dritten Eintrag: Das JSON ist syntaktisch gültig, aber "sehr hoch" steht nicht in der erlaubten Menge. Genau deshalb reicht format="json" allein nicht - die Schema-Prüfung musst du selbst machen.
Quellen
Zur Ausarbeitung wurden generative Tools unterstützend eingesetzt.
-
B. T. Willard and R. Louf, "Efficient guided generation for large language models," arXiv:2307.09702, 2023. ↩
-
Z. R. Tam, C.-K. Wu, Y.-L. Tsai, et al., "Let me speak freely? A study on the impact of format restrictions on performance of large language models," arXiv:2408.02442, 2024. ↩