Datos sintéticos para entrenar IA: cuándo te dan ventaja… y cuándo provocan “model collapse”

INTELIGENCIA ARTIFICIAL · DATOS SINTÉTICOS · ENTRENAMIENTO

Si estás montando un sistema con IA y dudas entre RAG, fine-tuning o agentes, este tema conecta muchísimo con la decisión de arquitectura: no es lo mismo generar datos para entrenar un modelo que enriquecer contexto en tiempo real. Si quieres ese mapa completo, aquí lo tienes: RAG vs fine-tuning vs agentes: cómo elegir arquitectura.

1. Qué son (de verdad) los datos sintéticos

“Datos sintéticos” suena a algo falso, pero en la práctica es más simple: son datos que no vienen directamente del mundo (usuarios, sensores, logs), sino de un proceso de generación: simuladores, reglas, motores físicos, modelos generativos o una mezcla de todo eso.

Y aquí está el matiz que lo cambia todo: no todo sintético es igual. Hay sintético “bueno” (controlado, diverso, con etiquetas fiables) y sintético “barato” (rápido de producir, pero lleno de sesgos y repeticiones). En entrenamientos grandes, esa diferencia se nota muchísimo.

Una forma útil de clasificarlo:

• Sintético por simulación: generas datos con un modelo del mundo (física, tráfico, mercados, ciberataques, entornos 3D). Suele ser el más “limpio” si el simulador es bueno.
• Sintético por reglas/plantillas: combinas variables y formatos (por ejemplo, tickets de soporte, facturas, emails). Barato, pero cuidado con la monotonía.
• Sintético generativo: un modelo crea nuevos ejemplos (texto, imagen, código) a partir de prompts. Potentísimo… y el que más fácilmente cae en bucles.

2. Cuándo los sintéticos te dan ventaja (y se nota en métricas)

Hay escenarios donde los datos sintéticos no son “un apaño”. Son una ventaja competitiva. Estas son las cuatro situaciones más típicas:

A) Cuando el mundo real no te da suficientes ejemplos de lo raro

Fraude, fallos críticos, incidentes de seguridad, edge cases en visión… El problema es siempre el mismo: lo importante pasa poco. Si esperas a tener suficientes muestras reales, entrenas tarde y mal. El sintético te permite “fabricar” variedad: más combinaciones, más severidad, más contextos.

B) Cuando necesitas etiquetas fiables y consistentes

Etiquetar es caro, lento y a veces subjetivo. Con sintético bien diseñado, las etiquetas vienen “de fábrica”: sabes la intención, el entity linking, el dato correcto, el error introducido, etc. Esto es oro para entrenar tareas específicas (clasificación, extracción, detección).

C) Cuando la privacidad te limita (y aun así necesitas entrenar)

Si trabajas con salud, finanzas o datos internos, hay un techo claro: no puedes mover ciertos datos, ni compartirlos, ni usarlos alegremente para entrenar. Aquí el sintético puede ser una salida… pero con una condición: no basta con “parecer real”; tiene que preservar la estructura útil sin filtrar información sensible.

D) Cuando quieres robustez, no solo rendimiento medio

Muchos modelos parecen buenos hasta que cambias el formato, metes ruido, o llega un caso fuera de manual. Los sintéticos permiten entrenar “adversarialmente” con variaciones controladas: más estilos, más longitudes, más idiomas, más errores humanos. Si lo haces bien, el modelo deja de ser un alumno de examen y se vuelve más “de vida real”.

Ojo: si este punto te interesa, hay un primo hermano que suele destrozar proyectos por la puerta de atrás: métricas engañosas, evaluación contaminada y autoengaño colectivo. Aquí tienes una guía muy práctica para evitarlo: cómo evaluar un LLM sin autoengañarte (golden set, contaminación y métricas).

3. El punto oscuro: feedback loops (cuando el modelo se “come a sí mismo”)

Un feedback loop aparece cuando el entrenamiento empieza a alimentarse, directa o indirectamente, de salidas del propio modelo (o de modelos muy parecidos). No tiene por qué ser explícito. Pasa con cosas como:

• Generar millones de ejemplos con tu modelo actual y “re-entrenar para mejorar”.
• Rascar internet sin control, donde cada vez hay más contenido generado por IA mezclado con el humano.
• Usar datasets “curados” que, sin darte cuenta, ya vienen inflados de texto sintético repetido.

¿Cuál es el problema? Que el modelo no está viendo el mundo. Está viendo una versión comprimida y sesgada de su propio estilo de respuesta. Es como aprender historia leyendo siempre el mismo resumen, reescrito una y otra vez por diferentes personas: cada vuelta pierde matices, se cuelan errores, desaparecen excepciones y, al final, lo que queda es un “promedio” cómodo.

4. Qué es “model collapse” explicado sin humo

“Model collapse” es un nombre contundente para una idea muy concreta: si entrenas iterativamente con datos generados por modelos (sin ancla suficiente de datos reales y sin control), el modelo tiende a:

• Perder diversidad: se vuelve más repetitivo, más “plantilla”, más parecido a sí mismo.
• Olvidar lo raro: las colas de la distribución (los casos poco frecuentes) desaparecen primero.
• Amplificar errores: pequeños fallos pasan a convertirse en “verdad estadística”.
• Subir en algunas métricas y bajar en el mundo real: el síntoma más traicionero.

