𝗩𝗲𝗰𝘁𝗼𝗿 𝗦𝗲𝗮𝗿𝗰𝗵 𝗜𝘀 𝗡𝗼𝘁 𝗘𝗻𝗼𝘂𝗴𝗵 𝗳𝗼𝗿 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗔𝗜

वेक्टर सर्चने सिमेंटिक रिट्रिव्हलमध्ये (semantic retrieval) बदल घडवून आणला आहे. तुम्ही डेटा एम्बेड करता, क्वेरी एम्बेड करता आणि शेजारील (neighbors) घटक शोधता. त्याने जुन्या कीवर्ड मॅचिंगची जागा घेतली आहे.

परंतु प्रोडक्शन AI ला केवळ समान एम्बेडिंग्जपेक्षा अधिक गोष्टींची गरज आहे. रिट्रिव्हल आता केवळ 'नेबर' (neighbor) शोधण्याच्या समस्येवरून रँकिंग आणि निर्णय घेण्याच्या समस्येकडे वळत आहे.

प्रोटोटाइप वेक्टरवर काम करू शकतो, परंतु प्रोडक्शन सिस्टमसाठी अधिक गोष्टींची आवश्यकता असते.

एका वास्तविक युजर क्वेरीसाठी खालील गोष्टी एकाच वेळी आवश्यक असतात:

बहुतेक टीम्स विविध टूल्स एकत्र जोडून ही समस्या सोडवतात. तुम्ही एक वेक्टर डेटाबेस, सर्च इंजिन, रीरँकर (reranker) आणि फीचर स्टोअर एकमेकांशी जोडता.

यामुळे काही समस्या निर्माण होतात:

वेक्टर्स हे वन-डायमेंशनल ॲरे (one-dimensional arrays) असतात, तर टेन्सर्स (Tensors) हे मल्टी-डायमेंशनल स्ट्रक्चर्स असतात.

टेन्सर्समुळे तुम्ही डेंस एम्बेडिंग्ज (dense embeddings), स्पार्स फीचर्स (sparse features) आणि मेटाडेटा एकाच वेळी एकत्रित करू शकता. यामुळे विखुरलेल्या (fragmented) पाइपलाइन टाळता येतात.

ColBERT सारखी नवीन मॉडेल्स मल्टी-वेक्टर दृष्टिकोन वापरतात. ती एका डॉक्युमेंटला एका बिंदूमध्ये कॉम्प्रेस करत नाहीत, तर टोकन-लेव्हल तपशील (token-level details) कायम ठेवतात. यामुळे रिलेव्हन्स (relevance) सुधारते, परंतु जुने वेक्टर डेटाबेस यामध्ये अडखळतात.

टेन्सर-नेटिव्ह आर्किटेक्चर्स (Tensor-native architectures) या स्ट्रक्चर्सना मुख्य प्राधान्य देतात. ते या स्ट्रक्चर्सना साध्या वेक्टर आकारात बसवण्याचा प्रयत्न करत नाहीत.

जर तुम्ही RAG पाइपलाइन्स किंवा रेकमेंडेशन सिस्टम्स बनवत असाल, तर ही विखुरलेली रचना (fragmentation) तुमचा वेग कमी करेल. जसजशी तुमची व्याप्ती वाढेल, तसतशी ही समस्या अधिक गंभीर होईल.

स्वतःला हे प्रश्न विचारा:

तुमच्या आर्किटेक्चरल निर्णयांमध्ये मदत करण्यासाठी GigaOm च्या ब्रीफमध्ये सविस्तर माहिती वाचा.

Source: https://dev.to/thegatewayguy/vector-search-got-you-started-production-ai-needs-tensors-41dl

Optional learning community: https://t.me/GyaanSetuAi