Les petits modèles apprennent à répondre sans écrire : les modèles de décision arrivent en local

La promesse est étroite et précise : un modèle qui n'écrit pas. D'après la documentation de Liquid AI, publiée le 29 septembre, d1 examine un état et renvoie des probabilités sur un ensemble fixe de résultats. L'exemple fourni par l'entreprise envoie une réclamation client et récupère un seul nombre, 0.999, pour la question « Is this message a complaint? »

Liquid appelle ce format un modèle de décision. Trois types de questions sont pris en charge, et la documentation les décrit simplement. Une question « noul » est une question oui/non qui renvoie une probabilité entre 0 et 1. Une question « choice » renvoie une distribution sur des options nommées. Une question « score » renvoie une position pondérée par les probabilités sur une grille ordonnée. La réponse de l'API contient un champ output_tokens toujours égal à zéro.

Pourquoi les petits modèles intéressent soudain

Liquid n'est pas seul sur ce créneau. L'analyse technique publiée le 29 septembre par Sebastian Raschka sur l'histoire de la classification de texte présente le récent modèle Jev d'abord comme un classifieur, ensuite comme un phénomène culturel. Son raisonnement : Jev n'est ni meilleur ni moins cher qu'un classifieur conçu pour une tâche précise, mais il est bien plus général que ces modèles spécialisés, tout en restant beaucoup plus rapide et moins cher qu'un LLM de pointe.

C'est cette combinaison, une généralité intermédiaire à faible coût par appel, qui rend l'histoire embarquée crédible. Un modèle de 2B ou 9B qui renvoie une probabilité au lieu d'un paragraphe tourne sur du matériel qu'un modèle de pointe ne peut pas approcher.

Qevi-2B, mis en ligne sur Hugging Face le 29 septembre, en est la version côté image. C'est un fine-tuning complet de Qwen3-VL-2B-Instruct qui répond à des questions fermées sur des images en lisant les logits à la position où le modèle commencerait à répondre, et non en générant du texte. La fiche du modèle est directe sur le compromis : « It is not a chat model. Ask it 'is there a ladder in this image?' and it returns P(Yes) = 0.97, not a sentence. »

La fiche annonce une exactitude de 0.977 en domaine contre 0.855 pour le modèle de base, et de 0.889 sur des domaines tenus à l'écart contre 0.745. L'erreur de calibration attendue sur ces données passe de 0.160 à 0.054. Un avertissement s'adresse aussi à ceux qui seraient tentés d'empiler un temperature scaling par-dessus : à T = 2.45, l'ECE hors domaine remonte à 0.160 et efface tout le gain.

La vitesse est l'autre moitié de la promesse. Qevi-2B annonce jusqu'à environ 21 fois plus rapide lorsqu'on pose plusieurs questions sur une même image, parce que les trois questions d'exemple partagent un seul encodage et sont séparées par un masque d'attention bloc-diagonal. La fiche précise que les réponses sont identiques à celles obtenues en posant les questions séparément, vérifié bit à bit.

« The biggest risk factor that we're seeing is in legitimate AI being used by developers, but then doing things that should not be done », a déclaré Omer Singer, cofondateur et CTO de Glow Security, dans un entretien avec The Register.

Le revers : des agents qui fuient en rendant service

Cette citation n'a pas grand-chose à voir avec l'exactitude de classification, et tout à voir avec le déploiement. The Register a rapporté le 29 septembre que des chercheurs de Glow Security avaient trouvé plus de 13 000 captures d'écran sensibles de projets logiciels d'entreprise, issues de 343 sociétés, publiées sur des dépôts GitHub publics par des agents IA. Ils appellent cela PixelLeak.

Le mécanisme est banal. GitHub n'a pas d'API pour téléverser des images dans des pull requests, alors les agents à qui l'on demande de montrer des captures d'interface avant/après les déposent dans un dépôt public. Environ un tiers des expositions venaient de développeurs utilisant gitshot, un outil de capture open source dont le propre avis de confidentialité prévient que les images téléversées sont publiques par défaut.

Rien de tout cela n'est causé par les petits modèles. Mais c'est l'environnement dans lequel on les promeut : assez bon marché pour tourner en permanence, intégrés aux outils de développement, agissant sans humain dans la boucle. Un classifieur qui tourne sur un portable resserre cette boucle.

Du raisonnement, mais juste un peu

Jeeves de PostHog, publié sur GitHub le 29 septembre, tente de corriger le problème d'exactitude des modèles de type Jev sans abandonner le format. C'est un classifieur de style Jev de 9B construit sur Qwen3.5-9B avec LoRA et une tête pointeur, entraîné à raisonner avant de décider, avec un drafter par diffusion par blocs de 4.

Les chiffres du dépôt le comparent à Kev-9B et à Jev sur des données qu'il n'a jamais vues : 0.889 contre 0.822 et 0.857. Sur les paliers publics de JevBench, il annonce 0.935 contre 0.866 pour Jev. Le coût, c'est la latence. Sans réflexion, une requête prend environ 0.3 seconde ; avec réflexion, une médiane de 3.3 secondes sur un seul H100 en précision FP8. Le dépôt note que tronquer la chaîne raccourcit ce délai.

Le tableau de Jeeves contredit aussi l'idée simple selon laquelle le raisonnement aide toujours. Sur MMLU-Pro, il obtient 0.739 contre 0.840 pour Jev, et sur MMLU 0.793 contre 0.900. Les auteurs ne gomment pas ces écarts par une moyenne : ils les publient côte à côte.

Le blog développeurs de Microsoft, dans un billet du 29 septembre sur l'Agent Experience, en donne la version générale. Les scores de benchmark orientent l'adoption, l'adoption pousse à optimiser pour le benchmark, et le score cesse de dire quoi que ce soit sur votre propre base de code. « A model that's excellent at Django might be mediocre at your internal framework that superficially resembles Django but works differently in critical ways », écrit le billet. La même logique vaut pour un modèle de décision testé sur des paliers publics puis installé dans votre file de tickets.

L'embarqué est le point où ces fils se rejoignent. Qevi-2B annonce 21 GB de poids en bf16, et Jeeves indique qu'un Mac Apple Silicon a besoin de 48 GB ou plus pour les caches par défaut, même si le FP8 réduit les poids à 11.5 GB et que des réglages de cache plus modestes tiennent sur une machine de 48 GB. Ce n'est pas un téléphone. C'est un portable, ce qui reste une cible de déploiement différente d'un centre de données, et c'est là que l'étiquette « petit modèle » fait un vrai travail.

Ce qu'aucune de ces publications ne tranche, c'est de savoir si le cadrage par la classification survit au contact de questions de production désordonnées. Un 0.97 se seuille facilement. Une question « score » dont la calibration n'est pas mesurée, ce que la fiche de Qevi-2B dit de son propre type « score », non.