Agents hybrides : raisonner en latent, agir en texte

Voici une vérité qui dérange à propos des agents LLM : la plupart des tokens qu'ils produisent sont du remplissage coûteux. Un agent de raisonnement qui résout un problème de maths va allègrement écrire « relisons la question » et « jusqu'ici, j'ai trouvé que... » au plein coût d'inférence, dépensant le même calcul sur des tics de langage que sur l'arithmétique réelle. Le raisonnement latent — faire la réflexion dans les états cachés du modèle plutôt qu'en texte — a toujours été la solution évidente, et un nouvel article sur les Hybrid Reasoning Agents montre qu'elle devient enfin praticable. Mais cette solution évidente a un prix que personne dans le domaine n'aime payer : on ne peut plus lire ce que le modèle pense.

J'ai passé des années à voir des équipes tenter de rendre la chaîne de pensée moins chère. Chaque approche se heurte au même mur, et il vaut la peine de comprendre pourquoi l'approche hybride est différente — et pourquoi je ne la déploierais toujours pas partout où une défaillance silencieuse ne serait pas acceptable.

Pourquoi la chaîne de pensée textuelle gaspille des tokens

La chaîne de pensée a été une découverte vraiment géniale. Laisser le modèle écrire ses étapes intermédiaires fait grimper la précision de façon spectaculaire sur les maths, la logique et les questions multi-sauts. Le problème, c'est que le langage est un format de sérialisation épouvantable pour le calcul. Les mots sont avec perte, redondants et — surtout pour votre facture d'inférence — séquentiels.

Pensez à ce qui se passe quand un modèle « reformule le problème » avant de le résoudre. Ce sont quelques centaines de tokens générés un par un, chacun exigeant une passe avant complète, alors que le contenu informationnel est presque nul — l'énoncé est déjà dans le contexte. Les modèles de raisonnement modernes en sont pleins. Quiconque a regardé une trace de raisonnement d'un modèle de dernière génération a vu des paragraphes d'auto-réassurance, de reformulation et de précautions oratoires qu'un ingénieur humain qualifierait de bruit. Sur les tâches agentiques avec appels d'outils, c'est pire : le modèle raconte ce qu'il s'apprête à faire, le fait, puis raconte ce qu'il vient de faire.

L'économie s'accumule à l'échelle d'un agent. Un agent qui effectue dix appels d'outils avec un préambule de raisonnement verbeux avant chacun peut consacrer 80 % de son budget de tokens à la narration. Si vous payez au token — et c'est le cas — c'est de l'argent réel. C'est aussi de la latence, ce qui compte énormément pour des agents dont des humains attendent la réponse. C'est la même pression qui pousse vers des offres d'inférence moins chères et plus rapides : le goulot d'étranglement n'est pas l'intelligence, c'est le coût de l'exprimer en mots.

Tentatives échouées : troncature, distillation et raisonnement latent pur

Le domaine a attaqué le problème sous trois angles, et chacun a échoué d'une manière instructive.

Tentative 1 : générer simplement moins de tokens

Budget forcing, pénalités de longueur, fine-tunings pour un raisonnement concis — l'approche naïve consiste à faire moins réfléchir le modèle en texte. Ça marche jusqu'à un certain point, puis la précision s'effondre. La trace verbeuse n'est pas du gaspillage pur ; une partie de cette redondance apparente porte la charge du calcul. Une compression aveugle jette le calcul avec le remplissage, et on ne peut pas distinguer l'un de l'autre depuis l'extérieur.

Tentative 2 : raisonnement latent pur

L'idée plus élégante : ne produire aucun token de réflexion. On réinjecte les embeddings de sortie du modèle comme entrées — un « vecteur de pensée » continu au lieu de mots discrets — et on le laisse raisonner en interne sur de nombreuses étapes avant d'émettre une réponse. Des travaux comme COCONUT ont montré que cela peut égaler ou dépasser la chaîne de pensée textuelle sur certaines tâches, avec une fraction des passes avant. Mais le raisonnement latent pur souffre de deux problèmes fatals pour les agents. D'abord, le monde extérieur parle texte : les API d'outils prennent des arguments chaîne, les moteurs de recherche prennent des requêtes, les utilisateurs veulent des réponses en prose. Un modèle qui ne pense qu'en vecteurs doit quand même tout traduire à la frontière, et c'est là que se cachent les erreurs. Ensuite — et c'est celui dont on discute le plus — la réflexion devient une boîte noire. On perd entièrement la trace de raisonnement, qui est pour l'instant notre seule fenêtre à peu près correcte sur les raisons pour lesquelles un modèle a fait ce qu'il a fait.

Tentative 3 : tokens de pause et calcul de remplissage

Une piste plus discrète a tenté d'insérer des tokens de « pause » dénués de sens pour donner au modèle du calcul supplémentaire sans contenu supplémentaire. Les résultats étaient mitigés au mieux, et ça n'est jamais sorti du laboratoire. Il s'avère que c'est le contenu des tokens intermédiaires qui compte pour orienter le calcul, pas seulement leur existence.

