Mehr Rechenzeit statt größerer Modelle
Nein. Sampling-Zufall (die Ziehung aus der Verteilung, Modul 1) steuert Variation — Zufall allein löst kein Logikproblem. Reasoning ist etwas anderes als „mehrmals würfeln".
Nein. Es ist derselbe Transformer, dieselbe Decode-Phase, stur Token für Token. Es gibt keinen „Rückwärtsgang" im Netz und keine verborgene Logik-Engine.
Ein Reasoning-Modell tippt nicht sofort die Antwort. Es generiert zuerst — ganz normal, Token für Token — Text in einen abgetrennten Denk-Block (Chain-of-Thought, „Gedankenkette"). Der Kontext baut sich dreiteilig auf:
Start- und Ende-Marker trennen den Denk-Block von der Antwort — erzeugt wird alles vom selben Decode-Loop.
Das Problem wird in Einzelschritte und Hypothesen aufgeteilt — wie auf einem Whiteboard.
Ein Fehler im Denk-Block wird von den nächsten Tokens erkannt und revidiert — „warte, nein …".
Reinforcement Learning auf verifizierbaren Aufgaben belohnt Denkwege, die zu richtigen Ergebnissen führen (siehe LLM-Grundlagen).
Erinnerung aus den LLM-Grundlagen: jede Vorhersage ist bedingt durch den Kontext. Genau das nutzt Reasoning aus:
P(Antwort | Prompt)
Das Modell muss beim allerersten Token „richtig abbiegen" — bei komplexer Logik geht das oft schief, und der Fehler pflanzt sich autoregressiv fort.
P(Antwort | Prompt + eigener Plan)
Der komplette Denkprozess steht im Kontext (KV-Cache), wenn die Antwort beginnt. Jedes Antwort-Token ist durch den geprüften Bauplan konditioniert.
Fehlersuche mit mehreren Verdächtigen, Architektur-Entscheidungen, verzwickte Migrationen, Mathe-/Logik-Anteile — alles, was man nicht auf einen Blick löst.
Umbenennen, Formatieren, Boilerplate, klare lokale Fixes — hier zahlt ihr Wartezeit und Tokens für einen Plan, den die Aufgabe nicht braucht.
Denk-Tokens sind Output-Tokens — der langsame, teure Teil der Decode-Phase (LLM-Grundlagen). Tausende davon, bevor die Antwort beginnt.
Der Agent denkt auch zwischen Tool-Calls: Ergebnis lesen, neu planen, nächstes Werkzeug — jeder Denk-Block gehört zum Verlauf.
Der Denk-Aufwand ist in Claude Code ein Regler (mehr Budget für schwere Aufgaben, wenig für Mechanik). Bedienung: Modul 4.
Entscheidet für jede Aufgabe: Denk-Budget hoch oder runter — mit einem Satz Begründung:
(a) 30 Methoden nach neuem Schema umbenennen · (b) Heisenbug mit drei möglichen Ursachen eingrenzen · (c) REST-Boilerplate für zwei neue Endpoints generieren · (d) Architektur-Entscheidung: Event-getrieben oder Batch? · (e) Changelog aus Commit-Messages formatieren · (f) Rundungslogik der Währungsumrechnung prüfen
Dauer ca. 5 Minuten · Zuruf im Plenum oder Partnerarbeit · kurze Pause — Auflösung auf der nächsten Folie
Die Trennlinie ist immer dieselbe: Mechanik löst man auf einen Blick — Mehrhypothesen-Probleme brauchen den Denk-Block.
| Aufgabe | Reasoning | Begründung |
|---|---|---|
| (a) 30 Methoden umbenennen | runter | Mechanik — Muster anwenden, kein Plan nötig |
| (b) Heisenbug, drei Verdächtige | hoch | Hypothesen bilden, prüfen, verwerfen |
| (c) REST-Boilerplate | runter | millionenfach gesehenes Standard-Muster |
| (d) Event vs. Batch | hoch | Abwägung mit Konsequenzen — der Plan ist das Produkt |
| (e) Changelog formatieren | runter | reine Transformation |
| (f) Währungs-Rundungslogik | hoch | Mathe-/Invarianten-Prüfung — Fehler sind subtil |
Alle Rechte vorbehalten
Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung, Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.
cgsit-claude-training · Exkurs Reasoning · v0.3.31