Modèles de raisonnement : entraînés, pas promptés

Voici une opinion que j'ai mal défendue lors d'un déjeuner d'équipe l'an dernier, et que je trouve encore plus juste aujourd'hui : si votre modèle mental d'un modèle de raisonnement est « un LLM classique à qui on a demandé de réfléchir étape par étape », vous ne comprenez pas vraiment ces modèles, et ce malentendu vous coûte discrètement de l'argent et de la précision en production. Les modèles de raisonnement ne sont pas une technique de prompting. Ce sont un artefact d'entraînement. Le comportement de chaîne de pensée qui les rend bons en maths et en code émerge de l'apprentissage par renforcement avec récompenses vérifiables, et non de ce que vous écrivez dans un prompt système. J'ai enfin vraiment compris cela en parcourant le même terrain que Sebastian Raschka couvre dans son nouveau cours de 11 heures sur la construction d'un modèle de raisonnement : charger un petit modèle de base Qwen3, écrire un vérificateur, lancer GRPO, et regarder les traces de raisonnement s'allonger pendant que la précision grimpe. Une fois que vous l'avez vu se produire dans votre propre boucle d'entraînement, impossible de faire comme si de rien n'était.

Laissez-moi défendre cette affirmation comme il se doit, puis la nuancer là où elle doit l'être, car il y a un domaine où le prompting compte vraiment, et prétendre le contraire serait une forme d'exagération d'un autre genre.

Pourquoi le modèle mental du « il suffit de promptер » ne tient pas

L'histoire populaire se déroule ainsi : en 2022, des chercheurs découvrent qu'ajouter « Réfléchissons étape par étape » à un prompt améliore nettement la précision en arithmétique, et la chaîne de pensée naît. C'est vrai, jusqu'à un certain point. Ce que l'histoire omet, c'est la suite : les laboratoires ont pris ce comportement et l'ont gravé dans les poids grâce à l'apprentissage par renforcement. Un modèle de raisonnement moderne n'a pas besoin de votre incantation « étape par étape ». Il génère des traces de raisonnement étendues par défaut parce qu'il a été entraîné à le faire, récompensé pour produire des traces qui aboutissent à des réponses correctes.

Vous pouvez le vérifier vous-même avec une expérience qui prend un après-midi. Prenez un modèle de base, Qwen3 0.6B fait très bien l'affaire et tourne sur un seul GPU grand public, et évaluez-le sur MATH-500 avec et sans prompt de chaîne de pensée. Vous obtenez une légère amélioration. Prenez ensuite la variante entraînée en RLVR de la même famille de modèles. L'écart entre ces deux conditions n'est plus une légère amélioration, c'est une falaise. Aucun prompt système jamais écrit ne le comble. C'est le cœur empirique de mon propos : la capacité réside dans les poids, et les poids sont devenus ce qu'ils sont grâce à l'entraînement, pas grâce à des agencements astucieux de tokens au moment de l'inférence.

La confusion persiste parce que, vu de l'extérieur, les deux se ressemblent : le modèle émet un long flux de raisonnement intermédiaire avant de répondre. Mais cette ressemblance de surface masque une différence causale. Demander à un modèle de base de réfléchir étape par étape, c'est comme demander à quelqu'un de commenter sa pensée pendant un calcul mental : le commentaire suit la capacité. L'entraînement par RL modifie réellement la capacité elle-même, car le modèle est optimisé de bout en bout pour la justesse de sa réponse, et le raisonnement étendu se trouve être une stratégie utile pour obtenir de bonnes réponses sur les problèmes difficiles.

Le vérificateur est tout le truc

Quand j'étais ingénieur en ML, la partie du RLHF qui me paraissait toujours un peu maudite, c'était le modèle de récompense. On entraîne un réseau de neurones séparé pour imiter les préférences humaines, on optimise ensuite sa politique contre lui, et on passe le reste du projet à lutter contre le reward hacking : la politique trouve une sortie dégénérée qui obtient un bon score auprès du modèle de récompense tout en étant inutile pour de vrais humains. C'est une relation antagoniste inscrite dans l'architecture.

