Mascota Jacar — leyendo contigo Un portátil cuyos ojos siguen el cursor mientras lees.
Inteligencia Artificial Metodologías

Evaluación de alineamiento: RLHF, DPO y alternativas recientes

Evaluación de alineamiento: RLHF, DPO y alternativas recientes

Actualizado: 2026-05-03

Cuando OpenAI describió RLHF como la técnica detrás de InstructGPT en 2022, el panorama del alineamiento de modelos de lenguaje pareció resuelto conceptualmente. RLHF era caro pero funcionaba, y durante un tiempo fue el método por defecto para cualquier fine-tuning serio con preferencias humanas. Tres años después, ese monopolio se ha desvanecido: DPO demostró que se podía lograr un resultado similar con mucho menos esfuerzo, y desde entonces han aparecido variantes (KTO, ORPO, SimPO) que prometen simplificar todavía más el proceso.

Este post es una revisión práctica del estado actual: cuándo tiene sentido cada método, qué coste tiene, qué resultados producen en contextos reales y qué criterios usar para elegir. No es una introducción teórica sino una lectura aplicada, pensada para quien está construyendo un pipeline de alineamiento.

Puntos clave

  • DPO es el default para la mayoría de casos de alineamiento estándar hoy: más simple, más rápido, funciona bien con datasets modestos.
  • RLHF se reserva para casos donde los últimos puntos porcentuales importan mucho o se necesita un modelo de recompensa reutilizable para evaluación continua.
  • KTO encaja cuando los datos vienen en formato binario (respuestas buenas/malas sin pares explícitos).
  • ORPO simplifica el pipeline fusionando SFT y alineamiento en un solo paso.
  • La barrera para alinear un modelo abierto se ha desplomado: lo que en 2022 era proyecto de laboratorio es hoy fine-tuning de fin de semana con GPU moderada.

El problema que todos resuelven

El objetivo común es el mismo: partir de un modelo pre-entrenado y fine-tuneado en instrucciones, y ajustarlo para que responda conforme a preferencias. Las preferencias pueden ser:

  • «Responde de forma útil»
  • «No produzcas contenido dañino»
  • «Adopta este estilo»
  • «Prioriza la brevedad»

Todos los métodos parten del mismo insumo: pares de respuestas etiquetadas como «mejor» y «peor» según algún criterio. Lo que cambia entre métodos es cómo se usa ese dataset para actualizar los pesos del modelo.

RLHF: el clásico

RLHF entrena primero un modelo de recompensa que predice cuánto le gustará a un humano una respuesta dada. Después usa aprendizaje por refuerzo (típicamente PPO) para optimizar el modelo de lenguaje maximizando esa recompensa, con restricciones de KL divergence para evitar que se aleje demasiado del modelo base.

Ventajas: – El método mejor estudiado. – Produce resultados de calidad alta. – El modelo de recompensa permite evaluar respuestas nuevas fuera del entrenamiento.

Inconvenientes: – Caro computacionalmente (tres modelos activos simultáneamente: política, referencia, recompensa). – Inestable en la práctica (el ajuste de hiperparámetros es notoriamente difícil). – Requiere un dataset de preferencias grande y de buena calidad.

Cuándo usarlo: cuando tienes recursos (equipo de investigación en ML, presupuesto computacional, tiempo para iterar), cuando quieres reutilizar el modelo de recompensa para evaluación offline, o cuando la complejidad del criterio de alineamiento es alta.

DPO: la simplificación

DPO (Direct Preference Optimization) llegó en 2023 con una idea simple: puedes reformular el problema de RLHF de tal manera que el modelo de recompensa implícito sea el propio modelo de lenguaje, y entonces puedes entrenar directamente contra pares de preferencias sin PPO, sin modelo de recompensa separado.

En la práctica, DPO funciona sorprendentemente bien. La calidad del modelo resultante es muy cercana a la de RLHF en la mayoría de benchmarks, y el coste de entrenamiento es una fracción. Esto ha hecho que DPO sea hoy el método más común en la comunidad abierta: prácticamente todos los fine-tunes públicos de Llama, Mistral o Gemma lo usan.

Ventajas: – Mucho más simple de implementar. – Mucho más rápido de entrenar. – Menos sensible a hiperparámetros. – Funciona bien con datasets más pequeños.

