Le 9 octobre, une équipe de Stanford a publié Next-Concept Modeling (NCM). C’est un papier sur la vitesse, pas sur la sécurité, et rien de ce qu’il décrit ne roule dans un produit que vous utilisez aujourd’hui. Ça vaut quand même dix minutes de votre temps : il montre où l’architecture des LLM pourrait aller, et plusieurs de vos contrôles en production dépendent, sans que personne l’ait écrit nulle part, de l’architecture qu’il laisse derrière.
Ce que le papier propose
Les LLM d’aujourd’hui sont autorégressifs : ils écrivent un token à la fois, de gauche à droite, et chaque token dépend des précédents. Les modèles par diffusion, la principale piste de recherche concurrente, partent d’un brouillon de pleine longueur et le raffinent partout en même temps, sur plusieurs dizaines d’étapes.
NCM ne fait ni l’un ni l’autre. Il compresse le texte en une courte hiérarchie de codes, du plus grossier au plus fin. Le premier niveau, quelques codes à peine, porte l’idée générale. Chaque niveau suivant ajoute du détail, jusqu’à un code par token. Le modèle génère un niveau à la fois, et tous les codes d’un même niveau en parallèle. Un décodeur distinct retransforme ensuite le dernier niveau en mots.
Les résultats, à l’échelle de la recherche :
- Vitesse. 21 fois plus rapide que le meilleur modèle par diffusion sur un benchmark, 10 fois sur du texte web, 31 fois sur du résumé d’articles de presse, à qualité comparable.
- Étapes. Un résumé en 8 passes, contre 128 pour le modèle par diffusion.
- Raisonnement. Meilleur au Sudoku que les modèles autorégressifs et par diffusion, à tous les niveaux de difficulté, avec moins de passes.
Pas de panique : c’est de la recherche
Les expériences principales roulent sur des modèles d’environ 100 millions de paramètres, et l’étude de mise à l’échelle s’arrête à 725 millions. Les LLM en production sont des centaines, voire des milliers de fois plus gros. Les auteurs qualifient eux-mêmes leurs résultats de mise à l’échelle de préliminaires, et en traduction, la méthode reste derrière les modèles autorégressifs à moins de lui donner plus de calcul. Aucun code n’est publié.
Rien ne change donc ce trimestre. Ce qui change, c’est la question à poser à vos fournisseurs à partir de maintenant, parce que la pression derrière ces travaux est bien réelle : l’inférence devient la principale charge de calcul, et tous les labos cherchent à générer du texte sans payer une passe par token.
Trois contrôles bâtis pour l’écriture de gauche à droite
Les guardrails sur le streaming
Bien des guardrails lisent la réponse pendant qu’elle s’affiche et la coupent dès qu’elle dérape. Ça marche parce qu’un token affiché est final. Avec un modèle qui va du grossier au fin, il n’y a aucun texte lisible avant le dernier niveau, et la réponse arrive d’un bloc. Le filtre qui comptait couper tôt devient un filtre sur la réponse complète. Ce n’est pas moins sûr en soi, mais la latence, le coût et la façon dont ça échoue changent, et les tests de votre fournisseur ont été faits sur une autre architecture.
Le constrained decoding pour les tool calls
Un agent appelle un outil en produisant une sortie structurée, souvent du JSON. Beaucoup de plateformes garantissent cette structure par constrained decoding : à chaque étape, les tokens qui briseraient le schéma sont interdits. Cette technique repose sur la prédiction du prochain token. Quand le texte sort d’un décodeur, la garantie doit venir d’ailleurs, par exemple d’une validation après coup avec une nouvelle tentative. Si votre dossier de sécurité dit « le modèle ne peut pas produire un tool call invalide », vérifiez quel mécanisme le rend vrai.
Les logprobs et le watermarking
Certains détecteurs d’hallucinations lisent la probabilité de chaque token (les logprobs). Les techniques connues de watermarking du texte généré par IA, elles, biaisent le choix de chaque token selon les tokens précédents. Les deux supposent un modèle qui choisit ses tokens un après l’autre. Ni l’un ni l’autre ne se transpose tel quel à un modèle dont les mots sortent d’un décodeur. Si vous comptez sur le watermark d’un fournisseur pour prouver la provenance d’un texte, ou sur les logprobs pour mesurer la confiance, demandez-lui si ça tient encore le jour où il change de modèle.
Un nouveau type d’erreur : la bonne idée, le mauvais mot
L’annexe du papier documente une catégorie d’erreurs qui mérite d’avoir un nom. Le décodeur est très précis, 99,99 % des tokens sur du texte web, mais ses rares erreurs ne tombent pas au hasard. Il échange des noms propres, décale des chiffres et brise le balisage : Melbourne devient Brisbane, une année devient la suivante.
Ce n’est pas une hallucination. Le modèle peut avoir planifié le bon contenu et sortir quand même la mauvaise ville. Dans un texte banal, c’est du bruit. Dans le résumé d’un contrat, la chronologie d’un incident ou une instruction de paiement, les noms, les dates et les montants sont exactement ce qui compte.
Le contrôle, vous devriez déjà l’avoir pour toute sortie d’IA qui déplace de l’argent ou engage l’organisation : valider les noms, les chiffres et les identifiants contre la source, avec une règle et pas avec un autre modèle, avant que quelqu’un agisse. Un modèle qui a raison la plupart du temps, ce n’est pas un contrôle.
Moins cher à générer, plus d’agents à surveiller
La conséquence la plus discrète, c’est le coût. Si générer du texte devient dix fois moins cher, l’inférence arrête de freiner le nombre d’agents qu’une équipe déploie et la fréquence à laquelle ils roulent. Le volume va grossir plus vite que votre capacité de revue. Ceux qui tiennent déjà un inventaire des agents IA et un registre des quasi-incidents vont voir la vague arriver. Les autres vont la découvrir pendant un incident.
Concrètement, cette semaine
- Ajoutez une ligne à votre inventaire IA et à votre questionnaire fournisseur : comment le modèle génère-t-il le texte (autorégressif, diffusion, autre), et est-ce que ça a changé depuis la dernière revue ?
- Repérez les contrôles qui en dépendent : guardrails sur le streaming, constrained decoding, logprobs, watermarking. Pour chacun, notez ce qui se passe si le fournisseur change d’architecture.
- Validez les faits des sorties à fort enjeu avec une règle : noms, montants, dates et identifiants, comparés à la source, peu importe le modèle.
Besoin d’un deuxième regard ?
Notre évaluation de la sécurité de l’IA générative fait le tour des contrôles autour de vos systèmes d’IA et des hypothèses sur lesquelles chacun repose, y compris celles sur le fonctionnement du modèle. Le jour où votre fournisseur change de modèle, vous savez quels contrôles retester.
Trois questions à poser à votre équipe
- Lesquels de nos guardrails arrêteraient de fonctionner, ou fonctionneraient autrement, si le modèle sortait toute sa réponse d’un coup ?
- Quand un agent fait un tool call, qu’est-ce qui en garantit la structure : le modèle, le décodeur ou un validateur qu’on contrôle ?
- Quelles sorties d’IA contiennent des noms ou des montants sur lesquels quelqu’un agit sans vérifier la source ?