Microsoft-Decision-1 : le modèle Microsoft qui répond par un nombre au lieu d'une phrase

Microsoft-Decision-1 comporte une ligne dans sa fiche de modèle qu'aucun autre modèle Microsoft n'a jamais portée : non conçu pour la génération de texte. Le modèle est passé en disponibilité générale sur Microsoft Foundry le 8 octobre 2026, et il s'agit d'un rétrécissement délibéré de la vocation d'un modèle de langage. Vous lui soumettez une situation et une question avec une liste fixe de réponses — oui/non, un ensemble à choix multiples, une échelle d'évaluation, une grille d'évaluation — et il renvoie une probabilité calibrée pour chaque option. Pas de prose. Pas d'explication. Pas de champ de justification. La sortie est composée de nombres JSON et de rien d'autre. Il est construit sur le modèle à poids ouverts Qwen3.5-9B, post-entraîné par Microsoft, et Microsoft indique qu'il fera ultérieurement reposer le modèle sur d'autres architectures, citant MAI et d'autres modèles partenaires.

C'est un produit plus étrange qu'il n'y paraît au premier abord. La position concurrentielle de Microsoft en 2026 repose sur les modèles de chat de frontière et sur Copilot, et Microsoft-Decision-1 est l'opposé des deux : un évaluateur de taille moyenne, à finalité unique, dont l'unique fonction est d'indiquer à une application laquelle de vos propres options est la plus susceptible d'être correcte, et avec quel degré de confiance. La question intéressante n'est pas de savoir s'il est bon en rédaction — il est explicitement mauvais pour cela et ne cherche pas à l'être — mais de savoir si, pour les charges de travail que les entreprises exécutent réellement, une distribution de probabilités sur des options est une primitive plus utile qu'un autre modèle généraliste doté d'un mode JSON.

Ce qu'il fait, précisément

Le contrat est le suivant : un appel en entrée, une distribution en sortie. Microsoft répertorie les formats de question pris en charge comme étant oui/non, choix multiples, notation, classification et basés sur une grille d’évaluation. Chaque option reçoit un score. Le modèle s’exécute en une seule invocation sur des entrées allant jusqu’à 32K tokens — 32 768 est la fenêtre de contexte indiquée — et le plafond pratique correspond à l’entrée plus l’ensemble d’options, et non à un budget de génération, car il n’y a pas de génération.

Les cas d’usage publiés sont ceux qu’une équipe plateforme reconnaîtrait immédiatement :

• Évaluation des sorties d’IA — notez une réponse générée par rapport à une grille d’évaluation fournie, ou déterminez si elle est fondée sur les éléments de preuve qui lui ont été fournis.

• Classification et routage — classer une requête, évaluer la pertinence, trier une file d'attente, choisir une branche de flux de travail.

• Garde-fous d’agent — évaluer un appel d’outil ou une action d’agent proposé avant que l’application d’intégration ne le laisse s’exécuter.

• Filtrage de sécurité du contenu — signalez le contenu par rapport aux seuils définis par l'application, plutôt qu'à une politique de fournisseur figée.

• Pertinence de la recherche et du document — déterminer si un document récupéré répond à une question donnée.

• Automatisation fondée sur le niveau de confiance — accepter automatiquement les résultats à forte confiance et transmettre les autres à un humain.

L’option d’abstention est le détail qui mérite d’être remarqué. Microsoft prend explicitement en charge des options telles que « impossible à dire » lorsque les éléments fournis sont insuffisants, ce qui fait la différence entre un système de notation calibré et un système simplement confiant. Et comme les scores sont renvoyés sous forme de nombres, le seuil d’escalade est une décision qui vous appartient — c’est vous qui définissez où 0,7 envoie quelque chose à une personne et où 0,95 ne le fait pas.

Ce qu'il ne fera pas

Microsoft est inhabituellement explicite au sujet des exclusions, et celles-ci importent davantage que la liste des fonctionnalités pour quiconque évalue cela pour un véritable pipeline. Microsoft-Decision-1 n'est pas conçu pour la génération de texte, les questions-réponses ouvertes, la conversation, la traduction ou le résumé. Il n'est pas destiné aux tâches sans question fermée et ensemble défini d'options de réponse, ni aux tâches qui nécessitent des connaissances absentes de l'entrée. Il est uniquement textuel : aucune image, aucun audio ni vidéo en entrée, aucune en sortie. Il ne fournit ni explications ni justifications.

