En el módulo 5 armamos PPO desde sus piezas: un actor (la política que elige acciones), un crítico (una cabeza de valor que estima cuánto vale un estado), la ventaja (cuánto mejor salió una acción respecto de lo esperado) y el clip que impide que cada actualización se pase de largo. Todo eso lo hicimos sobre entornos de juguete, donde la recompensa venía del mundo: el poste se cayó o no se cayó. Este módulo cambia una sola cosa —de dónde sale la recompensa— y con eso llegamos a la técnica que alineó a los modelos de chat que usas todos los días: RLHF (Reinforcement Learning from Human Feedback, aprendizaje por refuerzo a partir de retroalimentación humana).

Ya viste el mapa de RLHF en transformer, módulo 8: las tres etapas, la idea de premiar respuestas que a la gente le gustan. Aquel módulo lo contó a vista de pájaro porque todavía no teníamos PPO en las manos. Ahora sí. Este módulo no repite el mapa: baja a la mecánica de RL que en aquel momento no podías entender y que después de los módulos 1 a 5 sí puedes. Vas a ver el modelo de recompensa por dentro, el bucle PPO corriendo token a token, y por qué la penalización KL no es un detalle sino la pieza que evita que todo se rompa.

La tesis del módulo

RLHF es PPO donde la recompensa no viene del mundo sino de un modelo entrenado para imitar el juicio humano. El modelo de recompensa es el corazón del método y también su punto más frágil: el agente aprende a maximizar exactamente lo que ese modelo premia, aciertos y errores incluidos. Si el modelo de recompensa tiene una grieta, PPO la va a encontrar y explotar con una eficiencia que da miedo.

Por qué hace falta RL para esto

La pregunta razonable es: si tengo ejemplos de buenas respuestas, ¿por qué no entreno con SFT (supervised fine-tuning, ajuste supervisado) y listo? Porque SFT necesita la respuesta correcta escrita, y para la mayoría de lo que le pedimos a un asistente no existe una respuesta correcta: existe un espectro de respuestas mejores y peores. Es mucho más fácil para una persona comparar dos respuestas (“esta es mejor que aquella”) que escribir la ideal desde cero.

RLHF nace de esa asimetría. En vez de pedir la respuesta perfecta, pide comparaciones. Y comparar es exactamente el material del que se construye una recompensa: si sabemos que A es mejor que B, podemos entrenar algo que le dé más puntaje a A. Ese algo es el modelo de recompensa, y una vez que existe, tenemos justo lo que RL necesita —una señal de recompensa— y podemos soltar PPO a optimizarla.

Las tres etapas

Etapa 1 — SFT: el punto de partida

Antes de cualquier RL, el modelo base (que solo sabe predecir el siguiente token de internet) pasa por SFT sobre un conjunto de ejemplos de instrucción-respuesta escritos por humanos. Esto le enseña el formato de un asistente: responder a lo que se pregunta, seguir instrucciones, no seguir escribiendo el prompt del usuario. La cubrimos a fondo en el curso de fine-tuning, así que aquí solo lo necesario: SFT no basta —da un asistente correcto pero plano— pero es imprescindible como arranque. RLHF sin un SFT decente detrás no converge a nada útil; PPO necesita partir de una política que ya diga cosas razonables para que las comparaciones tengan sentido.

El modelo SFT cumple dos papeles a la vez, y conviene tenerlo claro desde ya: es el punto de partida de la política que vamos a optimizar, y —congelado, sin tocar— será el modelo de referencia contra el que mediremos cuánto se aleja la política. Volvemos a esto en la etapa 3.

Etapa 2 — El modelo de recompensa

El modelo de recompensa (reward model, RM) es una red que recibe un prompt y una respuesta y devuelve un escalar: un número de calidad, más alto mientras mejor la respuesta. Normalmente es el mismo transformer del asistente con la cabeza de lenguaje reemplazada por una cabeza que produce un solo número.

Se entrena con datos de preferencia: pares donde una persona vio dos respuestas al mismo prompt y marcó cuál prefería. Cada ejemplo es (prompt, respuesta_elegida, respuesta_rechazada). El RM no ve la etiqueta “8 sobre 10”; solo ve “esta le ganó a esta otra”.

¿Cómo se convierte un montón de comparaciones en un número calibrado? Con la pérdida de Bradley-Terry, un modelo estadístico clásico para rankings (el mismo que hay detrás del ELO del ajedrez). La idea: si el RM le asigna puntaje r_e a la elegida y r_r a la rechazada, la probabilidad de que la elegida sea preferida se modela como σ(r_e − r_r), donde σ es la sigmoide. Entrenar es empujar esa probabilidad hacia 1 en cada par observado:

pérdida = −log σ(r_elegida − r_rechazada)

Léelo así: si el RM ya le da más puntaje a la elegida (r_e > r_r), la diferencia es positiva, la sigmoide se acerca a 1, el log se acerca a 0 y la pérdida es chica —poco que corregir. Si se equivocó y premió la rechazada, la diferencia es negativa, la sigmoide baja y la pérdida se dispara. El gradiente entonces sube r_e y baja r_r. Nota lo importante: solo importan las diferencias, no los valores absolutos. El RM no aprende una escala objetiva de calidad; aprende a ordenar. Un puntaje de 3.2 no significa nada por sí solo, solo significa “mejor que uno de 1.1 para el mismo prompt”.

Un detalle práctico sobre de dónde salen esos pares. Se toma un prompt, se generan dos o más respuestas con el modelo SFT (a temperatura alta, para que salgan distintas) y una persona las ordena. Cuando hay más de dos, el ranking completo se descompone en pares: si el orden fue A > B > C, salen los pares (A,B), (A,C) y (B,C), y cada uno alimenta la pérdida. Así una sola sesión de anotación produce varios ejemplos de entrenamiento. La calidad del RM depende por completo de la calidad y la consistencia de esas anotaciones: anotadores cansados, mal instruidos o con criterios distintos meten ruido que el RM aprende como si fuera señal.

Ojo: el RM se entrena sobre preferencias humanas ruidosas, sesgadas y a veces contradictorias, y comprime todo ese juicio en un solo número. Es un modelo aproximado de un objetivo que ni los humanos definen con precisión. Tratarlo como si fuera la verdad de la calidad es el error conceptual del que salen casi todos los problemas de RLHF.

Etapa 3 — PPO sobre tokens

Aquí RLHF es PPO, con el mapeo que hace toda la magia. Costó cinco módulos llegar a poder leer esta tabla sin nervios:

Concepto de RL	En el LLM
Estado	El prompt más los tokens generados hasta ahora
Acción	El siguiente token a emitir
Política	El propio LLM (la distribución sobre el vocabulario)
Actor	El LLM que estamos optimizando
Crítico	Una cabeza de valor pegada al LLM
Recompensa	El escalar del reward model, al final de la respuesta
Episodio	Generar una respuesta completa a un prompt

Dos cosas de esta tabla merecen detenerse. Primero: generar texto es un problema de decisión secuencial. Cada token es una acción, el estado crece con cada token, y una respuesta entera es un episodio. Segundo, y más delicado: la recompensa es dispersa (sparse). El RM no puntúa token por token —no sabría hacerlo—; puntúa la respuesta terminada. Es decir, el agente juega toda la partida y recién al final recibe el número. Todo el aparato de crítico y ventaja del módulo 5 existe precisamente para repartir ese único número hacia atrás, atribuyendo a cada token cuánto contribuyó al resultado. Sin crítico, el modelo no sabría qué tokens premiar dentro de una respuesta que salió bien.

La penalización KL: la pieza que evita el desastre

Si sueltas PPO a maximizar el reward model sin restricción alguna, pasa algo predecible y catastrófico: el modelo se aleja tanto de donde empezó que rompe el lenguaje. Empieza a producir texto degenerado —repeticiones, símbolos raros, muletillas— que por alguna casualidad el RM puntúa alto. No es que el RM sea tonto; es que el RM solo vio texto normal durante su entrenamiento, y no tiene idea de qué hacer con la basura que un optimizador implacable encuentra fuera de esa zona. PPO explota esa ignorancia.

La defensa es la penalización KL (Kullback-Leibler divergence, una medida de cuánto difiere una distribución de probabilidad de otra). En cada token comparamos la política actual con el modelo de referencia —el SFT congelado de la etapa 1— y penalizamos que se separen. La recompensa que ve PPO no es el puro puntaje del RM, sino:

recompensa_efectiva = r_RM  −  β · KL(política ‖ referencia)

donde β (beta) controla cuánto pesa la correa. El RM tira hacia “responde mejor”; la KL tira hacia “no te alejes de cómo hablabas antes”. El entrenamiento es ese tira y afloja. Con β muy chico el modelo se desboca y hace reward hacking; con β muy grande el modelo casi no se mueve del SFT y RLHF no aporta nada. Ajustar β es de las decisiones más sensibles del método.

