फ़ोटोन: खरोंच से एक पुनप्राप्ति और रैंकिंग इंजन का निर्माण

Perplexity का AI-नेटिव सर्च स्टैक उम्मीदवार पृष्ठों को पुनः प्राप्त करता है और रैंक करता है, मॉडल के लिए अपने उत्तरों को ग्राउंड करने के लिए सबसे प्रासंगिक सामग्री को सतह पर लाता है। मूल रूप से, यह चरण एक ओपन-सोर्स इंजन पर चला जिसे हमने अपनी प्रणाली के अनुकूल बनाया। हालांकि, जैसे-जैसे हमारा इंडेक्स और वर्कलोड बढ़ा, हमने लागत, टेल लेटेंसी और नोड रिकवरी समय पर कड़ी सीमाओं को छुआ जिसे हम मौजूदा थर्ड-पार्टी प्लेटफॉर्म के भीतर हल नहीं कर सके।

इन चुनौतियों से पार पाने के लिए, हमने फ़ोटोन, एक नया इन-हाउस पुनप्राप्ति और रैंकिंग इंजन बनाया। यह खरोंच से AI-प्रथम खोज बुनियादी ढांचे के निर्माण के हमारे दृष्टिकोण को जारी रखता है, जैसा कि हमने CobbleDB के साथ किया था, जो पृष्ठ रिकॉर्ड की सेवा के लिए हमारा वितरित कुंजी-मूल्य स्टोर है, और हमारा Search API है।

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

फ़ोटोन अब हमारे सर्च पाइपलाइन को शक्ति प्रदान करता है और हमारे सर्च API के लिए एक नए फ़ास्ट प्रीसेट का आधार भी है, जिसमें p50 पर 160 ms और p95 पर 230 ms की सिंगल-सर्च-कॉल लेटेंसी है। छह सार्वजनिक बेंचमार्क में, फ़ास्ट प्रीसेट ने डिफ़ॉल्ट प्रीसेट के तुलनीय एग्रीगेट टास्क क्वालिटी को बनाए रखते हुए प्रति टास्क अनुमानित मॉडल-प्लस-सर्च लागत को 68% तक कम कर दिया। हम इसे आज रिलीज़ कर रहे हैं ताकि डेवलपर इन सुधारों तक पहुँच प्राप्त कर सकें।

प्रदाता-रिपोर्ट किए गए मेडियन और उपलब्ध टेल परसेंटाइल दिखाने वाला सिंगल-सर्च-कॉल लेटेंसी चार्ट, जिसमें p95 के बजाय Exa Instant p90 शामिल है। — स्व-रिपोर्ट की गई सिंगल-सर्च-कॉल लेटेंसी। PPLX Fast p50 लेटेंसी 160 ms और p95 लेटेंसी 230 ms रिपोर्ट करता है; Exa Instant अपने हाई-टेल मान के लिए p95 के बजाय p90 रिपोर्ट करता है; Parallel के हाई-टेल मान प्रकाशित नहीं किए जाते हैं। रिपोर्ट किए गए परसेंटाइल और माप सेटअप नियंत्रित लाइक-फॉर-लाइफ तुलना नहीं हैं।

छह कॉन्फ़िगरेशन में अनुमानित कुल मॉडल और खोज लागत के साथ कार्य-भारित बेंचमार्क स्कोर की तुलना करने वाला स्कैटर प्लॉट। — समान 3,554 चयनित कार्यों के लिए कुल मॉडल-प्लस-सर्च लागत बनाम एग्रीगेट टास्क क्वालिटी। स्कोर टास्क काउंट द्वारा भारित किए जाते हैं, और लागत पूर्ण टास्क सेट को कवर करती है। PPLX Fast का स्कोर $59.73 पर 64.3% है, जबकि डिफ़ॉल्ट PPLX प्रीसेट के लिए $187.60 पर 64.0% है, समान संख्या में कार्यों के लिए लगभग 68% कम अनुमानित लागत है।

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

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

