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 प्रकारच्या प्रश्नांना समर्थन देते:

• होय / नाही: बायनरी निर्णय.
• बहुपर्यायी: सानुकूल मल्टी-क्लास लेबल्स.
• स्कोअर: क्रमबद्ध स्तर.

निर्णय मॉडेल्स वर्गीकरण आणि स्कोअरिंगच्या विविध प्रकारच्या कार्यांना समर्थन देतात:

• आउटपुटचे मूल्यमापन: स्रोतनिष्ठा, गुणवत्ता आणि सुरक्षितता तपासणे.
• राउटिंग: अडचणीच्या पातळीनुसार विनंत्या लहान किंवा मोठ्या मॉडेल्सकडे पाठवणे.
• मॉडरेशन आणि सुरक्षा: टूल आउटपुटमधील हानिकारक सामग्री, फिशिंग आणि प्रॉम्प्ट इंजेक्शन ओळखणे.
• फिल्टरिंग आणि टॅगिंग: मजकुराचे मोठे संग्रह व्यवस्थित करणे.
• रिट्रिव्हल आणि रीरँकिंग: प्रासंगिकतेनुसार शोध परिणामांना गुण देणे.

यापैकी अनेक कार्ये पूर्वी LLMs सारख्या जनरेटिव्ह मॉडेल्सद्वारे हाताळली जात होती, जरी त्यांना मुक्त-स्वरूपातील मजकूर निर्मितीची आवश्यकता नसते. निर्णय मॉडेल्स (decision models) LLMs आणि कार्य-विशिष्ट क्लासिफायर्स यांच्या मधल्या स्थानावर असतात. ती एकाच इनपुटबद्दलच्या अनेक प्रश्नांसाठी एकाच फॉरवर्ड पासमध्ये संभाव्यता परत करतात, ज्यामुळे टोकन-दर-टोकन उत्तर निर्मिती टाळली जाते आणि प्रश्नांमध्ये गणन (computation) सामायिक केले जाते. कार्य-विशिष्ट क्लासिफायर्सच्या विपरीत, ती नैसर्गिक भाषेतील प्रॉम्प्ट्सद्वारे नवीन कार्ये हाताळू शकतात; ही लवचिकता सामायिक प्रश्नोत्तर स्वरूपात विविध कार्यांवर प्रशिक्षण घेतल्यामुळे आत्मसात होते.

प्रशिक्षण

जनरेटिव्ह LLM चे निर्णय मॉडेलमध्ये रूपांतर

आम्ही सक्षम जनरेटिव्ह LLM बॅकबोन्स अनुकूलित करून Decider तयार करतो. हे अनुकूलन स्पष्ट करण्यासाठी, आम्ही प्रथम विनंती कशी दर्शवली जाते याचे वर्णन करतो. खाली दाखवल्याप्रमाणे, विनंतीमध्ये एक सामायिक संदर्भ (स्टेट) आणि अनेक प्रश्न असतात. स्टेट सर्व प्रश्नांसाठी पुन्हा वापरली जाईल.

उदाहरणार्थ, एखादा दस्तऐवज आणि त्याचा सारांश दिल्यास, सारांश दस्तऐवजाचे विश्वासूपणे प्रतिनिधित्व करतो का आणि तो तज्ज्ञांसाठी आहे की सामान्य वाचकांसाठी, हे दोन्ही एकाच विनंतीत विचारता येते. स्टेटनंतर, प्रत्येक प्रश्न ब्लॉकमध्ये एक प्रश्न आणि त्याची संभाव्य उत्तरे असतात; प्रत्येक उत्तराला A, B किंवा C सारखे पूर्वनिर्धारित लेबल टोकन दिलेले असते. विशेष <|marker|> टोकन मॉडेलचे अनुमान कोठे वाचायचे ते दर्शवतो. या स्थानावर, शिकलेला रेखीय आउटपुट स्तर (निर्णय हेड) हिडन स्टेटला प्रश्नाच्या उत्तर पर्यायांसाठीच्या गुणांमध्ये रूपांतरित करतो, ज्यांचे नंतर संभाव्यतांमध्ये रूपांतर केले जाते.

विस्तृत करा

आम्ही आउटपुट स्तर बेस मॉडेलमधून इनिशियलाइझ करतो, जो सामान्यतः संपूर्ण शब्दसंग्रहातून पुढील टोकनसाठी गुण देतो, आणि केवळ A, B किंवा C सारख्या पूर्वनिर्धारित पर्याय टोकन्सशी संबंधित रो ठेवतो. त्यानंतर हा छाटलेला स्तर <|marker|> च्या हिडन स्टेटचे उत्तर गुणांमध्ये रूपांतर करण्यासाठी प्रशिक्षित केला जातो. हा दृष्टिकोन सर्व वर्गीकरण प्रश्नांना लागू होतो, कारण ते सर्व बहुपर्यायी स्वरूपात मांडता येतात.

प्रशिक्षणासाठी, आम्ही विविध कार्ये (भावना, नैसर्गिक भाषा अनुमान, हेतू ओळख, एंटिटी मॅचिंग, मॉडरेशन, तथ्य पडताळणी, रेटिंग्ज इ.) व्यापणारे शेकडो सार्वजनिक डेटासेट घेतो आणि प्रत्येक उदाहरण वर वर्णन केलेल्या एकीकृत फॉरमॅटमध्ये रूपांतरित करतो: एक स्टेट, एक किंवा अधिक प्रश्न, त्यांचे पर्याय आणि एक लक्ष्य. आमच्याकडे गोल्ड लेबल्स असल्यास लक्ष्य हा एकमेव योग्य पर्याय असू शकतो, अन्यथा ते पर्यायांवरील संभाव्यता वितरण असू शकते.

v1.3 मध्ये, आम्ही locate सादर करत आहोत, जे पूर्वनिर्धारित पर्यायांमधून निवड करण्याऐवजी स्टेटमधून मजकूर काढते. locate प्रश्नात काय शोधायचे याचे वर्णन असते; त्यासाठी “स्थान” सारखे छोटे लेबल किंवा “नोकरी ज्या शहरात आहे त्या शहराचे नाव काढा.” सारखी सूचना वापरली जाते. मॉडेल स्टेटमधील अचूक जुळणारा मजकूर, त्याच्या सुरुवातीच्या आणि शेवटच्या कॅरेक्टर स्थानांसह परत करते. कोणतीही जुळणी न आढळल्यास, ते रिकामी यादी परत करते.

विस्तृत करा

सामायिक स्टेटमुळे, एकाच विनंतीत एकाच इनपुटबद्दलचे locate, वर्गीकरण आणि स्कोअरिंग प्रश्न एकत्र करता येतात. उदाहरणार्थ, नोकरीसाठी वरिष्ठ स्तरावरील अनुभव आवश्यक आहे का हे विचारणे आणि आवश्यक कौशल्ये काढणे, हे दोन्ही एकाच विनंतीत करता येते.

द्विदिशात्मक अटेंशन: मॉडेलला दोन्ही दिशांनी वाचू देणे

आमची मॉडेल्स सशक्त पूर्वप्रशिक्षित जनरेटिव्ह बॅकबोनपासून सुरू होतात, ज्यांच्या कॉझल अटेंशनमुळे प्रत्येक टोकन केवळ स्वतःवर आणि आधीच्या टोकन्सवर लक्ष देऊ शकतो. आमच्या अ‍ॅब्लेशन अभ्यासांतून असे दिसून आले की बॅकबोनचे फुल-अटेंशन स्तर द्विदिशात्मक केल्याने कार्यक्षमता सुधारते, म्हणून प्रत्येक टोकनला संपूर्ण इनपुटमधील संदर्भ समाविष्ट करता यावा यासाठी आम्ही ही रचना स्वीकारतो.

द्विदिशात्मक अटेंशनमुळे आणखी एक डिझाइन निवड समोर येते: स्टेट आणि प्रश्न यांनी परस्परांशी कसा संवाद साधावा? आम्ही तीन अटेंशन पॅटर्न्सचा विचार केला, ज्यांचे कार्यक्षमता, उत्तरांची स्थिरता आणि कॅशे पुनर्वापरावर वेगवेगळे परिणाम होतात:

• सर्व काही सर्व काही पाहते (v1.2): स्टेट आणि सर्व प्रश्नांवर पूर्ण द्विदिशात्मक अटेंशनसह एकत्रित प्रक्रिया केली जाते. स्टेटवरील गणना सामायिक असते, परंतु एका प्रश्नाचे उत्तर इतर कोणते प्रश्न विचारले आहेत यानुसार बदलू शकते.
• स्वतंत्र प्रश्न (v1.3): स्टेट सर्व प्रश्नांवर अटेंड करते, तर प्रत्येक प्रश्न केवळ स्टेटवर आणि स्वतःच्या टोकन्सवर अटेंड करतो. प्रश्न सामायिक स्टेटमार्फत एकमेकांवर अप्रत्यक्षपणे प्रभाव टाकू शकतात, परंतु परिणाम अधिक स्थिर असतात.
• पूर्णपणे कॅश करण्यायोग्य: स्टेट फक्त स्वतःकडे लक्ष देते (attend), तर प्रत्येक प्रश्न स्टेटकडे आणि स्वतःच्या टोकनकडे लक्ष देतो. स्टेट प्रश्नांपासून स्वतंत्र असते आणि प्रॉम्प्ट कॅशिंगचा लाभ घेण्यासाठी विनंत्यांमध्ये पुन्हा वापरता येते. आम्ही हे डीफॉल्टनुसार वापरत नाही, कारण स्टेटला प्रश्न पाहू देणे अनेक कार्यांसाठी खूप महत्त्वाचे असते, परंतु थोड्याशा फाइन-ट्यूनिंगद्वारे मॉडेलला या पद्धतीकडे वळवता येते.

उत्कृष्ट कार्यक्षमता आणि स्थिरतेमुळे आम्ही शेवटी स्वतंत्र प्रश्नांची निवड केली.

विस्तृत करा

प्रशिक्षण पद्धत

दोन्ही मॉडेल आकारांसाठी प्रशिक्षण तीन टप्प्यांमध्ये होते. आम्ही प्रथम Qwen3.8-27B वर आधारित मोठ्या मॉडेलला मोठ्या डेटासेटवर क्रॉस-एन्ट्रॉपी वापरून प्रशिक्षित करतो आणि नंतर त्याचे लहान Qwen3.5-4B मॉडेलमध्ये डिस्टिलेशन करतो.

पहिला टप्पा जनरलिस्ट प्रशिक्षणाचा आहे, ज्यात आम्ही मोठ्या प्रमाणातील कॉर्पोरावर मॉडेलचे पूर्ण फाइन-ट्यूनिंग करतो. या टप्प्यात, आम्ही केवळ असाच डेटा स्वीकारतो जो मॉडेलला सर्वच बाबतीत मदत करतो आणि कोणत्याही बेंचमार्कसाठी विशिष्ट नसतो; त्यामुळे आम्ही कोणतेही बेंचमार्क ट्रेनिंग स्प्लिट्स वगळतो.

हे जनरलिस्ट मॉडेल प्रशिक्षित झाल्यानंतर, आम्ही LoRA वापरून दुसरा, अधिक सूक्ष्म टप्पा चालवतो. या टप्प्यात वापरला जाणारा डेटा विशिष्ट डोमेन आणि कार्यांवर लक्ष्यित असतो. जर आम्हाला मर्यादित सुधारणा दिसल्या किंवा इतर कार्यांवर काही घसरण (regression) दिसली, तर आम्ही तो डेटा पहिल्या टप्प्याऐवजी दुसऱ्या टप्प्यात जोडतो. जनरलिस्ट मॉडेलपासून फार दूर भरकटू नये आणि त्या विशिष्ट डोमेनशी जुळवून घेताना कार्यक्षमता गमावण्याचा धोका टाळावा, यासाठी आम्ही LoRA वापरतो. बॅकबोनचे सामान्य ज्ञान कायम ठेवत कार्यक्षमता सुधारणे हे उद्दिष्ट आहे. भरकटणे अधिक अचूकपणे नियंत्रित करण्यासाठी आणि कोणत्याही इन-डोमेन सुधारणांपेक्षा राखीव (held-out) मेट्रिक्सना प्राधान्य देण्यासाठी, LoRA पुन्हा बेस मॉडेलमध्ये विलीन करताना आम्ही एक वेट (weight) देखील वापरतो.

शेवटी, आम्ही एक व्हिजन-विशिष्ट टप्पा जोडतो. दुसऱ्या टप्प्याप्रमाणेच, व्हिजन टप्पा हा आणखी एक सूक्ष्म स्पेशलायझेशन टप्पा मानला जातो, ज्यात LoRA अ‍ॅडॉप्टर वापरला जातो आणि तो एका वेटसह बेस मॉडेलमध्ये परत मर्ज केला जातो. काही व्हिजन क्षमतांची किंमत मजकूर कार्यक्षमतेत मोजावी लागू शकते. मॉडेल्सचा वापर मजकुरावर कितीतरी अधिक होत असल्याचे आम्हाला दिसते, म्हणून आम्ही व्हिजन मेट्रिक्सपेक्षा मजकूर मेट्रिक्सना प्राधान्य देतो.

दोन्ही मजकूर टप्प्यांसाठी, आम्ही तीन रनमधील सरासरी वेट्स वापरतो; प्रत्येक रनमध्ये वेगळा रँडम सीड वापरला जातो. यामुळे एकत्रित मॉडेलची कार्यक्षमता आणि मजबुती सुधारते, असे आम्हाला आढळले.

अंतिम मोठे मॉडेल मिळाल्यानंतर, आम्ही लहान मॉडेलवर तीच तीन-टप्प्यांची प्रशिक्षण प्रक्रिया लागू करतो. येथे मोठे मॉडेल शिक्षकाची (teacher) भूमिका बजावते: त्याचे अंदाजित आउटपुट वितरण गोल्ड लेबल्सची जागा घेते, आणि लहान मॉडेलला त्याच्या अंदाजांमधील आणि शिक्षक मॉडेलच्या अंदाजांमधील KL डायव्हर्जन्स कमीत कमी करण्यासाठी प्रशिक्षित केले जाते. हे डिस्टिलेशन उद्दिष्ट त्याच प्रशिक्षण डेटावर क्रॉस-एन्ट्रॉपीपेक्षा अधिक चांगली कामगिरी करते. समर्पित प्रशिक्षण डेटा असलेल्या बेंचमार्कवर क्रॉस-एन्ट्रॉपी अधिक चांगली कामगिरी करते, परंतु राखीव (held-out) डेटावर तिचे सामान्यीकरण तितके चांगले होत नाही. आमचे गृहितक असे आहे की डिस्टिलेशन शिक्षक मॉडेलचे आउटपुट वितरण, गोल्ड नसलेल्या पर्यायांवरील त्याच्या आत्मविश्वासासह, अधिक चांगल्या प्रकारे हस्तांतरित करते, तर क्रॉस-एन्ट्रॉपी बेंचमार्क-विशिष्ट प्रशिक्षण वितरणाशी ओव्हरफिटिंगला प्रोत्साहन देते. म्हणून आम्ही KL-आधारित डिस्टिलेशन उद्दिष्ट स्वीकारतो.

प्रशिक्षण-चाचणी दूषितता (train-test contamination) कमी करण्यासाठी, आम्ही वापरत असलेल्या कोणत्याही मूल्यमापनाशी ओव्हरलॅप होऊ शकणारे सर्व प्रशिक्षण नमुने काढून टाकतो. हे महत्त्वाचे आहे, कारण काही सार्वजनिक प्रशिक्षण डेटासेटमध्ये काही मूल्यमापन डेटासेटचे मोठे भाग असतात. आमच्या सुधारणा विश्वासार्ह आहेत आणि केवळ शिकलेल्या पूर्वग्रहांमुळे (biases) झालेल्या नाहीत, याची खात्री करण्यासाठी आम्ही व्यापक पूर्वग्रह ऑडिट करतो आणि ते पूर्वग्रह दूर करतो.

माहिती काढण्याची क्षमता जोडणे

locate वैशिष्ट्य सामान्य विनंत्यांना उत्तरे देण्याची पद्धत न बदलता, मजकुरातून नेम्ड एंटिटीसारखी माहिती काढते. हे करण्यासाठी, आम्ही एक अतिरिक्त प्रशिक्षण टप्पा सादर करतो: आम्ही Decider मध्ये एक नवीन विशेष टोकन, <|locate|>, एक स्पॅन हेड आणि LoRA अ‍ॅडॉप्टर जोडतो.

आम्ही <|locate|> चे एम्बेडिंग मागील प्रशिक्षण टप्प्यांत शिकलेल्या <|marker|> पासून इनिशियलाइझ करतो. मूळ बॅकबोन वेट्स आणि निर्णय हेड फ्रोझन ठेवून, आम्ही फक्त हे नवीन एम्बेडिंग, स्पॅन हेड आणि LoRA अ‍ॅडॉप्टर्स प्रशिक्षित करतो. विनंती केलेल्या प्रत्येक फील्डला स्वतःचे <|locate|> टोकन मिळते.

स्पॅन हेड <|locate|> चे प्रतिनिधित्व (representation) आणि स्टेट-टोकनची प्रतिनिधित्वे एकत्र वापरून जुळणारे स्पॅन कुठे सुरू होतात आणि कुठे संपतात, तसेच कोणत्या सुरुवात-शेवट जोड्या एकमेकांशी संबंधित आहेत, याचे स्कोअर ठरवते. या स्कोअरसाठी फील्ड-विशिष्ट थ्रेशोल्डचा अंदाज लावण्यासाठी ते <|locate|> टोकनच्या प्रतिनिधित्वाचाही वापर करते. निवडलेले स्पॅन मूळ मजकुरातील अक्षरांच्या स्थानांच्या (character positions) स्वरूपात परत केले जातात.

आम्ही स्पॅन हेडला अनुकूलित InfoNCE लॉसने प्रशिक्षित करतो, जो प्रत्येक गोल्ड स्पॅनला थ्रेशोल्डच्या वर आणि थ्रेशोल्डला इतर प्रत्येक स्पॅनच्या वर ढकलतो. या लॉसमध्ये दोन टर्म्स आहेत: पहिली टर्म योग्य स्पॅनचे स्कोअर थ्रेशोल्ड आणि चुकीच्या स्पॅनच्या वर ढकलते. दुसरी टर्म थ्रेशोल्डला चुकीच्या स्पॅनच्या स्कोअरच्या वर ढकलते. ज्या फील्डना उत्तर नसते त्यांना फक्त दुसरी टर्म लागू होते, ज्यामुळे मॉडेल रिकामी यादी परत करायला शिकते.

