Perplexity pplx-embed-v2-late divide la búsqueda multimodal entre indexación de 9B y consultas de 0.6B

Perplexity lanzó dos modelos pplx-embed-v2-late con una división destacable: un modelo de 9B construye índices más ricos, mientras que uno de 0.6B gestiona consultas más rápidas. Ambos modelos buscan texto, imágenes y páginas de documentos renderizadas en el mismo espacio de embeddings.

Esta combinación importa más que el número de parámetros. Los equipos de recuperación suelen elegir un único modelo de embeddings y asumir sus compromisos de calidad, latencia y costes de infraestructura en todas partes. Perplexity propone, en cambio, dedicar más cómputo cuando los documentos entran en el índice y utilizar un codificador más pequeño en la ruta de solicitudes.

Los modelos también cuestionan el proceso estándar para buscar en PDF visualmente complejos. En lugar de extraer texto mediante OCR, un desarrollador puede codificar una página renderizada y recuperarla con una consulta de texto. Sin embargo, este enfoque sustituye algunos costes de análisis por índices más grandes y una puntuación más costosa.

Perplexity lanzó dos modelos que funcionan como un único sistema de recuperación

El lanzamiento central no es simplemente un par de checkpoints. Es un diseño de recuperación asimétrico construido en torno a un espacio de embeddings compartido.

Perplexity publicó versiones de 0.6B y 9B de pplx-embed-v2-late bajo licencia MIT. Los pesos están disponibles en repositorios separados de modelos de Hugging Face, incluido el modelo de 0.6B y su contraparte mayor de 9B.

Ambos modelos son recuperadores multimodales de interacción tardía. La interacción tardía significa que los documentos y las consultas se codifican por separado, pero sus vectores de tokens individuales interactúan durante la puntuación. Esto difiere de la recuperación densa, que normalmente reduce cada entrada a un único vector.

Cada modelo produce un vector de 128 dimensiones por token. La puntuación MaxSim encuentra entonces la coincidencia más fuerte de token de documento para cada token de consulta y suma esas similitudes máximas. Por tanto, distintos términos de consulta pueden coincidir con diferentes regiones de una página.

Perplexity construyó la familia sobre backbones Qwen3.5 con atención bidireccional. Según la tarjeta del modelo, ambos modelos publicados fueron destilados de un profesor interno ColBERT de 18B. ColBERT es una arquitectura de recuperación que preserva representaciones a nivel de token para comparaciones tardías.

La empresa realizó un ajuste fino completo del modelo más pequeño. Para la versión de 9B, ajustó por completo las ocho últimas capas del transformador, mientras adaptaba las capas restantes y el codificador visual con LoRA.

Los tamaños anunciados también requieren contexto. El checkpoint más pequeño contiene unos 594 millones de parámetros totales, pero Perplexity informa de 340 millones de parámetros activos. La codificación de texto activa aproximadamente 240 millones de parámetros, mientras que la codificación de imágenes activa unos 340 millones.

Perplexity produjo la torre de texto más pequeña recortando una torre Qwen3.5-0.8B de 24 capas a 12 capas. Su tabla de embeddings de tokens representa otros 254 millones de parámetros, según la empresa.

Esta construcción apunta a la economía en tiempo de consulta. La indexación puede ejecutarse sin conexión, en hardware paralelo y solo cuando cambian los documentos. La codificación de consultas está en la ruta de solicitudes en vivo, donde cada milisegundo adicional afecta a la experiencia del usuario.

El espacio compartido conecta esas dos cargas de trabajo. Una empresa puede codificar documentos con el modelo de 9B y luego buscar en el índice resultante con consultas codificadas por el modelo de 0.6B. Sustituir el codificador de consultas no exige reconstruir ese índice.

Perplexity también describe una configuración local-nube. Un dispositivo podría codificar una consulta privada o un documento local con el modelo más pequeño y luego comparar esa representación con resultados de un índice de 9B alojado en la nube.

