Entwickler können nun die Kosten für das Korrigieren von fehlerhaftem JSON aus Large Language Models (LLMs) unter Kontrolle halten, indem sie die Reparaturversuche auf zwei begrenzen, wie eine einfache Python-Schleife zeigt. Das Muster – generieren, parsen, validieren, wiederholen, dann akzeptieren oder scheitern – verwandelt „vielleicht gültiges JSON“ in eine messbare Erfolgsquote und verhindert unkontrollierten Token-Verbrauch.

Warum eine Reparatur-Schleife wichtig ist

LLMs werden oft angewiesen, „JSON zurückzugeben“, doch die Ausgabe enthält häufig Syntaxfehler, fehlende Schlüssel oder Werte, die Geschäftsregeln verletzen. Ein nachgelagertes System, das eine strikte Payload erwartet, wird abstürzen oder falsche Ergebnisse liefern, wenn es mit einer solchen Ausgabe gefüttert wird. Ohne eine systematische Methode, um diese Probleme zu erfassen und zu korrigieren, müssen Teams entweder eine hohe Fehlerrate akzeptieren oder Geld verschwenden, indem sie das Modell wiederholt anweisen, bis es es richtig macht.

Die drei Validierungsebenen

Eine zuverlässige Schleife unterteilt die Validierung in:

  • Syntax – lässt sich der String überhaupt als JSON parsen?
  • Struktur – enthält das Top-Level-Objekt genau die erwarteten Schlüssel?
  • Semantik – halten die Werte die Domänenbeschränkungen ein (zum Beispiel muss eine „Kategorie“ zu einem vordefinierten Satz gehören)?

Indem die Schleife beim ersten fehlschlagenden Layer stoppt, kann sie dem Modell eine präzise Fehlermeldung geben, was die Chancen auf eine korrekte Korrektur beim nächsten Versuch drastisch erhöht.

Minimales Python-Beispiel

Der folgende Code verwendet ausschließlich die Standardbibliothek. Er definiert ein winziges Schema (ein Dictionary mit den Schlüsseln category und summary) und eine feste Liste erlaubter Kategorien.

import json

CATEGORIES = {"bug", "feature", "question"}

def validate(raw: str):
    try:
        value = json.loads(raw)
    except json.JSONDecodeError as exc:
        return None, f"syntax: {exc.msg}"

    if not isinstance(value, dict):
        return None, "shape: root must be an object"
    if set(value) != {"category", "summary"}:
        return None, "shape: expected category and summary"
    if value["category"] not in CATEGORIES:
        return None, "semantic: invalid category"
    if not isinstance(value["summary"], str) or not value["summary"].strip():
        return None, "semantic: summary must be text"

    return value, None

Die Reparatur-Schleife selbst legt eine harte Obergrenze für die Versuche fest:

MAX_ATTEMPTS = 2
raw = model_response   # initial LLM output

for attempt in range(MAX_ATTEMPTS + 1):
    value, error = validate(raw)
    if error is None:
        break
    if attempt == MAX_ATTEMPTS:
        raise RuntimeError(f"failed after {MAX_ATTEMPTS} retries: {error}")

    # Send the error and schema back to the model for a fix
    raw = ask_model_to_repair(raw, error)

Wenn das JSON beim ersten Durchlauf die Validierung besteht, bricht die Schleife sofort ab. Andernfalls wird ein erneuter Versuch unternommen, wobei dem Modell eine prägnante Payload übergeben wird: die ursprüngliche Ausgabe, der exakte Fehlerstring und das erwartete Schema. Nach zwei fehlgeschlagenen Versuchen bricht der Prozess mit einer klaren Exception ab.

Zwei Regeln für kosteneffiziente Reparaturen

  1. Halten Sie Reparatur-Prompts kompakt – Geben Sie nur das rohe JSON, die Fehlermeldung und das Schema an. Das Hinzufügen eines langen Chat-Verlaufs bläht den Token-Verbrauch auf und kann das Modell verwirren, was die Kosten pro Wiederholung erhöht, ohne die Genauigkeit zu verbessern.

  2. Trennen Sie Validierung von der Faktenprüfung – Der Parser kann strukturelle Probleme erkennen, aber er kann nicht verifizieren, ob eine „Zusammenfassung“ wahr ist. Die Faktenprüfung gehört in eine spätere Phase; der Versuch, eine falsche Behauptung zu „reparieren“, lässt die Lüge lediglich sauberer aussehen.

Erfolgsmessung

Das Protokollieren des Fehlertyps jedes Versuchs (Syntax, Struktur, Semantik) und ob die Schleife erfolgreich war, liefert eine konkrete Kennzahl: den Anteil der LLM-Antworten, die innerhalb der begrenzten Wiederholungen nutzbar werden. Teams können dies im Zeitverlauf verfolgen, Prompt-Stile vergleichen oder mit verschiedenen Schema-Definitionen experimentieren.

Potenzielle Nachteile

Die Begrenzung der Schleife bedeutet, dass einige fehlerhafte Ausgaben verworfen werden, sobald das Limit erreicht ist, was die Gesamtausfallrate erhöhen kann, wenn die Rohqualität des Modells niedrig ist. In Umgebungen, in denen jede Antwort kritisch ist, bevorzugen Entwickler möglicherweise eine höhere Anzahl an Wiederholungen auf Kosten zusätzlicher Token. Der Kompromiss ist eindeutig: höhere Kosten für eine größere Abdeckung oder engere Budgets mit einer vorhersehbaren Obergrenze.

Was als Nächstes zu beachten ist

  • Prompt Engineering für Reparaturen – Die Verfeinerung des Formats der Fehlermeldung kann die Anzahl der benötigten Wiederholungen reduzieren.
  • Alternative Parser – Einige Bibliotheken bieten ein tolerantes Parsing an, das kleinere Probleme automatisch korrigieren kann; ein Vergleich ihrer Kosten mit einer begrenzten Schleife ist lohnenswert.
  • Modell-Updates – Neuere LLM-Versionen liefern möglicherweise von Haus aus saubereres JSON, was es potenziell ermöglicht, das Limit für Wiederholungen weiter zu senken.

Eine begrenzte JSON-Reparatur-Schleife bietet Entwicklern ein praktisches Werkzeug, um ungenaue LLM-Ausgaben in zuverlässige Daten zu verwandeln, ohne dass die Kosten explodieren. Indem sie die Validierung als wichtigen Schritt behandeln und die Wiederholungen begrenzen, können Teams sowohl die Budgets als auch die nachgelagerten Systeme zufriedenstellen.