Resumo Técnico: Repense Antes de Executar: Execução Adaptativa para Modelos de Ação de Mundo

Declaração do Problema

Os Modelos de Ação de Mundo (WAMs) representam um paradigma para manipulação robótica que prevê conjuntamente ações futuras e a evolução do ambiente. A implantação padrão de um WAM envolve gerar um "chunk" (pedaço) de ações futuras e executar um prefixo fixo desse chunk antes de disparar uma etapa de replanejamento. Os autores argumentam que esse horizonte de execução fixo é fundamentalmente incompatível com a dinâmica de execução.

Como ilustrado no artigo, a confiabilidade dos chunks de ação é dependente do estágio:

• Estágios fáceis: Os chunks permanecem precisos por muitos passos, tornando o replanejamento frequente computacionalmente dispendioso.
• Estágios difíceis: Os erros acumulam-se rapidamente após apenas alguns passos, tornando um horizonte fixo propenso a falhas se não replanejar cedo o suficiente.

Métodos de execução adaptativa existentes dependem de métricas de proxy, como entropia de ação, consistência de predição ou pesos de atenção. Os autores sustentam que estas são insuficientes porque não medem explicitamente o fator crítico para a execução: se a tarefa está realmente progredindo. Uma sequência pode ser suave (baixa entropia), mas não progredir, ou ter alta entropia, mas avançar a tarefa. Além disso, muitos métodos existentes (por exemplo, verificação via imaginação futura) introduzem custos computacionais proibitivos ou exigem aprendizado por reforço online, o que é impraticável para implantação.

Metodologia: TempoWAM

O artigo propõe o TempoWAM (Timing Execution by Monitoring Progress Online), um esquema de execução leve e plug-and-play que adapta o horizonte de execução com base na estimativa de progresso da tarefa, em vez de contagens de passos. Ele consiste em dois componentes primários:

1. Monitor de Progresso Recorrente (RPM)

O RPM é um módulo leve que estima o progresso da tarefa ($v_t \in [0, 1]$) que seria alcançado se as ações candidatas atuais fossem executadas. Ele recebe os seguintes inputs:

• Observação Atual ($o_t$): Codificada via o backbone visual congelado do WAM base.
• Prefixo de Ação Candidata ($c^{rem}_t$): As próximas $n_t$ ações do chunk restante, codificadas por um codificador recorrente.
• Histórico de Execução ($v_{t-1}$): A estimativa de progresso anterior, injetada via uma projeção aprendida para manter o contexto temporal.
• Instrução da Tarefa ($\ell$): Incorporada a partir do WAM base.

O módulo utiliza um núcleo GRU para agregar esses recursos e produzir uma estimativa de progresso. Ele é treinado em trajetórias de demonstração usando uma perda de entropia cruzada binária contra rótulos de progresso baseados em tempo ($y_u = u/T_{ep}$), aumentada com regularizações de suavidade e consistência histórica para garantir estabilidade e robustez ao ruído visual.

2. Protocolo de Execução Adaptativa (AEP)

O AEP decide se continua executando o atual chunk ou se descarta o restante e replaneja. Ele opera comparando a taxa de progresso observada ($\rho^{cur}_t$) contra uma taxa de progresso necessária ($\rho^{need}_t$).

