Por Canuto  

El equipo de KwaiKAT presentó KAT-Coder-V2.5, un modelo agentic diseñado para trabajar dentro de repositorios ejecutables y validar sus cambios mediante pruebas reales. La propuesta combina más de 100.000 entornos verificables, entrenamiento con PPO y una auditoría de infraestructura que redujo fallas del sandbox de aproximadamente 16% a menos de 2%.
***

  • AutoBuilder elevó de 16,5% a 57,2% la tasa de éxito al construir entornos verificables en 12 lenguajes.
  • KAT-Coder-V2.5 obtuvo 94,9 en PinchBench y superó a Opus 4.8, aunque quedó último en Terminal-Bench 2.1.
  • La variante abierta KAT-Coder-V2.5-Dev utiliza un modelo MoE de 35B de parámetros totales y 3B activos bajo Apache-2.0.


Un modelo pensado para repositorios reales

El equipo de KwaiKAT, perteneciente a Kuaishou, presentó KAT-Coder-V2.5 como un modelo de codificación agentic. Su objetivo consiste en operar dentro de repositorios reales y ejecutables, en lugar de limitarse a producir código en un único turno.

La compañía ofrece el modelo servido a través de StreamLake. Además, lanzó KAT-Coder-V2.5-Dev, una variante de pesos abiertos disponible en Hugging Face bajo la licencia Apache-2.0.

La investigación define cada tarea verificable como un triplete compuesto por una descripción precisa, un entorno de repositorio ejecutable y un conjunto de pruebas de validación. El parche solo se considera correcto cuando supera todas las pruebas previstas.

Las tareas proceden de solicitudes de extracción y commits reales, siguiendo el enfoque de SWE-bench. El cambio de código fusionado funciona como parche dorado, mientras que el cambio de prueba correspondiente aporta el parche de validación.

KwaiKAT descarta el texto original del problema como especificación principal. En su lugar, regenera las descripciones a partir del parche dorado, los requisitos derivados del parche de prueba y las restricciones de interfaz inferidas de ambos.

Una revisión de claridad elimina los casos ambiguos, incompletos, insuficientemente especificados o internamente inconsistentes. Este filtro busca impedir que el modelo reciba tareas cuyo resultado dependa de interpretaciones arbitrarias.

AutoBuilder crea entornos que pueden comprobarse

AutoBuilder se ocupa de construir el lado operativo de cada tarea. Un agente analiza el repositorio y redacta un script de configuración capaz de instalar dependencias y ejecutar pruebas desde una nueva extracción.

Después, un agente de verificación ejecuta el script dentro de un sandbox aislado. La aceptación no depende de leer códigos de salida ni de buscar patrones específicos en los registros.

El sistema analiza la salida estructurada del marco de pruebas. Solo acepta un entorno cuando se recopila más del 90% de las pruebas esperadas y los resultados de aprobación y falla se reproducen en ejecuciones posteriores.

Las fallas se convierten en información estructurada para iniciar reparaciones iterativas. Esta retroalimentación permitió combinar un entorno base preconfigurado, plantillas de construcción y una biblioteca recuperable de recetas destiladas.

Con esa combinación, la tasa de éxito en la construcción de entornos pasó de 16,5% a 57,2%. El proceso generó más de 100.000 entornos verificables que abarcan 12 lenguajes de programación.

El equipo también eliminó el historial de Git, los metadatos de los commits y otras huellas explotables. Así, los agentes no pueden leer desde el repositorio la solución de referencia que deberían descubrir mediante su propio proceso.

La decisión resulta relevante porque un agente de código necesita algo más que un archivo de entrada y una respuesta textual. Debe explorar, localizar el problema, editar archivos, ejecutar herramientas y recuperar errores dentro de un entorno controlado.

Filtrado de trayectorias y problemas de infraestructura

KwaiKAT sostiene que filtrar las trayectorias únicamente por el éxito final de las pruebas puede producir datos engañosos. Algunas ejecuciones exitosas recurren a códigos duros, evasiones o atajos diseñados para superar el arnés.

Al mismo tiempo, ciertas ejecuciones fallidas contienen comportamientos útiles de búsqueda, localización y reparación. Por ello, el equipo desarrolló un proceso que conserva señales de progreso sin aceptar trayectorias explotativas.

En los casos cercanos al éxito, las pistas dirigidas a nivel de proceso indican qué debe inspeccionarse o verificarse, pero no revelan la solución. Esa intervención elevó aproximadamente a 20% la aprobación de tareas que antes no tenían éxito.

Como las trayectorias sugeridas contienen información que no estaría disponible durante la inferencia, KwaiKAT corrige y verifica el parche. Después, regenera una trayectoria sin sugerencias a partir del contexto original de la tarea.

El sistema conserva únicamente las muestras que superan la verificación, no contienen filtraciones y mantienen consistencia con el parche. Para las ejecuciones exitosas, filtros basados en reglas descartan comportamientos inválidos, inestables o explotativos.

Una etapa de puntuación evalúa la exploración, la localización, el razonamiento previo a la edición, la fidelidad a la especificación y el respeto por las convenciones del repositorio. También considera la minimalidad del parche, la calidad de la verificación, la recuperación y la honestidad del proceso.

El equipo introdujo además aleatorización en los nombres de herramientas, los argumentos, los formatos de salida y las plantillas de aviso. La funcionalidad se mantiene, pero el modelo no puede depender con tanta facilidad de un arnés fijo.

La investigación también inyecta perturbaciones realistas, como dependencias faltantes, fallas transitorias de comandos, salidas truncadas y registros ruidosos. La intención es reducir el sobreajuste y acercar el entrenamiento a condiciones operativas menos previsibles.

