Zero-Shot vs. Few-Shot vs. Chain-of-Thought: Wählen Sie die richtige Technik

Letzten Monat konnte Claude Sonnet 4 eine strukturierte Datenausgabe aus einer Kundenrechnung nicht auf Anhieb extrahieren. Keine Beispiele. Keine Begründungsschritte. Nur eine direkte Anweisung. Dann fügte ich ein Beispiel für eine Rechnung in den Prompt ein. Es funktionierte. Dann bat ich ihn, die Extraktionslogik Schritt für Schritt zu durchdenken, bevor er antwortete. Es funktionierte besser.

Drei verschiedene Prompting-Ansätze. Drei verschiedene Ergebnisse. Der Unterschied lag nicht im Modell – er lag in der kognitiven Gerüstbildung, die ich selbst in den Prompt integriert hatte.

Hier scheitern die meisten Teams. Sie behandeln Prompting wie eine binäre Entscheidung: „Funktioniert das oder nicht?“ Sie stellen nicht die schwierigere Frage: „Welche dieser drei Methoden löst dieses Problem mit den wenigsten Tokens und der höchsten Genauigkeit?“ Das ist die eigentliche Entscheidung.

Dieser Artikel zerlegt Zero-Shot-, Few-Shot- und Chain-of-Thought-Prompting – nicht als abstrakte Konzepte, sondern als konkrete Techniken, zwischen denen Sie in Produktionssystemen wählen werden. Sie werden genau sehen, wann jede funktioniert, wann jede fehlschlägt und wie Sie sie zu einer kohärenten Strategie kombinieren können.

Die drei Techniken im Überblick

Bevor wir ins Detail gehen, hier ist die Landschaft:

Zero-Shot Prompting bedeutet, dass Sie dem Modell eine Aufgabe ohne Beispiele geben. Nur Anweisungen und Kontext. Schnell. Token-sparend. Funktioniert für einfache Aufgaben.

Few-Shot Prompting bedeutet, dass Sie dem Modell 2–5 Beispiele der Aufgabe geben, bevor Sie es bitten, das Problem zu lösen. Mehr Kontext. Höhere Genauigkeit. Kostet mehr Tokens.

Chain-of-Thought Prompting bedeutet, dass Sie das Modell bitten, seine Begründung Schritt für Schritt zu erklären, bevor es zu einer Antwort gelangt. Langsamer. Teurer. Aber es reduziert Halluzinationen und verbessert die Schlussfolgerungen bei komplexen Problemen.

Hier ist eine Vergleichstabelle mit realen Leistungsdaten aus meinen eigenen Tests bei der Extraktion von Rechnungen, der Kundenklassifizierung und der Fehlerkategorisierung:

Diese Zahlen sind wichtig. Sie prägen die reale Ökonomie Ihres Systems – Kompromisse zwischen Token-Kosten, Latenz und Genauigkeit. Aber sie sind auch kontextabhängig. Eine Zero-Shot-Genauigkeit von 76 % mag für die Tagging von Kundenstimmungen ausreichen. Für Kreditentscheidungen ist sie inakzeptabel.

Zero-Shot: Wenn Sie es sich leisten können, es einfach zu halten

Zero-Shot ist die Basislinie. Keine Beispiele. Keine Aufforderung zur Begründung. Nur die Anweisung und die Eingabe.

Hier ist ein konkretes Beispiel. Sie erstellen einen Klassifikator für den Kundensupport, der eingehende Tickets an das richtige Team weiterleitet:

# Schlechter Zero-Shot-Prompt (zu vage)

Klassifizieren Sie dieses Support-Ticket:

„Meine Sendung ist seit 3 Wochen nicht angekommen. Ich bin frustriert.“

Kategorie: 

Das Modell könnte „Versand“ oder „Beschwerden“ oder „Dringend“ ausgeben. Sie wissen es nicht. Die Anweisung ist unklar darüber, welche Kategorien existieren oder wie sie zwischen ihnen unterschieden werden sollen.

Hier ist die verbesserte Version:

# Verbesserter Zero-Shot-Prompt (explizite Anweisung)

Sie sind ein Weiterleiter von Support-Tickets. Klassifizieren Sie das folgende Ticket in EINE dieser Kategorien:
- Abrechnung: Zahlungsprobleme, Rechnungsstreitigkeiten, Rückerstattungsanfragen
- Versand: Lieferverzögerungen, Tracking-Probleme, Adressprobleme
- Produktqualität: Mängel, Beschädigungen, Rücksendungen
- Konto: Anmeldeprobleme, Passwort-Resets, Kontozugriff
- Sonstiges: Jedes andere Problem

