Cómo aprenden comportamiento: de predictor de texto a asistente útil

El preentrenamiento aprende un único objetivo: dado texto, adivina qué viene después. Un modelo base capaz puede responder preguntas y seguir instrucciones desde el prompt, pero no ha aprendido a comportarse como asistente de forma confiable.

Un modelo base no es un asistente

Un modelo base es, en esencia, un imitador talentoso sin sentido de la ocasión. Ha visto miles de millones de tokens de todo tipo — libros, foros, código, poesía — y aprendió a imitar todos esos estilos. El problema es que no tiene noción de cuándo usar cada uno.

Ejemplo práctico — el prompt: "¿Cuál es la capital de Francia?" Un modelo base podría responder, con probabilidad similar entre las opciones:

• “París.” (correcto, pero seco, sin ningún criterio de estilo).
• “¿Sabías que París es la capital de Francia?” (responde con otra pregunta — vio muchos diálogos donde los personajes se turnan preguntando).
• “La capital de Francia es París, situada a orillas del río Sena…” (continúa como si fuera un artículo enciclopédico).
• “Usuario: ¿Cuál es la capital de Francia? Asistente: París.” (imita el formato completo de un diálogo que vio en sus datos, incluyendo las etiquetas, como parte de su propia respuesta).

El modelo no “entiende” que se espera una respuesta directa y útil — simplemente continúa el patrón más estadísticamente probable, y ese patrón puede ser una pregunta, una etiqueta, o un divague, dependiendo de qué vio con más frecuencia en sus datos. El preentrenamiento le da al modelo conocimiento — no le da comportamiento. Eso se enseña en la fase que sigue.

Fine-tuning supervisado (SFT): enseñando el formato deseado

El SFT usa exactamente la misma predicción de siguiente token del preentrenamiento, apuntada a un tipo distinto de ejemplo: conversaciones completas con formato de asistente.

Usuario: ¿Cuál es la capital de Francia?
Asistente: París es la capital de Francia.

Usuario: ¿Cómo se hace un pastel de chocolate?
Asistente: Para hacer un pastel de chocolate, necesitas los siguientes ingredientes...

El modelo ve miles de ejemplos así. Poco a poco aprende que cuando ve el patrón Usuario: pregunta..., lo que debe venir es Asistente: respuesta útil... — y no solo el formato, también el estilo: conciso, educado, directo.

La clave: solo calificamos la respuesta del asistente. El modelo ve el intercambio completo (usuario + asistente), pero solo actualizamos los pesos basándonos en los tokens de la respuesta del asistente. Los tokens del usuario son contexto que el modelo debe aprender a seguir, no a predecir — si “acertáramos” también la pregunta del usuario como parte de la pérdida, estaríamos enseñándole a predecir preguntas, no a responderlas.

Bajo el capó (simplificado):

tokens = tokenizer(conversacion_completa)   # [USUARIO, ASISTENTE, ...]
mascara = [0, 0, ..., 1, 1, 1]              # 1 solo para los tokens del asistente

logits = model(tokens)
loss = cross_entropy(logits, tokens, mascara=mascara)
# Los gradientes de los tokens del usuario son ignorados

¿Cuántos ejemplos hacen falta? Muchos menos que en el preentrenamiento. Mientras el preentrenamiento usa cientos de miles de millones de tokens, el SFT suele funcionar con decenas de miles de conversaciones (típicamente 10k-100k ejemplos) — el modelo ya sabe lenguaje, solo necesita aprender formato y estilo. Pero la calidad de esos ejemplos es crítica: si son de mala calidad (respuestas incorrectas, poco útiles), el modelo aprenderá exactamente ese comportamiento con la misma diligencia con la que aprendería uno bueno.

Analogía: imagina un actor que leyó enciclopedias completas (preentrenamiento) — sabe muchos hechos, pero no sabe cómo actuar en una entrevista. El SFT es como un director que le da guiones y le dice “así es como queremos que respondas”. El actor aprende a usar su conocimiento en el formato deseado, pero no adquiere hechos nuevos solo por leer guiones.

Lo que el SFT puede y no puede hacer

