Pular para o conteúdo

O RL pode fazer um modelo de 4B competir com um de 27B?

Ver no idioma original →

Autoria: Prompt Engineering · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Can RL Make a 4B Model Compete with 27B? · Canal: Prompt Engineering · 16:06 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Modelos de IA, Modelos locais e open source

O vídeo apresenta experimentos que usam ambientes de RL open source para melhorar um modelo de 4B em tarefas de análise de dados. Com GRPO e uma seleção de tarefas na fronteira das capacidades do modelo, o treinamento reduziu mais da metade da diferença em relação a um modelo de 27B, sobretudo ensinando o modelo a concluir tarefas e responder ao que foi perguntado. O progresso estagnou quando as tarefas deixaram de fornecer um sinal útil de aprendizado; fine-tuning com exemplos produzidos pelo modelo maior mudou o comportamento, mas pouco os resultados. O autor ressalta que o experimento foi limitado a um único modelo e compartilha o checker, o modelo treinado e as receitas no GitHub.

  • Um ambiente de RL fornece uma tarefa, ferramentas e um checker que atribui uma recompensa à resposta.
  • O modelo aprende aquilo que o checker recompensa; por isso, um checker confiável e rigoroso é essencial para evitar reward hacking.
  • No GRPO usado no experimento, tarefas que o modelo sempre acerta ou sempre erra não oferecem um sinal de aprendizado útil.
  • Selecionar tarefas que o modelo resolve apenas em algumas tentativas levou a uma melhora clara e reduziu mais da metade da diferença para o modelo de 27B.
  • O RL aprimorou habilidades que o modelo já demonstrava ocasionalmente, como concluir tarefas e registrar a resposta no formato pedido.
  • Treinar com mais tarefas não melhorou os resultados quando elas não ofereciam um sinal novo para o modelo.
  • O fine-tuning com exemplos corretos gerados pelo modelo de 27B mudou a abordagem do modelo pequeno, mas teve pouco efeito na pontuação.
  • Aplicar RL após esse fine-tuning produziu o melhor dos modelos pequenos testados, embora ainda não alcançasse o modelo de 27B.
  • O experimento foi limitado a um único modelo; o autor disponibilizará o checker, o modelo treinado e as receitas no GitHub.
Início Capítulo Resumo
00:00 Ambientes de RL e objetivo do experimento O autor apresenta a hipótese de melhorar um modelo de 4B com ambientes de RL e explica o que é um ambiente de tarefas com checker.
03:39 Treinamento, modelo e configuração O vídeo situa o RL no processo de treinamento, explica o GRPO e descreve os modelos, o hardware e a avaliação usados.
07:47 Seleção de tarefas e ganhos com RL Ao treinar com tarefas que o modelo acerta apenas algumas vezes, o autor observa ganhos claros e mudanças na forma de concluir tarefas.
11:23 Limites do RL e fine-tuning com exemplos O treinamento adicional não melhora a pontuação; o autor então usa exemplos corretos do modelo de 27B e aplica RL novamente.
14:32 Conclusões e limitações O autor resume as condições para obter ganhos com RL, ressalta os limites do experimento e anuncia a publicação dos materiais no GitHub.

O modelo aprende aquilo que o checker recompensa, não o que você quis dizer. — 02:35

O modelo só aprende com tarefas que às vezes acerta. — 04:41

A diferença dá uma ideia aproximada do espaço que o RL tem para trabalhar. — 11:55

