Möglichkeiten und Grenzen im praktischen Einsatz

1. Was ist Reasoning

Reasoning ist eine zentrale Eigenschaft moderner Large Language Models (LLMs). Sie ermöglicht es, dass ein System nicht nur Texte wiederholt, sondern selbstständig Antworten aus einem Wissensbestand ableitet – ohne dass jede Antwort manuell vorformuliert werden muss. Gerade bei technischen Wissensdatenbanken bietet das ein enormes Einsparpotential (siehe auch Reasoning in Wissensdatenbanken – Vor- und Nachteile – Rely-QA).

Wichtig dabei: Wer Reasoning produktiv einsetzen möchte, muss verstehen, wie es funktioniert und wo seine Grenzen liegen. Dieser Beitrag gibt dazu praxisnahe Orientierung.

Hinweis: Werden LLMs in Agenten eingesetzt, kann der benötigte Kontext die verfügbare "Memory-Größe" überschreiten. Dieses Limit ist ein eigenständiges Thema und wird hier nicht weiter adressiert.

Reasoning im Alltag und in LLMs

Manchmal begegnet man Gesprächspartnern, die Aussagen nur nachplappern, statt eigene Schlussfolgerungen zu ziehen. Dass es hilfreicher ist, vor einer Antwort nachzudenken, zeigt schon ein einfaches Beispiel:

„Wir haben einen schwarzen und einen weißen Hasen. Der dunkle heißt Schnuffi, der helle heißt Peter.“ – Welche Farbe hat Peter?

Eine bloß reproduzierende Antwort lautet: „Peter hat eine helle Farbe.“ Die denkende Antwort: „Peter ist weiß.“ Dieser Unterschied – das Schlussfolgern aus Bedeutungen statt reines Wiederholen – ist der Kern von Reasoning.

Dieses Prinzip reicht von einfachen Dialogen bis zu komplexen Analysen: Wenn ein Mitarbeiter im technischen Service aus einer Symptombeschreibung auf eine mögliche Ursache schließt, ist das anspruchsvolles Reasoning.

Frühe Modelle wie GPT-2 waren dazu nicht in der Lage. GPT-3 konnte bereits logische Muster in Kontexten erkennen – ohne dass man dabei schon von echtem Reasoning sprach. Den nächsten entscheidenden Schritt brachte das sogenannte „Chain of Thought“-Prompting-Verfahren. Und als die Modelle hier überraschende Leistungen zeigten, wurden sie nicht nur auf das korrekte Ergebnis, sondern auch auf den Denkweg trainiert. Mit o1 wurde dieser Ansatz erstmals in großem Stil umgesetzt.

Dieser Denkweg benötigt eigene Tokens – sogenannte Reasoning Tokens. Das Modell „denkt laut“ und arbeitet sich schrittweise zur Lösung vor. In manchen Modellen lässt sich dafür sogar ein explizites Budget definieren.

Moderne Modelle wie Gemini 3 sind gezielt für Reasoning optimiert. Sie versuchen, die Aufgabe zu „verstehen“ und ein mentales Modell zu finden, mit dem sie die Antwort erarbeiten – eine mächtige Grundlage für technische Anwendungsfälle wie Lösungsfindung, Handhabungshinweise oder Reparaturanweisungen.

2. Was kann beim Reasoning schiefgehen – und wie sorgt man für gute Antworten?

Risiken realistisch einschätzen

Die Anforderungen an Zuverlässigkeit variieren stark je nach Anwendungsfall. Wer ein Logfile auf mögliche Fehlerursachen prüft, arbeitet mit geringem Risiko. Wer dagegen Mitarbeitende bei der Bewertung von Gesundheitsfragen unterstützt, muss deutlich höhere Maßstäbe anlegen.

Entscheidend ist daher zu klären: Wie gut kann ein Anwender das Ergebnis kritisch beurteilen – und welche Konsequenzen hat eine Fehlantwort?

Komplexität und Modellleistungsfähigkeit

Wie bei jedem System gibt es Obergrenzen der realisierbaren Komplexität – und diese hängen stark vom gewählten Modell ab. Dabei ist weniger die Anzahl der Denkschritte entscheidend als deren Zusammensetzung.

Lange, aber konsistente Logikketten meistern aktuelle Modelle recht zuverlässig – beispielsweise die Ermittlung eines Verwandtschaftsgrades über viele Generationen (homogenes Reasoning). Schwieriger wird es, wenn mehrere, unterschiedliche Einflussfaktoren gleichzeitig berücksichtigt werden müssen (heterogenes Reasoning). Ein Beispiel: In einem Text werden Beteiligungsverhältnisse beschrieben; kurz darauf wird erwähnt, dass das Unternehmen zu 49 % übernommen wurde. Dass sich dies auf die Eigentumsverhältnisse auswirkt, wird von Modellen häufig übersehen.

Ablenkende, eigentlich irrelevante Zusatzinformationen (sogenannte „Distractors“) können Modelle wie Deepseek überfordern und zu deutlich erhöhtem Tokenverbrauch führen.

In der Praxis werden häufig zu einfache Testfragen verwendet oder Ergebnisse nur auf ihre Lesbarkeit, nicht auf ihre inhaltliche Korrektheit geprüft. Besser ist es, praxisnahe Fragen zu nutzen und systematisch zu testen:

• Beispielhafte Fragen aus dem realen Betrieb formulieren
• Verschiedene thematische Bereiche abdecken (z. B. IT, mechanische Aspekte, Alltagswissen)
• Mehrfachtests durchführen, um die Konsistenz des Modells einschätzen zu können
• Den Frageaufbau schematisch vereinheitlichen

Das LLM wählt das falsche „mentale Modell“

Reasoning-fähige Modelle planen vor der Antwort: Sie entwickeln ein internes Modell des Problems – beispielsweise eine räumliche Darstellung oder eine Ahnenhierarchie. Hier unterscheiden sich Modelle deutlich. Gemini 3 ist stark darin, solche Modelle zu finden; andere erzeugen Reasoning Tokens ohne erkennbare Strategie.

Wählt ein Modell das falsche mentale Modell, führt das zu Fehlern, die auf den ersten Blick überraschend wirken. Ein bekanntes Beispiel: GPT-5 weigerte sich, Tic-Tac-Toe um 90 Grad gedreht zu spielen, da es Schwierigkeiten beim mentalen Wechsel von Zeilen und Spalten hatte.

Erschwerend kommt hinzu, dass Modelle nicht alle Alternativen prüfen, sondern tendenziell die wahrscheinlichste Lösung wählen – man spricht von probabilistischem Reasoning. Bei einer Anfrage zur Zeitzone eines Ansprechpartners neigt ein Modell etwa dazu, die kleinere Zeitdifferenz (z. B. nach Osten) anzunehmen – obwohl die Person auch viel weiter westlich sein könnte.

Für den IT-Bereich ist das ein weniger kritisches Problem, da Schlussfolgerungswege hier gut bekannt sind. Sobald jedoch mechanische oder Alltagsaspekte eine Rolle spielen, steigt das Risiko.

Um das zu beherrschen, empfiehlt sich:

• Fragen so realistisch wie möglich formulieren
• Verschiedene thematische Bereiche testen
• Explizit nach alternativen Lösungen fragen, um probabilistische Engführungen aufzudecken

Reasoning und Einsatz zusätzlichen Wissens

Gerade beim Lösen technischer Probleme hilft externes Wissen. Eine HTTP-Kommunikationsfehler über einen Proxy lässt sich leichter diagnostizieren, wenn das Modell auf konkretes Wissen zu dieser Technologie zugreifen darf.

Viele Modelle verfügen zwar über internes Wissen zu einer Vielzahl von Themen, aber dieses Wissen ist oft unspezifisch oder veraltet. Nicht definiertes Wissen kann dazu führen, dass unpassende Quellen herangezogen werden – falsche Versionen, veraltete Dokumentationen oder nicht zutreffende Software.

Deshalb ist es wichtig, dem Modell explizit zu definieren, welches Wissen es verwenden soll: das kontextbasierte Wissen aus dem Prompt, eine Beschreibung relevanter Wissensgebiete und gegebenenfalls konkrete Datenquellen oder Webseiten.

Mangelndes „Symbol Grounding“

LLMs sind in vielen Domänen leistungsfähig – scheitern aber häufig an Alltagssituationen, die für Menschen trivial sind. Dieses Phänomen wird als „Moravec’sches Paradox“ bezeichnet: Hochkomplexe Aufgaben gelingen, während kinderleichte Situationen Probleme bereiten. (Eine schöne Übersicht findet man unter https://unipat.ai/blog/BabyVision).

Ein anschauliches Beispiel: Ein Verkehrsspiegel zeigt ein Auto, das von links kommt. Je nach Situationsbeschreibung kommt ein Modell zu dem Schluss, das Auto komme von rechts – weil es die optische Spiegelwirkung kennt, aber die räumliche Alltagseinschätzung fehlt, die jedes Kind aus der Badezimmerspiegel-Erfahrung mitbringt.

Zwei Gründe erklären das:

• Reporting Bias: Alltägliche, selbstverständliche Situationen werden kaum schriftlich festgehalten. Da LLMs aus geschriebenen Texten lernen, fehlt ihnen genau dieses Alltagswissen.
• Fehlendes Symbol Grounding / Embodiment: Ein LLM hat nie erlebt, wie sich ein Spiegel verhält – es kennt nur physikalische Beschreibungen davon. Den verwendeten Symbolen fehlt die Verankerung in realen Erfahrungen.

Für technische Wissensdatenbanken mit klarem IT-Fokus ist das meist kein kritischer Faktor. Sobald jedoch Anwendergruppen wie ältere Menschen oder mechanische Aspekte eine Rolle spielen, sollte der Einsatz von Alltagswissen sorgfältig geplant werden.

Fazit

Reasoning-fähige LLMs bieten im technischen Service und in Wissensdatenbanken erhebliches Produktivitätspotential. Sie können aus einfach zu erstellenden Basisdaten eigenständig Lösungen, Handhabungshinweise und Reparaturanleitungen ableiten – ohne dass jede Antwort manuell geschrieben werden muss.

Dieses Potential lässt sich jedoch nur zuverlässig heben, wenn man die charakteristischen Schwächen kennt und berücksichtigt:

• Heterogene Komplexität (mehrere Einflussfaktoren gleichzeitig) überfordert Modelle schneller als lange, gleichförmige Ketten.
• Das falsche mentale Modell führt zu inhaltlich falschen, aber formal plausiblen Antworten.
• Unklare oder ablenkende Frageformulierungen beeinträchtigen die Qualität erheblich.
• Fehlendes Symbol Grounding macht Alltagssituationen zum unerwarteten Stolperstein.
• Nicht definiertes Hintergrundwissen führt zur Nutzung unpassenden oder veralteten Quellen.

Wer diese Punkte im Blick behält, das Modell gezielt testet und Fragen sorgfältig formuliert, kann mit einem verlässlichen, produktiven System rechnen – im Rahmen der jeweils geforderten Komplexität.