Cómo ML Intern convierte ideas en modelos listos para Hugging Face

El problema real en proyectos de ML

La mayoría de los proyectos de machine learning no fracasan por la elección del modelo: fallan en el “medio desordenado”. Ahí están las tareas que consumen tiempo: encontrar y entender el dataset correcto, validar usabilidad, escribir y depurar código de entrenamiento, interpretar logs, evaluar salidas y empacar el modelo para otros. ML Intern nace para ayudar en ese tramo intermedio, no solo para seleccionar y afinar modelos.

¿Qué es ML Intern?

ML Intern es un asistente open-source construido alrededor del ecosistema Hugging Face. Puede usar documentación, papers, datasets, repositorios, jobs y cómputo en la nube para avanzar una tarea de ML. A diferencia de AutoML tradicional, que está enfocada en la selección y ajuste de modelos, ML Intern apoya las tareas alrededor del entrenamiento: investigar enfoques, inspeccionar datos, generar scripts, corregir errores y preparar salidas para compartir. La analogía útil es pensar en AutoML como una máquina de construir modelos y en ML Intern como un compañero junior de ML que lee, planifica, codifica, corre y reporta —siempre con supervisión humana.

Objetivo del proyecto de prueba

Para poner a prueba ML Intern se definió una tarea práctica y completa: construir un modelo de clasificación de texto que etiquete tickets de soporte por tipo de problema, usando recursos públicos de Hugging Face. Requisitos del ejercicio:

• Usar un dataset público de Hugging Face.
• Afinar un transformer ligero.
• Evaluar con accuracy, macro F1 y una matriz de confusión.
• Preparar el modelo final para publicar en el Hugging Face Hub.
• No ejecutar entrenamientos costosos sin aprobación del usuario.

La intención fue probar si ML Intern puede acompañar todo el flujo —investigación, inspección de datos, generación de scripts, depuración, entrenamiento, evaluación, publicación y demo— y no solo generar fragmentos de código aislados.

Paso a paso: cómo trabajó ML Intern

Paso 1 — Prompt claro

El experimento comenzó con un prompt específico: describir el objetivo, el tipo de modelo, las métricas, el entregable final y una regla explícita de seguridad respecto al cómputo. Definir estos límites desde el inicio facilita que la herramienta actúe dentro de los parámetros esperados.

Paso 2 — Búsqueda y selección del dataset

ML Intern encontró y eligió el dataset público Bitext (Bitext-customer-support-llm-chatbot-training-dataset). Resumen de las características reportadas por la herramienta:

• Filas: 26,872
• Categorías: 11
• Intents: 27
• Longitud promedio de texto: 47 caracteres
• Valores faltantes: ninguno
• Duplicados: 8.3%
• Problema principal: desequilibrio moderado de clases

ML Intern identificó los campos útiles: instruction como texto de entrada, category como etiqueta de clasificación y intent como etiqueta más fina.

Paso 3 — Smoke testing y depuración

Antes de lanzar un entrenamiento completo, se generó un script de entrenamiento y se ejecutó una prueba con una muestra pequeña. La prueba detectó dos problemas prácticos: la columna de etiquetas requería conversión a ClassLabel y la función de métricas debía manejar casos donde el conjunto de prueba pequeño no contuviera las 11 clases. ML Intern aplicó las correcciones y confirmó que el script terminaba correctamente.

Paso 4 — Plan de entrenamiento y aprobación humana

Con el script validado, ML Intern propuso un plan de entrenamiento que incluyó:

• Modelo: distilbert/distilbert-base-uncased
• Parámetros: 67M
• Clases: 11
• Learning rate: 2e-5
• Épocas: 5
• Batch size: 32
• Métrica objetivo: Macro F1
• Coste GPU estimado: ~ $0.20

Este plan sirvió como punto de aprobación: ML Intern no lanzó el job automáticamente hasta recibir la orden.

Paso 5 — Revisión previa al entrenamiento

