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, zeigen Sie 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. Die Research-Quelle führt unter den System-Prompt-Anti-Patterns explizit auf: mehrere widersprüchliche Beispiele führen dazu, dass das Modell das nächstgelegene wählt. Die Korrektur lautet, diverse, kanonische Beispiele ohne Duplikate zu verwenden.

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. Bei der Tool-Definition empfiehlt die Quelle ein input_examples-Array mit ein bis drei kanonischen Aufrufen. Ohne Beispiele rät das Modell bei verschachtelten oder optionalen Parametern, mit Beispielen sinkt diese Fehlerquelle deutlich. Die Verbindung zur Tool-Selection-Zuverlässigkeit ist eng: Anthropic berichtet, dass disziplinierte Tool-Kataloge plus Tool-Search die Tool-Selection-Accuracy auf Opus 4 von 49 auf 74 Prozent und auf Opus 4.5 von 79,5 auf 88,1 Prozent heben (interne MCP-Evals, Stand 2026). 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 erreicht funktional Äquivalentes über erzwungenes Tool-Use mit einem Pseudo-Tool wie return_structured_result. 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 Quelle dokumentiert, dass alle Frontier-Modelle mit zunehmender Input-Länge messbar degradieren (Context Rot, Chroma-Studie Juli 2025), die effektive Kapazität liegt bei reasoning-lastigen Tasks oft nur bei 30 bis 50 Prozent der nominalen. 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 100-prozentige Struktur-Garantie kombiniert man dieses Few-Shot-Setup mit erzwungenem Tool-Use auf das create_order-Schema, so trägt Few-Shot die Logik, das Schema die Form.

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: Investieren Sie früh in eine kuratierte, versionierte Beispielsammlung pro Use-Case, sie ist wiederverwendbares Asset und Differenzierungsmerkmal. Für B2B-Entscheider gilt: Verlangen Sie von Ihrem 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 Sie Agent-Workflows mit nachweisbarer Output-Zuverlässigkeit aufbauen wollen, unterstützt Sie Blck Alpaca aus Wien bei Design, Eval und produktivem Betrieb DACH-konformer Agenten.