🎯 Qué resuelve esta plataforma
Objetivo principal: entender, antes de tocar ninguna pantalla, qué problema concreto resuelve esto y de quién es cada parte del trabajo.
El punto de partida
Un alumno que aprende machine learning sabe escribir la lógica de un modelo. Escribe una función que decide algo —a partir de la temperatura del aula, propone una consigna y dice si encender el clima— y ahí se acaba: un script que corre en su portátil y que nadie más puede invocar.
El salto de «tengo una función» a «hay un servicio al que se le pueden hacer peticiones» le exige cuatro competencias que no son las que está aprendiendo:
| Lo que haría falta | Por qué no es su asignatura |
|---|---|
| Empaquetado | Decidir cómo se distribuye su código y con qué estructura |
| Servicio en red | Levantar un proceso que escuche, enrutar, serializar |
| Gestión de dependencias | Resolver versiones que funcionen juntas y que sigan funcionando |
| Despliegue | Colocarlo en un servidor ajeno sin romper lo que ya hay |
La plataforma existe para que no tenga que aprender ninguna de las cuatro y siga teniendo un servicio invocable al final.
El escenario real, y sus restricciones
No es un laboratorio. Es un centro educativo con un solo servidor, sin orquestador de contenedores, y ese servidor ya sostiene el stack de producción del edificio: recoge datos de aula en tiempo real y su motor de workflows dispara peticiones HTTP programadas contra direcciones que ya existen.
Eso no es una preferencia: es la restricción que da forma a todo lo demás. Cualquier cosa que publique un alumno convive con servicios de los que depende el edificio.
La escala prevista del piloto son de 20 a 40 modelos publicados vivos, invocados cada varios minutos —no de forma continua—.
Los cuatro papeles
El alumnado escribe una función predecir dentro de modelo.py, con ese nombre exacto
porque la plataforma la busca así. Declara sus paquetes en requirements.txt, que puede
quedar vacío y eso es correcto, no un olvido. Se autoevalúa ejecutando su propio archivo. Y
entrega la carpeta.
Lo que no hace: no publica, no consulta el inventario, no invoca, no retira y no tiene
pantalla propia. Ni siquiera tiene puerta: cómo llega su carpeta a la plataforma es una
decisión que sigue abierta —DEF-9, sin candidatos—. Hoy la entrega a mano a quien le da
clase.
El profesorado recoge la carpeta, publica desde la pantalla, invoca para comprobarlo delante del grupo, consulta el inventario, retira cuando toca y proyecta la vista de clase. Es quien responde de lo que se publica en el servidor del centro.
La plataforma revisa el material, valida que la función existe y encaja, resuelve las dependencias, construye el artefacto, lo inventaría y lo pone a responder en una dirección.
El motor de workflows que ya estaba en el servidor invoca esa dirección de forma programada. No pasa por la plataforma: le habla directamente al modelo.
Lo que hay que tener claro desde el principio
Los cuatro límites de recursos están declarados pero no se aplican, no hay denegación de red por modelo, y la puerta de entrada del alumnado no existe. La propia plataforma lo dice en todas sus pantallas. Está explicado sin rodeos en Lo que no hace.