इस पोस्ट का संक्षिप्त संस्करण 19 मार्च, 2024 को द न्यू स्टैक पर प्रकाशित हुआ।

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

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

एक अन्य पोस्ट में, हमने एक आधुनिक डेटालेक के लिए एक संदर्भ आर्किटेक्चर प्रस्तुत किया है जो व्यावसायिक बुद्धिमत्ता, डेटा एनालिटिक्स, डेटा विज्ञान और AI/ML की ज़रूरतों को पूरा करने में सक्षम है। आइए आधुनिक डेटालेक संदर्भ आर्किटेक्चर की समीक्षा करें और AI/ML कार्यभार का समर्थन करने के लिए इसकी क्षमताओं पर प्रकाश डालें।

आधुनिक डेटालेक

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

OTFs अपाचे आइसबर्ग, अपाचे हुडी और डेल्टा लेक हैं। इन्हें क्रमशः नेटफ्लिक्स, उबर और डेटाब्रिक्स द्वारा लिखा गया था - क्योंकि बाजार में ऐसे कोई उत्पाद नहीं थे जो उनकी डेटा आवश्यकताओं को पूरा कर सकें। अनिवार्य रूप से, वे सभी (अलग-अलग तरीकों से) एक डेटा वेयरहाउस को परिभाषित करते हैं जिसे ऑब्जेक्ट स्टोरेज (मिनियो) के शीर्ष पर बनाया जा सकता है। ऑब्जेक्ट स्टोरेज स्केलेबल क्षमता और उच्च प्रदर्शन का संयोजन प्रदान करता है जो अन्य स्टोरेज समाधान नहीं कर सकते हैं। चूंकि ये आधुनिक विनिर्देश हैं, इसलिए इनमें उन्नत सुविधाएँ हैं जो पुराने जमाने के डेटा वेयरहाउस में नहीं हैं - जैसे कि विभाजन विकास, स्कीमा विकास और शून्य-प्रतिलिपि शाखा। अंत में, चूंकि डेटा वेयरहाउस ऑब्जेक्ट स्टोरेज के साथ बनाया गया है, इसलिए आप छवियों, वीडियो फ़ाइलों, ऑडियो फ़ाइलों और दस्तावेज़ों जैसे असंरचित डेटा के लिए इसी ऑब्जेक्ट स्टोर का उपयोग कर सकते हैं।

असंरचित डेटा को आमतौर पर उस जगह संग्रहीत किया जाता है जिसे उद्योग डेटा लेक कहते हैं। अपने डेटा लेक और अपने डेटा वेयरहाउस दोनों के लिए आधार के रूप में ऑब्जेक्ट स्टोर का उपयोग करने से आपके सभी डेटा को रखने में सक्षम समाधान प्राप्त होता है। संरचित संग्रहण OTF-आधारित डेटा वेयरहाउस में रहता है और असंरचित संग्रहण डेटा लेक में रहता है। दोनों के लिए मिनियो का एक ही उदाहरण इस्तेमाल किया जा सकता है।

मिनियो में, हम OTF-आधारित डेटा वेयरहाउस और डेटा लेक के इस संयोजन को आधुनिक डेटालेक कहते हैं, और हम इसे आपके सभी AI/ML कार्यभार के लिए आधार के रूप में देखते हैं। यह वह जगह है जहाँ डेटा एकत्र, संग्रहीत, संसाधित और रूपांतरित किया जाता है। विभेदक AI (पर्यवेक्षित, अप्रशिक्षित और सुदृढ़ीकरण अधिगम) का उपयोग करके मॉडल को प्रशिक्षित करने के लिए अक्सर एक भंडारण समाधान की आवश्यकता होती है जो संरचित डेटा को संभाल सकता है जो डेटा वेयरहाउस में रह सकता है। दूसरी ओर, यदि आप बड़े भाषा मॉडल (LLM) को प्रशिक्षित कर रहे हैं, तो आपको डेटा लेक में उनके कच्चे और संसाधित रूप में असंरचित डेटा या दस्तावेज़ों का प्रबंधन करना होगा।

