Multimodala embeddingar bortom en enda vektor

Sedan vi släppte pplx-embed-v1 i februari har vi arbetat på en ny generation embeddingsmodeller. Förra veckan introducerade vi vår nya kontextuella embeddingsmodell, pplx-embed-v2-context. I dag utökar vi familjen med pplx-embed-v2-late, en samling modeller med sen interaktion. Vid sidan av starkare retrievalförmåga är modellerna de första som kombinerar tre kärnfunktioner:

• Multi-vektorrepresentationer. I stället för att komprimera varje inmatning till en enda vektor behåller dessa modeller tokennivåvektorer för mer finmaskiga jämförelser mellan fråga och dokument. Detta gör att olika delar av en fråga kan matcha olika delar av ett dokument och bevarar detaljer som är särskilt värdefulla för multimodal retrieval.
• Stöd för både text- och bildmodaliteter. Utöver våra tidigare modellers text-till-text-retrieval kan dessa nya modeller hantera text-till-bild-retrieval, vilket gör att de direkt kan söka i renderade PDF-sidor utan att OCR eller analyserad text behövs.
• Ett delat inbäddningsutrymme. Vi släpper två modellstorlekar, 0,6B och 9B, för att stödja olika krav på kvalitet, latens och beräkningskapacitet. Var och en kan användas oberoende, men det delade inbäddningsutrymmet gör det också möjligt för den mindre modellen att fråga ett index som skapats med den större modellen, vilket kombinerar dokumentinbäddningar av högre kvalitet med billig och snabb inferens vid frågetillfället.

De nya modellerna når resultat i toppklass på en rad riktmärken för bild- och texthämtning, liksom på agentiska frågesvarsuppgifter. Noterbart är att vår 0,6B-modell på ViDoRe (V3), ett ledande riktmärke för visuell dokumenthämtning, presterar i nivå med modeller som har fem gånger så många aktiva parametrar. Båda modellerna finns offentligt tillgängliga på Hugging Face. I vår tekniska rapport finns mer information om metodiken och utvärderingsresultaten.

Från enkelvektorer till sen interaktion

Retrievalsystem måste hitta en balans mellan effektivitet och djupet i interaktionen mellan frågor och dokument. Täta embeddingsmodeller kodar varje fråga och varje dokument oberoende av varandra, vilket gör att de kan jämföras med en billig inre produkt. Detta gör ungefärlig närmaste-granne-sökning (ANN) över miljarder dokument praktiskt användbar. I andra ytterligheten bearbetar cross-encoders frågan och dokumentet tillsammans, vilket möjliggör rikare interaktion men kräver ett separat framåtpass för varje kandidat. Att tillämpa denna beräkning över en stor korpus av dokument för varje sökning är oöverkomligt dyrt, så cross-encoders används vanligtvis för omrankning av en liten uppsättning upphämtade kandidater.

Begränsningar med täta embeddingar

Att representera ett helt dokument med en enda vektor med fast storlek skapar en informationsflaskhals. När dokument blir längre och täcker fler ämnen måste modellen komprimera mer innehåll till samma vektor, vilket gör det svårare att bevara allt som är relevant för en fråga. Chunking kan minska detta tryck, men det fragmenterar dokumentet och kan separera information som bara blir meningsfull tillsammans, ett problem som vi också hanterar med vår kontextuella embeddingsmodell. Denna flaskhals förvärras i multimodala sammanhang, där informationsdensiteten i bilder kräver ännu mer komprimering.

Enkelvektorbaserad tät retrieval reducerar dessutom varje jämförelse till en inre produkt mellan två vektorer, vilket begränsar scorerfunktionens expressivitet. För en given inbäddningsdimension och en tillräckligt stor korpus är vissa mönster av poäng över fråga-dokument-par omöjliga att producera, oavsett träning. LIMIT-benchmarken gör denna teoretiska fråga till ett konkret stresstest för enkelvektorbaserad retrieval.

Retrieval med sen interaktion

Modeller med sen interaktion intar utrymmet mellan de billigare täta embeddingsmodellerna och de mer expressiva cross-encoders. Liksom täta modeller kodar de dokument oberoende av frågan, vilket gör att dokumentrepresentationer kan beräknas offline. Men i stället för att reducera varje inmatning till en enda vektor behåller de flera vektorer och använder en rikare scorerfunktion när en fråga jämförs med ett dokument.

