Diese Woche drehte sich um vorhersehbare, prüfbare Outputs: Prompt-Struktur, Constraints/Rollen, Schema-first, Validierungsschleifen, Evaluation-Prompts und Anti-Patterns. In der Prüfung kommen diese Themen selten als „Definiere X“, sondern als Szenario: Du bekommst ein Ziel (z. B. Daten extrahieren, Entscheidung begründen, Workflow robust machen) und musst erklären, wie du Claude so steuerst, dass das Ergebnis zuverlässig und auditierbar ist.
1. Input- und Output-Contract: Was sind erlaubte Eingaben? Was ist das exakte Ziel-Format (JSON, Markdown, Tabellenstruktur)?
2. Constraints explizit: Längenlimits, Pflichtfelder, verbotene Inhalte, Quellenregeln („nur aus dem gegebenen Text“).
3. Schema-first: Definiere Felder, Typen, Enumerations, Required vs. Optional, Fehlermeldungsformat.
4. Validation & Repair: Plane eine Schleife ein: „validate → report errors → repair only those parts“.
5. Evaluation als eigener Schritt: Eine separate Checkliste/Rubric („ist jedes Feld belegt? sind Datentypen korrekt? stimmen Einheiten?“).
6. Anti-Patterns erkennen: zu vage Ziele, widersprüchliche Constraints, versteckte Annahmen („die Rechnung ist bestimmt in EUR“), Overprompting.
Aufgabe: Du sollst aus Support-Tickets strukturierte Daten für ein Dashboard extrahieren (Kategorie, Dringlichkeit, betroffene Komponente, Kurzfassung).
Guter Ansatz:
Prüfungssatz: Du maximierst Zuverlässigkeit, indem du Unsicherheit explizit machst und Halluzinationen durch Contract + Validierung abfängst.
Aufgabe: Ein Agent soll Angebote vergleichen und eine Kaufempfehlung geben. Risiko: Marketing-Texte, fehlende Daten, prompt injection in Produktbeschreibungen.
Guter Ansatz:
1. Contracts > Charme: Ein präzises Input/Output-Contract (Schema + Regeln) schlägt „schöne“ Prompts.
2. Validate/Repair als Standardmuster: Fehler passieren; entscheidend ist, dass dein System sie detektieren und korrigieren kann.
3. Szenario-Denken: In Exam-Fragen zählt der Ablauf (Extraktion → Validierung → Bewertung) und die Begründung der Trade-offs.
Du extrahierst Rechnungsdaten in JSON. Der Modell-Output verletzt das Schema (Datum falsch formatiert, `total_amount` als String) und ein Feld wurde frei erfunden. Welche Prompt-/Workflow-Änderung ist am wirksamsten?
Führe einen Schema-first Contract ein und ergänze eine Validation+Repair Schleife: erst JSON validieren, dann nur die konkreten Schema-Fehler korrigieren; bei nicht belegbaren Feldern `null` + Flag setzen. Zusätzlich: klare Regel „nur aus Input ableiten, sonst unknown“ verhindert erfundene Werte.