Visión RAG vs OCR 2026: ¿qué enfoque es mejor para trabajar con documentos

Con la llegada de GPT-4V en 2023 y el posterior desarrollo de modelos multimodales, la pregunta en las discusiones técnicas ha sido recurrente: ¿es necesario el OCR en absoluto si un modelo de Visión puede leer un documento directamente como una imagen? En 2025-2026, esta pregunta se ha vuelto práctica: hay herramientas, hay benchmarks, hay proyectos reales. Es hora de resumir los compromisos.

Este artículo está dirigido a arquitectos que diseñan u optimizan canalizaciones RAG de documentos y quieren entender qué enfoque es adecuado para su escenario. Si necesita un análisis técnico de cómo los errores de OCR arruinan el chunking y los embeddings, lea el artículo anterior de la serie: "Cómo el OCR afecta la calidad de los sistemas RAG: un análisis técnico".

Por qué el procesamiento de documentos es una tarea no trivial para la IA

"Conectar la IA a los documentos de la empresa" suena simple. En la práctica, entre esta frase y un sistema RAG funcional hay varios problemas no triviales, cada uno de los cuales afecta la elección del enfoque arquitectónico.

Problema 1: los documentos no son solo texto

El 70-80% de los datos corporativos no están estructurados: escaneos, imágenes PDF, formularios en papel. Incluso un PDF "digital" puede contener tablas como imágenes, páginas con diseños complejos o diagramas incrustados. Ningún analizador de texto lee píxeles.

Problema 2: la estructura del documento tiene significado

En la línea de una factura "50 | Cable | 120 UAH", el significado se define por la posición en la tabla. Si la tabla se descompone en texto lineal: "50 Cable 120 UAH", la conexión entre cantidad, nombre y precio se pierde. El OCR tradicionalmente ignora las relaciones espaciales entre los elementos.

Problema 3: heterogeneidad de archivos

Un archivo corporativo real rara vez es homogéneo. Contiene PDFs digitales limpios, escaneos de calidad variable, documentos con diseños complejos, notas manuscritas, formularios mixtos. Una solución que funciona perfectamente para un tipo puede fallar por completo en otro.

Es precisamente esta heterogeneidad la que convierte la elección entre OCR-first y Vision-first no en una cuestión académica, sino en una decisión arquitectónica con consecuencias reales para la calidad y el costo del sistema.

Arquitectura OCR-first: el enfoque clásico y sus límites

OCR-first es el enfoque estándar para los sistemas RAG de documentos en los últimos 3-4 años. La lógica es simple: convertimos la imagen en texto, y luego trabajamos con una canalización RAG de texto estándar.

Arquitectura OCR-first

Documento (escaneo / PDF)
  ↓
Preprocesamiento de imagen (enderezar, eliminar ruido, orientación)
  ↓
Motor OCR → texto plano
  ↓
Postprocesamiento (normalización, eliminación de basura)
  ↓
Chunking
  ↓
Embeddings de texto (text-embedding-3-small, BGE, E5)
  ↓
Base de datos vectorial → Recuperación → LLM
  

Ventajas de OCR-first

Límites del sistema OCR-first

Un análisis detallado de dónde y cómo estas limitaciones rompen el chunking, los embeddings y la recuperación se encuentra en el artículo anterior de la serie: "Cómo el OCR afecta la calidad de los sistemas RAG".

Arquitectura Visión-first: GPT-4o, Gemini, Qwen2.5-VL, olmOCR, Docling

El enfoque Visión-first reemplaza o omite el paso de OCR: el documento se pasa a un modelo de Visión-Lenguaje (VLM) como una imagen, y el modelo extrae el texto, la estructura y el contexto por sí mismo.

Arquitectura Visión-first (TextRAG a través de análisis de Visión)

Documento (escaneo / PDF / imagen)
  ↓
Renderizado de páginas como imágenes (pdf2image / PyMuPDF)
  ↓
Análisis VLM → texto estructurado (Markdown / JSON)
  ↓
Chunking (basado en la estructura conservada)
  ↓
Embeddings de texto → Base de datos vectorial → Recuperación → LLM
  

Arquitectura VisRAG (embeddings de imágenes)

Documento → páginas como imágenes
  ↓
Embeddings visuales (ColPali, ColQwen2, modelos tipo MuRAG)
  ↓
Base de datos vectorial multimodal (imágenes + consultas de texto)
  ↓
Recuperación → imágenes de página relevantes
  ↓
Generación de respuesta VLM basada en las imágenes encontradas
  

