फोटॉन: स्क्रॅचपासून रिट्रीव्हल आणि रँकिंग इंजिन तयार करणे

परिचय

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

ही आव्हाने पार करण्यासाठी, आम्ही फोटॉन तयार केले, एक नवीन इन-हाउस रिट्रीव्हल आणि रँकिंग इंजिन. हे CobbleDB, पेज रेकॉर्ड सर्व्ह करण्यासाठी आमचे वितरित की-व्हॅल्यू स्टोअर, आणि आमचे Search API सह केल्याप्रमाणे, स्क्रॅचपासून AI-प्रथम सर्च इन्फ्रास्ट्रक्चर तयार करण्याचा आमचा दृष्टीकोन चालू ठेवतो.

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

फोटॉन आता आमच्या सर्च पाइपलाइनला पॉवर देतो आणि आमच्या सर्च API साठी नवीन फास्ट प्रीसेटचा पाया देखील आहे, ज्यामध्ये p50 वर 160 ms आणि p95 वर 230 ms ची सिंगल-सर्च-कॉल लेटेंसी आहे. सहा सार्वजनिक बेंचमार्कवर, फास्ट प्रीसेटमुळे प्रति टास्क मॉडेल-प्लस-सर्चचा अंदाजे खर्च ६८% ने कमी झाला, तर डीफॉल्ट प्रीसेटशी तुलना करता येणारी एकत्रित टास्क गुणवत्ता राखली. आम्ही तो आज रिलीज करत आहोत जेणेकरून डेव्हलपर्स या सुधारणा ऍक्सेस करू शकतील.

विस्तृत करा

विस्तृत करा

रिट्रीव्हल आणि रँकिंग इंजिनला कशाची आवश्यकता असते

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

आमच्याकडे अनेक ओपन-सोर्स पर्यायांचे मूल्यमापन केले आणि एक परिपक्व, सामान्य-हेतू रिट्रीव्हल आणि रँकिंग इंजिन निवडले जे आमच्या प्रारंभिक गरजा पूर्ण करते. त्यानंतर आम्ही ते आमच्या आर्किटेक्चर आणि वर्कलोडशी जुळवून घेतले, उत्पादन स्केलवर स्थिर लेटेंसी आणि थ्रूपुट मेंटेन केले.

आमची मागील सिस्टीम कुठे कमी पडली

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

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

२. खराब टेल लेटेंसी. प्रोडक्शन ट्रॅफिकवर, जुन्या सिस्टीमचा p99 प्रतिसाद वेळ सुमारे ८०० ms होता. डेटासेट उपलब्ध RAM पेक्षा जास्त होता, त्यामुळे आम्ही तो पूर्णपणे मेमरीमध्ये ठेवण्यासाठी mlock वापरू शकलो नाही. नॉनरेसिडेंट डेटा ऍक्सेस केल्यामुळे मोठे पेज फॉल्ट ट्रिगर होऊ शकतात, ऑपरेटिंग सिस्टमने डिस्कवरून वाचताना क्वेरी एक्झिक्युशन स्टॉल होते.

इंजिनने आपला मुख्य डिस्क इंडेक्स मेमरीतून फ्लश केलेल्या लहान इंडेक्सेससोबतही कालांतराने विलीन केला. या डिस्क इंडेक्स फ्युजन प्रक्रियेदरम्यान, पेज फॉल्ट्सची संख्या आणखी वाढली, आणि p99 लेटन्सी सुमारे 1.2 s पर्यंत 10–15 मिनिटांसाठी पोहोचली. कॅशे गरम होत गेल्यावर, पेज फॉल्ट्सची वारंवारता आणि लेटन्सी दोन्ही कमी झाले, यावरून थंड वाचनांमुळे या उसळ्यांमध्ये मोठा वाटा होता असे सूचित होते. डेटा प्रीलोड केल्याने आणि इंडेक्स गरम केल्याने उसळ्या कमी झाल्या, पण उच्च टेल लेटन्सीला पुरेशा प्रमाणात हाताळता आले नाही.

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

