Daphne Koller के ML प्रोडक्ट सबक: शोध से तैनाती तक

शोध के नतीजे अक्सर प्रोडक्ट वास्तविकता में क्यों टिकते नहीं हैं

एक उत्कृष्ट ML पेपर कभी-कभी एक निराशाजनक प्रोडक्ट में बदल सकता है। पेपर नियंत्रित परिस्थितियों में किसी बात को साबित करने के लिए बनाए जाते हैं। प्रोडक्ट लोगों को एक अव्यवस्थित दिन पर, गंदे डेटा के साथ और सीमित धैर्य में कोई काम पूरा करने में मदद करने के लिए बनाए जाते हैं।

Daphne Koller के ML प्रोडक्ट पाठ से एक उपयोगी सबक (एक लेंस के रूप में, जीवनी के रूप में नहीं) प्रेरणाओं में बदलाव है: शोध नवाचार और साफ़ बढ़तों को रिवॉर्ड करता है, जबकि प्रोडक्ट उपयोगिता और भरोसे को रिवॉर्ड करता है। अगर आपका मॉडल प्रभावशाली है लेकिन फीचर समझने में मुश्किल, धीमा, या अप्रत्याशित है, तो उपयोगकर्ताओं को बेंचमार्क की परवाह नहीं होगी।

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

अधिकांश "पेपर जीत" वास्तविक दुनिया में कुछ ही कारणों से फेल होती हैं: लक्ष्य अस्पष्ट होता है (तो टीम वही ऑप्टिमाइज़ कर देती है जो नापना आसान हो), डेटा शिफ्ट होता है (नए उपयोगकर्ता, नए विषय, नए एज केस), स्वामित्व अस्पष्ट होता है (तो गुणवत्ता समस्याएं लंबित रहती हैं), या फीचर को “AI जादू” के रूप में शिप किया जाता है बिना किसी तरीके के जिससे आउटपुट की भविष्यवाणी, सत्यापन, या सुधार किया जा सके।

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

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

यह बात उपयोगकर्ता-समक्ष AI बिल्डर्स जैसे Koder.ai में स्पष्ट रूप से दिखती है। चैट से ऐप जनरेट करना डेमो में आश्चर्यजनक लग सकता है, पर असली उपयोगकर्ता इस बात की परवाह करते हैं कि परिणाम चलता है या नहीं, एडिट्स प्रत्याशित तरीके से व्यवहार करते हैं या नहीं, और कुछ टूटने पर वे वापस रोल कर सकते हैं या नहीं। यही प्रोडक्ट वास्तविकता है: "best model" से कम और भरोसेमंद अनुभव से ज़्यादा।

पेपर मेट्रिक्स बनाम प्रोडक्ट परिणाम: व्यवहार में क्या बदलता है

शोध आम तौर पर किसी बात को साबित करने की कोशिश करता है: एक मॉडल साफ़ डैटा सेट पर फिक्स्ड टेस्ट में बेसलाइन को पछाड़ दे। प्रोडक्ट उपयोगकर्ता की मदद करने की कोशिश करता है ताकि वह गंदे हालात में, असली दांव के साथ और सीमित धैर्य में कोई काम पूरा कर सके। यही असंगति कई वादों को तोड़ देती है।

Daphne Koller के ML प्रोडक्ट पाठों में से एक सबसे व्यावहारिक सिद्धांत यह है कि “सटीकता” को आरंभिक संकेत के रूप में लें, अंतिम लक्ष्य के रूप में नहीं। पेपर में एक छोटा मेट्रिक लाभ मायने रख सकता है। प्रोडक्ट में वही लाभ दिखाई नहीं देगा, या वह नए लागत ला सकता है: धीमी प्रतिक्रिया, भ्रमित करने वाले एज केस, या सपोर्ट टिकटों में वृद्धि।

प्रोटोटाइप, पायलट, प्रोडक्शन: नियम बदलते हैं

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

याद रखने का एक आसान तरीका:

• प्रोटोटाइप: छोटा डेटा सैंपल, सरल मेट्रिक, बहुत मैन्युअल चेकिंग
• पायलट: असली यूजर फ्लो, संरचित एरर विश्लेषण, फ़ीडबैक लूप्स
• प्रोडक्शन: मॉनिटरिंग, फेलबैक, लागत सीमाएँ, और रिट्रेनींग प्लान

