Microsoft-Decision-1 är nu live på Foundry. Fliken Benchmarks är tom.

Det mest intressanta med Microsofts lansering den här veckan är inte vad Microsoft-Decision-1 kan göra. Det är vad Microsoft valde att inte skriva om den. Modellen är live: den blev allmänt tillgänglig på Microsoft Foundry den 8 oktober 2026, två dagar innan detta skrevs. Det är en modell för beslutsbedömning – du ger den ett tillstånd och en fråga med en fast uppsättning svar, och den returnerar en kalibrerad sannolikhet per svar – eftertränad av Microsoft på den öppenviktade Qwen3.5-9B, som kör ett enda pass över upp till 32 768 tokens och avger noll utdatatokens eftersom den aldrig genererar någonting alls. Katalogsidan har en flik som heter Benchmarks. Den innehåller ett stycke om metodik och inga siffror.

Det gapet är historien, och det är en mer användbar sådan än ännu en "Microsoft levererar en modell"-nyhet. Varje seriös fråga om en scorer är en kalibreringsfråga – betyder ett returnerat 0,8 verkligen 0,8 – och en lansering som kommer utan ett enda Brier score eller mått på förväntat kalibreringsfel lämnar det enda tal som spelar roll att mätas av den som tar den i bruk. Det som följer är vad Foundry-sidan faktiskt dokumenterar, vad den påfallande nog utelämnar, och vad ett utvärderingsteam kan göra åt det den här veckan.

Vad som levererades, exakt

Microsoft-Decision-1 är ett hostat API. Kontraktet är ett anrop in, en fördelning ut, utan någon avkodningsslinga någonstans i kedjan: förfrågan innehåller materialet som ska bedömas plus en fråga med en begränsad svarsuppsättning, och svaret innehåller en sannolikhet för varje alternativ. Microsoft listar de stödda frågeformaten som ja/nej, flerval, betyg, klassificering och rubrikbaserade, allt inom ett enda anrop på upp till 32K tokens. Det är endast text — ingen bild-, ljud- eller videoinmatning, och ut kommer inget annat än siffror.

Undantagen anges lika tydligt som funktionerna, och de är värda att läsa först av allt: inte utformad för textgenerering, öppet frågebesvarande, konversation, översättning eller sammanfattning, och inte avsedd för uppgifter som kräver kunskap som saknas i indata. Den producerar inga motiveringar. De publicerade användningsfallen är alla platser där ett plattformsteam redan har ett märkt beslut att fatta – bedöma ett genererat svar mot en bedömningsmall, bedöma hämtningsrelevans, triagera en kö, grinda ett föreslaget agentverktygsanrop, granska innehåll mot tröskelvärden som applikationen definierar i stället för en fast leverantörspolicy, och automatiskt acceptera resultat med hög konfidens medan resten eskaleras.

Två operativa detaljer sticker ut i driftsättningslistan. Det första är att Microsoft uttryckligen stöder ett avståendealternativ som "kan inte avgöra" när de tillhandahållna bevisen är otillräckliga – det är skillnaden mellan en poängsättare som är kalibrerad och en som bara är självsäker, och det är vad som får tröskelvärdesättning att fungera. Det andra är att batchinferens är inaktiverad. Du kan inte amortisera en stor poängsättningskörning via batchkanalen på samma sätt som du skulle göra med en generativ modell, så latensen per anrop är din pipelines latens i stället för ett problem för ett offlinejobb.

Distribution sker endast via Foundry, i portföljen "Direct from Azure" som en serverlös eller enhetlig slutpunktsdistribution på standard-SKU – betala per användning eller reserverat etablerat dataflöde. Vikterna distribueras inte. Det finns inget Hugging Face-arkiv, ingen nedladdning, ingen väg för finjustering och inget alternativ för egen hosting. Program integreras över HTTPS med standardautentisering i Azure. Träningsredovisningen rapporterar att datamängden först användes i september 2026 med pågående insamling, vilket är det kortast möjliga avståndet mellan träningsdata och ett GA-datum och är normalt för en efterträning på någon annans släppta bas.

