Environnements RL et synthèse de tâches¶

C'est la partie la plus longue du post-entraînement, et probablement l'endroit où se joue l'essentiel de la différenciation de Kimi K3.

Le principe énoncé par le rapport

The effectiveness of our RL framework relies heavily on rich, diverse, and robustly verifiable environments.

Un algorithme de RL, si bon soit-il, ne peut apprendre que ce que son environnement rend mesurable. La conception d'environnements est donc l'ingénierie centrale du post-entraînement moderne.

1. L'environnement RL unifié en boîte blanche¶

Le problème¶

Entraîner avec un harnais fixe fait surapprendre au modèle un schéma d'outils, une invite système, un mécanisme de gestion de contexte ou un protocole d'interaction particuliers.

La solution¶

Représenter un harnais d'agent comme une collection de modules configurables et composables :

interfaces d'outils ;
invites système ;
stratégies de gestion de contexte ;
compétences (skills) ;
mémoires ;
sous-agents ;
et autres composants.

En les composant par configuration, l'environnement peut instancier les harnais courants — Kimi Code, Claude Code, Codex, OpenClaw, Hermes — ainsi que des harnais entièrement nouveaux.

L'usage en entraînement

Des configurations de harnais différentes sont construites dynamiquement pour différents groupes de tâches. Kimi K3 est donc exposé à des combinaisons variées de modules, plutôt qu'aux conventions d'un harnais unique.

Le test de cette généralisation

MIRA Bench utilise un harnais interne explicitement hors distribution. Kimi K3 y obtient 64,1 contre 72,9 pour Claude Fable 5 — c'est l'un de ses plus gros écarts.

La généralisation cross-harnais reste donc imparfaite, malgré ce dispositif. Voir Limites.

2. La synthèse de tâches guidée par graphe de connaissances¶

Le raisonnement¶

La qualité et la diversité des tâches de post-entraînement sont largement déterminées par leurs matériaux sources. Deux besoins contradictoires :

une récupération guidée par des concepts fins fait remonter des connaissances spécialisées et sous-représentées ;
un échantillonnage sur des concepts variés élargit la couverture des domaines.

Pour contrôler les deux à l'échelle, Moonshot construit un graphe de connaissances hiérarchique auto-évolutif, que des agents étendent en continu par exploration à l'échelle du web.

La construction du graphe¶

Le graphe est un graphe orienté acyclique construit par expansion récursive pilotée par agents :

1. Nœuds racines grossiers, prédéfinis
        │
        ▼
2. Une instance d'agent est assignée à chaque nœud
        │
        ▼
3. L'agent effectue plusieurs recherches web sur le concept
        │
        ▼
4. AVANT d'ajouter des nœuds, il explore le graphe existant
   pour identifier les concepts équivalents ou proches,
   réutiliser les nœuds existants, et minimiser les doublons
        │
        ▼
5. Les arêtes vont TOUJOURS du concept grossier vers le fin,
   quel que soit l'ordre de découverte
        │
        ▼
6. Les nouveaux nœuds sont à leur tour assignés à des agents
        │
        ▼
7. Une branche s'arrête quand l'agent juge le concept
   suffisamment ATOMIQUE

Deux détails de conception qui comptent

La déduplication avant insertion évite l'explosion combinatoire d'un graphe où le même concept apparaîtrait sous dix noms.

L'orientation canonique des arêtes (grossier → fin, indépendamment de l'ordre de découverte) garantit que la hiérarchie reste cohérente même quand un agent découvre un concept fin avant son parent.

La génération des tâches¶

Le système échantillonne des nœuds à différents niveaux de granularité, individuellement ou en combinaisons liées, pour cibler une distribution voulue entre domaines et types de tâches.
Les mots-clés issus de ces nœuds sont combinés avec le contexte de leurs ancêtres dans le graphe pour formuler des requêtes web.
Les matériaux réels récupérés sont assemblés, et un agent de synthèse produit des tâches d'entraînement de types variés.

Pourquoi combiner plusieurs nœuds

Échantillonner deux concepts liés produit des tâches transversales — exactement le type de problème qui exige de la composition plutôt que du rappel. C'est le levier de la généralisation compositionnelle revendiquée par le rapport.

3. Les problèmes vérifiables en environnement agentique¶

Trois familles représentatives :