वे छिपी हुई ज़रूरतें जिनका पेपर में जिक्र नहीं होता

प्रोडक्ट परिणाम मॉडल के चारों ओर की हर चीज़ पर निर्भर करते हैं। डेटा पाइपलाइन्स टूटती हैं। जब उपयोगकर्ता व्यवहार बदलते हैं तो इनपुट ड्रिफ्ट होते हैं। लेबल्स पुराने हो जाते हैं। आपको समस्याओं को जल्दी नोटिस करने और जब AI गलत हो तो उपयोगकर्ताओं की मदद करने का तरीका चाहिए।

वह "छिपा हुआ काम" आमतौर पर इनपुट गुणवत्ता ट्रैक करना, फ़ेल्योर लॉग करना, अजीब मामलों की समीक्षा करना, और कब retrain करना है यह तय करना शामिल करता है। इसमें सपोर्ट स्क्रिप्ट्स और स्पष्ट UI संदेश भी शामिल हैं, क्योंकि उपयोगकर्ता पूरे अनुभव को आंकते हैं, न कि केवल मॉडल को।

बनाने से पहले परिभाषित करें कि "कافی अच्छा" का क्या अर्थ है और इसे सादा भाषा में लिखें: किन उपयोगकर्ताओं के लिए, किन कार्यों के लिए, स्वीकार्य त्रुटि प्रकार, और वह थ्रेशहोल्ड जहाँ आप शिप या रोक देते हैं। "हाथ से समीक्षा समय 20% घटाना बिना उच्च-जोखिम गलतियों में वृद्धि के" कहना "F1 स्कोर में सुधार" से ज़्यादा उपयोगी है।

अनुमान लगाये बिना ML फीचर का स्कोप कैसे तय करें

मॉडल से नहीं, उपयोगकर्ता के काम से शुरू करें। एक अच्छा स्कोप उस एक प्रश्न से शुरू होता है: लोग क्या पूरा करना चाह रहे हैं, और आज उन्हें क्या धीमा कर रहा है? अगर आप वर्कफ़्लो के उस सटीक मोमेंट का वर्णन नहीं कर सकते जहाँ फीचर मदद करता है, तो आप अभी भी "पेपर मोड" में हैं, प्रोडक्ट मोड में नहीं।

Daphne Koller के ML प्रोडक्ट पाठ से एक सहायक फ्रेम यह है कि फीचर को उपयोगकर्ता के लिए उसकी भूमिका से परिभाषित करें। क्या यह उनका काम खुद कर रहा है (ऑटोमेशन), उन्हें बेहतर करने में मदद कर रहा है (assistance), या एक सुझाव दे रहा है जिसे वे स्वीकार या अस्वीकार कर सकते हैं (decision support)? यह चुनाव UI, मेट्रिक, स्वीकार्य त्रुटि दर, और गलतियों को संभालने के तरीके को आकार देता है।

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

बाधाएँ ही असली स्कोप हैं। उन्हें स्पष्ट करें।

एक सरल स्कोपिंग टेम्पलेट

इन पांच लाइनों के स्पष्ट होने तक आगे न बढ़ें:

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

उदाहरण: मान लीजिए आप Koder.ai जैसे वाइब-कोडिंग टूल में एक "AI schema helper" जोड़ रहे हैं। उपयोगकर्ता का काम है "मुझे जल्दी एक डेटाबेस टेबल चाहिए ताकि मैं बिल्ड जारी रख सकूँ।" अगर आप इसे असिस्ट के रूप में स्कोप करते हैं, तो वादा हो सकता है "एक टेबल स्कीमा सुझाता है जिसे आप रिव्यू और लागू कर सकते हैं।" यह तुरंत गार्डरेल इंगित करता है: लागू करने से पहले diff दिखाएं, रोलबैक की अनुमति दें, और जटिल reasoning की तुलना में तेज़ प्रतिक्रियाओं को प्राथमिकता दें।

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

ऐसे मेट्रिक्स चुनें जो असली उपयोगकर्ता मूल्य से मेल खाते हों

एक अच्छा ML मेट्रिक एक अच्छा प्रोडक्ट मेट्रिक नहीं ही होता। दरअसल गैप देखने का सबसे तेज़ तरीका यह पूछना है: अगर यह नंबर बढ़े तो क्या असली उपयोगकर्ता इसे नोटिस कर के फर्क महसूस करेगा? अगर नहीं, तो वह शायद लैब मेट्रिक है।