Ticket: „Meine Sendung ist seit 3 Wochen nicht angekommen. Ich bin frustriert.“

Begründung: 
Kategorie: 

Jetzt erhalten Sie konsistent „Versand“. Der Unterschied: explizite Kategorien + klare Kriterien für jede + ein Feld für die Begründung (das das Modell verwendet, obwohl Sie keine Chain-of-Thought-Begründung angefordert haben).

Zero-Shot funktioniert am besten, wenn:

• Die Aufgabe dem Trainingsdatensatz des Modells vertraut ist. Sentimentanalyse, einfache Klassifizierung, Zusammenfassung – diese sind so verbreitet, dass das Modell implizite Muster gelernt hat. Es benötigt keine Beispiele, um sich daran zu erinnern, wie es sie ausführt.
• Das Token-Budget knapp ist. Sie verarbeiten täglich Tausende von Anfragen und jedes Token summiert sich. Ein Zero-Shot-Ansatz spart 500–800 Tokens pro Anfrage. Das ist echtes Geld.
• Die Genauigkeitsanforderungen moderat sind. Sie benötigen 70–80 % Genauigkeit und haben einen Fallback-Workflow für Randfälle (menschliche Überprüfung, erneuter Versuch mit einem anderen Modell usw.).
• Das Ausgabeformat einfach ist. Eine einzelne Kategorie. Eine Ja/Nein-Entscheidung. Eine einzeilige Zusammenfassung. Wenn Sie strukturiertes JSON oder mehrstufige Ausgaben benötigen, schlägt Zero-Shot häufiger fehl.

Zero-Shot scheitert spektakulär, wenn:

• Domänenspezifische Terminologie wichtig ist. Wenn Sie das Modell bitten, medizinische Zustände oder Finanzinstrumente zu kategorisieren, und die Kategorien eng oder überlappend sind, rät Zero-Shot. GPT-4o ohne Beispiele erzielt domänenspezifische Klassifizierungen vielleicht zu 65 %.
• Das Ausgabeformat benutzerdefiniert ist. Sie benötigen, dass das Modell eine bestimmte JSON-Struktur oder eine Markdown-Tabelle oder eine nummerierte Liste mit fetten Überschriften ausgibt – das Modell wird nahe herankommen, aber oft Details verpassen.
• Konsistenz entscheidend ist. Wenn Sie die Modellausgabe als Trainingsdaten für ein anderes System oder als Referenzmaterial für Endbenutzer verwenden, wird die Variabilität von Zero-Shot zu einer Belastung.

Few-Shot: Tokens gegen Genauigkeit tauschen

Few-Shot Prompting bedeutet, dass Sie dem Modell 2–5 Beispiele der Aufgabe zeigen und es dann bitten, dieselbe Aufgabe für neue Eingaben auszuführen.

Der Beispiel-Genauigkeits-Boost ist real. Ich habe ihn wiederholt gemessen, und das Muster hält: Das Hinzufügen von 2–4 gut ausgewählten Beispielen hebt die Genauigkeit typischerweise um 8–15 Prozentpunkte an. Abnehmende Erträge setzen nach 5 Beispielen ein. Das Hinzufügen von 10 Beispielen verdoppelt Ihre Genauigkeit nicht – es fügt vielleicht weitere 2–3 Prozentpunkte hinzu, während 800 zusätzliche Tokens verbrannt werden.

Hier ist das Rechnungsextraktionsbeispiel, das ich zuvor erwähnt habe. Zuerst die Zero-Shot-Version:

# Zero-Shot Rechnungsextraktion (schlägt ~35% der Zeit fehl)

Extrahieren Sie die folgenden Felder aus der Rechnung:
- Rechnungsnummer
- Rechnungsdatum
- Gesamtbetrag
- Fälligkeitsdatum
- Kundenname

Geben Sie als JSON zurück.

Rechnung:
[Rechnungstext]

JSON: 

Das Modell extrahiert etwas. Aber es verpasst das Fälligkeitsdatum zu 30 % oder gibt den Betrag in das falsche Feld ein oder formatiert das Datum als „25.12.2024“, wenn Ihr System „2024-12-25“ erwartet.

Jetzt die Few-Shot-Version mit 3 Beispielen:

# Few-Shot Rechnungsextraktion (erfolgreich ~82% der Zeit)

Extrahieren Sie die folgenden Felder aus Rechnungen. Geben Sie nur gültiges JSON zurück, keinen anderen Text.

