प्रॉम्प्ट और संदर्भ
एक सर्च टीम ने एक नया रैंकिंग एल्गोरिदम पूरा कर लिया है, लेकिन लॉन्च का तरीका तय नहीं हुआ है। इंजीनियरिंग टीम फीचर फ्लैग चाहती है, ग्रोथ टीम A/B टेस्ट चाहती है, और ऑपरेशन्स टीम इंसिडेंट्स को लेकर चिंतित है। बताएं कि आप मैकेनिज्म का चयन कैसे करते हैं, सफलता को कैसे परिभाषित करते हैं, एक्सपोजर को कैसे नियंत्रित करते हैं, और खराब परिणाम आने पर रोलबैक कैसे करते हैं। मान लें कि एल्गोरिदम पहले से ही डिप्लॉय किया जा चुका है; प्रश्न यह है कि इसे कौन देखता है, इसकी तुलना कैसे की जाए और इसका विस्तार कब किया जाए।
इंटरव्यूअर क्या टेस्ट कर रहा है
- क्या आप लक्ष्यों को अलग-अलग समझते हैं: एक फ्लैग एक्सपोजर को नियंत्रित करता है, एक प्रोग्रेसिव रोलआउट जोखिम को नियंत्रित करता है, और एक A/B टेस्ट कारणात्मक (causal) तुलना का उत्तर देता है।
- क्या आप ट्रैफिक प्रतिशत पर चर्चा करने से पहले यूजर, बिजनेस और सिस्टम गार्डरेल्स को परिभाषित करते हैं।
- क्या आप स्टेबल बकेटिंग, संदूषण (contamination), रोलबैक का अधिकार और सुरक्षित डिफॉल्ट्स (safe defaults) की व्याख्या करते हैं।
- क्या आप लॉन्च को सिर्फ एक बटन क्लिक मानने के बजाय फ्लैग ओनरशिप, लाइफसाइकिल और क्लीनअप को शामिल करते हैं।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- क्या हम वैल्यू सीख रहे हैं या सिर्फ सुरक्षित रूप से शिप कर रहे हैं? अज्ञात वैल्यू के लिए एक प्रयोग की आवश्यकता होती है; उच्च जोखिम वाली ज्ञात वैल्यू के लिए प्रोग्रेसिव रोलआउट की आवश्यकता होती है।
- प्रयोग की इकाई (experiment unit) क्या है? सर्च रैंकिंग को आम तौर पर स्टेबल यूजर या अकाउंट बकेटिंग की आवश्यकता होती है; रिक्वेस्ट-लेवल रैंडमनेस के कारण एक ही यूजर का अनुभव बार-बार बदलता रहता है।
- प्राइमरी मेट्रिक क्या है और कौन से गार्डरेल्स गैर-परक्राम्य (non-negotiable) हैं? अधिक क्लिक खराब लेटेंसी, शिकायतों, कन्वर्जन या एरर्स को सही नहीं ठहरा सकते।
- क्या कोई क्रॉस-डिवाइस, क्षेत्रीय या डिपेंडेंसी से संबंधित सीमाएं हैं? असंगत एक्सपोजर निष्कर्षों को दूषित करता है; पहले दायरे को सीमित करें या आवंटन (allocation) को ठीक करें।
30-सेकंड का उत्तर फ्रेमवर्क
"मैं सबसे पहले यह स्पष्ट करता हूं कि लक्ष्य सीखना है, जोखिम नियंत्रण है, या दोनों। रैंकिंग वैल्यू की तुलना करने के लिए, मैं यूजर-लेवल स्टेबल A/B स्प्लिट का उपयोग करता हूं; जब वैल्यू ज्ञात हो लेकिन विफलता का जोखिम अधिक हो, तो मैं किल स्विच के साथ एक छोटे प्रोग्रेसिव रोलआउट से शुरुआत करता हूं। लॉन्च से पहले, मैं एक नॉर्थ-स्टार मेट्रिक और लेटेंसी व एरर्स जैसे गार्डरेल्स को परिभाषित करता हूं, और वैरिएंट आईडी, एक्सपोजर और परिणाम को लॉग करता हूं। मैं पूर्व-निर्धारित थ्रेशोल्ड पूरे होने के बाद ही विस्तार करता हूं, विफलता पर रोककर रोलबैक करता हूं, और निर्णय के बाद एक्सपेरिमेंट ब्रांच और फ्लैग को हटा देता हूं।"
स्टेप-बाय-स्टेप विस्तृत उत्तर
1. प्रत्येक मैकेनिज्म को प्रश्न के साथ मैप करें
एक फीचर फ्लैग एक रनटाइम कंट्रोल प्लेन है: कोड को सभी के सामने एक्सपोज किए बिना डिप्लॉय किया जा सकता है। एक प्रोग्रेसिव रोलआउट एक एक्सपोजर पॉलिसी है: इंटरनल अकाउंट्स से एक छोटे ग्राहक कोहोर्ट और फिर व्यापक ट्रैफिक की ओर बढ़ना। एक A/B टेस्ट एक माप डिजाइन (measurement design) है: तुलनीय समूहों में वैरिएंट्स की तुलना करना। इन्हें एक साथ लेयर किया जा सकता है, लेकिन एक दूसरे की जगह नहीं ले सकता।
2. इकाई और स्टेबल बकेटिंग चुनें
Google Cloud का उदाहरण स्टिकी बकेटिंग के लिए userID और विश्लेषण के लिए विवरणात्मक वैरिएंट आईडी का उपयोग करता है। रैंकिंग के लिए, किसी यूजर या अकाउंट को बेसलाइन या एक्सपेरिमेंटल में हैश करें ताकि टेस्ट के दौरान वही व्यक्ति बार-बार न बदले। रिक्वेस्ट-लेवल रैंडमाइजेशन कैशिंग, सीखने के व्यवहार और लौटने वाले यूजर के अनुभव को दूषित करता है।
3. मेट्रिक्स और स्टॉप रूल्स परिभाषित करें
नॉर्थ-स्टार मेट्रिक को यूजर के कार्य का प्रतिनिधित्व करना चाहिए, जैसे उपयोगी सर्च के बाद एक संतुष्ट क्लिक या कार्य पूरा होना। गार्डरेल्स P95 लेटेंसी, जीरो-रिजल्ट रेट, एरर रेट, शिकायतों और व्यावसायिक नुकसान को कवर करते हैं। परिणाम देखने से पहले विस्तार, ठहराव और रोलबैक थ्रेशोल्ड लिखें ताकि शॉर्ट-टर्म क्लिक में वृद्धि लॉन्ग-टर्म या सिस्टम के नुकसान को छिपा न सके।
4. अपरिवर्तनीय (irreversible) जोखिम के लिए प्रोग्रेसिव रोलआउट का उपयोग करें
Microsoft डिप्लॉयमेंट को एक्सपोजर से अलग करने और टीम अकाउंट्स से चुनिंदा ग्राहकों और फिर व्यापक यूजर्स की ओर बढ़ने का वर्णन करता है। इंटरनल यूजर्स पहले शुद्धता को मान्य करते हैं; इसके बाद क्षेत्र या कोहोर्ट का विस्तार होता है। हर चरण पर मेट्रिक्स और लॉग्स की जांच करें। किल पाथ नए एल्गोरिदम से स्वतंत्र होना चाहिए ताकि रोलबैक नियंत्रण विफल हो रहे कोड पाथ पर निर्भर न हो।
5. संदूषण रोकें और वैरिएंट्स का ऑडिट करें
यूजर, वैरिएंट, टाइमस्टैम्प, वर्जन, एक्सपोजर इवेंट और आउटकम इवेंट को लॉग करें। Google Cloud एक साधारण बूलियन के बजाय विवरणात्मक वैरिएंट नामों की सिफारिश करता है। यदि कोई यूजर अलग-अलग डिवाइसेज पर अलग-अलग बंट जाता है या समूह आपस में हस्तक्षेप करते हैं, तो संदूषण को चिह्नित करें और परिणामों की व्याख्या करना बंद कर दें। विश्लेषण को प्रत्येक परिणाम को उस समय सक्रिय फ्लैग नियमों से जोड़ना चाहिए।
6. प्रयोग समाप्त करें और फ्लैग का प्रबंधन (govern) करें
Optimizely प्रयोगों को लक्षित डिलीवरी (targeted delivery) से अलग करता है: प्रयोग यह उत्तर देते हैं कि कौन सा विकल्प बेहतर है, फिर जीतने वाले विकल्प को एक फ्लैग के साथ रोल आउट किया जाता है। Atlassian और Microsoft दोनों ब्रांच, समन्वय और मेंटेनेंस डेट (ऋण) से बचने के लिए पूर्ण रोलआउट के बाद फ्लैग्स को हटाने पर जोर देते हैं। फ्लैग बनाए जाने पर एक ओनर, समाप्ति तिथि, डिफॉल्ट और डिलीशन टास्क रजिस्टर करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं सबसे पहले पूछूंगा कि क्या टीम को सीखने की जरूरत है या जोखिम नियंत्रण की। रैंकिंग वैल्यू अज्ञात है, इसलिए मैं यूजर-लेवल स्टेबल A/B एक्सपेरिमेंट से शुरुआत करूंगा, जिसे एक छोटे प्रोग्रेसिव एक्सपोजर गेट में लपेटा जाएगा जिसे गार्डरेल का उल्लंघन होने पर बंद किया जा सकता है। प्राइमरी मेट्रिक एक उपयोगी सर्च के बाद संतुष्ट क्लिक्स होंगे; गार्डरेल्स में P95 लेटेंसी, जीरो-रिजल्ट रेट, एरर्स और शिकायतें शामिल होंगी।
मैं वैरिएंट आईडी, एक्सपोजर और परिणाम को लॉग करूंगा, कभी भी प्रति रिक्वेस्ट रैंडमाइज नहीं करूंगा, और केवल क्लिक्स को देखने से बचूंगा। मैं इंटरनल अकाउंट्स और एक छोटे ग्राहक कोहोर्ट से शुरुआत करूंगा, लॉगिंग, कैश व्यवहार और क्रॉस-डिवाइस आवंटन को सत्यापित करूंगा, फिर स्पष्ट थ्रेशोल्ड पर विस्तार करूंगा। एक बार निर्णय हो जाने के बाद, मैं विजेता को डिफॉल्ट बना दूंगा और एक्सपेरिमेंट ब्रांच, ओनर रिकॉर्ड और फ्लैग को हटा दूंगा। यदि गार्डरेल्स बिगड़ते हैं, तो मैं रोकूंगा, बेसलाइन को रिस्टोर करूंगा और जांच करूंगा। यह सीखने, सुरक्षा और लाइफसाइकिल ओनरशिप को कवर करता है।
सामान्य गलतियां
- गलती → फीचर फ्लैग को A/B टेस्ट कहना। यह क्यों विफल होता है: एक फ्लैग एक्सपोजर को नियंत्रित करता है लेकिन स्वचालित रूप से एक तुलनीय माप नहीं बनाता है। सुधार: समूह, मेट्रिक्स, एक्सपोजर लॉगिंग और विश्लेषण निर्दिष्ट करें।
- गलती → हर रिक्वेस्ट को रैंडमाइज करना। यह क्यों विफल होता है: एक यूजर अनुभवों के बीच झूलता रहता है और कैश तथा व्यवहार को दूषित करता है। सुधार: एक स्थिर इकाई चुनें और स्टिकी बकेटिंग का उपयोग करें।
- गलती → केवल ग्रोथ मेट्रिक को परिभाषित करना। यह क्यों विफल होता है: लेटेंसी, एरर्स या शिकायतों के बिगड़ने पर भी क्लिक बढ़ सकते हैं। सुधार: नॉर्थ-स्टार मेट्रिक को सिस्टम और अनुभव गार्डरेल्स के साथ जोड़ें।
- गलती → पूर्ण रोलआउट के बाद फ्लैग को बनाए रखना। यह क्यों विफल होता है: ब्रांचेस और नियम जमा हो जाते हैं, जिससे भविष्य के व्यवहार को समझना कठिन हो जाता है। सुधार: फ्लैग के साथ एक ओनर, समाप्ति तिथि और रिमूवल टास्क बनाएं।
फॉलो-अप प्रश्न और उत्तर
प्रयोग से क्लिक्स बढ़ते हैं लेकिन लेटेंसी भी बढ़ती है। कौन सा परिणाम जीतता है?
पहले से निर्धारित गार्डरेल थ्रेशोल्ड की पहले जांच करें। यदि इसका उल्लंघन होता है, तो विस्तार को रोकें और बेसलाइन को रिस्टोर करें; फिर यूजर वैल्यू को विभाजित (segment) करके यह तय करें कि एल्गोरिदम को ऑप्टिमाइज़ करना है या टेस्ट को केवल लेटेंसी-सहनशील संदर्भों के लिए रखना है। क्लिक्स में वृद्धि सिस्टम की गिरावट को ओवरराइड नहीं करती है।
एक ही यूजर को वेब और मोबाइल पर अलग-अलग वैरिएंट्स मिलते हैं। आप क्या करेंगे?
प्रयोग की इकाई को परिभाषित करें। यदि क्रॉस-डिवाइस निरंतरता मायने रखती है, तो अकाउंट-लेवल की और एक ही एलोकेशन सर्विस का उपयोग करें। यदि इसे एकीकृत नहीं किया जा सकता है, तो क्रॉस-डिवाइस इंटरैक्शन को प्रयोग के प्रभाव के रूप में मानने के बजाय निष्कर्ष को केवल एक प्लेटफॉर्म तक सीमित करें।
A/B टेस्ट कब करने लायक नहीं होता है?
इसे तब छोड़ दें जब शुद्धता (correctness) या अनुपालन (compliance) प्रमुख हो, सैंपल लक्षित अंतर का पता लगाने में असमर्थ हो, या कोई बाहरी बाधा पहले से ही लॉन्च का निर्धारण करती हो। जब निर्णय की अनिश्चितता कम हो तो गार्डरेल्स के साथ एक छोटा प्रोग्रेसिव रोलआउट अधिक सस्ता होता है।
यदि फ्लैग सर्विस अनुपलब्ध हो तो क्या होना चाहिए?
प्रत्येक वैरिएंट के लिए एक सुरक्षित डिफॉल्ट परिभाषित करें, आमतौर पर सत्यापित बेसलाइन, और उचित होने पर अंतिम उपयोग योग्य कॉन्फ़िगरेशन को स्थानीय रूप से रखें। मूल्यांकन विफलताओं को रिकॉर्ड करें ताकि फ्लैग-सर्विस आउटेज कोर बिजनेस आउटेज न बन जाए।