Cuando una empresa afronta por primera vez el fine-tuning de un modelo de lenguaje propio, generalmente se centra en la parte técnica: qué modelo, qué framework, qué GPU. El dataset se aborda después — y ahí es exactamente donde suele surgir el problema. Hemos visto proyectos en los que se invirtieron varios días de tiempo de GPU para que el modelo resultante acabase en el cajón. No porque el método fuese malo, sino porque los datos no se prepararon con el cuidado necesario.
Este artículo trata específicamente de la preparación del dataset: cuántos ejemplos necesita realmente, cómo medir la calidad, qué hacer con los duplicados, cómo configurar el split de entrenamiento y evaluación, y por qué existe algo llamado data-sufficiency gate antes de lanzar el entrenamiento.
Por qué el dataset importa más que el método
El fine-tuning es en esencia sencillo: muestre al modelo cómo debe responder en un contexto concreto, suficientes veces como para que lo interiorice. El problema surge cuando lo que le muestra no es lo que realmente quiere — o cuando se lo muestra demasiado pocas veces, o demasiadas veces lo mismo.
La investigación en entrenamiento de modelos de lenguaje ha demostrado repetidamente que la calidad pesa más que la cantidad. Un conjunto de 1 000 ejemplos cuidadosamente preparados, diversos y correctos puede producir un modelo mejor que 50 000 ejemplos generados a toda prisa con errores sistemáticos. No es intuitivo — la mayoría de los equipos técnicos buscan instintivamente mayor volumen.
Peor que los datos insuficientes es, sin embargo, la mala calidad con volumen suficiente. Un modelo entrenado con ejemplos erróneos, sesgados o contradictorios fija esos errores como verdad. Y dado que el fine-tuning aumenta la confianza del modelo en los patrones aprendidos, el resultado es un modelo que responde con seguridad a preguntas en las que debería dudar o decir "no sé". En dominios como el derecho, la medicina o el asesoramiento financiero, esto es un problema grave.
Mínimos de orden de magnitud: SFT, DPO y GRPO
No todos los fine-tuning son iguales. Los tres enfoques principales tienen requisitos de datos diferentes:
SFT (Supervised Fine-Tuning) es el método base: el modelo recibe pares entrada–salida y aprende a imitarlos. Los resultados funcionales son alcanzables desde aproximadamente 1 000 ejemplos de alta calidad, pero para sistemas en producción se trabaja típicamente con 10 000 a 100 000 pares. Lo importante es que cubran los escenarios principales del dominio — no solo los más frecuentes.
DPO (Direct Preference Optimization) requiere pares de preferencia: para cada entrada tiene una respuesta "mejor" y una "peor". El modelo aprende qué es lo que usted prefiere. Esto requiere anotación por personas reales o una evaluación automática fiable. El mínimo recomendado son aproximadamente 2 000 pares de preferencia con resultados verificados por humanos. Por debajo de ese umbral existe el riesgo de que el modelo aprenda los artefactos del proceso de anotación en lugar de las preferencias reales.
GRPO y recompensas verificadas son adecuados para tareas con respuestas correctas verificables — matemáticas, código, lógica, formatos con esquema definido. El mínimo aquí es aproximadamente 1 000 trayectorias puntuadas, pero el requisito clave es que la recompensa sea genuinamente objetiva y verificable automáticamente. Si define la recompensa de forma manual y subjetiva, obtendrá los mismos problemas que con un dataset DPO malo.
Estas cifras son mínimos para la funcionalidad básica, no garantías de calidad. Para despliegues en producción en sectores regulados (derecho, medicina, farmacia) aplica un estándar más estricto: cobertura completa de todos los escenarios y jurisdicciones objetivo, no solo una muestra representativa.
Qué significa un ejemplo de calidad
Antes de hablar de volumen, hay que definir qué se quiere de cada ejemplo individual.
Un ejemplo SFT de calidad tiene estas propiedades:
- Corrección: la salida es factualmente correcta y corresponde al contexto de la entrada
- Consistencia: la misma entrada (o una formulación equivalente) obtiene la misma categoría de respuesta
- Representatividad: el ejemplo cubre un escenario real, no solo un caso de prueba artificial
- Claridad: el modelo entiende inequívocamente qué se espera de él — sin ambigüedad
- Longitud apropiada: ni innecesariamente corto (patrones vacíos) ni innecesariamente largo (el modelo se pierde)
Problemas típicos que vemos en la práctica:
- Salidas copiadas de documentos existentes sin editar — contienen errores del documento original
- Ejemplos generados por un LLM sin revisión humana — el modelo aprende las alucinaciones de otro modelo
- Formato inconsistente — a veces JSON, a veces Markdown, a veces texto libre para el mismo tipo de tarea
- Entradas superpuestas con salidas distintas — el modelo recibe señales contradictorias
Formato del dataset y estructura del archivo
La mayoría de los frameworks modernos (Unsloth, Axolotl, LLaMA-Factory, TRL) aceptan formatos estándar. Los más utilizados son:
Formato Alpaca para tareas de instrucción: cada ejemplo tiene los campos instruction, input (opcional) y output. Sencillo y bien soportado.
Formato ShareGPT / conversacional para modelos de chat: los ejemplos son conversaciones con una lista de mensajes, donde cada uno tiene un rol (system, user, assistant). Más adecuado para escenarios multi-turno.
JSONL (un objeto JSON por línea) es el formato de archivo preferido por la mayoría de herramientas — permite la carga en streaming de datasets grandes sin cargar el archivo completo en memoria.
Al preparar un dataset DPO se añade un campo: típicamente chosen y rejected (o denominaciones equivalentes según el framework) para cada prompt de entrada.
Deduplicación — el paso infravalorado
Los ejemplos duplicados o casi duplicados son uno de los problemas más frecuentes en datasets construidos de forma automática o a partir de documentación empresarial. El efecto es doble: el modelo aprende de forma desproporcionada los patrones contenidos en los duplicados (sobreajuste a un subconjunto de datos) y la evaluación se sesga si los duplicados acaban tanto en el conjunto de entrenamiento como en el de test.
Las deduplicaciones básicas trabajan sobre coincidencia exacta (hash del texto de entrada). Los enfoques más avanzados utilizan MinHash o similitud de embedding para detectar duplicados semánticos — es decir, ejemplos que están formulados de forma diferente pero tienen el mismo contenido.
Para datasets de dominio recomendamos al menos estos pasos:
- 1.Deduplicación exacta por hash de la salida
- 2.Verificación de que distintas formulaciones de la misma entrada llevan a salidas consistentes
- 3.Eliminación de ejemplos donde tanto la entrada como la salida son más cortos que un umbral mínimo significativo (p. ej., respuestas demasiado cortas)
Herramientas como la librería datasets de Hugging Face o datasketch (implementación MinHash) cubren estos pasos sin necesidad de escribir código propio.
Split train/eval: cifras y lógica
Dividir el dataset en conjunto de entrenamiento y evaluación es lo básico, pero en la práctica se cometen errores innecesarios.
La división estándar 80 % entrenamiento / 20 % evaluación funciona, pero para datasets pequeños (por debajo de ~5 000 ejemplos) es mejor usar 90/10 y complementar el conjunto de evaluación con validación cruzada múltiple o un conjunto de test hold-out separado.
Regla fundamental: ningún ejemplo del conjunto de evaluación puede estar en el de entrenamiento — ni su duplicado semántico. Si hace deduplicación, hágala antes del split, no después.
Para datasets de fine-tuning de dominio recomendamos que el conjunto de evaluación contenga: - Una muestra representativa de los escenarios principales (misma distribución que el entrenamiento) - Algunos edge cases y situaciones límite deliberados - Ejemplos donde la respuesta correcta es "no sé" o "información insuficiente" — si eso es lo que espera del modelo
El conjunto de evaluación sirve para dos cosas: medir el rendimiento durante el entrenamiento (validation loss) y evaluación independiente después del entrenamiento. Para las decisiones en producción es más valiosa la segunda función — por eso el conjunto de evaluación debería estar verificado por humanos y no generado automáticamente.
Artículo relacionado sobre cómo medir los resultados tras el entrenamiento: Cómo medir si el fine-tuning ayudó.
Datos sintéticos: beneficios y riesgos
Para la mayoría de los proyectos de dominio, el volumen de datos creados por humanos existentes no es suficiente. La solución es ampliar el dataset con datos sintéticos — es decir, datos generados por un modelo más potente (frontier) a partir de ejemplos semilla humanos.
Receta típica: 150–200 ejemplos semilla escritos y verificados por humanos → generación de 10 a 100 veces ese volumen mediante un modelo teacher (Claude Opus, GPT-4o o un frontier similar) → revisión humana de una muestra (al menos 10–20 %) → filtrado por calidad.
Riesgos de los datos sintéticos:
- Colapso del modelo: si el dataset de entrenamiento consiste exclusivamente en datos generados sintéticamente por un único modelo teacher, el modelo fine-tuned copia sus debilidades y "quirks". La larga cola de escenarios reales queda sin cubrir.
- Alucinaciones del modelo teacher: el modelo teacher no es infalible — genera errores factuales que, sin revisión humana, entran en el entrenamiento.
- Sesgo de estilo: un modelo teacher potente tiene un estilo de respuesta marcado. Si no es el estilo deseado para su caso de uso, hay que corregirlo explícitamente tanto en el prompt como en la revisión.
Trabajar con datos sintéticos requiere más disciplina en el control de calidad, no menos. Más sobre este tema: Datos sintéticos para fine-tuning.
Data-sufficiency gate: no lance el entrenamiento antes de que los datos estén listos
Uno de los errores que vemos repetidamente es lanzar el entrenamiento con un dataset del que se sabe de antemano que está incompleto — con la idea de "lo completamos después". El problema es que un fine-tuning incompleto puede ser activamente perjudicial.
Un modelo entrenado con un dataset que cubre solo parte del dominio aprende a responder con alta confianza también a preguntas de la parte no cubierta. No tiene mecanismo para reconocer que "no sabe" algo — solo sabe lo que aprendió. El resultado es peor que el modelo base, que al menos sabe que no está especializado en el dominio.
Antes de lanzar el entrenamiento recomendamos verificar:
- 1.Cobertura de los escenarios principales: ¿tiene ejemplos para cada tipo clave de tarea que realizará el modelo?
- 2.Volumen mínimo: ¿cumple los mínimos de orden de magnitud para el método elegido (SFT, DPO, GRPO)?
- 3.Conjunto de evaluación de calidad: ¿tiene un conjunto de evaluación verificado por humanos, separado de los datos de entrenamiento?
- 4.Para sectores regulados: ¿cubre todas las jurisdicciones y escenarios objetivo — no solo una muestra representativa?
Esta lista de verificación no es burocracia — es un seguro contra que la inversión en entrenamiento acabe produciendo un modelo problemático. Más sobre la elección entre métodos: SFT, DPO, GRPO — qué método y cuándo.
Catastrophic forgetting: qué puede romper el fine-tuning
El fine-tuning sobre un dataset estrecho tiene un efecto secundario: el modelo puede olvidar parcialmente las capacidades que tenía antes del entrenamiento. Este fenómeno — llamado catastrophic forgetting (olvido catastrófico) — está avalado por la investigación y es real en la práctica.
LoRA y QLoRA mitigan este problema porque los pesos originales del modelo permanecen congelados y los adaptadores son relativamente pequeños. Pero ni los métodos PEFT lo eliminan por completo — con un entrenamiento demasiado agresivo (learning rate alto, dataset grande con distribución estrecha) la degradación de las capacidades generales se hace visible.
Consecuencias prácticas:
- Evalúe no solo en el conjunto de evaluación del dominio, sino también en benchmarks generales (al menos de forma informativa)
- Si el modelo falla tras el fine-tuning en tareas donde antes funcionaba, es una señal para ajustar la distribución de entrenamiento o los parámetros
- Para despliegues en producción, compare siempre el modelo fine-tuned con el modelo base en el mismo conjunto de tareas — no solo en el dominio
Lista de verificación antes del primer entrenamiento
Antes de lanzar el entrenamiento, repase esta lista:
- 1.El dataset está en formato estándar (Alpaca o ShareGPT JSONL)
- 2.La deduplicación exacta se ha realizado sobre todo el dataset
- 3.El split train/eval está hecho antes de cualquier otro procesamiento
- 4.El conjunto de evaluación no contiene duplicados semánticos del conjunto de entrenamiento
- 5.Al menos el 10 % del dataset ha pasado por revisión humana de calidad
- 6.La cobertura de escenarios está verificada — ninguna categoría clave está vacía
- 7.Los datos generados sintéticamente están marcados y su proporción en el dataset es una elección consciente
- 8.Para DPO: cada par de preferencia tiene definido el motivo por el que "chosen" es mejor que "rejected"
Esta lista no es exhaustiva, pero cubre las fuentes de problemas más frecuentes que vemos en clientes que afrontan su primer fine-tuning.
Preguntas frecuentes
¿Cuántos ejemplos mínimo necesito para SFT?
Los resultados funcionales son alcanzables desde aproximadamente 1 000 ejemplos de alta calidad — esta cifra proviene de investigaciones que han demostrado que ejemplos seleccionados cuidadosamente pueden superar a un dataset un orden de magnitud mayor pero de menor calidad. Para sistemas en producción recomendamos al menos 10 000 ejemplos con verificación de cobertura de los escenarios clave. Para sectores regulados aplican criterios más estrictos.
¿Puedo generar el dataset completo con un LLM?
Un dataset generado sintéticamente puede constituir la mayor parte del volumen, pero no el dataset completo. Necesita ejemplos semilla escritos y verificados por humanos (típicamente 150–200 como mínimo) y revisión humana de una muestra de los ejemplos generados sintéticamente. Un modelo entrenado exclusivamente en la salida de un único LLM teacher copia sus errores y debilidades sin corrección.
¿Cómo divido el dataset en conjunto de entrenamiento y conjunto de test?
La división estándar es 80 % entrenamiento / 20 % evaluación; para datasets pequeños de menos de 5 000 ejemplos, mejor 90/10. Regla clave: haga la deduplicación antes del split, no después. El conjunto de evaluación no puede contener duplicados semánticos del conjunto de entrenamiento — si no, está midiendo "capacidad de memorizar", no "capacidad de generalizar".
¿Qué hago si tengo pocos datos de dominio y no puedo completarlos sintéticamente?
En ese caso considere RAG en lugar de fine-tuning — RAG (Retrieval-Augmented Generation) no requiere datos de entrenamiento y funciona bien para escenarios donde necesita acceso al conocimiento, no un cambio en el estilo o formato de la respuesta. El fine-tuning es más adecuado cuando cambia el comportamiento del modelo, no su conocimiento.
¿Por qué el modelo responde peor tras el fine-tuning que antes?
Las causas más frecuentes: mala calidad del dataset (errores en los ejemplos, formato inconsistente), cobertura insuficiente de escenarios (el modelo "aprendió" solo parte del dominio y extrapola incorrectamente en el resto), o catastrophic forgetting con un entrenamiento demasiado agresivo. Una visión más detallada: 7 razones por las que el fine-tuning falla.
*La preparación del dataset es donde se decide el éxito de todo el fine-tuning — no en la elección del método ni de la GPU. Si está planificando su primer fine-tuning o no está satisfecho con los resultados de un intento anterior, en MP Industrial Solutions le ayudamos a evaluar la calidad y estructura de los datos antes de lanzar el entrenamiento.*