एक डेवलपर टीम ने OpenSearch को SQLite FTS5 के साथ जोड़ा और शून्य-परिणाम (zero-result) वाले वीडियो सर्च को 11.4 प्रतिशत से घटाकर 2.1 प्रतिशत कर दिया, जबकि लेटेंसी (latency) को 20 ms से कम रखा। अब जब उपयोगकर्ता “blackpink jenny solo stag” टाइप करते हैं, तो उन्हें खाली सूची के बजाय सही “BLACKPINK Jennie SOLO stage” दिखाई देता है।

बदलाव की आवश्यकता क्यों थी

एक वीडियो-होस्टिंग प्लेटफॉर्म के सर्च लॉग्स से एक आवर्ती समस्या (recurring problem) सामने आई: लैटिन-स्क्रिप्ट (Latin-script) वाले शीर्षक में एक एकल टाइपो (typo) भी सभी मैचों को खत्म कर सकता था। SQLite का FTS5 एक्सटेंशन, जो चीनी, जापानी और कोरियाई (CJK) टेक्स्ट में सबस्ट्रिंग (substring) मैच करने की अपनी क्षमता के लिए जाना जाता है, फजी मैचिंग (fuzzy matching) नहीं करता है। किसी नाम या गाने के शीर्षक में एक गलत स्पेलिंग वाला अक्षर भी क्वेरी को पूरी तरह से तोड़ देता है।

मौजूदा पाइपलाइन SQLite को एकमात्र इंडेक्स मानती थी। यह CJK क्वेरीज़ को अच्छी तरह से संभालती थी लेकिन लैटिन-स्क्रिप्ट टाइपो के लिए कोई सुरक्षा कवच (safety net) प्रदान नहीं करती थी। इसलिए, टीम ने एक पूरक (complementary) सर्च इंजन की तलाश की जो मौजूदा FTS5 लेयर को हटाए बिना टाइपो सहिष्णुता (typo tolerance) प्रदान कर सके।

OpenSearch को कैसे जोड़ा गया

OpenSearch फ्रंट-लाइन सर्च सर्विस के रूप में चलता है; SQLite 'सोर्स ऑफ ट्रुथ' (source of truth) बना रहता है। दोनों सिस्टम समानांतर (parallel) रूप से चलते हैं: OpenSearch पहले यूजर क्वेरी प्राप्त करता है, और यदि यह पर्याप्त तेज़ी से जवाब देता है, तो इसके परिणाम दिखाए जाते हैं। यदि OpenSearch टाइमआउट हो जाता है या एरर आता है, तो अनुरोध SQLite FTS5 इंडेक्स पर वापस चला जाता है। यह “फेल-सेफ” (fail-safe) डिज़ाइन यह सुनिश्चित करता है कि नेटवर्क की किसी भी समस्या के कारण सर्च बार कभी खाली न रहे।

मल्टी-फील्ड मैपिंग (Multi-field mapping)

OpenSearch में प्रत्येक वीडियो शीर्षक को तीन तरीकों से इंडेक्स किया जाता है:

  • title.std – ASCII फोल्डिंग के साथ एक स्टैंडर्ड एनालाइज़र द्वारा प्रोसेस किया जाता है। यह एक्सेंटेड (accented) कैरेक्टर्स को सामान्य करता है और अधिकांश लैटिन-स्क्रिप्ट टाइपो को संभालता है।
  • title.cjk – एक CJK एनालाइज़र द्वारा प्रोसेस किया जाता है जो बिग्राम्स (दो-कैरेक्टर टोकन) बनाता है। यह उस सबस्ट्रिंग-मैचिंग क्षमता को बनाए रखता है जो FTS5 एशियाई लिपियों के लिए प्रदान करता है।
  • title.keyword – सटीक-मैच (exact-match) लुक-अप और सॉर्टिंग के लिए बिना किसी बदलाव के स्टोर किया जाता है।

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

बूस्ट टियर्स (Boost tiers)

एक एकल मोनोलिथिक क्वेरी के बजाय, टीम ने एक टियर वाली क्वेरी बनाई जो परिणामों को स्वचालित रूप से रैंक करती है:

  1. title.keyword पर सटीक वाक्यांश मिलान (Exact phrase matches) को उच्चतम बूस्ट मिलता है, जिससे यह सुनिश्चित होता है कि सटीक मिलान सूची में सबसे ऊपर रहें।
  2. title.cjk पर CJK बिग्राम मिलान (CJK bigram matches) को मध्यम बूस्ट मिलता है, जिससे एशियाई भाषा के सर्च की गुणवत्ता बनी रहती है।
  3. title.std पर फजी लैटिन मिलान (Fuzzy Latin matches) को कम बूस्ट मिलता है, जिससे सटीक परिणामों को प्रभावित किए बिना टाइपो-सहिष्णु परिणाम दिखाई दे सकें।

