Warum LLMs nicht rechnen sollten Zahlenarbeit gehört in den Code.
LLMs sind brillant darin, Texte zu verstehen — und unzuverlässig, sobald sie rechnen sollen. Bittet man ein Modell, aus einem Geschäftsbericht die Bruttomarge zu berechnen, eine Wachstumsrate zu ermitteln oder ein Bewertungsmultiple aufzustellen, bekommt man oft eine plausibel klingende, aber falsche Zahl. Im Trading ist das fatal: Eine um zwei Prozentpunkte falsch berechnete Marge oder ein vertauschter Nenner kann ein Signal in sein Gegenteil verkehren. Die Lösung ist keine bessere Mathematik im Prompt, sondern Arbeitsteilung. Das Modell tut, was es gut kann — Text verstehen, Zahlen aus dem Kontext extrahieren, die richtige Formel auswählen. Das Rechnen selbst übernimmt deterministischer Code via Tool-Use oder Code-Execution. Dieser Beitrag zeigt, warum LLMs strukturell schlecht rechnen, wie das saubere Muster aus Extraktion plus Code-Ausführung aussieht, welche Fallstricke dabei lauern — von falsch extrahierten Eingaben bis zu Einheiten-Verwechslungen — und wo die ehrliche Grenze dieser Arbeitsteilung liegt.
Warum Sprachmodelle strukturell schlecht rechnen.
Ein LLM rechnet nicht — es sagt das nächste Token vorher. Wenn es „die Marge beträgt 42,8 Prozent“ schreibt, hat es keine Division ausgeführt, sondern eine Zeichenfolge erzeugt, die in seinem Training auf ähnliche Kontexte gefolgt ist. Dass dabei manchmal die richtige Zahl herauskommt, ist Mustererkennung, keine Berechnung.
Bei einfachen, häufig gesehenen Rechnungen funktioniert das oft erstaunlich gut. Bei mehrstelligen Zahlen, mehrstufigen Rechnungen oder ungewöhnlichen Werten bricht es zusammen — das Modell „schätzt“ ein plausibles Ergebnis, das daneben liegt. Tückisch ist, dass die falsche Zahl genauso selbstbewusst und gut formatiert daherkommt wie eine richtige.
Hinzu kommt der Nicht-Determinismus: Dieselbe Rechnung kann bei zwei Aufrufen zwei verschiedene Ergebnisse liefern. Für Finanzkennzahlen, die reproduzierbar und prüfbar sein müssen, ist das untragbar. Die Erkenntnis ist nicht, dass Modelle zu schwach sind — sondern dass Rechnen schlicht die falsche Aufgabe für ein Sprachmodell ist.
Die Arbeitsteilung: Text zum Modell, Zahlen in den Code.
Das tragfähige Muster trennt sauber, wer was tut. Das LLM übernimmt die sprachlichen Teile, der Code die numerischen:
- Extraktion — das Modell liest den Text und zieht die relevanten Rohzahlen heraus: Umsatz, Kosten, Vorjahreswert, Aktienzahl. Es gibt sie strukturiert zurück, rechnet aber nichts.
- Formelwahl — das Modell entscheidet, welche Kennzahl mit welcher Formel gefragt ist. Das ist eine sprachlich-konzeptionelle Aufgabe, die es gut beherrscht.
- Berechnung — deterministischer Code nimmt die extrahierten Zahlen und die gewählte Formel und rechnet exakt, reproduzierbar, prüfbar.
- Einordnung — das Modell interpretiert das Ergebnis wieder in Worten: ist die Marge hoch, der Trend positiv, das Multiple teuer.
In diesem Ablauf berührt das Modell die eigentliche Arithmetik nie. Es bereitet vor und interpretiert nach; das Rechnen passiert in einer Umgebung, die deterministisch und testbar ist. Genau das ist mit Tool-Use oder Code-Execution gemeint.
Tool-Use und Code-Execution in der Praxis.
Technisch gibt es zwei verbreitete Wege. Beim Tool-Use definiert man dem Modell fertige Funktionen — etwa „berechne_marge(umsatz, kosten)“ — und das Modell entscheidet, welche es mit welchen Argumenten aufruft. Die Funktion selbst ist gewöhnlicher, getesteter Code. Das eignet sich gut für ein überschaubares, bekanntes Set an Kennzahlen.
Beim Code-Execution-Ansatz schreibt das Modell selbst Rechencode, der dann in einer abgeschotteten Umgebung ausgeführt wird. Das ist flexibler für ungewöhnliche oder mehrstufige Rechnungen, bringt aber zusätzliche Verantwortung mit: Der erzeugte Code muss in einer sicheren Sandbox laufen, ohne Zugriff auf Netzwerk oder sensible Ressourcen.
Eine grobe Orientierung, wann was passt:
| Ansatz | Stärke | Geeignet für |
|---|---|---|
| Tool-Use (feste Funktionen) | kontrolliert, testbar | bekannter Kennzahlen-Katalog |
| Code-Execution (Sandbox) | flexibel | ad-hoc und mehrstufige Rechnungen |
In beiden Fällen gilt: Die Rechenlogik ist Code, den man versionieren, testen und auditieren kann — nicht eine flüchtige Modellausgabe. Das ist der eigentliche Gewinn.
Die Falle verschiebt sich zur Extraktion.
Wer das Rechnen in den Code verlagert, hat das Problem nicht gelöst, sondern verschoben — von der Berechnung zur Extraktion. Der Code rechnet exakt, aber nur mit den Zahlen, die das Modell ihm liefert. Extrahiert es die falsche Zahl, ist das Ergebnis exakt falsch.
Typische Extraktionsfehler sind erstaunlich tückisch: Das Modell greift den Umsatz des falschen Segments, verwechselt das laufende mit dem Vorjahresquartal, nimmt einen bereinigten statt eines berichteten Wertes oder übersieht, dass eine Zahl in Tausend statt in Millionen angegeben ist. Keiner dieser Fehler wird vom Rechencode bemerkt — er rechnet brav mit dem falschen Input.
Schutz bietet nur Plausibilisierung. Der Code sollte Eingaben gegen einfache Sanity-Checks prüfen: Liegt die Zahl in einer realistischen Größenordnung? Passt das Vorzeichen? Stimmen Summen, die aus Teilwerten gebildet werden, mit dem berichteten Gesamtwert überein? Solche Prüfungen fangen einen Großteil der groben Extraktionsfehler ab, bevor sie zu einem Signal werden.
Einheiten, Währungen und Perioden.
Eine eigene, besonders heimtückische Fehlerklasse betrifft Einheiten und Bezugsgrößen. Finanzdaten kommen in Tausend, Millionen oder Milliarden; in unterschiedlichen Währungen; als Quartals- oder Jahreswerte; berichtet oder bereinigt. Eine Kennzahl, die diese Dimensionen vermischt, ist wertlos — und der Fehler ist im Ergebnis oft nicht zu sehen.
Das Modell ist genau hier unzuverlässig, weil Einheiten im Text oft implizit sind oder weit von der Zahl entfernt stehen. Eine robuste Pipeline extrahiert deshalb nicht nur die Zahl, sondern explizit auch ihre Einheit, Währung und Periode — und der Code normalisiert alles auf eine gemeinsame Basis, bevor er rechnet.
Konkret heißt das: Niemals zwei Werte verrechnen, ohne dass beide auf dieselbe Einheit, Währung und denselben Zeitraum gebracht sind. Eine Wachstumsrate zwischen einem Quartalswert und einem Jahreswert ist Unsinn, fällt aber numerisch nicht auf. Die explizite Mitführung der Dimension ist hier der einzige verlässliche Schutz.
Prüfbarkeit als eigentlicher Gewinn.
Der oft übersehene Vorteil dieser Arbeitsteilung ist nicht nur die korrekte Zahl, sondern die Nachvollziehbarkeit. Wenn das Rechnen in versioniertem Code passiert, lässt sich jede Kennzahl bis auf ihre Eingaben und ihre Formel zurückverfolgen. Bei einer reinen Modellausgabe ist das unmöglich — man hat eine Zahl, aber keinen Beleg, wie sie zustande kam.
Für ein Trading-System ist das entscheidend. Wenn ein Signal auf einer berechneten Marge beruht, muss man im Zweifel zeigen können: Diese Marge ergab sich aus diesem Umsatz und diesen Kosten, extrahiert aus diesem Dokument, mit dieser Formel. Diese Kette ist die Grundlage für Backtest-Reproduzierbarkeit, für Audits und schlicht für das Vertrauen ins eigene System.
Es lohnt sich, beide Spuren zu protokollieren: die rohen extrahierten Werte und das Rechenergebnis. Weicht eine Kennzahl im Live-Betrieb plötzlich auffällig ab, sieht man sofort, ob die Extraktion oder die Datenquelle das Problem ist — und muss nicht raten.
Wo die Arbeitsteilung an Grenzen stößt.
So wertvoll das Muster ist — es hat Grenzen, die man ehrlich benennen sollte. Die erste: Wenn die Quelldaten selbst mehrdeutig oder lückenhaft sind, hilft auch perfekte Rechenlogik nicht. Ein Geschäftsbericht, der eine Kennzahl in einer ungewöhnlichen Definition ausweist, führt zu einer korrekt gerechneten, aber konzeptionell unvergleichbaren Zahl.
Die zweite Grenze betrifft den Aufwand. Eine robuste Extraktions- und Rechen-Pipeline mit Plausibilitätschecks, Einheiten-Normalisierung und Logging ist deutlich mehr Arbeit als ein schneller Prompt. Für einen einmaligen Blick mag der direkte Modellweg reichen; für ein produktives Signal, auf das Kapital gesetzt wird, führt an der sauberen Variante kein Weg vorbei.
Die dritte, grundsätzliche Grenze: Auch die beste Kennzahl ist nur so gut wie ihre Interpretation. Das Modell kann die Marge korrekt einordnen — aber ob eine bestimmte Marge in einer bestimmten Branche und Marktlage ein Kauf- oder Verkaufssignal ist, bleibt eine Strategiefrage, die weder Extraktion noch Code beantwortet. Die Arbeitsteilung löst das Rechenproblem zuverlässig; das Urteilsproblem bleibt menschlich.
Sie lassen ein LLM Finanzkennzahlen berechnen und misstrauen den Zahlen — zu Recht? Unverbindlich anfragen — wir bauen gemeinsam die Arbeitsteilung aus Extraktion und deterministischem Rechen-Code, inklusive Einheiten-Normalisierung und Plausibilitätschecks, damit Ihre Kennzahlen exakt und prüfbar werden.