एका एकमेव vectorच्या पलीकडील multimodal embeddings

फेब्रुवारीमध्ये pplx-embed-v1 प्रसिद्ध केल्यापासून, आम्ही embedding मॉडेल्सच्या एका नवीन पिढीवर काम करत आहोत. गेल्या आठवड्यात, आम्ही आमचे नवीन contextual embedding model, pplx-embed-v2-context, सादर केले. आज, आम्ही pplx-embed-v2-late या late-interaction मॉडेल्सच्या संग्रहासह या कुटुंबाचा विस्तार करत आहोत. अधिक मजबूत retrieval क्षमता यांसोबतच, ही मॉडेल्स तीन मुख्य वैशिष्ट्ये एकत्र करणारी पहिली आहेत:

• Multi-vector representations. प्रत्येक इनपुटला एका एकमेव vector मध्ये संकुचित करण्याऐवजी, ही मॉडेल्स अधिक सूक्ष्म query-document तुलना करण्यासाठी token-level vectors राखून ठेवतात. यामुळे queryचे वेगवेगळे भाग दस्तऐवजाच्या वेगवेगळ्या भागांशी जुळू शकतात, आणि विशेषतः multimodal retrieval साठी उपयुक्त असलेली तपशीलवार माहिती जपली जाते.
• टेक्स्ट आणि इमेज दोन्ही modalities साठी समर्थन. आमच्या मागील मॉडेल्सच्या text-to-text retrieval क्षमतांव्यतिरिक्त, ही नवीन मॉडेल्स text-to-image retrieval हाताळतात, ज्यामुळे OCR किंवा parsed textची गरज न पडता ती थेट rendered PDF pages शोधू शकतात.
• एक shared embedding space. आम्ही वेगवेगळ्या quality, latency, आणि compute requirementsना समर्थन देण्यासाठी 0.6B आणि 9B असे दोन model sizes रिलीज करत आहोत. प्रत्येक स्वतंत्रपणे वापरता येतो, पण shared embedding space मुळे लहान मॉडेलला मोठ्या मॉडेलने तयार केलेल्या indexवर query करण्याचीही परवानगी मिळते, ज्यामुळे उच्च-गुणवत्तेच्या document embeddingsना स्वस्त, जलद query-time inference सोबत एकत्र करता येते.

हे नवीन मॉडेल्स विविध व्हिजन आणि टेक्स्ट रिट्रीव्हल बेंचमार्क्सवर, तसेच एजंटिक प्रश्नोत्तर कार्यांवर अत्याधुनिक निकाल साध्य करतात. विशेष म्हणजे, आघाडीचा व्हिज्युअल डॉक्युमेंट रिट्रीव्हल बेंचमार्क असलेल्या ViDoRe (V3) वर आमचे 0.6B मॉडेल पाचपट सक्रिय पॅरामीटर्स असलेल्या मॉडेल्सची बरोबरी करते. दोन्ही मॉडेल्स Hugging Face वर सार्वजनिकरित्या उपलब्ध आहेत. आमच्या तांत्रिक अहवालात कार्यपद्धती आणि मूल्यमापन निकालांविषयी अधिक तपशील दिले आहेत.

सिंगल vectors पासून late interaction पर्यंत

Retrieval प्रणालींना कार्यक्षमते आणि queries व documents यांच्यातील interactionच्या खोलीमध्ये समतोल साधावा लागतो. Dense embedding मॉडेल्स प्रत्येक query आणि document स्वतंत्रपणे encode करतात, ज्यामुळे त्यांची cheap inner product द्वारे तुलना करता येते. यामुळे अब्जावधी दस्तऐवजांवर approximate nearest-neighbor (ANN) search व्यवहार्य ठरते. दुसऱ्या टोकाला, cross-encoders query आणि document एकत्र प्रक्रिया करतात, अधिक समृद्ध interaction सक्षम करतात पण प्रत्येक candidate साठी स्वतंत्र forward passची गरज पडते. प्रत्येक search साठी मोठ्या दस्तऐवज-संग्रहावर ही गणना लागू करणे अत्यंत महागडे ठरते, म्हणून cross-encoders सामान्यतः retrieve केलेल्या थोड्या candidate setच्या rerankingपुरते मर्यादित असतात.

