एकल vector से आगे multimodal embeddings

फरवरी में pplx-embed-v1 जारी करने के बाद से, हम embedding models की नई पीढ़ी पर काम कर रहे हैं। पिछले सप्ताह हमने अपना नया contextual embedding model, pplx-embed-v2-context, पेश किया। आज, हम इस family का विस्तार pplx-embed-v2-late के साथ कर रहे हैं, जो late-interaction models का एक संग्रह है। अधिक मजबूत retrieval क्षमताओं के साथ, ये models तीन core features को संयोजित करने वाले पहले models हैं:

• Multi-vector representations. प्रत्येक input को एक ही vector में compress करने के बजाय, ये models finer-grained query-document comparisons के लिए token-level vectors बनाए रखते हैं। इससे query के अलग-अलग हिस्से document के अलग-अलग हिस्सों से match कर सकते हैं, और वह detail संरक्षित रहती है जो विशेष रूप से multimodal retrieval में उपयोगी है।
• text और image modalities दोनों के लिए support. हमारे पिछले models की text-to-text retrieval क्षमताओं के अलावा, ये नए models text-to-image retrieval को संभालते हैं, जिससे वे OCR या parsed text की आवश्यकता के बिना सीधे rendered PDF pages को search कर सकते हैं।
• एक shared embedding space. हम विभिन्न quality, latency, और compute आवश्यकताओं का समर्थन करने के लिए दो model sizes, 0.6B और 9B, जारी कर रहे हैं। प्रत्येक का स्वतंत्र रूप से उपयोग किया जा सकता है, लेकिन shared embedding space छोटे model को बड़े model से बनाए गए index को query करने की भी अनुमति देता है, जिससे उच्च-गुणवत्ता वाले document embeddings को सस्ते, तेज़ query-time inference के साथ जोड़ा जा सकता है।

ये नए मॉडल विज़न और टेक्स्ट रिट्रीवल के कई बेंचमार्क के साथ-साथ एजेंटिक प्रश्न-उत्तर कार्यों पर भी अत्याधुनिक परिणाम हासिल करते हैं। ख़ास तौर पर, अग्रणी विज़ुअल डॉक्यूमेंट रिट्रीवल बेंचमार्क ViDoRe (V3) पर हमारा 0.6B मॉडल उन मॉडलों की बराबरी करता है जिनमें पाँच गुना अधिक सक्रिय पैरामीटर हैं। दोनों मॉडल Hugging Face पर सार्वजनिक रूप से उपलब्ध हैं। हमारी तकनीकी रिपोर्ट में कार्यप्रणाली और मूल्यांकन परिणामों के बारे में अधिक जानकारी दी गई है।

एकल vectors से late interaction तक

Retrieval systems को efficiency और queries तथा documents के बीच interaction की गहराई के बीच संतुलन बनाना होता है। Dense embedding models हर query और document को स्वतंत्र रूप से encode करते हैं, जिससे उन्हें एक सस्ते inner product से compare किया जा सकता है। इससे अरबों documents पर approximate nearest-neighbor (ANN) search व्यावहारिक हो जाती है। दूसरी छोर पर, cross-encoders query और document को साथ में process करते हैं, जिससे अधिक समृद्ध interaction संभव होता है, लेकिन हर candidate के लिए एक अलग forward pass की आवश्यकता होती है। हर search के लिए documents के बड़े corpus पर इस computation को लागू करना अत्यधिक महंगा है, इसलिए cross-encoders आम तौर पर retrieved candidates के एक छोटे set को rerank करने के लिए आरक्षित होते हैं।

Dense embeddings की सीमाएँ

