Chain of Thought, RLVR et test-time compute, mesurés

La tentation est de dire que la seconde version « y a réfléchi ». Résistez-y, car le mécanisme est à la fois plus simple et plus utile à connaître.

Un transformer effectue une quantité de calcul fixe par token généré. Un forward pass : les mêmes couches, les mêmes matrices, le même nombre d’opérations, que la question soit combien font 2+2 ou démontrez ce théorème. Il n’y a pas, à l’intérieur du modèle, de bouton « essaie plus fort sur celle-ci ».

Ainsi, lorsqu’on demande à un modèle de répondre immédiatement, tout le calcul dont il dispose tient dans un seul forward pass. Chaque quantité intermédiaire doit tenir dans les activations de ce passage unique, et ce qu’il ne peut pas y calculer, il ne peut pas le calculer.

Émettre des tokens change cela, et de deux façons distinctes qu’il vaut la peine de séparer :

• Plus de calcul. Chaque token généré est un autre forward pass complet. Cent quarante-cinq tokens de travail représentent cent quarante-cinq fois l’arithmétique nécessaire pour répondre directement.
• Mémoire externalisée. Les tokens sont écrits dans le contexte, de sorte que le passage suivant puisse les lire. 5 × 13 = 65 devient un fait dans l’entrée, et non une valeur que le modèle doit conserver dans une activation et transporter plus loin. Le modèle utilise sa propre sortie comme brouillon.

C’est ce second point que l’on manque souvent, et il explique pourquoi le travail doit être écrit pour aider. Un modèle à qui l’on demande de « réfléchir en silence puis répondre » n’a nulle part où mettre la pensée.

Rien de tout cela n’exige quoi que ce soit de mystique, et cela produit une prédiction ferme : la chain of thought devrait surtout aider sur les problèmes à structure sérielle — où la deuxième étape a besoin du résultat de la première — et très peu sur les problèmes qui relèvent d’une simple récupération. C’est exactement ce que constate la littérature, et c’est pourquoi « think step by step » ne change rien à quelle est la capitale de la France.

La technique est arrivée en 2022 en deux morceaux. Wei et al. ont montré qu’inclure des exemples résolus dans le prompt — des démonstrations où la réponse est précédée d’un raisonnement — produisait de grands gains sur des benchmarks d’arithmétique et de bon sens.¹ Kojima et al. ont ensuite montré quelque chose de plus étrange : vous n’avez pas besoin des exemples. Ajouter « Let's think step by step » à un prompt zero-shot capture une grande partie du même gain.²

Le second résultat est celui qui révèle ce qui se passe. Si une phrase magique débloque le comportement, c’est que le comportement était déjà dans le modèle — le préentraînement est plein de solutions développées, et la phrase est un pointeur vers cette région de la distribution. La chain of thought n’a rien appris au modèle. Elle a sélectionné quelque chose que le modèle possédait déjà.

Ce cadrage prédit aussi l’obsolescence future de la technique, à laquelle nous revenons à la fin du chapitre.

L’étape suivante est évidente : si une chaîne de raisonnement peut être fausse, échantillonnez-en plusieurs et prenez la réponse majoritaire. C’est la self-consistency.³ C’est une dépense strictement supérieure — $n$ générations complètes au lieu d’une — et l’intuition est que les mauvaises réponses se dispersent tandis que les bonnes convergent.

Mesuré sur 16 des mêmes problèmes, avec un sampling à temperature 0,8 et un vote majoritaire sur $n$ chaînes :

Seize problèmes, c’est un petit dénominateur, et la règle du chapitre 4 s’applique à ce tableau autant qu’à n’importe quel autre. 13 sur 16 donne 81 % avec un intervalle de Wilson à 95 % de [57, 93] ; 16 sur 16 donne 100 % avec [81, 100]. Ils se chevauchent. Lisez la forme de la courbe, qui est le résultat ; ne lisez pas l’échelon exact où elle s’aplatit, que seize problèmes ne peuvent pas localiser.

Deux choses dans ce tableau, et la seconde n’est pas celle à laquelle je m’attendais.

La courbe s’aplatit à $n = 3$. Dès le troisième échantillon, l’exactitude atteint son plafond et les deux échantillons restants n’achètent rien, tout en coûtant 172 tokens chacun, 345 à eux deux. C’est la forme de toutes les courbes de self-consistency publiées dans la littérature, et cela arrive bien plus tôt que ne le suggère le cadrage « plus d’échantillons, c’est forcément mieux ».

Et le greedy decoding était déjà à 100 %. Revenez au début du chapitre : une chaîne, pas de sampling, 145 tokens, 24/24. Le sampling à temperature 0,8 a fait chuter l’exactitude à 81 %, et la self-consistency a eu besoin de trois générations pour remonter là où un seul passage greedy se trouvait déjà — avec 3,6 fois plus de tokens, ou six fois plus si vous poussez le balayage jusqu’à cinq sans savoir où la courbe s’aplatit.

Ce n’est pas un argument contre la self-consistency. C’est un énoncé précis de ce qu’elle fait : la temperature achète de la diversité en injectant des erreurs, et le vote retire les erreurs qu’elle vient d’injecter. Sur les problèmes où le greedy decoding échoue — où la chaîne la plus probable mène quelque part de faux et une chaîne moins probable est juste — cet échange paie, et c’est pourquoi la technique existe. Sur les problèmes où le greedy réussit déjà, c’est une façon de dépenser six fois le budget pour revenir au point de départ.

Personne ne publie le second cas, d’où l’intérêt de le mesurer sur votre propre tâche avant d’adopter la technique. Ce sont des problèmes faciles en deux étapes pour un petit modèle ; c’est le régime dans lequel la réponse sort ainsi.

Tout ce qui précède se produit au moment du prompt, sur un modèle qui n’a jamais été spécifiquement entraîné pour cela. Le basculement qui a produit la génération actuelle de modèles de raisonnement a consisté à le déplacer dans l’entraînement — et la clé qui l’a rendu possible est plus étroite qu’elle n’en a l’air.

Le post-training du chapitre 11 nécessitait des préférences humaines, parce que « était-ce une bonne réponse ? » n’a pas de réponse programmatique. Mais pour certaines questions, il en existe une. Une réponse mathématique est égale à la bonne valeur, ou elle ne l’est pas. Du code passe les tests, ou il ne les passe pas. Une preuve se vérifie, ou elle ne se vérifie pas.

Pour ces domaines, vous pouvez remplacer le modèle de récompense par un vérificateur, et tout ce qui suit s’améliore d’un coup : pas d’annotateurs, pas d’ajustement Bradley–Terry, pas de reward hacking du type mesuré au chapitre 11 — car vous ne pouvez pas flatter un test unitaire. C’est le reinforcement learning from verifiable rewards, et c’est le cadre pour lequel GRPO a été conçu : échantillonner un groupe de tentatives de solution au même problème, vérifier chacune d’elles, puis utiliser le score moyen du groupe comme baseline. Pas de critic, pas d’annotateur, pas de modèle de récompense. Juste un programme qui dit juste ou faux.

Le résultat qui a recadré le domaine est venu de DeepSeek début 2025.⁶ Ils ont pris un modèle de base et appliqué le reinforcement learning avec verifiable rewards directement, sans étape préalable de supervised fine-tuning — l’étape que le chapitre 11 présente comme le fondement de tout. De longues chaînes de raisonnement ont quand même émergé. Des comportements que personne n’avait entraînés aussi : le modèle s’est mis à revérifier ses propres étapes et, dans le passage le plus cité de l’article, à reconsidérer spontanément une approche au milieu d’une solution.

La lecture honnête n’est pas que le raisonnement est magique. C’est que lorsque la seule chose récompensée est d’avoir raison, et qu’avoir raison sur un problème difficile exige de le travailler, alors le travailler est ce que l’optimiseur trouve — y compris les parties du travail que les humains font aussi, parce qu’elles sont ce que le problème exige plutôt que ce que quelqu’un a enseigné.

La conséquence pratique de tout cela est qu’un modèle de raisonnement produit des tokens que vous avez demandés et des tokens que vous n’avez pas demandés, et vous payez les deux.

