Pesquisadores propõem o framework PAPAV: apenas 3 de 64 benchmarks avaliam a verificação

Quando um agente multimodal passa do controle de um navegador para o controle de um manipulador robótico, muda não só o ambiente, mas também o custo do erro. Um novo artigo do Hugging Face Daily Papers tenta descrever essa transição com uma linguagem única. Os autores introduzem o conceito de agentes multimodais incorporados (MMEA) e propõem o framework PAPAV, com cinco funções. A principal conclusão empírica: entre os 64 benchmarks analisados, apenas 5 avaliam a capacidade de prever as consequências das ações e somente 3 verificam se o resultado foi alcançado. Quase todos os demais medem se a tarefa foi concluída.

Três classes de sistemas e um denominador comum

Os autores começam por uma divisão. Os agentes multimodais (MMA) sustentam a interação por meio de raciocínio, memória, ferramentas e feedback. O exemplo mais visível são os agentes que operam um computador. Os sistemas robóticos (RS) conectam percepção e execução sob a dinâmica do mundo físico. Os MMEA ficam na interseção: são sistemas orientados a objetivos que unem o raciocínio multimodal sobre a tarefa à ação física e revisam as decisões com base no resultado.

A pergunta central do trabalho é simples: o que muda quando o agente passa de computer-use para robot-use? Para responder, é preciso uma escala de comparação que não dependa de uma arquitetura específica. Por isso, os autores escolhem funções, e não o desenho do modelo.

PAPAV: cinco funções em vez de uma única métrica

A sigla significa:

• Perceive: perceber o estado atual;
• Anticipate: prever os efeitos das ações;
• Plan: construir um plano executável;
• Act: agir por meio de uma interface ou de um corpo;
• Verify: verificar o resultado.

Essa definição permite identificar o que as três classes têm em comum e, depois, comparar os MMEA com os MMA tradicionais e com a robótica clássica. Um agente que clica em botões e um manipulador numa fábrica executam as cinco funções. O que muda é a dificuldade de cada uma e o custo de uma falha.

Onde a física tira a liberdade

Os autores destacam cinco restrições físicas. A lista vai da observabilidade parcial a resultados impossíveis de verificar. O efeito geral é um só: no mundo físico, há menos decisões que podem ser fixadas de antemão e também menos chances de desfazer um erro. Um clique errado numa interface costuma poder ser revertido. Um objeto derrubado ou um movimento errado não podem.

Daí vem o peso das funções Anticipate e Verify. Um agente que não consegue avaliar as consequências com antecedência e depois checar o resultado com honestidade é perigoso em ambiente físico, mesmo com bom planejamento.

O que a análise de 64 benchmarks mostrou

O principal número do trabalho diz respeito ao estado da avaliação no setor:

• 64 benchmarks foram analisados no total;
• a avaliação explícita se concentra na função Act;
• apenas 5 benchmarks avaliam Anticipate;
• apenas 3 avaliam Verify;
• as duas funções ficam, em sua maioria, escondidas atrás do indicador final de sucesso da tarefa.

O problema é que o sucesso da tarefa mistura as cinco capacidades em um único número. O modelo pode ter concluído a tarefa graças a uma boa percepção, e não a uma boa previsão. Ou pode ter falhado por causa de uma verificação fraca, embora o plano estivesse correto. Sem medições separadas, é difícil entender o que de fato melhorou entre versões do sistema e o que precisa ser corrigido.

Com base nessas mesmas restrições, os autores montam uma lista de problemas em aberto. Entre eles estão o projeto de agentes físicos confiáveis e a medição do progresso nas cinco capacidades.

Como usar o framework na prática

Para equipes que desenvolvem agentes para robôs, o trabalho tem aplicação prática. O PAPAV pode servir como checklist de auditoria: para cada função, definir qual teste a mede e encontrar as que ficam sem cobertura. Se o pipeline não tem uma verificação separada do resultado após a ação, vale adicioná-la antes de escalar.

Para quem desenvolve benchmarks, a conclusão é ainda mais concreta. São necessárias tarefas que avaliem separadamente a previsão de consequências e a verificação do resultado, e não apenas o sucesso final. Para investidores e clientes, é uma referência na hora de assistir a demos: um bom índice de conclusão de tarefas ainda não diz como o sistema se comporta quando o resultado não pode ser verificado ou o erro não pode ser desfeito.

O trabalho não propõe um novo modelo nem promete ganho em um teste específico. É uma tentativa de organizar termos e métricas na interseção entre agentes e robótica, enquanto a fronteira entre eles se apaga rapidamente.