O RL aprimora aquilo que o modelo já consegue fazer às vezes. — 15:02

  • RL environments (conceito): Ambientes que apresentam tarefas a modelos e permitem avaliar suas respostas por meio de um checker.
  • GRPO (conceito): Método de aprendizado por reforço usado no experimento, que compara tentativas em grupos para reforçar as que têm melhor desempenho.
  • LoRA (conceito): Adaptador pequeno treinado como alternativa a retreinar o modelo inteiro.
  • reward hacking (conceito): Comportamento em que o modelo aprende a explorar falhas ou permissividade do checker em vez de cumprir o objetivo pretendido.
  • distillation (conceito): Técnica em que um modelo menor aprende com exemplos ou transcrições produzidos por um modelo maior.
  • Firecrawl (empresa): Patrocinadora apresentada no vídeo, que oferece acesso a dados estruturados da web e um servidor MCP.
  • Opus 5.5 (modelo): Modelo de fronteira citado como possível gerador de tarefas a partir de dados.
  • Claude (modelo): Modelo mencionado no exemplo de uso do servidor MCP da Firecrawl para pesquisar dados.

00:00 É possível tornar um modelo de 4 bilhões comparável a um modelo de 27 bilhões usando RL? É exatamente isso que vou mostrar neste vídeo. Se você acompanhar os lançamentos recentes de modelos, há uma coisa que aparece repetidamente: ambientes de RL. Segundo relatos, a Anthropic, por exemplo, discutiu gastar mais de um bilhão de dólares com eles em um único ano. E parece que ter ótimos ambientes de RL pode elevar o nível do desempenho dos modelos.

00:31 A boa notícia é que começamos a ver alguns ambientes de RL realmente incríveis em open source. A Xiaomi disponibilizou milhares deles em open source com o Mimo 2.6. E agora até a equipe da Hugging Face lançou ambientes de RL criados especificamente para modelos pequenos. Então, para este vídeo, quis explorar uma pergunta simples: você pode usar esses ambientes abertos no seu próprio hardware para melhorar um modelo pequeno? Para descobrir, fiz uma série de experimentos em dois DGX Spark que

01:02 tenho. E vou explicar todos eles para vocês. A resposta curta é sim, funciona. Um modelo de 4 bilhões claramente melhorou e reduziu em mais da metade a diferença para um modelo cerca de seis vezes maior. Mas o que percebi foi que, em certo momento, ele parou de melhorar. E o motivo provavelmente é a parte mais útil deste vídeo. Antes de mostrar minha configuração e meus experimentos, vamos falar sobre o que exatamente é um ambiente de RL. Uma boa analogia é uma prova de

01:33 treino com gabarito. O modelo recebe uma tarefa, tenta resolvê-la e algo verifica a resposta. Para deixar isso mais concreto, vamos ver um dos que usei, chamado Small Data Environments. Cada tarefa usa um conjunto de dados real do Kaggle, com uma pergunta sobre esses dados e uma resposta que um programa pode verificar. Por exemplo, aqui está uma planilha com vendas de videogames, e a pergunta é: qual distribuidora específica

02:03 tem o maior total de vendas? Nesse caso específico, a resposta é Nintendo. Em cada tarefa, o ambiente fornece ao modelo três coisas diferentes. Primeiro, um sandbox, que é basicamente um computador isolado, no qual o modelo não pode estragar nada. Segundo, uma ferramenta. Neste caso específico, é um terminal. Assim, o modelo pode examinar os arquivos e executar Python. E a terceira coisa é um verificador. O modelo grava a resposta final em um arquivo, e o verificador pode compará-la com o gabarito.

02:35 Se estiver certa, o modelo recebe uma recompensa de um. Se estiver errada, recebe uma recompensa de zero. Essa recompensa é o único feedback que o modelo recebe. Mas o mais importante a ter em mente é que o modelo aprende aquilo que o verificador recompensa, não aquilo que você quis dizer. E isso é muito importante. Se o verificador recompensa a coisa errada, o modelo vai acabar aprendendo a coisa errada com os dados. Então, o verificador que vem com esse conjunto de dados específico é um pouco permissivo. Por exemplo,

03:08 se a resposta certa for 42 e o modelo escrever 42, isso ainda será aceito. Um modelo treinado com um verificador assim pode aprender a encher a resposta de conteúdo desnecessário. É o que chamamos de reward hacking. Então, quando analisei o verificador, precisei escrever um mais rigoroso. Todas as pontuações deste vídeo são baseadas nesse verificador mais rigoroso, e não no verificador permissivo que vem com o conjunto de dados. Certo, agora vamos falar sobre onde o RL