En el enfoque VisRAG, el embedding se calcula no a partir del texto, sino de la imagen de la página en sí. La recuperación se realiza en un espacio multimodal: la consulta de texto se compara con los vectores de las imágenes. La investigación VisRAG (ICLR 2025) muestra que este enfoque proporciona una **mejora del 20-40% en el resultado de extremo a extremo** en comparación con el TextRAG tradicional en documentos multimodales, gracias a la preservación de la información de diseño que la canalización OCR de texto pierde.

Resumen de herramientas de Visión actuales (2025-2026)

Dónde OCR pierde estructura: tablas, columnas, encabezados

Para entender dónde Vision gana, es necesario ver específicamente dónde OCR pierde. Consideremos tres modos de fallo más comunes.

Modo de fallo 1: tablas con celdas combinadas

La consulta "¿cuál es el beneficio para T1–T2 2024?" no coincide en la variante OCR: "T1–T2 2024" y "1 100 000" se encuentran en posiciones diferentes del texto lineal sin conexión estructural. En la variante Vision, la tabla se conserva, la recuperación encuentra la fila correcta.

Modo de fallo 2: diseño multicolumna

Un documento de dos columnas (por ejemplo, una historia clínica o un artículo científico) es leído por OCR de izquierda a derecha a lo ancho de la página. Resultado: las oraciones de la columna izquierda y derecha se alternan en un solo flujo de texto. El divisor de oraciones corta en lugares incorrectos. Los fragmentos contienen contexto mixto de dos temas no adyacentes.

El modelo Vision identifica las columnas como bloques de texto separados y lee cada una de forma independiente. Según el benchmark comparativo de Procycons (2025), Docling con TableFormer maneja correctamente tablas complejas donde Unstructured (basado en OCR) produce desplazamientos de columnas y un índice de contenido incompleto.

Modo de fallo 3: encabezados jerárquicos y orden de lectura

Una especificación técnica con secciones H1 → H2 → H3 → párrafo se convierte en texto continuo sin jerarquía después del OCR. El fragmentado semántico no "sabe" que este párrafo pertenece a la sección "4.2.1 Requisitos de seguridad", porque el marcado estructural se ha perdido. La recuperación para la consulta "requisitos de seguridad" puede omitir el fragmento correcto o devolver uno irrelevante.

olmOCR y Docling conservan el orden de lectura y la jerarquía de los encabezados en la salida, lo que permite que las estrategias de fragmentación se basen en los límites estructurales del documento, no solo en el tamaño del texto.

Dónde ganan los modelos Vision: diseño complejo, diagramas, texto manuscrito

Caso: documentación médica con contenido mixto

En la práctica de AskYourDocs, procesamos un archivo de un centro médico: historias clínicas escaneadas, donde cada página contenía una plantilla impresa, notas manuscritas del médico, un sello del departamento y resultados de análisis insertados como imágenes.

La canalización OCR solo daba un resultado satisfactorio en la parte impresa (~60% de la página). Las notas manuscritas del médico (críticas para el contexto clínico) se reconocían con un CER de ~8–12%, peor que el promedio debido a la especificidad de la terminología médica en forma manuscrita. Los resultados de análisis insertados como imágenes eran completamente inaccesibles.

Después de cambiar a GPT-4o-mini con un prompt detallado para documentación médica: la precisión en los campos manuscritos aumentó a un nivel aceptable, los resultados de los análisis se volvieron accesibles para la recuperación. El Recall@5 general en el conjunto de prueba de preguntas clínicas aumentó de 0.34 a 0.71.

Limitaciones: el costo aumentó ~15 veces; el procesamiento requirió un DPA con OpenAI y un acuerdo legal separado. Para un archivo pequeño (3.000 historias), esto fue aceptable. Para 50.000+ se necesita una opción autoalojada.

Comparación de la calidad de recuperación: TextRAG vs VisRAG

Ambos enfoques difieren fundamentalmente no solo a nivel de análisis, sino también a nivel de qué se vectoriza y cómo se realiza la recuperación.

TextRAG: embeddings de texto después de análisis OCR o Vision

En la canalización TextRAG (independientemente de si obtuvo el texto a través de OCR o análisis Vision), se vectoriza el texto. El modelo de embedding (text-embedding-3-small, BGE, E5) convierte un fragmento de texto en un vector. La recuperación es una búsqueda ANN en el espacio de texto.

Problema: si la información de diseño (posición de los elementos en la página, jerarquía, estructura tabular) no se conserva en el texto, se pierde para la recuperación. OCR → embeddings de texto: dos pasos con pérdida de información.

VisRAG: embeddings de imágenes de página

VisRAG (arXiv 2410.10594, ICLR 2025) propone un enfoque fundamentalmente diferente: el embedding se calcula no a partir del texto, sino de la imagen de la página misma a través de un Modelo de Lenguaje de Visión (ColPali, ColQwen2 y análogos). La recuperación es una búsqueda en un espacio multimodal: la consulta de texto se compara con los vectores de imagen.

