Techniken: Reasoning und Genauigkeit

Jede Technik kostet — deshalb eine Leiter

Über den Grundlagen liegt eine Familie von Techniken, die Genauigkeit gegen Tokens, Latenz und Komplexität tauschen: Zwischenschritte ausschreiben lassen, die Aufgabe zerlegen, mehrfach sampeln, verifizieren. Keine davon ist gratis, und keine hilft überall. Der häufigste Fehler ist nicht, die falsche Technik zu wählen — es ist, gleich mehrere gleichzeitig zu bauen, bevor gemessen wurde, ob eine einzige nötig ist.

Die tragfähige Reihenfolge ist eine Leiter: die leichteste Stufe zuerst, und nur bei gemessenem Bedarf eskalieren. Jede Stufe ist teurer als die vorige, und jede Stufe, die du überspringst, bezahlst du dauerhaft pro Aufruf.

Die Leiter hat noch eine zweite, unterschätzte Funktion: Sie ordnet die Diagnose. Wer bei einem Fehlerbild direkt zur teuersten Stufe greift, hat die Frage übersprungen, ob überhaupt ein Reasoning-Problem vorliegt. In der Praxis sitzt die Ursache erstaunlich oft eine Stufe unterhalb dessen, wo man sie sucht — in einer unvollständigen Spezifikation oder in einem fehlenden Beispiel, nicht im Denkvermögen des Modells.

Chain-of-Thought: Rechenraum in der Ausgabe

Chain-of-Thought (CoT) heißt: das Modell die Zwischenschritte ausschreiben lassen, statt direkt die Antwort zu verlangen. Wei und Kollegen zeigten das 2022 mit acht Beispielen, in denen jeweils der Lösungsweg mitstand — und erreichten damit auf dem Rechenaufgaben-Benchmark GSM8K mit einem 540B-Modell den damaligen Stand der Technik, besser als ein feinjustiertes Modell mit separatem Verifizierer.

Chain-of-Thought — Eine Prompt-Technik, bei der das Modell Zwischenschritte explizit in die Ausgabe schreibt, bevor es die Antwort nennt. Der Effekt ist mechanisch: Zwischenergebnisse, die sonst in einem Schritt entstehen müssten, stehen als Text da und sind für die folgenden Tokens verfügbar.

Diese mechanische Lesart ist die nützliche. CoT verleiht keine Einsicht — es verschiebt Rechenarbeit in die Ausgabe, wo sie über mehrere Tokens verteilt stattfinden kann. Daraus folgt direkt, wann es hilft: bei Aufgaben mit echten Zwischenergebnissen. Und wann nicht: wenn es nichts zu verketten gibt.

Wo CoT nicht hilft — und das ist gut belegt

Hier liegt der Befund, der die meisten Prompt-Sammlungen überholt. Sprague und Kollegen haben 2024 eine quantitative Meta-Analyse über mehr als 100 Arbeiten zu CoT gelegt und zusätzlich 20 Datensätze über 14 Modelle selbst gemessen. Ergebnis: Der starke Gewinn tritt vor allem bei Mathematik und symbolischem Schließen auf. Bei anderen Aufgabentypen bleiben die Gewinne deutlich kleiner.

Die schärfste Einzelbeobachtung betrifft MMLU, einen der am häufigsten zitierten Wissens-Benchmarks: Dort liefert direktes Antworten fast identische Genauigkeit wie CoT — es sei denn, die Frage oder die Antwort des Modells enthält ein Gleichheitszeichen. Der Gewinn hängt also an der symbolischen Operation, nicht am Nachdenken im Allgemeinen.

Aufgabentyp

Was CoT dort leistet

Rechnen, Einheiten, Tarifstufen

Trägt deutlich — es gibt Zwischenergebnisse, die aufeinander aufbauen.

Logik, Constraint-Prüfung, Ableitung

Trägt — der Zwischenzustand muss irgendwo stehen.

Abruf und Klassifikation

Trägt kaum — es gibt keine Zwischenschritte, nur Kosten und Latenz.

Zusammenfassen, Umformulieren

Trägt kaum — die Arbeit ist Auswahl, nicht Verkettung.

Reasoning ersetzt kein Wissen

Ein Muster, das in Reviews regelmäßig falsch diagnostiziert wird: Ein Assistent beantwortet Fragen zu eurer Storno-Policy falsch. Die Antworten sind gut begründet, flüssig, in sich schlüssig — und inhaltlich erfunden, weil die Policy nirgends im Kontext steht. Der Reflex lautet, mehr und ausführlicheres CoT einzubauen. Er ist falsch.

CoT verlängert die Kette der Schlüsse aus dem, was vorhanden ist. Fehlt die Prämisse, wird die Kette länger und die Begründung überzeugender, ohne dass die Antwort richtiger wird — im Gegenteil: Eine gut begründete falsche Antwort ist im Review schwerer zu erkennen als eine kurze falsche.