La metáfora que mejor funciona es una fotocopia: haces una copia de un documento, luego fotocopias la copia, y repites el proceso. Al principio se ve bien. Pero con cada iteración: se pierde detalle, aparecen artefactos y el texto se vuelve menos legible. Con datos sintéticos recursivos pasa algo parecido: la señal útil se “aplana” y los artefactos se vuelven parte del patrón.

Y si te preguntas “¿esto también afecta a alucinaciones?”, la respuesta corta es: puede empeorarlas, porque el sistema aprende a sonar convincente sin el freno de un mundo externo. Si quieres una guía directa sobre por qué ocurren (y cómo reducir riesgos), encaja muy bien con: errores típicos al usar IA: alucinaciones y privacidad.

5. Señales de alarma: cómo se ve el colapso antes de que sea tarde

Lo peligroso del “model collapse” es que no siempre llega como un crash. Muchas veces llega como una mejora aparente… hasta que lo sacas de tu laboratorio.

Estas señales suelen aparecer pronto:

• Respuestas más homogéneas: menos variedad de estilo, más “frases típicas”, más estructura repetida.
• Caída en conjuntos “difíciles”: el rendimiento se mantiene en test fácil, pero baja en casos raros o fuera de distribución.
• Mejora sospechosa en benchmarks internos: sobre todo si el propio pipeline de generación pudo “tocar” la evaluación.
• Drift semántico: el modelo empieza a preferir definiciones y explicaciones “de manual”, incluso cuando el usuario necesita contexto específico.

6. Reglas para usar datos sintéticos sin cargarte el modelo

Aquí va lo que realmente importa: una checklist que funciona en la práctica. No necesitas cumplir el 100% desde el día uno, pero sí entender qué estás rompiendo cuando te saltas algo.

1) Mantén un “ancla” real (y protégela)

Si todo lo que comes es sintético, el modelo acaba soñando con los ojos abiertos. Necesitas un núcleo de datos reales, representativos y limpios. Y algo igual de importante: no lo uses para generar sintético. Si tu ancla se mezcla con el generador, ya no es ancla.

2) Controla la proporción (y no te fíes del “ya veremos”)

No hay un número mágico, pero sí una idea: el sintético debe ser un suplemento con intención, no el grueso por defecto. Si el sintético supera al real, tu pipeline necesita controles más duros (filtros, scoring, diversidad, evaluación externa). Si no los tienes, estás jugando a la ruleta.

3) Genera para cubrir huecos, no para inflar volumen

La mejor pregunta antes de generar es: ¿qué casos no estoy cubriendo? Generar “más de lo mismo” solo consigue que el modelo aprenda más fuerte lo que ya sabía. El sintético bueno es quirúrgico: edge cases, formatos raros, ataques, errores humanos realistas, dominios con pocos ejemplos.

4) Filtra con modelos distintos (y con reglas simples)

Si generas y validas con el mismo modelo (o familia), el sesgo se retroalimenta. Una práctica sólida es usar: un “juez” distinto para filtrar (otro modelo, otro proveedor, o un clasificador dedicado), más reglas simples (deduplicación, detección de plantillas, límites de longitud, prohibición de frases muletilla).

5) Deduplica agresivamente y mide diversidad

La repetición es gasolina para el colapso. Deduplicación exacta y aproximada (paráfrasis), control de n-gramas, y métricas de diversidad (variedad de estructuras, entidades, estilos, longitudes) te ahorran disgustos. Si tus sintéticos “se parecen demasiado”, no es un halago: es un problema.

6) Evalúa con un golden set “sagrado”

Tu evaluación debe vivir en cuarentena: nada de usarla para generar, nada de “mirarla” durante el tuning, nada de reciclarla como ejemplos. Si no puedes proteger un conjunto de evaluación, estás entrenando a ciegas.

7. Un enfoque que suele funcionar: sintético como “entrenamiento guiado”

Si tuviera que resumir un enfoque sensato en una frase sería: usa sintético para enseñar comportamientos, no para reinventar conocimiento del mundo.

Ejemplos donde el sintético suele rendir muy bien:

• Formato y estructura: cómo responder con un esquema, cómo extraer campos, cómo seguir una plantilla de salida.
• Razonamiento procedimental: pasos de diagnóstico, checklists, flujos de decisión, atención a restricciones.
• Robustez al ruido: typos, mensajes incompletos, instrucciones contradictorias, cambios de idioma.

Y donde conviene ser mucho más conservador:

• Hechos del mundo: si el sintético mete errores, el modelo los aprende “con confianza”.
• Estilo generalista: si entrenas “a sonar bien”, el modelo puede volverse más convincente… sin ser más correcto.

8. Cierre: el truco está en el control, no en el volumen

Los datos sintéticos no son el villano. El villano es el “más es mejor” aplicado a ciegas: más ejemplos, más iteraciones, más reciclaje… hasta que el modelo deja de aprender del mundo y empieza a aprender de su reflejo.

Si te quedas con una idea práctica, que sea esta: todo sintético necesita una brújula. Esa brújula son datos reales ancla, evaluación limpia y controles de calidad y diversidad. Con eso, el sintético te da velocidad. Sin eso, te da un modelo que suena bien… y se equivoca con más tranquilidad.

La próxima vez que alguien te diga “vamos a generar un millón de ejemplos y listo”, ya tienes la contra-pregunta que separa un proyecto serio de un experimento peligroso: ¿cómo evitamos el feedback loop y cómo sabemos que no estamos colapsando?