El equipo KwaiKAT de Kuaishou presentó KAT-Coder-V2.5, un modelo de codificación diseñado para trabajar dentro de repositorios de software reales y ejecutables, en lugar de producir fragmentos de código de una sola interacción. El modelo servido está disponible a través de StreamLake. Una variante independiente de pesos abiertos, KAT-Coder-V2.5-Dev, fue lanzada en Hugging Face bajo la licencia Apache-2.0.

El lanzamiento se centra en flujos de trabajo de codificación agéntica, donde un modelo debe inspeccionar un repositorio, comprender una tarea, editar archivos, ejecutar pruebas y verificar si un parche es correcto. Ese enfoque refleja un cambio más amplio en la evaluación de modelos de codificación: de prompts de programación aislados hacia mantenimiento de software a nivel de repositorio, donde los entornos reproducibles y la retroalimentación confiable de pruebas pueden ser tan importantes como la calidad de generación de código. El proyecto pone énfasis en entornos de repositorio, construcción de datos, confiabilidad del sandbox, infraestructura de aprendizaje por refuerzo y evaluación en benchmarks.

AutoBuilder construye entornos que ejecutan las pruebas previstas

La investigación define una tarea de codificación verificable como una tripleta: una descripción precisa de la tarea, un entorno de repositorio ejecutable y un conjunto de pruebas de validación. Un parche se considera correcto solo si supera todo el conjunto de validación.

Las tareas se extraen de pull requests y commits reales, siguiendo la línea de SWE-bench. El cambio de código fusionado proporciona un parche de referencia, mientras que el cambio de prueba asociado proporciona un parche de prueba. El sistema no utiliza el texto sin procesar de los issues como especificación. En su lugar, las descripciones de tareas se regeneran en tres componentes: un planteamiento del problema basado en el parche de referencia, requisitos derivados del parche de prueba y restricciones de interfaz inferidas de ambas fuentes. Una revisión de claridad elimina tareas ambiguas, incompletas, insuficientemente especificadas o internamente inconsistentes.

AutoBuilder se encarga del proceso de construcción del entorno. Un agente de construcción examina el repositorio y escribe un script de configuración que instala dependencias y ejecuta pruebas desde una copia limpia. Luego, un agente de verificación ejecuta el script en un sandbox aislado.

El proceso de aceptación no depende de códigos de salida ni de coincidencias de patrones en logs. En cambio, la verificación analiza la salida estructurada de los frameworks de prueba. Un entorno se acepta solo cuando se recopila más del 90% de las pruebas esperadas y los resultados de aprobado/fallido son reproducibles entre ejecuciones. Las fallas se devuelven como información estructurada para una reparación iterativa.

Al combinar un entorno base preconfigurado, plantillas de sistemas de compilación y una biblioteca recuperable de recetas de compilación destiladas, el equipo aumentó la tasa de éxito en la construcción de entornos de 16.5% a 57.2%. El conjunto de datos resultante incluye más de 100,000 entornos verificables en 12 lenguajes de programación. El historial de Git, los metadatos de commits y otros rastros explotables se eliminan para que los agentes no puedan obtener la solución de referencia directamente desde el repositorio.

Data Scaling Flywheel filtra por calidad del proceso

El proyecto sostiene que filtrar trayectorias solo por el éxito final en las pruebas puede ser engañoso. Algunas ejecuciones que aprueban pueden depender de código hardcodeado, de eludir mecanismos previstos o de tomar atajos orientados a las pruebas. Al mismo tiempo, algunas ejecuciones fallidas pueden contener comportamientos útiles de búsqueda, localización y reparación.

KwaiKAT aborda ambos casos. Para intentos que quedan cerca de aprobar, las pistas dirigidas a nivel de proceso identifican qué debe inspeccionarse o verificarse sin revelar la solución. Esto eleva la tasa de aprobación de tareas que antes no tenían ninguna ejecución aprobada a aproximadamente 20%. Debido a que las trayectorias con pistas contienen información que no estaría disponible durante la inferencia, luego se fija el parche verificado y se regenera una trayectoria sin pistas desde el contexto original de la tarea. Solo se conservan las muestras que pasan la verificación, no contienen filtración de pistas y se mantienen consistentes con el parche.

Para las trayectorias que ya aprueban, compuertas basadas en reglas eliminan ejemplos inválidos, inestables o explotativos. Luego, una etapa de puntuación evalúa exploración, localización, razonamiento previo a la edición, fidelidad a la especificación, adhesión a las convenciones del repositorio, minimalidad del parche, calidad de verificación, comportamiento de recuperación y honestidad.

