Principe de fonctionnement

Le modèle LLM GLM‑5.3‑Flash, comme tout LLM, génère à chaque position une distribution de probabilité sur l’ensemble de son vocabulaire. En limitant le vocabulaire aux index numériques des options (par ex. 0, 1, 2), le premier token produit correspond directement à l’option choisie. Le prompt inclut le state, la question et la liste d’options indexées, puis se termine par la chaîne choice_index:. Le modèle ne doit donc produire qu’un seul token, dont les logits sont ensuite renormalisés pour fournir une probabilité (confiance) pour chaque option.

{
  "state": "I was charged twice for my order.",
  "question": "Which team?",
  "options": [
    {"index": 0, "name": "payments"},
    {"index": 1, "name": "complaints"},
    {"index": 2, "name": "technical"}
  ]
}
assistant choice_index:

Dans l’exemple ci‑dessus, le modèle renvoie les logits suivants : 0 → 62.1 %, 1 → 37.7 %, 2 → 0.2 %, ce qui donne payments avec une confiance de 0,39 (1 = certain, 0 = équivalent).

Mise en œuvre avec vLLM

Le déploiement s’effectue sur Privatemode via vLLM. L’appel /chat/completions utilise les paramètres continue_final_message et add_generation_prompt:false afin que le modèle poursuive le texte pré‑rempli au lieu d’initialiser une nouvelle réponse. La fonction allowed_token_ids de vLLM filtre le vocabulaire aux seuls index d’options, en assignant -inf aux autres tokens. Cependant, top_logprobs ne suffit pas : il renvoie la distribution avant filtrage, ce qui laisse les espaces ou ponctuations occuper les premières positions. La méthode logprob_token_ids résout ce problème en retournant les log‑probabilités exactes des tokens demandés.

Les identifiants de token varient selon le tokenizer du modèle ; par exemple, GLM‑5.3‑Flash possède un token unique pour le nombre 12. Au lieu d’intégrer un tokenizer local, la bibliothèque interroge le serveur avec /completions?echo=true pour récupérer la tokenisation exacte, garantissant la compatibilité avec tout modèle supporté par vLLM.

Évaluation et limites

Un benchmark construit à partir de jeux de données publics montre que GLM‑5.3‑Flash atteint une précision et une vitesse comparables à celles du modèle spécialisé Jev de TypeSafe. La différence notable réside dans la capacité du setup à traiter des images en même temps que du texte ; Jev ne supporte pas les entrées visuelles. Malgré ces performances, la méthode dépend fortement de la stabilité du mapping token‑index ; tout changement de vocabulaire du modèle requiert une mise à jour du masque. De plus, la confiance fournie provient uniquement de la distribution de logits, sans calibration supplémentaire, ce qui peut limiter l’interprétabilité dans des scénarios à risque élevé.