Configurar correctamente la estructura de un repositorio, construir imágenes Docker y validar predicciones de un modelo de machine learning con Postman son pasos fundamentales antes de llevar cualquier aplicación a un entorno productivo. Aquí se detalla cada parte del proceso, desde la organización de archivos hasta la consulta de resultados almacenados en una base de datos PostgreSQL.
¿Cómo debe estar estructurado el repositorio para el despliegue?
Antes de ejecutar cualquier comando, es clave tener una rama específica de deploy en el repositorio. Esto evita confusiones y garantiza que solo los archivos necesarios lleguen al servidor. Dentro del directorio App deben existir los siguientes elementos [01:00]:
__init__.py: archivo vacío que marca el directorio como paquete Python.config: contiene la configuración general de la aplicación.conductorizer.pickle: el artefacto serializado que transforma datos en una representación matricial numérica para que el modelo los reciba como features y ejecute el método .predict().db: módulo con la configuración de la base de datos, incluyendo campos, tipado y la llave primaria (en este caso, el ID).main: encapsula toda la lógica de la aplicación y el entry point.prestart.sh: script que inicializa la base de datos en el puerto 5432, ya definido en el Docker Compose [01:52].utils: módulo con funciones de procesamiento y transformación de datos.
Fuera de App se requieren archivos complementarios: el Docker Compose, el Dockerfile, el archivo mobile que se lee al hacer el entry point para generar predicciones bajo serving batch, el archivo de requerimientos con todas las dependencias, y un archivo de configuración para la instancia en AWS [02:28].
Este último archivo permite configurar el servidor remoto: actualizar paquetes con apt, establecer conexiones SSH y asignar llaves para que la instancia pueda clonar el repositorio de trabajo.
¿Cómo construir y levantar la aplicación con Docker de forma local?
Una vez verificada la rama correcta en la terminal, se ejecutan dos comandos esenciales [04:02]:
docker compose build: descarga las dependencias del Dockerfile y copia el directorio de trabajo.docker compose up: levanta la imagen construida.
Durante este proceso puede aparecer un error de indentación en algún archivo como db.py. La solución es corregir la indentación, guardar el archivo y volver a construir la imagen [04:30]. En Windows, una buena práctica es ejecutar docker compose down o un shutdown antes de reconstruir, para asegurar que no queden contenedores en ejecución.
¿Qué hacer si aparecen errores al levantar el contenedor?
El flujo de corrección es directo: identificar el archivo y la línea señalados en el error, corregir el código, guardar antes de reconstruir y ejecutar nuevamente docker compose build seguido de docker compose up [05:12].
¿Cómo probar las predicciones con Postman?
Para validar que todo funciona se utiliza Postman como cliente HTTP [05:42]. La configuración del request incluye:
- Método: POST, ya que se envía información al servidor.
- URL del entry point: compuesta por la dirección IP local, el puerto
5004 y la ruta /predict.
Una dirección IP identifica un dispositivo en la red, pero además se necesita especificar el puerto por el cual se transmiten los datos [06:00].
¿Qué estructura debe tener el cuerpo del request?
El body sigue la estructura definida en el main mediante la clase Sentence [06:30]:
sentence: una lista que contiene diccionarios.- Cada diccionario representa un input con dos campos:
client_name (nombre del cliente) y text (descripción del problema o ticket).
Al trabajar con serving batch, se envían múltiples diccionarios en una sola petición, lo que permite clasificar varios tickets simultáneamente. El objetivo del modelo es clasificar tickets de soporte para que las empresas ofrezcan atención más específica según la categoría: préstamos, hipotecas, productos bancarios, entre otros [07:10].
Al presionar Send, la respuesta retorna un diccionario con la clave prediction que contiene una lista de diccionarios, cada uno con el nombre del cliente y su predicción ya decodificada [07:55]. Esto ocurre gracias al label mapping definido en el main, que convierte las predicciones numéricas del modelo en etiquetas legibles.
Un status code 200 confirma que la petición fue exitosa y los resultados se almacenaron automáticamente en la base de datos.
¿Cómo verificar los datos almacenados en PostgreSQL?
Para consultar la base de datos se puede usar cualquier gestor, como la extensión Connections de Visual Studio Code [08:35]. La conexión requiere:
- Host:
localhost.
- Puerto:
5433.
- Usuario, contraseña y nombre de la base de datos definidos en el archivo Docker.
Al conectar, se visualizan los registros con tres columnas: el ID como llave primaria de tipo integer, el nombre del cliente y la predicción clasificada. En las pruebas realizadas se almacenaron aproximadamente 1300 registros [09:10].
¿Ya lograste levantar tu aplicación de forma local? Comparte tu experiencia o dudas en los comentarios.
