कोड जनरेशन म्हणून सर्चचा पुनर्विचार करणे

AI सिस्टीम्ससाठी सर्च हा एक मूळ घटक आहे. फ्रंटियर मॉडेल्स दरमहा अधिक सक्षम होत आहेत, परंतु त्यांना अजूनही विस्तृत जगाकडून ताजी, अचूक आणि उत्तम प्रकारे क्युरेट केलेल्या ज्ञानाच्या प्रवेशाची आवश्यकता आहे. सर्च हा AI सिस्टीम्सचा त्या ज्ञानापर्यंत पोहोचण्याचा प्राथमिक मार्ग आहे, आणि अशा प्रकारे निष्कर्ष काढणे, कृती करणे आणि वास्तविक जगातील कार्ये पार पाडणे आवश्यक असलेल्या कोणत्याही उत्पादनाचा हा एक पायाभूत घटक आहे.

आमचा विश्वास आहे की एजंट्सच्या युगात पारंपारिक सर्च पाइपलाइन अधिकाधिक कालबाह्य होत आहेत. पारंपारिक सर्च प्रश्नांची उत्तरे देतो, परंतु आजचे एजंट अशी कार्ये पूर्ण करतात ज्यांचे अनेक प्रकार असू शकतात. या कार्यांसाठी एजंट्सना थेट त्यांच्या हार्नेसमध्ये कार्य-विशिष्ट पुनर्प्राप्ती धोरणे परिभाषित करणे आवश्यक असते. Perplexity Computer मध्ये, आम्ही पाहिले आहे की एकाच कार्यामुळे काही मिनिटांत शेकडो किंवा हजारो पुनर्प्राप्ती ऑपरेशन ट्रिगर होऊ शकतात: हा एक असा वर्कफ्लो आहे जो मानवांसाठी अशक्य आहे परंतु एजंट्ससाठी पूर्णपणे नैसर्गिक आहे.

या जगात, सर्च स्वतः एजंट्स बनले पाहिजे, ज्याचे बिल्डिंग ब्लॉक थेट एजंट हार्नेसमध्ये SDK म्हणून उपलब्ध आहेत. आम्ही Perplexity ची नवीन संदर्भ सर्च आर्किटेक्चर म्हणून Search as Code (SaC) सादर करत आहोत.

Perplexity चे सर्च स्टॅक आमच्या सर्व उपयोगांमध्ये आणि API प्लॅटफॉर्मवर दर सेकंदाला हजारो क्वेरींना सर्व्ह करते. सप्टेंबर २०२५ मध्ये, आम्ही आमच्या सर्च सिस्टीम्सचा पहिला आर्किटेक्चरल आढावा प्रकाशित केला. या सिस्टीममधील सातत्यपूर्ण नाविन्यामुळे Search API, Agent API, आणि Computer सारख्या नवीन ऑफरिंगच्या लाँचला समर्थन मिळाले आहे, ज्यामध्ये प्रत्येक दिवसागणिक वापरकर्त्यांना अधिक चांगल्या प्रकारे सेवा देण्यासाठी सर्च स्टॅक ऑप्टिमाइझ करणारे सेल्फ-इम्प्रूव्हमेंट लूप्स आहेत.

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

पारंपारिक सर्च आर्किटेक्चर एक सिंगल फिक्स सिस्टीम उघड करतात जी मॉडेल्स मालिकेने कॉल करतात, तर Search as Code ॲटॉमाइज्ड सर्च प्रिमिटिव्ह्ज उघड करतो जे एजंट जनरेट केलेल्या कोडद्वारे एकत्र करतात.

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

मुख्य अडथळा अखेरीस नियंत्रणाचा असतो. फ्रंटियर मॉडेल्स स्थिर संदर्भावर तर्क करण्यामध्ये आधीच बरीच चांगली आहेत. तथापि, सर्वात शक्तिशाली AI प्रणालींना हा संदर्भ कसा पुनर्प्राप्त, प्रक्रिया, एकत्रित आणि मॉडेलला सादर केला जातो हे कसे नियंत्रित करण्याची क्षमता लागेल.

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

ही गरज पूर्ण करण्यासाठी, आम्ही आमच्या उत्पादनांमध्ये एक नवीन सर्च आर्किटेक्चर सादर करत आहोत: Search as Code (SaC). हे नवीन आर्किटेक्चर मॉडेल्सना केवळ अंतिम परिणामांचा वापर करण्याऐवजी थेट सर्च स्टॅकमध्ये प्रवेश करण्यास सक्षम करते. मूळ कल्पना सोपी आहे: आम्ही SDK मधील प्रिमिटिव्ह्ज म्हणून सर्च स्टॅकचे घटक उघड करतो. सर्चची आवश्यकता असलेल्या कोणत्याही विनंतीसाठी, मॉडेल हे प्रिमिटिव्ह्ज ऑन-डिमांड एका विशिष्ट विनंतीसाठी तयार केलेल्या पुनर्प्राप्ती पाइपलाइनमध्ये एकत्र करते.

ही पाइपलाइन एकत्रित करणे सुरक्षित सँडबॉक्समधील कोड जनरेशन आणि एक्झिक्युशनद्वारे केले जाते. सर्चसाठी इतर कोडजेन-चालित दृष्टिकोनांच्या विपरीत, आम्ही शेक किंवा भाषा रनटाइममध्ये पारंपारिक सर्च API फक्त इन्सर्ट करत नाही. त्याऐवजी, आम्ही एक एजंटिस सर्च SDK काळजीपूर्वक डिझाइन केले आहे जे सर्चचे वैयक्तिक बिल्डिंग ब्लॉक शक्य तितक्या ॲटॉमिक स्तरावर उघड करते.

Search as Code (SaC) विविध बेंचमार्कच्या सुइटमध्ये एजंटिस सर्चची कामगिरी मर्यादा वाढवते.

या बिल्डिंग ब्लॉक्ससह सज्ज, SaC मॉडेलना प्रत्येक वैयक्तिक सर्च स्टेपवर थेट नियंत्रण देते: पुनर्प्राप्ती, रँकिंग, फिल्टरिंग, फॅनआउट्स, रेन्डरिंग आणि बरेच काही. हे मॉडेलला उमेदवार याद्या आणि रँकिंग सिग्नल सारख्या मध्यवर्ती स्थितीमध्ये कार्यक्षम प्रवेश देखील देते. एकत्रितपणे, नियंत्रण आणि सुवाच्यता या दोन्ही जोड्या एजंट्सना हजारो पुनर्प्राप्ती ऑपरेशन्स पसरवणाऱ्या बेस्पोक सर्च पाइपलाइन डिझाइन करण्यास, इन-फ्लाइट त्या पाइपलाइन ऑप्टिमाइझ करण्यास आणि मॉडेल संदर्भ म्हणून केवळ सर्वात उपयुक्त माहिती वापरण्यास अनुमती देतात.