Ce qui fonctionne vraiment : les agents de raisonnement hybrides

L'article HybridAgent adopte la position pragmatique que j'aurais aimé voir adoptée plus souvent : arrêter de choisir entre raisonnement latent et textuel, et laisser le modèle basculer entre les deux en cours de génération. Raisonner en latent pour le calcul interne ; passer au texte quand il faut appeler un outil, lire sa sortie ou s'expliquer à un humain.

L'architecture repose sur trois éléments qui méritent qu'on s'y attarde. Un module léger, HybridLink, gère les transitions : il convertit l'état caché final d'un segment latent en quelque chose que le modèle en mode texte peut poursuivre, et inversement. Une mémoire de travail continue conserve tout le contexte hybride d'un tour à l'autre, de sorte que les pensées latentes du premier tour restent disponibles au cinquième au lieu d'être réduites au résumé textuel. Et côté entraînement, deux étapes : HybridSFT apprend au modèle de base à se coordonner avec HybridLink, puis HybridRL utilise l'apprentissage par renforcement pour lui apprendre quand chaque mode vaut son coût.

C'est, à mon avis, la vraie contribution. Le problème difficile n'a jamais été « un modèle peut-il raisonner dans l'espace latent ? » — on savait qu'il le pouvait. Le problème difficile, c'est la politique : quelles parties d'une tâche méritent un calcul opaque et bon marché, et lesquelles méritent du texte coûteux mais inspectable. Apprendre cette politique par RL, face aux vraies récompenses de la tâche, c'est ce qui donne quelque chose qui fonctionne plutôt que quelque chose qui fait de belles démos.

Les chiffres annoncés sont solides : sur 11 benchmarks couvrant les maths, les sciences, la médecine, la recherche et le raisonnement agentique, l'agent hybride revendique une amélioration de performance d'environ 10 % par rapport aux bases textuelles et latentes, avec 35 à 55 % de tokens en moins, une inférence 1,8 à 2,6 fois plus rapide et environ 3 fois d'économies de coût. Il faut prendre avec des pincettes les résultats d'un seul article — les benchmarks ratent régulièrement ce à quoi ressemblent les charges de travail réelles — mais la direction du résultat correspond à la théorie. Si la majeure partie d'une trace est du remplissage, la supprimer devrait surtout supprimer du coût, pas de la capacité.

À quoi ressemble concrètement le raisonnement latent dans le code

Mécaniquement, l'astuce est plus simple qu'il n'y paraît. En mode texte, on échantillonne un token, on l'embedde et on le réinjecte. En mode latent, on saute l'échantillonnage et on réinjecte directement le vecteur de sortie du modèle — éventuellement passé par une petite projection — comme entrée suivante. Un jeton de contrôle spécial ou une porte apprise décide du mode. Schématiquement :

def hybrid_step(hidden_state, mode_gate, hybrid_link):
mode = mode_gate(hidden_state)  # learned: LATENT or TEXT
if mode == LATENT:
# No sampling. Feed the continuous thought back in.
next_input = hybrid_link.latent_in(hidden_state)
return next_input, None  # nothing human-readable emitted
# TEXT mode: normal autoregression
logits = lm_head(hidden_state)
token = sample(logits)
next_input = hybrid_link.text_in(embed(token))
return next_input, token  # inspectable output

Le système réel ajoute la mémoire de travail et la mécanique d'entraînement, mais c'est la boucle centrale. Remarquez ce que cela implique pour votre pile de service : les étapes latentes restent des passes avant complètes. Vous économisez sur le nombre de tokens — longueur de sortie, croissance du contexte, pression sur le cache KV des longues traces — pas sur le calcul par étape. L'accélération de plus de 2x vient surtout de séquences plus courtes et d'un décodage autorégressif de texte moins important, pas d'une pensée gratuite. Un commentateur de l'article a suggéré d'aller plus loin en exécutant le chemin latent en parallèle de la génération de texte, puisque vous payez de toute façon la passe avant. C'est une idée vraiment intéressante, et elle montre à quel point cet espace de conception est jeune.

Le coût en interprétabilité que personne ne veut payer

Maintenant, la partie que je serais négligent de sauter. La trace de raisonnement n'est pas un simple confort de débogage : c'est un mécanisme de sécurité. Quand un agent fait quelque chose de bizarre en production, la première chose qu'on fait est de lire sa trace. Quand des chercheurs en alignement sondent les comportements trompeurs, ils cherchent un raisonnement qui contredit la réponse finale. Si l'on déplace le raisonnement dans des vecteurs, ces deux workflows deviennent aveugles.

L'article affirme que la mémoire de travail continue rend les pensées latentes « directement inspectables ». Je classerais cela dans la catégorie vrai techniquement, trompeur en pratique. On peut inspecter les vecteurs comme n'importe quel état caché : avec des classifieurs sondes, des projections de décodeur, de l'analyse par plus proches voisins dans l'espace des embeddings. C'est un outillage de recherche, pas un workflow d'astreinte. C'est la différence entre lire un fichier de log et attacher un débogueur à un core dump. Certains d'entre nous sont sceptiques face aux promesses exagérées de l'interprétabilité depuis un moment, et un tampon de mémoire de travail ne change pas l'asymétrie fondamentale : le texte est lisible par tout le monde, les latents ne le sont presque par personne.

