प्रोडक्शन AI के लिए वेक्टर सर्च पर्याप्त नहीं है

वेक्टर सर्च ने सिमेंटिक रिट्रीवल (semantic retrieval) को बदल दिया है। आप डेटा को एम्बेड करते हैं, क्वेरी को एम्बेड करते हैं, और पड़ोसियों (neighbors) को खोजते हैं। इसने पुराने कीवर्ड मैचिंग की जगह ले ली है।

लेकिन प्रोडक्शन AI को केवल समान एम्बेडिंग्स से कहीं अधिक की आवश्यकता होती है। रिट्रीवल अब 'नेबर' (neighbor) खोजने की समस्या से बदलकर रैंकिंग और निर्णय लेने की समस्या बनता जा रहा है।

एक प्रोटोटाइप वेक्टर के साथ काम कर सकता है। एक प्रोडक्शन सिस्टम के लिए इससे कहीं अधिक की आवश्यकता होती है।

एक वास्तविक यूजर क्वेरी को एक साथ इन चीजों की आवश्यकता होती है:

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

इससे समस्याएँ पैदा होती हैं:

वेक्टर वन-डायमेंशनल एरे (one-dimensional arrays) होते हैं। टेंसर (Tensors) मल्टी-डायमेंशनल स्ट्रक्चर होते हैं।

टेंसर आपको डेंस एम्बेडिंग्स (dense embeddings), स्पार्स फीचर्स (sparse features) और मेटाडेटा को एक ही पास में संयोजित करने की अनुमति देते हैं। आप खंडित पाइपलाइन (fragmented pipeline) से बच जाते हैं।

ColBERT जैसे नए मॉडल्स मल्टी-वेक्टर अप्रोच का उपयोग करते हैं। वे किसी डॉक्यूमेंट को एक बिंदु (point) में कंप्रेस नहीं करते हैं। वे टोकन-लेवल विवरण (token-level details) बनाए रखते हैं। यह प्रासंगिकता (relevance) में सुधार करता है लेकिन पुराने वेक्टर डेटाबेस के लिए समस्या पैदा करता है।

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

यदि आप RAG पाइपलाइन या रिकमेंडेशन सिस्टम बनाते हैं, तो विखंडन (fragmentation) आपकी गति धीमी कर देगा। जैसे-जैसे आप बढ़ेंगे, यह समस्या और गंभीर होती जाएगी।

खुद से ये सवाल पूछें:

अपने आर्किटेक्चरल निर्णयों में मदद के लिए GigaOm ब्रीफ में पूरी जानकारी पढ़ें।

स्रोत: https://dev.to/thegatewayguy/vector-search-got-you-started-production-ai-needs-tensors-41dl

वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi