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

A equipe da ecom.tech testou se é possível fazer um modelo pequeno, o Qwen3-4B-Instruct, escrever testes unitários úteis para um backend em Kotlin não com o SFT comum, mas por meio de um algoritmo evolutivo, o Evolution Strategies. O resultado prático foi forte: na geração de testes, a abordagem superou tanto o ajuste supervisionado (SFT) quanto o GRPO em reward final e coverage. Mas, junto com o ganho em especialização, os pesquisadores viram o outro lado: quanto mais o modelo era ajustado à tarefa específica, mais ele perdia de suas capacidades gerais.

O motivo do experimento era bem prático. No serviço de geração de código da equipe, havia um problema típico: o LLM primeiro entrega um código funcional e depois escreve testes que parecem plausíveis, mas não seguem as convenções internas e nem sempre verificam a lógica de negócio que realmente importa. Para avaliar se o ajuste fino poderia corrigir isso, os pesquisadores montaram um dataset de 1500 exemplos: 1300 para treino e 200 para teste. Na entrada, o modelo recebia não só a classe a ser testada, mas todo o contexto ao redor, reunido por um agente baseado em qwen-code, e na saída devia gerar um arquivo pronto de testes unitários.

Foram usadas duas métricas. A primeira é o Coverage, não no sentido usual de cobertura de linhas, mas como cobertura funcional: até que ponto o teste gerado atinge a mesma funcionalidade pública do teste de referência. A segunda é o CodeBLEU, métrica que olha não só a coincidência de tokens, mas também a sintaxe e o fluxo de dados do código. Como o CodeBLEU padrão não suporta Kotlin, a equipe teve de adicionar esse suporte separadamente, com tree-sitter-kotlin e um conjunto próprio de palavras-chave. A função de reward foi mantida simples: peso de 0,6 para o CodeBLEU e 0,4 para o Coverage, para considerar ao mesmo tempo a forma do código e sua utilidade prática.

No experimento, o Evolution Strategies funcionou assim: em vez de atualização por gradiente, foram geradas cerca de 30 cópias perturbadas do modelo base, com ruído gaussiano somado aos pesos; cada cópia gerava uma resposta em modo determinístico, que era avaliada pela recompensa. Depois, os pesos base eram deslocados na direção das mudanças que deram o melhor resultado. Essa abordagem é mais fácil de paralelizar, não exige armazenar gradientes pesados e, na opinião dos autores, é menos propensa a reward hacking.

Como base, usou-se o projeto aberto Evolution Strategies at Scale com aceleração por vLLM, e o modelo foi treinado em um cluster de 8 H100. Como percorrer todo o dataset a cada iteração é caro, foi adotado batching: 32 exemplos escolhidos aleatoriamente por vez.

O experimento mostrou ganho visível já após 500 iterações. No fim do treino, o CodeBLEU subiu 21,3% em relação ao modelo base e o Coverage, 18,6%. O melhor resultado do ES atingiu coverage de 0,7381 e o maior reward final; nas métricas escolhidas, superou não só SFT e GRPO, mas até o muito maior Qwen3-Coder-480B. O quadro dos métodos concorrentes foi revelador: o SFT gerava testes sintaticamente limpos, mas acertava pouco a lógica necessária, enquanto o GRPO, nesse setup, piorou nas duas métricas. Para uma tarefa de engenharia específica, a conclusão é direta: o ajuste evolutivo pode ser uma ferramenta funcional mesmo para um modelo relativamente pequeno.

Depois veio a parte menos agradável. Diante de trabalhos recentes sobre esquecimento catastrófico, a equipe verificou separadamente o que acontece com o conhecimento geral do modelo ajustado. Para isso, a versão ES do Qwen3-4B-Instruct foi avaliada no GPQA, um benchmark científico difícil. A accuracy caiu em média 2,1% em zero-shot e 5,3% em five-shot chain-of-thought. Especialmente visível foi a perda da capacidade de usar dicas de contexto: o benefício dos exemplos few-shot encolheu de 41% a 72%. A hipótese coincide com o que outros estudos mostram: o ES faz mudanças densas em quase todos os pesos do modelo, e por isso ele resolve melhor a tarefa-alvo, mas se afasta mais do estado base e esquece parte das habilidades anteriores.

O que isso significa na prática? O Evolution Strategies parece menos um substituto universal do RL e mais uma ferramenta especializada e poderosa para empresas que precisam extrair o máximo de um modelo para um pipeline específico. Se há uma função de reward clara, recursos computacionais suficientes e é aceitável abrir mão de parte das capacidades gerais, o ES já pode dar um ganho palpável. Para times de produto, é também um lembrete: melhorar em uma tarefa não é de graça, e a disputa daqui para frente será não só por novas métricas, mas por formas de ajustar modelos sem perder sua flexibilidade básica.