CASO DE ESTUDIO · PROYECTO PROPIO · IA Y AUTOMATIZACIÓN
Procesamiento inteligente de documentos
Sistema backend que convierte documentos PPTX, PDF y XLSX desordenados en conocimiento estructurado, con agentes de IA encadenados y PostgreSQL.
Video de presentación del proyecto.
Contexto
Gran parte de la inteligencia de negocio está atrapada en PPTX, PDFs y Excels desordenados que no se pueden consultar. El problema lo vi hablando con gente de consultoría.
Meter esos archivos en un chat de IA y pedir un resumen no escala: primero hay que limpiar y estructurar la información. Este sistema lo hace de extremo a extremo: ingiere el archivo, lo analiza con agentes de IA y guarda el resultado en la base de datos.
Lo que construí
El flujo, paso a paso
- Subida: el usuario sube un archivo a la API REST.
- Enrutado: el sistema lo deriva al extractor de su formato:
python-pptxpara PowerPoint,pypdfpara PDF ypandaspara Excel. - Análisis: la IA limpia el texto y extrae insights en cadena: limpieza genérica, Agente Analista de Mercado y Agente Analista de Marca, con Groq (
gpt-oss-120b). - Persistencia: el resultado, en JSON estructurado, se guarda en PostgreSQL (Neon) con el tipo
JSONB. - Respuesta: la API devuelve el JSON limpio.
Decisiones de diseño
- Tres agentes en cadena: separé la tarea en un limpiador/extractor (JSON base), un Agente de Mercado (tendencias y competidores) y un Agente de Marca (posicionamiento). Cada uno recibe el contexto del anterior. Al probar un único prompt, el modelo tendía a ignorar partes de la tarea; con responsabilidades separadas, cada resultado es acotado y verificable.
- Prompts editables: viven en archivos Markdown (
/prompts), separados del código. Un consultor sin conocimientos de Python puede ajustar las instrucciones de la IA sin tocar el código fuente. - JSONB en PostgreSQL: la IA puede devolver propiedades nuevas con el tiempo; con
JSONBno hace falta migrar el esquema, se conserva el JSON completo para auditoría y se puede consultar dentro de él (por ejemplo, todos los análisis de un cliente). - Extractores modulares y API validada: un extractor por formato, y una API REST con FastAPI que valida los archivos y maneja los errores HTTP.
Qué queda guardado
Por cada fragmento del documento, el JSON incluye tema, cliente, sentimiento, análisis de mercado (competidores, tema y tamaño de mercado), insight principal y análisis de marca (valores y percepción).
Automatización y despliegue
- n8n: orquesta y visualiza. Consume los datos de PostgreSQL y arma tableros con insights (tendencias, competidores, tamaño de mercado) para los consultores.
- Docker y Azure: la aplicación está contenerizada y desplegada como demo en Azure App Service, con la base de datos en Neon (PostgreSQL serverless).
El código está en un repositorio privado.
Cómo lo trabajé
Un problema real: procesar archivos grandes en la nube
Al desplegar la API en Azure App Service (plan de 1 GB de RAM), las presentaciones largas fallaban con errores 504 Gateway Timeout y 502 Bad Gateway. Un PPTX de 29 diapositivas hace 3 llamadas a la IA por cada una, y el proceso superaba el tiempo máximo de espera de Azure (cerca de 4 minutos por petición) y la memoria disponible.
Qué hice
- Ajusté el arranque de Gunicorn:
-w 1 --timeout 1200. Un solo worker evita agotar la RAM, y el timeout alto evita que Gunicorn mate el proceso. El límite de petición de la plataforma sigue vigente. - Diseñé la solución para producción: para archivos grandes, el camino es el procesamiento asíncrono (webhooks o colas como Celery), de modo que la petición HTTP no quede bloqueada. Es el próximo paso y todavía no está implementado.
- Hoy: los archivos pesados los proceso en local con el contenedor Docker y los livianos en la nube.
Cómo verifiqué que funciona
- Probé con tres documentos: un PDF real de 13 páginas (un white paper de transformación digital), una presentación académica de 29 diapositivas con tablas y gráficos, y un Excel financiero de prueba.
- Comprobé que el modelo no inventa datos: cuando el documento no menciona competidores, devuelve
No especificadoen lugar de suponerlos. Lo revisé en el JSON final y en la base de datos. - Verifiqué que se extraen las notas del orador de las presentaciones y que el flujo de n8n, conectado a PostgreSQL, muestra la tabla sin errores.
Costo
Según el panel de consumo de Groq, procesar un PDF de 13 páginas con 3 agentes (39 llamadas) costó unos 0,02 USD. Por eso estimo que un documento completo con la cadena de 3 agentes cuesta menos de 0,10 USD.
Uso de asistentes de IA
Usé Claude y GitHub Copilot como apoyo para acelerar el código base, depurar Docker en Windows (conflicto de versiones de Python) y optimizar expresiones en n8n. La arquitectura, el diseño del pipeline, la estrategia de prompts y la resolución de los problemas de infraestructura las diseñé y ejecuté yo.