Fliken Benchmarks, citerad i sin helhet

Här är allt som Microsoft har publicerat om hur väl modellen presterar. Utvärderingen använde ”offentliga och gemenskapsbaserade beslutsbenchmarkar samt internt undanhållna testset som inte använts i träning”. Metriken var noggrannhet, kalibreringsfel, säkerhetsrecall, andel falska positiva och konsekvens i rättvisa. Alternativens ordning varierades. Parade statistiska tester tillämpades. Påståendet är kvalitativt: Microsoft-Decision-1 ”presterar i nivå med ledande beslutsmodeller och före andra öppna beslutsmodeller som utvärderats med samma metodik.”

Det är en kompetent utvärderingsdesign som beskrivs utan ett resultat. Det är inte en anklagelse att påpeka det – ett metodavsnitt utan tabell är ett specifikt, kontrollerbart val, och det är ett annat val än det som resten av den här lilla kategorin har gjort. De öppna beslutsmodeller som Microsoft implicit jämför sig med publicerar sina siffror: InternLMs Intern-Decision-familj trycker Brier- och expected-calibration-error-siffror på sina modellkort, TypeSafes Jev publicerar båda, och Liquid AIs d1-serie levererar noggrannhetstabeller tillsammans med sina vikter. Microsoft är det största företaget i den här gruppen och det enda som ber att få bli taget på förtroende.

Företaget säger faktiskt var det anser att modellen är stark och svag, vilket är mer användbart än ett övergripande betyg. Starkast: resonemang, regelapplicering och robusthet mot promptformatering. Konkurrenskraftig: klassificering, hämtning, rättvisa, verktygsanvändning och de flesta flerspråkiga uppgifter. Svagast: specialiserad domänkunskap. De självrapporterade begränsningarna är uppriktiga på samma sätt – poäng kan förändras beroende på formulering och ordningen på svarsalternativen, en dåligt formulerad fråga ger fortfarande en poäng, kalibreringen är starkast för välbekanta uppgiftstyper, och det finns inga förklaringar att granska när ett svar verkar fel.

Språktäckningen har samma typ av förbehåll. 25 språk listas som stödda, med japanska, koreanska, arabiska, vietnamesiska, thailändska, turkiska, hindi, bengaliska, swahili, hebreiska, persiska och ukrainska bland andra, med den uttryckliga varningen att täckning, kvalitet och kalibrering "kan variera mellan språk" och att icke-engelska, särskilt lågresursspråk, är ett område med svag prestanda. Basmodellen Qwen3.5-9B stöder långt över 200 språk. Efterträningen behöll ungefär en fjärdedel av detta, och det är i den fjärdedelen som kalibreringen anpassades.

Inget pris på sidan heller

Katalogens prisfält anger ingen taxa. Det länkar ut till Microsofts egen prissättningsyta för modeller, så kostnaden per beslut är något man läser av från Azure eller från en faktura snarare än från modellkortet. För den som modellerar kostnad per beslut i volym är det en verklig lucka, och det är värt att säga rakt ut i stället för att uppskatta. Två saker följer faktiskt av arkitekturen och är värda att ta med i den uppskattningen: 0 % av kostnaden för ett anrop utgörs av utdatatokens, eftersom det inte finns några, och alternativuppsättningen är en del av indata, så en fråga med sextiotvå beskrivande alternativ kostar mer per anrop än en ja/nej-fråga – du betalar för bedömningsmallen du skrev, inte för svaret.

Varför den här formen av release är det intressanta

En beslutsbedömare är en satsning på att det som de primitiva företagen faktiskt behöver inte är en bättre skribent utan en billigare, mer tillförlitlig domare. Den satsningen lönar sig bara om sannolikheten är tillförlitlig, eftersom allt nedströms en bedömare är en tröskel: 0,7 eskalerar till en person, 0,95 accepterar automatiskt, och kostnaden för att få den gränsen fel betalas i dåliga automatiserade beslut snarare än i tokens. En leverantör som levererar bedömaren utan kalibreringstabellen ber varje kund att härleda den på nytt utifrån sina egna data.