Esta flexibilidad sigue siendo una propuesta técnica, no una promesa de producto gestionado. La tarjeta del modelo indica que los checkpoints funcionan con versiones recientes de Sentence Transformers y Transformers. También señala que ningún proveedor de inferencia sirve actualmente el checkpoint más pequeño.

Perplexity afirma que los embeddings de interacción tardía, densos y contextuales llegarán progresivamente a su plataforma API. Hasta entonces, los equipos que evalúen pplx-embed-v2-late deben asumir que tendrán que operar los modelos y la infraestructura de recuperación por sí mismos.

El mecanismo de Perplexity pplx-embed-v2-late preserva el detalle de las páginas

Perplexity apuesta por que la coincidencia a nivel de token puede conservar evidencia que un único vector de documento a menudo comprime.

Un modelo de embeddings densos representa una consulta y un documento con un vector cada uno. La recuperación se convierte en una búsqueda eficiente de vecinos más cercanos, que funciona bien en colecciones muy grandes. Sin embargo, el vector debe resumir cada detalle potencialmente relevante.

Esa compresión se vuelve más difícil a medida que los documentos se alargan o contienen secciones no relacionadas. Se complica aún más cuando las páginas incluyen gráficos, tablas, diagramas, leyendas y significado dependiente del diseño. Una sola representación tiene espacio limitado para todas esas señales.

La segmentación reduce la cantidad de información incluida en cada vector. Sin embargo, puede separar una tabla de su etiqueta, un gráfico de su leyenda o una cláusula de una salvedad importante. Las reglas de análisis también varían entre formatos de documento.

Un cross-encoder aborda parte del problema procesando conjuntamente una consulta y un candidato. Esa atención conjunta permite comparaciones detalladas, pero el modelo debe ejecutarse de nuevo para cada par consulta-candidato. Normalmente solo resulta práctico para reordenar una lista corta de candidatos.

La interacción tardía ocupa el punto intermedio. Los documentos siguen recibiendo sus representaciones antes de que llegue una consulta. El sistema de recuperación realiza después múltiples comparaciones a nivel de token, en lugar de calcular un producto interno por candidato.

La explicación técnica de Perplexity ilustra el método con MaxSim. Cada token de consulta selecciona su mejor coincidencia de token de documento, y el sistema añade esas similitudes a una puntuación del documento.

Consideremos una consulta sobre un estatuto, un plazo y una excepción. Un único vector de consulta combina esos conceptos. MaxSim puede hacer coincidir cada concepto con un pasaje, etiqueta o región visual independiente dentro de la misma página.

El mismo mecanismo se aplica a las imágenes. Una página PDF renderizada entra en el codificador visual como imagen, en lugar de pasar primero por OCR. Una consulta de texto puede recuperar directamente la representación visual.

Esto no significa que el modelo “lea” un archivo PDF sin preparación. La aplicación debe renderizar cada página relevante como imagen y codificarla. La distinción se refiere a cómo se produce la representación consultable.

Omitir el OCR puede preservar el diseño y las relaciones visuales que pierde la extracción de texto. Las posiciones de filas y columnas de una tabla financiera pueden transmitir un significado esencial. Un diagrama puede comunicar relaciones que su leyenda solo describe parcialmente.

La recuperación sin OCR también puede evitar errores de reconocimiento en escaneos, fuentes inusuales y estructuras de página complejas. Sin embargo, no proporciona automáticamente texto extraído para resaltado, citas, controles de acceso o contexto posterior para modelos de lenguaje.

Por ello, muchas aplicaciones mantendrán el análisis junto con la recuperación visual. Los embeddings visuales pueden identificar una página prometedora, mientras que el OCR o el texto nativo del PDF proporcionan después pasajes exactos. Las técnicas pueden complementarse.

Perplexity entrenó los dos modelos con 186 millones de pares consulta-documento procedentes de 594 conjuntos de datos y 46 idiomas. Informa de que el 88.3% eran pares de texto a texto, el 8.3% de texto a imagen y el 3.4% de texto a documento visual.