Dense embeddingsच्या मर्यादा

संपूर्ण दस्तऐवज एका fixed-size vector मध्ये मांडल्याने माहितीचा bottleneck तयार होतो. दस्तऐवज जितके लांब आणि जितक्या अधिक विषयांवर पसरतात, तितके modelला समान vector मध्ये अधिक सामग्री संकुचित करावी लागते, ज्यामुळे queryशी संबंधित सर्व काही जपणे कठीण होते. Chunking हा दबाव कमी करू शकते, पण त्यामुळे दस्तऐवज तुकड्यांत विभागला जातो आणि एकत्र अर्थ प्राप्त होणारी माहिती वेगळी पडू शकते; हा मुद्दा आम्ही आमच्या contextual embedding model द्वारेही हाताळतो. Multimodal settings मध्ये हा bottleneck अधिक तीव्र होतो, कारण प्रतिमांची माहितीघनता आणखी जास्त संकुचनाची मागणी करते.

Single-vector dense retrieval मध्ये प्रत्येक comparison दोन vectors मधील inner product इतकाच राहतो, त्यामुळे scoring functionची अभिव्यक्तीक्षमता मर्यादित होते. निश्चित embedding dimension आणि पुरेसा मोठा corpus असताना, प्रशिक्षण काहीही असले तरी query-document जोड्यांवरील scoresचे काही नमुने तयार करणे अशक्य ठरते. LIMIT benchmark ही सैद्धांतिक चिंता single-vector retrieval साठी एक ठोस stress testमध्ये रूपांतरित करते.

लेट-इंटरॅक्शन पुनर्प्राप्ती (Late-interaction retrieval)

Late-interaction मॉडेल्स स्वस्त dense embedding मॉडेल्स आणि अधिक अभिव्यक्तीक्षम cross-encoders यांच्यामधील जागा व्यापतात. Dense मॉडेल्सप्रमाणे, ती documentला queryपासून स्वतंत्रपणे encode करतात, ज्यामुळे document representations offline compute करता येतात. तथापि, प्रत्येक input एका single vectorमध्ये कमी करण्याऐवजी, ती अनेक vectors राखून ठेवतात आणि queryची दस्तऐवजाशी तुलना करताना अधिक समृद्ध scoring function वापरतात.

आमची pplx-embed-v2-late मॉडेल्स ColBERT-style architecture वापरतात, आणि इनपुटमधील प्रत्येक tokenसाठी 128-dimensional embeddings आउटपुट करतात. आम्ही query-document जोड्यांचे scoring MaxSim वापरून करतो; प्रत्येक query tokenसाठी, model सर्वाधिक score मिळवणारा document token निवडतो आणि अंतिम score तयार करण्यासाठी tokenप्रमाणे maximum similaritiesची बेरीज करतो. यामुळे queryचे वेगवेगळे भाग दस्तऐवजाच्या वेगवेगळ्या भागांशी जुळू शकतात, आणि अधिक मजबूत token matches scoreमध्ये अधिक भर घालतात.

विस्तृत करा

ही अतिरिक्त अभिव्यक्ती अधिक साठवणूक आणि candidate-scoring खर्चासह येते. Dense retrieval प्रत्येक दस्तऐवजासाठी एक vector साठवते आणि एका inner product ने candidate चे स्कोअरिंग करते; late interaction दस्तऐवज tokens साठी vectors साठवते आणि अनेक token-to-token similarities मूल्यांकित करते. दस्तऐवजाच्या लांबीबरोबर खर्च वाढतो, त्यामुळे late interaction ला one-vector ANN retrieval पेक्षा वेगळी indexing आणि serving trade-off आवश्यक असते. त्याबदल्यात, quality-sensitive corpora साठी ती अधिक समृद्ध first-stage retrieval प्रदान करते आणि मोठ्या web-scale retrieval pipeline मध्ये later stage म्हणूनही काम करू शकते.