03:39 se encaixa no treinamento de um modelo. Os modelos costumam ser treinados em etapas. Primeiro, há o pré-treinamento, no qual o modelo lê uma enorme quantidade de texto e aprende a prever a próxima palavra. É aí que a maioria dos modelos adquire seu conhecimento do mundo real e sua compreensão da linguagem. Depois vem o fine-tuning. O fine-tuning supervisionado é um bom exemplo: nele, o modelo aprende imitando exemplos de boas respostas. E também deixa de ser um simples previsor da próxima palavra e passa a responder perguntas.

04:11 O RL vem depois disso. Em vez de copiar exemplos do que é uma boa resposta, o modelo pratica. Por exemplo, ele tenta realizar uma tarefa. O verificador informa como ele se saiu, e o modelo se ajusta com base na recompensa que recebe. Então, você não precisa escrever a resposta. Só precisa de uma maneira de verificá-la. Neste experimento, o método de RL que usamos se chama GRPO. Para cada tarefa, o modelo faz oito tentativas.

04:41 As tentativas que se saem melhor do que a média do grupo são reforçadas. Assim, o modelo fica mais propenso a tentá-las de novo. E as que se saem pior são, basicamente, desincentivadas. Agora, há uma parte muito importante nisso tudo: se todas as tentativas estiverem certas ou todas estiverem erradas, nenhuma fica acima da média. Então, essa tarefa não ensina nada ao modelo. E é muito importante lembrar disso. O modelo só aprende com tarefas que às vezes consegue acertar.

05:12 Não com tarefas que sempre acerta ou sempre erra. Já voltaremos a isso. Certo. Vamos falar da configuração propriamente dita e do que aprendi com esses experimentos. Usei dois DGX Spark. Cada um tem 128 GB de memória unificada. O modelo que tentei treinar foi o Qwen 3.5 4B e, em vez de retreinar o modelo inteiro, treinei um complemento pequeno chamado LoRA, que é

05:44 bem mais barato de treinar. Para medir o progresso, reservei uma prova que nunca foi usada no treinamento do modelo. Isso é basicamente um conjunto de validação. Ele também inclui tarefas do conjunto de dados que o modelo ainda não tinha visto. Antes de qualquer treinamento, o modelo de 4 bilhões acertava cerca de metade e errava a outra metade. Agora, neste caso, estamos usando um modelo de 27 bilhões. Ele é da mesma família Qwen, mas esse era o modelo-alvo para nós. E o objetivo era alcançar o mesmo

06:15 desempenho desse modelo de 27 bilhões. Vamos falar do patrocinador de hoje, Firecrawl. Lembrem-se: apenas 87 tarefas da prova usavam conjuntos de dados que o modelo nunca tinha visto no treinamento. Então, como conseguir mais? Você poderia pedir a um modelo de fronteira como Opus 5.5 para criá-las. Mas ele só conhece o que viu antes do corte de dados de treinamento, ou seja, os mesmos conjuntos de dados famosos que todos os modelos já memorizaram. É aí que entra Firecrawl.

06:45 Uma ferramenta geral de busca na web apenas coleta dados da web e pode ser bloqueada por certos sites. Firecrawl dá acesso a dados estruturados e atualizados de mais de 110 milhões de fontes, sem precisar analisar arquivos HTML. É a API de contexto para agents de IA. Por meio do servidor MCP, Claude pôde pesquisar no índice de desenvolvedores do Firecrawl, encontrar no GitHub os dados da Copa do Mundo de 2026 e coletar as 104 partidas,

07:17 incluindo cada gol e o minuto em que aconteceu. Com isso, criou uma nova tarefa: qual equipe marca mais gols a partir dos 80 minutos? Nesse caso, é a Argentina, com 10. A resposta é calculada a partir do arquivo, então o verificador pode avaliá-la. E o torneio terminou depois do corte de dados, então nenhum modelo o memorizou. Se você precisa de dados estruturados e atualizados da web, Firecrawl é a solução. O link estará na descrição. E há um plano gratuito para você começar.

