ए/बी परीक्षण खत्म हो रहा है, और मैं इसके लिए यहां हूं। हस्तक्षेपों के एक छोटे समूह (कभी-कभी केवल एक हस्तक्षेप) का असतत, समयबद्ध मूल्यांकन स्थायी रूप से कार्रवाई योग्य परिणाम नहीं देता है। किसी भी वास्तविक दुनिया की व्यावसायिक स्थिति में, परीक्षण करने के लिए चीजों की संख्या बहुत तेजी से बढ़ जाती है - यदि आप ए / बी परीक्षण ढांचे का उपयोग कर रहे हैं। अभिभूत होना परीक्षण दृष्टिकोण की एक सीमा है, परीक्षण वातावरण की विशेषता नहीं है। ऐसी बहुत सी चीज़ें हैं जिनका आप संभावित रूप से परीक्षण कर सकते हैं। आपको सावधान रहना होगा कि अलग-अलग परीक्षण उन उपयोगकर्ताओं में ओवरलैप न हों जिनसे वे प्रभावित होते हैं। आपको उन दिनों और स्थानों से बचना होगा जिन्हें व्यवसाय किसी परीक्षण में शामिल करने के लिए तैयार नहीं है। यह ए/बी परीक्षण चलाने के लिए बहुत से संसाधनों का एकाधिकार करता है। एक परीक्षण चलाने में लंबा समय लग सकता है, और बहुत सारे परीक्षण चलाने में लंबा, लंबा समय लग सकता है। - यदि आप एक महीने के लिए A बनाम B चलाते हैं और पाते हैं कि A ने बहुत बेहतर प्रदर्शन किया है, तो इसका मतलब है कि आपने अपने आधे उपयोगकर्ताओं को पूरे महीने कम प्रदर्शन करने वाला वेरिएंट दिखाया। आपने वह सब मूल्य खो दिया। इससे कोई खुश नहीं है। एक परीक्षण संभावित रूप से हारने वाले वेरिएंट पर बहुत अधिक प्रभाव डालता है आपके द्वारा किए गए किसी भी विकल्प का प्रभाव दिन के समय, सप्ताह के दिन, महीने के समय, वर्ष के समय, विश्व की घटनाओं, बाजार में परिवर्तन से प्रभावित हो सकता है - सिर्फ इसलिए कि A उस महीने B से बेहतर था जिस महीने आपने इसका परीक्षण किया था, इसका मतलब यह नहीं है कि यह हमेशा बेहतर होगा। और कोई A/B परीक्षण आपको इसके परिणामों की शेल्फ-लाइफ नहीं बता सकता है। परीक्षण की दीर्घकालिक प्रभावशीलता कभी भी निश्चित नहीं होती है। यदि आप ए/बी परीक्षण के साथ समस्याओं की थोड़ी अधिक गहन चर्चा चाहते हैं, तो [बबेल](https://अनुकूली नियंत्रण समूह का उपयोग करके एक ही समय में कई प्रयोग चलाएं) पर लोगों की एक अच्छी प्रस्तुति है विषय, और दस्यु फ़ीडबैक पर कई उद्योग जगत के नेताओं का एक अच्छा दृष्टिकोण है। यह ट्यूटोरियल https://www.youtube.com/watch?v=NevkPmpkEyw&embedable=true बहु-सशस्त्र डाकू भविष्य हैं, और भविष्य अब है, और अब हमारे पास नई समस्याएं हैं। पारंपरिक A/B टेस्टिंग सेटिंग में, आपके पास वैरिएंट A होता है और आपके पास वैरिएंट B होता है। वास्तविक दुनिया की अधिकांश स्थितियों में, या तो A या B केवल सांख्यिकीय अर्थ में "बेहतर" होता है। यदि आप एक परीक्षण चलाते हैं और A को 20% सफलता दर मिलती है और B को 10% सफलता दर मिलती है, तो A स्पष्ट रूप से "जीतता है" ... लेकिन उन लोगों के बारे में क्या जिन्होंने B को जवाब दिया? क्या वे ए प्राप्त करने के साथ ठीक होने जा रहे हैं? ए/बी परीक्षण और बैंडिट एल्गोरिदम दोनों ही आपको बहुमत के लिए अपनी अल्पसंख्यक प्राथमिकताओं का त्याग करने के लिए मजबूर करते हैं। यह उस तरह से होना नहीं है - बस यही तरीका है कि वे विशेष उपकरण काम करते हैं। एक बेहतर रणनीति उन लोगों को विकल्प A प्राप्त करना है जो विकल्प A को पसंद करते हैं, और विकल्प B उन लोगों को प्राप्त करना है जो विकल्प B का जवाब देते हैं। इसलिए: जरूरी 100 लोगों को विकल्प A और 100 लोगों को विकल्प B भेजें। विकल्प A की 20% सफलता दर का मतलब है कि आपको 20 सफलताएँ मिलीं। विकल्प B की 10% सफलता दर का मतलब है कि आपको 10 सफलताएँ मिलीं। आइए उदार बनें और मान लें कि विकल्प बी पर प्रतिक्रिया देने वाले आधे लोगों ने वास्तव में विकल्प ए को जवाब दिया होता अगर वे इसके बजाय इसे देखते। इसका मत: परीक्षण पूरा होने के बाद केवल विकल्प ए दिखाने से 12.5% सफलता दर प्राप्त होती है (20 जिन्होंने ए को जवाब दिया, साथ ही 5 जिन्होंने बी को जवाब दिया लेकिन ए को जवाब दिया होगा, दोनों समूहों में 200 कुल लोगों द्वारा विभाजित)। विकल्प A को उन लोगों को भेजना जो A को चाहते हैं और B को चाहते हैं उन्हें B को भेजने से 15% सफलता दर प्राप्त होती है। इसलिए परिणामों के आधार पर आप प्रत्येक उपचार को कैसे लागू करते हैं, इसे समायोजित करके, आप टेबल पर कम मूल्य छोड़ते हैं। बैंडिट एल्गोरिथम इतना ही करता है — यह दांव को हेज करता है: B, A की तुलना में आधा सफल है, इसलिए आप वास्तव में B को आधा समय दिखाते हैं। आप इसे एक ही समय में कई अलग-अलग विकल्पों के साथ कर सकते हैं (सिर्फ ए और बी नहीं), स्वत: परिनियोजन और पुन: समायोजन परीक्षण चलाने के लिए कम खर्चीला बनाता है, आप वेरिएंट खोने के लिए ज्यादा मूल्य का त्याग नहीं करते हैं, और सिस्टम कर सकता है उपयोगकर्ता प्राथमिकताओं या बड़े निर्णय परिवेश में परिवर्तन के लिए समायोजित करें। ए/बी परीक्षण की सभी समस्याएं हल हो गईं! लेकिन यह उल्टा पड़ सकता है। आप कितनी बार A को पसंद करने वाले लोगों को B दिखाएंगे, या B को पसंद करने वाले लोगों को A दिखाएंगे, क्योंकि आप अपना निर्णय व्यक्तिगत प्राथमिकताओं के बजाय कुल आंकड़ों पर आधारित कर रहे हैं? इस प्रकार की परिस्थितियों में बैंडिट एल्गोरिद्म का A/B परीक्षण से भी खराब प्रदर्शन करना वास्तव में संभव है। और, बेशक, ये सभी चीजें समय के साथ बदल सकती हैं। हो सकता है कि B को पसंद करने वाले लोगों में से आधे वास्तव में समय के साथ A को पसंद करने लगे। , बिल्कुल वैसा ही रहेगा। वह इष्टतम नहीं है। नियमित बैंडिट छिपी हुई लागतें होती हैं — या, बल्कि, वे A/B परीक्षणों की लागत लेते हैं और इसे अलग-अलग स्थानों पर घुमाते हैं ताकि आप इसे आसानी से नोटिस न कर सकें। आप अपना एल्गोरिथ्म सेट करते हैं और भेजना शुरू करते हैं और सब कुछ बहुत अच्छा लगता है... जब तक कि आप उन कुछ मुद्दों को महसूस करना शुरू नहीं कर देते जिनका मैंने पिछले पैराग्राफ में उल्लेख किया था। हो सकता है कि ए बनाम बी के लिए वरीयताओं का संतुलन, नए उपयोगकर्ताओं के लिए भिन्न हो, जितना कि लौटने वाले उपयोगकर्ताओं के लिए। हो सकता है कि वे प्राथमिकताएँ अलग-अलग भौगोलिक क्षेत्रों के लिए अलग-अलग हों। शायद अनुभवी उपयोगकर्ताओं को भी उन लोगों में विभाजित किया जा सकता है जो पावर उपयोगकर्ता हैं और जो नियमित हैं। यही कारण है कि लोगों ने आविष्कार किया है, जो वास्तव में बैंडिट्स प्लस सेगमेंटेशन के लिए एक फैंसी शब्द है। एल्गोरिदम में प्रासंगिक बैंडिट्स का अब आपको यह समझने के लिए बहुत अधिक रिपोर्टिंग करनी होगी कि आपके उपयोगकर्ता आधार के कौन से सेगमेंट में अलग-अलग वरीयताएँ प्रोफ़ाइल हो सकती हैं। इसलिए आपने प्रयोगों का विश्लेषण करने के लिए आवश्यक रिपोर्टिंग कम कर दी, लेकिन आपने अपने बैंडिट का दायरा बढ़ाने के लिए आवश्यक रिपोर्टिंग बढ़ा दी। और आपने उस रिपोर्टिंग को वास्तविक दायरे में बदलने के लिए आवश्यक कार्य की मात्रा बढ़ा दी है। और एक बार जब आपके पास ये अलग-अलग सेगमेंट हो जाते हैं, तो आप महसूस करते हैं कि उस संदर्भ को ध्यान में रखने के लिए शायद आपको अधिक क्रिएटिव की आवश्यकता है, इसलिए यह अधिक काम है। और फिर पाइपलाइन बनाने के लिए इंजीनियरिंग का काम है जो सही उपयोगकर्ता को सही बैंडिट में ले जाएगा। और यह सुनिश्चित करने के लिए आपको अपने मैसेजिंग सिस्टम में काम करने की ज़रूरत है कि यह पृष्ठभूमि में चल रही इन सभी चीजों का समर्थन करता है। तो डाकुओं ने ए/बी परीक्षण की बहुत सारी समस्याओं का समाधान किया है, लेकिन जो डाकू वास्तव में प्रभावी हैं वे नई विश्लेषणात्मक ज़रूरतें और नई तार्किक बाधाएँ पैदा करते हैं जिन्हें हल करना आसान नहीं है। ए/बी परीक्षण अभी भी इतना लोकप्रिय होने के कारणों में से एक है: प्रक्रिया इतनी आम है कि भारी भारोत्तोलन में मदद के लिए बहुत सारे उपकरण हैं। गतिशील परीक्षण के लिए गतिशील मूल्यांकन की आवश्यकता होती है, जिसके लिए गतिशील नियंत्रण समूह की आवश्यकता होती है। इसलिए मैंने एक ऐसे उत्पाद के डिजाइन और निर्माण में मदद की जो जटिल प्रासंगिक दस्यु परीक्षण को आसान बनाता है — इतना आसान कि यह आपकी साइट या ऐप पर प्रत्येक व्यक्तिगत उपयोगकर्ता के लिए एक अलग संदर्भ बनाता है। आप उस उत्पाद के बारे में अधिक विवरण प्राप्त कर सकते हैं, यह वास्तव में इस पोस्ट का सार नहीं है, इसलिए मैं इसके बारे में और बात नहीं करूंगा। मैं यहां किस बारे में बात करना चाहता हूं कि हमने प्रति दिन सैकड़ों हजारों व्यक्तिगत अनुकूली परीक्षणों के मूल्यांकन की समस्या को कैसे हल किया। यहां विवरण में पाया जा सकता है। arXiv पर हमारे पेपर मैंने प्रयोगों का मूल्यांकन करने के लिए होल्डआउट समूह के निर्माण में निहित व्यावहारिक, विश्लेषणात्मक और कभी-कभी नैतिक चुनौतियों के बारे में । मैं अभी भी उस पर कायम हूं। हम का उपयोग करके अपने अनुकूली प्रयोगों का मूल्यांकन करते हैं, क्योंकि इसमें किसी भी उपयोगकर्ता को संभावित लाभकारी हस्तक्षेपों से वंचित करना शामिल नहीं है। हालाँकि, पारंपरिक सिंथेटिक नियंत्रण विधियाँ विश्लेषणात्मक नुकसान से भरी हो सकती हैं, क्योंकि आप अनिवार्य रूप से उस वातावरण के लिए आधारभूत डेटा-जनरेटिंग प्रक्रिया का मॉडल कर रहे हैं जिसमें आप अपना प्रयोग कर रहे हैं। बहुत सारे और बहुत सारे समानांतर प्रयोग करें, जिनमें से कई अतिव्यापी वातावरण में होते हैं, और नियंत्रण समस्या का एक विश्लेषणात्मक समाधान ... कठिन हो जाता है। पहले भी लिखा है सिंथेटिक नियंत्रण इसलिए हम उस रास्ते पर नहीं गए। कई साल पहले हार्वर्ड में गैरी किंग और उनके सहयोगियों ने अवलोकन डेटा से कारण निष्कर्ष निकालने के लिए एक अद्भुत सरल विधि का आविष्कार किया था। इसे मोटे तौर पर सटीक मिलान (सीईएम) कहा जाता है। आप सेमिनल पेपर और सैद्धांतिक आधार पा सकते हैं। यहां यहां विचार सरल है: हो रहे आपके हस्तक्षेप (परीक्षण) के बारे में अपनी सभी टिप्पणियों को एकत्रित करें। उन प्रेक्षणों का एक समूह एकत्र करें जहाँ हस्तक्षेप नहीं हुआ था लेकिन हो सकता था। ऐसी विशेषताएँ चुनें जो दो समूहों से किसी विशेष जोड़ी के अवलोकन के बीच समानता को माप सकें। श्रेणीबद्ध चर में "मोटे" गुण। इसलिए यदि "आयु" एक विशेषता है, तो आप इसे आयु श्रेणियों में बाइंड कर सकते हैं। मोटे गुणों के सटीक मिलान के आधार पर प्रत्येक हस्तक्षेप अवलोकन को गैर-हस्तक्षेप अवलोकन से मेल करें। इसका मतलब है कि आप गैर-हस्तक्षेप टिप्पणियों का केवल एक सबसेट चुनेंगे, और अक्सर आप अपनी कुछ हस्तक्षेप टिप्पणियों को भी छोड़ देंगे, लेकिन आपके पास जो बचा है उसका मिलान किया जाएगा। दो परिष्कृत समूहों के बीच अंतर को मॉडल करें। CEM कारण अनुमान की जटिलता को विश्लेषणात्मक तरीकों से दूर ले जाता है - आप जो भी तरीका पसंद करते हैं उसका उपयोग कर सकते हैं - और इसके बजाय इसे डेटासेट निर्माण विधियों में रख सकते हैं। यह एक वर्गीकरण समस्या में असंतुलन डेटासेट के ओवर- या अंडर-सैंपलिंग के समान, वैचारिक रूप से समान है। हमने महसूस किया कि हम अपने बैंडिट प्रयोगों के लिए उपयुक्त नियंत्रण संदर्भों को खोजने के लिए इसी तरह के तर्क का उपयोग कर सकते हैं, जिसमें मिलान करने के लिए सुविधाओं में से एक के रूप में समय शामिल है। हम पहले से ही कुछ हस्तक्षेप विशेषताओं पर मेल खाते हैं - एक उपयोगकर्ता द्वारा प्राप्त हस्तक्षेप का प्रकार और हस्तक्षेप के समय उपयोगकर्ता द्वारा ऐप पर प्रदर्शित गतिविधि का स्तर। लेकिन फिर हम एक अवलोकन विंडो को भी परिभाषित करते हैं और यह सुनिश्चित करते हैं कि किसी भी मिलान किए गए उपयोगकर्ता को उस हस्तक्षेप के करीब समय अवधि में हस्तक्षेप प्राप्त होगा जिसके लिए हम नियंत्रण की मांग कर रहे हैं, लेकिन हस्तक्षेप की अवलोकन अवधि के भीतर नहीं। यह हमारे द्वारा चलाए जाने वाले अधिकांश परीक्षणों के लिए उपयोगकर्ता स्तर पर नियंत्रणों का मिलान करने की अनुमति देता है। बैंडिट एल्गोरिदम बड़े पैमाने पर A/B परीक्षण की कुछ जटिलताओं से छुटकारा पा लेते हैं, लेकिन उस जटिलता के अन्य भागों को छिपा देते हैं। हमारी नियंत्रण विधि उस छिपी हुई जटिलता को लेती है और उसका समाधान करती है ताकि हम बैंडिट असाइनमेंट के अनुकूली लाभ प्राप्त कर सकें, लेकिन A/B परीक्षण के स्पष्ट अनुमान और आरोपण। तो यहाँ आपकी टू-डू सूची है: आपके द्वारा किए जाने वाले हर हस्तक्षेप के लिए, एक आगे-पीछे और एक पीछे की ओर देखने वाली खिड़की की पहचान करें। लुक-फॉरवर्ड विंडो वह है जिसका उपयोग आप यह देखने के लिए करते हैं कि उपयोगकर्ता ने हस्तक्षेप पर कैसे प्रतिक्रिया दी, और लुक-बैक विंडो वह है जहां आप नियंत्रण मामलों की तलाश करते हैं। प्रत्येक हस्तक्षेप के लिए, अन्य हस्तक्षेपों के एक पूल की पहचान करें जो (1) लुक-बैक विंडो के भीतर हुआ, और (2) आगे-देखने वाली विंडो नहीं है जो आगे-देखने वाली विंडो को ओवरलैप करती है, जिसके लिए आप हस्तक्षेप की तलाश कर रहे हैं एक नियंत्रण। उन उपयोगकर्ताओं से मिलान करें, जिन्होंने उन संभावित नियंत्रण हस्तक्षेपों को प्राप्त किया, जिनके लिए आप हस्तक्षेप प्राप्त कर रहे हैं, जिसके लिए आप नियंत्रण की मांग कर रहे हैं। आप अपनी इच्छानुसार किसी भी मापदंड पर मेल कर सकते हैं - गतिविधि का स्तर, प्राप्त हस्तक्षेप की समानता, आदि। यादृच्छिक रूप से उनमें से एक उपयोगकर्ता का चयन करें जो इसे मिलान प्रक्रिया के माध्यम से बनाते हैं। बहाना करें कि आपने मूल हस्तक्षेप न केवल उस उपयोगकर्ता को भेजा है जिसने वास्तव में इसे प्राप्त किया है, बल्कि उस उपयोगकर्ता को भी भेजा है जिसे आपने नियंत्रण के रूप में चुना है। अपनी रुचि के किसी भी समय अवधि के लिए अपने परीक्षण और नियंत्रण उपयोगकर्ताओं के बीच प्रतिक्रिया में अंतर को मापें। दोबारा, आप पेपर में पर अधिक जानकारी प्राप्त कर सकते हैं। arXiv