Se pidió una última revisión antes de proceder. Checklist ejecutado por ML Intern:

1. Riesgo de data leakage
2. Necesidad de manejo de desequilibrio de clases
3. Razonabilidad de los hiperparámetros
4. Expectativa de rendimiento baseline vs fine-tuned
5. Posibles casos de falla

Tras revisar esos puntos, la herramienta concluyó que la configuración estaba lista para entrenar.

Paso 6 — Control de cómputo y fallback a CPU

Al intentar lanzar el job en hardware GPU de Hugging Face, el job fue rechazado porque el namespace no tenía créditos disponibles. En lugar de detenerse, ML Intern cambió a un sandbox gratuito en CPU, más lento pero que permitió continuar sin cómputo pago. Se estableció un prompt operativo más estricto para la ejecución: registrar pérdidas y métricas, vigilar sobreajuste, guardar el mejor checkpoint, usar early stopping, abortar ante errores o pérdidas anómalas y respetar el presupuesto estimado.

Paso 7 — Progreso del entrenamiento

Durante el entrenamiento, ML Intern monitorizó pérdida y métricas de validación. El reporte de métricas por época fue:

• Época 1: Accuracy 99.76% — Macro F1 99.78% (buen inicio)
• Época 2: Accuracy 99.68% — Macro F1 99.68% (ligera caída)
• Época 3: Accuracy 99.88% — Macro F1 99.88% (mejor checkpoint)
• Época 4: Accuracy 99.80% — Macro F1 99.80% (ligera bajada)
• Época 5: Accuracy 99.80% — Macro F1 99.80% (mejor checkpoint retenido)

El mejor checkpoint correspondió a la época 3.

Fortalezas y riesgos observados

Fortalezas:

• Cobertura del “trabajo sucio”: investigación, inspección de datos, generación de scripts, depuración y preparación para Hugging Face.
• Fuerte integración con el ecosistema de Hugging Face (datasets, modelos, jobs, Hub).
• Comportamiento de colega junior: útil para acelerar prototipos y liberar tiempo de ingenieros más senior.
• Capacidad práctica para adaptarse a restricciones de cómputo (fallback a CPU) y mantener controles de seguridad.

Riesgos y límites:

• No es totalmente autónomo: requiere supervisión humana y revisiones críticas (por ejemplo, para evitar data leakage o tratar desequilibrios de clase).
• Dependencia de créditos y acceso a hardware cuando se requiere entrenamiento intensivo en GPU.
• Las decisiones automáticas sobre métricas y manejo de errores necesitan validación por parte del equipo.

ML Intern vs AutoML: ¿qué aporta de diferente?

AutoML tiende a enfocarse en la selección y optimización del modelo. ML Intern amplía el alcance: cubre investigación, diagnóstico de datos, scripting, ejecución de jobs y preparación para publicación. No sustituye la experiencia humana, pero puede acelerar el flujo y reducir tareas repetitivas.

Implicaciones para equipos en América Latina

Para equipos y tomadores de decisión en la región, ML Intern puede ser especialmente útil para prototipado rápido y para organizaciones con recursos humanos limitados: permite avanzar desde la idea hasta un checkpoint funcional sin necesidad de experiencia profunda en cada etapa. Es importante, sin embargo, que los equipos mantengan controles sobre calidad de datos, costos de cómputo y protección de información sensible al integrar la herramienta en proyectos productivos.

Conclusión

La evaluación práctica mostró que ML Intern puede acompañar un proyecto completo, desde el prompt inicial hasta obtener un mejor checkpoint entrenado y listo para la publicación en Hugging Face. No reemplaza a un ingeniero senior, pero actúa como un asistente capaz de reducir fricciones en el “medio desordenado” del desarrollo de ML. Para equipos que buscan acortar ciclos de experimentación y estandarizar buenas prácticas, ML Intern merece un lugar como apoyo en la pila de herramientas, siempre bajo supervisión y con políticas de gobernanza de datos y costos claras.