शेवटी, आमचा फोर्क ॲडॉप्ट आणि मेंटेन करत राहण्यापेक्षा स्क्रॅचपासून तयार करणे सोपे आणि स्वस्त होईल असा निष्कर्ष आम्ही काढला. मागील सिस्टम चालवण्याच्या आमच्या अनुभवाचा वापर करून, एका लहान इंजिनिअरिंग टीमने फोटॉन तयार करण्यासाठी पर्झिस्टंट कोडिंग एजंट्सच्या समवेत काम केले.

शोध स्टॅकमध्ये Photon कुठे बसते

फोटॉन दोन प्राथमिक वर्कफ्लोसाठी डिझाइन केला आहे: सर्च विनंत्या सर्व्ह करणे आणि प्रोसेसिंग पाइपलाइनमधून अपडेट्स इनजेस्ट करणे.

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

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

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

विस्तृत करा

आमच्या वर्कफ्लोसाठी फोटॉन डिझाइन करणे

तीन डिझाइन पर्याय फोटॉनला आमच्या वर्कलोडसाठी योग्य बनवतात: कॉम्पॅक्ट डेटा प्रतिनिधित्व, कॅशिंग आणि असिंक्रोनस डिस्क रीड्स, आणि क्वेरी सर्व्हिंगपासून इंडेक्स अपडेट वेगळे करणे.

पुनप्राप्ती आणि रँकिंगसाठी डेटा प्रतिनिधित्व

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

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

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

इनव्हर्टेड इंडेक्स

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

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

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

विस्तृत करा

वर्क बजेटमध्ये याद्या ट्रॅव्हर्स करणे

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

अल्गोरिदम याद्यांचे दोन गटांमध्ये विभाजन करतो. ड्रायव्हिंग याद्या ट्रॅव्हर्सल पुढे नेतात आणि उमेदवार कागदपत्रांचा प्रस्ताव देतात. प्रोब याद्या त्या उमेदवारांच्या स्कोअरमध्ये योगदान देतात परंतु स्वतः उमेदवार तयार करत नाहीत.

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

निवड नंतर तीन चरणांमध्ये होते:

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

अल्गोरिदम पुढील रँकिंगमध्ये वापरल्या जाणाऱ्या संबंधित कागदपत्रांचा उमेदवार संच तयार करतो.

विस्तृत करा

डॉकबलोब

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

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

त्या सिलेक्टिव्ह डिकोडिंगमुळे डॉकबलोबला संपूर्ण रेकॉर्डऐवजी जुळणाऱ्या अटींशी संबंधित भागांनाच रँकिंग स्पर्श करत असल्यामुळे, प्रमाणशीर खर्च वाढीशिवाय प्रति कागदपत्र अधिक डेटा संचयित करण्यास समर्थन मिळते. रेकॉर्ड वाढवल्यामुळे प्रति लूकअप जास्त काम करावे लागत नाही.

विस्तृत करा

बॅच केलेले रीड्स आणि मेमरीसह काम करणे

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

विस्तृत करा

ओव्हरलॅपिंग डिस्क वेट्स

रँकिंगसाठी फाइलच्या वेगवेगळ्या भागांमध्ये असलेल्या शंभर कागदपत्रांची वैशिष्ट्ये प्राप्त करणे आवश्यक असते. हमारी मागील सिस्टीमने फाइलला व्हर्च्युअल ॲड्रेस स्पेसमध्ये मॅप करण्यासाठी mmap वापरले जेणेकरून ती मेमरी पॉइंटर्सद्वारे वाचली जाऊ शकली असती. तथापि, मेमरीमधून अनुपस्थित असलेले पेज ऍक्सेस करण्यासाठी अजूनही डिस्क रीडची आवश्यकता होती. संगणकीय कार्य सुरू ठेवण्यापूर्वी थ्रेडला डेटाची प्रतीक्षा करावी लागली, आणि प्रक्रियेला कोल्ड रेकॉर्ड अनुक्रमे वाचण्याची आवश्यकता असताना हा प्रतीक्षा वेळ जोडला गेला.

फोटॉन रेकॉर्ड ऑफसेट्स आधीच ज्ञात आहेत या वस्तुस्थितीचा फायदा घेतो, त्यामुळे आपण एकाच वेळी अनेक रीड्स सबमिट करू शकतो. हे रिएक्टरद्वारे व्यवस्थापित केले जाते: समर्पित वर्कर थ्रेड्स io_uring द्वारे बॅचेस सबमिट करतात आणि त्यांनी वाचलेला डेटा कॉलिंग कोडकडे पाठवतात. प्रत्येक थ्रेड स्वतःचे io_uring मेंटेन करतो; बॅचेस सर्वात कमी लोड असलेल्या रिएक्टरकडे पाठवल्या जातात. आधी नोंदणीकृत फाइल डिस्क्रिप्टर आणि बफर पूल्स वारंवार होणाऱ्या रीड्सचा ओव्हरहेड कमी करतात. या असिंक्रोनस एक्झिक्युशनमुळे अनेक ऑपरेशन्सच्या वेट्सना ओव्हरलॅप होण्याची परवानगी मिळते, ज्यामुळे टेल लेटेंसी कमी होते.

ड्राइव्ह ऍक्सेसची संख्या कमी करणे

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

कॅशे बॅच रीड्ससाठी डिझाइन केला आहे. विशेषतः:

• हिटवर कोणतेही स्वतंत्र वाटप नाही. त्याऐवजी, डेटा कॉलिंग कोडद्वारे आधीच तयार केलेल्या बफरमध्ये कॉपी केला जातो.
• वाचक याद्वारे कोणतेही लॉक अधिग्रहण नाही. त्याऐवजी, तो डेटा आवृत्ती तपासतो आणि escritura सह संघर्ष झाल्यास पुन्हा प्रयत्न करतो.
• हे प्रत्येक रीडवर सामायिक LRU यादीला अपडेट्सची आवश्यकता असण्याऐवजी CLOCK इव्हिक्शन वापरते.
• हे सीपीयू कॅशे प्रिफेटचींग वापरते, जिथे आगामी रेकॉर्ड्ससाठी मेटाडेटा आणि डेटा आधीच मागितला जातो.

हे ऑप्टिमायझेशन आपल्याला आवडणाऱ्या वर्कलोड्सवरील कामगिरीला नुकसान न पोहोचवता लेटेंसी कमी करतात.

सर्व्हिंगपासून स्वतंत्रपणे इंडेक्स तयार करणे आणि अपडेट करणे

फोटॉनमध्ये, इंडेक्स बिल्डिंग आणि क्वेरी सर्व्हिंग वेगवेगळ्या नोड्सवर चालतात. इंडेक्सर्स डेटाचे तयार स्टोरेज स्ट्रक्चर्समध्ये रूपांतर करतात, तर सर्व्हिंग नोड्स ते वाचतात आणि रिट्रीव्हल आणि रँकिंग करतात. परिणामी, इंडेक्स बिल्डिंग सीपीयूसाठी सर्च क्वेरीशी स्पर्धा करत नाही, आणि या कार्यांसाठी संसाधने स्वतंत्रपणे स्केल केली जाऊ शकतात.

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

विस्तृत करा

तयारी आणि वितरित इमारत

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

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

नवीन आवृत्ती तैनात करणे

तैनातीपूर्वी, कंट्रोलर तपासतो की नवीन इंडेक्स तयार आहे. डेटा अपूर्ण असल्यास, तैनाती आपोआप ब्लॉक केली जाते.

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

डेटा अपडेटच्या वेळा सर्च व्हर्टिकलनुसार बदलतात. उच्च फ्रेशनेस आवश्यकता असलेल्या व्हर्टिकलसाठी, कागदपत्र वितरण एकांकी अंकी मिनिटे घेते. डेटाची अतिरिक्त प्रत सुमारे अर्ध्या तासात तैनात केली जाऊ शकते; तयार इंडेक्स स्त्रोत कागदपत्रे पुन्हा इंडेक्स न करता लोड केले जातात आणि शार्ड्सना जोडले जातात.