पूरे document को एक fixed-size vector से निरूपित करना एक information bottleneck बनाता है। जैसे-जैसे documents लंबे होते जाते हैं और अधिक topics को कवर करते हैं, model को उतनी ही vector में अधिक content compress करना पड़ता है, जिससे query से संबंधित हर चीज़ को संरक्षित करना कठिन हो जाता है। Chunking इस दबाव को कम कर सकती है, लेकिन यह document को टुकड़ों में बाँट देती है और ऐसी जानकारी को अलग कर सकती है जो केवल साथ होने पर ही अर्थपूर्ण होती है; इस समस्या से हम अपने contextual embedding model के साथ भी निपटते हैं। यह bottleneck multimodal settings में और बढ़ जाता है, जहाँ images की information density और अधिक compression की माँग करती है।

Single-vector dense retrieval भी हर comparison को दो vectors के बीच inner product तक सीमित कर देती है, जिससे scoring function की expressivity सीमित हो जाती है। निश्चित embedding dimension और पर्याप्त बड़े corpus के लिए, query-document pairs के across scores के कुछ patterns training चाहे जैसी भी हो, उत्पन्न करना असंभव है। LIMIT benchmark इस सैद्धांतिक चिंता को single-vector retrieval के लिए एक ठोस stress test में बदल देता है।

लेट-इंटरैक्शन रिट्रीवल

Late-interaction models सस्ते dense embedding models और अधिक expressive cross-encoders के बीच की जगह लेते हैं। Dense models की तरह, वे query से स्वतंत्र रूप से documents को encode करते हैं, जिससे document representations को offline compute किया जा सकता है। हालाँकि, प्रत्येक input को एक ही vector तक सीमित करने के बजाय, वे कई vectors बनाए रखते हैं और query को document से compare करते समय richer scoring function का उपयोग करते हैं।

हमारे pplx-embed-v2-late models ColBERT-शैली की architecture का उपयोग करते हैं, जो input के प्रत्येक token के लिए 128-dimensional embeddings output करते हैं। हम MaxSim का उपयोग करके query-document pairs को score करते हैं; हर query token के लिए model सबसे उच्च-स्कोर वाले document token का चयन करता है और final score बनाने के लिए per-token maximum similarities का योग करता है। इससे query के अलग-अलग हिस्से document के अलग-अलग हिस्सों से match कर सकते हैं, और अधिक मज़बूत token matches score में अधिक योगदान देते हैं।

बड़ा करें

यह अतिरिक्त expressiveness higher storage और candidate-scoring costs के साथ आती है। Dense retrieval एक document प्रति एक vector संग्रहीत करती है और एक candidate को एक inner product से score करती है; late interaction document tokens के लिए vectors संग्रहीत करती है और कई token-to-token similarities का मूल्यांकन करती है। लागत document length के साथ बढ़ती है, इसलिए late interaction को one-vector ANN retrieval से अलग indexing और serving trade-off की आवश्यकता होती है। बदले में, यह quality-sensitive corpora के लिए अधिक समृद्ध first-stage retrieval प्रदान करती है और बड़े web-scale retrieval pipeline में बाद के stage के रूप में भी काम कर सकती है।

एक model, अनेक modalities

यह बेहतर interaction depth long-context, agentic और out-of-domain retrieval सहित विभिन्न tasks के लिए बहुत उपयोगी सिद्ध हुई है। यह अंतर multimodal retrieval में विशेष रूप से स्पष्ट है, जैसा कि ViDoRe(V3) leaderboard पर ColPali models की बड़ी बढ़त से दिखाई देता है।

वास्तविक-विश्व corpora केवल साफ़ text से नहीं बने होते। वे PDFs, slide decks, screenshots, scanned pages, charts, और tables के रूप में आते हैं। पारंपरिक pipeline इन documents को parse करती है, OCR या captioning लागू करती है, और परिणामस्वरूप text को search करती है, जो महँगा और loss़y है: यह OCR errors ला सकता है और layout, table structure, figures, तथा spatial relationships को हटा देता है। Visual document search उस चरण को छोड़ देती है, और rendered page को सीधे representation space में प्रक्षेपित करती है जहाँ textual queries उसे search कर सकती हैं।

