Wie Modelle mehr Rechenzeit nutzen: Reasoning

Die erste Antwort ist nicht immer die beste Nutzung des Modells

Dein Unternehmen prüft Reisekostenabrechnungen. Eine Mitarbeiterin reicht Hotel, Zug und drei Bewirtungsbelege ein. Dazu kommen eine interne Richtlinie und unterschiedliche Höchstbeträge. Du könntest ein Sprachmodell um eine sofortige Entscheidung bitten. Es liest die Angaben und antwortet direkt mit „freigeben“.

Die erste Antwort nutzt nur einen möglichen Lauf durch das Modell. Das System kann die Aufgabe auch zerlegen. Es kann jeden Beleg einzeln prüfen, Grenzwerte vergleichen und danach die Gesamtentscheidung ableiten. Vielleicht erzeugt es mehrere Lösungen und lässt einen Prüfer auswählen. Diese zusätzliche Arbeit kostet Zeit und Rechenleistung.

Die Rechenleistung beim Training kennst du bereits. Beim Pretraining und Post-Training verändern Optimierungsverfahren die Gewichte des Modells. Die Rechenarbeit bei einer konkreten Antwort heißt Inference-Time Compute oder Test-Time Compute. Inferenz bedeutet hier, dass ein fertiges Modell eine Eingabe verarbeitet und eine Ausgabe erzeugt. Beide englischen Begriffe bezeichnen also zusätzliche Rechenarbeit zur Antwortzeit.

Mehr Rechenzeit ist kein allgemeiner Qualitätsregler. Eine Begrüßung wird durch fünf Lösungswege kaum besser. Eine mehrstufige Prüfung kann dagegen von Zwischenergebnissen und Kontrollen profitieren. Aufgabe, Modell und Prüfverfahren bestimmen den Nutzen.

Der erste Modelllauf ist deshalb ein Ausgangspunkt. Er ist nicht automatisch die beste Verwendung deines Rechenbudgets.

Mehr erzeugte Zwischenschritte können bei manchen Aufgaben helfen

Nehmen wir eine Rechnung mit vier aufeinander aufbauenden Schritten. Das Modell könnte sofort eine Zahl nennen. Es kann aber zuerst Teilbeträge erzeugen und diese später wieder aufgreifen. Jeder ausgegebene Token wird Teil des Kontexts für die folgenden Token. Der bisherige Text wird damit zu einer Art Arbeitsfläche.

Eine 2022 veröffentlichte Originalarbeit zeigte genau diesen Effekt. Große Sprachmodelle lösten in den untersuchten Rechen-, Alltagslogik- und Symbolaufgaben mehr Fälle richtig, wenn der Prompt Beispiele samt Lösungsweg enthielt. Das Verfahren heißt Chain-of-Thought-Prompting. Chain of Thought, kurz CoT, bedeutet eine erzeugte Folge von sprachlichen Zwischenschritten.

Das ist Few-shot-CoT, weil der Prompt einige Beispiele vorgibt. Kojima und Kollegen untersuchten 2022 eine andere Variante ohne solche Beispiele. Für dieses Zero-shot-CoT ergänzten sie nur eine Aufforderung wie „Denke Schritt für Schritt“. Ein Benchmark ist eine festgelegte Sammlung von Aufgaben und Auswertungsregeln. Das Verfahren verbesserte die Ergebnisse der getesteten großen Modelle auf mehreren Benchmarks für schrittweises Schlussfolgern. Es ist ein eigener, begrenzter Befund und keine allgemeine Prompt-Regel.

Die Einschränkung ist wichtig: Die Arbeit untersuchte bestimmte Modelle und Benchmarks. Kleinere Modelle profitierten dort nicht im gleichen Maß. Ein guter Wert bei Textaufgaben beweist auch keine allgemeine Fähigkeit für Planung, Faktenprüfung oder Unternehmensentscheidungen.

Warum können zusätzliche Token helfen? Das Modell verarbeitet weiterhin Token für Token. Jeder weitere Schritt löst neue Berechnungen im Netz aus. Ein sichtbares Zwischenergebnis steht danach im Kontext und kann die nächsten Wahrscheinlichkeiten beeinflussen. Das Modell muss eine lange Aufgabe also nicht in einem einzigen Ausgabeschritt lösen.

Mehr Text kann aber auch mehr Unsinn bedeuten. Ein falscher Zwischenwert bleibt ebenfalls im Kontext. Das Modell kann ihn sauber weiterverarbeiten und am Ende sehr überzeugend falsch liegen. Zusätzliche Schritte schaffen nur eine weitere Möglichkeit zur Bearbeitung. Sie garantieren kein richtiges Ergebnis.