हमने इंजन को हमारे बढ़ते इंडेक्स के अनुकूल बनाने के लिए अपने स्वयं के फ़र्क को बनाए रखा, लेकिन मुख्य सीमाओं को संबोधित करने के लिए प्लेटफ़ॉर्म के बड़े हिस्सों को फिर से डिज़ाइन करने की बढ़ती आवश्यकता थी। बुनियादी स्थापत्य परिवर्तनों के बिना कई बाधाओं को हल करना मुश्किल साबित हुआ:

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

2. खराब टेल लेटेंसी। उत्पादन ट्रैफ़िक पर, पुरानी प्रणाली का p99 प्रतिक्रिया समय लगभग 800 ms था। डेटासेट उपलब्ध RAM से अधिक हो गया, इसलिए हम इसे पूरी तरह से मेमोरी में रखने के लिए mlock का उपयोग नहीं कर सके। गैर-निवासी डेटा तक पहुँचने से प्रमुख पेज फॉल्ट हो सकते हैं, जबकि ऑपरेटिंग सिस्टम डिस्क से पढ़ रहा था, क्वेरी निष्पादन रुक जाता था।

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

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

अंततः, हमने निष्कर्ष निकाला कि हमारे फ़र्क को अनुकूलित और बनाए रखना जारी रखने के बजाय खरोंच से निर्माण करना सरल और सस्ता होगा। पिछली प्रणाली को संचालित करने के अपने अनुभव का लाभ उठाते हुए, एक छोटी इंजीनियरिंग टीम ने फ़ोटोन का निर्माण करने के लिए लगातार कोडिंग एजेंटों के एक झुंड के साथ मिलकर काम किया।

फ़ोटोन को दो प्राथमिक वर्कफ़्लो के लिए डिज़ाइन किया गया है: खोज अनुरोधों की सेवा देना और प्रोसेसिंग पाइपलाइन से अपडेट का सेवन करना।

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

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

इंडेक्स अपडेट एक अलग रास्ते का अनुसरण करते हैं। पिलर, हमारी पब्लिशिंग लेयर, डेटा तैयार करती है और इसे YTsaurus तालिकाओं में संग्रहीत करती है। इंडेक्सर इन तालिकाओं को इंडेक्स संरचनाओं में परिवर्तित करते हैं जिन्हें शार्ड खोज के लिए लोड कर सकते हैं। कंट्रोलर डेटा तैयारी, इंडेक्स निर्माण और सर्विंग ग्रुप्स में नए इंडेक्स वर्शन के परिनियोजन (डिप्लॉयमेंट) का समन्वय करता है। लाइव ट्रैफ़िक को संभालने से पहले, प्रत्येक शार्ड अपने कैश को गर्म करने के लिए वास्तविक खोज क्वेरी को रीप्ले करता है।

उच्च-स्तरीय खोज, लोड बैलेंसर, ब्रोकर और शार्ड के बीच ठोस अनुरोध तीरों और खंडित रिटर्न तीरों के साथ फ़ोटोन क्वेरी अनुक्रम; उम्मीदवार-चयन और सारांश-पढ़ना चरण शीर्षक बाईं ओर बैठते हैं। — एक क्वेरी उच्च-स्तरीय खोज सेवा से लोड बैलेंसर और ब्रोकर के माध्यम से एक चयनित शार्ड ग्रुप में जाती है। प्रत्येक शार्ड उम्मीदवारों को पुनः प्राप्त करता है और रैंक करता है; ब्रोकर परिणामों को विलीन करता है, चयनित पृष्ठों के लिए दस्तावेज़ फ़ील्ड लाता है, और उन्हें उच्च-स्तरीय खोज सेवा को लौटाता है। क्रमांकित चरण क्रम दिखाते हैं। ठोस तीर अनुरोधों को ले जाते हैं, और खंडित तीर परिणामों को वापस ले जाते हैं। बाएं हाथ के चरण लेबल उम्मीदवार चयन को सारांश रीड से अलग करते हैं।

तीन डिज़ाइन विकल्प फ़ोटोन को हमारे वर्कफ़्लो के अनुकूल बनाते हैं: कॉम्पैक्ट डेटा प्रतिनिधित्व, कैशिंग और असमकालिक डिस्क रीड, और क्वेरी सर्विंग से इंडेक्स अपडेट को अलग करना।

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

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