हमारे models का नया family multi-modal search के लिए multi-vector models के मजबूत प्रदर्शन पर आधारित है और सबसे व्यापक रूप से उपयोग किए जाने वाले document search benchmark, ViDoRe(V3), पर छोटे models के लिए Pareto frontier को आगे बढ़ाता है। यद्यपि हम अपेक्षा करते हैं कि document renderings visual input का सबसे सामान्य रूप होंगे, हमारे models प्राकृतिक images, जैसे scenic photographs, पर semantic image search का भी समर्थन करते हैं।

Interoperable models का एक family प्रशिक्षित करना

Search मूल रूप से asymmetrical है: indexing और query encoding की operational constraints अलग-अलग होती हैं। Indexing offline चलती है और parallelized की जा सकती है, इसलिए इसकी compute cost कई भविष्य की searches में amortize हो जाती है। Query encoding हर request के लिए online चलती है, जिससे यह latency-sensitive होती है और कभी-कभी serving या edge-device limits के अधीन होती है। हमारा model family इस asymmetry का लाभ उठाता है, और retrieval pipeline के प्रत्येक पक्ष के लिए उपयुक्त sizes प्रदान करता है।

हम 18B टीचर को contrastively प्रशिक्षित करते हैं, फिर उसे अलग-अलग 9B और 0.6B स्टूडेंट्स में distill करते हैं। प्रत्येक स्टूडेंट को केवल टीचर के ranking distribution को पुन: प्रस्तुत करने के लिए प्रशिक्षित करने के बजाय, हम LEAF-style representation distillation का उपयोग करते हैं: प्रत्येक input token के लिए, हम स्टूडेंट के output embedding को टीचर के साथ align करते हैं। जबकि representation-space distillation का पहले dense, single-vector models में उपयोग किया गया है, हम इसे late interaction तक विस्तारित करते हैं, जहाँ alignment target हर retained token के लिए एक vector होता है.

परिणामस्वरूप, दोनों released checkpoints एक ही multi-vector embedding space साझा करते हैं। यह cross-model retrieval को सक्षम बनाता है, जिससे अतिरिक्त deployment options संभव होते हैं।

• अधिकतम गुणवत्ता: documents और queries को 9B model से encode करें।
• अधिकतम दक्षता: 100% local inference के लिए documents और queries को 0.6B model से encode करें
• Low-latency retrieval: corpus index को 9B model से build करें, फिर query-time पर तेज़ी बनाए रखने के लिए live queries को 0.6B model से encode करें और index-time computation का लाभ उठाएँ।
• Local–cloud retrieval: private local documents या live queries को 0.6B model से device पर encode करें, और उन representations को cloud में hosted 9B index के results के साथ compare या merge करें।

Latency-sensitive settings के लिए, हमने 0.6B model को एक lightweight query encoder के रूप में डिज़ाइन किया है जो edge devices पर भी चल सकता है। Qwen3.5-0.8B से शुरू करके, हम इसके 24-layer text tower को 12 layers तक prune करते हैं, जिससे वह tower 498M से घटकर 240M non-embedding parameters रह जाती है। परिणामी model में कुल 594M parameters हैं, लेकिन इसका nominal size serving cost को अधिक दिखाता है: 100M image encoding के लिए उपयोग होते हैं, और 254M token-embedding table में स्थित हैं, जिसका runtime पर बहुत कम प्रभाव पड़ता है। Text encoding के लिए केवल लगभग 240M parameters और image encoding के लिए 340M parameters सक्रिय होते हैं, जिससे model 9B index के साथ compatibility बनाए रखते हुए काफी छोटे model की serving cost देता है।

हमने 27B backbone से अपना 18B teacher बनाने के लिए वही प्रक्रिया लागू की, जिससे teacher प्रदान किए जाने वाले signal को कमज़ोर किए बिना उसे distill करना काफी सस्ता हो गया।

बहुभाषी, बहुविध, अप्रदूषित प्रशिक्षण डेटा

