एआई फीचर लॉन्च करना पारंपरिक फीचर लॉन्च करने से अलग है, और आपके शिप करने के बाद पहले सप्ताह में अंतर सबसे ज्यादा होता है।
नियमित सुविधा के साथ, कोड वही करता है जो कोड करता है। एआई सुविधा के साथ, आप कुछ ऐसा जारी कर रहे हैं जो लोड के तहत अलग व्यवहार करता है, प्रति उपयोगकर्ता आपके द्वारा निर्धारित की गई तुलना में अधिक लागत लेता है, और ऐसे मामलों में शर्मनाक आउटपुट उत्पन्न कर सकता है जिन्हें किसी ने परीक्षण करने के बारे में नहीं सोचा था। लॉन्च के बाद ⟦रेट्रो⟧ वैकल्पिक नहीं है - यह वह जगह है जहां आप पता लगाते हैं कि आपके पास एक व्यवहार्य सुविधा है या महंगी देनदारी है।
एआई लॉन्च को क्या अलग बनाता है
यदि आपने पहले सॉफ़्टवेयर शिप किया है, तो आपको पहले से ही अंदाजा है कि क्या गलत हो सकता है। AI लॉन्च उन विफलता मोडों में से कुछ को साझा करता है और कई नए जोड़ता है:
लागत उपयोगकर्ताओं के साथ रैखिक रूप से नहीं बढ़ती है। एक पारंपरिक सुविधा प्रति उपयोगकर्ता सीमांत सर्वर लागत जोड़ सकती है। एक LLM सुविधा प्रति इंटरैक्शन टोकन लागत जोड़ती है, और जो उपयोगकर्ता इस सुविधा को पसंद करते हैं वे इसका अधिक उपयोग करते हैं, जिसकी लागत अधिक होती है, जो बहुत अच्छा हो सकता है या वित्तीय रूप से अस्थिर हो सकता है। आप अक्सर यह नहीं बता सकते कि कौन सा तब तक है जब तक वास्तविक उपयोगकर्ता उस तक नहीं पहुंच जाते।
वास्तविक परिस्थितियों में गुणवत्ता में परिवर्तन होता है। आपका मूल्यांकन सूट स्वच्छ परीक्षण मामले चलाता है। वास्तविक उपयोगकर्ता विकृत इनपुट भेजते हैं, बड़े-बड़े दस्तावेज़ चिपकाते हैं, ऐसी चीज़ें मांगते हैं जिनकी आपने आशा नहीं की थी, और चीज़ों को तोड़ने का प्रयास करते हैं (कभी-कभी जानबूझकर)। पैमाने पर गुणवत्ता हमेशा परीक्षण में गुणवत्ता से भी बदतर होती है।
दर सीमाएं आर्किटेक्चर बन जाती हैं। जब आप किसी बाहरी एपीआई को कॉल कर रहे होते हैं, तो आपकी सुविधा की क्षमता किसी और की दर सीमा से बंधी होती है। यदि आपका लॉन्च आपकी दर सीमा से अधिक ट्रैफ़िक लाता है, तो उपयोगकर्ता ऐसी त्रुटियाँ करते हैं जिनका आपके कोड से कोई लेना-देना नहीं है।
फीडबैक लूप आपकी अपेक्षा से धीमा है। एक पारंपरिक सुविधा के साथ, आप तुरंत देख सकते हैं कि बटन क्लिक किए गए हैं और फॉर्म सबमिट किए गए हैं या नहीं। एआई सुविधा के साथ, आपको यह आकलन करने के लिए समय चाहिए कि क्या आउटपुट वास्तव में अच्छे हैं - और "अच्छे" का अलग-अलग उपयोगकर्ताओं के लिए अलग-अलग मतलब हो सकता है।
लॉन्च से पहले: क्या जगह होनी चाहिए
यह एक व्यापक लॉन्च चेकलिस्ट नहीं है - आपकी टीम जानती है कि सॉफ़्टवेयर कैसे भेजना है। ये एआई-विशिष्ट तैयारियां हैं जिन्हें नजरअंदाज करना आसान है:
लागत नियंत्रण। अपने एपीआई प्रदाता या अपने बुनियादी ढांचे पर एक कठिन खर्च सीमा निर्धारित करें। जानें कि आपका दैनिक बजट क्या है और अलर्ट 50%, 75% और 90% पर सेट करें। यदि आपके पास लागत नियंत्रण नहीं है, तो एक सफल लॉन्च (बहुत सारे उपयोगकर्ता!) एक बजट घटना में बदल सकता है।
एआई आउटपुट के लिए गुणवत्ता निगरानी। आपको कुछ चाहिए - कुछ भी - जो आपको बताता है कि आउटपुट उत्पादन में अच्छे हैं या नहीं, न कि केवल आपके परीक्षण सूट में। यह उपयोगकर्ता फीडबैक सिग्नल (अंगूठे ऊपर/नीचे), उत्पादन आउटपुट के नमूने पर स्वचालित मूल्यांकन, या यादृच्छिक उपसमूह की मैन्युअल समीक्षा हो सकती है। लॉन्च करने से पहले "काफी अच्छा" परिभाषित करें।
एक किल स्विच। आपको पुनः तैनात किए बिना AI सुविधा को बंद करने में सक्षम होना चाहिए। एक फ़ीचर फ़्लैग, एक कॉन्फ़िगरेशन परिवर्तन, कुछ। यदि आउटपुट ख़राब हो जाता है या लागत बढ़ जाती है, तो आपको रक्तस्राव को तुरंत रोकने की आवश्यकता है।
शानदार गिरावट। जब AI अनुपलब्ध हो तो क्या होता है? दर सीमित? धीमा? यदि आपका उत्तर है "सुविधा बस टूट जाती है," लॉन्च से पहले इसे ठीक करें।
बेसलाइन मेट्रिक्स। AI सुविधा के लाइव होने से पहले अपनी वर्तमान स्थिति को कैप्चर करें: वे मेट्रिक्स जिन्हें आप सुधारने की उम्मीद कर रहे हैं, जिन लागतों को आप उचित ठहराने की उम्मीद कर रहे हैं, जिस उपयोगकर्ता अनुभव को आप बढ़ाने की उम्मीद कर रहे हैं। आधार रेखा के बिना, आपका रेट्रो "यहाँ क्या बदल गया है" के बजाय "ऐसा लगता है जैसे यह ठीक हो गया" होगा।
चरणबद्ध रोलआउट तर्क
पहले दिन से ही सभी के लिए एआई सुविधा शुरू करना आकर्षक है - आप इस पर महीनों से काम कर रहे हैं और आप इसका प्रभाव देखना चाहते हैं। लेकिन चरणबद्ध रोलआउट एआई सुविधाओं के लिए विशेष रूप से मूल्यवान हैं क्योंकि विस्फोट त्रिज्या छोटा होने पर वे आपको समस्याएं पकड़ने देते हैं।
एक समझदार प्रगति:
- आंतरिक डॉगफ़ूड (1 सप्ताह): आपकी टीम इसका उपयोग वास्तविक कार्य में करती है। डेमो नहीं, परीक्षण वातावरण नहीं - वास्तविक दैनिक उपयोग।
- छोटा समूह (1-2 सप्ताह): 5-10% उपयोगकर्ता। वास्तविक उपयोग पैटर्न देखने के लिए पर्याप्त, इतना छोटा कि समस्याएं कुछ ही लोगों को प्रभावित करती हैं।
- व्यापक रोलआउट (1-2 सप्ताह): 25-50% उपयोगकर्ता। अब आप बड़े पैमाने पर परीक्षण कर रहे हैं और सत्यापित कर रहे हैं कि लागत अनुमान सही हैं।
- सामान्य उपलब्धता: यह सभी को मिलती है।
प्रत्येक चरण में, विस्तार करने से पहले गुणवत्ता, लागत और उपयोगकर्ता प्रतिक्रिया की समीक्षा करें। इसके लिए हर चरण में एक औपचारिक बैठक की आवश्यकता नहीं है - कभी-कभी खुले मेट्रिक्स के साथ एक त्वरित Slack चेक-इन पर्याप्त होता है। लेकिन चेक को न छोड़ें।
लॉन्च के बाद रेट्रोस्पेक्टिव: एक तीन-पास दृष्टिकोण
एक बड़ा रेट्रो चलाने के बजाय, अलग-अलग समय के पैमाने पर तीन पास करें। हर कोई अलग-अलग चीजें पकड़ता है।
पास 1: पहले दिन की समीक्षा (30 मिनट, अगला व्यावसायिक दिन)
यह तत्काल आश्चर्य पर केंद्रित एक त्वरित सिंक है। अतिविश्लेषण न करें - आपके पास अभी तक पर्याप्त डेटा नहीं है।
क्या चर्चा करें:
- क्या कुछ टूटा या अप्रत्याशित व्यवहार हुआ?
- क्या लागतें हमारे अनुमानों पर नज़र रख रही हैं, या कोई आश्चर्य है?
- कोई उपयोगकर्ता रिपोर्ट जिस पर तत्काल ध्यान देने की आवश्यकता है?
- क्या निगरानी हमें उपयोगी संकेत दे रही है, या क्या हमारे पास कुछ अंधे बिंदु हैं?
आउटपुट: अत्यावश्यक सुधारों की एक छोटी सूची, यदि कोई हो। अधिकांश दिन-पहले निष्कर्ष "हमें कुछ बदलने की ज़रूरत है" के बजाय "हम इसे देखेंगे" होना चाहिए।
पास 2: सप्ताह-एक डीप डाइव (60 मिनट, पहले सप्ताह का अंत)
अब आपके पास वास्तविक डेटा है। यहीं पर सारगर्भित चर्चा होती है।
तैयार करने के लिए डेटा:
- दैनिक सक्रिय उपयोग और उपयोग पैटर्न (कब, कितना, किस प्रकार के अनुरोध)
- वास्तविक लागत बनाम अनुमानित लागत, उपयोग पैटर्न के अनुसार विभाजित
- गुणवत्ता संकेत: उपयोगकर्ता रेटिंग, संपादन दरें, त्रुटि दरें, कोई मैन्युअल समीक्षा परिणाम
- प्रदर्शन डेटा: विलंबता वितरण, टाइमआउट दरें, दर सीमा हिट
- एआई सुविधा से संबंधित समर्थन टिकट और उपयोगकर्ता प्रतिक्रिया
चर्चा संरचना:
हमें किस बात ने आश्चर्यचकित किया? यहां से प्रारंभ करें। अपेक्षाओं और वास्तविकता के बीच का अंतर वह जगह है जहां सबसे उपयोगी अंतर्दृष्टि रहती है। हो सकता है कि उपयोग आपके अनुमान से 3 गुना अधिक हो। हो सकता है कि उपयोगकर्ता इस सुविधा का उपयोग किसी ऐसी चीज़ के लिए कर रहे हों जिसके लिए आपने इसे डिज़ाइन नहीं किया है। हो सकता है कि गुणवत्ता कुछ क्षेत्रों में अपेक्षा से बेहतर हो और अन्य में बदतर हो।
हमें अगले सप्ताह में क्या बदलना चाहिए? यह सामरिक समायोजन के बारे में है। त्वरित बदलाव, कैशिंग रणनीतियाँ, उपयोगकर्ताओं को बेहतर इनपुट की ओर मार्गदर्शन करने के लिए यूएक्स परिवर्तन, स्पष्ट अपशिष्ट के लिए लागत अनुकूलन।
निर्णय लेने से पहले हमें और अधिक डेटा की क्या आवश्यकता है? एक सप्ताह के बाद कुछ चीजें अस्पष्ट हो जाएंगी। उन्हें स्पष्ट रूप से नाम दें और तय करें कि आपको किस डेटा की आवश्यकता है और आपके पास कब पर्याप्त डेटा होगा।
पास 3: माह-एक रणनीतिक समीक्षा (60-90 मिनट, एक माह के बाद)
यह रेट्रो है जहां आप आकलन करते हैं कि सुविधा दीर्घकालिक रूप से व्यवहार्य है या नहीं।
बड़े सवाल:
- क्या यह सुविधा अपनी लागत अर्जित कर रही है? (अमूर्त मूल्य में नहीं, बल्कि मापने योग्य व्यावसायिक प्रभाव में।)
- क्या गुणवत्ता काफी अच्छी है, या हम तकनीकी और ट्रस्ट ऋण जमा कर रहे हैं?
- क्या हम इसे 5x या 10x वर्तमान उपयोग पर बनाए रख सकते हैं?
- हमने एआई सुविधाओं के निर्माण के बारे में क्या सीखा जो हमारे अगले पर लागू होता है?
इस पास से रणनीतिक निर्णय लेने चाहिए: अधिक निवेश करें, अनुकूलन करें और बनाए रखें, या दृष्टिकोण पर पुनर्विचार करें। इसे सीखे गए पाठों की एक सूची भी तैयार करनी चाहिए जो अगली बार वास्तव में उपयोगी होने के लिए पर्याप्त विशिष्ट हो।
लागत आश्चर्य और उनके बारे में क्या करना है
एआई फीचर लॉन्च में लागत में बढ़ोतरी सबसे आम समस्या है। यहां पैटर्न और व्यावहारिक प्रतिक्रियाएं दी गई हैं:
गपशप करने वाले उपयोगकर्ता की समस्या। उपयोगकर्ताओं का एक छोटा सा प्रतिशत टोकन उपयोग की अनुपातहीन मात्रा उत्पन्न करता है। यदि 5% उपयोगकर्ता लागत का 40% हिस्सा लेते हैं, तो आपको यह निर्णय लेने की आवश्यकता है कि क्या भारी उपयोगकर्ताओं को दर-सीमा देनी है, उनके उपयोग के मामले के लिए अनुकूलन करना है, या लागत स्वीकार करना है।
फूले हुए संदर्भ की समस्या। आप मॉडल को आवश्यकता से अधिक संदर्भ भेज रहे हैं। अपने संकेतों और सिस्टम संदेशों की समीक्षा करें - क्या ऐसे निर्देश हैं जिनकी मॉडल को अधिकांश अनुरोधों के लिए आवश्यकता नहीं है? क्या आप प्रासंगिक होने पर ही संदर्भ को गतिशील रूप से शामिल कर सकते हैं?
"हम पुनः प्रयास के बारे में भूल गए" समस्या। विफलताएं पुनः प्रयास को ट्रिगर करती हैं, पुनः प्रयास में टोकन की लागत आती है, और लोड के तहत, पुनः प्रयास तूफान आपकी लागत को कई गुना बढ़ा सकते हैं। घातीय बैकऑफ़ लागू करें और विचार करें कि क्या विफल अनुरोध को फिर से प्रयास करना चाहिए या केवल एक सुंदर त्रुटि लौटानी चाहिए।
मॉडल ओवरकिल समस्या। आप उन कार्यों के लिए अपने सबसे सक्षम (और महंगे) मॉडल का उपयोग कर रहे हैं जिन्हें एक छोटा, सस्ता मॉडल पूरी तरह से अच्छी तरह से संभाल सकता है। सस्ते मॉडलों के लिए सरल अनुरोधों को रूट करें। पहले कार्य को वर्गीकृत करें, फिर मॉडल चुनें।
वे सबक जो प्रत्येक एआई लॉन्च में स्थानांतरित होते हैं
कई AI फीचर लॉन्च से गुजरने के बाद, कुछ पैटर्न लगातार सामने आते हैं:
आपका परीक्षण सूट बहुत साफ था। वास्तविक दुनिया के इनपुट आपके द्वारा परीक्षण किए गए किसी भी चीज़ की तुलना में अधिक गंदे, लंबे, अजीब और अधिक प्रतिकूल हैं। प्रत्येक लॉन्च के बाद "अजीब वास्तविक इनपुट" का एक संग्रह बनाएं और उन्हें अपने परीक्षण सूट में जोड़ें।
उपयोगकर्ता आपको बताएंगे कि फीचर को वास्तव में क्या करना चाहिए। जिस तरह से लोग आपके एआई फीचर का उपयोग करते हैं वह अक्सर आपके डिजाइन इरादे से भिन्न होता है। उस विचलन पर ध्यान दें - यह मुफ़्त उत्पाद अनुसंधान है।
गति आपकी सोच से कहीं अधिक मायने रखती है। उपयोगकर्ताओं के पास AI सुविधाओं के लिए आपकी अपेक्षा से कम विलंबता सहनशीलता है। यदि इसमें कुछ सेकंड से अधिक समय लगता है, तो वे अलग होना शुरू कर देते हैं। अनुमानित प्रदर्शन सुधार (स्ट्रीमिंग प्रतिक्रियाएं, प्रगति संकेतक) बहुत मदद करते हैं।
आपने V1 को अधिक और V3 को कम आंका। AI सुविधा का पहला संस्करण उपयोगकर्ताओं के लिए शायद ही कभी प्रभावशाली होता है। लेकिन तीसरा संस्करण, वास्तविक उपयोग डेटा द्वारा संचालित दो दौर के सुधार के बाद, अक्सर अपेक्षाओं से अधिक होता है। V1 को यह जानते हुए शिप करें कि यह एक सीखने का वाहन है, अंतिम उत्पाद नहीं।
<घंटा/>NextRetro निःशुल्क आज़माएं - चरणबद्ध कॉलम के साथ अपने AI लॉन्च रेट्रो की संरचना करें और वोट करें कि लॉन्च के बाद कौन से मुद्दों को पहले निपटाना है।
<घंटा/>अंतिम अद्यतन: फरवरी 2026
पढ़ने का समय: 8 मिनट