Våra pplx-embed-v2-late-modeller använder en ColBERT-liknande arkitektur och ger ut embeddingar med 128 dimensioner för varje token i indata. Vi skårar fråga-dokument-par med MaxSim; för varje frågetoken väljer modellen dokumenttokenen med högst poäng och summerar de maximala likheterna per token för att ge den slutliga poängen. Detta gör att olika delar av en fråga kan matcha olika delar av ett dokument, där starkare tokenmatchningar bidrar mer till poängen.

Förstora

Denna extra uttrycksfullhet kommer med högre lagrings- och kandidatpoängsättningskostnader. Tät retrieval lagrar en vektor per dokument och poängsätter en kandidat med en enda inre produkt; sen interaktion lagrar vektorer för dokumenttokens och utvärderar många token-till-token-likheter. Kostnaden växer med dokumentlängden, så sen interaktion kräver en annan avvägning för indexering och servering än ANN-retrieval med en enda vektor. I gengäld ger den rikare retrieval i första steget för kvalitetskänsliga korpusar och kan också fungera som ett senare steg i en större webbskalig retrievalpipeline.

En modell, flera modaliteter

Detta förbättrade interaktionsdjup har visat sig vara mycket användbart för olika uppgifter, inklusive retrieval med långt sammanhang, uppgiftsdriven retrieval och retrieval utanför domänen. Denna skillnad blir särskilt tydlig i multimodal retrieval, vilket visas av ColPali-modellernas stora försprång på ViDoRe(V3)-topplistan.

Verkliga korpusar består inte bara av ren text. De kommer som PDF-filer, presentationsdäck, skärmdumpar, skannade sidor, diagram och tabeller. Den konventionella pipelinen parser dessa dokument, tillämpar OCR eller bildtextgenerering och söker i den resulterande texten, vilket är dyrt och förlustbringande: det kan introducera OCR-fel och det kastar bort layout, tabellstruktur, figurer och rumsliga relationer. Visuell dokumentsökning hoppar över det steget och projicerar den renderade sidan direkt in i representationsutrymmet där textfrågor kan söka i den.

Vår nya modellfamilj bygger vidare på den starka prestandan hos multivektormodeller för multimodal sökning och flyttar Paretofronten för små modeller på den mest använda benchmarken för dokumentsökning, ViDoRe(V3). Även om vi förväntar oss att dokumentrenderingar blir den vanligaste formen av visuell indata, stöder våra modeller också semantisk bildsökning över naturliga bilder, till exempel foton av landskap.

Träning av en familj interoperabla modeller

Sökning är i grunden asymmetrisk: indexering och frågekodning har olika operativa krav. Indexering körs offline och kan parallelliseras, så dess beräkningskostnad skrivs av över många framtida sökningar. Frågekodning körs online för varje begäran, vilket gör den latenskänslig och ibland underkastad begränsningar i servering eller på edge-enheter. Vår modellfamilj utnyttjar denna asymmetri och erbjuder storlekar anpassade för vardera sidan av retrievalpipenlinen.

Vi tränar en 18B-lärare kontrastivt och destillerar sedan separat till 9B- och 0,6B-elever. I stället för att träna varje elev enbart för att reproducera lärarens rangordningsfördelning använder vi representationdestillering i LEAF-stil: för varje indatatoken justerar vi elevens utdataembedding mot lärarens. Även om destillering i representationsutrymmet tidigare har använts för täta, enkelvektorbaserade modeller, utvidgar vi den till sen interaktion, där aligneringsmålet är en vektor för varje bevarad token.

Som ett resultat delar båda de släppta checkpointarna samma multivektorinbäddningsutrymme. Detta möjliggör sökning över modeller och gör ytterligare distributionsalternativ möjliga.

• Maximal kvalitet: koda dokument och frågor med 9B-modellen.
• Maximal effektivitet: koda dokument och frågor med 0,6B-modellen för 100 % lokal inferens
• Retrieval med låg latens: bygg korpusindexet med 9B-modellen och koda sedan livefrågor med 0,6B-modellen för att utnyttja beräkning vid indexeringstid samtidigt som frågning hålls snabb.
• Lokal–moln-retrieval: koda privata lokala dokument eller livefrågor med 0,6B-modellen på enheten och jämför eller slå samman dessa representationer med resultat från ett 9B-index som hostas i molnet.

För miljöer där latens är kritisk designade vi 0,6B-modellen som en lättviktig frågekodare som också kan köras på edge-enheter. Med utgångspunkt i Qwen3.5-0.8B beskär vi dess texttower med 24 lager till 12 lager, vilket minskar det tornet från 498 miljoner till 240 miljoner icke-embeddingparametrar. Den resulterande modellen har totalt 594 miljoner parametrar, men dess nominella storlek överskattar serveringskostnaden: 100 miljoner används för bildkodning och 254 miljoner finns i token-embeddingtabellen, vilket har liten effekt på körningstiden. Endast cirka 240 miljoner parametrar är aktiva för textkodning och 340 miljoner för bildkodning, vilket ger modellen serveringskostnaden för en betydligt mindre modell samtidigt som kompatibiliteten med 9B-indexet bibehålls.