हम दोनों models को 46 भाषाओं में 594 datasets से लिए गए 186 million query-document pairs के dataset पर प्रशिक्षित करते हैं। इन pairs में से 88.3% text-to-text, 8.3% text-to-image, और 3.4% text-to-visual-document pairs हैं। Dataset size के अनुपात में sampling करने के बजाय, हम प्रत्येक dataset को एक sampling weight देते हैं, जिससे क्रमशः 56.5%, 30.9%, और 12.6% का अधिक संतुलित training mixture मिलता है।

अपना training data बनाते समय, हम उन datasets को बाहर कर देते हैं जो उन benchmarks से जुड़े हैं जिन पर हम मूल्यांकन करते हैं, ताकि benchmark scores को कृत्रिम रूप से बढ़ाए बिना अपने results को ईमानदारी से प्रस्तुत किया जा सके। इस निर्णय के साथ यह trade-off है कि जिन datasets को हमने बाहर करने का चुना, उनमें से कुछ में उच्च-गुणवत्ता वाला data है जो benchmark से इतर tasks पर हमारे model के प्रदर्शन को सुधार सकता था। अंततः, हमने उस cost को स्वीकार करना चुना: विकास के दौरान हमारे लिए, और models की तुलना करते समय users के लिए, भरोसेमंद numbers अधिक उपयोगी होते हैं।

मूल्यांकन

हम दोनों models का मूल्यांकन text, visual-document, mixed-image, और agentic retrieval में करते हैं। दोनों models Q2D-Web और BrowseComp+ पर evaluated baselines से बेहतर प्रदर्शन करते हैं, और visual-document retrieval तथा MADQA पर मज़बूत परिणाम प्राप्त करते हैं।

Text retrieval

हम तीन benchmarks पर text-to-text retrieval का मूल्यांकन करते हैं:

• Domain-specific benchmarks: 72 MTEB-style tasks का एक संग्रह, जिसमें पाँच domains (finance, legal, health, conversation, tech) में 55 तथा 17 miscellaneous multilingual tasks शामिल हैं। इस संग्रह में FinQA, AILACasedocs और XLSum जैसे tasks शामिल हैं। ऊपर वर्णित अनुसार, ये datasets हमारे training data में शामिल नहीं हैं।
• Q2D-Web: हमारा web-scale retrieval benchmark, लगभग 70,000 agent-reformulated search queries का, जो production search traffic से लिए गए हैं, और 190M web documents के corpus पर आधारित है। यह benchmark अन्य उपलब्ध retrieval benchmarks की तुलना में real-world web retrieval के कहीं अधिक निकट सेटिंग में retrieval performance को मापता है, क्योंकि इसमें production-like queries और large-scale corpus हैं.
• ViDoRe(V3) Markdown: ViDoRe(V3) सामान्यतः एक text-to-visual-document retrieval task है, लेकिन इसे Markdown में parsed corpus के एक संस्करण का उपयोग करके text task के रूप में भी मूल्यांकित किया जा सकता है, जिससे हम image और text दोनों modalities में information-rich document retrieval का मूल्यांकन कर सकते हैं।

हम nDCG@10 का उपयोग करके performance मापते हैं, सिवाय Q2D-Web के, जहाँ benchmark के first-stage web-retrieval scenario पर ध्यान के कारण हम Recall@1000 रिपोर्ट करते हैं। अपनी सभी evaluations में, हम विभिन्न size classes के across industry-leading embedding models से तुलना करते हैं। text retrieval के लिए, nemotron-embed-8b, gemini-embedding-2, voyage-large-4, और qwen3-embed-8b सबसे मजबूत और सबसे व्यापक रूप से उपयोग किए जाने वाले dense competitors का प्रतिनिधित्व करते हैं, जबकि voyage-4-nano और qwen3-embed-0.6b sub-billion parameter dense baselines के रूप में काम करते हैं। हम अतिरिक्त रूप से उन benchmarks पर TopK के हाल ही में जारी topk-embed-v1 late-interaction models से भी तुलना करते हैं, जिनके लिए TopK ने results प्रकाशित किए हैं। ViDoRe(V3) scores उनके model cards से 128 dimensions पर लिए गए हैं, जो हमारे token embeddings की width से मेल खाते हैं; Q2D-Web score हमारी leaderboard से लिया गया है.