स्रोत :

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

• विभेदकारी ए.आई.

  
  

  • असंरचित डेटा के लिए भंडारण
  • अर्ध-संरचित डेटा के लिए भंडारण
  • डेटा वेयरहाउस में शून्य प्रतिलिपि शाखा

    
    

• जनरेटिव एआई

  
  

  • वेक्टर डेटाबेस के साथ कस्टम कॉर्पस का निर्माण
  • दस्तावेज़ पाइपलाइन का निर्माण
  • पुनर्प्राप्ति संवर्धित पीढ़ी (आरएजी)
  • बड़े भाषा मॉडल को परिष्कृत करना
  • एलएलएम सटीकता मापना

    
    

• मशीन लर्निंग संचालन

  
  

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

• GPU की वर्तमान स्थिति

  
  

  • भूखे GPU की समस्या
  • ऑब्जेक्ट स्टोरेज को सुपरचार्ज करना

    
    

• दो संगठनों की कहानी
• आपके AI डेटा इंफ्रास्ट्रक्चर के निर्माण की योजना

विभेदकारी ए.आई.

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

असंरचित डेटा के लिए भंडारण

असंरचित डेटा डेटा लेक में रहेगा, जहाँ इसका उपयोग मॉडल के प्रशिक्षण और परीक्षण के लिए किया जा सकता है। मेमोरी में फ़िट होने वाले प्रशिक्षण सेट को प्रशिक्षण से पहले लोड किया जा सकता है (आपके एपोच लूप के शुरू होने से पहले)। हालाँकि, यदि आपका प्रशिक्षण सेट बड़ा है और मेमोरी में फ़िट नहीं होगा, तो आपको प्रशिक्षण से पहले ऑब्जेक्ट की एक सूची लोड करनी होगी और अपने एपोच लूप में प्रत्येक बैच को संसाधित करते समय वास्तविक ऑब्जेक्ट को पुनः प्राप्त करना होगा। यदि आप हाई-स्पीड नेटवर्क और हाई-स्पीड डिस्क ड्राइव का उपयोग करके अपना डेटा लेक नहीं बनाते हैं, तो यह आपके डेटा लेक पर दबाव डाल सकता है। यदि आप ऐसे डेटा के साथ मॉडल को प्रशिक्षित कर रहे हैं जो मेमोरी में फ़िट नहीं हो सकता है, तो 100 जीबी नेटवर्क और NVMe ड्राइव के साथ अपना डेटा लेक बनाने पर विचार करें।

अर्ध-संरचित डेटा के लिए भंडारण

मॉडर्न डेटालेक में अर्ध-संरचित फ़ाइलों जैसे कि पार्केट फ़ाइलें, AVRO फ़ाइलें, JSON फ़ाइलें और यहाँ तक कि CSV फ़ाइलें संग्रहीत करने के लिए कुछ विकल्प उपलब्ध हैं। सबसे आसान काम उन्हें अपने डेटा लेक में संग्रहीत करना और उन्हें उसी तरह लोड करना है जैसे आप असंरचित ऑब्जेक्ट लोड करते हैं। यदि इन अर्ध-संरचित फ़ाइलों में मौजूद डेटा की आवश्यकता अन्य कार्यभारों को नहीं है जिन्हें मॉडर्न डेटालेक सपोर्ट करता है (बिजनेस इंटेलिजेंस, डेटा एनालिटिक्स और डेटा साइंस), तो यह सबसे अच्छा विकल्प है।

दूसरा विकल्प इन फ़ाइलों को अपने डेटा वेयरहाउस में लोड करना है, जहाँ अन्य वर्कलोड उनका उपयोग कर सकते हैं। जब डेटा आपके डेटा वेयरहाउस में लोड हो जाता है, तो आप इसका उपयोग कर सकते हैं अपने डेटा के साथ.

डेटा वेयरहाउस में शून्य प्रतिलिपि शाखा

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

जनरेटिव एआई