Daphne Koller के ML प्रोडक्ट पाठों से एक भरोसेमंद अभ्यसन है कि एक प्राथमिक सफलता मेट्रिक चुनें जो उपयोगकर्ता मूल्य से जुड़ा हो और लांच के बाद मापनीय हो। बाकी सब कुछ इसका समर्थन करे, प्रतिस्पर्धा नहीं।

एक सरल मेट्रिक स्टैक

एक प्राथमिक मेट्रिक से शुरू करें, फिर कुछ गार्डरेल जोड़ें:

• प्राथमिक सफलता मेट्रिक: उपयोगकर्ता जो चाहते हैं उसका परिणाम (टास्क पूरा होने की दर, सही उत्तर तक का समय, % सेशन्स जो "यह मददगार था" के साथ खत्म होते हैं)
• गार्डरेल मेट्रिक्स: ऐसी चीजें जो आपको "जीतने" से रोकती हैं जो उपयोगकर्ताओं को नुकसान पहुंचाती हैं (हानिकारक सुझाव दर, शिकायत दर, उच्च-प्रभाव वाली त्रुटि दर)
• लागत और लेटेंसी: प्रतिक्रिया समय और प्रति अनुरोध लागत, क्योंकि धीमा या महँगा AI जल्दी बेकार बन जाता है

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

ऑफ़लाइन मेट्रिक्स (accuracy, F1, BLEU, ROUGE) अभी भी उपयोगी हैं, पर उन्हें स्क्रीनिंग टूल के रूप में लें। ऑनलाइन मेट्रिक्स (conversion, retention, सपोर्ट टिकट, रिफंड, रीवर्क टाइम) बताते हैं कि क्या फीचर प्रोडक्ट में होना चाहिए या नहीं।

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

बेसलाइन न छोड़ें। आपके पास कुछ ऐसा होना चाहिए जिसे आप हरा सकें: नियम-आधारित सिस्टम, टेम्पलेट लाइब्रेरी, या वर्तमान मानव वर्कफ़्लो। अगर AI सिर्फ़ बेसलाइन के बराबर है पर भ्रम जोड़ता है, तो यह नेट नुकसान है।

उदाहरण: आप चैट के लिए AI सारांश शिप करते हैं। ऑफ़लाइन, सारांश ROUGE पर अच्छे अंक पाते हैं। ऑनलाइन, एजेंट जटिल मामलों पर सारांश ठीक करने में ज़्यादा समय लगाते हैं। बेहतर प्राथमिक मेट्रिक होगा "AI सारांश वाले चैट्स पर औसत हैंडल टाइम," साथ में गार्डरेल जैसे "महत्वपूर्ण चूकों के साथ सारांश %" (साप्ताहिक ऑडिट) और "उपयोगकर्ता-दर्ज गलत सारांश" दर।

चरण-दर-चरण: ML आइडिया को तैनात करने योग्य सिस्टम में बदलना

एक शोध परिणाम तब प्रोडक्ट बनता है जब आप उसे शिप कर सकें, माप सकें, और सपोर्ट कर सकें। व्यवहारिक संस्करण अक्सर पेपर वर्शन से छोटा और अधिक प्रतिबंधित होता है।

1) MVP स्लाइस परिभाषित करें

सबसे छोटे इनपुट के साथ शुरू करें जिसे आप स्वीकार कर सकते हैं और सबसे सरल आउटपुट जो फिर भी मदद करता है।

"किसी भी दस्तावेज़ का सारांश करें" के बजाय, "1000 शब्द से कम सपोर्ट टिकट को 3 बुलेट पॉइंट्स में सारांशित करें" से शुरू करें। कम फ़ॉर्मैट = कम आश्चर्य।

2) तय करें आपको किस डेटा की ज़रूरत है

लिखित लिखें: आपके पास क्या है, आप क्या सुरक्षित रूप से लॉग कर सकते हैं, और क्या आपको जानबूझ कर इकट्ठा करना होगा। कई विचार यहीं अटक जाते हैं।