07:47 Agora, vamos ao restante do vídeo. Certo. Como reduzimos a diferença de desempenho? Vou descrever alguns dos meus experimentos. Primeiro, treinei com um conjunto aleatório de tarefas. O modelo aprendeu algo útil. Começou a concluir as tarefas em vez de ficar sem turnos. Mas a pontuação só aumentou um pouco. E seria fácil dizer que foi sorte. Um dos motivos interessantes vinha do GRPO que descrevi antes. Quando

08:18 analisei as tarefas de treinamento, a maioria era composta por tarefas que o modelo ou sempre acertava ou sempre errava. Então, basicamente, a maior parte do tempo de treinamento era gasta sem aprender absolutamente nada. Foi aí que mudei as tarefas com que treinava o modelo. Fiz o modelo tentar cerca de mil tarefas, quatro vezes cada. Depois, mantive apenas aquelas que ele resolvia algumas vezes e descartei as que ele sempre conseguia resolver ou

08:49 nunca conseguiu resolvê-las. A razão é que essas são basicamente as tarefas no limite do que o modelo conseguia fazer. Então, treinei com elas durante a maior parte de um dia. E realmente funcionou. A pontuação subiu claramente, e a diferença para o modelo de 27 bilhões diminuiu em mais da metade. Sempre que você vê um salto como esse, a primeira pergunta deve ser: será que foi só sorte? Então, comparei o modelo treinado com o não treinado, tarefa por tarefa. Havia um subconjunto de tarefas que

09:19 o modelo recém-treinado realmente acertava, mas havia outro conjunto de tarefas que ele errava. Se o treinamento não tivesse feito nada, esses dois subconjuntos deveriam ter mais ou menos o mesmo tamanho. No meu caso, o primeiro subconjunto era bem maior. E a probabilidade de isso acontecer por acaso é muito pequena. Certo. Então, estávamos progredindo, mas eu queria muito entender que mudanças de comportamento tinham vindo do treinamento. Então, vou mostrar alguns testes reais. Basicamente, as mesmas tarefas antes e depois do

09:51 treinamento. Certo. Lembram da pergunta sobre o videogame que descrevi no início? O modelo não treinado faz a análise corretamente e até menciona Nintendo na resposta. Mas, no arquivo de respostas, escreve o número de vendas em vez do nome. Então, recebe nota zero. Já o modelo treinado confere os cinco principais publishers e escreve Nintendo. Eu precisei analisar isso porque queria ter certeza de que não era algo que aconteceu só uma vez. Em perguntas em que

10:22 a resposta é um nome, ele escreve um número isolado com muito menos frequência do que o modelo não treinado. Aqui vai outro exemplo. A pergunta é: qual jogo tem o maior tempo de jogo? O arquivo não tem uma linha de cabeçalho, o que significa que as colunas não têm nomes no arquivo. O modelo não treinado comete um erro atrás do outro. Basicamente, repete o mesmo comando palavra por palavra e acaba ficando sem tentativas antes de escrever a resposta. O modelo treinado identifica as

10:52 colunas, encontra Dota 2 e escreve a resposta em bem menos etapas. Mas não é perfeito. Ele também perdeu uma tarefa que antes acertava. Nesse caso, faz a conta corretamente, mas escreve uma fração, enquanto o gabarito esperava uma porcentagem. Também queria verificar se havia reward hacking, porque o verificador original era bastante permissivo. Mas, nesse caso, não vi nenhum indício de reward hacking, o que foi ótimo. Certo. A principal conclusão foi