टियर वाला दृष्टिकोण ट्यूनिंग को सरल बनाता है: एक बूस्ट वैल्यू को बदलने से मिलान के पूरे वर्ग (class) का सापेक्ष महत्व बदल जाता है।

स्मार्ट फजीनेस (Smart fuzziness)

फजीनेस—जिसमें सीमित संख्या में कैरेक्टर एडिट की अनुमति होती है—केवल लैटिन फ़ील्ड पर लागू होती है। टीम ने title.cjk के लिए फजीनेस को अक्षम (disable) कर दिया क्योंकि CJK में एक कैरेक्टर का बदलाव अक्सर अर्थ को पूरी तरह से बदल देता है। लैटिन टेक्स्ट के लिए क्वेरी OpenSearch की AUTO फजीनेस सेटिंग का उपयोग करती है, जो शब्द की लंबाई के आधार पर अनुमत एडिट डिस्टेंस (edit distance) को स्केल करती है, जिससे सहिष्णुता और प्रासंगिकता के बीच संतुलन बना रहता है।

प्रदर्शन और फ़ालबैक लॉजिक (Performance and fallback logic)

सर्च रूटीन OpenSearch कॉल को try-catch ब्लॉक में लपेटता है:

  • यदि OpenSearch 400 ms के भीतर परिणाम देता है, तो उसके परिणाम प्रदर्शित किए जाते हैं।
  • यदि कॉल में कोई अपवाद (exception) आता है या टाइमआउट से अधिक समय लगता है, तो सिस्टम तुरंत SQLite FTS5 के विरुद्ध क्वेरी फिर से चलाता है।

यह सुनिश्चित करता है कि नेटवर्क लेटेंसी या सर्विस आउटेज के कारण यूजर एक्सपीरियंस कभी खराब न हो। सर्च लेटेंसी 20 ms से कम रही।

मापने योग्य प्रभाव (Measurable impact)

  • लैटिन-स्क्रिप्ट क्वेरीज़ के लिए शून्य-परिणाम दर (Zero-result rates) 11.4% से घटकर 2.1% हो गई।
  • CJK क्वेरीज़ के लिए सर्च क्वालिटी अपरिवर्तित रही, जिससे पुष्टि हुई कि नए CJK एनालाइज़र ने मूल FTS5 इंडेक्स की खूबियों को बरकरार रखा है।
  • एंड-टू-एंड लेटेंसी आराम से 20 ms के लक्ष्य से नीचे रही, जिसका अर्थ है कि जोड़े गए लेयर ने UI को धीमा नहीं किया।

सबक और समझौते (Lessons and trade-offs)

  • अलग फोल्डिंग और फजीनेस – फोल्डिंग (कैरेक्टर्स को सामान्य करना) और फजीनेस (टाइपो को संभालना) अलग-अलग समस्याओं का समाधान करते हैं। उन्हें अलग-अलग फ़ील्ड्स पर रखने से अनपेक्षित इंटरैक्शन से बचा जा सकता है।
  • सर्च इंडेक्स को 'सोर्स ऑफ ट्रुथ' न मानें – SQLite मुख्य स्टोर (canonical store) बना रहता है; OpenSearch एक व्युत्पन्न (derived), रिफ्रेश करने योग्य व्यू है। यह इंडेक्स ड्रिफ्ट को रोकता है और विफलताओं के बाद रिकवरी को सरल बनाता है।
  • बूस्ट टियर्स ट्यूनिंग को सरल बनाते हैं – संबंधित मिलानों को एक ही बूस्ट फैक्टर के तहत समूहित करने से उन मापदंडों (parameters) की संख्या कम हो जाती है जिन्हें समायोजित करने की आवश्यकता होती है।

आगे क्या देखें

यह प्रयोग सिद्ध करता है कि SQLite FTS5 की प्रमाणित CJK क्षमताओं से समझौता किए बिना, एक मामूली OpenSearch लेयर बहुभाषी वीडियो शीर्षकों के लिए typo tolerance में नाटकीय रूप से सुधार कर सकती है। उन प्लेटफार्मों के लिए जहाँ search relevance सीधे watch time को प्रभावित करती है, यह सुधार user-experience के लिए एक ठोस जीत साबित होता है।