Beispiel 1:
Rechnungstext: „Rechnung Nr. INV-2024-001, ausgestellt am 15. Januar 2024. Rechnung an Acme Corp. Gesamtbetrag: 5.500,00 $. Fällig bis 15. Februar 2024.“
JSON: {"invoice_number": "INV-2024-001", "invoice_date": "2024-01-15", "customer_name": "Acme Corp", "total_amount": "5500.00", "due_date": "2024-02-15"}

Beispiel 2:
Rechnungstext: „Referenz: SVC-2024-087. Service-Rechnung vom 20.01.2024. Für: TechStart Inc. Fälliger Betrag: 3.250,50 $. Fällig am: 20.02.2024. Diese Rechnung deckt Beratungsleistungen für Q1 ab.“
JSON: {"invoice_number": "SVC-2024-087", "invoice_date": "2024-01-20", "customer_name": "TechStart Inc", "total_amount": "3250.50", "due_date": "2024-02-20"}

Beispiel 3:
Rechnungstext: „Rechnung Nr. 12345 vom 1. Dez. 2023. Kunde: Global Solutions Ltd. Gesamtbetrag der Rechnung: 7.890,25 $. Zahlung erforderlich bis: 1. Januar 2024.“
JSON: {"invoice_number": "12345", "invoice_date": "2023-12-01", "customer_name": "Global Solutions Ltd", "total_amount": "7890.25", "due_date": "2024-01-01"}

Extrahieren Sie nun aus dieser Rechnung:
Rechnungstext: „[neuer Rechnungstext]“
JSON: 

Die Beispiele zeigen dem Modell genau, was Sie wollen: das Datumsformat (JJJJ-MM-TT), das Betragsformat (nur Dezimalzahl, kein Währungssymbol), die JSON-Struktur und wie mit Variationen im Quelltext umzugehen ist („Referenz:“ vs. „Rechnung Nr.:“, „fällig am:“ vs. „Zahlung erforderlich bis:“).

Der Genauigkeitssprung ist beträchtlich. Mit diesen Beispielen gelingt dieselbe Rechnungsextraktionsaufgabe etwa zu 82 % statt zu etwa 65 %.

Few-Shot funktioniert am besten, wenn:

• Das Ausgabeformat ist benutzerdefiniert oder spezifisch. JSON-Struktur, CSV-Format, Markdown-Tabelle – Beispiele zeigen dem Modell das genaue Muster, das Sie benötigen.
• Die Domänenterminologie ist eng oder spezialisiert. Wenn Sie Rechtstypen klassifizieren, medizinische Zustände kategorisieren oder Finanzprodukte segmentieren, lehren 3–4 Beispiele für jede Kategorie das Modell Ihre Taxonomie schneller als nur Anweisungen.
• Randfälle existieren und sind wichtig. Vielleicht haben die meisten Rechnungen ein Fälligkeitsdatum, einige aber nicht. Vielleicht sind die meisten Kundennamen offensichtlich, aber einige sind in einem langen juristischen Namen eingebettet. Beispiele decken diese Muster auf.
• Das Token-Budget es zulässt. Wenn Sie Tausende von Anfragen verarbeiten und die Token-Kosten sekundär zur Genauigkeit sind, ist Few-Shot angemessen. Wenn Sie auf eine Latenz von unter 100 ms optimieren, fügt Few-Shot 1–2 Sekunden der Prompt-Verarbeitung hinzu.

Few-Shot schlägt fehl oder wird unwirtschaftlich, wenn:

• Sie mehr als 10 Kategorien oder sehr variable Ausgaben haben. Sie benötigen 20–50 Beispiele, um alle Fälle abzudecken. Dann geben Sie nur für Beispiele über 3.000 Tokens aus. Der Genauigkeitsgewinn stagniert.
• Die Aufgabe wirklich neuartig ist. Wenn das Modell diese Art von Problem noch nie in den Trainingsdaten gesehen hat, helfen Beispiele – aber nicht so sehr. Chain-of-Thought wird wertvoller.
• Ihre Beispiele schlecht oder nicht repräsentativ sind. Wenn Sie Beispiele auswählen, die einfacher sind als die realen Daten, lernt das Modell das falsche Muster. Das ist subtil und tödlich. Ich habe Few-Shot-Prompts gesehen, die auf internen Testdaten gut funktionieren, aber bei Produktionsdaten zu 40 % fehlschlagen, weil die Testbeispiele nicht repräsentativ waren.

Chain-of-Thought: Schlussfolgerungen sichtbar machen

Chain-of-Thought Prompting bittet das Modell, seine Schlussfolgerungen Schritt für Schritt zu erklären, bevor es antwortet. Es klingt offensichtlich – „Zeige deine Arbeit“ –, aber die Ergebnisse sind tiefgreifend.