Domain-specific benchmarks पर, हमारे 9B और 0.6B models का औसत क्रमशः 81.3% और 78.0% है। हमारा 9B model हमारे द्वारा मूल्यांकित सभी models में सबसे उच्च score हासिल करता है, और अगले सर्वोत्तम model को 1.6pp से पीछे छोड़ता है। हमारा 0.6B model अन्य शीर्ष-स्कोरिंग models के साथ प्रतिस्पर्धी है, और gemini-embedding-2 से केवल 0.3pp पीछे स्कोर करता है। महत्वपूर्ण बात यह है कि, चूँकि हमने इन benchmark tasks के किसी भी data पर training नहीं की, domain-specific benchmarks दिखाते हैं कि हमारे embedding models नए domains में generalize कर सकते हैं।

बड़ा करें

ViDoRe(V3) Markdown task पर हमारे 0.6B model की सापेक्ष मजबूती और भी अधिक है; इसका 61.2% score हमारे 9B model, जिसने 64.7% score किया, को छोड़कर सभी अन्य models को पछाड़ता है। अगला सर्वोत्तम external model 60.6% score करता है, और अगला सर्वोत्तम sub-1B model, topk-embed-v1-0.8b, हमारे 0.6B model से 4.3pp पीछे है।

बड़ा करें

Q2D-Web पर, relevance तीन judgment sets से आती है: documents the agent cited (Citation), हमारे production retrieval system द्वारा ranked documents (Web), और दोनों का union, जिसमें unlabeled documents के LLM judgments भी जोड़े गए हैं (Combined)। दोनों pplx-embed-v2-late models सभी तीन judgment sets पर हर baseline से आगे हैं। हम combined judgments पर ध्यान केंद्रित करते हैं, क्योंकि Citation और Web sets उन चीज़ों से निकले हैं जिन्हें हमारे own systems पहले ही surface कर चुके हैं, और इसलिए वे उन models का पक्ष लेते हैं जो उसी तरह rank करते हैं; Combined में जोड़े गए LLM judgments उन documents को कवर करते हैं जिन्हें किसी भी system ने retrieve नहीं किया। उस set पर, हमारे 9B और 0.6B दोनों models सभी competitors को पछाड़ते हैं, और क्रमशः 74.8% तथा 73.6% scores तक पहुँचते हैं, जबकि पिछला सर्वोत्तम score 69.3% था।

बड़ा करें

विज़ुअल रिट्रीवल

हमारा प्राथमिक विज़ुअल रिट्रीवल बेंचमार्क ViDoRe(V3) का मानक सार्वजनिक उपसमुच्चय है, जहाँ कॉर्पस Markdown रूपांतरण के बजाय रेंडर किए गए पेज इमेजों से बना है। हम दो प्रमुख dense vision-language models, qwen3-vl-embed-8b और gemini-embedding-2, तथा topk-embed-v1 late-interaction models के विरुद्ध तुलना करते हैं। इसके अतिरिक्त, Tencent के EVIE models और NVIDIA के Nemotron ColEmbed V2 models image retrieval कार्यों के लिए विशेष रूप से प्रशिक्षित “vision-only” multi-vector baselines हैं।

हमारे दोनों models vision-language models के लिए state of the art प्रदर्शन हासिल करते हैं। हमारा 9B model औसतन 65.2% स्कोर करता है, और केवल EVIE से पीछे है। हमारा 0.6B model 62.3% स्कोर हासिल करता है, जो topk-embed-v1-2b से आगे है और external baselines में केवल बहुत बड़े EVIE और nemotron-colembed-v2-8b से पीछे है।

बड़ा करें