Aquí está el bucle completo, que es donde encaja todo lo anterior:

       EL BUCLE RLHF (una iteración de PPO)

             ┌──────────────────────┐
  prompt ──► │ política (LLM/actor) │ ──► respuesta
             └───────────┬──────────┘     (tokens)
                         │                    │
          KL vs          │                    ▼
       referencia        │            ┌───────────────┐
       (SFT              │            │  reward model │
        congelado)       │            └───────┬───────┘
                         │                    │ r_RM
                         ▼                    ▼
              ┌─────────────────────────────────┐
              │        r_RM  −  β · KL          │
              └────────────────┬────────────────┘
                               ▼
              ┌─────────────────────────────────┐
              │   PPO: actor + crítico + clip   │
              └────────────────┬────────────────┘
                               │ actualiza
                               ▼
                     vuelve a la política

Fíjate en quiénes viven en memoria al mismo tiempo: la política (que se entrena), la referencia (congelada, para la KL), el reward model (congelado, para el puntaje) y el crítico (que también se entrena). Cuatro modelos. Guarda ese dato: es el que motiva el módulo siguiente.

Reward hacking: la grieta inevitable

Reward hacking (u over-optimization, sobre-optimización) es lo que ocurre cuando el agente sube el puntaje del RM sin subir la calidad real. La KL frena la variante catastrófica —romper el lenguaje— pero no cierra las grietas sutiles. Porque el RM aprendió correlaciones de sus datos de preferencia, y algunas de esas correlaciones no son calidad de verdad:

Los humanos tendieron a preferir respuestas más largas, así que el RM premia longitud, y PPO aprende a alargar sin agregar contenido.
Los humanos prefirieron respuestas seguras y aduladoras, así que el modelo se vuelve zalamero (sycophancy): te da la razón para caerte bien.
Ciertos formatos (listas, encabezados, “en resumen…”) puntúan alto, así que aparecen aunque la pregunta no los pida.

Ninguno de esos comportamientos es lenguaje roto; la KL los deja pasar porque son perfectamente fluidos. Son la grieta exacta entre “lo que el RM mide” y “lo que queríamos”. Y como PPO optimiza lo que el RM mide, se cuela por ahí. La conclusión incómoda: el techo de RLHF es el techo del reward model. No puedes alinear mejor de lo que tu RM sabe juzgar. Este problema tiene módulo propio más adelante (rl-11); por ahora quédate con que el eslabón frágil no es PPO, es el número que PPO persigue.

Las tres etapas de un vistazo

Etapa	Con qué datos	Qué produce	Qué puede salir mal
SFT	Ejemplos instrucción-respuesta escritos por humanos	El asistente base y el futuro modelo de referencia	Datos de baja calidad → arranque plano que RLHF no logra rescatar
Reward model	Pares de preferencia (elegido / rechazado)	Un escalar de calidad por (prompt, respuesta)	Aprende correlaciones falsas (longitud, adulación) que luego se explotan
PPO	Prompts + el RM como recompensa + la referencia para la KL	La política final alineada	Reward hacking, colapso si β mal calibrado, costo de 4 modelos en memoria

El código, a alto nivel

Vamos a esbozar las dos piezas con TRL (Transformer Reinforcement Learning, la librería de Hugging Face para RLHF). Un aviso honesto antes: la API de PPO en TRL es inestable. PPOTrainer y PPOConfig viven en trl.experimental.ppo, el espacio experimental de TRL, donde la API puede cambiar entre versiones sin aviso (así sigue en TRL 1.x). Trata el código de PPO como ilustrativo del flujo, no como algo copiable sin revisar la doc vigente. El reward modeling, en cambio, está estable. Fuente: documentación oficial de TRL.

Primero, entrenar el reward model. TRL implementa la pérdida de Bradley-Terry por dentro; tú solo le das el dataset de preferencias con columnas chosen y rejected:

# Reward modeling con TRL (API estable a la fecha).
# El dataset trae pares de preferencia: columnas 'chosen' y 'rejected'.
from datasets import load_dataset
from transformers import AutoModelForSequenceClassification, AutoTokenizer
from trl import RewardTrainer, RewardConfig

modelo_base = "Qwen/Qwen2.5-0.5B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(modelo_base)

# num_labels=1: la cabeza produce UN escalar (el puntaje de calidad).
rm = AutoModelForSequenceClassification.from_pretrained(
    modelo_base, num_labels=1)

# Cada fila: {"chosen": [...conversación...], "rejected": [...]}
prefs = load_dataset("trl-lib/ultrafeedback_binarized", split="train")

config = RewardConfig(output_dir="rm-out", per_device_train_batch_size=8)

trainer = RewardTrainer(
    model=rm,
    args=config,
    processing_class=tokenizer,   # antes se llamaba 'tokenizer'
    train_dataset=prefs,
)
trainer.train()   # minimiza  -log σ(r_chosen - r_rejected)

