Reward modeling y cuándo lo necesitas

Objetivo de maestría

entender qué es un reward model, cómo se entrena, sus fallos (reward hacking), y —decisión clave de 2026— cuándo te conviene un reward model neuronal frente a una recompensa verificable (RLVR). Esta lección es el puente entre preferencias (L4) y RL (L6–L8).

5.1Qué es un reward model (RM)

Un RM es un modelo que toma (prompt, respuesta) y devuelve un escalar: cuánto de buena es la respuesta. Se usa como la "función de recompensa" en RL cuando no hay un criterio verificable automático.

Se entrena sobre los mismos datos de comparación que DPO (pares chosen/rejected), pero en vez de optimizar la política, optimiza el RM para que puntúe más alto la chosen:

L_RM = − E[ log σ( r_θ(x, y_w) − r_θ(x, y_l) ) ]      # Bradley-Terry otra vez

Arquitectura típica: un LLM base + una cabeza de regresión (una capa lineal sobre el último hidden state) que produce el escalar.

5.2La pregunta de 2026: RM neuronal vs recompensa verificable (RLVR)

Aquí está la decisión que define tu enfoque de RL:

Reward model neuronal: necesario cuando "bueno" es subjetivo y no computable — utilidad, tono, seguridad, calidad de redacción. Es lo que usa el RLHF clásico. Problema: es un modelo aprendido → se puede hackear (5.3).
Recompensa verificable (RLVR): cuando "bueno" es objetivamente comprobable — ¿el código pasa los tests?, ¿la respuesta numérica es exacta?, ¿la tool-call parsea y devuelve lo correcto?, ¿la SQL produce el resultado esperado? La recompensa es una función determinista, no un modelo. Es la receta de DeepSeek-R1 y la que harás en L7–L8.

Regla práctica: si puedes verificar la corrección con código, usa RLVR — es más barato, más robusto y casi imposible de hackear de forma trivial. Reserva el RM neuronal para lo genuinamente subjetivo. La mayoría de tareas de ingeniería (código, datos, tool-calling, matemáticas) son verificables → RLVR.

5.3Reward hacking: por qué los RM neuronales son frágiles

Un RM es una aproximación. La política, al optimizar contra él, encuentra atajos que suben el reward sin mejorar la calidad real — explota los errores del RM. Ejemplos clásicos:

El RM premia respuestas largas → la política se vuelve verbosa sin aportar.
El RM premia ciertas palabras ("Por supuesto, encantado de ayudar") → la política las repite.
El RM penaliza incertidumbre → la política afirma con seguridad cosas falsas.

Mitigaciones: penalización KL hacia la referencia (L6), RM más robustos (ensembles), y —la mejor cuando es posible— recompensas verificables que no se pueden hackear (un test pasa o no pasa).

Esta es una de las razones por las que el campo se movió hacia RLVR: una función de verificación no tiene "errores explotables" como los tiene un RM neuronal.

5.4Laboratorio L5.1 — Entrenar un reward model pequeño

Aunque vayas a usar RLVR, entrenar un RM una vez te da la intuición y te sirve como juez o como métrica. Lo entrenamos con TRL.

python

1# lab_n2l5_rm.py — entrena un reward model sobre pares de preferencia
2from unsloth import FastLanguageModel
3from datasets import load_dataset
4from trl import RewardConfig, RewardTrainer
5
6# Cargamos un base pequeño CON cabeza de clasificación (num_labels=1 -> regresión escalar)
7model, tok = FastLanguageModel.from_pretrained(
8    "unsloth/Qwen3-1.7B-Instruct", max_seq_length=2048, load_in_4bit=True,
9    # para RM se carga como AutoModelForSequenceClassification por debajo
10)
11model = FastLanguageModel.get_peft_model(model, r=16, lora_alpha=16,
12    target_modules=["q_proj","k_proj","v_proj","o_proj"])
13
14ds = load_dataset("trl-lib/ultrafeedback_binarized", split="train[:5000]")
15# RewardTrainer espera columnas chosen/rejected ya formateadas con chat template
16
17trainer = RewardTrainer(
18    model=model, processing_class=tok, train_dataset=ds,
19    args=RewardConfig(per_device_train_batch_size=4, gradient_accumulation_steps=2,
20                      num_train_epochs=1, learning_rate=1e-5, logging_steps=20,
21                      max_length=1024, output_dir="./rm_out"),
22)
23trainer.train()
24# Métrica a vigilar: accuracy en validación = fracción de pares donde r(chosen) > r(rejected)

Líneas no triviales:

Por debajo, el modelo se carga como AutoModelForSequenceClassification con num_labels=1: la cabeza produce el escalar de recompensa.
La métrica de un RM no es perplexity sino accuracy de ranking (¿ordena bien chosen vs rejected?). Un RM con accuracy ~0.5 es ruido; quieres >0.7.

5.5Laboratorio L5.2 — Un verificador (la alternativa RLVR)

Para una tarea verificable, la "recompensa" es una función, no un modelo. Aquí, para texto→SQL (dataset de L3):

python

1# lab_n2l5_verifier.py — recompensa verificable para SQL: ejecuta y compara resultados
2import sqlite3, sqlglot
3
4def sql_reward(generated_sql: str, gold_sql: str, schema_setup_sql: str) -> float:
5    """+1 si la SQL generada produce el mismo resultado que la gold; 0 si no; -0.5 si no parsea."""
6    try:
7        sqlglot.parse_one(generated_sql)            # ¿parsea?
8    except Exception:
9        return -0.5
10    try:
11        con = sqlite3.connect(":memory:")
12        con.executescript(schema_setup_sql)         # crea el esquema en memoria
13        gen = con.execute(generated_sql).fetchall()
14        gold = con.execute(gold_sql).fetchall()
15        return 1.0 if gen == gold else 0.0          # comparación de resultados, no de strings
16    except Exception:
17        return 0.0
18    finally:
19        con.close()

Por qué esto es superior a un RM para esta tarea: no hay nada que hackear. O la consulta devuelve el resultado correcto o no. Compara resultados, no texto (una SQL puede escribirse de mil formas equivalentes). Esta función es exactamente lo que conectarás como recompensa en GRPO en L8.

5.6Ejercicios

E1. Entrena el RM y mide su accuracy de ranking en validación. ¿Supera 0.7? Si no, ¿qué falla (datos, base demasiado pequeño)?

E2. Toma tu RM y genera 8 respuestas a un prompt; ordénalas por reward. ¿El orden tiene sentido para un humano? Busca un caso de reward hacking (una respuesta que el RM puntúa alto pero es mala).

E3. Para tres tareas (escribir un poema bonito, resolver una ecuación, generar SQL), di si usarías RM neuronal o RLVR y por qué.

Solución E3

Poema bonito → subjetivo → RM neuronal (o LLM-as-judge). Ecuación → verificable (respuesta exacta) → RLVR. SQL → verificable (ejecutar y comparar) → RLVR. Regla: verificable ⇒ RLVR.

5.7Trampas comunes

Usar RM neuronal donde había una verificación trivial disponible (más frágil y caro).
No medir la accuracy de ranking del RM (puede ser ruido).
Comparar SQL/código por string en vez de por resultado.

5.8Referencias

InstructGPT (Ouyang et al. 2022) para RM clásico. Tülu 3 / RLVR (Lambert et al. 2024). Docs TRL (RewardTrainer). Literatura de reward hacking (Skalse et al. 2022).