Técnica de RL concentra esforço em problemas difíceis sem abandonar os fáceis

{ "resumo": "## O efeito Matthew no RL para LLMs\n\nMichael Noukhovitch apresenta, em post sobre seu novo artigo, um problema recorrente no pós-treinamento de LLMs com RL: a melhora medida por benchmarks como o AIME 2025 se concentra quase inteiramente nos problemas fáceis. Ao dividir 30 questões do AIME em três níveis de dificuldade (definidos pelo desempenho inicial do modelo, com pass@32=0 como "difíceis"), ele mostra que os ganhos do treino com RL vêm principalmente de problemas já razoavelmente bem resolvidos, enquanto os mais difíceis mal melhoram. Ele nomeia esse fenômeno de Matthew Effect - "os ricos ficam mais ricos" - e demonstra que ele também aparece em RL de código e agentic, usando modelos e logs de Deepcoder e DeepSWE.\n\n## Não é só o sinal perdido\n\nA explicação intuitiva seria o signal loss do GRPO: se nenhuma das k amostras acerta, não há gradiente. Mas os experimentos mostram algo contraintuitivo: treinar Qwen 2.5 0.5B Instruct com GRPO no GSM8k platinum revela que k menor (k=4) resolve mais problemas difíceis do que k=32, com mesmo orçamento de batch. O motivo é que k grande aumenta tanto a chance de achar soluções raras corretas para problemas difíceis quanto de achar respostas raras incorretas para problemas fáceis - desperdiçando computo filtrando o que já está dominado. Os autores chamam isso de problema de signal efficiency: o RL gasta computo demais em problemas fáceis. Em configuração assíncrona, o computo poupado é realocado para problemas mais difíceis.\n\n## Never Give Up\n\nA solução proposta, Never Give Up (NGU), adapta o sampling assíncrono: começa com k pequeno; se o problema for resolvido, treina; se estiver totalmente resolvido, filtra; se todas as amostras estiverem erradas, com probabilidade p o prompt volta ao gerador para mais k completions, acumulando todas para treinar quando resolver. O número esperado de amostras segue uma distribuição geométrica (k/(1-p)). O método é implicitamente adaptativo - diferente de curriculum learning, que pré-define dificuldade, o NGU se ajusta online à medida que a dificuldade relativa muda ao longo do treino. No GSM8k, NGU com k=4 e p=0.9 supera todas as configurações padrão de GRPO, capturando o melhor dos dois mundos: k grande no início (para achar soluções raras em problemas difíceis) e k pequeno no fim (para filtrar fáceis rápido).\n\n## Truques para lidar com staleness\n\nMúltiplas rodadas de NGU geram completions obsoletos (stale), que são prejudiciais no RL para LLMs. O artigo filtra completions acima de um limiar de idade (T=4) e propõe usar todas as amostras, mesmo as filtradas, no baseline do GRPO, com reescalonamento das vantagens para manter o reward total em zero. Esse truque pode ser útil em geral para RL assíncrono com filtragem de amostras off-policy.\n\n## Escalando para matemática e código\n\nEm escala maior, treinando Qwen 3 4B base no DeepScaler (~120 horas de H100), NGU melhora sobre um baseline GRPO forte com k=16, especialmente nos subconjuntos mais difíceis do AIME 2025 e BRUMO 2025, sem degradar os fáceis.\n\nEm código, o cenário é diferente: cada problema tem múltiplos testes de dificuldades variadas, e resolver o problema exige passar em todos. No benchmark Manufactoria, o GRPO padrão estagna: testes fáceis ficam quase totalmente resolvidos e o sinal oscila em testes médios. O NGU só aceita novas rodadas se passarem em mais testes que antes, empurrando o modelo a resolver progressivamente mais testes até completar o problema.\n\n## Não é plasticidade\n\nO efeito Matthew se assemelha ao primacy bias do deep RL, atribuído a problemas de plasticidade. Mas o artigo mostra que não: partindo de um checkpoint estagnado por milhares de steps, tanto trocar o reward para exigir todos os testes quanto usar NGU com reward parcial recuperam o desempenho - LLMs conseguem se recuperar de amostras iniciais ruins.\n\n## Limitações e conclusão\n\nNGU depende de realocar computo filtrando problemas fáceis; se a distribuição já for majoritariamente difícil, o método deve ter pouco efeito. O processo de amostrar, esperar e reamostrar também produz amostras mais off-policy do que necessário, com sinal de aprendizado pior e treino mais lento - embora NGU deva funcionar se já houver um k adequado para a distribuição.\n\nA conclusão dupla: métricas escalares simples podem esconder o que os evals realmente medem, e vale inspecionar evals por dificuldade; e o NGU mostra que melhor alocar computo - gastando menos nos fáceis - traz ganhos substanciais em tarefas difíceis. Trabalhos futuros devem explorar ambientes agentic multi-step e entender como o RL muda a distribuição do modelo.", "hook": "Curvas de eval do AIME que sobem escondem um detalhe: no RL para LLMs, quase todo o ganho vem dos problemas fáceis, enquanto os difíceis mal saem do lugar. O artigo de Michael Noukhovitch mostra que aumentar o número de amostras por prompt (k) até piora o resultado - e propõe o Never Give Up, um esquema de amostragem que retenta problemas não resolvidos e alcança ganhos no matemática em escala e no RL de código, onde o GRPO padrão estagna.", "entities": ["Michael Noukhovitch", "Olmo 3.1", "Qwen", "GRPO", "DeepScaler", "Manufactoria", "Ai2"], "themes": ["pesquisa-e-benchmarks"], "story_key": "matthew-effect-rl-llms-never-give-up", "reasoning": { "story_key": "Tese central do artigo: o efeito Matthew no RL de LLMs e a solução Never Give Up para realocar computo aos problemas difíceis.", "themes": { "pesquisa-e-benchmarks": "O fato é entender como o RL treina modelos (alocação de sinal, evals por dificuldade), não lançar modelo." }, "entities": { "Michael Noukhovitch": "Autor e proponente do método.", "Olmo 3.1": "Modelo usado nos experimentos de RL matemático que revelam o efeito.", "Qwen": "Modelos (Qwen 2.5 0.5B e Qwen 3 4B) usados nos experimentos de GSM8k e DeepScaler.", "GRPO": "Algoritmo de RL analisado e sobre o qual NGU é aplicado.", "DeepScaler": "Setup de matemática em escala usados para validar NGU.", "Manufactoria": "Benchmark de código onde o GRPO estagna e NGU resolve.", "Ai2": "Forneceu computo para o trabalho." }, "excluded": { "Deepcoder/DeepSWE": "Menções secundárias como fontes de logs.", "GSM8k/AIME/BRUMO": "Benchmarks de avaliação, não sujeitos do fato." } } }