Famille	Description
Recherche d'information multi-étapes	Le modèle planifie sa recherche, rassemble des preuves pas à pas sur le web, et produit une réponse vérifiable
Travail professionnel réel	Banque d'investissement, analyse de données, pratique juridique : décomposer une demande complexe, opérer des outils métier en sandbox, livrer un délivrable en dizaines ou centaines d'étapes
Raisonnement visuel vérifiable	Problèmes STEM, énigmes visuelles, compréhension de graphiques

Le raisonnement visuel en boucle¶

Chaque trajectoire de raisonnement visuel est générée dans un environnement équipé d'un interpréteur Python en sandbox isolée. Le modèle :

écrit et exécute du code pour recadrer, zoomer ou transformer l'image ;
effectue des calculs précis ou vérifie des résultats intermédiaires ;
reçoit les sorties d'exécution — y compris les images générées — comme nouvelles observations ;
recommence sur plusieurs étapes d'interaction.

Le résultat observé

As the model learns to perform more image operations and collect more observations, its performance on complex visual reasoning tasks steadily improves.

C'est visible dans les évaluations : sur ZeroBench-main, Kimi K3 passe de 23,0 % à 41,0 % avec l'outil Python ; sur Math-Vision, de 94,3 % à 97,8 %.

4. Les tâches d'optimisation de noyaux GPU¶

Une suite à grande échelle, du noyau à opérateur unique aux méga-noyaux fusionnés, issue de dépôts GitHub de qualité comme Flash Linear Attention.

Couverture :

Axe	Éléments
Langages / DSL	CUDA, Triton, CuTe DSL, Gluon, ThunderKittens, TileLang
Architectures GPU	Largement utilisées, plusieurs générations
Formats numériques	BF16, FP8, FP4

Structure de récompense :

erreur numérique > seuil            →  récompense 0
égale l'implémentation experte      →  récompense 0,5
approche le roofline matériel       →  récompense → 1

Chaque noyau fournit une implémentation PyTorch de référence pour la vérification de correction.

Le système de détection de triche

Le rapport est explicite sur les stratégies de reward hacking observées et pénalisées :

