DPO y Datos de Preferencia: Preparación de Datasets de Alineación On-Premise

Direct Preference Optimization (DPO) es la técnica de alineación más práctica disponible para equipos empresariales hoy. Dirige el comportamiento del modelo — tono, precisión, cumplimiento de políticas, seguridad — sin la complejidad de infraestructura de Reinforcement Learning from Human Feedback (RLHF). No hay modelo de recompensa que entrenar. No hay bucle de entrenamiento PPO que estabilizar. Solo pares de respuestas etiquetadas como "elegida" y "rechazada", y una sola pasada de fine-tuning.

El problema para las empresas son los datos. Los datasets de preferencia codifican lo que la organización considera una respuesta "buena" versus una "mala". Esto incluye decisiones sensibles de cumplimiento, patrones de razonamiento propietarios y estándares internos de calidad. Enviar estos datos a un servicio de terceros para preparación o aumento filtra inteligencia competitiva y viola las políticas de gobernanza de datos.

Todo el flujo de trabajo de preparación de datos DPO debe ejecutarse on-premise. Aquí está cómo hacerlo, desde entradas crudas hasta JSONL listo para exportar.

Qué Es DPO y Por Qué Importa para Modelos Empresariales

El fine-tuning estándar (SFT) le enseña a un modelo qué decir. DPO le enseña a un modelo qué preferir. La distinción importa cuando necesitas un modelo que no solo produzca respuestas correctas, sino que las produzca de la manera correcta — con el tono correcto, el nivel de detalle correcto, las advertencias correctas y las barreras de cumplimiento correctas.

Un modelo SFT entrenado en transcripciones de soporte al cliente generará respuestas que se parecen a transcripciones de soporte al cliente. Pero podría generar respuestas excesivamente informales, o prometer cosas que la empresa no puede cumplir, o saltarse divulgaciones requeridas. DPO corrige estos comportamientos mostrándole al modelo ejemplos pareados: "esta respuesta es aceptable, esta respuesta casi idéntica no lo es."

Los resultados son medibles. Los equipos que agregan una pasada de alineación DPO después de SFT típicamente ven una mejora del 15-25% en las calificaciones de preferencia humana y una reducción del 30-50% en violaciones de políticas (respuestas que rompen directrices internas). Estos números provienen de benchmarks internos, no de evaluaciones sintéticas.

Para industrias reguladas — finanzas, salud, legal — DPO no es opcional. Es el mecanismo que asegura que el modelo siga reglas de comunicación específicas del sector, requisitos de divulgación y estándares de lenguaje de riesgo.

El Formato del Dataset de Preferencia

Un dataset DPO es una colección de tripletas:

{
  "prompt": "A customer asks: 'Can I get a refund on my subscription?'",
  "chosen": "I can help with that. Our refund policy allows full refunds within 30 days of purchase. Could you share your order number so I can check your eligibility?",
  "rejected": "Sure, I'll process your refund right away! You should see the money back in your account within 24 hours."
}

La respuesta "elegida" sigue la política — referencia la política de reembolso, pide verificación y no hace promesas. La respuesta "rechazada" se salta la verificación y hace un compromiso de tiempo que la empresa puede no cumplir.

Ambas respuestas son plausibles. Ambas son fluidas. La diferencia es la alineación de comportamiento — y esa diferencia es lo que DPO aprende.

El formato en sí es simple. La dificultad es producir suficientes pares de alta calidad donde la distinción entre elegida y rechazada sea significativa y consistente.

De Dónde Provienen los Datos de Preferencia en la Empresa

No necesitas generar datos de preferencia desde cero. La mayoría de las empresas están sentadas sobre ricas fuentes de señal de preferencia que nunca han sido formateadas para entrenamiento de modelos.

Registros de Retroalimentación Humana

Si tu organización usa cualquier herramienta asistida por IA — un chatbot, un asistente de redacción de documentos, una herramienta de completado de código — probablemente hay registros de reacciones de usuarios. Pulgares arriba/abajo, solicitudes de regeneración, ediciones manuales a salidas de IA y tickets de queja codifican datos de preferencia. Un usuario que edita un correo generado por IA te está mostrando el par "rechazado" (original) y "elegido" (editado).

Resultados de Pruebas A/B

Si has ejecutado pruebas A/B comparando salidas de modelos, variantes de prompts o formatos de respuesta, la variante ganadora es "elegida" y la perdedora es "rechazada". Los datos de pruebas A/B son particularmente valiosos porque vienen con significancia estadística — sabes que la preferencia es real, no ruido.

Salidas de Modelos Revisadas por Calidad