La mezcla de muestreo aumentó la presencia relativa de datos visuales. Perplexity afirma que sus ponderaciones finales de muestreo produjeron un 56.5% de ejemplos de texto a texto, un 30.9% de texto a imagen y un 12.6% de texto a documento visual.

Estos detalles importan porque “multimodal” abarca varios problemas distintos. Recuperar una fotografía no es idéntico a encontrar evidencia dentro de una densa página de informe anual. El equilibrio del entrenamiento influye en qué casos de uso reciben la representación más sólida.

La tarjeta del modelo publicada también especifica una restricción de implementación. Los elementos de solo texto y de solo imagen requieren llamadas de codificación separadas, y no se admiten entradas mixtas de texto más imagen en un solo elemento. Las aplicaciones deben diseñar la ingesta en consecuencia.

Los embeddings compartidos presionan a los procesos de recuperación de un solo modelo

La presión competitiva recae sobre los sistemas de recuperación que usan un único tamaño de codificador tanto para la indexación sin conexión como para las consultas sensibles a la latencia.

La mayoría de los despliegues de embeddings tratan el modelo como un componente uniforme. El mismo checkpoint genera embeddings de un corpus y de cada consulta entrante. Esa simetría simplifica las operaciones, pero ignora la economía distinta de ambos trabajos.

La codificación de documentos suele ser un gasto amortizado. Una empresa puede procesar una página una vez y luego responder miles de búsquedas contra su representación almacenada. Puede programar la indexación en hardware más grande o procesar el trabajo por lotes.

La codificación de consultas se repite en cada búsqueda. Afecta al tiempo de respuesta, la concurrencia y la viabilidad en dispositivos. Ejecutar un gran codificador de visión-lenguaje para cada solicitud puede eliminar las ganancias obtenidas durante la indexación sin conexión.

El espacio compartido de Perplexity separa estas decisiones. El modelo de 9B puede dedicar cómputo adicional a capturar información del documento, mientras que el modelo de 0.6B produce consultas compatibles. El índice conserva parte del beneficio del codificador de documentos más grande.

En la evaluación de Perplexity sobre 72 tareas de recuperación específicas de dominio, la configuración asimétrica obtuvo una mejora media de 1.6 puntos porcentuales frente al uso de 0.6B en ambos lados. El codificador de consultas permaneció sin cambios.

Para la recuperación de imágenes ViDoRe v3, la configuración con consulta de 0.6B y documento de 9B obtuvo un 63.5% de nDCG@10. La configuración simétrica de 0.6B obtuvo un 62.3%, una diferencia de 1.2 puntos.

El uso del modelo de 9B tanto para consultas como para documentos siguió produciendo la media de dominio más alta comunicada, con un 81.3%. Perplexity afirma que la configuración asimétrica recuperó aproximadamente la mitad de la brecha de calidad de texto sin una codificación más grande en tiempo de consulta.

Ese es el argumento más práctico del lanzamiento. El modelo más pequeño no necesita igualar por sí solo cada resultado de 9B. Solo necesita hacer útil un índice de 9B de alta calidad bajo restricciones de servicio más estrictas.

El enfoque presiona a los modelos densos estándar, pero también compite con otros recuperadores multivector. Perplexity compara sus modelos con Qwen3-VL-Embedding, EVIE, TopK Embed y la familia Nemotron ColEmbed de Nvidia.

En la parte pública de imágenes de ViDoRe v3, Perplexity informa de un 65.2% de nDCG@10 para el modelo de 9B y un 62.3% para el de 0.6B. Las puntuaciones correspondientes en markdown fueron 64.7% y 61.2%.

Perplexity afirma que el modelo de 0.6B quedó a 1.2 puntos de Nemotron ColEmbed V2 8B en recuperación de imágenes. También subraya que sus salidas utilizan 128 dimensiones por token.

Esta comparación de dimensiones se refiere directamente a la viabilidad del índice. Perplexity enumera dimensiones de salida de 2,048 para EVIE-4.5B y de 4,096 para los modelos EVIE y Nemotron más grandes. Menos dimensiones pueden reducir el tamaño de cada vector de token almacenado.

Las dimensiones por sí solas no determinan el coste de producción. También importan el número de tokens retenidos, la precisión numérica, el método de compresión, la estructura del índice y la estrategia de generación de candidatos. Perplexity no ha publicado un cálculo completo de almacenamiento para corpus representativos.

La alternativa no está desapareciendo. La recuperación densa sigue siendo más fácil de indexar y buscar a una escala enorme. Los cross-encoders siguen siendo atractivos para la reordenación. La búsqueda léxica híbrida sigue protegiendo identificadores exactos, nombres y términos técnicos poco frecuentes.

Por lo tanto, es más probable que Pplx-embed-v2-late se convierta en una etapa dentro de una pila de recuperación que en un reemplazo universal. Perplexity describe la interacción tardía como una recuperación inicial más rica o como una etapa posterior en sistemas a escala web.

Para los equipos que crean una base de conocimientos consultable, la cuestión de diseño se vuelve más específica. Deben decidir qué documentos justifican una indexación visual de múltiples vectores y cuáles siguen siendo eficientes con la recuperación de texto.

Los resultados de los benchmarks son sólidos, pero siguen siendo reportados por la empresa

Las puntuaciones publicadas justifican pruebas serias, pero no resuelven la latencia, el almacenamiento ni la calidad de recuperación en el mundo real.

Perplexity informa una puntuación de precisión de respuesta del 64,0 % para el modelo de 9B en BrowseComp+. Ese resultado superó al siguiente modelo ColBERT por 4,9 puntos porcentuales y al siguiente modelo denso por 8,7 puntos.

BrowseComp+ utiliza un corpus fijo en lugar de búsqueda web en vivo. Su diseño de benchmark incluye 830 consultas difíciles y aproximadamente 100.000 documentos web seleccionados con evidencia de respaldo verificada por humanos.

Una colección fija mejora la reproducibilidad. Los investigadores pueden separar la calidad de recuperación de los cambios en los motores de búsqueda comerciales o en la web abierta. También hace que el benchmark sea más acotado que operar un índice web en vivo y en constante cambio.

Perplexity combinó su recuperador con GPT-OSS-120B en un nivel de esfuerzo alto. Otro modelo de lenguaje evaluó si la respuesta generada coincidía con la referencia. Por lo tanto, el 64,0 % informado mide un sistema de agente y recuperador, no una puntuación de embeddings aislada.

La empresa afirma que el modelo de 0,6B también superó a todos los modelos fuera de la familia pplx-embed-v2-late. Sin embargo, el anuncio no proporciona todas las puntuaciones subyacentes como texto consultable. El informe técnico completo está previsto para una publicación posterior.

En MADQA, Perplexity informa una precisión de respuesta del 92,4 % para su recuperador de 9B y del 90,1 % para el modelo de 0,6B. Ambos se combinaron con Gemini 3.5 Flash.

MADQA evalúa la búsqueda agéntica en PDF heterogéneos. El artículo de MADQA describe 2.250 preguntas redactadas por humanos y fundamentadas en 800 documentos, mientras que la evaluación informada utiliza un subconjunto de 500 preguntas.

Perplexity afirma que ese subconjunto abarca más de 18.000 páginas. Las preguntas no pueden responderse con conocimiento general, por lo que el agente debe recuperar evidencia de la colección de documentos.

El resultado de 9B superó por 3,5 puntos a un recuperador estándar de Mixedbread con el mismo agente. Mixedbread Agentic Search alcanzó el 93,4 %, una cifra que Perplexity dice que se situó dentro de su intervalo de confianza.