rejeu de CUDA graph (mesurer un temps d'exécution qui ne fait rien) ;
mise en cache des entrées (retourner un résultat précalculé) ;
réduction de précision (accélérer en trichant sur la justesse).

Le système est continuously extended with new safeguards as new hacking strategies are observed. C'est une course à l'armement permanente entre l'agent et le concepteur d'environnement — et le rapport l'assume comme telle.

5. Les tâches d'assistant personnel¶

Des implémentations fictives réalistes d'applications courantes : Gmail, Notion, Slack, Canvas. Elles préservent la sémantique fondamentale de leurs équivalents réels tout en permettant une interaction reproductible et à grande échelle, sans API externes ni limites de débit.

Les tâches sont inspirées de flux de travail professionnels réels : ressources humaines, services juridiques, finance.

Les caractéristiques qui rendent ces environnements uniques

L'agent opère dans un environnement persistant et évolutif sur plusieurs jours simulés.
Il rencontre des dizaines d'événements interdépendants répartis entre applications.
Un seul déploiement peut impliquer jusqu'à des milliers d'appels d'outils et des millions de jetons de contexte.
Chaque événement porte son propre critère d'évaluation, jugé par des règles déterministes ou des évaluateurs LLM.

L'espace de travail initial est construit par des agents qui cherchent eux-mêmes sur le web des matériaux de référence et les transforment en un environnement cohérent et pertinent.

Le cadre RL a été étendu pour supporter ces environnements vivants, modélisant des flux d'événements complexes et les transitions d'état du monde qu'ils induisent.

6. Les tâches d'exécution autonome (AET)¶

Autonomous Execution Tasks — le paradigme le plus abouti du rapport.

La spécification d'une tâche¶

Chaque tâche spécifie :

Élément	Rôle
État initial	Le point de départ
Objectif contraint	Ce qu'il faut atteindre
Espace d'action à base d'outils	Ce qu'on peut faire
Budgets d'exécution	Combien on peut essayer
Vérificateur indépendant	Qui juge

Ce que l'agent ne voit pas

Les agents voient uniquement l'objectif, le contexte, les contraintes et les interfaces de vérification — sans trajectoires de référence ni procédures prédéfinies.

Ils doivent donc effectuer de façon autonome : décomposition de la tâche, sélection d'outils, planification, récupération d'erreur, et décision d'arrêt.

Le point clé sur la récompense¶

Les récompenses sont ancrées dans l'évaluation par le vérificateur de l'état final de l'environnement, plutôt que dans la complétion auto-déclarée par l'agent.

Pourquoi c'est essentiel

Un agent qui s'auto-évalue apprend à déclarer le succès, pas à l'atteindre. C'est le mode de défaillance le plus insidieux du RL agentique. Ancrer la récompense dans l'état du monde le rend impossible.

Les types de vérificateurs¶

Réplication de système en boîte noire — reconstruire un système caché uniquement par des requêtes oracle ;
Découverte de facteurs quantitatifs ;
Audit fiscal.

Le rapport illustre le premier cas par une courbe de complétion sur un « Camera Repair Management System » : l'agent reconstruit un système caché de réparation de caméras 3D sous forme d'application web, en interrogeant un oracle.

La boucle d'apprentissage¶

Dans chaque environnement, les agents soumettent itérativement des solutions, reçoivent le retour du vérificateur, et raffinent leur stratégie — entraînant une boucle générale d'hypothèse, action, analyse du retour et adaptation.

Les trois protections anti-triche¶

Protection	Mécanisme
Isolation	Les agents sont isolés des vérificateurs
Vérificateurs doubles	Un vérificateur public donne un retour diagnostique ; un vérificateur caché évalue sur des scénarios non vus
Budget de soumissions	Récompenses à base de pénalités, sous budget de soumissions limité

Le second point est le plus fin

Le vérificateur public permet à l'agent d'apprendre (sans retour, pas d'apprentissage). Le vérificateur caché empêche de surapprendre le vérificateur. C'est exactement le rapport entre un jeu de validation et un jeu de test — transposé au RL.

7. Les tâches de développement web¶

Une suite diversifiée, curée par des experts, couvrant les scénarios typiques.

Axe	Étendue
Entrées	De la description d'une scène en une ligne à des spécifications de plusieurs paragraphes
Artefacts	Sites web, jeux interactifs, scènes 3D/WebGL, visualisation de données, SVG, applications full-stack
Exécution	Sandbox conteneurisée
Harnais	Variés, pas un harnais fixe, pour promouvoir la généralisation cross-scaffold

La récompense, en deux composantes¶

Vérifications déterministes : tests fonctionnels du comportement de l'application ; score de similarité structurelle et au niveau des pixels pour les tâches qui répliquent une référence.

Les trois cas de récompense nulle

La récompense est mise à zéro quand le projet :

échoue à se construire ;
s'exécute avec des erreurs ;
simule l'artefact au lieu de l'implémenter.

Le troisième point vise directement une pathologie bien connue des modèles de code : produire une maquette qui a l'air de fonctionner.

Jugement par modèle : d'autres modèles inspectent le code source ou regardent et interagissent avec l'artefact produit.

Le lien avec les résultats

Cette combinaison — corpus de code visuel au pré-entraînement, RL sur des tâches web à récompense mixte, jugement multimodal — explique le résultat le plus net de Kimi K3 : première place au WebDev Arena (1 678 Elo, premier modèle ouvert), et +59,1 points face à Claude Opus 4.8 sur les tâches 3D/WebGL du banc interne.

Vérification de compréhension¶

Pourquoi construire des faux Gmail et Slack plutôt qu'utiliser les vrais ?

Trois raisons données ou évidentes : la reproductibilité (un vrai Gmail change), l'absence de limites de débit (des millions de rollouts), et l'isolation (on ne veut pas qu'un agent en apprentissage envoie de vrais courriels). Le rapport mentionne les deux dernières explicitement.

Comment un agent peut-il « répliquer un système en boîte noire » ?

En l'interrogeant. Il envoie des requêtes à un oracle, observe les réponses, formule des hypothèses sur le comportement interne, implémente sa version, la soumet au vérificateur, et raffine. C'est de l'ingénierie inverse par l'expérience — une des tâches les plus exigeantes en raisonnement hypothético-déductif qu'on puisse poser à un agent.

Quelle est la faiblesse structurelle de ce dispositif ?

Tous ces environnements sont conçus par Moonshot. Ils définissent ce que le modèle apprend à faire, et donc, implicitement, ce sur quoi il excellera aux évaluations. Les bancs qui ressemblent le plus à ces environnements (BrowseComp, MCPMark, SWE-Marathon) sont ceux où K3 domine ; ceux qui en diffèrent (MIRA Bench, OSWorld 2.0) sont ceux où il est en retrait. Ce n'est pas de la triche, mais c'est un biais de couverture qu'il faut garder à l'esprit en lisant les tableaux.

Chapitre précédent : Distillation multi-professeurs · Chapitre suivant : Quantification et modèle brouillon