Muy bueno enseñando formas: formatos (listas, tablas, código), estilos (formal, amigable, técnico), y rutinas (cómo pedir aclaraciones, cómo despedirse). Pero el SFT no puede enseñar conocimiento nuevo de forma fiable — si el modelo nunca vio en el preentrenamiento que “la capital de Australia es Canberra”, ningún ejemplo de SFT se lo va a enseñar. Solo puede enseñarle a expresar el conocimiento que ya tiene, no a adquirir conocimiento nuevo. Y si los ejemplos de entrenamiento son contradictorios entre sí, el modelo se confunde en vez de aprender un patrón limpio.

La siguiente frontera: preferencias humanas

El SFT produce un modelo que sigue el formato deseado — pero sigue sin saber qué respuestas son “mejores” que otras entre varias que son igualmente correctas en formato.

El linaje histórico:

• 2017: investigadores de OpenAI y DeepMind enseñaron a un agente de simulación a hacer una mortal hacia atrás usando puramente comparaciones humanas entre videoclips — nadie definió matemáticamente qué era una “buena” mortal, pero los humanos la reconocían al verla. Primera demostración de que el feedback comparativo podía enseñar comportamientos complejos sin etiquetas explícitas.
• 2022: el mismo principio se aplica a texto — OpenAI entrena InstructGPT con RLHF (Reinforcement Learning from Human Feedback): humanos comparan respuestas, se entrena un modelo de recompensa que las puntúa, y se usa RL para optimizar el modelo contra ese puntaje. Primer paso hacia los chatbots modernos — pero un pipeline pesado (modelo de recompensa, modelo de referencia, RL delicado de estabilizar).
• 2023: un grupo de Stanford deriva que, bajo ciertos supuestos, la política deseada puede entrenarse con una sola pérdida de estilo clasificación, directamente sobre las comparaciones — sin modelo de recompensa separado, sin RL. Eso es DPO (Direct Preference Optimization). No es matemáticamente intercambiable con toda forma de RLHF, pero es un camino más simple al mismo destino.

DPO: optimización directa de preferencias

Qué hace exactamente: se mantienen dos copias del modelo — la política (la que se entrena) y una referencia congelada (normalmente el modelo ya afinado con SFT). Para cada par de preferencia, se le pregunta a ambas copias: ¿qué tan probable serías de producir la respuesta elegida, y la rechazada? La pérdida empuja sobre la brecha entre las dos, recompensando a la política por favorecer la elegida más de lo que ya la favorecía la referencia.

Un ejemplo hipotético, para verlo en números: supongamos la pregunta "¿Cómo se hace un pastel de chocolate?", con dos respuestas candidatas:

• A (elegida): “Primero, mezcla la harina, el cacao, y el azúcar. Luego añade los huevos y la leche. Hornea a 180°C durante 30 minutos.”
• B (rechazada): “El pastel de chocolate es delicioso. Necesitas chocolate, harina, y huevos.”

Los humanos prefieren A (instrucciones claras y accionables) sobre B (vaga). Supongamos que el modelo de referencia (SFT, antes de DPO) le daba, por alguna razón, más probabilidad a B que a A — quizás porque B es más genérica y ese tipo de respuesta es más común en los datos. El entrenamiento DPO empuja a la política a que la probabilidad de A suba relativo a la referencia, y la de B baje relativo a la referencia, ampliando la brecha a favor de A. El modelo no aprende una regla simple como “prefiere respuestas largas” — aprende el criterio humano específico detrás de esa preferencia, que en otros casos podría favorecer justamente lo contrario (una respuesta corta y directa).

El parámetro beta: controla qué tan fuerte se ancla el objetivo a la referencia. Un beta pequeño (~0.1) deja a la política más libre de desviarse — aprende preferencias rápido, pero puede divergir más. Un beta grande (~1.0) la mantiene más cerca de la referencia — aprende más lento, pero de forma más estable. En la práctica, beta suele estar entre 0.1 y 0.5.

La fórmula canónica:

$$\mathcal{L}_{DPO} = -\log \sigma\left(\beta \left[\log\frac{\pi_\theta(y_w|x)}{\pi_{ref}(y_w|x)} - \log\frac{\pi_\theta(y_l|x)}{\pi_{ref}(y_l|x)}\right]\right)$$

Donde π_θ es la política, π_ref la referencia congelada, y_w la respuesta elegida (win), y_l la rechazada (lose). La pérdida es pequeña cuando la política prefiere la elegida mucho más que la referencia, y grande cuando prefiere la rechazada — es una pérdida de clasificación binaria, donde la “clase” es cuál respuesta es mejor.

