Verificações simples antes da ação reduzem erros de agentes de IA em testes iniciais

Resumo

• “Agentes” de IA que executam comandos no computador, editam código ou fazem reservas de viagem por conta própria podem falhar sem produzir nenhuma mensagem de erro: a ação é concluída, mas o resultado está errado.
• Dois novos artigos de pesquisa, nenhum ainda revisado por pares, testaram cada um a adição de verificações automáticas simples antes que a ação de um agente produza efeito, para detectar esse tipo de erro silencioso.
• O verificador de um dos artigos detectou a maioria dos comandos inválidos e quase eliminou a corrupção silenciosa de arquivos causada por edições de código malfeitas; as verificações do outro quase dobraram a frequência com que um agente de reservas de viagem concluía a tarefa corretamente.
• Ambos são estudos isolados, conduzidos pelos próprios autores, sem replicação independente, e cada um cobre apenas um conjunto restrito de tarefas.

O que aconteceu

Sistemas de IA construídos para agir por conta própria — digitando comandos em um terminal de computador ou editando arquivos de código diretamente — nem sempre avisam quando algo dá errado. Asaad Althoubi, cujo artigo propõe verificar a ação de um agente antes que ela produza efeito, resumiu assim: “Uma ação errada nem sempre falha de forma ruidosa; ela pode falhar silenciosamente, produzindo um efeito plausível, mas incorreto, que não gera nenhum erro.”

Althoubi testou verificações baseadas em regras em dois tipos de ação. Para comandos de shell — instruções de texto digitadas na linha de comando de um computador —, um verificador que confirma a sintaxe, confirma que o programa chamado existe e valida os parâmetros (flags) contra documentação extraída de textos de ajuda e manuais detectou 95,8% de 9.930 comandos inválidos abrangendo 482 ferramentas, ao mesmo tempo em que sinalizou erroneamente 10,0% dos comandos válidos. Usando apenas as verificações de sintaxe e existência, a ferramenta não produziu nenhum alarme falso, mas detectou apenas metade dos comandos inválidos; acrescentar a verificação de parâmetros detectou mais erros, mas também foi responsável pela maior parte dos alarmes falsos.

Para edições de código, Althoubi constatou que especificar uma edição por número de linha corrompeu silenciosamente 99,1% dos arquivos assim que o arquivo se deslocava mesmo que apenas uma linha em relação ao que o agente esperava, em testes com 640 edições e 224 arquivos. Especificar uma edição apenas pelo nome da função acertou a função errada em 12,7% das vezes mesmo sem esse deslocamento, porque muitos arquivos contêm mais de uma função com o mesmo nome. A alternativa do próprio Althoubi — um método que exige texto ao redor suficiente para confirmar uma correspondência, recusa correspondências ambíguas e só aceita uma correspondência aproximada quando ela é claramente a melhor candidata — produziu apenas uma aplicação silenciosa incorreta em 8.320 tentativas, uma taxa de 0,01%. Uma versão relacionada, de dois níveis, construída para se abster diante de combinações ambíguas de parâmetros em vez de arriscar um palpite, detectou 95,8% dos erros com uma taxa de falsos positivos mais baixa, de 7,0%.

Segundo o próprio relato de Althoubi, a maior parte dos comandos e edições inválidos usados nos testes foi gerada sinteticamente ou por alteração artificial de arquivos, não produzida por um agente cometendo erros reais; a validação contra a produção real de um modelo ficou limitada a 42 comandos e 9 edições, todos de um único modelo Claude da Anthropic rodando em um computador Linux.

Um segundo artigo, de Vikas Reddy, Sumanth Reddy Challaram e Abhishek Basu, examinou um agente de IA rodando sobre o modelo gpt-4o-mini enquanto ele processava reservas de passagens aéreas em um benchmark de cenários realistas de atendimento ao cliente que pesquisadores usam para avaliar esse tipo de agente, chamado tau-squared-bench. Os autores constataram que 78% das falhas de tarefa observadas no agente foram silenciosas: os dados da reserva ficaram errados sem que nenhuma ferramenta usada pelo agente disparasse um erro. A adição de quatro verificações automáticas, somente de leitura, antes que o agente pudesse agir — confirmando a elegibilidade para cancelamento, verificando a franquia de bagagem, bloqueando alterações no número de passageiros e exigindo que o agente lesse os dados atuais antes de gravar novos dados — elevou a taxa de sucesso da tarefa de 29,6% para 42,0%, um ganho de 12,4 pontos percentuais que, segundo os autores, se manteve em diferentes rodadas de teste aleatórias.

Um artigo no CCTest.ai, publicado no mesmo dia que o artigo de Althoubi, resumiu suas descobertas sem realizar nenhum teste independente e sem indicar autoria.

O que isso significa (e o que não significa)

Dentro de suas próprias configurações de teste, os dois artigos mostram que uma verificação simples, baseada em regras, executada antes que a ação de um agente de IA produza efeito, consegue detectar uma parcela significativa dos erros que de outra forma passariam despercebidos — seja um comando malformado, uma edição de código mal direcionada, ou um agente de reservas deixando dados errados sem que nenhuma ferramenta sinalizasse isso.

Isso não mostra que essas verificações específicas funcionem além das configurações testadas. Os resultados de Althoubi cobrem comandos de shell e edições de código em uma única máquina; os resultados de Reddy, Challaram e Basu cobrem um modelo, um benchmark e um domínio. Nenhum dos artigos passou por revisão por pares, e cada grupo de autores avaliou o próprio método proposto em um benchmark e uma configuração que eles mesmos construíram, sem que nenhum grupo externo reproduzisse os números de nenhum dos dois artigos. O resumo do CCTest.ai sobre o artigo de Althoubi, publicado no mesmo dia, repete suas afirmações sem testá-las, agregando visibilidade, não confirmação independente.

O que ainda não sabemos

O quão bem essas verificações detectam falhas silenciosas no uso comum e real de agentes permanece, em grande parte, não testado: os números centrais de Althoubi vêm quase inteiramente de um benchmark sintético e de arquivos alterados artificialmente que ele mesmo construiu, com erros genuinamente gerados por modelo limitados a 42 comandos e 9 edições de um único modelo Claude.

Nenhum dos artigos mede o tempo extra ou o custo computacional que as próprias verificações acrescentam, de modo que não há comparação publicada com o custo de se recuperar de uma falha silenciosa não detectada.

Se alguma das duas abordagens funciona para outros tipos de ação — gravações em banco de dados, chamadas de API em outros domínios, planos de múltiplas etapas — é algo ainda não estabelecido: Althoubi cobre apenas comandos de shell e edições de código, e as barreiras de verificação para reservas aéreas foram testadas apenas nesse único benchmark, com um único modelo.

Os dois artigos são preprints no arXiv que não passaram por revisão por pares, e nenhum grupo independente replicou os resultados quantitativos de nenhum dos dois. Eles também medem coisas diferentes sob a ideia geral de “falha silenciosa” — ações inválidas de baixo nível e edições mal aplicadas em um caso, estados finais que violam políticas no outro —, de modo que seus números são relacionados, mas não diretamente comparáveis. Os próprios autores do segundo artigo observam que sua comparação com modelos de fronteira se apoia em apenas 5 tentativas não replicadas, que algumas verificações individuais têm baixa precisão, e que não compararam sua abordagem com alternativas como prompts diferentes ou autoverificação pelo próprio modelo.