Principe du décodage contraint
Le modèle « system one » présenté repose sur la contrainte du vocabulaire à un ensemble fixe d’options (A‑E). En masquant tous les tokens hors de cet ensemble, le LLM ne peut générer que l’un des cinq symboles. Le choix se fait en sélectionnant le token ayant la probabilité maximale à l’étape finale du décodage. Cette approche nécessite 11 passes de génération pour produire la réponse complète, alors qu’une génération libre implique un passage par token. L’article précise que les techniques d’inférence spéculative ne sont pas prises en compte dans ce compte.
Implémentation avec Qwen3‑1.7B
Le code charge le modèle Qwen/Qwen3‑1.7B via la bibliothèque transformers, utilise torch_dtype="auto" et device_map="auto" pour exploiter le GPU disponible. La liste options = ["A","B","C","D","E"] est transformée en identifiants de token :
option_token_ids = [tokenizer.encode(opt, add_special_tokens=False)[0] for opt in options]apply_chat_template génère le texte d’entrée. Après le passage model(**model_inputs), les logits du dernier token sont filtrés avec logits[option_token_ids] et normalisés par torch.softmax. Le token avec la plus grande probabilité est affiché comme prédiction, tandis que les probabilités de chaque option sont imprimées. Un test simple avec la question « What color is the sky? » donne : prediction: B et une probabilité de 0.9988 pour l’option B, montrant que le modèle identifie correctement la réponse lorsqu’elle est évidente.Évaluation sur CommonsenseQA
Sur un sous‑échantillon de 1 221 questions du jeu de données CommonsenseQA, le modèle non finetuné atteint une exactitude de 0.5938 (725 bonnes réponses) et un macro‑F1 de 0.5844, le macro‑F1 étant la moyenne non pondérée des F1 par classe. Les scores par option varient : A (precision 0.5733, recall 0.7197), B (0.5506 / 0.7686), C (0.5372 / 0.6598), D (0.7206 / 0.3904), E (0.7519 / 0.4255). Un finetuning rapide améliore l’exactitude à 0.6241 et le macro‑F1 à 0.6234, avec des gains de précision et de rappel pour chaque classe, ce qui confirme que l’ajustement sur le même domaine augmente les performances.
Calibration et mise à l’échelle de température
L’analyse des scores de confiance révèle une sur‑confiance marquée : dans la tranche (0.90, 1.00] le modèle est correct seulement 70 % du temps, alors que dans (0.80, 0.90] la précision chute à 40 %. Cette discordance indique une mauvaise calibration. En appliquant une température T = 3.797280788421631, les distributions de probabilité sont aplaties, ce qui rapproche les scores de confiance des taux de réussite réels. Après recalibration, la tranche (0.90, 1.00] atteint une précision de 95 %, et les tranches intermédiaires affichent des écarts réduits (par ex. (0.70, 0.80] passe de 43 % à 77 %). La température a été optimisée en minimisant la divergence entre les scores de confiance et les précisions observées sur le jeu de validation. Le dépôt GitHub associé propose des scripts pour reproduire la création du jeu de données, l’évaluation, le finetuning et la calibration, permettant d’étendre la méthode à des modèles plus volumineux.
