Hugging Face propose une interface commune pour les modèles de décision : Transformers ajoute DecisionPipeline et un point d'accès /v1/systemone, llama.cpp sert la même API, et trois primitives (choice, score, noul) renvoient des probabilités ; le billet ne rapporte aucun benchmark de précision, de calibration ou de latence, et ses chiffres d'exemple ne sont pas tout à fait cohérents

Le 10 novembre 2026, Hugging Face a publié « Decision Models in Hugging Face », un long billet signé Aritra Roy Gosthipaty, Lysandre, Pedro Cuenca et Tom Aarsen. Il décrit une interface commune pour un type de modèle qui n'écrit pas de texte. Un modèle de décision lit un état, par exemple un message de client, ainsi qu'un ensemble de questions typées avec des réponses autorisées, et renvoie des décisions structurées accompagnées de probabilités. Le billet dit que le modèle attribue des probabilités à des réponses que l'application comprend déjà, au lieu de générer des jetons un par un. L'interface est écrite ainsi : « State + Questions + Allowed Answers → Decisions + Probabilities ». Le billet explique que TypeSafe AI a lancé l'idée sous le nom de Jev, décrit comme un « modèle System One », et que la communauté s'est ensuite accordée sur « modèle de décision », terme qui décrit le rôle du modèle et non une théorie de la pensée.

L'exemple de départ est un message d'assistance : « J'ai été débité deux fois pour mon abonnement. J'ai besoin d'un remboursement aujourd'hui. » Une application veut en tirer trois choses : quelle équipe doit le traiter, quelle est l'urgence et si le client demande un remboursement. Le billet montre d'abord un modèle de langage qui écrit du JSON avec ces réponses, puis défend l'autre voie. Il liste trois problèmes quand on demande une sortie structurée à un modèle de langage. Le modèle n'est pas garanti de suivre le schéma demandé : il peut renvoyer du JSON invalide, des clés inattendues ou une réponse hors des choix autorisés. Les bibliothèques de décodage contraint comme Outlines et XGrammar imposent une grammaire, mais ajoutent leur propre travail. Et générer toute une réponse est du travail inutile quand l'application doit seulement choisir entre des réponses fixes. Le billet ne donne aucune comparaison mesurée de vitesse, de coût ou de précision à l'appui de ces points ; ce sont des arguments, pas des résultats.

Une question appartient à l'un de trois types, appelés primitives. Une question « choice » sélectionne une réponse parmi plusieurs et renvoie une probabilité pour chacune. Une question « score » évalue quelque chose sur une échelle ordonnée et renvoie l'espérance de l'indice de niveau. Un troisième type, appelé « noul » d'après la loi de Bernoulli, répond à une question oui/non par la probabilité que l'énoncé soit vrai. Pour les questions de choix et de score, le résultat porte aussi un champ de confiance. Pour un choix à K options, la confiance est la plus grande probabilité moins 1/K, divisée par 1 moins 1/K : une distribution uniforme donne 0 et une distribution entièrement concentrée donne 1. Dans l'exemple du billet, la question du département renvoie « billing » avec une probabilité de 0,998 et une confiance de 0,997. Le score d'urgence est de 1,705 avec une confiance de 0,558, ce que le billet explique comme une espérance sur la distribution et non un niveau à mi-chemin entre moyen et élevé.

Le billet compare les modèles de décision à deux approches plus anciennes. Un classifieur traditionnel a ses classes de sortie fixées dans sa tête de classification ; ajouter un quatrième département comme le service juridique peut exiger de nouvelles données et un réentraînement. La classification zéro-shot fournit les étiquettes à l'inférence, et le billet montre un modèle renvoyant des scores pour facturation, support technique, ventes et, après modification, juridique. Le billet dit que l'avantage des modèles de décision n'est pas d'avoir inventé les étiquettes à l'exécution ni les probabilités. C'est de les réunir dans une seule interface avec plusieurs questions typées sur le même état, plus un score ordonné et des décisions oui/non natifs. Dans le tableau du billet, la classification donne des probabilités sur les choix mais ne permet pas de définir des étiquettes à l'inférence, et seuls les modèles de décision ont plusieurs questions typées.