11:23 que o modelo já sabia fazer análise de dados, certo? A parte de RL não ensinou isso a ele, mas ensinou-o a terminar o trabalho e responder à pergunta que realmente foi feita. Certo, então o próximo passo óbvio era fazer mais RL. Mais uma vez, selecionei um novo lote de tarefas da mesma forma e treinei de novo, mas, para minha surpresa, isso não melhorou mais o modelo. E esse é o tipo de detalhe sobre o qual falamos. Estamos procurando

11:55 tarefas em que o modelo, quando você o executa várias vezes, às vezes acerta e às vezes erra. Caso contrário, não há sinal algum para ele aprender. Aqui vai um experimento simples que você pode fazer para ver esse limite. Dê ao modelo não treinado quatro tentativas por tarefa, em vez de uma, e conte quantas ele resolve pelo menos uma vez. Isso é mais do que ele resolve em uma tentativa, e a diferença dá uma ideia aproximada do espaço que o RL tem para trabalhar. Meu palpite é que

12:27 o treinamento com as tarefas no limite já tinha aproveitado uma grande parte desse espaço. Certo, então, se o modelo não consegue descobrir novas habilidades praticando, a próxima opção é mostrá-las a ele. Fiz o modelo de 27 bilhões resolver um lote de tarefas de treinamento. Depois, mantive as transcrições em que ele acertou as respostas. Em seguida, fiz fine-tuning do modelo pequeno com elas. Isso é basicamente todo o conceito de destilação. Nesse caso, temos um modelo aluno que

12:57 aprende observando um modelo professor resolver problemas. Certo, quando tentei isso, a pontuação não mudou muito. Permaneceu praticamente igual, mas o interessante é que o modelo começou a trabalhar como um modelo 27B. Aqui está a pergunta: uma forma de redimensionar os dados resulta em menos erros do que outra? O modelo de RL experimenta um modelo de machine learning atrás do outro. O modelo destilado faz uma comparação bem organizada e responde em

13:27 bem menos etapas, exatamente como faria o modelo de 27 bilhões. Mas notei algo muito interessante. O modelo destilado começou a resolver algumas tarefas que o modelo de RL nunca tinha conseguido resolver. Então, o próximo passo óbvio era que essas eram exatamente as tarefas que talvez precisassem de RL. Fiz mais uma rodada de RL por cima dele. Certo, a maioria dos experimentos — ou todos os experimentos que fiz — teve pontuações finais praticamente iguais, mas, no conjunto de dados

13:59 que o modelo nunca tinha visto, esse último modelo é o melhor dos modelos pequenos que testei. E eu diria que foi o primeiro em que os ganhos passaram no teste de sorte. Aqui está uma dessas tarefas. É um banco de dados do Departamento de Agricultura dos EUA. E a pergunta é: qual é a variedade de maçã mais comum? O modelo não treinado e o modelo de RL respondem “Novel”. Essa é a variedade mais comum no arquivo. Mas é uma laranja. O modelo destilado encontra a resposta certa, mas fica sem tentativas enquanto

14:32 confere a resposta. E o modelo final filtra primeiro as maçãs e escreve Red Delicious, que é a mesma resposta do modelo de 27 bilhões e está correta. Certo, então é possível usar ambientes de RL open source em casa para melhorar um modelo pequeno? Eu diria que sim. Você precisa de um verificador em que possa realmente confiar. Depois, precisa de um conjunto de tarefas no limite do que o modelo consegue fazer. E provavelmente de

15:02 um dia ou algo assim de treinamento para ter uma primeira ideia de se está funcionando ou não. Mas a conclusão mais importante é que o RL aprimora aquilo que o modelo já consegue fazer às vezes. Depois que você esgota esse potencial, na minha opinião, as pontuações basicamente param de subir. Certo, então considere tudo isso com cautela, porque este é um experimento muito limitado. No essencial, testei isso em um único modelo. Testei muitos checkpoints ao longo do processo, e o último modelo provavelmente é

