Modèles de raisonnement et test-time compute

Un modèle de raisonnement ne se contente plus de prédire le mot suivant aussi vite que possible : il dépense du calcul à l'inférence pour réfléchir avant de répondre, en déroulant une longue chaîne de pensée. C'est le pari du test-time compute : à modèle figé, donner plus de temps de réflexion peut faire grimper la précision autant — voire plus — que de gonfler le modèle. Cet article explique pourquoi cela marche, comment on entraîne ces modèles (o1/o3, DeepSeek-R1, RL et récompense vérifiable), quelles stratégies existent à l'inférence (vote, best-of-N, vérificateurs, recherche arborescente), et où sont les limites.

De la prédiction rapide au raisonnement délibéré

Un LLM classique répond en un seul jet : il produit la réponse token par token, sans étape de réflexion explicite. Cela suffit pour des tâches simples, mais s'écroule sur les problèmes qui demandent plusieurs étapes — mathématiques de compétition, preuves, planification, code complexe.

L'idée fondatrice est la chaîne de pensée (chain-of-thought, CoT) : au lieu de cracher la réponse, le modèle écrit son raisonnement intermédiaire — « posons X, alors Y, donc Z ». Ce raisonnement explicite sert de mémoire de travail externalisée :

• chaque étape conditionne la suivante, ce qui étale le calcul sur plusieurs jetons ;
• le modèle peut détecter et corriger ses propres erreurs au passage ;
• la trace devient inspectable, donc plus facile à déboguer qu'une réponse opaque.

La nouveauté des modèles de raisonnement (o1, o3, DeepSeek-R1, et leurs successeurs) est que ce comportement n'est plus seulement déclenché par un prompt habile (« réfléchis étape par étape »). Il est désormais entraîné : le modèle apprend à produire de longues traces de réflexion, à revenir en arrière, à se vérifier, parce que c'est explicitement récompensé pendant l'entraînement.

On distingue donc deux régimes :

• le CoT déclenché par prompt sur un modèle généraliste, peu fiable et sensible à la formulation ;
• le raisonnement appris d'un modèle dédié, robuste, qui sait quand et combien réfléchir.

Pourquoi un LLM standard plafonne en un seul jet

Une raison mécanique : un Transformer dépense une quantité de calcul fixe par jeton produit. Pour une question dont la résolution demande, disons, l'équivalent de dix étapes de déduction, exiger la réponse en un seul jeton revient à comprimer ces dix étapes dans une seule passe — ce qui dépasse la profondeur effective du réseau. La chaîne de pensée contourne cette borne : en écrivant les étapes intermédiaires, le modèle réinjecte son propre travail dans le contexte et s'offre, jeton après jeton, autant de passes de calcul qu'il y a d'étapes.

C'est aussi pour cela que « réfléchis étape par étape » fonctionne sur un modèle non entraîné, mais de façon fragile : le prompt autorise le calcul étalé sans garantir qu'il soit productif. Le RL, lui, façonne la politique de réflexion : combien d'étapes, quand revenir en arrière, quand s'arrêter.

Pourquoi dépenser du calcul à l'inférence aide

Le pré-entraînement déplace le coût en amont : on dépense énormément de FLOPs une fois, puis chaque réponse est bon marché. Le test-time compute inverse partiellement la logique : on garde un modèle plus modeste, mais on dépense plus à chaque requête difficile.

Pourquoi est-ce souvent gagnant ? Trois raisons :

• Beaucoup de problèmes sont vérifiables ou décomposables. Une réponse fausse sur dix tentatives ne coûte rien si on sait reconnaître la bonne ; échantillonner plusieurs solutions augmente mécaniquement la chance qu'au moins une soit correcte.
• Le raisonnement séquentiel construit sur lui-même. Une trace longue permet d'explorer, de tester une piste, de l'abandonner, d'en essayer une autre — exactement ce qu'un humain fait sur un problème dur.
• L'allocation est adaptative. On peut donner peu de calcul aux questions faciles et beaucoup aux questions dures, au lieu d'un coût uniforme.