Vi tillämpade samma process för att bygga vår 18B-lärare från en 27B-backbone, vilket gjorde läraren betydligt billigare att destillera från utan att försvaga signalen den tillhandahåller.

Multispråkig, multimodal, okontaminerad träningsdata

Vi tränar båda modellerna på en dataset med 186 miljoner fråga-dokument-par från 594 dataset på 46 språk. Av dessa par är 88,3 % text-till-text, 8,3 % text-till-bild och 3,4 % text-till-visuellt-dokument. I stället för att sampla proportionellt mot datasetstorlek tilldelar vi varje dataset en samplingsvikt, vilket ger en mer balanserad träningsmix på 56,5 %, 30,9 % respektive 12,6 %.

När vi bygger vår träningsdata exkluderar vi alla dataset som är kopplade till benchmarker som vi utvärderar på, för att troget återge våra resultat utan att blåsa upp benchmarkpoängen. Detta beslut innebär en avvägning, eftersom vissa av de dataset vi valde att exkludera innehåller högkvalitativ data som skulle kunna förbättra vår modells prestanda på andra uppgifter än den benchmark de kom ifrån. I slutändan valde vi att acceptera den kostnaden: tillförlitliga siffror är mer användbara för oss under utvecklingen och för användare när modeller jämförs.

Utvärdering

Vi utvärderar båda modellerna över text, visuellt dokument, blandad bild och uppgiftsdriven retrieval. Båda modellerna överträffar de utvärderade baslinjerna på Q2D-Web och BrowseComp+, och uppnår starka resultat på visuell dokumentretrieval och MADQA.

Textretrieval

Vi utvärderar text-till-text-retrieval på tre benchmarker:

• Domänspecifika benchmarker: En samling med 72 MTEB-liknande uppgifter, 55 över fem domäner (finans, juridik, hälsa, konversation, teknik), plus 17 övriga flerspråkiga uppgifter. Samlingen innehåller uppgifter som FinQA, AILACasedocs och XLSum. Ingen av dessa dataset förekommer i vår träningsdata, som beskrivs ovan.
• Q2D-Web: vår webbskaliga retrieval-benchmark med omkring 70 000 av agent omformulerade sökfrågor, hämtade från produktionssöktrafik, över en korpus på 190 miljoner webbdokument. Denna benchmark mäter retrievalprestanda i en miljö som ligger mycket närmare verklig webbretrieval än andra tillgängliga retrievalbenchmarks, tack vare sina produktionsliknande frågor och sin storskaliga korpus.
• ViDoRe(V3) Markdown: ViDoRe(V3) är vanligtvis en text-till-visuellt-dokument-retrievaluppgift, men den kan också utvärderas som en textuppgift med hjälp av en version av korpusen som har parsats till Markdown, vilket låter oss utvärdera informationsrik dokumentsökning i både bild- och textmodaliteter.

Vi mäter prestanda med nDCG@10, utom på Q2D-Web, där vi rapporterar Recall@1000 på grund av benchmarkens fokus på ett första steg i webbretrieval. Genom alla våra utvärderingar jämför vi med branschledande embeddingsmodeller över olika storleksklasser. För textretrieval representerar nemotron-embed-8b, gemini-embedding-2, voyage-large-4 och qwen3-embed-8b de starkaste och mest använda täta konkurrenterna, medan voyage-4-nano och qwen3-embed-0.6b fungerar som täta baslinjer under en miljard parametrar. Vi jämför dessutom med TopK:s nyligen släppta topk-embed-v1-modeller med sen interaktion på de benchmarker där TopK har publicerat resultat. Poäng för ViDoRe(V3) är hämtade från deras model cards vid 128 dimensioner, vilket matchar bredden på våra tokenembeddingar; poängen för Q2D-Web är hämtad från vår leaderboard.

På de domänspecifika benchmarkerna är våra 9B- och 0,6B-modeller i snitt 81,3 % respektive 78,0 %. Vår 9B-modell uppnår den högsta poängen av alla modeller vi utvärderade och slår den näst bästa modellen med 1,6 procentenheter. Vår 0,6B-modell är konkurrenskraftig med de andra topprankade modellerna och ligger endast 0,3 procentenheter efter gemini-embedding-2. Viktigt är att eftersom vi inte tränade på någon av data för dessa benchmarkuppgifter visar de domänspecifika benchmarkerna att våra embeddingmodeller kan generalisera till nya domäner.

