RAG multimodal: documentos con tablas, imágenes y esquemas

Recibe la documentación técnica de una línea de producción: 1 200 páginas en PDF. Aproximadamente un tercio son tablas de parámetros, otro tercio son esquemas hidráulicos y eléctricos, y el resto es texto continuo. Configura el pipeline RAG, indexa los documentos, prueba las primeras veinte preguntas — y tres cuartas partes obtienen respuestas incorrectas o incompletas. Un técnico pregunta por la carga de corriente de un determinado accionamiento en la tabla de la página 847. El modelo responde con convicción y con error, porque nunca ha visto la tabla: el pipeline ingenuo la parseó como texto desestructurado y en el paso de chunking perdió la relación entre los valores y las columnas.

Esto no es un problema teórico. En entornos industriales — fabricación, energía, ingeniería mecánica — hasta el 40–60 % del valor informativo de los documentos está vinculado a contenido no textual: tablas, planos, diagramas P&ID, esquemas de conexiones, tolerancias de fabricación en gráficos. El RAG de solo texto pierde sistemáticamente esta información. El RAG multimodal resuelve estos problemas — pero no de forma gratuita ni de la misma manera para cada tipo de contenido. Este artículo decide cuándo adoptarlo, qué herramientas usar y cuáles son los retos reales.

Dónde falla el RAG de solo texto y por qué

Antes de pasar a las soluciones, es importante entender con precisión por qué el pipeline ingenuo falla con contenido no textual. Existen tres mecanismos de fallo:

Tablas: El chunking clásico por número de tokens corta la tabla en fragmentos. Los encabezados de columna quedan en un chunk, los valores en otro. Las celdas combinadas desaparecen. Resultado: el retrieval encuentra el fragmento con el número, pero sin el contexto de qué significa ese número. El modelo alucina o responde correctamente «no sé» — ambos resultados son inaceptables en documentación técnica.

Imágenes y esquemas: El parser de PDF extrae texto e imágenes por separado. Si la imagen no está acompañada de texto descriptivo cercano, el pipeline la ignora. La mayoría de los planos industriales tienen un contexto textual muy escueto — números de componentes, leyenda — y la información sustantiva la aporta la disposición visual. Eso es lo que el modelo de solo texto no ve.

Documentos escaneados: Un documento de fabricación antiguo es una imagen escaneada. El OCR lo convierte en texto, pero pierde el layout 2D. Una tabla en texto continuo parece una serie incoherente de números. Los planos permanecen como imágenes sin texto, que el pipeline ignora.

Tres arquitecturas de RAG multimodal

No existe una única solución. En la práctica se han consolidado tres enfoques, cada uno con un trade-off distinto entre calidad, coste y complejidad.

1. Caption-and-index (descripción e indexación)

El camino más sencillo hacia el RAG multimodal. Durante el pipeline de ingestion se usa un vision-language model (VLM) — un modelo que comprende entrada visual — para generar automáticamente una descripción textual de cada imagen y tabla. Esta descripción se almacena junto con el contenido textual de la página y se indexa con retrieval vectorial estándar.

Implementación: Unstructured o Docling extraen imágenes y tablas del PDF. Para cada imagen se llama al VLM (p. ej. GPT-4o, Gemini 2.5 Pro, o localmente Qwen2.5-VL) con el prompt «describe con precisión lo que ves en este plano técnico, incluyendo todos los números, códigos y etiquetas». El texto resultante se indexa.

Ventajas: el retrieval funciona con embeddings estándar, el pipeline es sencillo, las necesidades de almacenamiento son moderadas — del orden de decenas de GB por millones de páginas. Desventaja: la calidad depende de cuán bien el VLM describe la imagen. Los diagramas P&ID complejos con decenas de componentes y simbología según ISA-5.1 pueden describirse de forma imprecisa. Para documentos críticos se recomienda revisión human-in-the-loop al generar las descripciones.

2. Page-as-image con multi-vector retrieval (estilo ColPali)

En lugar de extraer texto del PDF, se renderiza la página completa como imagen y se embebe directamente a través de un vision-language embedding model — típicamente modelos de la familia ColPali, actualmente ColQwen2.5, que ocupa posiciones punteras en el leaderboard ViDoRe V2 para visual document retrieval.

