Output Validation ist der Schritt zwischen „Das Modell hat etwas geliefert“ und „Wir dürfen damit weiterarbeiten“. Für die Prüfung ist das wichtig, weil viele Architekturfragen genau dort kippen: Nicht der erste Prompt ist das Problem, sondern die fehlende Kontrolle danach. Ein guter Agent produziert also nicht einfach Output, sondern prüft aktiv, ob Format, Vollständigkeit und inhaltliche Mindestanforderungen erfüllt sind. Erst dann geht es weiter.
Der erste Baustein ist explizite Validierung. Wenn ein Modell JSON liefern soll, reicht „bitte als JSON antworten“ nicht. Du brauchst eine überprüfbare Regel: Schema-Check, Pflichtfelder, Datentypen, erlaubte Werte, maximale Länge oder Regex-Muster. Gleiches gilt für Text-Outputs. Auch ein Freitext kann validiert werden, zum Beispiel auf vorhandene Abschnitte, Bullet-Anzahl, verbotene Begriffe oder Mindestbegründung. Der Prüfungswinkel: Gute Systeme verlassen sich nicht auf Höflichkeit im Prompt, sondern auf maschinell prüfbare Kriterien.
Der zweite Baustein ist die Trennung von syntaktischer und semantischer Validierung. Syntaktisch heißt: Ist das Format korrekt, zum Beispiel valides JSON mit den richtigen Feldern? Semantisch heißt: Ergibt der Inhalt Sinn? Ein Feld `priority` kann formal vorhanden sein und trotzdem einen ungültigen Wert tragen. Für die Prüfung ist genau diese Unterscheidung wichtig: formal korrekt ist nicht automatisch fachlich brauchbar.
Dann kommen Auto-Repair Loops ins Spiel. Das Muster ist einfach: Modell erzeugt Output, Validator prüft, bei Fehlern gibt das System gezieltes Feedback und fordert eine Korrektur an. Wichtig ist dabei: kein kompletter Neustart, sondern eine präzise Rückmeldung wie „Feld `owner` fehlt“ oder „liefere nur gültiges JSON“. Dadurch steigt die Trefferquote oft deutlich, ohne unnötige Kosten.
Aber: Auto-Repair braucht Grenzen. Sonst entsteht eine Endlosschleife mit steigenden Kosten und unklarem Verhalten. Deshalb definierst du meist 1 bis 3 Repair-Versuche, klares Logging und danach einen Fallback. Typische Fallbacks sind: einfacherer Prompt, kleinerer Scoped Task, anderer Modell-Tier oder Human Handoff. Für die Prüfung ist „bounded retries + fallback“ fast immer stärker als „retry until success“.
Praktisch sieht ein robuster Flow so aus: 1) Modell generiert strukturierten Output. 2) Ein Validator prüft Schema und Business Rules. 3) Bei Fehlern erstellt das System eine kompakte Fehlerliste. 4) Das Modell bekommt diese Fehler plus die Anweisung zur Korrektur. 5) Nach wenigen Versuchen wird eskaliert oder sauber abgebrochen. Das ist vorhersehbar und testbar.
Architektonisch ist der eigentliche Punkt: Validation und Repair sind eigene Systemschritte, nicht bloß gute Prompt-Formulierung.
Du baust einen Agenten, der Support-Tickets als JSON klassifiziert und danach automatisch an ein Workflow-System übergibt. Welches Design ist am robustesten?
A) Ein sehr detaillierter Prompt ohne nachgelagerte Prüfung
B) JSON-Ausgabe mit Schema-Validierung, begrenzten Repair-Versuchen und anschließendem Fallback
C) Freitext-Antwort, die das nächste System „schon irgendwie versteht“
D) Unbegrenzte Retries, bis der Output gültig ist
B ist richtig. In produktionsreifen Agentensystemen wird Output nicht einfach vertraut, sondern validiert und bei klaren Fehlern gezielt repariert. Begrenzte Retries plus Fallback reduzieren Kosten, verhindern Endlosschleifen und machen das Verhalten prüfbar und zuverlässig.