Models, Datasets y Spaces: cómo funciona Hugging Face

Hugging Face es una plataforma para publicar, localizar, versionar y utilizar componentes de aprendizaje automático. En su núcleo, Hugging Face Hub, Models reúne modelos, Datasets organiza conjuntos de datos y Spaces aloja aplicaciones o demostraciones: son repositorios relacionados, pero cada uno cumple un papel distinto.

La diferencia se entiende mejor siguiendo un proyecto hipotético. Si un equipo necesita clasificar comentarios en español, puede seleccionar un modelo, evaluarlo con datos pertinentes y, después, presentar el resultado mediante un Space. En cada etapa cambian lo que se descarga o ejecuta y los controles necesarios.

Tres repositorios, tres responsabilidades

Models, Datasets y Spaces comparten historial, commits, ramas y revisiones porque funcionan como repositorios versionados. La documentación de Hugging Face Hub declara más de dos millones de modelos, 1,5 millones de datasets y 1,5 millones de aplicaciones, y distingue sus funciones: alojar modelos, reunir datos y ejecutar demostraciones interactivas.

Models responde a qué sistema se quiere utilizar. Un repositorio puede contener pesos, configuración, tokenizer, documentación y otros archivos necesarios para cargar el modelo con una biblioteca compatible.
Datasets responde con qué ejemplos se puede entrenar, validar o evaluar. Mantiene los datos, su configuración y la documentación que describe su procedencia, estructura y condiciones de uso.
Spaces responde cómo puede una persona probar o utilizar el resultado. Conserva el código y las dependencias de una aplicación; no constituye por sí solo el modelo ni el conjunto empleado para evaluarlo.

Relacionar los tres repositorios no crea un paquete certificado. Un Space puede llamar a un modelo alojado en otro lugar y una tarjeta de modelo puede mencionar datasets concretos, pero esas referencias no garantizan que las versiones, licencias o condiciones de evaluación coincidan.

La selección empieza por el modelo, no por la demo

Para el clasificador hipotético, la búsqueda comenzaría en Models, atendiendo a la tarea, el idioma y las bibliotecas compatibles. Las descargas y los “me gusta” reflejan actividad o visibilidad, pero no demuestran que el modelo funcione bien con comentarios de un país, sector o periodo determinados.

La tarjeta del modelo es el punto de partida para conocer su uso previsto, limitaciones, idiomas, datos de entrenamiento declarados y resultados de evaluación. Una métrica aislada dice poco si no se identifica el conjunto de prueba, la distribución de clases y la similitud entre esos ejemplos y las entradas que recibirá el sistema.

Después hay que inspeccionar los archivos. Cargar un modelo suele implicar descargar pesos y configuración; según la arquitectura, también puede requerir un tokenizer, dependencias o código personalizado. Para reproducir la prueba, conviene fijar una revisión concreta —por ejemplo, un identificador de commit— en lugar de depender de una rama que puede cambiar.

El dataset aporta la base de comparación

El segundo paso es escoger un dataset independiente y pertinente. No bastaría con una colección marcada como “español”: habría que comprobar qué variedades lingüísticas incluye, cómo se obtuvieron los comentarios, qué significan las etiquetas y si existen datos personales, sesgos de selección o restricciones de licencia.

El repositorio del dataset contiene los archivos de datos o la configuración para acceder a ellos, además de metadatos y una tarjeta descriptiva. Explorar algunas filas ayuda a reconocer su estructura, pero no sustituye la documentación; algunas colecciones requieren autorización y otras pueden cargarse mediante transmisión progresiva en lugar de descargarse completas.

Modelo y dataset deben identificarse por separado. Registrar la revisión del modelo, la del dataset y el código de evaluación permite reconstruir el resultado. Si los datos cambian mientras el modelo permanece fijo, la métrica puede variar porque cambió la base de comparación, no necesariamente porque el sistema mejoró o empeoró.

Spaces convierte la combinación en una aplicación

Tras evaluar el clasificador, el equipo puede crear una interfaz donde una persona escriba una frase y reciba una etiqueta y una puntuación. El Space recibe la entrada, la prepara, invoca el modelo y presenta la salida. Esa experiencia puede ocultar qué repositorio o revisión utiliza, por lo que una demostración convincente no equivale a una evaluación documentada.

La documentación oficial de Spaces explica que el código de cada aplicación se guarda en un repositorio Git y que un nuevo commit provoca automáticamente la reconstrucción y el reinicio del Space. Por ello, un cambio en el preprocesamiento, la interfaz o las dependencias puede alterar la respuesta aunque los pesos del modelo no hayan cambiado.

Un Space público permite consultar su código, ejecutar la aplicación y clonar el repositorio; otros niveles de visibilidad restringen esas posibilidades. Antes de duplicar o desplegar una aplicación ajena, es necesario identificar el modelo utilizado, revisar sus dependencias y mantener credenciales o tokens fuera del código público.

Licencias, revisiones y código exigen controles separados

La licencia debe comprobarse en cada repositorio. La licencia del modelo no concede automáticamente derechos sobre los datos ni sobre el código del Space. Del mismo modo, que un archivo sea accesible o descargable no basta para asumir que se permite modificarlo, redistribuirlo o utilizarlo comercialmente.

El historial Git muestra qué cambió, pero una rama como main es una referencia móvil. Una evaluación reproducible debe conservar los identificadores exactos del modelo, del dataset y de la aplicación, además de las versiones de sus dependencias. Así es posible atribuir una variación a los pesos, los datos o el código de presentación.

Los análisis automáticos de la plataforma tampoco eliminan el riesgo de ejecutar archivos ajenos. La guía de seguridad de Hugging Face sobre pickle advierte que cargar archivos de ese formato puede ejecutar código arbitrario y recomienda confiar solo en autores conocidos, comprobar commits firmados y considerar formatos alternativos. El código personalizado y las dependencias de un Space también deben inspeccionarse y aislarse antes de incorporarlos a un sistema propio.

El flujo completo no consiste en encontrar una demo y copiarla. Consiste en seleccionar una revisión del modelo, medirla con una versión documentada del dataset y construir o auditar un Space que haga explícita esa combinación. Separar esos papeles permite saber qué se está descargando, qué código se ejecuta y qué componente explica cada resultado.

Hugging Face no es solo un catálogo: modelos, datos y apps tienen otro papel