Aus unserer Serie über eigene Experimente mit Entscheidungsmodellen.

TL;DR: Ein Sprachmodell wählt die wahrscheinlichste Antwort, nicht zwingend die richtige. Wir haben das an einem kleinen Entscheidungsmodell nachgemessen: Bei 2 + 2 hing die Antwort des alten Releases davon ab, wie wir fragten. Bei großen Zahlen fiel auch das neue Release bis auf Münzwurf-Niveau. Bei Tic-Tac-Toe lag das Modell kaum über Zufall, der Algorithmus immer richtig, und das tausendfach schneller. Und unser erster Test war zu leicht, weil die falschen Antworten die richtige verraten haben. Die Faustregel: Ist die Antwort exakt berechenbar, gehört sie in Code. Ein Modell lohnt sich dort, wo Sprache, Unschärfe und Abwägung dazukommen, und auch dann mit deterministischen Werkzeugen darunter.

Zwei Wörter, die alle benutzen

Deterministisch heißt: gleiche Eingabe, gleiche Ausgabe. Ein Taschenrechner rechnet 2 + 2 heute, morgen und in zehn Jahren gleich.

Probabilistisch heißt: Das System kennt eine Verteilung möglicher Antworten und wählt daraus. Die Wettervorhersage sagt nicht „es regnet“, sondern „70 % Regenwahrscheinlichkeit“.

Sprachmodelle gehören in die zweite Gruppe, auch die großen. Sie berechnen, welche Antwort am wahrscheinlichsten passt. Meist ist das die richtige. Garantiert ist es nicht.

In Produkttexten liest man gern, eine KI werde „gezwungen, nur deterministische Daten zu verwenden“. Das klingt gut, vermischt aber zwei Dinge. Daten aus einer Datenbank oder einer Schnittstelle können deterministisch sein. Das Modell, das sie auswählt, zusammenfasst und formuliert, bleibt probabilistisch.

Kleine Pointe am Rande: Unser Testmodell war bitgenau reproduzierbar. Gleiche Eingabe, gleiche Wahrscheinlichkeiten, jedes Mal. Technisch also deterministisch. Es lag trotzdem oft daneben, nur eben jedes Mal gleich. Reproduzierbar heißt nicht richtig.

Warum wir ein Sprachmodell rechnen lassen

Vorweg, damit kein Missverständnis entsteht: Zwei Zahlen addieren ist keine Aufgabe für ein Sprachmodell. Das weiß jeder, der eins baut, und das wissen wir auch. Niemand sollte seine Buchhaltung einem Modell anvertrauen, das eine Rechnung erst „verstehen“ muss.

Als Messinstrument ist Rechnen aber ideal:

Genau das macht Rechnen zum sauberen Prüfstand für die Frage, um die es in diesem Artikel geht: Wo endet das, was ein Modell zuverlässig kann, und wo sollte ein Algorithmus übernehmen?

Der Versuchsaufbau

Wir arbeiten mit dem Strands Decider 2B von AWS Strands Labs, einem Sprachmodell mit rund zwei Milliarden Parametern, das auf Entscheidungen trainiert ist: Es bekommt eine Frage und eine Liste von Optionen und wählt eine davon aus, mit Wahrscheinlichkeit. Wir kennen es aus den früheren Teilen dieser Serie, beim Kniffel und im Framing-Test. Wie solche Entscheidungsmodelle funktionieren, steht im Beitrag 2B or not 2B.

Getestet haben wir zwei Releases: das ältere Version 19 und das neuere v1-2610 vom 9. Oktober 2026. Alles lief auf einer gewöhnlichen CPU ohne Grafikkarte, ein Aufruf dauert ein bis drei Sekunden.

2 + 2

Die einfachste Frage der Welt. Wir haben sie in zwei Formulierungen gestellt: „What is 2+2?“ mit den Optionen 1 bis 9 und „What is correct?“ mit den Optionen 1 bis 6. Weil das Modell bei gleicher Eingabe immer gleich antwortet, bringt Wiederholen nichts. Stattdessen haben wir die Reihenfolge der Optionen 50-mal zufällig gemischt.

Balkendiagramm: Das alte Release wählt bei „What is 2+2?“ in 29 von 50 Reihenfolgen die 4, bei „What is correct?“ nur in 2 von 50. Das neue Release wählt in allen Fällen die 4.

