Présentation

Hugging Face décrit les modèles de décision comme une interface où l’on fournit un state (contexte) et une série de questions avec leurs réponses possibles. Le modèle renvoie une décision accompagnée d’une distribution de probabilité. L’exemple de la prise en charge d’un ticket client (« I was charged twice for my subscription… ») montre comment le pipeline decision de autotrust/GEV-26B-Decide retourne choice: "billing" avec une confiance de 0.9974 et des probabilités détaillées : billing 0.9983, technical 0.0010, sales 0.0007.

from transformers import pipeline
decide = pipeline("decision", model="autotrust/GEV-26B-Decide")
decision = decide({
    "state": "I was charged twice for my order and want a refund.",
    "questions": {
        "department": {
            "type": "choice",
            "instructions": "Which team should handle this?",
            "criteria": {
                "billing": "Payments and refunds",
                "technical": "Bugs and technical issues",
                "sales": "Pricing and subscriptions"
            }
        }
    }
})
print(decision)

Fonctionnement technique

Le modèle génère, pour chaque question, un vecteur de logits correspondant aux réponses autorisées. Un softmax transforme ces logits en probabilités normalisées, ce qui permet d’obtenir à la fois la décision la plus probable et le degré de confiance. Cette approche évite le décodage autoregressif complet : le modèle ne produit pas de texte token par token, mais directement les scores numériques associés aux options.

Comparé à la classification traditionnelle, où la tête de classification fixe le nombre de classes, le modèle de décision accepte dynamiquement un dictionnaire de réponses. Ainsi, ajouter une nouvelle catégorie (par ex. « Legal ») ne nécessite pas de ré‑entraînement du head, seulement la transmission de la nouvelle clé dans le champ criteria.

Analyse comparée avec la classification zéro‑shot

La classification zéro‑shot, illustrée avec facebook/bart-large-mnli, convertit chaque label candidat en hypothèse NLI et renvoie des scores. Dans l’exemple fourni, les scores sont : billing 0.84668, sales 0.09621, technical 0.05710. En ajoutant le label « Legal », le score chute à 0.03319. Cette méthode partage le principe de probabilité sur des réponses explicites, mais elle reste limitée à une seule question et à un format de sortie fixe (liste de labels).

Les modèles de décision généralisent ce schéma : ils peuvent gérer plusieurs questions simultanément, chaque question pouvant être de type choice, score ou noul (probabilité d’une affirmation). Le résultat inclut donc un objet JSON structuré contenant, pour chaque question, la réponse choisie, la confiance et la distribution complète.

Limitations et perspectives

Le texte souligne trois problèmes majeurs des LLMs utilisés en génération de JSON : non‑respect du schéma, surcharge de décodage et besoin de contraintes externes (Outlines, XGrammar). Les modèles de décision atténuent ces problèmes en ne générant que des valeurs numériques, mais ils restent dépendants de la qualité du calibrage du softmax ; une confiance élevée (≈0.998) ne garantit pas l’absence d’erreur de logique. De plus, la nécessité de fournir explicitement le dictionnaire de réponses impose une étape de pré‑traitement qui peut devenir lourde dans des contextes très dynamiques.

En pratique, l’adoption de modèles de décision pourrait réduire le coût de calcul (moins de tokens générés) et simplifier l’intégration côté client, à condition que les développeurs maîtrisent la construction du state et la définition précise des criteria. Les recherches futures porteront probablement sur l’amélioration du calibrage des probabilités et sur des mécanismes de mise à jour en temps réel des réponses autorisées.