Décider plutôt que générer

La plupart des systèmes qui ont ajouté un modèle ces trois dernières années n’ont pas ajouté un rédacteur. Ils ont ajouté un classifieur, un routeur, un validateur ou une étape de triage, et ils l’ont emballé dans une API en forme de chat parce que c’était la seule forme disponible. L’emballage n’est pas gratuit. Il coûte la latence de générer des tokens que personne ne lit, le prix d’un modèle généraliste, et l’ambiguïté d’une réponse en texte libre qu’il faut reparsing pour retrouver l’énumération dont le système avait besoin.

Ce que le trafic est réellement

Regardez ce qu’on demande à un assistant typique en production, et la distribution est embarrassante. Router ce ticket de support vers l’une de onze files. Décider si cette facture correspond à son bon de commande. Classer cet incident en accès, capacité ou données. Vérifier si cette réponse générée est soutenue par le passage retrouvé. Aucune de ces tâches n’a besoin d’un paragraphe. Toutes ont besoin d’une étiquette, et la plupart d’un nombre disant à quel point le système est sûr, pour que les cas incertains partent ailleurs.

Ce n’est pas une petite optimisation. Elle change trois propriétés du système d’un coup. L’espace de sortie devient fini, ce qui signifie que les modes de défaillance peuvent être énumérés et que les tests s’écrivent contre un schéma. Le coût par appel devient à peu près indépendant de la longueur de sortie, ce qui compte quand le volume se compte en millions. Et l’audit devient possible : une décision peut être enregistrée comme une décision, avec la version du modèle et la probabilité calibrée attachées, au lieu d’une transcription qu’un humain doit relire.

Ce qu’est un modèle de décision

La catégorie est assez récente pour que les définitions bougent encore, mais la forme est cohérente dans les implémentations que j’ai vues décrites. Le modèle renvoie un choix typé pris dans un ensemble déclaré, plus une distribution de probabilité sur cet ensemble. Il n’y a pas de canal en texte libre, donc rien à parser et rien à injecter dans le système en aval. Certaines implémentations contraignent la sortie par un solveur ou un compilateur, de sorte que la valeur renvoyée est structurellement valide par construction plutôt que par réessai.

Le premier exemple public de cette vague est Jev, annoncé en accès anticipé par TypeSafe en septembre 2026 [TypeSafe 2026]. L’annonce affirme qu’un modèle de décision peut être deux ordres de grandeur plus rapide et moins cher qu’un modèle de chat de pointe sur des tâches structurées, parce qu’il ne génère pas de tokens. Une seconde implémentation, Laya, vise la même forme avec des poids ouverts et de l’inférence locale [Innovations 2026]. Les deux sont intéressantes ensemble précisément parce qu’elles ne sont pas d’accord sur le déploiement : l’une gérée et calibrée centralement, l’autre auto-hébergée et ajustable.

La phrase a une forme marketing, et je la cite parce qu’elle est aussi la meilleure description courte du problème architectural [Waehner 2026]. L’intéressant n’est pas qu’un modèle plus petit sache classer. C’est qu’une fois la décision devenue un objet de première classe, le système autour peut être conçu pour elle : seuils, abstention, escalade vers un modèle généraliste, revue humaine pour la queue.

La calibration est le produit

La confiance brute d’un modèle est un nombre qui ressemble à une probabilité sans en être une. Un classifieur juste à quatre-vingt-quatorze pour cent peut se tromper systématiquement dans la région où il est le plus sûr, et les logits seuls ne permettent pas de le savoir.

Une sortie calibrée change ce qu’un opérateur peut construire. Si la probabilité veut dire ce qu’elle dit, alors un seuil est une politique : router automatiquement tout ce qui dépasse 0,9, envoyer 0,6 à 0,9 vers une file humaine, et traiter tout ce qui est sous 0,6 comme « la taxonomie ne couvre pas ce cas » plutôt que de forcer une étiquette. Cette troisième branche est celle qui manque à la plupart des systèmes, et c’est celle qui empêche l’accumulation lente de sottises confiantes.

Trois manières d'obtenir une étiquette d'un modèle, et ce que chacune coûte au système autour.

Les chiffres, et ce qu’ils prouvent

L’annonce du fournisseur rapporte de grands multiples : de l’ordre de deux cents fois plus rapide et quatre cents fois moins cher qu’un modèle de pointe sur les tâches pour lesquelles il a été construit. Un article distinct rapporte l’exécution de soixante agents pendant une journée pour des dixièmes de dollar, contre des dizaines de dollars pour la même charge via une API de pointe [Folkman 2026].

Ces chiffres sont plausibles et ne sont pas une preuve de supériorité générale. Ils sont mesurés sur des tâches structurées, c’est-à-dire exactement le régime où la comparaison est la plus facile à gagner : sorties courtes, ensemble d’étiquettes fermé, aucune trace de raisonnement requise. La lecture honnête est plus étroite et plus utile. Sur les tâches qui épousent cette forme, l’écart de coût et de latence est assez grand pour changer l’architecture — parce qu’il devient moins cher de décider à chaque requête que de regrouper les décisions la nuit. Sur les tâches qui n’épousent pas cette forme, les chiffres ne disent rien du tout.

