SAP B1 Blog

Dies ist eine Fortsetzung der Reihe auf diesem Blog, die sich mit Künstlicher Intelligenz im Zusammenspiel mit SAP Business One beschäftigt. Es ist der Versuch, grundlegende KI-Begriffe in Ruhe durchzudenken und zu klären. Jede Folge nimmt sich einen Begriff aus der aktuellen KI-Forschung vor und stellt am Ende dieselbe Frage: Was davon kommt im ERP-Alltag tatsächlich an, und was bleibt Vokabular, das sich gut verkauft? Die letzte Folge drehte sich um Verifikation und Reward-Modelle. Diesmal geht es um eine einfachere, aber überraschend wirkungsvolle Idee: dieselbe Frage einfach mehrfach stellen oder Test-Time Compute Scaling.

Weiterlesen: Test-Time Compute Scaling: Warum ein kleineres KI-Modell am Ende gewinnen kann — und was der Lieferantenvergleich in SAP Business One damit zu tun hat

Mehr Rechenleistung, bessere KI: eine Faustregel mit Lücke

Ein größeres, teureres KI-Modell liefert die besseren Antworten. Das klingt nach einer soliden Faustregel, die man gerne immer wieder zitiert. Ganz so einfach stimmt sie aber nicht. Ein kleines, günstiges Modell kann ein großes im direkten Vergleich schlagen. Die Bedingung dafür ist einfach: Man muss ihm erlauben, dieselbe Frage öfter zu stellen, und man muss die brauchbaren Antworten danach herausfiltern. Modellgröße ist dann nicht mehr der entscheidende Hebel. Sie ist nur noch einer von mehreren.

Untersuchungen dazu sind mittlerweile recht eindeutig. Ein kleines Modell, das mehrfach getestet und anschließend gefiltert wird, kann ein großes, einmal befragtes Modell bei komplexen Aufgaben überholen. Der Vorsprung liegt dabei nicht am besseren Model. Es ist vielmehr die Anzahl der Versuche und ein brauchbaren Kriterium für die Auswahl.

Warum das für Budgetentscheidungen zählt

Für Geschäftsführer und CFOs im Mittelstand ist das keine akademische Fußnote. Die Entscheidung über KI-Funktionen fokussiert sich meist auf die Modellfrage:welches System, welcher Anbieter, welche Lizenz. Die eigentliche Stellschraube liegt dabei oft woanders. Sie liegt darin, wie oft ein System einen Vorgang prüfen darf, bevor es eine Antwort ausgibt.

Ein Budget, das ausschließlich in ein größeres Modell fließt, kann schlechter angelegt sein als eines, das mehr Prüfschleifen für ein kleineres Modell finanziert. Test-Time Compute Scaling ist also oft das bessere Investment.

Verstecktes Test-Time Compute Scaling

Das betrifft nicht nur die Wahl der KI-Software selbst. Es betrifft auch die Erwartung an bestehende ERP-Funktionen, die scheinbar Ähnliches leisten. Wer versteht, warum wiederholtes Erzeugen und Prüfen mehr bringt als ein einzelner teurer Versuch, erkennt dasselbe Prinzip leichter wieder, wo es im eigenen System schon längst eingebaut ist. Nicht selten steckt genau diese Logik in Funktionen, die niemand als „künstliche Intelligenz” bezeichnen würde, weil sie fest verdrahtet sind und aus keiner Entscheidung lernen. Das macht sie nicht weniger wirksam.

Ein Beispiel gibt es im Einkauf von SAP Business One, an einer Stelle, die auf den ersten Blick nichts mit Künstlicher Intelligenz zu tun hat. Dazu später mehr.

Viele Schätzungen, ein überraschend gutes Ergebnis

Ein altbekanntes Experiment: Ein Glas ist mit Bohnen gefüllt, und eine größere Gruppe von Menschen soll unabhängig voneinander schätzen, wie viele es sind. Fast jede einzelne Schätzung liegt daneben, teils deutlich. Bildet man aber den Mittelwert oder nimmt die häufigste Schätzung, liegt das Ergebnis meist erstaunlich nah an der echten Zahl

.

Genau diese Logik steckt hinter Repeated Sampling, dem zentralen Mechanismus von Test-Time Compute Scaling. Statt ein KI-Modell einmal zu befragen und die Antwort zu übernehmen, lässt man es dieselbe Aufgabe viele Male lösen. Einzelne Versuche können danebenliegen. Über viele Versuche hinweg lässt sich aber zuverlässig herausfiltern, welche Antworten stimmen. Genau das macht Test-Time Compute Scaling aus: Rechenzeit zur Antwortzeit investieren, statt zusätzliches Training. Eine Untersuchung mit dem Titel „Large Language Monkeys: Scaling Inference Compute with Repeated Sampling” hat diesen Effekt für Sprachmodelle systematisch nachgewiesen.

Wie Repeated Sampling technisch funktioniert

Der Ablauf lässt sich in vier Schritten beschreiben, unabhängig davon, um welche Aufgabe es geht:

1. Eine Aufgabe wird formuliert, etwa eine Coding- oder Mathe-Frage. Modell und Eingabe bleiben dabei unverändert, es findet kein zusätzliches Training statt.
2. Das Modell wird nicht einmal, sondern zehn-, hundert- oder tausendmal mit derselben Aufgabe aufgerufen, mit bewusst hoher Zufälligkeit in der Antwortformulierung. Es entstehen viele unabhängige Kandidatenantworten.
3. Jeder Kandidat wird gegen ein Korrektheitskriterium geprüft, etwa einen Unit-Test bei Programmcode, einen formalen Beweis-Checker bei Mathematik oder ein gelerntes Bewertungsmodell bei allgemeineren Aufgaben.
4. Aus den geprüften Kandidaten wird die Ausgabe bestimmt, entweder per Mehrheitsentscheid oder per bestem Bewertungs-Score.

