Viele Agent-Systeme scheitern nicht daran, dass Claude „zu schwach“ wäre, sondern daran, dass nach der ersten Antwort niemand mehr prüft, ob das Ergebnis wirklich brauchbar ist. Genau hier kommen Evaluation-Prompts ins Spiel. Die Idee ist simpel: Du behandelst Qualitätsprüfung als eigenen Architektur-Schritt, nicht als Hoffnung. Statt nur „erzeuge eine Lösung“ zu sagen, planst du zusätzlich ein: „prüfe die Lösung gegen klare Kriterien“. Für die Exam-Perspektive ist das wichtig, weil Foundations-Fragen oft testen, ob du robuste Workflows von naiven Einzelschritten unterscheiden kannst.
Ein Evaluation-Prompt ist also kein normaler User-Prompt, sondern eine gezielte Prüfanweisung. Er bewertet einen vorhandenen Output entlang definierter Maßstäbe: Korrektheit, Vollständigkeit, Format-Treue, Sicherheits-Compliance, Quellenbezug oder Aufgabenabdeckung. Typisch ist ein Flow wie: generate → evaluate → repair → finalisieren. Damit verschiebst du Qualität von „implizit erwartet“ zu „explizit gemessen“.
Wichtig: Ein guter Evaluation-Prompt braucht klare Kriterien. Wenn du nur fragst „Ist das gut?“, bekommst du weiche, unzuverlässige Antworten. Besser ist: „Prüfe, ob alle drei Anforderungen erfüllt sind, ob die Antwort im JSON-Schema validierbar ist und ob sicherheitskritische Anweisungen ignoriert wurden.“ Je konkreter die Checkliste, desto reproduzierbarer die Bewertung. In der Praxis sind Rubrics, Ja/Nein-Checks und strukturierte Fehlertypen sehr nützlich.
Ein häufiger Architekturfehler ist, Generator und Evaluator nicht sauber zu trennen. Wenn dasselbe Modell im selben Schritt gleichzeitig erzeugt und beurteilt, steigt das Risiko von Selbstbestätigung. Besser ist ein separater Prüfschritt mit anderer Prompt-Rolle, klaren Kriterien und wenn nötig anderem Modell-Tier. Für teure oder kritische Workflows kannst du zunächst günstig erzeugen und dann selektiv hochwertig evaluieren. Das spart Kosten und erhöht Zuverlässigkeit.
Evaluation-Prompts sind besonders stark bei vier Dingen: Erstens Formatprüfung, etwa ob JSON wirklich dem Schema entspricht. Zweitens Content-Abdeckung, also ob alle User-Anforderungen beantwortet wurden. Drittens Sicherheits-Checks, zum Beispiel Prompt-Injection, Policy-Verstöße oder unerlaubte Tool-Nutzung. Viertens Qualitätsranking, wenn mehrere Kandidaten vorliegen und der beste ausgewählt werden soll.
Exam-relevant ist auch der Unterschied zwischen subjektiver und operativer Evaluation. „Klingt professionell“ ist weich. „Enthält genau 5 Felder, keine Halluzinationsmarker, referenziert nur erlaubte Datenquellen“ ist operativ und testbar. Foundations bevorzugt fast immer die zweite Variante, weil sie sich in Systeme, Guardrails und Automatisierung übersetzen lässt.
Die beste mentale Abkürzung für die Prüfung: Evaluation ist kein Nice-to-have nach dem Prompting, sondern Teil der Kontrollschicht deines Agenten. Wenn ein Szenario nach Reliability, Structured Output oder sicherer Tool-Ausführung fragt, ist ein dedizierter Eval-Schritt oft die robustere Antwort als „mehr Prompting“.
Du baust einen Agenten, der Support-Antworten im festen JSON-Format erzeugt und keine nicht freigegebenen Rückerstattungen versprechen darf. Welche Architektur ist am robustesten?
A) Ein einziger, sehr detaillierter Generierungs-Prompt
B) Generierung + separater Evaluation-Prompt für Schema, Policy und Vollständigkeit + Repair bei Fehlern
C) Zwei Generierungsversuche und Auswahl der längeren Antwort
D) Nur ein menschlicher Review am Ende, ohne automatische Checks
Richtig ist B. Die Kombination aus Generierung, expliziter Evaluation und gezielter Reparatur ist am robustesten, weil sie sowohl Format- als auch Policy-Fehler systematisch erkennt. Genau das passt zu Foundations-Prinzipien: kontrollierbare, prüfbare und zuverlässige Agent-Workflows statt bloßer Hoffnung auf den ersten Output.