GPT-6 Astra corrigiu os loops do Qwen: a precisão subiu de 7,9% para 48,1%

Um modelo local recebe um problema de matemática, começa a raciocinar e fica preso em repetições. Os tokens são consumidos, o usuário espera e a resposta completa não chega. Uma equipe do MIT CSAIL demonstrou uma forma experimental de corrigir essa falha: pedir a outro modelo de linguagem que encontre a origem do loop e ajuste os parâmetros numéricos da rede afetada. Para desenvolvedores, há uma pista útil: às vezes, a baixa precisão está ligada à incapacidade do modelo de concluir a resolução.

No experimento publicado, o GPT-6 Astra editou o Qwen3.5-0.8B. Após a intervenção, o resultado no teste de matemática MATH-500 subiu de 7,9% para 48,1%. Os autores chamaram a abordagem de weight-space programming — programação por meio dos pesos do modelo. Os resultados e as condições do experimento estão na publicação dos pesquisadores.

O que exatamente foi corrigido

Os pesos são os números que determinam como uma rede neural processa os dados de entrada. Normalmente, eles são alterados durante o treinamento. Neste caso, o agente recebeu acesso aos parâmetros e a possibilidade de testar hipóteses, mas foi proibido de realizar o ajuste fino convencional por meio do cálculo de gradientes.

Um exemplo simples ilustra o problema: o modelo já chegou à fórmula necessária, mas volta a explicar a etapa anterior e retorna a ela mais uma vez. A resposta é interrompida quando se esgota a quantidade permitida de tokens. Na avaliação, essa execução pode ser considerada malsucedida mesmo que a parte útil da solução já tenha aparecido.

Segundo os pesquisadores, o agente encontrou em duas camadas do Qwen um componente que sustentava as repetições e reduziu sua contribuição. A mudança afetou apenas 0,016% dos parâmetros. O processo se parece com a busca por uma falha específica: primeiro, identificar onde surge o comportamento indesejado; depois, verificar se uma pequena intervenção ajuda.

O interesse prático está na própria sequência de trabalho. O agente analisa a arquitetura da rede, propõe uma explicação para a falha, altera parâmetros e recebe feedback. Para uma equipe que mantém seu próprio modelo, essa pode ser uma ferramenta adicional de diagnóstico. O experimento ainda não oferece uma receita universal para corrigir qualquer tipo de repetição.

Por que o ganho de precisão exige ressalvas

Os autores associam explicitamente a melhora à eliminação dos loops. Por isso, o resultado não pode ser interpretado automaticamente como a aquisição de novos conhecimentos matemáticos. Se antes o modelo não chegava à resposta final, remover esse obstáculo, por si só, pode elevar drasticamente sua pontuação.

Para um produto, a diferença é importante. O usuário precisa de um resultado completo, e corrigir as repetições pode ser muito útil. Mas um gerente de produto que prometa uma capacidade maior de raciocínio matemático em geral após essa intervenção precisa verificar essa promessa separadamente nas tarefas do seu serviço.

O trabalho inclui um teste revelador com outro modelo pequeno, o Gemma 3 270M. Os pesquisadores não obtiveram uma melhora comparável. Esse resultado negativo limita a conclusão: corrigir com sucesso uma falha acentuada não significa que o agente tenha aprendido a melhorar qualquer rede de forma confiável.

Além disso, a ausência de treinamento adicional não torna o procedimento gratuito. A análise, as execuções de teste e a avaliação dos resultados exigem recursos computacionais. Ao comparar essa abordagem com outras formas de correção, a equipe terá de considerar todos esses custos. O custo de um erro também importa: mesmo uma pequena mudança nos parâmetros precisa ser avaliada no comportamento geral do modelo, incluindo as tarefas para as quais ele foi escolhido originalmente.

O que verificar no seu próprio modelo

Vale começar pelos registros de respostas malsucedidas. Com que frequência o modelo se repete? Quantas solicitações terminam ao atingir o limite? Esses casos são diferentes dos erros comuns de cálculo ou de informação? Essa classificação ajuda a entender qual problema realmente precisa ser resolvido.

Em seguida, é necessário um conjunto de testes que o agente não use ao selecionar as mudanças. Ele deve servir para comparar a qualidade das respostas, o comprimento da geração e o tempo de espera antes e depois da intervenção. Também é útil verificar separadamente os fluxos de trabalho habituais: a melhora em um teste pode vir acompanhada de uma piora em outro.

Para equipes que trabalham por meio de uma API fechada, a edição direta dos pesos geralmente não está disponível. Mas a lição de diagnóstico também se aplica nesse cenário: diferencie erros de conhecimento, erros de raciocínio e respostas incompletas. Essa distinção determina o próximo passo — mudar o modelo, as configurações de geração ou a arquitetura da própria aplicação. O experimento do MIT dá motivos para examinar mais de perto as causas das falhas antes de reservar orçamento para um novo treinamento.