Lisez-les ensemble et une frontière apparaît, facile à franchir par mégarde. Ce n’est pas un chatbot auquel on peut demander de classer aussi des choses, et ce n’est pas un résumeur auquel on peut accoler un score. C’est une fonction de notation avec un budget de tokens. Le cadrage de l’équipe elle-même — à savoir qu’il ne devrait pas être le seul décideur automatisé pour des décisions lourdes de conséquences concernant des personnes, et qu’il ne devrait pas constituer la seule base de décisions impliquant le crédit, l’emploi, le logement, l’assurance, l’éducation, les soins de santé, les droits juridiques « ou des domaines aux conséquences similaires » — va dans le même sens. Elle est conçue pour se placer à côté d’une décision, et non pour être cette décision.

La situation des benchmarks est l'histoire que personne ne veut publier.

Il n'y a aucun chiffre. La page catalogue de Microsoft Foundry consacrée à Microsoft-Decision-1 comporte un onglet Benchmarks, et celui-ci est dépourvu de chiffres. Ce qu'elle contient à la place, c'est un paragraphe de méthodologie et une affirmation qualitative : le modèle a été « évalué sur des benchmarks de décision publics et communautaires ainsi que sur des ensembles de test internes tenus à l'écart et non utilisés lors de l'entraînement », Microsoft indique qu'il « affiche des performances équivalentes à celles des principaux modèles de décision et supérieures à celles d'autres modèles de décision ouverts évalués selon la même méthodologie », et les métriques utilisées étaient l'exactitude, l'erreur de calibration, le rappel de sécurité, les taux de faux positifs et la constance de l'équité, l'ordre des options étant varié et des tests statistiques appariés étant appliqués.

C'est une description méthodologique sérieuse, mais sans aucun résultat publié. Cela signifie que toute affirmation de performance concernant Microsoft-Decision-1 aujourd'hui est rapportée par le fournisseur et non reproduite, et la position honnête pour quiconque l'évalue est que la calibration — la seule propriété qui rend une probabilité réellement utile — n'est pas vérifiée en dehors de Microsoft. L'entreprise indique bel et bien où, selon elle, le modèle est le plus fort et le plus faible, ce qui est plus utile qu'un score mis en avant : le plus fort en raisonnement, application de règles et robustesse au formatage des invites ; compétitif en classification, récupération d'informations, équité, utilisation d'outils et sur la plupart des tâches multilingues ; plus faible sur les tâches nécessitant des connaissances de domaine spécialisées.

Les limites auto-déclarées méritent d'être lues avant la liste des fonctionnalités. Les scores peuvent varier selon la formulation et l'ordre des options, et une question mal formulée renvoie tout de même un score. La calibration est la plus fiable sur les types de tâches familiers. Il peut s'appuyer sur des connaissances obsolètes et ne fournit aucune explication. Concernant la couverture multilingue : 25 langues sont répertoriées comme prises en charge, dont le japonais, le coréen, l'arabe, le vietnamien, le thaï, le turc, l'hindi, le bengali, le swahili, l'hébreu, le persan et l'ukrainien, mais Microsoft indique que la couverture, la qualité et la calibration « peuvent varier selon la langue », et cite les langues non anglaises — en particulier les langues à faibles ressources — comme un domaine de sous-performance. Le modèle sous-jacent Qwen3.5-9B prend en charge plus de 200 langues ; le modèle post-entraîné n'en prend en charge qu'un quart.

Comment vous l’obtenez, et ce que cela coûte

Microsoft-Decision-1 est distribué en tant qu'API hébergée dans Microsoft Foundry, sous le portefeuille « Direct from Azure ». Les poids du modèle ne sont pas distribués — il ne s'agit pas d'une version à poids ouverts, et il n'existe aucun dépôt Hugging Face pour le télécharger. Toute application capable d'émettre des requêtes HTTPS peut s'intégrer en utilisant les points de terminaison Foundry et l'authentification Azure standard. La fiche de déploiement présente des options serverless et de point de terminaison unifié en paiement à l'usage ou en débit provisionné réservé, avec SKU standard, l'inférence par lots étant désactivée, et la déclaration d'entraînement indique que le jeu de données d'entraînement a été utilisé pour la première fois en septembre 2026, la collecte étant en cours.