Förstora

Den relativa styrkan hos vår 0,6B-modell är ännu större på uppgiften ViDoRe(V3) Markdown; dess poäng på 61,2 % slår alla andra modeller utom vår 9B-modell, som fick 64,7 %. Den näst bästa externa modellen fick 60,6 %, och den näst bästa sub-1B-modellen, topk-embed-v1-0.8b, låg 4,3 procentenheter efter vår 0,6B-modell.

Förstora

På Q2D-Web kommer relevansen från tre bedömningsuppsättningar: dokument som agenten citerade (Citation), dokument rankade av vårt produktionsretrievalsystem (Web) och unionen av båda kompletterad med LLM-bedömningar av oetiketterade dokument (Combined). Båda pplx-embed-v2-late-modellerna leder samtliga baslinjer i alla tre bedömningsuppsättningar. Vi fokuserar på de kombinerade bedömningarna, eftersom Citation- och Web-mängderna härleds från det som våra egna system redan lyfte fram och därför gynnar modeller som rankar på samma sätt; LLM-bedömningarna som lades till i Combined täcker dokument som inget av systemen hämtade upp. I den uppsättningen slår både vår 9B- och 0,6B-modell alla konkurrenter och når poängen 74,8 % respektive 73,6 %, mot det tidigare bästa resultatet på 69,3 %.

Förstora

Visuell retrieval

Vår primära benchmark för visuell retrieval är det offentliga standardurvalet av ViDoRe (V3), där korpusen består av renderade sidbilder snarare än Markdown-konverteringen. Vi jämför med två ledande täta vision-språkmodeller, qwen3-vl-embed-8b och gemini-embedding-2, samt med de sent-interagerande modellerna topk-embed-v1. Dessutom är Tencent:s EVIE-modeller och NVIDIA:s Nemotron ColEmbed V2-modeller "vision-only"-multivektorsbaslinjer som har tränats specifikt för bildretrievaluppgifter.

Båda våra modeller uppnår toppmodern prestanda för vision-språkmodeller. Vår 9B-modell får 65,2 % i snitt och är bara efter EVIE. Vår 0,6B-modell uppnår 62,3 %, före topk-embed-v1-2b och endast efter de mycket större EVIE och nemotron-colembed-v2-8b bland externa baslinjer.

Förstora

Vår 0,6B-modell är särskilt konkurrenskraftig sett till modellstorlek. Den ligger före alla jämförbara modeller i storlek och inom 1,2 procentenheter från nemotron-colembed-v2-8b samtidigt som den aktiverar endast 340 miljoner parametrar för bildinmatningar. Våra modeller producerar embeddingar med 128 dimensioner per token, jämfört med 2 048 för EVIE-4.5B och 4 096 för EVIE-8B och nemotron-colembed-v2-8b. Denna skillnad i lagringskostnader kan drastiskt påverka i vilka scenarier dessa modeller är praktiskt användbara.

Förstora

Vi utvärderar också visuell retrieval på MIRACL-Vision, en benchmark vars korpus består av skärmdumpar av Wikipedia-artiklar, och PPLX-Q2I, en intern benchmark som täcker både visuella dokument och naturliga bilder. PPLX-Q2I bygger på Perplexitys produktionsloggar för bildsökning och är utformad för att spegla bredden av användningsfall för bildsökning. Vi använder ett urval på 10 000 frågor, stratifierat efter språk och domän, mot en korpus med 100 000 bilder; varje frågas relevanta dokument är de bilder som visades för den. Vi utvärderade inte EVIE-8B eller Nemotron ColEmbed på PPLX-Q2I, eftersom indexering av en korpus i den här storleken vid deras standardutdata-dimensioner (2 560 för Nemotron ColEmbed 4B och 4 096 för Nemotron ColEmbed 8B och EVIE-8B) var opraktisk.

I likhet med prestandan på ViDoRe(V3) är vår 0,6B-modell konkurrenskraftig med mycket större modeller och ligger endast 1 procentenhet bakom qwen3-vl-embed-8b på MIRACL-Vision. Vår 9B-modell överträffar alla andra modeller utom gemini-embedding-2.

På PPLX-Q2I slår båda våra modeller qwen3-vl-embedding-8b med mer än 9 procentenheter, och vår 9B-modell ligger endast 2 procentenheter efter gemini-embedding-2. Våra resultat förblir konkurrenskraftiga på korpusar som innehåller naturliga bilder såväl som visuella dokument, så de multivektorrepresentationer som ger utdelning på ViDoRe(V3) sker inte på bekostnad av generell bildsökning.

