Um modelo de código aberto que aprendeu na prática

Um modelo de código aberto que aprendeu na prática

A JetBrains lançou o Mellum2.1 em 8 de outubro. É um modelo mixture-of-experts de 12 bilhões de parâmetros feito para agentes de programação, disponível no Hugging Face sob a licença Apache 2.0. Só esses fatos o colocariam como um entre vários lançamentos parecidos deste mês. O que o diferencia é a forma como foi treinado.

O pós-treinamento do Mellum2.1 usa aprendizado por reforço dentro de ambientes reais de programação. Não um banco de testes simulado, nem um conjunto de dados estático de problemas resolvidos. O modelo explora repositórios, edita arquivos e confere as próprias mudanças, do jeito que um desenvolvedor em atividade faz.

Por que a configuração do treinamento importa mais que o número de parâmetros

A maioria dos modelos de código hoje é treinada para prever o próximo trecho de código e depois ajustada com exemplos de bons patches. É um pipeline razoável, e produz modelos capazes de autocompletar e explicar. Mas é uma preparação ruim para a realidade bagunçada de um repositório que não compila, onde o primeiro ajuste quebra um teste e o segundo quebra outra coisa.

A habilidade que importa não é escrever uma função. É fechar o ciclo: formular uma hipótese, mudar algo, observar o resultado, corrigir. Treinar com aprendizado por reforço em um ambiente vivo recompensa exatamente esse comportamento, porque a recompensa vem de a mudança ter funcionado de fato.

É a mesma virada que tornou os agentes de programação úteis desde o início. Um modelo que só sabe escrever código é um autocompletar sofisticado. Um modelo que consegue rodar os testes, ler as falhas e tentar de novo é um colaborador. Os dados de treinamento do Mellum2.1 são o próprio ciclo.

Um modelo de 12B é um tamanho deliberado

Doze bilhões de parâmetros é pouco diante da fronteira. É justamente esse o ponto. Um agente de programação atua em um ciclo apertado, lendo arquivos, rodando comandos e inspecionando diffs, então é chamado o tempo todo. Um modelo barato de rodar e rápido de responder pode ser usado de forma muito mais agressiva do que um que custa dinheiro de verdade a cada passo.

O design mixture-of-experts reforça a mesma ideia. As ativações por token se mantêm modestas mesmo quando a capacidade total cresce, o que mantém a inferência barata sem deixar o modelo sem conhecimento. Para uma ferramenta que pode disparar dezenas de vezes para concluir uma tarefa, essa troca é exatamente a certa.

Está se formando um padrão ao longo de outubro. Modelos pequenos, especializados e com licença aberta aparecem para fazer o trabalho repetitivo dentro de sistemas maiores: aqui a JetBrains, além dos modelos de decisão da Liquid AI, a versão 27B comprimida da Underdog AI. O modelo de fronteira define o teto. Os modelos pequenos definem o piso, e é no piso que a maior parte dos tokens é gasta.

Pesos abertos como estratégia de distribuição

A JetBrains não é um laboratório disputando coroas de benchmark. Ela vende ferramentas para desenvolvedores, e seu incentivo é torná-las melhores, não guardar um modelo. Lançar o Mellum2.1 sob Apache 2.0 deixa o modelo se espalhar pelo ecossistema, inclusive para editores concorrentes e harness de agentes.

Vale reparar nisso. Quando uma empresa de ferramentas abre o código de um modelo de programação, ela aposta que o valor está na integração e no fluxo de trabalho, não nos pesos. É a mesma aposta que muitas empresas de infraestrutura estão fazendo neste ano, e é uma aposta que costuma envelhecer bem. Um modelo que ninguém pode adotar é um modelo que não pode virar padrão.

A Apache 2.0 importa especificamente para a adoção. Uma licença permissiva elimina a revisão jurídica que trava uma grande empresa na hora de testar um modelo novo. Para uma companhia cujos clientes são exatamente essas empresas, lançar um modelo com licença permissiva é uma forma de semear familiaridade antes de vender qualquer coisa.

Como se compara aos modelos de código de fronteira

Os modelos de código de fronteira são melhores em problemas difíceis. Isso não está em discussão e dificilmente mudará logo. O que está em discussão é se toda tarefa de programação precisa da fronteira. A maioria não precisa. Renomear uma função no projeto inteiro, atualizar uma dependência, escrever um teste para um comportamento existente: são tarefas comuns, tediosas e bem ao alcance de um modelo pequeno com um bom harness.

O Mellum2.1 não tenta vencer os maiores modelos nas tarefas em que eles são melhores. Tenta ser bom o suficiente nas tarefas que preenchem o dia de um desenvolvedor. É um objetivo mais estreito, e mais duradouro, porque não depende de ganhar uma corrida que ele não vai ganhar.

Há também uma razão estratégica para uma empresa de ferramentas manter um modelo nesse tamanho. Um modelo pequeno o bastante para rodar localmente pode ser oferecido sem cobrança por consulta, o que remove a medição que deixa os desenvolvedores hesitantes em usar agentes à vontade. Um editor capaz de invocar o próprio modelo sem uma ida e volta pela rede é um produto diferente de um que não consegue, e a diferença aparece em quanto os usuários se dispõem a se apoiar nele.

Por que o aprendizado por reforço em um ambiente real é diferente

A distinção entre treinar em exemplos e treinar em resultados merece mais uma passada, porque é o detalhe mais consequente do lançamento. Um modelo treinado em exemplos aprende como é uma boa saída. Um modelo treinado em resultados aprende quais ações levam a bons resultados, uma habilidade diferente e mais difícil.

Ações são sequências. Um patch que passa nos testes não é uma decisão, mas uma cadeia delas: onde olhar, o que mudar, o que rodar, como ler uma falha. O aprendizado por reforço em um ambiente vivo dá ao modelo um sinal sobre a cadeia inteira, que é a única forma de aprender que algumas escolhas localmente razoáveis levam a um lugar ruim. É a intuição por trás de usar repositórios reais em vez de um conjunto selecionado de problemas.

Essa abordagem é mais cara e mais frágil de operar do que o ajuste supervisionado, e é por isso que mais modelos não a adotam. Ela também tende a produzir agentes que se comportam melhor em situações desconhecidas, porque praticaram se recuperar de estar errados, em vez de apenas imitar o acerto.

O que observar

O teste óbvio é se um agente de 12B treinado assim se sustenta em uma tarefa real de repositório: diagnosticar um teste que falha, propor um patch, verificar o resultado. Se sim, a pergunta interessante passa a ser o quão perto um modelo aberto pequeno consegue chegar da qualidade de código de fronteira quando recebe um bom harness e um ciclo de feedback apertado.

Essa pergunta é mais consequente do que qualquer lançamento isolado de modelo. Se a distância entre um agente de 12B e um modelo de fronteira encolher na prática, então boa parte do mercado de agentes de programação deixa de ser sobre quem tem o melhor modelo e passa a ser sobre quem tem as melhores ferramentas em torno de um modelo bom o suficiente. O Mellum2.1 é um dado pequeno e concreto nessa direção, e a direção é o que importa.