सभी मॉडल, चाहे वे Scikit-Learn के साथ बनाए गए छोटे मॉडल हों, PyTorch या TensorFlow के साथ बनाए गए कस्टम न्यूरल नेटवर्क हों, या ट्रांसफॉर्मर आर्किटेक्चर पर आधारित बड़े भाषा मॉडल हों, उन्हें इनपुट के रूप में संख्याओं की आवश्यकता होती है और आउटपुट के रूप में संख्याएँ उत्पन्न होती हैं। यह सरल तथ्य आपके AI/ML इंफ्रास्ट्रक्चर पर कुछ अतिरिक्त आवश्यकताएँ रखता है यदि आप जेनरेटिव AI में रुचि रखते हैं, जहाँ शब्दों को संख्याओं (या वैक्टर, जैसा कि हम देखेंगे) में बदलना होगा। यदि आप LLM द्वारा उत्पादित उत्तरों को बढ़ाने के लिए अपनी कंपनी के स्वामित्व वाले ज्ञान वाले निजी दस्तावेज़ों का उपयोग करना चाहते हैं तो जेनरेटिव AI समाधान और भी जटिल हो जाता है। यह वृद्धि रिट्रीवल ऑगमेंटेड जेनरेशन या LLM फ़ाइन-ट्यूनिंग के रूप में हो सकती है।

इस खंड में इन सभी तकनीकों (शब्दों को संख्याओं में बदलना, RAG और फ़ाइन-ट्यूनिंग) और AI इंफ्रास्ट्रक्चर पर उनके प्रभाव पर चर्चा की जाएगी। आइए चर्चा करके शुरू करें कि कस्टम कॉर्पस कैसे बनाया जाए और इसे कहाँ रखा जाना चाहिए।

वेक्टर डेटाबेस के साथ कस्टम कॉर्पस बनाना

यदि आप जेनरेटिव एआई के बारे में गंभीर हैं, तो आपके कस्टम कॉर्पस को आपके संगठन को परिभाषित करना चाहिए। इसमें ऐसे ज्ञान वाले दस्तावेज़ होने चाहिए जो किसी और के पास नहीं हैं और केवल सच्ची और सटीक जानकारी होनी चाहिए। इसके अलावा, आपके कस्टम कॉर्पस को वेक्टर डेटाबेस के साथ बनाया जाना चाहिए। एक वेक्टर डेटाबेस आपके दस्तावेज़ों को उनके वेक्टर एम्बेडिंग के साथ अनुक्रमित करता है, संग्रहीत करता है और उन तक पहुँच प्रदान करता है, जो आपके दस्तावेज़ों का संख्यात्मक प्रतिनिधित्व हैं। (यह ऊपर वर्णित संख्या समस्या को हल करता है।)

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

 SELECT snippet FROM MyCorpusTable WHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ...

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

 { Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } }

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

अपने मूल में, वेक्टर डेटाबेस असंरचित डेटा संग्रहीत करते हैं। इसलिए, उन्हें आपके डेटा लेक को अपने स्टोरेज समाधान के रूप में उपयोग करना चाहिए।

दस्तावेज़ पाइपलाइन का निर्माण

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

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

बड़े भाषा मॉडल को परिष्कृत करना

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

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

नुकसान

• फाइन-ट्यूनिंग के लिए कम्प्यूट संसाधनों की आवश्यकता होगी।
• व्याख्या करना संभव नहीं है.
• जैसे-जैसे आपका कोष विकसित होता जाएगा, आपको समय-समय पर नए डेटा के साथ इसे पुनः परिष्कृत करने की आवश्यकता होगी।
• मतिभ्रम एक चिंता का विषय है।
• दस्तावेज़-स्तर की सुरक्षा असंभव है।

  
  

लाभ

• एलएलएम में आपके कस्टम कॉर्पस से फाइन-ट्यूनिंग के माध्यम से ज्ञान प्राप्त होता है।
• अनुमान प्रवाह RAG की तुलना में कम जटिल है।

  
  

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

