The Evolution of ‘More Like This’

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

इस परिदृश्य को पारंपरिक रूप से कहा जाता है इस तरह और अधिक (एमएलटी): चयनित दस्तावेज़ के समान दस्तावेज़ खोजने के लिए एक फ़ंक्शन। इस आलेख में, एमएलटी का अर्थ है वह खोज जो किसी ज्ञात दस्तावेज़ से शुरू होती है, न कि किसी नई टाइप की गई क्वेरी से।

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

लघु शब्दावली

पूरे लेख में परिभाषाओं को दोहराने से बचने के लिए, यहां मुख्य शब्द दिए गए हैं:

क्या क्लासिक मोर लाइक दिस ने किया

क्लासिक एमएलटी शाब्दिक था। इसने एक सरल प्रश्न का उत्तर दिया: कौन से दस्तावेज़ समान महत्वपूर्ण शब्दों का उपयोग करते हैं?

प्रक्रिया आमतौर पर इस तरह दिखती थी:

1. खोज प्रणाली ने स्रोत दस्तावेज़ लिया।
2. इसने अपने पाठ का विश्लेषण किया।
3. इसमें सूचनाप्रद शब्दों का चयन किया गया।
4. इसने उन शर्तों से एक क्वेरी बनाई।
5. इसने शब्दों के समान सेट वाले दस्तावेज़ों की खोज की।
6. इसने समान दस्तावेजों की एक सूची लौटा दी।

आंतरिक रूप से, इसमें परिचित पूर्ण-पाठ खोज तंत्र का उपयोग किया गया: TF-IDF या BM25, टर्म फ़्रीक्वेंसी, स्टॉपवर्ड, फ़ील्ड बूस्ट और दस्तावेज़-फ़्रीक्वेंसी सीमाएँ। यही कारण है कि पुराने एमएलटी कार्यान्वयन जैसे मापदंडों को उजागर करते हैं min_term_freq, min_doc_freq, max_doc_freqऔर max_query_terms.

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

जहां शाब्दिक दृष्टिकोण अभी भी मजबूत है

जब विशिष्ट शब्द, पहचानकर्ता और स्थिर फॉर्मूलेशन मायने रखते हैं तो लेक्सिकल एमएलटी अच्छी तरह से काम करता है।

उदाहरण:

• त्रुटि कोड;
• उत्पाद SKU;
• भाग संख्या;
• फ़ंक्शन नाम;
• ढेर के निशान;
• कानूनी शब्दावली;
• लगभग समान उत्पाद या टिकट विवरण।

कारण यह है कि यहां सटीक मिलान महत्वपूर्ण है। यदि दो घटना रिपोर्टों में समान त्रुटि कोड या समान स्टैक ट्रेस होता है, तो पूर्ण-पाठ खोज में सीधा मिलान दिखता है। उदाहरण के लिए, कोड के साथ टिकट खोजते समय ERR_404लेक्सिकल एमएलटी उस कोड के हर उल्लेख को तुरंत ढूंढ लेता है, जबकि वेक्टर खोज ऐसे टिकट लौटा सकती है जो समान लेकिन समान समस्याओं का वर्णन नहीं करते हैं।

लेक्सिकल एमएलटी का एक और फायदा था: इसे चलाना सस्ता था। उलटा सूचकांक पहले से ही खोज इंजन में है। विश्लेषक पहले से ही कॉन्फ़िगर हैं. रैंकिंग पहले से ही काम करती है. केवल “समान खोजें” सुविधा का समर्थन करने के लिए अलग खोज बुनियादी ढांचे को तैनात करने की आवश्यकता नहीं है।

सीमा भी स्पष्ट है. यदि दो दस्तावेज़ एक ही चीज़ का अलग-अलग शब्दों में वर्णन करते हैं, तो शाब्दिक एमएलटी उन्हें जोड़ने में विफल हो सकता है। समानार्थी शब्द असमान रूप से कार्य करते हैं। व्याख्याएँ कठिन हैं. क्रॉस-लिंगुअल समानता आमतौर पर अनुपलब्ध है। उदाहरण के लिए, memory leak और unbounded heap growth एक ही समस्या का वर्णन कर सकता है, लेकिन एक मानक विश्लेषक अलग-अलग टोकन देखता है।

लेक्सिकल एमएलटी कुशलतापूर्वक मिलान या समान शब्दों वाले दस्तावेज़ ढूंढता है। अर्थ संबंधी खोज तब मदद करती है जब अर्थ मेल खाता हो, शब्दों का नहीं।

एम्बेडिंग क्या बदलती है

एम्बेडिंग का उपयोग – दस्तावेज़ों का संख्यात्मक प्रतिनिधित्व – तुलना सिद्धांत को बदलता है: शब्दों के बजाय, सिस्टम वेक्टर प्रतिनिधित्व की तुलना करता है।

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

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