Für genaue Arithmetik bleibt ein Taschenrechner die bessere Prüfung. Für Programmcode sind ausführbare Tests stärker als die Selbsteinschätzung des Modells. Für aktuelle Fakten brauchst du belastbare Quellen. Sprachliche Zwischenschritte und Werkzeuge ergänzen sich, aber sie ersetzen sich nicht.

Chain of Thought als Ausgabe und als verborgene Berechnung

Stell dir vor, ein Assistent zeigt vor seiner Antwort drei Sätze: „Ich prüfe zuerst den Betrag. Danach vergleiche ich die Richtlinie. Schließlich entscheide ich.“ Sieht das nach dem vollständigen inneren Ablauf aus? Nein.

Wir müssen drei Ebenen trennen. Erstens rechnet das neuronale Netz bei jedem Token mit Gewichten und vorübergehenden inneren Zahlenwerten. Zweitens kann ein System zusätzliche Zwischentoken erzeugen und vor dir verbergen. Drittens kann es einen sichtbaren Lösungsweg oder nur eine kurze Zusammenfassung ausgeben.

Ein sichtbarer Text ist deshalb nicht automatisch die gesamte Berechnung. Ein verborgener Text ist ebenfalls nicht mit allen inneren Zahlenwerten gleichzusetzen. Und eine nachträglich erzeugte Erklärung kann gut klingen, obwohl sie den wirksamen Ablauf nur unvollständig beschreibt.

Forschende prüfen diese Übereinstimmung unter dem Begriff Faithfulness. Das bedeutet hier: Beschreibt die ausgegebene Begründung tatsächlich Einflüsse, die für die Antwort wirksam waren? In Experimenten wurden Gedankengänge verändert, gekürzt oder mit Fehlern versehen. Die Antworten reagierten je nach Modell und Aufgabe sehr unterschiedlich. Teilweise stützten sie sich stark auf den Text. Teilweise ignorierten sie ihn weitgehend.

Auch bei einem benannten Produkt musst du genau auf die Version schauen. Die offizielle OpenAI o1 System Card vom 5. Dezember 2024 beschreibt die Prüfergebnisse für den Stand o1-dec5-release. Bei diesem Stand blieb die ausführliche Chain of Thought verborgen. ChatGPT konnte Zusammenfassungen anzeigen. Die Karte sagt selbst, dass spätere Produktstände abweichen können. Diese Beobachtung gehört also zu diesem dokumentierten Stand und nicht zu jedem Modell mit dem Namen o1.

Eine sichtbare Herleitung kann trotzdem nützlich sein. Du findest Annahmen, prüfst Zahlen und stellst gezielte Rückfragen. Behandle sie als prüfbaren Arbeitstext. Behandle sie nicht als lückenloses Protokoll des neuronalen Netzes.

Mehrere Wege erzeugen und vergleichen

Nehmen wir an, fünf Modellläufe bearbeiten dieselbe Textaufgabe. Drei enden bei 42, einer bei 38 und einer bei 45. Du könntest die häufigste Antwort wählen. Dieses Verfahren heißt Self-Consistency. Das Modell erzeugt mehrere unterschiedliche Gedankengänge und die Endantworten stimmen anschließend ab.

Die Originalarbeit von 2022 verbesserte damit die Ergebnisse auf mehreren Rechen- und Alltagslogik-Benchmarks. Die Methode nutzt Unterschiede zwischen den Läufen. Wenn alle Pfade dieselbe falsche Annahme übernehmen, gewinnt allerdings nur der häufigste Fehler. Bei offenen Fragen ohne eindeutige Endantwort passt eine einfache Mehrheitswahl oft gar nicht.

Eine zweite Variante heißt Best-of-N. N steht für die Zahl der erzeugten Antworten. Ein Prüfer bewertet die Kandidaten und wählt einen davon aus. Der Prüfer kann ein Test, ein formales Verfahren, ein Mensch oder ein weiteres Modell sein. Die Qualität hängt dann von zwei Dingen ab: den Kandidaten und dem Prüfer.

Für verschiedene Pfade braucht das System meist eine gewisse Streuung. Sampling ist die Auswahl des nächsten Tokens aus den berechneten Wahrscheinlichkeiten. Die Temperatur verändert, wie stark wahrscheinliche Token bevorzugt werden. Ein niedriger Wert macht Ausgaben meist ähnlicher. Ein höherer Wert verbreitert die Auswahl und erzeugt mehr Varianten.

Top-K begrenzt die Auswahl auf die K wahrscheinlichsten Token. Top-P sortiert die Token nach ihrer Wahrscheinlichkeit und nimmt die kleinste Gruppe der wahrscheinlichsten Token, deren addierte Wahrscheinlichkeit mindestens den festgelegten Anteil erreicht. Welche Regler verfügbar sind, hängt vom Anbieter ab. Bei Temperatur null wählen viele Systeme jeweils den wahrscheinlichsten Token. Das heißt Greedy Decoding. Bytegenau gleiche Antworten sind damit trotzdem nicht überall garantiert. Server, Modellstand, numerische Berechnung und vorgeschaltete Regeln können sich unterscheiden.

Abbildung 9: Zusätzliche Rechenzeit kann mehrere Lösungswege erzeugen und prüfen lassen. Mehr Versuche erhöhen Kosten und Wartezeit. Ein richtiges Ergebnis garantieren sie nicht.

Mehrere Antworten sind also noch keine Kontrolle. Erst die Auswahlregel macht aus Varianten ein Verfahren.

Verifier, Suche und Wertschätzungen

Nehmen wir eine Programmieraufgabe. Das Modell erzeugt zehn Lösungen. Ein automatischer Test führt jede Lösung aus und verwirft neun davon. Das ist der Verifier aus Kapitel 9.

Ein deterministischer Endantwortprüfer kann bei Mathematik die letzte Zahl extrahieren und nur mit der Musterlösung vergleichen. Er ist kein gelerntes Bewertungsmodell. Lightman und Kollegen untersuchten auf dem MATH-Datensatz zwei andere Arten der Aufsicht. Bei Outcome Supervision erhält jede vollständige Lösung ein einziges Label, das aus der Richtigkeit der Endantwort abgeleitet wird. Das gelernte Belohnungsmodell darf für seine Bewertung trotzdem die komplette Lösung lesen. Bei Process Supervision erhält es dagegen Labels für einzelne Schritte. In diesem MATH-Versuch schnitt die Prozessaufsicht besser ab als die Ergebnisaufsicht. Das ist kein allgemeiner Beleg für jede Aufgabe oder jeden Prüfer.

Ein Verifier kann die Suche steuern. Das System erzeugt einen Teilschritt, bewertet ihn und verfolgt aussichtsreiche Wege weiter. Tree of Thoughts nennt einen solchen Aufbau mit verzweigten Lösungspfaden. Eine Wertschätzung ist dabei eine geschätzte Punktzahl dafür, wie vielversprechend ein Zwischenstand wirkt. Sie ist keine Gewissheit über das spätere Ergebnis.

Suche bedeutet hier also: Varianten erzeugen, Zwischenstände bewerten, Pfade verwerfen und bei Bedarf zurückspringen. Das ähnelt bekannten Suchverfahren aus der Informatik. Die Suchknoten bestehen jedoch aus erzeugtem Text oder anderen Modellzuständen. Breite und Tiefe der Suche bestimmen den Rechenaufwand.

Prüfbare Aufgaben haben einen Vorteil. Ein Compiler kann feststellen, ob Programmcode überhaupt übersetzt wird. Tests können beobachtbares Verhalten prüfen. Ein formaler Beweisprüfer folgt festen Regeln. Bei einem Strategiepapier gibt es dagegen selten eine eindeutige Musterlösung. Ein Sprachmodell als Prüfer kann dort helfen, bringt aber eigene Fehler und Vorlieben mit.

Der Prüfer definiert damit einen Teil des Ziels. Prüft ein Test nur den Normalfall, kann eine Lösung im Alltag trotzdem scheitern. Bevorzugt ein Modell lange Antworten, wählt es vielleicht den wortreichsten Kandidaten. Suche verstärkt dann die Maßstäbe des Prüfers, gute wie schlechte.

Reasoning trainieren oder bei der Antwort mehr rechnen

Nehmen wir zwei Systeme. Das erste wurde im Post-Training darauf vorbereitet, lange Aufgaben zu zerlegen und automatisch prüfbare Belohnungen zu nutzen. Das zweite erhält erst bei deiner Anfrage den Auftrag, fünf Varianten zu erzeugen. Beide können mehr Rechenarbeit einsetzen. Sie tun es aber an unterschiedlichen Stellen.

