Microsoft-Decision-1 vs Kev : acheter un score, ou posséder la recette qui en produit un

Jared Palmer a placé un reçu à côté de son modèle. La famille Kev — Kev-0.8B, Kev-4B et Kev-9B, construits sur des checkpoints de base à poids ouverts gelés avec un adaptateur LoRA de rang 16 et une petite tête de pointage — est sortie le 24 septembre 2026, avec sa recette d'entraînement, ses décomptes de données étape par étape et ses chiffres d'évaluation tous publiés, et le constat honnête pour quiconque la compare à Microsoft-Decision-1 est que Kev vous en dit bien plus sur la façon de se reproduire lui-même. Le scorer de Microsoft est passé en disponibilité générale sur Microsoft Foundry le 8 octobre 2026 : une base Qwen3.5-9B post-entraînée par Microsoft, un contexte de 32 768 tokens, texte uniquement, des poids non distribués, une méthodologie d'évaluation publiée et aucun résultat publié. Les deux prennent un état et un ensemble de questions typées et renvoient une distribution calibrée au lieu de texte généré. L'un est un service, l'autre est une méthode que vous pouvez exécuter dans un notebook ce soir.

La raison pour laquelle cette distinction, plutôt que la capacité, tranche cette confrontation : Kev-4B rapporte un ECE de 0,017 sur son test verrouillé hors domaine, tandis que Microsoft-Decision-1 ne rapporte rien ; l’argument de calibration qui départage habituellement une comparaison entre scoreurs n’a donc qu’un seul camp qui expose sa position.

Ce que Kev publie réellement

La fiche de Kev-4B est d’une précision inhabituelle, et cette précision est justement l’essentiel. Le réseau de base est Qwen3.5-4B-Base, figé à une révision nommée, avec 24 couches d’attention linéaire Gated DeltaNet et 8 couches d’attention complète, avec une taille cachée de 2 560. Par-dessus se trouvent un adaptateur LoRA de rang 16 — 33,8 millions de paramètres entraînables, appliqué aux projections d’attention, de MLP et de DeltaNet — et une tête de pointeur qui note le token de fermeture de chaque option par rapport au token final de la question et applique un softmax. Une température, T = 2,41, est stockée dans le fichier de la tête et appliquée au chargement, et la fiche donne la valeur ajustée ainsi que le hachage du fichier. L’entraînement s’est déroulé par étapes, avec des nombres d’enregistrements publiés : une recette de base de 12 576 enregistrements, 1 425 pour les dates et les preuves manquantes, 5 219 récits de plaintes réelles du CFPB, 6 000 enregistrements de compétences et 5 320 enregistrements d’outils de développement, les étapes ultérieures rejouant les précédentes. La fiche indique aussi ce qui n’a pas été utilisé : « Aucune sortie de Jev (le modèle de décision hébergé de TypeSafe) n’a été utilisée. »

Le tableau de benchmark figure sur la même page, et il est accompagné des cas d’échec, ce qui est plus rare que les réussites. Test hors domaine verrouillé de Transfer-v4 : exactitude 0,838, Brier 0,224, ECE 0,017. Breadth-v1 sur 14 jeux de données mis de côté et 3 089 questions : exactitude 0,690, ECE 0,029. Test Hard-v1 : 0,803. Test Documents-v1 : 0,903. MMLU-Pro avec dix options : 0,565. Arithmétique des dates : 0,65, désignée par l’auteur comme le domaine le plus faible, avec un drapeau de préprocesseur proposé comme correctif partiel et une note explicite indiquant qu’elle n’a pas été remesurée. La section sur les limites ajoute que la calibration repose sur une température unique en distribution, de sorte que la couverture se dégrade hors domaine, que l’ordre des options peut faire basculer une réponse et que les longueurs au-delà de 8 192 jetons sont servies mais non validées. Les chiffres de service sont également publiés : 18,1 ms pour six questions sur un état court sur un H100, 12,9 ms en cache, 14,3 Go de mémoire GPU résidente.

Ce que Microsoft publie à la place

Microsoft-Decision-1 couvre en grande partie les mêmes aspects avec une posture différente. Il évalue les questions de type oui/non, à choix multiples, de notation, de classification et à grille d'évaluation, prend en charge des options d'abstention explicites telles que « impossible à déterminer », renvoie des probabilités au format JSON et s'exécute en un seul appel sur jusqu'à 32K jetons — soit quatre fois le contexte que Kev valide. Il est distribué sous forme d'API hébergée dans Microsoft Foundry au sein du portefeuille Direct from Azure, avec un déploiement sans serveur et à point de terminaison unifié, une référence SKU standard, l'authentification Azure et un chemin de facturation unifié. L'inférence par lots est désactivée, et il n'existe ni téléchargement de poids ni possibilité de réglage fin.