हमारा 0.6B model model size के संदर्भ में विशेष रूप से प्रतिस्पर्धी है। यह समान आकार के सभी models से आगे है और केवल image inputs के लिए 340M parameters सक्रिय करते हुए nemotron-colembed-v2-8b से 1.2pp के भीतर है। हमारे models token प्रति 128-dimensional embeddings बनाते हैं, जबकि EVIE-4.5B के लिए 2,048 और EVIE-8B तथा nemotron-colembed-v2-8b के लिए 4,096। storage costs में यह अंतर इन models के व्यावहारिक उपयोग के परिदृश्यों को नाटकीय रूप से प्रभावित कर सकता है।

बड़ा करें

हम MIRACL-Vision पर भी visual retrieval का मूल्यांकन करते हैं, एक ऐसा benchmark जिसका corpus wikipedia articles के screenshots से बना है, और PPLX-Q2I पर, एक internal benchmark जो visual documents और natural images दोनों को कवर करता है। PPLX-Q2I Perplexity के production image-search logs से बनाया गया है और image search use cases की विविधता को प्रतिबिंबित करने के लिए डिज़ाइन किया गया है। हम 10,000-query का एक sample, language और domain के अनुसार stratified, 100,000 images के corpus के विरुद्ध उपयोग करते हैं; प्रत्येक query के relevant documents वे images हैं जो उसके लिए served की गईं। हमने PPLX-Q2I पर EVIE-8B या Nemotron ColEmbed का मूल्यांकन नहीं किया, क्योंकि इस आकार के corpus को उनकी default output dimensionalities (Nemotron ColEmbed 4B के लिए 2,560 और Nemotron ColEmbed 8B तथा EVIE-8B के लिए 4,096) पर index करना अव्यावहारिक था।

ViDoRe(V3) पर इसके प्रदर्शन की तरह, हमारा 0.6B model बहुत बड़े models के साथ प्रतिस्पर्धी है, और MIRACL-Vision पर qwen3-vl-embed-8b से केवल 1pp पीछे स्कोर करता है। हमारा 9B model gemini-embedding-2 को छोड़कर अन्य सभी models से बेहतर प्रदर्शन करता है।

PPLX-Q2I पर, हमारे दोनों models qwen3-vl-embedding-8b को 9pp से अधिक के अंतर से पछाड़ते हैं, और हमारा 9B model gemini-embedding-2 से केवल 2pp पीछे है। हमारे परिणाम उन corpora पर प्रतिस्पर्धी बने रहते हैं जिनमें natural images के साथ-साथ visual documents भी शामिल हैं, इसलिए ViDoRe(V3) पर लाभ देने वाली multi-vector representations सामान्य image search की कीमत पर नहीं आतीं।

बड़ा करें

क्रॉस-मॉडल रिट्रीवल

पिछले sections के results प्रत्येक model का मूल्यांकन उस corpus के विरुद्ध करते हैं जिसे उसी ने embedded किया था। Shared embedding space का अर्थ है कि यह कोई आवश्यकता नहीं है: 9B model द्वारा indexed corpus को 0.6B model द्वारा embedded queries के साथ search किया जा सकता है। हमें उम्मीद है कि अधिकांश production deployments इसी configuration का उपयोग करेंगे, क्योंकि indexing एक one-off cost है जो corpus के जीवनकाल में amortize हो जाती है, जबकि query embedding हर request के latency-critical path पर चलती है।

एक deployment जो query time पर 9B model चला नहीं सकता, अन्यथा corpus को भी 0.6B model से ही index करेगा; इसलिए वह symmetric 0.6B configuration तुलना का प्रासंगिक बिंदु है। हम ऊपर उपयोग किए गए 72 domain-specific benchmarks और ViDoRe v3 image retrieval पर मूल्यांकन करते हैं। Queries को pplx-embed-v2-late-0.6b से embed किया जाता है, और हम केवल यह बदलते हैं कि corpus को किसने embed किया।

