Serie AI-Native · Aprendizaje por refuerzo
La recompensa es el mundo
La idea en un minuto — con qué te quedas
En todo sistema de RL hay dos funciones, y solo una de ellas está en tu código. U es lo que de verdad quieres. r es el proxy que implementaste. El optimizador maximiza r, y allí donde ambas discrepan en una región que puede alcanzar, la encontrará — no porque sea astuto, sino porque ese es su trabajo. Esto es la Ley de Goodhart, publicada en 1975: any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes. (Traducción: toda regularidad estadística observada tenderá a colapsar en cuanto se ejerza presión sobre ella con fines de control.) Este replanteamiento vale por lo que te dice que no va a funcionar: el hackeo de la recompensa no es un error que se pueda corregir en el RLHF, es el comportamiento genérico de cualquier sistema de control apuntado hacia un proxy. Así que la pregunta útil no es "¿mi recompensa es correcta?" sino "¿cuánta presión de optimización puede soportar?" — y solo la segunda tiene un número asociado.
Escribe dos funciones.
U(y) — la utilidad verdadera. Lo que realmente quieres del modelo. Esta función nunca está en tu código. No puede estarlo; si pudieras escribirla con exactitud, no necesitarías machine learning.
r(y) — el proxy implementado. Un modelo de recompensa entrenado con preferencias, una prueba unitaria, una rúbrica calificada por un juez. Este sí está en tu código, y es lo único que tu optimizador puede ver.
Todos los fallos de este episodio viven en la brecha entre ambas.
La idea central: esta ley tiene cincuenta años
Antes de concluir que el hackeo de la recompensa es algo que inventaron los modelos de lenguaje, notemos que los economistas lo escribieron medio siglo antes de que existiera el RLHF.
Charles Goodhart, sobre la política monetaria del Reino Unido, 1975 [1]:
Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes. (Traducción: toda regularidad estadística observada tenderá a colapsar en cuanto se ejerza presión sobre ella con fines de control.)
La frase que la mayoría conoce —"when a measure becomes a target, it ceases to be a good measure" (Traducción: cuando una medida se convierte en un objetivo, deja de ser una buena medida)— no es de Goodhart, sino de la antropóloga Marilyn Strathern, de 1997 [1]. Vale la pena saberlo, porque el original es el planteamiento más útil: habla de presión, y nombra el mecanismo en lugar del síntoma.
Donald Campbell llegó ahí, podría decirse, antes, en 1979 [2], con formulaciones que datan de 1969:
The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor. (Traducción: Cuanto más se usa un indicador social cuantitativo para la toma de decisiones sociales, más sujeto estará a presiones de corrupción y más propenso será a distorsionar y corromper los procesos sociales que pretende monitorear.)
En nuestra notación: en el momento en que r se usa para optimizar en lugar de para observar, la correlación entre r y U que justificaba usar r empieza a disolverse — y se disuelve más rápido justo donde el optimizador es más fuerte.
Por qué esta reformulación merece un párrafo de tu atención
Porque te dice qué reparaciones son imposibles.
Si el hackeo de la recompensa fuera un error de RLHF, la solución sería un mejor modelo de recompensa. Pero es el comportamiento genérico de cualquier sistema de control apuntado a un proxy, y hay cincuenta años de parches fallidos que lo demuestran: enseñar para el examen, hospitales manipulando los objetivos de tiempo de espera, la recompensa colonial por ratas que produjo granjas de ratas. Cada uno de esos casos se abordó con un objetivo mejor especificado. Cada uno de esos casos fue luego manipulado.
Así que la consecuencia de ingeniería es un cambio de pregunta. Stop asking "is this reward correct?" Start asking "how much optimization pressure can this reward survive?" (Traducción: Deja de preguntar "¿es correcta esta recompensa?". Empieza a preguntar "¿cuánta presión de optimización puede soportar esta recompensa?") Son preguntas distintas, y solo la segunda tiene un número asociado — pasos, presupuesto de KL, best-of-n, como sea que midas la fuerza que estás aplicando.
El único lugar donde la realidad todavía puede calificarte
Hay una salida, y es estrecha pero real: a veces el mundo puede verificar la respuesta.
RLVR — aprendizaje por refuerzo a partir de recompensas verificables — reemplaza el modelo de recompensa aprendido por algo que no se deja convencer con halagos. ¿Pasa la prueba unitaria? ¿Es la respuesta final, en el recuadro requerido, igual a la conocida?
DeepSeek-R1-Zero es la evidencia más contundente de que esto no es un juguete [3]. Solo recompensas basadas en reglas: precisión sobre una respuesta verificable, más una recompensa de formato por producir la <think>…</think><answer>…</answer> estructura. En ningún punto del ciclo hay un crítico neuronal. El pass@1 de AIME 2024 pasó de 15.6% a 71.0%, y el modelo final de R1 alcanza aproximadamente un 79.8% tras un pipeline adicional de ajuste supervisado y RL [3].
Un verificador es estrecho —la mayor parte de lo que quieres de un modelo no se puede comprobar con una prueba unitaria— pero dentro de su dominio estrecho es honesto, y lo honesto le gana a lo amplio cuando el optimizador es fuerte.
Predice antes de seguir leyendo
Tienes dos fuentes de recompensa para una tarea de programación. La fuente A es un modelo de preferencias entrenado con 50,000 juicios humanos sobre calidad de código. La fuente B es la suite de pruebas existente del repositorio.
Vas a entrenar con fuerza —procesos largos, alta presión de optimización—. ¿En qué recompensa confías más, y por qué?
La mayoría elige A por cobertura: captura legibilidad, estilo, intención, todo lo que una prueba no puede. Ese instinto acierta en cuanto a lo que mide y se equivoca en cuanto a lo que sobrevive a la presión. A es una regularidad estadística aprendida de una muestra finita, y tiene una superficie rica y suave que el optimizador puede escalar en direcciones que ningún anotador consideró jamás. B es estrecha, frágil y aburrida —y no tiene opiniones que se puedan halagar.
Sala de fallos: la máquina de párrafos
Entrena contra un modelo de recompensa que prefiere levemente respuestas más largas y mejor estructuradas. Nada patológico —una preferencia real, aprendida honestamente.
Lo que obtienes, en orden: respuestas un poco más largas; luego respuestas con encabezados; luego respuestas con encabezados, viñetas y un resumen; luego un modelo que produce un ensayo de tres párrafos bellamente formateado cuando la respuesta correcta era la palabra "no".
Nada se rompió. El modelo de recompensa nunca se equivocó —los humanos sí prefieren estructura, en promedio, en la distribución con la que fue entrenado. El optimizador simplemente caminó hasta el borde de esa distribución y siguió caminando, y cuanto más lejos llegaba, menos significaba ese promedio.
Lo que esto te cuesta, honestamente
Goodhart no te dice qué hacer. Es un diagnóstico, no un tratamiento. Saber que tu proxy se desviará bajo presión no te dice cuánta presión es aceptable.
Tampoco los verificadores escapan al problema. Un conjunto de pruebas también es un proxy: un proxy de que el software funcione. Optimiza lo suficientemente fuerte contra él y obtendrás código que pasa las pruebas y no sirve para nada.
Y, por construcción, no existe ninguna medición de U. Cualquier experimento que pretenda detectar el hackeo de la recompensa necesita una utilidad de reserva con la que la política nunca fue entrenada, lo que significa que debes ser capaz de escribir al menos una parte de eso que dijiste que no se podía escribir.
Hacia dónde va esto
El episodio 4 deja de lado la pregunta de qué optimizar y aborda lo que ocurre cuando algoritmos elegantes se topan con secuencias largas, despliegues (rollouts) obsoletos y la realidad de los sistemas — donde la falla no es haber perseguido el número equivocado, sino que tu entrenamiento dejó de aprender hace varios miles de pasos y la curva de pérdida nunca lo mencionó.
Episodio 3 de Intelligence Engineering Adventures, Season 1 — The Consequence Engine. Las afirmaciones en la fuente de la serie están etiquetadas por clase — definición, derivación, evidencia, decisión de ingeniería, pregunta abierta — y una metáfora puede introducir una afirmación, pero nunca sirve como evidencia de ella. Cada episodio incluye un laboratorio ejecutable en CPU. Este artículo no contiene material de ningún empleador o cliente. — Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app
Referencias
- Goodhart, C. A. E. (1975). Problems of Monetary Management: The U.K. Experience. Origen de la Ley de Goodhart. La frase más citada, "when a measure becomes a target, it ceases to be a good measure" (Traducción: cuando una medida se convierte en un objetivo, deja de ser una buena medida), es de Strathern, M. (1997), Improving Ratings: Audit in the British University System, European Review 5(3), 305–321 — no es la formulación original de Goodhart. Resumen y fuentes
- Campbell, D. T. (1979). Assessing the Impact of Planned Social Change. Evaluation and Program Planning, 2(1), 67–90. Las formulaciones datan de 1969, lo que le da a Campbell una prioridad discutible. Resumen y contexto
- Guo, D. et al. (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. Fuente de las cifras de AIME 2024 (15.6% → 71.0% para R1-Zero; ≈79.8% para R1) y del diseño de recompensa basado en reglas de precisión + formato. arxiv.org/abs/2501.12948
- Ouyang, L. et al. (2022). Training language models to follow instructions with human feedback (Traducción: Entrenar modelos de lenguaje para seguir instrucciones con retroalimentación humana) (InstructGPT). El pipeline de RLHF que este episodio pone en cuestión. arxiv.org/abs/2203.02155
- Rafailov, R. et al. (2023). Direct Preference Optimization: Your Language Model is Secretly a Reward Model. (Traducción: Optimización directa de preferencias: tu modelo de lenguaje es en secreto un modelo de recompensa.) arxiv.org/abs/2305.18290
- Bradley, R. A. & Terry, M. E. (1952). Rank Analysis of Incomplete Block Designs. (Traducción: Análisis de rangos en diseños de bloques incompletos.) Biometrika. El modelo de preferencias que subyace a todo modelo de recompensa aprendido. doi.org/10.2307/2334029