Inconvenientes: – No produce un modelo de recompensa reutilizable. – Ligeramente peor que RLHF bien ajustado en tareas muy complejas. – Tiende a producir respuestas más largas que el modelo base (un sesgo bien documentado).

Cuándo usarlo: para la mayoría de casos de alineamiento estándar, especialmente en entorno open source con recursos moderados.

Diagrama comparando los pipelines de RLHF y DPO durante el entrenamiento

Las variantes recientes

Durante el último año han aparecido varias alternativas a DPO que intentan mejorar aspectos concretos:

  • KTO (Kahneman-Tversky Optimization): en vez de pares de preferencias, usa respuestas etiquetadas individualmente como deseables o no deseables. Los datasets son más fáciles de construir (no necesitas comparaciones, solo etiquetas). Si tu fuente de datos es naturalmente binaria (respuestas buenas vs malas sin par), KTO encaja mejor.
  • ORPO (Odds Ratio Preference Optimization): fusiona el fine-tuning supervisado inicial y el alineamiento en un solo paso, eliminando la fase de SFT previa. Interesante para quien quiere pipelines más cortos.
  • SimPO (Simple Preference Optimization): propone una reformulación de DPO que usa la longitud de secuencia normalizada como referencia, eliminando la necesidad del modelo de referencia. Reduce el coste de memoria en entrenamiento. Resultados prometedores pero adopción aún modesta.

Qué pasa en la práctica

El patrón que se repite en equipos con los que he trabajado: para alineamiento estándar de un modelo de tamaño mediano (7B a 70B) con un dataset de preferencias humanas razonable, DPO es el default y no hay razón fuerte para cambiarlo.

  • KTO se adopta cuando el dataset viene en formato binario (feedback de usuarios en producción con respuestas aprobadas y rechazadas, pero no pares explícitos).
  • ORPO se prueba cuando se quiere simplificar el pipeline.
  • SimPO aparece más en papers que en producción.
  • RLHF se reserva para modelos de frontera donde los últimos puntos porcentuales importan mucho, o cuando el criterio de alineamiento es complejo y multimodal.

Para herramientas concretas, cualquier framework decente (TRL de HuggingFace, Axolotl, Unsloth) lleva a un pipeline DPO funcional en un día. El ecosistema de modelos base para empezar es amplio; ver nuestro análisis de modelos de pesos abiertos en empresa para orientación sobre cuál elegir.

Recomendaciones concretas

Si estás empezando un proyecto de alineamiento hoy:

  1. Empieza con DPO. Es el que más documentación, tutoriales e implementaciones públicas tiene.
  2. Usa un dataset de preferencias de al menos unos cuantos miles de ejemplos. Si tienes menos, KTO puede ser más eficiente porque el etiquetado binario es más barato.
  3. Evalúa con un conjunto de validación reservado, con métricas automáticas (ROUGE, BLEU) y evaluación humana aleatoria. La evaluación puramente automática engaña, especialmente con DPO que tiende a inflar longitud.
  4. Solo pásate a RLHF si, tras probar DPO, tienes evidencia concreta de que te falta calidad para tu caso específico. En la mayoría de proyectos esa evidencia no aparece.
  5. Prueba una variante reciente (KTO, ORPO) si tu dataset o tu pipeline encajan mejor con sus premisas.

Mi lectura

La barrera para alinear un modelo abierto de forma efectiva se ha desplomado. Lo que en 2022 era proyecto de laboratorio de investigación es hoy fine-tuning en fin de semana con un presupuesto de GPU moderado. Eso no significa que el problema esté resuelto conceptualmente (hay preguntas abiertas importantes sobre alineamiento seguro de modelos de frontera), pero sí que la práctica rutinaria de ajustar un modelo al estilo o la tarea que necesitas es ya accesible para cualquier equipo técnico.

La existencia de variantes nuevas cada pocos meses es señal de que el espacio está vivo. La tendencia general —hacia menos complejidad y más accesibilidad— es claramente buena para el ecosistema.

¿Te ha resultado útil?
[Total: 0 · Media: 0]

Escrito por

CEO - Jacar Systems

Apasionado de la tecnología, la infraestructura cloud y la inteligencia artificial. Escribe sobre DevOps, IA, plataformas y software desde Madrid.