आम्ही नेम्ड एंटिटी रेकग्निशन, PII ओळख आणि एक्स्ट्रॅक्टिव्ह प्रश्नोत्तर यांसह स्पॅन एक्स्ट्रॅक्शन कार्यांच्या मिश्रणावर प्रशिक्षण देतो. आम्ही फील्ड वर्णने छोट्या लेबल्सपासून तपशीलवार सूचनांपर्यंत बदलतो, जेणेकरून मॉडेल निश्चित लेबल संच लक्षात ठेवण्याऐवजी विनंतीचे पालन करायला शिकेल.

Locate मॉडेलला संरचनात्मकदृष्ट्या वेगळे कार्य शिकवते, आणि मॉडेल आधीपासून जे चांगले करते ते न गमावता आम्हाला ते जोडायचे आहे. locate अ‍ॅडॉप्टर्स बॅकबोनमध्ये विलीन केल्याने निर्णय विनंत्यांवर काही प्रमाणात घसरण होते. ही घसरण मर्यादित ठेवण्यासाठी, आम्ही काही तपासण्या करत आहोत, जसे की आधीच्या टप्प्यांमधील अधिक रिप्ले डेटा आणि निर्णय विनंत्यांवरील मॉडेलचे आउटपुट मूळ मॉडेलच्या आउटपुटच्या जवळ ठेवणारी सहायक उद्दिष्टे. तथापि, विलीनीकरण अजूनही पूर्णपणे हानिरहित (lossless) नाही असे आम्हाला आढळते, म्हणून आम्ही अ‍ॅडॉप्टर्स विलीन न करता स्वतंत्र ठेवतो आणि ते फक्त locate विनंत्यांसाठी सक्रिय करतो.

मूल्यमापन

आम्ही Decider v1.3 आणि Decider Flash v1.3 चे मूल्यमापन Hugging Face Decision Index, Vals AI चे ClaimBench आणि Artificial Analysis Decision Index मधील बाह्य बेंचमार्क्सवर करतो.

या मूल्यमापनांमध्ये आमची मॉडेल्स दमदार कामगिरी दाखवतात. या लीडरबोर्डमध्ये खासगीरित्या ठेवलेली कार्ये समाविष्ट असली तरी, वारंवार सबमिशन आणि लीडरबोर्डवरील अभिप्रायावर आधारित पुनरावर्ती ट्यूनिंगद्वारे त्यांचा गैरफायदा घेता येऊ शकतो. या लीडरबोर्डना पूरक म्हणून, आम्ही खासगी प्रॉडक्शन कार्ये आणि सार्वजनिक नॉन-बेंचमार्क डेटासेटमधून घेतलेली राखीव (held-out) मूल्यमापने एकत्र करणाऱ्या अंतर्गत संचावर मॉडेल्सचे मूल्यमापन करतो. ही मूल्यमापने सार्वजनिक बेंचमार्कपलीकडील सामान्यीकरणाची अतिरिक्त तपासणी करतात, ज्यामुळे आम्हाला व्यापक सुधारणा आणि परिचित मूल्यमापन संचांपुरत्या मर्यादित सुधारणा यांमध्ये फरक करता येतो.

अंतर्गत वापरासाठी, आम्ही वर्गीकरण, स्कोअरिंग, रीरँकिंग आणि एंटिटी एक्स्ट्रॅक्शन यांसारख्या विविध क्षेत्रांतील आणि प्रकारांतील 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 चे मूल्यमापन exact-span F1 वापरून करतो, ज्यासाठी अंदाजित स्पॅन संदर्भ सीमांशी तंतोतंत जुळणे आवश्यक असते. एक्सट्रॅक्टिव्ह QA साठी अक्षर-स्तरीय (character-level) F1 वापरले जाते, जे उत्तराच्या मजकुराशी अंशतः जुळणाऱ्या भागासाठी आंशिक श्रेय देते, तर संरचित माहिती-निष्कर्षणासाठी फील्ड अचूकता वापरली जाते, म्हणजेच योग्यरित्या काढलेल्या फील्डचे प्रमाण. CV पार्सिंगसाठी, आम्ही NER आणि PII च्या exact-span 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}
}