El equipo KwaiKAT en Kuaishou ha presentado el KAT-Coder-V2.5. Es un modelo de codificación entrenado para operar dentro de repositorios ejecutables reales en lugar de emitir código de un solo turno. El modelo servido está disponible a través de StreamLake. Una variante de peso abierto, KAT-Coder-V2.5-Dev, se lanzó por separado en Hugging Face bajo Apache-2.0.
AutoBuilder: entornos que realmente ejecutan las pruebas previstas
La investigación enmarca una tarea verificable como un triplete. Necesita una descripción precisa de la tarea, un entorno de repositorio ejecutable y un conjunto de pruebas de validación. Un parche es correcto sólo si los pasa todos.
Las tareas se extraen de solicitudes de extracción y confirmaciones reales, siguiendo el linaje de SWE-bench. El cambio de código combinado proporciona un parche dorado y el cambio de prueba que lo acompaña proporciona un parche de prueba. El texto del problema sin procesar se descarta como especificación. En cambio, las descripciones se regeneran en tres partes: una declaración del problema basada en el parche dorado, los requisitos derivados del parche de prueba y las restricciones de interfaz inferidas de ambos. Luego, una verificación de claridad descarta cualquier cosa ambigua, incompleta, poco especificada o internamente inconsistente.
AutoBuilder se encarga del aspecto medioambiental. Un agente de compilación analiza el repositorio y escribe un script de configuración que instala dependencias y ejecuta pruebas desde un proceso de pago limpio. Un agente de verificación ejecuta ese script en un entorno aislado.
La regla de aceptación es la parte interesante. La verificación no lee códigos de salida ni patrones de registro grep. Analiza la salida del marco de prueba estructurado y acepta un entorno solo cuando se recopilan más del 90 % de las pruebas esperadas y los resultados de aprobación/fallo se reproducen en todas las ejecuciones. Las fallas se retroalimentan como información estructurada para su reparación iterativa.
La combinación de un entorno base preconfigurado, plantillas de sistema de construcción y una biblioteca recuperable de recetas de construcción destiladas aumentó la tasa de éxito de la construcción del 16,5 % al 57,2 %. El resultado son más de 100.000 entornos verificables que abarcan 12 idiomas. El historial de Git, los metadatos de confirmación y otros rastros explotables se eliminan para que los agentes no puedan leer la solución de referencia del repositorio.
Volante de escalado de datos: filtrado por proceso
Filtrar trayectorias según el éxito de la prueba final es engañoso. Algunas ejecuciones de aprobación se basan en codificación, omisión de mecanismos o atajos orientados a pruebas. Algunas ejecuciones fallidas contienen valiosos comportamientos de búsqueda, localización y reparación.
KwaiKAT aborda ambas direcciones. Para los cuasi accidentes, las sugerencias específicas a nivel de proceso indican qué inspeccionar o verificar sin revelar la solución. Solo eso eleva la tasa de aprobación de tareas que antes no se aprobaban a aproximadamente el 20%. Debido a que las trayectorias sugeridas contienen información no disponible en la inferencia, el parche verificado se repara y se regenera una trayectoria sin pistas a partir del contexto de la tarea original. Solo se conservan las muestras que pasan la verificación, no muestran fugas de pistas y son consistentes con el parche.
Para carreras de pase, las barreras basadas en reglas eliminan trayectorias inválidas, inestables o de explotación. Luego, una etapa de puntuación califica la exploración, la localización, el razonamiento previo a la edición, la fidelidad de las especificaciones, las convenciones del repositorio, la mínimalidad de los parches, la calidad de la verificación, el comportamiento de recuperación y la honestidad.
Un tercer mecanismo apunta al sobreajuste del arnés. Los nombres de herramientas, las convenciones de argumentos, los formatos de salida y las plantillas de mensajes se aleatorizan mientras se conserva la funcionalidad. Debido a que la verificación está anclada a los resultados de las pruebas en lugar de a los seguimientos del arnés, una tarea se puede reservar bajo muchas configuraciones de arnés. También se inyectan perturbaciones realistas: dependencias faltantes, fallas transitorias de comandos, salidas truncadas y registros ruidosos.
Explore el proceso y los números
Las fallas de infraestructura limitaron las recompensas antes que los límites algorítmicos
Durante el entrenamiento KAT-Coder-V2, inicialmente se atribuyó al algoritmo RL las lentas curvas de recompensa. Sin embargo, una auditoría reveló que ~16% de las trayectorias fallaron debido a problemas de infraestructura de la zona de pruebas en lugar de a la política del modelo, con desalineaciones de límites que a veces vaciaban las observaciones de ~40 pasos y corrompían las recompensas.
Siguieron tres arreglos de infraestructura. En primer lugar, una política de desalojo de imágenes de lanzamiento anticipado redujo el uso del disco del 95% al 60%, reduciendo los lanzamientos no válidos inducidos por el tiempo de espera del 6% al 7% a menos del 1%. En segundo lugar, la corrección de las variables de entorno durante la inicialización remota de la zona de pruebas detuvo las anulaciones del sistema que cambiaban las recompensas en entre el 6% y el 7% de las muestras, reduciendo los errores por debajo del 1%. En tercer lugar, el servidor Gateway pasó por alto los puntos finales de chat convencionales, lo que provocó una deriva del token del 40 % en una escala de ~200 turnos al volver a aplicar apply_chat_template y volver a tokenizar, y llamó a /generate directamente para garantizar la alineación del token de implementación.
En conjunto, estas actualizaciones redujeron la tasa de error de retroalimentación de la zona de pruebas de aproximadamente el 16 % a menos del 2 % y redujeron los colapsos del entrenamiento en un orden de magnitud.
PPO asimétrica y recompensa de tres niveles
El equipo de investigación eligió PPO con GAE en lugar de métodos de trayectoria sin críticas porque los arneses de producción dividen las sesiones en muestras estructuralmente distintas, lo que complica las líneas de base del grupo.
Al utilizar actor-crítico asimétrico, el crítico obtiene un contexto de entrenamiento privilegiado (recompensas, pruebas, cobertura, parches, metadatos, turnos futuros), mientras que el actor solo ve el estado de implementación. La crítica y el contexto adicional se descartan en la inferencia.
Las recompensas tienen tres niveles: las puntuaciones de las tareas principales requieren que se aprueben todas las pruebas de fallar y aprobar; Las restricciones de comportamiento estándar penalizan la duplicación, las llamadas incorrectas a herramientas y los restos de depuración; Recuperación del archivo de puntuación de incentivos de trayectoria fallida a través de F2 y otorga crédito de prueba parcial.
Cinco expertos se fusionan a través de la destilación basada en políticas de múltiples profesores utilizando KL inverso, un inicio fuera de la política y un truncamiento con detección de deriva de Prune-OPD.
Resultados
Bajo un arnés unificado de Claude Code, KAT-Coder-V2.5 lidera su panel en PinchBench con 94,9, superando al Opus 4.8 con 93,5. Ocupa el segundo lugar en SWE-Bench Pro (65,2 frente a 69,2) y el KAT Code Bench interno (53,1 frente a 57,3).
Sin embargo, está por detrás de Terminal-Bench 2.1, ubicándose en último lugar con 60,7 detrás de GLM-5.1 (61,8) y Opus 4.8 (84,6). En SciCode, obtiene una puntuación de 50,3, igualando a GLM-5.2.
En particular, el KAT-Coder-V2.5-Dev de peso abierto es un MoE independiente de 35 B en total/3 B activo post-entrenado en Qwen3.6-35B-A3B usando ejemplos de 127 K SFT, luego RL. Evaluados según un protocolo interno independiente, sus resultados no son comparables a los de la tabla principal.
Conclusiones clave
KwaiKAT trata la codificación agente como un problema de infraestructura, no como un problema a escala de modelo. AutoBuilder aumentó el éxito en la construcción de entornos del 16,5 % al 57,2 %, lo que generó más de 100 000 entornos verificables en 12 idiomas. Una auditoría de sandbox encontró que aproximadamente el 16 % de las trayectorias de RL fallaron debido al sandbox, no a la política; las correcciones reducen eso a menos del 2%. KAT-Coder-V2.5 supera a PinchBench con 94,9 y ocupa el segundo lugar en SWE-Bench Pro con 65,2, detrás de Opus 4.8. El KAT-Coder-V2.5-Dev de peso abierto es un MoE 35B-A3B independiente bajo Apache-2.0, con sus propios números de referencia.
Consulte el documento, el peso del modelo en la cara abrazada y la página del producto. Todo el crédito por esta investigación va a los investigadores de este proyecto.
Michal Sutter es un profesional de la ciencia de datos con una Maestría en Ciencias de Datos de la Universidad de Padua. Con una base sólida en análisis estadístico, aprendizaje automático e ingeniería de datos, Michal se destaca en transformar conjuntos de datos complejos en conocimientos prácticos.