एक मॉडेल, अनेक modalities

Interactionची ही सुधारित खोली long-context, agentic आणि out-of-domain retrieval यांसारख्या विविध कार्यांसाठी अतिशय उपयुक्त ठरते, हे दाखवले गेले आहे. Multimodal retrieval मध्ये हा फरक विशेषतः ठळकपणे दिसतो, जसे ViDoRe(V3) leaderboardवर ColPali मॉडेल्सची मोठी आघाडी दाखवते.

वास्तविक-जगातील corpora केवळ स्वच्छ मजकुराने बनलेले नसतात. ती PDFs, slide decks, screenshots, scanned pages, charts, आणि tables स्वरूपात येतात. पारंपरिक pipeline या दस्तऐवजांचे parsing करते, OCR किंवा captioning लागू करते, आणि तयार झालेला मजकूर शोधते; हे महागडे आणि माहिती-हानीकारक असते: त्यातून OCR चुका येऊ शकतात आणि layout, table structure, figures, तसेच spatial relationships गमावले जातात. Visual document search तो टप्पा वगळते, rendered page थेट representation spaceमध्ये projected करते जिथे textual queries त्याचा शोध घेऊ शकतात.

आमचे मॉडेल्सचे नवीन कुटुंब multi-modal search साठी multi-vector मॉडेल्सच्या मजबूत कामगिरीवर आधारित आहे आणि सर्वाधिक वापरल्या जाणाऱ्या document search benchmark ViDoRe(V3) वर लहान मॉडेल्ससाठी Pareto frontier पुढे नेत आहे. आम्ही अपेक्षा करतो की document renderings हे visual inputचे सर्वात सामान्य रूप असेल, तरी आमची मॉडेल्स scenic photographsसारख्या natural images वर semantic image searchलाही समर्थन देतात.

Interoperable मॉडेल्सचे प्रशिक्षण

Search मूलत: asymmetric आहे: indexing आणि query encoding यांच्या operational constraints वेगवेगळ्या असतात. Indexing offline चालते आणि parallelize करता येते, म्हणून त्याचा compute cost अनेक भविष्यातील searchesमध्ये विभागला जातो. Query encoding प्रत्येक विनंतीसाठी online चालते, त्यामुळे ते latency-sensitive असते आणि कधी कधी serving किंवा edge-device मर्यादांच्या अधीन असते. आमचे model family या asymmetryचा उपयोग करते, retrieval pipelineच्या प्रत्येक बाजूस अनुरूप sizes देत.

आम्ही प्रथम 18B teacherचे contrastively प्रशिक्षण देतो, आणि नंतर त्याचे 9B आणि 0.6B studentsमध्ये स्वतंत्रपणे distillation करतो. प्रत्येक studentला केवळ teacherचे ranking distribution पुनरुत्पादित करण्यासाठी प्रशिक्षित करण्याऐवजी, आम्ही LEAF-style representation distillation वापरतो: प्रत्येक input tokenसाठी, आम्ही studentचे output embedding teacherच्या embeddingशी align करतो. Representation-स्पेसमधील distillation याआधी dense, single-vector मॉडेल्ससाठी वापरले गेले आहे, परंतु आम्ही ते late interactionपर्यंत विस्तारित करतो, जिथे alignment target हा राखून ठेवलेल्या प्रत्येक tokenसाठी एक vector असतो.

परिणामी, दोन्ही released checkpoints समान multi-vector embedding space सामायिक करतात. यामुळे cross-model retrieval शक्य होते, आणि अतिरिक्त deployment पर्याय उपलब्ध होतात.

