Resumo Técnico: AutoRPA

Declaração do Problema

Embora agentes de Modelos de Linguagem de Grande Escala (LLM) tenham demonstrado proficiência na interação com Interfaces Gráficas de Usuário (GUI) por meio do paradigma ReAct (Raciocínio e Ação), eles enfrentam ineficiências significativas na implantação prática. A maioria das pesquisas existentes otimiza o desempenho de tarefas únicas em instâncias novas, frequentemente invocando raciocínio de LLM caro para cada interação. No entanto, cenários do mundo real frequentemente envolvem tipos de tarefas repetitivas (por exemplo, envio de relatórios diários, reserva de voos), onde invocar raciocínio de LLM para cada instância é computacionalmente desperdiçado e custoso.

Por outro lado, a Automação Robótica de Processos (RPA) tradicional oferece alta eficiência de execução para tarefas repetitivas, mas sofre de fragilidade. A RPA tradicional depende de scripts criados manualmente que são rígidos; eles falham quando os layouts da GUI mudam e exigem esforço humano significativo para serem desenvolvidos e mantidos. O desafio central abordado por este artigo é como sintetizar automaticamente funções de RPA robustas e eficientes em tokens para tipos de tarefas específicos usando assistência de LLM, preenchendo a lacuna entre a flexibilidade dos agentes de LLM e a eficiência da RPA tradicional.

Metodologia: A Estrutura AutoRPA

O AutoRPA é uma estrutura projetada para "destilar" a lógica de decisão de agentes no estilo ReAct em código de RPA executável e reutilizável. O processo é dividido em três fases principais:

1. Fase de Exploração

• Geração de Trajetória ReAct: Um agente no estilo ReAct interage com o ambiente da GUI para resolver uma instância de tarefa. Ele observa capturas de tela e estruturas de UI (DOM/árvores de acessibilidade), raciocina sobre as etapas e executa ações.
• Reflexão: Se uma trajetória falhar, um mecanismo de reflexão permite que o agente analise a falha e tente novamente (até $N_{ref}$ vezes) para garantir que trajetórias bem-sucedidas sejam coletadas.
• Tradução (Codificação Rígida para Suave): Um Agente Tradutor dedicado converte as ações "codificadas rigidamente" do agente (por exemplo, click(index=2)) em procedimentos "codificados suavemente". Em vez de depender de índices ou coordenadas fixas, o tradutor gera código que localiza elementos com base em atributos semânticos (por exemplo, conteúdo de texto, tipo de elemento, descrições de destino) usando uma função find_element. Isso garante que a lógica resultante seja robusta a pequenas alterações de layout.

2. Fase de Geração de RPA

• Agente Construtor com RAG: Um Agente Construtor sintetiza a função final de RPA ($F_k$) para um tipo de tarefa específico ($G_k$).
• Geração Aumentada por Recuperação (RAG): Para evitar que o construtor faça suposições errôneas sobre o estado da interface devido à falta de contexto, a estrutura emprega um mecanismo de recuperação organizado em árvore. O construtor pode consultar um banco de dados de trajetórias para buscar blocos de interação específicos (observações, ações, resumos) de explorações bem-sucedidas anteriores.
• Síntese de Código: O construtor gera uma função Python que inclui estruturas lógicas (loops, condicionais) para lidar com variações de tarefas. Ele poda etapas redundantes da trajetória traduzida e incorpora o tratamento de erros necessário. O código também pode incluir chamadas a LLMs Multimodais (ask_mllm) para tarefas de raciocínio complexo que não podem ser resolvidas por regras estáticas.

3. Fase de Verificação com Reparo Híbrido

