Perplexity Decider

हम Decider v1.3 और Decider Flash v1.3 रिलीज़ कर रहे हैं, जो हमारे पिछले निर्णय मॉडल v1, v1.1, v1.2 और Flash v1.2 के उत्तराधिकारी हैं।

Decider Flash v1.3 एक छोटा मॉडल है जिसे Decider v1.3 से डिस्टिल किया गया है। दोनों मॉडल Apache लाइसेंस के तहत Hugging Face पर, OpenRouter के ज़रिए और Perplexity Decisions API पर उपलब्ध हैं।

Perplexity Decider, Jev से प्रेरित है, जो TypeSafe AI का System One Model है। यह क्रमबद्ध या अक्रमबद्ध लेबल के साथ बाइनरी और मल्टी-क्लास वर्गीकरण को सपोर्ट करता है, और ऐसी प्रायिकताएँ लौटाता है जिनका उपयोग एप्लिकेशन इनपुट को वर्गीकृत, रूट, रैंक और मूल्यांकित करने के लिए कर सकते हैं।

दोनों v1.3 मॉडल द्विदिश अटेंशन, बेहतर ढंग से क्यूरेट किए गए ट्रेनिंग डेटा और परिष्कृत ट्रेनिंग रेसिपी के ज़रिए टेक्स्ट और विज़न कार्यों की व्यापक रेंज में प्रदर्शन और मज़बूती बेहतर करते हैं। हम locate भी पेश कर रहे हैं, जो एक नई सुविधा है और नेम्ड एंटिटी रिकग्निशन, व्यक्तिगत जानकारी की पहचान और एक्सट्रैक्टिव प्रश्न-उत्तर कार्यों के लिए चयनित सामग्री को हाइलाइट करती है।

इस पोस्ट में, हम बताते हैं कि हम Decider को कैसे ट्रेन करते हैं और उसका मूल्यांकन कैसे करते हैं, और साझा करते हैं कि हम Perplexity में आंतरिक रूप से इसका उपयोग कैसे करते हैं।

निर्णय मॉडल क्या है?

निर्णय मॉडल एक सामान्य-उद्देश्य वाला क्लासिफ़ायर है। आप इसे एक इनपुट और प्रश्नों का एक सेट देते हैं, जिनमें से हर प्रश्न के अपने संभावित उत्तर होते हैं। हर प्रश्न के लिए, यह उत्तरों पर एक प्रायिकता वितरण लौटाता है। यह 3 प्रकार के प्रश्नों को सपोर्ट करता है:

• हाँ / नहीं: बाइनरी निर्णय।
• बहुविकल्पीय: कस्टम मल्टी-क्लास लेबल।
• स्कोर: क्रमबद्ध स्तर।

निर्णय मॉडल वर्गीकरण और स्कोरिंग के कई तरह के कार्यों को सपोर्ट करते हैं:

• आउटपुट का मूल्यांकन: स्रोत-निष्ठा, गुणवत्ता और सुरक्षा का आकलन करना।
• रूटिंग: कठिनाई के आधार पर अनुरोधों को छोटे या बड़े मॉडल की ओर भेजना।
• मॉडरेशन और सुरक्षा: टूल आउटपुट में हानिकारक सामग्री, फ़िशिंग और प्रॉम्प्ट इंजेक्शन का पता लगाना।
• फ़िल्टरिंग और टैगिंग: सामग्री के बड़े संग्रहों को व्यवस्थित करना।
• रिट्रीवल और रीरैंकिंग: प्रासंगिकता के आधार पर खोज परिणामों को स्कोर करना।

इनमें से कई कार्य पहले LLM जैसे जनरेटिव मॉडल संभालते थे, भले ही उनमें फ़्री-फ़ॉर्म टेक्स्ट जनरेशन की आवश्यकता नहीं होती। निर्णय मॉडल LLM और कार्य-विशिष्ट क्लासिफ़ायर के बीच की श्रेणी में आते हैं। वे एक ही इनपुट के बारे में कई प्रश्नों के लिए एक ही फ़ॉरवर्ड पास में प्रायिकताएँ लौटाते हैं, जिससे टोकन-दर-टोकन उत्तर जनरेट करने की ज़रूरत नहीं पड़ती और प्रश्नों के बीच गणना साझा होती है। कार्य-विशिष्ट क्लासिफ़ायर के विपरीत, वे प्राकृतिक भाषा प्रॉम्प्ट के ज़रिए नए कार्य संभाल सकते हैं; यह लचीलापन एक साझा प्रश्न-उत्तर फ़ॉर्मैट में विविध कार्यों पर प्रशिक्षण से सीखा जाता है।

ट्रेनिंग

जनरेटिव LLM को निर्णय मॉडल में बदलना

हम मज़बूत जनरेटिव LLM बैकबोन को अनुकूलित करके Decider बनाते हैं। इस अनुकूलन को समझाने के लिए, हम पहले बताते हैं कि किसी अनुरोध को कैसे दर्शाया जाता है। जैसा कि नीचे दिखाया गया है, एक अनुरोध में एक साझा संदर्भ (स्टेट) और कई प्रश्न होते हैं। स्टेट का उपयोग सभी प्रश्नों द्वारा दोबारा किया जाएगा।

उदाहरण के लिए, एक दस्तावेज़ और उसका सारांश दिए जाने पर, एक ही अनुरोध में पूछा जा सकता है कि क्या सारांश दस्तावेज़ को सटीक रूप से प्रस्तुत करता है और क्या वह किसी विशेषज्ञ के लिए है या सामान्य पाठकों के लिए। स्टेट के बाद, प्रत्येक प्रश्न ब्लॉक में एक प्रश्न और उसके संभावित उत्तर होते हैं, जिनमें से प्रत्येक को A, B या C जैसा पहले से तय लेबल टोकन असाइन किया जाता है। एक विशेष <|marker|> टोकन बताता है कि मॉडल की भविष्यवाणी कहाँ से पढ़नी है। इस स्थिति पर, एक सीखी गई लीनियर आउटपुट लेयर (डिसीज़न हेड) हिडन स्टेट को प्रश्न के उत्तर विकल्पों के स्कोर में मैप करती है, जिन्हें फिर प्रायिकताओं में बदला जाता है।

