Microsoft-Decision-1 è online su Foundry. La sua scheda Benchmark è vuota.

La cosa più interessante del rilascio Microsoft di questa settimana non è ciò che Microsoft-Decision-1sa fare. È ciò che Microsoft ha scelto di non rendere pubblico al riguardo. Il modello è attivo: è diventato disponibile in generale su Microsoft Foundry l'8 ottobre 2026, due giorni prima che questo articolo venisse scritto. È un modello di valutazione decisionale — gli si fornisce uno stato e una domanda con un insieme fisso di risposte, e restituisce una probabilità calibrata per ogni risposta — addestrato successivamente da Microsoft sul modello open-weight Qwen3.5-9B, eseguendo una singola passata su un massimo di 32.768 token ed emettendo zero token di output perché non genera mai nulla. La pagina del catalogo ha una scheda Benchmarks. Contiene un paragrafo di metodologia e nessun dato numerico.

Quel divario è la storia, ed è una storia più utile di un altro articolo del tipo "Microsoft spedisce un modello". Ogni domanda seria su uno scorer è una domanda di calibrazione — un 0,8 restituito significa 0,8? — e un lancio che arriva senza un singolo Brier score o un valore di expected calibration error lascia che l'unico numero che conta venga misurato da chiunque lo adotti. Quanto segue è ciò che la pagina di Foundry documenta effettivamente, ciò che omette in modo evidente e ciò che un team di valutazione può fare al riguardo questa settimana.

Cosa è stato rilasciato, esattamente

Microsoft-Decision-1 è un'API ospitata. Il contratto prevede una chiamata in ingresso e una distribuzione in uscita, senza alcun ciclo di decodifica lungo il percorso: la richiesta trasporta il materiale da valutare più una domanda con un insieme limitato di risposte, e la risposta trasporta una probabilità per ciascuna opzione. Microsoft elenca le forme di domanda supportate come sì/no, scelta multipla, valutazione, classificazione e basata su rubriche, tutto all'interno di una singola invocazione fino a 32K token. È solo testo — nessun input immagine, audio o video, e in uscita nient'altro che numeri.

Le esclusioni sono enunciate con la stessa chiarezza delle funzionalità, e vale la pena leggerle prima di ogni altra cosa: non è progettato per la generazione di testo, la risposta a domande aperte, la conversazione, la traduzione o il riassunto, e non è destinato a compiti che richiedono conoscenze assenti dall'input. Non produce motivazioni. I casi d'uso pubblicati riguardano tutti situazioni in cui un team di piattaforma ha già una decisione etichettata da prendere — valutare una risposta generata in base a una rubrica, giudicare la pertinenza del retrieval, smistare una coda, decidere se consentire una chiamata a uno strumento proposta da un agente, filtrare i contenuti in base a soglie definite dall'applicazione anziché a una policy fissa del fornitore, e accettare automaticamente gli esiti ad alta confidenza mentre gli altri vengono inoltrati a un livello superiore.

Due dettagli operativi emergono dall'elenco del deployment. Il primo è che Microsoft supporta esplicitamente un'opzione di astensione come "non è possibile dirlo" quando le prove fornite sono insufficienti — questa è la differenza tra uno scorer calibrato e uno semplicemente sicuro di sé, ed è ciò che fa funzionare la sogliatura. Il secondo è che l'inferenza in batch è disabilitata. Non è possibile ammortizzare una grande esecuzione di scoring attraverso il canale batch come si farebbe con un modello generativo, quindi la latenza per chiamata è la latenza della tua pipeline, non un problema di un job offline.

La distribuzione è solo tramite Foundry, nel portfolio "Direct from Azure" come deployment serverless o con endpoint unificato su SKU standard — pay-as-you-go o throughput con provisioning riservato. I pesi non sono distribuiti. Non esiste alcun repository Hugging Face, né download, né percorso di fine-tuning, né opzione di self-hosting. Le applicazioni si integrano tramite HTTPS con l'autenticazione standard di Azure. L'informativa sull'addestramento riporta che il dataset è stato utilizzato per la prima volta a settembre 2026 con raccolta ancora in corso, il che rappresenta la distanza più breve possibile tra i dati di addestramento e una data di GA ed è normale per un post-train su una base rilasciata da altri.