हा लेख SaC ची प्रेरणा, डिझाइन आणि अंमलबजावणी यांचे वर्णन करतो, तसेच विद्यमान आणि नवीन दोन्ही बेंचमार्कवर अनुभवजन्य परिणाम सादर करतो. SaC एजंटिस सर्चसाठी नवीन खर्च-कार्यक्षमता सीमा स्थापित करते, आणि आम्ही ते आमच्या वापरकर्त्यांसोबत आणि व्यापक AI समुदायासोबत सामायिक करण्यास उत्सुक आहोत.

जगातील पहिले सर्च इंजिन मानवी वापरकर्त्यांसाठी तयार केले गेले होते. या वापरकर्त्यांना एका अंदाजे अनुभवाची अपेक्षा होती, ज्यामध्ये सामान्यत: सुसंगतता-रँक केलेल्या कागदपत्रांची निश्चित संख्या समाविष्ट असते. वापरकर्त्यांना सर्च प्रक्रियेचे मायक्रोमॅनेजमेंट करायचे नव्हते; त्यांना एक क्वेरी प्रविष्ट करायची होती आणि एक उपयुक्त परिणाम शोधायचा होता.

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

नंतर LLMs आले, आणि AI सिस्टीम देखील सर्चचे ग्राहक बनले. Perplexity ने २०२२ मध्ये आमच्या उत्तर इंजिनच्या लाँचसह या बदलाची सुरुवात केली. तेव्हापासून, आमच्या सर्च अभियांत्रिकी प्रयत्नांनी AI मॉडेल्ससाठी सर्च परिणामांचे मूल्य कसे ऑप्टिमाइझ करावे यावर लक्ष केंद्रित केले आहे. जगातील सर्वात अचूक आणि विश्वासार्ह AI तयार करण्यासाठी, आम्हाला प्रत्येक टोकन शक्य तितके माहिती-दाट बनवण्यावर लक्ष केंद्रित करणारी सर्च सिस्टीम इंजिनिअर करावी लागली. उप-दस्तऐवज पुनर्प्राप्ती, संदर्भ कार्यक्षमता, सिमेंटिक समज आणि इतर प्रमुख क्षेत्रांमधील परिणामी नवकल्पनांमुळे माहिती पुनर्प्राप्त करण्याची आणि त्यावर कृती करण्याची AI सिस्टीमची क्षमता नाटकीयरीत्या सुधारली.

तथापि, AI-ऑप्टिमाइझ केलेल्या सिस्टीमने देखील पारंपारिक सर्च इंजिनचा समान मूलभूत करार मोठ्या प्रमाणावर स्वीकारला आहे: क्वेरी स्वीकारा, पूर्वनिर्धारित सर्च पाइपलाइन चालवा, पूर्णपणे प्रक्रिया केलेले परिणाम संच परत करा. साध्या विनंत्यांसाठी, हा दृष्टिकोन चांगला चालतो. परंतु अधिक गुंतागुंतीच्या विनंत्यांसाठी, हा एक अधिकाधिक मर्यादित करणारा बॉटलनॅक बनतो जो कार्यक्षमता, विलंब (latency) आणि खर्च खराब करतो.

पारंपारिक सर्च सिस्टीम एजंटिस वर्कफ्लोना मॉडेल-दृश्यमान वळणांद्वारे सर्च अनुक्रमित करण्यास भाग पाडतात. मॉडेल्सना वेगवेगळ्या क्वेरी पॅरामीटर्सवर वारंवार समान सर्च पाइपलाइन कॉल करणे आवश्यक असते आणि सर्व परिणाम मॉडेल संदर्भात समाविष्ट करणे आवश्यक असते.

पारंपारिक सर्च पाइपलाइन एकाच नियंत्रण बिंदूभोवती डिझाइन केल्या आहेत: क्वेरी पॅरामीटर्स. सर्च इंजिन त्याच्या पूर्वनिर्धारित लॉजिकनुसार पाइपलाइनच्या बाकीच्या भागाची मालकी घेते आणि मॉडेलला त्यानुसार अनुकूल करावे लागते. मॉडेलसाठी, क्वेरी पॅरामीटर्सच्या खालील कोणतीही गोष्ट कडक असते—वास्तविक संगणनाची रचना मॉडेलच्या नियंत्रणाबाहेर असते.

ग्राहक जेव्हा लिंक्स स्कॅन करणारा माणूस असतो तेव्हा ही एक समजण्याजोगी सीमा असते. बंद लूपमध्ये ज्ञान-केंद्रित समस्या सोडवण्याचा प्रयत्न करणारे AI मॉडेल जेव्हा ग्राहक असते तेव्हा ती एक खराब सीमा असते. आमच्या अनुभवानुसार, या कडकपणामुळे तीन पुनरावृत्ती होणारे अपयश मोड तयार होतात:

कठोर संदर्भ (Coarse context). AI मॉडेल्स संदर्भाच्या गुणवत्तेबद्दल आणि संक्षिप्ततेबद्दल संवेदनशील असतात. गुणवत्ता आणि संक्षिप्तता दोन्ही अत्यंत क्वेरी-अवलंबून असतात आणि मोनोलिथिक सर्च पाइपलाइन सर्व क्वेरींवर इष्टतमपणे कार्य करण्यासाठी डिझाइन केलेल्या नसतात. उदाहरणार्थ, जर मॉडेलला माहितीचा एकच, अत्यंत सर्जिकल तुकडा हवा असेल परंतु रिकॉलला प्राधान्य देणाऱ्या एंड-टू-एंड सर्च एंडपॉइंटवर फक्त प्रवेश असेल, तर ते एंडपॉइंट वापरल्याने मॉडेल संदर्भात मोठ्या प्रमाणावर अप्रासंगिक माहिती समाविष्ट होईल. दुसरीकडे, जर मॉडेलला माहितीचे अनेक तुकडे हवे असतील ज्यांना प्रत्येकाला वेगवेगळ्या सर्च धोरणांची आवश्यकता असेल, तर त्यांना सर्वांसाठी समान सबऑप्टिमल पाइपलाइन वारंवार कॉल करण्यास भाग पाडले जाऊ शकते, परिणामी खर्च वाढवणे आणि नोइजी संदर्भ मिळणे.

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

अकार्यक्षम नियंत्रण प्रवाह आणि संदर्भ प्रदूषण (Inefficient control flow and context pollution). बरेच सर्च वर्कफ्लो नैसर्गिकरित्या मालिका नसतात. त्यांना क्वेरी प्रकारांवर फॅन-आउट, समांतर फेचिंग, डुप्लिकेट काढणे आणि इतर ऑपरेशन्सची आवश्यकता असू शकते ज्यासाठी नॉनलाइनर आणि असिंक्रोनस नियंत्रण प्रवाहाची आवश्यकता असते. वारंवार मॉडेल वळणांद्वारे या चरणांना सक्ती केल्याने विलंब वाढतो आणि वर्कफ्लो ऑप्टिमाइझ करणे कठीण होते. हे नोइजी मध्यवर्ती स्थितीसह मॉडेल संदर्भ देखील प्रदूषित करते जे मॉडेलच्या तर्कासाठी उपयुक्त असू शकत नाही, परिणामी खराब कामगिरी आणि अधिक वारंवार कॉम्पॅक्शन्स होतात.

