Por qué tu dataset de fine-tuning no funcionará para IA on-device — y cómo solucionarlo

Ajustaste un modelo de 70B con tus datos empresariales. Funciona bien. Ahora lo destilas en un modelo de 0.5B para despliegue en NPUs móviles. La precisión cae de 92% a 61%.

Este no es un problema de destilación. Es un problema de datos.

La mayoría de los datasets de fine-tuning hoy están optimizados para modelos grandes. Los ejemplos son largos, complejos, y asumen que el modelo tiene miles de millones de parámetros para codificar patrones matizados. Cuando comprimes ese conocimiento en un modelo con 140 veces menos parámetros, el dataset se convierte en una desventaja en lugar de un activo.

La solución no son mejores técnicas de destilación. Es construir datasets que estén diseñados para el modelo objetivo desde el inicio.

Por qué los Datasets de Modelos Grandes Fallan a Escala Pequeña

Un modelo de 70B tiene aproximadamente 70 mil millones de parámetros. Un modelo de 0.5B tiene 500 millones. Eso es una proporción de 140:1. Considera lo que eso significa para la capacidad de aprendizaje.

Límites de cabezas de atención. Un modelo de 70B podría tener 64 cabezas de atención a lo largo de 80 capas. Un modelo de 0.5B podría tener 16 cabezas a lo largo de 24 capas. Las cadenas de razonamiento complejas de múltiples pasos que un modelo de 70B maneja sin esfuerzo exceden la capacidad de atención de un modelo de 0.5B. Los ejemplos de entrenamiento que requieren razonamiento de 5 pasos desperdician capacidad en un modelo que puede manejar confiablemente 2-3 pasos.

Restricciones de ventana de contexto. Los modelos grandes en producción frecuentemente usan contextos de 8K-32K tokens. Los modelos on-device típicamente operan con contextos de 512-2048 tokens debido a restricciones de memoria. Si tus datos de entrenamiento promedian 3,000 tokens por ejemplo, el modelo aprende patrones que se extienden más allá de su ventana de contexto en producción. Está aprendiendo habilidades que nunca podrá usar.

Utilización de vocabulario. Los modelos pequeños tienen vocabularios efectivos más reducidos. La jerga técnica, terminología rara y abreviaturas específicas de dominio que un modelo de 70B maneja a través de su espacio de embeddings masivo se convierten en ruido para un modelo de 0.5B. Datos de entrenamiento con 50,000 tokens únicos le piden a un modelo pequeño que distribuya su capacidad limitada demasiado finamente.

Sensibilidad a la distribución. Un modelo de 70B maneja el desbalance de clases con gracia. Si 80% de los ejemplos de entrenamiento son categoría A y 20% son categoría B, el modelo grande aún aprende la categoría B adecuadamente. Un modelo de 0.5B en el mismo escenario puede efectivamente ignorar la clase minoritaria. El desbalance de distribución a escala pequeña produce modelos que solo funcionan para el caso mayoritario.

El Pipeline No Es Entrenar → Desplegar

El pipeline estándar de IA empresarial asume: preparar datos → entrenar modelo → desplegar. Esto funciona cuando el entrenamiento y el despliegue usan la misma arquitectura.

Para IA on-device, el pipeline real es:

1. Modelo profesor (70B+) define el techo de calidad
2. Generación de datos sintéticos usando el profesor, calibrados para el estudiante
3. Filtrado de datos para eliminar ejemplos más allá de la capacidad del estudiante
4. Fine-tuning del modelo estudiante (0.5B-8B)
5. Cuantización para el hardware objetivo (Q4/Q5/Q8)
6. Exportación de runtime (ExecuTorch, LiteRT, ONNX, Qualcomm AI Hub)
7. Validación on-device contra restricciones de producción

La preparación de datos abarca los pasos 2 y 3 — y estos pasos determinan el resultado más que el fine-tuning en sí. Un dataset bien preparado con hiperparámetros de fine-tuning mediocres supera a un dataset mal preparado con hiperparámetros óptimos a esta escala.

Cómo Se Ve la Preparación de Datos Consciente de Destilación

Paso 1: Define las restricciones objetivo antes de tocar los datos.

Antes de preparar un solo ejemplo de entrenamiento, documenta:

• Tamaño de modelo objetivo (0.5B, 1B, 3B, 8B)
• Hardware objetivo (Snapdragon NPU, Apple Neural Engine, Intel NPU, etc.)
• Ventana de contexto en producción (512, 1024, 2048 tokens)
• Presupuesto de latencia (¿qué tan rápida debe ser la inferencia?)
• Nivel de cuantización (Q4, Q5, Q8)