आइए एक ऐसी तकनीक पर नजर डालें जो अनुमान के समय आपके कस्टम डेटा और पैरामीट्रिक डेटा को संयोजित करती है।

पुनर्प्राप्ति संवर्धित पीढ़ी (आरएजी)

रिट्रीवल ऑगमेंटेड जेनरेशन (RAG) एक ऐसी तकनीक है जो पूछे जाने वाले प्रश्न से शुरू होती है - प्रश्नों को अतिरिक्त डेटा के साथ जोड़ने के लिए वेक्टर डेटाबेस का उपयोग करती है, और फिर सामग्री निर्माण के लिए प्रश्न और डेटा को LLM को भेजती है। RAG के साथ, किसी प्रशिक्षण की आवश्यकता नहीं है क्योंकि हम LLM को हमारे गुणवत्तापूर्ण दस्तावेज़ों के संग्रह से प्रासंगिक टेक्स्ट स्निपेट भेजकर शिक्षित करते हैं।

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

यह फ़ाइन-ट्यूनिंग से ज़्यादा जटिल है। हालाँकि, उपयोगकर्ता प्राधिकरण को लागू किया जा सकता है क्योंकि दस्तावेज़ (या दस्तावेज़ स्निपेट) अनुमान के समय वेक्टर डेटाबेस से चुने जाते हैं। दस्तावेज़ों में मौजूद जानकारी कभी भी मॉडल के पैरामीट्रिक मापदंडों का हिस्सा नहीं बनती। RAG के फ़ायदे और नुकसान नीचे सूचीबद्ध हैं।

नुकसान

• अनुमान प्रवाह अधिक जटिल है।

  
  

लाभ

• एलएलएम को आपके कस्टम कॉर्पस से प्रत्यक्ष ज्ञान प्राप्त होता है।
• व्याख्या संभव है।
• इसमें किसी बारीक बदलाव की जरूरत नहीं है।
• वेक्टर डाटाबेस क्वेरीज़ के परिणामों की जांच करके मतिभ्रम को काफी हद तक कम किया जा सकता है और इसे नियंत्रित किया जा सकता है।
• प्राधिकरण क्रियान्वित किया जा सकता है।

मशीन लर्निंग ऑपरेशन (एमएलओपीएस)

MLOps के महत्व को बेहतर ढंग से समझने के लिए, मॉडल निर्माण की तुलना पारंपरिक अनुप्रयोग विकास से करना सहायक है। पारंपरिक अनुप्रयोग विकास, जैसे कि किसी अनुप्रयोग में नई सुविधा जोड़ने वाले नए माइक्रोसर्विस को लागू करना, विनिर्देश की समीक्षा के साथ शुरू होता है। कोई भी नई डेटा संरचना या मौजूदा डेटा संरचना में कोई भी परिवर्तन पहले डिज़ाइन किया जाता है। कोडिंग शुरू होने के बाद डेटा का डिज़ाइन नहीं बदलना चाहिए। फिर सेवा को लागू किया जाता है और इस प्रक्रिया में कोडिंग मुख्य गतिविधि होती है। यूनिट टेस्ट और एंड-टू-एंड टेस्ट भी कोड किए जाते हैं। ये परीक्षण साबित करते हैं कि कोड दोषपूर्ण नहीं है और विनिर्देश को सही ढंग से लागू करता है। संपूर्ण अनुप्रयोग को तैनात करने से पहले उन्हें CI/CD पाइपलाइन द्वारा स्वचालित रूप से चलाया जा सकता है।

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

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

1. किसी प्रमुख खिलाड़ी से समर्थन - MLOps तकनीक और सुविधाएँ लगातार विकसित हो रही हैं। आप एक ऐसा उपकरण चाहते हैं जो किसी प्रमुख खिलाड़ी द्वारा समर्थित हो, यह सुनिश्चित करते हुए कि उपकरण निरंतर विकास और सुधार के अधीन है।

   
   