AI च्या फंक्शन कॉलिंग आणि MCP युगात या आव्हानांबद्दल फारसे काही केले जाऊ शकले नाही. जेव्हा प्रत्येक सर्च ऑपरेशनला LLM इन्फरन्ससाठी स्वतःच्या राउंडट्रिपची आवश्यकता असते, तेव्हा विकासक नैसर्गिकरित्या त्या राउंडट्रिपमध्ये शक्य तितके काम पूर्ण करण्यास प्राधान्य देतात. याचा अर्थ एंड-टू-एंड सर्च पाइपलाइन ज्या मॉडेलद्वारे थेट वापरासाठी पूर्णपणे प्रक्रिया केलेले परिणाम संच परत करतात.

परिणामी, आजची बहुतेक AI-अभिममुख सर्च सिस्टीम अजूनही या मोनोलिथिक करारांतर्गत कार्य करतात. तथापि, मॉडेल बुद्धिमत्ता आणि वापरकर्त्याच्या मागण्यांमध्ये सतत वाढ झाल्यामुळे, त्या कराराचे तोटे अधिक स्पष्ट होतात. कोड-प्रथम हार्नेसच्या वर बनवलेले आजचे सर्वात प्रगत AI सिस्टीम, कार्य-विशिष्ट वर्कफ्लो कंपोज करू शकतात जे दर मिनिटाला हजारो कृती अंमलात आणतात. सर्च सिस्टीमने अद्याप ही क्षमता पूर्णपणे साकारलेली नाही.

आमचा खूप आधीपासून संशय होता की AI-नेटिव्ह सर्चसाठी योग्य सीमा स्टॅकमध्ये खाली आहे. मॉडेल्सनी केवळ सर्च इंजिनला कॉल करू नये. विशिष्ट कार्याची मागणी असताना त्यांना सर्च स्टॅकच्या वैयक्तिक भागांचे समन्वय साधण्यास सक्षम असले पाहिजे. त्यासाठी मूलभूतपणे भिन्न आर्किटेक्चरची आवश्यकता आहे.

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

आमचे नवीन Search as Code (SaC) आर्किटेक्चर या तत्त्वाचे मूर्त रूप आहे. SaC मध्ये, फंक्शन कॉलिंग किंवा MCP इंटरफेसद्वारे एकही पुनर्प्राप्ती ऑपरेशन पाठवले जात नाही. त्याऐवजी सर्व ऑपरेशन्स मॉडेल-जनरेटेड पायथन कोडद्वारे ऑर्केस्ट्रेट केले जातात. साध्या सर्च गरजांसाठी, या कोडमध्ये उच्च-स्तरीय सर्च एंडपॉइंटसाठी काही विनंत्या समाविष्ट असू शकतात. परंतु गुंतागुंतीच्या कार्यांसाठी, कोड आवश्यक तितका गुंतागुंतीचा असू शकतो, ज्यामध्ये सशर्त अंमलबजावणी, असिंक्रोनसी, समांतरता आणि विस्तृत श्रेणीतील कमी-स्तरीय प्रिमिटिव्ह्जचे कॉल समाविष्ट असतात.

Search as Code (SaC) आर्किटेक्चर Perplexity च्या सर्च इन्फ्रास्ट्रक्चरच्या वर बसलेल्या मॉडेल्स, कंप्युट सँडबॉक्स आणि एजंटिस सर्च SDK मधील स्टॅकवर अवलंबून आहे.

SaC मध्ये तीन घट्ट जोडलेले स्तर समाविष्ट आहेत:

मॉडेल्स नियंत्रण विमान म्हणून काम करतात. ते वापरकर्त्याच्या (किंवा पालक एजंटच्या) निर्देशनावर तर्क करतात, निर्देशांचे कामांमध्ये विघटन करतात, प्रत्येक कार्यासाठी कोणत्या पुनर्प्राप्ती आणि प्रक्रिया पाइपलाइन आवश्यक आहेत हे ठरवतात आणि त्या पाइपलाइन अंमलात आणण्यासाठी कोड जनरेट करतात.

कंप्युट सँडबॉक्स सुरक्षित कोड एक्झिक्युशन रनटाइमद्वारे निर्धारित संगणन प्रदान करतात. ते मॉडेल्सना नियंत्रण प्रवाह, बॅचिंग, पुनरावृत्ती, फिल्टरिंग, जॉइनिंग, एकत्रीकरण आणि इतर निर्धारित ऑपरेशन्स अंमलात आणण्यासाठी कॅनव्हास प्रदान करतात.

आमचे Agentic Search SDK Perplexity चे सर्च स्टॅक कंपोसेबल प्रिमिटिव्ह्ज म्हणून उघड करते. हे लो-लेव्हल पुनर्प्राप्ती ऑपरेशन्सपासून हाय-लेव्हल सिमेंटिक पार्सिंगपर्यंत बिल्डिंग ब्लॉक प्रदान करते. SDK सँडबॉक्सच्या एक्झिक्युशन रनटाइम्समध्ये एम्बेड केलेले आहे, ज्यामुळे मॉडेल्सना एकाच इन्फरन्स वळणात हजारो ऑपरेशन्सचे समन्वय साधण्याची परवानगी मिळते. खाली, आम्ही प्रत्येक स्तरासाठी आमच्या डिझाइन निर्णयांवर चर्चा करतो.

Agentic Search SDK प्रोग्राम करण्यायोग्य सर्चसाठी बिल्डिंग ब्लॉक्स परिभाषित करतो. विशेष म्हणजे, आमचे SDK हे लायब्ररी म्हणून पॅकेज केलेले पूर्व-विद्यमान सर्च API नाही. गेल्या काही महिन्यांत, आमची अभियांत्रिकी टीम आमच्या सर्च स्टॅकची मॉड्यूलर, कंपोसेबल प्रिमिटिव्ह्जमध्ये पुनर्रचना करत आहे. मॉडेल कार्य-विशिष्ट पुनर्प्राप्ती पाइपलाइनचे समन्वय साधू शकेल असा अधिक शक्तिशाली कॅनव्हास तयार करण्यासाठी आम्ही Agentic Search SDK तयार केले आहे.

उच्च-स्तरीय, एंड-टू-एंड सर्च पाइपलाइन अद्याप SDK मध्ये उपलब्ध आहेत, परंतु ते आता एकमेव पर्याय नाहीत. त्याऐवजी, ते सामान्य सर्च पॅटर्नसाठी शॉर्टहँडचे रूप म्हणून काम करतात. कार्याची मागणीनुसार मॉडेल त्यांचा वापर करण्यास किंवा बायपास करण्यास मोकळे आहे.