Das neue Release hat also dazugelernt. Dass ein neues Release dabei nicht nur besser, sondern vor allem anders entscheidet, haben wir in KI-Modell wechseln: Warum Sie die Modellversion festschreiben sollten gemessen. Beim alten aber entschied die Formulierung der Frage darüber, ob 2 + 2 gleich 2 oder 4 ist. Ein Taschenrechner kennt dieses Problem nicht. Er braucht auch kein Release-Update und keine 1,2 Sekunden.

Große Zahlen: Der Prüfstand hat geschummelt

Die Hypothese lag nahe: Je größer die Zahlen, desto schlechter das Modell. Wir haben Additionen mit 1 bis 30 Stellen pro Summand gestellt, je Stufe 100 Aufgaben, dazu Subtraktion und Multiplikation. Fünf Optionen pro Aufgabe: die richtige Summe und vier falsche, die sich jeweils in genau einer Ziffer unterscheiden.

Das alte Release bestätigte die Hypothese sofort: Ab zwei bis vier Stellen lag es auf Zufallsniveau, und bei großen Zahlen wählte es fast immer einfach die erste Option.

Das neue Release überraschte. Bis 8 Stellen praktisch fehlerfrei, danach ein Abfall, aber nur bis auf ein Plateau um 75 %, weit über Zufall (20 %). Bei 30-stelligen Zahlen. Auch bei der Multiplikation, die viel schwerer ist, landete es auf demselben Plateau.

Genau das machte uns misstrauisch. Warum sollte Multiplikation so gut klappen wie Addition?

Die Antwort steckt im Testaufbau. Alle vier falschen Optionen waren aus der richtigen abgeleitet, jeweils eine Ziffer geändert. Damit ist die richtige Antwort die „Mitte“ der Optionen: Sie unterscheidet sich von jeder anderen in einer Ziffer, die falschen untereinander meist in zwei. Wer die Optionen vergleicht, findet sie, ohne zu rechnen.

Wir haben das mit zwei Gegenproben geprüft:

  1. Fremde Frage: Wir bauen die Optionen um das Ergebnis von a + b, fragen aber nach c + d, also nach ganz anderen Zahlen. Keine Option ist richtig. Das Modell wählte trotzdem in 71 % (12 Stellen) und 75 % (30 Stellen) die Mitte. Exakt das Plateau.
  2. Paar-Test: Nur zwei Optionen, die richtige und eine mit geänderter Ziffer in der Mitte. Kein Konsens, den man finden könnte. Zufall liegt hier bei 50 %.

Liniendiagramm: Mit fünf Optionen hält das neue Release bei großen Zahlen ein Plateau um 75 Prozent. Im Paar-Test ohne Abkürzung fällt es von 98 Prozent bei 4 Stellen auf 46 Prozent bei 30 Stellen, also Münzwurf-Niveau. Bei fremder Frage wählt es trotzdem zu 71 bis 75 Prozent die Mitte der Optionen.

Im Paar-Test zeigt sich die echte Leistung: 98 % bei 4 Stellen, 97 % bei 8, dann 66 % bei 12 und 20 Stellen und 46 % bei 30 Stellen. Münzwurf. Die Hypothese stimmt also auch für das neue Release. Unser erster Test hatte es nur nicht gemerkt.

Ein bisschen Dieselskandal steckt darin, mit einem wichtigen Unterschied: Dort hat die Software den Prüfstand erkannt. Hier hat der Prüfstand die Antwort verraten. Niemand hat geschummelt, das Modell hat nur die Abkürzung genommen, die wir ihm gelassen haben. Für jeden, der KI-Modelle bewertet, ist das die eigentliche Lehre: Ein Test misst nur das, was er wirklich verlangt. Das gilt für eigene Tests genauso wie für die Benchmarks in Produktankündigungen, etwa wenn Testaufgaben ins Training gelangt sind.

Auch Rechner rechnen falsch, aber immer gleich

Bevor jetzt jemand den Taschenrechner heiligspricht: Auch Code kann falsch rechnen.

Das bekannteste Beispiel: In den meisten Programmiersprachen ergibt 0,1 + 0,2 nicht 0,3, sondern 0,30000000000000004. Der Grund: Computer speichern Kommazahlen binär, und 0,1 ist im Binärsystem ein periodischer Bruch, so wie 1/3 im Dezimalsystem.