Snell et al. (arXiv 2408.03314) montrent qu'une stratégie d'allocation compute-optimale — adapter la méthode et le budget à la difficulté de chaque prompt — peut être plus de 4× plus efficace qu'un best-of-N naïf. Plus frappant encore : sur des problèmes où un petit modèle a déjà un taux de succès non trivial, le test-time compute peut lui faire dépasser un modèle 14× plus gros à budget de calcul égal.

Cela ne veut pas dire que l'inférence remplace l'entraînement. Les deux leviers sont complémentaires : un meilleur modèle de base relève le plafond, et le test-time compute permet d'en extraire davantage sur le moment. La vraie question d'ingénierie est : où placer le prochain euro de calcul ?

pass@k contre pass@1 : ce que la couverture révèle

Une intuition clé se lit dans l'écart entre deux métriques. Le pass@1 mesure la probabilité qu'une seule tentative soit correcte ; le pass@k, la probabilité qu'au moins une parmi k tentatives le soit. Quand pass@k est très supérieur à pass@1, cela signifie que le modèle sait souvent produire la bonne réponse, mais pas de façon fiable au premier coup. Tout l'enjeu du test-time compute parallèle est alors de convertir cette couverture en précision : échantillonner k traces (pour viser le pass@k), puis sélectionner la bonne avec un vote ou un vérificateur. Si au contraire pass@k reste proche de pass@1, échantillonner ne sert à rien — le problème dépasse le modèle, et seul un meilleur modèle (ou un raisonnement séquentiel plus profond) aidera.

Figure : les deux grandes familles de test-time compute — séquentiel et parallèle.

o1 et o3 : apprendre à raisonner par renforcement

OpenAI a ouvert cette ère avec o1 (« Learning to reason with LLMs »). L'idée centrale : entraîner le modèle par apprentissage par renforcement (RL) à produire une chaîne de pensée productive. Au fil de l'entraînement, le modèle apprend à :

• reconnaître ses propres erreurs et les corriger ;
• essayer des approches différentes quand la première échoue ;
• décomposer un problème difficile en sous-problèmes traitables.

Deux lois de scaling se cumulent alors :

• La performance s'améliore avec le calcul d'entraînement (plus de RL).
• Elle s'améliore aussi avec le calcul d'inférence (plus de temps de réflexion par requête).

C'est une nouvelle frontière de la « bitter lesson » : on échange du calcul à l'inférence contre de meilleures décisions. o3 prolonge o1 en augmentant le RL et en intégrant une recherche au moment de l'inférence ; une part de ses gains rapides vient de l'utilisation des traces de réflexion d'o1 comme données synthétiques pour l'entraînement.

Particularité : la chaîne de pensée brute de ces modèles est en partie cachée à l'utilisateur (on n'en voit qu'un résumé), pour des raisons de sécurité et de propriété intellectuelle. C'est précisément ce que DeepSeek-R1 a rendu ouvert — d'où son importance pour la communauté.

Deux axes de calcul orthogonaux

Il est utile de séparer deux dimensions souvent confondues :

• le calcul d'entraînement (pré-entraînement + post-entraînement RL), payé une fois et amorti sur des milliards de requêtes ;
• le calcul d'inférence (jetons de réflexion, échantillons, recherche), payé à chaque requête.

Le tournant des modèles de raisonnement, c'est d'avoir rendu le calcul d'inférence productif : sur un LLM standard, lui donner 10× plus de jetons ne fait pas 10× mieux ; sur un modèle entraîné à raisonner, la courbe précision/calcul monte de façon exploitable. Autrement dit, le RL ne se contente pas d'améliorer le modèle « en moyenne » — il débloque une seconde loi de scaling, celle de l'inférence, en plus de celle du pré-entraînement.

DeepSeek-R1 : le RL sur le raisonnement, ouvert

DeepSeek-R1 (arXiv 2501.12948) est la réplication ouverte qui a démystifié la recette. Son point de départ provocateur : R1-Zero, entraîné par RL pur, sans phase de fine-tuning supervisé (SFT) au préalable. L'hypothèse : les schémas de raisonnement imposés par l'humain limitent l'exploration ; mieux vaut laisser le modèle découvrir lui-même comment raisonner.

Le signal de récompense est uniquement la justesse de la réponse finale, plus un bonus de format :

