El stack de documentos libre de OCR 2026: ColPali, ColQwen, ModernVBERT y Qdrant
Los modelos de retrieval visual buscan la página como imagen en lugar de por OCR. Un panorama sobrio.
Traducción generada automáticamente con IA. La versión alemana es el original revisado por la redacción.
Para el RAG documental, el OCR en 2026 ya no es el primer paso evidente. Una serie de modelos de retrieval visual busca la página directamente como imagen, es decir, con layout, tablas y diagramas, sin descomponerla antes en texto. Eso cambia dónde surgen los errores en una arquitectura RAG y qué piezas se necesitan siquiera. Cuatro nombres aparecen una y otra vez: ColPali, ColQwen, ModernVBERT y Qdrant. Este texto los ordena, sin bombo, con los puntos en los que vale la pena el cambio y aquellos en los que no.
01. Por qué el OCR era la parte tambaleante del pipeline
El OCR fue durante mucho tiempo el punto por el que entraban errores silenciosos en la respuesta. El camino clásico es una cadena: escanear la página, convertirla por OCR en texto, cortarla en trozos, incrustar, recuperar. Cada etapa pierde algo. Una página de dos columnas se recompone mal, una tabla se desmorona en cifras inconexas, un diagrama cae del todo, porque no es texto. En nuestra experiencia, en documentos difíciles la mayor parte del problema de calidad no está en el modelo de lenguaje, sino aquí, en la lectura. El retrieval visual aplica justo en esa etapa: se salta el reconocimiento de texto al buscar y trabaja sobre la imagen de la página.
02. Las cuatro piezas, brevemente explicadas
ColPali. La referencia, presentada en julio de 2024 (arXiv). Se construye sobre el modelo de visión y lenguaje PaliGemma y genera unos 1024 vectores de fragmento de imagen por página, cada uno de 128 dimensiones. En lugar de comprimir la página en un único vector, la granularidad se conserva. El cotejo pasa por Late Interaction, una técnica tomada de ColBERT que desglosamos aquí con más detalle.
ColQwen. La misma receta, otra base: ColQwen2.5 apuesta por Qwen2.5-VL en lugar de PaliGemma y suele ir por delante en el benchmark ViDoRe. Quien empieza hoy de cero, empieza sensatamente aquí.
ModernVBERT. La palanca de eficiencia. ColModernVBERT tiene 250M de parámetros, es decir, unas diez veces menos que ColPali, y según el paper queda aun así solo 0,6 nDCG@5 por debajo. Es la pieza que hace asequible el retrieval visual on-prem.
Qdrant. La infraestructura de debajo. Qdrant almacena los multi-vectores de estos modelos de forma nativa y calcula la puntuación de Late Interaction al buscar (documentación). Sin una base de datos vectorial que entienda varios vectores por página, no corre ninguno de los tres encoders.
03. Cuándo vale la pena el cambio, y cuándo no
El retrieval visual gana allí donde el layout porta la información. Contratos escaneados, facturas, hojas de datos, presentaciones, formularios, expedientes multilingües: todo aquello en lo que una cadena de OCR fracasa con regularidad. Además ahorra todo el mantenimiento de esa cadena.
Pero no es una ganancia general. Varios vectores por página cuestan más memoria y más índice que un único vector de texto, a menudo varias veces más. Con texto corrido limpio y puro, el RAG de texto clásico sigue siendo más barato y del todo suficiente. Y algunas tareas necesitan al final texto de todos modos, por ejemplo búsqueda de texto completo, copiar o un rastro de auditoría. Para eso sigue habiendo buenas razones para el OCR, en el híbrido junto al retrieval visual.
04. Una hoja de ruta sobria
- Probar con los propios documentos, no con el benchmark. ViDoRe es una buena referencia, pero su situación de expedientes no lo es. Tome las veinte páginas en las que su búsqueda actual fracasa.
- Empezar con ColQwen o ColModernVBERT, según el hardware. En una GPU justa, el modelo pequeño suele ser el más honesto.
- Montar Qdrant como almacén multi-vector, Late Interaction solo en la etapa de reordenación, para mantener el índice pequeño.
- Calcular el precio de memoria de antemano. El tamaño del índice es el punto que después duele, no la elección del modelo.
Quien busca el arco mayor, es decir, por qué los modelos locales y el retrieval propio van juntos: eso está en On-Premise contra Cloud. Las piezas individuales las profundizamos en textos propios, empezando por la mirada de la pyme.