Il existe aussi un mode de défaillance moins discuté : la propagation silencieuse d'erreurs. Dans une trace textuelle, une étape intermédiaire fausse est visible et parfois corrigée d'elle-même — les modèles repèrent leurs erreurs quand ils relisent. Une pensée latente fausse se propage dans la mémoire de travail sans aucune trace textuelle. La réponse finale paraît tout aussi fluide, que la délibération latente ait été saine ou absurde. Pour les équipes qui font tourner des agents en production, cela rejoint directement le compromis entre confinement et supervision : les agents hybrides vous poussent vers le confinement, parce que la supervision vient de devenir beaucoup plus difficile.

Il a été noté ouvertement dans la discussion autour de cet article que le raisonnement latent était officieusement tabou dans une partie de la communauté de recherche, pour ces raisons précisément. Ce tabou est clairement levé. Je ne pense pas que ce soit automatiquement une mauvaise chose, mais ceux qui célèbrent les chiffres d'efficacité devraient reconnaître qu'ils dépensent de l'interprétabilité pour les obtenir.

L'écart entre l'article et votre GPU

Le code, les poids et les données sont publics, ce qui est vraiment excellent. Cela a aussi produit un rappel immédiat à la réalité. En quelques heures, des praticiens faisant tourner localement les modèles publiés ont signalé des comportements dégénérés : un build 8B quantifié se bloquait en répétant indéfiniment le même paragraphe de raisonnement textuel en réponse à « qui est le pape ? », et un build 14B bouclait sur des variantes du même paragraphe pendant cinq minutes sur une tâche banale de recherche et résumé que des modèles comparables gèrent sans problème.

Ce sont peut-être des artefacts de quantification ou des décalages de template de chat — le support de llama.cpp pour une architecture toute neuve est toujours un coup de dés. Mais je soupçonne que le problème de boucle n'est pas une coïncidence. Le changement de mode est un comportement appris, et les comportements appris sont exactement ce que la quantification et le décalage de distribution cassent en premier. Un modèle dont la politique latent-texte est légèrement faussée ne plante pas bruyamment ; il échoue en ne décidant jamais d'arrêter de réfléchir. C'est un mode de défaillance bien plus vicieux pour un agent en production qu'une mauvaise réponse, parce qu'il consomme le budget indéfiniment. Si vous construisez aujourd'hui des boucles d'agents, c'est un argument de plus pour imposer des budgets stricts de tours et de tokens à chaque appel de modèle — la discipline évoquée dans la façon dont les CLI agentiques structurent leurs boucles — quel que soit le paradigme de raisonnement adopté.

Faut-il s'y intéresser ? Verdict d'un pragmatique

Oui, mais comme un panneau de signalisation, pas comme une dépendance. Ma lecture honnête :

• L'argument d'efficacité est réel et structurel. Le texte est un mauvais support pour le calcul interne, et à mesure que les agents gagnent en horizon long, la taxe en tokens de la narration ne fera que croître. Une forme de raisonnement latent arrivera en production, qu'on le veut ou non — on peut d'ailleurs considérer que l'approche des grands laboratoires, les « résumés de raisonnement » opaques, est déjà un pas dans cette direction.
• Le coût en interprétabilité est tout aussi réel, et actuellement sous-évalué. Si votre cas d'usage exige d'auditer pourquoi un agent a agi — médecine, finance, tout ce qui est réglementé —, les traces textuelles sont une fonctionnalité qu'on abandonne à ses risques et périls.
• Les artefacts actuels relèvent de la recherche. Les boucles dégénérées sur des prompts simples, un comportement incertain après quantification et une politique de changement de mode qu'on ne peut pas facilement inspecter ne sont pas des choses qu'on met derrière une API destinée aux clients.
• Le cadrage hybride est le bon. Le raisonnement latent pur n'allait jamais survivre au contact des API d'outils et des utilisateurs ; le raisonnement textuel pur ne peut pas survivre au contact de la facture d'inférence. Une frontière apprise entre les deux, c'est là que tout cela finira.

Le point de fond, c'est que « penser avec des mots » a toujours été un accident de la façon dont nous avons entraîné ces modèles, et non une loi de la cognition. Aucun théorème ne dit que le langage est la bonne granularité pour la pensée machine — la surprise, c'est que ça ait aussi bien marché. Les agents de raisonnement hybrides sont la première esquisse crédible de ce qui vient après : des modèles qui délibèrent en privé et ne parlent que lorsque parler fait partie du travail. Savoir si nous pourrons construire cet avenir sans perdre la capacité de vérifier le travail de la machine est, à mon avis, la question ouverte la plus importante du design d'agents aujourd'hui.