Microsoft-Decision-1: Microsoft-modellen som svarar med ett tal i stället för en mening

Microsoft-Decision-1 har en rad i sitt modellkort som ingen annan Microsoft-modell någonsin har haft: inte avsedd för textgenerering. Modellen blev allmänt tillgänglig på Microsoft Foundry den 8 oktober 2026, och det är en medveten avgränsning av vad en språkmodell är till för. Du ger den en situation och en fråga med en fast lista av svarsalternativ — ja/nej, en uppsättning flervalsalternativ, en betygsskala, en bedömningsmatris — och den returnerar en kalibrerad sannolikhet för varje alternativ. Ingen prosa. Ingen förklaring. Inget motiveringsfält. Utdata är JSON-nummer och inget annat. Den är byggd på modellen med öppna vikter, Qwen3.5-9B, eftertränad av Microsoft, och Microsoft säger att man senare kommer att basera om modellen på andra backbone-nätverk, och nämner MAI och andra partnermodeller.

Det är en underligare produkt än vad den först låter som. Microsofts konkurrensposition 2026 vilar på frontier-chattmodeller och på Copilot, och Microsoft-Decision-1 är motsatsen till båda: en medelstor scorer med ett enda syfte, vars hela uppgift är att tala om för en applikation vilket av dina egna alternativ som med störst sannolikhet är korrekt, och hur säker den är. Den intressanta frågan är inte om den är bra på att skriva – den är uttryckligen dålig på det och försöker inte – utan om en sannolikhetsfördelning över alternativ är en mer användbar primitiv för de arbetsbelastningar som företag faktiskt kör än ännu en generell modell med ett JSON-läge.

Vad det gör, exakt

Kontraktet är ett anrop in, en distribution ut. Microsoft listar de frågeformat som stöds som ja/nej, flerval, betyg, klassificering och rubrikbaserade. Varje alternativ får en poäng. Modellen körs i ett enda anrop över indata på upp till 32K tokens — 32 768 är det angivna kontextfönstret — och det praktiska taket är indata plus alternativuppsättningen, inte en genereringsbudget, eftersom det inte finns någon generering.

De publicerade användningsfallen är de som ett plattformsteam omedelbart skulle känna igen:

• Utvärdering av AI-utdata — bedöm ett genererat svar mot en tillhandahållen bedömningsmall, eller avgör om det är grundat i det underlag det fick.

• Klassificering och routning — klassificera en förfrågan, bedöma relevans, triagera en kö, välja en gren i ett arbetsflöde.

• Skyddsräcken för agenter — poängsätt ett föreslaget verktygsanrop eller en agentåtgärd innan den integrerande applikationen låter det köras.

• Innehållssäkerhetsgranskning — flagga innehåll mot tröskelvärden som applikationen definierar, i stället för en fast leverantörspolicy.

• Sök- och dokumentrelevans — bedöm huruvida ett hämtat dokument besvarar en given fråga.

• Konfidensbaserad automatisering – acceptera automatiskt utfall med hög konfidens och eskalera resten till en människa.

Alternativet att avstå är detaljen som är värd att lägga märke till. Microsoft stöder uttryckligen alternativ som "kan inte avgöra" när underlaget är otillräckligt, vilket är skillnaden mellan en poängsättare som är kalibrerad och en som bara är självsäker. Och eftersom poäng kommer tillbaka som siffror är eskaleringsgränsen ett beslut du äger — du bestämmer var 0.7 skickar något till en person och 0.95 inte gör det.

Vad det inte kommer att göra

Microsoft är ovanligt tydliga med undantagen, och de är viktigare än funktionslistan för alla som dimensionerar detta för en verklig pipeline. Microsoft-Decision-1 är inte utformat för textgenerering, besvarande av öppna frågor, konversation, översättning eller sammanfattning. Det är inte avsett för uppgifter utan en sluten fråga och en definierad uppsättning svarsalternativ, eller för uppgifter som kräver kunskap som saknas i indata. Det är enbart text: inga bilder, ljud eller video in, inga ut. Det ger inga förklaringar eller motiveringar.

Läs dem tillsammans och en gräns framträder som är lätt att snubbla över. Det här är inte en chattbot som du kan be att också klassificera saker, och det är inte en sammanfattare som du kan koppla en poäng till. Det är en poängsättningsfunktion med en tokenbudget. Teamets egen formulering – att den inte bör vara den enda automatiserade beslutsfattaren i beslut med stora konsekvenser som rör människor, och inte bör vara den enda grunden för beslut som rör kredit, anställning, boende, försäkring, utbildning, hälso- och sjukvård, juridiska rättigheter "eller liknande områden med stora konsekvenser" – pekar i samma riktning. Den är utformad för att finnas vid sidan av ett beslut, inte för att vara det.

Benchmark-situationen är historien som ingen vill trycka.

Det finns inga siffror. Microsoft Foundry-katalogsidan för Microsoft-Decision-1 har en flik för Benchmarks, och den innehåller inga siffror. Det den i stället innehåller är ett stycke om metodik och ett kvalitativt påstående: modellen "utvärderades på offentliga och community-baserade benchmarks för beslutsfattande och på interna testuppsättningar som hållits undan och inte använts i träningen," Microsoft rapporterar att den "presterar i nivå med ledande beslutsmodeller och bättre än andra öppna beslutsmodeller som utvärderats med samma metodik," och måtten som användes var noggrannhet, kalibreringsfel, säkerhetsrecall, falskpositiva frekvenser och rättvisekonsistens, där ordningen på alternativen varierades och parade statistiska tester tillämpades.