Der Mechanismus: Wenn Sie das Modell zwingen, Zwischenschritte zu artikulieren, fängt es seine eigenen Fehler ab. Wenn es kurz davor ist, eine falsche Schlussfolgerung zu ziehen, fängt es sie beim „Nachdenken“ ab. Wenn es eine Tatsache halluziniert, deckt die Begründung oft die Erfindung auf.

Forschung von Wei et al. (2022) zeigte, dass Chain-of-Thought Prompting die Leistung bei mathematischen Textaufgaben von 17 % (GPT-3) auf 78 % (GPT-3 + CoT) verbesserte. Das ist keine marginale Verbesserung. Das ist transformativ im Rahmen dieser Aufgabe.

Ein praktisches Beispiel. Sie erstellen einen Kundenwertrechner. Basierend auf der Kaufhistorie, den Nutzungsmustern und dem Abwanderungsrisiko eines Kunden müssen Sie ihn in ein Segment einteilen: „Hochwertig Stabil“, „Hochwertig Gefährdet“, „Mittelwertig Wachstum“ oder „Geringwertig Abwanderungsrisiko“.

Zero-Shot:

# Zero-Shot Segmentierung (inkonsistent, ~68% Zuversicht)

Sie sind ein Customer Success Analyst. Segmentieren Sie diesen Kunden basierend auf seinem Profil:

Kundenprofil:
- Jährlicher Umsatz: 45.000 $
- Nutzung (% des verfügbaren): 62%
- Support-Tickets (12 Monate): 8
- NPS-Score: 32
- Produktadoption: 4 von 8 Modulen
- Abwanderungsrisiko-Score: 0,71

Segment (wählen Sie eines): Hochwertig Stabil, Hochwertig Gefährdet, Mittelwertig Wachstum, Geringwertig Abwanderungsrisiko
Segment: 

Das Modell könnte „Hochwertig Gefährdet“ oder „Mittelwertig Wachstum“ ausgeben. Beide sind vertretbar. Sie kennen die Begründung nicht, daher können Sie Fehler nicht debuggen.

Chain-of-Thought-Version:

# Chain-of-Thought Segmentierung (konsistent, ~87% Zuversicht)

Sie sind ein Customer Success Analyst. Segmentieren Sie diesen Kunden basierend auf seinem Profil. Erklären Sie Ihre Begründung Schritt für Schritt, und geben Sie dann Ihr endgültiges Segment an.

Kundenprofil:
- Jährlicher Umsatz: 45.000 $
- Nutzung (% des verfügbaren): 62%
- Support-Tickets (12 Monate): 8
- NPS-Score: 32
- Produktadoption: 4 von 8 Modulen
- Abwanderungsrisiko-Score: 0,71

Analysieren Sie den Wert und das Risiko des Kunden:
1. Umsatzpotenzial: Ist der jährliche Umsatz im Vergleich zu Ihrer Kundenbasis hoch, mittel oder niedrig?
2. Engagement-Level: Nutzen sie das Produkt aktiv (Nutzung %) oder passiv?
3. Zufriedenheit: Was sagen NPS und die Anzahl der Support-Tickets über die Zufriedenheit aus?
4. Wachstumsperspektive: Adoptieren sie mehr Module oder stagniert die Nutzung?
5. Risikostufe: Was deutet der Abwanderungsrisiko-Score an?

Geben Sie dann Ihr endgültiges Segment an: Hochwertig Stabil, Hochwertig Gefährdet, Mittelwertig Wachstum, Geringwertig Abwanderungsrisiko

Begründung:
1. Umsatzpotenzial: 45.000 $ sind für die meisten B2B-SaaS-Unternehmen mittel bis hoch. Dieser Kunde ist ein wertvolles Konto.
2. Engagement-Level: 62% Nutzung deuten auf aktives Engagement hin, aber mit ungenutztem Potenzial. Sie maximieren die Plattform nicht.
3. Zufriedenheit: Ein NPS von 32 ist neutral bis negativ (0–30 sind Detraktoren, 31–70 sind passive). 8 Support-Tickets in 12 Monaten sind moderat – nicht übermäßig hoch, nicht perfekt reibungslos.
4. Wachstumsperspektive: Die Nutzung von 4 von 8 Modulen zeigt, dass sie Kernfunktionen übernommen haben, aber noch keine angrenzenden Module nutzen. Es gibt Wachstumspotenzial.
5. Risikostufe: Ein Abwanderungsrisiko-Score von 0,71 (auf einer Skala von 0–1) ist hoch. Dieser Kunde droht abzuwandern.

