Embeddings multimodali oltre un singolo vettore

Da quando abbiamo rilasciato pplx-embed-v1 a febbraio, abbiamo lavorato a una nuova generazione di modelli di embedding. La scorsa settimana abbiamo presentato il nostro nuovo modello di embedding contestuale, pplx-embed-v2-context. Oggi ampliamo la famiglia con pplx-embed-v2-late, una raccolta di modelli a interazione tardiva. Insieme a capacità di retrieval più forti, questi modelli sono i primi a combinare tre funzionalità fondamentali:

• Rappresentazioni multi-vettore. Anziché comprimere ogni input in un singolo vettore, questi modelli conservano vettori a livello di token per confronti query-documento più granulari. Ciò consente a parti diverse di una query di corrispondere a parti diverse di un documento, preservando dettagli particolarmente preziosi per il retrieval multimodale.
• Supporto per le modalità testo e immagine. Oltre alle capacità di retrieval text-to-text dei nostri modelli precedenti, questi nuovi modelli gestiscono il retrieval text-to-image, consentendo loro di cercare direttamente pagine PDF renderizzate senza richiedere OCR o testo analizzato.
• Uno spazio di embedding condiviso. Stiamo rilasciando due dimensioni di modello, 0,6B e 9B, per supportare diversi requisiti di qualità, latenza e calcolo. Ciascuno può essere usato indipendentemente, ma lo spazio di embedding condiviso consente anche al modello più piccolo di interrogare un indice creato con il modello più grande, combinando embedding dei documenti di qualità superiore con un’inferenza delle query economica e veloce.

Questi nuovi modelli raggiungono risultati allo stato dell'arte in una serie di benchmark di recupero visivo e testuale, oltre che in attività agentiche di domanda e risposta. In particolare, su ViDoRe (V3), uno dei principali benchmark per il recupero di documenti visivi, il nostro modello da 0,6B eguaglia modelli con un numero di parametri attivi cinque volte superiore. Entrambi i modelli sono disponibili pubblicamente su Hugging Face. Il nostro report tecnico fornisce maggiori dettagli sulla metodologia e sui risultati della valutazione.

Da singoli vettori a interazione tardiva

I sistemi di retrieval devono trovare un equilibrio tra efficienza e profondità dell’interazione tra query e documenti. I modelli di embedding dense codificano ogni query e ogni documento in modo indipendente, consentendo di confrontarli con un prodotto interno economico. Questo rende praticabile la ricerca approssimata dei vicini più prossimi (ANN) su miliardi di documenti. All’estremo opposto, i cross-encoder elaborano insieme la query e il documento, consentendo un’interazione più ricca ma richiedendo un passaggio forward separato per ogni candidato. Applicare questo calcolo a un grande corpus di documenti per ogni ricerca è proibitivamente costoso, quindi i cross-encoder sono in genere riservati al reranking di un piccolo insieme di candidati recuperati.

Limiti degli embedding dense

Rappresentare un intero documento con un solo vettore di dimensione fissa crea un collo di bottiglia informativo. Man mano che i documenti diventano più lunghi e coprono più argomenti, il modello deve comprimere più contenuto nello stesso vettore, rendendo più difficile preservare tutto ciò che è rilevante per una query. Il chunking può ridurre questa pressione, ma frammenta il documento e può separare informazioni che hanno senso solo insieme, un problema che affrontiamo anche con il nostro modello di embedding contestuale. Questo collo di bottiglia peggiora in contesti multimodali, in cui la densità informativa delle immagini richiede una compressione ancora maggiore.

Il retrieval dense a singolo vettore riduce inoltre ogni confronto a un prodotto interno tra due vettori, limitando l’espressività della funzione di scoring. A una dimensione di embedding fissa e con un corpus abbastanza grande, alcuni schemi di punteggi tra coppie query-documento sono impossibili da produrre, indipendentemente dall’addestramento. Il benchmark LIMIT trasforma questa preoccupazione teorica in un test di stress concreto per il retrieval a singolo vettore.

Retrieval a interazione tardiva