9B model के साथ indexing एक स्पष्ट सुधार है। Domain-specific benchmarks पर, asymmetric configuration औसतन 1.6pp का लाभ देती है। ViDoRe v3 image retrieval पर, यह 63.5% स्कोर करती है, जो 0.6B model को दोनों sides पर उपयोग करने पर 62.3% था, यानी 1.2 percentage points का लाभ। Symmetric 0.6B और asymmetric configurations के बीच query-encoding cost अपरिवर्तित रहती है, क्योंकि दोनों में query को वही 0.6B model encode करता है; अतिरिक्त document-encoding cost indexing समय पर लगती है।

दोनों sides पर 9B model चलाना अभी भी बेहतर है, और domain-specific benchmarks पर औसतन 81.3% देता है। इसलिए asymmetric configuration text पर दोनों models के बीच गुणवत्ता अंतर का लगभग आधा हिस्सा बिना किसी अतिरिक्त query-encoding cost के पुनः प्राप्त कर लेती है। कौन-सी configuration चुननी है, यह इस पर निर्भर करता है कि query time पर 9B model वहन किया जा सकता है या नहीं; जहाँ यह संभव नहीं है, वहाँ asymmetric setup उसके लाभ का एक बड़ा हिस्सा पकड़ लेती है।

बड़ा करें

Agentic retrieval

Agentic retrieval एक और ऐसा setting है जहाँ multi-vector embeddings विशेष रूप से मज़बूत हैं। BrowseComp+ में, एक LLM (GPT-OSS-120B हमारे मामले में) embedding model का उपयोग करके एक जटिल user query से संबंधित जानकारी के लिए corpus को search करता है, और दूसरा LLM यह निर्णय करता है कि परिणामी answer ground truth से मेल खाता है या नहीं। हमारा 9B model 64.0% accuracy हासिल करता है, जो अगले सर्वोत्तम ColBERT model से 4.9pp और अगले सर्वोत्तम dense model से 8.7pp बेहतर है, जबकि वह हमारे 0.6B model के अलावा किसी भी अन्य model से कम searches जारी करता है। 0.6B model भी हमारी family के बाहर के हर model से आगे है।

बड़ा करें

MADQA 800 विषम वास्तविक-विश्व PDFs पर agentic question-answering का परीक्षण करता है, जो 18,000 से अधिक pages तक फैले हैं, और इसमें 500 मानव-लिखित प्रश्न हैं जिन्हें सामान्य ज्ञान से उत्तर नहीं दिया जा सकता। एक agent (हमारे मामले में Gemini 3.5 Flash) परीक्षणाधीन retriever के साथ collection को search करता है और answer accuracy तथा annotated evidence pages के विरुद्ध page F1 पर स्कोर किया जाता है। हमारा 9B model retrievers में 92.4% accuracy के साथ state of the art स्थापित करता है, जो Mixedbread’s retriever का उपयोग करने वाले उसी agent से 3.5pp आगे है; हमारा 0.6B model 90.1% तक पहुँचता है। हम यह भी नोट करते हैं कि हमारा retriever Mixedbread Agentic Search के मुकाबले प्रतिस्पर्धी परिणाम प्राप्त करता है, जो उनके search system में एक search sub-agent का उपयोग करता है जो मुख्य agent से प्रति call कई searches की योजना बनाता है और चलाता है (93.4%, हमारे confidence interval के भीतर)।

बड़ा करें

शुरुआत करें

हमारे 0.6B और 9B दोनों models Hugging Face पर उपलब्ध हैं और sentence-transformers >= 6.0.0 तथा transformers >= 5.4.0. के साथ out of the box compatible हैं। आगे के technical details और complete evaluation results इस वर्ष बाद में एक technical report में प्रकाशित किए जाएँगे।

हम फ़िलहाल अपने डेंस एम्बेडिंग मॉडलों की अगली पीढ़ी को ट्रेन कर रहे हैं, और Perplexity API Platform पर लेट-इंटरैक्शन, डेंस और कॉन्टेक्स्चुअल एम्बेडिंग के लिए सपोर्ट को चरणबद्ध तरीक़े से उपलब्ध कराएँगे।

उद्धरण

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