- Para extraer información de documentos complejos, los métodos tradicionales de OCR y parsing no logran preservar bien el significado
- Morphik implementa un enfoque de embeddings visuales de documentos basado en el modelo ColPali, que permite comprender directamente incluso tablas, gráficos y el contexto del layout
- Frente a los pipelines existentes, este método es muy superior en precisión y preservación de la información, y en pruebas de benchmark alcanzó hasta 95.56% de precisión
- Además, con la incorporación de MUVERA y Turbopuffer, logró mejoras de velocidad en la búsqueda de documentos a gran escala
- A futuro, el objetivo es la automatización real del trabajo documental, con capacidades como razonamiento multdocumento, integración en workflows e interpretación de nivel experto
Los límites del parsing de documentos complejos y las dificultades de RAG
- Al intentar extraer información de documentos PDF complejos mezclados con gráficos, diagramas y tablas, suele ocurrir que los pipelines de OCR y parsing pierden la información deseada
- En casos reales como tablas anidadas, diagramas importantes, documentos técnicos con muchas anotaciones e incluso manuales sin texto, se hacen evidentes los límites de los pipelines tradicionales
- Etapas del pipeline tradicional:
- Aplicar OCR al PDF (puede leer mal números o caracteres)
- Intentar separar tablas y diagramas con un modelo de detección de layout (con alta probabilidad de falla)
- Reconstrucción del orden de lectura (puede perder el flujo visual)
- Reconocimiento de captions de diagramas (a menudo se pierden matices)
- Chunking de texto (la información relacionada puede quedar separada)
- Generación de embeddings vectoriales y almacenamiento en una vector DB (se pierde la ubicación y el contexto)
- Ejemplo: incluso una tabla simple puede hacer que
1,000 se lea como l,0O0, o que la tabla y el encabezado queden separados y fallen los cálculos del total
- También son frecuentes casos reales de pérdida de información, como confundir la leyenda de un gráfico con el cuerpo del texto, o dispersar porcentajes en lugares incorrectos
Un nuevo enfoque: pasar a la comprensión visual de documentos
- El equipo de Morphik encontró un punto de inflexión con la pregunta: "¿Y si entendiéramos los documentos como objetos visuales, igual que lo hace una persona?"
- Gracias a investigaciones recientes (ColPali) y a los avances en Vision Language Model (VLM), es posible hacer embeddings directamente de imágenes y preservar el contexto completo del documento y su información visual sin parsing ni OCR
- Cada página del documento se procesa como una imagen de alta resolución y se divide por patches, generando embeddings que reflejan tanto la información visual como la textual
- El SigLIP-So400m Vision Transformer genera embeddings de patches visuales, y el modelo de lenguaje PaliGemma-3B comprende la estructura del documento
- Para consultas como "tendencia de ingresos del Q3", extrae con precisión la información relevante mediante una búsqueda de late interaction que incorpora pistas visuales como texto, gráficos, tablas y colores
- Se mantiene toda la información visual del documento, como ubicación, layout, color y cambios en gráficos, de forma similar a cómo una persona ve el documento de un vistazo
Comparación entre el parsing tradicional y el enfoque ColPali
- En los pipelines tradicionales basados en parsing, se pierde información en cada etapa, y al separar embeddings de texto e imagen resulta imposible interpretar las relaciones espaciales dentro del documento
- En cambio, el enfoque ColPali integra toda la información en un solo espacio de embeddings visuales, preservando el significado general y el contexto del documento completo
- En benchmarks reales (centrados en documentos financieros, con datasets públicos), Morphik (basado en ColPali) registró hasta 95.56% de precisión (LangChain+OpenAI text-embedding obtuvo 72%, y OpenAI file search apenas 13.33%)
- En el benchmark ViDoRe, el enfoque visual superó al parsing tradicional por más de 14 puntos porcentuales en nDCG@5
Optimización del rendimiento y uso en la práctica
- La desventaja del enfoque inicial era la caída de velocidad por la carga computacional, ya que su estructura requería búsqueda vectorial por cada patch y no era adecuada para decenas de millones de consultas por segundo
- Tomando como referencia el paper de MUVERA, se introdujo un método que reemplaza la búsqueda multivector por búsqueda de vector único (codificación de dimensión fija)
- Al combinarlo con la vector DB especializada Turbopuffer, la velocidad de consulta mejoró de 3-4 segundos a alrededor de 30 ms
- Esto permitió buscar entre millones de documentos a una velocidad muy superior a la del parsing de texto tradicional
Áreas de uso y una API fácil de usar
- Permite búsquedas de alta precisión en distintos tipos de documentos sin perder estructura visual ni información
- Documentos financieros donde las tablas y los gráficos complejos son clave
- Manuales técnicos centrados en diagramas
- Extracción de información basada en layout en facturas y recibos
- Comprensión de material visual y datos numéricos en papers de investigación
- Reconocimiento de relaciones basado en layout en historiales médicos
- La API tiene una estructura muy simple: se sube un documento y luego se consulta en lenguaje natural, permitiendo pedidos como "muéstrame todos los contratos con cláusulas de multa superiores a 10 mil dólares"
Dirección futura: inteligencia multdocumento y comprensión más profunda
- Inteligencia multdocumento: se está desarrollando la capacidad de referencias cruzadas y seguimiento de información entre varios documentos
- Más allá de la búsqueda en un solo documento, permitirá rastrear y razonar relaciones entre varios documentos (por ejemplo, conectar cláusulas contractuales → documentos regulatorios → manuales de ejecución)
- Sistema de comprensión agéntica: más allá del simple Q&A dentro de un documento, busca automatizar el razonamiento lógico entre chunks, como extracción de cláusulas → verificación con otros documentos → cross-check de detalles
- Integración en workflows: se quiere elevar la inteligencia de automatización documental para procesos reales, como comparar condiciones entre varios contratos o seguir el historial de decisiones técnicas
Límites actuales y objetivos a futuro
- El enfoque actual todavía no alcanza un nivel de interpretación experta y juicio contextual
- Aspectos como el análisis profundo de un especialista financiero siguen siendo técnicamente insuficientes, y hacen falta más desarrollos para requisitos enterprise como confiabilidad y cuantificación de la incertidumbre
- Entre los próximos desafíos clave están la combinación de comprensión visual con knowledge graphs de dominio, el razonamiento causal y la entrega de métricas de confiabilidad
Conclusión
- Los documentos deben tratarse como objetos visuales de conocimiento, y más allá de las limitaciones del parsing, la comprensión de documentos basada en imágenes es una solución superior para entornos RAG
- Morphik busca proponer un nuevo estándar para la extracción de información documental y apunta a la automatización de workflows documentales complejos y su aplicación en trabajo real
- Puedes probar las funciones en detalle en morphik.ai
1 comentarios
Opiniones en Hacker News
Hay varios problemas fundamentales que la gente debería conocer
Los LLM normalmente se preentrenan con 4k tokens de texto y luego se amplían a ventanas de contexto largas (pasar de 4000 a 4001 es fácil, pero con imágenes eso no es posible porque la tokenización funciona distinto)
Como resultado, se salen de la distribución y, al manejar más de dos o tres imágenes, las alucinaciones se vuelven un problema serio
Un PDF de 1536×2048 usa de 3 a 5 veces más tokens que texto, así que sube el costo de inferencia y se ralentiza la respuesta
Si bajas la resolución, la imagen se vuelve borrosa
Las imágenes ya son pesadas por su tamaño original, así que solo descargar las necesarias agrega latencia a cada solicitud
En benchmarks pequeños, obviamente funciona mejor que el chunking básico de texto para documentos financieros con muchas gráficas y tablas
Personalmente, me gustaría compararlo con algo como Gemini permitiendo anotar imágenes con OCR
Un enfoque end-to-end basado en imágenes tiene sentido en casos especiales (patentes, diagramas arquitectónicos, etc.), pero de verdad debería ser el último recurso
El problema es que el LLM puede inventarse texto plausible en las partes que no logra leer, y terminar empeorando el resultado
Por ejemplo, GPT4.1 funcionó perfecto con una captura de pantalla de 1296×179, pero al reducirla al 50% y dársela como 650×84 devolvió "Pdf's at 1536 × 2048 use 3 to 5X more tokens" como "A PNG at 512x 2048 is 3.5k more tokens"
Casi todo lo demás lo hace bien, pero hay que tener cuidado con estos cambios sutiles en los detalles
Una propiedad interesante de la familia gemma3 es que aumentar el tamaño de la imagen de entrada no incrementa los requisitos de memoria de procesamiento
Eso es porque el encoder de la segunda etapa la comprime en tokens de tamaño fijo
En la práctica resulta bastante útil
Pero hacerlo implicaría que todo el conjunto de documentos procesados tenga que pasar necesariamente por un VLM grande
Puede volverse demasiado caro y lento
Aquí claramente hay un trade-off
En la mayoría de los casos, la forma actual fue la más efectiva
A veces se mete todo al LLM, pero según el caso eso puede no encajar
No hace falta procesarlo todo obligatoriamente con un LLM
Siento que esto podría extenderse como una idea para cambiar el pipeline de RAG
Para cada resultado de RAG, en la etapa de procesamiento del modelo se podría extraer de la imagen la información directamente relevante para la consulta del usuario, juntar esos resultados (en texto) y usarlos como entrada para la generación final
Así se puede esquivar el límite de tokens de varias imágenes y paralelizar el proceso de comprensión visual
Mis colegas y yo implementamos algo así hace 6 meses para una agencia gubernamental francesa
Lo ofrecemos como open source aquí: https://github.com/jolibrain/colette
No es nuestro negocio principal y básicamente está abandonado, pero con un poco de tuning funciona bastante eficientemente
La verdadera gracia es que todo el pipeline se puede volver completamente diferenciable para hacer fine-tuning de viz rag especializado en un dataset específico
También se puede personalizar el modelo de layout para lograr comprensión documental precisa
En la mayoría de los casos, el mayor obstáculo es necesitar un set de evaluación de alta calidad (como siempre, ese es el cuello de botella)
He hecho varios estudios de benchmarking entre OCR e imagen + LLM genérico: https://getomni.ai/blog/ocr-benchmark
El mayor problema de extraer directamente desde imágenes son los documentos multipágina
En una sola página, (OCR=>LLM vs Image=LLM), la imagen directa salía apenas mejor, pero al pasar de 5 imágenes o más, la precisión se desplomaba frente al enfoque OCR-first
La verdad es que incluso el recall de contexto largo en texto ya es una tarea difícil, aunque los LLM sí están optimizados para eso; el recall de contexto largo en imágenes todavía está bastante verde
También funciona bastante bien poner una capa pequeña de transformación LLM directamente sobre las imágenes (es decir, en vez de hacer OCR directo, enviar 5 imágenes de una sola vez a un modelo de visión pequeño para extraer solo los puntos más importantes del documento)
Ahora mismo estamos investigando modificar el caché o los mapas de atención del LLM para que lotes más grandes de imágenes funcionen mejor
Enfoques como sliding window o infinite retrieval se ven prometedores
Es una impresión personal, pero viendo cómo se acelera el progreso de los modelos multimodales, creo que pronto el contexto largo en imágenes dejará de ser un gran problema
Este post del blog hace buenos señalamientos sobre usar modelos de visión para retrieval, pero quiero marcar algunos problemas
Document parsing es convertir documentos en texto estructurado como Markdown/JSON (o en salidas ajustadas a un esquema cuando se extrae información)
RAG es uno de esos usos, pero hay muchos otros
ColPali es excelente para retrieval, pero (al menos de forma nativa) no sirve para document parsing puro
El autor habla sobre todo de benchmarks de visual retrieval
Muchas veces funciona mejor que OCR estándar, pero
a. todavía tiene problemas de precisión en la cola larga
b. faltan metadatos como confidence score, bounding box, etc.
c. el pipeline de screenshots en sí también requiere esfuerzo si quieres llevarlo a un nivel sofisticado
Los tokens de imagen son mucho más potentes, pero los de texto son muchísimo más baratos de almacenar, así que permiten consultar el documento completo en retrieval (no solo por chunks)
(Nota: soy CEO de llamaindex y he trabajado tanto parsing como retrieval con LlamaCloud; esto es solo una visión general)
El año pasado dediqué bastante tiempo a construir un sistema de análisis de documentos de patentes
Las patentes incluyen contenido muy variado, como diagramas abstractos, fórmulas químicas y ecuaciones, así que preparar los datos para un LLM es realmente complicado
El método más simple que encontré fue convertir cada página como si le tomara una “foto” y luego pedirle al LLM que genere un JSON con la descripción del contenido y metadatos (número de página, cantidad de elementos visuales, etc.)
Para imágenes complejas, basta con pedirle al modelo que las describa
Así se puede embeber fácilmente el JSON en el vector store que quieras
Es difícil evaluar la eficiencia costo-beneficio, pero este enfoque me parece más simple y efectivo que el propuesto por el autor
Por ejemplo, aunque el modelo extraiga bien la mayoría de los pares x,y de una gráfica, si el usuario pregunta por un x/y específico puede omitirse
Si le muestras la imagen directamente al modelo en la etapa de inferencia, puede responder exactamente a lo que el usuario pregunte, así que ese enfoque es más efectivo
El único obstáculo real aquí es la calidad del retrieval, y eso es un problema relativamente menor
O sea, si logras pasar bien el contexto adecuado, el resto lo cubre el LLM
Si no, se dispara la cantidad de problemas que tienes que resolver: OCR, parsing, descripción de imágenes, etc.
Pero también muestra que la oportunidad de los LLM se concentra en reclasificar/reprocesar valor ya existente (como documentos de patentes)
En los 90 y 2000, las empresas de software triunfaron convirtiendo papeleo existente en bases de datos
Crear desde cero datasets nuevos y valiosos sigue requiriendo muchísima inversión y esfuerzo
Según mi experiencia, este enfoque no es muy bueno
Dependiendo de la fuente, distinguir entre o y 0 puede ser difícil
Si conviertes un documento (doc/xls/pdf/html) a imagen, pierdes esa información de distinción
Con números de serie y similares, a veces ni una persona lo puede distinguir bien a simple vista
Por eso, para PDF tiene bastante sentido renderizar la imagen y extraer desde ahí
Para los demás formatos, es mejor parsear el documento directamente
Aun así, en la práctica, al diseñar una página, mostrarle al modelo la imagen real suele ser mucho más efectivo para depurar que pasarle solo el código
Los problemas de 1 vs I y 0 vs O realmente existen, pero con documentos llenos de diagramas/gráficas muchas veces me ha resultado muchísimo más fácil procesarlos solo con imágenes
(Puede que haya sesgo de selección)
Intenté durante varios minutos copiar un horario en Gemini y hacerle preguntas, pero aunque estaba en HTML no funcionaba bien
Al final tomé una captura de pantalla, cubrí con rectángulos negros las partes que no necesitaba y le pasé la imagen; funcionó muy bien
Tengo curiosidad porque siento que esto ya se resuelve con RAG multimodal
He obtenido resultados bastante satisfactorios de análisis de imágenes con Flash 2.5, Sonnet 3.7, etc.
Incluso siento que, frente al texto, obtengo mejores respuestas cuando les doy imágenes
https://www.youtube.com/watch?v=p7yRLIj9IyQ
Solo que los multivectores en estado inicial (la base del RAG multimodal) son muy difíciles de manejar y el cálculo de similitud es muy caro, así que escalar es complicado
Se necesita cuantización, conversión a vector único (encoding de dimensión fija), optimización del indexado, etc.
Eso es precisamente lo que hacemos en Morphik
Yo también intenté escanear todas mis facturas de una sola vez: extraje solo los adjuntos del buzón y corrí un script para subirlos uno por uno y hacer que extrajera “Invoice: sí/no”, además de cada ítem, nombre del proveedor, fecha, número de factura, etc.
Al final la tasa de lectura fue alta y las llamadas al LLM tardaron más de 3 horas, pero como era automatizado no me importó
Después incluso le pedí al LLM que las conciliara con los estados bancarios, y solo faltaron algunas facturas que no habían llegado como adjuntos
Eso sí, la conciliación factura-estado bancario la hizo bastante mal el LLM (si había diferencia de unos pocos dólares, igual respondía que era ese estado)
Así que por ahora parece que todavía hace falta un contador
No tengo idea aproximada del costo, y usé un modelo barato como Claude 3.7
Entiendo por qué ColPali resulta intuitivo y potente, pero aun así los enfoques de procesamiento documental tienen sus ventajas