• vérité terrain en maths (la réponse numérique est-elle exacte ?) ;
• exécution de tests en code (le programme passe-t-il ?) ;
• un bonus si le raisonnement reste bien encadré dans les balises attendues.

Point capital : aucune supervision du raisonnement lui-même. On ne dit jamais au modèle comment penser, seulement si le résultat est juste.

Résultat : sur AIME 2024, le score pass@1 de R1-Zero grimpe de 15,6 % à 71,0 % au fil de l'entraînement RL, et atteint 86,7 % avec vote majoritaire — au niveau d'o1. Le modèle développe spontanément des comportements sophistiqués : traces plus longues, retours en arrière, auto-vérification. La version finale R1 ajoute une petite amorce SFT pour la lisibilité, mais l'essentiel des capacités vient du RL.

Le pipeline multi-étapes de R1

R1-Zero prouve que le RL pur suffit pour raisonner, mais sa sortie est peu lisible (mélange de langues, mise en forme erratique). R1 « final » corrige cela par un pipeline en quatre temps, qui est le vrai patron reproductible :

1. Cold start SFT : un petit jeu de longues CoT lisibles amorce le modèle, pour stabiliser le format avant le RL.
2. RL orienté raisonnement : GRPO avec récompense vérifiable (maths/code) ; on ajoute une récompense de cohérence linguistique pour combattre le mélange de langues.
3. Rejection sampling + SFT : on échantillonne massivement avec le modèle RL, on garde les traces correctes (filtrées par vérification), puis on re-SFT — y compris sur des données non-raisonnement (rédaction, factualité).
4. RL final tous domaines : un dernier tour de RL aligne aussi l'utilité et l'innocuité, pas seulement le raisonnement.

La leçon : alterner RL (qui explore et découvre des stratégies) et SFT sur traces filtrées (qui consolide et nettoie) est plus robuste que l'un ou l'autre seul.

GRPO : un RL sans modèle de valeur

DeepSeek utilise GRPO (Group Relative Policy Optimization), une variante de PPO conçue pour être plus légère. Au lieu d'entraîner un coûteux critic (modèle de valeur) en parallèle, GRPO échantillonne un groupe de G réponses pour la même question, les note, puis calcule l'avantage de chaque réponse relativement à la moyenne du groupe.

Pour une question q :
  échantillonner G réponses o_1 … o_G depuis la politique
  récompense r_i  =  +1 si o_i est correcte, + bonus de format
  avantage A_i  =  (r_i − moyenne(r)) / écart-type(r)
  monter le gradient des traces dont A_i > 0,
  descendre celui des traces dont A_i < 0

L'astuce : une réponse meilleure que la moyenne de son groupe est renforcée, une réponse pire est pénalisée. Pas besoin de critic séparé — d'où un entraînement plus simple et moins gourmand en mémoire. La normalisation par groupe (centrer-réduire les récompenses) recale automatiquement chaque lot à moyenne nulle et variance unitaire, ce qui stabilise les gradients sans avoir à régler une échelle de récompense.

L'objectif complet ressemble à PPO : un ratio de vraisemblance clippé (pour éviter des pas trop grands) plus un terme de divergence KL vers le modèle de référence (pour empêcher la politique de trop dériver, donc de « casser » le langage acquis au pré-entraînement) :

