Microsoft e Hugging Face treinam o Qwen3.8-27B com avaliações do banco de dados: de 38 para 107 tarefas

A equipe da Microsoft, junto com a Hugging Face, publicou o ThinkingBox-Training, continuação do benchmark que flagra agentes que reportam sucesso mesmo quando gravam dados errados no banco. A ideia é simples: se a verificação do estado final do banco retorna 1 ou 0, ela já é uma função de recompensa pronta. Após 50 passos de GRPO, o Qwen3.8-27B elevou o sucesso médio (pass@1) de 51,70% para 60,78%, e o número de tarefas resolvidas em todas as vinte tentativas subiu de 38 para 107, ou seja, de 7,5% para 21,1% das 507 tarefas do ThinkingBox-Bench.

Recompensa vinda do estado do banco, não do texto da resposta

Cada tarefa do ThinkingBox sobe um backend de verdade, entrega ao agente um conjunto de ferramentas MCP e um usuário simulado com contexto fechado. No fim, verificações executáveis conferem quais registros estão no banco. A sequência de chamadas não é avaliada, então o modelo pode encontrar um caminho que não existe no gabarito de referência. A maior parte das recompensas é determinística, e uma pequena fatia de rubricas mais estreitas fica a cargo do GPT-5 Chat como juiz.

Um exemplo claro é a reserva corporativa de hotel. O funcionário precisa de um downgrade de quarto, mas a política exige aprovação do gerente. O modelo base alterava a reserva e emitia reembolsos sem aprovação em 15 de 20 tentativas. Depois do RL, em todas as 20 tentativas a reserva e o estado do pagamento permaneceram intactos, e todos os registros esperados coincidiram em 19.

Por que a seleção de tarefas importa mais que o otimizador

O GRPO tem uma limitação aritmética. Se todos os 8 rollouts falham ([0,0,0,0,0,0,0,0]) ou todos acertam, a centralização dentro do grupo zera a vantagem, e não há gradiente. São necessários grupos mistos, como [0,0,0,1,1,1,1,1]. Para um agente com estado, esses grupos vazios saem caros: cada rollout exige um backend isolado, uma sessão MCP ativa e um modelo separado para o papel do usuário.

Os autores introduziram a policy-relative difficulty offline. A probabilidade de sucesso de cada tarefa candidata é estimada uma única vez na política base, e o pool é então fixado para toda a execução. Eles deliberadamente não refizeram a sondagem de dificuldade durante o treinamento. Nenhuma tarefa do ThinkingBox-Bench entrou no treinamento. Os domínios, bancos, políticas e a maioria das ferramentas do teste são novos, embora a estrutura geral, o simulador de usuário e o estilo das tarefas sejam os mesmos, o que limita a força das conclusões sobre transferência.

Configuração da execução de referência: RL com todos os parâmetros em 187 tarefas, GRPO token-mean, 18 grupos de 8 rollouts, ou seja, 144 episódios por passo, em 24 H100. O treinamento é síncrono, com offload de parâmetros e do otimizador, AdamW, lr 1e-6 e weight decay zero. Grupos com variância zero eram substituídos pelo esquema do DAPO. Erros de sistema, como timeout do backend, não eram contados como falha do agente; o grupo era regenerado. O código que interpreta as saídas do Qwen é compartilhado entre treinamento e avaliação (trainer/core/tb_interpret.py); caso contrário, a recompensa mediria outro agente.

Tabela: sucesso médio versus repetibilidade

Pass@1 em todas as 507 tarefas e número de tarefas com 20/20:

• Claude Opus 5.5 — 67,16%, 241 tarefas (47,53%) • Claude Opus 5 — 66,50%, 241 (47,53%) • GPT-5.4 — 65,36%, 128 (25,25%) • GPT-5.6 Sol — 61,91%, 82 (16,17%) • Qwen3.8-27B após RL — 60,78%, 107 (21,10%) • Claude Sonnet 4.6 — 59,19%, 102 (20,12%) • GPT-6 Astra — 58,31%, 231 (45,56%) • Kimi-K3 — 57,37%, 68 (13,41%) • Qwen3.8-27B base — 51,70%, 38 (7,50%)

O GPT-5.6 Sol tem pass@1 maior, mas resolve de forma estável 25 tarefas a menos. O Opus 5.5 superou o Opus 5 na média por 0,66 p.p., mas em confiabilidade os dois empatam. O pass@1 e o 20/20 cresceram nos cinco domínios, e o maior ganho em 20/20 foi no varejo (+24,5 p.p.). O pass@20 caiu de 453 para 446 tarefas: subiu em neobanco e consultoria, e caiu em varejo, viagens e seguro auto (nesse último, −7,0 p.p.). Os autores descrevem isso como sharpening: a distribuição se desloca para trajetórias que funcionam sempre, e os caminhos raros são abandonados.

A economia da tarefa confiável

O custo da campanha de 507×20 caiu de $925,80 para $855,58 (−7,6%), e o preço de uma tentativa bem-sucedida, de $0,177 para $0,139 (−21,4%). A métrica de "custo por tarefa resolvida de forma confiável" (custo da campanha dividido pelo número de tarefas com 20/20) diminuiu de $24,36 para $8,00 (−67,2%). Para comparação: GPT-5.4 — $6,80, GPT-6 Astra — $7,45, Claude Opus 5.5 — $7,80. É um índice comparativo de serviço, não uma fatura de nuvem. Ele inclui a inferência, mas não considera o treinamento nem a sondagem de tarefas, e o tamanho do modelo no deploy continua o mesmo.

Para equipes que constroem agentes sobre bancos de produção, a conclusão é prática. Se você tem um verificador de estado executável, ele serve tanto como métrica quanto como recompensa. Comece pela seleção de tarefas: as que o modelo sempre resolve ou nunca resolve queimam horas de GPU e backends à toa. Avalie por 20/20, e não por pass@1. Se a cobertura de cenários raros é importante, leve o custo em conta: a repetibilidade foi paga com uma parte do pass@20.