Pesquisa · 2026-10-24 · Todas as pesquisas

+23 pontos em um modelo aberto de 70B, sem novos dados humanos. O que o RLVR faz, e o que não faz.

Elevamos o Apertus-70B de 41.6% para 64.8% em problemas de programação reservados em uma única rodada, deixando o modelo aprender só com as próprias respostas que passaram nos testes. Também descobrimos onde o método para.

Photo: Nemuel Sereti / Pexels

O Apertus-70B é o modelo totalmente aberto da Swiss AI Initiative: pesos, dados de treino e receita são todos públicos. Seus autores o alinharam com preferências humanas. Ele nunca tinha sido treinado com aprendizado por reforço com recompensas verificáveis, a técnica por trás da maior parte do progresso recente em programação e matemática.

Isso fez dele um teste limpo. Se aplicarmos o método a um modelo que nunca o viu, quanto ele avança, e o que exatamente avança?

Em uma rodada, em problemas de programação reservados, ele foi de 41.6% para 64.8%. Este texto é sobre como, e sobre os três pontos em que o método parou de funcionar, porque eles são tão úteis quanto a manchete.

Primeiro, o que não funcionou: ensinar pelo exemplo

O jeito intuitivo de deixar um modelo melhor em raciocínio é mostrar a ele bons raciocínios. Pegamos soluções detalhadas de alta qualidade de modelos mais fortes e fizemos ajuste fino do Apertus com elas.

Ele piorou, e piorou quanto mais treinávamos. Num conjunto de problemas recentes de programação competitiva, o modelo base resolvia 24%. Depois de 8,000 exemplos, resolvia 14%. Depois de 37,000, resolvia 10%.

Verificamos os dados, e os dados estavam limpos. O problema era o que o modelo aprendia com eles. Ele aprendeu a soar como o modelo mais forte: explicações confiantes e bem estruturadas, seguidas de código que não funcionava. A imitação ensina estilo. Não ensina a capacidade por baixo dele.

O que funcionou: aprender só com as próprias respostas que passam

A alternativa inverte a origem dos dados de treino. Em vez de aprender com as soluções de outro, o modelo:

1. gera várias tentativas para cada problema,
2. tem cada tentativa verificada automaticamente, rodando os testes ou comparando a resposta final,
3. mantém só as tentativas que passaram,
4. é treinado com elas.

Nada entra no conjunto de treino sem ter sido verificado como correto, e tudo nele veio do próprio modelo. Essa é toda a ideia por trás do RLVR: a recompensa não é a opinião de um juiz, é um teste que não admite discussão.

Em matemática de nível escolar (GSM8K), a primeira rodada levou o Apertus de 65.2% para 74.6%, um ganho de 9.4 pontos. A mesma mecânica do experimento de imitação. A única diferença foi de onde vieram os dados.

O número que nos mostrou o próximo passo

Antes de investir em programação, fizemos uma pergunta de diagnóstico simples: o modelo é incapaz de escrever esse código, ou só inconsistente nisso?

As duas coisas parecem idênticas se você deixa o modelo responder uma única vez. Parecem muito diferentes se você o deixa tentar 24 vezes. Num benchmark padrão de programação, o Apertus resolvia 38.2% na primeira tentativa, mas 62.4% dos problemas pelo menos uma vez em 24 tentativas.

Essa diferença de 24 pontos é a chave. A capacidade já estava lá; o modelo só não a produzia de forma consistente. Isso significava que não precisávamos de um pré-treino adicional caro. Precisávamos transformar "às vezes" em "de forma confiável".

O resultado: +23.2 pontos em uma rodada

Montamos um banco de 8,445 problemas de Python verificados, cada um com seus próprios testes, e removemos tudo o que se sobrepunha aos nossos conjuntos de avaliação. O Apertus gerou tentativas, cada tentativa foi executada contra seus testes, e 11,727 soluções corretas viraram o conjunto de treino.

Em problemas que ele nunca tinha visto, da mesma distribuição:

Esse é o maior ganho de todo o projeto, a partir de uma única rodada, sem nenhum dado novo escrito por humanos.

Onde ele para

Três descobertas definem os limites do método. Achamos que elas importam mais do que a manchete para quem pretende usá-lo.

O ganho pertence ao tipo de problema em que você treina. O mesmo modelo melhorado, avaliado num benchmark de programação escrito em outro estilo, não melhorou nada: 38.2% antes, 37.8% depois. O modelo ficou muito melhor nos problemas que praticou, não em programação em geral. A regra prática é simples e rígida: treine na distribuição em que você será avaliado, e, para uma empresa, isso significa nas suas próprias tarefas.

Funciona uma vez, não repetidamente. Uma segunda rodada no banco de programação não fez nada: de 64.8% para 64.0%. Em matemática, a segunda rodada acrescentou só 1.4 ponto. O método converte em desempenho a diferença entre "às vezes" e "de forma confiável", e faz quase tudo isso na primeira passada. O tamanho do ganho é mais ou menos o tamanho da diferença de partida. Ir além desse ponto exige problemas mais difíceis ou outra técnica, não mais do mesmo.

Treinar mais nas mesmas tentativas piora o resultado. Quando reutilizamos um lote de tentativas geradas por várias passadas de treino, o desempenho caiu de forma constante, de 76.0% para 74.8%. Depois da primeira passada, o modelo já não é o mesmo que produziu aquelas tentativas, então ele está aprendendo com dados desatualizados. A solução é gerar tentativas novas a cada rodada em vez de reutilizar as antigas.

O que isso significa para uma empresa

O método é geral. Qualquer modelo aberto, qualquer tarefa em que uma resposta possa ser verificada automaticamente: código que precisa passar nos testes, números que precisam bater com uma fonte, um documento que precisa cumprir um conjunto de regras. A maioria das empresas tem mais tarefas assim do que imagina.

Ele também estabelece expectativas honestas. O RLVR não vai transformar um modelo em algo que ele não conseguia fazer nem num dia bom. O que ele faz é tornar o dia bom o dia normal, exatamente no trabalho que importa para você. Para a maioria dos usos empresariais, essa é a diferença entre uma demo e uma ferramenta.

Onde isso rodou

Treinar assim um modelo de 70 bilhões de parâmetros significa gerar e verificar centenas de milhares de tentativas. Rodamos no LUMI, o supercomputador EuroHPC hospedado pelo CSC em Kajaani, na Finlândia, em aceleradores AMD MI250X, com uma alocação avaliada de forma competitiva pela EuroHPC Joint Undertaking (AI Factory Playground, EHPC-AIF-2026PG01-685).

Agradecemos à EuroHPC Joint Undertaking por conceder a este projeto acesso ao supercomputador EuroHPC LUMI, hospedado pelo CSC (Finlândia) e pelo consórcio LUMI, por meio da chamada EuroHPC AI Factory Playground Access.