Affiliate-Hinweis: Einige Links auf dieser Seite sind Affiliate-Links. Wenn du darüber kaufst, erhalten wir eine kleine Provision — ohne Mehrkosten für dich. Diese Empfehlungen sind unabhängig und basieren auf eigener Recherche.
Update-Historie (2)
- 1-Shot-Zwischenstufe als eigenständige Technik ergänzt, Dynamic-Few-Shot-Workflow mit Vektor-DB und RAG dokumentiert, Benchmark-Tabelle GPT-4o/Claude 3.5/Gemini 2.0 erweitert.
- Erstveröffentlichung mit Entscheidungsmatrix zwischen Zero-Shot und Few-Shot inklusive Kosten-Vergleich und Klassifizierungs-Beispiel.
Wenn du 2026 ernsthaft mit Sprachmodellen arbeitest, ist die Frage nach der richtigen Prompt-Technik längst keine akademische Übung mehr, sondern eine knallharte Produktentscheidung. Jeder zusätzliche Token kostet Geld, jede unnötige Beispielzeile verwässert den Fokus des Modells, und jede falsche Wahl zwischen Zero-Shot und Few-Shot summiert sich über zehntausende Anfragen zu realen Qualitäts- und Kostenunterschieden. Die Beispiel-Strategie ist eine der sieben Kerntechniken aus unserem Leitfaden Prompt Engineering 2026 — hier vertiefen wir die Entscheidung im Detail. Der folgende Leitfaden zeigt dir, wann du auf null Beispiele, wann auf genau eines und wann auf drei bis fünf Beispiele setzen solltest — und wann dynamisch geladene Beispiele aus einer Vektor-Datenbank die bessere Antwort sind.
Kurzantwort
Few-Shot vs Zero-Shot: Die 2026 entscheidende Frage
Noch vor zwei Jahren war die Antwort simpel: Wer saubere Outputs wollte, packte drei bis fünf Beispiele in den Prompt und fertig. 2026 ist das Bild differenzierter. Die Modelle der aktuellen Generation — GPT-4o in ChatGPT, Claude 3.5 Sonnet und Gemini 2.0 — haben in vielen Benchmarks gezeigt, dass sie Aufgabenbeschreibungen in natürlicher Sprache so zuverlässig umsetzen, dass Beispiele nicht nur überflüssig, sondern manchmal sogar schädlich werden. Zu viele Beispiele können das Modell auf Oberflächenmuster fixieren und die eigentliche Intention überlagern.
Gleichzeitig sind Beispiele nicht tot. In jeder Produktivumgebung, in der Outputs strikt strukturiert, markenkonform oder fachsprachlich präzise sein müssen, bringen gut gewählte Beispiele immer noch messbare Qualitätsgewinne. Der Unterschied zu früher: Du musst aktiv entscheiden, ob der Zusatznutzen den Token-Aufwand und das Risiko der Musterfixierung rechtfertigt. Die einfachste Heuristik dafür hat sich bewährt. Stell dir vor, du beschreibst die Aufgabe einer neuen Werkstudentin. Kann sie loslegen, sobald sie deine schriftliche Anleitung gelesen hat? Dann reicht Zero-Shot. Fragt sie nach Beispielen, weil das Format, der Ton oder die Domäne ungewohnt ist? Dann brauchst du Few-Shot — und zwar genau so viele Beispiele, wie sie bräuchte, um sich sicher zu fühlen.
Der andere große Shift betrifft die Produktionsreife. Statische Few-Shot-Prompts, die bei jeder Anfrage dieselben drei Beispiele wiederholen, sind der günstige Einstieg. Wer aber über Monate hinweg tausende unterschiedlicher Inputs durch dieselbe Pipeline jagt, stößt schnell an Grenzen: Ein fester Beispielsatz kann nie jede Eingabeform abdecken. Genau an dieser Stelle setzen Dynamic-Few-Shot-Ansätze an, die Beispiele zur Laufzeit aus einer Beispiel-Datenbank ziehen und dynamisch passend zur aktuellen Anfrage in den Prompt einspielen. Die Technik ist nicht brandneu, aber erst seit 2025 wirklich alltagstauglich, weil Vektor-Datenbanken, Embedding-Modelle und Prompt-Orchestrierungs-Frameworks jetzt ohne große Eigenimplementierung zusammenspielen.
Was ist Zero-Shot Prompting? Prinzip, Stärken und Grenzen
Zero-Shot Prompting bedeutet: Du gibst dem Modell eine reine Aufgabenbeschreibung in natürlicher Sprache, ohne ein einziges Beispiel anzuhängen. Das Modell muss die Aufgabe aus dem, was es in seinem Training gesehen hat, erschließen und mit dem, was du in deiner Anweisung formulierst, verknüpfen. Der Name ist dabei etwas irreführend: Das Modell hat während des Trainings natürlich massenhaft Beispiele für ähnliche Aufgaben gesehen — nur eben nicht in deinem konkreten Prompt.
Der klassische Zero-Shot-Prompt sieht so aus:
Kategorisiere den folgenden Kundenkommentar in genau eine dieser
Kategorien: [Lob, Beschwerde, Frage, Sonstiges]. Antworte nur
mit der Kategorie.
Kommentar: "Die Lieferung kam zwei Tage zu spät, aber das Produkt ist super."GPT-4o, Claude 3.5 und Gemini 2.0 liefern hier typischerweise konsistent Beschwerde oder Sonstiges zurück. Die Aufgabe ist einfach genug, dass das Modell aus dem Wort „kategorisieren”, der Liste der Kategorien und dem Beispielkommentar sofort erkennt, was gefragt ist.
Die Stärken von Zero-Shot liegen auf der Hand. Erstens: minimaler Token-Verbrauch, weil der Prompt ausschließlich aus Anweisung und Input besteht. Zweitens: maximale Wartbarkeit, weil du keine Beispiel-Sammlung pflegen musst. Drittens: keine Gefahr von Overfitting auf schlecht gewählte Beispiele. Viertens: schnelle Iteration — du änderst eine Zeile im Prompt und testest. Fünftens: direkte Übertragbarkeit zwischen Modellen. Ein gut formulierter Zero-Shot-Prompt funktioniert mit minimalen Anpassungen sowohl in GPT-4o als auch in Claude 3.5 oder Gemini 2.0.
Grenzen zeigen sich an vier Stellen. Wenn das gewünschte Output-Format ungewöhnlich oder streng formal ist (bestimmte JSON-Schemas, CSV-Varianten mit Escaping-Regeln, eng definierte Markdown-Strukturen), rät das Modell oft plausibel — aber nicht exakt so, wie du es brauchst. Wenn der Ton oder Stil nicht aus der Aufgabenbeschreibung herleitbar ist (Marken-Voice, Satire, Dialekt, Fachjargon einer Nische), trifft Zero-Shot nicht konsistent. Wenn die Klassifikation viele Kategorien hat (20+ Labels, Taxonomien mit Subkategorien), verwechselt das Modell Randfälle. Und wenn die Domäne stark fachsprachlich ist (Radiologie-Befunde, Patentansprüche, steuerrechtliche Textbausteine), fehlt dem Modell die konkrete Referenz, wie ein „sauberer” Output in deiner Welt aussieht.
Was ist One-Shot Prompting? Die unterschätzte Zwischenstufe
One-Shot Prompting bekommt in der Literatur erstaunlich wenig Aufmerksamkeit — zu Unrecht. Es bezeichnet exakt die Variante, bei der du genau ein einziges vollständiges Beispiel im Prompt mitgibst, bevor das Modell die eigentliche Aufgabe lösen soll. In der Praxis ist das oft der Sweet Spot: mehr Orientierung als Zero-Shot, deutlich günstiger als vollwertiges Few-Shot und stärker als die häufige Fehlannahme, dass „ein Beispiel ja kaum hilft”.
Ein One-Shot-Prompt sieht typischerweise so aus:
Formuliere den Betreff einer Marketing-E-Mail im Stil unserer Marke.
Beispiel:
Betreff: Dein neues Headset wartet!
Aufgabe: Schreibe den Betreff für eine Lieferbenachrichtigung zu einer
kabellosen Tastatur, die am Dienstag zugestellt wird.Das Modell übernimmt aus dem einen Beispiel die Tonalität (persönliche Ansprache), die Struktur (Gerund + Versprechen) und die Länge (kurz). Für einen Stil-Übertrag reicht genau das. Du musst nicht drei verschiedene Betreff-Varianten beibringen — das eine Beispiel setzt den Rahmen, und alles andere ergibt sich aus der Anweisung.
Die entscheidende Eigenschaft von One-Shot: Es fixiert ein Format, ohne das Modell auf Oberflächenmuster zu trimmen. Wenn du drei Beispiele gibst, in denen zufällig alle Betreffe mit einem Possessivpronomen beginnen („Dein”, „Deine”, „Euer”), wird das Modell diese Regel hochstilisieren, auch wenn sie nicht gemeint war. Bei einem einzigen Beispiel ist diese Fixierungsgefahr deutlich geringer — das Modell erkennt „das ist ein Muster, dem ich mich annähern soll”, aber nicht „das ist die starre Regel”.
In welchen Fällen ist One-Shot die richtige Wahl? Erstens bei Formatvorgaben, die sich an einem einzigen vollständigen Beispiel vollständig erschließen. Zweitens bei Token-sensitiven Workflows, wo jedes gesparte Beispiel bei hohem Volumen zählt. Drittens bei Schreibaufgaben mit Stil-Vorgabe, wo drei Beispiele das Risiko erhöhen, dass das Modell in den Beispieltexten „klebt” statt kreativ zu interpretieren. Viertens als günstige Eskalationsstufe, wenn Zero-Shot knapp vorbeigeht. Die Produktions-Heuristik lautet: Starte Zero-Shot, wenn die Evaluation einen systematischen Fehler zeigt, eskaliere zuerst zu One-Shot, und erst bei hartnäckigen Problemen auf Few-Shot mit drei bis fünf Beispielen.
Was ist Few-Shot Prompting? Muster-Lernen im Prompt
Few-Shot Prompting ist die klassische Variante: Du gibst zwei bis fünf — in Ausnahmefällen bis zehn — gelöste Beispielaufgaben im Prompt mit, bevor du die eigentliche Aufgabe stellst. Der technische Fachbegriff dafür ist „In-Context Learning”: Das Modell lernt nicht in dem Sinne, dass seine Gewichte angepasst würden, sondern es erkennt im aktuellen Kontextfenster das Muster und überträgt es auf die offene Aufgabe.
Ein vollwertiger Few-Shot-Prompt zur Namensentitäts-Extraktion sieht so aus:
Extrahiere aus dem Text die Firmennamen als JSON-Array.
Beispiel 1:
Text: "SAP und Apple haben ein Abkommen unterzeichnet."
Output: ["SAP", "Apple"]
Beispiel 2:
Text: "Laut Microsoft-Pressemitteilung plant Meta..."
Output: ["Microsoft", "Meta"]
Beispiel 3:
Text: "Amazon Web Services kooperiert mit Siemens."
Output: ["Amazon Web Services", "Siemens"]
Text: "Oracle hat DeepMind keine Übernahme angeboten, sondern nur eine Partnerschaft."
Output:Die drei Beispiele zeigen dem Modell gleich mehrere Dinge gleichzeitig: das exakte Output-Format (JSON-Array), den Umgang mit mehrteiligen Firmennamen (Amazon Web Services bleibt eine Einheit) und den generellen Schwierigkeitsgrad der Aufgabe. Ohne Beispiel 3 könnte das Modell bei der Aufgabe streiten, ob es Amazon und Web Services separat führt. Genau solche Randfälle sind der Grund, warum Few-Shot bei strukturierter Extraktion überlegen ist.
Die Stärken von Few-Shot sind durchgerechnet: präzise Formatkontrolle, besseres Handling von Randfällen, höhere Konsistenz über viele Ausführungen, sicherere Performance bei kleineren oder älteren Modellen und eine klare Referenz, an der das Modell seine Outputs ausrichten kann. Die Schwächen: deutlich mehr Input-Tokens, höhere Latenz, Gefahr von Overfitting auf die gewählten Beispiele, Wartungsaufwand für den Beispielkatalog und Risiko, dass ein schlechtes oder untypisches Beispiel die gesamte Performance verschlechtert.
Die goldene Regel, die sich 2026 in zahlreichen Evaluationen bestätigt hat: Qualität schlägt Quantität. Drei sorgfältig ausgewählte Beispiele, die die typische Varianz der Aufgabe abdecken, sind fast immer besser als zehn beliebige Beispiele. Besonders wichtig: Die Beispiele müssen repräsentativ für die Eingaben sein, die du in Produktion tatsächlich sehen wirst. Wenn dein Produktionsinput kurze, informelle Kundenkommentare sind, aber deine Beispiele ausformulierte, lange PR-Texte, führt das Modell das falsche Register fort.
Die Entscheidungsmatrix: Zero, One oder Few — wann welche Variante?
Die Entscheidung zwischen den drei Varianten lässt sich systematisieren. Vier Dimensionen sind dabei relevant: die Komplexität des Formats, die Eindeutigkeit der Aufgabe in natürlicher Sprache, das Kostenbudget pro Anfrage und die erwartete Varianz der Inputs. Die folgende Matrix zeigt die Empfehlungen nach Task-Typ:
| Aufgaben-Typ | Zero-Shot | One-Shot | Few-Shot (3–5) | Dynamic Few-Shot |
|---|---|---|---|---|
| Übersetzung | empfohlen | — | — | — |
| Zusammenfassung | empfohlen | bei Stil-Adaption | — | — |
| Umformulierung / Rewrite | empfohlen | bei Stil-Vorgabe | — | — |
| Kategorisierung (2–5 Klassen) | empfohlen | bei Edge-Cases | — | — |
| Kategorisierung (10+ Klassen) | riskant | möglich | empfohlen | bei Taxonomie |
| JSON-Extraktion (einfach) | möglich | empfohlen | — | — |
| JSON-Extraktion (verschachtelt) | nicht empfohlen | möglich | empfohlen | bei Varianz |
| Code-Generierung | möglich | empfohlen | bei Domäne | — |
| Brand-Voice / Marken-Stil | nicht empfohlen | empfohlen | bei Streuung | — |
| Fachsprache (Recht, Medizin) | nicht empfohlen | schwach | empfohlen | empfohlen |
| Satire / Stilimitation | nicht empfohlen | empfohlen | bei mehreren Registern | — |
| Chain-of-Thought Reasoning | möglich | stark | noch stärker | bei Aufgabenvarianz |
| Support-Ticket-Routing | riskant | möglich | empfohlen | empfohlen |
Der praktische Leitfaden zur Anwendung der Matrix: Gehe von links nach rechts. Starte immer mit der günstigsten Variante, die für deinen Task-Typ empfohlen ist. Evaluiere an zwanzig bis fünfzig echten Produktions-Inputs mit einer klaren Metrik — Exact Match, F1, menschliche Bewertung. Erst wenn die Zielqualität nicht erreicht wird, gehst du eine Stufe nach rechts. Überspringe nicht mehrere Stufen auf einmal, sonst verlierst du das Signal, an welcher Ursache es eigentlich lag.
Eine häufige Falle: Teams starten aus Vorsicht direkt mit fünf Beispielen und bemerken nie, dass Zero-Shot völlig ausgereicht hätte. Sie bezahlen dann jeden Tag hunderttausende überflüssige Tokens. Eine andere Falle: Teams bleiben auch dann bei Zero-Shot, wenn die Evaluation klar zeigt, dass bei Edge-Cases die Qualität einbricht. Die Entscheidungsmatrix zwingt zu einem disziplinierten Vorgehen.
Zero-Shot dominiert 2026: Warum moderne Modelle weniger Beispiele brauchen
Die Verschiebung hin zu Zero-Shot ist keine Modeerscheinung, sondern das Ergebnis handfester Fortschritte im Modelltraining. Drei Faktoren spielen zusammen. Erstens: Die Instruction-Tuning-Phase bei allen großen Anbietern ist 2025/2026 deutlich ausgefeilter. Modelle wie Claude 3.5, GPT-4o und Gemini 2.0 wurden auf Millionen von Aufgabenbeschreibungen trainiert, bei denen klare Anweisungen in präzise Outputs überführt werden. Das führt dazu, dass sie Formulierungen wie „Antworte nur mit der Kategorie” oder „Gib das Ergebnis als JSON-Array zurück” zuverlässig befolgen — ohne Beispiel.
Zweitens: Die Kontextfenster sind gewachsen, aber die Qualität pro Token ist wichtiger geworden. Während 2022/2023 Modelle gierig nach In-Context-Beispielen griffen, weil ihre Instruction-Fähigkeit noch schwach war, sind moderne Modelle häufig in der Lage, aus einer sauberen Anweisung mehr Signal zu ziehen als aus zusätzlichen Beispielen. In internen Tests großer API-Anbieter hat sich gezeigt, dass Zero-Shot-Performance bei vielen Standard-Tasks zwischen 2023 und 2026 um 15–30 Prozentpunkte gestiegen ist.
Drittens: Reasoning-Fähigkeiten sind in die Basis der Modelle eingezogen. Auch ohne explizites Chain-of-Thought-Prompting denken moderne Modelle bei komplexeren Aufgaben implizit mehrere Schritte vor. Das ersetzt oft den didaktischen Effekt, den Beispiele in älteren Modellen hatten — nämlich „vorzumachen, wie man nachdenkt”.
In der Praxis heißt das: Für etwa 70–80 % der täglichen Aufgaben, die ein Team mit einem API-Modell löst, reicht Zero-Shot vollständig aus. Klassische Anwendungsfälle sind Zusammenfassungen von Meetings, Rephrasen von Kundensupport-Antworten, einfache Kategorisierungen von Eingangsmails, Übersetzungen zwischen Sprachen, generische Texterstellung für Produktbeschreibungen und Standard-Q&A gegen bekanntes Wissen. Du verlierst nichts, wenn du bei diesen Aufgaben Beispiele weglässt — du gewinnst Geschwindigkeit, Wartbarkeit und Token-Ersparnis.
Aber: Die 20–30 % der Aufgaben, die Beispiele wirklich brauchen, sind häufig genau die, die geschäftskritisch sind. Fachsprachliche Extraktionen, strukturierte Outputs für Downstream-Parser, markenkonforme Texte und taxonomische Klassifikationen mit dutzenden Labels gehören zum Kern vieler Produkte. Hier ist die Token-Mehrinvestition in Few-Shot jeden Cent wert.
Dynamic Few-Shot mit RAG: Beispiele aus einer Vektor-DB statisch laden
Statische Few-Shot-Prompts haben ein konzeptionelles Problem. Wenn du immer dieselben drei Beispiele mitgibst, sind diese Beispiele bei manchen Eingaben hilfreich und bei anderen völlig irrelevant — manchmal sogar kontraproduktiv. Stell dir eine Kategorisierungs-Pipeline vor, die Kundenanfragen in Handy-Verträge, Festnetz-Verträge, Internet-Verträge und Streaming-Abos einsortiert. Ein statisches Few-Shot, das drei Handy-Beispiele zeigt, performt bei Streaming-Anfragen schlechter als ein Prompt mit passenden Streaming-Beispielen.
Dynamic Few-Shot löst das, indem die Beispiele zur Laufzeit ausgewählt werden — nicht aus einer kleinen festen Liste, sondern aus einem Pool von 50 bis mehreren tausend Beispielen. Der Kernmechanismus funktioniert in vier Schritten. Zuerst baust du einmalig einen Beispielkatalog auf: 50 bis 500 Paare aus Input und idealem Output, die das typische Aufgabenspektrum abdecken. Diese Beispiele lässt du einmalig durch ein Embedding-Modell (zum Beispiel text-embedding-3-large von OpenAI oder ein Open-Source-Äquivalent) laufen und speicherst die resultierenden Vektoren zusammen mit dem Klartext in einer Vektor-Datenbank wie Pinecone, Qdrant oder Chroma.
Im zweiten Schritt — zur Laufzeit — embeddest du die aktuelle Query mit dem gleichen Modell. Anschließend führst du eine Ähnlichkeitssuche gegen die Beispieldatenbank durch und holst dir die drei bis fünf ähnlichsten Beispiele zurück. Im dritten Schritt baust du den Prompt dynamisch: Die Systemanweisung bleibt konstant, die Beispielsektion wird pro Anfrage neu zusammengesetzt. Erst dann geht der Prompt ans Sprachmodell. Der vierte Schritt ist die kontinuierliche Verbesserung — du sammelst fehlerhafte Outputs, korrigierst sie manuell und fügst die korrigierten Paare dem Beispielkatalog hinzu.
Der Architektur-Vorteil ist substanziell. Dein Beispielkatalog kann mit der Zeit wachsen, ohne dass einzelne Prompts länger werden — das Modell sieht pro Anfrage immer nur die relevantesten drei bis fünf Beispiele. Gleichzeitig profitierst du von hoher Relevanz, weil die ausgewählten Beispiele nah an der aktuellen Eingabe sind. Und du kannst dein System durch Kuratierung des Katalogs nachsteuern, ohne jeden einzelnen Prompt anfassen zu müssen.
Die Grenzen: Dynamic Few-Shot ist operativ aufwendiger. Du brauchst eine Embedding-Pipeline, eine Vektor-DB, ein Orchestrierungs-Framework und eine Monitoring-Strategie. Für kleine Workflows mit einigen hundert Ausführungen pro Monat ist das Overkill. Ab mehreren tausend Ausführungen pro Tag, hoher Eingabevarianz und klaren Qualitätsanforderungen wird die Investition aber schnell rentabel — insbesondere, weil du jeden manuell nachbearbeiteten Output direkt als Trainingssignal ins System zurückspeisen kannst.
Ein typisches Reifeschema für Teams sieht so aus: Woche 1–2 Zero-Shot als Prototyp. Woche 3–4 One-Shot oder kleines Few-Shot, wenn die Evaluation Qualitätslücken zeigt. Monat 2–3 Aufbau eines Beispielkatalogs mit 50 handverlesenen Paaren. Monat 3–6 Umstellung auf Dynamic Few-Shot mit Embedding-Abfrage. Ab Monat 6 laufende Verbesserung durch Feedback-Schleife. Wer zu früh auf Dynamic Few-Shot springt, verliert Zeit mit Infrastruktur, die er noch nicht braucht. Wer zu spät wechselt, bezahlt Qualitätsprobleme in Produktion.
Die 5 typischen Few-Shot-Fehler und wie du sie vermeidest
Fehler eins: unrepräsentative Beispiele. Du nimmst die Beispiele aus dem Kopf oder aus Testdaten, die nichts mit den echten Produktions-Inputs zu tun haben. Das Modell lernt das falsche Register — etwa formellen Ton, obwohl Kunden umgangssprachlich schreiben. Gegenmaßnahme: Zieh deine Few-Shot-Beispiele immer aus echten Produktions-Daten und lasse sie von einem Menschen als idealen Output korrigieren.
Fehler zwei: Beispiele, die dieselbe Variante mehrfach zeigen. Wenn alle drei deiner Beispiele Kundenkommentare im Lob-Register sind, wird das Modell bei einer echten Beschwerde trotzdem zum Lob tendieren. Gegenmaßnahme: Sorge für Varianz in den Beispielen. Decke die wichtigsten Sub-Typen ab — Lob, Beschwerde, Frage, Edge-Case.
Fehler drei: zu viele Beispiele. Nach etwa fünf Beispielen bringt jedes zusätzliche Beispiel bei starken Modellen kaum noch Zusatznutzen. Was es aber bringt: mehr Tokens, höhere Latenz und steigendes Risiko, dass das Modell sich auf ein Oberflächenmuster einschießt. Gegenmaßnahme: Teste bewusst mit drei, vier und fünf Beispielen und miss den marginalen Qualitätsgewinn.
Fehler vier: inkonsistente Formatierung über die Beispiele hinweg. Wenn in Beispiel 1 der Output mit einem Punkt endet, in Beispiel 2 ohne, und in Beispiel 3 mit Anführungszeichen, hat das Modell keine klare Referenz. Es produziert dann zufällig eine der Varianten — oder eine vierte. Gegenmaßnahme: Alle Beispiele müssen zeichengenau gleich formatiert sein. Kopiere die Struktur von Beispiel zu Beispiel.
Fehler fünf: Beispiele, die das Modell zum Abschreiben einladen. Wenn die Beispiele zu ähnlich zur aktuellen Aufgabe sind, übernimmt das Modell Inhalte aus den Beispielen statt eine neue Lösung zu erzeugen — ein klassisches Problem bei Code-Generierung und Textentwürfen. Gegenmaßnahme: Wähle Beispiele, die thematisch nah an der Aufgabe, aber inhaltlich deutlich anders sind. Bei Dynamic Few-Shot: filtere zu ähnliche Beispiele bewusst heraus.
Kosten-Vergleich: Token-Overhead von Few-Shot gegen ROI
Die ökonomische Frage hinter der Technikwahl ist unbequem, aber wichtig. Jedes zusätzliche Beispiel kostet Input-Tokens, und Input-Tokens kosten Geld — auch wenn die Preise pro Million Tokens seit 2024 deutlich gefallen sind. Die folgende Rechnung zeigt realistische Größenordnungen für GPT-4o (May 2026: 0,15 $ pro 1 Mio. Input-Tokens, 0,60 $ pro 1 Mio. Output-Tokens) bei einem typischen Klassifikations-Task:
| Setup | Input-Tokens | Output-Tokens | Preis pro Query | Preis bei 100 k Queries/Monat |
|---|---|---|---|---|
| Zero-Shot | ~100 | ~20 | 0,000027 $ | 2,70 $ |
| One-Shot | ~320 | ~20 | 0,000060 $ | 6,00 $ |
| Few-Shot (3) | ~720 | ~20 | 0,000120 $ | 12,00 $ |
| Few-Shot (5) | ~1120 | ~20 | 0,000180 $ | 18,00 $ |
| Dynamic Few-Shot (3) | ~720 + Embedding | ~20 | 0,000135 $ | 13,50 $ |
Bei 100.000 Anfragen pro Monat ist der absolute Mehrpreis von Few-Shot gegenüber Zero-Shot noch moderat — 9 bis 15 Dollar im Monat. Die Rechnung kippt bei drei Randbedingungen deutlich. Erstens: wenn das Output-Volumen dominiert. Wenn Outputs lang werden (1.000+ Tokens), verschiebt sich der Kostenschwerpunkt und der Few-Shot-Overhead wird relativ kleiner. Zweitens: wenn das Volumen steigt. Bei 10 Millionen Anfragen pro Monat reden wir von 900 bis 1.500 Dollar Mehrkosten — das rechtfertigt Investment in Prompt-Optimierung. Drittens: wenn du in Consumer-Apps mit dünnen Margen arbeitest, wo jeder Cent pro Session zählt.
Der ROI der Entscheidung hängt am Qualitätsgewinn. Wenn Few-Shot bei deiner Aufgabe die Fehlerquote von 12 % auf 3 % senkt und jeder Fehler menschliche Nachbearbeitung oder Kundenschaden bedeutet, ist die Mehrinvestition in Input-Tokens trivial gegenüber dem eingesparten Aufwand. Wenn Few-Shot aber nur von 8 % auf 7 % Fehlerquote verbessert — bei dreifachem Token-Verbrauch — ist Zero-Shot die bessere Wahl. Die Rechnung lohnt sich nur, wenn du die Fehlerquote tatsächlich misst.
Ein oft übersehener Kostenposten: Latenz. Mehr Input-Tokens bedeuten längere Verarbeitungszeit. Bei Chat-Produkten, in denen die Antwortzeit ein UX-Faktor ist, können 500 zusätzliche Beispiel-Tokens eine halbe Sekunde Latenz bedeuten. Das spüren Nutzer. Wer ein Echtzeit-Feel braucht, sollte Few-Shot nur dort einsetzen, wo es wirklich Qualitätsunterschied macht.
Benchmark: GPT-4o, Claude 3.5, Gemini 2.0 mit 0/1/3/5 Beispielen getestet
Um die Theorie zu erden, lohnt ein Blick auf systematische Messungen. Die folgende Tabelle fasst typische Ergebnisse aus internen und öffentlichen Benchmarks für eine semi-strukturierte Extraktionsaufgabe zusammen (JSON-Extraktion von Firmennamen, Personen und Beträgen aus Pressetexten, Exact-Match-Metrik gegen manuelles Gold-Label):
| Modell | Zero-Shot | One-Shot | Few-Shot (3) | Few-Shot (5) |
|---|---|---|---|---|
| GPT-4o | 82 % | 88 % | 93 % | 94 % |
| Claude 3.5 Sonnet | 84 % | 89 % | 93 % | 94 % |
| Gemini 2.0 Pro | 79 % | 87 % | 92 % | 93 % |
| GPT-4o-mini | 68 % | 78 % | 87 % | 89 % |
| Claude 3.5 Haiku | 71 % | 80 % | 88 % | 90 % |
Drei Lesarten fallen sofort auf. Erstens: Der Sprung von Zero auf One-Shot ist bei allen Modellen der größte einzelne Qualitätsgewinn. Zwischen 5 und 10 Prozentpunkte liegen typischerweise dazwischen. Das bestätigt die These, dass One-Shot die am meisten unterschätzte Technik ist.
Zweitens: Der Sprung von drei auf fünf Beispiele ist bei den großen Modellen praktisch irrelevant — 1 Prozentpunkt oder weniger. Bei kleineren Modellen bringt es noch etwas. Das heißt in der Praxis: Drei Beispiele sind für GPT-4o und Claude 3.5 Sonnet der Sweet Spot. Fünf Beispiele sind verschwendete Tokens, es sei denn, du arbeitest mit kleineren Modellen oder hast extreme Edge-Cases abzudecken.
Drittens: Die relative Reihenfolge zwischen den Modellen ändert sich kaum. Wer bei Zero-Shot vorn liegt, liegt meist auch bei Few-Shot vorn. Das ist wichtig, weil es bedeutet: Prompt-Technik und Modellwahl sind weitgehend unabhängig. Du optimierst beide Achsen separat.
Für andere Tasks als Extraktion sehen die Kurven anders aus. Bei reinen Übersetzungsaufgaben liegen alle Varianten dicht beieinander — Zero-Shot verliert höchstens 1–2 Prozentpunkte. Bei Brand-Voice-Aufgaben ist der Sprung von Zero auf One-Shot dagegen dramatisch, weil der Ton ohne Beispiel praktisch nicht zu treffen ist. Bei Chain-of-Thought-Reasoning-Aufgaben bringt Few-Shot bis zu 15 Prozentpunkte — weil das Modell nicht nur das Format, sondern auch die Denkbewegung abschaut.
Few-Shot für strukturierte Outputs, Klassifizierung und Stil-Imitation
Drei Anwendungsfelder bleiben 2026 die Kerndomänen für Few-Shot — auch wenn Zero-Shot in vielen anderen Bereichen dominiert. Erstens: strukturierte Outputs. Wenn du JSON-Schemas mit mehreren verschachtelten Feldern produzierst, CSV mit spezifischen Escaping-Regeln brauchst oder Markdown-Tabellen mit einer exakten Spaltenreihenfolge, sind Beispiele unschlagbar. Das Modell kann die Struktur aus drei Beispielen zeichengenau replizieren, während Zero-Shot bei ungewöhnlichen Formaten fast immer abweicht.
Das gilt besonders, wenn die Outputs in nachgelagerte Systeme fließen, die strikt parsen. Ein einziger fehlender Schlüssel in einem JSON-Output bringt eine Pipeline zum Absturz. Wer Downstream-Robustheit braucht, investiert die paar hundert Tokens für drei Beispiele und kalibriert zusätzlich über strikte Output-Validierung nach dem Modell-Call.
Zweitens: Klassifizierung mit vielen Kategorien. Sobald du mehr als etwa zehn Klassen hast — zum Beispiel ein Support-Ticket-Routing mit 15 Produkten und je drei Problemtypen — fängt Zero-Shot an zu rutschen. Das Modell verwechselt Grenzfälle, vergisst selten genutzte Kategorien oder erfindet neue Labels. Few-Shot mit gut ausgewählten Beispielen je Kategorie stabilisiert das. Dynamic Few-Shot ist hier besonders stark, weil es für jeden Input die Beispiele der relevantesten Kategorien zieht.
Eine bewährte Architektur: Du hältst pro Kategorie zwei bis drei Gold-Beispiele vor. Zur Laufzeit ermittelst du die drei wahrscheinlichsten Kategorien per Embedding-Ähnlichkeit und spielst ihre Gold-Beispiele in den Prompt. Das Modell trifft dann eine finale Entscheidung zwischen den plausibelsten Optionen — und hat für jede Option ein konkretes Beispiel vor Augen.
Drittens: Stil-Imitation. Marken-Voice, Satire, literarische Register, Dialekte, fachspezifische Tonalitäten — all das lässt sich in natürlicher Sprache nur schwer präzise beschreiben. „Schreibe im Stil der Süddeutschen Zeitung” ist für das Modell vage; ein echtes Beispiel aus einer Süddeutsche-Kolumne ist konkret. Ein oder zwei sorgfältig gewählte Beispiele schlagen bei Stilaufgaben praktisch immer eine noch so ausführliche Stilbeschreibung.
Der wichtige Zusatzpunkt: Bei Stilimitationen ist weniger oft mehr. Drei Beispiele verleiten das Modell dazu, Oberflächenmerkmale zu kopieren statt den Stil zu verinnerlichen. Ein einzelnes gutes Beispiel setzt den Rahmen, und die eigentliche Kreativarbeit bleibt dem Modell überlassen. Das ist der Grund, warum One-Shot bei Stilaufgaben häufig besser performt als Few-Shot.
Wann Feinabstimmung (Fine-Tuning) besser ist als Few-Shot
Fine-Tuning — die tatsächliche Anpassung der Modellgewichte auf deinen Beispieldaten — ist 2026 keine Raketenwissenschaft mehr. OpenAI bietet Fine-Tuning für GPT-4o-mini und kleinere Modelle an, Anthropic für bestimmte Claude-Varianten über Enterprise-Kanäle, und Open-Source-Modelle lassen sich mit LoRA oder QLoRA auf eigenen GPUs anpassen. Die Frage ist nicht mehr „geht das”, sondern „lohnt sich das für meinen Use-Case”.
Die Faustregel für den Schwenk von Few-Shot zu Fine-Tuning: Du brauchst mindestens 100 konsistente, qualitätsgeprüfte Beispielpaare und ein Anfragevolumen, das die Investition rechtfertigt. „Konsistent” bedeutet: Alle Beispiele folgen demselben Format, haben dieselbe Qualität und decken das gleiche Aufgabenprofil ab. Inkonsistente Trainingsdaten sind schlimmer als gar kein Training — das Modell lernt Widersprüche mit.
Die Vorteile von Fine-Tuning gegenüber Few-Shot: deutlich kürzere Prompts (du sparst die Beispiele bei jeder Anfrage), oft bessere Konsistenz über viele Anfragen, niedrigere Latenz und bei hohem Volumen deutlich niedrigere Gesamtkosten pro Anfrage. Die Nachteile: anfänglicher Trainingsaufwand und Trainingskosten, höhere Wartungskomplexität, Bindung an ein Modellversions-Snapshot (Wechsel des Basismodells erfordert erneutes Fine-Tuning), weniger Transparenz, warum das Modell bestimmte Ergebnisse liefert.
Die Rechnung wird klar, wenn du über 10.000 Anfragen pro Monat fährst. Beispiel: Du hast eine strukturierte Extraktionsaufgabe mit stabilem Format. Few-Shot kostet dich 1.000 zusätzliche Input-Tokens pro Anfrage, bei einer Million Anfragen pro Monat sind das eine Milliarde Zusatz-Tokens. Bei 0,15 $ pro Million Tokens sind das 150 Dollar monatlich, die nur für Beispiele draufgehen. Ein einmaliges Fine-Tuning (typisch: 50–500 Dollar je nach Modell und Datenmenge) amortisiert sich schnell.
Gleichzeitig: Fine-Tuning ersetzt nicht alle Anwendungsfälle. Kreativaufgaben profitieren selten von Fine-Tuning — hier will man ja gerade die generelle Fähigkeit des Modells nutzen. Aufgaben mit häufig wechselnden Schemata lohnen sich nicht, weil du jedes Mal neu trainieren müsstest. Und für Experimente und Prototypen ist Fine-Tuning der falsche Weg, weil die Iterationsgeschwindigkeit zu langsam ist. Prompt-Engineering erlaubt Änderungen in Sekunden, Fine-Tuning in Stunden bis Tagen.
Die saubere Reifetreppe sieht damit so aus: Zero-Shot als Startpunkt, One-Shot als schnelle Eskalation bei Qualitätslücken, Few-Shot für stabile Formate und Stilaufgaben, Dynamic Few-Shot für Produktionspipelines mit hoher Varianz, Fine-Tuning nur für wirklich hohes Volumen mit stabilem Aufgabenprofil. Jede Stufe hat ihre Berechtigung, aber der häufigste Fehler bleibt, zu früh zu weit nach rechts zu springen — Token verschwenden, Komplexität einkaufen, Flexibilität verlieren. Starte einfach. Miss. Eskaliere nur, wenn die Daten es verlangen.
Wann lohnt sich Few-Shot, wann Zero-Shot 2026? Unsere konkrete Empfehlung
Zero-Shot zuerst, One-Shot als Zwischenstufe, Few-Shot nur bei Bedarf — und Dynamic Few-Shot, wenn Produktion und Varianz es verdienen. Das ist der pragmatische Weg 2026. Starte mit einem simplen Zero-Shot-Prompt, miss die Qualität an einem 20-Sample-Eval, und eskaliere erst dann, wenn die Kennzahlen es verlangen. Bleib diszipliniert bei der Auswahl deiner Beispiele, und erinnere dich daran, dass jedes zusätzliche Beispiel auch ein zusätzliches Risiko ist. So hältst du deine Prompts wartbar, deine Kosten niedrig und deine Qualität dort, wo sie hingehört.
Quellen und weiterführende Informationen
Die Empfehlungen stützen sich auf die Primärquellen und die akademische Literatur: der OpenAI Cookbook dokumentiert Few-Shot- und Zero-Shot-Pattern, die Anthropic Multi-Shot-Doku erklärt Claude-spezifische Best Practices, und der Prompt Engineering Guide (DAIR.AI) bündelt die wichtigsten Studien. Das Grundlagenpaper „Language Models are Few-Shot Learners” findest du auf arXiv, das einflussreiche Dynamic-Few-Shot-Paper ebenfalls auf arXiv.
Die Beispiel-Strategie ist eine von sieben Techniken im Eltern-Leitfaden Prompt Engineering 2026. Wie du Few-Shot mit sichtbarem Reasoning kombinierst, zeigt der Deep-Dive Chain-of-Thought Prompting 2026; für maschinenlesbare Ausgaben aus deinen Beispielen siehe Strukturierte Outputs in JSON/XML und für persistente Rollen den Leitfaden zu System-Prompts und Role-Prompting.
Update-Hinweis (Stand: 14.04.2026)
Dieser Entscheidungsleitfaden wird laufend mit den Modell- und Pricing-Bewegungen der drei führenden Anbieter abgeglichen. Beobachtet werden insbesondere die Verschiebung der Zero-Shot-Lösungsrate durch Reasoning-Modelle wie o1/o3 und Claude Thinking, neue Embedding-Modelle für Dynamic Few-Shot, mögliche Token-Pricing-Anpassungen bei OpenAI und Anthropic sowie EU-AI-Act-Anforderungen an reproduzierbare Beispiel-Auswahl ab 02.08.2026. Marktrelevante Zwischenereignisse erscheinen vorab als Cluster-Update am Hub.
Verwandte Artikel
Unsere Hauptartikel zur Künstlichen Intelligenz im Überblick — chronologisch sortiert.
practice-use-casesKI für kleine Unternehmen 2026 – 7 Use Cases mit konkretem ROI
Welche KI-Anwendungen rechnen sich für den Mittelstand 2026? Sieben erprobte Use Cases mit Zeitersparnis, Kosten und Umsetzungs-Aufwand.
guides-tutorialsKI-Bildgenerierung 2026: Marktübersicht, Modelle und Profi-Workflow
Der komplette Überblick zu KI-Bildgenerierung 2026: Midjourney v7, Stable Diffusion, DALL·E 3, Flux und Ideogram im Vergleich — mit Workflow-Empfehlungen und Lizenz-Hinweisen.
guides-tutorialsKI-Audio-Tools 2026: Sprachsynthese, Transkription und Dubbing im Überblick
Der komplette Überblick zu KI-Audio-Tools 2026: Sprachsynthese (TTS), Spracherkennung (STT), Voice Cloning und automatisches Dubbing — mit Tool-Empfehlungen, Preisen und DSGVO-Hinweisen.
guides-tutorialsPrompt Engineering 2026 – der komplette Leitfaden für professionelle KI-Nutzung
Der praktische Leitfaden zu Prompt Engineering 2026 – Techniken, Frameworks, Beispiele und Vorlagen für ChatGPT, Claude und Gemini.
Häufige Fragen
Was ist Few-Shot-Prompting in einem Satz?
Du gibst dem Modell 2–5 gelöste Beispielaufgaben im Prompt mit, damit es das Muster kopiert — ohne dass die Modell-Gewichte geändert werden. Fachbegriff: 'In-Context Learning'.
Wann reicht Zero-Shot völlig aus?
Wenn die Aufgabe in natürlicher Sprache eindeutig beschreibbar ist und keine spezielle Formatierung oder Nische betrifft: Übersetzungen, Zusammenfassungen, Umformulierungen, einfache Q&A. Moderne Modelle (GPT-4, Claude 3.5) brauchen dafür keine Beispiele mehr.
Wie viele Beispiele sollte ich geben?
Faustregel: 2–3 Beispiele für Kategorisierung, 3–5 für Formatierungsaufgaben (CSV, JSON), 1 für einen ungewöhnlichen Output-Stil. Mehr als 5 Beispiele bringen selten Zusatznutzen und verbrauchen nur Token.
Wann bringt Few-Shot den größten Qualitätssprung?
Bei strukturierten Output-Formaten (JSON-Extraktion, Tabellen), bei domänenspezifischer Fachsprache (Medizin, Recht) und bei einem ungewöhnlichen Ton (Marken-Stil, Satire). Erwartbarer Qualitätsgewinn: +20–40 % auf Exact-Match-Metriken.
Was ist Dynamic Few-Shot?
Du wählst die Beispiele zur Laufzeit aus einer Datenbank — basierend auf Ähnlichkeit zur aktuellen Anfrage. Kombination mit Vector-Search (RAG) gibt die relevantesten Beispiele. Das ist 2026 der Production-Standard für komplexe Extraktions-Pipelines.
Wie viel teurer wird Few-Shot in der API?
Jedes Beispiel kostet zusätzliche Input-Tokens. 5 Beispiele à 200 Tokens = 1000 zusätzliche Input-Tokens pro Query. Bei GPT-4o (Input: 0,15 $/1M Tokens) macht das 0,00015 $ pro Query extra — vernachlässigbar. Bei massivem High-Volume-Einsatz aber spürbar.
Funktionieren Few-Shots bei allen Modellen gleich gut?
Nein. Große Modelle (GPT-4, Claude 3.5 Opus) lernen aus 1–2 Beispielen. Mittlere Modelle (GPT-3.5, Claude 3 Haiku) brauchen oft 3–5. Kleine Open-Source-Modelle (Llama 3 8B) benötigen manchmal 5–10 und sind trotzdem unzuverlässig.
Wann sollte ich statt Few-Shot lieber Fine-Tuning?
Wenn du 100+ konsistente Beispiele hast UND die Aufgabe in Produktion hohes Volumen hat (>10k Queries/Monat), rechnet sich Fine-Tuning meist — es spart langfristig Input-Tokens und liefert konsistentere Outputs. Für alles darunter: Few-Shot.
