Resumo Técnico: Onto-EV-WM para Diagnóstico de Falhas e Reparo de Ciclo Fechado

1. Definição do Problema

Sistemas de IA física que utilizam modelos de mundo (ex: EV-WM) preveem futuros candidatos e os pontuam com base em vetores de características ou eventos. No entanto, essas pontuações escalares ou vetores de eventos frequentemente carecem de informação semântica explícita sobre o porquê de um candidato falhar. Especificamente, eles não registram:

• Qual predicado de tarefa específico permanece não satisfeito (ex: uma relação espacial ou restrição de junta).
• Os argumentos tipados associados à falha.
• Um rótulo de rota indicando qual mecanismo de correção deve ser aplicado.
• Um resultado de aceitação pós-correção baseado em predicados de tarefa nativos.

Consequentemente, embora o sistema possa identificar um candidato de baixa pontuação, ele carece de uma interface estruturada para diagnosticar a condição não atendida específica, atribuir uma estratégia de correção compatível e verificar o resultado usando um protocolo de ciclo fechado. O artigo aborda a lacuna entre a predição de alta dimensão e a verificação simbólica de tarefas, visando fornecer uma interface explícita para diagnóstico e reparo sem substituir o modelo de mundo subjacente ou o controlador visuomotor.

2. Metodologia: Onto-EV-WM

Os autores propõem o Onto-EV-WM, uma interface de diagnóstico e correção com portão de verificação fundamentada em ontologia, posicionada em uma camada acima da arquitetura EV-WM existente. Não é um modelo de mundo substituto, mas uma camada simbólica que gerencia o fluxo da predição para a correção.

2.1 Arquitetura e Componentes

O sistema opera através de um pipeline estruturado envolvendo três componentes principais:

1. Camada de Registro Ontológico (TBox e ABox):
   • TBox (Task Box): Define um esquema local da tarefa incluindo tipos de entidades (ex: Objeto, Região, Junta), assinaturas de predicados (ex: in_region, contact) e restrições de tipo. Serve como um vocabulário reutilizável para a tarefa específica.
   • ABox (Assertion Box): Instancia o estado atual. O sistema constrói três ABoxes específicos de proveniência:
     • $A^\star_g$: As asserções requeridas compiladas a partir da especificação estruturada da tarefa ($g$).
     • $\hat{A}^{pred}_{g,t+H}$: Asserções fundamentadas a partir das saídas preditas do modelo de mundo.
     • $A^{sim}_{g,t}$: Asserções fundamentadas diretamente do estado do simulador.
2. Diagnóstico e Roteamento Determinísticos:
   • Diagnóstico ($\Pi_D$): Compara a ABox requerida ($A^\star_g$) contra a ABox observada/predita. Identifica asserções não satisfeitas ($\Delta F_{src}$), preservando o predicado específico, seus argumentos tipados e quaisquer violações de margem contínua. Isso gera um registro de falha tipado (ex: relation_missing(plate, stove_front)).
   • Roteamento ($\Pi_R$): Uma base de regras determinísticas mapeia a falha tipada para um "rótulo de rota" específico. Uma rota é um rótulo de despacho para um mecanismo de correção compatível (ex: "pose de junta de origem", "predicado de relação de objeto"), não uma ação direta do robô.
3. Ciclo de Correção com Portão de Verificação:
   • Geração de Proposta: Um proponente (aprendido, heurístico ou baseado em planejamento) gera uma correção $q$ baseada no registro de falha e na rota selecionada.
   • Aplicação: A correção é aplicada via mutação direta do estado do simulador (ex: modificando $qpos$) ou execução mediada pelo controlador.
   • Verificação: Um verificador de tarefa nativo checa o estado resultante contra o predicado da tarefa.
   • Tentativa Limitada (Bounded Retry): Se a verificação falhar, o sistema incrementa um orçamento de tentativas ($b$), regrounda o estado e pode tentar novamente a mesma rota ou reroteamento. O loop termina no sucesso ou exaustão do orçamento.

2.2 Fluxo Operacional

A interface separa predição, fundamentação, diagnóstico, aplicação e verificação.

• Entrada: Especificação da tarefa, tag de origem (predição ou simulação) e estado.
• Processo: Fundamentar o estado em uma ABox $\rightarrow$ Diagnosticar predicados ausentes $\rightarrow$ Atribuir uma rota $\rightarrow$ Gerar correção $\rightarrow$ Aplicar $\rightarrow$ Verificar.
• Saída: Um estado aceito, um candidato de planejamento retido ou um traço de falha tipada não resolvido.

3. Principais Contribuições

O artigo apresenta três contribuições técnicas primárias:

1. Ontologia de Tarefa Robótica Operacional: Um design para uma interface de fundamentação explícita que representa estados preditos e observados pelo simulador como ABoxes distintos e específicos da tarefa sob um vocabulário e restrições de tipo compartilhados.
2. Diagnóstico e Roteamento Determinísticos: Um sistema baseado em regras que preserva os predicados violados e seus argumentos tipados, mapeando-os para rotas de correção específicas da tarefa sem descartar o contexto original.
3. Contrato de Correção com Portão de Verificação: Um protocolo que registra todo o ciclo de vida de uma tentativa de correção (diagnóstico, seleção de rota, proposta, modo de aplicação e aceitação de predicado nativo) e impõe um mecanismo de tentativa limitada.

4. Resultados Experimentais

Os autores avaliam o Onto-EV-WM em três cenários distintos de benchmark utilizando protocolos de simulação.

4.1 PointMaze (Comparação Alinhada)

• Configuração: Comparação de planejamento de estado aleatório de 50 tentativas entre EV-WM e Onto-EV-WM.
• Resultados: Ambos os métodos alcançaram uma taxa de sucesso de 94%. No entanto, o Onto-EV-WM alcançou uma distância média de estado final significativamente menor (0.61177) em comparação ao EV-WM (0.90573), indicando maior precisão ao satisfazer as condições da tarefa.
• Nota: Uma configuração separada com um orçamento de busca maior e seleção prioritária ao sucesso atingiu 100% de sucesso, mas isso não é diretamente comparável ao cenário alinhado devido às diferenças de orçamento.

4.2 LIBERO-Goal (Correção de Janela Amostrada)

• Configuração: Avaliação em 10 tarefas de manipulação usando 4 sementes de amostragem de avaliação. O protocolo amostra janelas de demonstração de 25 passos. As correções são aplicadas via um mecanismo fixo aprendido de delta de $qpos$ de fonte/junta diretamente ao estado do simulador.
• Resultados:
  • Semente 0: 93,8% de sucesso na janela corrigida (469/500).
  • Através de 4 Sementes: 94,05 ± 0,30% de sucesso corrigido.
  • Recuperação: Dos 261 falhas de replay, 142 foram "resgatadas" (54,4%) pelo mecanismo de correção.
• Contexto: A ontologia fornece o registro de diagnóstico ligando a falha ao cabeçalho de correção fixo; a métrica reportada reflete a configuração completa fundamentada pela ontologia.

4.3 LIBERO-Plus (Registro Fixo)

• Configuração: Avaliação em um registro fixo de 10.030 tarefas de perturbação através de quatro suítes (LIBERO-10, Goal, Object, Spatial).
• Resultados:
  • Sucesso Geral: 85,00% (8.526/10.030 tarefas).
  • Detalhamento por Suíte:
    • LIBERO-Goal: 91,39%
    • LIBERO-Object: 91,38%
    • LIBERO-Spatial: 91,38%
    • LIBERO-10: 65,98% (identificada como a suíte com o maior número de falhas residuais).
• Comparação: A configuração Onto-EV-WM supera vários baselines, incluindo DINO-WM + CEM (61,57%) e vários modelos VLA, embora a comparação seja de nível de sistema e não isole a contribuição causal da ontologia isoladamente.

5. Significância e Alegações

O artigo posiciona o Onto-EV-WM como uma interface de nível de sistema que melhora sistemas de IA física ao adicionar raciocínio tipado explícito ao processo de diagnóstico e reparo de falhas.

• Escopo Modesto: Os autores declaram explicitamente que os resultados não constituem:
  • Recuperação em robô real ou validação sim-to-real.
  • Um grafo de conhecimento de mundo aberto geral ou uma ontologia robótica universal.
  • Uma partilha causal apenas da ontologia (os ganhos de desempenho são atribuídos à configuração completa).
  • Uma nova classe de política aprendida substituindo controladores existentes.
• Valor Central: A significância reside na capacidade de registrar por que uma tarefa falhou (predicados tipados e argumentos) e em estruturar o processo de reparo (rotas e verificação) de forma a ser desacoplado do modelo de predição subjacente. Isso permite o reparo de "ciclo fechado" dentro de protocolos de simulação onde a verificação serve como portão para a aceitação de correções.
• Limitações: A avaliação depende de protocolos baseados em simulação. O "ciclo fechado" refere-se a um ciclo limitado de verificar-tentar novamente dentro do simulador, não ao controle de feedback em tempo real em hardware físico. Os resultados quantitativos refletem o desempenho do sistema integrado sob protocolos específicos, em vez da eficácia isolada da ontologia.