L’architecture : une couche de décision, pas un remplacement de modèle

La version de cette idée qui survit au contact de la production n’est pas « remplacer le LLM ». C’est une couche de décision avec un contrat explicite :

Taxonomie déclarée

L'ensemble des étiquettes vit dans le contrôle de version, avec un propriétaire et un processus de changement. Un modèle de décision entraîné ou prompté sur une taxonomie que personne ne maintient dérivera d'une manière qu'aucune métrique ne capte.

Vérification de calibration

Avant qu'un seuil soit utilisé en production, la probabilité doit être vérifiée sur des données tenues à l'écart : courbes de fiabilité, pas exactitude.

Chemin d'abstention

Une issue de première classe signifiant que la taxonomie ne couvre pas l'entrée. Elle route vers un humain ou vers un modèle généraliste, et son taux est surveillé.

Budget d'escalade

Combien de cas par jour peuvent quitter le chemin rapide, et qui les traite. Sans budget, la bande médiane grossit jusqu'à rendre le chemin rapide décoratif.

Décision enregistrée

Empreinte de l'entrée, version du modèle, étiquette, probabilité et politique appliquée. C'est ce qui rend la couche auditable et chiffrable.

flowchart LR
request["Request"] --> decision["Decision model"]
decision -->|"p >= 0.9"| act["Act automatically"]
decision -->|"0.6 <= p < 0.9"| review["Human review queue"]
decision -->|"p < 0.6 or out of taxonomy"| generate["General model, generation"]
generate --> review
act --> record["Decision log"]
review --> record

Les modes de défaillance qu’introduit le chemin rapide

L’économie s’améliore tellement que la tentation est de tout router. C’est là que vivent les modes de défaillance, et ils sont ennuyeux de la manière dont les pannes de production le sont souvent.

Dérive de taxonomie. L’ensemble d’étiquettes a été écrit pour la distribution d’entrées d’il y a six mois. De nouveaux produits, de nouveaux schémas d’abus et de nouveaux segments de clientèle créent des entrées que la taxonomie ne peut pas exprimer, et un modèle de décision sans chemin d’abstention les étiquettera quand même. Le symptôme n’est pas un taux d’erreur ; c’est un tas grandissant de mauvais routages confiants que personne ne remarque avant qu’un client escalade.

Dette de qualité des étiquettes. Le signal supervisé ne vaut que ce que valent les personnes qui l’ont produit. Si les étiquettes d’entraînement viennent d’une grille sous-spécifiée, le modèle reproduira l’ambiguïté avec plus de cohérence et moins d’honnêteté.

Dégradation silencieuse. Un modèle généraliste qui répond moins bien se voit dans les transcriptions. Un modèle de décision qui dérive produit des étiquettes plausibles et une distribution qui se dégrade lentement, que l’on ne voit qu’en traçant la confusion dans le temps. Rien dans l’interface ne vous le dit.

La bande médiane devient tout le système. Si le seuil d’abstention est mal réglé, ou si la capacité de revue est inférieure au volume ambigu, le chemin rapide devient une file et l’économie s’évapore. Le budget d’escalade est un plan de capacité, pas une valeur de configuration.

Ce que je testerais avant d’adopter

Le test n’est pas un benchmark. C’est un petit harnais sur votre propre trafic, exécuté pendant deux semaines :

Coût par décision

Pas le coût par token. Inclure les réessais, la revue et le temps d'ingénierie que l'abstraction économise ou coûte.

Queue de latence

La médiane s'améliore trivialement. Regarder le p99 face au budget côté utilisateur, parce qu'une couche de décision se place devant tout.

Taux d'abstention

S'il est nul, le seuil ment. S'il est énorme, la taxonomie ne correspond pas à la charge de travail.

Calibration sur données tenues à l'écart

Courbe de fiabilité par étiquette, pas un chiffre d'exactitude unique.

Accord avec les humains

Sur un échantillon de cas revus, y compris ceux où le modèle était sûr.

Où cela laisse le modèle de chat

Rien dans l’argument ne dit que le modèle généraliste disparaît. Il dit que le modèle généraliste cesse d’être le défaut. La génération reste le bon outil pour l’explication, le résumé, la traduction, le code et tout ce dont l’espace de sortie est réellement ouvert. Ce qui change est l’ordre des opérations : décider d’abord, générer seulement après que la décision a dit que la génération était nécessaire, et laisser un humain propriétaire de la bande intermédiaire.

C’est une thèse moins excitante que les benchmarks, et c’est celle qui survit à un audit. La couche de décision est là où atterrissent le coût, la latence et la redevabilité. Un système qui sait lesquels de ses appels de modèle sont des décisions, et les traite comme des décisions, est moins cher, plus rapide et — la partie qui compte — explicable à quelqu’un qui n’était pas là quand il a été construit.