2. आधुनिक डेटालेक एकीकरण - प्रयोगों से बहुत सारा संरचित और असंरचित डेटा उत्पन्न होता है। आदर्श रूप से, इसे डेटा वेयरहाउस और डेटा लेक में संग्रहीत किया जा सकता है। हालाँकि, कई MLOps उपकरण ओपन टेबल फ़ॉर्मेट से पहले मौजूद थे, जिसने आधुनिक डेटालेक को जन्म दिया, इसलिए अधिकांश के पास अपने संरचित डेटा के लिए एक अलग समाधान होगा।

   
   

3. प्रयोग ट्रैकिंग - प्रत्येक प्रयोग के डेटासेट, मॉडल, हाइपरपैरामीटर और मेट्रिक्स का ट्रैक रखें। प्रयोग ट्रैकिंग से दोहराव की सुविधा भी मिलनी चाहिए।

   
   

4. सहयोग को सुगम बनाना - टीम के सदस्यों को सभी एमएल इंजीनियरों द्वारा चलाए गए सभी प्रयोगों के परिणाम देखने की अनुमति देना।

   
   

5. मॉडल पैकेजिंग - मॉडल को इस प्रकार पैकेज करें कि वह अन्य प्रोग्रामिंग वातावरणों से सुलभ हो सके।

   
   

6. मॉडल सेवा - किसी संगठन के औपचारिक वातावरण में मॉडल तैनात करना। यदि आपको अपने मॉडल को मौजूदा CI/CD पाइपलाइन में शामिल करने का तरीका मिल गया है, तो आपको इसकी आवश्यकता नहीं होगी।

   
   

7. मॉडल रजिस्ट्री - सभी मॉडलों के सभी संस्करणों को बनाए रखें।

   
   

8. सर्वर रहित फ़ंक्शन - कुछ उपकरण ऐसी सुविधाएँ प्रदान करते हैं जो कोड को इस तरह से एनोटेट करने की अनुमति देते हैं कि किसी फ़ंक्शन या मॉडल को क्लस्टर में प्रयोग चलाने के लिए कंटेनरीकृत सेवा के रूप में तैनात किया जा सके।

   
   

9. डेटा पाइपलाइन क्षमताएँ - कुछ MLOps टूल का उद्देश्य संपूर्ण एंड-टू-एंड क्षमताएँ प्रदान करना है और इनमें ऐसी सुविधाएँ हैं जो आपको अपने कच्चे डेटा को पुनः प्राप्त करने और संग्रहीत करने के लिए पाइपलाइन बनाने की अनुमति देती हैं। यदि आपके पास पहले से ही डेटा पाइपलाइन है, तो आपको इसकी आवश्यकता नहीं होगी।

   
   

10. प्रशिक्षण पाइपलाइन क्षमताएँ - आपके सर्वरलेस फ़ंक्शन को निर्देशित अचक्रीय ग्राफ़ में ऑर्केस्ट्रेट करने की क्षमता। प्रशिक्षण पाइपलाइनों को शेड्यूल करने और चलाने की भी अनुमति देता है।

आपके AI डेटा इंफ्रास्ट्रक्चर पर GPU का प्रभाव

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

दुर्भाग्य से, इस समस्या से जूझ रहे लोगों के लिए बुरी खबर है। GPU की गति बढ़ती जा रही है। आइए GPU की वर्तमान स्थिति और उनके साथ की जा रही कुछ प्रगति पर नज़र डालें ताकि यह समझा जा सके कि आने वाले सालों में यह समस्या और भी बदतर कैसे हो जाएगी।

GPU की वर्तमान स्थिति

GPU तेज़ होते जा रहे हैं। न केवल रॉ परफॉरमेंस बेहतर हो रहा है, बल्कि मेमोरी और बैंडविड्थ भी बढ़ रही है। आइए Nvidia के सबसे हालिया GPU की इन तीन विशेषताओं पर एक नज़र डालें , द और यह .

जीपीयू	प्रदर्शन	याद	मेमोरी बैंडविड्थ
ए100	624 टीएफएलओपीएस	40जीबी	1,555जीबी/एस
एच100	1,979 टीएफएलओपीएस	80जीबी	3.35टीबी/एस
एच200	1,979 टीएफएलओपीएस	141जीबी	4.8टीबी/एस