La scheda benchmarks, citata integralmente

Ecco tutto ciò che Microsoft ha pubblicato su quanto bene si comporti il modello. La valutazione ha utilizzato "benchmark decisionali pubblici e della comunità e set di test interni trattenuti non utilizzati nell'addestramento". Le metriche erano accuratezza, errore di calibrazione, richiamo di sicurezza, tassi di falsi positivi e coerenza di equità. L'ordine delle opzioni è stato variato. Sono stati applicati test statistici appaiati. L'affermazione è qualitativa: Microsoft-Decision-1 "si comporta allo stesso livello dei principali modelli decisionali e supera altri modelli decisionali aperti valutati con la stessa metodologia".

Si tratta di un progetto di valutazione competente descritto senza un risultato. Non è un'accusa farlo notare: un paragrafo di metodologia senza tabella è una scelta specifica e verificabile, ed è una scelta diversa da quella presa dal resto di questa piccola categoria. I modelli decisionali aperti con cui Microsoft si sta implicitamente confrontando pubblicano i loro numeri: la famiglia Intern-Decision di InternLM riporta cifre di Brier e di errore di calibrazione atteso sulle sue schede modello, Jev di TypeSafe pubblica entrambi, e la linea d1 di Liquid AI distribuisce tabelle di accuratezza insieme ai suoi pesi. Microsoft è la più grande azienda di questo gruppo e l'unica che chiede di essere presa sulla fiducia.

L'azienda dichiara effettivamente dove ritiene che il modello sia forte e debole, il che è più utile a livello operativo di un punteggio di sintesi. Punti più forti: ragionamento, applicazione delle regole e robustezza rispetto alla formattazione dei prompt. A livello competitivo: classificazione, recupero, equità, uso di strumenti e la maggior parte delle attività multilingui. Punti più deboli: conoscenze specialistiche di dominio. Le limitazioni autodichiarate sono altrettanto sincere: i punteggi possono variare con la formulazione e l'ordine delle opzioni, una domanda mal formulata restituisce comunque un punteggio, la calibrazione è più solida sui tipi di attività familiari e non ci sono spiegazioni da verificare quando una risposta sembra sbagliata.

La copertura linguistica presenta lo stesso tipo di avvertenza. 25 lingue sono elencate come supportate, tra cui giapponese, coreano, arabo, vietnamita, thailandese, turco, hindi, bengalese, swahili, ebraico, persiano e ucraino, con l'esplicita avvertenza che copertura, qualità e calibrazione "possono variare a seconda della lingua" e che le lingue diverse dall'inglese, in particolare quelle a basse risorse, rappresentano un ambito in cui le prestazioni sono inferiori. La base Qwen3.5-9B supporta ben oltre 200 lingue. Il post-addestramento ne ha mantenuto circa un quarto, e quel quarto è quello su cui è stata effettuata la calibrazione.

Nemmeno il prezzo sulla pagina

Il campo dei prezzi del catalogo non riporta una tariffa. Rimanda alla pagina dei prezzi dei modelli di Microsoft, quindi il costo per decisione è qualcosa che si legge su Azure o su una fattura, non sulla scheda del modello. Per chiunque modelli il costo per decisione su grandi volumi, si tratta di una lacuna reale, e vale la pena dichiararlo chiaramente invece di fare stime. Due cose derivano effettivamente dall'architettura e vale la pena tenerle presenti in quella stima: lo 0% del costo di una chiamata è costituito da token di output, perché non ce ne sono, e l'insieme delle opzioni fa parte dell'input, quindi una domanda con sessantadue opzioni descrittive costa più per chiamata di una domanda sì/no — stai pagando per la rubrica che hai scritto, non per la risposta.

Perché questa forma di rilascio è la parte interessante

Uno scorer decisionale è una scommessa sul fatto che ciò di cui le imprese primitive hanno davvero bisogno non sia uno scrittore migliore, ma un giudice più economico e più affidabile. Quella scommessa ripaga solo se la probabilità è affidabile, perché tutto ciò che sta a valle di uno scorer è una soglia: 0,7 viene inoltrato a una persona, 0,95 viene accettato automaticamente, e il costo di sbagliare quella linea si paga in decisioni automatiche sbagliate anziché in token. Un fornitore che distribuisce lo scorer senza la tabella di calibrazione sta chiedendo a ogni cliente di ricavarla di nuovo sui propri dati.