Estas restricciones moldean cada decisión de datos que sigue.

Paso 2: Genera datos sintéticos al nivel de complejidad correcto.

Usa tu modelo profesor (70B+) para generar ejemplos de entrenamiento, pero restringe la generación:

• Longitud máxima de salida: coincide con la ventana de contexto de producción del estudiante
• Profundidad de razonamiento: limita a cadenas de 2-3 pasos para modelos de menos de 1B, 3-5 pasos para 3B-8B
• Vocabulario: restringe a los términos que el modelo estudiante encontrará en producción
• Consistencia de formato: usa plantillas de salida idénticas en todos los ejemplos

Un profesor de 70B generando un análisis de contrato de 500 palabras es inútil para entrenar un modelo de 0.5B que producirá clasificaciones de 50 palabras en producción.

Paso 3: Filtra agresivamente.

Para modelos grandes, más datos generalmente es mejor. Para modelos de menos de 1B, más datos pueden ser activamente dañinos si diluyen la distribución.

Aplica:

• Filtrado por longitud: elimina ejemplos fuera del percentil 10-90 de tu distribución de entrada en producción
• Puntuación de complejidad: usa la perplejidad del propio modelo estudiante — ejemplos de alta perplejidad están más allá de su capacidad
• Deduplicación: a escala pequeña, los casi-duplicados consumen capacidad desproporcionada
• Puntuación de relevancia de dominio: califica cada ejemplo contra la tarea específica que el modelo realizará
• Aplicación de balance: asegura que las distribuciones de clases coincidan con las distribuciones esperadas en producción

Apunta a 5,000-20,000 ejemplos de alta calidad para un modelo de menos de 1B. Esto es contraintuitivo — pero 10,000 ejemplos perfectamente calibrados consistentemente superan a 100,000 ruidosos a esta escala.

Paso 4: Valida en hardware objetivo antes de escalar.

Toma tu dataset filtrado, ajusta una muestra pequeña (1,000 ejemplos), despliega en el dispositivo objetivo real, y mide el rendimiento del mundo real. Si la precisión está por debajo del umbral, el problema es casi siempre la distribución de datos — no la arquitectura del modelo ni los hiperparámetros de entrenamiento.

El Requisito On-Premise

Hay una complicación adicional para equipos empresariales: los datos fuente para estos datasets son generalmente sensibles. Notas clínicas, documentos legales, registros financieros, datos de negocio propietarios.

No puedes enviar 700GB de BOQs de construcción a una herramienta de anotación en la nube solo porque tu despliegue objetivo es on-device. La preparación de datos de entrenamiento debe ocurrir on-premise incluso cuando el modelo final corre on-device.

Esto crea un flujo de trabajo donde:

• La preparación de datos ocurre on-premise (sin egreso de datos)
• El fine-tuning ocurre en GPUs en la nube (pesos del modelo, no datos crudos)
• El despliegue ocurre on-device (los datos de inferencia permanecen locales)

Cada paso tiene un requisito de infraestructura diferente, pero el paso de preparación de datos — el que determina si el modelo on-device realmente funciona — debe estar completamente air-gapped.

Qué Hace Ertas Data Suite Aquí

Ertas Data Suite se ejecuta como una aplicación de escritorio nativa, completamente on-premise. Para preparación de datos de IA on-device específicamente:

El módulo Clean proporciona puntuación de calidad, filtrado por longitud y deduplicación calibrada al tamaño de tu modelo objetivo. Establece tus parámetros objetivo (0.5B, ventana de contexto 1024, cuantización Q4) y las puntuaciones de calidad se ajustan para señalar ejemplos que exceden la capacidad del modelo.

El módulo Augment genera datos de entrenamiento sintéticos usando LLMs locales, con restricciones de generación ajustadas a las especificaciones de tu modelo estudiante. Ningún dato sale del edificio. Sin llamadas a APIs en la nube. Los datos sintéticos están diseñados para el modelo que realmente los usará.

El módulo Export produce JSONL formateado para tu framework de fine-tuning, con metadatos que rastrean qué ejemplos pasaron qué filtros de calidad — para que puedas iterar sobre el dataset cuando el rendimiento on-device no cumple los objetivos.

Agenda una Llamada de Descubrimiento para discutir tus requisitos de preparación de datos de IA on-device y ver cómo Ertas Data Suite encaja en tu pipeline.