15:34 o melhor que consegui. Ainda não é tão bom quanto o modelo de 27 bilhões. Ele chega perto, mas acho que, com mais dados de treinamento e técnicas de RL mais variadas, eu poderia chegar ao nível do modelo de 27 bilhões. Certo. Foi um experimento de RL divertido. Aprendi muito e queria compartilhar com a comunidade. Vou colocar tudo no GitHub, incluindo o verificador e o modelo treinado. Então, se quiser, você pode executar isso na sua própria GPU e ver até onde consegue levá-lo. Todas as receitas estarão no GitHub. Enfim, espero que isto tenha sido

16:06 útil. Obrigado por assistir e, como sempre, até o próximo vídeo.

Transcrição original

[00:00] Can you make a 4-billion model comparable to a 27-billion model using RL? That’s exactly what I’m going to be showing you in this video. If you look at recent model releases, there is one thing that keeps coming up again and again, and that is RL environments. Anthropic, for example, has reportedly discussed spending more than a billion dollars on them in a single year. And it seems like having great RL environments can push the envelope up when it comes to model performance.

[00:31] Now, the good news is we have started seeing some really incredible RL environments in open source. Xiaomi open source thousands of them with Mimo with 2.6. And now, even Hugging Face team has released RL environments that are specifically built for small models. So, for this video, I wanted to explore one simple question. Can you use these open environments on your own hardware to make a small model better? To find out, I ran a series of experiments on two DGX boxes that I

[01:02] have. And I’ll walk you through all of them. Now, the short answer is yes, it works. A 4-billion model clearly got better and closed more than half the gap to a model about six times its size. But what I noticed was that at some point it stopped improving. And the reason why is probably the most useful part of this video. Now, before showing you my setup and my experiments, let’s talk about what exactly an RL environment is. So, a good mental model is a practice

[01:33] exam with an answer key. The model gets a task, it tries to solve it, and something checks the answer. Now, to make this concrete, let’s look at one that I used, which is called small data environments. Every task is a real data set from Kaggle, which has a question about that data, and then an answer that a program can check. So, for example, here is a spreadsheet of video game sales, and the question is which particular publisher

[02:03] has the highest total sales. For this a specific one, the answer is Nintendo. Now, and on each task, the environment gives the model three different things. First, a sandbox, which is basically a locked-down computer where the model cannot break anything. Second, is a tool. In this specific case, it’s a terminal. So, the model can look at the files and run Python. And the third is a checker. The model writes its final answer to a file, and the checker can paste it with the answer key.

[02:35] So, if it’s right, the model gets a reward of one. If it’s wrong, it gets a reward of zero. Now, that reward is the only feedback the model ever gets. But, the most important thing to keep in mind is that the model learns whatever the checker rewards, not what you meant. And this is very important. If the checker is rewarding the wrong thing, your model is going to end up learning the wrong thing from the data. So, the checker that comes with this specific data set is a bit lenient. For example,

[03:08] if the right answer is 42, and the model writes 42, yes, that will still pass. Now, a model trained against a checker like that can learn to pad its answer. And this is what we call reward hacking. So, when I looked at the checker, I actually had to write a stricter checker. And every score in this video is based on this stricter checker, rather than the lenient checker that comes with the data set. Okay, now let’s talk about where does RL

[03:39] fit into training a model. So, models are usually trained in stages. First, there is pre-training, where the model reads a huge amount of text and learns how how predict the next word. This is where most of the models acquire their real-world knowledge and language understanding. Then there is fine-tuning. Supervised fine-tuning is a good example of this where it learns by copying examples of good answers. And it also goes from simple next word predictor to question answer machine.

[04:11] Now, RL comes after that. Instead of copying the model, practices what a good answer looks like. So, for example, it’s going to try a task. The checker tells it how did it do and it basically adjusts itself based on the reward that it’s getting. So, you don’t really have to write out the answer. You just need a way to check the answer. So, for this experiment, the RL method that we used is called GRPO. For every task, the model makes eight attempts.

