1 · Apps web para ML y el modelo petición/respuesta
Un modelo entrenado en un archivo no lo puede usar nadie — necesita un front end. La web te da dos: una API REST para otros sistemas, y un panel para humanos. Ambos viajan sobre el mismo ciclo petición/respuesta de HTTP, el cimiento de toda app web que construirás.
Una app web expone tu modelo por HTTP mediante el ciclo petición/respuesta: un CLIENTE envía una petición a una ruta del SERVIDOR, corre un manejador (parsear → `model.predict` → construir una respuesta), y el servidor devuelve una respuesta con un CÓDIGO DE ESTADO y un cuerpo (JSON para sistemas, HTML para humanos). Una API REST sirve a otros programas; un panel sirve a personas — pero ambos son el mismo ciclo por debajo.
Sin esto:
Sin un front end tu modelo se queda en un archivo `.joblib` que nada puede llamar — ningún otro sistema puede pedir una predicción, y ningún usuario no técnico podrá ver una nunca.
Pasaste todo el bootcamp convirtiendo datos en un modelo entrenado y guardándolo como un artefacto .joblib. Ese artefacto es el cerebro — pero ahora mismo nadie puede hablar con él. Un modelo en un archivo no puede tomar entrada de un usuario, no puede responder a otro programa, no puede hacer nada hasta que algo lo llama. Ese "algo" es una app web.
Hay dos audiencias, y quieren dos front ends distintos:
1. Una API REST — para otros sistemas. Una app móvil, un servicio de facturación, el backend de otro equipo: máquinas que quieren una predicción envían una petición estructurada y esperan una respuesta estructurada de vuelta, usualmente JSON ({"prediction": 1, "probability": 0.83}). Sin botones, sin colores — solo datos que entran, datos que salen. Esto es lo que construyes con Flask (este capítulo) o FastAPI (la pista de MLOps).
2. Un panel (dashboard) — para humanos. Un analista de riesgo, un vendedor, tu jefe: personas que quieren escribir unos valores en un formulario, hacer clic en un botón, y ver una predicción renderizada en una página. Necesitan HTML, campos de entrada y un resultado legible — no JSON crudo. Esto es lo que Streamlit (Capítulo 3) hace sin esfuerzo.
Ambos corren sobre el mismo motor: el ciclo petición/respuesta de HTTP. Esta es la idea más importante del desarrollo web, y nunca cambia:
- Un cliente (un navegador, una app de teléfono, un comando
curl) envía una petición a una URL específica en un servidor. - El servidor empareja esa URL con una ruta — una función que escribiste para manejarla.
- El manejador corre: parsea los datos entrantes, hace el trabajo (para nosotros:
model.predict), y construye un resultado. - El servidor devuelve una respuesta: un código de estado (¿funcionó?) más un cuerpo (los datos, como JSON o HTML).
- El cliente recibe la respuesta y la usa — un programa lee el JSON, un navegador renderiza el HTML.
Los métodos dicen qué quieres. La petición lleva un método de HTTP. GET significa "dame algo" (traer una página, leer datos — sin efectos secundarios). POST significa "aquí hay datos, haz algo con ellos" (enviar un formulario, mandar características a /predict). Las predicciones casi siempre usan POST porque estás enviando los valores de las características en el cuerpo de la petición.
Los códigos de estado dicen qué pasó. Cada respuesta lleva un código de 3 dígitos para que el cliente sepa el resultado sin adivinar: 2xx = éxito (200 OK), 4xx = culpa del cliente (400/422 entrada mala, 404 no encontrado), 5xx = culpa del servidor (500 algo se rompió). Una API robusta elige el código correcto para que quien llama pueda reaccionar bien — reintentar un 500, arreglar la petición en un 400.
La escena de abajo anima el ciclo completo para una petición /predict: observa la petición viajar hacia abajo dentro del servidor, el modelo correr, y la respuesta viajar de vuelta arriba al navegador. Todo lo demás en esta pista — rutas de Flask, APIs JSON, formularios, paneles de Streamlit — es solo una variación de este único bucle.
El viaje de ida y vuelta HTTP: la petición baja al servidor (azul), la respuesta sube al navegador (verde).
Un navegador envía `POST /predict` con un cuerpo JSON de características. En el orden correcto, ¿cuál es el ciclo petición/respuesta de HTTP?
- Un modelo entrenado necesita un front end web para ser usable: una API REST (JSON) para otros sistemas, y un panel (HTML) para humanos.
- Toda app web corre sobre el ciclo petición/respuesta de HTTP: el cliente envía una petición → ruta del servidor → corre el manejador → el servidor devuelve una respuesta → el cliente la lee.
- El método dice qué quieres (`GET` = traer, `POST` = enviar datos) y el código de estado dice qué pasó (2xx éxito, 4xx error del cliente, 5xx error del servidor).
Todo modelo desplegado — desde una API de scoring de fraude hasta un panel de churn — se alcanza mediante exactamente este ciclo; la petición lleva las características, la respuesta lleva la predicción.
Si lo quitas: Sin una capa de petición/respuesta el modelo no puede ser llamado en absoluto — es un archivo en disco que ningún sistema y ninguna persona podrá consultar por una predicción.