बड़ा करें

हम आउटपुट लेयर को बेस मॉडल से इनिशियलाइज़ करते हैं, जो सामान्यतः पूरी शब्दावली में से अगले टोकन को स्कोर करती है, और केवल A, B या C जैसे पहले से तय विकल्प टोकन से संबंधित पंक्तियाँ रखते हैं। इसके बाद इस प्रून की गई लेयर को <|marker|> की हिडन स्टेट को उत्तर स्कोर में बदलने के लिए ट्रेन किया जाता है। यह तरीका सभी वर्गीकरण प्रश्नों को कवर करता है, क्योंकि उन सभी को बहुविकल्पीय प्रश्न के रूप में तैयार किया जा सकता है।

ट्रेनिंग के लिए, हम विविध कार्यों (सेंटीमेंट, नेचुरल लैंग्वेज इन्फ़रेंस, इंटेंट डिटेक्शन, एंटिटी मिलान, मॉडरेशन, तथ्य-जाँच, रेटिंग आदि) में फैले सैकड़ों सार्वजनिक डेटासेट लेते हैं और प्रत्येक उदाहरण को ऊपर बताए गए एकीकृत फ़ॉर्मेट में बदलते हैं: एक स्टेट, एक या अधिक प्रश्न, उनके विकल्प और एक टारगेट। यदि हमारे पास गोल्ड लेबल हैं तो टारगेट एकल सही विकल्प हो सकता है, या फिर विकल्पों पर एक प्रायिकता वितरण।

v1.3 में, हम locate पेश कर रहे हैं, जो पहले से तय विकल्पों में से चुनने के बजाय स्टेट से टेक्स्ट निकालता है। locate प्रश्न बताता है कि क्या खोजना है, इसके लिए या तो “स्थान” जैसे छोटे लेबल का उपयोग किया जाता है या “उस शहर का नाम निकालें जहाँ नौकरी स्थित है।” जैसे निर्देश का। मॉडल स्टेट से बिल्कुल मेल खाने वाला टेक्स्ट, उसकी शुरुआती और अंतिम कैरेक्टर स्थितियों के साथ लौटाता है। यदि उसे कोई मिलान नहीं मिलता, तो वह एक खाली सूची लौटाता है।

बड़ा करें

साझा स्टेट के कारण, एक ही अनुरोध में एक ही इनपुट के बारे में locate, वर्गीकरण और स्कोरिंग प्रश्नों को जोड़ा जा सकता है। उदाहरण के लिए, इसमें यह पूछा जा सकता है कि क्या किसी नौकरी के लिए सीनियर-स्तर के अनुभव की आवश्यकता है, और साथ ही आवश्यक कौशल निकाले जा सकते हैं।

द्विदिश अटेंशन: मॉडल को दोनों दिशाओं में पढ़ने देना

हमारे मॉडल मज़बूत प्रीट्रेन्ड जनरेटिव बैकबोन से शुरू होते हैं, जिनका कॉज़ल अटेंशन प्रत्येक टोकन को केवल खुद पर और पिछले टोकन पर ध्यान देने देता है। हमारे एब्लेशन अध्ययनों से पता चला कि बैकबोन की फ़ुल-अटेंशन लेयर्स को द्विदिश बनाने से प्रदर्शन बेहतर होता है, इसलिए हम यह डिज़ाइन अपनाते हैं ताकि प्रत्येक टोकन पूरे इनपुट से संदर्भ शामिल कर सके।

द्विदिश अटेंशन एक और डिज़ाइन विकल्प सामने लाता है: स्टेट और प्रश्नों को आपस में कैसे इंटरैक्ट करना चाहिए? हमने तीन अटेंशन पैटर्न पर विचार किया, जिनका प्रदर्शन, उत्तर की स्थिरता और कैश के दोबारा उपयोग पर अलग-अलग असर होता है:

• हर चीज़ हर चीज़ को देखती है (v1.2): स्टेट और सभी प्रश्नों को पूर्ण द्विदिश अटेंशन के साथ एक साथ प्रोसेस किया जाता है। स्टेट पर होने वाली गणना साझा होती है, लेकिन किसी एक प्रश्न का उत्तर इस बात पर निर्भर करके बदल सकता है कि और क्या पूछा गया है।
• पृथक प्रश्न (v1.3): स्टेट सभी प्रश्नों पर ध्यान देता है, जबकि प्रत्येक प्रश्न केवल स्टेट और अपने टोकन पर ध्यान देता है। प्रश्न अब भी साझा स्टेट के ज़रिए अप्रत्यक्ष रूप से एक-दूसरे को प्रभावित कर सकते हैं, लेकिन परिणाम अधिक स्थिर होते हैं।
• पूरी तरह कैश करने योग्य: स्टेट केवल स्वयं पर अटेंड करती है, जबकि प्रत्येक प्रश्न स्टेट और अपने स्वयं के टोकन पर अटेंड करता है। स्टेट प्रश्न से स्वतंत्र होती है और प्रॉम्प्ट कैशिंग का लाभ उठाने के लिए इसे सभी अनुरोधों में दोबारा उपयोग किया जा सकता है। हम डिफ़ॉल्ट रूप से इसका उपयोग नहीं करते, क्योंकि कई कार्यों के लिए स्टेट का प्रश्नों को देख पाना बहुत मायने रखता है, लेकिन थोड़ी-सी फ़ाइन-ट्यूनिंग से किसी मॉडल को इस पर स्विच किया जा सकता है।

अंततः, हमने उनके मज़बूत प्रदर्शन और स्थिरता के कारण पृथक प्रश्नों को चुना।

बड़ा करें

ट्रेनिंग रेसिपी

