Microsoft-Decision-1 ist live auf Foundry. Der Benchmarks-Tab ist leer.

Das Interessanteste an der dieswöchigen Microsoft-Veröffentlichung ist nicht, was Microsoft-Decision-1 leisten kann. Es ist das, was Microsoft bewusst nicht darüber veröffentlicht hat. Das Modell ist live: Es wurde allgemein verfügbar auf Microsoft Foundry am 8. Oktober 2026, zwei Tage bevor dies geschrieben wurde. Es ist ein Decision-Scoring-Modell – Sie geben ihm einen Zustand und eine Frage mit einem festen Satz von Antworten, und es liefert eine kalibrierte Wahrscheinlichkeit pro Antwort – von Microsoft nachtrainiert auf dem Open-Weight-Qwen3.5-9B, das einen Durchlauf über bis zu 32.768 Token ausführt und null Ausgabe-Token ausgibt, weil es überhaupt nie etwas generiert. Die Katalogseite hat einen Tab „Benchmarks“. Sie enthält einen Methodikabsatz und keine Zahlen.

Diese Lücke ist die eigentliche Geschichte, und sie ist nützlicher als eine weitere Meldung der Art „Microsoft liefert ein Modell aus“. Jede ernsthafte Frage zu einem Scorer ist eine Kalibrierungsfrage – bedeutet eine zurückgegebene 0,8 auch 0,8 –, und eine Markteinführung, die ohne einen einzigen Brier-Score oder Expected-Calibration-Error-Wert daherkommt, überlässt die eine Zahl, auf die es ankommt, denen zur Messung, die sie übernehmen. Im Folgenden geht es darum, was die Foundry-Seite tatsächlich dokumentiert, was sie auffällig auslässt und was ein Evaluierungsteam diese Woche dagegen tun kann.

Was genau ausgeliefert wurde

Microsoft-Decision-1 ist eine gehostete API. Der Vertrag lautet: ein Aufruf hinein, eine Verteilung heraus, ohne Decoding-Schleife irgendwo im Pfad. Die Anfrage enthält das zu beurteilende Material sowie eine Frage mit einer begrenzten Antwortmenge, und die Antwort enthält eine Wahrscheinlichkeit für jede Option. Microsoft listet die unterstützten Frageformen als Ja/Nein, Multiple-Choice, Bewertung, Klassifizierung und rubrikbasiert auf, alle innerhalb eines einzigen Aufrufs von bis zu 32K Tokens. Sie ist reiner Text – keine Bild-, Audio- oder Videoeingabe, und als Ausgabe nichts als Zahlen.

Die Ausschlüsse sind ebenso klar formuliert wie die Funktionen, und es lohnt sich, sie vor allem anderen zu lesen: nicht für Textgenerierung, die Beantwortung offener Fragen, Konversation, Übersetzung oder Zusammenfassung konzipiert und nicht für Aufgaben gedacht, die Wissen erfordern, das in der Eingabe nicht enthalten ist. Es werden keine Begründungen erzeugt. Die veröffentlichten Anwendungsfälle sind allesamt Bereiche, in denen ein Plattformteam bereits eine mit Label versehene Entscheidung treffen muss – eine generierte Antwort anhand eines Bewertungsrasters bewerten, die Relevanz von Retrieval-Ergebnissen beurteilen, eine Warteschlange triagieren, einen vorgeschlagenen Tool-Aufruf eines Agenten über ein Gate steuern, Inhalte anhand von Schwellenwerten prüfen, die die Anwendung definiert, statt anhand einer festen Anbieterrichtlinie, und Ergebnisse mit hoher Konfidenz automatisch akzeptieren, während der Rest eskaliert wird.

