5. Reasoning

Reasoning

Ein Modell, das Token für Token antwortet, hat ein strukturelles Problem: Es muss die erste Silbe der Antwort produzieren, bevor es die Aufgabe durchdacht hat. Bei „Wie heißt die Hauptstadt von Österreich” ist das gleichgültig. Bei „Warum liefert dieser Endpunkt manchmal 500 zurück” ist es fatal, denn dort hängt die richtige erste Silbe davon ab, was die Analyse ergibt.

Die Antwort auf dieses Problem heißt Reasoning, und sie ist konzeptuell erstaunlich billig: Man lässt das Modell erst schreiben und dann antworten.

Chain-of-Thought: die einfache Fassung

Die Beobachtung stammt aus 2022. Wenn man ein Modell auffordert, schrittweise vorzugehen, statt sofort das Ergebnis zu nennen, steigt die Trefferquote bei mehrstufigen Aufgaben deutlich. Nicht weil das Modell dadurch klüger wird, sondern weil die Zwischenschritte im Kontext landen und die nächste Vorhersage darauf zugreifen kann.

Frage: Ein Server verarbeitet 40 Anfragen pro Sekunde. Eine Anfrage
       dauert im Schnitt 120 ms. Wie viele Anfragen sind im Mittel
       gleichzeitig in Bearbeitung?

Ohne Zwischenschritte:  "Etwa 40."               (falsch)

Mit Zwischenschritten:  "Ankunftsrate 40/s, Bearbeitungsdauer 0,12 s.
                         Nach Little's Law: L = 40 × 0,12 = 4,8.
                         Also etwa 5 gleichzeitig."   (richtig)

Der Trick funktioniert, weil das Modell im zweiten Fall auf 40 × 0,12 schauen kann, während es die Antwort formuliert. Im ersten Fall musste es die Zahl aus dem Nichts nennen. Das ist der ganze Mechanismus: Zwischenschritte sind ein Notizzettel, und der Notizzettel ist Teil der Eingabe für die nächste Vorhersage.

Reasoning-Modelle: die eingebaute Fassung

Seit 2024 ist dieses Verhalten nicht mehr eine Prompt-Technik, sondern in die Modelle hineintrainiert. Ein Reasoning-Modell erzeugt vor der eigentlichen Antwort eine interne Denkphase, oft ein Vielfaches länger als die Antwort selbst, und zwar ohne dass man darum bitten muss.

sequenceDiagram
  participant U as Anfrage
  participant M as Modell
  participant A as Antwort
  U->>M: Aufgabe
  M->>M: Denkphase (interne Tokens)
  Note over M: Ansätze prüfen,<br/>verwerfen, umkehren,<br/>Zwischenergebnisse festhalten
  M->>A: Antwort (sichtbare Tokens)

Vier Punkte, die man dazu wissen muss.

Denken kostet Tokens, und zwar Ausgabe-Tokens. Die Denkphase wird zum Ausgabepreis abgerechnet, auch wenn Sie sie nicht sehen. Eine Anfrage mit 300 Tokens Antwort und 8.000 Tokens Denkphase kostet das Achtundzwanzigfache einer Anfrage ohne Denkphase. Diese Zahl erklärt praktisch jede überraschende Rechnung.

Die Denkphase zählt gegen die Ausgabegrenze. Wenn max_tokens knapp bemessen ist, kann das Modell sein Budget beim Denken verbrauchen und die Antwort mitten im Satz abbrechen. Bei aktivem Reasoning gehört die Obergrenze großzügig gesetzt.

Man sieht die Denkphase in der Regel nicht im Rohtext. Bei aktuellen Modellen wird die eigentliche Gedankenkette nicht ausgeliefert; man erhält auf Wunsch eine Zusammenfassung. Für die Fehlersuche ist das eine echte Einschränkung, und man sollte sie nicht durch Prompts umgehen wollen, die das Modell auffordern, seine Gedanken offenzulegen: Man erhält dann eine plausibel klingende Nachkonstruktion, nicht das Protokoll.

Die Tiefe ist steuerbar. Statt eines festen Token-Budgets gibt es bei aktuellen Modellen zwei Regler: Das Modell entscheidet adaptiv, ob und wie lange es denkt, und eine Stufe gibt vor, wie großzügig es dabei sein darf. Bei Claude heißt diese Stufe Effort; im Folgenden ist mit „Denkstufe” immer sie gemeint. Die höchste Stufe ist nicht die beste Wahl, sondern die teuerste; bei einfachen Aufgaben führt sie zu Überlegungen, die niemand braucht.

Die Parameter bei Claude

Zwei getrennte Angaben im Request, und beide gehören an die richtige Stelle:

{
  "model": "claude-opus-5",
  "max_tokens": 32000,
  "thinking": { "type": "adaptive" },
  "output_config": { "effort": "high" }
}

thinking schaltet das adaptive Denken ein, effort legt die Tiefe fest. Die Stufen sind low, medium, high, xhigh und max; ohne Angabe gilt high. Beachten Sie, dass effort innerhalb von output_config steht und nicht auf oberster Ebene.

Für Programmieraufgaben und agentisches Arbeiten ist xhigh die Empfehlung, und es ist auch die Voreinstellung in Claude Code. max gehört den Fällen, in denen Korrektheit mehr zählt als Kosten und Wartezeit; low und medium genügen für Routinearbeit und sparen deutlich.

Ältere Anleitungen zeigen an dieser Stelle noch ein festes Token-Budget (thinking: { "type": "enabled", "budget_tokens": 10000 }). Aktuelle Modelle weisen das mit einem Fehler 400 zurück; die Tiefe wird über effort gesteuert, nicht über eine Tokenzahl. Andere Anbieter haben denselben Regler unter anderem Namen.

Minutenlange Antworten sind normal

Auf schwierigen Aufgaben kann eine einzige Anfrage bei hoher Denkstufe viele Minuten laufen. Wenn Sie so etwas in eine Anwendung einbauen, planen Sie das ein: Streaming statt Warten auf die Gesamtantwort, großzügige Timeouts, und eine Anzeige, die dem Benutzer sagt, dass gearbeitet wird. Ein Standard-HTTP-Timeout von 30 Sekunden reicht dafür nicht.

Wann Reasoning hilft und wann nicht

An dieser Unterscheidung hängen Kosten und Antwortzeit, denn die Denkphase wird in beiden Fällen bezahlt.

Reasoning hilft deutlich	Reasoning bringt kaum etwas
Fehlersuche mit mehreren Verdachtsmomenten	Text umformatieren
Entwürfe abwägen und begründen	Übersetzen
Mehrstufige Umbauten in Code	Aus einem Text Felder extrahieren
Aufgaben mit Rechnung oder Logik	Etwas nachschlagen, das im Kontext steht
Widersprüche in Anforderungen finden	Boilerplate nach Vorlage erzeugen
Planung vor der Umsetzung (Kapitel 10)	Kurze Fragen mit einer Antwort

Die Faustregel: Reasoning hilft, wenn die Aufgabe Zwischenschritte hat, deren Ergebnis den nächsten Schritt verändert. Wo die Antwort im Grunde eine Transformation der Eingabe ist, brauchen Sie es nicht, und es kostet.

Vorsicht bei der Grenze zwischen Wollen und Können. Reasoning macht ein Modell besser darin, aus dem zu schließen, was es hat. Es ersetzt keine Information. Ein Modell, das die Bibliotheksversion nicht kennt, kennt sie nach zehntausend Denk-Tokens auch nicht. Bei Wissenslücken hilft Kontext, nicht Denken. Diese Verwechslung ist die häufigste falsche Anwendung: Auf eine faktisch falsche Antwort mit einer höheren Denkstufe zu reagieren, produziert eine besser begründete falsche Antwort.

Überdenken

Reasoning hat eine Kehrseite, die im Unterricht regelmäßig auftritt. Bei hohen Denkstufen neigen Modelle dazu,

• Aufgaben umzudeuten, die eindeutig waren,
• Lösungen zu bauen, die allgemeiner sind als gefordert,
• Randfälle abzusichern, die nicht eintreten können,
• und Alternativen zu diskutieren, nach denen niemand gefragt hat.

Der wirksame Hebel dagegen ist nicht ein längerer Prompt mit mehr Verboten, sondern eine niedrigere Denkstufe. Wo das nicht reicht, wirkt eine klare Abgrenzung: eine Aufgabenbeschreibung, die sagt, was nicht zum Auftrag gehört. Was hier gilt, gilt in Kapitel 10 wieder: Ein Plan mit einem Abschnitt „Nicht-Ziele” ist mehr wert als einer mit doppelt so vielen Zielen.

Warum „Bist du sicher?” nicht funktioniert

Ein naheliegender Gedanke: Wenn Nachdenken hilft, dann hilft auch Nachfragen. Man lässt das Modell seine eigene Antwort prüfen.

Das funktioniert schlechter als erwartet, aus zwei Gründen. Erstens ist die Prüfung von derselben Verteilung erzeugt wie die Antwort; das Modell hat denselben blinden Fleck. Zweitens, und das ist der stärkere Effekt, ist Nachgeben aus dem Alignment-Training heraus die besser bewertete Reaktion (Kapitel 3). Sie messen mit „Bist du sicher?” die Höflichkeit des Modells, nicht die Korrektheit der Antwort.

Was tatsächlich hilft, ist Prüfung von außen:

• Ausführen. Compiler, Typprüfung, Linter, Tests. Eine widerlegbare Behauptung wird von der Maschine widerlegt, nicht vom Modell (Kapitel 11).
• Nachsehen. Werkzeuge, mit denen der Agent die Datei tatsächlich lesen und die Dokumentation tatsächlich abrufen kann (Kapitel 8).
• Frischer Kontext. Ein zweites Modell oder eine neue Sitzung, die nur den Code und die Anforderung sieht, ohne die Begründung der ersten Runde. Ein Prüfer mit eigenem Kontext ist wesentlich brauchbarer als Selbstkritik im gleichen Gespräch.

Bei aktuellen Modellen kommt ein Detail dazu, das gegen die alte Regel läuft: Sie prüfen ihre Arbeit von selbst. Eine Anweisung wie „verifiziere dein Ergebnis am Ende” führt bei ihnen zu doppelter Arbeit und längeren Antworten statt zu mehr Sicherheit. Solche Anweisungen sind Altlasten aus einer früheren Modellgeneration und gehören überprüft.

Benchmarks mit Vorsicht lesen

Bei jeder neuen Modellgeneration werden Prozentwerte auf Benchmarks veröffentlicht. Drei Vorbehalte, die man kennen sollte, bevor man auf so eine Zahl eine Entscheidung stützt.

Kontamination. Viele Benchmarks sind öffentlich und liegen mit hoher Wahrscheinlichkeit in den Trainingsdaten. Ein Modell kann eine Aufgabe gelöst haben, weil es die Lösung kennt.

Aufgabenzuschnitt. Benchmarks bestehen aus abgegrenzten Aufgaben mit klarer Erfolgsdefinition. Ihre Arbeit besteht aus unklaren Aufgaben in gewachsenem Code. Der Zusammenhang zwischen beidem ist locker.

Der Vergleich ist selten fair. Dieselbe Aufgabe bei unterschiedlichen Denkstufen, mit unterschiedlichen Werkzeugen und unterschiedlichem Gerüst ergibt völlig verschiedene Zahlen. Ein Prozentwert ohne Angabe der Einstellungen ist eine Behauptung.

Die brauchbare Alternative ist unspektakulär: Legen Sie sich fünf bis zehn Aufgaben aus Ihrer eigenen Arbeit als Prüfmenge zurecht und lassen Sie neue Modelle darauf laufen. Das ist die einzige Messung, deren Ergebnis für Sie etwas bedeutet, und sie kostet einen Nachmittag.

Häufige Stolperfallen

1. Reasoning bei jeder Aufgabe einschalten. Bei Formatierung und Extraktion zahlt man Denk-Tokens ohne Gegenwert.
2. Die Denkphase nicht ins max_tokens einrechnen. Die Antwort bricht mitten im Satz ab, und die Ursache steht nicht in der Fehlermeldung.
3. Reasoning gegen Wissenslücken einsetzen. Besser begründet, gleich falsch. Fehlende Information braucht Kontext.
4. Immer die höchste Denkstufe wählen. Teurer, langsamer, und bei einfachen Aufgaben schlechter, weil überdacht.
5. „Bist du sicher?” für eine Prüfung halten. Sie messen Nachgiebigkeit.
6. Verifikationsanweisungen aus alten Prompts weiterschleppen. Aktuelle Modelle prüfen selbst; die Anweisung verdoppelt nur den Aufwand.
7. Benchmark-Zahlen ohne Einstellungen vergleichen. Ohne Angabe von Denkstufe und Gerüst ist die Zahl nicht interpretierbar.

Lernergebnisse: Was Sie nach diesem Kapitel können sollten

• Erklären: erklären, warum Zwischenschritte die Trefferquote bei mehrstufigen Aufgaben erhöhen, und dies mit der Token-für-Token-Vorhersage aus Kapitel 3 verbinden.
• Erklären: den Unterschied zwischen Chain-of-Thought als Prompt-Technik und einem Reasoning-Modell benennen.
• Anwenden: die Kosten- und Zeitfolgen einer Denkphase abschätzen und die Ausgabegrenze entsprechend setzen.
• Beurteilen: für eine gegebene Aufgabe entscheiden, ob Reasoning angemessen ist, und die Entscheidung begründen.
• Anwenden: die Denkstufe passend zur Aufgabe wählen (bei Claude effort in Verbindung mit adaptivem thinking) und Überdenken durch klare Abgrenzung eindämmen.
• Erklären: begründen, warum Selbstprüfung durch das Modell schwach ist, und drei wirksame externe Prüfverfahren nennen.
• Beurteilen: eine veröffentlichte Benchmark-Angabe kritisch einordnen und eine eigene Prüfmenge für die eigene Arbeit entwerfen.