Können Sprachmodelle rechnen? Was die Forschung zeigt — und was daraus folgt

Die Frage taucht regelmäßig auf, sobald jemand eine Rendite, eine Umlage oder eine Kappungsgrenze von einer KI ausrechnen lässt: Kann ein Sprachmodell das überhaupt? Die kurze Antwort lautet: Es rechnet nicht im Sinne eines Taschenrechners, und trotzdem stimmt das Ergebnis oft. Interessant ist die längere Antwort — denn sie erklärt, warum ein Fehler hier anders aussieht als ein Rechenfehler in einer Tabellenkalkulation, und welche Lösungen sich dafür durchgesetzt haben. Dieser Beitrag fasst den Forschungsstand neutral zusammen und beschreibt am Ende, wie porthor damit umgeht.

Wie ein Sprachmodell zu einer Zahl kommt

Ein großes Sprachmodell (LLM) sagt zu einer Eingabe das jeweils nächste Textstück voraus — Token für Token, auf Grundlage statistischer Muster aus dem Training. Diese Vorhersage kennt keinen Unterschied zwischen einem Adjektiv und einer Zwischensumme. Wenn nach „3.480,00 € × 12 =“ die Zeichenfolge „41.760,00“ folgt, dann nicht, weil ein Multiplikationsverfahren ausgeführt wurde, sondern weil dieses Ergebnis die wahrscheinlichste Fortsetzung ist.

Das funktioniert erstaunlich gut, solange die Aufgabe klein ist. Schon die GPT-3-Veröffentlichung von Brown u. a. (2020) hat das systematisch vermessen: Bei zweistelliger Addition erreichte das größte Modell nahezu vollständige Genauigkeit, bei fünfstelliger Addition und Subtraktion fiel sie deutlich ab, bei mehrstelliger Multiplikation lag sie im niedrigen Bereich. Der Befund ist seither vielfach bestätigt worden; die absoluten Werte sind mit neueren Modellen besser, die Richtung ist geblieben: Die Genauigkeit sinkt, je mehr Stellen und Zwischenschritte eine Aufgabe hat.

Zwei Ursachen sind gut belegt:

Zahlen werden zerlegt, bevor das Modell sie sieht. Der Text wird in Token aufgeteilt, und eine Zahl wie 41.760 zerfällt dabei je nach Tokenizer in mehrere Bruchstücke — nicht unbedingt entlang der Stellenwerte. Nogueira, Jiang und Lin (2021) zeigten, dass allein die Art dieser Zerlegung darüber entscheidet, ob ein Modell Addition zuverlässig lernt und ob es auf längere Zahlen verallgemeinert. Die Stellenwertlogik, die wir in der Schule lernen, ist im Eingabeformat also nicht selbstverständlich enthalten.

Das Modell lernt Muster, keinen Algorithmus. Dziri u. a. (2023) untersuchten mehrstellige Multiplikation und ähnliche zusammengesetzte Aufgaben und beschreiben das Verhalten als „linearisiertes Teilgraph-Matching“: Modelle setzen bekannte Teilmuster zusammen, statt ein Verfahren Schritt für Schritt auszuführen. Deshalb wächst die Fehlerrate mit der Zahl der nötigen Zwischenschritte — und deshalb hilft mehr Training an Beispielen nur begrenzt.

Wie so eine Berechnung im Inneren tatsächlich abläuft, hat Anthropic 2025 in „On the Biology of a Large Language Model“ an einer einfachen Addition sichtbar gemacht: Das Modell verwendet mehrere parallele Näherungspfade und einen eigenen Pfad für die letzte Stelle. Bemerkenswert für die Praxis ist ein Nebenbefund derselben Arbeit — auf die Frage, wie es gerechnet habe, beschreibt das Modell den schriftlichen Schulalgorithmus, also nicht das, was intern passiert ist. Ein ausgewiesener „Rechenweg“ ist damit eine plausible Erzählung über das Ergebnis, aber kein Protokoll der Berechnung.

Dazu kommt ein zweiter Punkt, der unabhängig von der Genauigkeit ist: Reproduzierbarkeit. Sprachmodelle erzeugen Text durch Sampling; mit den üblichen Einstellungen kann dieselbe Anfrage zweimal unterschiedliche Formulierungen — und damit unterschiedliche Zahlen — ergeben. Für einen Text ist das eine Stärke, für eine Kennzahl in einer Bankanfrage nicht.