Muchas empresas tienen procesos de revisión de calidad donde personal senior revisa y califica las salidas de IA. Una institución médica revisando resúmenes clínicos generados por IA, una firma legal revisando cláusulas contractuales redactadas por IA, un banco revisando evaluaciones de riesgo generadas por IA — todos producen salidas calificadas que se mapean directamente a pares de preferencia.

Correcciones de Expertos

Cuando un experto de dominio corrige una salida de IA, obtienes un par de preferencia natural. La salida original es "rechazada" y la versión corregida es "elegida". Estos son los datos de preferencia de mayor calidad disponibles porque la corrección es dirigida y el experto entiende exactamente por qué el original estaba equivocado.

Guías de Estilo Internas y Reglas de Cumplimiento

Las directrices de comunicación de tu organización, plantillas de cumplimiento y documentos de voz de marca definen cómo luce lo "bueno". Genera pares de respuestas donde uno sigue las directrices y otro viola una regla específica. Estos son sistemáticos y pueden producirse a escala.

El Pipeline de Preparación

Paso 1: Recopilar Pares Prompt-Respuesta

Agrega datos crudos de las fuentes anteriores. Para cada fuente, extrae el prompt (la entrada o pregunta) y al menos dos respuestas candidatas. En esta etapa, no te preocupes por el formato — enfócate en la completitud.

Objetivo: 1,000-2,000 conjuntos crudos de prompt-respuesta. Después de filtrar y formatear, espera retener el 50-70% como pares DPO utilizables.

Paso 2: Los Expertos de Dominio Clasifican o Seleccionan las Respuestas Preferidas

Este es el paso que requiere juicio humano y no puede automatizarse. Presenta cada prompt con sus respuestas candidatas a expertos de dominio y pídeles que seleccionen la respuesta preferida.

Estructura la tarea cuidadosamente:

• Muestra el prompt y todas las respuestas candidatas simultáneamente
• Pide al anotador que seleccione la mejor respuesta y la peor respuesta (si existen más de dos candidatas)
• Requiere una breve justificación de la selección (una oración)
• Proporciona directrices claras: "Selecciona la respuesta que mejor siga nuestras políticas internas, use tono apropiado y proporcione información precisa"

Un experto de dominio puede evaluar 40-60 pares por hora cuando la interfaz está bien diseñada. Para 1,000 pares, presupuesta 20-25 horas de tiempo de experto — típicamente distribuidas entre 3-5 expertos durante dos semanas.

Paso 3: Formatear como Pares DPO

Convierte las salidas clasificadas al formato estándar de tripleta DPO: prompt, elegida, rechazada. Si los expertos clasificaron más de dos respuestas, crea múltiples pares del mismo prompt (la respuesta mejor clasificada vs cada una de las clasificaciones inferiores).

Valida el formato: asegúrate de que no haya campos vacíos, ni respuestas truncadas, y codificación consistente. Elimina cualquier ejemplo donde las respuestas elegida y rechazada sean casi idénticas — el modelo no puede aprender de pares con diferencias despreciables.

Paso 4: Verificación de Calidad con Acuerdo Entre Anotadores

Si múltiples expertos anotaron los mismos ejemplos, calcula el acuerdo entre anotadores. Para datos de preferencia, un kappa de Cohen por encima de 0.7 indica acuerdo fuerte. Por debajo de 0.5, las directrices son ambiguas y necesitan revisión.

Los desacuerdos son informativos. Si dos expertos discrepan sobre qué respuesta es preferida, examina por qué. Causas comunes: directrices ambiguas, casos límite no cubiertos por la política o diferencias genuinas de opinión experta. Resuelve desacuerdos a través de discusión, no por voto mayoritario — el objetivo es clarificar el estándar, no disimular inconsistencias.

Paso 5: Exportar

Exporta los pares validados como JSONL en el formato que tu framework de entrenamiento espera. Para la mayoría de las implementaciones DPO (TRL, Axolotl, LLaMA-Factory), el formato es:

{"prompt": "...", "chosen": "...", "rejected": "..."}

Divide en conjuntos de entrenamiento (85%) y validación (15%). El conjunto de validación se usa para monitorear la pérdida de entrenamiento DPO — si la pérdida de validación diverge de la pérdida de entrenamiento, estás sobreajustando a los datos de preferencia.

Por Qué Esto Debe Ser On-Premise

Los datos de preferencia son posiblemente más sensibles que los datos de entrenamiento crudos de los que se derivan. Aquí está por qué.

Los pares elegidos/rechazados revelan lo que la organización considera "bueno" — sus estándares de calidad, umbrales de cumplimiento, tolerancia al riesgo y normas de comunicación. Un competidor con acceso a tus datos de preferencia sabe exactamente cómo tu organización toma decisiones y qué prioriza.