• Execução e Análise: O código de RPA gerado é executado em instâncias de tarefas vistas. Se a execução falhar, um Agente Analista identifica o ponto de interrupção, analisa a causa da falha e determina se a tarefa pode ser retomada ou deve ser reiniciada.
• Estratégia de Reparo Híbrido: Em vez de depender apenas do refinamento de código, o sistema emprega uma abordagem híbrida. Se o código falhar, o agente ReAct retoma a execução a partir do ponto de interrupção (ou reinicia) para produzir uma demonstração corretiva. Essa "trajetória híbrida" (execução de código + reparo ReAct) é enviada de volta ao Agente Construtor para refinar o código iterativamente.
• Encerramento: O processo continua até que o código passe em todas as tarefas de validação ou seja atingido o número máximo de tentativas de refinamento ($M$). Se a tarefa permanecer não automatizável, o sistema recorre ao uso do agente ReAct para aquela instância específica.

Contribuições Principais

1. Estrutura AutoRPA: Um sistema inovador que gera automaticamente funções de RPA robustas para tipos de tarefas, visando cenários de automação de GUI repetitivos onde a RPA tradicional é muito frágil e os agentes ReAct são muito custosos.
2. Pipeline Tradutor-Construtor: Um processo de duas etapas onde um tradutor converte ações ReAct codificadas rigidamente em procedimentos baseados em atributos e codificados suavemente, e um construtor sintetiza funções de RPA robustas usando recuperação de trajetória em estrutura de árvore (RAG).
3. Estratégia de Reparo Híbrido: Um mecanismo de verificação que combina a execução direta de código com um fallback baseado em ReAct. Isso permite que o sistema refine iterativamente o código incorporando demonstrações corretivas do agente ReAct quando o código sintetizado falha.
4. Eficiência e Robustez: A estrutura reduz com sucesso o consumo de tokens significativamente, mantendo ou melhorando as taxas de sucesso em comparação com agentes puramente baseados em LLM.

Resultados Experimentais

Os autores avaliaram o AutoRPA em três benchmarks: AndroidWorld (aplicativos Android do mundo real), WebArena (tarefas web realistas) e MiniWoB++ (tarefas web simuladas).

• Eficiência de Tokens: O AutoRPA reduziu o uso de tokens em 82% a 96% em comparação com agentes no estilo ReAct. Por exemplo, no AndroidWorld com GPT-4o, o AutoRPA consumiu apenas 14,7 mil tokens versus 79,9 mil para o ReAct.
• Taxas de Sucesso:
  • No AndroidWorld, o AutoRPA alcançou uma taxa de sucesso de 37,0% (GPT-4o), superando o ReAct (35,2%) e o SeeAct (15,3%), enquanto usava significativamente menos tokens.
  • No MiniWoB++, o AutoRPA alcançou 91,1% de sucesso em tarefas "difíceis" e 95,4% em todas as tarefas, superando métodos state-of-the-art como AdaPlanner e AutoManual, enquanto consumia menos de 10% dos tokens exigidos pelo ReAct.
  • No WebArena, o AutoRPA igualou o desempenho de métodos anteriores, mas com uma redução drástica no consumo de tokens.
• Estudos de Ablação: Experimentos confirmaram que remover a fase de exploração ReAct, o agente tradutor, o mecanismo RAG ou a estratégia de reparo híbrido levou a quedas significativas nas taxas de sucesso, validando a necessidade de cada componente.

Significado e Alegações

O artigo afirma que o AutoRPA aborda um problema prático crítico: o alto custo e a ineficiência de executar agentes de LLM em tarefas repetitivas versus o alto custo de manutenção da RPA tradicional. Ao destilar a lógica de decisão de agentes de LLM em código verificável e reutilizável, o AutoRPA permite:

• Automação Eficiente em Tokens: Redução drástica do custo computacional da automação de GUI para tipos de tarefas recorrentes.
• Robustez: Geração de código que lida melhor com variações no ambiente e nas instruções de tarefa do que scripts estáticos ou geração única de LLM.
• Escalabilidade: Fornecimento de um caminho para automatizar tarefas de GUI diversas sem exigir scripts manuais extensos ou conhecimento especializado curado para cada novo tipo de tarefa.

Os autores enfatizam que seu método não depende de agentes ReAct específicos e pode ser adaptado a várias bases de LLM, tornando-o uma solução generalizável para automação de GUI eficiente.