Les fournisseurs gèrent cela différemment, et la différence compte :

• La plupart des APIs comptent les reasoning tokens dans le décompte des output tokens. Votre facture et votre limite max_tokens incluent tous deux la réflexion que vous ne voyez jamais.
• Gemini de Google signale les thinking tokens dans un champ séparé, en dehors du décompte standard des sorties.

C’est une véritable incompatibilité entre deux façons de compter la même chose, et tout code qui calcule un coût ou impose un budget entre fournisseurs doit la normaliser. Le chapitre 16 est l’endroit où cela devient de l’argent, et le chapitre 23 celui où cela devient un budget que vous pouvez faire respecter.

L’autre conséquence est une conséquence de latence qui surprend la première fois. Le temps jusqu’au premier token visible d’un modèle de raisonnement inclut toute sa réflexion, donc une requête qui ne stream rien pendant huit secondes puis répond en une seconde n’est pas une connexion bloquée — c’est le modèle qui travaille. Toute interface qui affiche un spinner sans explication pendant huit secondes a un problème de design, pas de réseau.

Un avertissement final, car c’est la façon la plus courante d’appliquer de travers le contenu de ce chapitre.

Tout ce qui se trouve dans la première moitié est une technique pour faire produire du raisonnement à un modèle qui n’a pas été entraîné à raisonner. Les modèles entraînés avec RLVR le font déjà : ils émettent leur propre travail, avec leur propre longueur, avant de répondre. Dire à un tel modèle de think step by step est au mieux redondant et au pire nuisible — cela peut produire une chaîne courte, en forme de prompt, à la place de la chaîne plus longue que le modèle aurait générée de lui-même, et certains fournisseurs documentent exactement cela.

Il en va de même pour les échafaudages de raisonnement élaborés dans le code applicatif. Un prompt qui guide un modèle à travers un arbre de décision qu’il parcourt déjà en interne dépense vos tokens pour contraindre un comportement qui a été entraîné. C’est la première apparition d’un thème qui traverse le reste du cours : des techniques essentielles en 2022 sont devenues des superstitions en 2025, et la seule façon de savoir lesquelles le sont pour votre modèle, aujourd’hui, est de mesurer les deux.

Le chapitre 15 est l’endroit où cette mesure devient une discipline plutôt qu’une opinion.

Le raisonnement a une propriété inconfortable : c’est la seule capacité dont le coût augmente avec la difficulté de la question. Un modèle qui réfléchit pendant neuf cents tokens effectue neuf cents forward passes, conserve un cache croissant en mémoire pour chacun d’eux, et occupe un GPU pendant toute la durée.

Cela rend l’économie du service d’un modèle de raisonnement nettement pire que celle d’un modèle de chat, et transforme un ensemble de détails d’implémentation en différence entre un produit viable et un produit non viable : comment le cache des clés et valeurs passées est stocké et réutilisé, combien de requêtes peuvent partager un forward pass, et de quelle précision les poids ont réellement besoin.

Le chapitre 13 est le dernier où le modèle est un objet dans votre mémoire plutôt qu’un service derrière un port, et il porte sur la manière de rendre cet objet assez bon marché pour être servi. Il encaisse aussi une promesse de ce chapitre : le speculative decoding, qui produit plusieurs tokens pour à peu près le prix d’un seul en faisant deviner un petit modèle et vérifier un grand — une astuce qui n’a de sens qu’une fois que vous avez vu quelle part d’un forward pass se passe à attendre la mémoire plutôt qu’à faire de l’arithmétique.

Toutes les mesures de ce chapitre viennent de Qwen/Qwen2.5-0.5B-Instruct sur 24 problèmes écrits générés en deux étapes, avec greedy decoding sauf lorsque le sampling est indiqué, et zéro génération tronquée aux plafonds de tokens utilisés. Elles sont reproductibles, et elles concernent un petit modèle sur des problèmes faciles : lisez le résultat de self-consistency comme une démonstration du mécanisme, pas comme un benchmark. Le chapitre 18 des notes de cours CS229 et le chapitre 12 du Hugging Face LLM Course couvrent tous deux ce sujet avec des modèles plus grands et de vrais benchmarks.