RAG multimodal: recuperación de imágenes, PDF y tablas

El RAG multimodal amplía el patrón de Retrieval-Augmented Generation a todo lo que no es texto corrido limpio: imágenes, PDF escaneados, tablas, gráficos y diagramas. El RAG clásico solo indexa texto. En cuanto la información está sobre todo en el layout, en una tabla o en un gráfico, un pipeline solo de texto pierde justo la sustancia decisiva para la respuesta. El RAG multimodal hace que estos contenidos se puedan indexar y recuperar. Así se pueden citar con respaldo de las fuentes.

• ¿Qué se recupera? Texto plano, imágenes de páginas, estructuras de tablas, contenidos de gráficos y documentos escaneados.
• ¿Cómo? Mediante embeddings multimodales (CLIP, ColPali), descripciones generadas por un LLM de visión o parsing sensible al layout, normalmente combinados.
• ¿Para qué? Documentación técnica, facturas, informes: allí donde el conocimiento está en el layout y los gráficos, no en el texto corrido.

Por qué el RAG clásico fracasa con imágenes y tablas

Un pipeline RAG clásico funciona en dos rutas: en la ruta de indexación, las fuentes se cargan, se parsean, se dividen en chunks, se convierten en embeddings y se escriben en una base de datos vectorial. En la ruta de consulta, se genera el embedding de la pregunta, se recuperan los fragmentos mediante recuperación híbrida, se reordenan con reranking y se insertan en el prompt del LLM generador. El punto débil para los contenidos no textuales está justo al principio: en el parsing y el chunking.

Aquí dominan dos antipatrones. Primero: el chunking ingenuo de tamaño fijo ignora los límites de frases, tablas y listas. Una estrategia de ventanas de 512 tokens corta una tabla en mitad de una fila, y el contenido de la tabla se pierde o queda desvirtuado. Las consecuencias típicas son alucinaciones y valores que faltan. Segundo: semántica pura sin BM25. Los embeddings a menudo no captan códigos exactos como un número de artículo «TS-999» o un número de factura, porque la similitud semántica no sirve de nada aquí. La búsqueda híbrida con fusión de rankings (RRF) recoge esas coincidencias exactas y, por eso, sigue siendo obligatoria también en la variante multimodal.

En los PDF escaneados, la dificultad aumenta porque ni siquiera hay capa de texto. Sin OCR ni retrieval visual, la página es sencillamente invisible para un RAG de texto.

Los tres enfoques del retrieval multimodal

1. Embeddings multimodales (CLIP, ColPali)

Los modelos de embedding multimodales representan imagen y texto en el mismo espacio vectorial. Así, una consulta de texto se puede comparar con vectores de imagen y viceversa. CLIP es el representante conocido para la vinculación genérica entre imagen y texto. ColPali va un paso más allá y está diseñado específicamente para el retrieval de documentos: indexa la página renderizada como imagen y se salta así el parsing intermedio a texto, propenso a errores. El layout, las tablas y los gráficos se conservan como contexto visual. Esto resulta especialmente potente en documentos cuyo significado reside en el layout.

También en el mainstream, la capa de embeddings se desplaza hacia la multimodalidad. Google puso Gemini Embedding 2 en disponibilidad general en abril de 2026. Según el paper del modelo, sitúa texto, imágenes, vídeo y audio en un espacio vectorial común y alcanza 69,9 puntos en MTEB Multilingual, un dato del fabricante. Su predecesor, gemini-embedding-001, es un modelo solo de texto. Como los valores de MTEB cambian cada semana y MTEB v2 no es directamente comparable con v1, anota la fecha del snapshot en cada elección de modelo.

2. LLM de visión para la descripción

Aquí, un LLM con capacidad de visión se encarga del preprocesamiento: recibe la imagen, la tabla o el gráfico y genera una descripción textual precisa. Esta descripción se convierte en embedding de la forma habitual y se escribe en la base de datos vectorial. Ventaja: el stack de RAG de texto existente sigue siendo útil, y el retrieval funciona con embeddings de texto probados. Inconveniente: la descripción solo es tan buena como el modelo de visión y cuesta una llamada adicional al LLM por cada asset durante la indexación. Para gráficos y diagramas, este enfoque suele ser preciso, porque un buen LLM de visión sabe verbalizar ejes, tendencias y puntos de datos.

3. Parsing sensible al layout

El tercer camino separa limpiamente la estructura antes de generar los embeddings. Los parsers sensibles al layout reconocen tablas, listas, encabezados y columnas, y conservan esa estructura. Para ello hay varias herramientas listas para producción (a fecha de 2026): Docling (IBM, open source), Unstructured.io, LlamaParse, Marker (datalab.to), PyMuPDF, así como motores de OCR como Tesseract, Azure Document Intelligence y AWS Textract. El framework RAGFlow incluye explícitamente «Deep Document Understanding» con Document Layout Analysis (DLA) y OCR. En la capa de chunking, la estrategia adecuada es el chunking sensible al layout (Docling, Unstructured), que conserva la estructura de tablas, listas y encabezados, ideal para PDF, contratos y manuales técnicos.

Comparativa de enfoques

En la práctica, estos enfoques no son una decisión excluyente. Un sistema en producción combina parsing sensible al layout para tablas estructuradas, descripciones con un LLM de visión para gráficos y búsqueda híbrida para coincidencias exactas.

Casos de uso típicos

• Documentación técnica: manuales con despieces, esquemas eléctricos y tablas de especificaciones. El benchmark Agri-Query (agosto de 2025) evalúa un único manual de maquinaria agrícola en inglés, francés y alemán, convertido previamente a Markdown con Docling. Allí, el RAG híbrido de BM25 y búsqueda por embeddings supera al prompting directo de contexto largo. Con él, Gemini 2.5 Flash alcanza una exactitud del 88 % en inglés y del 87 % en alemán. Según el propio benchmark, no mide si un modelo sabe interpretar tablas e ilustraciones. Por tanto, demuestra retrieval de texto, no retrieval multimodal.
• Facturas: tablas de líneas, importes, tipos impositivos y números de factura. Aquí es decisiva la combinación de extracción de la estructura de tablas y coincidencia exacta con BM25 sobre los códigos.
• Informes y presentaciones: cifras trimestrales en gráficos, dashboards de KPI, diagramas. La descripción de los gráficos con un LLM de visión más el parsing de tablas cubre ambas cosas.

Ejemplo concreto: RAG de facturas

Supongamos que un proveedor de servicios quiere que se pueda buscar en 50.000 facturas PDF escaneadas, para que un agente de soporte pueda responder preguntas como «¿Qué tipo impositivo se aplicaba a la línea 3 de la factura TS-2024-0815?».

```
INDEXACIÓN (offline):
[50.000 escaneos PDF]
-> OCR (Tesseract / Azure Document Intelligence)
-> Parsing sensible al layout (Docling): detecta la tabla de líneas
-> serializar la tabla conservando la estructura (Markdown)
-> opcional: un LLM de visión describe el layout/los sellos
-> Embedding (multilingüe, p. ej., Cohere Embed v4)
-> upsert en la BD vectorial + índice BM25 paralelo
(metadatos: tenant_id, numero_factura, fecha, ACL)

CONSULTA (online):
[Pregunta] -> Embedding + consulta BM25 ("TS-2024-0815")
-> Recuperación híbrida (top_k = 50)
-> Re-Ranker (Cohere Rerank v3.5), top_k = 5
-> Prompt + cita de la fuente (número de factura + snippet)
-> LLM -> respuesta con comprobación de faithfulness (RAGAS)
```

La ruta BM25 encuentra el número de factura exacto que un embedding por sí solo no captaría. El parser de layout se encarga de que «línea 3» y su tipo impositivo permanezcan en la misma fila estructurada, en lugar de quedar separados por el chunking de tamaño fijo. El reranking reduce aún más la tasa de error: en Contextual Retrieval de Anthropic, la tasa de error top-20 baja un 49 % con Contextual Embeddings y Contextual BM25, y un 67 % con reranking adicional (del 5,7 al 1,9 %, texto, datos de 2024). En los pipelines multimodales, el principio del reranking se aplica de forma análoga.

Escollos con layouts complejos

• Tablas anidadas y de varias columnas: los parsers asignan mal las celdas. Prueba antes del despliegue con documentos reales, no con ejemplos ideales.
• Mala calidad de escaneo: los errores de OCR se propagan a cada paso posterior. Aquí, los enfoques visuales como ColPali suelen ser más robustos, porque se saltan el paso de OCR.
• Falta de reranking y de evaluación: sin medición de faithfulness, las regresiones de calidad pasan desapercibidas. RAGAS mide según Faithfulness, Answer Relevancy, Context Precision y Context Recall. Esto debe formar parte de la CI.
• Lost-in-the-chunks: un chunk «Aumentó un 12 %» sin encabezado de contexto no sirve de nada. El Contextual Chunking (Anthropic 2024) antepone un contexto generado por un LLM y mejora de forma medible la calidad del retrieval.
• Deriva de embeddings al cambiar de modelo: cambiar el modelo de embedding multimodal exige reindexarlo todo. Guarda la cadena de versión en el índice.
• RGPD en facturas y escaneos: los datos personales contenidos en imágenes y tablas están sujetos a las mismas obligaciones: separación de clientes, concepto de roles, pipeline de borrado para chunks y embeddings, alojamiento en la UE (cf. guía orientativa de la DSK sobre RAG). Informativo, no constituye asesoramiento jurídico.

Para agencias y responsables de decisiones B2B

En 2026, el RAG multimodal es un tema de producción: decide si un asistente de IA llega a aprovechar los documentos más valiosos de la empresa (manuales técnicos, facturas, informes) o fracasa con ellos. Para las agencias, la palanca está en elegir bien los componentes según el tipo de documento: parsing sensible al layout para PDF estructurados, retrieval visual para escaneos y gráficos, búsqueda híbrida y reranking como estándar. Si quieres montar un sistema de conocimiento con imágenes, PDF escaneados y tablas que esté listo para producción, sea conforme al RGPD y tenga una faithfulness medible, deberías planificar la arquitectura y la evaluación juntas desde el principio. Blck Alpaca acompaña a empresas de toda Europa precisamente en este diseño, desde el pipeline de ingesta hasta una toolchain soberana en la UE.