क्यों आपके AI पायलट शिपिंग से पहले रुक जाते हैं?

अधिकांश कंपनियों के पास एक कब्रिस्तान होता है

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

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

पायलट ने वास्तव में क्या खर्च किया?

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

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

उन लागतों को जो कभी भी लेखा पर नहीं आतीं

महंगा हिस्सा हर उस व्यक्ति के लिए है जिसने एक आशाजनक उपकरण देखा और फिर यह गायब हो गया।

पहली नुकसान विश्वसनीयता है। जब एक प्रतिज्ञादायक उपकरण टीम के सामने प्रदर्शित किया जाता है और फिर गायब हो जाता है, तो लोगों को पता चलता है कि AI परियोजनाएं नाटक हैं। अगली बार जब आप एक प्रस्ताव रखेंगे, तो सबसे मजबूत ऑपरेटर - जो आप चाहते हैं - अपने आप को अलग कर लेंगे क्योंकि उन्होंने यह देखा है कि यह कैसे समाप्त होता है। आप एक नए पायलट से शुरू नहीं कर रहे हैं। आप शून्य से नीचे शुरू कर रहे हैं, खुद को बनाए गए संदेह के खिलाफ।

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

पायलट क्यों रुक जाते हैं?

पायलट दुर्लभ रूप से इसलिए विफल होते हैं क्योंकि तकनीक काम नहीं करती। वे उन कारणों से रुक जाते हैं जो कोड लिखे जाने से पहले मौजूद थे:

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

ध्यान दें कि इनमें से कोई भी मॉडल की समस्याएँ नहीं हैं। ये निर्णय स्वामित्व, स्कोप और प्रतिबद्धता के बारे में हैं जो शुरूआत से ही लिए जाते हैं।

पायलट को उत्पादन के रूप में इलाज करें

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

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

Hercules A में, हम एक ग्राहक के AI प्रयास को रोकने पर पहली बात जो देखते हैं, वह अक्सर एक अभाव है - न सिर्फ़ बेहतर मॉडल, बल्कि एक ऐसे स्वामित्व का अभाव जो उत्पादन तक पहुंच बनाए रखे। तकनीक दुर्लभ मामलों में रुकावट है।