I modelli a interazione tardiva occupano lo spazio tra i più economici modelli di embedding dense e i più espressivi cross-encoder. Come i modelli dense, codificano i documenti in modo indipendente dalla query, consentendo di calcolare le rappresentazioni dei documenti offline. Tuttavia, anziché ridurre ogni input a un singolo vettore, conservano più vettori e utilizzano una funzione di scoring più ricca nel confronto tra una query e un documento.

I nostri modelli pplx-embed-v2-late usano un’architettura in stile ColBERT, producendo embedding da 128 dimensioni per ciascun token dell’input. Valutiamo le coppie query-documento usando MaxSim; per ogni token della query, il modello seleziona il token del documento con il punteggio più alto e somma le massime similarità per token per produrre il punteggio finale. Ciò consente a parti diverse di una query di corrispondere a parti diverse di un documento, con corrispondenze tra token più forti che contribuiscono maggiormente al punteggio.

Espandi

Questa maggiore espressività comporta costi più elevati di storage e di scoring dei candidati. Il retrieval dense memorizza un vettore per documento e assegna un punteggio a un candidato con un solo prodotto interno; l’interazione tardiva memorizza vettori per i token del documento e valuta molte similarità token-token. Il costo cresce con la lunghezza del documento, quindi l’interazione tardiva richiede un compromesso diverso tra indicizzazione e serving rispetto al retrieval ANN a singolo vettore. In cambio, offre un retrieval di primo stadio più ricco per corpora in cui la qualità è critica e può anche servire come fase successiva in una pipeline di retrieval web su larga scala.

Un modello, più modalità

Questa maggiore profondità di interazione ha dimostrato di essere molto utile per vari task, tra cui retrieval a lungo contesto, agentic e out-of-domain. Questa differenza è particolarmente evidente nel retrieval multimodale, come mostra il grande vantaggio dei modelli ColPali nella leaderboard di ViDoRe(V3).

I corpora del mondo reale non sono composti solo da testo pulito. Arrivano come PDF, slide deck, screenshot, pagine scansionate, grafici e tabelle. La pipeline convenzionale analizza questi documenti, applica OCR o captioning e cerca nel testo risultante, il che è costoso e con perdita di informazioni: può introdurre errori OCR e scartare layout, struttura delle tabelle, figure e relazioni spaziali. La ricerca visiva nei documenti salta questo passaggio, proiettando direttamente la pagina renderizzata nello spazio di rappresentazione in cui le query testuali possono cercarla.

La nostra nuova famiglia di modelli si basa sulle solide prestazioni dei modelli multi-vettore per la ricerca multimodale e spinge in avanti la frontiera di Pareto per i modelli piccoli sul benchmark di document search più usato, ViDoRe(V3). Sebbene ci aspettiamo che le immagini renderizzate dei documenti siano la forma più comune di input visivo, i nostri modelli supportano anche la semantic image search su immagini naturali, come fotografie di paesaggi.

Addestrare una famiglia di modelli interoperabili

La ricerca è fondamentalmente asimmetrica: l’indicizzazione e la codifica delle query hanno vincoli operativi diversi. L’indicizzazione viene eseguita offline e può essere parallelizzata, quindi il suo costo computazionale si ammortizza su molte ricerche future. La codifica delle query viene eseguita online per ogni richiesta, rendendola sensibile alla latenza e talvolta soggetta a limiti di serving o dei dispositivi edge. La nostra famiglia di modelli sfrutta questa asimmetria, offrendo dimensioni adatte a ciascun lato della pipeline di retrieval.

Addestriamo un teacher da 18B in modo contrastivo, poi lo distilliamo separatamente in student da 9B e 0,6B. Anziché addestrare ogni student solo a riprodurre la distribuzione di ranking del teacher, usiamo una distillazione della rappresentazione in stile LEAF: per ogni token di input, allineiamo l’embedding di output dello student con quello del teacher. Sebbene la distillazione nello spazio di rappresentazione sia stata usata in precedenza per modelli dense a singolo vettore, la estendiamo all’interazione tardiva, in cui il target di allineamento è un vettore per ogni token conservato.

