← ब्लॉग पर वापस

संचालन सौंपने की समस्या: जब सलाहकार चले जाएँ तो आपकी टीम को क्या स्वामित्व होना चाहिए?

अधिकांश AI परियोजनाएँ लॉन्च के समय विफल नहीं होती — वे छह महीने बाद विफल होती हैं, जब कंपनी के अंदर कोई भी प्रणाली में बदलाव नहीं ला सकता। यहाँ ऐसा करने का तरीका दिया गया है।

एक एआई परियोजना के दो अंत

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

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

वास्तविक स्वामित्व का अर्थ

स्वामित्व एक फ़ोल्डर दस्तावेज़ों को सौंपने से ज़्यादा है जो अंतिम दिन पर दिया जाता है। यह आपकी कंपनी के भीतर चार व्यावहारिक क्षमताओं को है:

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

ज़्यादातर हस्तांतरण पहली क्षमता प्रदान करते हैं और अन्य तीनों को छोड़ देते हैं। इसलिए प्रणालियाँ ड्रिफ्ट करती हैं।

महत्वपूर्ण दस्तावेज़ीकरण

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

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

बाक़ी सब वैकल्पिक है। यदि एक दस्तावेज़ किसी को प्रणाली चलाने, बदलने, न्याय करने या बदलने में मदद नहीं करता है, तो यह सज़ावट है।

आपको जो लोग चाहिए

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

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

आमतौर पर इन तीनों के लिए आंतरिक लागत एक फुल-टाइम भूमिका से भी कम होती है। विफलता का मोड़ नहीं खर्च है; यह कोई नामित व्यक्ति न होना है।

हस्तांतरण का परीक्षण करें जबकि आप अभी भी शिकायत कर सकते हैं

दस्तावेज़ीकरण को स्वीकृति के प्रमाण के रूप में न स्वीकार करें। परियोजना के अंतिम दिनों में एक जीवंत परीक्षण करें, जबकि सलाहकार अभी भी अनुबंध के तहत बाहर हैं।

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

यदि आपकी टीम इसे एक दिन में पूरा करती है, तो आप प्रणाली के मालिक हैं। यदि यह एक सप्ताह और तीन सवालों तक लेता है, तो आपने ठीक से पहचाना है जो खामियाँ, और इससे पहले कि इनवॉइस समाप्त हों, आप उन्हें बंद करने के लिए कदम उठा सकते हैं।

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

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

लेख · Hercules A

अपनी कंपनी को AI के अनुरूप ढालने के विचार।

Contact