Resumo Técnico: Avaliando Métodos de Explicabilidade de RL pela Capacidade de Corrigir Bugs em Agentes

Declaração do Problema

O campo da Aprendizagem por Reforço Explicável (XRL - Explainable Reinforcement Learning) carece atualmente de um padrão de avaliação unificado e fundamentado em aplicações. Os paradigmas existentes baseiam-se em:

1. Métricas funcionalmente fundamentadas: Como fidelidade (faithfulness) e compacidade (compactness).
2. Proxies baseados em humanos: Como classificações subjetivas de confiança ou precisão de predição.

Essas abordagens interpretam o "entendimento" de formas distintas (por exemplo, como a capacidade de prever saídas ou criar modelos mais simples), mas não medem diretamente se uma explicação ajuda um desenvolvedor a resolver um agente com mau funcionamento. Além disso, o cenário de XRL apresenta uma "explosão cambriana" de saídas heterogêneas (mapas de saliência, destaques de vídeo, árvores de decisão, decomposição de recompensa), tornando a comparação entre métodos difícil. Existe uma lacuna específica na avaliação de métodos XRL baseada em sua utilidade para o depuração (debugging) — o processo de diagnosticar e consertar agentes quebrados — que é um caso de uso primário para engenheiros de ML, mas raramente medido como uma tarefa de consequência direta em benchmarks.

Metodologia: O Framework EvalXRL

O artigo propõe o EvalXRL, um benchmark projetado para avaliar métodos de XRL com base em sua capacidade de auxiliar um "programador" a reparar um agente de RL deliberadamente quebrado. O framework é definido por três escolhas de design centrais:

1. Substrato de Avaliação: Agentes Deliberadamente Quebrados

O benchmark utiliza um conjunto de agentes de RL com mau funcionamentos conhecidos e controlados, injetados via diffs unificados no código de treinamento ou nos ambientes. Esses mau funcionamentos são projetados para exigir raciocínio sobre consequências comportamentais, em vez de uma simples inspeção de código. Exemplos incluem:

• Exploração de recompensa (Reward hacking): Incentivar o agente a pairar perto de pequenos tesouros em vez de atravessar a grade.
• Mudança de distribuição (Distributional shift): Agentes treinados em clima de verão implantados no inverno.
• Deriva de sensor (Sensor drift): Sensores de temperatura lendo 5°C a mais.
• Miopia (Myopia): Fatores de desconto configurados muito baixos (0.3 vs 0.99).

2. O Desenvolvedor: Agentes de Codificação de LLM

Em vez de sujeitos humanos, o "desenvolvedor" é um agente de codificação baseado em um modelo de linguagem de grande escala (LLM) de fronteira (ex: Claude Opus) operando dentro de um ambiente Docker isolado (sandbox).

• Racional: Esta abordagem é ordens de magnitude mais barata e rápida do que estudos com humanos e evita aprovações éticas complexas. Alinha-se à tendência de "vibe coding", onde LLMs realizam tarefas de engenharia cada vez mais.
• Capacidades: O agente pode ler o código fonte, executar experimentos, modificar parâmetros, treinar agentes novamente e enviar correções.
• Interação de Ciclo Fechado: Ao contrário das avaliações de etapa única (one-shot), o agente opera em um ciclo fechado. Ele pode invocar um método de XRL, processar a saída, formar novas hipóteses, ajustar parâmetros e invocar o método novamente. Isso mimetiza o método científico e os processos de explicação dialógica.

3. Mecanismo de Pontuação: Desempenho de Reparo

A métrica primária é o Score de Reparo, um valor contínuo em $[0, 1]$ representando o desempenho normalizado da tarefa do agente após o reparo.
$$\text{Score} = \text{clip}_{[0,1]} \left( \frac{P_{\text{pós}} - P_{\text{quebrado}}}{P_{\text{limpo}} - P_{\text{quebrado}}} \right)$$
Onde:

• $P_{\text{pós}}$: Desempenho do agente reparado.
• $P_{\text{quebrado}}$: Desempenho do agente com mau funcionamento não reparado.
• $P_{\text{limpo}}$: Desempenho do agente sem o mau funcionamento.

O benchmark compara métodos XRL contra dois controles:

• Baseline Sem Método: O programador deve depurar usando apenas o código fonte e informações do ambiente (limite inferior).
• Referência Oráculo: O programador recebe uma descrição em linguagem natural do erro (limite superior).

O framework itera através de tuplas $(\text{ambiente} \times \text{mau funcionamento} \times \text{método XRL})$.

Principais Contribuições

1. Um Novo Paradigma de Avaliação: Muda a definição de "entendimento" em XRL para "a capacidade de consertar um mecanismo quebrado". Esta visão funcional é mensurável e está diretamente ligada à utilidade prática.
2. O Design do Benchmark EvalXRL: Um protocolo estruturado para uma comparação planejada frente a frente de métodos XRL heterogêneos (ex: Decomposição de Recompensa, Análise Contrafactual, Mapas de Saliência, Árvores de Decisão) em um cenário de depuração de ciclo fechado.
3. Uso de Ciclo Fechado: Propõe a primeira comparação sistemática de métodos XRL onde o usuário (LLM) pode interagir e ajustar parâmetros, em vez de depender de explicações estáticas de etapa única. Nota: Este artigo descreve o design para esta comparação; a avaliação real frente a frente é o objeto de um estudo planejado de acompanhamento.
4. Formulação de Hipóteses: O artigo delineia três hipóteses específicas a serem testadas em futuras execuções piloto:
   • H1 (Estrutura de Interação): Os métodos XRL não serão classificados linearmente; em vez disso, métodos específicos se agruparão como eficazes para tipos específicos de mau funcionamento.
   • H2 (Teto do Oráculo): Uma "referência oráculo" (descrição humana do erro) estabelecerá um limite alto, porém imperfeito, quantificando a lacuna entre diagnóstico e engenharia.
   • H3 (Métodos Podem Prejudicar): Pelo menos um método XRL terá um desempenho significativamente pior do que o baseline sem método para certos mau funcionamentos, demonstrando que explicações bem formadas, mas não causais, podem desviar o processo de depuração.

Resultados

Este artigo não relata resultados experimentais. É uma proposta preliminar que delineia o design do benchmark, as hipóteses e as questões em aberto. Os autores afirmam que a execução piloto para testar as hipóteses H1–H3 é o "próximo passo imediato" e será a contribuição de um artigo de acompanhamento.

Significância e Alegações

Os autores posicionam o EvalXRL como uma evolução necessária na avaliação de XRL:

• Utilidade Direta: Ao conectar o sinal de recompensa do agente de RL diretamente à avaliação, o benchmark remove o viés de proxies encontrado em classificações subjetivas ou precisão de predição.
• Escalabilidade: O uso de agentes de LLM permite testes de larga escala e reprodutíveis que são atualmente inviáveis com sujeitos humanos.
• Contribuição da Comunidade: Como uma proposta de estágio de workshop, os autores buscam feedback sobre a taxonomia de mau funcionamento, a validade do substituto de LLM e quais métodos XRL devem ser priorizados para o lançamento inicial.
• Aplicabilidade Futura: Os autores observam que a estrutura do framework (programador, dossiê, score de reparo, suporte de dois containers) é transferível para avaliar métodos de interpretabilidade mecanística para os próprios modelos de linguagem (LLMs).

O artigo enfatiza a modéstia, reconhecendo limitações como a "lacuna de validade LLM-vs-humano" (LLMs podem interpretar texto de forma diferente de como humanos interpretam visualizações) e o risco de "memorização", onde LLMs podem recordar padrões de erros de seus dados de treinamento. Estas são apresentadas como questões de design abertas para a comunidade abordar.