Di conseguenza, entrambi i checkpoint rilasciati condividono lo stesso spazio di embedding multi-vettore. Ciò abilita il retrieval cross-model, rendendo possibili ulteriori opzioni di deployment.

• Qualità massima: codifica documenti e query con il modello da 9B.
• Efficienza massima: codifica documenti e query con il modello da 0,6B per un’inferenza locale al 100%
• Retrieval a bassa latenza: crea l’indice del corpus con il modello da 9B, quindi codifica le query live con il modello da 0,6B per sfruttare il calcolo in fase di indicizzazione mantenendo veloce il querying.
• Retrieval locale-cloud: codifica documenti locali privati o query live con il modello da 0,6B sul dispositivo e confronta o unisci tali rappresentazioni con i risultati di un indice da 9B ospitato nel cloud.

Per gli ambienti sensibili alla latenza, abbiamo progettato il modello da 0,6B come un leggero codificatore di query che può anche essere eseguito su dispositivi edge. Partendo da Qwen3.5-0.8B, abbiamo potato la sua torre testuale a 24 livelli portandola a 12 livelli, riducendo quella torre da 498 milioni a 240 milioni di parametri non di embedding. Il modello risultante ha in totale 594 milioni di parametri, ma la sua dimensione nominale sovrastima il costo di serving: 100 milioni sono usati per la codifica delle immagini e 254 milioni risiedono nella tabella di embedding dei token, che ha poco effetto sul runtime. Solo circa 240 milioni di parametri sono attivi per la codifica del testo e 340 milioni per la codifica delle immagini, offrendo al modello il costo di serving di un modello sostanzialmente più piccolo pur mantenendo la compatibilità con l’indice da 9B.

Abbiamo applicato lo stesso processo per costruire il nostro teacher da 18B a partire da un backbone da 27B, il che ha reso il teacher considerevolmente meno costoso da distillare senza indebolire il segnale che fornisce.

Dati di addestramento multilingue, multimodali e non contaminati

Addestriamo entrambi i modelli su un dataset di 186 milioni di coppie query-documento tratte da 594 dataset in 46 lingue. Di queste coppie, l’88,3% è text-to-text, l’8,3% è text-to-image e il 3,4% è costituito da coppie text-to-visual-document. Anziché campionare in proporzione alla dimensione del dataset, assegniamo a ciascun dataset un peso di campionamento, ottenendo un mix di addestramento più bilanciato rispettivamente del 56,5%, del 30,9% e del 12,6%.

Quando costruiamo i nostri dati di addestramento, escludiamo qualsiasi dataset associato ai benchmark su cui valutiamo, per rappresentare fedelmente i nostri risultati senza gonfiare i punteggi dei benchmark. Questa decisione comporta il compromesso che alcuni dei dataset che abbiamo scelto di escludere contengono dati di alta qualità che potrebbero migliorare le prestazioni del nostro modello in task diversi dal benchmark da cui provengono. Alla fine abbiamo scelto di accettare questo costo: numeri affidabili sono più utili per noi durante lo sviluppo e per gli utenti quando confrontano i modelli.

Valutazione

Valutiamo entrambi i modelli su retrieval testuale, di documenti visivi, misto con immagini e agentico. Entrambi i modelli superano le baseline valutate su Q2D-Web e BrowseComp+, e ottengono risultati solidi nel retrieval di documenti visivi e in MADQA.

Retrieval testuale

Valutiamo il retrieval text-to-text su tre benchmark:

• Benchmark specifici per dominio: una raccolta di 72 task in stile MTEB, 55 in cinque domini (finanza, legale, salute, conversazione, tecnologia), più 17 task multilingue miscellanei. La raccolta include task come FinQA, AILACasedocs e XLSum. Nessuno di questi dataset compare nei nostri dati di addestramento, come descritto sopra.
• Q2D-Web: il nostro benchmark di retrieval su scala web di circa 70.000 query di ricerca riformulate da un agente, ricavate dal traffico di ricerca in produzione, su un corpus di 190 milioni di documenti web. Questo benchmark misura le prestazioni di retrieval in un contesto molto più vicino al retrieval web del mondo reale rispetto ad altri benchmark disponibili, grazie alle query simili alla produzione e al corpus su larga scala.
• ViDoRe(V3) Markdown: ViDoRe(V3) è tipicamente un task di retrieval text-to-visual-document, ma può anche essere valutato come task testuale usando una versione del corpus che è stata analizzata in Markdown, consentendoci di valutare il retrieval di documenti ricchi di informazioni sia nella modalità immagine sia in quella testuale.

