Resumen Técnico: Evaluación de Métodos de Explicabilidad en RL según su Capacidad para Corregir Errores en Agentes

Declaración del Problema

El campo de la Explicabilidad en el Aprendizaje por Refuerzo (XRL, por sus siglas en inglés) carece actualmente de un estándar de evaluación unificado y fundamentado en aplicaciones. Los paradigmas existentes se basan en:

1. Métricas funcionalmente fundamentadas: Tales como la fidelidad (faithfulness) y la compacidad (compactness).
2. Proxies basados en humanos: Tales como las calificaciones subjetivas de confianza o la precisión de la predicción.

Estos enfoques interpretan el "entendimiento" de formas distintas (por ejemplo, como la capacidad de predecir salidas o de crear modelos más simples), pero no miden directamente si una explicación ayuda a un desarrollador a resolver un agente con fallos. Además, el panorama de la XRL presenta una "explosión de Cambriano" de salidas heterogéneas (mapas de saliencia, resaltados de video, árboles de decisión, descomposiciones de recompensa), lo que dificulta la comparación entre métodos. Existe una brecha específica en la evaluación de los métodos de XRL basada en su utilidad para la depuración (debugging) —el proceso de diagnosticar y reparar agentes defectuosos—, que es un caso de uso primario para los ingenieros de ML, pero que rara vez se mide como una tarea derivada en los benchmarks.

Metodología: El Marco de Trabajo EvalXRL

El artículo propone EvalXRL, un benchmark diseñado para evaluar los métodos de XRL basándose en su capacidad para asistir a un "programador" en la reparación de un agente de RL deliberadamente defectuoso. El marco se define por tres elecciones de diseño fundamentales:

1. Sustrato de Evaluación: Agentes Deliberadamente Defectuosos

El benchmark utiliza un conjunto de agentes de RL con fallos conocidos y controlados, inyectados mediante diffs unificados en el código de entrenamiento o en los entornos. Estos fallos están diseñados para requerir un razonamiento sobre las consecuencias conductuales en lugar de una simple inspección de código. Los ejemplos incluyen:

• Hackeo de recompensa (Reward hacking): Incentivar el permanecer suspendido cerca de tesoros pequeños en lugar de atravesar la cuadrícula.
• Desplazamiento de distribución (Distributional shift): Agentes entrenados en clima de verano desplegados en invierno.
• Deriva de sensores (Sensor drift): Sensores de temperatura que leen 5°C por encima de lo real.
• Miopía (Myopia): Factores de descuento configurados demasiado bajos (0.3 frente a 0.99).

2. El Desarrollador: Agentes de Codificación LLM

En lugar de sujetos humanos, el "desarrollador" es un agente de codificación basado en un Modelo de Lenguaje Grande (LLM) de frontera (por ejemplo, Claude Opus) operando dentro de un entorno Docker aislado (sandboxed).

• Racional: Este enfoque es órdenes de magnitud más barato y rápido que los estudios con humanos y evita procesos éticos complejos. Se alinea con la tendencia del "vibe coding", donde los LLM realizan cada vez más tareas de ingeniería.
• Capacidades: El agente puede leer el código fuente, ejecutar experimentos, modificar parámetros, reentrenar agentes y enviar correcciones.
• Interacción de Bucle Cerrado (Closed-Loop): A diferencia de las evaluaciones de un solo paso (one-shot), el agente opera en un bucle cerrado. Puede invocar un método de XRL, procesar la salida, formar nuevas hipótesis, ajustar parámetros e invocar el método nuevamente. Esto imita el método científico y los procesos de explicación dialógica.

3. Mecanismo de Puntuación: Rendimiento de la Reparación

La métrica principal es la Puntuación de Reparación (Repair Score), un valor continuo en $[0, 1]$ que representa el rendimiento de la tarea del agente después de la reparación.
$$\text{Score} = \text{clip}_{[0,1]} \left( \frac{P_{\text{post}} - P_{\text{broken}}}{P_{\text{clean}} - P_{\text{broken}}} \right)$$
Donde:

• $P_{\text{post}}$: Rendimiento del agente reparado.
• $P_{\text{broken}}$: Rendimiento del agente con fallos sin reparar.
• $P_{\text{clean}}$: Rendimiento del agente sin fallos.

El benchmark compara los métodos de XRL contra dos controles:

• Línea Base Sin Método (No-Method Baseline): El programador debe depurar usando únicamente el código fuente e información del entorno (límite inferior).
• Referencia Oráculo (Oracle Reference): El programador recibe una descripción en lenguaje natural del fallo (límite superior).

El marco itera a través de tuplas de $(\text{entorno} \times \text{fallo} \times \text{método XRL})$.

Contribuciones Clave

1. Un Nuevo Paradigma de Evaluación: Desplaza la definición de "entendimiento" en XRL hacia "la capacidad de arreglar un mecanismo roto". Esta visión funcional es medible y está directamente vinculada a la utilidad derivada.
2. El Diseño del Benchmark EvalXRL: Un protocolo estructurado para una comparación planificada frente a frente de métodos de XRL heterogéneos (por ejemplo, Descomposición de Recompensa, Análisis Contrafáctico, Mapas de Saliencia, Árboles de Decisión) en un entorno de depuración de bucle cerrado.
3. Uso de Bucle Cerrado: Propone la primera comparación sistemática de métodos de XRL donde el usuario (LLM) puede interactuar y ajustar parámetros de forma interactiva, en lugar de depender de explicaciones estáticas de un solo paso. Nota: Este artículo describe el diseño para esta comparación; la evaluación real frente a frente es el objeto de un estudio de seguimiento planificado.
4. Formulación de Hipótesis: El documento esboza tres hipótesis específicas que se probarán en futuras ejecuciones piloto:
   • H1 (Estructura de Interacción): Los métodos de XRL no se clasificarán de forma lineal; en su lugar, métodos específicos se agruparán como efectivos para tipos específicos de fallos.
   • H2 (Techo del Oráculo): Una "referencia oráculo" (descripción humana del error) establecerá un límite alto pero imperfecto, cuantificando la brecha entre el diagnóstico y la ingeniería.
   • H3 (Los Métodos Pueden Perjudicar): Al menos un método de XRL funcionará significativamente peor que la línea base sin método para ciertos fallos, demostando que las explicaciones bien formadas pero no causales pueden desviar el proceso de depuración.

Resultados

Este artículo no reporta resultados experimentales. Es una propuesta preliminar que describe el diseño del benchmark, las hipótesis y las preguntas abiertas. Los autores afirman que la ejecución piloto para probar las hipótesis H1–H3 es el "siguiente paso inmediato" y será la contribución de un artículo de seguimiento.

Significación y Reivindicaciones

Los autores posicionan a EvalXRL como una evolución necesaria en la evaluación de XRL:

• Utilidad Directa: Al conectar directamente la señal de recompensa del agente de RL con la evaluación, este benchmark elimina el sesgo impulsado por proxies presentes en las calificaciones subjetivas o la precisión de la predicción.
• Escalabilidad: El uso de agentes LLM permite pruebas a gran escala y reproducibles que actualmente son inviables con sujetos humanos.
• Aporte de la Comunidad: Como propuesta en fase de taller (workshop), los autores buscan comentarios sobre la taxonomía de fallos, la validez del sustituto LLM y qué métodos de XRL deberían priorizarse para el lanzamiento inicial.
• Aplicabilidad Futura: Los autores señalan que la estructura del marco (programador, dossier, puntuación de reparación, soporte de dos contenedores) es transferible para evaluar métodos de interpretabilidad mecánica para los propios Modelos de Lenguaje Grande (LLM).

El artículo enfatiza la modestia, reconociendo limitaciones tales como la "brecha de validez LLM-humano" (los LLM pueden interpretar el texto de forma distinta a como los humanos interpretan las visualizaciones) y el riesgo de "memorización", donde los LLM podrían recordar patrones de errores de sus datos de entrenamiento. Estas se presentan como preguntas de diseño abiertas para que la comunidad las aborde.