दोनों मॉडल आकारों के लिए प्रशिक्षण तीन चरणों में होता है। हम पहले Qwen3.8-27B पर आधारित बड़े मॉडल को बड़े डेटासेट पर क्रॉस-एंट्रॉपी का उपयोग करके प्रशिक्षित करते हैं, फिर उसे छोटे Qwen3.5-4B मॉडल में डिस्टिल करते हैं।

पहला चरण जनरलिस्ट ट्रेनिंग है, जिसमें हम बड़े पैमाने के कॉर्पोरा पर मॉडल को पूरी तरह फ़ाइन-ट्यून करते हैं। इस चरण में, हम केवल वही डेटा स्वीकार करते हैं जो मॉडल को हर पहलू में मदद करता है और किसी भी बेंचमार्क के लिए विशिष्ट नहीं है; इसलिए हम किसी भी बेंचमार्क के ट्रेनिंग स्प्लिट को शामिल नहीं करते।

इस जनरलिस्ट मॉडल के प्रशिक्षित हो जाने के बाद, हम LoRA का उपयोग करके दूसरा, अधिक सूक्ष्म चरण चलाते हैं। इस चरण में उपयोग किया जाने वाला डेटा विशिष्ट डोमेन और कार्यों पर केंद्रित होता है। यदि हमें सीमित लाभ दिखते हैं या अन्य कार्यों पर कुछ गिरावट (रिग्रेशन) दिखती है, तो हम वह डेटा पहले चरण के बजाय दूसरे चरण में जोड़ते हैं। हम LoRA का उपयोग इसलिए करते हैं ताकि मॉडल जनरलिस्ट मॉडल से बहुत अधिक न भटके और उन विशिष्ट डोमेन के अनुरूप ढलने के प्रयास में प्रदर्शन खोने का जोखिम न रहे। लक्ष्य बैकबोन के सामान्य ज्ञान को बनाए रखते हुए प्रदर्शन में सुधार करना है। विचलन को अधिक सटीकता से नियंत्रित करने और किसी भी इन-डोमेन लाभ की तुलना में होल्ड-आउट मेट्रिक्स को प्राथमिकता देने के लिए, हम LoRA को बेस मॉडल में वापस मर्ज करते समय एक वेट का भी उपयोग करते हैं।

अंत में, हम एक विज़न-विशिष्ट चरण जोड़ते हैं। दूसरे चरण की तरह, विज़न चरण को भी एक और सूक्ष्म विशेषज्ञता चरण माना जाता है, जिसमें एक LoRA एडेप्टर का उपयोग होता है जिसे एक वेट के साथ बेस मॉडल में वापस मर्ज किया जाता है। कुछ विज़न क्षमताएँ टेक्स्ट प्रदर्शन की कीमत पर आ सकती हैं। चूँकि हम टेक्स्ट पर मॉडल का कहीं अधिक उपयोग देखते हैं, इसलिए हम विज़न मेट्रिक की तुलना में टेक्स्ट मेट्रिक को प्राथमिकता देते हैं।

दोनों टेक्स्ट चरणों के लिए, हम तीन रन के औसत वेट का उपयोग करते हैं, जिनमें से प्रत्येक में अलग रैंडम सीड का उपयोग होता है। हमने पाया कि इससे एकत्रित मॉडल का प्रदर्शन और मज़बूती बेहतर होती है।

अंतिम बड़ा मॉडल प्राप्त हो जाने के बाद, हम छोटे मॉडल पर भी वही तीन-चरणीय प्रशिक्षण प्रक्रिया लागू करते हैं। यहाँ बड़ा मॉडल शिक्षक (टीचर) की भूमिका निभाता है: उसका अनुमानित आउटपुट वितरण गोल्ड लेबल की जगह लेता है, और छोटे मॉडल को इस तरह प्रशिक्षित किया जाता है कि उसके अनुमानों और शिक्षक के अनुमानों के बीच KL डाइवर्जेंस न्यूनतम हो। यह डिस्टिलेशन उद्देश्य समान प्रशिक्षण डेटा पर क्रॉस-एंट्रॉपी से बेहतर प्रदर्शन करता है। हालाँकि समर्पित प्रशिक्षण डेटा वाले बेंचमार्क पर क्रॉस-एंट्रॉपी बेहतर प्रदर्शन करता है, लेकिन होल्ड-आउट डेटा पर यह उतना अच्छा सामान्यीकरण नहीं कर पाता। हमारी परिकल्पना है कि डिस्टिलेशन शिक्षक के आउटपुट वितरण को, जिसमें गैर-गोल्ड विकल्पों पर उसका विश्वास स्तर भी शामिल है, बेहतर ढंग से स्थानांतरित करता है, जबकि क्रॉस-एंट्रॉपी बेंचमार्क-विशिष्ट प्रशिक्षण वितरण पर ओवरफ़िटिंग को बढ़ावा देता है। इसलिए हम KL-आधारित डिस्टिलेशन उद्देश्य अपनाते हैं।

ट्रेन-टेस्ट संदूषण को कम करने के लिए, हम ऐसे सभी प्रशिक्षण नमूने हटा देते हैं जो हमारे द्वारा उपयोग किए जाने वाले किसी भी मूल्यांकन से ओवरलैप कर सकते हैं। यह महत्वपूर्ण है, क्योंकि कुछ सार्वजनिक प्रशिक्षण डेटासेट में कुछ मूल्यांकन डेटासेट के बड़े हिस्से शामिल होते हैं। हम व्यापक पूर्वाग्रह (बायस) ऑडिट भी करते हैं और पाए गए पूर्वाग्रहों को हटाते हैं, ताकि यह सुनिश्चित हो सके कि हमारे लाभ विश्वसनीय हैं और केवल सीखे गए पूर्वाग्रहों के कारण नहीं हैं।

जानकारी निकालने की क्षमता जोड़ना

locate सुविधा सामान्य अनुरोधों के उत्तर देने के तरीके को बदले बिना, टेक्स्ट से नेम्ड एंटिटी जैसी जानकारी निकालती है। इसके लिए, हम एक अतिरिक्त ट्रेनिंग चरण पेश करते हैं: हम Decider में एक नया विशेष टोकन <|locate|>, एक स्पैन हेड और LoRA एडेप्टर जोड़ते हैं।