Misuriamo le prestazioni usando nDCG@10, tranne che su Q2D-Web, dove riportiamo Recall@1000 a causa del focus del benchmark su uno scenario di web retrieval di primo stadio. Nel corso delle nostre valutazioni, confrontiamo i risultati con modelli di embedding leader del settore appartenenti a diverse classi dimensionali. Per il retrieval testuale, nemotron-embed-8b, gemini-embedding-2, voyage-large-4 e qwen3-embed-8b rappresentano i concorrenti dense più forti e più usati, mentre voyage-4-nano e qwen3-embed-0.6b fungono da baseline dense con meno di un miliardo di parametri. Confrontiamo inoltre i risultati con i modelli a interazione tardiva topk-embed-v1 rilasciati di recente da TopK, sui benchmark per i quali TopK ha pubblicato i risultati. I punteggi ViDoRe(V3) sono presi dalle loro model card a 128 dimensioni, in linea con la larghezza dei nostri embedding dei token; il punteggio Q2D-Web è preso dalla nostra leaderboard.

Nei benchmark specifici per dominio, i nostri modelli da 9B e 0,6B ottengono in media rispettivamente l’81,3% e il 78,0%. Il nostro modello da 9B raggiunge il punteggio più alto tra tutti i modelli che abbiamo valutato, superando il secondo migliore di 1,6 pp. Il nostro modello da 0,6B è competitivo con gli altri modelli con punteggio più alto, risultando inferiore di soli 0,3 pp a gemini-embedding-2. È importante sottolineare che, poiché non abbiamo addestrato su alcuno dei dati di questi task di benchmark, i benchmark specifici per dominio dimostrano che i nostri modelli di embedding possono generalizzare a nuovi domini.

Espandi

La forza relativa del nostro modello da 0,6B è ancora maggiore nel task ViDoRe(V3) Markdown; il suo punteggio del 61,2% supera tutti gli altri modelli tranne il nostro modello da 9B, che ha ottenuto il 64,7%. Il successivo miglior modello esterno ha ottenuto il 60,6% e il successivo miglior modello sotto 1B, topk-embed-v1-0.8b, è rimasto indietro di 4,3 pp rispetto al nostro modello da 0,6B.

Espandi

Su Q2D-Web, la rilevanza deriva da tre insiemi di giudizi: i documenti citati dall'agente (Citation), i documenti classificati dal nostro sistema di retrieval in produzione (Web) e l’unione di entrambi, estesa con giudizi LLM sui documenti senza etichetta (Combined). Entrambi i modelli pplx-embed-v2-late sono in testa rispetto a ogni baseline in tutti e tre gli insiemi di giudizi. Ci concentriamo sui giudizi combinati, poiché gli insiemi Citation e Web derivano da ciò che i nostri sistemi hanno già evidenziato e quindi favoriscono i modelli che ordinano come loro; i giudizi LLM aggiunti in Combined coprono documenti che nessuno dei due sistemi ha recuperato. Su quell’insieme, sia il nostro modello da 9B sia quello da 0,6B superano tutti i concorrenti, raggiungendo punteggi rispettivamente del 74,8% e del 73,6%, contro il precedente miglior punteggio del 69,3%.

Espandi

Retrieval visivo

Il nostro benchmark visivo principale è il sottoinsieme pubblico standard di ViDoRe(V3), in cui il corpus è costituito da immagini di pagina renderizzate anziché dalla conversione Markdown. Confrontiamo i risultati con due modelli dense vision-language all’avanguardia, qwen3-vl-embed-8b e gemini-embedding-2, e con i modelli a interazione tardiva topk-embed-v1. Inoltre, i modelli EVIE di Tencent e i modelli Nemotron ColEmbed V2 di NVIDIA sono baseline multimodali multi-vettore “vision-only” addestrate appositamente per attività di image retrieval.

