Ollama mit JSON-Schema: Strukturierte Antworten erzeugen

JSON-Modus oder festes Schema?

Mit format: "json" verlangst du eine JSON-Ausgabe. Ein vollständiges Schema beschreibt zusätzlich, welche Felder und Datentypen erwartet werden. Die Ollama-Dokumentation zu Structured Outputs zeigt beide Varianten.

Ein Schema macht ein Feld nicht automatisch wahr. Wenn das Modell einen Termin erfindet, kann dieser trotzdem als formal gültige Zeichenfolge in der Antwort stehen. Wie sich eine zusätzliche Eigenschaft auswirkt, zeigt unser JSON-Prüftest mit acht künstlichen Antworten. Die Dateien liefen durch zwei feste Prüfregeln; getestet wurde der Datenvertrag, keine Modellleistung.

Wenn ein weiterer Schritt auf Grundlage dieser Felder Werkzeuge aufruft, müssen auch Ziel und erlaubte Aktion kontrolliert werden. Der Guide zu Prompt Injection erklärt die Grenze zwischen fremden Daten und den Berechtigungen deiner Anwendung.

Ein Datenvertrag für eine Serviceanfrage

Unser eigenes Beispiel soll eine kurze Nachricht in drei Felder übersetzen: Betreff, Kategorie und frühester Termin. Die Nachricht lautet: „Bitte prüft den Drucker im Büro. Ein Termin steht noch nicht fest.“ Für das fehlende Datum soll die Antwort null enthalten, kein geratenes Datum.

Speichere folgende Anfrage als anfrage.json. Ersetze DEIN_MODELL durch den Namen eines lokal vorhandenen, für die Aufgabe geeigneten Modells:

{
  "model": "DEIN_MODELL",
  "stream": false,
  "messages": [{
    "role": "user",
    "content": "Extrahiere betreff, kategorie und fruehester_termin. Kategorie: technik oder sonstiges. Verwende null, wenn kein Datum genannt wird. Nachricht: Bitte prueft den Drucker im Buero. Ein Termin steht noch nicht fest."
  }],
  "format": {
    "type": "object",
    "properties": {
      "betreff": {"type": "string"},
      "kategorie": {
        "type": "string",
        "enum": ["technik", "sonstiges"]
      },
      "fruehester_termin": {
        "type": ["string", "null"]
      }
    },
    "required": [
      "betreff", "kategorie", "fruehester_termin"
    ],
    "additionalProperties": false
  }
}

required verlangt das Vorhandensein des Feldes. Es bedeutet in diesem Beispiel nicht, dass dort immer ein Datum stehen muss: Der Typ erlaubt ausdrücklich null. Diese Unterscheidung verhindert, dass dein Datenvertrag fehlende Informationen als vorhandene Werte behandelt.

Anfrage senden und Antwort auslesen

Voraussetzung ist eine erreichbare lokale Ollama-Instanz. Sende die Datei mit cURL an den Chat-Endpunkt: Ist die lokale API nicht erreichbar, kannst du zuerst den Ollama-Port prüfen. Für die Einordnung von Modell, lokaler Laufzeit und API hilft dir der Ollama-Grundlagenguide.

curl http://127.0.0.1:11434/api/chat -H "Content-Type: application/json" --data-binary @anfrage.json

Unter Windows PowerShell kannst du ausdrücklich curl.exe verwenden, damit die cURL-Anwendung aufgerufen wird. Die separate Datei vermeidet komplizierte Verschachtelungen von Anführungszeichen im Terminal.

Die API-Antwort ist ein äußeres Antwortobjekt. Der eigentliche Modelltext steht in message.content. Bei den SDK-Beispielen in der Herstellerdokumentation wird dieser Inhalt anschließend als JSON validiert. Verwechsle also das erfolgreiche Lesen der API-Antwort nicht mit der Prüfung des darin enthaltenen Ergebnisses.

Eine mögliche, hier von uns formulierte Zielausgabe wäre:

{
  "betreff": "Drucker im Büro prüfen",
  "kategorie": "technik",
  "fruehester_termin": null
}

Das ist ein erklärendes Sollbeispiel, keine gemessene Antwort eines bestimmten Modells.

Drei Prüfungen vor der Weiterverarbeitung

1. Syntax: Lässt sich message.content überhaupt als JSON lesen? Behandle Fehler ausdrücklich, statt den ursprünglichen Freitext ungeprüft weiterzureichen.
2. Schema: Sind Pflichtfelder, erlaubte Werte und Datentypen korrekt? Verwende möglichst dasselbe Schema für die Anfrage und die anschließende Validierung. Ollama zeigt dafür Beispiele mit Pydantic und Zod.
3. Inhalt: Stimmen die extrahierten Informationen mit der Originalnachricht überein? Im Beispiel darf aus „noch kein Termin“ kein konkreter Tag werden.

Lege außerdem fest, was bei Unsicherheit passiert. Ein Objekt kann technisch gültig sein und trotzdem eine falsche Kategorie enthalten. Für Aktionen mit Folgen ist ein ausdrücklicher Prüf- oder Freigabeschritt sinnvoll. Wenn eine nachgelagerte Automation das Objekt an eine API senden soll, erklärt n8n HTTP Request die Anfrage- und Antwortprüfung. Die fachliche Freigabe bleibt eine zusätzliche Entscheidung.

Die komplette Antwort mit Fehlerfällen prüfen

Du kannst den vorhandenen Druckerfall jetzt mit einem kleinen lokalen Prüfer nachvollziehen. Er liest die gespeicherte Antwort deiner nicht gestreamten /api/chat-Anfrage. Es gibt zwei JSON-Ebenen: außen die API-Antwort, innen den Text in message.content. Beide müssen lesbar sein. Danach prüfst du Felder und bekannte Sollwerte.

Antwort speichern und lokal prüfen

Verwende die oben erklärte anfrage.json mit einem passenden lokalen Modell und stream: false. Der folgende Aufruf sendet die Anfrage an deine eigene Ollama-Instanz und speichert ihre Antwort; er startet hier auf der Website nichts. Unter Windows PowerShell verwende gegebenenfalls curl.exe.

curl http://127.0.0.1:11434/api/chat -H "Content-Type: application/json" --data-binary @anfrage.json --output antwort-ollama.json
python antwort-pruefen.py antwort-ollama.json

Zum eigenen Versuch: Python-Prüfer herunterladen · Fiktive Antwort zum Probelauf · Fehlerfälle und Sollbefunde.

Lege Prüfer und Antwortdatei in denselben Ordner. Der Prüfer braucht installiertes Python und nur dessen Standardbibliothek. Zum Üben ohne Ollama nutzt du python antwort-pruefen.py beispielantwort.json. Diese Beispieldatei ist eine von uns geschriebene API-Hülle, keine Modellantwort.

Die Sollregel vor dem Versuch festlegen

Für genau diese Vorlage gilt: Der Druckerfall gehört zu technik; ein nicht genannter Termin bleibt echtes JSON-null. Der Betreff darf sinnvoll umformuliert werden. Deshalb prüft das Skript nur, dass er eine nicht leere Zeichenfolge ist. Ob er den Druckerfall korrekt wiedergibt, kontrollierst du selbst am Originaltext.

# Nur lokaler Abgleich der Drucker-Vorlage, keine allgemeine JSON-Schema-Engine.
import json, sys
def parse(raw):
    return json.loads(raw, parse_constant=lambda value: (_ for _ in ()).throw(ValueError(value)))
def check(outer):
    if not isinstance(outer, dict) or outer.get("done") is not True:
        return "antwort_unvollstaendig"
    message = outer.get("message")
    if not isinstance(message, dict) or not isinstance(message.get("content"), str):
        return "inhalt_fehlt"
    try:
        data = parse(message["content"])
    except ValueError:
        return "inneres_json_ungueltig"
    if not isinstance(data, dict) or set(data) != {"betreff", "kategorie", "fruehester_termin"}:
        return "felder_unpassend"
    if not isinstance(data["betreff"], str) or not data["betreff"].strip():
        return "betreff_unpassend"
    if data["kategorie"] not in ("technik", "sonstiges"):
        return "kategorie_unerlaubt"
    if data["fruehester_termin"] is not None and not isinstance(data["fruehester_termin"], str):
        return "termin_typ_unpassend"
    # Eigener Sollvertrag: Druckerfall = technik, kein genanntes Datum = null.
    if data["kategorie"] != "technik" or data["fruehester_termin"] is not None:
        return "inhalt_weicht_ab"
    return "sollfelder_erfuellt"
if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("Aufruf: python antwort-pruefen.py antwort-ollama.json")
    with open(sys.argv[1], encoding="utf-8-sig") as f:
        raw = f.read(1000001)
    if len(raw) > 1000000:
        raise SystemExit("Datei fuer diese kleine Uebung zu gross.")
    try:
        result = check(parse(raw))
    except ValueError:
        result = "aeusseres_json_ungueltig"
    print(result)
    print("Den Betreff weiterhin selbst am Originaltext pruefen; keine Leistungsbewertung.")
    raise SystemExit(0 if result == "sollfelder_erfuellt" else 1)

Das ist ein kleiner Prüfer für diesen einen Datenvertrag, keine allgemeine JSON-Schema-Engine. Er verarbeitet höchstens eine Million Zeichen, führt keinen Modellcode aus und sendet nichts ins Netzwerk. Für andere Schemata und Aufgaben brauchst du passende Validierung sowie eigene Inhaltsregeln. Die aktuelle Chat-Referenz dokumentiert die äußere Antwort und done; die Schema-Grundlage steht in der bereits verlinkten Structured-Outputs-Anleitung.

Grenzen und Fehlersuche

Die am 5. Oktober 2026 geprüfte Ollama-Dokumentation nennt Structured Outputs als derzeit nicht in Ollama Cloud unterstützt. Die Anleitung bezieht sich deshalb auf die lokale API. Übertrage ein funktionierendes lokales Beispiel nicht ungeprüft auf einen anderen Endpunkt.

Beginne bei Fehlern mit einem kleinen Schema und einer kurzen Eingabe. Prüfe Modellname, Ollama-Version und gegebenenfalls die verwendete Clientbibliothek. Ergänze zusätzliche Felder erst, wenn der einfache Ablauf verstanden ist.

Die Dokumentation empfiehlt eine niedrigere Temperatur für gleichmäßigere Ausgaben. Das ersetzt weder Schema- noch Inhaltsprüfung und ist keine Garantie für identische oder sachlich richtige Ergebnisse. Für eine belastbare Qualitätsaussage brauchst du eigene Testfälle mit bekannten Sollwerten, einschließlich fehlender und widersprüchlicher Angaben.