Microsoft e Hugging Face publicaram em 22 de outubro de 2026 o código de treinamento do ThinkingBox, uma abordagem para tornar agentes de IA mais confiáveis em tarefas que alteram sistemas reais. Em vez de recompensar o agente por uma resposta que parece correta, o método verifica o estado final do banco de dados e usa esse veredito executável como sinal de reforço. No experimento divulgado, um Qwen3.8-27B ajustado com GRPO elevou sua taxa média de acerto de 51,70% para 60,78% e quase triplicou o número de tarefas concluídas corretamente em todas as 20 tentativas avaliadas: de 38 para 107, entre 507 tarefas.
O ponto central não é transformar uma demonstração em um produto pronto. É atacar um problema recorrente na adoção de agentes: a diferença entre o modelo afirmar que concluiu o trabalho e o sistema de fato ficar no estado esperado. Para equipes brasileiras que avaliam automação em atendimento, operações, backoffice ou fluxos com MCP, essa diferença é mais importante do que uma resposta convincente no chat.
O que o ThinkingBox mede — e por que isso muda a avaliação de agentes
O ThinkingBox-Bench é um benchmark com 507 tarefas em backends simulados de domínios como varejo, seguro automotivo, viagens, neobanco e consultoria. Em cada episódio, o agente recebe ferramentas, interage com um usuário simulado e precisa modificar registros reais daquele ambiente. Ao fim, verificações determinísticas examinam a base de dados e os efeitos produzidos.
Isso evita premiar uma sequência de chamadas de ferramenta que apenas parece razoável. Um agente pode fechar um chamado, emitir um reembolso e escrever um resumo impecável, mas ainda violar uma regra de negócio — por exemplo, ignorar uma aprovação gerencial obrigatória. No método, o resultado só recebe recompensa se o estado terminal, incluindo registros que deveriam permanecer intactos, estiver correto.
Os resultados: mais repetibilidade, não uma vitória em todos os indicadores
O experimento relatado ajustou o Qwen3.8-27B por 50 etapas com Group Relative Policy Optimization (GRPO). O modelo foi avaliado no conjunto de benchmark que, segundo os autores, permaneceu fora do conjunto de treinamento. A métrica pass@1 — proporção média de tentativas bem-sucedidas — subiu de 51,70% para 60,78%. Já a métrica observed 20/20, que conta tarefas aprovadas em todas as 20 execuções, foi de 38 (7,50%) para 107 (21,10%).
| Métrica divulgada | Qwen3.8-27B base | Após RL | Leitura correta |
|---|---|---|---|
| pass@1 | 51,70% | 60,78% | Melhora no sucesso médio por tentativa |
| Tarefas aprovadas em 20/20 execuções | 38 | 107 | Ganho de repetibilidade em tarefas específicas |
| pass@20 | 89,35% | 87,97% | Houve pequena queda na capacidade de resolver ao menos uma vez |
| Custo estimado por tarefa confiável | US$ 24,36 | US$ 8,00 | Índice comparativo dos autores; não é uma fatura de nuvem |
Há uma ressalva essencial: o ganho não foi uniforme. O pass@20, que mede se uma tarefa foi resolvida pelo menos uma vez nas 20 tentativas, caiu de 89,35% para 87,97%. Os autores interpretam o padrão como uma troca possível entre amplitude e consistência: a política fica mais concentrada em trajetórias que dão certo repetidamente, mas pode perder alguns caminhos raros que ocasionalmente resolviam a tarefa.
Como a seleção de tarefas cria um sinal de recompensa útil
A parte mais interessante da proposta é a seleção por dificuldade relativa à política. Os autores argumentam que tarefas sempre resolvidas e tarefas sempre fracassadas geram grupos de recompensa sem contraste para o GRPO: em ambos os casos, todas as amostras recebem essencialmente o mesmo resultado. Para treinar, eles procuram tarefas que o modelo-base resolve em parte das tentativas.
O processo estima uma probabilidade de sucesso a partir de múltiplas execuções da política-base e separa tarefas em faixas. Casos quase sempre falhos e quase sempre bem-sucedidos são descartados; faixas difíceis, intermediárias e frequentemente resolvidas podem entrar no conjunto de treinamento. No experimento de referência, 187 tarefas foram selecionadas para o ajuste completo.
O que foi aberto e qual infraestrutura o experimento exigiu
O repositório microsoft/thinkingbox-training reúne o código de seleção de dados, execução de rollouts, recompensa e integração com Verl. O post também aponta para o benchmark, o repositório de dados e o artigo científico associado. A configuração validada pelos autores é pesada: Linux ou WSL, Python 3.12, GPUs NVIDIA compatíveis e, no caso da execução de referência, três nós com oito H100 cada, totalizando 24 GPUs.
Portanto, o código aberto não significa que qualquer equipe conseguirá reproduzir os números localmente. A própria publicação diz que a lista pública de tarefas é apenas uma amostra e que o conjunto privado de 187 tarefas usado no experimento não foi liberado como corpus de treinamento. Também há componentes de infraestrutura — servidores MCP, ambientes isolados, usuário simulado e juiz configurado em uma minoria de requisitos — que precisam ser projetados com cuidado.
Limitações que não podem ser escondidas
- Não é uma prova de confiabilidade geral. O benchmark cobre tarefas de negócios com estado e ferramentas específicas; não mede todos os riscos de agentes no mundo real.
- O conjunto de avaliação compartilha características com o ambiente de treinamento. Embora os autores afirmem que as 507 tarefas avaliadas não entraram no treinamento, framework, estilo de tarefa, mecanismos de usuário simulado e algumas ferramentas são relacionados. Isso limita o tamanho da inferência de transferência.
- Um veredito executável só é tão bom quanto a especificação. Se uma regra de negócio não estiver codificada no verificador, um agente pode passar no teste e ainda produzir um resultado operacional inadequado.
- Consistência pode ter custo de cobertura. A queda observada no pass@20 mostra que otimizar a repetibilidade não elimina a necessidade de acompanhar métricas diferentes.
Análise do NoticIA: a unidade de qualidade deixa de ser a resposta do modelo
Na análise do NoticIA, o trabalho é relevante porque desloca a discussão de agentes de “qual modelo parece melhor” para “qual estado verificável o sistema deixou depois de agir”. Para empresas, isso sugere uma ordem prática: antes de trocar de modelo ou treinar com reforço, defina invariantes auditáveis. Um fluxo de cobrança pode exigir que não haja estorno sem autorização; um fluxo de suporte pode exigir que o ticket, o pedido e o estoque permaneçam coerentes; um fluxo financeiro pode exigir trilha de aprovação e reconciliação.
Esse desenho também é aplicável sem 24 H100. Uma equipe brasileira pode começar criando testes de estado para um conjunto pequeno de tarefas críticas, executando o agente repetidamente em ambiente isolado e bloqueando a promoção para produção quando invariantes falharem. O treinamento por reforço só passa a ser uma etapa defensável depois que a organização sabe medir o que “correto” significa no seu processo.
O ThinkingBox não resolve governança, autorização, privacidade ou observabilidade. Mas oferece uma direção concreta para uma lacuna que demos de agentes frequentemente ignoram: não basta registrar a cadeia de pensamento aparente ou a lista de ferramentas chamadas; é preciso provar, por meio do estado final, que a ação preservou as regras do negócio.
Fontes e materiais para verificação
- Post técnico conjunto de Microsoft e Hugging Face, publicado em 22 de outubro de 2026
- Repositório oficial do treinamento ThinkingBox
- Dataset ThinkingBox-Bench
- Paper associado: One Success Isn’t Reliability
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