हम <|locate|> के एम्बेडिंग को पिछले ट्रेनिंग चरणों में सीखे गए <|marker|> से इनिशियलाइज़ करते हैं। हम केवल इस नए एम्बेडिंग, स्पैन हेड और LoRA एडेप्टर्स को ट्रेन करते हैं, जबकि मूल बैकबोन वेट और डिसीज़न हेड को फ़्रीज़ रखते हैं। प्रत्येक अनुरोधित फ़ील्ड को अपना <|locate|> टोकन मिलता है।

स्पैन हेड <|locate|> के प्रतिनिधित्व को स्टेट-टोकन प्रतिनिधित्वों के साथ उपयोग करके यह स्कोर करता है कि मेल खाने वाले स्पैन कहाँ शुरू और समाप्त होते हैं, और कौन-से प्रारंभ-अंत युग्म एक साथ आते हैं। यह इन स्कोर के लिए फ़ील्ड-विशिष्ट थ्रेशोल्ड का अनुमान लगाने हेतु <|locate|> टोकन के प्रतिनिधित्व का भी उपयोग करता है। चुने गए स्पैन मूल टेक्स्ट में कैरेक्टर स्थितियों के रूप में लौटाए जाते हैं।

हम स्पैन हेड को एक अनुकूलित InfoNCE लॉस के साथ प्रशिक्षित करते हैं, जो हर गोल्ड स्पैन को थ्रेशोल्ड से ऊपर और थ्रेशोल्ड को हर अन्य स्पैन से ऊपर धकेलता है। इस लॉस में दो पद हैं: पहला पद सही स्पैन के स्कोर को थ्रेशोल्ड और गलत स्पैन से ऊपर धकेलता है। दूसरा पद थ्रेशोल्ड को गलत स्पैन के स्कोर से ऊपर धकेलता है। जिन फ़ील्ड का कोई उत्तर नहीं होता, उन्हें केवल दूसरा पद मिलता है, जो मॉडल को खाली सूची लौटाना सिखाता है।

हम स्पैन निष्कर्षण कार्यों के मिश्रण पर ट्रेनिंग करते हैं, जिनमें नेम्ड एंटिटी रिकग्निशन, PII डिटेक्शन और एक्सट्रैक्टिव प्रश्न-उत्तर शामिल हैं। हम फ़ील्ड विवरणों को छोटे लेबल से लेकर विस्तृत निर्देशों तक बदलते रहते हैं, ताकि मॉडल किसी निश्चित लेबल सेट को याद करने के बजाय अनुरोध का पालन करना सीखे।

Locate मॉडल को संरचनात्मक रूप से एक अलग कार्य सिखाता है, और हम इसे इस तरह जोड़ना चाहते हैं कि मॉडल जो पहले से अच्छा करता है, उसमें कोई कमी न आए। Locate अडैप्टर को बैकबोन में मर्ज करने से निर्णय अनुरोधों पर कुछ गिरावट आती है। इसे सीमित करने के लिए, हम कई तरह की जाँच कर रहे हैं, जैसे पिछले चरणों से अधिक रीप्ले डेटा और ऐसे सहायक उद्देश्य जो निर्णय अनुरोधों पर मॉडल के आउटपुट को मूल मॉडल के आउटपुट के करीब रखें। हालाँकि, हम पाते हैं कि मर्ज करना अभी भी पूरी तरह बिना नुकसान के नहीं है, इसलिए हम अडैप्टर को अनमर्ज रखते हैं और उन्हें केवल Locate अनुरोधों के लिए सक्रिय करते हैं।

मूल्यांकन

हम Decider v1.3 और Decider Flash v1.3 का मूल्यांकन Hugging Face Decision Index, Vals AI के ClaimBench और Artificial Analysis Decision Index के बाहरी बेंचमार्क पर करते हैं।

इन मूल्यांकनों में, हमारे मॉडल मज़बूत प्रदर्शन दिखाते हैं। भले ही इन लीडरबोर्ड में निजी रूप से रखे गए कार्य शामिल हैं, फिर भी बार-बार सबमिशन और लीडरबोर्ड फ़ीडबैक के आधार पर बार-बार ट्यूनिंग के ज़रिए इनमें हेरफेर किया जा सकता है। इन लीडरबोर्ड के पूरक के रूप में, हम मॉडलों का मूल्यांकन एक आंतरिक सूट पर करते हैं, जो निजी प्रोडक्शन कार्यों को सार्वजनिक गैर-बेंचमार्क डेटासेट से लिए गए होल्ड-आउट मूल्यांकनों के साथ जोड़ता है। ये मूल्यांकन सार्वजनिक बेंचमार्क से परे सामान्यीकरण की एक अतिरिक्त जाँच प्रदान करते हैं, जिससे हमें व्यापक सुधारों को परिचित मूल्यांकन सूट तक सीमित लाभों से अलग करने में मदद मिलती है।

आंतरिक रूप से, हमने वर्गीकरण, स्कोरिंग, रीरैंकिंग और एंटिटी निष्कर्षण जैसे विभिन्न डोमेन और कार्यों में फैले 200 से अधिक कार्यों का एक सूट बनाया। Decider के वास्तविक प्रदर्शन का ईमानदारी से आकलन करने के लिए, सभी मूल्यांकन ज़ीरो-शॉट तरीके से, कार्य-विशिष्ट फ़ाइन-ट्यूनिंग के बिना किए जाते हैं, जिससे हमें स्पष्ट संकेत मिलता है कि मॉडल को कहाँ बेहतर बनाना है।

क्वेरी वर्गीकरण