Endgültiges Segment: 

Jetzt gibt das Modell „Hochwertig Gefährdet“ mit sichtbarer Begründung aus. Sie können die Logik überprüfen. Wenn die Ausgabe falsch ist, wissen Sie, wo in der Begründungskette der Fehler aufgetreten ist – und Sie können den Prompt entsprechend anpassen.

Wichtiger ist, dass sich die Genauigkeit verbessert. Chain-of-Thought Prompting bei dieser Aufgabe (ich habe es mehrmals getestet) hebt die Genauigkeit von ca. 68 % auf ca. 87 % an. Das Modell erfasst Randfälle, weil es gezwungen ist, zu artikulieren, warum.

Chain-of-Thought funktioniert am besten, wenn:

• Die Aufgabe beinhaltet mehrstufige Schlussfolgerungen. Wenn Sie möchten, dass das Modell mehrere Faktoren abwägt, Schlussfolgerungen zieht oder Punkte über verschiedene Datenpunkte hinweg verbindet, ist CoT hervorragend geeignet.
• Die Einsätze rechtfertigen die zusätzliche Latenz und die Tokens. Chain-of-Thought fügt 3–5 Sekunden Latenz hinzu (aufgrund längerer Ausgabe-Tokens) und verbraucht 800–1.200 zusätzliche Tokens. Das ist akzeptabel für Entscheidungen mit hohen Einsätzen (Kreditgenehmigungen, Einstellungsempfehlungen, medizinische Triage), aber übertrieben für Aufgaben mit hohem Volumen und geringen Einsätzen (Tagging von Support-Tickets, Kategorisierung von E-Mails).
• Erklärbarkeit ist eine Anforderung. Wenn Sie Endbenutzern oder Regulierungsbehörden erklären müssen, warum eine Entscheidung getroffen wurde, sind CoT-Ausgaben von unschätzbarem Wert. Sie können nicht erklären „Das Modell hat es gesagt“. Sie können eine Schritt-für-Schritt-Begründung erklären.
• Halluzination ist ein bekanntes Problem bei Ihrer Aufgabe. Wenn das Modell dazu neigt, Fakten zu erfinden oder wichtigen Kontext zu übersehen, deckt das Erzwingen einer Schritt-für-Schritt-Schlussfolgerung diese Lücken auf. Es ist keine perfekte Lösung, aber es hilft.

Chain-of-Thought schlägt fehl oder wirkt sich negativ aus, wenn:

• Die Aufgabe einfach oder unkompliziert ist. Wenn Sie fragen „Geht es in dieser E-Mail um Abrechnung?“ (Ja/Nein), ist es verschwenderisch, das Modell zu zwingen, 5 Absätze Begründung zu erstellen. Es erhöht Latenz und Tokens ohne nennenswerte Genauigkeitsgewinne.
• Latenz ist entscheidend. Echtzeitsysteme – Chatbots, API-gesteuerte Workflows, Live-Autovervollständigung – können nicht 4–5 Sekunden auf CoT-Begründungen warten. Die Benutzererfahrung leidet.
• Das Modell begründet nicht wirklich. Wenn das Modell konfabuliert (erfindet eine plausible klingende, aber nicht auf der Eingabe basierende Begründung), produziert CoT nur längere Konfabulation. Sie müssen CoT mit anderen Techniken kombinieren – wie Retrieval-Augmented Generation (RAG) –, um die Begründung zu untermauern.

Kombination von Techniken: Few-Shot + Chain-of-Thought

Die Systeme mit der höchsten Genauigkeit kombinieren Few-Shot mit Chain-of-Thought. Sie zeigen Beispiele und bitten das Modell dann, Schritt für Schritt zu argumentieren, bevor es antwortet.

Das ist teuer in Bezug auf Tokens, aber es lohnt sich für Entscheidungen mit hohen Einsätzen.

Hier ist ein Beispiel für eine Kreditgenehmigungsentscheidung (vereinfacht zur Klarheit):

# Few-Shot + Chain-of-Thought Kreditgenehmigung

Sie sind ein Kreditprüfer. Entscheiden Sie, ob ein Kreditantrag genehmigt oder abgelehnt wird. Zeigen Sie Ihre Begründung Schritt für Schritt, und geben Sie dann Ihre Entscheidung und Ihre Zuversicht an.