Ce qui change l'outillage, c'est la prise en charge dans la pile Hugging Face. Transformers dispose désormais d'un DecisionPipeline, d'une classe AutoModelForDecision et d'une classe DecisionConfig. Lancer « transformers serve » avec une version compatible de Transformers expose un point d'accès /v1/systemone, et le billet montre une requête avec trois questions renvoyant trois réponses typées, avec une utilisation de 148 jetons en entrée et 0 en sortie. llama.cpp sert les modèles de décision par la même API : l'exemple lance « llama serve -hf ggml-org/Kev-4B-GGUF », dont le port par défaut est 9931. Le billet ajoute que l'interface fonctionne aussi avec des modèles de langage autorégressifs compatibles. Transformers construit les invites de décision, lit les logits des étiquettes de réponse en une seule passe avant par lot et applique un softmax sans générer de texte : on peut donc essayer l'interface sans entraîner de nouveau modèle.

Pour la découverte et l'entraînement, le Hub a une nouvelle étiquette « decision-model ». Le billet dit que les modèles de décision n'ont pas à partager un même squelette : certains reposent sur des encodeurs comme ModernBERT, d'autres sur de plus grands modèles de langage génératifs. Pour l'entraînement, on peut affiner les modèles de décision avec l'API Trainer. Le billet donne un exemple volontairement petit qui affine autotrust/JEV-9B sur six messages d'assistance pendant 30 étapes avec un taux d'apprentissage de 1e-3, en utilisant une simple entropie croisée sur les options pour une question de choix. Il précise que la prise en charge native de l'entraînement dans TRL arrive et que la demande de tirage associée, huggingface/trl#8040, était encore ouverte au moment de la rédaction. Il renvoie aussi à une recette Unsloth qui affine des modèles comme Qwen avec LoRA et une tête de score de décision.

Le billet a des limites que le lecteur doit garder en tête. Son texte ne rapporte aucun benchmark de précision, de calibration ou de latence pour un modèle de décision nommé : des « décisions fiables et calibrées » sont donc un objectif énoncé, pas un constat. Ce compte rendu n'a pas ouvert les images ni les pages liées depuis le billet. Ses chiffres d'exemple ne sont pas tout à fait cohérents : un tableau montre des probabilités d'urgence de 0,10, 0,26 et 0,72, dont la somme vaut 1,08, si bien que ce tableau n'est pas une distribution de probabilité valide, alors que la sortie imprimée donne 0,0149, 0,2648 et 0,7203. Une phrase évoque une probabilité gagnante de 0,80 avant de calculer avec 0,99 ; avec trois options, la formule donne 0,70 pour 0,80 et 0,985 pour 0,99, et le billet imprime 0,98. Deux valeurs imprimées se recalculent à partir des probabilités imprimées : la confiance du choice, (0,99827 − 1/3) / (1 − 1/3) ≈ 0,9974, et l'espérance du score, 0 × 0,0149 + 1 × 0,2648 + 2 × 0,7203 ≈ 1,705 ; les deux correspondent à la sortie imprimée. Le billet ne donne aucune formule pour la confiance du score : le 0,558 cité plus haut est la valeur qu'il rapporte, et ce compte rendu ne l'a pas vérifiée. Le lecteur devrait traiter les chiffres du tableau et du texte comme des illustrations. Les modèles nommés, autotrust/GEV-26B-Decide, ggml-org/Kev-4B-GGUF et autotrust/JEV-9B, n'ont pas été testés pour ce compte rendu, et le billet ne donne ni licences ni caractéristiques au-delà des noms.

Pour une équipe qui oriente des tickets, note des risques ou filtre des contenus aujourd'hui avec un modèle de langage qui écrit du JSON, la question pratique est étroite. Un modèle qui renvoie des probabilités pour des réponses fixes convient-il à la décision, et existe-t-il un point de contrôle assez bon pour votre langue et votre domaine ? Le billet offre une API commune, un moyen de l'essayer sur un modèle de langage ordinaire et une petite recette d'entraînement. Il n'apporte pas de preuve qu'un modèle de décision bat l'approche actuelle. Cette comparaison doit être faite sur les données de l'équipe.