
Generación de Datos Sintéticos Optimizada para Destilación de Modelos Pequeños
Al construir modelos de 0.5B-1B para despliegue en NPU móvil, la calidad de los datos sintéticos importa exponencialmente más que para modelos grandes. Así es cómo generar, filtrar y validar datos de entrenamiento sintéticos diseñados para destilación de modelos pequeños.
Construir un modelo de 0.5B parámetros para despliegue en NPU móvil es fundamentalmente diferente de construir un modelo de 70B para inferencia en la nube. El modelo es 140x más pequeño. Su tolerancia a datos de entrenamiento ruidosos o desalineados es cercana a cero. Y los datos sintéticos — que cada vez dominan más los datasets de fine-tuning — deben generarse con restricciones que la mayoría de los pipelines ignoran.
El enfoque estándar para datos sintéticos es: tomar un modelo teacher grande, generar ejemplos, usarlos para entrenar un student más pequeño. Esto funciona aceptablemente cuando el student es 7B-13B. Se desmorona cuando el student es 0.5B-1B, porque el teacher genera texto a un nivel de complejidad que el student fundamentalmente no puede reproducir.
Así es cómo hacerlo de manera diferente.
Por Qué los Datos Sintéticos Estándar Fallan para Modelos Sub-1B
Un modelo teacher de 70B generando una respuesta sintética de soporte al cliente podría producir una respuesta de 400 palabras con lógica condicional, enmarcado empático, resolución de problemas multi-paso y un cierre personalizado. Esa respuesta es excelente dato de entrenamiento para un modelo student de 13B.
¿Para un modelo de 0.5B? Es dato de entrenamiento para patrones que el modelo no puede aprender. El modelo de 0.5B no tiene la capacidad de parámetros para codificar empatía condicional, razonamiento multi-paso Y conocimiento del dominio simultáneamente. Aprenderá fragmentos de cada uno y no ejecutará ninguno bien.
El resultado: un modelo que genera respuestas que comienzan coherentemente y se degradan a mitad de oración. O un modelo que maneja bien el caso más común y falla catastróficamente en casos extremos. O un modelo que produce texto gramaticalmente correcto que en realidad no responde la pregunta.
Estos no son problemas del modelo. Son problemas de datos.
Selección del Modelo Teacher
Tu modelo teacher define el techo de calidad para tus datos sintéticos. Pero más grande no siempre es mejor.
Para objetivos sub-1B: Usa un teacher de 70B o más para calidad de generación, pero agrega un modelo de 7B como "filtro de complejidad". Si el modelo de 7B no puede reproducir la salida del teacher con similitud superior al 80%, el ejemplo es demasiado complejo para el student de 0.5B. Este enfoque de filtrado de dos modelos detecta problemas de complejidad que las métricas estadísticas no captan.
Para objetivos de 3B-8B: Un teacher de 70B es ideal. La brecha de capacidad es menor (10x-25x en lugar de 140x), así que la salida del teacher es más aprendible. Puedes usar ejemplos más amplios y complejos.
Temperatura y muestreo. Genera a temperatura 0.3-0.5 para objetivos sub-1B. Temperaturas más altas producen texto más diverso pero también más complejo. A escala de 0.5B, quieres consistencia sobre diversidad. Reserva la diversidad de temperatura para modelos student más grandes.
Estrategias de Filtrado Que Realmente Importan
Generar datos sintéticos es la parte fácil. Filtrarlos es donde se determina el resultado.
Coincidencia de distribución de longitud. Mide tu distribución de entrada en producción. Si los usuarios enviarán entradas de 50-200 tokens a tu modelo on-device, genera entradas de entrenamiento sintéticas en ese rango. Si tus salidas de producción son de 20-100 tokens, genera salidas sintéticas en ese rango. Los desajustes de longitud son la causa individual más común de falla de modelos on-device.
Puntuación de complejidad. Ejecuta cada ejemplo sintético a través del modelo student (o un modelo de tamaño similar) y mide la perplejidad. Los ejemplos de alta perplejidad están más allá de la capacidad del modelo. Establece un umbral de perplejidad — típicamente el percentil 75 de un conjunto de validación conocido como bueno — y descarta todo lo que esté por encima.
Puntuación de relevancia del dominio. No todos los ejemplos que genera el teacher son relevantes al tema. Incluso con prompting cuidadoso, el 10-15% de los ejemplos sintéticos se desviarán del dominio. Usa similitud de embedding contra un conjunto curado de ejemplos gold-standard para puntuar relevancia del dominio. Descarta el 20% inferior.
Deduplicación a escala. Los datos sintéticos de modelos de lenguaje grandes tienden a ser más repetitivos que los datos generados por humanos. El teacher tiene modos — frases y estructuras comunes a las que recurre por defecto. A escala de 0.5B, los casi-duplicados son particularmente dañinos porque sobrerepresentan ciertos patrones a expensas de la amplitud. Usa deduplicación MinHash o SimHash con un umbral de similitud de 0.85.
Aplicación de consistencia de formato. Si tu modelo de producción genera JSON, cada ejemplo de entrenamiento debe generar JSON válido. Si genera etiquetas de clasificación, cada ejemplo debe usar el vocabulario exacto de etiquetas. Tolerancia cero para variación de formato a escala sub-1B. Un ejemplo inconsistente puede introducir un modo de falla que afecta al 5% de las salidas de producción.
Los Números
Para un modelo de 0.5B-1B orientado a una tarea empresarial específica:
| Métrica | Enfoque ingenuo | Enfoque optimizado |
|---|---|---|
| Ejemplos sintéticos generados | 100,000 | 100,000 |
| Después de filtro de longitud | 100,000 | 65,000 |
| Después de filtro de complejidad | 100,000 | 40,000 |
| Después de relevancia de dominio | 100,000 | 32,000 |
| Después de deduplicación | 85,000 | 22,000 |
| Después de validación de formato | 80,000 | 20,000 |
| Conjunto de entrenamiento final | 80,000 | 20,000 |
| Precisión on-device | 61-68% | 84-91% |
El enfoque optimizado usa 75% menos ejemplos de entrenamiento y logra 20-30 puntos porcentuales más de precisión. Esto es consistente en múltiples dominios empresariales que hemos observado. Calidad sobre cantidad no es un cliché a escala sub-1B — es la estrategia completa.
El Bucle Iterativo
La generación de datos sintéticos para destilación de modelos pequeños no es un proceso de una sola vez. Es un bucle:
- Generar datos sintéticos con el modelo teacher
- Filtrar usando los criterios anteriores
- Ajustar el modelo student con el dataset filtrado
- Desplegar en el hardware objetivo (dispositivo real, no emulador)
- Medir métricas representativas de producción
- Analizar casos de falla
- Generar datos sintéticos dirigidos para los modos de falla
- Volver al paso 2
La mayoría de los equipos hacen los pasos 1-3 una vez y lanzan. Los equipos que logran precisión superior al 90% en modelos sub-1B hacen 3-5 iteraciones de este bucle, con cada iteración enfocándose en los modos de falla específicos revelados por las pruebas on-device.
Datos Empresariales y el Requisito On-Premise
Hay una restricción crítica que la mayoría de las guías de datos sintéticos ignoran: el conocimiento fuente para tus datos sintéticos es propiedad empresarial.
Si estás construyendo un modelo de triaje clínico para móvil, el modelo teacher necesita conocimiento médico específico de tu institución. Si estás construyendo un modelo de análisis de contratos para la app móvil de un bufete de abogados, el teacher necesita ejemplos de los patrones de contratos de ese bufete.
Esto significa ya sea ajustar el teacher con datos empresariales (lo que requiere preparación de datos on-premise) o usar RAG con documentos empresariales durante la generación (lo que requiere infraestructura on-premise).
De cualquier manera, el pipeline de generación de datos sintéticos debe ejecutarse on-premise. Tus 700GB de notas clínicas o contratos legales no pueden ir a una API en la nube para generar datos de entrenamiento sintéticos para un modelo on-device.
Cómo Ertas Data Suite Maneja Esto
El módulo Augment de Ertas Data Suite ejecuta generación de datos sintéticos usando LLMs locales en tu propio hardware. Sin egreso de datos. La generación se configura con restricciones del modelo objetivo — especifica objetivo de 0.5B, ventana de contexto de 512, cuantización Q4 — y los ejemplos sintéticos se calibran automáticamente.
El módulo Clean proporciona el pipeline de filtrado: análisis de distribución de longitud, puntuación de calidad, deduplicación y validación de formato. Cada decisión de filtro se registra con rastro de auditoría completo.
El módulo Export genera el dataset filtrado y validado como JSONL listo para fine-tuning. Los metadatos rastrean qué ejemplos pasaron qué filtros, así que cuando iteras (y vas a iterar), puedes rastrear mejoras de rendimiento hasta decisiones de datos específicas.
Agenda una Llamada de Descubrimiento para discutir estrategias de datos sintéticos para tu despliegue de AI on-device.
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading

Why Your Fine-Tuning Dataset Won't Work for On-Device AI — And How to Fix It
Most fine-tuning datasets are built for large cloud models. When distilled to 0.5B–1B models for mobile NPUs, the data distribution breaks. Here's why, and how to build datasets that actually work for on-device deployment.

The Cloud-to-Edge AI Pipeline: How Data Prep Fits Between Training and Deployment
The full cloud-to-edge AI pipeline spans raw data through on-device deployment. Data preparation is the step between raw enterprise data and cloud training — and it's where most edge AI projects fail.

From Teacher Model to Edge Device: A Data Prep Workflow for Model Distillation
A step-by-step workflow for preparing training data when your target is an edge device with constrained compute. From defining hardware constraints to validating on-device performance.