एका डेव्हलपर टीमने OpenSearch ला SQLite FTS5 सोबत जोडले आणि व्हिडिओ सर्चमधील 'झिरो-रिझल्ट' (zero-result) प्रमाण ११.४ टक्क्यांवरून २.१ टक्क्यांपर्यंत खाली आणले, तेही २० ms पेक्षा कमी लॅटन्सी (latency) राखून. आता "blackpink jenny solo stag" असे टाईप करणारे युजर्स रिकाम्या लिस्टऐवजी योग्य "BLACKPINK Jennie SOLO stage" पाहू शकतात.

बदलाची गरज का होती

एका व्हिडिओ-होस्टिंग प्लॅटफॉर्मच्या सर्च लॉग्समधून एक वारंवार येणारी समस्या समोर आली: लॅटिन-स्क्रिप्ट (Latin-script) टायटलमधील एका साध्या स्पेलिंगच्या चुकीमुळे (typo) सर्व मॅचेस गायब होऊ शकत होते. SQLite चे FTS5 एक्सटेंशन, जे चिनी, जपानी आणि कोरियन (CJK) मजकुरातील सबस्ट्रिंग्स (substrings) मॅच करण्याच्या क्षमतेसाठी ओळखले जाते, ते 'फझी मॅचिंग' (fuzzy matching) करत नाही. नाव किंवा गाण्याच्या टायटलमधील एक चुकीचे अक्षर संपूर्ण क्वेरी (query) बिघडवू शकते.

सध्याच्या पाइपलाइनमध्ये SQLite ला एकमेव इंडेक्स (index) मानले जात होते. ते CJK क्वेरीज चांगल्या प्रकारे हाताळत होते, परंतु लॅटिन-स्क्रिप्टमधील स्पेलिंगच्या चुकांसाठी त्यात कोणतीही सुरक्षा यंत्रणा नव्हती. त्यामुळे, टीमने एक पूरक सर्च इंजिन शोधले जे सिद्ध झालेल्या FTS5 लेयरला न घालता 'टायपो टॉलरन्स' (typo tolerance) प्रदान करू शकेल.

OpenSearch कसे जोडले गेले

OpenSearch हे फ्रंट-लाईन सर्च सर्व्हिस म्हणून काम करते; तर SQLite हा 'सोर्स ऑफ ट्रुथ' (source of truth) म्हणून राहतो. ही दोन्ही सिस्टम्स समांतर चालतात: प्रथम OpenSearch युजरची क्वेरी स्वीकारते आणि जर ती पुरेशा वेगाने प्रतिसाद देत असेल, तर तिचे रिझल्ट्स दाखवले जातात. जर OpenSearch टाइम-आउट झाले किंवा एरर आली, तर रिक्वेस्ट SQLite FTS5 इंडेक्सकडे वळवली जाते. हे "फेल-सेफ" (fail-safe) डिझाइन हे सुनिश्चित करते की नेटवर्कमधील कोणत्याही अडथळ्यामुळे सर्च बार कधीही रिकामा राहणार नाही.

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

OpenSearch मध्ये प्रत्येक व्हिडिओ टायटल तीन प्रकारे इंडेक्स केले जाते:

  • title.std – ASCII फोल्डिंगसह स्टँडर्ड अनायझरद्वारे (standard analyzer) प्रोसेस केले जाते. हे ॲक्सेंटेड कॅरेक्टर्स नॉर्मलाईज करते आणि लॅटिन-स्क्रिप्टमधील बहुतेक स्पेलिंगच्या चुका हाताळते.
  • title.cjk – CJK अनायझरद्वारे प्रोसेस केले जाते जो बिग्राम्स (bigrams - दोन कॅरेक्टर टोकन्स) तयार करतो. यामुळे आशियाई लिपींसाठी FTS5 प्रदान करत असलेली सबस्ट्रिंग-मॅचिंगची ताकद कायम राहते.
  • title.keyword – अचूक मॅच (exact-match) शोधण्यासाठी आणि सॉर्टिंगसाठी कोणताही बदल न करता साठवले जाते.

वेगळ्या फील्ड्समुळे टोकनायझेशन स्ट्रॅटेजीज (tokenisation strategies) न मिसळता, प्रत्येक स्क्रिप्टसाठी योग्य विश्लेषण लागू करणे क्वेरीला शक्य होते.

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

एकच मोनोलिथिक (monolithic) क्वेरी वापरण्याऐवजी, टीमने एक टियर्ड (tiered) क्वेरी तयार केली जी रिझल्ट्सना आपोआप रँक करते:

  1. title.keyword वरील अचूक वाक्यांश मॅचेस (Exact phrase matches) ला सर्वाधिक बूस्ट दिला जातो, ज्यामुळे लिस्टमध्ये अचूक मॅचेस वरच्या क्रमांकावर राहतात.
  2. title.cjk वरील CJK बिग्राम मॅचेस ला मध्यम बूस्ट मिळतो, ज्यामुळे आशियाई भाषांच्या सर्चची गुणवत्ता कायम राहते.
  3. title.std वरील फझी लॅटिन मॅचेस ला कमी बूस्ट दिला जातो, ज्यामुळे अचूक मॅचेसना बाजूला न सारता स्पेलिंगच्या चुकांसह रिझल्ट्स दिसू शकतात.

