👩🎓 Tu primer modelo
Objetivo principal: que escribas una función que decida algo y la entregues sabiendo que va a funcionar cuando la publiquen, sin haber tocado ni un contenedor.
Esta página es para ti si estás en clase y vas a entregar un modelo. Todo lo demás del manual es para quien opera la plataforma.
Lo único que escribes
Un archivo, modelo.py, con una función:
def predecir(entrada: dict) -> dict:
temperatura = entrada.get("temperatura_aula", 21.0)
return {
"consigna": temperatura - 1.0,
"encender_clima": temperatura > 24.0,
}
Ya está. No hay nada más que configurar: ni contenedores, ni servidores, ni despliegue.
La firma es fija, y es a tu favor
predecir recibe un solo argumento y devuelve un diccionario. El nombre de la función
no se puede cambiar: la plataforma la busca así.
No es una limitación pendiente de levantar. Es lo que hace que tu proyecto siga funcionando cuando la plataforma cambie por dentro.
Qué recibes
entrada es un diccionario de valores numéricos, cada uno con su nombre:
{"temperatura_aula": 23.4, "co2_ppm": 812}
Depende de qué sensores se conecten. Acuérdalo con quien vaya a invocar tu modelo y anótalo en tu archivo, o el día de la invocación te llegará algo que tu código no espera.
Y accede a ellos siempre con .get() y un valor por defecto:
temperatura = entrada.get("temperatura_aula", 21.0) # así sí
temperatura = entrada["temperatura_aula"] # así revienta el día
# que no llegue
Qué devuelves
Un diccionario, también con nombre: {"consigna": 21.5}.
Cada valor tiene que ser un número, un booleano o un texto de Python.
Lo que devuelven las bibliotecas de cálculo no son números de Python aunque lo parezcan.
Envuélvelos: float(...), int(...), bool(...). Si no, la plataforma rechaza la respuesta
por «salida inválida» y el mensaje no siempre es evidente.
Y no devuelvas una tupla: llegaría sin nombres y nadie sabría qué es cada valor.
Tus paquetes
requirements.txt puede quedarse vacío. Si tu lógica solo usa Python, no hay nada que
declarar, y eso es un caso válido — no un olvido.
Si necesitas algo, escribe su nombre, uno por línea:
numpy
Puedes fijar la versión —joblib==1.6.0— y en general es buena idea: así tu proyecto se
sigue construyendo igual dentro de seis meses, con las mismas piezas exactas. (El ejemplo no es
numpy a propósito: es de los que la plataforma ya lleva, y esos no se fijan; sigue leyendo.)
Solo puedes declarar lo que el aula tiene preparado. La plataforma no sale a internet al publicar: instala desde un almacén que tu profesor rellena. Si pides algo que no está, la publicación se rechaza nombrando el paquete: pídeselo.
No puedes fijar otra versión de lo que la plataforma ya usa para funcionar (numpy, por
ejemplo). Si escribes numpy==2.1.0 y la plataforma lleva otra, se rechaza y te lo dice.
Escribe numpy a secas y usas la que hay.
Lo que se instaló de verdad, con su versión exacta, queda escrito en la declaración de tu versión, que tu profesor puede consultar.
Ahí solo van paquetes. Si escribes una línea de opciones —de las que empiezan por guion, como las que cambian de dónde se descargan las cosas—, la publicación se rechaza y te dice qué línea quitar. De dónde se descarga lo decide la plataforma, no tu entrega.
Lo que viaja y lo que no
La regla es simple: viaja lo que tu código abre al ejecutarse. Lo que solo usaste para entrenar, no hace falta.
Todo lo que escribes fuera de predecir se ejecuta al cargar el modelo, no al invocarlo — y
cargar los pesos entrenados suele estar ahí.
Si tu código hace open("pesos.bin") y ese archivo no viajó con tu entrega, la publicación
sale bien y el modelo falla en cada invocación. Comprueba tu carpeta antes de entregar.
Antes de entregar: ejecútalo
python modelo.py
La plantilla trae al final una comprobación que se ejecuta sola y te dice si tu función cumple las reglas. Cámbiale los casos por los tuyos.
Si no corre en tu portátil, no va a correr en el servidor. Es la comprobación más barata que existe y ahorra la mayoría de los rechazos.
Si el comando falla porque python no existe, prueba con python3 o con py. Cuál funciona
depende de cómo esté instalado en tu ordenador, y es una de las cosas que esta plataforma
existe para que dejes de pelear.
Qué entregas, y a quién
La carpeta entera: modelo.py, requirements.txt y todo lo que tu código abra.
A quien te dé clase. Hoy la entrega es a mano: cómo llegará tu carpeta a la plataforma todavía no está decidido, y decirlo es más honesto que inventarte un procedimiento que no existe.
Lo que NO tienes que hacer
| No haces | Quién lo hace |
|---|---|
| Publicar | Quien te da clase, desde la pantalla |
| Elegir el número de versión | La plataforma. Te lo dice al publicar |
| Empaquetar, servir o desplegar | La plataforma |
| Consultar el inventario o retirar | Quien opera la plataforma |
No tienes pantalla propia. Para saber si tu modelo respondió, pregunta a quien te da clase: en la vista de clase aparece tu modelo por su nombre —sin decir de quién es— y si ha respondido ya.
Si te rechazan la publicación
Recibirás un mensaje con tres partes: qué se intentaba, qué lo provocó y qué hacer. Está escrito para que puedas arreglarlo tú.
Los diez rechazos posibles, con lo que significa cada uno, están en Diagnósticos.