• कमाल गुणवत्ता: documents आणि queries 9B मॉडेलने encode करा.
• कमाल कार्यक्षमता: 100% local inference साठी documents आणि queries 0.6B मॉडेलने encode करा
• Low-latency retrieval: corpus index 9B model सह build करा, मग index-time computation चा लाभ घेण्यासाठी live queries 0.6B model ने encode करा, आणि querying जलद ठेवा.
• Local–cloud retrieval: private local documents किंवा live queries 0.6B मॉडेलने on-device encode करा, आणि त्या representationsना cloudमध्ये hosted 9B indexमधील परिणामांसह compare किंवा merge करा.

latency-sensitive settingsसाठी, आम्ही 0.6B मॉडेलला हलके query encoder म्हणून डिझाइन केले आहे, जे edge devicesवरही चालू शकते. Qwen3.5-0.8B पासून सुरुवात करून, आम्ही त्याचा 24-layer text tower 12 layersपर्यंत prune केला, ज्यामुळे हा tower 498M वरून 240M non-embedding parametersपर्यंत कमी झाला. परिणामी मॉडेलमध्ये एकूण 594M parameters आहेत, पण त्याचा nominal size serving costपेक्षा जास्त दर्शवतो: 100M image encodingसाठी वापरले जातात, आणि 254M token-embedding tableमध्ये असतात, ज्याचा runtimeवर फारसा परिणाम होत नाही. Text encodingसाठी फक्त सुमारे 240M parameters सक्रिय असतात आणि image encodingसाठी 340M, ज्यामुळे 9B indexशी सुसंगतता राखूनही या मॉडेलला खूपच लहान मॉडेलच्या serving costसह चालवता येते.

आम्ही 27B backboneमधून 18B teacher तयार करण्यासाठीही तीच प्रक्रिया लागू केली, ज्यामुळे teacherचे distillation खूपच स्वस्त झाले आणि त्याने दिलेला signal कमकुवत झाला नाही.

बहुभाषिक, multimodal, uncontaminated training data

आम्ही दोन्ही मॉडेल्सना 46 भाषांमधील 594 datasetsमधून घेतलेल्या 186 दशलक्ष query-document pairsच्या datasetवर प्रशिक्षण देतो. या pairsपैकी 88.3% text-to-text, 8.3% text-to-image, आणि 3.4% text-to-visual-document pairs आहेत. Datasetच्या आकाराच्या प्रमाणात sampling करण्याऐवजी, आम्ही प्रत्येक datasetला sampling weight देतो, ज्यामुळे 56.5%, 30.9%, आणि 12.6% अशी अधिक संतुलित training mixture मिळते, अनुक्रमे.

आमचे training data तयार करताना, आम्ही ज्यावर मूल्यांकन करतो अशा benchmarksशी संबंधित कोणतेही datasets वगळतो, जेणेकरून benchmark scores कृत्रिमरीत्या वाढवून न दाखवता आमचे परिणाम प्रामाणिकपणे सादर होतील. या निर्णयासोबत असा trade-off आहे की आम्ही वगळण्यासाठी निवडलेल्या काही datasetsमध्ये उच्च-गुणवत्तेचा डेटा आहे जो benchmarkव्यतिरिक्त इतर कार्यांवर आमच्या मॉडेलची कामगिरी सुधारू शकतो. शेवटी, आम्ही तो खर्च स्वीकारण्याचा निर्णय घेतला: विकासादरम्यान आम्हाला विश्वासार्ह संख्या अधिक उपयुक्त वाटतात, आणि मॉडेल्सची तुलना करताना वापरकर्त्यांनाही.

मूल्यांकन

आम्ही दोन्ही मॉडेल्सचे text, visual-document, mixed-image, आणि agentic retrieval या सर्वांवर मूल्यांकन करतो. दोन्ही मॉडेल्स Q2D-Web आणि BrowseComp+ वर evaluated baselinesपेक्षा चांगली कामगिरी करतात, आणि visual-document retrieval तसेच MADQA वर मजबूत निकाल साध्य करतात.

Text retrieval

आम्ही text-to-text retrievalचे तीन benchmarksवर मूल्यांकन करतो:

• डोमेन-विशिष्ट बेंचमार्क्स: 72 MTEB-style tasksचा संग्रह, ज्यात पाच डोमेन्समध्ये 55 tasks (finance, legal, health, conversation, tech) आणि 17 miscellaneous multilingual tasks आहेत. या संग्रहात FinQA, AILACasedocs आणि XLSum सारखी कार्ये समाविष्ट आहेत. वर वर्णन केल्याप्रमाणे, हे datasets आमच्या training dataमध्ये नाहीत.
• Q2D-Web: आमचा सुमारे 70,000 agent-reformulated search queriesचा web-scale retrieval benchmark, जो production search trafficमधून घेतला आहे, आणि 190M web documentsच्या corpusवर आधारित आहे. Productionसारखी queries आणि मोठ्या प्रमाणावरील corpus असल्यामुळे, हा benchmark इतर उपलब्ध retrieval benchmarksपेक्षा वास्तविक-जगातील web retrievalला अधिक जवळचे settingमध्ये retrieval performance मोजतो.
• ViDoRe(V3) Markdown: ViDoRe(V3) हा सामान्यतः text-to-visual-document retrieval task असतो, पण Markdownमध्ये parsed केलेल्या corpusच्या आवृत्तीचा वापर करून त्याचे text task म्हणूनही मूल्यांकन करता येते, ज्यामुळे image आणि text या दोन्ही modalitiesमध्ये information-rich document retrievalचे मूल्यांकन करता येते.

Q2D-Web वगळता आम्ही कार्यप्रदर्शन nDCG@10 वापरून मोजतो; Q2D-Web वर मात्र benchmarkचा focus first-stage web-retrieval scenarioवर असल्याने आम्ही Recall@1000 अहवालित करतो. आमच्या संपूर्ण मूल्यांकनात, आम्ही विविध size classesमधील उद्योगातील आघाडीच्या embedding मॉडेल्सशी तुलना करतो. 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 म्हणून काम करतात. TopKने प्रकाशित केलेल्या निकालांसाठी आम्ही TopKच्या अलीकडेच प्रसिद्ध झालेल्या topk-embed-v1 late-interaction मॉडेल्सशीही तुलना करतो. ViDoRe(V3) scores त्यांच्या model cardsमधून 128 dimensionsवर घेतले आहेत, जे आमच्या token embeddingsच्या widthशी जुळते; Q2D-Web score आमच्या leaderboardवरून घेतला आहे.

डोमेन-विशिष्ट बेंचमार्क्सवर, आमची 9B आणि 0.6B मॉडेल्स सरासरी अनुक्रमे 81.3% आणि 78.0% गुण मिळवतात. आमचे 9B मॉडेल आम्ही मूल्यांकन केलेल्या सर्व मॉडेल्समध्ये सर्वाधिक गुण मिळवते, आणि पुढील सर्वोत्तम मॉडेलला 1.6pp ने मागे टाकते. आमचे 0.6B मॉडेल इतर उच्च-गुणांकित मॉडेल्सशी स्पर्धात्मक आहे, आणि gemini-embedding-2 पेक्षा फक्त 0.3pp मागे आहे. महत्त्वाचे म्हणजे, आम्ही या बेंचमार्क कार्यांसाठीच्या कोणत्याही डेटावर प्रशिक्षण दिलेले नाही, त्यामुळे हे domain-specific बेंचमार्क्स दाखवतात की आमची embedding मॉडेल्स नवीन डोमेन्समध्ये सामान्यीकरण करू शकतात.

विस्तृत करा

ViDoRe(V3) Markdown taskवर आमच्या 0.6B मॉडेलची सापेक्ष ताकद आणखी जास्त आहे; त्याचा 61.2% गुण आमच्या 9B मॉडेलखेरीज सर्व इतर मॉडेल्सना मागे टाकतो, ज्याने 64.7% गुण मिळवले. पुढील सर्वोत्तम external modelने 60.6% गुण मिळवले, आणि पुढील सर्वोत्तम sub-1B model, topk-embed-v1-0.8b, आमच्या 0.6B मॉडेलपेक्षा 4.3pp मागे होता.

