6.1 AI रणनीति और तैयारी

अवलोकन और प्रेरणा

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

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

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

मुख्य सिद्धांत

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

सिफ़ारिशें

तकनीक चुनने से पहले समस्या को फ़्रेम करें

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

निर्माण-बनाम-खरीद-बनाम-फ़ाइन-ट्यून-बनाम-प्रॉम्प्ट निर्णय वृक्ष का उपयोग करें

सबसे सस्ते और तेज़ से सबसे महंगे और सबसे नियंत्रित की ओर बढ़ें:

1. एक मौजूदा होस्टेड मॉडल को प्रॉम्प्ट करें। यदि एक सामान्य-उद्देश्य मॉडल (जैसे Anthropic का Claude, या अन्य प्रदाताओं की तुलनीय पेशकश) सावधानीपूर्वक प्रॉम्प्टिंग और रिट्रीवल से समस्या हल करता है, तो पहले वही करें। सबसे कम लागत, सबसे तेज़ पुनरावृत्ति, कोई प्रशिक्षण इन्फ्रास्ट्रक्चर नहीं।
2. रिट्रीवल या टूल के साथ बढ़ाएं। यदि अंतर ज्ञान या क्रियाओं का है, तो मॉडल वेट को छूने से पहले रिट्रीवल-ऑगमेंटेड जेनरेशन (RAG) जोड़ें, जो क्वेरी के समय प्रासंगिक दस्तावेज़ लाता है और उन्हें संदर्भ के रूप में मॉडल को आपूर्ति करता है, और टूल उपयोग जोड़ें।
3. फ़ाइन-ट्यून या अनुकूलित करें। यदि प्रॉम्प्टिंग लगातार आवश्यक सटीकता, स्वर, या प्रारूप हासिल नहीं कर सकती, तो अपने डेटा पर एक छोटे मॉडल को फ़ाइन-ट्यून करें: यानी, इसे विशेषीकृत करने के लिए अपने उदाहरणों पर एक पूर्व-प्रशिक्षित मॉडल को आगे प्रशिक्षित करें। यह एक MLOps (मशीन लर्निंग ऑपरेशंस) पाइपलाइन की लागत पर नियंत्रण खरीदता है।
4. एक विशेष उत्पाद खरीदें। अच्छी तरह परिभाषित डोमेन (दस्तावेज़ प्रोसेसिंग, धोखाधड़ी स्कोरिंग) के लिए, एक परिपक्व विक्रेता उत्पाद आपके द्वारा बनाई गई किसी भी चीज़ को हरा सकता है।
5. शुरुआत से बनाएं। फ़ाउंडेशन मॉडल (व्यापक डेटा पर पूर्व-प्रशिक्षित और कई कार्यों के लिए अनुकूलनीय बड़े मॉडल) के प्रशिक्षण को अनोखे डेटा, गहरी प्रतिभा, और रणनीतिक कारणों वाले संगठनों के लिए आरक्षित रखें। लगभग सभी एंटरप्राइज़ और एजेंसियों के लिए, यह ग़लत विकल्प है।

डेटा, प्रतिभा, और प्लेटफ़ॉर्म पूर्वापेक्षाएं स्थापित करें

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

विनियमित और सरकारी संदर्भों को जानबूझकर संभालें

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

स्वामित्व की कुल लागत की गणना करें और लॉक-इन से बचाव करें

पूर्ण जीवनचक्र लागत मॉडल करें: इनफ़रेंस या लाइसेंसिंग, डेटा पाइपलाइन, मानव समीक्षा, निगरानी, पुनः प्रशिक्षण, घटना प्रतिक्रिया, और डीकमीशनिंग। इसकी तुलना यथास्थिति और विकल्पों की लागत से करें। मॉडल को एक आंतरिक इंटरफ़ेस के पीछे रखकर, प्रॉम्प्ट और मूल्यांकन डेटासेट को पोर्टेबल रखकर, और समय-समय पर एक दूसरे प्रदाता का परीक्षण करके लॉक-इन कम करें।

ट्रेड-ऑफ़: फ़ायदे और नुकसान

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

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

अपनी टीम के साथ चर्चा के लिए प्रश्न