रनटाइमची निवड: आम्ही SDK रनटाइम म्हणून Python, Rust, TypeScript आणि Bash चा विचार केला. आम्हाला शंका होती की Python त्याच्या सर्वव्यापी आणि डेटा प्रोसेसिंग लायब्ररीच्या इकोसिस्टममुळे सर्वात नैसर्गिक फिट असेल. अंतर्गत चाचणीने हे सिद्ध केले, आणि आज रोल आउट होत असलेली SDK ची आवृत्ती Python-आधारित आहे. ते एजंटचा सर्वोत्तम अनुभव प्रदान करत राहतील याची खात्री करण्यासाठी आम्ही वेळोवेळी रनटाइमच्या निवडीचे पुनर्मूल्यांकन करण्याची अपेक्षा करतो.

ऑटोर्सर्च द्वारे सतत सुधारणा: आम्ही आयटरेटिव्ह ऑटोर्सर्च लूपद्वारे फ्रंटियर LLMs साठी SDK ची वापरण्यायोग्यता देखील ऑप्टिमाइझ केली आहे. हे लूप, आठवडे सतत चालत असताना, विलंब, कोडजेन गुणवत्ता आणि एकूण कार्य कामगिरीसह मेट्रिक्स विरुद्ध SDK सुधारणा प्रस्तावित आणि सत्यापित करते. ऑटोर्सर्च लूपने आधीच SDK ची रचना आणि सौंदर्यशास्त्र दोन्हीमध्ये असंख्य बदल केले आहेत, सर्व परिमाणांमध्ये महत्त्वपूर्ण फायद्यांसह. नवीन फ्रंटियर मॉडेल्स आणि सर्च घटक उदयास आल्यावर आम्ही ऑटोर्सर्चद्वारे SDK चे आणखी परिशोधन करण्याची योजना आखत आहोत.

सँडबॉक्स SaC पाइपलाइन परिभाषित आणि चालवण्यासाठी सुरक्षित वातावरण प्रदान करतात. ते वैयक्तिक सर्च प्रिमिटिव्ह्जशी संवाद साधण्यास सुलभ करण्यासाठी Agentic Search SDK मध्ये प्रवेश प्रदान करून, मॉडेल-जनरेटेड कोड कार्यान्वित करतात.

आम्ही आमचे सँडबॉक्स ऑप्टिमाइझ करण्यासाठी आणि कठीण करण्यासाठी महत्त्वपूर्ण गुंतवणूक केली आहे, आणि त्यांची सर्वसमावेशक सिस्टीम डिझाइन स्वतःच्या लेखास पात्र आहे. येथे, आम्ही SaC शी सर्वात संबंधित असलेल्या डिझाइन विचारांवर लक्ष केंद्रित करतो: मध्यवर्ती स्थिती व्यवस्थापित करणे.

SaC एजंट्सना एकाच इन्फरन्स वळणामध्ये जटिल पाइपलाइनचे समन्वय साधण्यास सक्षम करते. तथापि, काही मध्यवर्ती स्थिती वळणांवर पोहोचवणे आवश्यक आहे. उदाहरणार्थ, मॉडेलला वळण 1 मध्ये काही दस्तऐवज फेच करायचे असतील, पुढे काय करावे हे ठरवण्यासाठी वळण 2 मध्ये त्या कागदपत्रेचे उपनमुना तपासणे आणि नंतर वळण 3 पासून त्या कागदपत्रांची आणखी तपासणी करण्यासाठी डाउनस्ट्रीम सर्च पाइपलाइन विकसित करणे आवश्यक असू शकते. वर चर्चा केल्याप्रमाणे, टोकन स्पेसद्वारे मध्यवर्ती स्थिती पास करणे ही प्रभावी धोरण नाही.

आम्ही वळणांवर मध्यवर्ती स्थिती व्यवस्थापित करण्यासाठी दोन दृष्टिकोनांचा विचार केला:

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

REPL: वैकल्पिकरित्या, सँडबॉक्स REPL-शैलीच्या वातावरणात वळणांवर एक्झिक्युशन रनटाइम स्वतः कायम ठेवू शकतो. यामुळे मॉडेल्सना सिरीलायझेशन करण्याची गरज न पडता इन-मेमरी मध्यवर्ती स्थिती राखता येते, कारण मागील वळणांवर परिभाषित केलेले किंवा बदललेले व्हेरिएबल्स त्यानंतरच्या वळणांवर नावावरून संदर्भित केले जाऊ शकतात. serde कोड जनरेट करण्याची गरज टाळल्यामुळे REPL दृष्टिकोन अधिक टोकन-कार्यक्षम आहे. तथापि, स्पष्ट सिरीलायझेशन चरणाचा अभाव १००-सेल Jupyter नोटबुकसह काम केलेल्या कोणालाही परिचित असलेल्या कारणांमुळे डाउनस्ट्रीम कामगिरीला हानी पोहोचवू शकतो: जसजसे व्हेरिएबल नेमस्पेस गोंधळात पडतो, तसतसे वळणांवर नक्की काय टिकून राहते आणि का याचा मागोवा घेणे अधिक कठीण होते.

आम्ही दोन्ही दृष्टिकोनांची चाचणी केली आणि असे आढळले की ते सामान्य वापरात समान कामगिरी करत असताना, फाइलसिस्टम-आधारित serde विशेषतः लांब ट्रॅजेक्टरीजवर अधिक विश्वसनीयता प्रदान करते. त्यामुळे आम्ही फाइलसिस्टम-आधारित serde आमचा उपाय म्हणून स्वीकारतो. आमचा असा अंदाज आहे की मॉडेल्सना अंतर्हित ऐवजी घोषणात्मक मार्गाने राज्य पोहोचवणे आवश्यक आहे ज्यामुळे त्यांना ते राज्य अधिक प्रभावीपणे व्यवस्थापित करण्यास मदत होते. हा एक तात्पुरता निष्कर्ष आहे आणि आम्ही दोन्ही दृष्टिकोनांवर पुनरावृत्ती करत राहू.

एजंट हार्नेसला शक्ती देणारी मॉडेल्स SaC चे नियंत्रण विमान म्हणून काम करतात: प्रत्येक कार्याची गरज पूर्ण करण्यासाठी Agentic Search SDK च्या बिल्डिंग ब्लॉक्समधून सर्च पाइपलाइन गतिमानपणे एकत्र करणे, नंतर सँडबॉक्स अंमलबजावणीसाठी कोड म्हणून त्या पाइपलाइन पाठवणे.

Perplexity आमच्या एजंट हार्नेसमध्ये विविध प्रकारच्या मॉडेल्सचा वापर करते, आणि आम्हाला सामान्य-हेतू कोड जनरेशनवर सर्व आघाड्यांवर नवीनतम फ्रंटियर मॉडेल्स oldukça प्रभावी असल्याचे आढळले आहे. मुख्य आव्हान विशेषतः Agentic Search SDK साठी प्रभावी कोड जनरेशन प्रेरित करणे आहे. म्हणजेच, मॉडेल्स आमच्या SDK चे बिल्डिंग ब्लॉक कार्य-ऑप्टिमाइझ केलेल्या पाइपलाइनमध्ये कसे प्रभावीपणे विणू शकतात?

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

या पहिल्या आव्हानात्मक भागासाठी, आम्ही मॉडेल्सना आमचा SDK प्रभावीपणे वापरण्यास शिकवण्यासाठी अत्यंत सूक्ष्मरित्या समायोजित Agent Skills विकसित केले आहेत. सुरुवातीच्या आवृत्त्या Perplexity च्या Skills साठीच्या डिझाइन तत्त्वांनुसार विकसित करण्यात आल्या, आणि नंतर SDK ऑप्टिमायझेशनमध्ये वापरल्या जाणाऱ्या त्याच मेट्रिक्सवर लक्ष केंद्रित केलेल्या समर्पित autoresearch लूपद्वारे त्यांचे ऑप्टिमायझेशन करण्यात आले. संदर्भाचा अनावश्यक विस्तार टाळण्यासाठी आम्ही skill आकारावरही मर्यादा घालतो, आणि आमच्या अंतिम आवृत्त्यांमध्ये त्यांच्या मूळ SKILL.md फाइल्समध्ये 2000 पेक्षा कमी टोकन्स आहेत.

ऑप्टिमाइझ केलेले कौशल्ये SDK चे उपलब्ध बिल्डिंग ब्लॉक सूचीबद्ध करण्याच्या पलीकडे जातात (काहीतरी जे रनटाइम रिफ्लेक्शनद्वारे सहज मिळू शकते). टोकन्सचा मोठा भाग हे ब्लॉक जटिल पॅटर्नमध्ये कंपोज करण्यासाठी संक्षिप्त, सामान्य करण्यायोग्य मार्गदर्शन आणि काही-शॉट उदाहरणे प्रदान करण्यासाठी खर्च केले जातात. या कौशल्यांसह सज्ज, आम्ही मॉडेल्सना हजारो विविक्त ऑपरेशन्सपर्यंत मोजमाप करणाऱ्या सर्च पाइपलाइनचे समन्वय साधण्यासाठी SDK चा प्रभावीपणे लाभ घेताना पाहतो.

हे स्तर एकत्र करून, SaC मॉडेल्स आणि सर्च स्टॅक यांच्यातील संबंध बदलतो. निश्चित-पाइपलाइन सर्च सिस्टीममध्ये, मॉडेल सर्चच्या वर बसते आणि संकुचित सिरियल कॉलर इंटरफेसद्वारे त्याच्याशी संवाद साधते. SaC मध्ये, मॉडेल सर्च प्रक्रिया स्वतः आयोजित करण्यात सक्रिय भागीदार बनते. सर्च स्टॅकचे सर्व घटक मॉडेलद्वारे थेट प्रोग्राम करण्यायोग्य बनतात, सँडबॉक्स आणि Agentic Search SDK त्या घटकांना आवश्यक इंटरफेस प्रदान करतात.

परंतु ज्या क्षमता मुळात अस्तित्वात नाहीत त्यांचे काय? पूर्व-विद्यमान क्षमतांचे समन्वय साधण्यासाठी कोड हे एक शक्तिशाली माध्यम आहे. तरीही कोडची शक्ती समन्वयाच्या पलीकडे जाते. सर्च स्टॅक किंवा SDK मध्ये उपस्थित नसलेल्या क्षमतांसाठी हे गॅप-फिलर म्हणून देखील काम करू शकते. एजंट्सना पार्सिमनीचा फायदा होतो, आणि SDK ने प्रत्येक संभाव्य ऑपरेशनला समर्पित फंक्शनसह झाकणे अकार्यक्षम ठरेल. त्याऐवजी, SDK सर्वात मूलभूत प्रिमिटिव्ह्ज प्रदान करते, आणि मॉडेल कोडसह फ्लाइटवर कोणतेही अतिरिक्त घटक तयार करू शकते.

उदाहरणार्थ, एक जटिल regex घ्या जी सर्च सिस्टीमच्या स्वतःच्या क्वेरी सिंटॅक्सद्वारे कार्यक्षमतेने अंमलात आणण्यायोग्य नाही. कोडिंग क्षमतांशिवाय, मॉडेलला त्याचे सर्वोत्तम अंदाजे जनरेट करण्यास, क्वेरी करण्यास आणि अत्यंत नोइजी परिणाम संचावर टोकन-स्पेस फिल्टरिंग करण्यास भाग पाडले जाईल. SaC सह, मॉडेल त्याऐवजी एक प्रोग्राम जनरेट करू शकते जो इच्छित regex च्या परिणाम संचाचा सुपरसेट गोळा करण्यासाठी समांतर SDK कॉल करतो. SDK द्वारे डुप्लिकेट काढून टाकल्यानंतर, मॉडेल नंतर परिणाम अचूक regex मध्ये निश्चितपणे कमी करण्यासाठी अतिरिक्त कोड लिहू शकते. या मार्गाने, एजंट SDK ला अतिशय विशिष्ट सबाउटीनसह फुगवल्याशिवाय सानुकूल सर्च क्षमता लागू करू शकतात.

आम्ही आमच्या चाचणी सुइटमधील वास्तविक जगाच्या कार्यावर आधारित केस स्टडी सादर करतो. हे कार्य एजंटला २०२३-२०२५ मधील २०० पेक्षा जास्त उच्च-गंभीर CVE ओळखण्यास आणि वैशिष्ट्यीकृत करण्यास सांगते. प्रत्येक रेकॉर्डने प्रभावित विक्रेत्याचा स्वतःचा सल्लागार उद्धृत केला पाहिजे, उत्पादन आणि निराकरण आवृत्तीचे नाव दिले पाहिजे आणि निराकरण आवृत्ती विशिष्ट CVE शी जोडलेली असल्याचे दर्शवले पाहिजे.

SaC च्या उत्तराने अचूकतेवर १००% गुण मिळवले, नॉन-SaC बेसलाइनच्या तुलनेत एकूण टोकन वापर ८५.१% कमी झाला (२८८.७K टोकन्स वरून ४२.९K टोकन्सवर). विभाग ४ मध्ये अधिक तपशीलात चर्चा केलेले, चाचणी केलेले नॉन-Perplexity सिस्टीम सर्व २५% पेक्षा कमी गुण मिळवले.

SaC ची प्रोग्रामेबिलिटी मॉडेलला प्रभावी धोरणे लागू करण्यास कशी अनुमती देते हे स्पष्ट करण्यासाठी आम्ही ट्रॅजेक्टोरी मधील तीन स्टायलाइज्ड कोड ब्लॉक सादर करतो.