La arquitectura ColPali genera decenas de vectores de patch por página (no uno solo), lo que permite capturar los detalles con mayor fineza. En el retrieval se utiliza late interaction — la consulta se compara con cada vector de patch por separado y la puntuación se agrega (similar a ColBERT para texto). Resultado: una precisión notablemente superior en páginas con contenido mixto texto-tabla-imagen.

La desventaja es clara: el almacenamiento. Donde caption-and-index necesita 1 vector por página, ColPali necesita 100–1 000 vectores. En corpus grandes (decenas de millones de páginas) esto equivale a varios terabytes de almacenamiento vectorial. Qdrant ofrece soporte nativo para multi-vector retrieval e interacción tardía al estilo ColBERT, lo que simplifica la implementación. Para la mayoría de los corpus industriales (10 000–500 000 páginas) este overhead es aceptable — los despliegues muy grandes deben calcular explícitamente los costes de almacenamiento.

3. Unified multimodal embeddings

Tercer enfoque: un modelo de embedding que procesa de forma nativa texto e imágenes en un único espacio. Ejemplos: Cohere Embed v4 (ventana de contexto de 128 000 tokens, texto + imágenes, API enterprise), voyage-multimodal-3.5 (Voyage AI, soporta fotogramas de vídeo). Toda la página se embebe directamente sin generar texto, obteniendo un único vector por página.

Ventajas: simplicidad, necesidades de almacenamiento moderadas (comparables a los embeddings de texto de vector único), sin dependencia de la calidad de las descripciones generadas por el VLM. Desventaja: estos modelos solo están disponibles como cloud API — no son adecuados para entornos on-prem o air-gapped. La precisión de retrieval es inferior a ColPali en los documentos visuales más exigentes, pero suficiente para la mayoría de los corpus enterprise y notablemente superior al de solo texto.

Parsing: Docling y Unstructured

Mientras que la arquitectura de embedding determina la calidad del retrieval, el parsing determina qué entra en el índice. Dos librerías open-source cubren la mayor parte de las necesidades:

`Docling` (IBM, Apache 2.0) convierte PDFs a JSON estructurado. Reconoce tablas, preserva la jerarquía del documento (capítulo → subcapítulo → contenido), extrae imágenes con referencias a su posición en la página. Es rápido incluso en CPU y no requiere GPU para documentos de texto habituales. Para la mayoría de los PDFs industriales con tablas impresas es la herramienta de partida.

`Unstructured` tiene un alcance más amplio: entiende más formatos (DOCX, PPTX, HTML, correos electrónicos, hojas de cálculo en Excel), tiene un modo de inferencia para clasificar elementos mediante un modelo. Para documentos escaneados use el modo hi_res, que activa OCR y analiza el layout de la página a través de un modelo de visión. Desventaja: hi_res es lento sin GPU y genera dependencia de una imagen Docker con los modelos.

Para planos industriales (P&ID, esquemas eléctricos) ninguna de las dos herramientas ofrece comprensión semántica — extraen píxeles o texto, no la lógica de conexión. Si necesita Q&A sobre el contenido lógico de un plano (no solo sobre las etiquetas), necesita un prompt VLM especializado con conocimiento de dominio o anotaciones manuales. A este tema le dedicamos un tratamiento más detallado en el artículo LLM sobre documentación industrial.

Tablas: el problema más frecuente en la práctica

Las tablas son un caso especial que merece su propia sección. En la práctica vemos tres tipos de tablas en documentos industriales, cada uno con un enfoque distinto:

Tablas paramétricas (tipos de equipos × valores) — bien procesables con Docling o el parser de tablas de LlamaIndex. Convierta a representación Markdown o JSON antes de indexar. Preserve el encabezado como parte de cada fila en el paso de chunking — el parent-child chunking donde parent = tabla completa y child = fila con encabezado es un patrón consolidado.

Tablas escaneadas — requieren VLM. Envíe la imagen de la tabla al modelo con un prompt explícito: «Extrae el contenido de esta tabla en formato JSON, conserva el encabezado de columnas, todos los valores incluyendo unidades y notas.» Verifique el resultado — el VLM puede fallar con valores manuscritos o símbolos no estándar.