Training verändert die Gewichte. Beispiele, Präferenzdaten, verifizierbare Belohnungen und andere Verfahren formen das spätere Verhalten. Die o1 System Card vom 5. Dezember 2024 beschreibt für ihre geprüften o1-Stände beispielsweise groß angelegtes Reinforcement Learning für komplexe Aufgaben. Sie veröffentlicht nicht das vollständige Trainingsrezept. Aus der Produktbezeichnung allein kannst du deshalb keine bestimmte Methode oder Architektur ableiten.

Ein weiteres Verfahren ist Destillation. Dabei liefern Ausgaben eines stärkeren oder rechenintensiveren Lehrermodells Trainingssignale für ein kleineres Studentenmodell. So lassen sich beobachtete Verhaltensmuster oder Fertigkeiten übertragen. Hsieh und Kollegen nutzten dafür auch erzeugte Begründungen als zusätzliche Aufsicht. Was übertragen wird und wie gut das gelingt, hängt von Daten, Aufgabe und Trainingsverfahren ab.

Inference-Time Compute wirkt bei der einzelnen Anfrage. Das System erzeugt längere Zwischenschritte, mehrere Kandidaten oder eine Suche. Die Gewichte bleiben bei einer gewöhnlichen Antwort gleich. Du bezahlst die zusätzliche Arbeit bei jeder Nutzung erneut.

Beide Hebel können zusammenwirken. Ein passend trainiertes Modell nutzt ein zusätzliches Rechenbudget oft gezielter. Ein größerer Suchbaum kann wiederum auch einem unveränderten Modell mehr Chancen geben. Die Forschung von Snell und Kollegen verglich solche Strategien 2024 unter festen Rechenbudgets. Der Nutzen hing stark von der Schwierigkeit der jeweiligen Aufgabe ab. In einem begrenzten Versuch konnte ein kleineres Modell mit passend verteilter Rechenzeit sogar ein deutlich größeres Modell übertreffen. Das gilt für die untersuchten Modelle, Mathematikaufgaben und Rechenbedingungen.

Inference-Time Scaling bezeichnet die Leistungsänderung, wenn der Rechenaufwand bei der Antwort wächst. Repeated Sampling ist die einfachste Form: Das System probiert dieselbe Aufgabe oft. Bei Programmcode und formalen Beweisen kann ein automatischer Verifier gute Treffer direkt erkennen. Ohne belastbaren Prüfer flacht der Nutzen viel früher ab.

Du kaufst mit zusätzlicher Rechenzeit also Möglichkeiten zur Suche. Ob daraus bessere Antworten werden, entscheidet das gesamte Verfahren.

Wo mehr Schritte einen Fehler verstärken

Nehmen wir an, der erste Zwischenschritt ordnet einen Beleg der falschen Kostenart zu. Alle späteren Grenzwerte passen dann sauber zu dieser falschen Kategorie. Der lange Lösungsweg sieht ordentlich aus und verstärkt trotzdem den ersten Fehler.

Mehrere typische Grenzen tauchen immer wieder auf. Ein Modell kann eine falsche Annahme fortschreiben. Verschiedene Stichproben können denselben systematischen Fehler teilen. Ein Verifier kann eine Lücke haben. Eine Suche kann aussichtslose Pfade bevorzugen, weil ihre Wertschätzung falsch liegt. Fehlende Informationen erscheinen durch längeres Rechnen ebenfalls nicht plötzlich im Kontext.

Mehr Rechenzeit hat außerdem abnehmenden Nutzen. Snell und Kollegen untersuchten MATH-Aufgaben mit einem auf einzelne Schritte trainierten Belohnungsmodell. Bei den zwei leichtesten, modellspezifischen Aufgabengruppen sank die Leistung der gesteuerten Beam Search, als das Rechenbudget stieg. Die Autoren deuten das als Überoptimierung auf zufällige Merkmale im Prüfsignal. Dieser Befund betrifft dieses Suchverfahren, den verwendeten Prüfer und den MATH-Versuch.

Davon zu trennen ist intrinsische Selbstkorrektur. Huang und Kollegen meinen damit, dass ein Modell seine erste Antwort ohne externes Feedback überarbeitet. Auf den untersuchten Reasoning-Aufgaben gelang das nicht verlässlich. Teilweise sank die Leistung. Die Aufforderung „Prüfe dich noch einmal“ liefert eben keine neue Tatsache. Ein externer Test, eine Quelle oder eine klare Regel fügt ein zusätzliches Signal hinzu.

