निकुंज बजाज, TrueFoundry के सह-संस्थापक और सीईओ – साक्षात्कार श्रृंखला

TrueFoundry की स्थापना से पहले आपने मशीन लर्निंग अनुसंधान, Facebook (META ) में वास्तविक परिचालन वाले एआई और बड़े पैमाने की अनुशंसा प्रणालियों पर काम किया। किन अनुभवों ने आपको उद्यमों के लिए एआई अवसंरचना कंपनी बनाने की ओर सबसे सीधे प्रेरित किया, और आपको कौन-सी समस्या उस समय अनसुलझी लगती थी?

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

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

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

जैसे-जैसे एआई प्रणालियाँ प्रयोगों से रोजमर्रा के संचालन में आ रही हैं, संगठनों को विश्वसनीयता और विफलता के बारे में जिस तरह सोचना चाहिए, उसमें क्या बदलाव आया है?

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

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

संगठनों को विश्वसनीयता पर विचार करते समय केवल प्रणाली के चालू रहने की अवधि ही नहीं, बल्कि समय के साथ प्रदर्शन में आने वाली गिरावट भी देखनी चाहिए।

TrueFailover लॉन्च हुआ उस समय, जब क्लाउड और एआई सेवाओं में कई चर्चित व्यवधान आए थे। हाल की किन घटनाओं ने स्पष्ट किया कि एआई की विश्वसनीयता अब केवल एक अच्छी अतिरिक्त सुविधा नहीं, बल्कि आर्किटेक्चर की बुनियादी आवश्यकता है?

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

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

एआई सेवाओं के कई व्यवधान अब भी मामूली तकनीकी अड़चन बताए जाते हैं। एआई प्रणालियाँ बंद होने पर वास्तविक आर्थिक और मानवीय लागतें कहाँ उभरती दिखाई देती हैं?

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

जैसे-जैसे एआई प्रणालियाँ परिचालन वर्कफ़्लो में गहराई से जुड़ रही हैं, व्यवधान केवल तकनीकी समस्याएँ नहीं रह गए हैं। उनके व्यवसाय, ग्राहकों और प्रतिष्ठा पर सीधे परिणाम लगातार बढ़ रहे हैं।

फार्मेसी, स्वास्थ्य सेवा संचालन या ग्राहक सहायता जैसे अत्यावश्यक परिवेशों में एआई के बंद रहने की स्थिति कितनी जल्दी परिचालन या प्रतिष्ठा संबंधी जोखिम बन सकती है?

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

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

आपने कहा है कि कई टीमें निरंतर संचालन के बजाय क्षमताओं को ध्यान में रखकर आर्किटेक्चर बनाती हैं। एआई प्रणालियों के डिज़ाइन में अब तक विफलताओं को सहन करने की क्षमता को कम प्राथमिकता क्यों दी गई है?

इसका मुख्य कारण संगठनों के भीतर प्रोत्साहनों की व्यवस्था है। नई क्षमताएँ स्पष्ट दिखाई देती हैं और उत्साह पैदा करती हैं। वे डेमो, सुविधाओं और उत्पाद की नई संभावनाओं को संभव बनाती हैं, जिन्हें नेतृत्व तुरंत देख सकता है।

निरंतर संचालन का स्वभाव ही ऐसा है कि जब सब ठीक चल रहा हो, तो वह नजर नहीं आता। इसलिए पुरस्कार की व्यवस्थाएँ अक्सर यह सुनिश्चित करने के बजाय कि कुछ खराब न हो, नई सुविधाएँ जारी करने की ओर झुकी होती हैं। नतीजतन, संगठन अक्सर विफलता-सहनशीलता की इंजीनियरिंग की तुलना में क्षमताओं के विकास में अनुपातहीन रूप से अधिक निवेश करते हैं।

उद्यम बाहरी मॉडलों और एपीआई पर अधिक निर्भर हो रहे हैं। इससे एआई स्टैक में कौन-सी नई कमजोरियाँ आ रही हैं, जिनकी गंभीरता नेतृत्व शायद अभी पूरी तरह न समझ पाया हो?

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

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

विशिष्ट उत्पादों पर ध्यान दिए बिना, संगठनों को एआई आर्किटेक्चर पर कैसे पुनर्विचार करना चाहिए ताकि व्यवधानों को दुर्लभ अपवाद मानने के बजाय विफलता होने की संभावना को आधार बनाया जाए?

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

एआई प्रणालियों के लिए भी अलग दृष्टिकोण नहीं होना चाहिए। हमें मानना चाहिए कि मॉडल प्रदाताओं को विलंबता, गिरावट या व्यवधान की समस्याएँ होंगी, और रिडंडेंसी शामिल करनी चाहिए ताकि अनुप्रयोग विफलता के अलग-अलग परिदृश्यों में भी टिके रह सकें।

क्या आपको लगता है कि एआई की विफलता-सहनशीलता प्लेटफ़ॉर्म और विक्रेता के चयन में निर्णायक कारक बन जाएगी, ठीक जैसे अपटाइम और रिडंडेंसी ने क्लाउड अवसंरचना के निर्णयों को प्रभावित किया था?

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

आगे देखते हुए, ऐसी दुनिया में “वास्तविक परिचालन के लिए तैयार” एआई का असली अर्थ क्या है, जहाँ उससे कभी-कभार उपयोगी होने के बजाय लगातार उपलब्ध रहने की अपेक्षा की जाती है?

वास्तविक परिचालन के लिए तैयार एआई प्रणालियों में ऑब्ज़र्वेबिलिटी होनी चाहिए, उन्हें नियंत्रित किया जा सकना चाहिए और विफलता के बाद उनका संचालन बहाल किया जा सकना चाहिए। इन तीनों आवश्यकताओं का पूरा होना जरूरी है।

परिचालन में एआई की ऑब्ज़र्वेबिलिटी के लिए टीमों को मॉडल के व्यवहार, विलंबता, त्रुटि दर, टोकन के उपयोग, ड्रिफ्ट और विफलता के पैटर्न की गहरी जानकारी चाहिए। मजबूत ऑब्ज़र्वेबिलिटी के बिना, उपयोगकर्ताओं को गिरावट नजर आने से पहले उसका पता लगाना बहुत कठिन हो जाता है।

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

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

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

इस बेहतरीन साक्षात्कार के लिए धन्यवाद। अधिक जानने के इच्छुक पाठक TrueFoundry की वेबसाइट देख सकते हैं।