Tablas con referencias cruzadas (p. ej. el código de la pieza apunta al plano) — aquí el enfoque de solo texto no basta ni con un buen parser. Se necesita vinculación explícita de entidades: id del registro de la tabla ↔ id del plano, almacenados en los metadatos. El enfoque agentic RAG, donde el agente puede realizar una segunda recuperación a partir de la referencia encontrada, mejora significativamente las respuestas aquí. Más sobre agentic RAG en el artículo Agentic RAG.

Cuándo necesita realmente el RAG multimodal

El RAG multimodal añade complejidad y coste. Antes de implantarlo, respóndase honestamente estas preguntas:

• ¿Qué porcentaje de la información que preguntan sus usuarios está vinculado a tablas o imágenes? Si es menos del 20 %, resuélvalo de forma puntual (descripciones manuales de los planos clave) y no construya todo un pipeline multimodal.
• ¿Son sus documentos principalmente impresos (PDFs digitales) o escaneados? Los escaneados requieren GPU durante la ingestion, lo que aumenta los costes de indexación.
• ¿Necesita on-prem o es aceptable una cloud API? Los embeddings multimodales unificados más potentes están actualmente disponibles solo a través de API.
• ¿Con qué frecuencia se actualizan los documentos? El pipeline caption-and-index es más barato en la primera ejecución, pero con cada actualización del corpus hay que regenerar las descripciones de las imágenes — las llamadas al VLM tienen un coste.

Para la mayoría de los despliegues industriales con manuales técnicos habituales (impresos, tablas estructuradas, planos con etiquetas) el caption-and-index con parser `Docling`/`Unstructured` y un VLM potente es suficiente y notablemente más barato que ColPali.

ColPali o los embeddings multimodales unificados se justifican cuando se tienen documentos visualmente ricos donde la descripción textual no es suficiente para capturar la información — por ejemplo, esquemas hidráulicos complejos con ramificaciones multinivel, o documentos donde el layout de la página en sí mismo porta información.

Retos que ningún tutorial menciona

De decenas de despliegues emergen problemas con los que casi todos se topan:

Coste de ingestion: Si tiene 500 000 páginas y cada una contiene de media 2 imágenes, generar descripciones a través de una cloud API de VLM puede costar del orden de miles de euros en una indexación puntual. Calcúlelo de antemano. Los VLM locales (p. ej. Qwen2.5-VL 7B o 72B) reducen este coste al precio de las horas de GPU, pero requieren VRAM suficiente — el modelo de 72B en cuantización de 4 bits necesita del orden de 40+ GB de VRAM.

Versiones de documentos: La documentación técnica tiene revisiones. El plano Rev3 puede tener valores distintos al Rev1. El pipeline multimodal debe preservar la versión como metadato y el retrieval debe saber filtrar por ella. Importa si quiere la versión actual o una revisión concreta.

Punto muerto en la evaluación: Las métricas RAGAS (Faithfulness, Context Recall, Answer Relevancy) funcionan bien para texto. Para retrieval multimodal no existe un benchmark estandarizado sobre sus propios documentos. Hay que crear manualmente un gold dataset — 100–200 preguntas con respuestas verificadas — y medir sobre él. Sin esto no podrá evaluar si un cambio de arquitectura ha ayudado o perjudicado.

Las alucinaciones siguen existiendo: El RAG reduce significativamente las alucinaciones respecto al LLM puro, pero no las elimina. Si el VLM describió mal una tabla durante la ingestion, el modelo responderá con convicción basándose en la descripción incorrecta. Importante: la métrica de faithfulness mide la coherencia de la respuesta con el contexto proporcionado — no la exactitud factual del contexto en sí. Si la descripción de la imagen es errónea, el faithfulness será alto y la respuesta seguirá siendo incorrecta. Más sobre citas y grounding en el artículo citas y grounding en RAG.

Arquitectura recomendada para PDFs industriales

Si tuviéramos que condensar la experiencia de despliegues en ingeniería mecánica y energía en una recomendación concreta:

1. 1.Parsing: Docling para PDFs impresos, Unstructured hi_res para escaneados. Extraiga tablas como entidades independientes, imágenes como bloques referenciables.
2. 2.Tablas: convertir a Markdown o JSON, indexar con parent-child chunking. El encabezado debe formar parte de cada child chunk.
3. 3.Imágenes y planos: para documentos habituales, caption-and-index con prompt VLM orientado al dominio (industria, electrotecnia, hidráulica). Para documentos visualmente intensivos, considere embeddings multimodales unificados (Cohere Embed v4 o Voyage) o ColQwen2.5 si el almacenamiento es aceptable.
4. 4.Embedding + retrieval: BGE-M3 sigue siendo una opción open-weight fiable para textos industriales en SK/CZ/PL — combina dense, sparse y multi-vector en un único modelo. La búsqueda híbrida (BM25 + dense) es casi obligatoria en documentación técnica por la coincidencia exacta de códigos e identificadores de equipos.
5. 5.Reranking: BGE-reranker-v2-m3 (self-hosted) o Cohere Rerank API. Añade latencia, pero es decisivo en documentación compleja donde el mismo término aparece en cientos de lugares.
6. 6.Almacenamiento: Qdrant para los casos multi-vector, pgvector si tiene infraestructura PostgreSQL existente y un volumen inferior a 50 millones de vectores.
7. 7.Evaluación: gold dataset de 100–200 preguntas extraídas de consultas reales de usuarios, RAGAS para métricas de texto, anotación manual para respuestas multimodales.

Preguntas frecuentes

¿Es ColPali siempre mejor que caption-and-index?

No. ColPali logra un mayor recall en documentos visualmente exigentes, pero a cambio de 100–1 000 veces más vectores por página. Para la mayoría de los corpus industriales con tablas impresas y planos descriptivos, caption-and-index con un buen prompt VLM es suficiente a una fracción del coste de almacenamiento. ColPali se justifica donde el layout de la página porta en sí mismo información que una descripción textual no puede capturar.

¿Puedo usar modelos VLM locales o debo pagar por una cloud API?

Los VLM locales son una alternativa plenamente funcional. Qwen2.5-VL en la variante 7B funciona en una GPU de consumo con 16–24 GB de VRAM; la variante 72B en cuantización de 4 bits necesita del orden de 40+ GB de VRAM. Para el pipeline caption-and-index donde el VLM se ejecuta durante la ingestion (no en cada consulta), el modelo local es económicamente ventajoso en corpus grandes. Desventaja: menor throughput durante la indexación. Las cloud API (GPT-4o, Gemini) ofrecen mayor calidad en las descripciones, pero con 500 000+ páginas el coste puede ser significativo.

¿Cómo gestionar documentos en varios idiomas — eslovaco, inglés, alemán?

Para el embedding recomendamos BGE-M3 o Qwen3-Embedding-8B — ambos modelos cubren eslovaco, checo, polaco, alemán e inglés dentro de su entrenamiento multilingüe. Para el captioning VLM de documentos industriales, el inglés sigue siendo el idioma recomendado para las descripciones (los modelos son notablemente más potentes en él), pero el retrieval funciona también en eslovaco gracias a los embeddings multilingües.

¿Cuándo tiene sentido usar una base de datos vectorial en lugar de pgvector?

pgvector es una opción de producción legítima hasta 50 millones de vectores con infraestructura PostgreSQL existente. Para multi-vector retrieval (estilo ColPali) con decenas de vectores por página y un millón de páginas, Qdrant con soporte nativo de ColBERT es notablemente más eficiente. La comparación de bases de datos se encuentra en el artículo bases de datos vectoriales — comparativa.

¿Cuál es el tiempo y coste típicos de indexación de un corpus industrial?

Depende del enfoque. Caption-and-index sobre 100 000 páginas con una mezcla de texto, tablas e imágenes: con cloud API de VLM del orden de cientos de euros; con VLM local de 7B del orden de horas de GPU en el equivalente a un A100. La arquitectura ColPali acelera la indexación (no es necesario generar descripciones), pero la infraestructura de retrieval (almacenamiento multi-vector) es más costosa. El parsing de solo texto con Docling sin VLM es carga puramente de CPU y gestiona cientos de miles de páginas en horas en un servidor convencional.

*El RAG multimodal no es una «funcionalidad vistosa» — es un requisito previo para un sistema fiable en cualquier corpus donde las tablas y los planos contienen información crítica. En la industria, esto aplica a la mayor parte de la documentación técnica. Si se enfrenta a un problema similar — tiene documentos donde el pipeline de solo texto da respuestas insatisfactorias — con mucho gusto analizamos su caso concreto y le proponemos una arquitectura adaptada a su corpus y sus requisitos de infraestructura.*