Perplexity में, हम हर उपयोगकर्ता क्वेरी को प्रोसेस करने के लिए मल्टी-हेड वर्गीकरण सिस्टम का उपयोग करते हैं। हर क्वेरी को पहले एक एम्बेडिंग मॉडल से गुज़ारा जाता है, जो फ़ीचर एक्सट्रैक्टर के रूप में काम करता है। इसके बाद परिणामी एम्बेडिंग को कई अलग-अलग वर्गीकरण हेड में भेजा जाता है, जिनमें बाइनरी और मल्टी-लेबल दोनों तरह के क्लासिफ़ायर शामिल हैं। उदाहरण के लिए, एक हेड यह तय करता है कि किसी उपयोगकर्ता क्वेरी पर वेब सर्च ट्रिगर होनी चाहिए या नहीं।

फ़्रंटियर LLM द्वारा स्वतंत्र रूप से फिर से लेबल किए गए संदर्भों वाले 63 वर्गीकरण कार्यों में, Decider v1.3 91.6% औसत सटीकता हासिल करता है, जो हमारे प्रोडक्शन क्लासिफ़ायर से 6.54 प्रतिशत अंक अधिक है। Decider Flash v1.3 भी प्रोडक्शन बेसलाइन से बेहतर प्रदर्शन करता है, जबकि Decider v1.3, Jev 1.14 से बेहतर प्रदर्शन करता है।

बड़ा करें

डोमेन-विशिष्ट वर्गीकरण

हमने सात डोमेन में निर्णय मॉडल के वर्गीकरण प्रदर्शन का आकलन करने के लिए सार्वजनिक डेटासेट से एक डोमेन-विशिष्ट मूल्यांकन सूट तैयार किया: दावा सत्यापन (6 कार्य), स्वास्थ्य सेवा (7), साइबर सुरक्षा (8), प्रोग्रामिंग (16), सरकार (7), कानून (9) और वित्त (9)।

उदाहरण के लिए, “किसी Python प्रोग्राम की टाइम कॉम्प्लेक्सिटी का आकलन करें”, या “वार्षिक वित्तीय रिपोर्ट के आधार पर तय करें कि क्या किसी कंपनी की अप्रतिबंधित नकदी अगले बारह महीनों में देय ऋण मूलधन को कवर करती है”। Decider v1.3 सभी सात डोमेन में आगे है, और वित्त में Jev 1.14 से 12.9 प्रतिशत अंक तक तथा कानून में 9.3 अंक तक बेहतर प्रदर्शन करता है। Decider Flash v1.3 वित्त, प्रोग्रामिंग और कानून में Jev 1.14 से पीछे है, और अन्य डोमेन में लगभग समान प्रदर्शन करता है।

बड़ा करें

रिट्रीवल और रीरैंकिंग

सर्च Perplexity के मूल में है। हम अपने मॉडल के रीरैंकिंग प्रदर्शन का मूल्यांकन करने के लिए रिट्रीवल कार्यों का एक व्यापक सूट बनाए रखते हैं। प्रत्येक कार्य के लिए, हम पहले एम्बेडिंग मॉडल के एक पूल का उपयोग करके प्रत्येक कॉर्पस से शीर्ष 50 उम्मीदवार दस्तावेज़ प्राप्त करते हैं। फिर हम Decider का उपयोग करके इन उम्मीदवारों को रीरैंक करते हैं और इसके प्रदर्शन की तुलना एक मज़बूत रीरैंकर बेसलाइन, Qwen3-Reranker-8B, से करते हैं।

हम Decider का मूल्यांकन ज़ीरो-शॉट, पॉइंटवाइज़ सेटिंग में करते हैं, जिसमें मॉडल हर क्वेरी–दस्तावेज़ जोड़ी को स्वतंत्र रूप से सीधे स्कोर करता है और प्रासंगिकता के आधार पर दस्तावेज़ों को रैंक करता है। 72 रिट्रीवल कार्यों में, Decider v1.3 83.99 का औसत nDCG@10 हासिल करता है, और Qwen3-Reranker-8B से 1.81 अंक तथा Jev 1.14 से 2.24 अंक बेहतर प्रदर्शन करता है।

BEIR बेंचमार्क पर, दोनों मॉडल Qwen3-Reranker-8B से क्रमशः 8.78 और 7.05 nDCG@10 अधिक स्कोर करते हैं। Jev 1.14 की तुलना में, Decider v1.3 का स्कोर 1.33 अंक अधिक है, जबकि Flash संस्करण का स्कोर 0.4 कम है।

बड़ा करें

बहुभाषी वर्गीकरण

अंग्रेज़ी से आगे निर्णय मॉडल का मूल्यांकन करने के लिए, हमने 8 सार्वजनिक डेटासेट से 19 भाषा-विशिष्ट कार्यों वाला एक बहुभाषी वर्गीकरण बेंचमार्क तैयार किया, जिसमें आठ भाषाओं में 46,484 उदाहरण हैं: जर्मन, स्पैनिश, फ़्रेंच, इतालवी, रूसी, जापानी, कोरियाई और चीनी। यह बेंचमार्क इंटेंट डिटेक्शन, विषय वर्गीकरण, सेंटीमेंट विश्लेषण, नेचुरल लैंग्वेज इन्फ़रेंस, पैराफ़्रेज़ डिटेक्शन, आपत्तिजनक भाषा डिटेक्शन और व्याकरणिक स्वीकार्यता को कवर करता है।

हम प्रत्येक भाषा के भीतर कार्यों में औसत सटीकता रिपोर्ट करते हैं, जिसमें हर कार्य को समान महत्व दिया जाता है। Decider v1.3 सभी आठ भाषाओं में Jev 1.14 से बेहतर प्रदर्शन करता है और Decider Flash v1.3 छह भाषाओं में ऐसा करता है; Decider v1.3 की औसत कार्य सटीकता 88.16% और Decider Flash v1.3 की 86.50% है, जबकि Jev 1.14 की 85.41% है।

बड़ा करें

NER, PII और एक्सट्रैक्टिव QA

हम locate सुविधा का मूल्यांकन 17 आउट-ऑफ़-डोमेन कार्यों पर करते हैं, जो विभिन्न डोमेन, इनपुट फ़ॉर्मेट (टेक्स्ट, टेबल, संरचित दस्तावेज़) और निर्देशों (छोटे लेबल, प्रश्न और विस्तृत विवरण) में इसके निष्कर्षण का परीक्षण करते हैं। डोमेन Wikipedia से लेकर वैज्ञानिक शोधपत्रों, साइबर-खतरा रिपोर्टों, तकनीकी सहायता, गोपनीयता नीतियों, रिज़्यूमे और कानूनी अनुबंधों तक फैले हैं। अनुरोध “व्यक्ति” या “ईमेल पता” जैसे छोटे लेबल नामों से लेकर, किसी टेबल या सपोर्ट टिकट के बारे में प्रश्नों से होते हुए, संरचित निष्कर्षण के लिए विस्तृत फ़ील्ड विवरणों तक हैं, जैसे किसी NDA के पक्षकार या किसी इनवॉइस पर कुल राशि।

हम NER और PII का मूल्यांकन एक्ज़ैक्ट-स्पैन F1 से करते हैं, जिसमें अनुमानित स्पैन का संदर्भ सीमाओं से पूरी तरह मेल खाना आवश्यक होता है। एक्सट्रैक्टिव QA में कैरेक्टर-स्तरीय F1 का उपयोग होता है, जो ओवरलैप होने वाले उत्तर टेक्स्ट के लिए आंशिक श्रेय देता है, जबकि स्ट्रक्चर्ड एक्सट्रैक्शन में फ़ील्ड सटीकता का उपयोग होता है, यानी सही ढंग से निकाले गए फ़ील्ड का अनुपात। CV पार्सिंग के लिए, हम NER और PII के एक्ज़ैक्ट-स्पैन F1 स्कोर का औसत लेते हैं।

हम अपने मॉडल की तुलना अलग-अलग आकार के सामान्य-उद्देश्य वाले निष्कर्षण मॉडल से करते हैं: GLiNER large v2.5 (0.5B), Liquid d1 (2B) और Cloudflare का Clairic (अघोषित)। Decider v1.3 69.0 का औसत स्कोर हासिल करता है (प्रत्येक कार्य के प्राथमिक मेट्रिक का उपयोग करके) और Decider Flash v1.3 63.6 तक पहुँचता है, जबकि Liquid d1 का स्कोर 43.3, Clairic का 41.5 और GLiNER large v2.5 का 33.6 है। दोनों Decider मॉडल हर श्रेणी में आगे हैं।

बड़ा करें

इमेज वर्गीकरण

Decider v1 से ही विज़न कार्यों को नेटिव रूप से सपोर्ट करता है। टेक्स्ट से आगे इसके प्रदर्शन का मूल्यांकन करने के लिए, हमने पाँच कार्यों वाला एक बेंचमार्क सूट तैयार किया, जिसका विशेष ध्यान दस्तावेज़ वर्गीकरण पर है, जिसमें इनवॉइस, पत्र और रिज़्यूमे शामिल हैं। इस सूट में सैटेलाइट इमेज वर्गीकरण, टेक्सचर वर्गीकरण, पालतू जानवरों की नस्ल का वर्गीकरण और जानवरों की गिनती भी शामिल है।

Decider v1.3 पाँच विज़ुअल कार्यों में 76.99% की औसत सटीकता हासिल करता है, और Jev 1.14 से 1.47 प्रतिशत अंक बेहतर प्रदर्शन करता है। Decider Flash v1.3 72.77% हासिल करता है, जो एक छोटे मॉडल में विज़ुअल वर्गीकरण क्षमताएँ दर्शाता है।

बड़ा करें

वास्तविक निर्णय अनुरोध

हमने Perplexity Decision API पर उसकी उपलब्धता के पहले 18 दिनों के दौरान सबमिट किए गए दस लाख डुप्लिकेट-रहित, PII-मास्क्ड अनुरोधों का नमूना लिया। चूँकि हर अनुरोध में एक ही स्टेट के बारे में कई प्रश्न हो सकते हैं, इसलिए इस नमूने में 23,18,887 अलग-अलग प्रश्न शामिल हैं। सभी अनुरोध शोध के लिए उपयोगकर्ता की स्पष्ट अनुमति के साथ शामिल किए गए थे।

प्रोडक्शन अनुरोधों के साथ ग्राउंड-ट्रुथ लेबल नहीं आते, इसलिए हम संदर्भ उत्तर तैयार करने के लिए फ़्रंटियर LLM जजों का उपयोग करते हैं और उनके साथ प्रत्येक मॉडल की सहमति मापते हैं। हम अनुरोधों को 10 कार्य श्रेणियों में भी समूहित करते हैं, जिनमें सूचना निष्कर्षण, डोमेन वर्गीकरण, सेंटीमेंट विश्लेषण, इंटेंट और रूटिंग, प्रासंगिकता रैंकिंग, कंटेंट मॉडरेशन, गुणवत्ता और अनुपालन समीक्षा, एंटिटी मिलान, व्यावसायिक विश्लेषण और एक “अन्य” श्रेणी शामिल हैं। यह विभाजन दिखाता है कि वास्तविक उपयोग के मामलों में प्रदर्शन कैसे बदलता है।

कार्यों का मिश्रण असमान है: सूचना निष्कर्षण के 4,25,402 प्रश्न हैं, डोमेन वर्गीकरण के 4,09,564 और सेंटीमेंट विश्लेषण के 3,44,158। ये तीनों श्रेणियाँ मिलकर नमूने के 50.8% प्रश्न बनाती हैं।

Decider v1.3 जजों के साथ 93.98% पर सबसे अधिक सहमति हासिल करता है, जबकि Decider v1.2 के लिए यह 93.68% और Jev 1.14 के लिए 93.35% है। डोमेन वर्गीकरण और सेंटीमेंट विश्लेषण पर Decider v1.3 और Jev 1.14 लगभग बराबर हैं, जिनमें क्रमशः 0.34 और 0.07 प्रतिशत अंकों का अंतर है। प्रासंगिकता रैंकिंग पर Jev 0.69 अंकों से आगे है, जबकि Decider v1.3 सूचना निष्कर्षण (नमूने में सबसे आम कार्य) पर 0.93 अंकों से और इंटेंट और रूटिंग पर 1.21 अंकों से आगे है।