• Reasoning-Problem — alle nötigen Angaben stehen im Prompt, die Verknüpfung scheitert. CoT, Zerlegung, Verifikation greifen.
• Wissens-Problem — eine nötige Angabe fehlt im Prompt. Nur Bereitstellen hilft: Kontext mitgeben, Retrieval, oder die Frage abweisen.
• Spezifikations-Problem — die Angabe ist da, aber die Aufgabe ist unklar. Zurück zu den Grundlagen, nicht nach vorn zur Technik.

Zerlegen: Dekomposition und Verketten

Der typische gewachsene Produktions-Prompt erledigt vier Dinge in einem Aufruf: extrahieren, bewerten, priorisieren, formatieren. Er wird lang, und die Fehler sind diffus — meist leidet der Schritt, der am Ende steht, weil er mit dem Rest um Aufmerksamkeit und Ausgabelänge konkurriert. Detaillierter formulieren hilft dann kaum, weil das Problem die Anzahl der Aufgaben ist, nicht ihre Beschreibung.

Die Antwort ist Zerlegung: mehrere fokussierte Aufrufe, deren Ausgabe jeweils Eingabe des nächsten ist. Zhou und Kollegen haben dieses Vorgehen als Least-to-Most-Prompting untersucht — erst in Teilprobleme zerlegen, dann der Reihe nach lösen. Der Betriebsvorteil ist unabhängig von der Genauigkeit: Jeder Schritt wird einzeln prüfbar, einzeln messbar und einzeln austauschbar.

Self-Consistency: mehrere Pfade, eine Mehrheit

Wenn ein Reasoning-Pfad manchmal abbiegt, kann man mehrere gehen. Self-Consistency (Wang und Kollegen, 2022) sampelt statt des einen greedy-Pfades eine Menge verschiedener Reasoning-Pfade und nimmt die Antwort, die am häufigsten herauskommt — die Pfade werden herausgemittelt, die Antwort bleibt. Die Gewinne waren deutlich: auf GSM8K +17,9 Prozentpunkte, auf SVAMP +11,0, auf AQuA +12,2, auf StrategyQA +6,4.

Zwei Voraussetzungen sind nicht verhandelbar, und beide werden in der Praxis verletzt. Erstens braucht das Verfahren Streuung: Bei temperature: 0 erzeugt jeder Lauf denselben Pfad, und die Mehrheit ist eine Kopie derselben Antwort. Zweitens braucht es eine Antwort, die sich vergleichen lässt — eine Zahl, ein Label, eine ID. Für freie Prosa gibt es keine Mehrheit, weil zwei Formulierungen nie identisch sind.

Voraussetzung

Warum sie zählt

temperature über 0

Ohne Streuung ist die Mehrheit dieselbe Antwort n-mal — kein Informationsgewinn, n-fache Kosten.

Vergleichbare Endantwort

Zahlen und Labels lassen sich zählen, Prosa nicht. Ohne Zählbarkeit kein Mehrheitsentscheid.

Budget für n Aufrufe

Kosten und Latenz skalieren mit n; das ist die teuerste Stufe der Leiter.

Self-Consistency — Ein Dekodierverfahren, das mehrere Reasoning-Pfade zur gleichen Frage sampelt und die Endantwort per Mehrheit bestimmt, statt einen einzigen Pfad zu verfolgen. Der Reasoning-Text wird verworfen; gezählt wird nur, worauf die Läufe hinauslaufen.

Praktisch ist die Technik damit auf einen schmalen Aufgabentyp begrenzt: Klassifikation, Rechenergebnis, Auswahl aus einer festen Menge. Genau dort ist sie stark, weil ein einzelner falscher Pfad von den übrigen überstimmt wird. Für einen Assistenten, der Freitext produziert, ist sie kein Kandidat — und das ist keine Feinheit, sondern die häufigste Fehlanwendung: Ohne zählbare Endantwort bleibt nur, die n Antworten wieder von einem Modell zusammenfassen zu lassen, und dann hast du die Mehrheit gegen eine weitere Generierung getauscht.

Selbstverifikation — und wo sie aufhört zu wirken

Ein naheliegender, billiger Hebel: das Modell seine eigene Ausgabe prüfen lassen. Er funktioniert — aber nur in einer bestimmten Form, und der Unterschied ist scharf belegt. Huang und Kollegen untersuchten intrinsische Selbstkorrektur, also den Fall, dass ein Modell seine Antwort allein aus eigener Kraft und ohne externe Rückmeldung überarbeitet. Ergebnis: Bei Reasoning-Aufgaben gelingt das kaum, und die Leistung wird nach der Selbstkorrektur teils schlechter als vorher.

Das ist keine Absage an Verifikation, sondern eine Präzisierung: Es fehlt das Kriterium von außen. Eine Rückfrage, ob das Modell sicher sei, liefert keines — es hat dieselbe Information wie im ersten Durchgang und wird eher zu einer Änderung gedrängt als zur richtigen Antwort. Eine Prüfung gegen etwas Gegebenes ist ein völlig anderer Vorgang.

Trägt: Prüfung gegen ein externes Kriterium

Trägt nicht: Prüfung gegen sich selbst

Jede Spalte der Query gegen ein mitgegebenes Schema prüfen lassen

Fragen, ob die Query korrekt ist

Für jede Aussage die Belegstelle im mitgegebenen Dokument nennen lassen

Fragen, ob die Antwort stimmt

Ausführen, Parsen, Schema-Validierung, Diff im Code

Zur Überarbeitung auffordern, ohne neue Information zu liefern

Die ausgeschriebene Kette ist keine Erklärung

Ein Missverständnis mit Folgen für Audits: Der ausgeschriebene Reasoning-Text sieht wie eine Begründung aus, ist aber nicht zwingend die Ursache der Antwort. Turpin und Kollegen haben das gezielt getestet: Sie fügten dem Prompt verzerrende Merkmale hinzu — etwa die Antwortoptionen in den Few-shot-Beispielen so umzusortieren, dass die richtige Antwort immer die erste war.

Die Modelle folgten der Verzerrung, schrieben Begründungen, die zur verzerrten Antwort passten, und erwähnten das verzerrende Merkmal systematisch nicht. Über 13 Aufgaben aus BIG-Bench Hard fiel die Genauigkeit um bis zu 36 Prozentpunkte, während der Begründungstext weiter plausibel aussah.

Reasoning und Ausgabe strukturell trennen

Sobald ein Prompt beides verlangt — schrittweises Vorgehen und ein strikt geparstes Ausgabeformat — kollidieren zwei Anforderungen im selben Ausgabetext. Das übliche Ergebnis: Der Parser bekommt Prosa vor dem JSON, oder das Reasoning bleibt aus, weil das Format dominiert.

Die Lösung ist strukturell, nicht sprachlich: Reasoning in einen eigenen, benannten Abschnitt, die Nutzlast in einen zweiten. Die Anthropic-Doku empfiehlt dafür Tags wie <thinking> und <answer>, damit die Trennung sauber bleibt; der Konsument liest ausschließlich den Nutzlast-Abschnitt. Verfügt das Modell über einen eigenen Reasoning-Modus, ist die Trennung schon vorhanden — dann steuerst du den Aufwand über den dafür vorgesehenen Parameter statt über Prompt-Text.

Was jede Stufe kostet

Damit die Leiter eine Entscheidung und keine Vorliebe ist, hier die Preise nebeneinander. Die relevante Größe ist selten der Token-Preis allein — es sind Latenz und Betriebskomplexität, die Nutzer und Bereitschaftsdienst tatsächlich spüren.

Stufe

Preis

Spezifikation schärfen

Etwas längerer Prompt, sonst nichts. Immer der erste Schritt.

Few-shot-Beispiele

Fester Kontext-Aufschlag pro Aufruf, plus Pflege der Beispiele.

Chain-of-Thought

Deutlich mehr Ausgabe-Tokens und Latenz — spürbar bei hohem Volumen.

Zerlegen und Verketten

Mehrere Aufrufe, Zustand zwischen den Stufen, mehr Fehlerpfade.

Mehrfach sampeln

n-fache Kosten und Latenz; braucht Streuung und vergleichbare Antworten.

Techniken sind Hypothesen

Alle Zahlen in diesem Modul stammen aus Messungen an bestimmten Modellen, Datensätzen und Zeitpunkten. Sie sagen dir, welche Technik bei welchem Aufgabentyp plausibel trägt — sie sagen nicht, was bei euren Daten passiert. Genau das ist der Grund, warum die Meta-Analyse überhaupt entstehen musste: Über 100 Einzelarbeiten hatten CoT gemessen, und erst die Zusammenschau zeigte, wo der Gewinn tatsächlich sitzt.

Die Konsequenz für dein Vorgehen ist unspektakulär und wirksam: eine Stufe der Leiter ändern, an fixer Fallmenge messen, Ergebnis notieren, erst dann die nächste Stufe erwägen. Zwei Stufen gleichzeitig zu ändern kostet dich die Information, welche gewirkt hat.

Zusammenfassung — gleich im Check

Du kennst jetzt die Leiter und ihre Preise: CoT verschiebt Rechenarbeit in die Ausgabe und trägt bei Zwischenergebnissen, nicht bei Abruf. Zerlegen hilft, wenn ein Prompt zu viele Aufgaben trägt — deterministische Teile gehören in den Code. Self-Consistency braucht Streuung und vergleichbare Endantworten. Verifikation braucht ein externes Kriterium; ohne eines wird sie schlechter als nichts. Und der ausgeschriebene Reasoning-Text ist eine Rechenhilfe, kein Prüfprotokoll.