एआई को ईटीएल का पुनः आविष्कार करने में समय बर्बाद नहीं करना चाहिए

एआई में हालिया प्रगति बहुत रोमांचक है। लोग ग्राहक सहायता अनुभवों को बेहतर बनाने और कोड लिखने और चलाने से लेकर, नया संगीत बनाने और यहां तक कि मेडिकल इमेजिंग तकनीक को तेज करने तक, हर तरह के नए तरीकों से इसका उपयोग कर रहे हैं।

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

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

मजबूत एक्सट्रैक्ट, ट्रांसफॉर्म और लोड (ईटीएल) पाइपलाइनों के निर्माण में शामिल चुनौतियों के बारे में बहुत कुछ लिखा गया है ( 1 , 2 ), लेकिन आइए इसे एआई के भीतर संदर्भ दें।

AI को डेटा मूवमेंट की आवश्यकता क्यों है?

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

इन सबके लिए डेटा मूवमेंट एक पूर्व शर्त है।

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

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

डेटा संचलन कठिन क्यों है?

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

वृद्धिशील अर्क और राज्य प्रबंधन

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

क्षणिक त्रुटि प्रबंधन, बैकऑफ़, असफलता पर फिर से शुरू करना, एयर गैपिंग

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

कॉन्फ़िगरेशन त्रुटियों की पहचान करना और सक्रिय रूप से उन्हें ठीक करना

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

प्रमाणीकरण एवं गुप्त प्रबंधन

एपीआई की सरलता साधारण बियरर टोकन ऑथ से लेकर, उह, सत्र टोकन या एकल-उपयोग-टोकन OAuth के "रचनात्मक" कार्यान्वयन तक होती है। आपको प्रमाणीकरण करने के लिए तर्क को लागू करने के साथ-साथ उन रहस्यों को प्रबंधित करने की आवश्यकता होगी जो एक घंटे में एक बार ताज़ा हो सकते हैं, संभावित रूप से कई समवर्ती श्रमिकों के बीच गुप्त ताज़ा का समन्वय कर सकते हैं।

निकालने और लोड करने की गति, संगामिति और दर सीमा को अनुकूलित करना

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

अपस्ट्रीम एपीआई परिवर्तनों को अपनाना

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

शेड्यूलिंग, मॉनिटरिंग, लॉगिंग और अवलोकन

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

डेटा ब्लॉकिंग या हैशिंग

इस पर निर्भर करते हुए कि आप डेटा कहां से खींच रहे हैं, आपको कॉलम को डाउनस्ट्रीम भेजने से पहले ब्लॉक करने या हैश करने के लिए कुछ गोपनीयता सुविधाओं की आवश्यकता हो सकती है।

स्पष्ट होने के लिए, यदि आप केवल कुछ फ़ाइलों को एक बार की चीज़ के रूप में स्थानांतरित करना चाहते हैं तो उपरोक्त लागू नहीं होता है।

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

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

तो एक एआई इंजीनियर को यहां कुछ डेटा स्थानांतरित करने के लिए क्या करना होगा?

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

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

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