Esta distinción es importante. Mixedbread Agentic Search incluye un subagente de búsqueda que puede planificar y ejecutar varias búsquedas por cada llamada externa. Pplx-embed-v2-late funciona como un recuperador dentro del agente, en lugar de ser un servicio completo de búsqueda agéntica.

Los autores de MADQA también identifican una limitación más amplia en los agentes de documentos. Su estudio concluyó que los sistemas sólidos pueden acercarse a la precisión humana mientras aciertan preguntas diferentes. Los agentes suelen compensar una estrategia débil mediante búsquedas repetidas.

Un mejor recuperador puede reducir ese desperdicio, pero no puede garantizar una buena planificación de búsqueda ni una buena síntesis de evidencia. La precisión de recuperación, la precisión de respuesta, la calidad de la evidencia a nivel de página, la latencia y el número de llamadas a herramientas deben evaluarse por separado.

Perplexity también informa sólidos resultados en ViDoRe v3. Ese benchmark público ofrece a los desarrolladores una visión más directa de la recuperación de páginas que las pruebas de generación de respuestas. Aun así, las colecciones de benchmark no pueden reproducir todos los formatos de documentos empresariales.

Los corpus reales contienen duplicados, restricciones de acceso, revisiones, anotaciones manuscritas, escaneos de baja resolución y páginas con diseños casi idénticos. También contienen abreviaturas específicas de cada dominio que pueden estar ausentes de las mezclas generales de entrenamiento.

El benchmark interno PPLX-Q2I introduce otra brecha de verificación. Perplexity lo construyó a partir de registros de búsqueda de imágenes de producción y evaluó 10.000 consultas frente a 100.000 imágenes. Los investigadores externos aún no pueden reproducir esa prueba privada.

Perplexity afirma que ambos modelos superaron a Qwen3-VL-Embedding-8B por más de nueve puntos en PPLX-Q2I. También afirma que el modelo de 9B quedó aproximadamente dos puntos por detrás de Gemini Embedding 2. Estos hallazgos deben seguir atribuyéndose a la empresa.

El lanzamiento merece atención porque los pesos y los puntos de control de benchmarks públicos permiten pruebas independientes. No merece una aceptación automática como la mejor opción para todos los corpus.

Los desarrolladores deberían construir un conjunto de evaluación a partir de sus propios documentos y consultas reales. Debe incluir búsquedas exactas, evidencia entre páginas, tablas visuales, terminología poco común y negativos deliberadamente difíciles.

También deberían comparar sistemas integrales equivalentes. Una configuración no debería recibir mejor OCR, más rondas de búsqueda o un reranker más potente, salvo que esas diferencias representen el diseño de producción previsto.

La búsqueda multivector desplaza los costes en lugar de eliminarlos

Pplx-embed-v2-late evita un cuello de botella de compresión al aceptar representaciones más grandes y una puntuación de candidatos más compleja.

La recuperación densa almacena un vector para cada documento o fragmento. La interacción tardía conserva múltiples vectores, a menudo uno por cada token no podado. Por lo tanto, una página larga puede generar muchas representaciones consultables.

Incluso con 128 dimensiones, esos vectores se acumulan. El almacenamiento del índice depende del número de tokens, el formato numérico, el esquema de compresión, los metadatos y el motor de recuperación. Las representaciones visuales a nivel de página pueden modificar aún más el cálculo.

MaxSim también exige más trabajo que un único producto interno entre consulta y documento. Cada token de la consulta debe localizar su coincidencia más fuerte entre los tokens del documento. Un servicio eficiente necesita indexación especializada, poda o recuperación por etapas.

Perplexity reconoce esta contrapartida en su anuncio. Afirma que la interacción tardía requiere decisiones de indexación y servicio distintas de la recuperación aproximada de vecinos más cercanos de un solo vector. Los documentos más largos aumentan el coste.