Det är en seriös metodbeskrivning som åtföljs av noll publicerade resultat. Det innebär att varje prestandapåstående om Microsoft-Decision-1 i dag är leverantörsrapporterat och inte reproducerat, och den ärliga hållningen för den som utvärderar det är att kalibreringen – den enda egenskap som över huvud taget gör en sannolikhet användbar – är overifierad utanför Microsoft. Företaget anger visserligen var det anser att modellen är starkast och svagast, vilket är mer användbart än ett enskilt toppbetyg: starkast på resonemang, regeltillämpning och robusthet mot promptformatering; konkurrenskraftig på klassificering, retrieval, rättvisa, verktygsanvändning och de flesta flerspråkiga uppgifter; svagare på specialiserade domänkunskapsuppgifter.

Det självrapporterade är värt att läsa före funktionslistan. Poäng kan skifta beroende på formulering och svarsalternativ, och en dåligt formulerad fråga ger fortfarande en poäng. Kalibreringen är starkast för uppgiftstyper. Den kan förlita sig på föråldrad kunskap och ger inga förklaringar. När det gäller flerspråkig täckning: 25 språk listas som stödda, inklusive japanska, koreanska, arabiska, vietnamesiska, thailändska, turkiska, hindi, bengaliska, swahili, hebreiska, persiska och ukrainska, men Microsoft uppger att täckning, kvalitet och kalibrering ”kan variera mellan språk” och listar icke-engelska – särskilt lågresursspråk – som ett område med underprestation. Den underliggande Qwen3.5-9B stöder fler än 200 språk; den eftertränade modellen stöder en fjärdedel av detta.

Hur du får det, och vad det kostar

Microsoft-Decision-1 distribueras som ett hostat API i Microsoft Foundry under portföljen "Direct from Azure". Modellvikter distribueras inte – detta är inte en utgåva med öppna vikter, och det finns inget Hugging Face-arkiv för att ladda ner den. Alla program som kan skicka HTTPS-begäranden kan integrera med Foundry-slutpunkterna och standardautentisering i Azure. Distributionslistningen visar serverlösa och enhetliga slutpunktsalternativ på betala per användning eller reserverat etablerat dataflöde, standard-SKU, med batchinferens inaktiverad, och träningsdeklarationen rapporterar att träningsdatauppsättningen först användes i september 2026 med pågående insamling.

Priser publiceras inte på modellsidan. Katalogens prisfält länkar vidare till Microsofts sida för modellpriser i stället för att ange en taxa för indata och utdata, så kostnaden per token för ett Decision-1-anrop är något man måste slå upp i Azures prissättningsöversikt eller läsa av på en faktura. Det är en verklig lucka för alla som försöker modellera kostnaden per beslut vid stora volymer, och det är värt att säga rakt ut i stället för att uppskatta. Två saker är värda att känna till när du väl prissätter det: 0 % av kostnaden utgörs av utdatatokens, eftersom det inte finns några, och batchinferens är avstängd, så du kan inte fördela kostnaden för en masskörning för poängsättning via batchkanalen på samma sätt som du skulle göra med en generativ modell.

Var OrcaRouter passar in i detta är på andra sidan av anropet. 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 inte en modell man routar chattkompletteringar till. Det vi däremot erbjuder är den halva av mönstret som faktiskt genererar: de modeller som skriver bedömningsmallen, tar fram utkasten till kandidatsvaren eller producerar det verktygsanrop som Decision-1 sedan poängsätter. De finns bakom en enda OpenAI-kompatibel nyckel med fler än 200 modeller på den, till leverantörens listpris som förs vidare med 0 % påslag, så en leverantörs prissänkning på en domarmodell får genomslag hos oss samma dag. Om du bygger en utvärderingsloop där en modell skriver och en annan poängsätter, går poängsättningsanropet till Microsoft och genereringsanropet kan gå vart som helst – inklusive genom routnings-DSL:en, som komponerar flera modeller till ett enda anrop när du vill ha en panel i stället för en enda domare.

Varför en scorer är en annan satsning än en bättre chattbot

Mönstret som Microsoft säljer här finns redan öppet. InternLM:s Intern-Decision-4B, Liquid AI:s d1-3B, Convai Innovations Laya och Kev-familjen från Jared Palmer returnerar alla kalibrerade fördelningar över angivna alternativ utan att generera text, och de flesta av dem är Apache-2.0-vikter som du kan köra på din egen hårdvara gratis. Microsofts bidrag skiljer sig på tre sätt som inte är benchmarkberoende: det är ett hanterat API med Azure-autentisering, fakturering och styrning kopplade, så det passar en väg för företagsupphandling som en nedladdning från Hugging Face inte gör; dess bas är en 9B-modell, större än de flesta i det fältet; och det kommer med en Responsible AI-bedömning och en dokumenterad utvärderingsmetodik, vilket ofta är det faktiska grindkravet för en reglerad driftsättning.

Det den inte levereras med är en siffra. Gentemot öppna konkurrenter som publicerar Brier-poäng och förväntat kalibreringsfel – de två måtten som säger om en 0,8 betyder 0,8 – har Microsoft publicerat en metod och inga resultat. Tills oberoende kalibreringstester finns är det försvarbara sättet att använda Microsoft-Decision-1 det som dess egen dokumentation rekommenderar: validera på data som är representativa för ditt användningsfall, sätt trösklar utifrån kostnaden för dina fel, inkludera alltid ett alternativ att avstå, slumpa ordningen på alternativen där ordningen skulle kunna snedvrida svaret och behåll en människa i loopen för allt som får konsekvenser. Det är bra råd för vilken poängsättare som helst. Det är särskilt bra råd för en vars kalibrering ingen utanför företaget har mätt.