Reasoning-Techniken: mehr Genauigkeit — zum richtigen Preis
Einführung · 7 Abschnitte · ~9 Min Lesezeit · Stand
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
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.
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) |
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.
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.
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.