El espacio compartido del modelo ayuda con la codificación de consultas, pero no elimina los costes de puntuación de candidatos. Un codificador de consultas ligero aún puede producir una solicitud costosa de comparar con millones de vectores de tokens.

Por lo tanto, los equipos deberían medir cuatro componentes de latencia por separado: codificación de consultas, generación de candidatos, puntuación MaxSim y reranking o generación posteriores. Informar solo el tiempo de inferencia del modelo oculta gran parte de la experiencia del usuario.

El uso de memoria también requiere una medición cuidadosa. El checkpoint de 9B puede ser un componente sin conexión, pero indexar un corpus que cambia con frecuencia puede seguir exigiendo capacidad persistente de GPU. Recodificar revisiones de documentos añade trabajo operativo.

Una canalización de documentos visuales requiere renderizar las páginas antes de la inferencia del modelo. Los PDF grandes necesitan paginación, normalización de imágenes, manejo de fallos, asignación de metadatos y flujos de trabajo de eliminación. El OCR puede desaparecer de la recuperación, pero la ingesta sigue siendo un problema de sistemas.

El OCR también conserva ventajas. El texto extraído admite búsqueda por palabras clave, resaltado, citas, revisión de cumplimiento y contexto directo para modelos de lenguaje. Un embedding de página renderizada no puede reproducir esas funciones por sí solo.

El diseño de producción probable es híbrido. Un sistema puede indexar texto nativo para la recuperación exacta, mantener embeddings visuales para páginas sensibles al diseño y utilizar un reranker sobre un conjunto acotado de candidatos.

El control de acceso merece la misma atención. Los índices de recuperación deben filtrar el material no autorizado antes de que los resultados lleguen a un agente. Un espacio compartido de embeddings local-nube no proporciona automáticamente permisos de documentos ni garantías de privacidad.

La ruta de consultas propuesta en el dispositivo plantea más preguntas. Perplexity considera que el modelo de 0,6B es adecuado para dispositivos edge, pero las clases de dispositivos varían ampliamente. Los límites de memoria, el soporte de aceleración, la cuantización y el uso de batería determinarán la viabilidad real.

El checkpoint publicado utiliza tensores F32 en su página de Hugging Face. Es probable que los desarrolladores prueben variantes de menor precisión o específicas de plataforma, pero esas conversiones requieren controles de calidad. La cuantización puede alterar las clasificaciones de recuperación.

La compatibilidad es otra preocupación temprana. La tarjeta del modelo requiere Sentence Transformers 6.0 o posterior y Transformers 5.4 o posterior. También advierte que PyLate inserta marcadores de consulta y documento en una posición diferente.

La exportación utiliza módulos nativos de Sentence Transformers y no requiere código Python personalizado. Esto reduce la fricción de integración, pero no proporciona un índice de producción completo ni un endpoint gestionado.

Las licencias son comparativamente sencillas. La licencia MIT permite un uso y modificación amplios. Aun así, los adoptantes deben revisar las dependencias del modelo, las consideraciones sobre los datos de entrenamiento y su propio manejo de documentos sensibles.

El término «código abierto» también puede ocultar distinciones importantes. Perplexity publicó pesos abiertos e instrucciones de implementación, pero no ha publicado el corpus completo de entrenamiento ni el profesor interno de 18B.

La empresa afirma que excluyó del entrenamiento los conjuntos de datos relacionados con los benchmarks evaluados. Es una afirmación metodológica útil, pero los investigadores independientes necesitan el informe técnico prometido para examinar los controles de contaminación y los detalles de evaluación.

La conclusión prudente no es que la interacción tardía cueste demasiado. Es que el gasto se desplaza. Los equipos intercambian la dependencia del OCR y la compresión de un solo vector por índices más ricos, puntuación a nivel de token e infraestructura más especializada.

Tres señales mostrarán si el diseño se traslada más allá de los benchmarks

La próxima prueba es si los despliegues independientes pueden reproducir las mejoras de calidad sin una complejidad inaceptable de almacenamiento, latencia u operaciones.