Bei mehreren Pfaden bleibt die Auswahl das Nadelöhr. Wiederholtes Sampling erhöht zwar die Chance, dass irgendwo eine richtige Lösung liegt. Ohne guten Prüfer findest du sie womöglich nicht. Die Untersuchung „Large Language Monkeys“ zeigte 2024 genau diesen Unterschied. Automatisch prüfbare Code- und Beweisaufgaben profitierten stark von vielen Stichproben. Mehrheitswahl und Belohnungsmodelle erreichten bei anderen Aufgaben deutlich früher ein Plateau.

Setze deshalb kein pauschales Tokenbudget für alles. Miss den zusätzlichen Nutzen getrennt nach Aufgabentyp und Schwierigkeit.

Was „Reasoning“ über Bewusstsein aussagt und was nicht

Ein Modell schreibt: „Ich überlege kurz und entscheide mich dann.“ Dieser Satz beschreibt eine Textfolge. Er belegt kein subjektives Erleben.

In diesem Kapitel verwenden wir Reasoning als Arbeitsbegriff für beobachtbare Methoden und Leistungen. Das Modell erzeugt Zwischenschritte, sucht zwischen Pfaden, nutzt Prüfer oder löst Aufgaben mit mehreren Abhängigkeiten. Diese Vorgänge lassen sich messen. Der Begriff sagt für sich allein nichts darüber aus, ob ein System Bewusstsein, Gefühle, Absichten oder ein menschliches Verständnis besitzt.

Anthropomorphe Deutungen übertragen menschliche Eigenschaften auf ein technisches System. Sie liegen sprachlich nahe, weil Modelle in der Ich-Form schreiben und ihre Zwischenschritte wie Selbstgespräche aussehen können. Für eine technische Erklärung reichen aber beobachtbare Vorgänge. Ein Pfad wurde verworfen. Ein Prüfwert fiel niedrig aus. Das Ergebnis änderte sich nach zusätzlicher Suche. Dafür müssen wir dem Modell keinen inneren Willen zuschreiben.

Auch die Gegenbehauptung verlangt Sorgfalt. Eine interdisziplinäre Forschungsgruppe leitete 2023 Merkmale aus mehreren Bewusstseinstheorien ab und prüfte damalige KI-Systeme dagegen. Sie fand bei den untersuchten Systemen keinen ausreichenden Fall für Bewusstsein. Zugleich erklärte sie die Frage nicht grundsätzlich für technisch erledigt. Das ist eine datierte wissenschaftliche Einschätzung, keine Messung jedes heutigen oder künftigen Systems.

Für Unternehmensentscheidungen brauchst du diese philosophische Frage meistens nicht zu lösen. Du kannst Verhalten, Fehlerquoten, Kosten und Kontrollen prüfen. Genau dort liegt deine Verantwortung.

Die Folge für Unternehmen: Wartezeit, Kosten, Wiederholbarkeit und Prüfung

Kehren wir zur Reisekostenprüfung zurück. Ein direkter Lauf kostet eine Einheit und dauert zwei Sekunden. Zehn Kandidaten plus Prüfer brauchen vielleicht zwanzig Sekunden und ein Vielfaches der Rechenarbeit. Solche Zahlen musst du mit deinem Anbieter und deinem Prozess messen. Das Prinzip bleibt gleich: Mehr Pfade und längere Ausgaben erhöhen meist Kosten und Latenz. Latenz ist die Wartezeit bis zur Antwort.

Du brauchst deshalb verschiedene Wege für verschiedene Fälle. Einfache Belege können eine feste Regel oder ein schneller Modelllauf bearbeiten. Unklare Fälle erhalten mehr Rechenbudget. Kritische Freigaben gehen zusätzlich an einen Menschen. Ein Router verteilt Anfragen auf diese Wege. Der Router kann eine feste Regel oder ein eigenes Modell sein. Auch seine Fehlzuordnungen gehören in deine Tests.

Wiederholbarkeit ist bei Reasoning schwieriger. Sampling erzeugt Varianten. Eine niedrige Temperatur reduziert Unterschiede, beseitigt sie aber nicht sicher. Halte deshalb Modellversion, Prompt, Systemanweisung, Werkzeuge, Datenquellen, Sampling-Einstellungen und Rechenbudget fest. Speichere auch die endgültige Antwort und das Ergebnis externer Prüfungen. Verborgene Zwischentoken sind kein verlässliches Audit-Protokoll.