[04:41] The attempts that did better than the group’s average gets reinforced. So, the model is more likely to attempt those again. And the one that did worse gets basically pushed down. Now, here’s a very important part of this whole thing. If all the attempts are right or all of them are wrong, none of them beats the average. So, that task teaches the model nothing. And this is really important to remember. The model only learns from task it sometimes gets

[05:12] right. Not the task that it always gets right or always gets wrong. We’re going to come back to this in a bit. Okay. Uh let’s talk about the actual setup and what exactly I learned through these experiments. So, I used two DGX uh Spikes. Both of them have 128 GB unified memory. The model that I tried to uh train was quant 3.5 4B and instead of retraining the whole model, I trained a small add-on called LoRA, uh which is

[05:44] a lot cheaper to train. To measure progress, I held back an exam that model never was trained on. So, this is basically a validation set. Now, this is also included task from the data set that it has not seen before. So, before any training, the 4 billion model was getting about half right and half wrong. Now, in this case, we’re using a 27 billion model. Uh this is the same coin family, but this was the target model for us. And the goal was to get to the same

[06:15] performance as this 27 billion model. Let’s talk about today’s sponsor, Firecrawl. Remember, only 87 of the exam tasks used data sets that the model never saw in training. So, how do you get more? You could ask a frontier model like Opus 5.5 to write them. But, it only knows what it saw before its training cut off, which means the same famous data sets every model has already memorized. This is where Firecrawl comes in.

[06:45] A general web search tools only scrapes the web data and can be blocked by certain websites. Firecrawl gives you access to live structured data from 100 and 10 plus million sources without the need for parsing HTML files. It’s the context API for AI agents. Through its MCP server, Claude could search Firecrawl’s developer index, found the 2026 World Cup data on GitHub, and pulled all 104 matches,

[07:17] including every goal with its minutes. From that, it wrote a new task, which team scores the most goals from the 80th minute on. In this case, it’s Argentina with 10. The answer is computed from the file, so Checker can grade it. And the tournament ended after the cut off, so no model has memorized it. If you need live structured data from web, Firecrawl is your answer. Link is going to be in the description. And there’s a free tier for you to get

[07:47] started. Now, let’s talk about the rest of the video. Okay. So, how do we close the gap of the performance? Now, I’m going to describe some of my experiments. So, first I train on a random set of tasks. The model did learn something useful. It started finishing its task instead of running out of turns. But the score only moved by a little bit. And you could easily say that was luck. Now, one of the interesting reason was coming from GRPO that I described before. So, when I

[08:18] looked at the training tasks, most of them were ones that the model always either got right or always got wrong. So, essentially most of the training time was spent on learning absolutely nothing. Now, this is where I actually changed the tasks that I was training the model on. So, I had the model try about a thousand tasks four times each. Then I kept only the ones it solved some of the times and threw away the ones it always either was able to solve them or

[08:49] never was able to solve them. Now, the reason was these are basically the tasks at the edge of what the model could do. So, I trained on those for most of a day. And it actually worked. So, the score went up clearly and it closed more than half the gap to the 27 billion model. Now, whenever you see a jump like this, the first question should be is this just luck? So, I compared the trained model to the untrained one task by task. Now, there was a subset of tasks that

[09:19] the newly trained model actually gets right, but then there are another set of tasks that it gets wrong. So, if the training did nothing, those two subsets should be about the same size. Now, in my case, the first subset was a lot bigger. And the odds of that by chance are really small. Okay. So, we were making progress, but I really wanted to understand what behavioral changes were coming from the training. So, let me show you some real runs. Basically, same tasks before and after

[09:51] training. Okay. So, remember the video game question that I described in the beginning? The untrained model actually does the analysis right, and it even says Nintendo in its reply. But, in the answer file, it writes the sales number instead of the name. So, it gets a score of zero. Now, the trained model double-checks the top five publishers and writes Nintendo. Now, I actually had to look at it because I wanted to make sure it’s not just a one-off. So, on questions where

