Few-Shot Prompting für robuste Agent-Outputs

Few-Shot Prompting bezeichnet die Technik, einem AI-Agenten im Prompt einige wenige Beispiele für korrekte Ein- und Ausgaben mitzugeben, damit er Format, Stil und Logik einer Aufgabe per In-Context Learning übernimmt, ohne dass das Modell nachtrainiert wird. Statt das Verhalten in Prosa zu beschreiben, zeig es: zwei bis fünf repräsentative Fälle, an denen sich das Modell für den nächsten Inferenz-Turn ausrichtet. Für produktionsreife Agenten ist Few-Shot keine Spielerei, sondern einer der wirksamsten Hebel für zuverlässige Output-Formate und korrektes Tool-Calling.

• Wie viele: Zwei bis fünf Beispiele für den allgemeinen Output, ein bis drei kanonische Aufrufe pro Tool. Mehr hilft selten linear.
• Welche: Diverse, repräsentative Fälle ohne Duplikate und ohne Widersprüche. Qualität und Abdeckung schlagen Quantität.
• Wann nicht: Bei einfachen Zero-Shot-Tasks oder wenn 100-Prozent-Format-Treue gefordert ist, hier ist Schema-constrained Decoding überlegen.

Few-Shot im Kontext: ein Baustein des Context Engineering

Few-Shot Prompting ist kein eigenständiges Verfahren neben Prompt Engineering, sondern eine Sub-Disziplin innerhalb des Context Engineering. Andrej Karpathy nennt "few-shot examples" explizit als einen der wissenschaftlichen Bausteine, mit denen das Kontextfenster für den nächsten Schritt befüllt wird, neben Task-Beschreibungen, RAG, Tools und State. Das mentale Modell für Agenten lautet entsprechend: Beispiele sind Teil des Token-Substrats, das das Modell pro Turn sieht, nicht eine einmalige Instruktion.

Diese Einordnung hat praktische Konsequenzen. Beispiele konkurrieren mit allem anderen um Aufmerksamkeitsbudget und Token-Platz. Wer Few-Shot einsetzt, muss es im Rahmen des Context-Budgets betrachten, nicht isoliert.

Zero-Shot, Few-Shot, One-Shot

• Zero-Shot: Nur die Aufgabenbeschreibung, keine Beispiele. Schnell, günstig, ideal für einfache oder offensichtliche Aufgaben.
• One-Shot: Genau ein Beispiel. Nützlich, um ein eindeutiges Format ohne große Token-Last zu verankern.
• Few-Shot: Mehrere Beispiele, die Varianten und Edge-Cases abdecken. Der Standard für format- und logikkritische Agent-Outputs.

Auswahl und Repräsentativität: das eigentliche Engineering

Der häufigste Fehler ist nicht die falsche Anzahl, sondern die falsche Auswahl. Ein typisches Anti-Pattern in System-Prompts: Mehrere widersprüchliche Beispiele verleiten das Modell, das nächstgelegene zu kopieren. Die Korrektur sind diverse, kanonische Beispiele ohne Duplikate. Anthropic empfiehlt in seinem Leitfaden zu Context Engineering vom September 2025 ebenfalls diverse, kanonische Beispiele, statt jede Regel als lange Liste von Edge-Cases in den Prompt zu schreiben.

Konkret bedeutet repräsentative Auswahl:

• Varianten abdecken, nicht denselben Fall dreimal in leichter Abwandlung. Wenn ein Agent Rechnungen, Gutschriften und Stornos verarbeitet, gehört je ein Beispiel hinein, nicht drei Rechnungen.
• Edge-Cases bewusst zeigen, etwa einen Fall mit fehlenden Pflichtfeldern und die korrekte Reaktion darauf. Beispiele lehren auch das Verhalten bei Unschärfe.
• Konsistentes Format über alle Beispiele. Format-Drift zwischen den Beispielen ist Gift, das Modell repliziert die Inkonsistenz.
• Keine widersprüchlichen Signale. Wenn Beispiel A ein Feld weglässt und Beispiel B es füllt, ohne dass der Unterschied erklärbar ist, rät das Modell.

Einfluss auf Tool-Calling und Output-Zuverlässigkeit

Hier zahlt Few-Shot am stärksten ein. Für die Tool-Definition hat Anthropic im November 2025 Tool Use Examples eingeführt: ein input_examples-Feld, das Beispielaufrufe direkt neben dem Schema mitliefert. Anthropic empfiehlt 1 bis 5 realistische Beispiele pro Tool, in internen Tests stieg die Genauigkeit bei komplexen Parametern damit von 72 auf 90 Prozent. Ohne Beispiele rät das Modell bei verschachtelten oder optionalen Parametern. Als Faustregel genügen meist ein bis drei kanonische Aufrufe pro Tool, denn jedes Beispiel kostet Tokens. Die Verbindung zur Tool-Selection-Zuverlässigkeit ist eng: Im selben Beitrag berichtet Anthropic, dass das Tool Search Tool bei großen Tool-Bibliotheken die Tool-Selection-Accuracy in internen MCP-Evals auf Opus 4 von 49 auf 74 Prozent und auf Opus 4.5 von 79,5 auf 88,1 Prozent hebt. Gute Beispiele in der Tool-Description sind Teil derselben Disziplin.

Für den finalen Output gilt eine wichtige Abgrenzung. Wo verbindlich maschinen-parsbare Strukturen gefordert sind, ist Few-Shot allein nicht hinreichend. OpenAI Structured Outputs (GA seit August 2024, für GPT-4o-2024-08-06 und Nachfolger) erzwingt über Constrained Decoding auf Token-Ebene eine dokumentierte 100-Prozent-Schema-Adherence. Anthropic hat im November 2025 nachgezogen: Structured Outputs für Claude starteten als Beta und sind seit Februar 2026 allgemein verfügbar. JSON-Outputs laufen über output_config.format, Tool-Aufrufe über Strict Tool Use mit strict: true, beide per Constrained Decoding. Der frühere Behelf, erzwungenes Tool-Use mit einem Pseudo-Tool wie return_structured_result, garantiert ohne strict keine Schema-Treue: Laut Anthropic-Doku kann Claude dann falsche Typen liefern oder Pflichtfelder weglassen. Die saubere Arbeitsteilung 2026: Schema-Enforcement garantiert die Struktur, Few-Shot prägt Stil, Wortwahl, Logik und die Behandlung von Grenzfällen, die kein Schema abbildet.

Wann Few-Shot, wann Zero-Shot, wann Fine-Tuning

Die Entscheidung folgt drei Achsen: Aufgabenkomplexität, Volumen und Stabilität der Anforderungen.

• Zero-Shot, wenn die Aufgabe einfach ist und das Format unkritisch. Jeder zusätzliche Beispiel-Token wäre verschwendet.
• Few-Shot, sobald ein bestimmtes Format, ein konsistenter Stil oder eine nicht triviale Logik gefordert ist und die Anforderungen sich noch ändern. Few-Shot ist ohne Trainingszyklus iterierbar, das ist sein größter Vorteil.
• Fine-Tuning, erst bei sehr hohem, stabilem Volumen, wenn die Beispiel-Tokens pro Call wirtschaftlich ins Gewicht fallen oder Latenz kritisch wird. Cognition Labs hat für Devin ein eigenes kleineres Summarization-Modell auf eigenen Trace-Daten trainiert, weil generische Prompts zu viele Details verloren, ein klassischer Fall, in dem Few-Shot an seine Grenze stieß.

Eine Zwischenstufe verdient Erwähnung: Bei der LLM-as-Judge-Verifikation sind Few-Shot-Beispiele im Judge-Prompt (positive und negative) Standard. Hamel Husains Empfehlung lautet, solche Judge-Evals mit über 100 gelabelten Beispielen zu kalibrieren und wöchentlich zu warten. Das zeigt die Grenze zwischen Few-Shot im Prompt (wenige Beispiele) und der Eval-Datenbasis (viele Beispiele) dahinter.

Stolperfallen: Overfitting und Token-Kosten

Overfitting auf Beispiele ist die subtilste Falle. Der Agent kopiert Oberflächenmerkmale der Beispiele, etwa eine bestimmte Reihenfolge oder Formulierung, statt die zugrunde liegende Regel zu generalisieren. Symptom: Bei Inputs, die den Beispielen ähneln, ist der Output perfekt, bei abweichenden Fällen bricht er ein. Gegenmittel ist gezielte Diversität der Beispiele und ein Eval-Set, das gerade die nicht abgedeckten Fälle prüft.

Token-Kosten und Context Rot sind die zweite Falle. Jedes Beispiel läuft bei jedem Call mit. Die Chroma-Studie Context Rot vom Juli 2025 hat 18 Modelle getestet, darunter GPT-4.1, Claude 4, Gemini 2.5 und Qwen3. Über alle Experimente hinweg sank die Leistung mit wachsender Input-Länge. Im DACH-Kontext kommt erschwerend hinzu, dass deutscher Text 30 bis 50 Prozent mehr Tokens braucht als äquivalenter englischer. Deutsche Few-Shot-Beispiele sind also spürbar teurer.

Der wichtigste ökonomische Hebel: Stabile Beispielblöcke gehören in den cachebaren Prompt-Prefix. Anthropic-Cache-Reads kosten rund 10 Prozent der Standard-Input-Rate (Stand 2026), bei Sonnet 4.6 etwa 0,30 statt 3,00 US-Dollar pro Million Tokens. Wer seine Few-Shot-Beispiele zusammen mit System-Prompt und Tool-Definitionen stabil hält und nur den dynamischen Teil ans Ende setzt, zahlt die Beispiel-Tokens überwiegend zum Cache-Tarif. Jede Änderung an den Beispielen invalidiert den Cache, also: Beispiele versionieren und in geplanten Releases ändern, nicht per Hotfix.

Konkretes Beispiel: mit und ohne Few-Shot

Ein Agent soll aus einer E-Mail eine strukturierte Bestelldatensatz-Anfrage für ein create_order-Tool erzeugen.

Ohne Few-Shot (Zero-Shot):

```
System: Erzeuge aus der E-Mail einen create_order-Aufruf.
Input: "Bitte 3x Artikel A-100 und 1 Stk B-205 an Kundennr. 4711."
Output (typisch): {"kunde": "4711", "artikel": "A-100, B-205", "menge": "3 und 1"}
```

Der Output ist plausibel, aber unbrauchbar: Mengen und Artikel sind als Fließtext zusammengefasst, die Feldnamen weichen vom Tool-Schema ab. Downstream bricht das Parsing.

Mit Few-Shot (zwei kanonische Beispiele im Tool-Prompt):

```
Beispiel 1
Input: "2x C-300 für Kunde 9001"
Aufruf: {"customer_id":"9001","items":[{"sku":"C-300","qty":2}]}

Beispiel 2 (Edge-Case: keine Menge genannt -> Default 1)
Input: "Artikel D-401 an Kunde 9002"
Aufruf: {"customer_id":"9002","items":[{"sku":"D-401","qty":1}]}

Realer Input: "Bitte 3x Artikel A-100 und 1 Stk B-205 an Kundennr. 4711."
Aufruf: {"customer_id":"4711","items":[{"sku":"A-100","qty":3},{"sku":"B-205","qty":1}]}
```

Zwei Beispiele genügen, um Feldnamen, die Array-Struktur, das Default-Verhalten bei fehlender Menge und die Trennung mehrerer Positionen zu verankern. Kostenseitig: Die beiden Beispiele addieren grob 150 bis 250 Tokens pro Call, im Deutschen entsprechend mehr. Liegen sie im gecachten Prefix, kostet das beim wiederholten Aufruf nur rund ein Zehntel. Für eine Struktur-Garantie kombiniert man dieses Few-Shot-Setup mit Strict Tool Use (strict: true) auf das create_order-Schema. Few-Shot trägt dann die Logik, das Schema die Form. Die Ausnahmen nennt Anthropic in der Doku zu Structured Outputs selbst: Bei einer Ablehnung (stop_reason: "refusal") oder einem Abbruch an max_tokens kann der Output vom Schema abweichen.

Für Agenturen und B2B-Entscheider

Few-Shot Prompting ist der schnellste Weg, einen Agenten von "funktioniert in der Demo" zu "verlässlich in Produktion" zu bringen, ohne Trainingsbudget. Für Agenturen heißt das: Investiere früh in eine kuratierte, versionierte Beispielsammlung pro Use-Case, sie ist wiederverwendbares Asset und Differenzierungsmerkmal. Für B2B-Entscheider gilt: Verlange von deinem Umsetzungspartner ein Eval-Set, gegen das Beispiele getestet werden, sowie eine klare Trennung zwischen Few-Shot für Logik und Schema-Enforcement für Format. Wenn du Agent-Workflows mit nachweisbarer Output-Zuverlässigkeit aufbauen willst, unterstützt dich Blck Alpaca aus Wien bei Design, Eval und produktivem Betrieb DACH-konformer Agenten.