Entrambi i nostri modelli raggiungono prestazioni all’avanguardia per i modelli vision-language. Il nostro modello da 9B ottiene un punteggio medio del 65,2%, dietro solo a EVIE. Il nostro modello da 0,6B raggiunge un punteggio del 62,3%, davanti a topk-embed-v1-2b e dietro solo ai molto più grandi EVIE e nemotron-colembed-v2-8b tra le baseline esterne.

Espandi

Il nostro modello da 0,6B è particolarmente competitivo in termini di dimensioni del modello. È davanti a tutti i modelli di dimensioni comparabili ed entro 1,2 pp da nemotron-colembed-v2-8b, attivando però solo 340 milioni di parametri per gli input immagine. I nostri modelli producono embedding da 128 dimensioni per token, rispetto ai 2.048 di EVIE-4.5B e ai 4.096 di EVIE-8B e nemotron-colembed-v2-8b. Questa differenza nei costi di storage può influire drasticamente sugli scenari in cui questi modelli sono pratici da usare.

Espandi

Valutiamo inoltre il retrieval visivo su MIRACL-Vision, un benchmark il cui corpus è composto da screenshot di articoli di Wikipedia, e PPLX-Q2I, un benchmark interno che copre sia documenti visivi sia immagini naturali. PPLX-Q2I è costruito a partire dai log di image search in produzione di Perplexity ed è progettato per riflettere la varietà dei casi d’uso della ricerca di immagini. Usiamo un campione di 10.000 query, stratificato per lingua e dominio, su un corpus di 100.000 immagini; i documenti rilevanti per ciascuna query sono le immagini servite per essa. Non abbiamo valutato EVIE-8B o Nemotron ColEmbed su PPLX-Q2I, poiché indicizzare un corpus di queste dimensioni alle loro dimensionalità di output predefinite (2.560 per Nemotron ColEmbed 4B e 4.096 per Nemotron ColEmbed 8B e EVIE-8B) era impraticabile.

Analogamente a quanto osservato nelle prestazioni su ViDoRe(V3), il nostro modello da 0,6B è competitivo con modelli molto più grandi, risultando inferiore di soli 1 pp a qwen3-vl-embed-8b su MIRACL-Vision. Il nostro modello da 9B supera tutti gli altri modelli tranne gemini-embedding-2.

Su PPLX-Q2I, entrambi i nostri modelli superano qwen3-vl-embedding-8b con un margine superiore a 9 pp, e il nostro modello da 9B è dietro a gemini-embedding-2 di soli 2 pp. I nostri risultati restano competitivi su corpus che contengono sia immagini naturali sia documenti visivi, quindi le rappresentazioni multi-vettore che danno vantaggio su ViDoRe(V3) non vanno a scapito della ricerca generalista di immagini.

Espandi

Retrieval cross-model

I risultati nelle sezioni precedenti valutano ciascun modello rispetto a un corpus di cui ha calcolato gli embedding. Lo spazio di embedding condiviso significa che questo non è un requisito: un corpus indicizzato dal modello da 9B può essere interrogato con query di cui il modello da 0,6B ha calcolato gli embedding. Questa è la configurazione che ci aspettiamo venga usata nella maggior parte delle implementazioni in produzione, poiché l’indicizzazione è un costo una tantum ammortizzato sull’intera vita del corpus, mentre l’embedding delle query rientra nel percorso critico della latenza di ogni richiesta.

Un'installazione che non può eseguire il modello da 9B al momento della query altrimenti indicizzerebbe anche con il modello da 0,6B, quindi la configurazione simmetrica da 0,6B è il punto di confronto rilevante. Valutiamo sui 72 benchmark specifici per dominio usati sopra e sul retrieval di immagini di ViDoRe v3. Le query sono trasformate in embedding con pplx-embed-v2-late-0.6b e variamo solo il modello usato per generare gli embedding del corpus.