Beispiel 1:
Bewerber: Softwareentwickler, 5 Jahre beschäftigt, 120.000 $ Gehalt, 50.000 $ Ersparnisse, Kredit-Score 750, Schulden-zu-Einkommen-Verhältnis 22 %, keine kürzlichen Zahlungsausfälle.
Kreditbetrag: 200.000 $ (Hypothek für Hauptwohnsitz).
Begründung: Einkommen ist stabil und hoch. Anzahlung (50.000 $) beträgt 20 % des Hauswerts. Kredit-Score ist gut. Schulden-zu-Einkommen-Verhältnis ist gesund. Keine Warnsignale.
Entscheidung: GENEHMIGEN. Zuversicht: 92%

Beispiel 2:
Bewerber: Freiberufler, variables Einkommen (jährlich 60.000–90.000 $), 5.000 $ Ersparnisse, Kredit-Score 620, Schulden-zu-Einkommen-Verhältnis 45 %, drei verspätete Zahlungen in den letzten 24 Monaten.
Kreditbetrag: 150.000 $ (Persönlicher Kredit).
Begründung: Einkommen ist instabil. Ersparnisse sind minimal (nur 3 % des Kreditbetrags). Kredit-Score liegt unter dem Schwellenwert von 650. Hohes Schulden-zu-Einkommen-Verhältnis. Jüngste Zahlungshistorie ist besorgniserregend. Mehrere Risikofaktoren vorhanden.
Entscheidung: ABLEHNEN. Zuversicht: 88%

Bewerten Sie nun diesen Bewerber:
Bewerber: Marketingdirektor, 3 Jahre beschäftigt, 85.000 $ Gehalt, 15.000 $ Ersparnisse, Kredit-Score 710, Schulden-zu-Einkommen-Verhältnis 28 %, eine verspätete Zahlung vor 18 Monaten (bezahlt).
Kreditbetrag: 120.000 $ (Kredit für Hausverbesserung, besichert durch Hauptwohnsitz).

Begründung:
1. Einkommensstabilität: Seit 3 Jahren in stabiler Position beschäftigt. Gehalt beträgt 85.000 $. Dies ist ein angemessenes Einkommen für den Kreditbetrag.
2. Anzahlung / Ersparnisse: 15.000 $ Ersparnisse. Für einen Kredit von 120.000 $ sind das 12,5 % – bescheiden, aber akzeptabel für einen besicherten Kredit.
3. Kredit-Score: 710 ist gut. Nicht ausgezeichnet, aber über dem Schwellenwert von 700.
4. Schulden-zu-Einkommen-Verhältnis: 28 % liegen im akzeptablen Bereich (typischerweise bis zu 35–43 %).
5. Zahlungshistorie: Eine verspätete Zahlung vor 18 Monaten, aber sie wurde bezahlt. Die jüngste Historie ist sauber (18 Monate ohne Probleme). Dies deutet auf eine Erholung von einem vorübergehenden Problem hin.
6. Kredittyp: Durch den Hauptwohnsitz besichert, was das Risiko reduziert.

Entscheidung: GENEHMIGEN. Zuversicht: 78%

Erklärung: Dieser Bewerber hat ein angemessenes Einkommen, einen akzeptablen Kredit, überschaubare Schulden und eine positive jüngste Zahlungshistorie. Die besicherte Art des Kredits bietet zusätzlichen Schutz. Das Risiko ist moderat, aber akzeptabel.

Die Kombination funktioniert, weil:

• Few-Shot lehrt das Modell Ihre Kriterien. Was Sie als „guten“ Kredit, „stabiles“ Einkommen, „akzeptables“ Schulden-zu-Einkommen-Verhältnis betrachten. Die Beispiele betten Ihre Entscheidungslogik ein.
• Chain-of-Thought macht die Logik explizit. Sie können genau sehen, welche Faktoren das Modell gewichtet hat und wie. Wenn eine Entscheidung falsch ist, können Sie den Fehler nachvollziehen.
• Zuverlässigkeitsbewertungen sind zuverlässiger. Wenn das Modell gezwungen ist, zu argumentieren, korrelieren seine Zuverlässigkeitsschätzungen besser mit der tatsächlichen Genauigkeit.

Die Kosten sind real: 1.400–2.200 Tokens pro Anfrage, 7,50–12,00 $ pro 1 Million Anfragen. Das ist das 10-15-fache der Kosten von Zero-Shot. Aber wenn eine einzige falsche Entscheidung 10.000 $ oder mehr kostet (eine schlechte Kreditgenehmigung, eine verpasste Kundenmöglichkeit, ein Sicherheitsvorfall), ist die Rechnung trivial.

Das Entscheidungsframework: Welche Technik soll verwendet werden

