L’équipe KwaiKAT de Kuaishou a présenté KAT-Coder-V2.5, un modèle de codage conçu pour fonctionner dans de véritables dépôts logiciels exécutables plutôt que pour produire des extraits de code en une seule interaction. Le modèle servi est disponible via StreamLake. Une variante distincte à poids ouverts, KAT-Coder-V2.5-Dev, a été publiée sur Hugging Face sous licence Apache-2.0.

Cette sortie est centrée sur les workflows de codage agentique, dans lesquels un modèle doit inspecter un dépôt, comprendre une tâche, modifier des fichiers, exécuter des tests et vérifier si un correctif est valide. Cette orientation reflète une évolution plus large de l’évaluation des modèles de codage, qui passe de prompts de programmation isolés à la maintenance logicielle au niveau du dépôt, où des environnements reproductibles et des retours de test fiables peuvent être aussi importants que la qualité de génération du code. Le projet met l’accent sur les environnements de dépôt, la construction des données, la fiabilité des sandboxes, l’infrastructure d’apprentissage par renforcement et l’évaluation par benchmarks.

AutoBuilder construit des environnements qui exécutent les tests prévus

La recherche définit une tâche de codage vérifiable comme un triplet : une description précise de la tâche, un environnement de dépôt exécutable et un ensemble de tests de validation. Un correctif n’est considéré comme correct que s’il réussit l’ensemble complet de validation.

Les tâches sont extraites de véritables pull requests et commits, dans la lignée de SWE-bench. La modification de code fusionnée fournit un correctif de référence, tandis que la modification de test associée fournit un correctif de test. Le système n’utilise pas le texte brut des issues comme spécification. À la place, les descriptions de tâches sont régénérées en trois composants : un énoncé du problème fondé sur le correctif de référence, des exigences dérivées du correctif de test et des contraintes d’interface déduites des deux sources. Un contrôle de clarté supprime les tâches ambiguës, incomplètes, sous-spécifiées ou incohérentes en interne.

AutoBuilder est responsable du processus de construction de l’environnement. Un agent de build examine le dépôt et rédige un script de configuration qui installe les dépendances et exécute les tests à partir d’un checkout propre. Un agent de vérification exécute ensuite le script dans une sandbox isolée.

Le processus d’acceptation ne repose pas sur les codes de sortie ni sur la correspondance de motifs dans les journaux. La vérification analyse plutôt les sorties structurées des frameworks de test. Un environnement n’est accepté que lorsque plus de 90% des tests attendus sont collectés et que les résultats réussite/échec sont reproductibles entre plusieurs exécutions. Les échecs sont renvoyés sous forme d’informations structurées pour une réparation itérative.

En combinant un environnement de base préconfiguré, des modèles de systèmes de build et une bibliothèque interrogeable de recettes de build distillées, l’équipe a fait passer le taux de réussite de construction des environnements de 16.5% à 57.2%. Le jeu de données obtenu comprend plus de 100,000 environnements vérifiables couvrant 12 langages de programmation. L’historique Git, les métadonnées de commit et les autres traces exploitables sont supprimés afin que les agents ne puissent pas obtenir directement la solution de référence depuis le dépôt.

Data Scaling Flywheel filtre la qualité du processus

Le projet soutient que filtrer les trajectoires uniquement selon la réussite finale des tests peut être trompeur. Certaines exécutions réussies peuvent dépendre de valeurs codées en dur, du contournement de mécanismes prévus ou de raccourcis adaptés aux tests. Dans le même temps, certaines exécutions échouées peuvent tout de même contenir des comportements utiles de recherche, de localisation et de réparation.

KwaiKAT traite les deux cas. Pour les tentatives proches de la réussite, des indices ciblés au niveau du processus indiquent ce qui doit être inspecté ou vérifié sans révéler la solution. Cela porte à environ 20% le taux de réussite de tâches qui n’avaient auparavant aucune réussite. Comme les trajectoires avec indices contiennent des informations qui ne seraient pas disponibles au moment de l’inférence, le correctif vérifié est ensuite fixé et une trajectoire sans indice est régénérée à partir du contexte de tâche original. Seuls les échantillons qui passent la vérification, ne présentent aucune fuite d’indice et restent cohérents avec le correctif sont conservés.

Pour les trajectoires qui réussissent déjà, des filtres fondés sur des règles retirent les exemples invalides, instables ou exploitants. Une étape de notation évalue ensuite l’exploration, la localisation, le raisonnement avant modification, la fidélité à la spécification, le respect des conventions du dépôt, la minimalité du correctif, la qualité de la vérification, le comportement de récupération et l’honnêteté.