ऊपर दिए गए आँकड़ों पर कुछ तुलनात्मक अवलोकन ध्यान देने योग्य हैं। सबसे पहले, H100 और H200 का प्रदर्शन समान है (1,979 TFLOPS), जो A100 से 3.17 गुना ज़्यादा है। H100 में A100 से दोगुनी मेमोरी है और मेमोरी बैंडविड्थ में भी उतनी ही वृद्धि हुई है - जो समझ में आता है, अन्यथा GPU खुद को भूखा रखेगा। H200 141GB की मेमोरी संभाल सकता है और इसकी मेमोरी बैंडविड्थ भी अन्य GPU के सापेक्ष आनुपातिक रूप से बढ़ी है।

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

प्रदर्शन - एक टेराफ्लॉप (TFLOP) प्रति सेकंड एक ट्रिलियन (10^12) फ़्लोटिंग-पॉइंट ऑपरेशन है। यह एक 1 है जिसके बाद 12 शून्य हैं (1,000,000,000,000)। मॉडल प्रशिक्षण के दौरान होने वाले फ़्लोटिंग पॉइंट ऑपरेशन में सरल टेंसर गणित के साथ-साथ हानि फ़ंक्शन (उर्फ ग्रेडिएंट) के विरुद्ध पहले व्युत्पन्न शामिल होने के कारण TFLOPs को गीगाबाइट में IO मांग के बराबर करना कठिन है। हालाँकि, सापेक्ष तुलना संभव है। ऊपर दिए गए आँकड़ों को देखते हुए, हम देखते हैं कि H100 और H200, जो दोनों 1,979 TFLOPS पर प्रदर्शन करते हैं, तीन गुना तेज़ हैं - संभावित रूप से डेटा का उपभोग 3 गुना तेज़ी से करते हैं यदि बाकी सब कुछ बनाए रखा जा सकता है।

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

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

मॉडल प्रशिक्षण के लिए ऑब्जेक्ट स्टोरेज को सुपरचार्ज करें

यदि आप GPU की कमी की समस्या का सामना कर रहे हैं, तो 100 GB नेटवर्क और NVMe ड्राइव का उपयोग करने पर विचार करें। इस तरह के कॉन्फ़िगरेशन के साथ MinIO का उपयोग करने से, ऑफ-द-शेल्फ NVMe SSDs के केवल 32 नोड्स के साथ GETs पर 325 GiB/s और PUTs पर 165 GiB/s की गति प्राप्त हुई।

जैसे-जैसे कंप्यूटिंग की दुनिया विकसित हुई है हम पाते हैं कि सर्वर कॉन्फ़िगरेशन अक्सर 500GB या उससे ज़्यादा DRAM के साथ आते हैं। जब आप बड़े डिप्लॉयमेंट से निपट रहे होते हैं, यहाँ तक कि अल्ट्रा-डेंस NVMe ड्राइव वाले भी, तो उन सर्वर पर DRAM से गुणा किए गए सर्वर की संख्या तेज़ी से बढ़ सकती है - अक्सर प्रति इंस्टेंस कई TB तक। उस DRAM पूल को मेमोरी के वितरित साझा पूल के रूप में कॉन्फ़िगर किया जा सकता है और यह उन कार्यभारों के लिए आदर्श है जो बड़े IOPS और थ्रूपुट प्रदर्शन की मांग करते हैं। नतीजतन, हमने अपने एंटरप्राइज़ और एंटरप्राइज़ लाइट ग्राहकों को कोर AI कार्यभार - जैसे GPU प्रशिक्षण - के लिए प्रदर्शन को और बेहतर बनाने के लिए इस साझा मेमोरी पूल का लाभ उठाने के लिए अपने बुनियादी ढांचे को कॉन्फ़िगर करने में सक्षम बनाने के लिए MinIO कैश बनाया, जबकि एक साथ पूर्ण दृढ़ता बनाए रखी।

