GRPO e RL sobre recompensas verificáveis

01 · Conceito

Conceito

Pergunte a um reward model se um patch corrige um bug e você recebe um julgamento aprendido. Rode a suíte de testes do repositório contra o patch e você recebe um resultado reproduzível de aprovação ou falha sob aquela suíte. Essa diferença — uma estimativa aprendida contra uma observação executável com fronteira explícita — é o assunto inteiro desta lição, e é por isso que as afirmações publicadas mais fortes sobre programação e matemática hoje vêm de sistemas treinados contra verificadores, não contra jurados. Passar na suíte é evidência mais forte que uma opinião, mas não prova que o patch esteja correto além dos comportamentos cobertos pelos testes.

Recompensas verificáveis trocam “isto soa bem?” por uma pergunta mais estreita cuja resposta se repete. Uma expressão matemática pode ser normalizada e comparada com um resultado conhecido. Código pode rodar contra testes num sandbox. Uma prova formal pode ser conferida por máquina. Um jogo tem regras e placar. O aprendizado por reforço se encaixa nesse cenário naturalmente, porque o modelo pode amostrar muitas soluções candidatas e ser informado de quais funcionaram sem que nenhum humano escreva o caminho de raciocínio desejado. Uma solução correta ganha recompensa mesmo quando toma uma rota que nenhuma demonstração continha, o que dá à policy espaço para descobrir estratégias em vez de meramente imitar uma.

A Group Relative Policy Optimization (GRPO), vinda do trabalho DeepSeekMath de 2024, amostra um grupo de saídas para o mesmo prompt. Sejam suas recompensas $R_1,\ldots,R_G$. A vantagem relativa ao grupo padroniza cada amostra contra seus pares:

Ponha números nisso. Amostre um grupo de oito tentativas numa tarefa de correção de bug e rode cada uma pela suíte de testes, dando recompensa 1 para duas tentativas e 0 para as outras seis. A média é 0,25. O desvio padrão populacional é $\sqrt{0.1875}\approx 0.433$. Então cada tentativa bem-sucedida recebe vantagem $(1-0.25)/0.433 \approx +1.73$, e cada falha recebe $(0-0.25)/0.433 \approx -0.58$. Duas amostras são empurradas para cima com força, seis são empurradas para baixo suavemente, e nenhum modelo de valor aprendido foi consultado em lugar nenhum — a própria média do grupo era a linha de base. Repare também que as vantagens caem automaticamente numa escala sensata, independentemente de as recompensas desta tarefa serem 0 e 1 ou 0 e 100, e é isso que torna treináveis os batches com dificuldade mista.

Agora a falha que decorre da mesma fórmula. Suponha que a tarefa seja difícil e as oito tentativas falhem: toda recompensa é 0, a média é 0, o desvio padrão é 0, e toda vantagem é 0. O grupo custou oito gerações completas e não produziu gradiente algum. Inverta — uma tarefa tão fácil que as oito acertam — e você obtém o mesmo nada.

É aqui que o desvio clássico acontece. Ao ver o treino estagnar, um time empurra problemas mais difíceis para a mistura, com o raciocínio de que o modelo deve ser desafiado. O throughput desaba, porque uma fração crescente do orçamento de computação é gasta em grupos que falham inteiros e não contribuem com nada. O movimento correto é o oposto da intuição: você quer problemas em que a policy acerte às vezes, porque o contraste dentro do grupo é todo o sinal de aprendizado. Cure um currículo de dificuldade em torno da taxa de sucesso atual, acompanhe a fração de grupos com variância não nula como métrica de treino de primeira classe, e aumente a dificuldade apenas na medida em que essa fração se mantiver saudável. Tamanho do grupo, temperature de sampling e seleção de prompts são todos alavancas sobre a mesma quantidade.

O retorno de acertar isso é a classe de resultados de programação agêntica que vem sendo publicada. O model card do Qwen3.8-27B informa SWE-bench Pro 61,7, ao lado de Terminal Bench 2.1 em 73,0 e DeepSWE 1.1 em 42,2. Cada um desses números é informado pelo fabricante e aguarda reprodução independente — uma ressalva que vale enunciar com clareza em vez de enterrar, porque benchmarks agênticos são incomumente sensíveis a configuração de harness, política de retentativa e scaffolding, e porque nenhum relatório técnico acompanha este modelo para explicar como os números foram produzidos. Repare também que a distância entre 61,7 e 42,2 em dois benchmarks de programação é grande demais para tratar qualquer escore isolado como “a capacidade de programação do modelo”. O que o model card de fato estabelece é o formato da afirmação: esses são escores de desfecho vindos de verificadores executáveis, não escores de preferência vindos de um jurado, e esse é um tipo de evidência materialmente mais forte que uma taxa de vitória contra a prosa de outro modelo.

Verificabilidade não é o mesmo que solução correta, porém. Um verificador de resposta exata aceita palpites de sorte e raciocínio construído sobre afirmações intermediárias inválidas. Testes unitários públicos podem ser chumbados no código. Um agente de código vai explorar acesso a sistema de arquivos, temporização ou rede se o sandbox permitir. Um verificador de prova valida sintaxe e regras de inferência, nunca se o teorema é o que o usuário queria. O projeto da recompensa precisa declarar onde fica a fronteira real, e então defendê-la.

Recompensas normalmente são compostas: correção, validade de formato, restrições de uso de ferramentas, às vezes um escore de estilo aprendido. Seus pesos criam incentivos, e os incentivos raramente são o que você pretendia. Uma recompensa de formatação pode afogar um sinal esparso de correção. Uma penalidade de comprimento pode suprimir o raciocínio que a tarefa exigia. Um jurado aprendido dobrado na mistura reintroduz todos os perigos da lição 6.4. Registre cada componente separadamente, sempre, para que um total em alta nunca consiga esconder uma taxa primária de sucesso em queda.

Reward overfitting é o outro risco durável. Templates estreitos de prompt e verificadores estreitos ensinam estratégias superficiais que evaporam em distribuições novas. Separe geradores de problemas em vez de problemas, mute os testes, inclua casos adversariais e avalie respostas finais e raciocínio de forma independente. Contaminação entre problemas de treino e conjuntos de avaliação é especialmente corrosiva aqui, porque uma resposta memorizada parece exatamente uma melhoria de raciocínio.

O GRPO é um membro de uma família mais ampla, e o acrônimo não deve obscurecer o princípio: amostre um grupo, estime quais membros se saíram relativamente bem, atualize de forma conservadora. Ele é convincente onde quer que um verificador de alta precisão possa fornecer feedback em escala, e inadequado onde quer que o desfecho desejado seja plural, carregado de valores ou resistente a um teste programático robusto. O modelo durável é um torneio com um árbitro auditado — o grupo cria competição local, o verificador a pontua, a otimização aumenta a probabilidade dos vencedores — e o aprendizado só é tão bom quanto a compreensão do árbitro sobre o que os usuários realmente valorizam.