विस्तृत करा

आमच्या सर्च स्टॅक अंतर्गत स्थलांतर आणि सत्यापन

आमचे पहिले ध्येय प्रतिसाद वेळ कमी करताना कार्यक्षमता आणि सर्च गुणवत्ता कायम राखणाऱ्या इंजिनने जुनी सिस्टीम बदलणे हे होते. लाईव्ह ट्रॅफिककडे जाण्यापूर्वी पुनरुत्पादित लोड चाचण्या आणि ऑफलाइन गुणवत्ता मूल्यांकनांपासून सुरूवात करून आम्ही टप्प्याटप्प्याने फोटॉनचे सत्यापन केले. फोटॉन आता आमच्या प्रोडक्शन सर्च स्टकमध्ये रिट्रीव्हल आणि रँकिंगला पॉवर देतो, जुन्या सिस्टीमपेक्षा लक्षणीयरीत्या कमी प्रतिसाद वेळा.

लोड चाचणी आणि मूल्यमापन

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

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

उत्पादनातील मोजलेल्या सुधारणा

आमच्या प्रोडक्शन वर्कफ्लोमध्ये, p99 प्रतिसाद वेळ जुन्या सिस्टीममधील सुमारे ८०० ms वरून फोटॉनमध्ये सुमारे ६५ ms पर्यंत खाली आला. हे मोजमाप फोटॉनमधील सर्व टप्पे कव्हर करते, परंतु उच्च-स्तरीय सर्च स्टकमधील त्यानंतरचे टप्पे वगळते. आम्हाला आता इंडेक्स आवृत्त्या स्विच करण्याशी संबंधित लेटेंसी स्पाइक्स देखील दिसत नाहीत.

प्रति डॉक्युमेंट अंदाजे २.५ पट अधिक डेटा स्टोअर करत असताना फोटॉन जुन्या सिस्टीमच्या सामग्री नोड्सपेक्षा अंदाजे २०% कमी समतुल्य सर्व्हिंग मशीन वापरतो. स्थलांतरानंतर, आम्ही जुन्या सिस्टीमच्या पलीकडे रँकिंग गुणवत्ता सुधारण्यासाठी हा अतिरिक्त डेटा वापरला.

फोटॉन मेमरीमध्ये राहणारा डेटा देखील कमी करतो. mlock सह RAM मध्ये समान फोटॉन डेटासेट पिन करण्यासाठी फोटॉन सध्या वापरत असलेल्या रेसिडेंट मेमरीपेक्षा अंदाजे ४.६ पट अधिक मेमरी आवश्यक असेल.

वेगवान Search API प्रीसेटचे मूल्यमापन

आम्ही Search API साठी नवीन फास्ट प्रीसेटचा आधार म्हणूनही Photon वापरला, जो latency-sensitive workloads साठी डिझाइन केला आहे. आमच्या मोजमापांनुसार, फास्ट प्रीसेटसाठी single-search-call latency p50 वर 160 ms आणि p95 वर 230 ms आहे, जे इतर Search API providers च्या self-reported numbers पेक्षा कमी किंवा तुलनीय आहे, जरी reported tail percentiles वेगळे असले तरी.

आम्ही सहा एजंट बेंचमार्क्सवर फास्ट प्रीसेटचे मूल्यमापन केले: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0, आणि SEAL-Hard. या मूल्यांकनांमध्ये, चाचणी केलेल्या कॉन्फिगरेशनमध्ये यात सर्वात कमी अंदाजे एकूण मॉडेल-प्लस-सर्च खर्च आणि सर्वोच्च एकत्रित टास्क स्कोअर होता.