दो संगठनों की कहानी

एक अंतिम विचार प्रयोग के रूप में, आइए दो संगठनों की कहानी बताते हैं जो अपनी AI/ML यात्रा पर बहुत अलग दृष्टिकोण अपनाते हैं। संगठन #1 में "पुनरावृत्तीय सुधार" की संस्कृति है। उनका मानना है कि सभी बड़ी पहलों को छोटी, अधिक प्रबंधनीय परियोजनाओं में तोड़ा जा सकता है। इन छोटी परियोजनाओं को फिर इस तरह से शेड्यूल किया जाता है कि प्रत्येक परियोजना अधिक से अधिक जटिलता वाली समस्याओं को हल करने के लिए पिछली परियोजना के परिणामों पर आधारित होती है। उन्हें ये छोटी परियोजनाएँ इस तरह से व्यवस्थित भी पसंद हैं कि प्रत्येक परियोजना व्यवसाय को मूल्य प्रदान करे। उन्होंने पाया है कि जो परियोजनाएँ केवल व्यवसाय के लिए किसी नई सुविधा के बिना बुनियादी ढाँचे में सुधार या सॉफ़्टवेयर को आधुनिक बनाने के बारे में हैं, वे बजट को नियंत्रित करने वाले अधिकारियों के बीच बहुत लोकप्रिय नहीं हैं। नतीजतन, उन्होंने सीखा है कि एक जनरेटिव AI प्रूफ़ ऑफ़ कॉन्सेप्ट के लिए फैंसी स्टोरेज एप्लायंस और कंप्यूट क्लस्टर का अनुरोध करना बुनियादी ढाँचे में सुधार और नई सॉफ़्टवेयर क्षमताओं को व्यवस्थित करने का सबसे अच्छा तरीका नहीं है। इसके बजाय, वे बुनियादी ढाँचे के उत्पादों के साथ छोटी शुरुआत करेंगे जो बढ़ने के साथ-साथ बढ़ सकते हैं - और वे सरल AI मॉडल से शुरुआत करेंगे ताकि वे अपने MLOP टूलिंग को जगह दे सकें और यह पता लगा सकें कि मौजूदा DevOps टीमों और CI/CD पाइपलाइनों के साथ कैसे काम किया जाए।

संगठन #2 में "चमकदार वस्तुएँ" संस्कृति है। जब कोई नया विचार उद्योग में प्रवेश करता है, तो वह सबसे पहले अपनी तकनीकी शक्ति का प्रदर्शन करने के लिए सबसे उच्च-प्रोफ़ाइल चुनौती का सामना करता है। उन्होंने पाया है कि ये परियोजनाएँ आंतरिक और बाहरी दोनों ही तरह से अत्यधिक दिखाई देती हैं। अगर कुछ टूटता है, तो स्मार्ट लोग हमेशा इसे ठीक कर सकते हैं।

संगठन #1 ने अपनी मुख्य ई-कॉमर्स साइट के लिए एक अनुशंसा मॉडल पर काम करते हुए अपने AI डेटा इंफ्रास्ट्रक्चर के एक हिस्से का निर्माण करके अपनी पहली परियोजना की संरचना की। अनुशंसा मॉडल को प्रशिक्षित करना अपेक्षाकृत सरल था। यह एक विभेदक मॉडल है जो फ़ाइल शेयर पर पहले से मौजूद डेटासेट का उपयोग करता है। हालाँकि, इस परियोजना के अंत में टीम ने एक छोटा (लेकिन स्केलेबल) मॉडर्न डेटालेक भी बनाया था, MLOPs टूलिंग को लागू किया था, और मॉडलों को प्रशिक्षित करने और तैनात करने के लिए कुछ सर्वोत्तम अभ्यास किए थे। भले ही मॉडल जटिल नहीं है, फिर भी इसने उनकी साइट में बहुत सारी दक्षताएँ जोड़ीं। उन्होंने इन सकारात्मक परिणामों का उपयोग अपनी अगली परियोजना के लिए धन प्राप्त करने के लिए किया, जो एक जनरेटिव AI समाधान होगा।