python

# Part 1 of 3: fan out over official advisory formats.
templates = [
    ("Mozilla",
     'site:mozilla.org/en-US/security/advisories/mfsa{year} '
     '"CVE-{year}-" "Fixed in" "Impact high"'),
    ("Jenkins",
     'site:jenkins.io/security/advisory/{year} '
     '"CVE-{year}" "Severity" "High" "Fix"'),
    ("Chrome",
     'site:chromereleases.googleblog.com/{year} '
     '"High CVE-{year}" "Stable channel has been updated"'),
    ("Android",
     'source.android.com/docs/security/bulletin/{year}-{month:02d}-01 '
     '"High" "CVE-{year}"'),
    ...
]

queries = [
    {"vendor": vendor, "query": pattern.format(year=year, month=month)}
    for year in [2023, 2024, 2025]
    for vendor, pattern in templates
    for month in ([1] if "{month" not in pattern else range(1, 13))
]

seed_hits = sdk.search.web_many(queries, limit_per_query=8, concurrency=12)

pages = [
    {"vendor": q["vendor"], "url": h.url, "text": join_result_fields(h)}
    for q, hits in zip(queries, seed_hits)
    for h in hits
    if official_vendor_advisory(h.url, q["vendor"])
]

हा पहिला ब्लॉक पूर्णपणे orchestration आहे. तयार झालेला प्रोग्राम source-class नियम थेट query plan मध्ये encode करून सुरुवात करतो: केवळ vendor-मालकीचे advisory formats संबंधित आहेत. NVD, MITRE, CVE Details, बातम्या, CERT पृष्ठे, आणि तृतीय-पक्ष डेटाबेसेससह non-vendor स्रोत संरचनात्मकदृष्ट्या scope बाहेर आहेत. exact-phrase निर्बंधही search ला अशा पृष्ठांकडे वळवतात ज्यांचा indexed text downstream साठी आवश्यक असलेले नेमके CVE details आधीपासूनच समाविष्ट करतो.

python

# Part 2 of 3: synthesize refinements for sparse vendor-years.
coverage = summarize(pages, by=["vendor", "year", "url_kind"])

prompt = """
Goal: 230+ high or critical CVEs from official vendor advisories.
Avoid aggregators, CERTs, news, NVD, MITRE, and CVE databases.
Current coverage:
{coverage}
Suggest more site-scoped exact-phrase queries for sparse vendor-years.
Prefer per-advisory pages over archive or month-index pages.
Return JSON lines with vendor and query.
""".format(coverage=coverage)

raw = query_llm(prompt)

expanded_queries = [
    row for row in parse_jsonl(raw)
    if official_scope(row["query"]) and mentions_cve_year(row["query"])
]

expanded_hits = sdk.search.web_many(
    unique(expanded_queries),
    limit_per_query=8,
    concurrency=12,
)

दुसरा ब्लॉक intermediate planning subroutine म्हणून LLM चा वापर करतो. कोणते vendor-year जोडपे पुरेश्या candidate pages तयार करत आहेत हे code सारांशित करते, targeted refinements विचारते, आणि execution पूर्वी प्रत्येक प्रस्तावित query ची पडताळणी करते. यामुळे trajectory मधील उपयुक्त patterns—जसे site-scoped exact-phrase probes आणि adaptive backfilling—जतन होतात, आणि SDK मध्ये bespoke CVE-advisory crawler hardcode करावा लागत नाही.

python

# Part 3 of 3: verify CVE-to-version binding.
all_hits = dedupe_by_url(flatten(seed_hits) + flatten(expanded_hits))

items = [
    {"url": h.url, "vendor_hint": infer_vendor(h.url),
     "text": join_result_fields(h)}
    for h in all_hits
    if official_vendor_advisory(h.url, infer_vendor(h.url))
]

verified = sdk.llm.extract_many(
    items,
    instruction=(
        "Keep only vendor advisories where the page ties a high or critical "
        "CVE to a specific fixed version, build, patch, or security level."
    ),
    schema={
        "matches": bool,
        "cve": str,
        "vendor": str,
        "product": str,
        "fix_version": str,
        "severity": str,
        "source_url": str,
        "evidence": str,
        "version_bound_to_cve": bool,
        "confidence": float,
    },
)

records = [
    to_cve_record(x) for x in verified
    if x.matches and x.version_bound_to_cve
    if high_or_critical(x.severity) and x.confidence > 0.75
]
records = dedupe_by(records, key="cve")

अंतिम ब्लॉक हा एक परिणाम पडताळणी करणारा आहे ज्याचे लॉजिक कोडजेन द्वारे एजंटद्वारे पूर्णपणे परिभाषित केले जाते. सर्च सबाउटीन प्रशंसनीय सल्लागार पृष्ठे शोधू शकतात, परंतु कार्यासाठी कठोर संबंधांची आवश्यकता असते: सल्लागाराने विक्रेता-लिखित मजकुरात एका CVE ला एका प्रभावित उत्पादनाशी आणि एका निराकरण आवृत्तीशी जोडले पाहिजे. स्कीमा तो संबंध स्पष्ट करतो, जेणेकरून डाउनस्ट्रीम कोड CVE द्वारे डुप्लिकेट काढून टाकू शकेल, अॅग्रीगेटर URL नाकारू शकेल, दुर्बल आवृत्ती पुरावे टाकून देऊ शकेल आणि रेकॉर्ड-संख्या फ्लोर मिळेपर्यंत बॅकफिलिंग चालू ठेवू शकेल.

आम्ही संपूर्ण बेंचमार्क सुइटवर SaC च्या प्रभावाचे मूल्यांकन करतो, संपूर्ण कामगिरी आणि खर्च-कार्यक्षमता सीमा या दोन्हीवर लक्ष केंद्रित करतो.

आमच्या बेंचमार्क सुइटमध्ये एकूण पाच बेंचमार्क समाविष्ट आहेत, जे डोमेन, कार्य स्वरूप आणि जटिलता स्तरांच्या श्रेणीमध्ये सर्च-अवलंबून AI वर्कफ्लो ताणण्यासाठी डिझाइन केलेले आहेत. आम्ही चार पूर्व-विद्यमान बेंचमार्क वापरतो: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE), आणि WideSearch. पहिल्या तीन बेंचमार्कसाठी (DSQA, BrowseComp, आणि HLE), आम्ही टॉपलाइन मेट्रिक म्हणून अचूकता नोंदवतो. WideSearch साठी, आम्ही ओळीनुसार F1 स्कोअर नोंदवतो.