Las respuestas rechazadas son particularmente reveladoras. Muestran lo que la organización considera inaceptable — los modos de fallo, las violaciones de cumplimiento, las respuestas dañinas para la marca. Esto es un manual para ataques adversariales contra los sistemas de IA de la organización.

En industrias reguladas, los datos de preferencia a menudo codifican decisiones de cumplimiento. Los datos de preferencia de una institución financiera muestran cómo interpreta la orientación regulatoria — qué respuestas pasan la revisión de cumplimiento y cuáles no. Esta es interpretación regulatoria propietaria que los competidores gastan millones desarrollando.

Ningún servicio en la nube, por fuertes que sean sus garantías de seguridad, debería tener acceso a estos datos. El pipeline de preparación se ejecuta en infraestructura local, con LLMs locales para aumento, y exporta a almacenamiento local.

Uso de LLMs Locales para Generación de Respuestas Candidatas

Los expertos de dominio no deberían escribir respuestas desde cero. En su lugar, usa un LLM local para generar 3-5 respuestas candidatas por prompt, luego haz que los expertos seleccionen la mejor y la peor.

Ejecuta Ollama con un modelo capaz de seguir instrucciones. Para cada prompt, genera respuestas con temperaturas variables (0.3, 0.7, 1.0) para obtener un rango desde conservador hasta creativo. También genera respuestas con diferentes system prompts — uno que enfatice brevedad, uno que enfatice exhaustividad, uno que sea deliberadamente defectuoso (para ejemplos rechazados).

Este enfoque produce 3,000-5,000 respuestas candidatas de 1,000 prompts. El tiempo de revisión de expertos baja de "escribir respuestas" a "seleccionar y comparar", reduciendo el esfuerzo aproximadamente a la mitad.

Requisitos de Escala

DPO es eficiente relativo a RLHF, pero aún requiere un volumen significativo de pares de preferencia.

Mínimo viable: 500 pares. Suficiente para ver mejora direccional en un comportamiento específico (por ejemplo, reducir tono excesivamente informal). No suficiente para alineación completa.

Recomendado: 2,000-3,000 pares. Cubre las principales dimensiones de comportamiento — tono, precisión, cumplimiento, divulgación y seguridad. Este es el punto óptimo para la mayoría de los despliegues empresariales.

Completo: 5,000+ pares. Requerido cuando el modelo sirve a múltiples grupos de usuarios con diferentes requisitos (por ejemplo, un modelo que sirve tanto a soporte al cliente como a flujos de trabajo de analistas internos).

Por debajo de 500 pares, la señal de entrenamiento DPO es demasiado débil para producir cambios de comportamiento consistentes. Por encima de 5,000, necesitas verificar que los pares no sean contradictorios — señales de preferencia conflictivas degradan el modelo.

Errores Comunes

Pares obvios: Si la respuesta elegida es claramente mejor por cada métrica, el modelo no aprende nada útil. Los pares más efectivos son aquellos donde ambas respuestas son razonables pero una es preferida por una razón específica. Las distinciones sutiles producen la señal de alineación más fuerte.

Estándares inconsistentes: Si el Experto A prefiere respuestas concisas y el Experto B prefiere respuestas detalladas, el dataset resultante contiene señales contradictorias. Alinea las directrices antes de que comience la anotación, no después.

Ignorar la distribución: Si el 80% de tus pares abordan tono y el 5% abordan precisión, el modelo se alineará fuertemente en tono pero débilmente en precisión. Equilibra los pares entre las dimensiones de comportamiento que te importan.

Datos obsoletos: Las políticas cambian, las regulaciones se actualizan, la voz de marca evoluciona. Un dataset de preferencia de hace 12 meses puede codificar estándares desactualizados. Planifica actualizaciones trimestrales.

La alineación DPO es un problema de calidad de datos, no de cantidad de datos. Mil pares de preferencia cuidadosamente elaborados superarán a diez mil descuidados. Invierte el tiempo en revisión de expertos, y los resultados de alineación seguirán.

Lectura Adicional

• Calidad de Datos Sobre Cantidad: Por Qué 250 Buenos Ejemplos Superan a 10,000 Malos — El caso para la construcción de datasets priorizando la calidad, con evidencia.
• Los Expertos de Dominio Deberían Ser Dueños del Etiquetado de Datos — Por qué los expertos en la materia producen mejores datos de entrenamiento que equipos de anotación externalizados.
• Preparación de Datos On-Premise y la Ley de IA de la UE — Impulsores regulatorios para mantener los flujos de trabajo de preparación de datos en infraestructura local.