विशेषीकृत डेटा प्रतिनिधित्व हमें मुख्य डेटा को अधिक कुशलता से संग्रहीत करने में सक्षम बनाते हैं। एक अधिक कॉम्पैक्ट इन्वर्टेड इंडेक्स प्रति क्वेरी पढ़े जाने वाले या ले जाए जाने वाले डेटा की मात्रा को कम करता है, अनावश्यक I/O संचालन को समाप्त करके लेटेंसी में सुधार करता है। ये प्रारूप यह जाँच करना भी संभव बनाते हैं कि कोई दस्तावेज़ पूरी तरह से डिकोड किए बिना किसी सूची में दिखाई देता है या नहीं, एक ऐसी संपत्ति जिस पर हमारा ट्रैवर्सल तर्क यह नियंत्रित करने के लिए निर्भर करता है कि एक निश्चित बजट के तहत क्वेरी कितना काम करती है। प्रति-डॉक्यूमेंट रिकॉर्ड को अनुकूलित करने से हमें रैंकिंग के लिए प्रति दस्तावेज़ अधिक डेटा संग्रहीत करने की अनुमति मिलती है, साथ ही हमारी पिछली प्रणाली से जुड़ी स्केलिंग लागत भी कम होती है।

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

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

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

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

उम्मीदवार चयन के लिए संभावित प्रासंगिक दस्तावेजों को खोजने के लिए पोस्टिंग सूचियों को पार करने की आवश्यकता होती है। हर सूची को पूरी तरह से स्कैन करना महंगा है, इसलिए फ़ोटोन WAND-जैसी एल्गोरिथ्म का उपयोग करता है जो दूसरों में मैचों के लिए लेखांकन करते समय केवल कुछ सूचियों को पार करता है।

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

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

चयन तब तीन चरणों में आगे बढ़ता है:

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

एल्गोरिथ्म आगे की रैंकिंग में उपयोग किए जाने वाले प्रासंगिक दस्तावेजों का एक उम्मीदवार सेट तैयार करता है।

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

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

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

वह चयनात्मक डिकोडिंग डॉकब्लॉब (docblob) को आनुपातिक लागत वृद्धि के बिना प्रति दस्तावेज़ अधिक डेटा संग्रहीत करने का समर्थन करने देती है। रिकॉर्ड बढ़ाने से प्रति लुकअप अधिक कार्य करने के लिए मजबूर नहीं होना पड़ता है, क्योंकि रैंकिंग में केवल पूरे रिकॉर्ड के बजाय मिलान किए गए पदों से प्रासंगिक टुकड़ों को छुआ जाता है।

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

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

एक रीड बैच कैश हिट और मिस में विभाजित होता है, जिसमें लापता रिकॉर्ड के लिए वेट को ओवरलैप करने वाले असमकालिक डिस्क रीड होते हैं। — फ़ोटोन डिस्क रीड जारी करने से पहले अपने कैश में ज्ञात रिकॉर्ड ऑफ़सेट के एक बैच की जाँच करता है। कैश हिट को एक तैयार बफर में कॉपी किया जाता है; मिस को io_uring के माध्यम से सबमिट किया जाता है ताकि डिस्क वेट ओवरलैप हो सकें, और लौटाया गया डेटा कैश को भर देता है। रिकॉर्ड और टाइमलाइन योजनाबद्ध हैं, मापी गई लेटेंसी नहीं।

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

फ़ोटोन (Photon) इस तथ्य का लाभ उठाता है कि रिकॉर्ड ऑफ़सेट पहले से ज्ञात होते हैं, जिससे हम एक साथ कई रीड सबमिट कर सकते हैं। इसे रिएक्टर द्वारा प्रबंधित किया जाता है: समर्पित वर्कर थ्रेड io_uring के माध्यम से बैच सबमिट करते हैं और उनके द्वारा पढ़े गए डेटा को कॉलिंग कोड तक पहुँचाते हैं। प्रत्येक थ्रेड अपना खुद का io_uring बनाए रखता है; बैच सबसे कम लोड वाले रिएक्टर को भेजे जाते हैं। पूर्व-पंजीकृत फ़ाइल डिस्क्रिप्टर और बफर पूल बार-बार होने वाले रीड के ओवरहेड को कम करते हैं। यह असमकालिक निष्पादन कई ऑपरेशनों के वेट को ओवरलैप होने देता है, जिससे टेल लेटेंसी कम होती है।

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

