Pourquoi tant d’appels LLM sont en réalité de la classification
Une grande partie du trafic LLM en production renvoie un seul mot. Escalader ce ticket ou non. Spam ou pas spam. Lequel des six handlers traite cet événement. Pour obtenir ce mot, vous envoyez le prompt entier à un modèle généraliste, vous attendez qu’il décode une réponse token par token, et vous parsez un objet JSON dans le résultat. Vous payez le prix et la latence de la génération de texte, et ce qui revient est une décision qui tient dans un enum.
« System One model » est le nom que TypeSafe AI donne à un modèle construit pour cette seconde forme : il prend un morceau d’état plus un ensemble de questions typées, et renvoie une réponse à chacune en une seule passe, sans générer de texte. Le terme emprunte à la distinction de Daniel Kahneman entre la pensée « Système 1 », rapide et automatique, et la pensée « Système 2 », lente et délibérée. Jev, l’implémentation de TypeSafe, sert d’exemple concret ici. L’étiquette appartient au fournisseur, mais l’idée derrière est plus ancienne : si la sortie se limite à un ensemble connu de réponses, le modèle peut en choisir une plutôt que d’en écrire une. La question pour votre système, c’est si cette forme correspond à un vrai goulot d’étranglement.
Pourquoi un modèle system one peut sauter le décodage token par token
Un LLM génératif produit une sortie qu’il n’a jamais vue. Chaque token dépend de tous les tokens qui le précèdent, donc le modèle en prédit un, l’ajoute à l’entrée, et prédit le suivant. Cette dépendance, c’est pourquoi la génération est lente. Le token 40 ne peut pas commencer avant que le token 39 existe.
Un modèle de ce type supprime la dépendance en fixant l’espace de sortie avant l’appel. Vous ne lui demandez pas d’écrire une réponse. Pour chaque question, vous lui donnez un menu (choisir un de ces labels, placer ceci sur une échelle de 1 à 10, répondre oui ou non), et il note chaque option de chaque menu en une seule passe parallèle. Il n’y a rien à décoder en séquence, parce que chaque réponse possible est connue à l’avance.
C’est tout le truc, et c’est aussi la limite. Fixer la sortie est ce qui permet de sauter l’autorégression, et tout ce qui sort de cette sortie fixée disparaît : vous n’obtenez aucun texte libre, aucun raisonnement écrit à inspecter. La propre documentation de Jev indique que le modèle se débrouille mal en arithmétique, en comptage et en comparaison de dates, qui demandent un calcul en plusieurs étapes plutôt qu’un choix entre options. Si la tâche demande au modèle de produire quelque chose plutôt que de sélectionner quelque chose, utilisez un autre outil.
Ce que vous envoyez à un modèle system one et ce que vous récupérez
Chaque appel a deux parties. L’état, c’est tout ce que le modèle doit regarder : un e-mail, un ticket de support, une frame de jeu, une ligne de données applicatives. Les questions sont typées et bornées, selon les trois types ci-dessus. Pour chaque question, vous récupérez la réponse sélectionnée plus une distribution de probabilité sur les alternatives.
Construisez autour de cette distribution. « Escalader » à 0,52 et « escalader » à 0,98 portent le même label et veulent dire des choses très différentes. Le second, vous pouvez agir dessus automatiquement. Le premier appartient à un chemin plus lent et plus prudent, soit une personne, soit un appel LLM complet.
Vous pouvez obtenir un signal similaire depuis un modèle génératif en lisant les log-probabilities des tokens d’une réponse contrainte, si votre fournisseur les expose. La différence, c’est qu’un modèle system one renvoie la distribution comme réponse elle-même, pour chaque question, sans plomberie supplémentaire.
Quand utiliser un modèle system one dans un pipeline LLM
Le schéma qui marche, c’est le filtrage, pas le remplacement. Un modèle typé rapide décide si l’appel génératif coûteux doit avoir lieu du tout.
- Routage. Classez la requête avant de choisir quel modèle ou quel handler la traite, plutôt que de demander à un seul modèle généraliste de classer et de répondre dans le même appel. Un pipeline RAG peut utiliser le même filtre pour décider si une question a d’abord besoin de retrieval.
- Modération et triage. Notez le contenu pour le spam ou l’urgence avant qu’il n’atteigne une personne ou un modèle plus coûteux, pour que le chemin coûteux ne tourne que sur ce qui en a besoin.
- Garde-fous. Après génération, vérifiez la réponse contre des contraintes typées (contient-elle un motif de données précis, tombe-t-elle dans une catégorie interdite) comme une passe séparée bon marché, plutôt que de replier la vérification dans le prompt de génération.
- Boucles de contrôle temps réel. Une boucle de jeu ou un contrôleur de robot qui a besoin d’une décision à chaque frame ne peut pas attendre la génération. Un modèle à une seule passe rentre dans cette boucle. Un modèle token par token, structurellement, non.
Les choses se cassent quand vous traitez la réponse du modèle rapide comme une vérité absolue. Envoyez les réponses à faible confiance vers le chemin lent, et fixez le seuil à partir de vos propres données labellisées, pas d’un chiffre rond qui semblait bien. Une distribution plate avec un label dessus reste une supposition.
Alternatives : sortie structurée et classificateurs fine-tunés
Des équipes résolvaient ce problème avant que la catégorie n’ait un nom, de deux façons principales.
Sortie structurée sur un LLM généraliste. Les principales API de LLM peuvent contraindre la génération à un schéma JSON ou à un enum, ce qui vous donne la même garantie de réponse typée sans adopter un nouveau type de modèle. Le décodage reste autorégressif, mais quand la réponse est une seule valeur d’enum, la partie générée ne fait que quelques tokens. L’essentiel de la latence et du coût vient du traitement du prompt, et un modèle system one doit faire ça aussi. TypeSafe positionne Jev comme plus rapide et moins cher que cette approche. La part de vrai que ça a pour vos appels dépend de la longueur de votre prompt et du nombre de questions posées par appel, donc c’est un chiffre à mesurer, pas à supposer. La sortie structurée ne demande non plus aucune nouvelle infrastructure si vous appelez déjà ce fournisseur.
Un petit classificateur fine-tuné. Pour une décision stable unique, comme exactement cet appel d’escalade ou exactement ce filtre anti-spam, un classificateur entraîné sur vos propres données labellisées est en général plus rapide et moins cher que n’importe quel modèle généraliste, typé ou non. Le coût, c’est qu’il vous faut des données labellisées et une passe de réentraînement à chaque fois que la tâche dérive. L’avantage d’un modèle system one sur lui, c’est la largeur : un seul modèle répond à de nombreuses questions typées différentes sur différents types d’état, sans passe d’entraînement par décision.
Le bon choix dépend du nombre de décisions distinctes que vous avez et du trafic qu’elles reçoivent. Si vous avez une décision stable et à fort volume, utilisez un classificateur dédié. Si vous avez plusieurs décisions liées mais variées dans un pipeline, c’est le cas pour lequel la forme system one est conçue. Si vous ne faites pas des milliers de ces appels par minute, commencez par la sortie structurée sur le modèle que vous appelez déjà.
Comment repérer les appels LLM qui devraient être des décisions
Passez en revue ce que vous envoyez déjà à un LLM généraliste et marquez chaque appel dont toute la sortie utile pourrait être une valeur d’enum ou un nombre. Ce sont vos candidats. Basculez-en deux vers de la sortie structurée sur un modèle que vous utilisez déjà, une API hébergée ou un modèle local tournant sous Ollama, qui accepte un schéma JSON dans son paramètre format. Mesurez la latence et le coût par appel face à la version actuelle.
Quoi que vous mettiez à la place, continuez d’envoyer quelques pour cent du trafic filtré vers l’ancien chemin aussi, et comparez les réponses. Si la sortie structurée tient déjà votre budget de latence et s’accorde avec l’ancien chemin, arrêtez-vous là. N’évaluez un modèle system one dédié comme Jev que si ce n’est pas le cas, et utilisez cet échantillon côte à côte pour en juger.