La primera señal es la evaluación independiente de los pesos publicados. Los investigadores y proveedores de recuperación ahora pueden comparar ambos modelos en tareas públicas de documentos visuales y corpus privados de la industria.

La reproducción debería cubrir la configuración asimétrica, no solo las pruebas simétricas de 0,6B y 9B. La afirmación central depende de que las consultas de modelos pequeños conserven valor frente a un índice de modelos grandes.

Si los resultados independientes preservan las mejoras reportadas en documentos legales, financieros, técnicos y escaneados, el diseño de Perplexity se convierte en un patrón de despliegue creíble. Grandes caídas de calidad debilitarían el argumento del espacio compartido.

La segunda señal es un informe técnico completo con mediciones del índice. Perplexity afirma que ese informe llegará más adelante este año. Debería revelar configuraciones de recuperación, compresión, hardware, latencia y almacenamiento por token de documento.

El informe también debería explicar los intervalos de confianza, el filtrado de datos de entrenamiento y la configuración del benchmark. Esos detalles mostrarán si las mejoras de precisión reportadas sobreviven con límites de recursos comparables.

El almacenamiento es especialmente importante porque la dimensión de salida es solo una variable. Un vector de token de 128 dimensiones parece compacto junto a una alternativa de 4.096 dimensiones, pero el tamaño total del índice depende de la cantidad de tokens retenidos.

La tercera señal es el soporte de producto. Perplexity afirma que añadirá progresivamente embeddings de interacción tardía, densos y contextuales a su plataforma de API. Un endpoint gestionado revelaría cómo la empresa empaqueta las contrapartidas de indexación y servicio.

El soporte de API también ampliaría las pruebas más allá de los equipos capaces de operar infraestructura de GPU personalizada. La adopción seguirá siendo más limitada si los usuarios deben montar por sí mismos el renderizado, la indexación, la búsqueda MaxSim y el escalado.

El despliegue debería aclarar si los clientes pueden combinar índices de documentos de 9B con consultas de 0,6B mediante un servicio gestionado. Esa configuración es la idea operativa más sólida del lanzamiento.

Los precios aún no constituyen una comparación útil, y no deben inferirse cifras a partir de los servicios de embeddings anteriores de Perplexity. El almacenamiento y la puntuación multivector difieren sustancialmente de los embeddings de texto de un solo vector.

Las respuestas de la competencia también importan, pero son pruebas de apoyo más que la prueba principal. Qwen, Nvidia, Google, Mixedbread y otros proveedores de recuperación pueden mejorar la calidad, reducir las dimensiones u ofrecer sistemas gestionados más sencillos.

La ventaja de Perplexity no dependerá de una sola instantánea de una clasificación. Dependerá de si el espacio compartido reduce los costes de las consultas en producción y conserva suficiente de la calidad de recuperación del indexador más grande.

Para los desarrolladores, la acción inmediata es una evaluación acotada. Construyan un corpus representativo, rendericen las páginas visualmente complejas y conserven una referencia basada en texto. Después, comparen configuraciones simétricas y asimétricas con el mismo presupuesto de recuperación.

Midan la precisión de las respuestas, la recuperación de páginas con evidencia, el tamaño del índice, el rendimiento de ingesta, la latencia de consulta y los casos de fallo. Incluyan OCR y canalizaciones híbridas, ya que la recuperación visual no elimina todos los motivos para analizar texto.

Perplexity pplx-embed-v2-late plantea una hipótesis clara: la codificación de documentos y la codificación de consultas no deberían compartir el mismo presupuesto de cómputo. Los pesos abiertos hacen que esta hipótesis sea comprobable.

La pregunta restante es operativa, no conceptual. ¿Puede un índice de 9B y una ruta de consulta de 0,6B superar una recuperación más sencilla una vez que se contabilizan el almacenamiento, la puntuación, las actualizaciones, los permisos y la extracción de evidencia posterior?