# Techniken: Reasoning & Genauigkeit

> Über die Grundlagen hinaus: Chain-of-Thought, Decomposition, Self-Consistency und Verifikation — welche Technik welche Aufgabe wirklich verbessert, und welche nur Kosten addiert.

Track: [Prompt Engineering](https://physar.tech/learn/prompt-engineering)  
Kanonische Fassung: https://physar.tech/learn/prompt-engineering/prompt-techniques  
Stand: 2026-07-22  
Interaktiver Teil: 8 Checks (nur im Browser)

## Reasoning-Techniken: mehr Genauigkeit — zum richtigen Preis

### Die Technik-Leiter: leicht zuerst, eskalieren nur bei Bedarf

Über die Grundlagen (klare Instruktion, Beispiele, Format) hinaus gibt es Techniken, die das **Schlussfolgern** verbessern. Sie sind kein Gratis-Upgrade: jede kostet Tokens, Latenz und Komplexität. Die Kunst ist, die **leichteste** Technik zu wählen, die die Aufgabe löst.

Klare Instruktion → Few-shot → **Chain-of-Thought** → Decomposition / Self-Consistency

> **Grundregel:** Steig die Leiter Stufe für Stufe — und nur, wenn die Messung sagt, dass du musst. Schwerer ist nicht sicherer, nur teurer und schwerer zu debuggen.

### Chain-of-Thought: Raum zum Denken

Bei **mehrstufigen** Aufgaben (rechnen, vergleichen, aus Regeln ableiten) scheitern Modelle oft, weil sie viele Schritte in eine einzige Token-für-Token-Vermutung pressen. **Chain-of-Thought (CoT)** gibt dem Modell Raum, die Zwischenschritte auszuschreiben, bevor es die Endantwort gibt — das senkt Fehler.

> **Was CoT ist:** Kein magischer Schalter, sondern explizit gemachtes Zwischen-Reasoning. Die sichtbare Kette ist eine **Rationalisierung**, kein Beweis — sie kann selbstsicher falsch sein.

### Wo CoT nicht hilft

CoT pauschal überall einzusetzen ist ein häufiger Fehler. Bei **simpler** Klassifikation oder einem Lookup addiert es nur Kosten und Latenz — und kann sich in eine falsche Begründung hineinreden. Und CoT verbessert das **Schlussfolgern**, nicht das **Wissen**: über einen falschen Fakt sauber zu reasonen macht ihn nicht richtig.

|  |  |
| --- | --- |
| Mehrstufige Ableitung, Rechnung, Logik | CoT hilft |
| Einfache Klassifikation / Lookup | CoT = nur Overhead |
| Fehlender/falscher Fakt | Kein Reasoning-, ein Grounding-Problem (→ RAG) |

> **Trennen:** Unterscheide „kann nicht schlussfolgern“ von „weiß es nicht“. Ersteres löst eine Technik, Letzteres nur Kontext/Retrieval.

### Zerlegen: Decomposition & Chaining

Ein Prompt, der drei Dinge auf einmal tun soll (extrahieren, bewerten, formatieren), teilt seine Aufmerksamkeit und verbirgt, welcher Teilschritt versagt hat. **Decomposition** zerlegt die Aufgabe in fokussierte Schritte (Prompt Chaining) — jeder einzeln prompt-, prüf- und verbesserbar.

> **Struktur schlägt Monolith:** Ein überladener Mega-Prompt wird nicht besser, indem man ihn detaillierter macht — sondern indem man ihn aufteilt.

### Self-Consistency: mehrere Pfade, Mehrheit

Wenn ein Modell eine Reasoning-Aufgabe **öfter richtig als falsch**, aber nicht zuverlässig löst, hilft **Self-Consistency**: mehrere unabhängige Reasoning-Pfade sampeln (Temperature > 0) und die häufigste Antwort per Mehrheit nehmen. Das mittelt einzelne Fehl-Pfade heraus.

> **Verstärker, kein Erzeuger:** Self-Consistency verstärkt eine **korrekte Mehrheit** — es kann keine erzeugen. Ist das Modell mehrheitlich falsch, festigt Voting den Fehler. Und es kostet das N-fache pro Entscheidung.

### Reasoning und Ausgabe trennen — plus Verifikation

Brauchst du **beides** — freies Reasoning UND strikte JSON-Ausgabe — dann zwing sie nicht in dasselbe Feld: das korrumpiert entweder das Schema oder erstickt das Reasoning. Gib dem Reasoning einen eigenen Bereich (z. B. einen `<reasoning>`-Block, dann das JSON; oder einen zweiten, rein formatierenden Aufruf).

Und wo Fehler **subtil und still** sind (falsche Spalte im generierten SQL, fehlender Filter), lohnt ein **Verifikations-Schritt**: das Modell die Ausgabe gegen Schema/Constraints selbst prüfen lassen — ein günstiger Filter, aber keine Garantie (das Modell teilt seine eigenen blinden Flecken).

### Techniken sind Hypothesen — gleich im Check

Jede Technik hier ist eine **Hypothese mit Kosten**. Ob CoT, Self-Consistency oder Decomposition sich lohnen, entscheidet nicht das Bauchgefühl, sondern die Messung an einer repräsentativen Menge — dieselbe empirische Disziplin wie in den Grundlagen und im Evaluation-Track.

> **Gleich im Check:** Du entscheidest jetzt selbst: welche Technik bei welcher Aufgabe wirklich hilft — und wann sie nur Kosten addiert oder das Problem gar kein Reasoning-Problem ist.

## Quellen

- Chain-of-Thought Prompting Elicits Reasoning in Large Language Models — Wei et al., 2022
- Large Language Models are Zero-Shot Reasoners — Kojima et al., 2022
- Self-Consistency Improves Chain of Thought Reasoning in Language Models — Wang et al., 2023
- Least-to-Most Prompting Enables Complex Reasoning in Large Language Models — Zhou et al., 2022
- A Systematic Survey of Prompt Engineering in Large Language Models — Sahoo et al., 2024
- Retrieval-Augmented Generation for Large Language Models: A Survey — Gao et al., 2023