बड़ा करें

नीचे दिया गया चार्ट उन्हीं दस लाख प्रोडक्शन अनुरोधों को चलाने की रिपोर्ट की गई लागत की तुलना करता है। हर अनुरोध में कई प्रश्न हो सकते हैं, इसलिए यहाँ इकाई अनुरोध है, अलग-अलग प्रश्न नहीं।

बड़ा करें

मज़बूती

हमने 372 बहुविकल्पीय प्रश्नों पर लेबल संवेदनशीलता का मूल्यांकन किया, और प्रति मॉडल 4,788 अनुरोध किए। हमने प्रत्येक प्रश्न का अर्थ बनाए रखते हुए विकल्पों का क्रम बदला, उत्तर टेक्स्ट को लेबल फिर से असाइन किए और लेबल के नाम बदले, फिर जाँचा कि क्या मॉडल का अर्थगत उत्तर बदला। कम फ़्लिप दर अधिक स्थिरता दर्शाती है।

प्रत्येक ट्रांसफ़ॉर्मेशन के तहत Decider v1.3 ने केवल 0.27% प्रश्नों पर अपना उत्तर बदला, जबकि Jev 1.14 के लिए यह 2.69–4.84% था। हमने सर्विंग में परिवर्तनशीलता मापने के लिए समान इनपुट को दोहराया भी: Decider v1.3 में कोई बदलाव नहीं दिखा, जबकि Jev 1.14 ने 1.88% प्रश्नों पर उत्तर बदला।

बड़ा करें

हम Decider का उपयोग कैसे करते हैं

Decider उन वर्कफ़्लो के लिए बनाया गया है जिन्हें तेज़ और संरचित निर्णयों की आवश्यकता होती है। इस सेक्शन में हम देखते हैं कि हमारे काम करने के तरीके पर सार्थक प्रभाव डालने के लिए इनका लाभ कैसे उठाया जाए। यहाँ कुछ ऐसे उपयोग दिए गए हैं जो सबसे अलग नज़र आए।

स्वयं-सुधार करने वाले सुरक्षा नियम

आंतरिक रूप से, हम अपनी सुरक्षा नीतियों को बेहतर बनाने के लिए पहले से ही Decider का उपयोग कर रहे हैं।

हमारे एजेंटों की गतिविधि रिकॉर्ड की जाती है और किसी भी समस्याग्रस्त व्यवहार की पहचान करने के लिए नियम-आधारित जाँचों की एक शृंखला चलाई जाती है। नियम-आधारित दृष्टिकोण का अर्थ है कि हम नगण्य अतिरिक्त लेटेंसी के साथ अपने एजेंटों की रीयल-टाइम में निगरानी कर सकते हैं। ऑफ़लाइन, हम इन रिकॉर्ड किए गए एजेंट लॉग के नमूनों को देखने के लिए Decider का उपयोग करते हैं। यदि कोई समस्याग्रस्त व्यवहार फ़्लैग नहीं किया गया, तो Decider जाँचता है कि क्या हमारे नियमों के सेट से कुछ छूट गया है; और यदि कोई अलार्म बजा, तो Decider जाँचता है कि क्या यह गलत अलार्म था। जिन रिकॉर्ड में हमारा नियम सेट इनमें से किसी भी स्थिति में विफल रहता है, उन्हें ट्राइएज के लिए एक एजेंट को भेजा जाता है और नियमों में सुधार प्रस्तावित किया जाता है, जिसे हमारी सुरक्षा टीम के किसी सदस्य द्वारा स्वीकृत किया जाना होता है।

एक दिन में, Decider ने 7,000 एजेंट सत्रों में 1 अरब टोकन पढ़े और ऐसी खामियों की पहचान की जिनसे नियमों में 14 सुधार हुए, जिनमें से 6 को दो दिनों के भीतर स्वीकृत करके शिप कर दिया गया। एक सप्ताह के लॉग पर दोबारा चलाने पर, इन सुधारों ने हमारे सबसे व्यस्त नियम की मात्रा 52% कम कर दी, और विस्तारित नियमों ने जाँच के लिए लगभग 40% अधिक वैध कार्रवाइयाँ पकड़ीं।

बड़ा करें

RL रोलआउट की निगरानी

जब हम रीइन्फ़ोर्समेंट लर्निंग के साथ मॉडल को पोस्ट-ट्रेन करते हैं, तो टर्मिनल रिवॉर्ड जैसे समग्र मेट्रिक यह नहीं बताते कि कोई रोलआउट (किसी कार्य पर एक अलग प्रयास) क्यों सफल या विफल हुआ। किसी टूल सेवा या सैंडबॉक्स के विफल होने के कारण वह अनुचित रूप से रिवॉर्ड खो सकता है, या यदि मूल्यांकनकर्ता किसी असमर्थित दावे को नज़रअंदाज़ कर दे, जैसे कोई गढ़ा हुआ मान जिसे किसी टूल ने नहीं लौटाया, तो उसे अनुचित रिवॉर्ड मिल सकता है।

हम इन मामलों के लिए रोलआउट की निगरानी करने में Decider का उपयोग करते हैं। पहले कोड किसी रोलआउट के उन हिस्सों की पहचान करता है जिनकी बारीकी से जाँच ज़रूरी है: एक विफल टूल कॉल और उसके आसपास का तर्क, बिना त्रुटियों के चला कोड, या अंतिम उत्तर। इसके बाद Decider प्रत्येक हिस्से के बारे में बहुविकल्पीय प्रश्नों के उत्तर देता है, जैसे किसी चरण में क्या विफल हुआ (कोई टूल सेवा, कोई बाहरी साइट, सैंडबॉक्स, हार्नेस, या एजेंट का अपना कोड) और क्या एजेंट ने परिणाम की सही व्याख्या की। हम किसी दिए गए हिस्से के बारे में सभी प्रश्नों को एक ही अनुरोध में बंडल करते हैं और कोई फ़ैसला सहेजने के बजाय प्रायिकताएँ सहेजते हैं, ताकि हम बाद में Decider से फिर से क्वेरी किए बिना थ्रेशोल्ड समायोजित कर सकें। मॉनिटर केवल देखता है और निदान करता है: यह कभी भी रिवॉर्ड नहीं बदलता और न ही किसी रन को रोकता है।

