Perplexity lanza dos modelos late interaction para buscar en páginas de PDF sin OCR

Perplexity ha subido a Hugging Face la colección pplx-embed-v2, que incluye dos modelos pplx-embed-v2-late. Funcionan con el principio de late interaction y buscan en las páginas de los documentos como si fueran imágenes. La página completa, con sus tablas, gráficos y maquetación, se convierte en embeddings, y el paso de reconocimiento de texto (OCR) desaparece del pipeline. El blog de Qdrant del 13 de octubre de 2026 señala de entrada el punto débil del lanzamiento: el recuperador visual de Perplexity tiene un problema de tamaño, y el equipo de Qdrant afirma haberlo resuelto. El fragmento disponible del material no explica los detalles de la solución, por lo que a continuación se separan los hechos confirmados de las suposiciones razonables.

Por qué buscar por página y no por texto

Una cifra en un informe financiero no significa nada sin su fila, su columna y su unidad de medida. Un gráfico sin etiquetas, tampoco. El pipeline clásico extrae el texto del PDF con OCR, lo divide en fragmentos y lo indexa. Con ello la estructura se desmorona: la celda de una tabla queda separada del encabezado de su columna, y la etiqueta de un eje, del propio eje.

Perplexity propone otro camino. El modelo recibe la imagen de la página y la codifica entera. La tabla sigue siendo una tabla y el gráfico sigue siendo un gráfico. La consulta busca coincidencias en la página tal como la ve una persona. En corpus de informes, presentaciones y especificaciones técnicas, esto elimina toda una capa de errores: no hay que ajustar el OCR a distintas tipografías, idiomas y escaneos.

Dónde surge el problema del tamaño

Late interaction funciona de forma distinta a la búsqueda habitual con un solo vector por documento. En esquemas como ColBERT y ColPali, la página se representa con un conjunto de vectores, y la relevancia se calcula comparando cada vector de la consulta con el mejor vector de la página (MaxSim). La precisión es mayor, pero hay que almacenar muchos vectores por página en lugar de uno. Este es un principio general de esta clase de modelos, no un dato del lanzamiento. El texto disponible no indica la dimensionalidad concreta ni el número de vectores por página.

Por eso el titular sobre el «problema de tamaño» se lee como un problema del volumen del índice multivectorial. Es una deducción, no una cita. En un corpus de millones de páginas, la diferencia entre un vector y cientos por página se traduce en diferencias de memoria, de coste de servidores y de latencia de búsqueda. Qdrant lleva tiempo admitiendo almacenamiento multivectorial, así que su interés en el tema resulta comprensible. Cómo redujo exactamente el tamaño el equipo, habrá que consultarlo en la versión completa del post.

Qué se sabe hasta ahora

• Desarrollador: Perplexity, colección pplx-embed-v2 en Hugging Face
• Modelos: dos modelos late interaction pplx-embed-v2-late
• Entrada: imagen de la página del documento
• Qué se codifica: tablas, diagramas, disposición de la página
• OCR: no es necesario
• Fuente del análisis: blog de Qdrant, 13 de octubre de 2026
• No se revela en el fragmento: dimensionalidad de los embeddings, número de vectores por página, resultados en benchmarks, licencia, método de compresión

Qué comprobar antes de implantarlo

No conviene migrar la búsqueda en producción a embeddings visuales sin haber calculado antes varias cosas.

1. Cuántos vectores genera el modelo por página y cuánta memoria ocupará su corpus con esa densidad. Multiplique el número de páginas por el tamaño del multivector y compárelo con su presupuesto. 2. Cómo se comporta la calidad con sus documentos. Tome entre 50–100 consultas reales sobre tablas y gráficos y compare los resultados con la línea base de OCR más embeddings de texto. 3. Si su base de datos vectorial admite multivectores y MaxSim de forma nativa. De lo contrario, tendrá que construir el recálculo por su cuenta. 4. Qué método de compresión se aplica y cómo afecta a la calidad. Cualquier reducción del índice debe verificarse con esas mismas consultas, sin fiarse de las cifras medias.

Si el corpus es pequeño y las tablas y diagramas son lo principal, el recuperador visual se puede probar ya. Si hay millones de páginas, lo decisivo no será la calidad, sino cuánto se haya logrado comprimir el índice.