Der Anteil der Aufgaben, die unter allen erzeugten Kandidaten mindestens einmal richtig gelöst werden, nennt sich dann Coverage. Sie wächst mit jeder zusätzlichen Sampling-Runde. Der Zuwachs pro Runde nimmt dabei ab, bleibt aber positiv.

Warum Prüfen der eigentliche Engpass ist

Der ganze Aufwand lohnt sich nur, wenn der Prüfschritt selbst zuverlässig ist. Erzeugen ist billig: Ein Modell produziert in kurzer Zeit tausende Antworten. Prüfen ist der eigentliche Engpass. Das gilt vor allem dort, wo kein automatischer Test existiert und stattdessen ein weiteres Modell oder ein Mensch urteilen muss. Ist der Prüfschritt schwach, nützt auch die größte Zahl an Versuchen wenig.

Wie stark sich das lohnt, folgt einem einfachen Muster: Mit jeder zusätzlichen Runde steigt der Anteil gelöster Aufgaben, allerdings mit abnehmendem Zugewinn. Der Effekt ist trotzdem groß genug, dass ein kleineres Modell eins der Spitzenmodelle bei komplexen Aufgaben übertreffen kann: Wenn es genug Versuche bekommt.

Der Lieferantenanfragevergleich: dasselbe Prinzip im Einkauf

Im Einkauf von SAP Business One gibt es eine Funktion, die genau dieses Muster abbildet, ohne dass jemand sie als Künstliche Intelligenz bezeichnen würde. Beim Lieferantenanfragevergleich stellt das System alle eingegangenen Angebote mehrerer Lieferanten zu einem Artikel tabellarisch zusammen. Anschließend markiert es den geringsten Stückpreis und das früheste Angebotsdatum farblich als beste Option.

Ein Beispiel macht das greifbar. Für einen bestimmten Artikel gehen mehrere Angebote unterschiedlicher Lieferanten ein. Das System stellt sie nebeneinander und markiert automatisch, welches den niedrigsten Stückpreis hat und welches am frühesten liefern kann. Der Einkäufer muss die Zahlen nicht mehr selbst vergleichen, er sieht die beste Option auf einen Blick.

Die Anzahl macht den Unterschied

Strukturell ist das dieselbe Grundfigur wie beim Repeated Sampling. Mehrere unabhängig entstandene Kandidaten, in diesem Fall Angebote statt KI-Antworten, werden gegen ein festes Kriterium geprüft. Preis und Termin übernehmen die Rolle des Verifiers. Ein Unterschied bleibt trotzdem bestehen: Die Farbmarkierung ist eine Entscheidungshilfe, keine automatische Letztauswahl wie beim Mehrheitsentscheid einer KI. Am Ende entscheidet weiterhin ein Mensch, welches Angebot tatsächlich beauftragt wird.

Der Unterschied zeigt sich auch in der Menge der Kandidaten. Ein Einkäufer holt für einen Artikel selten mehr als eine Handvoll Angebote ein, jede zusätzliche Anfrage kostet Zeit und Aufwand beim Lieferanten. Ein Sprachmodell kennt diese Grenze nicht. Es kann für denselben Preis zehn oder tausend Versuche erzeugen.

Eine verwandte Funktion, die Artikelverfügbarkeitsprüfung, geht in dieselbe Richtung. Bei drohendem Lieferengpass schlägt das System mehrere Lösungsoptionen vor, etwa Alternativartikel oder Bestände in anderen Lagern, aus denen der Bearbeiter wählt.

Ein Gedankenexperiment: gelernte Kriterien statt fester Schwellen

Bis jetzt nicht in SAP Business One enthalten, aber mit KI durchaus denkbar: Neben Preis und Termin tritt ein weiteres, lernfähiges Kriterium, das aus früheren Lieferantenbeurteilungen – wie Liefertreue oder Reklamationsquote – abgeleitet wird. Ein preislich attraktives Angebot eines unzuverlässigen Lieferanten würde so nicht mehr automatisch an erster Stelle landen.

Das Risiko dabei: Historische Daten tragen auch frühere Nachlässigkeiten oder bloße Gewohnheiten in die Zukunft. Ein etablierter Lieferant könnte bevorzugt bleiben, obwohl ein neues Angebot objektiv besser ist.

Dieser Verzerrungseffekt lässt sich jedoch gezielt auffangen, indem das System mehrere Kriterien parallel prüft und ausweist. Statt einer starren Automatisierung erhält der Einkauf eine mehrdimensionale Entscheidungsgrundlage: Die bewährte, transparente Logik bleibt sichtbar, während das Wissen aus der Vergangenheit ergänzend unterstützt.

Für wen sich das lohnt

Dieser Artikel richtet sich an Geschäftsführer und CFOs im Umfeld von SAP Business One, die verstehen wollen, wie viel von “mehr KI-Rechenleistung” tatsächlich Substanz hat, bevor sie über Budget oder Lizenzstufen entscheiden. Wer kein SAP Business One einsetzt, kann die Erklärung zu Repeated Sampling trotzdem mitnehmen; der SAP B1 entfällt dann. Wer eine konkrete Kaufempfehlung oder einen Produktvergleich sucht, wird hier leider nicht fündig. Wer aber ein bisschen den Vorhang zur Seite schieben will im KI-Theater, hoffe ich, findet hier einen ersten Blick auf die Hintergründe.