L'apprentissage par renforcement avec récompenses vérifiables, le RLVR, contourne entièrement ce problème, et construire un vérificateur à partir de zéro vous fait apprécier l'élégance de la démarche. Pour les maths, le vérificateur est un programme ennuyeux et déterministe : il extrait la réponse finale de la sortie du modèle, la normalise (gérer les fractions, les décimales, les formes équivalentes comme 1/2 et 0.5) et vérifie l'équivalence mathématique. Bonne réponse, récompense de un. Mauvaise réponse, zéro. Il n'y a pas de modèle de récompense appris à exploiter. Le signal de récompense est une vérité de terrain.

C'est pour cela que les modèles de raisonnement ont d'abord bien réussi en maths et en code. Ces deux domaines disposent de vérificateurs bon marché et fiables : des vérificateurs d'équivalence symbolique pour les maths, des tests unitaires pour le code. Pas besoin d'annotateurs humains qui classent des sorties ; il suffit d'une fonction Python qui renvoie un booléen. La conséquence pratique pour quiconque construit un raisonnement spécifique à un domaine est nette : si vous savez écrire un vérificateur pour votre domaine, vous pouvez probablement entraîner un modèle de raisonnement pour lui. Si vous ne le pouvez pas, si la justesse dans votre domaine relève du goût, comme pour un texte marketing, vous êtes coincé avec le RLHF et ses maux de tête liés au reward hacking.

Le goulot d'étranglement pour le raisonnement dans un nouveau domaine n'est ni le calcul ni les données. C'est la capacité à écrire ce que « correct » signifie sous forme de programme.

Un détail que j'adore dans la construction du vérificateur en premier, avant tout entraînement : il fait double emploi. Le même correcteur qui note votre modèle de base sur MATH-500 pour l'évaluation devient la fonction de récompense pendant le RL. Quand vous l'implémentez vous-même, vous remarquez le travail subtil qu'il effectue : l'extraction de la réponse est franchement délicate, car les modèles expriment leurs réponses finales dans des dizaines de formats, et un extracteur fragile corrompt silencieusement votre signal de récompense. Un modèle qui écrit « donc x = 7 » pourrait être mal noté si votre regex ne cherche que les réponses encadrées. Des vérificateurs bâclés forment des politiques bâclées. C'est le genre de leçon qu'on ne tire tout simplement pas en lisant des articles.

Ce que GRPO fait réellement aux poids

La boucle d'entraînement elle-même, dans sa forme simplifiée construite à partir de zéro, est étonnamment compacte. Group Relative Policy Optimization, l'algorithme popularisé par DeepSeek, supprime le réseau critique qui rendait PPO si gourmand en mémoire. Au lieu d'apprendre une fonction de valeur, vous générez un groupe de réponses au même prompt, vous les notez toutes avec le vérificateur, et vous calculez l'avantage de chaque réponse par rapport à la moyenne du groupe. Les réponses meilleures que la moyenne voient leurs probabilités de tokens augmenter ; les moins bonnes diminuent.

def grpo_advantages(rewards: torch.Tensor) -> torch.Tensor:
# rewards: [group_size], one per sampled response to the same prompt
mean = rewards.mean()
std = rewards.std().clamp_min(1e-4)
return (rewards - mean) / std  # relative advantage per response
# Training step: maximize advantage-weighted log-probability
def grpo_loss(logprobs: torch.Tensor, advantages: torch.Tensor) -> torch.Tensor:
# logprobs: summed sequence log-prob under the current policy
return -(advantages.detach() * logprobs).mean()

Les implémentations réelles ajoutent une pénalité KL pour empêcher la politique de trop s'éloigner du modèle de référence, ainsi qu'un écrêtage emprunté à PPO, mais le squelette ci-dessus est honnêtement l'idée centrale. Et ce qui rend le spectacle magique, c'est que vous ne dites rien au modèle sur le style de raisonnement. Vous récompensez uniquement les bonnes réponses finales. Pourtant, au fil de l'entraînement, la longueur des réponses augmente. Le modèle commence à se corriger en cours de trace (« attends, vérifions ») parce que les traces avec un comportement de vérification ont plus de chances d'aboutir à de bonnes réponses, et que les bonnes réponses sont la seule chose qui rapporte une récompense. Le style de chaîne de pensée est une solution émergente au problème d'optimisation, et non un comportement que quelqu'un a conçu. C'est pour cela que je dis qu'il est entraîné, pas promptée : la version de cette capacité à l'époque du prompting consistait en des humains qui imitaient ce que le RL a fini par découvrir seul.