आम्ही नवीन विकसित केलेले WANDR बेंचमार्क देखील वापरतो, जे सर्च, संगणन आणि मॉडेल तर्काचे काळजीपूर्वक समन्वय आवश्यक असलेल्या कठीण “वाइड रिसर्च” कार्यांवर लक्ष केंद्रित करते. WANDR हे Perplexity Computer वापरकर्त्यांसाठी हाताळणाऱ्या ज्ञान-केंद्रित व्यावसायिक कार्यांमुळे प्रेरित आहे. हे WideSearch आणि तत्सम बेंचमार्कवर पुनरावृत्ती करते, परंतु अधिक गुंतागुंतीच्या कार्यांवर आणि कार्य संरचनांवर जोर देते. आम्ही आगामी आठवड्यात WANDR बेंचमार्क प्रकाशित करू.

आम्ही पाच एजंट-आधारित सिस्टीमचे मूल्यांकन करतो. समांतरतेच्या फायद्यांऐवजी अंतर्निहित आर्किटेक्चरची कामगिरी वेगळी करण्यासाठी आम्ही “सर्वोत्कृष्ट-ऑफ-N” गुणांऐवजी वैयक्तिक चालवण्याचा विचार करतो. प्रत्येक सिस्टीमचे कॉन्फिगरेशन खाली वर्णन केले आहे:

Perplexity (SaC): आम्ही Perplexity च्या उत्पादन एजंट API मधील SaC आर्किटेक्चरचे मूल्यांकन करतो. GPT ५.५ (उच्च तर्क) अंतर्निहित मॉडेल म्हणून काम करतो.

OpenAI: आम्ही सर्च (web_search) आणि पायथन रनटाइम (code_interpreter) दोन्ही सक्षम करून OpenAI Responses API चे मूल्यांकन करतो. GPT ५.५ (उच्च तर्क) अंतर्निहित मॉडेल म्हणून काम करतो.

Anthropic: आम्ही २००६०४०१ एजंट टूलसेट आणि स्वयं-परवानगी कमांडसह Anthropic Managed Agents चे मूल्यांकन करतो. Opus ४.७ (उच्च तर्क) अंतर्निहित मॉडेल म्हणून काम करतो.

Exa: आम्ही उत्पादन API द्वारे Exa Agent चे मूल्यांकन करतो, प्रयत्न उच्च वर सेट केले आहेत.

Parallel: आम्ही उत्पादन API द्वारे Parallel Tasks चे मूल्यांकन करतो, प्रोसेसर ultra4x वर सेट केला आहे.

तक्ता 1 प्रत्येक सिस्टीमसाठी बेंचमार्क स्कोअर नोंदवतो. पाच पैकी चार बेंचमार्कवर SaC इतर सर्व सिस्टीमपेक्षा वरचढ ठरतो. उर्वरित बेंचमार्कवर (HLE), SaC हे OpenAI Responses सह पहिल्या स्थानासाठी अनिवार्यपणे जोडलेले आहे. परिचयातील आकृती 2 हे स्कोअर ग्राफिकल स्वरूपात दर्शवते.

बेंचमार्क	Perplexity (SaC)	OpenAI	Anthropic	Exa	समांतर (Parallel)
DSQA	०.८७१	०.७३३	०.८१५	०.५३०	०.८१०
BrowseComp	०.८०५	०.७२०	०.५९८	०.३८०	०.५६०
HLE	०.६१२	०.६१४	०.५६६	०.३८७	०.५१५
WideSearch	०.६५१	०.५२२	०.५९०	०.४७१	०.५८४
WANDR	०.३८६	०.१३०	०.१५२	०.०५७	०.१२६

तक्ता 1 | प्रत्येक मूल्यांकन केलेल्या सिस्टीमसाठी बेंचमार्क स्कोअर. प्रति ओळ सर्वोत्तम स्कोअर ठळक.

जरी SaC बेंचमार्क सुइटमध्ये अत्याधुनिक कामगिरी साध्य करत असले, तरी त्याचा फायदा WANDR वर विशेषतः उच्च आहे. आकृती 5 WANDR स्कोअर विभाजित करते, दर्शवते की Perplexity ची SaC अंमलबजावणी पुढील-सर्वोत्तम सिस्टीमपेक्षा २.५× च्या घटकाद्वारे उत्कृष्ट कामगिरी करते. या मोठ्या मार्जिन असूनही, WANDR असंतृप्त राहतो आणि SaC साठी देखील आव्हानात्मक सिद्ध होतो. आमचा विश्वास आहे की WANDR च्या कार्यांसाठी आवश्यक असलेले गुंतागुंतीचे, अत्यंत क्षैतिज सर्च वर्कफ्लो सतत उच्च कामगिरी साध्य करण्यासाठी संशोधन आणि सर्च अभियांत्रिकीमध्ये अतिरिक्त प्रगती आवश्यक करतील.

मूल्यांकन केलेल्या सिस्टीममध्ये WANDR स्कोअर. Perplexity Agent API पुढील-सर्वोत्तम सिस्टीमपेक्षा २.५× च्या फॅक्टरने पुढे आहे.

शेवटी, आम्ही समान Perplexity सर्च इन्फ्रास्ट्रक्चरचा फायदा घेणाऱ्या अधिक पारंपारिक सर्च पाइपलाइनच्या तुलनेत SaC च्या सापेक्ष लाभांचे मोजमाप करतो. आकृती 6 प्रत्येक बेंचमार्कवर SaC आणि नॉन-SaC आर्किटेक्चर मधील स्कोअरमधील फरक नोंदवते. सर्व आघाड्यांवर, SaC कामगिरीमध्ये महत्त्वपूर्ण वाढ प्रदान करतो, DSQA वर सर्वात मोठा निरपेक्ष लाभ (+१९.७७ pp, २९%) आणि WANDR वर सर्वात मोठा सापेक्ष लाभ (+१२.०० pp, ४५%) आहे.

प्रत्येक बेंचमार्कवर Perplexity बेसलाइन विरुद्ध SaC स्कोअर, निरपेक्ष आणि सापेक्ष डेल्टा एनोटेट केलेले आहेत.

सराव मध्ये, वापरकर्त्यांना खर्चाच्या सापेक्ष कामगिरीची काळजी असते. त्यामुळे आम्ही DSQA आणि WideSearch वर खर्च-कार्यक्षमता सीमेचे मूल्यांकन करतो. आम्ही इतर सिस्टीमसह कमी, मध्यम आणि उच्च मॉडेल तार्किक स्तरांवर SaC चा खर्च आणि कामगिरी मोजतो. आकृती 7 आणि 8 प्रति-कार्य किंमतीच्या विरोधात बेंचमार्क स्कोअर प्लॉट करतात, x-अक्ष उलट करून जेणेकरून अधिक उजवीकडील बिंदू स्वस्त असतात आणि उच्च बिंदू चांगली कामगिरी दर्शवतात.

DSQA स्कोअर विरुद्ध प्रति-कार्य किंमत. डॅश केलेली ओळ SaC मॉडेल तर्क कॉन्फिगरेशन जोडते.

