KwaiKAT lança KAT-Coder-V2.5: modelo de codificação agêntica treinado em mais de 100 mil ambientes verificáveis

O modelo que aprendeu a programar dentro de repositórios reais

A equipe KwaiKAT, laboratório de IA da gigante chinesa Kuaishou, acaba de lançar o KAT-Coder-V2.5: um modelo de codificação agêntica treinado para operar dentro de repositórios executáveis, não apenas para gerar código em turno único. O diferencial não está no tamanho do modelo, mas na infraestrutura de treinamento que produziu mais de 100.000 ambientes verificáveis em 12 linguagens de programação.

AutoBuilder: ambientes que realmente rodam os testes

O coração da abordagem está no AutoBuilder, um sistema que constrói ambientes de desenvolvimento isolados a partir de pull requests e commits reais. Cada tarefa é definida como um trio: descrição precisa do problema, repositório executável e conjunto de testes de validação. O patch só é considerado correto se passar em todos os testes.

As descrições das tarefas não usam o texto bruto das issues. Em vez disso, são regeneradas em três partes: enunciado do problema (baseado no patch dourado), requisitos (derivados do patch de teste) e restrições de interface (inferidas de ambos). Um filtro de clareza descarta qualquer coisa ambígua, incompleta ou internamente inconsistente.

Do lado do ambiente, um agente de build analisa o repositório e escreve um script de configuração que instala dependências e executa testes a partir de um checkout limpo. Um agente de verificação executa esse script em sandbox isolado. A regra de aceitação é particularmente interessante: a verificação não lê códigos de saída ou padrões de log — ela analisa a saída estruturada do framework de testes e só aceita o ambiente quando mais de 90% dos testes esperados são coletados e os resultados de pass/fail se reproduzem entre execuções.

O resultado: a taxa de sucesso na construção de ambientes saltou de 16,5% para 57,2%, gerando mais de 100.000 ambientes verificáveis. Histórico do Git, metadados de commit e outros rastros exploráveis são removidos para que os agentes não possam ler a solução de referência diretamente do repositório.

Filtragem de dados: além do sucesso nos testes

Filtrar trajetórias apenas pelo resultado final dos testes é enganoso. Algumas execuções que passam dependem de hard-coding, atalhos mecânicos ou atalhos específicos de teste. Algumas execuções que falham contêm comportamentos valiosos de busca, localização e reparo.

A equipe implementou três mecanismos de filtragem: para quase-acertos, dicas de processo direcionadas indicam o que inspecionar sem revelar a solução — isso elevou a taxa de aprovação de tarefas antes zeradas para ~20%. Para execuções bem-sucedidas, gates baseados em regras removem trajetórias inválidas, instáveis ou exploratórias, seguidas por uma pontuação que avalia exploração, localização, raciocínio pré-edição, fidelidade à especificação, minimalidade do patch e recuperação de erros. Um terceiro mecanismo randomiza nomes de ferramentas, convenções de argumentos e templates de prompt para evitar overfitting.

Infraestrutura: quando o sandbox sabotava o aprendizado

Durante o treinamento do KAT-Coder-V2, as curvas de recompensa lentas foram inicialmente atribuídas ao algoritmo de RL. Uma auditoria revelou que ~16% das trajetórias falhavam por problemas de infraestrutura, não pela política do modelo — com desalinhamentos de boundary esvaziando observações por até 40 passos e corrompendo recompensas.

Três correções de infraestrutura seguiram: política de evicção de imagens que reduziu o uso de disco de 95% para 60%, eliminando rollouts inválidos por timeout de 6-7% para menos de 1%; correção de variáveis de ambiente durante inicialização do sandbox remoto, reduzindo erros de sobrescrição de sistema abaixo de 1%; e bypass dos endpoints de chat convencionais — que causavam 40% de deriva de tokens em escala de ~200 turnos — chamando diretamente o endpoint /generate. Juntas, essas atualizações reduziram a taxa de erro do sandbox de 16% para menos de 2%.

PPO Assimétrico e recompensa em três camadas

O time escolheu PPO com GAE em vez de métodos critic-free porque os harnesses de produção dividem sessões em amostras estruturalmente distintas, complicando baselines de grupo. Usando ator-crítico assimétrico, o crítico recebe contexto privilegiado de treinamento (recompensas, testes, cobertura, patches, metadados), enquanto o ator vê apenas o estado do rollout. O crítico e o contexto extra são descartados na inferência.

As recompensas operam em três camadas: pontuações de tarefa principal exigem que todos os testes passem; restrições de comportamento penalizam duplicação, chamadas ruins de ferramenta e remanescentes de debug; incentivos de trajetórias falhas pontuam recuperação de arquivos e dão crédito parcial por testes. Cinco especialistas são fundidos via Multi-Teacher On-Policy Distillation com KL reverso.

Resultados nos benchmarks

Sob um harness unificado do Claude Code, o KAT-Coder-V2.5 lidera no PinchBench com 94,9, superando o Opus 4.8 (93,5). Fica em segundo no SWE-Bench Pro com 65,2 (vs 69,2 do líder) e no benchmark interno KAT Code Bench (53,1 vs 57,3). No entanto, fica atrás no Terminal-Bench 2.1 (60,7, último lugar) e marca 50,3 no SciCode.

Importante: a variante aberta KAT-Coder-V2.5-Dev é um modelo separado de 35B total / 3B ativos (MoE), pós-treinado sobre Qwen3.6-35B-A3B com 127K exemplos SFT e depois RL. Está disponível no Hugging Face sob licença Apache-2.0, mas seus números de benchmark não são diretamente comparáveis com a tabela principal.

Por que isso importa

O KAT-Coder-V2.5 mostra que codificação agêntica de alta performance não depende exclusivamente de escala de modelo. O trabalho de infraestrutura — construir ambientes verificáveis, depurar o sandbox e filtrar dados de treinamento com rigor — foi tão determinante quanto a arquitetura do modelo. A variante open-weight sob Apache-2.0 também coloca capacidades de coding agent nas mãos da comunidade, embora com performance diferente do modelo flagship.