• Taxa de Progresso: Em vez de progresso absoluto, o sistema avalia a taxa de avanço por passo.
• Calibração: Para preencher a lacuna entre a supervisão de treinamento e a realidade de implantação, o protocolo emprega um fator de calibração de duas escalas de tempo ($\kappa_{final}$):
  • Calibração Offline: Um fator específico da tarefa ($\kappa_{task}$) é derivado de episódios de demonstração via ajuste de mínimos quadrados.
  • Adaptação Online:
    • Intra-episódio: Uma Média Móvel Exponencial (EMA) atualiza o fator para rastrear o desvio dentro de um único episódio.
    • Inter-episódio: Um fator de escala ($\delta'$) ajusta-se com base na taxa de sucesso em relação a um alvo ($s^*$): se o sucesso estiver abaixo do alvo, o protocolo torna-se mais rigoroso (replaneja mais cedo); se acima, torna-se mais relaxado (replaneja menos) para melhorar a eficiência.

A regra de decisão é: se a razão calibrada $r_t \ge 1$, a execução continua; caso contrário, o chunk é descartado e o WAM é invocado para uma nova predição.

Principais Contribuições

1. Mudança de Critério: Os autores demonstram que avaliar apenas a racionalidade da ação é insuficiente para a execução adaptativa. Eles argumentam que o progresso da tarefa é o critério natural e necessário para decidir quando replanejar.
2. Arquitetura Plug-and-Play: O TempoWAM foi projetado para ser um acréscimo leve. Ele não requer modificação ou retreinamento do WAM base. Ele opera inteiramente na camada de execução, sendo compatível com várias arquiteturas de WAM (demonstrado em FastWAM e Motus).
3. Trade-off Eficiência-Sucesso: O método alcança um equilíbrio superior entre custo computacional (chamadas de inferência) e sucesso da tarefa ao estender dinamicamente o reuso de chunks em estágios fáceis e disparar o replanejamento precoce em estágios difíceis.

Resultados Experimentais

Os autores avaliaram o TempoWAM em benchmarks de simulação (LIBERO, RoboTwin 2.0) e tarefas robóticas no mundo real.

• RoboTwin 2.0:

  • Tarefas de curto horizonte: O TempoWAM preservou ou melhorou ligeiramente as taxas de sucesso enquanto reduziu as chamadas de inferência do WAM em comparação com horizontes fixos.
  • Tarefas de longo horizonte: Melhorou as taxas de sucesso em 1,54 pontos (limpo) e 0,87 pontos (randomizado) enquanto reduzia os passos executados, superando horizontes fixos de 12 ou 24 passos.
  • Comparação: Superou significativamente os baselines adaptativos como Auto-Horizon (baseado em atenção) e AAC (baseado em entropia), que ou falharam em melhorar o sucesso ou incorreram em custos computacionais excessivos.

• Benchmark LIBERO:

  • O TempoWAM reduziu as chamadas médias de WAM de 14,88 para 12,46 enquanto preservava as taxas de sucesso em todas as quatro suítes (Long, Spatial, Object, Goal).
  • Na suíte LIBERO-10, melhorou o sucesso de 95,00% para 95,60% reduzindo as chamadas.

• Robôs no Mundo Real:

  • Em três tarefas (pegar bebidas, pegar e colocar, embalar creme de mãos), o TempoWAM reduziu as chamadas em 26,9% na tarefa mais fácil ("take drinks") e melhorou o sucesso em 13,3 pontos percentuais em tarefas difíceis em geral (especificamente na tarefa "pack hand cream", que é a mais difícil entre as avaliadas).
  • Generalização de Cross-Backbone: Ao ser anexado ao Motus WAM sem retreinamento, o TempoWAM melhorou o sucesso em 59 pontos especificamente na tarefa "move_can_pot", confirmando sua natureza agnóstica à arquitetura.

• Sobrecarga Computacional:

  • O RPM adiciona uma sobrecarga negligível. Com codificação visual, consome 3,54% do tempo de uma chamada de inferência otimizada do WAM; com recursos compartilhados, isso cai para 0,34%.

Significância e Alegações

O artigo afirma que o TempoWAM aborda uma limitação crítica na implantação atual de WAMs: a rigidez dos horizontes de execução fixos. Ao fundamentar as decisões de execução na estimativa de progresso da tarefa, o sistema se adapta ao estado real do ambiente em vez de depender de proxies indiretos de incerteza ou contagens de passos predeterminadas.

Os autores enfatizam que sua abordagem é consciente do progresso e eficiente. Não requer imaginação futura cara ou treinamento de RL online. Em vez disso, aproveita um monitor recorrente leve e um protocolo calibrado para ajustar dinamicamente o horizonte de execução. Os resultados sugerem que, para WAMs, a decisão de replanejar deve ser impulsionada pelo fato de as ações restantes ainda estarem avançando a tarefa, uma capacidade que o TempoWAM fornece consistentemente através de domínios de simulação e do mundo real.

O artigo conclui que, embora os rótulos baseados em tempo sejam válidos para tarefas não repetitivas e de progresso monotônico (o que cobre seus benchmarks avaliados), trabalhos futuros são necessários para lidar com tarefas periódicas ou simétricas onde o mapeamento observação-rótulo não é um para um.