Microsoft-Decision-1 staat live op Foundry. Het tabblad Benchmarks is leeg.

Het meest interessante aan de Microsoft-release van deze week is niet wat Microsoft-Decision-1kan doen. Het is wat Microsoft ervoor koos er niet over te publiceren. Het model is live: het werd algemeen beschikbaar gesteld op Microsoft Foundry op 8 oktober 2026, twee dagen voordat dit werd geschreven. Het is een beslissingsscoremodel — je geeft het een toestand en een vraag met een vaste set antwoorden, en het geeft een gekalibreerde waarschijnlijkheid per antwoord terug — na-getraind door Microsoft op het open-weight Qwen3.5-9B, waarbij het één pass uitvoert over maximaal 32.768 tokens en nul uitvoertokens produceert omdat het helemaal nooit iets genereert. De cataloguspagina heeft een tabblad Benchmarks. Die bevat een methodologieparagraaf en geen cijfers.

Dat gat is het verhaal, en het is een nuttiger verhaal dan nog een item in de trant van "Microsoft brengt een model uit". Elke serieuze vraag over een scorer is een kalibratievraag — betekent een teruggegeven 0,8 ook 0,8 — en een lancering die verschijnt zonder één enkele Brier-score of een cijfer voor expected calibration error, laat het ene getal dat ertoe doet, over aan degene die het adopteert om te meten. Wat volgt is wat de Foundry-pagina daadwerkelijk documenteert, wat ze opvallend weglaat, en wat een evaluatieteam er deze week aan kan doen.

Wat er precies is uitgebracht

Microsoft-Decision-1 is een gehoste API. Het contract is één aanroep erin, één distributie eruit, zonder ergens in het pad een decoderingslus: het verzoek bevat het te beoordelen materiaal plus een vraag met een begrensde antwoordset, en het antwoord bevat een waarschijnlijkheid voor elke optie. Microsoft vermeldt de ondersteunde vraagvormen als ja/nee, meerkeuze, beoordeling, classificatie en op rubrics gebaseerd, allemaal binnen één enkele aanroep van maximaal 32K tokens. Het is uitsluitend tekst — geen beeld-, audio- of video-invoer, en als uitvoer niets dan getallen.

De uitsluitingen worden even duidelijk vermeld als de functies, en ze zijn het waard om vóór alles te lezen: niet ontworpen voor tekstgeneratie, open vraagbeantwoording, gesprekken, vertaling of samenvatting, en niet bedoeld voor taken waarvoor kennis nodig is die niet in de invoer aanwezig is. Het produceert geen onderbouwingen. De gepubliceerde use cases zijn allemaal situaties waarin een platformteam al een gelabelde beslissing moet nemen — het beoordelen van een gegenereerd antwoord aan de hand van een rubric, het beoordelen van retrievalrelevantie, het triageren van een wachtrij, het al dan niet doorlaten van een voorgestelde agent-toolaanroep, het screenen van content aan de hand van drempelwaarden die de applicatie zelf definieert in plaats van een vast leveranciersbeleid, en het automatisch accepteren van uitkomsten met hoge betrouwbaarheid terwijl de rest wordt geëscaleerd.

Twee operationele details vallen op in het deployment-overzicht. Het eerste is dat Microsoft expliciet een abstentieoptie zoals "kan het niet zeggen" ondersteunt wanneer het aangeleverde bewijs onvoldoende is — dat is het verschil tussen een scorer die gekalibreerd is en een die slechts zelfverzekerd is, en dat is wat drempels laat werken. Het tweede is dat batch-inferentie is uitgeschakeld. Je kunt een grote scoringsrun niet via het batchkanaal amortiseren zoals je bij een generatief model zou doen, dus de latentie per aanroep is de latentie van je pijplijn in plaats van het probleem van een offline taak.

Distributie is uitsluitend via Foundry, in het portfolio "Direct from Azure" als een serverless- of unified-endpoint-implementatie op standaard-SKU — pay-as-you-go of gereserveerde provisioned throughput. De gewichten worden niet gedistribueerd. Er is geen Hugging Face-repository, geen download, geen fine-tuningpad en geen optie voor self-hosting. Applicaties integreren via HTTPS met standaard Azure-verificatie. De trainingsdisclosure meldt dat de dataset voor het eerst werd gebruikt in september 2026, met nog lopende verzameling, wat de kortst mogelijke afstand is tussen trainingsdata en een GA-datum en normaal is voor een post-train op de vrijgegeven basis van iemand anders.