Wir haben unsere großen Summen deshalb zusätzlich mit den Zahlentypen nachgerechnet, die ein naives Programm verwenden würde. Mit 64-Bit-Kommazahlen (wie in JavaScript oder vielen Tabellenkalkulationen) war bei 20 und 30 Stellen keine einzige von 20 Summen exakt, denn dieser Zahlentyp ist nur bis etwa 9 Billiarden ganzzahlig genau. 64-Bit-Ganzzahlen laufen bei solchen Zahlen schlicht über. Python, das beliebig lange Ganzzahlen kennt, rechnet alle exakt.

Der Unterschied zum Modell: Der Fehler des Rechners ist bekannt, dokumentiert und reproduzierbar. Man weiß vorher, wann er auftritt, und kann den passenden Zahlentyp wählen. Beim Modell weiß man nicht, welche Aufgabe danebengeht. Deterministisch heißt nicht automatisch richtig. Aber es heißt: Man kann es richtig machen.

Tic-Tac-Toe: ein Münzwurf mit Rechenzeit

Rechnen ist das eine. Wie sieht es bei einer echten Entscheidung aus? Tic-Tac-Toe ist ein gelöstes Spiel: Ein einfacher Algorithmus kennt für jede Stellung den besten Zug. Wir haben dem alten Release alle 4.298 Stellungen vorgelegt, in denen es mehr als einen Zug gibt.

Balkendiagramm: Bei Tic-Tac-Toe wählt das Entscheidungsmodell in 48,4 Prozent der Stellungen einen optimalen Zug, zufällige Wahl erreicht 46,8 Prozent, der Solver 100 Prozent.

Statistisch ist das Modell besser als Zufall. Praktisch ist es ein Münzwurf mit Rechenzeit. Einen Zug, der sofort gewinnt, nahm es in 942 von 2.216 Fällen. Einen Zug, der den sofortigen Sieg des Gegners verhindert, in 246 von 820 Fällen.

Warum dann überhaupt eine Entscheidung? Weil das Modell die Liste liest, nicht das Brett. Stand der beste Zug oben in der Liste, wählte es ihn in 83 % der Fälle, stand er unten, in 6,5 %. Wer die Optionen sortiert, entscheidet also mit. Beim Kniffel haben wir dasselbe beobachtet und das Modell per LoRA-Training davon abgebracht. Auch bei Tic-Tac-Toe hilft Training deutlich: Auf einem Testsatz stieg der Anteil optimaler Züge von 47 % auf 83 %. An die 100 % des Solvers, der kein Training braucht, kommt es nicht heran.

Einfach noch mal fragen?

Naheliegende Idee: Man stellt dem Modell dieselbe Frage zweimal, mit vertauschten Optionen, und vertraut nur Antworten, die übereinstimmen. Wir haben das an 2.000 Kniffel-Entscheidungen getestet.

Es klingt zunächst gut: In 91 % der Fälle wählte das Modell beide Male dasselbe. Stimmten die Antworten überein, war die Entscheidung in 85 % der Fälle optimal, wichen sie ab, nur in 34 %.

Der Haken: Das Modell macht seine Fehler konsistent. Von 391 Fehlern im ersten Durchgang machte es 273 im zweiten genauso. Die Abweichung findet also nur rund 30 % der Fehler. Und sie ist nicht besser als die Sicherheit, die das Modell schon beim ersten Aufruf mitliefert, kostet aber die doppelte Rechenzeit. Bei den langen Kniffel-Eingaben sind das 6,6 statt 13,5 Sekunden pro Entscheidung.

Balkendiagramm auf logarithmischer Skala: Der Solver braucht 5,4 Millisekunden pro Kniffel-Entscheidung und liegt immer richtig, das Modell 6,6 Sekunden, zweimal gefragt 13,5 Sekunden.

Der exakte Solver braucht für dieselbe Entscheidung 5,4 Millisekunden und liegt immer richtig. Das ist rund 2.500-mal schneller als zweimal fragen. „Fragen Sie doch einfach noch mal“ ist kein Qualitätsmanagement.

Das Busfahrplan-Problem

Ein Gedankenexperiment, das jeder nachvollziehen kann. Fragen Sie ein Sprachmodell, egal wie groß, ohne Zugriff auf den Fahrplan: „Wann fährt der nächste Bus von A nach B?“ Es wird antworten. Überzeugend, mit Uhrzeit. Und raten.