Le tarif n'est pas publié sur la page du modèle. Le champ de tarification du catalogue renvoie vers la page de tarification des modèles de Microsoft plutôt que d'afficher un tarif d'entrée et de sortie, de sorte que le coût par token d'un appel à Decision-1 est quelque chose que vous devez rechercher dans l'interface de tarification Azure ou lire sur une facture. C'est un véritable manque pour quiconque cherche à modéliser le coût par décision à grande échelle, et il vaut mieux le dire clairement plutôt que de l'estimer. Deux choses méritent d'être connues lorsque vous l'évaluez : 0 % du coût correspond aux tokens de sortie, car il n'y en a aucun, et l'inférence par lots est désactivée, vous ne pouvez donc pas amortir une exécution de scoring en masse via le canal batch comme vous le feriez avec un modèle génératif.

Là où OrcaRouter s'inscrit dans tout cela, c'est de l'autre côté de l'appel. Nous n'hébergeons pas Microsoft-Decision-1, et il ne figure pas dans notre catalogue — un modèle qui renvoie des probabilités plutôt que du texte n'est pas un modèle vers lequel on achemine des complétions de chat. Ce que nous proposons, c'est la moitié du schéma qui génère réellement : les modèles qui rédigent la grille d'évaluation, élaborent les brouillons de réponses ou produisent l'appel d'outil que Decision-1 évalue ensuite. Ceux-ci sont accessibles derrière une seule clé compatible OpenAI, avec plus de 200 modèles, à prix catalogue du fournisseur répercuté avec 0 % de margeSi vous construisez une boucle d'évaluation où un modèle écrit et un autre note, l'appel de notation va à Microsoft et l'appel de génération peut aller n'importe où — y compris via le DSL de routage, qui compose plusieurs modèles en un seul appel lorsque vous voulez un panel plutôt qu'un juge unique.

Pourquoi un évaluateur est un pari différent d'un meilleur chatbot

Le schéma que Microsoft commercialise ici existe déjà en open source. Intern-Decision-4B d’InternLM, d1-3B de Liquid AI, Laya de Convai Innovations et la famille Kev de Jared Palmer renvoient tous des distributions calibrées sur les options fournies sans générer de texte, et la plupart sont des poids Apache-2.0 que vous pouvez exécuter sur votre propre matériel gratuitement. La proposition de Microsoft diffère sur trois points qui ne dépendent pas des benchmarks : c’est une API gérée avec authentification, facturation et gouvernance Azure intégrées, ce qui correspond à un parcours d’achat en entreprise auquel un téléchargement depuis Hugging Face ne répond pas ; sa base est un modèle 9B, plus grand que la plupart de ceux de ce domaine ; et elle s’accompagne d’une évaluation Responsible AI et d’une méthodologie d’évaluation documentée, qui constituent souvent la véritable exigence bloquante pour un déploiement réglementé.

Ce qu'il ne fournit pas, c'est un chiffre. Face à des concurrents ouverts qui publient des scores de Brier et une erreur de calibration — les deux chiffres qui vous indiquent si un 0,8 signifie 0,8 — Microsoft a publié une méthodologie et aucun résultat. Tant qu'il n'existe pas de tests de calibration indépendants, la manière défendable d'utiliser Microsoft-Decision-1 est celle que sa propre documentation recommande : valider sur des données représentatives de votre cas d'usage, fixer les seuils en fonction du coût de vos erreurs, toujours inclure une option d'abstention, randomiser l'ordre des options lorsque l'ordre pourrait biaiser la réponse, et garder un humain dans la boucle pour tout ce qui a des conséquences. C'est un bon conseil pour n'importe quel système de notation. C'est un conseil particulièrement bon pour un système dont la calibration n'a été mesurée par personne en dehors de l'entreprise.