विस्तृत करा

Q2D-Web वर, relevance तीन judgment sets मधून येते: एजंटने उद्धृत केलेली दस्तऐवज (Citation), आमच्या production retrieval system ने रँक केलेली दस्तऐवज (Web), आणि या दोन्हींच्या संघासोबत unlabeled दस्तऐवजांच्या LLM judgments ने विस्तारित केलेला संघ (Combined). सर्व तीन judgment sets वर pplx-embed-v2-late ची दोन्ही मॉडेल्स प्रत्येक बेसलाइनपेक्षा आघाडीवर आहेत. आम्ही combined judgments वर लक्ष केंद्रित करतो, कारण Citation आणि Web sets आमच्या स्वतःच्या प्रणालींनी आधीच पुढे आणलेल्या परिणामांमधून तयार केलेले आहेत आणि त्यामुळे त्यांच्या प्रमाणे रँक करणाऱ्या मॉडेल्सना अनुकूल ठरतात; Combined मध्ये जोडलेले LLM judgments त्या दस्तऐवजांचा समावेश करतात जे दोन्ही प्रणालींनी शोधले नाहीत. त्या सेटवर, आमची 9B आणि 0.6B ही दोन्ही मॉडेल्स सर्व प्रतिस्पर्ध्यांना मागे टाकतात, अनुक्रमे 74.8% आणि 73.6% गुण मिळवतात, मागील सर्वोत्तम 69.3% गुणांच्या तुलनेत.

विस्तृत करा

दृश्य पुनर्प्राप्ती

आमचा प्राथमिक दृश्य पुनर्प्राप्ती बेंचमार्क म्हणजे ViDoRe(V3)चा मानक सार्वजनिक उपसंच, जिथे कॉर्पस Markdown रूपांतरणाऐवजी रेंडर केलेल्या पृष्ठ प्रतिमांचा समावेश करतो. आम्ही दोन आघाडीच्या dense vision-language मॉडेल्स, qwen3-vl-embed-8b आणि gemini-embedding-2, तसेच topk-embed-v1 late-interaction मॉडेल्सशी तुलना करतो. याशिवाय, Tencentची EVIE मॉडेल्स आणि NVIDIAची Nemotron ColEmbed V2 मॉडेल्स ही प्रतिमा पुनर्प्राप्ती कार्यांसाठी विशेषतः प्रशिक्षित केलेली “vision-only” multi-vector बेसलाईन्स आहेत.

आमची दोन्ही मॉडेल्स vision-language मॉडेल्ससाठी state of the art कामगिरी साध्य करतात. आमचे 9B मॉडेल सरासरी 65.2% गुण मिळवते, आणि केवळ EVIE याच्या मागे राहते. आमचे 0.6B मॉडेल 62.3% गुण मिळवते, topk-embed-v1-2b च्या पुढे आणि बाह्य बेसलाईन्समध्ये केवळ खूप मोठ्या EVIE आणि nemotron-colembed-v2-8b यांच्या मागे राहते.

विस्तृत करा

मॉडेलच्या आकाराच्या संदर्भात आमचे 0.6B मॉडेल विशेषतः स्पर्धात्मक आहे. ते तुलनात्मक आकाराच्या सर्व मॉडेल्सपेक्षा पुढे आहे आणि nemotron-colembed-v2-8b च्या 1.2pp आत आहे, तरी प्रतिमा इनपुटसाठी केवळ 340M parameters सक्रिय करते. आमची मॉडेल्स token प्रति 128-dimensional embeddings तयार करतात, तर EVIE-4.5B साठी 2,048 आणि EVIE-8B व nemotron-colembed-v2-8b साठी 4,096 आहेत. storage costs मधील हा फरक या मॉडेल्स प्रत्यक्षात वापरण्यास कितपत व्यवहार्य आहेत यावर मोठा परिणाम करू शकतो.