Microsofts egen dokumentation rekommenderar exakt det, vilket samtidigt mildrar kritiken och skärper den praktiska slutsatsen. Validera på data som är representativa för ditt användningsfall. Sätt tröskelvärden utifrån kostnaden för dina fel i stället för utifrån en standard. Inkludera alltid ett alternativ att avstå. Slumpa ordningen på alternativen där ordningen skulle kunna snedvrida svaret. Håll en människa i loopen för allt som får konsekvenser. Det är klokt råd för vilken bedömare som helst. Det är det enda råd som finns för den här.

Testar det den här veckan utan att binda mig

Den billigaste utvärderingen är att välja ett beslut som du redan fattar manuellt, sammanställa tvåhundra märkta fall med de svarsuppsättningar som din applikation faktiskt skulle leverera, och köra dem genom en Foundry-driftsättning. Beräkna förväntat kalibreringsfel på utdata och du kommer att veta mer om Microsoft-Decision-1 än vad Microsoft har publicerat om den, eftersom du kommer att ha mätt den på din fördelning i stället för på en undanhållen intern testuppsättning. Det är en eftermiddags arbete och det avskaffar hela benchmarkfrågan.

Var OrcaRouter passar in är på den andra halvan av en poängsättningsloop, och det är den halva som genererar. Vi hostar inte Microsoft-Decision-1 och den finns inte i vår katalog – en modell som returnerar sannolikheter i stället för text är inget man routar chattkompletteringar till, och inget här bör läsas som ett tillgänglighetsanspråk. Det som ligger bakom vår enda OpenAI-kompatibla nyckel är poolen av fler än 200 modeller som sköter skrivandet: modellen som utformar bedömningsmallen, de två som tar fram kandidatsvar, den som avger verktygsanropet Decision-1 och sedan poängsätter innan det körs. Leverantörens listpris förs vidare med 0 % påslag, så en prissänkning på generatorsidan slår igenom hos oss samma dag, och automatisk failover håller genereringsbenet vid liv när en enskild leverantör försämras – vilket spelar större roll i en pipeline som poängsätter allt den ser än i en som svarar en användare då och då. Om du hellre vill slippa välja en enda domare, komponerar routnings-DSL:en flera modeller till ett anrop, och modellfusion rapporterar deras överensstämmelse som ett poängsatt fält i stället för som prosa du måste läsa.

Det som skulle förändra den här artikeln är en tabell. Publicera Brier-poängen och ECE, eller låt en oberoende körning landa på en resultattavla, så blir utvärderingen ovan en bekräftelse i stället för det enda bevis som existerar. Fram till dess är den korrekta beskrivningen av Microsoft-Decision-1 snäv: vikterna är verkliga, kontraktet är dokumenterat bättre än vad de flesta hostade releaser klarar av, möjligheten att avstå är inbyggd snarare än påmonterad, och prestandapåståendet är en mening – en välskriven sådan, utan en enda siffra kopplad till sig.

Slutsats

Microsoft-Decision-1 blev allmänt tillgänglig på Microsoft Foundry den 8 oktober 2026 som en beslutsbedömare för enbart text med 32 768 token, byggd på Qwen3.5-9B, som returnerar kalibrerade sannolikheter över dina egna alternativuppsättningar med noll utdatatoken och inga vikter att ladda ner. Dess styrkor är ett rent kontrakt för en enda genomkörning, en inbyggd väg för att avstå från att svara och att Azure-autentisering, fakturering och styrning är kopplade till den; dess svaghet är att ingen utanför Microsoft har publicerat en siffra på hur välkalibrerad den är, inte heller Microsoft. Betrakta lanseringen som att ett API blir tillgängligt, inte som att en förmåga etableras, och kör dina egna märkta fall genom den innan något nedströms beror på en tröskel.