Förstora

Sökning över modeller

Resultaten i de föregående avsnitten utvärderar varje modell mot en korpus som den själv har bäddat in. Det delade inbäddningsutrymmet innebär att detta inte är ett krav: en korpus som indexerats av 9B-modellen kan sökas med frågor som bäddats in av 0,6B-modellen. Det här är den konfiguration vi förväntar oss att de flesta produktionssättningar ska använda, eftersom indexering är en engångskostnad som skrivs av över korpusens livstid medan frågeinbäddning körs i den latenskritiska vägen för varje begäran.

En distribution som inte kan köra 9B-modellen vid frågetillfället skulle annars även indexera med 0,6B-modellen, så den symmetriska 0,6B-konfigurationen är den relevanta jämförelsepunkten. Vi utvärderar mot de 72 domänspecifika benchmarkerna som användes ovan och på bildretrieval i ViDoRe v3. Frågor bäddas in med pplx-embed-v2-late-0.6b, och vi varierar endast vad som bäddade in korpusen.

Att indexera med 9B-modellen är en tydlig förbättring. På de domänspecifika benchmarkerna ger den asymmetriska konfigurationen i genomsnitt en vinst på 1,6 procentenheter. På bildretrieval i ViDoRe v3 uppnår den 63,5 %, upp från 62,3 % med 0,6B-modellen på båda sidor, en vinst på 1,2 procentenheter. Kostnaden för frågekodning är oförändrad mellan den symmetriska 0,6B- och den asymmetriska konfigurationen, eftersom samma 0,6B-modell kodar frågan i båda fallen; den extra kostnaden för dokumentkodning uppstår vid indexeringstid.

Att köra 9B-modellen på båda sidor är fortfarande bättre och ger i genomsnitt 81,3 % på de domänspecifika benchmarkerna. Den asymmetriska konfigurationen återvinner därför ungefär hälften av kvalitetsskillnaden mellan de två modellerna på text, utan någon extra kostnad för frågekodning. Vilken konfiguration som ska väljas beror på om 9B-modellen är överkomlig vid frågetillfället; där så inte är fallet fångar den asymmetriska uppsättningen en betydande del av dess fördel.

Förstora

Uppgiftsdriven retrieval

Uppgiftsdriven retrieval är en annan miljö där multivektor-embeddingar är särskilt starka. I BrowseComp+ använder en LLM (GPT-OSS-120B i vårt fall) embeddingmodellen för att söka i en korpus efter information som är relevant för en komplex användarfråga, och en andra LLM bedömer om det resulterande svaret matchar facit. Vår 9B-modell uppnår 64,0 % noggrannhet, vilket slår den näst bästa ColBERT-modellen med 4,9 procentenheter och den näst bästa täta modellen med 8,7 procentenheter, samtidigt som den utför färre sökningar än någon annan modell utom vår 0,6B. 0,6B-modellen ligger också före varje modell utanför vår familj.

Förstora

MADQA testar uppgiftsdriven frågesvar över 800 heterogena verkliga PDF-filer som omfattar mer än 18 000 sidor, med 500 mänskligt författade frågor som inte kan besvaras utifrån allmänkunskap. En agent (Gemini 3.5 Flash i vårt fall) söker i samlingen med retrievern som testas och poängsätts på svarsnoggrannhet och på sid-F1 mot de annoterade evidenssidorna. Vår 9B-modell sätter en ny toppnotering bland retrievers med 92,4 % noggrannhet, 3,5 procentenheter före samma agent som använder Mixedbreads retriever; vår 0,6B-modell når 90,1 %. Vi noterar också att vår retriever uppnår konkurrenskraftiga resultat mot Mixedbread Agentic Search, som använder en söksubagent i deras söksystem som planerar och kör flera sökningar per anrop från huvudagenten (93,4 %, inom vårt konfidensintervall).

Förstora

Kom igång

Både våra 0,6B- och 9B-modeller finns tillgängliga på Hugging Face och är direkt kompatibla med sentence-transformers >= 6.0.0 och transformers >= 5.4.0. Ytterligare tekniska detaljer och fullständiga utvärderingsresultat kommer att publiceras i en teknisk rapport senare i år.

Vi tränar just nu nästa generation av våra täta inbäddningsmodeller och kommer successivt att lansera stöd för inbäddningar med sen interaktion samt täta och kontextuella inbäddningar på Perplexity API Platform.

Citat

@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}
}