Investigadores da IBM publicaram o DRACO, um método de aprendizagem por reforço para agentes de longa duração que procura resolver um problema recorrente: uma trajetória pode conter dezenas de decisões, mas o sinal de recompensa chegar apenas no fim. O artigo foi submetido ao arXiv a 3 de setembro de 2026 e a IBM disponibilizou, sob licença Apache-2.0, o código de treino, avaliação e análise.
DRACO significa Distributing Rubric-based Advantage for Credit Optimization. Em vez de aplicar a mesma vantagem de uma trajetória a todos os tokens da resposta, o método usa critérios gerados dinamicamente e as referências do avaliador a passos concretos para redistribuir essa vantagem. A quantidade total de sinal atribuída à trajetória mantém-se; muda o ponto em que esse sinal influencia a aprendizagem.
Um resultado final diz pouco sobre dezenas de decisões
A atribuição de mérito é particularmente difícil em agentes que executam tarefas longas. Um agente pode cometer um erro no início, recuperar, usar corretamente várias ferramentas e falhar apenas no último passo. Um único indicador de sucesso não explica quais das decisões anteriores devem ser reforçadas.
O DRACO cria critérios específicos para o pedido e para a trajetória, elimina duplicados e remove critérios que não distinguem as diferentes execuções do grupo. Um avaliador analisa depois a trajetória completa e associa cada critério aos passos relevantes. Essas referências são convertidas em pesos por passo, e a vantagem normalizada pelo GRPO é redistribuída de acordo com esses pesos.
Há aqui uma diferença importante: o método não introduz outro modelo treinado para decidir a responsabilidade de cada passo. A redistribuição é calculada diretamente. A nova dependência passa a ser o próprio circuito de criação de critérios e avaliação.
Os resultados são interessantes, mas há uma discrepância
O resumo do artigo afirma que o DRACO melhora 15,9 pontos sobre o modelo base no AppWorld e 5,3 pontos sobre GRPO treinado com uma recompensa real mas esparsa. Para o tau-bench, o mesmo resumo indica uma melhoria de 5,3 pontos sobre o modelo base num cenário sem um avaliador externo de fronteira.
O README do repositório oficial da IBM apresenta, contudo, outro número para o tau-bench: 4,6 pontos. A diferença não invalida o trabalho, mas merece ser assinalada porque o repositório é o artefacto a partir do qual uma equipa tentará reproduzir os resultados.
Aipolix trata, por isso, os ganhos de desempenho como resultados reportados pelos autores. Não foi encontrada uma reprodução independente nesta análise, e a divergência entre 5,3 e 4,6 pontos deve ser esclarecida antes de o valor ser tratado como definitivo.
O avaliador passa a fazer parte do controlo do treino
A consequência de engenharia mais importante é que o comportamento do avaliador fica diretamente ligado à otimização. Em várias configurações descritas no repositório, um modelo externo avançado gera ou classifica os critérios. Noutras, uma cópia servida do próprio modelo em treino assume essa função; há ainda uma configuração que exige concordância entre três avaliações.
Isto altera a disciplina operacional necessária. Uma mudança na instrução do avaliador, na versão do modelo, na amostragem ou na forma como são produzidas as referências pode alterar a localização da recompensa, mesmo que o resultado global da trajetória seja semelhante. A deriva do avaliador deixa, portanto, de ser apenas um problema de medição: pode transformar-se num problema de treino.
Uma equipa que teste este método deve versionar os prompts do avaliador, o modelo usado, a lógica de geração dos critérios e as referências produzidas, juntamente com a configuração de treino. Guardar apenas os pesos e os parâmetros do otimizador não é suficiente para reproduzir o processo que decidiu onde cada passo recebeu mérito.
O código publicado permite uma inspeção pouco habitual
O repositório da IBM inclui configurações de treino, scripts de execução, documentação do circuito de recompensa, fórmulas de atribuição, ambientes de avaliação para AppWorld e tau-bench e o código de análise usado nos resultados. O README descreve oito configurações que variam a origem da recompensa, o avaliador e a forma como a vantagem é distribuída.
A maioria das experiências usa Qwen3.6-27B, enquanto uma configuração usa Qwen2.5-32B-Instruct. A configuração principal do DRACO combina critérios dinâmicos com redistribuição por passo. O repositório indica também que cada configuração foi treinada durante 100 passos, um detalhe relevante para interpretar a amplitude da evidência.
A disponibilidade do código torna o método verificável, mas não substitui uma reprodução independente. AppWorld e tau-bench são ambientes controlados; agentes em produção podem ter horizontes maiores, falhas de ferramentas diferentes e observabilidade muito mais imperfeita.
O que vale a pena testar antes de adotar
O primeiro teste não deve limitar-se a comparar pontuações de benchmark. A equipa deve comparar a atribuição uniforme com a atribuição por passo mantendo, tanto quanto possível, o mesmo modelo, as mesmas trajetórias e o mesmo avaliador. Depois, deve verificar se o ganho resiste a mudanças no modelo avaliador, nos critérios e na distribuição das tarefas.
O segundo teste é de sensibilidade a erros de avaliação. Como o DRACO usa referências do avaliador para decidir que passos recebem mais sinal, é útil remover ou alterar deliberadamente algumas dessas referências e medir o efeito no treino. Isso ajuda a perceber se o agente está a aprender a tarefa ou a adaptar-se ao estilo de atribuição de um avaliador específico.
Mesmo que os números publicados mudem após replicação, a ideia arquitetural continua relevante: o treino de agentes de longa duração precisa de uma cadeia rastreável entre evidência de avaliação e otimização. O DRACO torna essa cadeia explícita e mostra que o avaliador deve ser tratado como uma dependência operacional, com versionamento e capacidade de auditoria.