La auditoría del sandbox cambió el entrenamiento

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 descubrió que cerca de 16% de las trayectorias fallaban por problemas del sandbox y no por la política del modelo.

En algunos casos, las desalineaciones de límites vaciaban las observaciones durante aproximadamente 40 pasos. Esa pérdida de información terminaba corrompiendo las recompensas y dificultaba distinguir un fallo del agente de un fallo de infraestructura.

La primera corrección aplicó una política de desalojo de imágenes de primera liberación. El cambio redujo el uso del disco de 95% a 60% y llevó los despliegues inválidos causados por tiempos de espera desde 6%-7% hasta menos de 1%.

La segunda solución corrigió las variables de entorno durante la inicialización remota del sandbox. Según el equipo, esto detuvo sobreescrituras del sistema que alteraban las recompensas en 6%-7% de las muestras y redujo esos errores por debajo de 1%.

La tercera actualización incorporó un Gateway Server que evita los puntos finales de chat convencionales. Esos puntos producían una desviación de 40% en los tokens a una escala aproximada de 200 turnos, debido a la reaplicación de apply_chat_template y la retokenización.

El servidor llama directamente a /generate para conservar la alineación entre los tokens del entrenamiento y los del despliegue. En conjunto, las actualizaciones redujeron la tasa de error de retroalimentación del sandbox de aproximadamente 16% a menos de 2%.

El equipo también reportó una reducción de un orden de magnitud en los colapsos del entrenamiento. La conclusión de KwaiKAT es que la calidad de la infraestructura puede limitar el aprendizaje antes de que aparezcan los límites del algoritmo.

PPO asimétrico y resultados de evaluación

Para el entrenamiento, los investigadores eligieron PPO con GAE en lugar de métodos de trayectoria sin crítico. La razón fue que los arneses de producción dividen las sesiones en muestras estructuralmente distintas, lo que complica el uso de líneas base grupales.

El sistema utiliza un actor y un crítico asimétricos. El crítico recibe durante el entrenamiento un contexto privilegiado con recompensas, pruebas, cobertura, parches, metadatos y turnos futuros.

El actor solo observa el estado disponible durante el despliegue. El crítico y la información adicional se eliminan durante la inferencia, para impedir que el modelo utilice datos que no tendría en una ejecución real.

Las recompensas se dividen en tres niveles. Las puntuaciones de la tarea principal exigen superar todas las pruebas que pasan de falla a éxito y las que permanecen en éxito.

Las restricciones conductuales penalizan la duplicación, las llamadas defectuosas a herramientas y los restos de depuración. Los incentivos de trayectorias fallidas puntúan la recuperación de archivos mediante F2 y otorgan crédito parcial por las pruebas.

Cinco expertos se combinan mediante Multi-Teacher On-Policy Distillation, con divergencia KL inversa, un inicio fuera de política y truncamiento consciente de desviaciones a través de Prune-OPD.

Bajo un arnés unificado de Claude Code, KAT-Coder-V2.5 lideró el panel de PinchBench con 94,9. La cifra superó a Opus 4.8, que obtuvo 93,5 en esa evaluación.

En SWE-Bench Pro, el modelo ocupó el segundo lugar con 65,2, detrás de Opus 4.8, que alcanzó 69,2. En el KAT Code Bench interno consiguió 53,1 frente a 57,3 del modelo líder.

El resultado más débil apareció en Terminal-Bench 2.1. KAT-Coder-V2.5 quedó último con 60,7, por debajo de GLM-5.1, con 61,8, y de Opus 4.8, con 84,6.

En SciCode, el modelo obtuvo 50,3 y empató con GLM-5.2. El conjunto de resultados muestra una ventaja clara en PinchBench, pero también un desempeño desigual entre distintos tipos de tareas agentic.

La variante abierta tiene métricas separadas

KAT-Coder-V2.5-Dev no es simplemente una versión con menos capacidad del modelo insignia. Se trata de un modelo MoE separado, con 35B de parámetros totales y 3B activos.

La variante abierta recibió postentrenamiento sobre Qwen3.6-35B-A3B. Su proceso incluyó 127.000 ejemplos de ajuste supervisado y una etapa posterior de aprendizaje por refuerzo.

KAT-Coder-V2.5-Dev se distribuye bajo Apache-2.0. Esa licencia permite estudiar y reutilizar los pesos dentro de las condiciones establecidas por el proyecto.

Sus resultados proceden de un protocolo interno separado. Por esa razón, la investigación advierte que sus cifras no son comparables directamente con la tabla principal del modelo insignia.

La separación de métricas evita presentar como equivalentes dos configuraciones con entrenamiento, evaluación y objetivos diferentes. También permite analizar la variante abierta según sus propias condiciones de prueba.

La propuesta de KwaiKAT pone el foco en la infraestructura, los datos verificables y la calidad del proceso. En este enfoque, aumentar el tamaño del modelo no basta si los entornos no ejecutan correctamente las pruebas.

La disponibilidad de más de 100.000 entornos puede ampliar la diversidad de tareas para el entrenamiento. Sin embargo, el desempeño desigual en las evaluaciones indica que todavía existen diferencias importantes entre explorar repositorios, usar terminales y resolver problemas científicos.

La fuente de la investigación señala que KAT-Coder-V2.5 lidera PinchBench y ocupa el segundo puesto en SWE-Bench Pro. También destaca que la auditoría del sandbox redujo errores capaces de distorsionar el aprendizaje por refuerzo.

En conjunto, el lanzamiento representa un intento de tratar la codificación agentic como un problema de sistemas completos. El modelo, el arnés, el sandbox, las pruebas y la selección de trayectorias deben funcionar de forma coordinada para que los resultados sean confiables.


Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín