DeReAct: o que falta para confirmar seus resultados e sua proposta de controle

A proposta ainda não equivale a um resultado confirmado

Na proposta desta matéria, o DeReAct é apresentado como um projeto que separa duas decisões em um agente de inteligência artificial: se uma ação em uma ferramenta está autorizada e se a tarefa já pode ser considerada concluída. A ideia é relevante porque um agente pode fazer mais do que redigir uma resposta: ele também pode acionar ferramentas, modificar informações ou iniciar operações. No entanto, com as fontes verificadas disponíveis, não é possível confirmar a existência de um artigo de pesquisa sobre o DeReAct com os detalhes descritos, nem validar seu método ou seus resultados.

Essa limitação atinge o ponto central da notícia. Não há aqui evidências primárias verificáveis que permitam conferir as pontuações de Pass@1, as variantes avaliadas, os baselines, os rastros experimentais ou a disponibilidade de código e prompts. Portanto, as supostas melhorias no GAIA e no SWE-bench Verified não devem ser apresentadas como descobertas comprovadas. Também não é possível atribuir ao sistema números, mecanismos específicos de decisão ou garantias operacionais.

Há, sim, contexto geral para explicar o problema de projeto. O ReAct é descrito como uma abordagem que combina raciocínio e ações, inclusive ações realizadas por meio de ferramentas. Esse enquadramento ajuda a entender por que o planejamento de uma ação e sua execução podem estar conectados no mesmo fluxo. Isso, porém, não confirma a existência do DeReAct nem que ele resolva as limitações dessa abordagem.

O que a arquitetura propõe separar

A descrição da proposta atribui duas funções a componentes distintos. O Critic decidiria se uma ação que o agente pretende realizar deve ser permitida. O Context Manager reuniria informações sobre o estado da tarefa e determinaria se há evidências suficientes para certificar que ela foi concluída. Essa separação busca evitar que o mesmo processo que impulsiona uma ação também conceda permissão a si próprio ou declare o sucesso sem uma verificação independente.

É uma distinção conceitual útil, mas insuficiente para avaliar um sistema. Para saber o que um Critic realmente faz, seria necessário conhecer, por exemplo, quais ações ele considera sensíveis, quais regras utiliza, que informações recebe e o que acontece quando sua decisão é incerta. Também seria preciso medir tanto os bloqueios indevidos — ações válidas que ele impede — quanto as autorizações indevidas — ações que permite apesar de não atenderem à política. Não dispomos de resultados verificados que respondam a essas perguntas sobre o DeReAct.

A função atribuída ao Context Manager levanta outra questão: o que conta como evidência de conclusão. Um resumo da conversa pode deixar de fora alterações feitas em uma ferramenta; uma resposta do agente pode afirmar que uma operação foi bem-sucedida sem demonstrá-lo. Para verificar a tarefa, seria necessário saber qual estado o componente mantém, quais sinais externos consulta e como resolve contradições entre o histórico e o resultado de uma ferramenta. A proposta aponta para essa separação, mas a descrição disponível não permite confirmar sua implementação nem seus critérios.

Os benchmarks não substituem a verificação do artigo

A proposta menciona o GAIA e o SWE-bench Verified como testes nos quais teriam sido medidas melhorias. Para interpretar uma pontuação de Pass@1, é preciso mais do que saber o nome do benchmark: é necessário conhecer a versão, os modelos usados, as ferramentas habilitadas, o número de tentativas, as condições de execução e o baseline de comparação. Também importa saber se as diferenças são consistentes e como as falhas são contabilizadas. Sem esses detalhes confirmados, um número isolado não permitiria atribuir o resultado ao Critic, ao Context Manager ou a outra alteração de configuração.

Benchmarks testam tarefas delimitadas em condições experimentais. Mesmo um resultado reproduzível em um desses testes descreveria o desempenho naquele ambiente; não demonstraria automaticamente que o agente é seguro para usuários, dados sensíveis ou ferramentas conectadas a sistemas reais. Para sustentar uma afirmação sobre segurança operacional, seriam necessárias avaliações específicas das políticas, de falhas de autorização, de tentativas de manipulação e do comportamento em situações de incerteza.

Neste caso, a primeira tarefa não é avaliar se as melhorias são grandes ou pequenas, mas confirmar o que foi medido e onde. As informações verificadas não permitem responder quais valores exatos de Pass@1 cada variante do DeReAct teria alcançado, quais baselines foram comparados ou se o protocolo pode ser reproduzido. Até que apareça documentação primária aplicável, não cabe preencher essas lacunas com números ou detalhes inferidos.

Custos, erros residuais e generalização

Separar decisões pode facilitar a supervisão, mas também pode aumentar a latência, o número de chamadas a modelos e os pontos de falha. Um Critic rigoroso demais pode bloquear tarefas legítimas; um permissivo demais pode deixar passar ações que deveriam ser rejeitadas. Um Context Manager com informações incompletas pode certificar uma tarefa antes da hora, enquanto um excessivamente conservador pode mantê-la em aberto mesmo depois de o objetivo ter sido alcançado. São riscos gerais que precisariam ser medidos, não falhas comprovadas do DeReAct.

A avaliação deveria incluir casos-limite e falhas, não apenas a porcentagem de tarefas concluídas. Entre as perguntas relevantes estão o que acontece quando uma ferramenta retorna um erro, quando o agente recebe dados contraditórios ou quando o estado muda depois de uma ação. Também seria importante observar se o sistema distingue entre solicitar uma operação e verificar que ela foi executada corretamente.

A generalização também não pode ser deduzida a partir de dois nomes de benchmarks. Um método pode ter bom desempenho em tarefas de programação ou de uso de ferramentas sob condições controladas e se comportar de outra forma em processos empresariais, sistemas com permissões diferentes ou situações que envolvam informações pessoais. Em seu material geral sobre IA agêntica, a AEPD observa que esses sistemas podem introduzir mais automação no tratamento de dados pessoais. Esse contexto torna relevante avaliar limites e supervisão, mas não constitui evidência sobre o projeto ou a segurança do DeReAct.

O que falta para concluir a verificação

Para transformar a proposta em uma notícia verificável, é necessária uma fonte primária acessível que identifique o trabalho e descreva a versão avaliada. Em seguida, seria preciso analisar o método: como a política do Critic é definida, de onde ele obtém contexto, quais estados o Context Manager mantém e qual critério utiliza para certificar uma tarefa. Sem esses elementos, os nomes dos componentes descrevem uma intenção, não necessariamente o comportamento de uma implementação.

A análise dos resultados exige, no mínimo, tabelas completas de Pass@1 para cada variante, a configuração dos baselines e uma explicação de como o GAIA e o SWE-bench Verified foram executados. A disponibilidade de código, prompts e rastros ajudaria a reproduzir o experimento; se algum desses materiais não for publicado, seria necessário indicar expressamente quais partes não podem ser reproduzidas. Não é válido presumir que esses materiais estão disponíveis nem afirmar que o estudo não os oferece sem ter verificado o artigo.

Até que essa documentação esteja disponível, a conclusão adequada é limitada: desacoplar a autorização de ações da verificação de conclusão é uma proposta que pode ser explicada e avaliada como princípio de projeto, mas seus resultados experimentais e suas garantias não podem ser confirmados aqui. Essa diferença importa para quem compara ferramentas ou considera implantar agentes: uma arquitetura promissora não equivale a uma validação independente nem a uma avaliação de riscos no contexto específico de uso.

Para continuar a leitura, vale distinguir três perguntas: o que um agente pode fazer, quais controles aplica antes de agir e como o resultado é verificado. A explicação geral do ReAct ajuda a contextualizar a primeira; uma comparação entre sistemas deveria examinar a segunda; e uma avaliação de descoberta deveria verificar a terceira com evidências de cada ferramenta conectada. Nenhuma dessas linhas de leitura altera o status de verificação do DeReAct: o documento primário e seus resultados continuam pendentes de confirmação.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.