Het tabblad Benchmarks, volledig geciteerd

Hier is de volledige informatie die Microsoft heeft gepubliceerd over hoe goed het model presteert. De evaluatie gebruikte "openbare en gemeenschapsbeslissingsbenchmarks en achtergehouden interne testsets die niet in de training zijn gebruikt." De metrieken waren nauwkeurigheid, kalibratiefout, veiligheidsrecall, percentages valse positieven en eerlijkheidsconsistentie. De volgorde van de opties werd gevarieerd. Er werden gepaarde statistische tests toegepast. De bewering is kwalitatief: Microsoft-Decision-1 "presteert op hetzelfde niveau als toonaangevende beslissingsmodellen en beter dan andere open beslissingsmodellen die met dezelfde methodologie zijn geëvalueerd."

Dat is een competente evaluatieopzet die wordt beschreven zonder resultaat. Het is geen beschuldiging om daarop te wijzen — een methodologieparagraaf zonder tabel is een specifieke, controleerbare keuze, en het is een andere keuze dan degene die de rest van deze kleine categorie heeft gemaakt. De open beslissingsmodellen waarmee Microsoft impliciet vergelijkt, publiceren hun cijfers: de Intern-Decision-familie van InternLM vermeldt Brier- en expected-calibration-error-cijfers op zijn modelkaarten, TypeSafe's Jev publiceert beide, en de d1-lijn van Liquid AI levert nauwkeurigheidstabellen mee met zijn gewichten. Microsoft is het grootste bedrijf in deze groep en het enige dat vraagt om op vertrouwen te worden aangenomen.

Het bedrijf zegt wel waar het model volgens hen sterk en zwak in is, wat bruikbaarder is dan een score in de kop. Het sterkst: redeneren, toepassing van regels en robuustheid voor de opmaak van prompts. Competitief: classificatie, retrieval, fairness, gebruik van tools en de meeste meertalige taken. Het zwakst: gespecialiseerde domeinkennis. De zelfgerapporteerde beperkingen zijn even openhartig: scores kunnen verschuiven met de formulering en de volgorde van opties, een slecht geformuleerde vraag levert nog altijd een score op, kalibratie is het sterkst bij bekende taaktypen, en er zijn geen uitleg om te controleren wanneer een antwoord fout lijkt.

De taaldekking kent dezelfde vorm van voorbehoud. 25 talen worden als ondersteund vermeld, met onder meer Japans, Koreaans, Arabisch, Vietnamees, Thais, Turks, Hindi, Bengaals, Swahili, Hebreeuws, Perzisch en Oekraïens, met de expliciete waarschuwing dat dekking, kwaliteit en kalibratie "per taal kunnen verschillen" en dat niet-Engels, met name talen met minder hulpbronnen, een gebied is waar ondermaats wordt gepresteerd. De Qwen3.5-9B-basis ondersteunt ruim meer dan 200 talen. De post-training behield ongeveer een kwart daarvan, en op dat kwart is de kalibratie afgestemd.

Ook geen prijs op de pagina

Het prijsveld van de catalogus vermeldt geen tarief. Het linkt door naar Microsofts eigen prijsoverzicht voor modellen, dus de kosten per beslissing lees je af van Azure of van een factuur, niet van de modelkaart. Voor wie de kosten per beslissing bij volume modelleert, is dat een echte lacune, en het is de moeite waard om dat ronduit te zeggen in plaats van te schatten. Twee dingen volgen wel uit de architectuur en zijn het waard om in die schatting mee te nemen: 0% van de kosten van een aanroep bestaat uit outputtokens, want die zijn er niet, en de optieset maakt deel uit van de input, dus een vraag met tweeënzestig beschrijvende opties kost per aanroep meer dan een ja/nee-vraag — je betaalt voor het beoordelingskader dat je hebt geschreven, niet voor het antwoord.

Waarom deze vorm van release het interessante deel is

Een beslissingsscorer is een weddenschap dat wat primitieve ondernemingen echt nodig hebben, niet een betere schrijver is, maar een goedkopere, betrouwbaardere beoordelaar. Die weddenschap loont alleen als de waarschijnlijkheid betrouwbaar is, want alles stroomafwaarts van een scorer is een drempel: 0,7 escaleert naar een persoon, 0,95 accepteert automatisch, en de kosten van het verkeerd trekken van die grens worden betaald in slechte geautomatiseerde beslissingen in plaats van in tokens. Een leverancier die de scorer zonder de kalibratietabel levert, vraagt elke klant om die op basis van hun eigen data opnieuw af te leiden.