Il y a une remarque d'ingénierie pragmatique enfouie ici que le cycle de hype ignore : un modèle de 0,6 milliard de paramètres avec un GPU correct suffit pour observer réellement cette dynamique. Vous obtiendrez une amélioration mesurable sur MATH-500 grâce à GRPO, sur un matériel que l'on peut louer pour quelques dollars de l'heure. Vous n'obtiendrez pas un modèle de pointe. C'est très bien ainsi, ce n'est pas le but de l'exercice.

Mise à l'échelle au moment de l'inférence : quand le calcul remplace l'entraînement (en partie)

Avant tout RL, il existe une famille de techniques qui améliorent les réponses avec les poids figés : échantillonner plusieurs candidats avec la température et le top-p, puis les combiner. L'auto-cohérence est le cheval de trait : générer k réponses et prendre le vote majoritaire sur les réponses finales. Cela fonctionne remarquablement bien, et cela fonctionne aussi sur des modèles de base, ce qui constitue la première brèche dans ma thèse d'ouverture, que je concède : le calcul au moment de l'inférence est un axe d'amélioration réel et indépendant.

Mais regardez ce que ces techniques exigent réellement. Le vote majoritaire n'aide que si votre modèle a déjà une probabilité non négligeable de produire de bonnes réponses : le vote amplifie un signal qui existe, il ne crée pas un signal à partir de rien. La sélection par score (classer les candidats selon leur log-probabilité de séquence) a la même propriété. Quant aux boucles d'auto-affinement, où le modèle critique et révise sa propre réponse, elles s'avèrent décevantes sur les modèles de base, car une autocritique honnête est elle-même une capacité que le RL installe. Chaque astuce d'inférence se combine avec l'entraînement ; aucune ne le remplace. Si les systèmes de pointe associent des modèles entraînés en RL à une mise à l'échelle à l'inférence, c'est parce que les deux se multiplient au lieu de s'additionner.

Le coût compte pour les praticiens. L'auto-cohérence avec k=16 coûte seize fois plus cher en inférence. Savoir si c'est un bon compromis dépend entièrement de votre courbe précision par dollar, et la seule façon honnête d'y répondre est de tracer vous-même la précision sur MATH-500 en fonction du nombre de candidats. Nous avons abordé une question similaire de placement du calcul dans notre article sur les modèles de gamme flash et l'efficacité de l'inférence : le thème récurrent est que « dépenser plus de calcul » a au moins trois sens différents, et qu'ils ne sont pas interchangeables.

La distillation, et le seul endroit où le prompting survit

La dernière étape du pipeline construit à partir de zéro est la distillation : prendre les longues traces de raisonnement d'un raisonneur puissant (généralement grand) et affiner directement un modèle plus petit dessus, par apprentissage supervisé classique. Pas de RL, pas de vérificateur dans la boucle. C'est ainsi que beaucoup des petits modèles de raisonnement bon marché que vous déploierez réellement ont été fabriqués. Cela renforce la thèse au lieu de la contredire : le comportement de raisonnement provient toujours de données d'entraînement produites par un modèle entraîné en RL, simplement transmises par descente de gradient au lieu de récompense. La capacité n'est jamais injectée au moment du prompt ; elle est toujours intégrée par l'optimisation.

Alors, où ma thèse à contre-courant se brise-t-elle ? Honnêtement, ici : le prompting compte encore en marge, et ces marges ne sont pas nulles. Les contrôles d'effort de raisonnement, les réglages de budget de réflexion bas, moyen ou élevé que les modèles de la génération actuelle exposent, sont des leviers d'inférence qui échangent de manière significative précision contre latence et coût. Les contraintes de sortie structurée, les pipelines avec vérificateur dans la boucle et le décodage contraint sont des techniques de niveau prompt et harnais à la valeur réelle, comme nous l'avons défendu dans notre article sur le décodage contraint. Et si vous êtes coincé avec un modèle de base et ne pouvez rien entraîner, le prompt de chaîne de pensée vaut toujours de vrais points sur les évaluations. « Entraîné, pas promptée » est une affirmation sur l'origine de la capacité, et non une affirmation selon laquelle les choix faits à l'inférence n'auraient pas d'importance.