Bajo el capó — una variante normalizada por longitud: la fórmula de arriba compara log-probabilidades sumadas de cada respuesta completa — pero eso tiene un efecto colateral: una respuesta más larga acumula más log-probabilidad negativa simplemente por tener más tokens, así que el margen de preferencia puede convertirse parcialmente en un concurso de longitud, no de calidad. Una variante más cuidadosa normaliza por la cantidad de tokens, comparando qué tan natural es cada respuesta por token, en vez de en total:

conteo_tokens = mx.maximum(mascara.sum(axis=-1), 1)
logprob_respuesta = -(perdidas_token * mascara).sum(axis=-1) / conteo_tokens

# cuánto más le gusta a la política cada respuesta, comparado con la referencia
brecha_elegida = logprob_politica_elegida - logprob_referencia_elegida
brecha_rechazada = logprob_politica_rechazada - logprob_referencia_rechazada

loss = -log_sigmoide(beta * (brecha_elegida - brecha_rechazada))

Si la política prefiere la elegida más fuertemente que la referencia, el sigmoide se satura y la pérdida cae hacia cero. Los pesos de referencia están congelados en todo momento — solo la política aprende.

Ventajas de DPO sobre RLHF: simplicidad (sin modelo de recompensa separado, sin algoritmos de RL inestables), eficiencia (una sola pérdida, optimizable con el mismo descenso de gradiente de siempre), y estabilidad (sin los problemas de divergencia típicos de RL). Limitaciones: asume que las preferencias humanas son transitivas y modelables con una función de utilidad simple (no siempre es cierto), y no funciona bien para tareas que requieren exploración activa, porque DPO es un método offline — usa un conjunto fijo de comparaciones, no genera nuevas sobre la marcha.

La evaluación del comportamiento: ¿cómo saber si funciona?

Evaluar comportamiento es más difícil que evaluar loss de validación — no basta una métrica numérica; hace falta juicio humano o evaluación automatizada con otros modelos. Esto es exactamente el terreno de los jueces LLM que ya vimos a fondo en Parte II: comparación por pares entre dos versiones de un modelo, calificación de respuesta única en una escala, o evaluación guiada por rúbrica — las mismas tres técnicas, aplicadas aquí para decidir si un modelo post-entrenado realmente mejoró, no solo si su loss bajó.

Un patrón adicional común en este contexto específico: el win rate — qué porcentaje de las comparaciones gana el modelo nuevo contra una versión base o contra un competidor (ej. “el modelo con DPO gana el 65% de las comparaciones contra el modelo solo-SFT”). Es, en esencia, una agregación de muchas comparaciones por pares en un solo número resumen.

El flujo completo de post-entrenamiento

El camino habitual para producir un modelo asistente:

1. Preentrenamiento — texto masivo, predictor de siguiente token → modelo base.
2. SFT — ejemplos de conversaciones usuario↔asistente → modelo que sigue el formato.
3. DPO (o RLHF) — comparaciones humanas → modelo que además prefiere respuestas de mayor calidad.

Analogía de cierre: piensa en un estudiante de medicina. El preentrenamiento es leer todos los libros de medicina — adquiere conocimiento bruto. El SFT es aprender a estructurar diagnósticos y recetas en el formato correcto. El DPO es trabajar codo a codo con un médico experto que te señala, una y otra vez, cuándo un diagnóstico es mejor que otro — hasta que ese criterio se internaliza.

Resumen del capítulo

• Un modelo base es un imitador sin sentido de la ocasión — tiene conocimiento, pero no comportamiento.
• SFT enseña formato y estilo con ejemplos de conversaciones, calificando solo la respuesta del asistente.
• DPO enseña preferencias mediante comparaciones humanas, sin necesitar una “respuesta correcta” explícita — solo cuál de dos opciones es mejor.
• Ninguna de las dos técnicas de post-entrenamiento enseña conocimiento nuevo ni razonamiento que el modelo no desarrolló en el preentrenamiento — solo moldean cómo usa lo que ya tiene.
• Evaluar si el post-entrenamiento funcionó requiere las mismas herramientas de jueces LLM que vimos en Parte II, no solo mirar el loss.

En el próximo capítulo veremos los límites de los modelos base — qué pueden hacer, qué no, y dónde fallan sistemáticamente.