Un tercer mecanismo busca reducir el sobreajuste al harness. Los nombres de herramientas, las convenciones de argumentos, los formatos de salida y las plantillas de prompts se aleatorizan mientras la funcionalidad permanece sin cambios. Como la verificación está vinculada a los resultados de las pruebas y no a los rastros del harness, la misma tarea puede presentarse bajo múltiples configuraciones de harness. El sistema también inyecta perturbaciones realistas, incluidas dependencias faltantes, fallas transitorias de comandos, salidas truncadas y logs ruidosos.

Las fallas del sandbox afectaron las recompensas antes que los límites algorítmicos

Durante el entrenamiento de KAT-Coder-V2, las curvas de recompensa lentas se atribuyeron inicialmente al algoritmo de aprendizaje por refuerzo. Una auditoría posterior encontró que aproximadamente 16% de las trayectorias fallaban por problemas de infraestructura del sandbox, no por la política del modelo. Las desalineaciones de límites a veces vaciaban las observaciones durante cerca de 40 pasos y corrompían las recompensas.

El equipo implementó tres correcciones de infraestructura. Primero, una política de desalojo temprano de imágenes redujo el uso de disco de 95% a 60%, disminuyendo los rollouts inválidos causados por timeouts de 6–7% a menos de 1%. Segundo, corregir las variables de entorno durante la inicialización remota del sandbox evitó sobrescrituras del sistema que habían invertido recompensas en 6–7% de las muestras, reduciendo esos errores por debajo de 1%. Tercero, el Gateway Server omitió endpoints de chat convencionales, que habían causado una deriva de tokens de 40% a una escala aproximada de 200 turnos al volver a aplicar apply_chat_template y retokenizar. En su lugar, el sistema llamó directamente a /generate para mantener la alineación de tokens del rollout.

En conjunto, estos cambios redujeron la tasa de error de retroalimentación del sandbox de alrededor de 16% a menos de 2% y disminuyeron los colapsos de entrenamiento en un orden de magnitud. El hallazgo también subraya una restricción práctica para el entrenamiento de código agéntico: la calidad de la recompensa depende del sistema de ejecución circundante, no solo de la arquitectura del modelo o del método de optimización.

PPO asimétrico y recompensas de tres niveles

Los investigadores eligieron PPO con GAE en lugar de métodos de trayectoria sin crítico porque los harnesses de producción dividen las sesiones en muestras estructuralmente diferentes, lo que dificulta las líneas base grupales.

La configuración de entrenamiento utiliza un diseño actor–critic asimétrico. El Critic recibe contexto privilegiado de entrenamiento, incluidas recompensas, pruebas, cobertura, parches, metadatos y turnos futuros. El Actor solo ve el estado del rollout. El Critic y el contexto adicional se descartan durante la inferencia.

Las recompensas se organizan en tres niveles. Core Task Scores exige que pasen todas las pruebas fail_to_pass y pass_to_pass. Standard Behavior Constraints penaliza duplicación, llamadas inválidas a herramientas y remanentes de depuración. Failed Trajectory Incentives puntúa la recuperación de archivos mediante F2 y asigna crédito parcial por pruebas.

Cinco expertos se combinan mediante Multi-Teacher On-Policy Distillation usando KL inversa, un inicio off-policy y truncamiento consciente de deriva de Prune-OPD.

Resultados en benchmarks

Bajo un harness unificado de Claude Code, KAT-Coder-V2.5 lideró su panel en PinchBench con una puntuación de 94.9, por delante de Opus 4.8 con 93.5. Ocupó el segundo lugar en SWE-Bench Pro con 65.2 frente a 69.2, y el segundo lugar en el KAT Code Bench interno con 53.1 frente a 57.3.

El modelo tuvo un desempeño menos sólido en Terminal-Bench 2.1, donde quedó en último lugar con 60.7, detrás de GLM-5.1 con 61.8 y Opus 4.8 con 84.6. En SciCode, obtuvo 50.3, igualando a GLM-5.2. Los resultados mixtos hacen que el alcance del harness y del benchmark sea importante para la interpretación, ya que el parcheo de repositorios, la operación en terminal y las pruebas de codificación científica miden distintas partes de un sistema de codificación agéntica.

KAT-Coder-V2.5-Dev, de pesos abiertos, es un modelo MoE independiente de 35B totales / 3B activos, posentrenado sobre Qwen3.6-35B-A3B con 127K ejemplos SFT, seguido de aprendizaje por refuerzo. Fue evaluado bajo un protocolo interno separado, por lo que sus resultados no son comparables con la tabla principal de benchmarks del modelo insignia.

Los materiales principales del proyecto incluyen el paper, la página de producto de StreamLake y los pesos del modelo KAT-Coder-V2.5-Dev en Hugging Face.