Bewerte das System mit echten Fällen. Öffentliche Benchmarks messen nur festgelegte Ausschnitte. Mathematiktests, Programmieraufgaben und Logikaufgaben prüfen unterschiedliche Fähigkeiten. Ergebnisse ändern sich mit Prompt, Werkzeugen, Anzahl der Versuche und Rechenbudget. Ein hoher Wert ohne diese Bedingungen hilft dir wenig.

Hinzu kommt Benchmark-Kontamination. Dabei gelangen Testaufgaben oder sehr ähnliche Beispiele in Trainingsdaten. Dodge und Kollegen fanden Aufgaben aus anderen NLP-Benchmarks im untersuchten Webkorpus C4. Das kann einen Wert erhöhen, ohne dass die Fähigkeit auf neue Fälle übertragbar ist.

Wu und Kollegen untersuchten elf Aufgaben mit gegenfaktischen Varianten. Dabei änderten sie vertraute Annahmen der üblichen Aufgaben. Das grundlegende Lösungsverfahren blieb gleich. Die Leistung sank gegenüber den Standardvarianten deutlich und durchgängig. Ein hoher Wert im bekannten Format belegt deshalb noch keinen robusten Transfer auf veränderte Fälle.

Offene Antworten werden häufig durch Menschen oder andere Sprachmodelle verglichen. Ein Sprachmodell als Bewerter heißt LLM-as-a-Judge. Das ist schnell, aber nicht neutral. Zheng und Kollegen beobachteten in ihren Versuchen Positions- und Ausführlichkeitsverzerrungen. Ihre begrenzten Messungen zur möglichen Selbstbevorzugung blieben ohne eindeutiges Ergebnis. Length-Controlled AlpacaEval versuchte 2024, den bekannten Längeneffekt statistisch zu kontrollieren. Die Studie berichtete danach eine Spearman-Rangkorrelation von 0,98 mit der Chatbot-Arena-Rangfolge. Eine Korrelation von 0,98 bedeutet nicht, dass 98 Prozent einzelner Urteile übereinstimmen. Sie beschreibt hier die Ähnlichkeit zweier Rangfolgen für die untersuchten Modelle.

Deine wichtigste Evaluation bleibt deshalb näher am Betrieb. Sammle normale Fälle, Grenzfälle und bekannte Fehler. Definiere, was ein Verifier wirklich prüft. Miss Qualität, Wartezeit und Kosten gemeinsam. Für hohe Risiken brauchst du unabhängige Kontrollen statt längerer Modelltexte.

Mehr Rechenzeit braucht einen Prüfer

Prüfe das Kapitel an fünf kurzen Fällen:

1. Ein Modell erzeugt acht Lösungswege und sieben enden bei derselben Zahl. Ist die Zahl damit richtig? Nein. Self-Consistency findet die häufigste Antwort. Ein gemeinsamer Fehler kann trotzdem gewinnen.
2. Ein Assistent zeigt eine kurze Begründung. Siehst du damit seine vollständige interne Berechnung? Nein. Sichtbarer Text, verborgene Zwischentoken und die inneren Zahlenwerte des Netzes sind verschiedene Ebenen.
3. Ein Programm besteht alle vorhandenen Tests. Reicht das als Freigabe? Nur wenn die Tests alle wichtigen Anforderungen abdecken. Ein lückenhafter Verifier kann eine falsche Lösung auswählen.
4. Ein größerer Reasoning-Aufwand verbessert einen Mathematik-Benchmark. Gilt das für deine Vertragsprüfung? Noch nicht. Du brauchst eigene Fälle, passende Kriterien und ein gemessenes Kostenprofil.
5. Ein Modell schreibt, es habe „lange nachgedacht“. Belegt das Bewusstsein? Nein. Der Satz ist eine Ausgabe. Bewusstseinsaussagen brauchen andere Begriffe und eigene Evidenz.

Reasoning kann Zwischenschritte verlängern, mehrere Pfade durchsuchen und Prüfer einbeziehen. Training formt, wie ein Modell solche Arbeit nutzt. Inference-Time Compute bezahlt zusätzliche Arbeit bei jeder Anfrage. Beides kann bestimmte Aufgaben verbessern und beides kann Fehler verstärken.

Auch ein sorgfältig suchendes System bleibt ein Sprachmodell mit begrenzten Daten, unvollständigen Prüfern und fehlerhaften Ausgaben. Das nächste Kapitel betrachtet diese Grenzen genauer. Es geht um Halluzinationen, Unsicherheit und die Frage, wann eine plausible Antwort nicht genügt.