El comentario del final es toda la etapa 2: bajo el capó, RewardTrainer calcula el escalar para la respuesta elegida y para la rechazada y aplica la pérdida de Bradley-Terry. No escribes tú la fórmula; sí tienes que entenderla para saber qué está optimizando.

Ahora el bucle PPO, en su forma conceptual. El punto es ver quién es quién, no memorizar firmas que van a cambiar:

# ESQUEMA ILUSTRATIVO del bucle PPO en RLHF.
# La API de PPOTrainer en TRL está en flujo (trl.experimental.ppo);
# consulta la doc de tu versión antes de correr esto.
from trl.experimental.ppo import PPOTrainer, PPOConfig

# Los cuatro modelos que viven en memoria a la vez:
#   policy    -> el actor que se entrena (parte del SFT)
#   ref_model -> el SFT CONGELADO, para la penalización KL
#   reward_model -> el RM de la etapa 2, congelado, da r_RM
#   value_model  -> el crítico (cabeza de valor) que se entrena
trainer = PPOTrainer(
    args=PPOConfig(kl_coef=0.05, output_dir="ppo-out"),  # kl_coef = β
    processing_class=tokenizer,
    model=policy,
    ref_model=ref_model,
    reward_model=reward_model,
    value_model=value_model,
    train_dataset=prompts,   # solo prompts: las respuestas las genera él
)

# Por dentro, cada paso de train():
#   1. la política genera respuestas a un lote de prompts   (rollout)
#   2. el reward_model puntúa cada respuesta terminada      -> r_RM
#   3. se resta la penalización KL contra ref_model         -> r_RM - β·KL
#   4. el crítico reparte esa recompensa hacia los tokens   (ventaja)
#   5. PPO actualiza policy y value_model con el clip        (módulo 5)
trainer.train()

Los cinco pasos del comentario son literalmente el diagrama de más arriba en código. El kl_coef es la β de la fórmula. Y el hecho de que le pases cuatro modelos distintos al constructor es, otra vez, el dato que va a doler en producción.

Cuidado: no confundas el modelo de referencia con el reward model. Son dos modelos congelados con papeles opuestos: el reward model da el puntaje que queremos subir; el modelo de referencia define la zona de la que no queremos alejarnos. El primero empuja el cambio, el segundo lo frena. Mezclarlos al leer código lleva a no entender de dónde sale cada término de la recompensa.

Errores comunes

Creer que el reward model conoce la calidad. No la conoce: aprendió a ordenar preferencias humanas ruidosas. Es una aproximación, y PPO va a explotar cada una de sus imperfecciones. El RM es el techo del método.
Saltarse o descuidar el SFT. PPO parte de la política SFT y se mide contra ella. Un SFT flojo da un arranque del que RLHF no logra levantarse, porque las comparaciones parten de respuestas ya malas.
Bajar β para “aprovechar más” el reward model. Es la receta directa al reward hacking y al colapso del lenguaje. La KL no es un freno opcional: es lo que mantiene al modelo dentro de la zona donde el RM tiene sentido.
Interpretar los puntajes del RM como una escala absoluta. Bradley-Terry solo fija diferencias. Un 4.0 no es “el doble de bueno” que un 2.0; solo es “preferido a” para el mismo prompt.
Olvidar la recompensa dispersa. El RM puntúa la respuesta completa, no cada token. Todo el crítico existe para repartir ese único número hacia atrás; quien lo ignora no entiende para qué está el value model en el constructor.
Subestimar el costo. Cuatro modelos en memoria (política, referencia, reward, crítico) no es un detalle de ingeniería: es la razón económica por la que existen las alternativas del módulo siguiente.

La frase para llevarse

“En RLHF el agente no aprende a ser bueno: aprende a maximizar un número que un modelo entrenado con preferencias humanas cree que es bondad. Alinéalo tan bien como quieras: nunca superarás la calidad del juez que le pusiste.”

Qué viene

Cerramos con la cuenta que quedó pendiente: RLHF-PPO necesita cuatro modelos en memoria a la vez —política, referencia, reward y crítico— más un bucle de generación en cada paso. Es potente, pero es caro, frágil de ajustar y complicado de estabilizar. En el módulo 7 vamos a ver la familia de métodos que nació justo para esquivar ese costo: DPO (Direct Preference Optimization), que se salta el reward model y optimiza directo sobre las preferencias con una sola pérdida, y GRPO (Group Relative Policy Optimization), que se salta el crítico estimando la ventaja por comparación dentro de un grupo de respuestas. Los dos atacan la misma pregunta desde ángulos distintos: ¿cuánto de esta maquinaria de cuatro modelos es de verdad imprescindible?

Razonamiento y RL — Módulo 6: RLHF por dentro