विस्तृत करा

आम्ही MIRACL-Vision वरही visual retrievalचे मूल्यांकन करतो, ज्या benchmarkचा corpus wikipedia लेखांच्या screenshotsचा समावेश करतो, आणि PPLX-Q2I वर, जो visual documents आणि natural images दोन्हींचा समावेश करणारा एक internal benchmark आहे. 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. आम्ही PPLX-Q2I वर EVIE-8B किंवा Nemotron ColEmbedचे मूल्यांकन केले नाही, कारण त्यांच्या default output dimensionalitiesवर (Nemotron ColEmbed 4B साठी 2,560 आणि Nemotron ColEmbed 8B आणि EVIE-8B साठी 4,096) इतक्या मोठ्या corpusचे indexing करणे अव्यवहार्य होते.

ViDoRe(V3) वरील कामगिरीप्रमाणेच, आमचे 0.6B मॉडेल खूप मोठ्या मॉडेल्सशी स्पर्धात्मक आहे, आणि MIRACL-Vision वर qwen3-vl-embed-8b पेक्षा फक्त 1pp मागे आहे. आमचे 9B मॉडेल gemini-embedding-2 वगळता इतर सर्व मॉडेल्सपेक्षा चांगली कामगिरी करते.

PPLX-Q2I वर, आमची दोन्ही मॉडेल्स qwen3-vl-embedding-8b ला 9pp पेक्षा अधिक फरकाने मागे टाकतात, आणि आमचे 9B मॉडेल gemini-embedding-2 च्या मागे फक्त 2pp आहे. नैसर्गिक प्रतिमा तसेच visual documents असलेल्या corporaवरही आमचे निकाल स्पर्धात्मक राहतात, त्यामुळे ViDoRe(V3) वर फायदेशीर ठरणारी multi-vector representations सामान्य image searchच्या किमतीवर मिळत नाहीत.

विस्तृत करा

Cross-model retrieval

मागील विभागांमधील निकाल प्रत्येक मॉडेलचे मूल्यांकन त्या कॉर्पसवर करतात जो त्याने स्वतः embed केला आहे. सामायिक embedding space याचा अर्थ असा की ही अट आवश्यक नाही: 9B मॉडेलने अनुक्रमित केलेला कॉर्पस 0.6B मॉडेलने embedded केलेल्या क्वेरीजसह शोधता येतो. आम्हाला अपेक्षा आहे की बहुतेक production deployments हीच संरचना वापरतील, कारण indexing हा एकदाच होणारा खर्च आहे जो कॉर्पसच्या आयुष्यभर पसरतो, तर query embedding प्रत्येक विनंतीच्या latency-critical मार्गावर चालतो.

जी deployment query timeला 9B मॉडेल चालवू शकत नाही, तिने अन्यथा 0.6B मॉडेलनेही indexing करावी लागेल, त्यामुळे symmetric 0.6B configuration हा संबंधित comparison point ठरतो. आम्ही वर वापरलेल्या 72 domain-specific benchmarksवर आणि ViDoRe v3 image retrievalवर मूल्यांकन करतो. Queries pplx-embed-v2-late-0.6b ने embed केल्या जातात, आणि आम्ही केवळ corpusला कोणी embed केले ते बदलतो.

9B मॉडेलने indexing करणे हे निश्चितच चांगले आहे. डोमेन-विशिष्ट बेंचमार्क्सवर, asymmetric configuration सरासरी 1.6ppची वाढ देते. ViDoRe v3 image retrievalवर, ते 63.5% गुण मिळवते, 0.6B मॉडेल दोन्ही बाजूंनी वापरल्यावर मिळालेल्या 62.3% च्या तुलनेत, म्हणजे 1.2 टक्के गुणांची वाढ. Query-encoding खर्च symmetric 0.6B आणि asymmetric configurationsमध्ये बदलत नाही, कारण दोन्ही ठिकाणी query encode करण्यासाठी तेच 0.6B मॉडेल वापरले जाते; अतिरिक्त document-encoding खर्च indexing timeला येतो.

