Desplegar un modelo de machine learning en producción requiere orquestar repositorio, contenedores y base de datos en una secuencia precisa. Aquí entenderás cómo estructurar tu proyecto, levantar la aplicación con Docker Compose, probar el endpoint con Postman y verificar que las predicciones se almacenen correctamente en PostgreSQL, todo antes de subirlo a un servidor en AWS.

Qué estructura debe tener tu repositorio para el deploy

Antes de tocar la terminal, tu repositorio debe estar ordenado y, sobre todo, en una rama exclusiva de deploy para evitar confusiones con otras versiones del código [00:18].

Dentro de la carpeta app necesitas estos archivos:

• __init__.py vacío, que marca el directorio como módulo de Python.
• config.py con las variables de configuración.
• count_vectorizer.pickle, el artefacto que transforma texto en una representación matricial numérica para que el modelo aplique .predict [00:43].
• db.py con los campos, el tipado y la llave primaria (en este caso id).
• main.py que encapsula la lógica de la aplicación.
• prestart.sh que inicializa la base de datos en el puerto 5432.
• utils/ con la lógica de procesamiento y transformación de datos.

Fuera de app van el Dockerfile, el docker-compose.yml, el archivo model que se lee al ejecutar el endpoint bajo serving batch, el requirements.txt con las dependencias y un script adicional para configurar la instancia en AWS [02:00].

¿Qué es serving batch en machine learning? Es un modo de servir un modelo en el que recibes varios inputs en una sola petición y devuelves todas las predicciones juntas, en lugar de procesar uno a uno.

Cómo levantar la aplicación localmente con Docker Compose

Una vez tu rama está lista, el flujo en terminal es directo. Primero verificas que estás parado en la rama de deploy y luego ejecutas los dos comandos clave [03:42].

bash docker compose build docker compose up

El build descarga lo definido en el Dockerfile, instala los requerimientos y copia el contenido de app al directorio de trabajo del contenedor. El up levanta la imagen.

Si aparece un error de indentación, como ocurrió en db.py línea 29 por unos docstrings mal alineados [04:36], detén el contenedor con Ctrl + C, corrige, guarda y vuelve a construir la imagen. En Windows conviene además ejecutar un shutdown del contenedor para matar procesos colgados.

Cómo probar el endpoint predict con Postman

Con la imagen levantada, Postman te permite simular cómo un sistema externo consumiría tu API [06:11].

La configuración del request es:

• Método: POST, porque envías datos para obtener una respuesta.
• URL local: http://localhost:5004/predict.
• Body: un JSON con la estructura esperada por la clase definida en main.py.

El cuerpo se construye con una llave sentence que contiene una lista de diccionarios. Cada diccionario representa un input y debe incluir dos campos: client_name con el nombre del cliente y text con el contenido del ticket que el modelo va a clasificar [07:15].

¿Por qué se usa una lista de diccionarios en serving batch? Porque cada diccionario es un input independiente y la lista permite mandar varios casos en la misma llamada, optimizando el tiempo de respuesta.

El problema de negocio detrás es claro: clasificar tickets de soporte (préstamos, hipotecas, temas bancarios) para que una empresa con miles de usuarios pueda dirigir cada caso al equipo correcto y mejorar la satisfacción del cliente [08:08].

Cómo interpretar la respuesta del modelo y validar la base de datos

Al hacer clic en send, la API responde con un diccionario que contiene la llave prediction. Su valor es una lista de diccionarios, donde cada uno trae el client_name y la predicción ya decodificada [09:00].

La decodificación importa porque el modelo retorna enteros (0, 1, 2). En main.py se aplica un label_mapping que traduce esos enteros a etiquetas legibles como préstamo o hipoteca. Sin ese paso, la respuesta no tendría valor para el negocio.

La señal de que todo funcionó es el status code 200, que confirma que el request se procesó y los registros se almacenaron en la base de datos [09:32].

Cómo conectarte a PostgreSQL desde Visual Studio Code

Para verificar lo almacenado, puedes usar la extensión Connections de Visual Studio Code u otro gestor de tu preferencia [09:51]. Los parámetros de conexión son:

• Host: localhost.
• Puerto: 5433.
• Usuario, contraseña y nombre de base de datos: los que definiste en el docker-compose.yml.

Al abrir la tabla verás tres columnas: id como entero y llave primaria, client_name y la predicción. En el ejemplo del despliegue ya había alrededor de 1300 registros acumulados de pruebas previas [10:34].

Qué sigue antes de subir el modelo a AWS

El despliegue local es solo el primer filtro. Una vez confirmas que el endpoint responde y la base guarda correctamente, el siguiente paso es replicar este flujo en una instancia de AWS, configurando el acceso por llaves SSH y dándole permisos al servidor para clonar tu repositorio desde la rama de deploy [02:30].

Ahí también vas a crear dos ambientes en Postman, uno local y otro productivo, para alternar pruebas sin romper la configuración. ¿Ya tienes definida tu rama de deploy o aún estás trabajando todo en main? Cuéntame cómo organizas tus despliegues.