Zwei operative Details stechen aus der Deployment-Liste hervor. Das erste ist, dass Microsoft ausdrücklich eine Enthaltungsoption wie „kann nicht sagen“ unterstützt, wenn die gelieferte Evidenz nicht ausreicht – das ist der Unterschied zwischen einem Scorer, der kalibriert ist, und einem, der lediglich selbstsicher ist, und es ist das, was die Schwellenwertsetzung funktionieren lässt. Das zweite ist, dass die Batch-Inferenz deaktiviert ist. Man kann einen großen Scoring-Lauf nicht über den Batch-Kanal amortisieren, so wie man es bei einem generativen Modell tun würde, daher ist die Latenz pro Aufruf die Latenz Ihrer Pipeline und nicht das Problem eines Offline-Jobs.

Die Distribution erfolgt ausschließlich über Foundry, im Portfolio „Direct from Azure" als serverloses Deployment oder Unified-Endpoint-Deployment auf Standard-SKU – Pay-as-you-go oder reservierter bereitgestellter Durchsatz. Die Gewichte werden nicht verteilt. Es gibt kein Hugging-Face-Repository, keinen Download, keinen Fine-Tuning-Pfad und keine Self-Hosting-Option. Anwendungen integrieren über HTTPS mit standardmäßiger Azure-Authentifizierung. Die Offenlegung zum Training gibt an, dass der Datensatz erstmals im September 2026 verwendet wurde, wobei die Erfassung weiterhin läuft – das ist der kürzestmögliche Abstand zwischen Trainingsdaten und einem GA-Termin und normal für einen Post-Train auf einer bereits veröffentlichten Basis eines anderen.

Der Tab „Benchmarks“, vollständig zitiert

Hier ist der gesamte Inhalt dessen, was Microsoft darüber veröffentlicht hat, wie gut das Modell abschneidet. Die Evaluierung verwendete „öffentliche und Community-Entscheidungs-Benchmarks sowie zurückgehaltene interne Testsets, die nicht für das Training verwendet wurden“. Die Metriken waren Genauigkeit, Kalibrierungsfehler, Sicherheits-Recall, Falsch-Positiv-Raten und Fairness-Konsistenz. Die Reihenfolge der Optionen wurde variiert. Gepaarte statistische Tests wurden angewendet. Die Aussage ist qualitativ: Microsoft-Decision-1 „schneidet genauso gut ab wie führende Entscheidungsmodelle und besser als andere offene Entscheidungsmodelle, die mit derselben Methodik bewertet wurden.“

Das ist ein kompetentes Evaluationsdesign, das ohne ein Ergebnis beschrieben wird. Es ist keine Anschuldigung, das festzustellen – ein Methodikabsatz ohne Tabelle ist eine konkrete, überprüfbare Entscheidung, und sie unterscheidet sich von der, die der Rest dieser kleinen Kategorie getroffen hat. Die offenen Entscheidungsmodelle, mit denen Microsoft sich implizit vergleicht, veröffentlichen ihre Zahlen: Die Intern-Decision-Familie von InternLM druckt Brier- und Expected-Calibration-Error-Werte auf ihre Modellkarten, TypeSafe's Jev veröffentlicht beides, und die d1-Reihe von Liquid AI liefert Genauigkeitstabellen mit ihren Gewichten aus. Microsoft ist das größte Unternehmen in dieser Gruppe und das einzige, das darum bittet, ihm zu vertrauen.

Das Unternehmen sagt zwar, wo es das Modell für stark und schwach hält, was handlungsrelevanter ist als eine einzelne Schlagzeilenbewertung. Am stärksten: Schlussfolgern, Anwendung von Regeln und Robustheit gegenüber Prompt-Formatierung. Wettbewerbsfähig: Klassifikation, Retrieval, Fairness, Tool-Nutzung und die meisten mehrsprachigen Aufgaben. Am schwächsten: spezialisiertes Domänenwissen. Die selbstberichteten Einschränkungen sind auf dieselbe Weise offen — Bewertungen können sich je nach Formulierung und Reihenfolge der Optionen ändern, eine schlecht formulierte Frage liefert dennoch eine Bewertung, die Kalibrierung ist bei vertrauten Aufgabentypen am stärksten, und es gibt keine Erklärungen zum Nachprüfen, wenn eine Antwort falsch erscheint.