maximiser  E[ min( ρ_i · A_i,  clip(ρ_i, 1−ε, 1+ε) · A_i ) ]  −  β · KL(π_θ ‖ π_ref)
   avec    ρ_i = π_θ(o_i | q) / π_ancienne(o_i | q)        (ratio d'importance)

Deux garde-fous, donc : le clip borne l'amplitude d'une mise à jour, et le KL ancre la politique au modèle de référence. Tous deux contrent l'instabilité classique du RL sur LLM (effondrement de diversité, oubli catastrophique).

Figure : la boucle RL avec récompense vérifiable (style GRPO / DeepSeek-R1).

L'« aha moment »

Le moment le plus cité du papier : au cours de l'entraînement, le modèle se met de lui-même à allouer plus de temps de réflexion en réévaluant son approche initiale — il écrit littéralement quelque chose comme « attends, vérifions cette étape ». Personne ne lui a appris cette stratégie ; elle émerge parce que réfléchir davantage rapporte plus de récompense. C'est la démonstration que de bonnes incitations suffisent à faire apparaître des stratégies de résolution avancées.

Un corollaire mesurable accompagne ce moment : la longueur moyenne des traces croît au fil du RL. Le modèle apprend, sans qu'on le lui dise, que dépenser plus de jetons sur les problèmes durs paie — c'est l'émergence in situ de la loi de scaling à l'inférence, observée pendant l'entraînement.

Récompense : vérifiable d'abord, modélisée ensuite

La force de cette recette tient à la récompense vérifiable : en maths et en code, on sait dire de façon fiable si la réponse est juste (exécuter les tests, comparer le résultat). Pour les domaines ouverts (rédaction, dialogue), il faut un modèle de récompense appris — plus fragile, et exposé au reward hacking (le modèle optimise le score sans résoudre la tâche). DeepSeek a évité les récompenses neuronales sur le raisonnement pur précisément pour ne pas se faire pirater le signal.

Sous-tendant tout cela, le concept de RLVR (Reinforcement Learning from Verifiable Rewards) : remplacer le juge humain/neuronal par une fonction de vérification déterministe (exécuteur de tests, vérificateur formel, comparaison à la vérité terrain). C'est dense, fiable, et impossible à flatter — mais cantonné aux domaines où une vérité automatique existe. Étendre le raisonnement aux domaines « mous » reste un problème ouvert, précisément parce que la récompense y redevient apprise et donc piratable.

Stratégies à l'inférence : du vote à la recherche

Une fois le modèle entraîné, plusieurs leviers permettent d'investir du calcul au moment de répondre. On les classe en deux familles (voir première figure) : parallèle (échantillons indépendants puis sélection) et séquentiel (une seule trace, plus longue).

Self-consistency (vote majoritaire)

La technique la plus simple : échantillonner N chaînes de pensée distinctes (température > 0), extraire la réponse finale de chacune, et garder la plus fréquente. Plusieurs chemins de raisonnement convergent souvent vers la bonne réponse même s'ils diffèrent ; le vote filtre les erreurs isolées. C'est purement parallèle, trivial à implémenter, et très efficace sur les tâches à réponse unique vérifiable.

Le présupposé est statistique : si la bonne réponse est le mode de la distribution des sorties (chaque erreur étant idiosyncratique), agréger N tirages fait converger l'estimateur vers ce mode. D'où ses limites : sur un problème où le modèle se trompe systématiquement de la même façon, le vote amplifie l'erreur au lieu de la corriger ; et sur les tâches à réponse libre (pas de forme canonique à comparer), le vote n'est tout simplement pas applicable.

Best-of-N avec vérificateur

Plutôt que voter, on note chaque candidat avec un vérificateur (un modèle entraîné à juger la qualité) et on garde le mieux noté. Deux granularités :

• ORM (Outcome Reward Model) : juge la réponse finale, verdict binaire « correct / incorrect ».
• PRM (Process Reward Model) : juge chaque étape du raisonnement, donnant un signal dense. Un PRM repère où la trace dérape, ce qui guide une sélection plus fine et la recherche.

Les PRM sont au cœur du résultat de Snell et al. : chercher contre un vérificateur par étape (process-based) est nettement plus efficace que de simplement multiplier les échantillons.

Comment entraîner un PRM sans étiqueter chaque étape à la main ? L'astuce courante est le roll-out par étape : depuis un préfixe de raisonnement, on échantillonne plusieurs continuations jusqu'à la réponse finale ; la proportion de continuations qui aboutissent à la bonne réponse devient une étiquette de valeur pour ce préfixe. On obtient ainsi un signal d'étape sans annotation humaine — au prix de beaucoup de calcul de génération.

Recherche arborescente (Tree of Thoughts)

On peut transformer le raisonnement en recherche. Au lieu d'une trace linéaire, on explore un arbre d'étapes possibles : à chaque nœud, le modèle propose plusieurs continuations, un vérificateur (ou PRM) les évalue, et on étend les branches prometteuses (beam search, lookahead, voire MCTS). C'est plus coûteux mais permet de revenir en arrière proprement et d'éviter les impasses — utile sur les problèmes où une mauvaise première étape condamne tout.

Trois variantes méritent d'être distinguées :

• Beam search guidé par PRM : on garde les b meilleurs préfixes à chaque profondeur. Très efficace à budget modéré, mais sujet à la sur-optimisation du vérificateur sur les questions faciles (on optimise le score du PRM, pas la vérité).
• Lookahead : avant de noter un nœud, on simule k étapes en avant pour évaluer son potentiel réel. Plus informatif mais coûteux — souvent dominé par le simple beam search à budget égal.
• MCTS : équilibre exploration/exploitation par essais successifs ; puissant mais lourd à implémenter et à régler.

La leçon de Snell : le beam search bat le best-of-N à petit budget, mais ses gains s'érodent à mesure qu'on échantillonne plus, finissant parfois sous le best-of-N — preuve qu'aucune méthode ne domine partout.

Budget forcing et jetons de « réflexion »

Côté séquentiel, s1 (arXiv 2501.19393) propose le budget forcing, d'une simplicité désarmante. Pour faire réfléchir plus : quand le modèle tente de clore sa réflexion, on supprime le jeton de fin et on insère « Wait » — ce qui le pousse à reprendre et souvent à corriger une erreur. Pour faire réfléchir moins : on force la fin une fois le budget atteint. On contrôle ainsi directement le nombre de jetons de « thinking » dépensés. Les auteurs montrent que ce budget forcing séquentiel passe mieux à l'échelle que le vote majoritaire, car les étapes tardives s'appuient sur les précédentes.

Détail frappant : s1 atteint ce résultat après un SFT sur seulement ~1 000 exemples soigneusement choisis, sans aucun RL. Cela suggère qu'une grande part du « savoir-raisonner » est déjà latente dans le modèle de base, et que l'entraînement sert surtout à activer un format de réflexion exploitable — pas à enseigner les mathématiques de zéro.

Tableau récapitulatif

Un aide-mémoire pour choisir :

Stratégie	Famille	Besoin d'un vérificateur	Idéale pour
Self-consistency	Parallèle	Non (vote)	Réponse unique vérifiable
Best-of-N + ORM/PRM	Parallèle	Oui	Math, code, QA factuelle
Tree of Thoughts	Hybride	Oui (ou heuristique)	Problèmes exploratoires
Budget forcing	Séquentiel	Non	Réflexion profonde itérative

Aucune de ces approches n'est universellement meilleure : le bon choix dépend de la tâche, du budget, et de la possibilité de vérifier la réponse.

Lois de scaling : le calcul contre la précision

Le fait empirique central : la précision croît avec le calcul d'inférence, souvent de façon log-linéaire, jusqu'à une saturation. Mais la pente et le plafond dépendent de la méthode et de la difficulté :

• Sur les questions faciles, raffiner une bonne réponse de départ (séquentiel) suffit ; multiplier les échantillons gaspille du calcul.
• Sur les questions dures, il faut une recherche plus large (parallèle + vérificateur) car la première piste est souvent fausse.

D'où la stratégie compute-optimale : estimer la difficulté, puis choisir méthode et budget en conséquence. C'est ce qui donne les fameux gains de 4× et le dépassement d'un modèle 14× plus gros. La leçon stratégique : pour une partie des charges, mieux vaut investir à l'inférence qu'agrandir le modèle — mais pas pour toutes.

Séquentiel ou parallèle : un arbitrage par difficulté

Snell formalise l'idée par des bins de difficulté. Sur les bins faciles, le raffinement séquentiel domine : le modèle part près de la bonne réponse et l'affine. Sur les bins durs, le parallèle (échantillonner large puis sélectionner) domine : la diversité compte plus que la profondeur, car aucune trace unique n'aboutit de façon fiable. La vraie stratégie compute-optimale combine les deux : pour un budget total fixé, on choisit le ratio séquentiel/parallèle selon la difficulté estimée du prompt.

budget total B = (nb d'échantillons N) × (longueur par trace L)

facile  →  N petit, L grand    (peu de pistes, on creuse)
difficile →  N grand, L modéré  (beaucoup de pistes, on ratisse)

D'où une conséquence pratique : sans estimateur de difficulté, on ne sait pas répartir B — et l'on retombe sur le best-of-N uniforme, jusqu'à 4× moins efficace.

Un exemple concret de chaîne de pensée

Pour rendre tout cela tangible, voici à quoi ressemble une trace produite par un modèle de raisonnement sur un petit problème. Notez l'auto-correction au milieu — le « wait » caractéristique.

Question : un train parcourt 120 km en 1 h 30. Quelle est sa vitesse moyenne ?

<think>
Vitesse = distance / temps.
1 h 30 = 1,5 h.
120 / 1,5 = 80... attends, vérifions : 80 × 1,5 = 120. OK.
Donc 80 km/h.
</think>

Réponse : 80 km/h.

Avec self-consistency, on échantillonnerait plusieurs telles traces ; la réponse « 80 km/h » sortirait majoritaire. Avec un PRM, on noterait chaque étape (« 1 h 30 = 1,5 h » est correct, etc.) pour détecter une trace qui dérape dès la conversion d'unités.

Pour illustrer le budget forcing, supposons que le modèle veuille conclure trop tôt sur un problème plus dur ; on intercepte la fin et on relance :

<think>
… donc la réponse est 42.
</think>          ← le décodeur veut s'arrêter ici
Wait,            ← on supprime la fin et on injecte « Wait »
revérifions le cas où n est impair…  ← le modèle reprend et corrige

Le même levier, inversé, sert à plafonner : dès que le quota de jetons « thinking » est atteint, on force la balise de fin et on demande la réponse, ce qui borne coût et latence.

Distiller le raisonnement dans des modèles plus petits

Faire tourner un gros modèle de raisonnement coûte cher. Une voie élégante : distiller. DeepSeek a généré ~800 000 traces de raisonnement avec R1, puis a fine-tuné par SFT des modèles plus petits (Qwen, Llama) sur ces traces. Surprise : ces petits modèles distillés héritent de bonnes capacités de raisonnement sans avoir fait de RL eux-mêmes — le RL coûteux est fait une fois, sur le grand modèle, puis transféré.

Un résultat marquant du papier : appliquer directement le RL à un petit modèle de base donne moins bien que distiller depuis R1. Autrement dit, le grand modèle a découvert des schémas de raisonnement qu'un petit modèle, faute de capacité, ne retrouverait pas seul par RL — mais qu'il peut imiter une fois explicités sous forme de traces. La distillation transfère donc une découverte, pas seulement des réponses.

Limites de la distillation :

• Les petits modèles digèrent mal des traces trop longues ou trop formelles ; un SFT naïf peut même dégrader leur taux de résolution.
• Ils héritent des défauts du maître : tendance à l'overthinking et aux hallucinations.
• Ils sont souvent moins fidèles : un modèle distillé articule certains indices de son raisonnement bien moins souvent que R1 lui-même.

Des approches plus fines (par exemple générer des traces variées par recherche arborescente, puis filtrer par vérification avant le SFT) atténuent ces problèmes, mais la distillation reste un compromis : on gagne en coût ce qu'on perd un peu en robustesse et en transparence. En pratique, beaucoup de déploiements combinent : un modèle distillé pour le gros du trafic, et un appel au grand modèle (ou un budget de réflexion accru) réservé aux requêtes que le routeur juge difficiles.

Coûts, latence et limites

Le test-time compute n'est pas gratuit. Ses contreparties sont réelles :

• Coût et latence. Multiplier les jetons de réflexion multiplie le coût par requête et le délai de réponse. Une question triviale traitée comme un problème olympique, c'est de l'argent et des secondes gaspillés.
• Overthinking. Les modèles de raisonnement sur-réfléchissent parfois : ils déroulent des pages de CoT sur une question simple, voire se talent eux-mêmes en partant d'une bonne intuition. D'où l'intérêt de contrôler le budget.
• Fidélité du raisonnement (faithfulness). Point délicat et contre-intuitif : la chaîne de pensée affichée ne reflète pas toujours le vrai calcul interne du modèle. Des études montrent que les modèles peuvent produire un raisonnement plausible qui rationalise une réponse décidée autrement, sans mentionner les indices réellement utilisés. Une CoT lisible n'est donc pas une garantie de transparence ni de correction.
• Reward hacking. Hors récompense vérifiable, le modèle peut apprendre à plaire au vérificateur plutôt qu'à résoudre le problème.
• Sur-optimisation du vérificateur. Même avec un PRM, pousser la recherche trop loin optimise le score du vérificateur plutôt que la vérité — d'où l'effondrement du beam search à gros budget sur les questions faciles.
• Saturation. Au-delà d'un certain budget, chaque jeton supplémentaire rapporte de moins en moins — il faut savoir s'arrêter.
• Variance. Deux exécutions sur la même question peuvent emprunter des chemins très différents ; le vote ou le best-of-N stabilisent la sortie mais multiplient le coût.

Ces limites ne disqualifient pas le raisonnement : elles cadrent son usage. Un système mûr décide quand raisonner, pas seulement comment.

En pratique : quand activer le raisonnement

Quelques repères pour un système réel :

• Router selon la difficulté. Détecter les requêtes simples et les traiter en mode rapide ; réserver le raisonnement long aux problèmes durs.
• Choisir la famille selon la tâche. Vérification possible (math, code, QA factuelle) → best-of-N + vérificateur. Réponse à chemin unique → self-consistency. Problème exploratoire → recherche arborescente.
• Plafonner le budget. Fixer un nombre maximal de jetons de réflexion pour borner coût et latence ; le budget forcing est un levier direct.
• Distiller pour la production. Quand le volume est élevé, distiller le raisonnement d'un grand modèle dans un plus petit réduit fortement le coût unitaire.
• Ne pas confondre lisible et fiable. Traiter le CoT comme une aide au raisonnement, pas comme une preuve d'audit — vérifier les conclusions indépendamment quand l'enjeu est élevé.
• Mesurer, pas supposer. Tracer la précision en fonction du budget de jetons sur vos données : la courbe vous dira où se situe la saturation, et donc le budget par défaut à fixer.

Ces principes se combinent : un routeur de difficulté en amont, une famille de stratégie adaptée par type de tâche, un plafond de budget, et un modèle distillé pour le gros du trafic forment une architecture d'inférence à la fois performante et maîtrisée en coût.

Checklist de mise en production

Pour passer du prototype au service, une liste de contrôle concrète :

• Estimer la difficulté en amont (longueur, mots-clés, score d'un petit classifieur, ou désaccord d'un mini-vote) pour router rapide vs. réflexion.
• Borner les jetons « thinking » par requête (budget dur) et couper au-delà, pour garantir un SLA de latence.
• Choisir le sélecteur : vote majoritaire si la réponse a une forme canonique ; vérificateur (ORM/PRM) si la qualité doit être jugée ; rien si une seule trace suffit.
• Surveiller le reward hacking hors domaines vérifiables : auditer un échantillon de sorties, pas seulement le score du vérificateur.
• Cacher les réponses des requêtes fréquentes pour ne pas re-payer la réflexion à chaque fois.
• Tracer la courbe précision/budget sur vos données et fixer le budget par défaut avant la saturation, pas après.
• Prévoir un repli : si la réflexion dépasse le budget sans converger, renvoyer la meilleure réponse partielle plutôt que d'attendre indéfiniment.
• Journaliser budget consommé, méthode et issue par requête, pour mesurer le coût réel et ajuster le routeur.

En résumé

Les modèles de raisonnement transforment le calcul d'inférence en levier de qualité : on apprend au modèle, par RL et récompense vérifiable, à penser plus quand le problème l'exige (o1/o3, DeepSeek-R1 et son GRPO, l'« aha moment »). À l'inférence, un éventail de stratégies — vote majoritaire, best-of-N avec PRM, recherche arborescente, budget forcing — permet d'échanger des FLOPs contre de la précision, de façon idéalement compute-optimale. Le tout se distille dans des modèles plus petits pour la production.

Mais le calcul à l'inférence se paie en coût, en latence, et bute sur l'overthinking et la fidélité incertaine du raisonnement affiché : la vraie compétence n'est pas de réfléchir le plus, mais de réfléchir juste assez.