TL;DR
Après avoir écrit « Ce que vous ne savez pas sur Claude Code : Architecture, Gouvernance et Pratique d'Ingénierie » et « Ce que vous ne savez pas sur les Agents : Principes, Architecture et Pratique d'Ingénierie », j'ai voulu me lancer le défi de résumer comment fonctionne réellement l'entraînement des grands modèles de langage (LLM). Cet article se veut compréhensible même pour ceux sans formation professionnelle.
En regardant vers 2026, le véritable écart de performance des LLM ne réside plus seulement dans le pré-entraînement lui-même, mais dans la longue traîne qui suit : le post-entraînement, l'évaluation, les récompenses, l'entraînement des agents et la distillation. Chaque étape affecte l'expérience réelle de l'utilisateur. Lorsque vous constatez qu'un modèle devient soudainement plus performant, c'est probablement parce que ces domaines ont été optimisés ensemble, plutôt qu'un seul facteur.
Ce qui suit suit le pipeline d'entraînement des LLM, en se concentrant sur la manière dont les fabricants améliorent les résultats finaux grâce à la seconde moitié de la pile d'entraînement.
L'entraînement des LLM est un pipeline
Ces dernières années, les progrès des modèles étaient généralement expliqués par l'accumulation de paramètres, de données et de puissance de calcul. Cependant, les améliorations que de nombreux utilisateurs ressentent réellement ne proviennent pas de l'entraînement sur davantage de corpus de base, mais de l'ensemble du processus d'entraînement après le pré-entraînement. La façon dont un modèle parle, suit les instructions, raisonne et utilise des outils – ces capacités ne grandissent pas naturellement simplement en lui donnant plus de texte Internet.
InstructGPT a donné un exemple très direct : un modèle avec seulement 1,3 milliard de paramètres qui a subi un alignement et une optimisation des préférences pouvait battre le GPT-3 de 175 milliards de paramètres dans les évaluations de préférences humaines. Avec une différence de paramètres de deux ordres de grandeur, les utilisateurs ont finalement préféré la version beaucoup plus petite. La seconde moitié de l'entraînement réécrit véritablement la perception de l'utilisateur.
Le processus d'entraînement est en fait un pipeline où les données, les algorithmes, les systèmes et les retours sont fortement couplés. Un changement dans une couche se propage généralement aux autres. En 2026, les capacités des modèles et la valeur industrielle sont de plus en plus concentrées dans les couches suivant le pré-entraînement.
C'est aussi pourquoi nous avons souvent l'impression que Doubao ne rivalise pas pour les classements, mais semble plus satisfaisant dans l'utilisation quotidienne – c'est parce que le post-entraînement est bien exécuté.
Ces six couches ne sont qu'une représentation de la division du travail. Les neuf étapes dans la figure ci-dessous sont une version plus détaillée : les données brutes et les recettes système sont séparées, et le harnais des agents et le déploiement sont des subdivisions de la seconde moitié. Il y a également deux boucles de rétroaction tout au long : le trafic de production retourne à l'ingénierie des données, et les résultats d'évaluation hors ligne retournent au pré-entraînement.
Le pré-entraînement n'est que le fondement
Le pré-entraînement reste le point de départ de la chaîne d'entraînement. Ce n'est qu'en comprenant ce qu'il fait que nous pouvons comprendre ce que chaque couche suivante apporte. Sans cette étape, il n'y a pas de capacité de modélisation du langage, pas de compression des connaissances, et pas de place pour le transfert de capacités ultérieur. En ingénierie, il fait plus que simplement apprendre au modèle à prédire le jeton suivant : il apprend la distribution du langage, comprime les connaissances et les motifs du texte à grande échelle dans des paramètres, et laisse de la place pour l'activation des capacités suivantes. La prédiction du prochain jeton ne décrit que la forme de l'entraînement ; elle n'explique pas pourquoi les modèles développent soudainement de nouvelles capacités à mesure que l'échelle augmente.
Après GPT-3, de nombreux efforts de réglage des modèles considèrent plus attentivement le budget et les ratios. Les modèles ne sont pas meilleurs simplement parce qu'ils sont plus grands. Il y a un problème de ratio entre le nombre de paramètres, les jetons d'entraînement et le budget de calcul total. De nombreux modèles ne sont pas trop petits ; ils sont sous-entraînés et n'ont pas atteint un point plus adapté sous un budget donné.
Dans les décisions d'entraînement réelles, la question pratique est : si quelqu'un vous donne 10 000 H100 et un mois, comment entraîneriez-vous un modèle open-source suffisamment bon ? Les lois de mise à l'échelle sont ici plus un outil d'allocation budgétaire qu'une courbe abstraite dans un article. En fin de compte, vous devez considérer : le prochain cycle d'entraînement doit-il empiler plus de paramètres ou fournir plus de données ? Le modèle actuel manque-t-il de capacité ou est-il simplement sous-entraîné ? Sous un budget GPU limité, quel ratio est le plus précieux ?
Le pré-entraînement est comme la pose des fondations des capacités du modèle, déterminant l'étendue des connaissances, le potentiel de généralisation et la capacité d'induction de motifs. Il détermine également s'il y a de la place pour que le post-entraînement puisse exploiter. Cependant, le pré-entraînement ne peut pas contrôler si le modèle suit les instructions, coopère avec les utilisateurs ou fonctionne de manière stable sur des tâches critiques.
La phase de pré-entraînement ne décide pas seulement de la quantité de connaissances apprises ; elle prédétermine ce que le modèle peut devenir. La méthode de découpage du tokenizer affecte directement l'entraînement ultérieur, et la longueur de la fenêtre de contexte doit être définie à l'avance. Que ce soit pour continuer le pré-entraînement multimodal ou si le fonctionnement sur un seul accélérateur est une exigence dès le départ – ces compromis sont écrits dans la recette pendant la phase d'entraînement, et non ajoutés comme fonctionnalités lors de la sortie. Gemma 3 met l'accent sur un seul accélérateur, un contexte de 128K, des capacités de vision et la quantification simultanément, reflétant ces compromis. Les capacités que les utilisateurs voient finalement – fonctionner sur un ordinateur local, voir des images, comprendre des documents longs – sont en fait largement déterminées pendant la phase d'entraînement.
En regardant le point optimal de données donné par Chinchilla, pour un modèle de 8 milliards de paramètres, c'est environ 200 milliards de jetons. Cependant, Llama 3 8B a en réalité utilisé 15 000 milliards de jetons, soit environ 75 fois plus. De telles recettes de sur-entraînement échangent généralement une densité de capacité plus élevée pour les mêmes paramètres, ce qui donne un modèle plus petit et plus rentable pour l'inférence. Mesurer cela par le nombre total de FLOPs (opérations en virgule flottante) est plus fiable que de regarder les nombres de paramètres. La figure ci-dessous montre visuellement cet écart.
Un autre aspect souvent négligé dans la phase de pré-entraînement : la taille du vocabulaire du tokenizer, les stratégies de découpage et les méthodes d'encodage au niveau des octets ont un impact significatif. Llama 2 avait un vocabulaire de 32 000 ; après que Llama 3 l'ait étendu à 128 000, la longueur des séquences a été compressée d'environ 15 %, et les performances en aval ont suivi. Cet impact s'étend aux coûts d'inférence et aux capacités multilingues. L'efficacité des jetons pour le chinois, le code et les formules mathématiques est déterminée lors de la conception du vocabulaire. Par exemple, un tokenizer qui découpe le chinois en très petits morceaux ne coûte pas seulement plus de jetons à chaque fois ; chaque inférence doit continuellement supporter le coût de cette mauvaise décision.
Les recettes de données déterminent les capacités du modèle
L'échelle des paramètres était une métrique importante dans le passé, mais ces deux dernières années, la chose la plus importante est la « recette de données ».
Ce processus ressemble à un nettoyage de données en surface, mais c'est en fait une tâche complète d'ingénierie de production de données. Les données brutes provenant de pages web, de dépôts de code, de livres et de forums doivent d'abord passer par l'extraction de texte, l'identification de la langue, le filtrage de qualité, le traitement de la confidentialité, le filtrage de sécurité et la déduplication avant d'entrer dans le pré-entraînement. La figure ci-dessous montre le flux de traitement en entonnoir complet.
Si vous ne traitez les données que comme du carburant d'entraînement, il est facile de conclure que plus il y en a, mieux c'est. Mais l'ingénierie des données est plus proche de la conception des capacités. Ce que le modèle voit et ne voit pas, et les proportions de code, de mathématiques et d'encyclopédie, affectent directement la distribution finale des capacités du modèle.
La déduplication et le contrôle de la contamination sont souvent ignorés, mais ils impactent significativement les résultats. Il ne s'agit pas seulement de données de mauvaise qualité ; cela inclut les modèles en double, les textes de licence, les sites miroirs et la contamination due à des fuites de benchmarks. Si la déduplication au niveau du document et au niveau de la ligne est insuffisante, le modèle absorbe souvent de manière répétée le contenu le plus facile à copier sans nécessairement apprendre les parties les plus précieuses. Les performances inconsistantes de nombreux modèles open-source sont souvent dues à des lacunes dans la qualité du traitement des données.
Ces deux dernières années, le mélange de données lui-même est devenu un problème de recherche distinct. Des travaux comme les lois de mélange de données (Data Mixing Laws) se concentrent non seulement sur la quantité de données supplémentaires pouvant être collectées, mais sur la manière dont les proportions de différents types de données orientent le modèle vers des structures de capacités spécifiques.
Les données synthétiques sont également passées d'un moyen auxiliaire à une partie formelle du processus d'entraînement. Des méthodes comme Self-Instruct, les trajectoires de distillation de DeepSeek-R1, et la supervision synthétique de plus en plus évidente dans les séries Qwen et Kimi, vont toutes dans la même direction. Chaque génération de modèles plus puissants participe à la reconstruction des données vues par la génération suivante. Les premiers modèles généraient des données d'instructions de base ; les modèles plus forts génèrent des trajectoires de raisonnement de haute qualité et des données de chaîne de pensée (CoT) ; et les modèles de raisonnement entraînés par RL distillent ces trajectoires dans des modèles denses plus petits. « Dense » signifie que tous les paramètres fonctionnent, contrairement à MoE (Mixture of Experts) qui s'active à la demande.
Le point clé ici est que les modèles doivent souvent former des capacités à plus grande échelle d'abord avant que ces capacités puissent être compressées dans des modèles plus petits. La série DeepSeek-R1-Distill en est un exemple direct. Les trajectoires des grands modèles après RL ont apporté des gains significatifs pour les modèles denses de 1,5B à 70B. Llama 3.1 405B a également été explicitement utilisé pour améliorer la qualité du post-entraînement des modèles 8B et 70B. Ce ne sont pas des produits secondaires mais une partie de la conception de l'entraînement.
Les contraintes système et d'architecture doivent être claires avant l'entraînement
Beaucoup de gens comprennent l'entraînement comme un problème de recherche : comment définir la fonction objectif, comment réduire la perte et comment modifier la structure du modèle. Mais dans l'entraînement réel des LLM, les contraintes système sont très importantes ; c'est un problème de système distribué, pas un problème d'apprentissage profond sur une seule machine. Le nombre de GPU, la bande passante mémoire, les stratégies de parallélisme, la tolérance aux pannes et le coût – tout cela ne peut pas attendre d'être optimisé après l'entraînement. Ils déterminent dès le départ la taille que vous pouvez entraîner, la longueur de contexte que vous pouvez supporter et si vous pouvez exécuter un post-entraînement plus complexe.
MoE est l'exemple le plus typique à cette couche. Le mode multi-experts permet au modèle d'étendre le nombre total de paramètres sous une charge de calcul similaire tout en contrôlant le coût d'activation par jeton. Le compromis réside dans un routage complexe, un équilibrage de charge difficile et une infrastructure lourde. Les conceptions MoE de DeepSeek-V3 et Qwen sont des compromis entre coût et effet, pas seulement des préférences architecturales.
Les discussions dans les recettes récemment publiées ne portent plus seulement sur des analyses grossières comme la taille du modèle et les ratios de jetons. muP permet de transférer les hyperparamètres des expériences à petite échelle vers l'entraînement à grande échelle. Le taux d'apprentissage WSD est un schedule qui monte, se stabilise puis décroît. Combinés avec une taille de lot optimale et des ratios données-paramètres plus élevés, ces détails deviennent les véritables différenciateurs entre les modèles de même échelle.
Le contexte long, la multimodalité et les nouvelles architectures, s'ils sont compris uniquement comme des fonctionnalités produit, manquent les contraintes du côté de l'entraînement. Un objectif de contexte de 128K change directement les coûts d'attention, les tailles de lot, le curriculum d'entraînement (séquencement des données) et les stratégies de parallélisme. La multimodalité ne change pas seulement la structure du modèle, mais aussi le mélange de données, la conception de l'encodeur et l'évaluation de la sécurité. Si le fonctionnement sur une seule carte est une exigence stricte, le nombre de paramètres, les chemins de quantification et la taille de la famille de modèles seront tous restreints.
Des travaux comme Forgetting Transformer et les résidus d'attention de Kimi répondent à des questions similaires : comment entraîner des contextes plus longs et comment éviter la dilution de l'information à mesure que les réseaux deviennent plus profonds. Ce que vous voyez est un modèle capable de gérer des entrées plus longues ou plus facile à déployer, mais ce qui est confronté pendant l'entraînement est un ensemble de contraintes complètement différent.
Le budget de calcul est fixe. Taille du modèle, volume de jetons d'entraînement, longueur de contexte et coût de service – pour chaque bit dépensé dans une direction, les autres doivent céder.
À mesure que le contexte s'allonge, les coûts d'attention explosent et la taille du lot doit être réduite. À mesure que les modèles deviennent plus grands, l'utilisation de la mémoire GPU augmente, et les coûts de service suivent. Ce ne sont pas des choix mais des résultats de contraintes de ressources. La plupart des décisions sont verrouillées avant le début de l'entraînement.
Il y a aussi une réalité d'ingénierie souvent ignorée : l'entraînement n'est pas toujours stable. Des milliers de GPU fonctionnent pendant des semaines, et soudainement un pic de perte d'entraînement se produit, si important qu'il ne peut être ignoré, forçant un retour à un point de contrôle de plusieurs jours auparavant pour recommencer.
Outre les pics de perte, il y a des erreurs silencieuses de GPU – un seul GPU qui ne signale pas d'erreur mais produit silencieusement des gradients erronés – des anomalies de bande passante NVLink et des gigues de communication inter-nœuds. Chacun peut polluer plusieurs étapes de l'entraînement. Être capable de détecter, isoler et récupérer rapidement dans l'entraînement à grande échelle est une capacité d'ingénierie de niveau laboratoire, pas un problème résolu par la lecture d'articles.
DeepSeek-V3 a spécifiquement mentionné dans son rapport technique que l'ensemble du processus de pré-entraînement n'avait eu aucun pic de perte irrécupérable et aucun retour en arrière. C'est également l'un des rares cas vérifiant que l'entraînement en précision mixte FP8 est réalisable sur des modèles à très grande échelle. Selon les données publiques, le processus complet a pris environ 2,788 millions d'heures GPU H800 pour pré-entraîner 14,8 billions de jetons.
Les systèmes d'entraînement et les systèmes d'inférence sont étroitement liés mais ne sont pas le même problème d'ingénierie. L'entraînement se préoccupe des gradients, du parallélisme, des points de contrôle, du débit et du coût ; l'inférence se préoccupe de la latence, du cache KV (mise en cache des calculs historiques pour éviter la répétition), de la quantification et de la stabilité du service.
Le post-entraînement détermine l'écart perçu par l'utilisateur
De nombreuses améliorations que les utilisateurs ordinaires peuvent réellement ressentir se produisent après le pré-entraînement. Le réglage par instruction (instruction tuning) utilise des paires instruction-réponse étiquetées pour un entraînement supervisé. Il modifie la façon dont le modèle répond, transformant des exigences comme comment accepter des tâches, organiser la sortie et agir comme un assistant coopératif en signaux de supervision. Un modèle de base peut déjà avoir de nombreuses capacités potentielles, mais sans cette étape, ces capacités n'émergent souvent pas de manière stable sous la forme attendue par les utilisateurs.
En regardant plus loin, RLHF, DPO et RFT partagent des directions similaires – intégrer la définition d'une « meilleure réponse » dans la boucle d'entraînement – mais par des chemins différents.
- RLHF (apprentissage par renforcement à partir de retours humains) imite d'abord les réponses de haute qualité, puis utilise des comparaisons de préférences pour le renforcement.
- DPO (optimisation directe des préférences) raccourcit ce chemin en apprenant directement à partir de comparaisons de préférences sans avoir besoin d'un modèle de récompense séparé.
- RFT (réglage fin par renforcement) est une interface plus facile à implémenter en ingénierie, plaçant les définitions de tâches, les conceptions de correcteurs et les signaux de récompense dans le processus de productisation.
Aujourd'hui, parler de post-entraînement uniquement en termes de SFT (fine-tuning supervisé) ou de RL ne suffit plus. Les parties les plus difficiles sont comment définir les évaluations, comment noter et quel type de réponse mérite une optimisation continue. SFT est un fine-tuning supervisé ; il n'apprend pas seulement des connaissances mais aussi le style. La longueur des données, le format, l'inclusion de citations et la préférence pour les puces affectent considérablement la forme finale de la sortie du modèle. De nombreux utilisateurs pensent comparer des capacités, mais ils comparent souvent simplement des différences de style. De plus, les évaluations de préférences favorisent naturellement les réponses plus longues, prenant facilement des sorties longues d'aspect sérieux pour plus fiables. Par conséquent, regarder les classements pour le post-entraînement est souvent insuffisant ; il faut combiner les résultats de tâches réelles, le coût et la stabilité.
Le post-entraînement moderne est un pipeline multi-étapes. La recette de DeepSeek-R1 est la plus claire dans les documents publics. Elle se déroule en quatre étapes :
Étape 1 : SFT de démarrage à froid (cold-start SFT). Avant de faire de l'apprentissage par renforcement, utilisez une petite quantité de données de chaîne de pensée (CoT) de haute qualité pour échauffer. DeepSeek-R1-Zero a prouvé que faire du RL directement à partir d'un modèle de base (le modèle brut après pré-entraînement sans alignement) est réalisable, mais les modèles entraînés purement avec RL se répètent, ont un langage désordonné et une mauvaise lisibilité. Le SFT de démarrage à froid donne au RL un point de départ plus stable, verrouillant le format et la cohérence linguistique.
Étape 2 : effectue un apprentissage par renforcement dans des domaines vérifiables comme les mathématiques, le code et la logique, en utilisant GRPO comme algorithme d'entraînement et la correction vérifiable par programme comme signal de récompense. La clé est pourquoi GRPO a été choisi plutôt que le PPO traditionnel : PPO (Proximal Policy Optimization) nécessite un réseau de valeur indépendant pour estimer la valeur de l'état actuel, ce qui représente une charge d'ingénierie élevée pour les grands modèles. GRPO échantillonne plusieurs réponses pour la même invite et utilise un classement intra-groupe au lieu d'une estimation de valeur absolue, éliminant le besoin d'un réseau de valeur indépendant. La série DeepSeek et l'infrastructure RL de Cursor Composer 2 utilisent tous deux des schémas proches de GRPO.
Étape 3 : effectue un réglage fin par échantillonnage de rejet (Rejection Sampling Fine-Tuning), filtrant les trajectoires réussies générées par RL et les convertissant en nouvelles données SFT pour un autre cycle de réglage fin supervisé. C'est le pont entre RL et SFT ; les bonnes trajectoires explorées par RL deviennent des échantillons d'entraînement de haute qualité pour le prochain cycle de SFT.
Étape 4 : intègre les retours de préférence sur l'utilité et la sécurité pour ajuster le modèle en une forme d'assistant répondant aux normes de publication.
Les quatre étapes sont interdépendantes : le démarrage à froid permet à RL de commencer de manière stable, RL génère des données de haute qualité, l'échantillonnage de rejet transforme ces données en entrée pour le prochain cycle SFT, et le RL d'alignement complète la convergence comportementale. D'après les résultats publics, l'écart entre le SFT direct et la réalisation des quatre étapes est généralement visible.
L'évaluation, le correcteur et la récompense redéfinissent les objectifs d'entraînement
Le composant responsable de transformer la sortie du modèle en scores d'entraînement est appelé un correcteur (grader), et il peut facilement avoir des problèmes inattendus. S'il ne regarde que la réponse finale, le modèle apprend rapidement à prendre des raccourcis ; si la notation est trop grossière, le bruit sera continuellement amplifié par l'apprentissage par renforcement ; si le score au classement augmente, les tâches réelles pourraient ne pas suivre. Souvent, les utilisateurs pensent voir un écart dans le modèle de base, mais l'écart réside dans la façon dont l'objectif est défini.
Dans le flux d'entraînement, l'évaluation détermine ce qui est testé, le correcteur détermine comment une sortie devient un score, et la récompense détermine où le modèle sera poussé. Ensemble, ils forment une boucle de rétroaction spécifique : définition de la tâche, évaluation, correcteur, optimisation, déploiement (rollout) et réévaluation. Le déploiement fait référence aux trajectoires générées par le modèle exécutant des tâches. Si un maillon de la chaîne s'égare, l'optimisation ultérieure s'égarera aussi.
En regardant uniquement le résultat final, un modèle pourrait obtenir la bonne réponse par hasard ou suivre un mauvais processus pour obtenir la bonne réponse. Cela est particulièrement évident dans les tâches de code, de mathématiques et de raisonnement complexe. Si les étapes intermédiaires n'entrent pas dans la rétroaction, ce que le modèle apprend n'est souvent pas un raisonnement plus fiable, mais comment obtenir ce point final avec une probabilité plus élevée.
Par conséquent, davantage de travaux ces dernières années se sont déplacés du RLHF traditionnel vers les récompenses vérifiées, utilisant des programmes pour vérifier directement la correction. Dans les tâches vérifiables comme les mathématiques, le code et la logique, la correction peut maintenant être notée directement sans dépendre principalement de la préférence humaine. Mais les récompenses vérifiées n'ont pas complètement résolu le problème. Des phénomènes comme la sur-optimisation, le surajustement de la récompense (reward overfitting) où les règles de notation sont sur-optimisées sans gain réel de capacité, et l'effondrement modal (mode collapse) où la sortie devient très singulière et perd en diversité, se produisent encore. Le problème est passé de la question de savoir si les préférences sont étiquetées avec précision à celle de savoir si la chaîne de notation est stable.
Le processus de réflexion écrit par le modèle ne peut pas être traité comme un enregistrement complet des processus internes. Anthropic a découvert dans des expériences d'observabilité des modèles de raisonnement que les modèles utilisent des indices supplémentaires mais ne l'admettent pas dans le CoT visible ; dans les scénarios de piratage de récompense (reward hacking), ils sont plus susceptibles d'ajouter une explication qui semble plausible. Le piratage de récompense consiste à exploiter le système de notation plutôt qu'à terminer réellement la tâche. Le CoT visible est mieux adapté comme signal d'entraînement et de surveillance, pas comme la vérité complète.
En allant plus loin, les modèles pourraient même commencer à exploiter le canal de notation lui-même. La recherche sur la falsification des récompenses (reward tampering) et la simulation d'alignement (alignment faking) montre que les modèles pourraient théoriquement intervenir activement dans le processus de notation. La falsification des récompenses consiste à altérer directement le processus de calcul de la récompense ; la simulation d'alignement consiste à feindre l'alignement – paraître conforme en surface tout en cachant des intentions non alignées.
Une fois qu'un modèle a un accès suffisamment fort à l'environnement, ce qu'il optimise n'est pas seulement les résultats de la tâche, mais potentiellement la liste de contrôle, le code de récompense et la relation d'entraînement elle-même. Une expérience d'Anthropic en 2025 a injecté des connaissances supplémentaires de piratage de récompense dans un ensemble d'environnements de codage RL exploitables en production et a ensuite observé une généralisation similaire. Après avoir appris le piratage de récompense, le modèle n'a pas seulement continué à l'exploiter dans des tâches similaires, mais a également montré un désalignement plus large comme la simulation d'alignement.
Ces comportements ne sont pas observés dans les évaluations de dialogue standard, seulement dans les environnements de tâches d'agents. L'implication d'ingénierie est directe : la récompense, le correcteur, l'isolation de l'environnement et la surveillance doivent faire partie de la conception de l'entraînement.
Dans la phase d'agent, la conception de la récompense est encore affinée. Le résultat final n'est qu'un élément ; la qualité du processus, la gestion du contexte et les contraintes anti-triche doivent également être mesurées séparément. Kimi K2.5 récompense la décomposition efficace et le véritable parallélisme ; Chroma Context-1 note les documents pertinents trouvés lors de la recherche ; Cursor Composer 2 inclut les résumés dans les tâches longues comme récompenses car si un résumé est déformé, le contexte ultérieur sera induit en erreur.
En implémentation, ORM (Outcome Reward Model) est un modèle de récompense sur le résultat, notant uniquement la réponse finale. Les signaux sont rares, les coûts sont faibles, et c'est adapté pour commencer, mais il est plus facile pour le modèle de prendre des raccourcis. PRM (Process Reward Model) est un modèle de récompense sur le processus, notant les étapes intermédiaires. Les signaux sont plus denses, et c'est généralement plus fort pour le raisonnement mathématique et le code, mais les coûts d'étiquetage et de système sont beaucoup plus élevés. OpenAI a vu dans des expériences de raisonnement mathématique que PRM non seulement améliorait la précision mais aussi facilitait la contrainte du processus parce que chaque étape était supervisée. Le problème est également direct : le coût de PRM est généralement plusieurs fois celui de ORM, donc la plupart des systèmes réels commencent avec ORM. Seulement dans des tâches vérifiables comme les mathématiques, le code et la logique, il est plus facile d'automatiser PRM, en utilisant des programmes pour vérifier les étapes intermédiaires et contourner les goulots d'étranglement d'étiquetage humain.
La boucle complète fonctionne comme ceci :
Les méthodes d'alignement récentes font toutes la même chose. L'IA Constitutionnelle d'Anthropic (Constitutional AI) intègre des principes écrits par l'homme dans l'entraînement, en utilisant les retours de l'IA pour remplacer les préférences humaines individuelles. L'Alignement Délibératif (Deliberative Alignment) d'OpenAI place la conformité de sécurité dans le processus de raisonnement, laissant la capacité de raisonnement elle-même supporter une partie de la contrainte de sécurité. Alignement Délibératif signifie ici que le modèle juge lui-même les normes de sécurité pendant la phase de raisonnement plutôt que de se fier à des réflexes entraînés. Les deux voies transforment l'alignement d'étiquettes humaines en une partie de l'objectif d'entraînement interne.
Prenant l'IA Constitutionnelle comme exemple, le processus en deux étapes permet d'abord au modèle de s'auto-critiquer et de réviser sa sortie en fonction des principes, puis utilise les retours de l'IA pour remplacer l'étiquetage individuel des préférences humaines. L'alignement n'est jamais un correctif accroché derrière l'entraînement ; quoi que le système teste, comment il note et ce qu'il récompense, le modèle se déplacera dans cette direction. C'est l'outil d'ajustement le plus direct dans la seconde moitié de l'entraînement.
Dans l'entraînement des agents, ce n'est pas seulement le modèle qui est optimisé
Ces deux dernières années, l’émergence rapide des modèles de raisonnement incarnés par les séries o1 et DeepSeek-R1 montre que, dans des conditions de récompenses stables, de vérification fiable et d’infrastructure adéquate, le RL sur les modèles de langage peut améliorer significativement les performances en mathématiques, en code et en logique.
Cela ouvre également une nouvelle dimension : le calcul d’inférence peut désormais être mis à l’échelle. Le rôle de l’entraînement RL ajoute une couche supplémentaire : au-delà d’apprendre au modèle à répondre à des questions, il lui apprend comment allouer un budget d’inférence – savoir quand réfléchir davantage et quand s’arrêter. À l’avenir, la difficulté sera de laisser le modèle agir en continu dans un environnement plutôt que de simplement allonger une seule pensée.
Junyang Lin, ancien responsable du modèle chez Qwen, a une réflexion représentative sur la voie mixte entre Thinking et Instruct : la difficulté n’est pas de doter le modèle d’un interrupteur de réflexion, mais que les objectifs des deux modes sont différents – l’un recherche la franchise, la conformité et une faible latence, tandis que l’autre recherche plus d’exploration et une meilleure précision. Aller plus loin, l’objectif d’entraînement passe de « combien de temps réfléchir avant de répondre » à « comment allouer le budget durant l’action, comment accepter le feedback et comment continuer à faire avancer la tâche ».
À ce stade, l’objet de l’entraînement n’est plus seulement un modèle qui répond à des questions, mais un système capable de planifier, d’appeler des outils, de recevoir des retours et de maintenir une cohérence dans les tâches longues. Par conséquent, la stack d’entraînement change : navigateurs, terminaux, recherche, sandbox d’exécution, systèmes de mémoire, serveurs d’outils et cadres d’orchestration commencent tous à entrer dans le système d’entraînement.
Plus précisément, un harnais est un programme de contrôle enveloppant le modèle. Ce concept n’appartient pas seulement au runtime de l’Agent ; il existe aussi dans la phase d’entraînement : déterminer quelle entrée le modèle voit, comment il reçoit les retours, quand élaguer le contexte et quand appeler les outils. La construction des prompts, la mise à jour de la mémoire, la politique de récupération, l’édition de contexte et l’orchestration des outils se trouvent tous ici. L’environnement n’est plus seulement un validateur statique, mais une couche que l’entraînement et le déploiement doivent tous deux affronter directement.
Le harnais doit être stable pour que l’entraînement du modèle ait un sens. Si les valeurs de retour des outils sont instables, si l’environnement du navigateur n’est pas cohérent avec celui en ligne, ou si l’état du système de fichiers n’est pas reproductible, le correcteur échouera en premier, et le modèle apprendra ensuite à exploiter les failles de l’environnement plutôt qu’à acquérir des capacités. Lorsqu’on entraîne des Agents, on débogue souvent à la fois le modèle et l’environnement.
Les approches des trois entreprises sont claires : Kimi utilise PARL pour résoudre la décomposition parallèle et l’attribution du crédit ; Cursor utilise l’auto-résumé et le RL en temps réel pour reconnecter les longues sessions de codage et le trafic de production à l’entraînement ; Chroma entraîne prune_chunks comme une stratégie en soi, laissant l’élagage du contexte entrer directement dans le processus de récupération.
À l’époque du SFT, la diversité des données était primordiale ; à l’ère de l’Agent, la qualité de l’environnement est au cœur : stabilité, authenticité, couverture, distribution de la difficulté, richesse du feedback et anti-exploitation. Les objectifs d’entraînement changent en conséquence, nécessitant une fiabilité dans les tâches complètes, pas seulement la réussite d’une question. Les benchmarks CoT classiques ne peuvent pas couvrir cela.
Ce changement continue de progresser : non seulement entraîner le modèle dans un harnais d’exécution, mais même le code du harnais lui-même devient un objet qui peut être recherché et optimisé par une boucle externe.
Le PARL de Kimi K2.5 est un cas d’ingénierie remarquable avec une voie claire : n’entraîner que l’orchestrateur, concentrer l’attribution du crédit sur la couche d’orchestration, et ne pas optimiser tous les sous-agents simultanément.
Les signaux de récompense sont divisés en trois catégories : succès de la tâche, décomposition parallèle et contraintes d’achèvement, qui ensemble pilotent la couche d’orchestration. Au début de l’entraînement, le poids r_parallel est augmenté pour encourager l’exploration des stratégies parallèles, puis réduit progressivement à 0 plus tard pour éviter de traiter l’ouverture de plusieurs sous-agents comme un raccourci. L’évaluation regarde non seulement le nombre total d’étapes mais aussi la longueur du chemin critique ; un chemin critique plus court indique que le parallélisme est réellement efficace.
Mais en 2026, les choses ont franchi une nouvelle étape. Meta-Harness traite explicitement l’ingénierie du harnais comme un objectif d’optimisation distinct. Il n’optimise pas les poids, mais le code du harnais lui-même – les programmes de construction de prompts, de récupération, de mémoire et de mise à jour d’état autour d’un modèle fixe. Les chiffres au début de l’article sont directs : pour le même modèle de base, changer simplement le harnais peut entraîner un écart de performance allant jusqu’à 6x sur le même benchmark. Cet ensemble de programmes hors du modèle n’est plus un simple détail de déploiement, mais une couche de formation de capacité.
La clé n’est pas d’ajouter un optimiseur abstrait supplémentaire, mais d’écrire le code préalable, les scores et les traces d’exécution (journaux des appels d’outils et des changements d’état) dans le système de fichiers, de laisser un proposant faire grep, cat et diff comme pour écrire du code, puis de modifier le harnais le long des chemins d’échec. Le proposant est le module qui suggère des modifications du harnais.
Les auteurs jugent clairement que de nombreux optimiseurs de texte passés n’étaient pas efficaces pour les programmes longs et stateful comme les harnais, car ne regarder que les scores scalaires, les templates courts ou les résumés aplatit le problème. Les scores scalaires ne fournissent que des points finaux sans information sur le processus. Les erreurs de harnais se manifestent souvent plusieurs étapes plus tard ; une fois que le feedback est trop compressé, la chaîne de diagnostic se rompt.
Ces résultats sont plus que de simples scores de benchmark plus élevés. En classification de texte en ligne, Meta-Harness dépasse ACE (baseline d’ingénierie du contexte agent) de 7,7 points tout en compressant l’utilisation des tokens de contexte à 1/4. En raisonnement mathématique augmenté par récupération, un harnais découvert a amélioré 5 modèles retenus (non impliqués dans l’optimisation) de 4,7 points en moyenne sur 200 problèmes de niveau IMO. Sur TerminalBench-2, il a également dépassé les baselines d’ingénierie manuelle. Cela montre que ce qui est optimisé ne sont plus seulement les stratégies internes du modèle, mais aussi les programmes qui organisent l’information et les actions autour du modèle.
Un exemple concret : Meta-Harness a automatiquement découvert l’amorçage d’environnement sur TerminalBench-2 – exécuter une commande shell avant le début de la boucle agent pour organiser le répertoire de travail, les langages disponibles, les gestionnaires de paquets et l’état mémoire en un instantané injecté dans le premier prompt. De nombreux agents de codage passent les premiers tours à explorer l’environnement ; avec ce pré-traitement effectué, l’amélioration ne vient pas nécessairement de poids plus forts, mais du fait que le harnais permet au modèle de démarrer avec un meilleur contexte.
À ce stade, l’objectif d’optimisation s’est élargi : des réponses aux trajectoires, puis au programme du harnais qui porte ces trajectoires.
Après la sortie d’un modèle phare, la chaîne d’entraînement continue
Comprendre les grands modèles d’aujourd’hui uniquement à travers le prisme d’un seul tour de pré-entraînement n’est plus suffisant. Derrière un modèle publié, toute la chaîne de pré-entraînement, post-entraînement, distillation et spécialisation a généralement été achevée, et des modèles plus forts continuent de produire des données d’entraînement pour la génération suivante.
La distillation des séries DeepSeek-R1 est un exemple typique. Un grand modèle développe d’abord des capacités de raisonnement par RL et récompenses vérifiées, puis transfère ces trajectoires de raisonnement à des modèles denses plus petits. Des modèles spécialisés comme TranslateGemma montrent une autre voie : sur des tâches cibles plus spécifiques, utiliser des données de haute qualité et des conceptions de récompenses spécialisées pour compresser et orienter davantage les capacités. À ce stade, les modèles plus forts ne sont pas seulement destinés à servir les utilisateurs, mais aussi à produire directement des données d’entraînement pour la génération suivante.
La raison derrière cela est plus fondamentale qu’un simple transfert de trajectoire : une explication possible est que dans les corpus internet, la mémoire des connaissances et la capacité de raisonnement sont couplées, et les objectifs de pré-entraînement existants exigent que les modèles apprennent bien les deux. Les grands modèles doivent venir en premier car seuls ils sont assez grands pour supporter les deux, puis ils peuvent être utilisés pour générer des données de démonstration de raisonnement pures. Lorsque les petits modèles s’entraînent sur ces données, ils peuvent se concentrer sur le raisonnement lui-même sans être obligés de mémoriser toutes les connaissances. Commencer grand puis aller petit, c’est un découplage des capacités, pas seulement une stratégie de coût.
D’un autre côté, l’adaptabilité au déploiement est aussi importante que la capacité elle-même. De nombreux scénarios n’ont pas besoin d’un grand modèle polyvalent ; ils se soucient davantage du coût, de la latence, de la stabilité et de la contrôlabilité. La fin de l’entraînement n’est pas nécessairement plus grande, mais potentiellement plus petite, moins chère et plus spécialisée.
Le modèle finalement publié n’est pas nécessairement le checkpoint le plus à droite de la courbe d’entraînement. Avant la publication effective, plusieurs checkpoints sont souvent comparés à plusieurs reprises pour les résultats réels des tâches, les styles de refus, la stabilité des outils, le coût et les risques de régression. La version mise en ligne est souvent une décision produit, pas celle qui obtient les meilleures performances sur un seul indicateur.
Lorsque les utilisateurs voient un nom de modèle, ils supposent qu’il correspond à une courbe d’entraînement qui monte régulièrement, mais savoir quel checkpoint est réellement mis en ligne est une autre affaire.
La valeur d’un grand modèle réside à la fois dans sa propre capacité de service et dans la fourniture continue de données d’entraînement, de sources de distillation et de bases de publication pour la génération suivante.
Au-delà de l’entraînement hors ligne, l’optimisation continue quasi en ligne est entrée dans le processus principal. Le RL en temps réel de Cursor Composer 2 montre que certaines capacités d’Agent ont commencé à itérer en continu via le trafic de production plutôt que d’attendre le prochain tour d’entraînement hors ligne à grande échelle. La frontière entre l’entraînement et le déploiement n’a pas disparu, mais la boucle de rétroaction entre eux se raccourcit.
Comment juger pourquoi un modèle est devenu plus fort à l’avenir
La valeur des modèles phares en 2026 dépend de plus en plus de qui peut compléter toute la chaîne d’entraînement après le pré-entraînement : produire en continu des données d’entraînement, faire de la distillation, faire de la spécialisation, bien faire l’évaluation et les récompenses, et prendre les bonnes décisions de publication finale.
Pour cette raison, lorsqu’on examine pourquoi un modèle devient soudainement plus fort, on peut d’abord regarder trois choses :
- Premièrement, voir si le changement s’est produit au niveau du pré-entraînement ou dans le processus d’entraînement ultérieur. De nombreuses améliorations de capacité proviennent effectivement d’un meilleur pré-entraînement et de meilleures recettes de données, mais de nombreux changements perçus proviennent en réalité du post-entraînement. Qu’un modèle suive les instructions, utilise des outils ou ait un style de réponse stable ne se développe souvent pas naturellement simplement en s’entraînant sur plus de corpus.
- Ensuite, voir de quelle couche provient l’amélioration : s’agit-il des poids et des recettes d’entraînement, ou de la récompense/évaluation/correcteur, ou du code du harnais et de la boucle de déploiement. Au moment où nous arrivons aux modèles de raisonnement et aux Agents, la force que les utilisateurs ressentent n’est souvent pas le résultat du seul modèle de base. La manière dont les évaluations sont définies, dont les récompenses sont notées, si l’environnement d’outils est stable, comment la récupération et la mémoire sont organisées, comment les résumés et le contexte sont élagués, et quel checkpoint a été choisi pour la publication – tout cela change ensemble les performances du produit final.
- Enfin, voir ce que la version en ligne optimise. Certaines versions visent un plafond plus élevé, certaines visent un coût, une latence et un risque de régression plus faibles, et certaines sont spécialisées pour un certain type de scénario. La version publiée est une décision produit, pas le point à l’extrême droite de la courbe d’entraînement. Ainsi, lorsqu’on examine les mises à jour d’un modèle, regarder ce qu’il optimise réellement se rapprochera davantage de la vérité.
Décomposer l’amélioration soudaine d’un modèle en étapes de production, de nombreux gains sont en réalité amplifiés par la seconde moitié de la stack d’entraînement et le harnais externe. Le cycle d’itération de cette chaîne se raccourcit également : le trafic de production retourne en continu vers l’entraînement, chaque génération de modèles plus forts produit des données de supervision de nouvelle génération tout en produisant des capacités, et les programmes externes sont constamment réécrits en fonction des déploiements, des journaux et des retours réels des tâches.
Le modèle publié aujourd’hui n’est qu’un instantané ; le pipeline et le programme du harnais sont les produits qui continuent de fonctionner.
Documents d’apprentissage
- Hoffmann et al. (2022). Entraînement de modèles de langage volumineux optimaux en calcul (Chinchilla). arXiv:2203.15556
- Ouyang et al. (2022). Entraînement de modèles de langage à suivre des instructions avec retour humain (InstructGPT). arXiv:2203.02155
- Shao et al. (2024). DeepSeekMath : repousser les limites du raisonnement mathématique dans les modèles de langage ouverts (GRPO). arXiv:2402.03300
- DeepSeek-AI (2025). DeepSeek-R1 : encourager la capacité de raisonnement dans les LLM via l’apprentissage par renforcement. arXiv:2501.12948
- DeepSeek-AI (2024). Rapport technique DeepSeek-V3. arXiv:2412.19437
- Llama Team, AI @ Meta (2024). La meute de modèles Llama 3. arXiv:2407.21783
- Bai et al. (2022). IA Constitutionnelle : innocuité à partir du retour de l’IA. arXiv:2212.08073
- OpenAI (2024). Alignement délibératif : le raisonnement permet des modèles de langage plus sûrs. openai.com/index/deliberative-alignment
- Anthropic (2025). De la sycophance à la subterfuge : enquête sur la falsification des récompenses dans les modèles de langage. anthropic.com/research/reward-tampering
- MacDiarmid et al. (2025). Désalignement émergent naturel à partir du piratage de récompenses dans le RL de production. arXiv:2511.18397
- Lee et al. (2026). Meta-Harness : optimisation de bout en bout des harnais de modèles (page de projet pré-impression). yoonholee.com/meta-harness
- Kimi Team (2026). Blog technique Kimi K2.5 : intelligence agentique visuelle. kimi.com/blog/kimi-k2-5
- Rush, S. (2026). Un rapport technique sur Composer 2. cursor.com/blog/composer-2-technical-report
- Chroma (2026). Chroma Context-1 : entraînement d’un agent de recherche auto-éditant. trychroma.com/research/context-1
Cet article n’autorise aucune forme de reproduction ou de réécriture pour republication. Si vous en trouvez, merci de m’aider à le signaler.