कैश को बैच रीड के लिए डिज़ाइन किया गया है। विशेष रूप से:

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

ये अनुकूलन उन वर्कलोड पर प्रदर्शन को नुकसान पहुँचाए बिना लेटेंसी को कम करते हैं जिनकी हमें परवाह है।

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

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

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

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

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

परिनियोजन से पहले, कंट्रोलर जाँच करता है कि नया इंडेक्स तैयार है या नहीं। यदि डेटा अधूरा है, तो परिनियोजन स्वचालित रूप से अवरुद्ध हो जाता है।

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

डेटा अपडेट का समय खोज वर्टिकल में भिन्न होता है। उच्च ताजगी आवश्यकताओं वाले वर्िकल के लिए, दस्तावेज़ वितरण में एकल-अंक मिनट लगते हैं। डेटा की एक अतिरिक्त प्रति को लगभग आधे घंटे में तैनात किया जा सकता है; तैयार इंडेक्स को स्रोत दस्तावेज़ों को पुनः अनुक्रमण (रीइंडेक्सिंग) किए बिना लोड किया जाता है और शार्ड से जोड़ा जाता है।

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

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

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

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

हमारे उत्पादन वर्कफ़्लो में, p99 प्रतिक्रिया समय पुरानी प्रणाली में लगभग 800 ms से गिरकर फ़ोटोन में लगभग 65 ms हो गया। यह माप फ़ोटोन के अंदर सभी चरणों को कवर करता है, लेकिन उच्च-स्तरीय खोज स्टैक में बाद के चरणों को छोड़कर। हम अब उन लेटेंसी स्पाइक्स का भी निरीक्षण नहीं करते हैं जो पहले इंडेक्स वर्शन को स्विच करने से जुड़े थे।

प्रति दस्तावेज़ लगभग 2.5 गुना अधिक डेटा संग्रहीत करते समय फ़ोटोन पुरानी प्रणाली के सामग्री नोड्स की तुलना में लगभग 20% कम समतुल्य सर्विंग मशीनों का उपयोग करता है। माइग्रेशन के बाद, हमने पुरानी प्रणाली से परे रैंकिंग गुणवत्ता में सुधार करने के लिए इस अतिरिक्त डेटा का उपयोग किया।

फ़ोटोन उस डेटा की मात्रा को भी कम करता है जिसे मेमोरी में रहना चाहिए। RAM में mlock के साथ उसी फ़ोटोन डेटासेट को पिन करने के लिए वर्तमान में फ़ोटोन द्वारा उपयोग की जाने वाली रेजिडेंट मेमोरी का अनुमानित 4.6 गुना आवश्यकता होगी।

हमने अपने Search API के लिए एक नए फ़ास्ट प्रीसेट के आधार के रूप में फ़ोटोन का उपयोग भी किया, जिसे लेटेंसी-संवेदनशील वर्कफ़्लो के लिए डिज़ाइन किया गया है। हमारे माप के अनुसार, फ़ास्ट प्रीसेट के लिए सिंगल-सर्च-कॉल लेटेंसी p50 पर 160 ms और p95 पर 230 ms है, जो अन्य Search API प्रदाताओं की स्व-रिपोर्ट की गई संख्याओं से कम या तुलनीय है, हालांकि रिपोर्ट किए गए टेल परसेंटाइल भिन्न होते हैं।

हमने छह एजेंटिक बेंचमार्क पर फ़ास्ट प्रीसेट का मूल्यांकन किया: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0, और SEAL-Hard। इन मूल्यांकनों में, परीक्षण किए गए कॉन्फ़िगरेशन में इसकी सबसे कम अनुमानित कुल मॉडल-प्लस-सर्च लागत और उच्चतम एग्रीगेट टास्क स्कोर था।

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

