El planteamiento invierte el orden habitual. En vez de tomar un dataset de preferencias humanas y entrenar de inmediato, primero lo audita: revisa si las respuestas elegidas se distinguen de las rechazadas por razones que nada tienen que ver con la calidad, como el largo del texto o unas cuantas palabras recurrentes. Solo después ajusta el modelo.

El recorrido usa el dataset Anthropic HH-RLHF y Optimización Directa de Preferencias, conocida por su sigla en inglés DPO. La secuencia completa incluye preparar un entorno robusto en Colab, cargar y analizar los pares de respuesta elegida y rechazada, auditar el conjunto en busca de sesgos estructurales y de longitud, correr diagnósticos de atajos léxicos, preparar los datos conversacionales con filtrado de largo consciente del tokenizador, construir un flujo de entrenamiento DPO resistente a cambios de versión con TRL y adaptación LoRA opcional, ajustar un modelo Qwen2.5-0.5B-Instruct, evaluar la exactitud de recompensa y el comportamiento del entrenamiento, analizar el desempeño por subconjunto, inspeccionar el sesgo de longitud, generar respuestas de muestra y guardar la política resultante.

¿Qué configuración usa el experimento?

Los parámetros centrales están definidos por adelantado y son los que determinan la escala del ejercicio.

Código
MODEL_ID            = "Qwen/Qwen2.5-0.5B-Instruct"
SUBSETS             = helpful-base, helpful-rejection-sampled,
                      helpful-online, harmless-base
N_TRAIN_PER_SUBSET  = 120
N_TEST_PER_SUBSET   = 30
MAX_LENGTH          = 512
MAX_PROMPT_LENGTH   = 256
BETA                = 0.1
MAX_STEPS           = 30
BATCH_SIZE          = 1
GRAD_ACCUM          = 8
LEARNING_RATE       = 5e-6
WARMUP_RATIO        = 0.1
USE_LORA            = True
N_REWARD_EVAL       = 40
SEED                = 17

Con cuatro subconjuntos de HH-RLHF y 120 ejemplos de entrenamiento por subconjunto, el conjunto de trabajo queda en 480 pares de entrenamiento y 120 de prueba. Es una escala deliberadamente pequeña, pensada para correr en una sesión de Colab, incluso con reserva para funcionar sobre CPU con un entrenamiento acortado a propósito cuando no hay GPU disponible.

Las dependencias declaradas son trl 0.12 o superior, transformers 4.45 o superior, accelerate, datasets, peft y scikit-learn, y se instalan en una sola llamada a pip para que el resolutor elija un conjunto mutuamente compatible.

¿Por qué el entorno necesita tanto cuidado?

Por un choque de versiones concreto y bien documentado en el propio código. Colab viene con torchao 0.10.0, mientras que peft exige una versión superior a 0.16 y, en lugar de omitir la comprobación, lanza un error. Como nada en el ejercicio usa torchao, la solución elegida es desinstalarlo antes que actualizarlo, porque una actualización puede arrastrar una compilación de torch incompatible con el entorno de ejecución.

El código incluye además una verificación explícita de qué parámetros acepta cada interfaz de TRL en la versión instalada, porque argumentos como el factor de calentamiento, beta o los largos máximos han ido cambiando de lugar entre la configuración y el entrenador según la versión. Es un detalle menor en apariencia, pero es la causa más frecuente de que un ejercicio de este tipo deje de funcionar meses después de publicado.

¿Cómo se validan los pares de preferencia?

Cada transcripción del dataset se divide por los marcadores de turno "Human:" y "Assistant:" y se convierte en una lista estructurada de mensajes. La validación descarta un par si el texto no empieza con un turno de usuario, si el último turno no es del asistente, si dos turnos consecutivos corresponden al mismo rol o si algún contenido queda vacío.

La condición más importante es otra: la respuesta elegida y la rechazada deben compartir exactamente el mismo prefijo conversacional. Solo así la comparación aísla la diferencia entre ambas respuestas y no arrastra un contexto distinto. Recién entonces se separa el último turno de cada rama para formar el par.

El código cuenta además cuántos pares tienen una respuesta elegida idéntica a la rechazada, un control de calidad simple sobre la muestra que revela cuánto ruido trae el conjunto.

¿Qué es el diagnóstico de atajos léxicos?

Es la parte más interesante del ejercicio y la que justifica todo el trabajo previo. La pregunta que responde es directa: ¿alcanza con patrones lingüísticos de superficie para separar una respuesta preferida de una rechazada?

Para averiguarlo se vectoriza el texto con TF-IDF y se entrena una regresión logística que intenta clasificar cada respuesta usando solo esas señales superficiales, midiendo el resultado con exactitud, reporte de clasificación y área bajo la curva ROC. Si un clasificador tan elemental logra buen desempeño, significa que el dataset contiene atajos que el modelo aprenderá con gusto, porque son más fáciles que la preferencia real que se pretende enseñar.

El mismo razonamiento aplica al sesgo de longitud, que el ejercicio inspecciona por separado después del entrenamiento. Es un problema conocido del aprendizaje por preferencias: si las respuestas elegidas tienden a ser más largas, el modelo puede terminar aprendiendo a escribir más en vez de a responder mejor.

Por qué el enfoque importa fuera del laboratorio

Un ejercicio de 480 pares y 30 pasos de entrenamiento no produce un modelo de producción, y no pretende hacerlo. Su valor está en el método. Auditar un dataset de preferencias antes de usarlo es barato, corre en una sesión gratuita de Colab y en un modelo de 0,5B de parámetros que cabe en el hardware que ya tiene cualquiera.

Para equipos de la región que están armando asistentes con datos de preferencia propios, recopilados de sus usuarios o etiquetados internamente, ese orden vale más que la técnica de entrenamiento en sí. El sesgo que no se mide antes se hereda después, y sale mucho más caro descubrirlo cuando el modelo ya está respondiendo a clientes.