Big Data e IA en producción: arquitectura con lakehouse y bases vectoriales

Cualquier proyecto de IA en producción que haya superado el primer año tiene cuatro capas reconocibles. Pueden estar implementadas con tecnologías distintas, pueden mezclar managed y self-hosted, pero las cuatro están. Saltarse alguna es la causa más común de proyectos que parecían listos y revientan al primer pico de uso real.

• Capa de almacenamiento: el sustrato donde viven los datos en bruto y procesados. Hoy esto es un Data Lake o, más comúnmente, un Lakehouse — un Data Lake con garantías transaccionales y formatos abiertos.
• Capa de cómputo: pipelines de ingesta, transformación y enriquecimiento, en batch (Spark, Databricks Jobs) y/o streaming (Kafka, Spark Structured Streaming). Aquí se prepara el dato para que el modelo pueda usarlo.
• Capa de retrieval semántico: la base vectorial que indexa embeddings y permite recuperar fragmentos relevantes por significado. Es la pieza clave para RAG y para cualquier agente que consulte conocimiento propio.
• Capa de orquestación y observabilidad: cómo se invoca cada componente, cómo se monitoriza, cómo se mide el coste por petición, cómo se traza una respuesta hasta los fragmentos que la generaron.

Hasta hace pocos años, las empresas debían elegir entre Data Lake (flexible, barato, pero sin garantías transaccionales ni rendimiento SQL) y Data Warehouse (rápido, transaccional, pero rígido y caro). El Lakehouse cierra esa brecha: combina almacenamiento abierto y barato con garantías ACID, schema evolution, time travel y rendimiento SQL competitivo.

Lo viable arquitectónicamente lo permiten tres formatos de tabla abiertos: Delta Lake (impulsado por Databricks), Apache Iceberg (originado en Netflix, hoy estándar de facto en muchas empresas) y Apache Hudi. Los tres aportan la capa transaccional sobre ficheros Parquet en almacenamiento de objetos (S3, ADLS, GCS). La elección entre ellos depende del ecosistema circundante: Delta encaja perfecto en Databricks; Iceberg es el preferido cuando quieres independencia de proveedor y compatibilidad con múltiples motores; Hudi tiene su nicho en upserts intensivos.

• Beneficios prácticos del Lakehouse: ACID sobre datos en almacenamiento de objetos, schema evolution sin reescribir, time travel para auditoría y debugging, particionado eficiente, separación clara entre almacenamiento y cómputo (escalas cada uno independientemente).
• Ventaja específica para IA: el mismo dato sirve para analítica BI tradicional y para alimentar pipelines de ML/IA. No hay copia paralela ni desincronización entre sistemas.
• Limitación realista: la curva de aprendizaje no es cero. Equipos que vienen de un Data Warehouse clásico necesitan tiempo para adoptar el modelo, especialmente la gestión de versiones de tabla y el coste de compactación.

La decisión entre las plataformas managed (Databricks, Snowflake) y una construcción propia con Iceberg + motor de cómputo no es de tecnología sino de modelo operativo. Cada opción optimiza para cosas distintas y conviene saber para qué optimiza la empresa antes de elegir.

• Databricks: el más maduro para casos donde la IA y el Big Data conviven (Spark + MLflow + Mosaic AI + vector search nativo). Coste relativamente alto pero ahorra meses de integración. Buen encaje para empresas que quieren una plataforma única y no quieren mantener stack abierto.
• Snowflake: tradicionalmente más fuerte en analítica SQL y BI; ha cerrado mucho el gap en IA con Cortex, vector search nativo y Snowpark. Buen encaje cuando el uso predominante es analítico y la IA es el segundo caso de uso, no el primero.
• Construcción propia (Iceberg + Spark/Trino + base vectorial separada): máxima flexibilidad y portabilidad, sin lock-in al proveedor. Coste operativo mayor: alguien tiene que mantener todo el stack. Buen encaje para empresas con equipo técnico maduro o requisitos regulatorios que exigen estar fuera de plataformas opinionadas.
• Plataformas cloud nativas (AWS Lake Formation + Glue + Bedrock, Azure Synapse + AI Foundry, BigQuery + Vertex AI): encajan cuando ya hay compromiso fuerte con un hyperscaler y quieres minimizar integración cruzada de proveedores.

La base vectorial es donde viven los embeddings — las representaciones semánticas que permiten recuperar fragmentos relevantes para RAG. La oferta es amplia y la elección depende de tres variables prácticas: volumen, latencia y stack existente.

• PgVector (extensión de PostgreSQL): la opción natural si ya tienes Postgres en producción. Funciona bien hasta millones de vectores; permite filtros relacionales en la misma consulta; SQL estándar para el equipo. Limitación: a partir de cientos de millones de vectores empieza a sufrir.
• Qdrant: base vectorial dedicada, open-source, alto rendimiento. Encaja cuando el volumen supera lo que PgVector aguanta o cuando la base de datos relacional no debe asumir la carga. Self-hosted o managed cloud.
• Pinecone: serverless gestionado. Cero operación. Buen encaje cuando el equipo no quiere mantener infraestructura vectorial y el coste por petición sale razonable para el volumen del caso.
• Elasticsearch / OpenSearch: si ya los usas para búsqueda textual, han añadido búsqueda vectorial nativa. Permite retrieval híbrido (BM25 + vector) en una sola consulta, lo cual mejora calidad en muchos casos.
• Redis: cuando la latencia es crítica (sub-10ms) y el volumen cabe en memoria. Encaja en agentes conversacionales en tiempo real.
• MongoDB Atlas Vector Search: si ya usas Mongo, ahorra integración. Sin la madurez de las dedicadas pero suficiente para muchos casos.
• Databricks Vector Search / Snowflake Cortex Search: si ya estás en una de esas plataformas, son la opción de menor fricción aunque no necesariamente la más barata por vector.