La documentazione di Microsoft stessa raccomanda esattamente questo, il che attenua la critica e al tempo stesso rende più incisiva la conclusione pratica. Convalida su dati rappresentativi del tuo caso d'uso. Imposta le soglie in base al costo dei tuoi errori anziché a un valore predefinito. Includi sempre un'opzione di astensione. Randomizza l'ordine delle opzioni laddove l'ordine potrebbe influenzare la risposta. Mantieni un essere umano nel processo per qualsiasi cosa abbia conseguenze. È un consiglio saggio per qualsiasi sistema di valutazione. È l'unico consiglio disponibile per questo.

Provarlo questa settimana senza impegnarmi

La valutazione più economica consiste nel prendere una decisione che già prendi manualmente, mettere insieme duecento casi etichettati con gli insiemi di risposte che la tua applicazione fornirebbe effettivamente e farli passare attraverso un deployment Foundry. Calcola l'errore di calibrazione atteso sull'output e saprai su Microsoft-Decision-1 più di quanto Microsoft abbia pubblicato al riguardo, perché l'avrai misurato sulla tua distribuzione invece che su un set di test interno tenuto separato. È il lavoro di un pomeriggio e chiude definitivamente l'intera questione del benchmark.

Il posto di OrcaRouter è sull'altra metà di un ciclo di valutazione, ed è la metà che genera. Non ospitiamo Microsoft-Decision-1 e non è nel nostro catalogo — un modello che restituisce probabilità invece di testo non è qualcosa verso cui instradare chat completion, e nulla di quanto detto qui va letto come una dichiarazione di disponibilità. Ciò che sta dietro la nostra unica chiave compatibile con OpenAI è il pool di oltre 200 modelli che scrive: il modello che redige la rubrica, i due che producono risposte candidate, quello che emette la tool call Decision-1 e poi assegna il punteggio prima che venga eseguita. Il prezzo di listino del provider viene trasferito con markup 0%, quindi un taglio di prezzo dal lato del generatore è attivo sul nostro lo stesso giorno, e il failover automatico mantiene in vita il ramo di generazione quando un singolo provider si degrada — cosa che conta di più in una pipeline che assegna un punteggio a tutto ciò che vede rispetto a una che risponde a un utente occasionalmente. Se preferisci non scegliere un singolo giudice, il DSL di routing compone più modelli in un'unica chiamata, e la fusione dei modelli riporta il loro accordo come campo con punteggio anziché come prosa da leggere.

Ciò che cambierebbe questo articolo è una tabella. Pubblica i punteggi Brier e l'ECE, oppure lascia che un'esecuzione indipendente arrivi in una classifica, e la valutazione di cui sopra diventa una conferma invece dell'unica prova esistente. Fino ad allora, la descrizione accurata di Microsoft-Decision-1 è limitata: i pesi sono reali, il contratto è documentato meglio di quanto riesca a fare la maggior parte delle release ospitate, l'opzione di astensione è progettata fin dall'inizio invece che aggiunta a posteriori, e l'affermazione sui pesi è una frase — scritta bene, senza alcun numero a corredo.

Il risultato finale

Microsoft-Decision-1 ha raggiunto la disponibilità generale su Microsoft Foundry l'8 ottobre 2026 come scorer decisionale solo testuale da 32.768 token, basato su Qwen3.5-9B, che restituisce probabilità calibrate sui tuoi stessi set di opzioni con zero token di output e nessun peso da scaricare. I suoi punti di forza sono un contratto pulito a singola passata, un percorso di astensione progettato fin dall'inizio e autenticazione, fatturazione e governance Azure integrate; il suo punto debole è che nessuno al di fuori di Microsoft ha pubblicato un numero su quanto sia ben calibrato, Microsoft inclusa. Considera il lancio come un'API che diventa disponibile, non come una capacità che viene stabilita, e fai passare i tuoi casi etichettati attraverso di essa prima che qualsiasi cosa a valle dipenda da una soglia.