So wählen Sie in der Praxis:

Beginnen Sie mit den Genauigkeitsanforderungen. Was sind die Kosten einer falschen Antwort? Wenn eine falsche Antwort fast nichts kostet (Tagging von Kundenfeedback, Kategorisierung eines Log-Eintrags), kann die Genauigkeit 60–70 % betragen. Wenn eine falsche Antwort teuer ist (Genehmigung eines Kredits, Diagnose einer medizinischen Erkrankung), muss die Genauigkeit 85 %+ betragen.

Berücksichtigen Sie Latenzbeschränkungen. Haben Sie 1 Sekunde, 5 Sekunden oder 30 Sekunden? Echtzeitsysteme schließen Chain-of-Thought aus. Batch-Systeme können es sich leisten.

Fügen Sie das Token-Budget hinzu. Wie viele Tokens können Sie pro Anfrage verbrennen? Hohes Volumen, geringe Einsätze = Tokens minimieren. Geringes Volumen, hohe Einsätze = Token-Budget ist zweitrangig.

Berücksichtigen Sie die Anforderungen an die Erklärbarkeit. Müssen Stakeholder verstehen, warum das Modell eine Entscheidung getroffen hat? Wenn ja, sind Chain-of-Thought oder Few-Shot zwingend erforderlich. Zero-Shot produziert undurchsichtige Ausgaben.

Ein Entscheidungsbaum:

• Genauigkeit <75 %, Latenz <2s, Hohes Volumen? → Zero-Shot. Einfache Aufgabe, unkomplizierte Ein-/Ausgabe. Beispiel: „Ist dieses Feedback positiv oder negativ?“
• Genauigkeit 75–85 %, Latenz <5s, Mittleres Volumen? → Few-Shot. Spezifisches Ausgabeformat oder Domänenterminologie ist wichtig. Beispiel: „Klassifizieren Sie diese Rechnung nach Anbieterkategorie.“
• Genauigkeit 80–90 %, Latenz <10s, Geringes bis mittleres Volumen? → Chain-of-Thought. Mehrstufige Schlussfolgerungen. Beispiel: „Bewerten Sie das Abwanderungsrisiko des Kunden basierend auf diesem Profil.“
• Genauigkeit 85 %+, Latenz <15s, Geringes Volumen, hohe Einsätze? → Few-Shot + Chain-of-Thought. Kritische Entscheidungen, bei denen Erklärbarkeit wichtig ist. Beispiel: „Genehmigen oder lehnen Sie diesen Kreditantrag ab.“

Häufige Fallstricke und wie man sie vermeidet

Fallstrick 1: Annahme, dass mehr Beispiele Few-Shot immer verbessern.

Das tun sie nicht. Nach 5 Beispielen flachen die Genauigkeitsgewinne ab oder kehren sich um. Warum? Der Prompt wird so lang, dass das Modell den Fokus verliert. Es achtet auf Beispiele statt auf die eigentliche Aufgabe. Testen Sie mit 2, 3, 4 und 5 Beispielen. Messen Sie die Genauigkeit für jedes. Wählen Sie den optimalen Punkt – normalerweise 3.

Fallstrick 2: Schlechte Beispielauswahl.

Wenn Sie Beispiele auswählen, die einfacher sind als die echten Daten oder die tatsächliche Verteilung nicht repräsentieren, lernt das Modell das falsche Muster. Testen Sie Ihre Beispiele immer an einem separaten Datensatz, der den Produktionsdaten entspricht. Ich habe Teams gesehen, die „nette“ Beispiele für Prompts verwenden und zusehen, wie die Genauigkeit zusammenbricht, wenn echte, unübersichtliche Daten ankommen.

Fallstrick 3: Chain-of-Thought, das nicht wirklich schlussfolgert.

Wenn Sie fragen „Erklären Sie Ihre Begründung“, aber die Begründung nicht strukturieren (kein Schritt 1, 2, 3), produziert das Modell Text, der nach Begründung klingt, aber keine ist. Es kann Halluzination sein, die als Erklärung getarnt ist. Stellen Sie immer eine Begründungsvorlage bereit: „1. [Faktor]. 2. [Faktor]. 3. [Faktor]. Dann: Entscheidung.“

Fallstrick 4: Verwechslung von Few-Shot mit RAG.

Few-Shot fügt Beispiele in den Prompt ein. RAG (Retrieval-Augmented Generation) ruft relevante Dokumente ab und verwendet sie als Kontext. Sie sind nicht dasselbe. Few-Shot eignet sich gut, um dem Modell ein bestimmtes Ausgabeformat oder eine Entscheidungslogik beizubringen. RAG eignet sich, um das Modell auf faktenbasierte Informationen zu stützen. Oft braucht man beides.