बड़ा करें

पेज गुणवत्ता फ़िल्टरिंग

उपयोगकर्ताओं के लिए इंडेक्स करने और दिखाने हेतु वेब पेज क्रॉल करते समय, कई पेज इतनी निम्न गुणवत्ता के होते हैं कि वे किसी काम के नहीं होते। इनमें एंटी-बॉट वॉल, CAPTCHA और त्रुटि पेज शामिल हैं, साथ ही सही ढंग से लोड हुए ऐसे वेब पेज भी जिनमें कोई उपयोगी जानकारी नहीं होती, जैसे स्पैम, SEO फ़िलर या केवल नेविगेशन वाले पेज। इन निम्न-गुणवत्ता वाले पेजों की पहचान करके उन्हें हमारे इंडेक्स से फ़िल्टर करना ज़रूरी है।

Decider का उपयोग करके, हम पेजों को क्रॉल करते समय ही उनकी गुणवत्ता का आकलन कर सकते हैं। उसी फ़ॉरवर्ड पास में, हम कई अन्य वर्गीकरण कार्य भी करते हैं, जैसे सामग्री के डोमेन और लक्षित दर्शकों की पहचान करना, और यह पता लगाना कि उसमें हानिकारक, अवैध या व्यक्तिगत रूप से पहचान योग्य जानकारी है या नहीं। LLM जज का उपयोग करने की तुलना में, Decider काफ़ी तेज़ और सस्ता है।

बड़ा करें

इन आंतरिक उपयोगों के अलावा, Decider निम्नलिखित जैसे वर्कफ़्लो के लिए भी उपयुक्त है।

विज़ुअल QA

चूँकि Decider इमेज पढ़ता है, इसलिए यह एक विज़ुअल चेकर के रूप में भी काम करता है, जो वेब पेजों या ऐप्स में स्टाइल बदलावों की समीक्षा करता है और खामियों की पहचान करता है। यह किसी बदलाव के शिप होने से पहले पेज स्क्रीनशॉट में कटे हुए टेक्स्ट, ओवरलैप होते एलिमेंट और टूटे लेआउट की समीक्षा कर सकता है, या ऐसे चार्ट फ़्लैग कर सकता है जिनका डिज़ाइन पाठक को गुमराह कर सकता है या ब्रांड गाइड का उल्लंघन कर सकता है।

बड़ा करें

ब्राउज़र नेविगेशन

एजेंट बड़े कार्यों के भीतर छोटे निर्णयों के लिए Decider का उपयोग कर सकते हैं। एक ब्राउज़र एजेंट हर चरण पर एक स्क्रीनशॉट भेज सकता है और पेज की स्थिति तथा हर संभावित कार्रवाई के अपेक्षित परिणाम के बारे में विस्तृत जानकारी प्राप्त कर सकता है।

बड़ा करें

शोध कार्यों की योजना बनाना

उपयोगकर्ताओं के प्रश्नों की जटिलता में काफ़ी अंतर हो सकता है, और इसी तरह उत्तर खोजने के लिए आवश्यक खोज की गहराई में भी। Decider खोज शुरू होने से पहले ही इसका अनुमान लगा सकता है, जिससे सरल प्रश्नों पर कम संसाधन खर्च होते हैं।

बड़ा करें

शुरुआत करें

Decider प्रायिकताएँ लौटाता है। उपयुक्त निर्णय थ्रेशोल्ड एप्लिकेशन पर निर्भर करता है। लेबल आवृत्तियाँ और फ़ॉल्स पॉज़िटिव तथा फ़ॉल्स नेगेटिव की सापेक्ष लागत अलग-अलग उपयोग के मामलों में भिन्न होती हैं। इसलिए हम उपयोगकर्ताओं को प्रोत्साहित करते हैं कि वे यह मानने के बजाय कि कोई निश्चित कटऑफ़ सभी कार्यों में समान रूप से अच्छा काम करेगा, एक छोटे, प्रतिनिधि, लेबल किए गए डेवलपमेंट सेट पर थ्रेशोल्ड ट्यून करें।

हम बारीक निर्णयों, विस्तृत रूब्रिक और उन वर्कफ़्लो के लिए Decider v1.3 का उपयोग करने की सलाह देते हैं जहाँ त्रुटियाँ महंगी पड़ती हैं। अधिक मात्रा वाले रूटिंग, लेबलिंग और फ़िल्टरिंग के लिए Decider Flash v1.3 चुनें, जहाँ लेटेंसी और लागत मुख्य बाधाएँ हैं। अपने वर्कलोड के प्रतिनिधि उदाहरणों पर दोनों मॉडल का मूल्यांकन करें, फिर वह मॉडल चुनें जो आपकी गुणवत्ता, लेटेंसी और बजट आवश्यकताओं को पूरा करता हो।

दोनों मॉडल Apache लाइसेंस के तहत Hugging Face पर डाउनलोड करने योग्य वेट के रूप में, OpenRouter के ज़रिए और Perplexity Decisions API पर उपलब्ध हैं।

उद्धरण

@online{perplexity2026PerplexityDecider,
  author = {{Perplexity} and Antoine Chaffin and Jonas Golde and Louis Milliken and Sarah Eslami and Markus Krimmel and Nandor Licker and Aleksandr Nikolenko and Ron Heichman and Bo Wang and Jarrod Bryan and Jeremy Yang and Denis Yarats},
  title = {{Perplexity Decider}},
  date = {2026-11-12},
  url = {https://www.perplexity.ai/hub/blog/perplexity-decider}
}