डिफ़ॉल्ट बनाम फ़ास्ट पुनप्राप्ति गुणवत्ता: 2.45 और 2.21 के प्रासंगिकता स्कोर, और कटी हुई कुल्हाड़ियों पर 0.596 और 0.567 की उत्तर उपलब्धता। — डिफ़ॉल्ट PPLX प्रीसेट और PPLX Fast के बीच आंतरिक पुनप्राप्ति-गुणवत्ता तुलना। प्रासंगिकता (DCG) 2.45 से गिरकर 2.21 हो जाती है, जो 0.24 अंकों की कमी है; उत्तर उपलब्धता 0.596 से गिरकर 0.567 हो जाती है, जो 2.9 प्रतिशत अंकों की कमी है। दो पैनल अलग-अलग, गैर-शून्य अक्ष बेसलाइन का उपयोग करते हैं, इसलिए बार की ऊंचाइयां आनुपातिक अंतर के बजाय अंतराल पर जोर देती हैं।

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

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

फ़ोटोन ने Perplexity के उत्पादों में तेज़ खोज को सक्षम किया है और Search API में हमारे नए फ़ास्ट प्रीसेट के लिए आधार प्रदान करता है। माइग्रेशन के बाद, p99 पुनप्राप्ति-और-रैंकिंग लेटेंसी लगभग 800 ms से गिरकर 65 ms हो गई। हमारे कॉम्पैक्ट डेटा प्रारूप हमें प्रति दस्तावेज़ 2.5 गुना अधिक डेटा संग्रहीत करने की अनुमति भी देते हैं, जिससे पुनप्राप्ति और रैंकिंग को समृद्ध दस्तावेज़ जानकारी तक पहुँच मिलती है।

फ़ास्ट प्रीसेट p50 पर 160 ms और p95 पर 230 ms की सिंगल-सर्च-कॉल लेटेंसी प्रदान करता है। मूल्यांकन किए गए छह एजेंटिक बेंचमार्क में, इसने डिफ़ॉल्ट प्रीसेट की तुलना में प्रति टास्क अनुमानित मॉडल-प्लस-सर्च लागत को 68% तक कम कर दिया, साथ ही तुलनीय एग्रीगेट टास्क क्वालिटी को बनाए रखा। ये परिणाम हमारे सर्च वर्कलोड के आसपास डिज़ाइन किए गए बुनियादी ढांचे के व्यावहारिक लाभों को प्रदर्शित करते हैं, जो Perplexity के उत्पादों और हमारे API के साथ निर्माण करने वाले डेवलपर्स दोनों के लिए हैं।

हम फ़ोटोन के प्रदर्शन और भंडारण दक्षता में सुधार करना जारी रख रहे हैं। हमारा लक्ष्य उसी हार्डवेयर पर एक बड़े इंडेक्स और समृद्ध दस्तावेज़ डेटा का समर्थन करना है, जबकि हमारे वर्कलोड बढ़ने पर खोज को तेज़ रखना है।

BibTeX

@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}
}

परिचय

पुनप्राप्ति और रैंकिंग इंजन की क्या आवश्यकता है

जहाँ हमारी पिछली प्रणाली कम पड़ गई

सर्च स्टैक में फ़ोटोन कहाँ फिट बैठता है

हमारे वर्कफ़्लो के लिए फ़ोटोन डिज़ाइन करना

पुनप्राप्ति (रिट्रीवल) और रैंकिंग के लिए डेटा प्रतिनिधित्व

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

कार्य बजट के भीतर सूचियों को पार करना (ट्रैवर्स करना)

डॉकब्लॉब (Docblob)

बैच रीड और मेमोरी के साथ काम करना

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

ड्राइव एक्सेस की संख्या कम करना

सर्विंग से अलग इंडेक्स का निर्माण और अद्यतन करना

तैयारी और वितरित भवन

नया वर्शन परिनियोजित करना

हमारे सर्च स्टैक के भीतर माइग्रेशन और वैलिडेशन

लोड टेस्टिंग और मूल्यांकन

उत्पादन में मापा गया सुधार

फास्ट Search API प्रीसेट का मूल्यांकन

निष्कर्ष

उद्धरण