Cualquier equipo que empieza con fine-tuning choca tarde o temprano con la misma pared: los ejemplos reales y bien anotados escasean. Crear nuevos ejemplos a mano es caro y lento. La pregunta llega casi inevitablemente — ¿y si generamos los datos con un modelo?
Es una técnica legítima. La usan equipos de investigación y sistemas en producción. Pero tiene condiciones precisas en las que funciona y condiciones precisas en las que arruina silenciosamente el modelo que está ajustando. Este artículo desglosa ambas sin optimismo innecesario.
Qué son realmente los datos sintéticos (y qué no son)
Los datos de entrenamiento sintéticos para fine-tuning son ejemplos entrada–salida generados automáticamente, no capturados del comportamiento humano real. En la práctica esto significa una de tres cosas:
- Generación mediante teacher model — un modelo más potente (p. ej. una API frontier) recibe una instrucción y genera ejemplos para el modelo objetivo más pequeño. A veces se denomina inexactamente destilación, aunque no lo es en el sentido original.
- Augmentación de datos existentes — los ejemplos existentes se parafrasean, reformatean o amplían; se conserva el contenido semántico y se modifica la forma.
- Self-play y escenarios sintéticos — el modelo genera datos para sí mismo (o en el rol de profesor y alumno a la vez), típicamente para fine-tuning de reasoning o conversacional.
Importante: los datos sintéticos no son un sustituto del continued pretraining sobre textos de dominio en bruto. El continued pretraining construye la base de conocimiento mediante textos no etiquetados. Los datos sintéticos para SFT (supervised fine-tuning) enseñan al modelo formato y comportamiento, no conocimiento. Estas dos capas se complementan pero no se sustituyen.
Cuándo la sintética realmente ayuda
No todos los casos de uso disponen de suficientes datos reales. Estas son las situaciones en las que los datos sintéticos aportan valor real:
1. Tiene un seed set sólido pero pequeño. La investigación muestra que un modelo entrenado con mil ejemplos de alta calidad supera a uno entrenado con cien mil mediocres. Si dispone de 150–200 ejemplos reales bien trabajados, puede ampliarlos 10–50× con un teacher model manteniendo la distribución que buscaba. Esto funciona bien en tareas estructuradas con salidas verificables: extracción de entidades, clasificación, transformación de formatos.
2. Cubre la cola larga. Los datos reales tienen su distribución — algunos casos son frecuentes, otros raros. Un modelo entrenado solo con datos reales puede no manejar bien los casos extremos que apenas aparecieron en el histórico. Un teacher model puede cubrir esos casos extremos de forma deliberada.
3. Quiere transferir el reasoning de un modelo mayor. Este es el principio central del enfoque de destilación que popularizó DeepSeek — la cadena de razonamiento (chain-of-thought) de un modelo frontier se usa como señal de entrenamiento para un modelo más pequeño. El modelo pequeño no aprende a "saber" lo mismo, pero aprende a *razonar* de manera similar. Los resultados están demostrados: modelos de tamaño 7B–8B entrenados con datasets sintéticos de chain-of-thought pueden superar a modelos generalistas varias veces mayores en tareas de reasoning concretas.
4. Necesita augmentación de datos para edge cases de seguridad. El red-teaming y la generación de ejemplos adversariales — donde quiere mostrarle al modelo lo que *no debe* hacer — es otro caso de uso legítimo de la sintética. Los ejemplos reales de fallo son escasos; un teacher sintético puede generarlos de forma sistemática.
Véase también: Dataset para fine-tuning: cuántos ejemplos y qué calidad necesita realmente para recomendaciones cuantitativas sobre el tamaño del dataset.
Los principales riesgos: cuándo envenenan el modelo
Los datos sintéticos tienen tres categorías de riesgo, cada una capaz de degradar el modelo silenciosamente.
Riesgo 1: Propagación de errores del teacher
El teacher model no es infalible. Tiene sus propios patrones de alucinación, puntos ciegos, preferencias de formulación. Cuando genera mil ejemplos y los entrena sobre el modelo objetivo, este no aprende solo la distribución deseada — también aprende los quirks del teacher. En pequeña dosis es tolerable. Con datasets sintéticos grandes y sin filtrado, el resultado es un modelo que repite con confianza errores que usted ni siquiera puede identificar (porque son errores del modelo, no de personas).
Ejemplo real: un cliente de documentación técnica tenía un teacher model que nombraba sistemáticamente un tipo de componente eléctrico con su denominación comercial antigua. Después de mil ejemplos generados, el modelo objetivo mostraba un sesgo sutil pero consistente hacia esa nomenclatura obsoleta — aunque ese patrón no existía en los datos semilla.
Riesgo 2: Model collapse
Este es técnicamente el riesgo más grave y un área de investigación activa. El model collapse ocurre cuando un modelo entrenado con datos sintéticos del mismo modelo (o de modelos similares) pierde progresivamente variabilidad y converge hacia una distribución de salidas estrecha. Las salidas son fluidas, formalmente correctas — pero el modelo ha dejado de cubrir el rango de entradas reales.
La intuición: si el teacher genera datos que son la respuesta distribuida del mismo modelo (o de su predecesor), cada iteración de entrenamiento amplifica los patrones centrales y debilita los extremos. Tras varios ciclos, el modelo responde bien a las entradas promedio y deja de procesar correctamente formulaciones inusuales, edge cases o datos fuera de la distribución de entrenamiento.
En sistemas en producción esto se manifiesta así: el modelo "funciona" en los tests (que cubren los casos comunes), pero en producción los usuarios se quejan de que a veces reciben respuestas genéricas o sin sentido — precisamente en las preguntas extremas.
Protección: nunca entrene exclusivamente con sintética. Los datos con semilla humana deben constituir al menos un ~20–30 % del dataset y deben cubrir la diversidad de entradas — no solo los casos promedio. La evaluación sistemática sobre entradas out-of-distribution antes del despliegue es obligatoria.
Riesgo 3: Restricciones de licencia y ToS
Este riesgo es menos técnico pero clave para uso B2B. La mayoría de los modelos frontier (Claude, GPT, Gemini) tienen en sus condiciones de servicio restricciones explícitas sobre la generación de datos de entrenamiento para modelos competidores. Las formulaciones concretas varían y cambian — lea siempre los ToS actuales del proveedor concreto.
En la práctica: si usa una API comercial como teacher model y el modelo objetivo lo va a distribuir comercialmente o desplegar para clientes, necesita tener clarificada la base legal. Para despliegue interno en su propia infraestructura la situación es diferente, pero no automáticamente limpia.
La vía segura: los modelos open-weight (Qwen, Mistral y otros con licencia Apache 2.0 o MIT) generalmente permiten la generación de datos sintéticos — pero cada modelo tiene sus propias condiciones, verifíquelas siempre antes de desplegar. Si quiere un pipeline sintético legalmente limpio sin interrogantes, tanto el teacher como el student model deberían pertenecer a familias con licencias permisivas.
Generación mediante teacher model — procedimiento práctico
Asumimos que dispone de 100–200 ejemplos semilla de calidad y quiere ampliarlos.
1. El seed set es la base — no lo reduzca. Esos 150 ejemplos deben cubrir la distribución que quiere. Si el seed set cubre solo un tercio del espacio de casos de uso, el dataset ampliado sintéticamente cubrirá ese mismo tercio — simplemente más grande.
2. Prompt engineering para el teacher. El teacher debe recibir instrucciones explícitas sobre el formato, el estilo, el dominio y lo que quiere *evitar*. Prompt vago = datos vagos. Un buen prompt para el teacher incluye: pares entrada–salida de ejemplo del seed set, el formato de respuesta requerido, la terminología de dominio que quiere priorizar y ejemplos negativos (qué evitar).
3. Genere más de lo que necesita — y filtre. Genere 3–5× más ejemplos de los que planea usar. Después filtre: - Validación automática de formato (JSON correcto, estructura correcta) - Deduplicación basada en embeddings (los ejemplos demasiado similares no aportan nada) - Puntuación de relevancia — bien con otro modelo como judge, bien con comprobadores basados en reglas si tiene salidas verificables - Revisión humana por muestreo de al menos el 5–10 % de los ejemplos generados
4. Mezcle con datos reales. El dataset final debería contener los datos semilla (100 %) + datos sintéticos (10–50× más, tras filtrado). Conserve el identificador de origen en los metadatos del dataset — lo agradecerá durante el debugging.
5. Evalúe sobre un holdout set de datos reales. Esto es crítico. El eval set no debe contener ejemplos sintéticos. Si no evalúa el modelo con evaluación humana real, nunca sabrá si la sintética introdujo drift.
Para más información sobre evaluación, véase Cómo medir si el fine-tuning ha funcionado.
Datos sintéticos vs. destilación de modelo — diferencia importante
Estos conceptos se mezclan en la práctica, pero no son lo mismo.
La destilación de modelo en el sentido original consiste en entrenar un modelo más pequeño para imitar la distribución de salida del mayor. Eso implica comparar distribuciones mediante divergencia KL, acceso a los logits del teacher, y todo el espectro de técnicas de knowledge distillation de la literatura académica.
La generación de datos sintéticos a partir de un teacher model es un enfoque más pragmático: el teacher model genera ejemplos texto entrada–salida, y estos se usan como un dataset SFT convencional. No se usan los logits del teacher, no se calculan similitudes distribucionales — solo se generan ejemplos. El resultado es inferior a la destilación completa, pero es realizable sin acceso a los internos del modelo y sin frameworks especiales.
En la práctica, la mayor parte de la "destilación" en proyectos comerciales ocurre exactamente mediante este segundo enfoque — porque el acceso a los logits de un modelo frontier no está disponible a través de la API estándar. Los resultados son no obstante demostrables: véanse los modelos DeepSeek-R1 destilados, que transfirieron capacidades de reasoning a modelos de 1.5B–8B mediante datos sintéticos de chain-of-thought.
Para una visión más profunda de la destilación como técnica: Destilación de modelos.
Augmentación vs. generación — cuándo usar cada una
La augmentación de ejemplos existentes (reformateo, paráfrasis, cambio de estilo) es un enfoque más seguro que la generación pura — conserva los hechos del seed set y solo modifica la forma. Es adecuada cuando:
- Sus datos semilla son factualmente fiables (p. ej. documentación técnica, sus propios procesos internos)
- Quiere enseñar al modelo a responder a distintas formas de formular la misma pregunta
- No tiene motivo para introducir hechos nuevos fuera del seed set
La generación pura (el teacher model crea ejemplos completamente nuevos) es más potente pero más arriesgada — el teacher puede introducir hechos que el seed set no contiene, y usted puede no detectarlo sin revisión humana.
Enfoque combinado: augmentación para ~60 % del dataset sintético, generación pura para ~40 % (para cubrir escenarios de long-tail) — con una tasa de revisión humana más alta en los ejemplos generados.
Cuándo no usar datos sintéticos
Hay situaciones en las que los datos sintéticos no solo no ayudan, sino que causan daño activo:
Hechos y valores numéricos precisos. Si el fine-tuning debe enseñar al modelo números de producto concretos, precios, parámetros técnicos — el teacher model los inventará. Este es el entorno clásico de alucinaciones. Para conocimiento factual la técnica correcta es RAG o continued pretraining sobre textos verificados, no SFT sobre sintética.
Dominios regulados sin validación experta. En contextos legales, médicos o financieros, los ejemplos generados sintéticamente pueden contener errores factuales que a un experto real le costaría cero tiempo detectar, pero que el modelo entrenado replicará con plena confianza. Si no tiene revisión experta de cada ejemplo generado, no use sintética aquí.
Cuando no tiene ningún dato semilla. La sintética sin dataset semilla es generación desde cero — obtendrá una distribución que refleja al teacher, no su dominio. Antes de generar debe tener al menos una base pequeña, real y bien anotada.
Información con sensibilidad temporal. El teacher model tiene un knowledge cutoff. Los ejemplos sintéticos sobre eventos actuales, legislación reciente o mercado actual estarán desactualizados, y usted no lo sabrá a menos que implemente un pipeline sistemático de fact-checking.
Filtrado y quality gates — pasos concretos
El filtrado es donde se decide si el dataset sintético ayudará o perjudicará. Quality gate mínimo:
- 1.Validación de formato — automática, 100 % de los ejemplos. Descarte los ejemplos con formato incorrecto, campos faltantes o valores inválidos.
- 2.Deduplicación — búsqueda de similitud basada en embeddings; los ejemplos con cosine similarity > 0.92 respecto a ejemplos existentes se descartan (o se elige un representante).
- 3.Puntuación de relevancia — si tiene salidas verificables (código, JSON, SQL), ejecute comprobación sintáctica. Si no, use model-as-judge con rúbrica explícita; no un prompt genérico del tipo "¿es esto bueno?".
- 4.Análisis distribucional — compare la distribución de temas, longitudes y formatos del dataset sintético frente al seed set. Las desviaciones notables señalan drift.
- 5.Revisión humana por muestreo — mín. 5 % de los ejemplos con criterio rotativo (no evalúe siempre los mismos tipos). Céntrese en: hechos, tono, edge cases.
Para más contexto sobre por qué la calidad de los datos importa más que la cantidad: 7 razones por las que el fine-tuning falla.
Preguntas frecuentes
¿Cuántos ejemplos sintéticos puedo añadir a los datos reales sin riesgo?
No existe una proporción fija válida para todos los casos. Un punto de referencia práctico: los ejemplos sintéticos no deberían superar el 70–80 % del dataset total si no se dispone de filtrado robusto y revisión humana. Con una proporción mayor, el riesgo de model collapse crece. Los datos semilla siempre deben estar presentes y deben cubrir toda la distribución del espacio de casos de uso — no solo los casos comunes.
¿Puedo usar ChatGPT / Claude para generar datos de entrenamiento para mi modelo?
Depende del uso. Para despliegue interno empresarial (el modelo corre en su infraestructura y no se distribuye comercialmente) la situación es diferente de la de un producto comercial. Lea siempre los ToS actuales del proveedor concreto — las formulaciones cambian. Para un pipeline comercialmente limpio recomendamos modelos teacher open-weight (Llama, Qwen, Mistral) con licencia permisiva.
¿Es la generación mediante teacher model lo mismo que la destilación de modelo?
No. La destilación en el sentido original trabaja con logits (la distribución de probabilidades) del teacher. La generación de datos sintéticos mediante la API del teacher es una variante más pragmática — se obtienen ejemplos de texto, no señal distribucional. Los resultados son inferiores a la destilación completa, pero realizables sin acceso a los internos del modelo. En proyectos comerciales esta variante es la más habitual precisamente por su accesibilidad.
¿Qué pasa si el teacher model genera ejemplos factualmente incorrectos?
Es el problema estándar y el principal argumento para la revisión humana por muestreo. El teacher model alucina — menos que los modelos pequeños, pero no llega a cero. Solución: las tareas verificables (código, JSON, SQL) se comprueban automáticamente; los hechos en texto no estructurado requieren revisión humana. Si no tiene capacidad para revisión humana, limite la sintética a la augmentación de ejemplos verificados existentes — no a la generación de hechos nuevos.
¿Ayudan los datos sintéticos si el modelo no sabe nada de mi dominio?
En raras ocasiones. La sintética puede ampliar y diversificar un seed set existente — no puede sustituir la base de conocimiento de dominio. Si el modelo no tiene ninguna base de dominio, el camino correcto es continued pretraining sobre textos de dominio (manuales, normas, documentos internos), y solo después SFT — sintético o real.
*MP Industrial Solutions toma estas decisiones a diario para clientes de fabricación, energía y logística. Si está analizando qué combinación de datos reales y sintéticos tiene sentido para su modelo y caso de uso concreto, estaremos encantados de revisarlo juntos.*