Un troisième mécanisme vise à réduire le surapprentissage du harness. Les noms d’outils, les conventions d’arguments, les formats de sortie et les modèles de prompts sont randomisés tout en conservant la fonctionnalité inchangée. Comme la vérification est liée aux résultats des tests plutôt qu’aux traces du harness, une même tâche peut être présentée sous plusieurs configurations de harness. Le système injecte également des perturbations réalistes, notamment des dépendances manquantes, des échecs transitoires de commandes, des sorties tronquées et des journaux bruités.

Les échecs de sandbox ont affecté les récompenses avant les limites algorithmiques

Lors de l’entraînement de KAT-Coder-V2, les courbes de récompense lentes ont d’abord été attribuées à l’algorithme d’apprentissage par renforcement. Un audit a ensuite montré qu’environ 16% des trajectoires échouaient à cause de problèmes d’infrastructure de sandbox plutôt que de la politique du modèle. Des désalignements de frontières vidaient parfois les observations pendant environ 40 étapes et corrompaient les récompenses.

L’équipe a mis en œuvre trois corrections d’infrastructure. Premièrement, une politique d’éviction anticipée des images a réduit l’utilisation du disque de 95% à 60%, abaissant les rollouts invalides causés par des timeouts de 6–7% à moins de 1%. Deuxièmement, la correction des variables d’environnement lors de l’initialisation de sandboxes distantes a empêché des remplacements système qui inversaient les récompenses sur 6–7% des échantillons, réduisant ces erreurs à moins de 1%. Troisièmement, le Gateway Server a contourné les endpoints de chat courants, qui avaient provoqué une dérive de tokens de 40% à une échelle d’environ 200 tours en réappliquant apply_chat_template et en retokénisant. Le système a plutôt appelé directement /generate afin de maintenir l’alignement des tokens de rollout.

Ensemble, ces changements ont réduit le taux d’erreur de retour de la sandbox d’environ 16% à moins de 2% et diminué les effondrements d’entraînement d’un ordre de grandeur. Ce constat souligne aussi une contrainte pratique pour l’entraînement au code agentique : la qualité des récompenses dépend du système d’exécution environnant, et pas seulement de l’architecture du modèle ou de la méthode d’optimisation.

PPO asymétrique et récompenses à trois niveaux

Les chercheurs ont choisi PPO avec GAE plutôt que des méthodes de trajectoire sans critique, car les harnesses de production divisent les sessions en échantillons structurellement différents, ce qui complique les lignes de base de groupe.

La configuration d’entraînement utilise une conception acteur–critique asymétrique. Le Critic reçoit un contexte d’entraînement privilégié, comprenant les récompenses, les tests, la couverture, les correctifs, les métadonnées et les tours futurs. L’Actor ne voit que l’état du rollout. Le Critic et le contexte supplémentaire sont supprimés au moment de l’inférence.

Les récompenses sont organisées en trois niveaux. Les Core Task Scores exigent que tous les tests fail_to_pass et pass_to_pass réussissent. Les Standard Behavior Constraints pénalisent la duplication, les appels d’outils invalides et les restes de débogage. Les Failed Trajectory Incentives notent la récupération de fichiers via F2 et attribuent un crédit partiel pour les tests.

Cinq experts sont combinés au moyen de Multi-Teacher On-Policy Distillation, avec KL inverse, démarrage off-policy et troncature sensible à la dérive issue de Prune-OPD.

Résultats des benchmarks

Sous un harness Claude Code unifié, KAT-Coder-V2.5 a pris la tête de son panel sur PinchBench avec un score de 94.9, devant Opus 4.8 à 93.5. Il s’est classé deuxième sur SWE-Bench Pro avec 65.2 contre 69.2, et deuxième sur le KAT Code Bench interne avec 53.1 contre 57.3.

Le modèle a été moins performant sur Terminal-Bench 2.1, où il s’est classé dernier avec 60.7, derrière GLM-5.1 à 61.8 et Opus 4.8 à 84.6. Sur SciCode, il a obtenu 50.3, à égalité avec GLM-5.2. Ces résultats contrastés rendent le périmètre du harness et du benchmark important pour l’interprétation, car la correction de dépôts, l’utilisation du terminal et les tests de codage scientifique mesurent différentes parties d’un système de codage agentique.

KAT-Coder-V2.5-Dev, la version à poids ouverts, est un modèle MoE distinct de 35B au total / 3B actifs, post-entraîné sur Qwen3.6-35B-A3B avec 127K exemples SFT, puis par apprentissage par renforcement. Il a été évalué selon un protocole interne séparé, de sorte que ses résultats ne sont pas comparables au tableau principal des benchmarks du modèle phare.

Les principaux documents du projet comprennent l’article, la page produit StreamLake et les poids du modèle KAT-Coder-V2.5-Dev sur Hugging Face.