संगठन #2 ने अपने ई-कॉमर्स साइट के लिए एक चैटबॉट बनाया जो उत्पादों के बारे में ग्राहकों के सवालों का जवाब देता था। बड़ी भाषा मॉडल काफी जटिल हैं - टीम फ़ाइन-ट्यूनिंग या रिट्रीवल ऑगमेंटेड जेनरेशन से परिचित नहीं थी - इसलिए इस परियोजना के लिए सभी इंजीनियर चक्र एक खड़ी सीखने की अवस्था पर तेज़ी से आगे बढ़ने पर केंद्रित थे। जब मॉडल पूरा हो गया, तो इसने ठीक-ठाक परिणाम दिए - कुछ भी शानदार नहीं। दुर्भाग्य से, इसे प्री-प्रोडक्शन और प्रोडक्शन वातावरण में मैन्युअल रूप से साइड-लोड करना पड़ा क्योंकि इसे तैनात करने के लिए कोई MLOps टूलिंग नहीं थी। इससे DevOps टीम के साथ थोड़ा घर्षण हुआ। मॉडल में उत्पादन में कुछ स्थिरता संबंधी समस्याएँ भी थीं। जिस क्लस्टर में यह चल रहा था, उसमें जनरेटिव AI कार्यभार के लिए पर्याप्त कंप्यूट नहीं था। कुछ गंभीरता-एक कॉल थे, जिसके परिणामस्वरूप क्लस्टर में एक आपातकालीन वृद्धि हुई ताकि LLM भारी ट्रैफ़िक स्थितियों में विफल न हो। परियोजना के बाद, एक पूर्वव्यापी ने निर्धारित किया कि अगर उन्हें AI के साथ सफल होना है तो उन्हें अपने बुनियादी ढांचे को बढ़ाने की आवश्यकता है।

आपके AI/ML डेटा इंफ्रास्ट्रक्चर के निर्माण की योजना

ऊपर दी गई छोटी कहानी दो चरम परिस्थितियों की एक सरल कथा है। AI मॉडल (विभेदक और उत्पादक दोनों) बनाना पारंपरिक सॉफ़्टवेयर विकास से काफी अलग है। AI/ML प्रयास को कतारबद्ध करते समय इसे ध्यान में रखा जाना चाहिए। नीचे दिया गया ग्राफ़िक पिछले अनुभाग में बताई गई कहानी का एक दृश्य चित्रण है। यह AI डेटा इंफ्रास्ट्रक्चर फ़र्स्ट बनाम मॉडल फ़र्स्ट दृष्टिकोण की एक साथ तुलना है। जैसा कि ऊपर की कहानी में दिखाया गया है - इंफ्रास्ट्रक्चर फ़र्स्ट दृष्टिकोण के लिए नीचे दी गई प्रत्येक ईंट को एक स्टैंडअलोन प्रोजेक्ट होने की ज़रूरत नहीं है। संगठनों को अपने इंफ्रास्ट्रक्चर के निर्माण के दौरान AI को डिलीवर करने के लिए रचनात्मक तरीकों की तलाश करनी चाहिए - यह AI के साथ सभी संभावनाओं को समझकर, सरल शुरुआत करके और फिर बढ़ती जटिलता वाली AI परियोजनाओं को चुनकर किया जा सकता है।

निष्कर्ष

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

इस संदर्भ आर्किटेक्चर का पालन करके, हम उम्मीद करते हैं कि उपयोगकर्ता एक लचीला, विस्तार योग्य डेटा इंफ्रास्ट्रक्चर बनाने में सक्षम होगा जो AI और ML पर लक्षित होने के साथ-साथ सभी OLAP वर्कलोड पर समान रूप से प्रदर्शन करेगा। घटक भागों पर विशिष्ट अनुशंसाएँ प्राप्त करने के लिए, कृपया मुझसे संपर्क करने में संकोच न करें .