DSQA वर, सर्व तीन SaC सेटिंग्ज वरच्या-उजव्या सीमेवर आहेत. कमी तर्क सेटिंग इतर सर्व सिस्टीमपेक्षा सस्ती आहे तर त्यापैकी दोनपेक्षा चांगली कामगिरी करते. मध्यम तर्क सेटिंग प्रति कार्य $१ पेक्षा कमी सर्व नॉन-SaC सिस्टीमपेक्षा सरस आहे. उच्च तर्क सेटिंग स्पर्धात्मक खर्चासह शीर्ष कामगिरी साध्य करते.

WideSearch स्कोअर विरुद्ध प्रति-कार्य किंमत. डॅश केलेली ओळ SaC मॉडेल तर्क कॉन्फिगरेशन जोडते.

WideSearch एक समान आकाराची frontier दर्शवते. DSQA प्रमाणेच, low reasoning setting सर्व non-SaC systems पेक्षा कमी खर्चात स्पर्धात्मक performance साधते, तर medium आणि high reasoning दोन्ही task performance मध्ये non-SaC systems पेक्षा चांगली कामगिरी करतात.

Search as Code सॉफ्टवेअर डिझाइनमधील व्यापक बदलाचे प्रतिबिंबित करतो. अनेक दशकांपासून, सॉफ्टवेअर सिस्टीम CPU वरील पारंपारिक रनटाइमद्वारे अंमलात आणलेल्या निर्धारित निर्देशांभोवती आयोजित केल्या गेल्या होत्या. फ्रंटियर मॉडेल्स संगणनाचा नवीन प्रकार அறிமுகం करतात: टोकन-स्पेस तर्क जे सूचनांचे अनुसरण आणि जनरेट दोन्ही करू शकतात. सर्वात सक्षम संगणकीय सिस्टीम या दोन प्रकारच्या संगणनाची निवड करण्याऐवजी त्यांना एकत्र करतील.

सर्च हा या हायब्रिड आर्किटेक्चरसाठी नैसर्गिक सिद्ध जमीन आहे. कोणता पुरावा आवश्यक आहे आणि अनिश्चितता कशी सोडवली पाहिजे हे ठरवण्यासाठी मॉडेल्स योग्य आहेत. निर्धारित रनटाइम बॅचिंग, समांतरता, फिल्टरिंग, रँकिंग आणि एकत्रीकरणासाठी योग्य आहेत. सर्च इन्फ्रास्ट्रक्चर सार्वत्रिक I/O स्तर म्हणून काम करते, ज्यामध्ये जगाच्या माहितीमध्ये रनटाइमला उपयुक्त हँडल प्रदान केले जातात जे प्रति मिनिट हजारो ऑपरेशन्स टिकवून ठेवू शकतात. जेव्हा हे तुकडे एकत्रित केले जातात, तेव्हा परिणामी सिस्टीम वास्तविक जगातील कार्ये साध्य करण्यासाठी अधिक शक्तिशाली आणि कार्यक्षम असते.

या क्षमता अनलॉक करण्यासाठी या आर्किटेक्चरचा प्रत्येक भाग आवश्यक आहे. बुद्धिमान मॉडेल्सशिवाय, सिस्टीम सर्च धोरणावर तर्क करू शकत नाही. सँडबॉक्सशिवाय, मॉडेल्स सिरियल I/O आणि अकार्यक्षम टोकन-स्पेस प्रोसेसिंगमध्ये भाग पाडली जातात. आणि ॲटॉमाइज्ड सर्च स्टॅकशिवाय, मॉडेलकडे समन्वय साधण्यासाठी काहीही नाही. SaC काम करते कारण तर्क, निर्धारित संगणन, आणि I/O हे प्रत्येक स्तराच्या ताकदीला हायलाइट करण्यासाठी संयुक्तपणे डिझाइन केलेले आहेत.

सतत सुधारणा लूपच्या विकासाद्वारे हे कोडिझाइन आणखी पुढे नेले जाऊ शकते. उदाहरणार्थ, Agentic Search SDK आणि SaC Agent Skills एका सामान्य ऑटोर्सर्च लूपमध्ये संयुक्तपणे ऑप्टिमाइझ केले जाऊ शकतात. अधिक महत्त्वाकांक्षीपणे, SDK म्हणून उघड केलेल्या लो-लेव्हल सर्च प्रिमिटिव्ह्जचा फायदा घेण्यासाठी मॉडेल्सना प्रशिक्षित केले जाऊ शकते. मॉडेल प्रशिक्षण प्रक्रियेदरम्यानच SDK डिझाइन सह-विकसित करण्याचा प्रयत्न केला जाऊ शकतो. भविष्यातील कामात अधिक आक्रमक कोडिझाइन धोरणांचा पाठपुरावा करण्यास आम्ही उत्सुक आहोत.

मॉडेल्सना केवळ परिणाम वापरण्याऐवजी सर्च प्रक्रिया नियंत्रित करण्याची परवानगी देण्यासाठी आम्ही SaC तयार केले. आमचे परिणाम या नियंत्रणाची शक्ती सिद्ध करतात: SaC ज्ञान-केंद्रित एजंट बेंचमार्कवर संपूर्ण कामगिरी आणि खर्च-कार्यक्षमता सीमा दोन्ही पुढे नेतो. Perplexity Computer आणि Agent API सह आजपासून सुरू करून, आम्ही आमच्या वापरकर्त्यांपर्यंत SaC ची क्षमता आणण्यास उत्सुक आहोत. आमच्या वापरकर्त्यांकडे (आणि त्यांना सेवा देणाऱ्या एजंट्सकडे) शक्य तितक्या शक्तिशाली आणि कार्यक्षम सर्च क्षमता असल्याची खात्री करण्यासाठी आम्ही स्टॅकच्या सर्व स्तरांवर SaC आर्किटेक्चर ऑप्टिमाइझ करणे सुरू ठेवू.

BibTeX

@online{perplexity2026RethinkingSearchAsCodeGeneration,
  author = {{Perplexity} and Denis Bykov and Aleksandr Nikolenko and Artur Zayats and Maksim Gaiduk and Vitalii Polshkov and Akshay Nair and James Liounis and Kirill Priemko and Ryan Buchmayer and Phi Hoang and Jerry Ma},
  title = {{Rethinking search as code generation}},
  date = {2026-06-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/rethinking-search-as-code-generation}
}

परिचय

पारंपारिक सर्चची कडकपणा (Rigidity)

कडकपणापासून अपयश मोड (Failure Modes from Rigidity)

प्रोग्राम करण्यायोग्य सर्च आर्किटेक्चर डिझाइन करणे

Agentic Search SDK

सँडबॉक्स

मॉडेल्स

ऑर्केस्ट्रेटर आणि गॅप फिलर म्हणून कोड

केस स्टडी: CVE विक्रेता सल्लागार

मूल्यांकन परिणाम

बेंचमार्क आणि सिस्टीम

तुलनात्मक कामगिरी

खर्च-कार्यक्षमता सीमा

कंप्युटिंगच्या नवीन आर्किटेक्चरच्या दिशेने

उद्धरण