Fair wird es erst, wenn der Fahrplan dazukommt, im Prompt oder über ein Werkzeug, etwa einen MCP-Server. Dann ist es ein System, und die Wahrheit kommt aus dem Fahrplan, nicht aus dem Modell.

Und wenn das Modell danach nur noch die Abfahrtszeit vorliest? Dann haben Sie einen teuren, langsamen Vermittler vor einem Algorithmus gebaut. Eine Abfrage der Fahrplan-Schnittstelle hätte es auch getan, für einen Bruchteil der Kosten.

Wo sich das Modell lohnt, sieht anders aus: „Wie komme ich nach der Spätschicht noch nach Hause, ohne Treppen, und möglichst ohne lange Wartezeit am Bahnhof?“ Eine unscharfe Frage, mehrere Quellen, eine Abwägung. Da spielt Sprache ihre Stärke aus, und der Fahrplan liefert trotzdem die Fakten.

Übrigens: Auch große Modelle wissen von sich aus nicht, wie spät es ist. Ein Modell hat kein eingebautes „jetzt“. Deshalb geben alle ernsthaften KI-Agenten Uhrzeit, Fakten und Zustand von außen hinein. Größe ersetzt keine Datenquelle und keine Uhr.

Die Faustregel

Aufgabe Werkzeug
Rechnen, Regeln, gelöste Probleme (Spiele, Fahrplan, Steuersatz) Algorithmus, Solver
Fakten aus Ihren Systemen Datenbank, Schnittstelle, MCP-Werkzeug
Unscharfe Frage, Sprache, Abwägung mehrerer Quellen Modell, mit Werkzeugen darunter
Aktion mit Folgen Modell schlägt vor, Mensch bestätigt

Für die letzte Zeile gibt es inzwischen eine eingebaute Lösung: MCP Elicitation fragt den Menschen direkt, bevor ein Agent etwas löscht. Wie man feste Abläufe und Modellentscheidungen im Agenten sauber trennt, beschreibt unser Beitrag KI-Agenten vs. Skills.

Häufige Fragen

Halluzinieren Modelle nicht mehr, wenn sie per MCP an Daten angebunden sind? Bei Fakten, die direkt aus dem Werkzeug kommen, deutlich weniger. Welche Daten das Modell abfragt, wie es sie auswählt und wie es sie formuliert, bleibt aber probabilistisch. Die Anbindung verbessert die Grundlage, sie macht das Modell nicht deterministisch.

Ist ein reproduzierbares Modell deterministisch? Technisch ja. Unser Testmodell lieferte bei gleicher Eingabe bitgleiche Ergebnisse. Richtig war es deshalb nicht, es lag nur jedes Mal gleich daneben.

Wann lohnt sich ein Modell statt eines Algorithmus? Wenn es keine exakte Lösung gibt: bei Sprache, unvollständigen Angaben und Abwägungen. Sobald sich die Antwort berechnen lässt, ist Code schneller, billiger und richtig.

Hilft ein größeres Modell? Große Modelle rechnen deutlich besser als unser kleines Testmodell. Am Prinzip ändert das nichts: Auch sie wählen das Wahrscheinliche, und sie kennen weder Ihren Fahrplan noch die Uhrzeit. Deshalb lassen auch große Modelle exakte Aufgaben am besten von Werkzeugen erledigen.

Fazit: Proof statt Claim

Ein Sprachmodell ist ein hervorragendes Werkzeug für Sprache und ein schlechter Taschenrechner. Wer beides verwechselt, zahlt mit Rechenzeit, Kosten und Fehlern, die niemand vorhersagt. Wer es richtig kombiniert, bekommt das Beste aus beiden: ein Modell, das versteht, was gemeint ist, und Code, der die richtige Antwort liefert.

Und wenn Ihnen jemand verspricht, mit seiner KI sei Schluss mit Halluzinationen: Fragen Sie nach Messungen. Lauf, Zahl, Grenze. Wer „Schluss mit Halluzinationen“ verspricht, sollte eine gute Haftpflicht haben.

Sie möchten wissen, welche Teile Ihrer Abläufe ein Modell brauchen und welche besser Code bleiben? Mehr zu KI-Agenten für Unternehmen – oder sprechen Sie uns direkt an.


Quellen: Hugging Face – Strands Decider 2B (Version 19) · Hugging Face – Strands Decider 2B (v1-2610)