टियर्ड दृष्टिकोनामुळे ट्यूनिंग करणे सोपे होते: एका बूस्ट व्हॅल्यूमध्ये बदल केल्यास संपूर्ण मॅचेसच्या वर्गाचे सापेक्ष महत्त्व बदलते.

स्मार्ट फझिनेस (Smart fuzziness)

फझिनेस (Fuzziness)—म्हणजेच मर्यादित प्रमाणात कॅरेक्टर बदल करण्याची परवानगी देणे—केवळ लॅटिन फील्डला लागू होते. टीमने title.cjk साठी फझिनेस बंद केले कारण CJK मध्ये एका अक्षराचा बदल देखील अनेकदा अर्थ पूर्णपणे बदलून टाकतो. लॅटिन मजकुरासाठी क्वेरी OpenSearch चे AUTO फझिनेस सेटिंग वापरते, जे शब्दाच्या लांबीनुसार अनुमत 'एडिट डिस्टन्स' (edit distance) ठरवते, ज्यामुळे टॉलरन्स आणि रिलेव्हन्स (relevance) यामध्ये संतुलन राखले जाते.

परफॉर्मन्स आणि फॉलबॅक लॉजिक (Performance and fallback logic)

सर्च रुटीनमध्ये OpenSearch कॉलला try-catch ब्लॉक मध्ये गुंडाळले आहे:

  • जर OpenSearch 400 ms च्या आत प्रतिसाद देत असेल, तर त्याचे रिझल्ट्स दाखवले जातात.
  • जर कॉलमध्ये एक्सेप्शन (exception) आले किंवा टाइम-आउट exceeded झाले, तर सिस्टम त्वरित SQLite FTS5 विरुद्ध क्वेरी पुन्हा चालवते.

यामुळे नेटवर्क लॅटन्सी किंवा सर्व्हिस आउटेजमुळे युजर एक्सपिरियन्स कधीही खराब होत नाही. सर्च लॅटन्सी 20 ms च्या खाली राहिली.

मोजता येण्यासारखा परिणाम (Measurable impact)

  • लॅटिन-स्क्रिप्ट क्वेरीजसाठी झिरो-रिझल्टचे प्रमाण ११.४% वरून २.१% पर्यंत खाली आले.
  • CJK क्वेरीजसाठी सर्चची गुणवत्ता तशीच राहिली, ज्यामुळे हे सिद्ध झाले की नवीन CJK अनायझरने मूळ FTS5 इंडेक्सची ताकद कायम ठेवली आहे.
  • एंड-टू-एंड लॅटन्सी २० ms च्या लक्ष्यापेक्षा खाली राहिली, याचा अर्थ नवीन लेयरमुळे UI च्या वेगावर परिणाम झाला नाही.

धडे आणि तडजोडी (Lessons and trade-offs)

  • वेगळे फोल्डिंग आणि फझिनेस – फोल्डिंग (कॅरेक्टर्स नॉर्मलाईज करणे) आणि फझिनेस (स्पेलिंगच्या चुका हाताळणे) या वेगवेगळ्या समस्या सोडवतात. त्यांना वेगवेगळ्या फील्ड्सवर ठेवल्यामुळे अनपेक्षित परस्पर क्रिया (interactions) टाळता येतात.
  • सर्च इंडेक्सला 'सोर्स ऑफ ट्रुथ' मानू नका – SQLite हा मुख्य स्टोअर (canonical store) राहतो; OpenSearch हे एक डेरिव्हड आणि रिफ्रेश करण्यायोग्य व्ह्यू (view) आहे. यामुळे इंडेक्स ड्रिफ्ट (index drift) टाळता येतो आणि फेल्युअर नंतर रिकव्हरी सोपी होते.
  • बूस्ट टियर्स ट्यूनिंग सोपे करतात – संबंधित मॅचेसना एकाच बूस्ट फॅक्टरखाली गटबद्ध केल्यामुळे ॲडजस्ट कराव्या लागणाऱ्या पॅरामीटर्सची संख्या कमी होते.

पुढे काय पाहावे (What to watch next)

हा प्रयोग सिद्ध करतो की, SQLite FTS5 च्या सिद्ध CJK क्षमतांशी तडजोड न करता, एक साधा OpenSearch लेअर बहुभाषिक व्हिडिओ शीर्षकांसाठी स्पेलिंगमधील चुका सहन करण्याची क्षमता लक्षणीयरीत्या सुधारू शकतो. ज्या प्लॅटफॉर्मवर शोध सुसंगतता थेट वॉच टाइमवर परिणाम करते, त्यांच्यासाठी ही सुधारणा वापरकर्ता अनुभवामध्ये एक प्रत्यक्ष यश ठरते.