दोन्ही बाजूंनी 9B मॉडेल चालवणे आणखी चांगलेच आहे, आणि डोमेन-विशिष्ट बेंचमार्क्सवर सरासरी 81.3% मिळवते. त्यामुळे asymmetric configuration मजकुरावरील दोन मॉडेल्समधील quality differenceचा अंदाजे अर्धा भाग अतिरिक्त query-encoding खर्चाशिवाय परत मिळवते. कोणते configuration निवडायचे हे query timeला 9B मॉडेल परवडते का यावर अवलंबून आहे; जिथे ते शक्य नाही, तिथे asymmetric setup त्याच्या फायद्याचा मोठा भाग मिळवतो.

विस्तृत करा

Agentic retrieval

Agentic retrieval हे आणखी एक setting आहे जिथे multi-vector embeddings विशेषतः मजबूत ठरतात. BrowseComp+ मध्ये, एक LLM (GPT-OSS-120B आमच्या बाबतीत) embedding modelचा वापर करून जटिल user queryसाठी संबंधित माहिती शोधण्यासाठी corpus शोधते, आणि दुसरे LLM दिलेले उत्तर ground truthशी जुळते का हे ठरवते. आमचे 9B मॉडेल 64.0% accuracy साध्य करते, पुढील सर्वोत्तम ColBERT मॉडेलपेक्षा 4.9pp आणि पुढील सर्वोत्तम dense मॉडेलपेक्षा 8.7pp अधिक, आणि आमच्या 0.6B मॉडेलखेरीज इतर कोणत्याही मॉडेलपेक्षा कमी searches जारी करते. 0.6B मॉडेल आमच्या familyबाहेरील प्रत्येक मॉडेलपेक्षाही पुढे आहे.

विस्तृत करा

MADQA 800 heterogeneous real-world PDFsवर agentic question-answering तपासते, जे 18,000 पेक्षा अधिक pages व्यापतात, आणि 500 मानवी-लेखित प्रश्नांचा समावेश करते ज्यांची उत्तरे सामान्य ज्ञानातून देता येत नाहीत. एक agent (आमच्या बाबतीत Gemini 3.5 Flash) परीक्षणाखालील retriever वापरून संग्रह शोधतो, आणि annotated evidence pagesच्या तुलनेत answer accuracy आणि page F1 वर गुणांकन केले जाते. आमचे 9B मॉडेल retrieversमध्ये 92.4% accuracyसह नवीन state of the art प्रस्थापित करते, Mixedbreadचा retriever वापरणाऱ्या त्याच agentपेक्षा 3.5pp पुढे; आमचे 0.6B मॉडेल 90.1% पर्यंत पोहोचते. आम्ही हेही नमूद करतो की आमचा retriever Mixedbread Agentic Searchविरुद्ध स्पर्धात्मक निकाल मिळवतो, जो त्यांच्या search systemमध्ये एक search sub-agent वापरतो आणि मुख्य agentमधून प्रत्येक कॉलसाठी अनेक searchesची योजना करतो व चालवतो (93.4%, आमच्या confidence intervalच्या आत).

विस्तृत करा

सुरुवात करा

आमची 0.6B आणि 9B ही दोन्ही मॉडेल्स Hugging Face वर उपलब्ध आहेत आणि sentence-transformers >= 6.0.0 तसेच transformers >= 5.4.0 शी out of the box सुसंगत आहेत. पुढील तांत्रिक तपशील आणि संपूर्ण मूल्यांकन निकाल या वर्षाच्या उत्तरार्धात तांत्रिक अहवालात प्रकाशित केले जातील.

आम्ही सध्या आमच्या डेन्स एम्बेडिंग मॉडेल्सची पुढील पिढी प्रशिक्षित करत आहोत आणि 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}
}