Wenn mehr Nachdenken die Antwort verschlechtert: Was die Evidenz zu „Overthinking“ bei Reasoning-Modellen zeigt – und was nicht

Die Frage: Verbessert mehr Reasoning immer die Antwort?

Mehr Rechenleistung während der Inferenz kann einem Modell zusätzliche Möglichkeiten geben, eine Aufgabe zu lösen. Daraus folgt jedoch weder, dass jedes weitere Token die Antwort verbessert, noch dass eine längere Reasoning-Trajektorie immer zuverlässiger ist. Genau dieser Frage widmet sich der Artikel „When More Thinking Hurts: Overthinking in LLM Test-Time Compute Scaling“: Er untersucht, wie sich die Leistung verändert, wenn das Reasoning-Budget steigt, und in welchen Fällen eine zunächst richtige Antwort falsch werden kann.

Die zentrale Aussage ist bewusst begrenzt. Die Arbeit stellt die intuitive Regel infrage, dass mehr Nachdenken immer besser sei, und analysiert abnehmende marginale Erträge sowie ungünstige Antwortwechsel. Für sich genommen legt sie aber keine Tokenzahl fest, die für alle Modelle, Fragen oder Produktionsumgebungen geeignet wäre. Wie lange Reasoning nützlich ist, hängt von der Aufgabe und davon ab, wie das System konfiguriert und evaluiert wurde.

Sinnvoll ist es, drei Ebenen auseinanderzuhalten. Ein beobachtetes Ergebnis beschreibt, was unter den experimentellen Bedingungen des Artikels geschieht. Eine Interpretation ist die Erklärung, die die Autorinnen und Autoren dafür vorschlagen. Eine operative Empfehlung – etwa eine automatische Abbruchregel nach einer bestimmten Anzahl von Tokens – erfordert zusätzliche Evidenz für das konkrete Modell und die konkrete Aufgabe, für die sie gelten soll.

Die bereitgestellten bibliografischen Angaben führen die Arbeit als Artikel in den Findings of ACL 2026 und nicht lediglich als den in der ursprünglichen Proposal erwähnten Preprint. Damit wird der dort beschriebene Publikationsstatus aktualisiert. Die hier verfügbaren Informationen nennen allerdings weder die Modelle und Aufgabensammlungen noch die Budgets oder numerischen Ergebnisse der Studie. Ohne den vollständigen Text lassen sich ihr daher keine konkreten experimentellen Konfigurationen zuschreiben und keine Resultate nach Modell oder Aufgabe zusammenfassen.

Was ein Wechsel von richtig zu falsch bedeutet

Um die Wirkung eines größeren Reasoning-Budgets zu untersuchen, lassen sich die Antworten desselben Systems bei unterschiedlichen Budgets vergleichen. Erfüllt eine Antwort bei einem kleineren Budget das Korrektheitskriterium und bei einem größeren nicht mehr, handelt es sich um einen Wechsel von richtig zu falsch – im Artikel als „negative flip“ bezeichnet. Das ist ein Vergleich von Ergebnissen, aber kein automatischer Beweis dafür, warum sich die Antwort geändert hat.

Diese Erfassung ist nützlich, weil ein aggregierter Score gegenläufige Entwicklungen verdecken kann. Bei mehr Compute könnten manche Antworten von falsch zu richtig wechseln, andere unverändert bleiben und wieder andere sich ungünstig verändern. Die Nettoveränderung der Genauigkeit zeigt für sich allein weder, wie viele Fälle gerettet oder verschlechtert wurden, noch wie viele Antworten gleich blieben.

Außerdem kommt es darauf an, was „richtig“ bedeutet. Bei Aufgaben mit überprüfbarer Antwort kann ein automatisches Kriterium oder eine explizite Referenz verwendet werden; bei anderen Aufgaben hängt die Korrektheit möglicherweise von einer menschlichen Bewertung oder einem Bewertungsverfahren ab. Solange nicht bekannt ist, welche Definition der Artikel für die einzelnen Aufgaben nutzt, sollte man nicht annehmen, dass alle Wechsel auf dieselbe Weise erkannt wurden. Ebenso wenig folgt aus einem ungünstigen Wechsel zwingend, dass inkohärentes Reasoning die Ursache ist. Dafür müsste der Inhalt der jeweiligen Trajektorien analysiert werden.

