Apples 'Illusion of Thinking' — was ist davon ein Jahr danach übrig?

Redaktion · · 4 Min. Lesezeit

Im Juni 2025 veröffentlichte Apple Machine Learning Research das Paper „The Illusion of Thinking”. Die These: Die damals neuen Reasoning-Modelle wie o3-mini und DeepSeek-R1 denken nicht wirklich — sie kollabieren bei steigender Problem-Komplexität auf null Genauigkeit, und ihr „Reasoning-Aufwand” sinkt sogar wieder, sobald Aufgaben zu schwer werden. Das Paper löste eine der heftigsten Methodik-Debatten des KI-Jahrs aus. Knapp ein Jahr später lohnt sich der nüchterne Rückblick: Was hat gehalten, was wurde widerlegt, und welche Folgen hat das für die Praxis?

Was vorher galt

Die Reasoning-Modell-Welle Anfang 2025 war von einem starken Optimismus geprägt: o1, dann o3-mini, dann DeepSeek-R1 zeigten auf Mathematik- und Coding-Benchmarks bisher unerreichte Werte. Die übliche Lesart: Längeres „Denken” (Chain-of-Thought, Self-Reflection, Tree Search) führt qualitativ zu echtem Schritt-für-Schritt-Schließen. Apples Paper stellte sich quer: Die Steigerung sei kein Reasoning, sondern besseres Pattern-Matching innerhalb des Trainingsbereichs.

Was sich seitdem geklärt hat

1. Die Methodik-Kritik war zum Teil berechtigt. Wenige Wochen nach der Veröffentlichung erschien das Folgepaper „The Illusion of the Illusion of Thinking” — und das saß. Apple hatte bei Tower of Hanoi mit hohen Disk-Zahlen evaluiert, ohne zu prüfen, ob die korrekte Lösung überhaupt in das verfügbare Token-Budget passt. Bei 15 Disks braucht die optimale Lösung über 30.000 Move-Schritte; das Modell kann sie schlicht nicht ausschreiben. Was Apple als „Reasoning-Kollaps” interpretierte, war zumindest teilweise ein Token-Limit-Artefakt.

2. Der Kernbefund hat trotzdem überlebt. Auch nach Bereinigung des Token-Limit-Problems bleibt: Reasoning-Modelle generalisieren schlechter auf strukturell neue Probleme, als ihre Benchmark-Werte nahelegen. Mehrere Folge-Studien aus dem Herbst 2025 und Frühjahr 2026 bestätigen, dass kontrollierte Komplexitätssteigerung — also eine, bei der das Token-Budget mitwächst — die Genauigkeit dennoch deutlich schneller fallen lässt als bei Trainings-In-Distribution-Aufgaben.

3. Die Branchen-Antwort war Test-Time-Search. Die Antwort der Industrie auf die Kritik war nicht „weniger Reasoning”, sondern „mehr Test-Time-Compute”. o3 (Vollversion), Claude Opus 4.7 mit extended thinking und DeepSeek-R2 setzen massiv auf Such-Strategien zur Inferenz-Zeit. Das verschiebt das Komplexitäts-Limit nach oben — beseitigt es aber nicht. Apples grundsätzlicher Kritikpunkt ist damit eher domestiziert als entkräftet.

Einordnung

Was lässt sich heute belastbar sagen? Drei Dinge:

Erstens — Benchmarks sind unzuverlässige Proxys. AIME, MATH, GPQA und Co. testen Probleme, die strukturell nah an Trainings-Daten liegen. Ein Modell kann dort 95 Prozent erreichen und auf einem strukturell verschobenen Puzzle der gleichen formalen Komplexität auf 20 Prozent fallen. Wer Modelle für produktive Reasoning-Aufgaben einsetzt, sollte eigene Out-of-Distribution-Tests fahren. Apples Hauptbeitrag ist methodisch: Sie haben sauber gezeigt, wie man so etwas misst.

Zweitens — die Verwechslung „längere Antwort = mehr Reasoning” hält sich hartnäckig. Tatsächlich korreliert die Antwortlänge bei aktuellen Reasoning-Modellen oft invers mit Genauigkeit auf schweren Aufgaben. Wer einen Reasoning-Output mit 8.000 Tokens sieht, sollte das nicht automatisch als Qualitätsmerkmal deuten — nicht selten ist es ein Signal, dass das Modell festsitzt.

Drittens — Compute-Hebel verschiebt das Problem. Mit Test-Time-Search, parallelen Rollouts und externer Verifikation lassen sich heute Aufgaben lösen, an denen 2024er-Modelle auch mit Reasoning-Aufsatz scheiterten. Das ist real. Aber es ist nicht dasselbe wie ein qualitativer Sprung in der Schließfähigkeit pro Token. Wer für seinen Einsatz Token-effizientes Reasoning braucht, sollte das im Hinterkopf haben.

Was du jetzt tun kannst

Wenn du Reasoning-Modelle produktiv einsetzt: Definiere für deine Domäne mindestens ein Out-of-Distribution-Testset und miss damit. Vendor-Benchmarks sind als Marketing-Material nützlich, als Auswahlhilfe für deinen Use-Case oft nicht.

Wenn du Modelle vergleichst: Achte nicht nur auf Benchmark-Score, sondern auch auf Token-Verbrauch pro gelöster Aufgabe und Antwort-Länge bei gescheiterten Aufgaben. Letzteres ist ein guter Indikator dafür, ob das Modell in einer Schleife festhängt oder produktiv sucht.

Wenn du das Paper noch nicht gelesen hast: Es ist auch ein Jahr später lesenswert — gerade weil die Diskussion darum so produktiv war. Beide Seiten der Debatte (Apples Originalpaper und das „Illusion of the Illusion”-Gegenpaper) lassen sich in einem Nachmittag durcharbeiten und schärfen den eigenen Blick auf Benchmark-Ergebnisse erheblich.

Entdecke mehr

Themenuebersicht