साक्षात्कार
शेनिया लेवेन, एम्प्रोम्प्टु एआई की संस्थापक और सीईओ – साक्षात्कार श्रृंखला
Unite.AI को Google पर अपने पसंदीदा स्रोतों में जोड़ें
शेनिया लेवेन, एम्प्रोम्प्टु एआई की संस्थापक और सीईओ, एक अनुभवी उत्पाद नेता हैं जिनके पास प्रमुख प्रौद्योगिकी कंपनियों में विकासकर्ता प्लेटफ़ॉर्म और एआई-संचालित उत्पादों का निर्माण करने का व्यापक अनुभव है। एम्प्रोम्प्टु लॉन्च करने से पहले, उन्होंने कोडसी, एक एआई डेवलपर प्लेटफ़ॉर्म की स्थापना की थी, जो टीमों को जटिल कोडबेस को देखने और समझने में मदद करता है, जिसे 2024 में गिटक्रैकन द्वारा अधिग्रहित किया गया था। अपने करियर की शुरुआत में, उन्होंने डॉकर, क्लाउडफ्लेयर, ईबे और गूगल जैसी कंपनियों में वरिष्ठ उत्पाद नेतृत्व भूमिकाएं निभाईं, जहां उन्होंने गूगल असिस्टेंट भुगतान एपीआई से लेकर सैकड़ों हज़ारों शिक्षार्थियों द्वारा उपयोग किए जाने वाले विकासकर्ता शिक्षा कार्यक्रमों तक कई पहलों पर काम किया।
(GOOGL )एम्प्रोम्प्टु एआई एक उद्यम प्लेटफ़ॉर्म है जो संगठनों को एकीकृत एआई अनुप्रयोगों का निर्माण और तैनाती करने में मदद करने के लिए डिज़ाइन किया गया है। प्लेटफ़ॉर्म अनुप्रयोग विकास, डेटा एकीकरण, शासन, मूल्यांकन, स्मृति और मॉडल ऑर्केस्ट्रेशन को एक ही वातावरण में जोड़ती है, जिससे कंपनियां तेजी से एआई प्रयोग से उत्पादन-ग्रेड प्रणालियों में स्थानांतरित हो सकती हैं जो उद्यम उपयोग के लिए आवश्यक नियंत्रण और विश्वसनीयता के साथ हैं।
आपने गूगल, ईबे, क्लाउडफ्लेयर और डॉकर जैसी कंपनियों में विकासकर्ता प्लेटफ़ॉर्म बनाने में 15 से अधिक वर्ष बिताए, फिर कोडसी की स्थापना की, जिसे बाद में गिटक्रैकन द्वारा अधिग्रहित किया गया, और अब एम्प्रोम्प्टु एआई का नेतृत्व कर रहे हैं। उन अनुभवों ने आपके दृष्टिकोण को आकार देने में कैसे मदद की कि इतने सारे एआई टूल डेमो स्टेज से बाहर निकलने के बाद विफल क्यों हो जाते हैं, और जब आपने एम्प्रोम्प्टु की स्थापना की तो आप किस विशिष्ट समस्या का समाधान करने के लिए निर्धारित थे?
विकासकर्ता प्लेटफ़ॉर्म बनाने से सीखने वाली चीजों में से एक यह है कि सबसे कठिन समस्याएं कभी भी डेमो में नहीं होती हैं। डेमो हमेशा काम करता है। असली परीक्षण यह है कि जब हज़ारों विकासकर्ता प्रणाली का उपयोग करते हैं, जब डेटा गंदा होता है, जब एकीकरण टूट जाते हैं, और जब वास्तविक व्यवसाय इस पर निर्भर करते हैं।
गूगल, क्लाउडफ्लेयर, डॉकर और ईबे में मैंने वैश्विक स्तर पर संचालित करने वाले प्लेटफ़ॉर्म पर वर्षों तक काम किया। वे वातावरण आपको जल्दी से कुछ सिखाते हैं: विश्वसनीयता, शासन और पर्यवेक्षण बाद में जोड़ने के लिए विशेषताएं नहीं हैं। वे वास्तुकला हैं।
जब मैंने एआई अनुप्रयोगों का निर्माण शुरू किया, तो मॉडल भयानक थे और जब वे बेहतर होने लगे तो मैंने देखा कि उद्योग पहले के सॉफ़्टवेयर लहरों में देखी गई aynı गलती को दोहरा रहा था। डेव टूल्स में एक अवधारणा जैसा लगता है कि भूल गया है। कितनी तेजी से आप हैलो वर्ल्ड तक पहुंच सकते हैं? आज, हैलो वर्ल्ड का उत्पन्न संस्करण एक पूरी कार्यशील सास प्रोटोटाइप है। लेकिन अब हम सिर्फ सास अनुप्रयोगों को वाइब कोड नहीं करते हैं; हम पूरे एआई अनुप्रयोगों को वाइब कोड करते हैं। एक एआई जो एआई बनाता है उसे उत्पादन में रखने के लिए अन्य प्रणालियों की आवश्यकता होती है।
आप एक कार्यशील एआई अनुप्रयोग या सुविधा को जल्दी से उत्पन्न कर सकते हैं, जो उत्साहजनक और वास्तव में उपयोगी है। लेकिन वर्तमान प्रणालियों में अभी भी उत्पादन वातावरण के लिए आवश्यक बुनियादी ढांचे की कमी है। संरचित डेटा पाइपलाइन, मूल्यांकन ढांचे, शासन नियंत्रण, निगरानी और दीर्घकालिक संदर्भ प्रबंधन जैसी चीजें याद आ रही थीं लेकिन हमने उन्हें रखते हुए वाइब कोडिंग के सभी अद्भुत भागों को बनाए रखा है।
जब मेरे सह-संस्थापक और मैंने एम्प्रोम्प्टु की स्थापना की, तो हम जिस समस्या का समाधान करना चाहते थे वह सरल था: हम एआई अनुप्रयोगों को शुरू से ही उत्पादन तैयार कैसे बना सकते हैं?
शासन, डेटा तैयारी, मूल्यांकन और अनुकूलन को अलग-अलग उपकरण या बाद की प्रक्रियाओं के रूप में मानने के बजाय, हमने उन्हें सीधे प्लेटफ़ॉर्म में बनाया। विचार यह है कि टीमें एआई अनुप्रयोगों का निर्माण जल्दी से कर सकती हैं, लेकिन उद्यम सॉफ़्टवेयर प्रणालियों की तरह ही विश्वसनीयता, गुणवत्ता और नियंत्रण के साथ।
आप एआई डेमो और उत्पादन तैयार प्रणालियों के बीच अंतर के बारे में खुलकर बात कर चुके हैं। आपके दृष्टिकोण से, टीमें एआई प्रोटोटाइप को विश्वसनीय उत्पाद में बदलने की कोशिश करते समय सबसे आम वास्तुकला गलतियां क्या करती हैं जो वास्तविक ग्राहकों द्वारा उपयोग की जाती हैं?
टीमें जो सबसे आम गलती करती हैं वह यह मानना है कि मॉडल उत्पाद है।
प्रारंभिक प्रोटोटाइप में, मॉडल सबसे दिखाई देने वाला काम करता है। आप इसे प्रॉम्प्ट करते हैं, यह एक उत्तर उत्पन्न करता है, और यदि उत्तर अच्छा दिखता है तो प्रणाली काम करने लगती है। यह धारणा बनाता है कि मॉडल में सुधार करना मुख्य चुनौती है।
लेकिन उत्पादन प्रणालियों में, मॉडल एक बहुत बड़े वास्तुकला में केवल एक घटक है।
पहली गलती डेटा को एक बाद की बात मानना है। प्रोटोटाइप में, टीमें अक्सर छोटे, साफ़ डेटासेट के साथ परीक्षण करती हैं। एक बार प्रणाली वास्तविक ऑपरेशनल डेटा से जुड़ जाती है, चीजें जल्दी बदल जाती हैं। डेटा अपूर्ण, असंगत, दोहराया गया या अप्रत्याशित प्रारूपों में आता है। संरचित डेटा पाइपलाइन के बिना जो इनपुट को सामान्य बनाती है और मान्य करती है, प्रणाली मॉडल कितना अच्छा है इसके बावजूद अविश्वसनीय हो जाती है।
दूसरी गलती मूल्यांकन ढांचे की अनुपस्थिति है। कई टीमें एआई सुविधाओं को लॉन्च करती हैं जो “अच्छा” का क्या अर्थ है इसकी परिभाषा किए बिना। वे विकास के दौरान आउटपुट की मैनुअल रूप से जांच कर सकते हैं, लेकिन वे लाइव होने पर सटीकता, ड्रिफ्ट और एज केस को लगातार मापने वाले स्वचालित मूल्यांकन पाइपलाइन नहीं बनाते हैं। बिना उन गार्डरेल के, विफलताएं अक्सर इंजीनियरों के बजाय ग्राहकों द्वारा खोजी जाती हैं।
एक तीसरा मुद्दा शासन और नियंत्रण तंत्र की कमी है। एआई प्रणालियां संभावित हैं, जिसका अर्थ है कि वे थोड़े अलग परिस्थितियों में अलग व्यवहार कर सकती हैं। नियंत्रित या उच्च दांव वाले वातावरण में, उस अप्रत्याशितता को निर्धारित नीतियों, अनुमोदन कार्य प्रवाह और ऑडिट लॉग के साथ सीमित किया जाना चाहिए जो यह कैप्चर करते हैं कि निर्णय कैसे किए गए थे।
यह वास्तव में इस बात पर नीचे आता है कि उत्पादन एआई प्रणालियां केवल मॉडल नहीं हैं। वे संचालन प्रणाली हैं।
आज एआई के साथ सफल होने वाली कंपनियां वे हैं जो डेटा पाइपलाइन, मूल्यांकन, शासन और निगरानी को मुख्य बुनियादी ढांचे के रूप में मानती हैं, न कि वैकल्पिक ऐड-ऑन के रूप में।
कई एआई कोडिंग प्लेटफ़ॉर्म का वादा है कि कोई भी सरल प्रॉम्प्ट का उपयोग करके एक अनुप्रयोग बना सकता है। ये टूल डेमो के लिए अच्छी तरह से क्यों काम करते हैं लेकिन वास्तविक उत्पादन वातावरण में तैनाती के लिए संघर्ष करते हैं?
इनमें से कई प्लेटफ़ॉर्म डेमो के लिए अच्छी तरह से काम करते हैं क्योंकि वे निर्माण के क्षण के लिए अनुकूलित हैं, न कि वास्तविक प्रणाली के जीवन चक्र के लिए।
लेकिन एक एआई का उपयोग करके एक लैंडिंग पेज बनाने और एक एआई अनुप्रयोग बनाने के बीच एक मूलभूत अंतर है।
एक लैंडिंग पेज अधिकांश स्थिर सॉफ़्टवेयर है। एक बार यह सही ढंग से रेंडर हो जाने के बाद, काम लगभग पूरा हो जाता है। प्रणाली को संभावित निर्णय लेने, लगातार बदलते डेटा को पचाने, या अप्रत्याशित उपयोगकर्ता व्यवहार के अनुकूल होने की आवश्यकता नहीं है।
एआई अनुप्रयोग पूरी तरह से अलग हैं। वे डेटा पाइपलाइन, मॉडल व्यवहार, मूल्यांकन ढांचे, और निरंतर निगरानी पर निर्भर डायनामिक प्रणाली हैं। अनुप्रयोग को संदर्भ प्रबंधित करना, आउटपुट में परिवर्तन का पता लगाना, एज केस को संभालना और मॉडल को पहले देखे गए स्थितियों से निपटने के लिए सुरक्षित रूप से संचालित करना होगा।
अधिकांश प्रॉम्प्ट-चालित कोडिंग टूल उन परतों को संबोधित नहीं करते हैं क्योंकि वे जल्दी से कुछ काम करने के लिए डिज़ाइन किए गए हैं। वे एक दृश्य परिणाम उत्पन्न करने वाला कोड उत्पन्न करते हैं, जो एक डेमो वातावरण के लिए उपयुक्त है। लेकिन उत्पादन प्रणालियों को एक बहुत बड़ा क्षमता सेट की आवश्यकता होती है: संरचित डेटा हैंडलिंग, शासन नियंत्रण, मूल्यांकन पाइपलाइन, पर्यवेक्षण, और समय के साथ व्यवहार को सुरक्षित रूप से अपडेट करने के लिए तंत्र।
इसलिए, जब कंपनियां उन्हें वास्तविक वातावरण में तैनात करने की कोशिश करती हैं, तो अंतर स्पष्ट हो जाता है। प्रोटोटाइप काम किया क्योंकि वातावरण नियंत्रित था। उत्पादन गंदा है।
एम्प्रोम्प्टु मौजूदा सॉफ़्टवेयर को एआई-मूल प्रणालियों में परिवर्तित करने पर ध्यान केंद्रित करता है, न कि कंपनियों को सब कुछ शुरू से बनाने के लिए मजबूर करता है। यह परिवर्तन वास्तव में क्या शामिल है?
उत्पाद स्तर पर, प्रत्येक अनुप्रयोग पूरी तरह से स्वयं निहित और कंटेनरीकृत है। हम सब कुछ बनाते हैं जो आपको चाहिए, फ्रंट एंड, बैकएंड, डेटाबेस, मॉडल, मूल्यांकन, एलएलएम ओप्स नियम और सब कुछ वास्तव में लचीला है जो उद्यम की आवश्यकताओं के अनुसार निर्भर करता है।
हमारे पास एआई ऐप्स के लिए कई विकल्प हैं:
“हेडलेस” ताकि यदि ग्राहक पहले से ही एक फ्रंट एंड है तो हम इसे हमारी प्रणाली से जोड़ सकते हैं और डेटा वापस भेज सकते हैं
पूरी तरह से कंटेनरीकृत ताकि वे हमारे बुनियादी ढांचे पर या ग्राहक के बुनियादी ढांचे के भीतर तैनात किए जा सकें, इसलिए वे डिफ़ॉल्ट रूप से ऑन-प्रिमिस हैं
या हम उन्हें सीधे क्लाउड में तैनात करने के लिए बना और तैनात कर सकते हैं जो सबसे सुविधाजनक विकल्प है
जो भी कोड वे हैं, हम इसे सीधे हमारी प्रणाली में आयात कर सकते हैं और इसे एजेंट कर सकते हैं यदि यह पहले से एजेंट नहीं है। उदाहरण के लिए, हमें यह देखने को मिलता है कि लवेबल, रेप्लिट, बोल्ट या बेस44 जैसे लोकप्रिय प्लेटफ़ॉर्म पर अपने ऐप्स बनाने की कोशिश करने वाले कई ग्राहकों के साथ। अक्सर वे काम नहीं करते हैं। लेकिन ग्राहकों ने पहले से ही इस अनुप्रयोग में बहुत समय और ऊर्जा और क्रेडिट लगा दिए हैं, इसलिए हम इसे पचाते हैं, इसे फिर से लिखते हैं और सभी एआई को काम करते हैं।
और हम ऐसा इसलिए कर सकते हैं क्योंकि हमारे पास कई कस्टम, प्रोप्राइटरी तकनीकें हैं, जैसे:
- संदर्भ प्रबंधित करने के लिए अनुकूली संदर्भ इंजन
- लंबे समय तक चलने वाले कोड अनुप्रयोगों को पचाने के लिए अनंत स्मृति
- सुनिश्चित करने के लिए कस्टम डेटा मॉडल और गोल्डन डेटा पाइपलाइन कि हम किसी भी डेटा सफ़ाई और सिंथेटिक लेबलिंग को संभाल सकते हैं जिसकी आवश्यकता हो सकती है
आपका प्लेटफ़ॉर्म संदर्भ, मूल्यांकन, शासन और संरचित डेटा को एआई प्रणालियों के मूल घटकों के रूप में जोर देता है। टीमें एआई सुविधाओं को अपने उत्पादों में जोड़ने के लिए जल्दी होने पर ये तत्व इतनी बार क्यों छूट जाते हैं?
क्योंकि वे करना मुश्किल है! मेरे सह-संस्थापक, डॉ. शॉन रॉबिन्सन, हमारे शोध प्रयोगशाला का नेतृत्व करते हैं, जो एक गणनात्मक खगोल भौतिक विज्ञानी हैं जिन्होंने मेरे पागल विचारों से, लेकिन हमारे ग्राहकों की जरूरतों और बाजार की दिशा से भी कई प्रौद्योगिकियों का आविष्कार किया है। हमारे अनुभव में कई एजेंटिक अनुप्रयोगों का निर्माण करने और दुनिया की सबसे बड़ी प्रौद्योगिकी कंपनियों में निर्माण करने में मदद मिलती है जो जटिल समस्याओं को बेहतर ढंग से हल करने में हमारी मदद करती है।
आप कई संस्थापकों के साथ काम करते हैं जिन्होंने पहले कोड नहीं लिखा है। जब वे पहली बार एआई अनुप्रयोग बनाने की कोशिश करते हैं तो गैर-तकनीकी संस्थापकों के पास क्या सबसे बड़े गलतफहमी होते हैं?
मुझे लगता है कि दो बड़े गलतफहमी हैं:
पहला यह है कि एआई जादू है। एआई जादू नहीं है। यह सिर्फ अच्छा इंजीनियरिंग है। और अंततः, आप उन प्लेटफ़ॉर्म पर क्या कर सकते हैं इसकी सीमा पर पहुंच जाते हैं जिनमें एक वास्तविक इंजीनियर नहीं है।
दूसरा यह है कि उनके पास महान तकनीकी उत्पाद प्रबंधन कौशल है। मेरे पास तकनीकी उत्पाद प्रबंधन की पृष्ठभूमि है और एक दृष्टि को अनुवादित करने की क्षमता, कभी-कभी एक बहुत बड़ी दृष्टि, छोटे शिप करने योग्य टुकड़ों में नीचे के साथ सही तकनीकी विशिष्टता के साथ जो आप चाहते हैं कि क्या हो। यह एक बहुत ही कठिन कौशल है जो समय लेता है।
उदाहरण के लिए, कहें कि आप एक ऐप बना रहे हैं जो एक पीडीएफ़ अपलोड करता है और इसे बाद में देखने के लिए सहेजता है। यह एक अवधारणा है जिसे स्थायित्व कहा जाता है। उस पीडीएफ़ को कोड में एन्कोड किया जाता है और डेटाबेस में सहेजा जाता है।
लेकिन अगर आपको यह नहीं पता था कि यह स्थायित्व कहलाता है, तो आप यह कैसे टाइप करेंगे? सुनिश्चित करें कि यह डेटा स्थायी रूप से बना रहे। तकनीकी शब्द चयन एक अलग भाषा बोलने जैसा है। प्राकृतिक भाषा और तकनीकी भाषा में लिखने में अंतर है।
कई स्टार्टअप्स मानते हैं कि एआई उत्पादों का निर्माण करने का समाधान अधिक इंजीनियरों को नियुक्त करना है। आप क्यों सोचते हैं कि यह दृष्टिकोण अक्सर विफल क्यों होता है, और एआई-संचालित उत्पादों का निर्माण करते समय संस्थापकों को क्या विचार करना चाहिए?
अधिक इंजीनियरों को नियुक्त करना कभी-कभी सही उत्तर होता है। यदि आप गहराई से तकनीकी उत्पाद बना रहे हैं या मॉडल अनुसंधान के फ्रंटियर पर काम कर रहे हैं, तो आपको मजबूत इंजीनियरिंग टीमों की आवश्यकता है। कठिन समस्याओं को हल करने के लिए अच्छे इंजीनियरों का कोई विकल्प नहीं है।
लेकिन स्टार्टअप्स द्वारा की जाने वाली गलती यह है कि वे मानते हैं कि अधिक इंजीनियरों को नियुक्त करने से एआई उत्पाद की चुनौती स्वचालित रूप से हल हो जाएगी।
वास्तव में, एआई उत्पादों में सबसे कठिन समस्याएं अक्सर शुद्ध इंजीनियरिंग समस्याएं नहीं होती हैं। वे प्रणाली समस्याएं हैं जैसा कि हर अन्य इंजीनियरिंग समस्या है। इंजीनियरों को विशेष रूप से प्रणालियों में सोचने के लिए सिखाया जाता है। लेकिन उत्पन्न विकास अलग है। जब हम ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग से फंक्शनल प्रोग्रामिंग में स्विच कर रहे थे, तो हमने इस बदलाव को किया था। क्या वे दोनों प्रोग्रामिंग हैं? हाँ, बिल्कुल, लेकिन क्या वे अलग हैं? क्या वे एक अलग तरीके से सोचने का तरीका है? हाँ, बिल्कुल।
एआई अनुप्रयोग डेटा, उत्पाद डिज़ाइन, संचालन कार्य प्रवाह और मॉडल व्यवहार के बीच के चौराहे पर बैठते हैं। आप एक अविश्वसनीय इंजीनियरिंग टीम को नियुक्त कर सकते हैं, लेकिन यदि डेटा पाइपलाइन अविश्वसनीय है, मूल्यांकन मानदंड स्पष्ट नहीं हैं, या प्रणाली में शासन और निगरानी का अभाव है, तो उत्पाद वास्तविक उपयोगकर्ताओं तक पहुंचने पर अभी भी संघर्ष करेगा।
एक और मुद्दा यह है कि कई टीमें उत्पादन में एआई प्रणाली का व्यवहार कैसे परिभाषित किए बिना निर्माण में कूद जाती हैं। मूल्यांकन कैसे किया जाएगा, किनारे के मामलों को कैसे संभाला जाएगा, निर्णय कैसे लॉग किए जाएंगे और मॉडल को समय के साथ कैसे अपडेट किया जाएगा, जैसे प्रश्न अक्सर बहुत बाद में आते हैं। उस समय तक, वास्तुकला को बदलना मुश्किल हो जाता है।
संस्थापकों को वास्तव में क्या सोचना चाहिए वह एआई प्रणाली का संचालन मॉडल है।
डेटा पाइपलाइन का मालिक कौन है?
मॉडल प्रदर्शन को निरंतर कैसे मापा जाता है, न कि केवल विकास के दौरान?
जब प्रणाली एक ऐसी स्थिति का सामना करती है जिसे उसने पहले नहीं देखा है तो क्या होता है?
आप व्यवहार को सुरक्षित रूप से कैसे अपडेट करते हैं बिना डाउनस्ट्रीम कार्य प्रवाह को तोड़े?
कभी-कभी उन समस्याओं का समाधान करने का मतलब अधिक इंजीनियरों को नियुक्त करना होता है। लेकिन यह सही बुनियादी ढांचे का चयन करने, मजबूत उत्पाद सीमाओं को परिभाषित करने और छोटी टीमों को स्केल पर विश्वसनीय रूप से संचालित करने वाली प्रणालियों का निर्माण करने का भी मतलब हो सकता है।
आज एआई के साथ सफल होने वाली कंपनियां आवश्यक रूप से उन लोगों के साथ नहीं हैं जिनके पास सबसे बड़ी इंजीनियरिंग टीमें हैं। वे वे हैं जो एआई को एक दीर्घकालिक प्रणाली के रूप में मानते हैं जिसे डेटा अनुशासन, मूल्यांकन, शासन और निरंतर सुधार की आवश्यकता होती है।
आपका तर्क है कि एआई डेवलपर टूल्स में वर्तमान व्यावसायिक मॉडल उत्पादों के निर्माण के साथ संरेखित नहीं हैं। आप क्या सोचते हैं कि वर्तमान एआई टूलिंग पारिस्थितिकी में प्रोत्साहन क्या हैं जो कंपनियों को गलत दिशा में ले जा रहे हैं?
वर्तमान में सबसे बड़ा प्रोत्साहन मिसमैच यह है कि कई एआई डेवलपर टूल विकास मीट्रिकों के लिए उत्पाद की स्थायित्व के बजाय अनुकूलित हैं।
इस स्थान में कई कंपनियां तेजी से कुछ बनाने में सक्षम होने के लिए पुरस्कृत की जाती हैं। यदि एक टूल एक कार्यशील ऐप, सुविधा या डेमो को कुछ मिनटों में उत्पन्न कर सकता है, तो यह साइनअप, सोशल शेयरिंग और निवेशक उत्साह को बढ़ावा देता है। उत्पाद अपनाने के दृष्टिकोण से, यह समझ में आता है।
लेकिन वे प्रोत्साहन अक्सर निर्माण बिंदु पर रुक जाते हैं।
एआई सॉफ़्टवेयर में कठिन काम निर्माण के बाद होता है। यह तब है जब विश्वास बनाया जाता है। जब आप गुणवत्ता पर भरोसा कर सकते हैं। जब उपयोगकर्ता बिना एआई की निराशा के खराब आउटपुट के साथ वापस आना चाहता है।
एक और मुद्दा यह है कि कई टूल कोड उत्पन्न करने के बजाय प्रणाली डिज़ाइन के लिए अनुकूलित हैं। कोड को जल्दी से उत्पन्न करना मददगार है, लेकिन एक एआई उत्पाद बनाने में कोड का उत्पादन करने से अधिक शामिल है। यह मूल्यांकन को परिभाषित करने, निर्णय लेने, विफलताओं को संभालने और व्यवहार को सुरक्षित रूप से समय के साथ विकसित करने की आवश्यकता को शामिल करता है।
जो कंपनियां अपने ग्राहकों को विश्वसनीय रूप से एआई प्रणालियों को चलाने में मदद करने के आसपास प्रोत्साहन को संरेखित करती हैं, न कि बस उन्हें जल्दी से बनाने में, वे इस पारिस्थितिकी में स्थायी मूल्य बनाएंगी।
कुछ आपके ग्राहक विशिष्ट उत्पादों का निर्माण कर रहे हैं, जैसे विशेष स्वास्थ्य उपकरण या स्थायित्व पर केंद्रित व्यवसाय, अक्सर पारंपरिक इंजीनियरिंग टीमों के बिना। जो संस्थापक सफलतापूर्वक उन विचारों को कार्यशील एआई उत्पादों में बदल देते हैं, उनमें आप कौन से पैटर्न देखते हैं?
सबसे दिलचस्प पैटर्न में से एक यह है कि सफल संस्थापक आवश्यक रूप से सबसे तकनीकी नहीं हैं। वे हैं जो समस्या को जिसे वे हल कर रहे हैं उसे बेहद अच्छी तरह से समझते हैं।
एम्प्रोम्प्टु का उपयोग करने वाले कई संस्थापक डोमेन विशेषज्ञ हैं। वे स्वास्थ्य सेवा, वित्त, स्थायित्व या किसी अन्य विशेष उद्योग से आ सकते हैं। वे जो लाते हैं वह उस वातावरण में काम प्रवाह, नियमों और निर्णयों का गहरा ज्ञान है। यह संदर्भ एआई उत्पाद को डिज़ाइन करते समय अविश्वसनीय रूप से मूल्यवान है क्योंकि यह परिभाषित करता है कि प्रणाली वास्तव में क्या करनी चाहिए।
सफल संस्थापक एआई को कम एक प्रौद्योगिकी प्रयोग के रूप में और अधिक एक उत्पाद प्रणाली के रूप में दृष्टिकोण लेते हैं। वे बहुत ही ठोस प्रश्न पूछना शुरू करते हैं। एआई उपयोगकर्ताओं को किन निर्णयों में मदद करनी चाहिए? यह किन डेटा स्रोतों तक पहुंच की आवश्यकता है? इस डोमेन में एक सही उत्तर वास्तव में कैसा दिखता है? कौन से गार्डरेल होने चाहिए ताकि प्रणाली जिम्मेदारी से व्यवहार करे?
एक और पैटर्न यह है कि वे संरचना पर ध्यान से विचार करते हैं। सफल टीमें जल्दी से महसूस करती हैं कि एआई आउटपुट केवल उतना ही अच्छा है जितना कि संदर्भ और डेटा जो उन्हें खिलाते हैं। वे डेटा पाइपलाइन, ज्ञान स्रोतों को व्यवस्थित करने और स्पष्ट मूल्यांकन मानदंड बनाने में समय लगाते हैं कि “अच्छा” किसे दिखाई देता है।
हम देखते हैं कि सफल संस्थापक मानव-एआई सहयोग को तुरंत सब कुछ स्वचालित करने की कोशिश करने के बजाय अपनाते हैं। वे ऐसे कार्य प्रवाह डिज़ाइन करते हैं जहां एआई दोहराए जाने वाले विश्लेषण या डेटा सिंथेसिस को संभालता है, जबकि मानव निर्णय और अंतिम निर्णयों के लिए जिम्मेदार रहते हैं। यह संतुलन प्रणालियों को विशेष रूप से स्वास्थ्य सेवा या वित्त जैसे क्षेत्रों में बहुत अधिक विश्वसनीय बनाता है।
कई मायनों में, सबसे बड़ा बदलाव मानसिकता है। सफल संस्थापक एआई को एक सुविधा के रूप में नहीं सोचते हैं जिसे वे जोड़ रहे हैं। वे इसे अपने उत्पाद के काम करने के तरीके की एक नई परिचालन परत के रूप में सोचते हैं।
जैसा कि एआई प्रणाली मुख्य व्यावसायिक संचालन में एकीकृत हो जाती है, तो एआई अनुप्रयोग प्लेटफ़ॉर्म की अगली पीढ़ी को परिभाषित करने वाली क्षमताएं क्या होंगी?
मुझे पता है कि यह पागल है और मैं कुछ अपवित्र कह रहा हूं, लेकिन लोग अपने स्वयं के कस्टम मॉडल को वाइब-कोड कर पाएंगे। हमारी शोध प्रयोगशाला द्वारा विशेषज्ञ नैनो मॉडल के रूप में जाने जाने वाले कुछ लोग लागत को नियंत्रित करने में मदद करेंगे।
साक्षात्कार के लिए धन्यवाद, पाठक जो अधिक जानना चाहते हैं उन्हें एम्प्रोम्प्टु एआई पर जाना चाहिए।