[10:22] the answer is a name, it writes a bare number a lot less often compared to the untrained model. Now, here’s another one. The question is, which game has the most playing time? Now, the file has no header row, which means the column columns don’t really have names in the file. The untrained model hits one error after another. It basically repeats the same command word for word, and essentially runs out of turns without writing the answer. The trained model figures out

[10:52] columns, finds Dota 2, then writes it down in a lot fewer steps. Now, it’s not perfect. It also lost some task it used to get right. So, in this one, it does the math right, but writes a fraction when the answer key wanted a percentage instead. Now, I also wanted to check for reward hacking because the original checker was pretty lenient. But, in this case, I didn’t really see any indication of reward hacking whatsoever, which was great. Okay. So, the main finding was

[11:23] that the model already knew data analysis, right? So, the RL part didn’t really teach it that, but it actually taught it to finish the job and answer the question that was actually asked. Okay, so the next obvious step was to do more auto, right? Again, I screened a fresh batch of tasks in the same way and trained again, but surprisingly it did not improve uh the model any further. And that’s the kind of detail that we talked about. We are looking for

[11:55] tasks where the model uh if you run it multiple times, sometimes it can get right, sometimes it can get it wrong. Otherwise, there’s no signal for it to learn at all. Now, here’s a simple experiment that you can run yourself to see that ceiling. Give the untrained model four tries per task instead of one and count how many it solves at least once. So, that’s more than it solves in uh one try, and the gap is roughly the room RL has to work with. Now, my guess is that

[12:27] training on the edge tasks had already used up a big part of it. Okay, so if the model cannot discover new skills by practicing, the next option is to show them to it. So, I had the 27 billion solve a batch of training tasks. Then, I kept the transcripts where it got the answers right. And then, fine-tune the small model on those. Now, this is basically the whole concept of distillation. In this case, we have a student model that

[12:57] is learning by watching a teacher model work through problems. Okay, now when I tried this, the score actually did not change much. It remained pretty much the same, but the interesting thing is that the model started working like 27B model. So, here’s the question that asks whether one way of re-scaling the data gives a lower error than another. The auto model tries one machine learning model after another. The distilled model runs one clean comparison and answers in

[13:27] a lot fewer steps, just like the 27 billion model would do. But I noticed something really interesting. The distilled model started solving some tasks the RL model never was able to do. So, the next obvious thing was that these are exactly the tasks that potentially would need RL. So, I ran RL one more time on top of it. Okay, so most of the experiments or all of the experiments that I ran were pretty much the same in terms of the final scores, but on the data set

[13:59] the model had never seen this last model is the best of the small models that I tried. And I would say this was the first one where the gains passes the luck check. Here is one of those tasks. It’s a database from the US Department of Agriculture. And the question is the most common apple variety. Now, the untrained model and the RL model both answers novel. That’s the most common variety in the file. But it’s an orange. The distilled model finds the right answer, but turns out of turns while

[14:32] double-checking. And the final model filters down to apples first and write red delicious, which is the same answer as the 27 billion model, and that is the correct one. Okay, so can you use an open RL environments at home to make small model better? I would say yes. You need a checker you can actually trust. Then you need a set of tasks at the edge of what the model can do. And probably a

[15:02] day or so of training to get a first feel of whether it’s working or not. But the most important takeaway from this is that RL sharpens what the model can already sometimes do. Once you use up that, in my opinion, the scores basically stops moving. Okay, so take all of this with a grain of salt because this is a very limited experiment. Essentially, I tested this on a single model. Now, I tested a lot of checkpoints along the way and the last model is probably

[15:34] the best one that I got. Now, it’s still not as good as the 27 billion model. It gets there, but I think with more training data, more diverse auto techniques, I could potentially get to the 27 billion model. All right. This was a fun auto experiment. I learned a lot and wanted to share this with the community. Now, I’m going to be putting everything on GitHub including the checker, the trained model. So, if you want, you can run this on your own GPU and see how far you can push it. All the recipes are going to be on GitHub. Anyways, I hope you this was

[16:06] helpful. Thanks for watching and as always, I’ll see you in the next one.