Microsoft lança ThinkingBox e melhora IA em 50 passos de treino
Microsoft apresenta o ThinkingBox, ferramenta que transforma o estado final de bancos de dados em função de recompensa para treinar agentes de IA. Modelo Qwen3.8-27B elevou a taxa média de sucesso de 51,70% para 60,78% e triplicou a consistência total em tarefas repetidas.

Inteligência Artificial
Nova ferramenta da Microsoft aprimora o treinamento de agentes de IA com avanços significativos em desempenho e consistência.
Leia também: Rivian compra startup 3D para acelerar self driving vs Tesla FSD
A Microsoft apresentou o ThinkingBox, uma ferramenta que avalia e treina agentes de inteligência artificial a partir do estado final de bancos de dados reais e já mostra ganhos concretos de confiabilidade no modelo Qwen3.8-27B, que passou a resolver tarefas de manipulação de dados com mais consistência após apenas 50 passos de treinamento.
Ferramenta vigia o banco de dados, não só a resposta do agente
O ThinkingBox foi criado para lidar com um problema recorrente em agentes de IA usados em sistemas de produção: modelos que declaram ter concluído uma tarefa, mas deixam o banco de dados em um estado errado ou inconsistente. “The Agent Said It Was Done. The Database Disagreed.”, resumiu a equipe da Microsoft em texto técnico sobre o projeto.
No benchmark ThinkingBox-Bench, cada uma das 507 tarefas sobe um backend real, oferece ao agente ferramentas via MCP e, ao final, roda checagens executáveis sobre o estado terminal do banco. Essas checagens retornam 1 ou 0, aprovando ou reprovando o resultado com base nos registros salvos — não no caminho que o agente seguiu para chegar até ali.
O conceito inverte a lógica usual de avaliação de agentes. Em vez de conferir se o modelo chamou as APIs certas ou seguiu um roteiro pré-definido, o sistema olha só para o que ficou gravado. Isso incentiva o agente a encontrar soluções novas, desde que corretas, e facilita a automatização da avaliação em larga escala.
Função de recompensa nasce do estado final do banco
Ao explorar o benchmark, os desenvolvedores perceberam que essa checagem binária do estado final podia ir além de um simples “corretor de provas” e virar função de recompensa para treinamento por reforço. Na prática, o mesmo sinal executável que avalia tarefas no ThinkingBox-Bench passou a ser usado para treinar agentes em tarefas externas ao conjunto de teste.
Para isso, a equipe montou uma pool de treinamento offline com tarefas no formato ThinkingBox, mas fora do benchmark. O desafio foi escolher tarefas que não fossem nem triviais nem impossíveis para o modelo base. “Difficulty is policy-relative: a task is hard for the current model only until that model learns it.”, escreveram os autores, destacando que a dificuldade depende da política atual do modelo.
Essa “dificuldade relativa offline” foi estimada rodando o modelo base em cada tarefa uma vez, calculando a probabilidade de sucesso e fixando, a partir disso, o conjunto de práticas usado ao longo de todo o treinamento.
Como o Qwen3.8-27B foi treinado com o ThinkingBox
Com a pool selecionada, o modelo Qwen3.8-27B foi fine-tunado com o algoritmo de reforço GRPO em 50 passos. Em cada tarefa, o agente interagia com o backend e recebia como recompensa exatamente o veredito executável do estado final do banco: 1 se o resultado estivesse correto, 0 se algo saísse errado.
Terminada a etapa de treinamento, o modelo ajustado foi avaliado no benchmark ThinkingBox-Bench, que reúne 507 tarefas nunca usadas no treino, com domínios, bancos de dados e ferramentas MCP distintos. Cada tarefa foi executada 20 vezes, o que permitiu medir não só a taxa média de sucesso, mas também a consistência ao longo das repetições.
Três métricas foram usadas: pass@1 (sucesso médio em todas as 10.140 tentativas), pass@20 (percentual de tarefas resolvidas pelo menos uma vez) e Observed 20/20, que conta quantas tarefas o modelo acerta em todas as 20 execuções registradas. Essa última é tratada pela Microsoft como a métrica mais próxima das exigências de produção.
“If you are choosing a model for work that touches production database records, pass@1 should not be read alone. Observed 20/20 shows which tasks succeed on every attempt, which is closer to what production reliability requires.”, alertou a equipe.
O que mudou na prática: hotel sem downgrade indevido
Um dos exemplos citados é uma tarefa de reservas de hotel corporativas. Um viajante pede o downgrade de quarto, mas a política da empresa exige aprovação prévia de um gerente. Antes do treinamento com o ThinkingBox, o Qwen3.8-27B alterava a reserva e emitia reembolso sem aprovação em 15 de 20 tentativas, violando a política e deixando o banco em estado incorreto.
Após o fine-tuning com a função de recompensa baseada no estado final do banco, o comportamento se inverteu. “After RL fine-tuning, it preserved the booking and payment state in all 20; all expected records matched in 19.”, relatou a equipe. Em outras palavras, o agente passou a respeitar a regra de negócio e a manter os registros financeiros íntegros, exatamente o tipo de requisito que vale mais do que uma resposta “parecendo correta” no chat.
Resultados: mais consistência, menos surpresas
Os números apontam para um ganho relevante na confiabilidade do Qwen3.8-27B. A taxa média de sucesso (pass@1) subiu de 51,70% para 60,78% após os 50 passos de GRPO. Ainda mais expressivo foi o salto em Observed 20/20: o modelo passou de 38 tarefas concluídas corretamente em todas as 20 tentativas para 107, quase o triplo.
Isso significa que o agente não apenas acerta mais, como acerta de forma repetível — algo crítico quando o alvo são sistemas que mexem com estoque, pagamentos, reservas ou dados sensíveis. A Microsoft descreve o efeito como um “afiamento” do comportamento: o modelo não se torna necessariamente mais amplo em cobertura, mas muito mais estável nas trajetórias que aprende a executar bem.
Os resultados também mostram como as métricas tradicionais podem enganar. Em avaliações anteriores com outros modelos, o Kimi-K3, por exemplo, conseguiu completar 93,89% das tarefas pelo menos uma vez, mas resolveu apenas 68 das 507 tarefas (13,41%) em todas as 20 execuções. Já os modelos Claude Opus 5 e 5.5 completaram 241 tarefas com 100% de consistência, apesar de não liderarem em pass@1 em todos os cenários.
Comparações adicionais indicam que modelos com pass@1 ligeiramente superior ao Qwen3.8-27B ajustado nem sempre alcançam o mesmo nível de confiabilidade em Observed 20/20, reforçando a tese de que, para produção, a repetibilidade pesa tanto quanto — ou mais do que — a média de acertos.
Impacto em custo e operação
A equipe também estimou o custo por tarefa “confiável”, dividindo o valor da campanha completa de avaliação (507 tarefas vezes 20 rodadas) pelo número de tarefas aprovadas em todas as tentativas. Com o fine-tuning via ThinkingBox, o Qwen3.8-27B se aproximou, em custo por tarefa dependável, de modelos mais avançados, reduzindo o custo por tentativa bem-sucedida ao mesmo tempo em que elevou o pass@1 de 51,70% para 60,78%.
A ressalva é que esses valores são índices comparativos, não faturas de nuvem, e não incluem o custo de treinar o modelo nem de rodar as sondagens iniciais para selecionar a pool de tarefas. Ainda assim, o resultado indica que investir em um ciclo de treinamento com função de recompensa ligada diretamente ao estado do banco pode compensar para aplicações que exigem alta confiabilidade.
O que muda para sistemas de dados em produção
A proposta do ThinkingBox mira diretamente setores que dependem de manipulação precisa de dados de produção: sistemas de reservas, bancos digitais, e-commerce, plataformas de assinatura, gestão de estoque, backoffices de empresas e serviços financeiros em geral. Nesses ambientes, um agente que “erra bonito” — com explicações plausíveis mas registros errados — pode gerar prejuízo financeiro, falhas em atendimento e perda de confiança.
Ao transformar a verificação do estado final do banco de dados em função de recompensa, a abordagem força o agente a alinhar seu comportamento ao que realmente importa nesses cenários: não parecer certo, mas deixar o sistema certo. A métrica Observed 20/20, ao exigir que a tarefa seja concluída com sucesso em todas as tentativas, se aproxima do requisito de “não quebrar” um sistema de produção sob uso intenso.
Por outro lado, a própria Microsoft reconhece que há custos e barreiras. Implementar benchmarks com backends reais, definir checagens executáveis de qualidade e manter infraestrutura para rodar 20 execuções por tarefa exige equipes técnicas estruturadas e acesso a recursos de computação. Organizações menores, ou que ainda operam com dados sintéticos, podem ter dificuldade para adotar a metodologia de imediato.
Entenda o contexto
O ThinkingBox surgiu a partir de experimentos internos da Microsoft com agentes orientados a ferramentas, projetados para trabalhar sobre bancos de dados reais. Em uma primeira leva de testes, os pesquisadores rodaram dezoito modelos diferentes no benchmark, expondo uma diferença grande entre “acertar uma vez” e “acertar sempre”.
Essa diferença levou à formulação da métrica Observed 20/20 e à constatação de que, em ambientes críticos, a escolha de modelo não pode se basear só em médias agregadas. Ao abrir o código do ThinkingBox-Training no GitHub, a Microsoft tenta estimular que outras equipes repliquem e adaptem o ciclo de treino em seus próprios domínios e bases.
Uma das apostas é que, com mais grupos contribuindo com novas tarefas e variações de backends, a pool de treinamento se torne mais rica e generalizável. Isso pode acelerar o desenvolvimento de agentes de IA voltados a áreas como saúde, finanças, governança de dados públicos e operações corporativas complexas.
Próximos passos e adoção pela comunidade
Os próximos passos indicados pela equipe envolvem ampliar o conjunto de tarefas disponíveis no formato ThinkingBox, refinar os critérios de seleção de dificuldade relativa e testar o método em modelos ainda maiores ou especializados. Outro movimento esperado é a integração desse tipo de treinamento com pipelines de MLOps já usados em produção, para que agentes sejam ajustados continuamente com base nos erros que realmente afetam o banco de dados.
Na comunidade de desenvolvedores e pesquisadores, a expectativa é que o código aberto do ThinkingBox-Training permita reproduzir os ganhos vistos com o Qwen3.8-27B em outros modelos e cenários, bem como explorar métricas derivadas da Observed 20/20. Com a pressão crescente por segurança e transparência em sistemas automatizados, a tendência é que abordagens que cobram consistência em todas as execuções ganhem espaço como novo padrão de qualidade para agentes que manipulam dados reais.
Fonte: matéria original

