Multi-Harness RL: O App Vale Mais Que o Modelo

Multi-harness RL é o método da Hugging Face que transforma apps de código fechados em ambientes de aprendizado por reforço. Com um proxy que captura tokens e probabilidades, um modelo de 2,6B passou de 42,2% para 54,2% de acerto médio nos quatro apps testados.

O que é multi-harness RL e por que o app muda a nota do modelo

Multi-harness RL é a pesquisa da Hugging Face que transforma apps de codificação agentes em ambientes de aprendizado por reforço sem alterar o código deles. O modelo avaliado é o LFM2.5, da Liquid AI, com 2,6 bilhões de parâmetros; o Claude Code, ferramenta de codificação agêntica da Anthropic apenas o aplicativo em que ele rodou.

A motivação vem de um número simples. O mesmo modelo resolveu 62,1% das tarefas dentro do Mini-SWE-Agent e 33,2% dentro do Claude Code. Nada mudou além do app. Se você escolhe um modelo por um leaderboard de agentes, o aplicativo ao redor faz parte daquele placar.

O CEO da Hugging Face, Clement Delangue, descreveu o trabalho: a equipe transformou Claude Code, Codex da OpenAI e OpenCode em ambientes de RL, sem tocar nos apps nem no código de treinamento. As tarefas vêm de problemas de análise de dados: 1.000 para treino e 250 reservadas para teste.

Como o capture proxy transforma um app fechado em ambiente de RL

O capture proxy é um servidor que finge ser a API do modelo. O app envia as requisições para ele como se fosse o serviço normal de inferência, e o proxy repassa tudo ao motor de inferência real enquanto grava cada chamada. Pense num tradutor que também anota a conversa inteira num caderno.

O fluxo tem cinco passos descritos pelos próprios autores. Primeiro, uma requisição POST ao endpoint de sessões cria um ID de captura; o app usa esse ID onde colocaria a chave de API, então cada chamada carrega a sessão a que pertence. Segundo, o proxy identifica o "dialeto" da requisição entre quatro formatos: chat completions da OpenAI, responses da OpenAI, messages da Anthropic Gemini.

Terceiro, o proxy converte tudo para o formato chat completions e envia ao motor de inferência que serve o modelo. Quatro dialetos viram um, e o modelo nunca precisa saber qual app chamou. Quarto, o pedido mais importante: o proxy exige do motor os IDs de token do prompt, os IDs amostrados e o log de probabilidade de cada token amostrado. Ele também desliga top-p e top-k, para o modelo amostrar da distribuição completa.

Quinto, o proxy espera a resposta completa e a devolve ao app no dialeto original, inclusive em stream quando solicitado. O código do app permanece intocado do começo ao fim.

Por que gravar texto não basta: o problema dos tokens exatos

Re-tokenizar o texto salvo quebra o gradiente de política. Sequências diferentes de tokens podem produzir o mesmo texto, então ao tokenizar de novo você pode obter IDs diferentes dos que o modelo realmente escolheu. O treinador passaria a aprender sobre tokens que o modelo nunca amostrou.

As probabilidades sofrem do mesmo problema. Para cada token, o treinador compara duas probabilidades: a do momento da amostragem e a sob os pesos atuais. Se a primeira for recalculada depois, ela usa o peso atualizado, e a comparação fica errada.

Por isso o proxy anota IDs exatos e probabilidades durante a geração, não um caderno de palavras. Sem essa captura, o método não existe — é o ponto técnico central do multi-harness RL.

Reconstrução de trajetórias: como multi-turn vira sequência de treino

Um rollout é uma tentativa completa de uma tarefa e contém muitas chamadas ao modelo. O proxy liga essas chamadas num grafo causal: cada chamada aponta para a anterior cujo prompt mais completão é o maior prefixo exato de tokens do próprio prompt dela.

Retentativas viram irmãs da chamada que repetem. Sub-agentes, que usam outro system prompt, iniciam uma nova raiz. Compaction de contexto, quando o app encurta o histórico, também abre raiz nova. Cada caminho de raiz a folha vira uma sequência de treinamento.

A máscara de loss separa o que ensina do que não ensina. Tokens de contexto recebem máscara zero; tokens amostrados pelo modelo recebem um. Como o Claude Code reescreve o histórico, um único rollout lá rende cerca de oito sequências de treino. É por isso que o treino em quatro apps processou 451 milhões de tokens contra 162 milhões do treino só no OpenCode.

Resultados: o ganho de treinar em quatro apps ao mesmo tempo

A configuração usa Async GRPO na TRL, a biblioteca de treinamento da Hugging Face, com duas H100 por execução: uma treina, a outra serve o modelo com vLLM. Cada rollout roda num sandbox isolado da E2B, então uma tentativa não contamina outra. O treino só no OpenCode levou 32 horas; o de quatro apps, 46 horas.

Treinar só no OpenCode elevou o OpenCode de 34% para cerca de 58%, mas quase todo o ganho ficou lá: o Claude Code foi a 42% e o Codex a 43%. O treino em quatro apps distribuiu o resultado de forma mais uniforme, como mostra a tabela.

App	Modelo base	Treino só OpenCode	Treino em 4 apps
Mini-SWE-Agent	62,1%	—	~62%
OpenCode	33,6%	~58%	50%
Claude Code	33,2%	42%	49%
Codex	40%	43%	54%