फास्ट प्रीसेट Photon ला एजेंटिक वर्कफ्लो साठी ऑप्टिमाइझ केलेल्या रँकिंगसोबत जोडतो, आणि default प्रीसेटच्या तुलनेत लक्षणीय कमी खर्चात तुलनात्मक कामगिरी देतो. तथापि, व्यापक शोध गुणवत्तेमध्ये यात काही तडजोड असते. फास्ट प्रीसेट रँकिंगसाठी default प्रीसेटपेक्षा कमी compute वापरतो. long-tail queries, broad coverage, आणि result diversity यांचा समावेश असलेल्या internal benchmarks वर, relevance मध्ये तो 0.24 points नी कमी आणि answer availability मध्ये अंदाजे 3 percentage points नी कमी स्कोअर करतो. एजेंटिक वर्कफ्लो साठी ही तडजोड वाजवी आहे असे आम्हाला वाटते, कारण मॉडेलचे स्वतःचे reasoning आणि knowledge या फरकाची भरपाई करण्यात मदत करू शकतात.

विस्तृत करा

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

निष्कर्ष

आम्ही आमचा सर्च स्टॅक हळूहळू Rust-आधारित, इन-हाउस इन्फ्रास्ट्रक्चरवर हलवत आहोत. ओपन-सोर्स इंजिनला फोटॉन, आमची सानुकूल रिट्रीव्हल आणि रँकिंग इंजिनसह बदलणे ही नवीनतम पायरी आहे. फोटॉन आम्हाला डेटा प्रतिनिधित्वावर, रीड्स कसे आयोजित केले जातात आणि नवीन इंडेक्स कसे तैनात केले जातात यावर पूर्ण नियंत्रण देतो, ज्यामुळे आम्हाला प्रत्येक लेयर आमच्या वर्कलोडसाठी ऑप्टिमाइझ करण्याची परवानगी मिळते.

फोटॉनने Perplexity च्या उत्पादनांमध्ये जलद सर्च सक्षम केला आहे आणि Search API मधील आमच्या नवीन फास्ट प्रीसेटसाठी पाया प्रदान केला आहे. स्थलांतरानंतर, p99 रिट्रीव्हल-आणि-रँकिंग लेटेंसी अंदाजे ८०० ms वरून ६५ ms पर्यंत खाली आली. आमचे कॉम्पॅक्ट डेटा फॉरमॅट्स आम्हाला प्रति डॉक्युमेंट २.५ पट अधिक डेटा स्टोअर करण्याची परवानगी देतात, ज्यामुळे रिट्रीव्हल आणि रँकिंगला समृद्ध डॉक्युमेंट माहिती ऍक्सेस मिळते.

फास्ट प्रीसेट p50 वर 160 ms आणि p95 वर 230 ms ची सिंगल-सर्च-कॉल लेटेंसी देते. मूल्यांकित केलेल्या सहा एजंट बेंचमार्क्समध्ये, डीफॉल्ट प्रीसेटच्या तुलनेत प्रति टास्क मॉडेल-प्लस-सर्चचा अंदाजे खर्च ६८% ने कमी केला, तर समतुल्य एकत्रित टास्क गुणवत्ता राखली. हे परिणाम आमच्या सर्च वर्कलोड्सभोवती डिझाइन केलेल्या इन्फ्रास्ट्रक्चरचे व्यावहारिक फायदे प्रदर्शित करतात, Perplexity च्या उत्पादनांसाठी आणि आमच्या API सह तयार करणाऱ्या डेव्हलपर्ससाठी दोन्ही.

आम्ही फोटॉनच्या परफॉर्मन्स आणि स्टोरेज कार्यक्षमतेमध्ये सतत सुधारणा करत आहोत. आमचे वर्कलोड्स वाढल्याने सर्च वेगवान ठेवत समान हार्डवेअरवर मोठा इंडेक्स आणि समृद्ध डॉक्युमेंट डेटा समर्थित करणे हे आमचे ध्येय आहे.

उद्धरण

@online{perplexity2026Photon,
  author = {{Perplexity} and Maksim Morozov and Bogdan Savko and Ruslan Kovalev and Aleksei Bykov and Artur Zayats and Denis Bykov and Nikita Kireev and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Photon: Building a retrieval and ranking engine from scratch}},
  date = {2026-09-24},
  url = {https://www.perplexity.ai/hub/blog/photon}
}