Reasoning oder nicht: Prompts nach Modelltyp
Reasoning-Modelle wollen anders angesprochen werden als klassische LLMs – wer beide gleich promptet, verschenkt Qualität oder Geld. Wann welcher Modelltyp die richtige Wahl ist, was ihm hilft, was ihm schadet und welche Few-Shot-Regeln 2026 gelten.
In Teil 1 ging es darum, warum Akronym-Frameworks ausgedient haben und welche Basis-Struktur sie ersetzt. Die funktioniert modellübergreifend – aber sobald du regelmäßig mit LLMs arbeitest oder Workflows baust, lohnt der Blick eine Ebene tiefer. Denn unter der Haube gibt es zwei Arbeitsweisen, und die reagieren auf denselben Prompt unterschiedlich.
Die Unterscheidung klingt akademischer, als sie ist. Wer einem Reasoning-Modell Prompts aus der GPT-3.5-Ära vorsetzt, bezahlt für Denkarbeit, die er gleichzeitig sabotiert. Wer umgekehrt ein Non-Reasoning-Modell wie einen Denker behandelt, bekommt selbstbewusst formulierte Abkürzungen. Beides kostet – einmal Geld und Latenz, einmal Qualität.
TL;DR
Reasoning- und Non-Reasoning-Modelle brauchen unterschiedliche Prompts – wer beide gleich behandelt, verschenkt Qualität oder zahlt drauf.
- Reasoning-Modelle wollen Ziel, Evidenz, Kriterien und Prüfauftrag – keine vorgekauten Denkschritte
- Non-Reasoning-Modelle wollen enge Aufgaben, klare Prozessschritte und gute Beispiele
- Few-Shot bleibt für Non-Reasoning-Modelle das stärkste Werkzeug, kann Reasoning-Modelle aber auf falsche Lösungswege fixieren
- Von den bekannten Reasoning-Verfahren bleibt im Alltag weniger übrig, als LinkedIn behauptet
Zwei Arbeitsweisen, ein Chatfenster
Reasoning-Modelle erzeugen interne Rechenschritte, bevor sie antworten – sie planen, verwerfen, prüfen, und erst dann kommt Text. Non-Reasoning-Modelle antworten direkt. Das macht sie nicht dümmer, sondern schneller und billiger, und für einen großen Teil der Alltagsaufgaben ist das die passende Eigenschaft. Extraktion, Klassifikation, Umformulieren, formatgebundene Ausgaben, Hochdurchsatz-Jobs in Pipelines – dafür braucht niemand ein Modell, das erst drei Absätze lang mit sich selbst ringt.
Im Chatfenster nimmt dir die Entscheidung inzwischen oft ein Router ab, der je nach Frage zwischen den Modi wechselt. Verlassen würde ich mich darauf nicht. Spätestens in der API, in eigenen LLM-Pipelines oder Workflows (z. B. in n8n) oder beim Modell-Dropdown wählst du selbst, und dann hilft eine simple Heuristik: Je mehr Abwägung, Abhängigkeiten und Unsicherheit in der Aufgabe stecken, desto eher lohnt Reasoning. Eine Architekturentscheidung, ein kniffliges Debugging, eine Forschungssynthese sind Reasoning-Fälle. Eine Rechnung klassifizieren ist keiner. Warum mehr Denktiefe kein Qualitätsregler ist und wann sie nur Geld verbrennt, habe ich hier ausführlich auseinandergenommen.
Was Reasoning-Modelle stark macht
Der Prompt für ein Reasoning-Modell definiert das Problem, nicht den Lösungsweg. Vier Zutaten haben sich bewährt.
Ein messbares Erfolgskriterium
„Analysiere diese Strategie“ lässt offen, woran ein gutes Ergebnis erkennbar wäre. „Bewerte die Strategie nach Umsetzbarkeit, Kosten und Risiken, empfiehl eine Option und benenne die größten Unsicherheiten“ gibt dem Modell einen Maßstab, gegen den es seine eigene Arbeit prüfen kann.
Gebundene Evidenz
Nur die mitgelieferten Quellen verwenden, Fakten von Schlussfolgerungen trennen, fehlende Evidenz kennzeichnen. Das schränkt den Lösungsraum ein – und genau davon lebt Grounding.
Gewichtete Kriterien
„Welche Lösung ist besser?“ lädt zum Münzwurf ein. „Gewichte Datenschutz mit 35 %, Wartbarkeit mit 25 %, Kosten mit 20 %“ zwingt zu einer nachvollziehbaren Abwägung, die sich hinterher auch gegen die Gewichtung kontrollieren lässt.
Verifikation statt Selbstkritik
„Reflektiere tief über deine Antwort“ produziert vor allem überzeugender klingende Antworten. „Prüfe jede Tatsachenbehauptung gegen die angegebenen Quellen“ oder „führe die vorhandenen Tests aus und nenne die Fehlschläge“ produziert Kontrolle. Eine konkrete Prüfhandlung schlägt jede allgemeine Sorgfalts-Beschwörung – und wo es um produktive Pipelines geht, gehört die Prüfung ohnehin aus dem Prompt heraus in ein QA-Gate.
Was denselben Modellen schadet, ist das Spiegelbild davon. Starre Denkpfade („bearbeite das exakt in diesen 14 Schritten“) legen das Modell auf einen Weg fest, der zur Aufgabe nicht passen muss. Die 70-Seiten-Materialschlacht, in der Regeln, Daten und Auftrag irgendwo verstreut liegen, verdrängt im Kontextfenster genau die Information, auf die es ankommt. Und Negativregel-Kaskaden („nicht werblich, nicht zu lang, nicht zu technisch, nicht langweilig …“) beschreiben alles außer dem gewünschten Verhalten. Eine positive Stilvorgabe plus zwei, drei harte Verbote leisten mehr als zehn weiche.
Was Non-Reasoning-Modelle stark macht
Hier dreht sich das Bild. Ohne eingebaute Denkschleife braucht das Modell mehr Führung – und belohnt diese zuverlässig.
Die Aufgabe muss eng geschnitten sein, ein Auftrag pro Prompt. „Fasse zusammen, analysiere kritisch, übersetze und mach noch Social-Media-Posts draus“ scheitert nicht an der Modellqualität, sondern daran, dass Priorität und Format nirgends definiert sind. Komplexe Jobs werden zerlegt: erst extrahieren, dann strukturieren, dann formulieren, dann prüfen – als Pipeline mit vier kleinen Prompts statt einem Monster. Klare operative Verben helfen zusätzlich. „Extrahiere“, „klassifiziere“, „konvertiere“ sind Arbeitsanweisungen; „beleuchte“, „sei kreativ“ und „mach was Professionelles draus“ sind Hoffnungen.
Das Ausgabeformat gehört exakt definiert, im Zweifel als Schema. Wo die Schnittstelle Structured Outputs oder JSON-Schema anbietet, ist das dem rein sprachlichen Format-Erzwingen vorzuziehen – der Prompt wünscht sich ein Format, das Schema erzwingt es. Welches Datenformat sich für welche Aufgabe eignet, steht hier im Detail.
Few-Shot: das unterschätzte Arbeitstier
Few-Shot-Beispiele sind für Non-Reasoning-Modelle das wirksamste einzelne Werkzeug – und gleichzeitig das am schlechtesten gepflegte. Sie lohnen sich, wenn Kategorien schwer abgrenzbar sind, ein Format ungewöhnlich ist, ein Stil getroffen werden muss oder interne Unternehmenslogik im Spiel ist. Die Auswahl folgt einer einfachen Regel, die kaum jemand anwendet: ein typischer Fall, ein schwieriger Fall, ein Grenzfall, optional ein Negativbeispiel. Drei unterschiedliche Beispiele schlagen zehn fast identische.
Der Haken steckt hier im Kleingedruckten. Das Modell übernimmt aus Beispielen nicht nur die Lösung, sondern auch Ton, Struktur, Annahmen – und Fehler. Ein schlechtes Beispiel ist deshalb schädlicher als gar keins. Bei Reasoning-Modellen kommt ein zweiter Effekt dazu, den OpenAI in den eigenen Best Practices benennt: Erst Zero-Shot probieren, Beispiele nur bei Bedarf nachlegen, denn unpassende Demonstrationen können das Modell auf einen Lösungsweg fixieren, den es allein besser gewählt hätte.
Die Verfahren aus den Papern – ein Reality-Check
Chain-of-Thought, Self-Consistency, Least-to-Most, Plan-and-Solve, Tree of Thoughts, ReAct – die Verfahrensliste liest sich beeindruckend und wird auf LinkedIn gern als Geheimarsenal verkauft. Für den Alltag Mitte 2026 schrumpft sie zusammen.
Chain-of-Thought (Wei et al. 2022) steckt in Reasoning-Modellen nativ drin; die explizite Aufforderung hat, wie in Teil 1 gezeigt, dort ausgedient. Für Non-Reasoning-Modelle bleibt sie bei Mathe- und Logikaufgaben ein legitimes Werkzeug. Self-Consistency (Wang et al. 2022) – mehrere unabhängige Lösungswege erzeugen, Mehrheitsentscheid nehmen – funktioniert nachweislich, aber nur bei Aufgaben mit eindeutiger Antwort und zum Preis mehrfacher Modellaufrufe. Für offene Schreibaufgaben taugt das Verfahren nicht, und sinnvoll umgesetzt ist es ein technischer Ablauf mit getrennten Aufrufen, kein „denk fünfmal nach“-Prompt. Least-to-Most und Plan-and-Solve sind im Kern Problemzerlegung mit Plan – nützlich, solange der Plan anpassbar bleibt und nicht als unverrückbares 25-Punkte-Korsett daherkommt.
Tree of Thoughts und ReAct schließlich sind ehrlicherweise keine Prompt-Techniken mehr. Ein echter Suchbaum braucht externe Zustandsverwaltung und Bewertung, ReAct braucht echte Tools samt Berechtigungs- und Abbruchlogik. Das ist Orchestrierung, also Software-Architektur – wer das in ein einzelnes Prompt-Textfeld tippt, spielt die Verfahren nur nach. Als Faustregel für die Praxis reicht: Zerlegung und Verifikation gehören in den Prompt, alles mit Schleifen, Zuständen und Werkzeugen gehört in den Code.
Kurz verdichtet
Für Reasoning-Modelle: Ziel, Evidenz, gewichtete Kriterien, Prüfauftrag – und dem Modell den Weg selbst überlassen. Für Non-Reasoning-Modelle: enge Aufgabe, klare Schritte, drei gute Beispiele, hartes Format. Für beide gilt, dass widersprüchliche Regeln und irrelevanter Langkontext mehr kaputtmachen als jeder fehlende Trick. Und produktive Prompts gehören versioniert und getestet, sonst bleibt jede Optimierung irgendwas zwischen Quiz und Anekdote.
Ganz heißer Take zum Schluss: Die Modelltyp-Frage ist die neue „Welches Keyword nehme ich“-Frage – alle reden über die Feinheiten, die meisten scheitern eine Etage tiefer, nämlich an der unklaren Aufgabe. Erst die Aufgabe sauber schneiden, dann den Modelltyp wählen, dann feilen. Im dritten Teil gibt es das Ganze zum Anfassen – fertige Vorlagen für Extraktion, Klassifikation, Analyse, Recherche und Schreibaufgaben, für Copy & Paste zum direkten Ausprobieren.