अगर आपके पास पर्याप्त असली उदाहरण नहीं हैं, तो एक हल्का कलेक्शन चरण योजना बनाएं: उपयोगकर्ताओं से आउटपुट रेट करने को कहें, या "helpful" बनाम "not helpful" का छोटा कारण माँगें। सुनिश्चित करें कि आप जो इकट्ठा कर रहे हैं वह वही है जिसे आप बेहतर बनाना चाहते हैं।

3) जल्दी ही एक मूल्यांकन विधि चुनें

सबसे सस्ता मूल्यांकन चुनें जो सबसे बड़ी विफलताओं को पकड़ सके। एक होल्डआउट सेट, स्पष्ट नियमों के साथ त्वरित मानव समीक्षा, या एक A/B टेस्ट गार्डरेल मेट्रिक के साथ काम कर सकता है। एक नंबर पर निर्भर न रहें; गुणवत्ता संकेत के साथ सुरक्षा या त्रुटि संकेत जोड़ें।

4) रिलीज़ की योजना एक प्रयोग की तरह बनाएं

स्टेजेस में रिलीज़ करें: आंतरिक उपयोग, छोटा उपयोगकर्ता समूह, फिर व्यापक रोलआउट। सख्त फ़ीडबैक लूप रखें: फ़ेल्योर लॉग करें, साप्ताहिक सैंपल समीक्षा करें, और छोटे फिक्स भेजें।

अगर आपकी टूलिंग स्नैपशॉट और रोलबैक को सपोर्ट करती है, तो उनका उपयोग करें। तेज़ revert करने की क्षमता यह बदल देती है कि आप कितनी सुरक्षित रूप से iterate कर सकते हैं।

5) स्पष्ट स्टॉप नियम के साथ दोहराएँ

पहले से तय करें कि "बढ़ाने के लिए काफी अच्छा" का क्या मतलब है और क्या ट्रिगर होगा कि आप रोक दे। उदाहरण: "हम rollout बढ़ाते हैं जब helpfulness 70% से ऊपर हो और severe errors 1% से कम हों लगातार दो हफ्तों तक।" यह अनंत बहस से रोकता है और ऐसे वादों से बचाता है जिन्हें आप निभा नहीं सकते।

उपयोगकर्ता-समक्ष AI ऐप्स में अपेक्षाएँ कैसे सेट करें

उपयोगकर्ता आपके मॉडल को उसके बेहतरीन जवाबों से नहीं आंकते। वे उसे उन कुछ पलों से आंकते हैं जब वह आत्मविश्वास के साथ गलत होता है, खासकर जब ऐप आधिकारिक लगे। अपेक्षा-सेटिंग प्रोडक्ट का हिस्सा है, डिस्क्लेमर नहीं।

रेंज में बोलें, सार्वभौमिक वादे में नहीं। "यह सटीक है" कहने के बजाय "X के लिए आमतौर पर सही" और "Y के लिए कम भरोसेमंद" कहें। अगर कर सकें, तो सादे शब्दों में confidence दिखाएँ (उच्च, मध्यम, कम) और हर स्तर के लिए उपयोगकर्ता को अगला कदम बताएं।

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

अनिश्चितता संकेत तब सबसे बेहतर काम करते हैं जब वे दिखाई देते हों और कार्रवाई योग्य हों। उपयोगकर्ता अधिक क्षमाशील होते हैं जब वे देख सकते हैं कि AI ने किस वजह से ऐसा उत्तर दिया, या जब ऐप स्वीकार कर ले कि इसे चेक की ज़रूरत है।

उपयोगकर्ताओं को समझ आने वाले व्यवहारिक अनिश्चितता संकेत

एक या दो संकेत चुनें और लगातार उनका उपयोग करें:

• एक संक्षिप्त कारण (कौन से इनपुट इस्तेमाल हुए)
• जब उत्तर दस्तावेज़ों पर निर्भर हो, तो उद्धरण या स्रोत के स्निपेट
• "Needs review" जैसा साधारण लेबल जब confidence कम हो
• इनपुट अस्पष्ट होने पर दो विकल्प दिखाना

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

उदाहरण: एक सपोर्ट रिप्लाई असिस्टेंट ऑटो-भेजना नहीं चाहिए। यह ड्राफ्ट जनरेट करे और जोखिम वाले हिस्सों (रिफंड, पॉलिसी वादों) को "Needs review" के रूप में हाइलाइट करे। अगर confidence कम है, तो अनुमान लगाने की बजाय एक फॉलो-अप सवाल पूछे।