Pourquoi construire vaut mieux que lire

Une objection légitime a circulé dans les endroits habituels : un tutoriel pour construire son propre modèle de raisonnement, n'est-ce pas un guide pour construire son propre CPU, charmant mais inutile, puisque les vrais entraînements demandent des clusters et des données propriétaires ? Je pense que cela passe à côté de l'intérêt de l'exercice, et je dirais la même chose du classique tutoriel pour construire un shell, que nous avons salué dans Ce que la construction d'un shell vous apprend sur Unix précisément pour cette raison. Personne n'écrit un shell pour remplacer bash. On en écrit un parce que fork, exec, les tubes et la gestion des signaux cessent d'être des abstractions mémorisées pour devenir une mécanique que l'on a réellement manipulée.

C'est pareil ici. Ce qui a durablement changé ma façon de travailler avec les modèles de raisonnement venait de détails d'implémentation, pas d'articles :

• Écrire le vérificateur m'a appris que la qualité de la récompense est un problème d'ingénierie logicielle : les cas limites de normalisation faussent silencieusement l'entraînement, et « la récompense est une vérité de terrain » n'est vraie que dans la mesure où votre extracteur de réponses l'est.
• Implémenter le scoring par log-probabilité de séquence (avec les acrobaties de stabilité numérique que cela implique) a démystifié la moitié des fonctions de perte de la littérature de post-entraînement. Toutes se ramènent à comparer la probabilité de réponses sous différentes politiques.
• Voir la longueur des réponses augmenter pendant GRPO, sans aucune consigne, a fait disparaître ma dernière croyance résiduelle selon laquelle le style de raisonnement serait un comportement de surface. C'est ce que l'optimisation trouve lorsque la justesse est le seul objectif.
• Tracer la précision en fonction du nombre de candidats pour l'auto-cohérence m'a donné une intuition concrète du compromis précision par dollar que aucun tableau de benchmark n'avait jamais réussi à me transmettre.

L'anxiété liée au calcul est également exagérée pour un usage d'apprentissage. Les premières parties, charger un modèle de base, générer en flux avec le cache KV, construire le vérificateur, lancer MATH-500, relèvent du CPU et du portable, ou presque. L'entraînement GRPO demande un GPU, mais un seul, et loué à l'heure il coûte moins cher que la plupart des manuels. Ce qu'on ne peut pas reproduire chez soi, c'est l'échelle, et l'échelle est vraiment une autre discipline. C'est l'un des mythes sur le moteur d'inférence de DeepSeek que nous avons testés : la pile de service d'un laboratoire de pointe résout des problèmes qui n'existent tout simplement pas à l'échelle d'un tutoriel, et inversement.

À retenir en pratique

Si vous ne retenez qu'une chose de tout cela, retenez la vision centrée sur le vérificateur. La pile moderne du raisonnement se compose d'un modèle de base, d'un programme qui décide de ce que « correct » signifie, d'un algorithme de RL qui optimise contre lui, et de techniques d'inférence qui multiplient le résultat. Le prompting se situe à la toute périphérie de ce système, en pilotant une capacité que l'entraînement a créée. Les équipes qui comprennent cela concentrent leurs efforts là où ils se cumulent : de meilleurs vérificateurs, une meilleure conception des récompenses, de meilleures boucles d'évaluation comme celles que nous avons défendues et qui manquent à la plupart des benchmarks d'IA qui passent à côté du travail réel. Les autres continuent à retoucher leurs prompts système en se demandant pourquoi la précision stagne.

Ma thèse du déjeuner d'équipe tient avec une réserve : les modèles de raisonnement sont entraînés, pas promptés, mais le harnais que vous construisez autour d'eux, prompts compris, détermine la part de cette capacité entraînée que vous récoltez réellement. Construisez vous-même la petite version un de ces jours. Onze heures de code en accompagnement, c'est un prix modeste pour ne plus jamais vous tromper sur ce point.