O treino em quatro apps também custou algo: no OpenCode, perdeu oito pontos em relação ao treino exclusivo naquele app, e processou muito mais dados, então a comparação não é simétrica. O Mini-SWE-Agent não ganhou nada, porque já começava perto do teto. O pass@1 médio nos quatro apps foi de 42,2% no modelo base para 52,3% com treino só no OpenCode e 54,2% com quatro apps. Os autores consideram ruído diferenças dentro de cerca de dois pontos, então os dois últimos números empatam na prática.

RL contra SFT: o modelo de 2,6B superou o professor de 27B

O treinador usa GRPO, o group relative policy optimization do artigo DeepSeekMath. Para cada tarefa, ele amostra um grupo de oito rollouts e compara as pontuações dentro do grupo. A recompensa é 1 por resposta correta, mais um bônus de até 0,1 por usar menos chamadas de ferramenta; resposta errada nunca ganha bônus.

Esse bônus pequeno importa mais do que parece. Em 22,6% dos grupos do treino em quatro apps, todos os rollouts pontuáveis estavam corretos e só a contagem de ferramentas diferia. Sem o bônus, entre 35% e 58% dos passos de treino não teriam sinal de aprendizado nenhum.

Na comparação com fine-tuning supervisionado, a equipe coletou 3.189 rollouts bem-sucedidos do Qwen3 27B em 888 tarefas e quatro apps. O SFT alcançou 47,5% no OpenCode e 43,1% em quatro apps; o RL em quatro apps chegou a 54,6% no passo 700. O RL venceu, mas os autores alertam que os métodos diferem em objetivo, dados, pool de tarefas e computo — são observações, não um ranking definitivo. Curiosamente, o SFT em quatro apps derrubou o Mini-SWE-Agent de 62,1% para 45,2%, sem explicação dos autores.

O modelo treinado com RL em quatro apps usou 31% menos chamadas de ferramenta, medidas nas tarefas que base e modelo treinado resolveram. Mas o bônus de recompensa incentivou esse comportamento, e o SFT nos dados do professor cortou 24,2% sem bônus algum. Menos chamadas não é exclusividade do RL.

Limitações: uma execução, um seed e nenhuma causa isolada

Cada configuração rodou uma única vez, com uma única seed aleatória. Todos os experimentos usam modelos pequenos, entre 2 e 2,6 bilhões de parâmetros. Duas execuções anteriores com Qwen3.5 2B treinadas só por correção picaram em 37% e 39,5% e depois caíram para cerca de 26%, mostrando que um checkpoint escolhido no pico pode inflar o resultado.

Sobre por que o Claude Code pontua tão baixo com os mesmos pesos, o artigo cita a análise do Quai Cat, que aponta overfitting ao formato, ao layout de contexto e ao fluxo de controle de um app. Mas o próprio trabalho não roda nenhum teste que isole a causa: tamanho de prompt, reescrita de histórico e nomes de ferramentas continuam sendo hipóteses.

O método exige pesos abertos servidos por você, porque o proxy fica na frente do seu próprio motor de inferência. Ele não consegue interceptar modelos hospedados via API. Há um precedente: o artigo Polar da NVIDIA, de 22 de maio de 2025, já fazia proxy de chamadas de apps imutáveis e reportou ganho de 22,6 pontos para o Qwen3.5 4B no SWE-bench Verified com o Codex. Os conversores do proxy da Hugging Face são adaptados do gateway do Polar; a novidade é o empacotamento aberto multi-app.

Um estudo separado reforça o padrão. Zhang e colegas, em artigo submetido em 7 de maio de 2025, testaram o GLM 5.1 em 100 tarefas do SWE-bench Verified e encontraram uma oscilação de 13 pontos entre três configurações de app, enquanto três modelos variaram apenas 2,5 a 5 pontos dentro de cada app. Os próprios autores dizem que a razão de 7,8 vezes entre variância de app e de modelo não é universal. É outro estudo, com outros modelos; apoia o padrão, mas não o prova aqui.

Perguntas frequentes sobre multi-harness RL

• O Claude participou do teste da Hugging Face? Não. O modelo avaliado é o LFM2.5 da Liquid AI, com 2,6 bilhões de parâmetros. O Claude Code foi apenas o aplicativo em que o modelo rodou durante treino e avaliação.

• O multi-harness RL funciona com modelos de API hospedados? Não. O proxy precisa capturar IDs de token e log de probabilidades na geração, o que exige servir você mesmo os pesos com um motor de inferência próprio. Modelos fechados via API ficam fora do alcance do método.

• Treinar em quatro apps é sempre melhor que treinar em um? Não. O treino em quatro apps elevou o Claude Code de 33% para 49% e o Codex de 40% para 54%, mas custou oito pontos no OpenCode em relação ao treino exclusivo naquele app. A escolha depende de onde o modelo vai rodar.

• Por que o mesmo modelo pontua 33% em um app e 62% em outro? A hipótese citada é overfitting ao formato, ao layout de contexto e ao fluxo de controle de cada app. O artigo da Hugging Face não roda experimento que isole a causa, então o mecanismo exato permanece em aberto.

• Quanto ganhou o modelo no total? O pass@1 médio nos quatro apps subiu de 42,2% no modelo base para 54,2% após treino em quatro apps, com o Claude Code ganhando cerca de 16 pontos individuais.

Source video