Die Sprachabdeckung birgt dieselbe Art von Einschränkung. 25 Sprachen werden als unterstützt aufgeführt und umfassen unter anderem Japanisch, Koreanisch, Arabisch, Vietnamesisch, Thailändisch, Türkisch, Hindi, Bengalisch, Suaheli, Hebräisch, Persisch und Ukrainisch, mit der ausdrücklichen Warnung, dass Abdeckung, Qualität und Kalibrierung „je nach Sprache variieren können" und dass Nicht-Englisch, insbesondere ressourcenschwache Sprachen, ein Bereich mit unterdurchschnittlicher Leistung ist. Die Qwen3.5-9B-Basis unterstützt weit über 200 Sprachen. Das Post-Training behielt etwa ein Viertel davon, und auf dieses Viertel wurde die Kalibrierung angepasst.

Auf der Seite steht auch kein Preis.

Das Preisfeld des Katalogs gibt keinen Tarif an. Es verlinkt auf Microsofts eigene Modell-Preisoberfläche, sodass man die Kosten pro Entscheidung bei Azure oder auf einer Rechnung abliest und nicht auf der Model Card. Für alle, die die Kosten pro Entscheidung bei hohem Volumen modellieren, ist das eine echte Lücke, und es lohnt sich, das klar zu benennen, statt zu schätzen. Zwei Dinge ergeben sich jedoch aus der Architektur und sollten in diese Schätzung einfließen: 0 % der Kosten eines Aufrufs entfallen auf Output-Tokens, denn es gibt keine, und das Optionsset ist Teil des Inputs, sodass eine Frage mit zweiundsechzig beschreibenden Optionen pro Aufruf mehr kostet als ein Ja/Nein — man bezahlt für das Bewertungsschema, das man geschrieben hat, nicht für die Antwort.

Warum diese Form der Veröffentlichung der interessante Teil ist

Ein Entscheidungs-Scorer ist eine Wette darauf, dass das, was primitive Unternehmen tatsächlich brauchen, nicht ein besserer Autor, sondern ein günstigerer, zuverlässigerer Richter ist. Diese Wette zahlt sich nur aus, wenn die Wahrscheinlichkeit vertrauenswürdig ist, denn alles, was einem Scorer nachgelagert ist, ist ein Schwellenwert: 0,7 wird an eine Person eskaliert, 0,95 wird automatisch akzeptiert, und die Kosten dafür, diese Grenze falsch zu ziehen, werden mit schlechten automatisierten Entscheidungen statt mit Tokens bezahlt. Ein Anbieter, der den Scorer ohne die Kalibrierungstabelle ausliefert, verlangt von jedem Kunden, sie anhand seiner eigenen Daten neu herzuleiten.

Microsofts eigene Dokumentation empfiehlt genau das, was die Kritik entschärft und zugleich die praktische Schlussfolgerung schärft. Validieren Sie mit Daten, die für Ihren Anwendungsfall repräsentativ sind. Leiten Sie Schwellenwerte aus den Kosten Ihrer Fehler ab statt aus einem Standardwert. Fügen Sie immer eine Enthaltungsoption hinzu. Randomisieren Sie die Reihenfolge der Optionen, wenn die Reihenfolge die Antwort verzerren könnte. Beziehen Sie bei allem, was Konsequenzen hat, einen Menschen ein. Das ist ein solider Rat für jeden Bewerter. Für diesen hier ist es der einzige verfügbare Rat.

Es diese Woche ausprobieren, ohne sich festzulegen.

Die kostengünstigste Evaluierung besteht darin, eine Entscheidung auszuwählen, die Sie bereits manuell treffen, zweihundert beschriftete Fälle mit den Antwortmengen zusammenzustellen, die Ihre Anwendung tatsächlich liefern würde, und sie durch eine Foundry-Bereitstellung laufen zu lassen. Berechnen Sie den erwarteten Kalibrierungsfehler für die Ausgabe, und Sie werden mehr über Microsoft-Decision-1 wissen als alles, was Microsoft darüber veröffentlicht hat, weil Sie es an Ihrer Verteilung gemessen haben werden und nicht an einem zurückgehaltenen internen Testset. Das ist ein Nachmittag Arbeit, und damit erledigt sich die gesamte Benchmark-Frage.

Wo OrcaRouter hineinpasst, ist die andere Hälfte einer Bewertungsschleife, und zwar die Hälfte, die generiert. Wir hosten Microsoft-Decision-1 nicht, und es ist nicht in unserem Katalog – ein Modell, das Wahrscheinlichkeiten statt Text zurückgibt, ist nichts, wohin man Chat-Completions routet, und nichts hier sollte als Verfügbarkeitsaussage gelesen werden. Hinter unserem einen OpenAI-kompatiblen Schlüssel steht der Pool von mehr als 200 Modellen, die das Schreiben übernehmen: das Modell, das die Bewertungsrubrik entwirft, die beiden, die Kandidatenantworten erzeugen, dasjenige, das den Tool-Aufruf Decision-1 ausgibt und dann bewertet, bevor er ausgeführt wird.Der Listenpreis des Anbieters wird mit 0 % Aufschlag durchgereicht, sodass eine Preissenkung auf der Generatorseite am selben Tag bei uns live ist, und automatisches Failover hält den Generierungszweig am Leben, wenn ein einzelner Anbieter beeinträchtigt ist – was in einer Pipeline, die alles bewertet, was sie sieht, mehr zählt als in einer, die nur gelegentlich einen Nutzer bedient. Wenn Sie lieber nicht einen einzelnen Judge auswählen möchten, setzt die Routing-DSL mehrere Modelle zu einem Aufruf zusammen, und Modellfusion meldet deren Übereinstimmung als bewertetes Feld statt als Prosa, die Sie lesen müssen.

Was diesen Artikel verändern würde, ist eine Tabelle. Veröffentlichen Sie die Brier-Scores und die ECE, oder lassen Sie einen unabhängigen Lauf auf einem Leaderboard landen, und die obige Evaluation wird zu einer Bestätigung statt zum einzigen existierenden Beleg. Bis dahin ist die zutreffende Beschreibung von Microsoft-Decision-1 eng: Die Gewichte sind real, der Vertrag ist besser dokumentiert, als es die meisten gehosteten Releases schaffen, die Enthaltungsoption ist von vornherein vorgesehen statt nachträglich angeflanscht, und die Leistungsbehauptung ist ein Satz – ein gut geschriebener, dem keinerlei Zahlen beigefügt sind.

Fazit

Microsoft-Decision-1 erreichte am 8. Oktober 2026 die allgemeine Verfügbarkeit auf Microsoft Foundry als textbasierter Entscheidungs-Scorer mit 32.768 Token, der auf Qwen3.5-9B basiert und kalibrierte Wahrscheinlichkeiten über Ihre eigenen Optionssets zurückgibt – mit null Ausgabe-Tokens und ohne Gewichte zum Herunterladen. Seine Stärken sind ein sauberer Single-Pass-Vertrag, ein fest eingebauter Enthaltungspfad sowie angebundene Azure-Authentifizierung, -Abrechnung und -Governance; seine Schwäche ist, dass niemand außerhalb von Microsoft eine veröffentlichte Zahl dafür hat, wie gut er kalibriert ist, einschließlich Microsoft. Betrachten Sie den Launch als eine API, die verfügbar wird, nicht als eine Fähigkeit, die etabliert wird, und lassen Sie Ihre eigenen gelabelten Fälle durchlaufen, bevor irgendetwas nachgelagert von einem Schwellenwert abhängt.