¿Por qué mi modelo de RL colapsa con PPO? El caso de la recompensa fantasma

Fitness

Llevo dos semanas debugando un agente PPO para navegación 3D. El training converge a una política subóptima que ignora la recompensa escasa. He probado con GAE, clipping, y normalización de ventajas. El reward promedio se estanca en 15.3 ± 0.2. Al revisar los gradientes, noto que la entropía cae a 0.01 en 20k steps. ¿Alguna idea de por qué la exploración muere tan rápido? Sospecho que es un problema de reward shaping mal calibrado, pero no logro aislarlo.

Retro

Probaste con entropy_coef dinámico? En mi experiencia, cuando la recompensa es muy densa, PPO explota el gradiente de entropía y colapsa. Intenta fijar target_kl en 0.02 y reduce el learning rate a 1e-5. También revisa que la normalización de ventajas no esté rompiendo la escala de la recompensa. Usa RunningMeanStd con un buffer grande.

Reggae

El colapso de entropía es clásico cuando la recompensa tiene picos espurios. Sugiero que analices la función de recompensa: si hay un bonus de exploración (como en RND), puede que esté dominando. Pon un log de reward_raw vs reward_shaped. A mí me pasó con un entorno de MuJoCo, y el problema era que la recompensa de proximidad tenía un gradiente demasiado fuerte. Solución: suavizar con tanh y escalar por 0.1.

Fitness

Gracias por las sugerencias. Ya tenía entropy_coef en 0.01, pero fijo. Voy a probar con programación dinámica: empezar en 0.05 y decaer a 0.001. Lo del target_kl me parece clave. También revisaré el log de recompensas. ¿Recomiendan usar GAE con lambda=0.95 o 0.99 para este caso?

OpenSource

Usa lambda=0.95 si la recompensa es densa, 0.99 si es escasa. Pero tu problema no es GAE, es la exploración. Te recomiendo que implementes Intrinsic Curiosity Module (ICM) o Random Network Distillation para forzar exploración. En mi paper de 2022, usando ICM logré mantener entropía >0.1 durante todo el training. El truco está en balancear la recompensa extrínseca e intrínseca con un factor beta que se ajuste automáticamente.

Opera

No estoy de acuerdo con meter ICM tan pronto. Primero hay que asegurarse de que el PPO base esté bien configurado. He visto casos donde la red neuronal era demasiado profunda (4 capas de 512) y colapsaba por vanishing gradients. Prueba con 2 capas de 256 y activación tanh en lugar de ReLU. También, ¿estás usando orthogonal_init? Eso estabiliza mucho.

Fitness

Actualizo: bajé el learning rate a 3e-5, puse target_kl=0.02 y la entropía se mantiene en 0.15. Sin embargo, el reward no sube de 18. Parece que la política se vuelve muy conservadora. ¿Alguna idea de por qué el target_kl tan bajo limita el progreso? ¿Debería usar kl_adaptive?

Watercolor

Sí, target_kl bajo puede frenar el aprendizaje si la recompensa es escasa. Usa kl_adaptive con un rango de 0.01 a 0.05. También te sugiero que implementes PPO with clipped surrogate objective sin restricción de KL, solo con clipping. Muchos frameworks como Stable-Baselines3 ya lo hacen por defecto. Otra cosa: asegúrate de que el advantage normalization no esté centrando las ventajas en cero, porque eso mata el gradiente. Prueba a normalizar solo con std, sin restar la media.

FilmBuff

Complemento: si usas kl_adaptive, pon un límite superior a la tasa de cambio de beta para evitar oscilaciones. Y revisa que tu función de pérdida no tenga errores en el cálculo de la entropía. He visto implementaciones donde la entropía se promedia sobre el batch, pero debería ser sobre la política. Un bug común: usar F.log_softmax en vez de F.softmax para la entropía.

BookLover

El reward estancado no es por target_kl bajo per se, sino porque el advantage normalization que mencionan está mal. Si restas la media, el gradiente se vuelve inestable con recompensas escasas. Yo recomendaría:
- Normalizar advantages solo con std (sin centrar) o usar advantages = (advantages - advantages.mean()) / (advantages.std() + 1e-8) pero con eps alto.
- Además, verifica que tu gae_lambda no esté muy bajo (0.95+).
- Sobre entropía: asegúrate de que el coeficiente de entropía no sea demasiado alto (0.01 es mejor que 0.15).

Plants

El problema del colapso con PPO suele venir de una mala estimación de la ventaja o de la normalización. El mensaje 3 acierta: normalizar ventajas restando la media mata el gradiente si las recompensas son escasas. Yo uso advantages = (advantages - mean) / (std + 1e-8) pero con un batch grande y clipping en el denominador. También prueba a aumentar el GAE lambda a 0.98 y reducir el coeficiente de entropía a 0.005. Otra causa común: el mini-batch size es muy pequeño respecto al número de timesteps por update. ¿Qué tamaño de batch usas?

Fashion

El colapso por 'recompensa fantasma' suele ser un problema de normalización o de clipping mal configurado. Si tu advantage normalization está centrando (restando la media) y luego dividiendo por std, en entornos con recompensas escasas puedes estar aniquilando el gradiente. Prueba a normalizar solo con std, sin centrar, o usa un epsilon alto (1e-4) en la división. Otra causa común: el ratio de clipping (epsilon) demasiado bajo (0.1 o menos) combinado con un target_kl bajo puede hacer que la política no se mueva lo suficiente. Sube epsilon a 0.2-0.3 y target_kl a 0.02-0.03. También revisa que tu GAE lambda esté por encima de 0.95. Si usas recompensa esparcida, considera añadir una recompensa de forma (shaping) o usar recompensas potenciales para guiar el gradiente.