Unsloth transforme Qwen3.5-4B en classificateur de 10 intentions sur un seul GPU T4

Un grand modèle de langage n'a pas toujours besoin de converser. Dans de nombreux produits, on attend de lui un résultat plus terre à terre : déterminer l'intention d'un client, choisir le prochain outil ou décider s'il faut laisser passer un message. Un LLM classique peut générer une explication, alors que le système n'a besoin que d'une réponse courte, par exemple « consultation du solde » accompagnée d'un score de confiance.

Machine Learning Mastery a montré comment construire un tel classificateur à partir du modèle ouvert Qwen3.5-4B. L'ensemble s'appuie sur Unsloth, une LoRA 4 bits et le jeu de données CLINC150. La démonstration s'exécute dans Google Colab sur une Tesla T4 avec 14,6 Go de mémoire vidéo et limite la tâche à dix intentions. Il ne s'agit pas d'un modèle industriel prêt à l'emploi, mais d'un point de départ clair pour un développeur qui souhaite remplacer une chaîne de prompts par un mécanisme de sélection dédié.

Le modèle choisit, il ne compose pas

Prenons le message : « Montre-moi le solde de mon compte d'épargne ». Un modèle génératif peut rédiger une consigne, demander quelle banque est concernée ou se lancer dans un raisonnement. Un classificateur doit faire autre chose : choisir l'intention balance dans un ensemble prédéfini et renvoyer un score de confiance.

Chez Unsloth, c'est FastDecisionModel qui s'en charge. Une tête spécialisée, chargée d'évaluer les options autorisées, est ajoutée au modèle de langage de base. Au lieu de générer des jetons séquentiellement, le système compare des décisions fixes. Sont pris en charge le choix d'une option unique, la réponse « oui ou non » et la notation sur une échelle ordonnée.

Ce format convient au routage des demandes, à la modération, à l'analyse de tonalité et aux scénarios d'agents. Par exemple, on peut placer devant le LLM principal un petit modèle qui décidera où diriger la requête : vers la recherche, la base de connaissances, le service de paiement ou un humain. La sortie est contrainte par un schéma, ce qui facilite sa vérification et sa transmission au composant suivant.

Comment fonctionne l'entraînement

L'auteur charge Qwen3.5-4B en mode quatre bits et branche une LoRA de rang 16. La majeure partie des paramètres d'origine reste gelée, et l'entraînement ne modifie que de compacts adaptateurs et la tête de décision. Les points de contrôle de gradient réduisent encore la consommation de mémoire.

Les données doivent elles aussi être restructurées. Chaque enregistrement comporte trois éléments : le texte de l'utilisateur, la description des décisions disponibles et la bonne option. Dans l'exemple tiré de CLINC150, 10 intentions sur 150 sont tirées au hasard — parmi elles figurent la date, l'heure, l'itinéraire, le remplacement d'un ingrédient et le démarrage d'une voiture avec une batterie externe. Seuls les exemples qui s'y rapportent sont ensuite conservés.

C'est précisément la liste d'options qui rend la tâche maîtrisable : le développeur définit à l'avance les actions autorisées au système. Mais c'est aussi là que se paie un coût. Plus il y a d'options, plus l'entrée s'allonge et plus l'entraînement devient lourd. Dix classes sur une T4 ne prouvent pas que la même configuration, sans modification, viendrait à bout des 150 catégories ou de véritables messages de clients.

Où s'arrête la démonstration

L'extrait disponible ne contient ni précision finale, ni matrice de confusion, ni comparaison avec un classificateur classique. On ne peut donc pas affirmer que Qwen3.5-4B surpasse déjà des modèles moins coûteux. La qualité de reconnaissance des requêtes hors du périmètre pris en charge n'est pas non plus montrée, alors que CLINC150 contient des exemples distincts de ce type de demandes.

En production, la seule confiance du modèle ne suffit pas. Il faut la calibrer sur un échantillon de validation, fixer un seuil de rejet et examiner les erreurs sur des intentions voisines. Si deux actions ne diffèrent que par un détail — par exemple « bloquer la carte » et « fermer la carte » —, le coût d'une mauvaise décision peut dépasser le délai induit par une demande de précision supplémentaire.

La conclusion pratique est simple : FastDecisionModel est intéressant comme moyen de transformer un LLM ouvert en routeur strictement encadré. Il vaut mieux commencer par un petit ensemble d'actions bien distinctes, une classe obligatoire « je ne sais pas » et un journal des erreurs. Ce n'est qu'ensuite qu'il convient de comparer la solution à un classificateur BERT compact, à des règles et à l'appel d'un modèle plus grand. Ce qui compte ici n'est pas l'élégance de l'architecture, mais la part de décisions correctes pour une latence et un coût acceptables.