ecom.tech comparou o ajuste fino evolutivo do Qwen3-4B com SFT e GRPO para testes em Kotlin

A equipe ecom.tech testou se um modelo pequeno Qwen3-4B-Instruct poderia ser feito para escrever testes unitários úteis para backends Kotlin não através de fine-tuning supervisionado padrão, mas através de um algoritmo evolutivo chamado Evolution Strategies. O resultado prático foi forte: na tarefa de geração de testes, essa abordagem superou tanto o fine-tuning supervisionado quanto o GRPO em termos de recompensa final e cobertura. Mas junto com a vitória na especialização, os pesquisadores viram o lado negativo: quanto melhor o modelo era ajustado para uma tarefa estreita, mais notavelmente ele perdia algumas de suas capacidades gerais.

A motivação para o experimento era bastante prática. Dentro de seu serviço de geração de código, a equipe enfrentava um problema típico: LLMs primeiro produzem código funcionando, depois escrevem testes para ele que parecem plausíveis mas não seguem convenções internas e nem sempre verificam a lógica de negócios realmente importante. Para avaliar se isso poderia ser corrigido através de fine-tuning, os pesquisadores montaram um conjunto de dados de 1.500 exemplos: 1.300 para treinamento e 200 para teste. O modelo recebia não apenas a classe sendo testada, mas também o contexto completo ao redor dela, coletado por um agente baseado em qwen-code, e precisava gerar um arquivo de teste unitário pronto para uso.

Eles usaram duas métricas para avaliação. A primeira foi Coverage, mas não no sentido familiar de cobertura de linhas—mas como cobertura funcional: o quão bem o teste gerado realmente cobre a mesma funcionalidade pública que o teste de referência. A segunda foi CodeBLEU, uma métrica que olha não apenas para correspondências de tokens, mas também para sintaxe e fluxo de dados no código. Como o CodeBLEU padrão não suporta Kotlin, a equipe precisou adicionar esse suporte separadamente através de tree-sitter-kotlin e um conjunto personalizado de palavras-chave.

A função de recompensa era simples: 0,6 de peso foi para CodeBLEU e 0,4 para Coverage, para considerar tanto a forma do código quanto sua utilidade prática. A essência das Evolution Strategies neste experimento funcionava assim: em vez de atualizações baseadas em gradiente, eles pegaram cerca de 30 cópias perturbadas do modelo base, adicionando ruído Gaussiano aos pesos, então fizeram cada cópia gerar uma resposta em modo determinístico e a avaliaram com a recompensa. Depois disso, os pesos base foram deslocados em direção às mudanças que produziram os melhores resultados. Essa abordagem é mais simples de paralelizar, não requer armazenamento de gradientes pesados e, segundo os autores, é menos propensa a reward hacking.

Eles usaram um projeto aberto Evolution Strategies at Scale com aceleração vLLM e treinaram o modelo em um cluster de 8 H100s. Devido ao custo de um passo completo através do conjunto de dados em cada iteração, eles introduziram batching: selecionando aleatoriamente 32 exemplos por lote.

O experimento mostrou melhoria notável já após 500 iterações. Ao final do treinamento, CodeBLEU tinha aumentado 21,3% em relação ao modelo base, e Coverage 18,6%. O melhor resultado do ES forneceu uma cobertura de 0,7381 e recompensa final máxima; pelas métricas selecionadas, superou não apenas SFT e GRPO, mas até o Qwen3-Coder-480B maior.

A imagem com os métodos concorrentes foi reveladora: SFT produziu testes sintaticamente limpos, mas teve dificuldade em atingir a lógica necessária, enquanto GRPO realmente degradou em ambas as métricas nesta configuração.

Para uma tarefa de engenharia estreita, a conclusão parece direta: fine-tuning evolutivo pode ser uma ferramenta viável mesmo para um modelo relativamente pequeno. Mas então veio a parte menos agradável.

No contexto de trabalhos recentes sobre catastrophic forgetting, a equipe verificou separadamente o que acontece com o conhecimento geral do modelo fine-tuned. Eles rodaram a versão ES do Qwen3-4B-Instruct através de GPQA—um benchmark científico desafiador. A queda na acurácia foi em média 2,1% em zero-shot e 5,3% em five-shot chain-of-thought. A capacidade de usar dicas contextuais foi particularmente afetada: o benefício dos exemplos few-shot caiu 41–72%.

A hipótese se alinha com o que outras pesquisas mostram: ES faz mudanças densas em quase todos os pesos do modelo, o que o ajuda a resolver melhor a tarefa alvo, mas o faz desviar mais da linha de base e esquecer algumas habilidades anteriores.

O que isso significa na prática? Evolution Strategies não parece ser um substituto universal para RL, mas como uma poderosa ferramenta especializada para empresas que se importam mais em extrair o máximo de desempenho localmente de um modelo para um pipeline específico. Se há uma função de recompensa clara, recursos computacionais suficientes e tolerância para um compromisso em capacidades gerais, ES pode já entregar ganhos significativos.

Mas para equipes de produto, também é um lembrete: melhorar a qualidade em uma tarefa não é gratuito, e a batalha à frente será não apenas sobre novas métricas, mas sobre formas de fazer fine-tune de modelos sem perder sua flexibilidade de linha de base.