ओवरप्रोमिसिंग और चर्न की सामान्य गलतियाँ

उपयोगकर्ता मॉडल के अधूरे होने की वजह से नहीं churn करते। वे तब churn करते हैं जब ऐप आत्मविश्वास से बोलता है और फिर ऐसे तरीके से फेल होता है कि भरोसा टूट जाए। Daphne Koller के कई ML प्रोडक्ट पाठ यहाँ उतरते हैं: काम सिर्फ़ मॉडल ट्रेन करने का नहीं है, बल्कि एक ऐसा सिस्टम डिज़ाइन करना है जो असली उपयोग में सुरक्षित तरीके से व्यवहार करे।

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

ये असफलताएँ अक्सर "नॉन-ML" प्रोडक्ट डिसीजन स्किप करने से आती हैं: मॉडल को क्या करने की अनुमति है, कब इसे मना करना चाहिए, जब confidence कम हो तो क्या होता है, और लोग इसे कैसे ठीक कर सकते हैं। अगर आप उन सीमाओं को परिभाषित नहीं करते, तो मार्केटिंग और UI उन्हें परिभाषित कर देंगे।

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

इसका समाधान शायद "ज्यादा ट्रेन करें" नहीं है। यह स्कोप के बारे में सटीक होना, उपयोगकर्ता नुकसान को दर्शाने वाले मेट्रिक्स चुनना (आत्मविश्वासी गलत उत्तर सुरक्षित मना करने से बदतर हैं), और ऑपरेशनल सुरक्षा बनाना (अलर्ट, स्टेज्ड रिलीज़, स्नैपशॉट, रोलबैक) है।

उदाहरण परिदृश्य: एक ऐसा AI फीचर शिप करना जिस पर लोग भरोसा कर सकें

कस्टमर सपोर्ट ट्रायज एक व्यावहारिक जगह है जहां Daphne Koller के ML प्रोडक्ट पाठ लागू होते हैं। लक्ष्य "AI से सपोर्ट का समाधान" नहीं है। लक्ष्य यह है कि एक मानव के लिए टिकट को सही जगह पर रूट करने का समय कम करना।

एक छोटा, ईमानदार वादा परिभाषित करें

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

यह शब्दावली मायने रखती है। "सुझाया" और "एजेंट कन्फर्म करे" सही अपेक्षा सेट करती है और शुरुआती गलतियों को ग्राहक-सामने आउटेज बनने से रोकती है।

काम के साथ मेल खाने वाले मेट्रिक्स चुनें

ऑफ़लाइन सटीकता मदद करती है, पर यह स्कोरबोर्ड नहीं है। ऐसे परिणाम ट्रैक करें जो असली काम को दर्शाते हैं: time-to-first-response, reassign rate, agent override rate, और उपयोगकर्ता संतुष्टि (CSAT)। साथ ही "साइलेंट फेल्योर" संकेतों पर भी नज़र रखें, जैसे कि मॉडल ने जो टिकट अर्जीट बताया उसके लिए हैंडलिंग टाइम बढ़ना।

पूर्णता नहीं, विफलता के लिए डिज़ाइन करें

एक उत्तर के बजाय, शीर्ष 3 category सुझाव दिखाएँ आसान confidence लेबल के साथ (उच्च, मध्यम, कम)। जब confidence कम हो, तो डिफ़ॉल्ट "needs review" रखें और स्पष्ट मानव चुना चाहिए।

जब एजेंट ओवरराइड करे तो एक त्वरित कारण कोड दें (गलत प्रोडक्ट एरिया, संदर्भ गायब, ग्राहक गुस्सैल)। ये कारण ट्रेनिंग डेटा बन जाते हैं और सिस्टमैटिक गैप्स को हाइलाइट करते हैं।

बिना आश्चर्य के रोल आउट करें

छोटे से शुरू करें और केवल तब बढ़ाएँ जब मेट्रिक्स सही दिशा में जाएँ। एक टीम को लॉन्च करें और पुरानी वर्कफ़्लो को फॉलबैक के रूप में रखें। साप्ताहिक सैंपल की समीक्षा करें ताकि दोहराव वाली गलतियाँ मिल सकें। लेबल और UI कॉपी को retrain करने से पहले एडजस्ट करें। जब मॉडल अपडेट के बाद ओवरराइड दर स्पाइक करे तो अलर्ट जोड़ें।

अगर आप यह फीचर Koder.ai जैसे प्लेटफ़ॉर्म पर बनाते हैं, तो प्रॉम्प्ट्स, नियम, और UI कॉपी को प्रोडक्ट का हिस्सा मानें। भरोसा पूरे सिस्टम से आता है, केवल मॉडल से नहीं।

शिप करने से पहले त्वरित चेकलिस्ट

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

लांच से पहले इन आइटम्स को चेक करें:

• उपयोगकर्ता वादा (एक वाक्य): फीचर क्या करेगा, और कब? इसे टेस्टेबल रखें।
• बेसलाइन और लक्ष्य सुधार: ML के बिना आज क्या होता है, और किस संख्या को अर्थपूर्ण सुधार माना जाएगा?
• जब मॉडल गलत या अनिश्चित हो: फेल बिहेवियर परिभाषित करें (confidence संकेत, स्पष्टीकरण प्रश्न, नियम फेलबैक, या फीचर छुपा दें)। असुरक्षित आउटपुट क्या है और कैसे ब्लॉक होगा, यह परिभाषित करें।
• साप्ताहिक सफलता संकेत: 1-2 मेट्रिक्स चुनें जिन्हें आप हफ्ते में जल्दी से देख सकें (opt-in उपयोग, पुनरावृत्ति उपयोग, पूर्णता दर, सेव दर, शिकायत दर, undo दर)।
• मॉनिटरिंग, रोलबैक, स्वामित्व: जानें कि गुणवत्ता किसकी ज़िम्मेदारी है, किसे अलर्ट जाता है, और आप बदलावों को कैसे तेज़ी से revert करते हैं।

यदि आप केवल एक अतिरिक्त काम कर पाते हैं, तो असली उपयोगकर्ताओं के साथ एक छोटा रिलीज़ चलाएँ, टॉप 20 विफलताओं को इकट्ठा करें, और उन्हें लेबल करें। वे विफलताएँ आमतौर पर बताती हैं कि स्कोप, UI, या वादे समायोजित करने की ज़रूरत है, न कि केवल मॉडल के।

अगले कदम: विचारों से शिपिंग तक एक व्यावहारिक योजना

दो मिनट में पढ़ने योग्य एक पेज का स्पेक से शुरू करें। इसे सादी भाषा में रखें और उस वादे पर ध्यान दें जिस पर उपयोगकर्ता भरोसा कर सके।

चार चीजें लिखें: उपयोगकर्ता वादा, इनपुट (और क्या उपयोग नहीं करना चाहिए), आउटपुट (जिसमें अनिश्चितता या इनकार का संकेत शामिल है), और सीमाएँ (अपेक्षित फेल्योर मोड और आप अभी क्या सपोर्ट नहीं करेंगे)।

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

फिर एक MVP रोलआउट चुनें जो जोखिम से मेल खाता हो: मैसी टेस्ट सेट पर ऑफ़लाइन मूल्यांकन, शैडो मोड, आसान फ़ीडबैक बटन के साथ सीमित बीटा, और एक क्रमिक रोलआउट जिसमें एक किल स्विच हो।

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

अगर आप तेजी से प्रोटोटाइप करना चाहते हैं, तो चैट-आधारित बिल्ड फ्लो आपकी मदद कर सकता है ताकि आप जल्दी से प्रोडक्ट का आकार मान्य कर सकें। उदाहरण के लिए Koder.ai पर आप उस फीचर के आसपास एक छोटा ऐप जनरेट कर सकते हैं, अपने चुने हुए मेट्रिक्स के लिए बेसिक ट्रैकिंग जोड़ सकते हैं, और उपयोगकर्ता वादे पर iterate कर सकते हैं। गति मदद करती है, पर अनुशासन वही रहता है: केवल उतना शिप करें जितना आपके मेट्रिक्स और गार्डरेल सपोर्ट कर सकें।

एक अंतिम परख: क्या आप एक पैराग्राफ में उपयोगकर्ता को फीचर का व्यवहार समझा सकते हैं, जिसमें यह भी बताया हो कि यह कब गलत हो सकता है? अगर नहीं, तो यह शिप करने के लिए तैयार नहीं है, चाहे डेमो कितना भी अच्छा दिखे।