1. हमारे शीर्ष तीन उम्मीदवार उपयोग मामलों में से हर एक प्रॉम्प्ट-फिर-रिट्रीव-फिर-फ़ाइन-ट्यून-फिर-खरीद-फिर-बनाएं सीढ़ी पर कहाँ बैठता है, और कौन सा सबूत इसे एक पायदान हिलाएगा? यह मायने रखता है क्योंकि अधिकांश बर्बाद AI खर्च एक पायदान बहुत ऊंचा शुरू करने से आता है: एक मॉडल को प्रशिक्षित करना जब सावधानीपूर्वक प्रॉम्प्टिंग काम कर गई होती। एक बड़ी टीम के लिए, सीढ़ी को साझा डिफ़ॉल्ट के रूप में सहमत करना हर समूह को एक महंगी पाइपलाइन के पुनराविष्कार से रोकता है। हर उम्मीदवार के लिए एक-पृष्ठ समस्या विवरण, वर्तमान बेसलाइन, और यह ईमानदार पढ़ाई लाएं कि क्या अंतर ज्ञान (रिट्रीवल), सुसंगति (फ़ाइन-ट्यूनिंग), या एक हल की गई कमोडिटी (खरीद) है। एंटरप्राइज़ और सरकारी सेटिंग्स में, हर पायदान की खरीद और ऑडिट लागत जोड़ें, क्योंकि एक फ़ाइन-ट्यून किया गया मॉडल एक MLOps बोझ खींचता है जो एक होस्टेड कॉल नहीं खींचता। उत्तर को कमरे में कम से कम एक अधिक-स्कोप वाली परियोजना को मारने या डाउनग्रेड करने देना चाहिए।

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

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

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

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

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

क्षेत्र लेंस

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

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

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

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

उदाहरण

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

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

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

बिज़नेस केस: प्रेरणाएं, ROI, और TCO

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

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

एंटी-पैटर्न और गड्ढे

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

परिपक्वता मॉडल

1. आरंभ। तदर्थ प्रयोग, कोई साझा रणनीति नहीं, प्रचार और व्यक्तिगत उत्साह द्वारा संचालित निर्णय।
2. विकास। कुछ परियोजनाओं के लिए समस्या फ़्रेमिंग मौजूद है; एक पहली प्लेटफ़ॉर्म बेसलाइन दिखाई देती है; निर्माण-बनाम-खरीद पर चर्चा होती है लेकिन असंगत है।
3. मानकीकरण। स्पष्ट मेट्रिक्स, एक दस्तावेज़ीकृत निर्णय वृक्ष, तैयारी आकलन, और लॉक-इन व TCO विश्लेषण के साथ AI उपयोग मामलों का एक पोर्टफ़ोलियो, टीमों में लगातार लागू।
4. प्रबंधन। पोर्टफ़ोलियो को मापा जाता है: तैयारी, ROI, TCO, और मानव-निगरानी लागत को बेसलाइन के विरुद्ध ट्रैक किया जाता है; किल मापदंड सबूत पर लागू होते हैं; डिलीवरी और गुणवत्ता प्रभाव हर जाओ या न-जाओ निर्णय को चलाते हैं।
5. आर्केस्ट्रेशन। AI रणनीति व्यवसाय और जोखिम योजना के साथ एकीकृत है; तैयारी निरंतर बनाए रखी जाती है; संगठन नियमित रूप से सबूत के आधार पर AI सिस्टम को सेवानिवृत्त करता है, बदलता है, और फिर से स्कोप करता है, बाज़ार और जोखिम तस्वीर के बदलने पर पोर्टफ़ोलियो को पुनर्संतुलित करता है।

चर्चा के लिए विचार

• आप कैसे तय करते हैं कि एक समस्या वास्तव में AI के लिए अनुपयुक्त है, और किसके पास “नहीं” कहने का अधिकार है?
• किस तैयारी सीमा को एक परियोजना को पायलट से प्रोडक्शन तक गेट करना चाहिए?
• तेज़ मूल्य समय के बदले में कितना लॉक-इन स्वीकार्य है?
• सरकार में, पारदर्शिता बाध्यताओं को निर्माण-बनाम-खरीद विकल्प को कैसे आकार देना चाहिए?
• जब विक्रेताओं और उत्साही लोगों के पास उन्हें कम आंकने के प्रोत्साहन हों तो आप TCO अनुमानों को ईमानदार कैसे रखते हैं?
• AI पोर्टफ़ोलियो का मालिक कौन है, और किल निर्णय कैसे लिए जाते हैं?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ना

• Ajay Agrawal, Joshua Gans, and Avi Goldfarb, Prediction Machines: The Simple Economics of Artificial Intelligence.
• Eric Siegel, The AI Playbook: Mastering the Rare Art of Machine Learning Deployment.
• Andriy Burkov, The Hundred-Page Machine Learning Book.
• National Institute of Standards and Technology, AI Risk Management Framework (AI RMF 1.0).
• Organisation for Economic Co-operation and Development, OECD AI Principles.
• Thomas H. Davenport, The AI Advantage: How to Put the Artificial Intelligence Revolution to Work.