L’indicizzazione con il modello da 9B è un miglioramento netto. Nei benchmark specifici per dominio, la configurazione asimmetrica registra in media un guadagno di 1,6 pp. Nel retrieval di immagini di ViDoRe v3, raggiunge il 63,5%, contro il 62,3% con il modello da 0,6B su entrambi i lati, per un guadagno di 1,2 punti percentuali. Il costo di codifica delle query rimane invariato tra la configurazione simmetrica da 0,6B e quella asimmetrica, poiché in entrambi i casi la query è codificata dallo stesso modello da 0,6B; il costo aggiuntivo di codifica dei documenti è sostenuto in fase di indicizzazione.

Eseguire il modello da 9B su entrambi i lati resta comunque migliore, con una media dell’81,3% nei benchmark specifici per dominio. La configurazione asimmetrica recupera quindi circa metà della differenza di qualità tra i due modelli sul testo, senza costi aggiuntivi di codifica delle query. La configurazione da scegliere dipende dal fatto che il modello da 9B sia o meno sostenibile al momento della query; dove non lo è, la configurazione asimmetrica cattura una parte sostanziale del suo beneficio.

Espandi

Retrieval agentico

Il retrieval agentico è un altro contesto in cui gli embedding multi-vettore sono particolarmente forti. In BrowseComp+, un LLM (GPT-OSS-120B nel nostro caso) usa il modello di embedding per cercare in un corpus informazioni rilevanti per una query utente complessa, e un secondo LLM giudica se la risposta risultante corrisponde alla verità di riferimento. Il nostro modello da 9B raggiunge un’accuratezza del 64,0%, superando il successivo miglior modello ColBERT di 4,9 pp e il successivo miglior modello dense di 8,7 pp, pur effettuando meno ricerche di qualsiasi altro modello tranne il nostro da 0,6B. Anche il modello da 0,6B è davanti a tutti i modelli al di fuori della nostra famiglia.

Espandi

MADQA mette alla prova il question answering agentico su 800 PDF eterogenei del mondo reale che coprono oltre 18.000 pagine, con 500 domande scritte da umani che non possono essere risposte a partire dalla conoscenza generale. Un agente (Gemini 3.5 Flash nel nostro caso) cerca nella raccolta con il retriever in esame ed è valutato sull’accuratezza della risposta e sull’F1 delle pagine rispetto alle pagine di evidenza annotate. Il nostro modello da 9B stabilisce un nuovo stato dell’arte tra i retriever con un’accuratezza del 92,4%, 3,5 pp davanti allo stesso agente che usa il retriever di Mixedbread; il nostro modello da 0,6B raggiunge il 90,1%. Notiamo inoltre che il nostro retriever ottiene risultati competitivi rispetto a Mixedbread Agentic Search, che utilizza un sotto-agente di ricerca nel loro sistema di ricerca che pianifica ed esegue più ricerche per chiamata dall’agente principale (93,4%, entro il nostro intervallo di confidenza).

Espandi

Per iniziare

Entrambi i nostri modelli da 0,6B e 9B sono disponibili su Hugging Face e sono compatibili out of the box con sentence-transformers >= 6.0.0 e transformers >= 5.4.0. Ulteriori dettagli tecnici e i risultati completi della valutazione saranno pubblicati in un technical report più avanti quest’anno.

Stiamo attualmente addestrando la prossima generazione dei nostri modelli di embedding densi e introdurremo progressivamente il supporto per embedding a interazione tardiva, densi e contestuali sulla Perplexity API Platform.

Citazione

@online{perplexity2026MultimodalEmbeddingsBeyondASingleVector,
  author = {{Perplexity} and Markus Krimmel and Louis Milliken and Antoine Chaffin and Sarah Eslami and Ekaterina Glazkova and Maximilian Schall and Bo Wang and Denis Bykov and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Multimodal embeddings beyond a single vector}},
  date = {2026-10-07},
  url = {https://www.perplexity.ai/hub/blog/multimodal-embeddings-beyond-a-single-vector}
}