La section d'évaluation décrit des benchmarks de décision publics et communautaires ainsi que des ensembles internes mis de côté, des métriques incluant la précision et l'erreur de calibration, la variation de l'ordre des options, des tests statistiques appariés, et une affirmation selon laquelle le modèle « est au niveau des principaux modèles de décision et devant les autres modèles de décision ouverts évalués avec la même méthodologie ». Il n'y a pas de tableau. La fiche du modèle nomme honnêtement ses propres limites — les scores changent selon la formulation et l'ordre des options, la calibration est la plus forte sur les types de tâches familiers, aucune explication n'est produite, et la couverture des langues autres que l'anglais est la plus faible — mais une liste de limites n'est pas une mesure de calibration. Quiconque fixe un seuil d'acceptation automatique de 0,9 sur Microsoft-Decision-1 le fait sur la foi et l'ajuste en production.

La partie de la comparaison qui coûte de l’argent

L’économie de Kev est la raison pour laquelle ce duel est vraiment serré. La recette, c’est une base gelée plus un adaptateur de 33,8 M, ce qui signifie que le modèle marginal que vous entraînez coûte en calcul l’équivalent d’un adaptateur, et non d’un modèle de fondation. Vous pouvez garder la base en mémoire une fois pour toutes et charger plusieurs adaptateurs — un par domaine de décision —, une forme de déploiement que l’API hébergée de Microsoft ne peut pas du tout exprimer. Si vos règles de routage diffèrent de celles d’un juge générique, Kev vous permet d’entraîner la différence ; Microsoft-Decision-1 vous permet d’écrire un meilleur prompt et d’espérer.

Face à cela, l’API hébergée n’implique aucune surface opérationnelle. Il n’y a aucun adaptateur à surveiller, aucune pile de service à garder en chauffe, aucun écart de contexte entre validation et service à analyser, et aucun risque qu’une température ajustée sur un jeu de données se comporte différemment sur le vôtre. Pour une équipe dont le volume de décisions est modeste, le service est l’artefact le moins coûteux en heures d’ingénierie, même si les jetons coûtent de l’argent ; pour une équipe qui évalue des millions d’éléments par jour, l’adaptateur auto-hébergé l’emporte sur le coût unitaire dès que le GPU est amorti.

Il existe une troisième voie qui n'utilise aucun des deux modèles là où il est le plus faible, et c'est là que se situe OrcaRouter. Nous n'hébergeons ni Microsoft-Decision-1 ni Kev — un scorer qui renvoie des probabilités n'est pas une cible de chat-completions et aucun des deux modèles ne figure dans notre catalogue. La moitié générative d'un pipeline de décision, voilà ce que nous portons : le modèle qui rédige la réponse candidate, écrit le barème, ou émet l'appel d'outil qui sera noté. Tout cela se trouve derrière une seule clé compatible OpenAI, sur laquelle figurent plus de 200 modèles au prix catalogue du fournisseur, répercuté avec 0 % de marge, de sorte qu'un changement de prix d'un fournisseur est effectif de notre côté le jour même. Si vous construisez une boucle de notation ou de triage, l'appel de rédaction est routable et l'appel de notation ne l'est pas, et garder cette frontière claire est ce qui empêche un pipeline de notation de devenir discrètement un pipeline de chat.

Comment décider

Choisissez Kev lorsque vous avez besoin de chiffres avant de livrer, lorsque vous voulez affiner sur votre décision, lorsque vous voulez exécuter l'évaluation à l'intérieur de votre propre périmètre à coût marginal nul, ou lorsque vous voulez que plusieurs domaines de décision partagent un même modèle de base résident. Ses chiffres d'ECE publiés restent les mesures de l'auteur lui-même sur son propre banc d'essai — considérez-les comme une auto-évaluation crédible, et non comme un résultat audité par un tiers — mais ils constituent au moins une échelle que vous pouvez tenter de reproduire, et la recette est juste là pour les reproduire.

Choisissez Microsoft-Decision-1 lorsque le critère décisif est l'approvisionnement ou la longueur du contexte : un point de terminaison Azure géré avec facturation unifiée et une offre Responsible AI, 32 K d'entrée pour les documents longs, et un fournisseur à qui s'adresser en cas d'escalade. L'absence de tableau de référence n'est pas un scandale — de nombreux modèles hébergés sont lancés sans en avoir un — mais cela implique bel et bien que la première courbe de calibration de ce modèle sera tracée par ses utilisateurs, et vous devriez prévoir d'en faire partie, sur vos propres données étiquetées, avant de lui appliquer un seuil de production.