Ventaja: el diseño, el color, la posición, la fuente, la estructura de la tabla, todo esto está codificado en el vector de la imagen. Ningún paso de pérdida de información entre el documento original y los embeddings.

Resultados ICLR 2025: VisRAG supera al TextRAG tradicional tanto en la etapa de recuperación como en la de generación, logrando un **aumento del 20–40% de extremo a extremo** en documentos multimodales. VisRAG 2.0 (octubre de 2025) además muestra una mejora del 27% en benchmarks de preguntas visuales a través de razonamiento multimagen guiado por evidencia.

Comparación de enfoques por métricas clave

Conclusión práctica: VisRAG es una dirección prometedora para documentos multimodales, pero en 2026 aún no está listo para producción para la mayoría de los escenarios corporativos. Vision → TextRAG (análisis a través de VLM + embeddings de texto) es un compromiso más maduro que combina la calidad del análisis Vision con la previsibilidad de la pila RAG estándar.

Costo: tokens, latencia, infraestructura

Para un arquitecto, el costo no es solo el precio de la API. Es la suma de cómputo, latencia, complejidad operativa y características de escalabilidad. Analicemos cada dimensión.

Costo de análisis: OCR vs API de Visión

La diferencia entre OCR autoalojado y GPT-4o para 100.000 páginas es de 60x a 600x. Con un flujo diario de 10.000 nuevos documentos al año, esto son millones de páginas. A esta escala, el costo de la API de Visión se convierte en la principal limitación arquitectónica.

Latencia: qué significa para diferentes escenarios

Para sistemas en tiempo real —procesamiento automático de facturas entrantes, indexación de documentos en el momento de la recepción— la API de Visión es prácticamente inadecuada sin un nivel empresarial de acceso.

Complejidad de infraestructura

Enfoque híbrido: cuándo y cómo combinar OCR + Visión

Creo que para la mayoría de los archivos corporativos, el mejor enfoque no es abandonar por completo el OCR en favor de los modelos de Visión, sino combinarlos. En la práctica, esto permite reducir significativamente los costos —a veces entre 5 y 10 veces— y, al mismo tiempo, mantener una alta calidad en el procesamiento de documentos con diseños complejos, tablas y gráficos.

Arquitectura de pipeline híbrido

Documento de entrada
  │
  ├─► ¿Capa de texto? → Sí → Analizador nativo (PyMuPDF / Docling)
  │                                    ↓
  │                              Texto estructurado
  │
  └─► No (escaneo o imagen)
          │
          ├─► Clasificador de tipo de documento
          │         │
          │         ├─► Documento estándar (contrato, factura, informe)
          │         │         ↓
          │         │   OCR autoalojado (PaddleOCR / Tesseract)
          │         │         ↓
          │         │   Detector de basura (ratio alfabético, langdetect)
          │         │         │
          │         │         ├─► Calidad OK → Postprocesamiento → Chunking
          │         │         └─► Calidad baja → Fallback de Visión
          │         │
          │         └─► Documento complejo (tablas, diagramas, manuscrito)
          │                   ↓
          │             OCR de Visión (GPT-4o-mini / olmOCR-2 / Docling)
          │                   ↓
          │             Markdown estructurado → Chunking
          │
          └─► Registro: tipo, ruta de procesamiento, evaluación CER
  

Criterios de enrutamiento: qué enviar a Visión

Visión autoalojada como alternativa compatible con GDPR

Para organizaciones donde los datos no se pueden enviar a APIs en la nube, pero la calidad del OCR clásico es insuficiente, olmOCR-2 (82.4 en olmOCR-Bench) y Docling con TableFormer ofrecen calidad apta para producción con autoalojamiento completo. Qwen2.5-VL-7B es otra opción para un equilibrio medio entre calidad/cómputo (requiere GPU de ~16 GB de VRAM).

Granite-Docling-258M de IBM es una alternativa compacta para entornos con recursos limitados: 258M de parámetros con una precisión a la par con modelos varias veces más grandes (Apache 2.0, autoalojado).

Recomendaciones: matriz de selección por tipo de documento y presupuesto

Árbol de decisión corto para el arquitecto

Conclusiones

La elección entre OCR y Visión en 2026 no es una elección entre lo viejo y lo nuevo. Es una elección de compromisos que dependen del archivo específico, el presupuesto y los requisitos de cumplimiento.

Conclusiones clave

La siguiente pregunta después de elegir la arquitectura de análisis es cómo vectorizar de manera óptima el texto obtenido. La dimensionalidad del vector de embedding, la elección del modelo y el impacto en la calidad de la recuperación son el tema del próximo artículo de la serie.