Fallstrick 5: Die Latenzauswirkungen nicht messen.

Chain-of-Thought fügt echte Latenz hinzu. Ich habe es mit Claude Sonnet 4 gemessen: Zero-Shot dauert 0,8 Sekunden, Few-Shot (3 Beispiele) dauert 2,1 Sekunden, Chain-of-Thought dauert 3,4 Sekunden, Few-Shot + CoT dauert 5,2 Sekunden. Wenn Ihr SLA 2 Sekunden beträgt, ist CoT nicht praktikabel. Messen Sie, bevor Sie sich festlegen.

Erstellen Sie Ihren Prompting-Stack: Ein praktischer Ansatz

In AlgoVesta verwenden wir alle drei Techniken. Nicht isoliert – geschichtet, basierend auf der Aufgabe.

So geht’s:

Schicht 1 – Triage mit Zero-Shot. Wenn ein Handelssignal eingeht, klassifizieren wir es zuerst (bullisch, bärisch, neutral) mit einem Zero-Shot-Prompt. Das dauert 300 Tokens, 1 Sekunde. 80 % der Signale sind eindeutig. Sie werden sofort weitergeleitet.

Schicht 2 – Tiefenanalyse mit Few-Shot + CoT. Die verbleibenden 20 % (mehrdeutige oder kritische Signale) erhalten Few-Shot-Prompting mit 3 Beispielen ähnlicher mehrdeutiger Fälle, plus Chain-of-Thought-Begründung. Das dauert 1.800 Tokens, 4 Sekunden. Aber für ein Signal, das Millionen in der Allokation bewegen könnte, sind 4 Sekunden und 1.800 Tokens trivial.

Schicht 3 – Menschliche Überprüfung für Randfälle. Signale, bei denen die Zuversicht des Modells unter 70 % liegt, gehen an einen menschlichen Analysten. Das Modell liefert seine Schritt-für-Schritt-Begründung, sodass der Mensch nicht bei Null anfangen muss.

Dieser gestaffelte Ansatz optimiert gleichzeitig Geschwindigkeit, Kosten und Genauigkeit. Das meiste Volumen wird kostengünstig und schnell bearbeitet. Kritische Entscheidungen erhalten die volle Behandlung.

Sie können dieselbe Logik auf Ihr System anwenden:

1. Identifizieren Sie die Volumenverteilung Ihrer Aufgabe. Welcher Prozentsatz der Anfragen ist unkompliziert? Welcher Prozentsatz ist mehrdeutig oder komplex?
2. Leiten Sie unkomplizierte Anfragen über Zero-Shot.
3. Leiten Sie mehrdeutige oder komplexe Anfragen über Few-Shot + CoT.
4. Fügen Sie für die schwierigsten Fälle (hohe Einsätze, wirklich neuartig) menschliche Überprüfung mit KI-Unterstützung hinzu.
5. Messen Sie die Genauigkeit auf jeder Ebene. Passen Sie die Beispielqualität und die Begründungs-Prompts basierend auf den Fehlermodi an.

Das skaliert.

Eine Aktion, die Sie diese Woche unternehmen können

Wählen Sie einen Produktions-Prompt in Ihrem System. Denjenigen, der das größte Volumen oder die höchsten Einsätze verarbeitet.

Messen Sie seine aktuelle Genauigkeit. Führen Sie dann drei parallele Experimente durch:

1. Behalten Sie ihn bei (Baseline). Dokumentieren Sie die Genauigkeitsrate.
2. Fügen Sie 3 Few-Shot-Beispiele hinzu. Wählen Sie Beispiele, die repräsentativ für Ihre tatsächliche Datenverteilung sind – nicht handverlesen. Messen Sie die Genauigkeit.
3. Fügen Sie Chain-of-Thought-Begründung hinzu. Verwenden Sie denselben Baseline-Prompt, bitten Sie das Modell aber, Schritt für Schritt zu erklären, bevor es antwortet. Messen Sie Genauigkeit und Latenz.

Vergleichen Sie die drei. Welcher gibt Ihnen das beste Verhältnis von Genauigkeit zu Latenz zu Token-Kosten? Das ist Ihre Antwort für diese spezielle Aufgabe.

Die meisten Teams machen das einmal und wiederholen es nie. Der bessere Weg ist, dies vierteljährlich zu wiederholen. Ihre Daten entwickeln sich. Ihre Randfälle verschieben sich. Ihre Prompts sollten das auch tun.