इससे इस प्रकार की खोज का दायरा विस्तृत हो जाता है. आप RAG सिस्टम में न केवल लेखों, बल्कि उत्पादों, छवियों, कोड अंशों, उपयोगकर्ता घटनाओं या संदर्भ अंशों की तुलना भी कर सकते हैं। आरएजी में, खोज प्रणाली पहले प्रासंगिक संदर्भ को पुनः प्राप्त करती है, और फिर जेनरेटिव मॉडल उत्तर देने के लिए उस संदर्भ का उपयोग करता है।

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

जैसा कि शाब्दिक और वेक्टर खोज की हमारी तुलना में दिखाया गया है, पूर्व सटीक सख्त मिलान पर जीतता है, जबकि बाद वाला अर्थ संबंधों के कवरेज में सुधार करता है।

सूचकांक से एक वेक्टर द्वारा लुकअप के रूप में एमएलटी

यदि किसी दस्तावेज़ के लिए वेक्टर प्रतिनिधित्व की गणना पहले ही की जा चुकी है और सूचकांक में संग्रहीत है, तो आधुनिक एमएलटी को एक अलग एपीआई उदाहरण के बिना वर्णित किया जा सकता है:

1. स्रोत दस्तावेज़ लें.
2. सूचकांक से इसके पूर्व-गणना किए गए वेक्टर प्रतिनिधित्व को पुनः प्राप्त करें।
3. निकटतम सदिश खोजें.
4. वे दस्तावेज़ लौटाएँ जिनसे वे वेक्टर संबंधित हैं।

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

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

एक न्यूनतम SQL उदाहरण इस तरह दिखता है:

SELECT id, title, knn_dist()
FROM products
WHERE knn(embedding, 10, 123)
LIMIT 10;

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

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

इंजन में खोज को बेहतर ढंग से प्रबंधित क्यों किया जाता है?

आप इस परिदृश्य को एप्लिकेशन में लागू कर सकते हैं: पहले दस्तावेज़ प्राप्त करें, फिर उसका वेक्टर निकालें, फिर एक अलग KNN क्वेरी भेजें, और फिर परिणाम को फ़िल्टर के साथ संयोजित करें।

वह दृष्टिकोण सिस्टम आर्किटेक्चर को और अधिक जटिल बनाता है। आवेदन करना होगा:

• सेवाओं के बीच वेक्टर पास करें;
• आकस्मिक लॉगिंग को रोकें;
• एम्बेडिंग मॉडल संस्करण की जाँच करें;
• डेटा को मुख्य सूचकांक के साथ सिंक्रनाइज़ रखें;
• सामान्य खोज में उपयोग किए जाने वाले समान फ़िल्टर लागू करें।

जब खोज प्रणाली स्वयं लुकअप करती है, तो पथ छोटा हो जाता है:

1. एप्लिकेशन स्रोत दस्तावेज़ की आईडी पास करता है।
2. खोज प्रणाली सूचकांक में पूर्व-गणना किए गए वेक्टर प्रतिनिधित्व को ढूंढती है।
3. खोज प्रणाली निकटतम-पड़ोसी खोज (केएनएन) या इसके अनुमानित संस्करण (एएनएन) चलाती है।
4. खोज प्रणाली पाए गए दस्तावेज़ों को समान एक्सेस फ़िल्टर और मेटाडेटा के साथ लौटाती है।

इस दृष्टिकोण के लाभ:

• एप्लिकेशन से कम अंतर-सेवा अनुरोध;
• बड़े वैक्टर को बाहरी एपीआई के माध्यम से भेजने की आवश्यकता नहीं है;
• फ़िल्टर खोज के करीब रहते हैं;
• परिणाम को पुन: पेश करना और डीबग करना आसान है;
• एप्लिकेशन को समानता गणना के लिए किसी अतिरिक्त परत की आवश्यकता नहीं है – सब कुछ खोज इंजन के अंदर चलता है।

यह खराब एम्बेडिंग को ठीक नहीं करेगा या रैंकिंग को ट्यून करने की आवश्यकता को दूर नहीं करेगा। लेकिन यह खोज श्रृंखला में परस्पर क्रिया करने वाले घटकों की संख्या को कम कर देता है, जिससे सिस्टम को बनाए रखना आसान हो जाता है।

व्यावहारिक उदाहरण और एमएलटी का विकास

किसी मौजूदा ऑब्जेक्ट से खोज विशेष रूप से तब उपयोगी होती है जब उपयोगकर्ता को पहले से ही एक प्रासंगिक प्रारंभिक बिंदु मिल गया हो।

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

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

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

एमएलटी के विकास को इस प्रकार वर्णित किया जा सकता है:

एमएलटी का विकास शाब्दिक तुलना से मेल खाते दस्तावेज़ वेक्टर अभ्यावेदन की ओर एक बदलाव है। लेकिन व्यावहारिक अनुरोध वही रहा: स्रोत परिणाम से संबंधित दस्तावेज़ ढूंढें।

क्या ध्यान रखें

सिमेंटिक एमएलटी सभी खोज इंजीनियरिंग को प्रतिस्थापित नहीं करता है।

उत्पादन प्रणालियों को अभी भी आवश्यकता है:

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

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

निष्कर्ष

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

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