Microsofts eigen documentatie beveelt precies dat aan, wat de kritiek verzacht en tegelijk de praktische conclusie aanscherpt. Valideer op data die representatief zijn voor uw use case. Stel drempels in op basis van de kosten van uw fouten in plaats van op basis van een standaardwaarde. Neem altijd een mogelijkheid tot onthouding op. Randomiseer de volgorde van opties waar de volgorde het antwoord zou kunnen beïnvloeden. Houd voor alles wat gevolgen heeft een mens in de lus. Dat is verstandig advies voor elke scorer. Het is het enige advies dat beschikbaar is voor deze.

Deze week probeer ik het zonder me vast te leggen

De goedkoopste evaluatie is om een beslissing te kiezen die je al handmatig neemt, tweehonderd gelabelde gevallen samen te stellen met de antwoordsets die je applicatie daadwerkelijk zou leveren, en ze door een Foundry-implementatie te laten lopen. Bereken de verwachte kalibratiefout op de output en je weet meer over Microsoft-Decision-1 dan uit alles wat Microsoft erover heeft gepubliceerd, omdat je het op jouw distributie hebt gemeten in plaats van op een achtergehouden interne testset. Dat is een middag werk en het maakt de hele benchmarkvraag overbodig.

Waar OrcaRouter past, is op de andere helft van een scoringslus, en dat is de helft die genereert. We hosten Microsoft-Decision-1 niet en het staat niet in onze catalogus — een model dat waarschijnlijkheden retourneert in plaats van tekst is niet iets waar je chat-completions naartoe routeert, en niets hier mag worden gelezen als een beschikbaarheidsclaim. Wat achter onze ene OpenAI-compatibele sleutel zit, is de pool van meer dan 200 modellen die het schrijfwerk doen: het model dat de rubric opstelt, de twee die kandidaatantwoorden produceren, degene die de tool call Decision-1 uitzendt en dan scoort voordat die wordt uitgevoerd. De lijstprijs van de provider wordt doorgegeven tegen 0% markup, dus een prijsverlaging aan de generatorkant is dezelfde dag bij ons live, en automatische failover houdt de generatiepoot in leven wanneer één provider verslechtert — wat meer uitmaakt in een pijplijn die alles scoort wat ze ziet dan in een die af en toe een gebruiker antwoordt. Als je liever niet één enkele rechter kiest, componeert de routing-DSL meerdere modellen tot één call, en model fusion rapporteert hun overeenstemming als een gescoord veld in plaats van als proza dat je moet lezen.

Wat dit artikel zou veranderen, is een tabel. Publiceer de Brier-scores en de ECE, of laat een onafhankelijke run op een leaderboard belanden, en de bovenstaande evaluatie wordt een bevestiging in plaats van het enige bewijs dat bestaat. Tot dan is de nauwkeurige beschrijving van Microsoft-Decision-1 beperkt: de gewichten zijn echt, het contract is beter gedocumenteerd dan de meeste gehoste releases voor elkaar krijgen, de abstentieoptie is vanaf het ontwerp ingebouwd in plaats van eraan vastgeschroefd, en de prestatieclaim is één zin — een goed geschreven zin, waaraan geen enkel cijfer hangt.

Kortom

Microsoft-Decision-1 bereikte op 8 oktober 2026 algemene beschikbaarheid op Microsoft Foundry als een uitsluitend tekstuele beslissingsscorer met 32.768 tokens, gebouwd op Qwen3.5-9B, die gekalibreerde waarschijnlijkheden over je eigen optiesets retourneert zonder uitvoertokens en zonder gewichten om te downloaden. De sterke punten zijn een schoon single-pass-contract, een ingebouwd onthoudingspad, en Azure-authenticatie, facturering en governance die eraan gekoppeld zijn; de zwakte is dat niemand buiten Microsoft een gepubliceerd cijfer heeft voor hoe goed hij gekalibreerd is, inclusief Microsoft. Beschouw de lancering als een API die beschikbaar komt, niet als een capaciteit die wordt gevestigd, en haal je eigen gelabelde gevallen erdoorheen voordat iets stroomafwaarts afhankelijk wordt van een drempelwaarde.