Die verfügbaren bibliografischen Angaben zeigen, dass der Artikel Wechselereignisse und den marginalen Nutzen behandelt, nennen aber weder die beobachteten Anteile noch das Prüfverfahren. Deshalb lässt sich nicht sagen, welcher Anteil der Fälle als Overthinking eingestuft wurde, ob alle Ergebnisse automatisch verifiziert wurden oder ob es eine manuelle Überprüfung gab. Diese Details sind entscheidend, um die Aussagekraft der Diagnose beurteilen zu können.

Abnehmende Erträge sind keine allgemeingültige Abbruchgrenze

Die dem Artikel zugeschriebene allgemeine Schlussfolgerung lautet, dass zusätzliches Compute abnehmende Erträge haben kann und dass sich geeignete Budgets je nach Schwierigkeit unterscheiden. Wird eine Aufgabe bereits mit wenig Reasoning gelöst, bringt eine längere Trajektorie möglicherweise nur wenig. Bei einer anderen, komplexeren Aufgabe könnte ein größeres Budget wertvoller sein. Diese Lesart ist mit einer adaptiven Zuteilung vereinbar, reicht aber nicht aus, um im Voraus festzulegen, wie viele Tokens eine konkrete Anfrage benötigt.

Auch die Schwierigkeit ist nicht zwangsläufig eine Variable, die vor der Antwortgenerierung bekannt ist. Sie kann anhand von Kategorien im Evaluationsdatensatz definiert, aus verfügbaren Signalen geschätzt oder während der Generierung erschlossen werden – und jede dieser Möglichkeiten kann zu eigenen Fehlern führen. Ein System kann eine Frage falsch klassifizieren und ihr ein ungeeignetes Budget zuweisen. Eine auf Schwierigkeit beruhende Policy muss deshalb sowohl die Qualität des Prädiktors als auch die Folgen seiner Entscheidungen evaluieren.

Die Arbeit zur optimalen Zuteilung von Test-Time-Compute bietet einen verwandten Kontext: Sie untersucht, ob sich Inferenzressourcen abhängig von der Schwierigkeit der Prompts unterschiedlich verteilen lassen, und berücksichtigt Such- und Aktualisierungsstrategien. Das ist eine ergänzende Perspektive, aber keine unabhängige Bestätigung jeder Schlussfolgerung des Hauptartikels. Die Resultate sollten nicht so verglichen werden, als hätten alle Studien dieselbe Intervention gemessen.

Die Evidenz zu Overthinking sollte außerdem nicht auf einen einzelnen Durchschnittswert reduziert werden. Ein Mittelwert kann sich verbessern, obwohl eine bestimmte Aufgabengruppe schlechter abschneidet. Er kann auch stabil bleiben, obwohl es sowohl gerettete als auch verschlechterte Antworten gibt. Um zu entscheiden, ob ein größeres Budget sinnvoll ist, müssen die Ergebnisse nach Aufgabe und Schwierigkeitsgrad aufgeschlüsselt werden. Dazu gehört auch, genau anzugeben, welche Budgets miteinander verglichen werden und welche Kosten der Unterschied verursacht.

Zusätzliches Compute bedeutet nicht immer längeres Nachdenken

Ein Budgetvergleich lässt sich nur interpretieren, wenn klar ist, welches Verfahren das Budget erhalten hat. Eine einzelne Reasoning-Trajektorie zu verlängern ist etwas anderes, als mehrere unabhängige Antworten zu erzeugen und eine davon auszuwählen. Beides kostet mehr Ressourcen, erkundet aber unterschiedliche Möglichkeiten: Im ersten Fall wird eine Sequenz fortgesetzt; im zweiten entstehen mehrere Kandidaten, die anschließend ausgewählt oder verifiziert werden.

Auch Suchverfahren können partielle Zustände oder Präfixe erkunden, statt lediglich eine einzelne Trajektorie fortzuführen oder vollständige Antworten zu vergleichen. Eine Übersicht zu Scaling-Regimen für Reasoning-Modelle unterscheidet genau zwischen sequenziellem Scaling, dem Sampling von Kandidaten mit anschließender Reduktion und der Suche über Präfixe. Diese Taxonomie hilft, einen Fehlschluss zu vermeiden: Wenn eine Strategie die Leistung verbessert oder verschlechtert, beweist das nicht, dass alle Arten, zusätzliches Compute einzusetzen, dieselbe Wirkung haben.

Sampling und Verifikation bilden eine weitere Gruppe von Entscheidungen. Eine Studie zu Inferenz mit Sampling und Verifikation untersucht, wie Antworten generiert und durch Bewertung skaliert werden können. Das ist nicht dasselbe, wie einer einzelnen Antwort weitere Tokens hinzuzufügen: In einem Fall wird eine Menge von Kandidaten verglichen oder verifiziert, im anderen eine Trajektorie verlängert. Die Qualität des Verifikators und die Auswahlregel können das Ergebnis verändern.

Budget Forcing, beschrieben in einer Arbeit zu einfachem Test-Time-Scaling, ist ein Beispiel dafür, die Dauer des Reasonings zu steuern. Damit lässt sich ein konkreter Eingriff in eine Trajektorie beschreiben. Seine Effekte dürfen jedoch nicht ohne Weiteres auf andere Methoden, Modelle oder Aufgaben übertragen werden. Für einen fairen Vergleich muss ein Team dokumentieren, ob es die Länge einer Sequenz, die Anzahl der Samples, die Suche, die Verifikation oder mehrere dieser Faktoren zugleich verändert.

Grenzen, die die Übertragbarkeit einschränken

Die wichtigste Vorsicht betrifft den Umfang der Experimente. Ein Ergebnis, das mit bestimmten Modellen, Prompts, Aufgaben und Compute-Grenzen gemessen wurde, wird nicht automatisch zu einem Gesetz für alle Reasoning-Modelle. Die bereitgestellten bibliografischen Informationen führen diese Bestandteile des Hauptartikels nicht auf. Deshalb können sie hier weder im Einzelnen beschrieben noch die Schlussfolgerungen auf nicht untersuchte Systeme verallgemeinert werden.

Auch die Extraktion der Antwort kann den Vergleich beeinflussen. Wird das Modell nach seinem Reasoning um eine finale Antwort gebeten, gehören Prompt-Format, Extraktionsregel und Umgang mit mehrdeutigen Antworten zur Messung. Für Reproduzierbarkeit müssen diese Bedingungen festgelegt werden. Andernfalls kann eine Formatänderung mit einem Effekt des Budgets verwechselt werden.

Stochastische Ausführungen werfen eine weitere Frage auf: Ein Unterschied zwischen zwei Budgets könnte von der Variabilität zwischen einzelnen Läufen abhängen. Wiederholungen unter denselben Bedingungen und die Angabe der Streuung helfen dabei, ein konsistentes Muster von einer Schwankung zu unterscheiden. Außerdem muss bei einem Budgetvergleich entschieden werden, ob gepaarte Ausführungen, identische Seeds und Prompts oder unabhängige Gruppen gegenübergestellt werden. Die verfügbaren Informationen bestätigen nicht, welches Design der Artikel verwendet.

Schließlich sind die Kosten kein nebensächlicher Punkt. Ob ein kleiner Genauigkeitsgewinn eine teurere Inferenz rechtfertigt, hängt von Anforderungen an Latenz, Budget und Fehlerrisiko ab. Die Analyse sollte daher sowohl Qualität als auch Ressourcen ausweisen und Genauigkeit nicht als einziges Kriterium behandeln. Die verfügbare Evidenz lässt auch keine Aussage darüber zu, welche Artefakte, Daten oder aufgeschlüsselten Ergebnisse veröffentlicht wurden, um die Kurven der Studie zu reproduzieren.

Ein reproduzierbares Verfahren zur Messung des eigenen Budgets

Ein Team kann die Fragestellung des Artikels auf das eigene System übertragen, ohne anzunehmen, dass sich dessen Ergebnisse unmittelbar verallgemeinern lassen. Ziel ist zu messen, ob ein größeres Budget Antworten rettet, verschlechtert oder lediglich zusätzliche Kosten verursacht, ohne eine relevante Verbesserung zu bringen. Im Verfahren sollten alle Bedingungen konstant bleiben, mit Ausnahme der Compute-Strategie, die verglichen werden soll.

Zuerst müssen die Aufgabe und das Korrektheitskriterium festgelegt werden, bevor die Tests ausgeführt werden. Eine genaue Definition dessen, was als Treffer zählt, verhindert, dass die Regel nach Sichtung der Ergebnisse geändert wird. Wenn die Bewertung ein Urteil erfordert, sollte eine Bewertungsrubrik und ein Verfahren zur Klärung von Meinungsverschiedenheiten festgelegt werden.

Danach werden Modell, Prompt, Antwortextraktion und Evaluationsdatensatz eingefroren. Es werden mehrere explizite Budgets gewählt, darunter ein Referenzbudget. Geht es um den Effekt einer verlängerten Trajektorie, dürfen nicht gleichzeitig die Zahl der Samples oder der Verifikator verändert werden. Diese Strategien können gesondert evaluiert werden.

Im nächsten Schritt werden die Ausführungen wiederholt, wenn stochastische Variabilität zu erwarten ist, und Antworten, Budgets und Kosten dokumentiert. Für jede Aufgabe wird festgehalten, ob die Antwort unter jeder Bedingung richtig oder falsch war. So lassen sich Wechsel von falsch zu richtig, von richtig zu falsch und unveränderte Fälle zählen sowie Genauigkeit und Variabilität berechnen.

Abschließend werden die Ergebnisse nach zuvor definiertem Aufgabentyp oder Schwierigkeitsgrad aufgeschlüsselt und gemeinsam mit Kosten und Latenz dargestellt. Eine Abbruch-Policy ist nur gerechtfertigt, wenn Nutzen und Kosten für den realen Einsatz akzeptabel sind und das Muster sich in neuen Stichproben bestätigt. Sind die Unterschiede klein oder unsicher, kann die richtige Schlussfolgerung lauten, dass weitere Evaluation nötig ist – nicht, dass ein Schwellenwert festgelegt werden sollte.

Fazit: erst messen, bevor eine Abbruchregel festgelegt wird

Der Wert der Arbeit liegt darin, eine Möglichkeit in den Vordergrund zu rücken, die aggregierte Metriken verdecken können: Mehr Reasoning bringt möglicherweise nicht nur keinen zusätzlichen Nutzen, sondern kann auch mit dem Verlust zuvor richtiger Antworten einhergehen. Die vorsichtige Schlussfolgerung lautet, den marginalen Nutzen von Compute zu untersuchen und die Länge nicht automatisch als Ersatz für Qualität zu behandeln.

Das reicht weder aus, um eine allgemeingültige Abbruchregel vorzuschreiben, noch um verlängertes Reasoning als kontraproduktiv einzustufen. Optimale Budgets hängen vom System, der Aufgabe, der Inferenzstrategie und den akzeptablen Kosten ab. Eine Trajektorie zu verlängern, mehrere Antworten zu samplen, sie zu verifizieren oder über partielle Zustände zu suchen, sind unterschiedliche Eingriffe, die getrennt gemessen werden sollten.

Für technische Teams ist die praktische Entscheidung empirisch: Bedingungen fixieren, Budgets vergleichen, Ausführungen wiederholen, Antwortwechsel erfassen und Ressourcenverbrauch berücksichtigen. Die Ergebnisse können dabei helfen, die nächsten Tests auszuwählen. Eine Produktions-Policy benötigt jedoch eigene Evidenz und eine Evaluation, die den vorgesehenen Einsatz abbildet.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.