El problema de negocio
Yiwu Corporation, un importador con infraestructura AWS y ERP Odoo, recibe diariamente alrededor de 100 imágenes de catálogos de productos vía WhatsApp desde sus proveedores. Cada imagen contiene precios, descripciones, códigos de producto y medidas — datos valiosos que quedaban atrapados en una pantalla de celular.
El desafío: automatizar la extracción, clasificación y sincronización de esa información hacia Odoo, con trazabilidad completa y sin perder la imagen original.
La solución fue construir un pipeline de ingesta sobre la arquitectura medallón, implementado como microservicio Python/FastAPI sobre infraestructura AWS.
¿Qué es la Arquitectura Medallón?
La arquitectura medallón (Medallion Architecture) es un patrón de diseño de datos propuesto por Databricks para organizar pipelines en capas progresivas de calidad. Cada capa tiene una responsabilidad clara y solo recibe datos que ya cumplen los criterios de la capa anterior.
- Bronze: datos crudos, sin transformar, idempotentes
- Silver: datos limpios, estructurados, enriquecidos
- Gold: datos listos para el negocio, optimizados para consumo
El principio fundamental es la separación de responsabilidades por capa. No existe transformación lógica mezclada con almacenamiento crudo. Este patrón nació en el contexto de Data Lakehouses con Databricks Delta Lake, pero su filosofía aplica a cualquier pipeline — incluyendo microservicios Python con 100 registros/día sobre AWS.
Cómo aplicamos Medallón a este proyecto
El proyecto implementa cuatro flujos batch independientes, cada uno mapeado a una capa del medallón. La fuente de datos es WhatsApp vía Evolution API; el destino final es el catálogo de productos en Odoo.
Bronze: Ingesta Cruda
La capa Bronze captura el dato en su forma más pura: la imagen original sin ninguna transformación analítica.
- FastAPI recibe el webhook de Evolution API con la imagen de WhatsApp
- Calcula un hash SHA-256 para deduplicación idempotente
- Sube la imagen a S3 bajo images/{hash}.jpg
- Registra en image_metadata con status = pending
Características clave de esta capa: sin transformación de datos, idempotente (el mismo mensaje procesado dos veces produce el mismo resultado), solo almacena. No infiere, no clasifica, no enriquece.
S3: images/abc123.jpg ← imagen original
PostgreSQL: image_metadata
- s3_key: images/abc123.jpg
- source_type: whatsapp
- status: pending
- created_at: 2024-01-15T10:30:00
Silver: Enriquecimiento con IA
La capa Silver lee los registros con status pending del Bronze y les agrega valor cognitivo a través de múltiples servicios de IA de AWS.
- AWS Rekognition detect_text: extrae texto OCR de la imagen
- AWS Rekognition detect_labels: detecta etiquetas visuales del producto (tipo, contexto, categoría)
- Amazon Nova Multimodal Embeddings (Bedrock): genera vector de 1024 dimensiones que encapsula imagen + texto
- Nova Micro (Bedrock): extrae campos estructurados — precio, marca, proveedor, talla, color
- Actualiza status = completed
image_metadata (silver)
- texto_ocr: "LA-130083 Cortina de ducha 1.8x1.8 S/2.8"
- image_embed: [0.023, -0.441, ..., 0.118] ← 1024 dims
- text_embed: [0.091, -0.203, ..., 0.445] ← 1024 dims
- status: completed
- precio: "2.8"
- marca: "Yang"
La clave del diseño Silver es que los datos son buscables por similitud semántica: pgvector sobre PostgreSQL 15 permite búsquedas ANN (Approximate Nearest Neighbor) sobre los embeddings para encontrar imágenes visualmente similares sin necesidad de un servicio vectorial externo.
Gold: Datos Listos para el Negocio
La capa Gold vincula los datos enriquecidos del Silver con el catálogo existente en Odoo, produciendo decisiones de negocio automatizadas.
- MatchProductUseCase: busca en pgvector el producto Odoo más similar usando cosine similarity sobre los embeddings
- Registra en product_matches con score de confianza y método de matching
- Expone Search API con endpoints /search/image y /search/text
- sync_odoo.py: sube los productos confirmados a Odoo vía XML-RPC
product_matches (gold)
- product_name: "Cortina de Ducha 1.8x1.8"
- match_score: 0.94
- match_method: image_cosine
- odoo_product_id: 4521
El score de confianza permite automatizar matches altos (> 0.90) y derivar a revisión manual los intermedios (0.70-0.90). El equipo comercial solo ve decisiones listas para ejecutar.
Evolution API: extracción de datos en WhatsApp
¿Qué es Evolution API?
Evolution API es un servidor de código abierto que implementa el protocolo de WhatsApp Web (no la API oficial de Meta). Básicamente simula ser un cliente de WhatsApp desde un servidor, permitiendo recibir y enviar mensajes de forma programática mediante webhooks y una REST API.
En este proyecto, Evolution API corre como un contenedor Docker en EC2. Cuando un proveedor envía una imagen al número de WhatsApp configurado, Evolution API dispara un webhook HTTP hacia el microservicio de ingesta con la imagen codificada en base64 — ese es el trigger que inicia el flujo Bronze.
¿Por qué funciona para extracción de datos?
Para un pipeline de ingesta de imágenes de proveedores controlados, Evolution API es una solución pragmática con ventajas concretas:
- Costo cero: no requiere cuenta aprobada de WhatsApp Business API, ni costos por mensaje
- Sin restricciones de templates: permite recibir cualquier tipo de imagen o mensaje libre sin aprobación previa
- Webhooks nativos: la integración con el microservicio es directa — un POST HTTP con la imagen en base64
- Baja latencia: el procesamiento comienza en segundos tras recibir el mensaje
Por qué NO es buena práctica para chatbots
Acá viene la parte crítica que muchos desarrolladores ignoran. Evolution API utiliza el protocolo no oficial de WhatsApp Web. Meta prohíbe explícitamente el uso de clientes no oficiales en sus Términos de Servicio. Las consecuencias son reales y ocurren:
- Banning permanente del número: Meta puede bloquear el número sin previo aviso y sin mecanismo de apelación para cuentas no registradas en la API oficial
- Sin garantías de disponibilidad: los cambios en el protocolo de WhatsApp Web pueden romper Evolution API de un día para el otro
- Sin SLA ni soporte: es un proyecto open source sin compromisos de estabilidad ni uptime
- Riesgo de privacidad: los mensajes de los usuarios pasan por un servidor no auditado por Meta
Para ingesta de datos unidireccional (el proveedor envía, el sistema recibe y procesa), el riesgo es acotado: si el número es baneado, el impacto es operativo pero recuperable. Hay tiempo para migrar a un canal alternativo sin afectar clientes finales.
Para chatbots de atención al cliente el escenario es radicalmente diferente: los clientes esperan respuestas, hay conversaciones activas, y un baneo masivo puede destruir la reputación del negocio en horas. La alternativa correcta es la WhatsApp Business API oficial de Meta o proveedores certificados como Twilio, Vonage o 360dialog — que incluyen SLA, mecanismos de apelación y cumplimiento legal.
Lecciones del pipeline
Separar capas es separar responsabilidades. El batch Silver puede fallar, reintentar, y nunca corrompe los datos Bronze. La idempotencia de Bronze es lo que hace posible el retry seguro en Silver sin lógica de compensación compleja.
pgvector es suficiente para este escenario. Con ~500 imágenes/día y vectores de 1024 dims, pgvector sobre PostgreSQL 15 tiene la performance necesaria sin el overhead operativo de Pinecone, Qdrant o OpenSearch. No sobre-ingenieriés la solución vectorial antes de tener los números reales.
Nova Multimodal Embed supera a Titan para este caso específico. Las imágenes de catálogos tienen texto prominente (precios, códigos, marcas). Nova Multimodal captura tanto el contenido visual como el texto en un único vector de 1024 dims, mejorando notablemente la calidad de las búsquedas de similitud.
EventBridge + Fargate para batch scheduling. Los flujos Silver y Gold no necesitan correr 24/7. EventBridge dispara el Fargate task cada 30 minutos, el procesamiento toma 2-5 minutos, y el costo cae drásticamente versus mantener una instancia permanente levantada.
Conclusión
La arquitectura medallón no es exclusiva de Databricks ni de big data. Es un patrón de ingeniería de datos que mejora la mantenibilidad, trazabilidad y confiabilidad de cualquier pipeline — incluyendo microservicios Python con 100 imágenes/día sobre AWS.
El principio que vale la pena llevarse a cualquier proyecto: los datos crudos son sagrados. Una vez que tenés el dato original en Bronze, podés reprocesar Silver y Gold cuantas veces necesites sin perder información. Esa es la garantía fundamental del patrón, y la razón por la que vale la pena estructurar el pipeline desde el primer día.