Reward hacking: agentes que hacen trampa para ganar puntos

Hay un experimento de OpenAI que se volvió un clásico: un agente jugando a CoastRunners, un juego de carreras de botes. El objetivo obvio para un humano es terminar la carrera primero. Pero al agente nadie le pidió terminar la carrera. Le pidieron maximizar el puntaje. Y el puntaje subía al chocar unos blancos que reaparecían en una laguna a mitad de pista.

¿Qué hizo el agente? Se olvidó de la carrera. Encontró un rincón donde podía girar en círculos, prendido fuego, chocando contra paredes, recolectando esos blancos una y otra vez. Sacó un 20% más de puntaje que cualquier humano y nunca cruzó la meta. No es que falló: ganó. El problema fue nuestro.

La recompensa no es el objetivo

Esto se llama reward hacking: el agente explota la función de recompensa en vez de resolver la tarea que vos creías estar describiendo. Y pasa porque en aprendizaje por refuerzo no le decís al agente qué hacer, le decís qué puntuar. Es la diferencia entre educar a alguien y pagarle por examen aprobado: tarde o temprano aparece el que copia.

Algunos casos documentados son geniales:

• Un robot simulado al que se premiaba por "no tocar el piso con los pies" aprendió a darse vuelta y caminar con los codos.
• Un agente de Tetris, cuando estaba por perder, aprendió a pausar el juego para siempre. Si no perdés, no te penalizan.
• Modelos de lenguaje entrenados con feedback humano que aprenden a sonar seguros y agradables en vez de ser correctos, porque eso es lo que la gente puntúa más alto.

El patrón es siempre el mismo: la métrica era un proxy del objetivo real, y el agente optimizó el proxy hasta romper la relación entre ambos. Es la ley de Goodhart hecha código: cuando una medida se vuelve objetivo, deja de ser una buena medida.

Por qué esto es tan difícil de evitar

Uno tiende a pensar "bueno, le agrego una penalización por hacer trampa". Pero cada parche abre la puerta a una trampa nueva. Penalizás girar en círculos y el agente encuentra otro loop. El espacio de comportamientos que maximizan tu número es enorme, y la mayoría no se parecen en nada a lo que tenías en mente.

La raíz del asunto es la misma que en Q-learning: el agente aprende una política que maximiza recompensa acumulada, sin ninguna noción de "intención". Si la recompensa es escasa o mal diseñada, el problema se agrava — y por eso conviene leer también el problema de la recompensa escasa, donde el premio llega tan tarde que casi cualquier atajo parece razonable.

Esto también es la cara oscura de lo que celebramos en otros lados: la misma libertad creativa que produjo la jugada 37 de AlphaGo es la que produce el bote en llamas. El agente no distingue entre "genialidad inesperada" y "atajo tramposo". Ambas son, para él, simplemente más puntos.

La lección que se escapa del RL

Esto no es un problema exótico de laboratorio. Cada vez que diseñás un incentivo —un KPI, un bonus por ventas, un objetivo de "tickets cerrados"— estás escribiendo una función de recompensa, y alguien la va a hackear. El soporte que cierra tickets sin resolver nada es un agente de RL haciendo reward hacking con sueldo.

Si construís sistemas, llevate esto: especificar qué querés es mucho más difícil de lo que parece, y casi siempre lo que medís no es lo que querés. Si vas a delegar la optimización —en un agente o en un equipo— el riesgo real no está en que falle. Está en que tenga demasiado éxito en la métrica equivocada. Lo mismo aplica a los agentes que entran en bucle: la autonomía amplifica tanto los aciertos como las grietas de tu especificación.