Warum das anders wiegt als ein Tippfehler

Ein Rechenfehler in einer Tabellenkalkulation ist meist sichtbar: Die Formel steht in der Zelle, ein falscher Bezug fällt beim Nachsehen auf, eine Division durch null wirft eine Fehlermeldung. Ein Sprachmodell hat keine dieser Rückmeldungen. Es liefert eine sauber formatierte Zahl im deutschen Format, mit Einheit und in ganzen Sätzen eingebettet — auch dann, wenn eine Eingabe fehlte und der Wert geschätzt wurde. Der Fehler sieht aus wie ein Ergebnis.

In der Immobilienpraxis trifft das genau die Stellen, an denen Zahlen weitergereicht werden: die Anfangsrendite in der Bankanfrage, die Sonderumlage je Einheit im WEG-Anschreiben, die Kappungsgrenze in der Mieterhöhung, der Rückstand im Mahnschreiben. Kommt dort eine Zahl an, die niemand nachgerechnet hat, ist der Schaden nicht technischer Natur.

Welche Lösungen sich durchgesetzt haben

Die Forschung hat auf das Problem in drei Richtungen geantwortet. Die ersten beiden verbessern das Rechnen im Modell, die dritte holt es heraus.

Schrittweises Vorgehen. Wei u. a. (2022) zeigten, dass Modelle deutlich bessere Ergebnisse liefern, wenn sie aufgefordert werden, Zwischenschritte auszuschreiben statt direkt zu antworten („Chain of Thought“). Der Effekt ist gut belegt und Grundlage vieler heutiger „Reasoning“-Modelle. Er verschiebt die Fehlerquote nach unten, beseitigt sie aber nicht: Jeder Zwischenschritt wird weiterhin vorhergesagt, nicht ausgeführt.

Prüfen lassen. Cobbe u. a. (2021) trainierten zum Datensatz GSM8K eigene Prüfmodelle, die mehrere Lösungswege bewerten und den plausibelsten auswählen. Auch das hebt die Trefferquote, ersetzt aber keine Rechnung — es ist eine zweite Meinung, keine Kontrolle.

Die Rechnung auslagern. Der wirksamste Ansatz besteht darin, das Modell die Aufgabe nur noch aufschreiben zu lassen und die eigentliche Rechnung von Code ausführen zu lassen. Gao u. a. (PAL, 2023) und Chen u. a. (Program of Thoughts, 2023) ließen Modelle statt einer Zahl ein kurzes Programm erzeugen, das ein Interpreter ausführt; Schick u. a. (Toolformer, 2023) brachten Modellen bei, selbstständig einen Taschenrechner und andere Werkzeuge aufzurufen. Genau dieses Muster steckt heute in den Code-Interpreter- und Werkzeug-Funktionen der großen Anbieter.

Der entscheidende Punkt daran ist nicht die Technik, sondern die Zuständigkeit: Die Zahl stammt dann nicht mehr aus der Vorhersage, sondern aus einer ausgeführten Rechnung. Das Sprachmodell übernimmt, was es gut kann — verstehen, einordnen, formulieren.

Zwei Einschränkungen gehören dazu. Erstens verlagert Werkzeugnutzung das Risiko: Das Modell entscheidet weiterhin, welche Formel es aufruft und welche Werte es einsetzt. Zweitens ist ein Code-Interpreter in der Cloud für personenbezogene Unterlagen eine eigene Frage — dort wird der Inhalt beim Anbieter verarbeitet, mit allem, was daran hängt (siehe Auftragsverarbeitungsvertrag und Drittlandtransfer).

Wie porthor damit umgeht

porthor folgt dem dritten Weg, zieht die Rechnung aber vollständig aus dem Modell heraus und lässt sie lokal im Programmcode laufen — kein erzeugtes Programm, kein externer Interpreter, kein Werkzeugaufruf, den das Modell auch anders hätte stellen können.

Für die rechnenden Skills (erkennbar am Hinweis „Σ deterministische Kennzahlen“ auf der Skill-Seite) läuft der Ablauf so:

1. Werte lesen. Eine Extraktionsschicht sucht die Eingabegrößen — Kaufpreis, Jahresnettokaltmiete, Fläche, Indexstand — im bereits lokal pseudonymisierten Text der Unterlagen.
2. Rechnen. Die Kennzahlen werden im Code nach festgelegten Formeln berechnet, mit deutschem Zahlenformat und definierter Rundung. Diese Formeln sind als Daten hinterlegt und damit die einzige Quelle: Dieselbe Regel steht im Programm und im Skill-Download, und ein Prüflauf schlägt fehl, wenn beide auseinanderlaufen.
3. Vorgeben statt vorschlagen. Das Ergebnis geht als fester Block in den Prompt, ausdrücklich als verbindlich gekennzeichnet. Das Modell übernimmt die Werte wörtlich und rechnet sie nicht nach.
4. Lücken benennen. Fehlt eine Eingabe, steht dort „nicht berechenbar“ mitsamt der fehlenden Angabe — keine Schätzung, keine Marktannahme. Stehen in den Unterlagen zwei verschiedene Kaufpreise oder zwei Flächenangaben, wird der Widerspruch ausgewiesen, statt still den ersten Fund zu verwenden.
5. Rechenweg zeigen. Eingabewert, Fundstelle, Formel und Ergebnis stehen im Bericht — hier ist es tatsächlich das Protokoll der ausgeführten Rechnung und keine nachträgliche Erzählung.

Daraus folgt die Eigenschaft, auf die es im Alltag ankommt: Zwei Läufe mit derselben Unterlage ergeben dieselbe Zahl. Das ist prüfbar und wird in der Entwicklung auch geprüft — für jeden rechnenden Skill läuft ein automatischer Test, der drei Durchläufe auf Zeichengleichheit vergleicht. Für die Rechenschaftspflicht ist das ein Unterschied ums Ganze: Ein Ergebnis, das sich beim zweiten Mal ändert, lässt sich nicht belegen.

Was porthor damit nicht löst

Drei Grenzen, die zur Ehrlichkeit gehören:

Die Extraktion ist die verbleibende Schwachstelle, nicht die Arithmetik. Wenn eine Angabe in der Unterlage ungewöhnlich formuliert ist, findet die Schicht sie unter Umständen nicht — dann meldet sie korrekt „nicht berechenbar“, aber der Anwender sieht zunächst nur eine Lücke. Die Prüfung der Eingabewerte bleibt Ihre Aufgabe; der ausgewiesene Rechenweg macht sie möglich.

Nicht jeder Skill rechnet deterministisch. Wo Werte aus Fließtext, Objektlisten oder mehrjährigen Beschlusssammlungen kommen, ist eine automatische Extraktion derzeit nicht zuverlässig genug. Diese Skills rechnen auch in porthor im Modell — und sagen das im Skill-Text ausdrücklich, statt eine Rechenschicht zu versprechen, die es dort nicht gibt.

Die Einordnung bleibt eine Einschätzung. Ob eine Rendite von 3,8 % gut ist, ob eine Rücklage auskömmlich ist, ob ein Objekt gekauft werden sollte: Das rechnet niemand aus. Der Code liefert die Zahl, das Modell die Einordnung, die Entscheidung treffen Sie.

Und außerhalb von porthor?

Wer einen porthor-Skill als portablen Prompt in ChatGPT, Claude oder Gemini nutzt, hat dort keine Rechenschicht — dort rechnet das Modell. Genau deshalb enthält jeder rechnende Skill seine Formeln im Klartext, samt der Anweisung, jeden Rechenschritt mit Eingabewert und Fundstelle auszuweisen. Das macht die Zahlen nachprüfbar, und nachprüfen sollten Sie sie dann auch. Der Skill-Download sagt bei jedem Skill dazu, wer rechnet.

Kurz zusammengefasst

Sprachmodelle rechnen nicht, sie sagen Zahlen vorher. Das geht bei kleinen Aufgaben meist gut und wird mit jeder zusätzlichen Stelle unzuverlässiger — ein seit Brown u. a. (2020) wiederholt gemessener Befund, für den Nogueira u. a. (2021) und Dziri u. a. (2023) die Ursachen benennen. Schrittweises Vorgehen und Prüfmodelle verbessern das Ergebnis, die belastbare Lösung ist die Auslagerung der Rechnung an Code (PAL, Program of Thoughts, Toolformer). porthor geht diesen Weg lokal und ohne Umweg über das Modell: Der Code rechnet, das Modell formuliert, der Rechenweg steht im Bericht — und dieselbe Unterlage ergibt dieselbe Zahl.