RAG (Retrieval-Augmented Generation) es la arquitectura que conecta las dos capas anteriores con el modelo. Su valor está en que el LLM responde con información real de la empresa, atribuible a fuentes concretas, sin necesidad de reentrenarlo. El pipeline tiene partes muy reconocibles cuando llega a producción.

1. 1. Ingesta

   documentos (PDFs, HTML, Confluence, SharePoint), tickets, transcripciones se traen al lakehouse en bruto y normalizado. Aquí el control de cambios y permisos es crítico.

2. 2. Chunking

   cada documento se divide en fragmentos del tamaño adecuado al modelo y al caso. El chunking ingenuo (cada N tokens) suele dar resultados mediocres; el chunking semántico (por sección, por encabezado) mejora notablemente la calidad de retrieval.

3. 3. Embedding

   cada chunk se transforma en un vector usando un modelo de embeddings (OpenAI text-embedding-3, modelos open-source como BGE o E5, modelos especializados por idioma o dominio). La elección impacta directamente en calidad y coste.

4. 4. Indexación

   los vectores y sus metadatos (origen, permisos, fecha) se cargan en la base vectorial. Aquí también va una copia textual del chunk para citar a fuente.

5. 5. Retrieval híbrido

   ante una consulta, se buscan los chunks más relevantes por similitud vectorial, opcionalmente combinado con filtros relacionales y/o búsqueda por palabra clave (BM25). El retrieval híbrido suele superar al puramente vectorial.

6. 6. Re-ranking

   un segundo modelo (más pequeño y más rápido) reordena los top-N para priorizar lo realmente relevante. Paso opcional pero con impacto importante en calidad cuando hay volumen.

7. 7. Generación con cita

   el LLM recibe la consulta, los chunks recuperados y la instrucción de responder citando las fuentes. La salida estructurada permite que la UI muestre las citas vinculadas al documento original.

8. 8. Feedback loop

   cada respuesta se loguea con su retrieval, su latencia, su coste y, si el caso lo permite, con una señal de calidad del usuario. Sin este paso no hay mejora iterativa posible.

El error más caro al pasar a producción no es elegir la base vectorial equivocada. Es no medir el coste por petición desde el primer día. Los modelos cobran por token; las bases vectoriales por almacenamiento y consulta; los pipelines por compute. Sin métricas, los costes en producción superan al presupuesto en semanas.

• Métricas críticas a monitorizar: coste por petición (desglosado en embedding, retrieval, generación, re-ranking), latencia por etapa, tasa de aciertos del retrieval, tasa de alucinación del modelo, distribución de tokens de entrada y salida, error rate por componente.
• Patrón típico de fuga de coste: el equipo activa el modelo más caro "por defecto" para máxima calidad, sin sistema de evaluación que indique cuándo el modelo intermedio basta. Resultado: factura 5-10x lo necesario para igual calidad percibida.
• Otro patrón: re-embedding completo en cada despliegue por no haber pensado en invalidación incremental. Eso suma horas de cómputo y cientos de euros por ciclo.
• Y el más doloroso: pipeline de ingesta sin control de duplicados que reindexa los mismos chunks cientos de veces. Se detecta por la curva de coste de la base vectorial que crece sin que el contenido lo justifique.

Este nivel de arquitectura tiene sentido cuando hay volumen significativo, requisitos de gobernanza serios y voluntad de iterar a varios casos de uso. Para muchas empresas, especialmente al principio, hay alternativas más ligeras que dan el 80% del valor con el 20% del coste.

• Caso de uso único con menos de cientos de miles de documentos: probablemente PgVector sobre Postgres existente, pipeline de ingesta simple en cron y un LLM por API basta para empezar.
• Asistente sobre documentación pública: puede tener sentido un SaaS de RAG empaquetado (Glean, Notion AI, Microsoft Copilot) si los datos viven ya ahí.
• Prototipo de validación: arquitectura mínima local con embeddings y vector store en memoria. El objetivo es validar el caso, no construir la versión productiva.
• Equipo pequeño sin perfiles de data engineering: alquilar plataforma managed completa (Databricks, una mezcla AWS Bedrock + Knowledge Bases, Azure AI Search) suele salir más barato que mantener stack propio.

Nuestro papel cambia según el momento del cliente. Si están eligiendo arquitectura, ayudamos a tomar decisiones sin sesgo de proveedor. Si están construyendo, aportamos perfiles que ya han pasado por las trampas. Si están en producción y los costes se descontrolan, hacemos auditoría con propuesta concreta.

• Asesoría arquitectónica (2-3 semanas): inventario actual, decisión documentada sobre lakehouse, base vectorial y patrón RAG; sin compromiso de implementación.
• Implementación de plataforma de IA (12-24 semanas): construcción de la arquitectura completa con observabilidad y traspaso al equipo del cliente.
• Auditoría de costes y rendimiento (3-4 semanas): para proyectos ya en producción que han perdido el control. Diagnóstico cuantitativo con plan de optimización priorizado por impacto.
• Mentoría continua a equipos de data engineering que están aprendiendo a llevar IA a producción internamente, con sesiones recurrentes sobre arquitectura y costes.