Hugo: Ben, DataFramed में आपका स्वागत है।
Ben: धन्यवाद, Hugo, यहाँ आना बहुत अच्छा लग रहा है और मैं आज Convoy और डेटा साइंस पर आपसे बात करने के लिए उत्सुक हूँ।
Hugo: मैं इससे अधिक सहमत नहीं हो सकता। आपका यहाँ होना शानदार है, और DataFramed पर डेटा साइंस क्या है और क्या हो सकती है, इस पर हमारी चल रही पड़ताल में, मैं आज आपसे Convoy में आपके काम और ट्रकिंग उद्योग में क्रांति लाने में डेटा साइंस की भूमिका पर बातचीत करने के लिए बेहद उत्साहित हूँ—जो उत्तर अमेरिका के सबसे प्रभावशाली उद्योगों में से एक है। लेकिन पहले, मैं आपके बारे में बात करना चाहता हूँ।
Ben: ठीक है, धन्यवाद।
डेटा साइंटिस्ट क्या होता है?
Hugo: लोग मुझसे हमेशा पूछते हैं, डेटा साइंटिस्ट असल में करते क्या हैं? Ben, आपके सहयोगी क्या सोचते हैं कि आप क्या करते हैं?
Ben: यह बहुत अच्छा प्रश्न है। मुझे लगता है कि "डेटा साइंटिस्ट" शब्द बहुत धुंधला है। अलग-अलग लोगों के लिए इसका अलग अर्थ होता है। मैं प्राकृतिक विज्ञान और सामाजिक विज्ञान, दोनों पृष्ठभूमियों से डेटा साइंस में आया हूँ। पीएचडी (इकॉनॉमिक्स) से पहले मैंने सिलिकॉन वैली का एक चक्कर भी लगाया। तो मेरे लिए, मैं अपना आधा दिन बैठकों में बिताता हूँ—यह चर्चा करते हुए कि हमारा प्लेटफ़ॉर्म कैसे चलाया जाए, या यहाँ डेटा साइंस के प्रति हमारा दृष्टिकोण कैसे विकसित हो रहा है, या विशिष्ट प्रश्नों पर, जैसे, प्रायोगिक डिज़ाइन। मैं लगभग आधा समय अन्य डेटा साइंटिस्ट्स को मेंटर करता हूँ—जैसे किसी जूनियर डेटा साइंटिस्ट की किसी कैंपेन के लिए प्रायोगिक डिज़ाइन पर मदद करना, या मान लीजिए, ग्राहक रिटेंशन समझने के लिए एक सरवाइवल मॉडल बनवाना।
फिर मैं अपना एक और आधा समय इंडिविजुअल कॉन्ट्रिब्यूटर के रूप में बिताता हूँ—उन पहलुओं पर सोचते हुए जो हमारे प्लेटफ़ॉर्म को चलाते हैं और उस चीज़ को ठीक कर के प्रभाव डालने की कोशिश करता हूँ जो अभी "आग पर" है। जैसे नीलामी, मैचिंग, प्राइसिंग और इस तरह के मुद्दों पर सोचना। जो भी गणित कर सकता है, वह नोटिस करेगा कि यह तीन आधों के बराबर हो गया, लेकिन मैं एक स्टार्टअप में काम करता हूँ, तो चीज़ें एक में नहीं जुड़तीं।
Hugo: मैं इससे अधिक सहमत नहीं हो सकता। DataCamp में तो कभी-कभी मुझे लगता है कि मैं वास्तव में एक अनंत सम के रूप में काम कर रहा हूँ। और क्योंकि आपकी पृष्ठभूमि भौतिकी में है, आपने मुझे बताया था कि भौतिकविदों के लिए केवल तीन ही संख्याएँ होती हैं, है न?
Ben: हाँ। ज़ीरो, वन और इन्फिनिटी—बाकी सब स्केलिंग का मामला है। पुराना मज़ाक है।
Ben का डेटा साइंस में करियर
Hugo: बिल्कुल। तो आप डेटा साइंस में कैसे आए?
Ben: यह बहुत अच्छा प्रश्न है, और मुझे लगता है कि मैं हमेशा से सॉफ्टवेयर, डेटा, गणित, सांख्यिकी और मॉडलों के साथ काम करता रहा हूँ, और जब DJ Patil ने यह शब्द गढ़ा और यह वायरल हो गया, तब मार्केटिंग विभाग में किसी ने मेरा रीब्रांडिंग कर के मुझे डेटा साइंटिस्ट कह दिया। लेकिन जब मैं कॉलेज में स्नातक था, तब भी मैं वैज्ञानिक प्रश्नों को समझने के लिए सॉफ्टवेयर लिख रहा था। तो सबसे पहली डेटा-साइंसनुमा चीज़ जो मैंने की, वह थी क्रेटर रीलैक्सेशन को समझने के लिए एक प्रोग्राम लिखना—McKinnon के लिए, जो Washington University में एक अद्भुत प्लानेटरी वैज्ञानिक हैं—और वहाँ Frankie बैंड बहुत बड़ा था, और चूँकि हम क्रेटर रीलैक्सेशन से डील कर रहे थे, मैंने अपने प्रोग्राम का नाम Frankie रखा। फिर हाल ही में, पीएचडी के बाद, मैं University of Chicago में था और Amazon में काम करने के लिए रिक्रूट हुआ। यह लगभग 2012 की बात है। तो तब मैं कहूँगा कि मैंने सचमुच अकादमिक से चीज़ें लेकर उद्योग में लागू करने की ओर संक्रमण किया।
Hugo: तो अब आप Convoy में डेटा साइंटिस्ट के रूप में काम कर रहे हैं?
Ben: जी।
Convoy
Hugo: ज़रा बताइए कि Convoy क्या करता है, इसका मिशन क्या है?
Ben: यह एक बहुत अच्छा उदाहरण है कि सॉफ्टवेयर का किसी स्थापित उद्योग में प्रवेश करना, उस स्थापित उद्योग के लिए खुद सॉफ्टवेयर लाना शुरू करने से कहीं आसान क्यों होता है। फ्रेट उद्योग लंबे समय से मौजूद है। अमेरिका में यह बहुत बड़ा बाज़ार है—लगभग 800 बिलियन डॉलर का। एक समस्या है कि ज़्यादातर शिपर्स भारी रूप से खंडित हैं—जैसे 95वें परसेंटाइल... माफ कीजिए, कैरियर्स। और कैरियर्स ट्रकिंग कंपनियाँ होती हैं, जिनके पास एक या अधिक ट्रक होते हैं। कैरियर्स बहुत खंडित हैं और 95वें परसेंटाइल वाला कैरियर लगभग दो या तीन ट्रक रखता है। तो शिपर्स उनके साथ ब्रोकर्स के माध्यम से जुड़ते हैं, और ब्रोकर्स 1980 के दशक की तकनीक का उपयोग करते हैं—फोन और फैक्स मशीनें। Convoy में हम एक नए दृष्टिकोण—डिजिटल फ्रेट—को आगे बढ़ा रहे हैं, जहाँ हम तकनीक, विशेष रूप से डेटा साइंस का उपयोग करके पूरी प्रक्रिया को सबके लिए बेहतर बना रहे हैं, क्योंकि सही कैरियर को सही शिपर के लोड से मिलाना बहुत महत्वपूर्ण है—तभी सबकुछ बेहतर तरीके से काम करता है। इसलिए हमें इसका दाम तय करना, मैच करना और पूरी प्रक्रिया को ऑटोमेट करना है—और यही उद्योग की कॉस्ट स्ट्रक्चर में क्रांति ले आएगा। आप सभी जो सुन रहे हैं—आप उपभोक्ता भी हैं—जो चीज़ें आप खरीदते हैं, उनमें से अधिकांश आपके पास पहुँचने से पहले आठ या दस ट्रक यात्राएँ करती हैं। तो अगर हम फ्रेट की लागत कम कर सकें, तो उम्मीद है कि आपकी खरीदी जाने वाली चीज़ों की कीमतें और अधिक प्रतिस्पर्धी हो जाएँगी।
Hugo: तो जमीन पर यह कैसा दिखता है—कैरियर्स यानी ड्राइवर्स के लिए?
Ben: कैरियर्स... यह परिभाषा थोड़ी जटिल है क्योंकि कई मालिक-ऑपरेटर होते हैं—एक तरह से अमेरिकन ड्रीम। उदाहरण के लिए, यहाँ पैसिफिक नॉर्थवेस्ट में, वे एक रूसी प्रवासी हो सकते हैं जो यहाँ कुछ भी लिए बिना आते हैं और फिर मालिक-ऑपरेटर बनने तक एक ट्रक से शुरुआत करते हुए ऊपर चढ़ते हैं, और जैसे-जैसे वे सफल होते हैं, वे अपना फ़्लीट बढ़ा सकते हैं—और यही वह चीज़ है जिसमें Convoy मालिक-ऑपरेटर्स की मदद करना चाहता है। या फिर यह एक अधिक स्थापित, मझोली ट्रकिंग कंपनी हो सकती है। आमतौर पर उनके पास एक या अधिक ट्रक होते हैं। किसी व्यक्ति के लिए लगभग 20 ट्रकों से अधिक स्केल करना कठिन होता है क्योंकि फिर लॉजिस्टिक्स जटिल हो जाती है और एचआर वगैरह से निपटना पड़ता है।
Hugo: बिलकुल। तो कैरियर्स के लिए ज़मीन पर Convoy कैसा दिखता है? क्या वे ऐप्स का उपयोग करते हैं या...
Ben: हाँ, यह बहुत अच्छा प्रश्न है। वे हमसे मुख्यतः Convoy ऐप के माध्यम से इंटरैक्ट करते हैं, और हमारे पास एक ऑनबोर्डिंग प्रक्रिया है जो उन्हें अपनी जानकारी का पैकेट देना बहुत आसान बना देती है—जैसे बीमा और लाइसेंसिंग संबंधी जानकारी—और फिर हम उनका अकाउंट सक्रिय कर सकते हैं। उस बिंदु पर, वे उन्हें ऐसे ऑफ़र्स दिखेंगे जो उस प्रकार के लोड के आधार पर सर्व किये जाते हैं, जिन्हें वे हमें बताते हैं कि उन्हें पसंद है। जैसे वे कह सकते हैं, "अरे, मैं I-5 कॉरिडोर पर काम करना पसंद करता हूँ," और फिर वे इन-ऐप उन लोड्स को स्वीकार कर सकते हैं और किसी इंसान से बात करने की ज़रूरत नहीं। यानी यह बहुत कुशल है।
वे लोड्स पर बोली भी लगा सकते हैं। तो अगर उन्हें हमारी कीमत पसंद नहीं आती, या वे किसी लोड के लिए अन्य कैरियर्स के साथ प्रतिस्पर्धा कर रहे हैं, तो वे बोली लगा सकते हैं; बाज़ार की स्थिति के अनुसार कीमत ऊपर-नीचे हो सकती है। और एक और चीज़ जो हम उनके लिए बढ़िया करते हैं, वह यह कि मान लीजिए वे San Francisco से Los Angeles तक एक लोड ले जाते हैं, तो अगर हम देखते हैं कि उन्होंने यह किया है तो हम कहते हैं, "अरे, हमारे पास Los Angeles से वापस वहाँ जाने या कहीं और जाने का लोड है।" यानी हम इसके प्रति जागरूक हैं, ताकि उन्हें लगातार चलते और कमाते रखें—ताकि वे कम बार खाली चलें, क्योंकि पता चलता है कि ट्रक लगभग 40% समय खाली चलते हैं—जो पर्यावरण और ट्रकर, दोनों के लिए बुरा है।
Hugo: हाँ, मैं कल्पना कर सकता हूँ कि आप तरह-तरह की ट्रैवलिंग सेल्समैन समस्याएँ सुलझाने की कोशिश कर रहे हैं—आप अनिवार्य रूप से यह नहीं चाहेंगे कि कोई ड्राइवर Seattle से Bay Area तक खाली ट्रक चलाए और फिर वहाँ से कहीं और चीज़ें ले जाए। आप चाहेंगे कि उनका सफ़र इस लिहाज़ से ऑप्टिमाइज़ हो कि वे कितना लेकर जा रहे हैं?
Ben: हाँ, बिल्कुल। जैसे-जैसे हमारे प्लेटफ़ॉर्म पर लिक्विडिटी बढ़ेगी, इन तरह की समस्याओं को सुलझाना और आसान होता जाएगा और कैरियर्स को लगभग निरंतर गति की अवस्था में रखना संभव होगा।
Hugo: यह वाकई शानदार है। मुझे यह इसलिए भी बहुत दिलचस्प लगता है क्योंकि जब हम आधुनिक उद्योग में डेटा साइंस की भूमिका के बारे में सोचते हैं, तो ज़्यादातर समय टेक के बारे में सोचते हैं—एक ऐसा उद्योग जो डेटा तक बढ़ती पहुँच के साथ पैदा हुआ था। जबकि आप ऐसे उद्योग में क्रांति लाने की बात कर रहे हैं जो इस पूरी तकनीकी अवसंरचना से पहले का है।
Ben: बिल्कुल। और अगर हम जो करने की कोशिश कर रहे हैं, उसमें सफल होते हैं, तो हम एक बड़े उद्योग की कॉस्ट स्ट्रक्चर बदल देंगे, जो बहुत से अमेरिकियों को प्रभावित करता है। Convoy में मैंने जो अद्भुत तथ्य सीखा, वह यह है कि लगभग 45 राज्यों में सबसे आम नौकरी ट्रक ड्राइवर की है। तो यह बहुत से लोगों को उनकी रोज़गार की दृष्टि से प्रभावित करता है, और साथ ही हर उपभोक्ता को भी। यह बहुत से लोगों के जीवन पर सकारात्मक प्रभाव डाल सकता है—खासकर ट्रक ड्राइवर्स के लिए—हम उनके लिए अपना व्यवसाय चलाना, उसे बढ़ाना और बहुत कम घर्षण के साथ उसे संचालित करना आसान बना रहे हैं।
Convoy में डेटा साइंस
Hugo: ज़रूर। तो Convoy के मिशन में डेटा साइंस अहम भूमिका कैसे निभाता है?
Ben: डेटा साइंस हमारे काम का केंद्र है। वास्तव में, जिस दिन से हमने शुरुआत की, हम ऑटोमेटेड रहे हैं। हमें अर्थशास्त्र से जुड़े ढेर सारे दिलचस्प समस्याओं को सुलझाना है—इसलिए कीमत का पूर्वानुमान लगाना बहुत महत्वपूर्ण है क्योंकि हमें शिपर्स के लिए सही प्राइस करना होता है—अक्सर हम उनसे दीर्घकालिक अनुबंध करते हैं—और हमें कैरियर्स के लिए भी सही प्राइस करना होता है। फिर हमें मैचिंग समस्या हल करनी होती है—सही कैरियर को सही लोड से मिलाना—क्योंकि इससे सभी के लिए बेहतर परिणाम मिलते हैं। उदाहरण के लिए, "सही" का मतलब हो सकता है कम डेडहेड स्पेस—यानी लोड शुरू होने की जगह तक खाली चलकर जाना—और डेस्टिनेशन एंडपॉइंट्स भी मायने रख सकते हैं। हम नीलामियों और स्वयं कैरियर्स के लिए प्राइस स्वीकृति तंत्र पर भी सोचते हैं, तथा कैरियर लाइफसाइकल से संबंधित कई अन्य चीज़ों पर भी—और यह सुनिश्चित करते हैं कि एक बार कैरियर ने लोड उठा लिया तो सब ठीक चल रहा है। इस तरह की समस्याएँ बहुतायत में हैं।
Hugo: मुझे लगता है कि यह एक ऐसा बिज़नेस है जहाँ आपको चिकन-एंड-एग समस्या का सामना करना पड़ सकता है—इस अर्थ में कि शिपर्स को साथ लाने के लिए आपको कैरियर्स चाहिए, और कैरियर्स को साथ लाने के लिए शिपर्स।
Ben: हाँ, यह किसी भी प्लेटफ़ॉर्म के लिए बहुत कठिन होता है। हमारे सीरीज़ A राउंड के एक निवेशक Simon Rothman की एक बढ़िया पोस्ट है—उन्होंने लिखा कि आपको एक ही समय में दो कंपनियाँ शुरू करनी पड़ती हैं। यानी आपको सप्लाई और डिमांड—दोनों तरफ़—एक साथ बूटस्ट्रैप करना होता है, और इसे बैलेंस में रखना बहुत मुश्किल होता है।
तो, सौभाग्य से, हमारे पास एक अद्भुत सेल्स टीम है—वे क्वालिटी डिमांड उत्पन्न करने में बहुत अच्छी हैं—और फिर हम जल्दी से सप्लाई बनाते हैं ताकि सबकुछ संतुलन में रहे, और यह ऐसी चीज़ है जिसे हम ट्रैक करते हैं। कोई भी प्लेटफ़ॉर्म इसको लेकर चिंतित रहता है—वे लिक्विडिटी और संतुलन बनाए रखने के बारे में बहुत सोचते हैं। जैसे—अगर आप डेटिंग साइट पर जाएँ और मान लें कि आप हेटेरोसेक्शुअल हैं—और वहाँ महिलाएँ नहीं हैं—तो यह एक खराब डेटिंग अनुभव होगा। इसलिए आपको पुरुषों और महिलाओं की संख्या में संतुलन चाहिए।
Hugo: यह मेरे दिमाग में इसलिए भी है क्योंकि DataCamp में शुरुआती दिनों में हमें भी ऐसी ही चुनौती का सामना करना पड़ा—छात्रों को लाना और साथ ही इंस्ट्रक्टर्स को भी—क्योंकि इंस्ट्रक्टर्स को ऑडियंस चाहिए और छात्रों को बेहतरीन इंस्ट्रक्टर्स, है न?
Ben: हाँ, बिल्कुल। और एक और बात यह है कि नेटवर्क इफ़ेक्ट्स भी होते हैं। तो एक बार जब यह चल पड़ता है, तो ये बिज़नेस एक्सपोनेंशियली बढ़ने लगते हैं—यह बहुत रोमांचक है। इसका मतलब है कि अगर आप यह सही तरीके से करते हैं, तो आप पाएँगे कि आप सो नहीं रहे।
Hugo: बिल्कुल। आपने कहा कि सबसे महत्वपूर्ण चीज़ों में से एक बहुत मजबूत सेल्स टीम है। उदाहरण के लिए, सेल्स टीम के संदर्भ में—डेटा साइंस टीम कंपनी में कैसे इंटीग्रेटेड है?
Ben: हाँ। मेरा मानना है कि हम उनके साथ सबसे बड़ी मदद प्राइसिंग समझने में कर सकते हैं—जैसे किस तरह लोड्स पर बोली लगानी है, किन लोड्स पर बोली लगानी चाहिए—और इस तरह हम उनके साथ बहुत नज़दीकी से काम करते हैं। प्राइसिंग अत्यंत जटिल चीज़ है और इसके आसपास तरह-तरह के इंसेंटिव्स होते हैं—इसे खोलने में घंटे लग जाएँगे।
Hugo: हम डेटा साइंस की भूमिका के इर्द-गिर्द बात कर रहे हैं। ऐसे कौन से विशिष्ट डेटा साइंस प्रश्न हैं जिनका उत्तर आपको अपनी नौकरी में देना पड़ता है?
Ben: Convoy की संस्कृति की एक अच्छी बात यह है कि हम बहुत डेटा-ड्रिवन हैं—और हम बहुत सारे प्रयोग करते हैं—जैसे कि मैं मानता हूँ उद्योग में हर कोई—या कम से कम शीर्ष खिलाड़ी। तो हम अक्सर प्रश्नों का उत्तर प्रयोगों के माध्यम से देते हैं—और यही एकमात्र तरीका है। इसलिए हम बहुत प्रयोग करते हैं। हमने बहुत अच्छे प्रयोग ढाँचे (एक्सपेरिमेंटेशन फ़्रेमवर्क) के निर्माण में निवेश किया है जिससे हम तेज़ी से प्रयोग दोहरा सकें। A/B टेस्ट चलाने के अलग-अलग तरीके हैं—जैसे Bayesian या frequentist—और Bayesian या सीक्वेंशियल विश्लेषण आपको अधिक तेज़ी से उत्तर दे देता है। यह प्रोडक्ट मैनेजर्स के साथ परिणामों पर चर्चा करना भी आसान बनाता है।
A/B परीक्षण
Hugo: थोड़ा पीछे चलते हैं—क्या आप किसी A/B टेस्ट का उदाहरण दे सकते हैं जो आप करते हैं?
Ben: बढ़िया। जिस तरह की चीज़ों का आप आमतौर पर A/B टेस्ट करेंगे, वह यह है कि क्या कोई नया UX फ्लो बेहतर काम करता है? तो मान लीजिए... हम जिन चीज़ों की परवाह करते हैं उनमें से एक है कि जब कोई ड्राइवर ट्रिप पूरी करता है तो वे अपने काग़ज़ात अपने-आप अपलोड कर दें—इसे BOL, bill of lading कहते हैं। अगर हम इसे बेहतर और आसान बनाने के लिए कोई नई प्रक्रिया रोलआउट करते हैं, तो हम एक प्रयोग चला सकते हैं—जिसमें आधे कैरियर्स को पुरानी तकनीक पर रखें और आधे को नई तकनीक पर—और फिर कुछ समय बाद हम किसी संभावना के साथ कह सकते हैं कि नई प्रक्रिया बेहतर काम करती है या नहीं।
Hugo: यह A/B टेस्टिंग का बढ़िया उदाहरण और वर्णन है। मैं थोड़ा और पूछूँगा—आपने कहा Bayesian तरीकों से frequentist तरीकों की तुलना में परिणाम जल्दी मिलते हैं। मैं आपको ऑन-द-स्पॉट रख रहा हूँ, लेकिन क्या आप आम लोगों के लिए संक्षेप में बता सकते हैं—frequentist सांख्यिकी, जिससे लोग अधिक परिचित हो सकते हैं, और यहाँ जिन Bayesian तरीकों की आप बात कर रहे हैं—उनमें अंतर क्या है?
Ben: अवश्य। सांख्यिकी के लिए पहला वास्तविक दृष्टिकोण Bayesian पद्धति था—जिसे Thomas Bayes ने विकसित किया था—वे दरअसल एक विकर थे। उनका विचार बहुत हद तक आपकी अंतर्ज्ञान की तरह काम करता है—आप किसी चीज़ के बारे में पूर्व मान्यताओं से शुरू करते हैं—जैसे मेरी नई प्रक्रिया बेहतर है—मान लीजिए इससे 10% लिफ्ट होगी। फिर समय के साथ जैसे-जैसे आप डेटा देखते हैं, आप उन मान्यताओं को अपडेट करते हैं। यह Bayesian अपडेटिंग अंततः जिसे हम posterior कहते हैं, पर अभिसरित हो जाती है—और वह वह वितरण है जिसकी हम उम्मीद करते हैं कि लिफ्ट होगी।
Frequentist दृष्टिकोण... Frequentist पर जाने से पहले—Bayesian तरीकों की गणना करना दो दशक पहले तक बहुत कठिन था। हमारे पास कम्प्यूटेशनल संसाधन पर्याप्त नहीं थे। तब से बहुत बड़े सुधार हुए हैं और इन मॉडलों की गणना करना आसान हो गया है। उससे पहले आप केवल विशेष मामलों को हल कर पाते थे। इसलिए R.A. Fisher जैसे लोग Bayesian दृष्टिकोण के आलोचक थे, और उन्होंने 1900 के शुरुआती वर्षों में frequentist दृष्टिकोण विकसित किया—अगर मैं सही हूँ। वहाँ विचार यह है कि पैरामीटर का कोई सच्चा मान है—और अगर मैं पर्याप्त डेटा सैंपल करूँ, तो जैसे-जैसे डेटा बढ़ता जाएगा, वह सच्चाई की ओर अभिसरित होगा।
तो frequentists P-वैल्यूज़ और कॉन्फिडेन्स इंटरवल्स की बात करते हैं—और यह वही पारंपरिक हाइपोथेसिस टेस्टिंग है जिसे आप जानते हैं। Frequentist दुनिया में, आपको मार्केटिंग मैनेजर के पास जाकर कहना होगा, "शून्य परिकल्पना के सत्य होने की शर्त पर, जितना बड़ा प्रभाव मैंने देखा या उससे बड़ा प्रभाव देखने की संभावना 5.7% है।" फिर बहस होगी क्योंकि पारंपरिक दृष्टि में 5% का सिग्निफिकेंस स्तर रखने से परिणाम को सिग्निफिकेंट कहा जाता है। तो इस मामले में, अगर आप अच्छे व्यक्ति हैं, तो आप शून्य परिकल्पना को रद्द नहीं करेंगे—लेकिन आपका मार्केटिंग मैनेजर कह सकता है, "5.7% तो 5% के काफ़ी क़रीब है, क्यों न 10% सिग्निफिकेंस स्तर ले लें।" और आप इस परेशानी में होंगे। जबकि Bayesian पद्धति में आप प्रोडक्ट मैनेजर से कह सकते हैं, "वेरिएंट A के वेरिएंट B से बेहतर होने की संभावना 94.3% या 98% है,"—और यह बातचीत करना कहीं आसान होता है।
Hugo: जिस उदाहरण की आप बात कर रहे हैं, वेरिएंट A और वेरिएंट B—or जो पैरामीटर हम देख रहे हैं—वह यह होगा कि कितने लोग सफलतापूर्वक अपने सारे काग़ज़ात अपलोड करते हैं?
Ben: सही।
Hugo: जो भी UX दिखता है, उसके एक फ़ंक्शन के रूप में।
Ben: हाँ। यानी जो भी आप टेस्ट कर रहे हैं—जैसे क्या मेरा नया वर्कफ़्लो उच्च क्लिकथ्रू रेट देता है या अधिक चेकआउट? क्या यह churn घटाता है? जो भी आपकी रुचि हो। तो हाँ। मुझे लगता है Bayesian पद्धति प्रोडक्ट मैनेजर्स के साथ बातचीत को आसान बनाती है—और इसके अलावा... हमारी सिमुलेशन स्टडीज़ में, हमें यह हमारी बिज़नेस के लिए कहीं जल्दी अभिसरित होता दिखा। आपकी बिज़नेस में आपका अनुभव अलग हो सकता है—and अगर आप यूरोप में हैं तो आपके किलोमीटर बदल सकते हैं।
Hugo: मुझे याद है Dave Robinson ने Stack Overflow के लिए Bayesian A/B टेस्टिंग पर कई पोस्ट लिखे थे—और दिखाया था कि उनके प्रयोगों के लिए यह आवश्यक नहीं कि अधिक तेज़ी से अभिसरित हो। मुझे यह जाँचना होगा, और हम उसे शो नोट्स में डाल सकते हैं।
Ben: हाँ। Evan Miller के कुछ बेहतरीन ब्लॉग पोस्ट भी इस विषय पर हैं।
अन्य डेटा साइंस तकनीकें और तरीके: इकोनोमेट्रिक्स और मशीन लर्निंग
Hugo: आपने प्रायोगिक डिज़ाइन का ज़िक्र किया। यह बहुत रोचक दृष्टिकोण है, क्योंकि मुझे नहीं लगता कि बहुत से लोग उम्मीद करेंगे कि प्रायोगिक डिज़ाइन और इस प्रकार की पद्धतियाँ डेटा साइंस का उपयोग करके ट्रकिंग उद्योग को फिर से आविष्कार करने में इतनी बड़ी भूमिका निभाएँगी। आप लोग और किन तकनीकों और तरीकों में रुचि रखते हैं?
Ben: हाँ, आगे बढ़ने से पहले A/B टेस्टिंग को बंद करते हुए—ट्रकिंग उद्योग के बारे में बहुत सी सामूहिक बुद्धि है। हमारी कंपनी आधी टेक स्टार्टअप है और आधी ट्रकिंग उद्योग के दिग्गज—और उनके पास बहुत मेहनत से कमाया ज्ञान और अंतर्ज्ञान है—पर वह हमेशा सही या सटीक नहीं होता। तो प्रयोग करके हम चीज़ों को कहीं अधिक ठोस बना सकते हैं।
Hugo: क्या इसमें राजनीतिक और सामाजिक पहलू भी है—यह अर्थ कि बहुत लोग लंबे समय से यहाँ हैं, उनके पास शक्ति और कठिन परिश्रम से अर्जित ज्ञान है—और धारणा यह है कि टेक स्टार्टअप्स आकर, उद्धरण-चिह्न में, इसे "डिसरप्ट" कर सकती हैं—और इसे ध्यान में रखते हुए सामाजिक व्यवहार की ज़रूरत होती है?
Ben: हाँ। मैं Convoy की संस्कृति की सीमा में ही बोल सकता हूँ—और यहाँ हमारी टीम-ओरिएंटेड संस्कृति बहुत बढ़िया है। यह वैसा लगता है जैसे जब मैं अच्छी हॉकी टीमों में खेलता था। दोनों पक्ष अपने-अपने योगदान की कद्र करते हैं। आप दो उद्योग दिग्गजों को भी देख सकते हैं जो किसी चीज़ पर सहमत न हों। तो Convoy में हम कोशिश करते हैं कि ऐसे मतभेद न रहें जिन्हें... चलिए फिर से कहता हूँ—अगर कोई मतभेद किसी सैद्धांतिक बहस या तथ्यों से हल नहीं हो सकता, तो हम एक प्रयोग चलाते हैं—बजाए इसके कि ऐसी बहस में बैठे रहें जिसका समाधान न हो।
Hugo: और क्या? आप लोग और किन तकनीकों और कार्यप्रणालियों का उपयोग करने में रुचि रखते हैं?
Ben: हाँ, हम व्यावहारिक, एप्लाइड डेटा साइंस शॉप हैं। हम कम समय में ठोस व्यावसायिक समस्याओं को सुलझाने की कोशिश करते हैं। तो हम वही मानक टूलकिट उपयोग करते हैं जिसकी अपेक्षा आप करेंगे। हम टूल्स के बारे में काफी आग्नॉस्टिक हैं—लोग काम के लिए सबसे अच्छे टूल का उपयोग करते हैं—तकनीक के लिहाज़ से वह R या Python हो सकता है—दोनों की ताकतें और कमजोरियाँ हैं—दोनों आना अच्छा है। फिर विशिष्ट दृष्टिकोणों में, कभी मशीन लर्निंग सर्वोत्तम होती है—खासकर जब हमें किसी चीज़ का पूर्वानुमान लगाना हो—जैसे कोई BOL अपलोड करेगा या नहीं, या मान लीजिए अच्छा कैरियर होगा या नहीं—तो आप लॉजिस्टिक रिग्रेशन या कोई बूस्टेड क्लासिफ़ायर बना सकते हैं। लेकिन अन्य समयों में आपको समझना होता है कि A ने B का कारण बना या नहीं—शायद हम प्रयोग नहीं चला पाए—तो हम फिर एप्लाइड स्टैटिस्टिक्स की दुनिया में होंगे और किसी तरह का रिग्रेशन विश्लेषण करेंगे। Convoy में मेरा पहला विन यही था कि मेरे शुरू होने से पहले उन्होंने बिना A/B टेस्ट के एक फीचर रिलीज़ किया था—और वे जानना चाहते थे कि यह नया फीचर मददगार था या नहीं—और मैं Google द्वारा विकसित causal impact पैकेज का उपयोग करके—Bayesian स्ट्रक्चरल टाइम सीरीज़ से—दिखा सका कि नए फीचर का सकारात्मक प्रभाव पड़ा।
Hugo: शानदार। और वह पहले से एकत्र डेटा पर था?
Ben: हाँ। हमारे पास मौजूदा डेटा था—और फिर आपको यह सुनिश्चित करने की कोशिश करनी होती है कि सब कुछ संभव हो तो रैंडम असाइनमेंट जैसा हो। एक प्रयोग के लिए प्रमुख शर्तों में से एक—रैंडम असाइनमेंट टू ट्रीटमेंट—और कुछ और चीज़ें भी संतुष्ट करनी होती हैं—जैसे आपका असाइनमेंट individualistic, probabilistic और unconfounded हो। ये तकनीकी शब्द हैं। अगर इनमें से कोई भी विफल हो जाता है, तो आप प्रेक्षणीय (observational) डेटा की दुनिया में होते हैं—और फिर आप एप्लाइड स्टैटिस्टिकल मेथड्स या इकोनोमेट्रिक्स का उपयोग करके कुछ ऐसा बनाते हैं जो रैंडम असाइनमेंट जितना अच्छा हो—ताकि आप कारणात्मक वक्तव्य दे सकें कि A ने B का कारण बना या नहीं।
Hugo: मुझे याद दिलाएँ कि इकोनोमेट्रिक्स क्या है?
Ben: ओह, इकोनोमेट्रिक्स वे सांख्यिकीय औज़ार हैं जो अर्थशास्त्रियों ने आर्थिक समस्याओं से निपटने के लिए विकसित किए हैं। बिज़नेस दुनिया के लिए ये औज़ार बहुत उपयोगी हैं क्योंकि हमारी अधिकांश समस्याएँ आर्थिक प्रकृति की होती हैं। एक क्लासिक उदाहरण सैंपल सेलेक्शन और एंडोजेनेइटी के अन्य रूपों से निपटना है—जहाँ आउटकम्स मॉडल के भीतर सह-निर्धारित (co-determined) होते हैं। क्लासिक उदाहरण—अगर आप समझना चाहते हैं कि पुलिस फोर्स का आकार बढ़ाने से अपराध घटता है या नहीं—तो आप सोच सकते हैं कि अपराध शायद पुलिस की मात्रा का फ़ंक्शन है—पर पुलिस भी अपराध के स्तर का फ़ंक्शन है। यानी यह एक साथ-समय (simultaneity) का उदाहरण है। सैंपल सेलेक्शन—एक बार जब आप इसे देखना शुरू करते हैं—हर जगह दिखता है—जैसे मैं यह प्रयोग चलाता हूँ कि क्या छोटे क्लास साइज़ से पढ़ने-समझने की क्षमता बेहतर होती है, लेकिन जो अमीर माता-पिता हैं, वे ज़िद करते हैं कि उनके बच्चे छोटे क्लास में हों—तो अब छोटे क्लास में अधिक होनहार बच्चे हैं—और अब आपके पास सेलेक्शन बायस है।
Hugo: तो इकोनोमेट्रिक्स ने इन चुनौतियों से निपटने के लिए ढेरों औज़ार बनाए हैं?
Ben: हाँ। विशेष रूप से, एक टूलसेट ऐसा है जो अर्थशास्त्रियों को तो अच्छी तरह ज्ञात है पर अर्थशास्त्र के बाहर डेटा साइंटिस्ट्स को कम—और वह है पैनल डेटा। ये औज़ार उस चीज़ से निपटने में बहुत अच्छे हैं जिसे अर्थशास्त्री individual heterogeneity कहते हैं। तो अगर मैं कैरियर्स या शिपमेंट्स के व्यवहार को देख रहा हूँ—इनमें व्यक्तिगत विचित्रताएँ होती हैं जिन्हें मैं देख नहीं पाता—और अगर मैं किसी कैरियर को समय के साथ देख सकूँ, तो पैनल डेटा मुझे बेहतरीन तरीके देता है इन अनदेखे व्यक्तिगत प्रभावों को हटा देने के—जो मेरे अनुमानों को भ्रमित कर सकते हैं।
Hugo: यह बहुत दिलचस्प है। ऐसा लगता है—अगर मैं गलत हूँ तो सुधारें—कि आपका कहना है कि इकोनोमेट्रिक्स में बहुत से होशियार लोगों ने ढेरों औज़ार विकसित किए हैं—जिनका उपयोग डेटा साइंस में किया जा सकता है—पर अभी इस दुनिया में उनकी उतनी चर्चा नहीं है?
Ben: हाँ। मुझे मशीन लर्निंग बहुत पसंद है—यह शानदार है—पर ऐसे मसले भी हैं जहाँ यह काम नहीं करती—और मुझे लगता है लोग मशीन लर्निंग पर इतना केंद्रित हो जाते हैं कि इकोनोमेट्रिक तरीकों की अनदेखी कर देते हैं—जो अक्सर बहुत उपयोगी होते हैं और ऐसे समस्याएँ सुलझा सकते हैं जिन्हें मशीन लर्निंग नहीं सुलझा सकती। मैं Uber में किसी से बात कर रहा था—Convoy में जुड़ने से पहले—उन्होंने कहा कि उन्होंने ऐसे मुद्दे देखे जिन्हें वे मशीन लर्निंग से हल नहीं कर सके—सिर्फ़ स्ट्रक्चरल इकोनोमेट्रिक मॉडल बनाकर हल कर सके—जो बहुत जटिल प्रक्रिया है—एक अच्छा मॉडल बनाने में एक साल या उससे अधिक लग जाता है। आप पूरे बिहेवियर प्रोसेस और यूटिलिटी फ़ंक्शन को मॉडल करने की कोशिश करते हैं—लेकिन जब आप हो जाते हैं—तो आपके पास बहुत समृद्ध और शक्तिशाली मॉडल होता है—जहाँ आप काउंटर-फ़ैक्चुअल आउटकम्स पर अच्छे पूर्वानुमान लगा सकते हैं।
Hugo: बढ़िया। और यह Uber में था, आपने कहा?
Ben: हाँ। यह मेरे इंटरव्यू के दौरान सामने आया—मैंने Convoy से पहले Uber में इंटरव्यू दिया था।
जियोस्पैशियल डेटा, क्वालिटी और सेल्फ-ड्राइविंग कारें
Hugo: ऐसा भी लगता है... हमने मशीन लर्निंग, इकोनोमेट्रिक्स, प्रायोगिक डिज़ाइन और A/B टेस्टिंग के लिए Bayesian विधियों पर बात की। लगता है आपके पास बहुत सारा भौगोलिक डेटा—जियोस्पैशियल डेटा—और समय-श्रृंखला के रूप में जियोस्पैशियल डेटा है। क्या यह आपके किसी काम में भूमिका निभाता है?
Ben: हाँ। यह डेटा बहुत महत्वपूर्ण है और हम अभी इसकी क्षमता को खोलना शुरू ही कर रहे हैं—लेकिन हम इसे ऐप में कई तरीकों से कैरियर्स का अनुभव बेहतर बनाने के लिए उपयोग करते हैं। उदाहरण के लिए, जब कोई कैरियर लोड पिक करने पहुँचता है, तो हम जियोस्पैशियल डेटा के आधार पर उन्हें स्वतः चेक-इन कर सकते हैं। कुछ लोडिंग सुविधाएँ बहुत खराब होती हैं—और अगर वे ट्रक को बहुत देर तक इंतज़ार कराती हैं, तो उन्हें detention नाम की चीज़ चुकानी पड़ती है। तो हम कैरियर के पात्र होते ही उनको detention का ऑटो-पेमेंट शुरू कर सकते हैं—उन्हें लंबी-चौड़ी डॉक्यूमेंटेशन प्रक्रिया से नहीं गुज़रना पड़ता—जो अमेरिका में इंश्योरेंस क्लेम फ़ाइल करने जैसा है।
Hugo: जब आपने कहा कि हमारे पास इतना डेटा है जिसे शायद आपने अभी पूरी क्षमता में नहीं खंगाला, तो मेरे दिमाग में आया कि इस डेटा के ज़रिए तरह-तरह के सामाजिक शोध की भी संभावनाएँ हो सकती हैं?
Ben: हाँ। मुझे लगता है हम मैचिंग, प्लेटफ़ॉर्म्स और नीलामियों पर बहुत से रोचक प्रश्नों का उत्तर दे सकते हैं—जिन पर मैं और गहराई से जाना चाहूँगा। मुझे यक़ीन है कि इस विषय पर कई अकादमिक पेपर लिखे जा सकते हैं।
Hugo: Convoy में विशेष तौर पर किन डेटा साइंस प्रोजेक्ट्स में आप शामिल रहे हैं—जो आपको समाज पर सबसे अधिक प्रभावकारी या उसके बारे में सबसे अधिक बताने वाले लगते हैं?
Ben: अच्छा प्रश्न है। मैं Convoy में एक साल से थोड़ा अधिक समय से हूँ—और कंपनी को दो साल से कुछ अधिक हुए हैं। मैंने मुख्यतः प्राइसिंग और एक्सपेरिमेंटेशन पर फोकस किया है। मुझे लगता है सबसे दिलचस्प प्रयोगों में से एक जो हमने चलाया—वह मेरे शुरू होने के तुरंत बाद था—जहाँ हमने उच्च-गुणवत्ता वाले कैरियर्स को लोड्स तक प्राथमिक पहुँच दी—और क्वालिटी नीचे चली गई। हर कोई चौंक गया—अरे, हम उच्च-गुणवत्ता वाले लोगों को काम तक जल्दी पहुँच दे रहे हैं और क्वालिटी घट रही है? क्या हो रहा है? इसका कोई मतलब नहीं। एक बुरा मैनेजर कहता, "अरे, तुम डेटा साइंटिस्ट, तुम बेवकूफ़ हो।" सौभाग्य से हमारे यहाँ एक बहुत अच्छे डेटा साइंस मैनेजर हैं—Ziad Ismail—जिन्होंने बढ़िया डेटा संस्कृति बनाई है। उन्होंने हमें इसमें गहराई से जाने दिया। तो मैंने इकॉनॉमिक्स की मैचिंग साहित्य के बारे में सोचना शुरू किया। मेरा परिकल्पना यह था कि क्योंकि हमने कैरियर्स के पूल को छोटा कर दिया था—भले ही वे उच्च-गुणवत्ता वाले थे—जॉब पर मैच क्वालिटी नीचे चली गई। हम इसे सत्यापित कर सके और फिर हमने रिग्रेशन विश्लेषण किया—जो दिखाता है कि मैच क्वालिटी का क्वालिटी पर कारणात्मक प्रभाव था। यह बहुत रोमांचक खोज थी—क्योंकि इससे पता चला कि हमारे प्लेटफ़ॉर्म पर मैचिंग कितनी महत्वपूर्ण है।
Hugo: अद्भुत। तो इसे अपने लिए स्पष्ट कर लूँ—उच्च-गुणवत्ता वाले कैरियर्स को लोड्स तक जल्दी पहुँच देने का मतलब यह हुआ कि उन्हें शिपर्स से मिलाने—मैचिंग एल्गोरिद्म—की क्वालिटी किसी अर्थ में घट गई—और उससे कैरियर्स की क्वालिटी में कमी आई?
Ben: हाँ। काम किस तरह अंजाम दिया गया, उसकी क्वालिटी—क्योंकि पात्र कैरियर्स का पूल छोटा था—और भले ही वे बेहतर थे—फिर भी मिलान के लिए संभावित लोगों की कम संख्या ने उनके उच्च-गुणवत्ता होने के तथ्य पर बढ़त ले ली।
Hugo: मेरा ख्याल है ब्राज़ील की कोई चींटी होती है, जिसमें 30%... मैं यह नहीं कह रहा कि यह प्रत्यक्ष अनुरूप है—पर मान लीजिए प्रत्येक कॉलोनी में 30% चींटियाँ कुछ नहीं करतीं। अगर आप उस 30% को हटा दें और एक दिन बाद लौटें, तो फिर से 30% चींटियाँ कुछ नहीं करतीं। मैं यह नहीं कह रहा कि वहाँ शिपर्स या कैरियर्स कुछ नहीं करते—पर कोई स्थिरीकरण-शक्ति जैसी चीज़ काम कर रही है। खैर, यह बहुत दिलचस्प है कि नतीजा उल्टा आया—जो सहज रूप से बेहतर क्वालिटी देनी चाहिए थी—उससे बदतर हुई।
Ben: हाँ। यह उत्कृष्ट उदाहरण है कि प्रयोग करना कितना महत्वपूर्ण है। जब हम यहाँ कोई प्रयोग चलाते हैं, तो हमने एक अच्छी परंपरा शुरू की—जहाँ लोग वोट करते हैं कि कौन-सा परिणाम जीतेगा। इससे पूरी कंपनी प्रयोगों में शामिल होती है—और आमतौर पर UX टीम विजेताओं को डोनट्स या कूल स्टिकर्स वगैरह देती है। हमारे पास ऐसे बहुत से प्रयोग रहे हैं जहाँ जो आप उम्मीद करते हैं, वह नहीं होता—क्योंकि किसी फीचर से प्रेम करना आसान होता है—जिसे आप शानदार मानते हैं—और वास्तविकता यह है कि ऐसा कुछ ढूँढना जो प्लेटफ़ॉर्म को आगे बढ़ाए—लगातार कठिन होता जाता है।
Hugo: एक अर्थ में इन प्रकार के प्रयोगों में—आप किसी तरह की प्रयोगशाला चला रहे हैं, है न?
Ben: हाँ, हम हैं—अपने व्यावसायिक प्रश्नों पर फोकस्ड।
Hugo: अगर यह कंपनी रणनीति या निजी सामग्री में बहुत घुसपैठ हो, तो मुझे बता दें। मैं बस यह जानना चाहता हूँ कि आप कैरियर्स की क्वालिटी—या किसी डिलिवरी की क्वालिटी—आदि का आकलन कैसे करते हैं?
Ben: ट्रकिंग में एक उद्योग-व्यापी समस्या है—लगभग 10% समय—जब कोई कैरियर किसी लोड को लेने के लिए प्रतिबद्ध होता है—तो वे बस नहीं आते—या आखिरी मिनट में बता देते हैं कि वे नहीं लेंगे—और आमतौर पर बहाना होता है कि मेरा ट्रक खराब हो गया। ट्रक 10% समय खराब नहीं होते। इसका मतलब होता है कि किसी ने उन्हें अधिक भुगतान वाला लोड ऑफ़र किया। कुछ कैरियर्स यह अक्सर करते हैं, और कुछ—मैंने उनका डेटा देखा है—जिन्होंने 100, 300 ट्रिप्स की हैं—और वे लगभग कभी फॉल ऑफ़ नहीं करते। तो फॉल ऑफ़—हम क्वालिटी मापने के लिए जिन प्रमुख घटकों का उपयोग करते हैं—उनमें से एक है—क्योंकि जब यह होता है तो यह हमारे लिए बेहद महँगा पड़ता है—क्योंकि हम शिपर्स को बहुत उच्च-गुणवत्ता वाला शिपिंग अनुभव देने के लिए प्रतिबद्ध हैं—और फिर हमें आखिरी मिनट में कोई और ट्रक ढूँढना पड़ता है—जो लोड कवर करे—और यह बहुत महँगा है।
Hugo: यह समझ में आता है। क्या आपकी कंपनी में सेल्फ-ड्राइविंग कारों या सेल्फ-ड्राइविंग ट्रक्स के आगमन के संदर्भ में कोई विचार-विमर्श होता है?
Ben: हाँ। मैं बस जोड़ दूँ कि क्वालिटी के लिहाज़ से हम और भी चीज़ें सोचते हैं—जैसे—
Hugo: ओह please, हाँ।
Ben: ड्राइवर का ऑन-टाइम परसेंटेज—हम कोशिश करते हैं कि वे ऐप का उपयोग करें—यह बहुत महत्वपूर्ण है—क्योंकि इससे हम compliance और safety में लागत घटा सकते हैं। ये सब बहुत महत्वपूर्ण हैं—लेकिन जिस विशिष्ट प्रयोग का मैंने ज़िक्र किया, उसमें फॉल ऑफ़ मुख्य चीज़ थी जिसकी मुझे फिक्र थी। हमें यह भी मिलता है कि अगर हम कैरियर्स को ऐप का उपयोग शुरू करने पर ला सकें—तो तरह-तरह की अच्छी चीज़ें होती हैं और संभव हो जाती हैं। तो डेटा साइंटिस्ट्स के तौर पर हम एक और बहुत ही इकॉनॉमिक्स-टाइप की चीज़ करते हैं—यानी प्लेटफ़ॉर्म पर इंसेंटिव्स को इस तरह स्ट्रक्चर करना—कि हमें वांछित व्यवहार मिले। उदाहरण के लिए—अगर कोई कैरियर ऐप का उपयोग करता है—तो उसे क्विक पे मिलता है। यानी हम उन्हें उसी दिन भुगतान कर देते हैं—जबकि उद्योग का मानक यह है कि कैरियर्स को काम करने के लगभग 30 दिन बाद भुगतान होता है—जिसका मतलब है कि वे आमतौर पर इस देयता को किसी फ़ैक्टरिंग कंपनी को बेचते हैं और अतिरिक्त 3% खो देते हैं। तो हम प्रभावी रूप से उन्हें 3% की वृद्धि दे रहे हैं—अगर वे... फ़ैक्टर के लिए लगभग 2-3%। तो अगर वे ऐप का उपयोग करते हैं—हम उन्हें 2-3% की वृद्धि दे रहे हैं।
Hugo: हाँ। यह बढ़ोतरी है—और इसका मतलब यह भी है कि उनके पास ज़्यादा लिक्विड असेट्स हैं, है न?
Ben: हाँ। मुझे नहीं पता आपके बारे में—पर जब मैं काम करता हूँ तो मुझे भुगतान मिलना पसंद है—और अगर मुझे 30 दिन इंतज़ार करना पड़े—तो यह सुखद अनुभव नहीं है। मुझे किराना, किराया और बाइक के पार्ट्स ख़रीदने हैं।
Hugo: सेल्फ-ड्राइविंग कारों और ट्रक्स के आगमन के संदर्भ में—क्या यह ऐसी चीज़ है जिस पर आप लोग Convoy में सक्रिय रूप से सोचते हैं?
Ben: हाँ। हम इस पर निश्चित रूप से सक्रिय रूप से सोचते हैं—और मुझे पता है फ़ाउंडर्स ने अपने नेटवर्क के ज़रिए इस पर बहुत समय बिताया है—और वे इससे बहुत जुड़े हुए हैं। अंततः, जब सेल्फ-ड्राइविंग ट्रक्स आएँगे—और यह शायद चरणबद्ध तरीके से होगा—जहाँ अलग-अलग स्तर का ऑटोमेशन होगा—उन्हें फिर भी फ्रेट से जुड़ना होगा—और हमारे पास एक प्लेटफ़ॉर्म है जो यह करता है। हमारा लक्ष्य होगा कि हम उसे प्लेटफ़ॉर्म की सप्लाई साइड में इंटीग्रेट कर दें।
डेटा साइंस में बहुपक्षीयता
Hugo: हम अब तक ट्रकिंग पर डेटा साइंस के प्रभाव की बात कर रहे थे—Convoy में आपके काम के संदर्भ में—और जैसा कि... हम डेटा साइंस के पास विभिन्न दिशाओं से पहुँचे हैं—यह स्पष्ट है कि इस अनुशासन में बहुत सी चीज़ें योगदान देती हैं—और आपके पास—आप कंप्यूटेशनल इकॉनॉमिस्ट, पूर्व-भौतिक विज्ञानी, और Amazon में पूर्व शोध वैज्ञानिक रहे हैं। मेरा प्रश्न है—ये सभी विधाएँ और इतिहास, डेटा साइंटिस्ट के रूप में आपकी भूमिका में कैसे योगदान देते हैं?
Ben: मेरा मानना है कि औज़ार कभी ज़्यादा नहीं होते। जब मैं युवा भौतिकविद था—मुझे सौभाग्य मिला—मैं John Wheeler के साथ काम करता था—और वे कहा करते थे—Niels Bohr को चैनल करते हुए—"जब तक आपको उत्तर न मालूम हो—कुछ उद्धृत मत करो।" यह एक प्रसिद्ध Wheelerism है—पर इसका मतलब यह है कि आपको अपने वैज्ञानिक प्रश्न के सही उत्तर का कुछ अंदाज़ा होना चाहिए। Feynman का एक प्रसिद्ध उदाहरण है—जहाँ Feynman आए और सोचा कि उन्होंने कुछ सिद्ध कर दिया—और Wheeler ने कहा—तुम गलत हो—और Feynman बहुत खीजे—क्योंकि Wheeler यह समस्या कैसे कर सकते हैं—Feynman ने अभी-अभी इसे पहली बार किया। Feynman की गणना में गलती थी। Wheeler का भौतिकी का ज्ञान इतना गहरा था कि उन्हें पता था—यह गलत होना चाहिए—यह समझ में नहीं आता। तो जैसे—अगर आप बाहर जाते हैं और अपने डायरेक्ट मेल कैंपेन पर लिफ्ट मापने के लिए कोई प्रयोग चलाते हैं—और 10% मिलता है—तो शायद यह गलत है। आप उम्मीद नहीं करेंगे कि यह सच हो। तो मुझे लगता है भौतिकी इस तरह बहुत मददगार है—जुगाड़ू बनने में और गणित—विशेषकर रैखिक बीजगणित—में दक्षता बनाने में। मेरा मानना है कि डेटा साइंस में सफलता के लिए रैखिक बीजगणित बेहद महत्वपूर्ण है—शायद कलन से भी ज़्यादा। अर्थशास्त्र ने मुझे व्यावसायिक समस्याओं पर सोचने के सैद्धांतिक औज़ार दिए—साथ ही इकोनोमेट्रिक्स के औज़ार—जिनसे आप सिद्धांत को डेटा से टकराते हैं। सॉफ्टवेयर इंजीनियरिंग में मेरे समय ने मुझे वह सॉफ़्टवेयर स्किल दी कि मैं सांख्यिकी को कोड में बदल सकूँ। आप जहाँ भी काम करें, उम्मीद है आप नए कौशल हासिल कर रहे होंगे—सीख रहे होंगे—यह डेटा साइंटिस्ट्स के लिए बेहद ज़रूरी है। साथ ही, सांस्कृतिक रूप से Amazon समस्याओं पर सोचने का बहुत परिपक्व तरीका सिखाता है—आवश्यकता का एहसास, प्रभाव पर फोकस—यह पीएचडी प्रोग्राम जैसा है—जहाँ आप दिन भर खुद से यह पूछना सीखते हैं—क्या जो मैं कर रहा हूँ वह मेरी पीएचडी पूरी कराएगा—और अगर जवाब ना है—तो आप गलत चीज़ पर काम कर रहे हैं।
Hugo: मुझे याद है आपने Data Science Pop-Up Seattle में Correctness in Data Science नाम की बहुत अच्छी बात कही थी। मुझे यह इसलिए पसंद आई क्योंकि आपने बताया कि किस तरह की गलतियाँ होती हैं—और हम एक सुव्यवस्थित अनुशासन बनाने के संदर्भ में—उन्हें कैसे सुधार सकते हैं—जो अभी एक अस्पष्ट मिश्रण है तकनीकों, अवधारणाओं और अनुप्रयोगों का। तो क्या आप बता सकते हैं कि आज आप डेटा साइंटिस्ट्स को कौन-सी बड़ी गलतियाँ करते देखते हैं?
Ben: मुझे खुशी है कि आपको वह बात पसंद आई।
Hugo: बहुत पसंद आई—और हम उसे शो नोट्स में भी डालेंगे—ताकि जो भी सुने वह देख सके।
Ben: बढ़िया। सबसे पहले, आशा है दर्शकों को यह पसंद आए—और मुझे लगता है वैज्ञानिक मॉडलों की शुद्धता बेहद महत्वपूर्ण है—और बहुत से लोग—खासकर शुरुआत में—सोचते हैं, ओह मेरा कोड सफलतापूर्वक चला—एक नंबर निकला—तो यह सही होगा। रुकिए। आपको सुनिश्चित करना चाहिए कि यह सही नंबर है। इसके बारे में सोचने के लिए एक एपिस्टेमोलॉजिकल फ़्रेमवर्क है—जो न्यूक्लियर इंडस्ट्री से निकला—जिसे verification, validation और uncertainty quantification कहा जाता है। मैं Robert Rosner—जो मेरे पोस्टडॉक सुपरवाइज़र और उससे भी बढ़कर Argonne के पूर्व निदेशक थे—का आभारी हूँ—जिन्होंने मुझे VV & UQ से परिचित कराया। VV & UQ के मूलतः तीन भाग होते हैं। पहला V—verification। यानी आपका कोड मॉडल को सही तरीके से लागू कर रहा है या नहीं—भले ही मॉडल सही हो या नहीं। इसका मतलब है—आपको यूनिट टेस्ट करने चाहिए—आप Monte Carlo तरीकों से सिंथेटिक डेटा—ज्ञात पैरामीटर्स के साथ—जेनरेट कर सकते हैं—और सुनिश्चित करें कि अपेक्षित परिणाम मिलते हैं—और इस तरह की चीज़ें करें—ताकि आपका कोड सही हो। Validation—यह सुनिश्चित करना कि आपके मॉडल की वास्तविकता से सुसंगति है—यानी बाद में प्रयोग चलाकर देखना कि आपका मॉडल वास्तविकता का सटीक प्रतिरूप है या नहीं। Uncertainty quantification—यह आपके मॉडल की सीमाओं के बारे में सोचना है—आपने क्या मान्यताएँ बनाई हैं? क्या वे लागू होती हैं? क्या कोई सुनामी आकर आपके न्यूक्लियर पावर प्लांट को धो सकती है? शायद आपको उसकी योजना बनानी चाहिए। तो ये कुछ बुनियादी बातें हैं। मुझे BI इंजीनियर्स से इंटरव्यू में पूछना पसंद है—आपको कैसे पता चलता है कि आपका SQL सही है—और वे आमतौर पर मुझे देखते हैं जैसे यह कोई अजीब सवाल है। पर SQL—या जो भी आप डेटा खींचने के लिए उपयोग कर रहे हैं—बहुत अहम है—क्योंकि अगर आपने कचरा डेटा सेट तैयार किया—तो बाद में आप जो भी करें—बेहतर नहीं होगा। चाहे आप कितनी भी फैंसी स्टैटिस्टिक्स कर लें—आप इस तथ्य को नहीं सुधार सकते कि आपने डेटा सही तरह असेंबल नहीं किया। इसलिए यह महत्वपूर्ण है कि डेटा असेंबल करते समय बहुत पद्धतिगत रहें और जाँचते रहें कि वह सही है—जॉइन प्लान्स पर सोचें—डेटा के सबसेट्स पर टेस्ट करें—और सुनिश्चित करें कि एग्रीगेट स्टैटिस्टिक्स और डिस्ट्रीब्यूशन्स समझ में आते हैं। समझदार चीज़ें जाँचें—जैसे कि आपके डायरेक्ट मेल कैंपेन पर 10% लिफ्ट नहीं आ गया। फिर एक और बहुत अहम बात—मॉडल्स प्रोडक्शन में जाते हैं—तो शायद आपको इंटीग्रेशन टेस्ट्स या अन्य टेस्ट्स की ज़रूरत होगी—ताकि सुनिश्चित हो सके कि प्रोडक्शन में जो है—वह रिसर्च में विकसित चीज़ के प्रति वफ़ादार है।
प्रोडक्शन में डेटा साइंस
Hugo: तो जहाँ... या तो जहाँ आपने पहले काम किया या अब Convoy में—डेटा साइंटिस्ट प्रोडक्शन में अपना काम डालने के संदर्भ में कहाँ बैठता है?
Ben: यह संगठन और समूह के अनुसार बहुत बदलता है। कुछ संगठनों या समूहों में डेटा साइंटिस्ट सिर्फ़ शुद्ध रिसर्च करेगा—और फिर चीज़ें "दीवार के पार" भेज देगा—और इंजीनियरिंग कुछ जादू करेगी। यह समस्यापूर्ण हो सकता है—चीज़ें ट्रांसलेशन में खो जाती हैं। कई इंजीनियर्स तब ख़ुश नहीं होते जब आप उन्हें R कोड देते हैं—आशा है Python से ख़ुश हों। Convoy में हम इस दिशा में काम कर रहे हैं कि डेटा साइंटिस्ट अपना मॉडल एंड-टू-एंड ओन करें—और हमारे पास एक मशीन लर्निंग प्लेटफ़ॉर्म हो—जो हमें मॉडल्स डिप्लॉय करने दे। हम अभी पूरी तरह वहाँ नहीं पहुँचे—इस संदर्भ में और काम बाकी है—पर मुझे लगता है यह सबके लिए बेहतर है—क्योंकि फिर इंजीनियर्स डेटा सर्विस को कॉल करके जो भी रिज़ल्ट चाहिए ले सकते हैं। साथ ही, Convoy में हमारा ऑर्गनाइज़ेशनल स्ट्रक्चर अच्छा डेटा साइंस करने के अनुकूल है—हम प्रोडक्ट ग्रुप्स में संगठित हैं—जो करीबी सहयोग करते हैं—पर एक प्रोडक्ट ग्रुप में एक प्रोडक्ट मैनेजर, एक या अधिक डेटा साइंटिस्ट्स और कई इंजीनियर्स होते हैं। हमारे प्रोडक्ट मैनेजर्स की बढ़िया बात यह है कि वे सभी बहुत टेक्निकल हैं—अधिकांश के पास कंप्यूटर साइंस में मास्टर्स या समकक्ष, अच्छा MBA है—और वे सभी SQL लिख सकते हैं। यहाँ एक प्रोडक्ट मैनेजर हैं—इंटरव्यू में मैंने उन्हें एक SQL प्रश्न पूछा—जिसमें left outer join का उपयोग था—और उन्होंने लगभग 60 सेकंड में हल कर दिया। मुझे लगता है वे इस उदाहरण से थक गए हैं—पर यही हमारे PMs का स्तर है। वे टेक्निकल, डेटा-ओरिएंटेड हैं—SQL लिख सकते हैं—अंडरग्रैज स्तर का स्टैट्स समझते हैं—और यह बहुत मददगार है—क्योंकि इससे वे सही ढंग से डेटा साइंस करने के पैरोकार बनते हैं—फिर हमारे पास बहुत-सा अतिरिक्त सामाजिक ढाँचा है जिससे सुनिश्चित हो कि डेटा साइंटिस्ट्स क्षैतिज रूप से जुड़े और सहयोग करते रहें। जैसे—हम डेटा साइंस ब्राउन बैग चलाते हैं। हमारे पास टेक्निकल वन-ऑन-वन होते हैं—जहाँ मैं अन्य डेटा साइंटिस्ट्स से मिलता हूँ—और सुनिश्चित करता हूँ कि वे सही दिशा में जा रहे हैं—और उनके किसी भी टेक्निकल प्रश्न का उत्तर दे सकूँ—ताकि वे ब्लॉक न हों।
Hugo: मुझे लगता है कि एक टेक्निकल प्रोडक्ट मैनेजर—as you say—कई फ़ायदे लाता है—पर सबसे बड़ा यह कि वह आपसे सच में बातचीत कर सकता है, है न?
Ben: हाँ। वे डेटा-ड्रिवन होने में बहुत निवेशित होते हैं। वे जानते हैं कि अगर वे किसी नए फीचर की योजना लिखते हैं—तो उन्हें डेटा साइंटिस्ट के साथ मिलकर Stack Overflow प्लान—या कोई अन्य प्लान—बनाना होगा—ताकि अपने विचारों को वेरिफ़ाई और वैलिडेट कर सकें। वे सभी डेटा के उपयोग के पैरोकार हैं—और हमारे यहाँ PMs का मानक बहुत ऊँचा है—पर ऐसी संस्था में यह अहम है कि वे डेटा की बातचीत में भाग ले सकें—क्योंकि अक्सर वही रिसर्च प्रश्नों को ड्राइव कर रहे होते हैं। यह दिखाने के लिए कि वे कितने डेटा-ड्रिवन हैं—Ziad Ismail—जो चीफ प्रोडक्ट ऑफिसर हैं—वे SQL लिखते हैं। मेरा मतलब, यह व्यक्ति रात में जागकर बिज़नेस समझने के लिए SQL लिखते हैं—और हमारे डेटा वेयरहाउस के डेटा का उन्हें उतना ही गहरा ज्ञान है जितना किसी को।
Hugo: बढ़िया। तो आपके पास—मुझे कहना होगा—सांख्यिकी, इकोनोमेट्रिक्स और डेटा साइंस तकनीकों का बहुत प्रभावशाली औज़ार-बक्सा है। आपका पसंदीदा तकनीक या कार्यप्रणाली क्या है?
Ben: हाँ, यह अच्छा प्रश्न है—और यह वैसा है जैसे पूछना—आपका पसंदीदा पंछी क्या है—या कैमरा। ब्रिटिश कहावत है—एक धागा कितना लंबा होता है?
Hugo: और कोई इसका उत्तर नहीं दे सकता।
Ben: है ना? तो मैं आमतौर पर...
Hugo: हाँ, आपको क्या पसंद है? किसमें रुचि है?
Ben: ...काम के लिए सबसे अच्छा औज़ार उपयोग करना। तो निश्चित रूप से... मैं ऐसे पीएचडी प्रोग्राम से आया हूँ जो पैनल डेटा मेथड्स में बहुत मजबूत था—जैसे UCL में लोग—Richard Blundell वगैरह—जिन्होंने इसे आगे बढ़ाने में बहुत योगदान दिया। तो यह मेरी ताकत है—पैनल डेटा मेथड्स का उपयोग। पर मुझे कोर ML टूल्स भी बहुत पसंद हैं। यह वाकई समस्या पर निर्भर करता है। मैं सबसे अच्छा औज़ार उपयोग करना चाहता हूँ। तो मुझे सबसे ज़्यादा ख़ुशी औज़ार उपयोग करने से नहीं—बल्कि दिलचस्प समस्याएँ सुलझाने से मिलती है। मैं अंततः एक एप्लाइड साइंटिस्ट हूँ। मैंने क्वांटम कॉस्मोलॉजी से लेकर बायोइन्फ़ॉर्मेटिक्स और ट्रकिंग तक—विभिन्न समस्याओं पर काम किया है। तो दिलचस्प समस्याएँ होना मायने रखता है—और उन्हें सुलझाने के लिए सही औज़ार ढूँढ़ पाना महत्वपूर्ण है—डेटा और सॉफ़्टवेयर के साथ।
डेटा साइंस का भविष्य
Hugo: हमने आधुनिक डेटा साइंस पर बहुत चर्चा की। आपके लिए भविष्य का डेटा साइंस कैसा दिखता है?
Ben: हम अद्भुत समय में हैं। अगर आपके पास गणित और सांख्यिकी के कौशल हैं—तो हर जगह डेटा फटकर बाहर आ रहा है। मेरा मानना है कि जब तक Elon Musk कोई ऐसा तरीका नहीं निकाल लेते कि हम सबको बेरोज़गार कर दें—तब तक हमारा समय बहुत मज़ेदार और रोचक रहने वाला है।
Hugo: तब तक क्या होगा?
Ben: किसी बिंदु पर ऐसे टूल्स आएँगे जो सरल मॉडलों के बहुत से हिस्सों को ऑटोमेट कर देंगे। आप अभी कंपनियों को कमोडिटी churn मॉडल्स वगैरह बेचने की कोशिश करते देखना शुरू कर रहे हैं—जो मेरे ख्याल से समस्यापूर्ण हो सकता है—क्योंकि अंततः हर कंपनी का डेटा अनोखा होता है—और आपको अपना churn मॉडल शुरू से बनाना चाहिए। पर आप शायद और अधिक कमोडिटी मॉडल्स देखेंगे—और ऐसे टूल्स—जो लो-हैंगिंग डेटा साइंस फलों को ऑटोमेट करेंगे। तो सफल और खुशहाल करियर के लिए आपको वैल्यू चेन में ऊपर जाना चाहिए—जहाँ वे चीज़ें हैं जिन्हें ऑटोमेशन जैसे ऑटोमेटेड फीचर इंजीनियरिंग नहीं बदल पाएगी। उदाहरण के लिए, Context Relevant—मेरी पिछली कंपनी—वे बड़ी समस्याओं की एक श्रेणी के लिए फीचर इंजीनियरिंग को ऑटोमेट करने में अच्छी प्रगति कर चुके थे।
Hugo: आप कौन-से कौशल सुझाएँगे—ताकि उदीयमान और अनुभवी डेटा साइंटिस्ट—अपनी नौकरियाँ ऑटोमेट होने से बचा सकें?
Ben: पहली बात—आप गणित कभी ज़्यादा नहीं जान सकते। इसमें निवेश करना बहुत फायदेमंद है—और यह कम उम्र से शुरू होता है। जब मैं Galvanize में पढ़ाता था—जहाँ वे डेटा साइंस बूटकैंप चलाते हैं—मैं आठ हफ्तों में किसी की प्रोग्रामिंग की कमी दूर कर सकता हूँ। मैं आठ या बारह हफ्तों में गणित की कमी दूर नहीं कर सकता—वह वर्षों की पढ़ाई है। तो मुझे लगता है आपको गणित में लगातार निवेश करना चाहिए। उसके बाद आपको कोर एल्गोरिद्म्स में महारत हासिल करनी चाहिए—फिर पढ़ते रहना चाहिए। पढ़ते रहना बहुत ज़रूरी है। बहुत से लोग इंडस्ट्री में आकर पढ़ना बंद कर देते हैं—और खासकर उन्नत लोगों के लिए—आपको कोई ऐसी स्पेशलाइज़ेशन चुननी चाहिए—जो आपकी रुचि से मेल खाती हो। तो प्रयोग (एक्सपेरिमेंटेशन) मुझे विशेष रूप से दिलचस्प लगता है—जैसे Bayesian मेथड्स—और ये दोनों ऐसी चीज़ें हैं जिनमें मैंने हाल के वर्षों में और गहराई से काम किया है। मुझे पता है बहुत से लोग डीप लर्निंग में जा रहे हैं—वह बहुत प्रतिस्पर्धी क्षेत्र है। तो मुझे लगता है डेटा साइंस में कई और रोचक और महत्वपूर्ण क्षेत्र हैं। तो हाँ, अगर आप डीप लर्निंग में जाना चाहते हैं—जाइए। पर थोड़ा कंट्रेरियन होने में भी फ़ायदा है।
आह्वान
Hugo: मुझे भी ऐसा लगता है। तो यह सब कहते हुए—क्या आपके पास उभरते और स्थापित दोनों प्रकार के डेटा साइंटिस्ट्स के लिए कोई अंतिम कॉल-टू-एक्शन है?
Ben: मैं किसी ऐसे व्यक्ति से—जो डेटा साइंस में आना चाहता है—मुख्यतः यही कहूँगा कि समझ लें—आप खुद को आजीवन सीखने के लिए तैयार कर रहे हैं—और यह मैराथन है—स्प्रिंट नहीं। यह पीएचडी करने जैसा है—आपको अपनी रफ़्तार साधनी होगी। इसे करने में कई साल लग सकते हैं। तो आपको लगातार निवेश करना होगा। तो शायद आपको रात में Netflix थोड़ा कम देखना चाहिए—और प्रासंगिक किताबें, पेपर्स पढ़ने, कोड लिखने, मॉडलों से खेलने में थोड़ा अधिक समय देना चाहिए—और अगर आपको डेटा के बारे में वह उत्साह महसूस नहीं होता—तो शायद कोई और जगह है जहाँ आप अधिक खुश होंगे।
Hugo: तो सीखते रहिए, पढ़ते रहिए, करते रहिए।
Ben: हाँ। मेरे लिए—और मुझे लगता है हममें से कई लोगों के लिए—डेटा एक Agatha Christie जैसा है—उसमें एक रहस्य छुपा है—और मैं उसे खोलना, सुलझाना चाहता हूँ—और पता लगाना चाहता हूँ कि क्या वह Colonel Mustard था—लिविंग रूम में—मोमबत्ती-दान के साथ।
Hugo: शानदार, Ben। तो आप अपना डेटा साइंस जीवन जासूसी कहानियों की तरह जी रहे हैं।
Ben: हाँ—कुछ ऐसा ही।
Hugo: यह अद्भुत है। मैं इससे बहुत जुड़ाव महसूस करता हूँ—क्योंकि डेटा देता ही जाता है। मेरे एक सहकर्मी हमें हमेशा बताते हैं—आपको अपने डेटा को सुनना चाहिए—वह बोलेगा—जब तक आप सुन रहे हैं, है न?
Ben: हाँ। और एक बात—जब आपने पहले गलतियों की बात की—एक गलती जो मैंने बहुत से वैज्ञानिकों में देखी—वे बिना EDA किए मॉडलिंग में कूद पड़ते हैं। EDA—Tukey का प्रसिद्ध शब्द—exploratory data analysis। EDA में कुछ समय लगाना क़ीमती है—क्योंकि आप चौंकाने वाली चीज़ें खोजेंगे। जब मैं Convoy में शामिल हुआ—मैंने डेटा पर EDA करना शुरू किया—और मुझे कुछ डेटा क्लीनिंग और आउट्लायर समस्याएँ मिलीं—जिनका समाधान नहीं हुआ था—और हमने उन्हें ठीक किया—और प्राइसिंग मॉडल में लगभग 10% सुधार मिला। यह जैसे मुफ़्त परफ़ॉर्मेंस थी।
Hugo: यह बहुत कुछ बताता है। यानी EDA—exploratory data analysis करना—क्योंकि मॉडल्स बनाने में कूद पड़ना आकर्षक होता है—पर मैं हमेशा लोगों को प्रोत्साहित करता हूँ कि वे अपने डेटा को 100 अलग-अलग तरीकों से विज़ुअलाइज़ करें—समरी स्टैटिस्टिक्स देखें—और बाकी सब—कुछ भी करने से पहले।
Ben: हाँ। और मैं छात्रों को बहुत पद्धतिगत, मानकीकृत दृष्टिकोण सिखाने की कोशिश करता हूँ—और यह उन चीज़ों में से एक है जो मुझे CRISP-DM में शानदार लगती हैं—जो cross-industry standard process for data mining है—और यह शायद किसी डेटा साइंस प्रोजेक्ट के लिए सबसे अच्छा वर्कफ़्लो है—और यह सुनिश्चित करने के लिए सभी चरणों से गुज़रना अच्छा है कि कुछ छूट न जाए। तो आप शुरुआत करते हैं—व्यावसायिक समस्या समझकर—फिर समझते हैं कि आपके पास क्या डेटा है। अपना डेटा तैयार करें। मॉडलिंग, मूल्यांकन और डिप्लॉय करें। और किसी भी बिंदु पर—आपको कोई गलती मिल सकती है—जिसे आपको पिछले चरणों में जाकर संबोधित करना होगा। तो आप मॉडलिंग शुरू करते हैं—और महसूस करते हैं—ओह, मैंने अपना फीचर इंजीनियरिंग सही नहीं किया—या मुझे कोई फीचर जोड़ना होगा ताकि किसी प्रमुख व्यवहार को कैप्चर कर सकूँ—जहाँ मॉडल असफल हो रहा है। इस तरह व्यवस्थित रहना बहुत अच्छा है—ताकि आप प्रयास न दोहराएँ—या चरण न छोड़ें—और अंततः शुद्धता (correctness) के संदर्भ में—जिसका हमने ज़िक्र किया—मैं CRISP-DM और VV & UQ को साथ जोड़ने का तरीका ढूँढ़ना चाहूँगा—और तब आप बहुत शक्तिशाली, पेशेवर और परिपक्व सेटअप में होंगे।
Hugo: शानदार। यह वास्तव में उस तरह की प्रणालीगत संरचना को दर्शाता है—कि भविष्य का डेटा साइंस कैसा दिख सकता है—या क्या समाहित कर सकता है।
Ben: हाँ। और इसका दूसरा पहलू यह है कि मॉडलिंग मज़ेदार हिस्सा है—और उत्तर तक पहुँचना—पर उससे पहले की चीज़ें बेहद महत्वपूर्ण हैं—और आपके समय का लगभग 80% लेती हैं। वह—डेटा साफ़ करना, तैयार करना। फिर मॉडलिंग तेज़ होती है—यह ऐसे होती है—और—धप्प—कहाँ गई? मैं वापस सामान्य पर। मुझे लगता है हम और टूल्स देखेंगे—आशा है—जो प्री-मॉडलिंग पीरियड को तेज़ करेंगे—क्योंकि वहीं आपको सबसे बड़े उत्पादकता लाभ मिलेंगे—अगर आप उस चरण में तेज़ हो पाएँ। तो यह निवेश करने की अच्छी जगह है। तो आपको UNIX जैसी चीज़ें सीखनी चाहिए—और कमांड लाइन टूल्स और अन्य टेक्नोलॉजी या प्लेटफ़ॉर्म्स में बहुत अच्छे हो जाना चाहिए—जो आपको डेटा को तेज़ी से मॉडल के लिए तैयार करने में मदद करेंगे।
Hugo: बिल्कुल। Ben, शो में आपका होना बहुत सुखद रहा।
Ben: धन्यवाद, Hugo। यहाँ आना बहुत अच्छा लगा—और शो के लिए आपको शुभकामनाएँ।
Hugo: धन्यवाद।
Hugo: Ben, DataFramed में आपका स्वागत है।
Ben: धन्यवाद, Hugo, यहाँ आना बहुत अच्छा लग रहा है और मैं आज Convoy और डेटा साइंस पर आपसे बात करने के लिए उत्सुक हूँ।
Hugo: मैं इससे अधिक सहमत नहीं हो सकता। आपका यहाँ होना शानदार है, और DataFramed पर डेटा साइंस क्या है और क्या हो सकती है, इस पर हमारी चल रही पड़ताल में, मैं आज आपसे Convoy में आपके काम और ट्रकिंग उद्योग में क्रांति लाने में डेटा साइंस की भूमिका पर बातचीत करने के लिए बेहद उत्साहित हूँ—जो उत्तर अमेरिका के सबसे प्रभावशाली उद्योगों में से एक है। लेकिन पहले, मैं आपके बारे में बात करना चाहता हूँ।
Ben: ठीक है, धन्यवाद।
डेटा साइंटिस्ट क्या होता है?
Hugo: लोग मुझसे हमेशा पूछते हैं, डेटा साइंटिस्ट असल में करते क्या हैं? Ben, आपके सहयोगी क्या सोचते हैं कि आप क्या करते हैं?
Ben: यह बहुत अच्छा प्रश्न है। मुझे लगता है कि "डेटा साइंटिस्ट" शब्द बहुत धुंधला है। अलग-अलग लोगों के लिए इसका अलग अर्थ होता है। मैं प्राकृतिक विज्ञान और सामाजिक विज्ञान, दोनों पृष्ठभूमियों से डेटा साइंस में आया हूँ। पीएचडी (इकॉनॉमिक्स) से पहले मैंने सिलिकॉन वैली का एक चक्कर भी लगाया। तो मेरे लिए, मैं अपना आधा दिन बैठकों में बिताता हूँ—यह चर्चा करते हुए कि हमारा प्लेटफ़ॉर्म कैसे चलाया जाए, या यहाँ डेटा साइंस के प्रति हमारा दृष्टिकोण कैसे विकसित हो रहा है, या विशिष्ट प्रश्नों पर, जैसे, प्रायोगिक डिज़ाइन। मैं लगभग आधा समय अन्य डेटा साइंटिस्ट्स को मेंटर करता हूँ—जैसे किसी जूनियर डेटा साइंटिस्ट की किसी कैंपेन के लिए प्रायोगिक डिज़ाइन पर मदद करना, या मान लीजिए, ग्राहक रिटेंशन समझने के लिए एक सरवाइवल मॉडल बनवाना।
फिर मैं अपना एक और आधा समय इंडिविजुअल कॉन्ट्रिब्यूटर के रूप में बिताता हूँ—उन पहलुओं पर सोचते हुए जो हमारे प्लेटफ़ॉर्म को चलाते हैं और उस चीज़ को ठीक कर के प्रभाव डालने की कोशिश करता हूँ जो अभी "आग पर" है। जैसे नीलामी, मैचिंग, प्राइसिंग और इस तरह के मुद्दों पर सोचना। जो भी गणित कर सकता है, वह नोटिस करेगा कि यह तीन आधों के बराबर हो गया, लेकिन मैं एक स्टार्टअप में काम करता हूँ, तो चीज़ें एक में नहीं जुड़तीं।
Hugo: मैं इससे अधिक सहमत नहीं हो सकता। DataCamp में तो कभी-कभी मुझे लगता है कि मैं वास्तव में एक अनंत सम के रूप में काम कर रहा हूँ। और क्योंकि आपकी पृष्ठभूमि भौतिकी में है, आपने मुझे बताया था कि भौतिकविदों के लिए केवल तीन ही संख्याएँ होती हैं, है न?
Ben: हाँ। ज़ीरो, वन और इन्फिनिटी—बाकी सब स्केलिंग का मामला है। पुराना मज़ाक है।
Ben का डेटा साइंस में करियर
Hugo: बिल्कुल। तो आप डेटा साइंस में कैसे आए?
Ben: यह बहुत अच्छा प्रश्न है, और मुझे लगता है कि मैं हमेशा से सॉफ्टवेयर, डेटा, गणित, सांख्यिकी और मॉडलों के साथ काम करता रहा हूँ, और जब DJ Patil ने यह शब्द गढ़ा और यह वायरल हो गया, तब मार्केटिंग विभाग में किसी ने मेरा रीब्रांडिंग कर के मुझे डेटा साइंटिस्ट कह दिया। लेकिन जब मैं कॉलेज में स्नातक था, तब भी मैं वैज्ञानिक प्रश्नों को समझने के लिए सॉफ्टवेयर लिख रहा था। तो सबसे पहली डेटा-साइंसनुमा चीज़ जो मैंने की, वह थी क्रेटर रीलैक्सेशन को समझने के लिए एक प्रोग्राम लिखना—McKinnon के लिए, जो Washington University में एक अद्भुत प्लानेटरी वैज्ञानिक हैं—और वहाँ Frankie बैंड बहुत बड़ा था, और चूँकि हम क्रेटर रीलैक्सेशन से डील कर रहे थे, मैंने अपने प्रोग्राम का नाम Frankie रखा। फिर हाल ही में, पीएचडी के बाद, मैं University of Chicago में था और Amazon में काम करने के लिए रिक्रूट हुआ। यह लगभग 2012 की बात है। तो तब मैं कहूँगा कि मैंने सचमुच अकादमिक से चीज़ें लेकर उद्योग में लागू करने की ओर संक्रमण किया।
Hugo: तो अब आप Convoy में डेटा साइंटिस्ट के रूप में काम कर रहे हैं?
Ben: जी।
Convoy
Hugo: ज़रा बताइए कि Convoy क्या करता है, इसका मिशन क्या है?
Ben: यह एक बहुत अच्छा उदाहरण है कि सॉफ्टवेयर का किसी स्थापित उद्योग में प्रवेश करना, उस स्थापित उद्योग के लिए खुद सॉफ्टवेयर लाना शुरू करने से कहीं आसान क्यों होता है। फ्रेट उद्योग लंबे समय से मौजूद है। अमेरिका में यह बहुत बड़ा बाज़ार है—लगभग 800 बिलियन डॉलर का। एक समस्या है कि ज़्यादातर शिपर्स भारी रूप से खंडित हैं—जैसे 95वें परसेंटाइल... माफ कीजिए, कैरियर्स। और कैरियर्स ट्रकिंग कंपनियाँ होती हैं, जिनके पास एक या अधिक ट्रक होते हैं। कैरियर्स बहुत खंडित हैं और 95वें परसेंटाइल वाला कैरियर लगभग दो या तीन ट्रक रखता है। तो शिपर्स उनके साथ ब्रोकर्स के माध्यम से जुड़ते हैं, और ब्रोकर्स 1980 के दशक की तकनीक का उपयोग करते हैं—फोन और फैक्स मशीनें। Convoy में हम एक नए दृष्टिकोण—डिजिटल फ्रेट—को आगे बढ़ा रहे हैं, जहाँ हम तकनीक, विशेष रूप से डेटा साइंस का उपयोग करके पूरी प्रक्रिया को सबके लिए बेहतर बना रहे हैं, क्योंकि सही कैरियर को सही शिपर के लोड से मिलाना बहुत महत्वपूर्ण है—तभी सबकुछ बेहतर तरीके से काम करता है। इसलिए हमें इसका दाम तय करना, मैच करना और पूरी प्रक्रिया को ऑटोमेट करना है—और यही उद्योग की कॉस्ट स्ट्रक्चर में क्रांति ले आएगा। आप सभी जो सुन रहे हैं—आप उपभोक्ता भी हैं—जो चीज़ें आप खरीदते हैं, उनमें से अधिकांश आपके पास पहुँचने से पहले आठ या दस ट्रक यात्राएँ करती हैं। तो अगर हम फ्रेट की लागत कम कर सकें, तो उम्मीद है कि आपकी खरीदी जाने वाली चीज़ों की कीमतें और अधिक प्रतिस्पर्धी हो जाएँगी।
Hugo: तो जमीन पर यह कैसा दिखता है—कैरियर्स यानी ड्राइवर्स के लिए?
Ben: कैरियर्स... यह परिभाषा थोड़ी जटिल है क्योंकि कई मालिक-ऑपरेटर होते हैं—एक तरह से अमेरिकन ड्रीम। उदाहरण के लिए, यहाँ पैसिफिक नॉर्थवेस्ट में, वे एक रूसी प्रवासी हो सकते हैं जो यहाँ कुछ भी लिए बिना आते हैं और फिर मालिक-ऑपरेटर बनने तक एक ट्रक से शुरुआत करते हुए ऊपर चढ़ते हैं, और जैसे-जैसे वे सफल होते हैं, वे अपना फ़्लीट बढ़ा सकते हैं—और यही वह चीज़ है जिसमें Convoy मालिक-ऑपरेटर्स की मदद करना चाहता है। या फिर यह एक अधिक स्थापित, मझोली ट्रकिंग कंपनी हो सकती है। आमतौर पर उनके पास एक या अधिक ट्रक होते हैं। किसी व्यक्ति के लिए लगभग 20 ट्रकों से अधिक स्केल करना कठिन होता है क्योंकि फिर लॉजिस्टिक्स जटिल हो जाती है और एचआर वगैरह से निपटना पड़ता है।
Hugo: बिलकुल। तो कैरियर्स के लिए ज़मीन पर Convoy कैसा दिखता है? क्या वे ऐप्स का उपयोग करते हैं या...
Ben: हाँ, यह बहुत अच्छा प्रश्न है। वे हमसे मुख्यतः Convoy ऐप के माध्यम से इंटरैक्ट करते हैं, और हमारे पास एक ऑनबोर्डिंग प्रक्रिया है जो उन्हें अपनी जानकारी का पैकेट देना बहुत आसान बना देती है—जैसे बीमा और लाइसेंसिंग संबंधी जानकारी—और फिर हम उनका अकाउंट सक्रिय कर सकते हैं। उस बिंदु पर, वे उन्हें ऐसे ऑफ़र्स दिखेंगे जो उस प्रकार के लोड के आधार पर सर्व किये जाते हैं, जिन्हें वे हमें बताते हैं कि उन्हें पसंद है। जैसे वे कह सकते हैं, "अरे, मैं I-5 कॉरिडोर पर काम करना पसंद करता हूँ," और फिर वे इन-ऐप उन लोड्स को स्वीकार कर सकते हैं और किसी इंसान से बात करने की ज़रूरत नहीं। यानी यह बहुत कुशल है।
वे लोड्स पर बोली भी लगा सकते हैं। तो अगर उन्हें हमारी कीमत पसंद नहीं आती, या वे किसी लोड के लिए अन्य कैरियर्स के साथ प्रतिस्पर्धा कर रहे हैं, तो वे बोली लगा सकते हैं; बाज़ार की स्थिति के अनुसार कीमत ऊपर-नीचे हो सकती है। और एक और चीज़ जो हम उनके लिए बढ़िया करते हैं, वह यह कि मान लीजिए वे San Francisco से Los Angeles तक एक लोड ले जाते हैं, तो अगर हम देखते हैं कि उन्होंने यह किया है तो हम कहते हैं, "अरे, हमारे पास Los Angeles से वापस वहाँ जाने या कहीं और जाने का लोड है।" यानी हम इसके प्रति जागरूक हैं, ताकि उन्हें लगातार चलते और कमाते रखें—ताकि वे कम बार खाली चलें, क्योंकि पता चलता है कि ट्रक लगभग 40% समय खाली चलते हैं—जो पर्यावरण और ट्रकर, दोनों के लिए बुरा है।
Hugo: हाँ, मैं कल्पना कर सकता हूँ कि आप तरह-तरह की ट्रैवलिंग सेल्समैन समस्याएँ सुलझाने की कोशिश कर रहे हैं—आप अनिवार्य रूप से यह नहीं चाहेंगे कि कोई ड्राइवर Seattle से Bay Area तक खाली ट्रक चलाए और फिर वहाँ से कहीं और चीज़ें ले जाए। आप चाहेंगे कि उनका सफ़र इस लिहाज़ से ऑप्टिमाइज़ हो कि वे कितना लेकर जा रहे हैं?
Ben: हाँ, बिल्कुल। जैसे-जैसे हमारे प्लेटफ़ॉर्म पर लिक्विडिटी बढ़ेगी, इन तरह की समस्याओं को सुलझाना और आसान होता जाएगा और कैरियर्स को लगभग निरंतर गति की अवस्था में रखना संभव होगा।
Hugo: यह वाकई शानदार है। मुझे यह इसलिए भी बहुत दिलचस्प लगता है क्योंकि जब हम आधुनिक उद्योग में डेटा साइंस की भूमिका के बारे में सोचते हैं, तो ज़्यादातर समय टेक के बारे में सोचते हैं—एक ऐसा उद्योग जो डेटा तक बढ़ती पहुँच के साथ पैदा हुआ था। जबकि आप ऐसे उद्योग में क्रांति लाने की बात कर रहे हैं जो इस पूरी तकनीकी अवसंरचना से पहले का है।
Ben: बिल्कुल। और अगर हम जो करने की कोशिश कर रहे हैं, उसमें सफल होते हैं, तो हम एक बड़े उद्योग की कॉस्ट स्ट्रक्चर बदल देंगे, जो बहुत से अमेरिकियों को प्रभावित करता है। Convoy में मैंने जो अद्भुत तथ्य सीखा, वह यह है कि लगभग 45 राज्यों में सबसे आम नौकरी ट्रक ड्राइवर की है। तो यह बहुत से लोगों को उनकी रोज़गार की दृष्टि से प्रभावित करता है, और साथ ही हर उपभोक्ता को भी। यह बहुत से लोगों के जीवन पर सकारात्मक प्रभाव डाल सकता है—खासकर ट्रक ड्राइवर्स के लिए—हम उनके लिए अपना व्यवसाय चलाना, उसे बढ़ाना और बहुत कम घर्षण के साथ उसे संचालित करना आसान बना रहे हैं।
Convoy में डेटा साइंस
Hugo: ज़रूर। तो Convoy के मिशन में डेटा साइंस अहम भूमिका कैसे निभाता है?
Ben: डेटा साइंस हमारे काम का केंद्र है। वास्तव में, जिस दिन से हमने शुरुआत की, हम ऑटोमेटेड रहे हैं। हमें अर्थशास्त्र से जुड़े ढेर सारे दिलचस्प समस्याओं को सुलझाना है—इसलिए कीमत का पूर्वानुमान लगाना बहुत महत्वपूर्ण है क्योंकि हमें शिपर्स के लिए सही प्राइस करना होता है—अक्सर हम उनसे दीर्घकालिक अनुबंध करते हैं—और हमें कैरियर्स के लिए भी सही प्राइस करना होता है। फिर हमें मैचिंग समस्या हल करनी होती है—सही कैरियर को सही लोड से मिलाना—क्योंकि इससे सभी के लिए बेहतर परिणाम मिलते हैं। उदाहरण के लिए, "सही" का मतलब हो सकता है कम डेडहेड स्पेस—यानी लोड शुरू होने की जगह तक खाली चलकर जाना—और डेस्टिनेशन एंडपॉइंट्स भी मायने रख सकते हैं। हम नीलामियों और स्वयं कैरियर्स के लिए प्राइस स्वीकृति तंत्र पर भी सोचते हैं, तथा कैरियर लाइफसाइकल से संबंधित कई अन्य चीज़ों पर भी—और यह सुनिश्चित करते हैं कि एक बार कैरियर ने लोड उठा लिया तो सब ठीक चल रहा है। इस तरह की समस्याएँ बहुतायत में हैं।
Hugo: मुझे लगता है कि यह एक ऐसा बिज़नेस है जहाँ आपको चिकन-एंड-एग समस्या का सामना करना पड़ सकता है—इस अर्थ में कि शिपर्स को साथ लाने के लिए आपको कैरियर्स चाहिए, और कैरियर्स को साथ लाने के लिए शिपर्स।
Ben: हाँ, यह किसी भी प्लेटफ़ॉर्म के लिए बहुत कठिन होता है। हमारे सीरीज़ A राउंड के एक निवेशक Simon Rothman की एक बढ़िया पोस्ट है—उन्होंने लिखा कि आपको एक ही समय में दो कंपनियाँ शुरू करनी पड़ती हैं। यानी आपको सप्लाई और डिमांड—दोनों तरफ़—एक साथ बूटस्ट्रैप करना होता है, और इसे बैलेंस में रखना बहुत मुश्किल होता है।
तो, सौभाग्य से, हमारे पास एक अद्भुत सेल्स टीम है—वे क्वालिटी डिमांड उत्पन्न करने में बहुत अच्छी हैं—और फिर हम जल्दी से सप्लाई बनाते हैं ताकि सबकुछ संतुलन में रहे, और यह ऐसी चीज़ है जिसे हम ट्रैक करते हैं। कोई भी प्लेटफ़ॉर्म इसको लेकर चिंतित रहता है—वे लिक्विडिटी और संतुलन बनाए रखने के बारे में बहुत सोचते हैं। जैसे—अगर आप डेटिंग साइट पर जाएँ और मान लें कि आप हेटेरोसेक्शुअल हैं—और वहाँ महिलाएँ नहीं हैं—तो यह एक खराब डेटिंग अनुभव होगा। इसलिए आपको पुरुषों और महिलाओं की संख्या में संतुलन चाहिए।
Hugo: यह मेरे दिमाग में इसलिए भी है क्योंकि DataCamp में शुरुआती दिनों में हमें भी ऐसी ही चुनौती का सामना करना पड़ा—छात्रों को लाना और साथ ही इंस्ट्रक्टर्स को भी—क्योंकि इंस्ट्रक्टर्स को ऑडियंस चाहिए और छात्रों को बेहतरीन इंस्ट्रक्टर्स, है न?
Ben: हाँ, बिल्कुल। और एक और बात यह है कि नेटवर्क इफ़ेक्ट्स भी होते हैं। तो एक बार जब यह चल पड़ता है, तो ये बिज़नेस एक्सपोनेंशियली बढ़ने लगते हैं—यह बहुत रोमांचक है। इसका मतलब है कि अगर आप यह सही तरीके से करते हैं, तो आप पाएँगे कि आप सो नहीं रहे।
Hugo: बिल्कुल। आपने कहा कि सबसे महत्वपूर्ण चीज़ों में से एक बहुत मजबूत सेल्स टीम है। उदाहरण के लिए, सेल्स टीम के संदर्भ में—डेटा साइंस टीम कंपनी में कैसे इंटीग्रेटेड है?
Ben: हाँ। मेरा मानना है कि हम उनके साथ सबसे बड़ी मदद प्राइसिंग समझने में कर सकते हैं—जैसे किस तरह लोड्स पर बोली लगानी है, किन लोड्स पर बोली लगानी चाहिए—और इस तरह हम उनके साथ बहुत नज़दीकी से काम करते हैं। प्राइसिंग अत्यंत जटिल चीज़ है और इसके आसपास तरह-तरह के इंसेंटिव्स होते हैं—इसे खोलने में घंटे लग जाएँगे।
Hugo: हम डेटा साइंस की भूमिका के इर्द-गिर्द बात कर रहे हैं। ऐसे कौन से विशिष्ट डेटा साइंस प्रश्न हैं जिनका उत्तर आपको अपनी नौकरी में देना पड़ता है?
Ben: Convoy की संस्कृति की एक अच्छी बात यह है कि हम बहुत डेटा-ड्रिवन हैं—और हम बहुत सारे प्रयोग करते हैं—जैसे कि मैं मानता हूँ उद्योग में हर कोई—या कम से कम शीर्ष खिलाड़ी। तो हम अक्सर प्रश्नों का उत्तर प्रयोगों के माध्यम से देते हैं—और यही एकमात्र तरीका है। इसलिए हम बहुत प्रयोग करते हैं। हमने बहुत अच्छे प्रयोग ढाँचे (एक्सपेरिमेंटेशन फ़्रेमवर्क) के निर्माण में निवेश किया है जिससे हम तेज़ी से प्रयोग दोहरा सकें। A/B टेस्ट चलाने के अलग-अलग तरीके हैं—जैसे Bayesian या frequentist—और Bayesian या सीक्वेंशियल विश्लेषण आपको अधिक तेज़ी से उत्तर दे देता है। यह प्रोडक्ट मैनेजर्स के साथ परिणामों पर चर्चा करना भी आसान बनाता है।
A/B परीक्षण
Hugo: थोड़ा पीछे चलते हैं—क्या आप किसी A/B टेस्ट का उदाहरण दे सकते हैं जो आप करते हैं?
Ben: बढ़िया। जिस तरह की चीज़ों का आप आमतौर पर A/B टेस्ट करेंगे, वह यह है कि क्या कोई नया UX फ्लो बेहतर काम करता है? तो मान लीजिए... हम जिन चीज़ों की परवाह करते हैं उनमें से एक है कि जब कोई ड्राइवर ट्रिप पूरी करता है तो वे अपने काग़ज़ात अपने-आप अपलोड कर दें—इसे BOL, bill of lading कहते हैं। अगर हम इसे बेहतर और आसान बनाने के लिए कोई नई प्रक्रिया रोलआउट करते हैं, तो हम एक प्रयोग चला सकते हैं—जिसमें आधे कैरियर्स को पुरानी तकनीक पर रखें और आधे को नई तकनीक पर—और फिर कुछ समय बाद हम किसी संभावना के साथ कह सकते हैं कि नई प्रक्रिया बेहतर काम करती है या नहीं।
Hugo: यह A/B टेस्टिंग का बढ़िया उदाहरण और वर्णन है। मैं थोड़ा और पूछूँगा—आपने कहा Bayesian तरीकों से frequentist तरीकों की तुलना में परिणाम जल्दी मिलते हैं। मैं आपको ऑन-द-स्पॉट रख रहा हूँ, लेकिन क्या आप आम लोगों के लिए संक्षेप में बता सकते हैं—frequentist सांख्यिकी, जिससे लोग अधिक परिचित हो सकते हैं, और यहाँ जिन Bayesian तरीकों की आप बात कर रहे हैं—उनमें अंतर क्या है?
Ben: अवश्य। सांख्यिकी के लिए पहला वास्तविक दृष्टिकोण Bayesian पद्धति था—जिसे Thomas Bayes ने विकसित किया था—वे दरअसल एक विकर थे। उनका विचार बहुत हद तक आपकी अंतर्ज्ञान की तरह काम करता है—आप किसी चीज़ के बारे में पूर्व मान्यताओं से शुरू करते हैं—जैसे मेरी नई प्रक्रिया बेहतर है—मान लीजिए इससे 10% लिफ्ट होगी। फिर समय के साथ जैसे-जैसे आप डेटा देखते हैं, आप उन मान्यताओं को अपडेट करते हैं। यह Bayesian अपडेटिंग अंततः जिसे हम posterior कहते हैं, पर अभिसरित हो जाती है—और वह वह वितरण है जिसकी हम उम्मीद करते हैं कि लिफ्ट होगी।
Frequentist दृष्टिकोण... Frequentist पर जाने से पहले—Bayesian तरीकों की गणना करना दो दशक पहले तक बहुत कठिन था। हमारे पास कम्प्यूटेशनल संसाधन पर्याप्त नहीं थे। तब से बहुत बड़े सुधार हुए हैं और इन मॉडलों की गणना करना आसान हो गया है। उससे पहले आप केवल विशेष मामलों को हल कर पाते थे। इसलिए R.A. Fisher जैसे लोग Bayesian दृष्टिकोण के आलोचक थे, और उन्होंने 1900 के शुरुआती वर्षों में frequentist दृष्टिकोण विकसित किया—अगर मैं सही हूँ। वहाँ विचार यह है कि पैरामीटर का कोई सच्चा मान है—और अगर मैं पर्याप्त डेटा सैंपल करूँ, तो जैसे-जैसे डेटा बढ़ता जाएगा, वह सच्चाई की ओर अभिसरित होगा।
तो frequentists P-वैल्यूज़ और कॉन्फिडेन्स इंटरवल्स की बात करते हैं—और यह वही पारंपरिक हाइपोथेसिस टेस्टिंग है जिसे आप जानते हैं। Frequentist दुनिया में, आपको मार्केटिंग मैनेजर के पास जाकर कहना होगा, "शून्य परिकल्पना के सत्य होने की शर्त पर, जितना बड़ा प्रभाव मैंने देखा या उससे बड़ा प्रभाव देखने की संभावना 5.7% है।" फिर बहस होगी क्योंकि पारंपरिक दृष्टि में 5% का सिग्निफिकेंस स्तर रखने से परिणाम को सिग्निफिकेंट कहा जाता है। तो इस मामले में, अगर आप अच्छे व्यक्ति हैं, तो आप शून्य परिकल्पना को रद्द नहीं करेंगे—लेकिन आपका मार्केटिंग मैनेजर कह सकता है, "5.7% तो 5% के काफ़ी क़रीब है, क्यों न 10% सिग्निफिकेंस स्तर ले लें।" और आप इस परेशानी में होंगे। जबकि Bayesian पद्धति में आप प्रोडक्ट मैनेजर से कह सकते हैं, "वेरिएंट A के वेरिएंट B से बेहतर होने की संभावना 94.3% या 98% है,"—और यह बातचीत करना कहीं आसान होता है।
Hugo: जिस उदाहरण की आप बात कर रहे हैं, वेरिएंट A और वेरिएंट B—or जो पैरामीटर हम देख रहे हैं—वह यह होगा कि कितने लोग सफलतापूर्वक अपने सारे काग़ज़ात अपलोड करते हैं?
Ben: सही।
Hugo: जो भी UX दिखता है, उसके एक फ़ंक्शन के रूप में।
Ben: हाँ। यानी जो भी आप टेस्ट कर रहे हैं—जैसे क्या मेरा नया वर्कफ़्लो उच्च क्लिकथ्रू रेट देता है या अधिक चेकआउट? क्या यह churn घटाता है? जो भी आपकी रुचि हो। तो हाँ। मुझे लगता है Bayesian पद्धति प्रोडक्ट मैनेजर्स के साथ बातचीत को आसान बनाती है—और इसके अलावा... हमारी सिमुलेशन स्टडीज़ में, हमें यह हमारी बिज़नेस के लिए कहीं जल्दी अभिसरित होता दिखा। आपकी बिज़नेस में आपका अनुभव अलग हो सकता है—and अगर आप यूरोप में हैं तो आपके किलोमीटर बदल सकते हैं।
Hugo: मुझे याद है Dave Robinson ने Stack Overflow के लिए Bayesian A/B टेस्टिंग पर कई पोस्ट लिखे थे—और दिखाया था कि उनके प्रयोगों के लिए यह आवश्यक नहीं कि अधिक तेज़ी से अभिसरित हो। मुझे यह जाँचना होगा, और हम उसे शो नोट्स में डाल सकते हैं।
Ben: हाँ। Evan Miller के कुछ बेहतरीन ब्लॉग पोस्ट भी इस विषय पर हैं।
अन्य डेटा साइंस तकनीकें और तरीके: इकोनोमेट्रिक्स और मशीन लर्निंग
Hugo: आपने प्रायोगिक डिज़ाइन का ज़िक्र किया। यह बहुत रोचक दृष्टिकोण है, क्योंकि मुझे नहीं लगता कि बहुत से लोग उम्मीद करेंगे कि प्रायोगिक डिज़ाइन और इस प्रकार की पद्धतियाँ डेटा साइंस का उपयोग करके ट्रकिंग उद्योग को फिर से आविष्कार करने में इतनी बड़ी भूमिका निभाएँगी। आप लोग और किन तकनीकों और तरीकों में रुचि रखते हैं?
Ben: हाँ, आगे बढ़ने से पहले A/B टेस्टिंग को बंद करते हुए—ट्रकिंग उद्योग के बारे में बहुत सी सामूहिक बुद्धि है। हमारी कंपनी आधी टेक स्टार्टअप है और आधी ट्रकिंग उद्योग के दिग्गज—और उनके पास बहुत मेहनत से कमाया ज्ञान और अंतर्ज्ञान है—पर वह हमेशा सही या सटीक नहीं होता। तो प्रयोग करके हम चीज़ों को कहीं अधिक ठोस बना सकते हैं।
Hugo: क्या इसमें राजनीतिक और सामाजिक पहलू भी है—यह अर्थ कि बहुत लोग लंबे समय से यहाँ हैं, उनके पास शक्ति और कठिन परिश्रम से अर्जित ज्ञान है—और धारणा यह है कि टेक स्टार्टअप्स आकर, उद्धरण-चिह्न में, इसे "डिसरप्ट" कर सकती हैं—और इसे ध्यान में रखते हुए सामाजिक व्यवहार की ज़रूरत होती है?
Ben: हाँ। मैं Convoy की संस्कृति की सीमा में ही बोल सकता हूँ—और यहाँ हमारी टीम-ओरिएंटेड संस्कृति बहुत बढ़िया है। यह वैसा लगता है जैसे जब मैं अच्छी हॉकी टीमों में खेलता था। दोनों पक्ष अपने-अपने योगदान की कद्र करते हैं। आप दो उद्योग दिग्गजों को भी देख सकते हैं जो किसी चीज़ पर सहमत न हों। तो Convoy में हम कोशिश करते हैं कि ऐसे मतभेद न रहें जिन्हें... चलिए फिर से कहता हूँ—अगर कोई मतभेद किसी सैद्धांतिक बहस या तथ्यों से हल नहीं हो सकता, तो हम एक प्रयोग चलाते हैं—बजाए इसके कि ऐसी बहस में बैठे रहें जिसका समाधान न हो।
Hugo: और क्या? आप लोग और किन तकनीकों और कार्यप्रणालियों का उपयोग करने में रुचि रखते हैं?
Ben: हाँ, हम व्यावहारिक, एप्लाइड डेटा साइंस शॉप हैं। हम कम समय में ठोस व्यावसायिक समस्याओं को सुलझाने की कोशिश करते हैं। तो हम वही मानक टूलकिट उपयोग करते हैं जिसकी अपेक्षा आप करेंगे। हम टूल्स के बारे में काफी आग्नॉस्टिक हैं—लोग काम के लिए सबसे अच्छे टूल का उपयोग करते हैं—तकनीक के लिहाज़ से वह R या Python हो सकता है—दोनों की ताकतें और कमजोरियाँ हैं—दोनों आना अच्छा है। फिर विशिष्ट दृष्टिकोणों में, कभी मशीन लर्निंग सर्वोत्तम होती है—खासकर जब हमें किसी चीज़ का पूर्वानुमान लगाना हो—जैसे कोई BOL अपलोड करेगा या नहीं, या मान लीजिए अच्छा कैरियर होगा या नहीं—तो आप लॉजिस्टिक रिग्रेशन या कोई बूस्टेड क्लासिफ़ायर बना सकते हैं। लेकिन अन्य समयों में आपको समझना होता है कि A ने B का कारण बना या नहीं—शायद हम प्रयोग नहीं चला पाए—तो हम फिर एप्लाइड स्टैटिस्टिक्स की दुनिया में होंगे और किसी तरह का रिग्रेशन विश्लेषण करेंगे। Convoy में मेरा पहला विन यही था कि मेरे शुरू होने से पहले उन्होंने बिना A/B टेस्ट के एक फीचर रिलीज़ किया था—और वे जानना चाहते थे कि यह नया फीचर मददगार था या नहीं—और मैं Google द्वारा विकसित causal impact पैकेज का उपयोग करके—Bayesian स्ट्रक्चरल टाइम सीरीज़ से—दिखा सका कि नए फीचर का सकारात्मक प्रभाव पड़ा।
Hugo: शानदार। और वह पहले से एकत्र डेटा पर था?
Ben: हाँ। हमारे पास मौजूदा डेटा था—और फिर आपको यह सुनिश्चित करने की कोशिश करनी होती है कि सब कुछ संभव हो तो रैंडम असाइनमेंट जैसा हो। एक प्रयोग के लिए प्रमुख शर्तों में से एक—रैंडम असाइनमेंट टू ट्रीटमेंट—और कुछ और चीज़ें भी संतुष्ट करनी होती हैं—जैसे आपका असाइनमेंट individualistic, probabilistic और unconfounded हो। ये तकनीकी शब्द हैं। अगर इनमें से कोई भी विफल हो जाता है, तो आप प्रेक्षणीय (observational) डेटा की दुनिया में होते हैं—और फिर आप एप्लाइड स्टैटिस्टिकल मेथड्स या इकोनोमेट्रिक्स का उपयोग करके कुछ ऐसा बनाते हैं जो रैंडम असाइनमेंट जितना अच्छा हो—ताकि आप कारणात्मक वक्तव्य दे सकें कि A ने B का कारण बना या नहीं।
Hugo: मुझे याद दिलाएँ कि इकोनोमेट्रिक्स क्या है?
Ben: ओह, इकोनोमेट्रिक्स वे सांख्यिकीय औज़ार हैं जो अर्थशास्त्रियों ने आर्थिक समस्याओं से निपटने के लिए विकसित किए हैं। बिज़नेस दुनिया के लिए ये औज़ार बहुत उपयोगी हैं क्योंकि हमारी अधिकांश समस्याएँ आर्थिक प्रकृति की होती हैं। एक क्लासिक उदाहरण सैंपल सेलेक्शन और एंडोजेनेइटी के अन्य रूपों से निपटना है—जहाँ आउटकम्स मॉडल के भीतर सह-निर्धारित (co-determined) होते हैं। क्लासिक उदाहरण—अगर आप समझना चाहते हैं कि पुलिस फोर्स का आकार बढ़ाने से अपराध घटता है या नहीं—तो आप सोच सकते हैं कि अपराध शायद पुलिस की मात्रा का फ़ंक्शन है—पर पुलिस भी अपराध के स्तर का फ़ंक्शन है। यानी यह एक साथ-समय (simultaneity) का उदाहरण है। सैंपल सेलेक्शन—एक बार जब आप इसे देखना शुरू करते हैं—हर जगह दिखता है—जैसे मैं यह प्रयोग चलाता हूँ कि क्या छोटे क्लास साइज़ से पढ़ने-समझने की क्षमता बेहतर होती है, लेकिन जो अमीर माता-पिता हैं, वे ज़िद करते हैं कि उनके बच्चे छोटे क्लास में हों—तो अब छोटे क्लास में अधिक होनहार बच्चे हैं—और अब आपके पास सेलेक्शन बायस है।
Hugo: तो इकोनोमेट्रिक्स ने इन चुनौतियों से निपटने के लिए ढेरों औज़ार बनाए हैं?
Ben: हाँ। विशेष रूप से, एक टूलसेट ऐसा है जो अर्थशास्त्रियों को तो अच्छी तरह ज्ञात है पर अर्थशास्त्र के बाहर डेटा साइंटिस्ट्स को कम—और वह है पैनल डेटा। ये औज़ार उस चीज़ से निपटने में बहुत अच्छे हैं जिसे अर्थशास्त्री individual heterogeneity कहते हैं। तो अगर मैं कैरियर्स या शिपमेंट्स के व्यवहार को देख रहा हूँ—इनमें व्यक्तिगत विचित्रताएँ होती हैं जिन्हें मैं देख नहीं पाता—और अगर मैं किसी कैरियर को समय के साथ देख सकूँ, तो पैनल डेटा मुझे बेहतरीन तरीके देता है इन अनदेखे व्यक्तिगत प्रभावों को हटा देने के—जो मेरे अनुमानों को भ्रमित कर सकते हैं।
Hugo: यह बहुत दिलचस्प है। ऐसा लगता है—अगर मैं गलत हूँ तो सुधारें—कि आपका कहना है कि इकोनोमेट्रिक्स में बहुत से होशियार लोगों ने ढेरों औज़ार विकसित किए हैं—जिनका उपयोग डेटा साइंस में किया जा सकता है—पर अभी इस दुनिया में उनकी उतनी चर्चा नहीं है?
Ben: हाँ। मुझे मशीन लर्निंग बहुत पसंद है—यह शानदार है—पर ऐसे मसले भी हैं जहाँ यह काम नहीं करती—और मुझे लगता है लोग मशीन लर्निंग पर इतना केंद्रित हो जाते हैं कि इकोनोमेट्रिक तरीकों की अनदेखी कर देते हैं—जो अक्सर बहुत उपयोगी होते हैं और ऐसे समस्याएँ सुलझा सकते हैं जिन्हें मशीन लर्निंग नहीं सुलझा सकती। मैं Uber में किसी से बात कर रहा था—Convoy में जुड़ने से पहले—उन्होंने कहा कि उन्होंने ऐसे मुद्दे देखे जिन्हें वे मशीन लर्निंग से हल नहीं कर सके—सिर्फ़ स्ट्रक्चरल इकोनोमेट्रिक मॉडल बनाकर हल कर सके—जो बहुत जटिल प्रक्रिया है—एक अच्छा मॉडल बनाने में एक साल या उससे अधिक लग जाता है। आप पूरे बिहेवियर प्रोसेस और यूटिलिटी फ़ंक्शन को मॉडल करने की कोशिश करते हैं—लेकिन जब आप हो जाते हैं—तो आपके पास बहुत समृद्ध और शक्तिशाली मॉडल होता है—जहाँ आप काउंटर-फ़ैक्चुअल आउटकम्स पर अच्छे पूर्वानुमान लगा सकते हैं।
Hugo: बढ़िया। और यह Uber में था, आपने कहा?
Ben: हाँ। यह मेरे इंटरव्यू के दौरान सामने आया—मैंने Convoy से पहले Uber में इंटरव्यू दिया था।
जियोस्पैशियल डेटा, क्वालिटी और सेल्फ-ड्राइविंग कारें
Hugo: ऐसा भी लगता है... हमने मशीन लर्निंग, इकोनोमेट्रिक्स, प्रायोगिक डिज़ाइन और A/B टेस्टिंग के लिए Bayesian विधियों पर बात की। लगता है आपके पास बहुत सारा भौगोलिक डेटा—जियोस्पैशियल डेटा—और समय-श्रृंखला के रूप में जियोस्पैशियल डेटा है। क्या यह आपके किसी काम में भूमिका निभाता है?
Ben: हाँ। यह डेटा बहुत महत्वपूर्ण है और हम अभी इसकी क्षमता को खोलना शुरू ही कर रहे हैं—लेकिन हम इसे ऐप में कई तरीकों से कैरियर्स का अनुभव बेहतर बनाने के लिए उपयोग करते हैं। उदाहरण के लिए, जब कोई कैरियर लोड पिक करने पहुँचता है, तो हम जियोस्पैशियल डेटा के आधार पर उन्हें स्वतः चेक-इन कर सकते हैं। कुछ लोडिंग सुविधाएँ बहुत खराब होती हैं—और अगर वे ट्रक को बहुत देर तक इंतज़ार कराती हैं, तो उन्हें detention नाम की चीज़ चुकानी पड़ती है। तो हम कैरियर के पात्र होते ही उनको detention का ऑटो-पेमेंट शुरू कर सकते हैं—उन्हें लंबी-चौड़ी डॉक्यूमेंटेशन प्रक्रिया से नहीं गुज़रना पड़ता—जो अमेरिका में इंश्योरेंस क्लेम फ़ाइल करने जैसा है।
Hugo: जब आपने कहा कि हमारे पास इतना डेटा है जिसे शायद आपने अभी पूरी क्षमता में नहीं खंगाला, तो मेरे दिमाग में आया कि इस डेटा के ज़रिए तरह-तरह के सामाजिक शोध की भी संभावनाएँ हो सकती हैं?
Ben: हाँ। मुझे लगता है हम मैचिंग, प्लेटफ़ॉर्म्स और नीलामियों पर बहुत से रोचक प्रश्नों का उत्तर दे सकते हैं—जिन पर मैं और गहराई से जाना चाहूँगा। मुझे यक़ीन है कि इस विषय पर कई अकादमिक पेपर लिखे जा सकते हैं।
Hugo: Convoy में विशेष तौर पर किन डेटा साइंस प्रोजेक्ट्स में आप शामिल रहे हैं—जो आपको समाज पर सबसे अधिक प्रभावकारी या उसके बारे में सबसे अधिक बताने वाले लगते हैं?
Ben: अच्छा प्रश्न है। मैं Convoy में एक साल से थोड़ा अधिक समय से हूँ—और कंपनी को दो साल से कुछ अधिक हुए हैं। मैंने मुख्यतः प्राइसिंग और एक्सपेरिमेंटेशन पर फोकस किया है। मुझे लगता है सबसे दिलचस्प प्रयोगों में से एक जो हमने चलाया—वह मेरे शुरू होने के तुरंत बाद था—जहाँ हमने उच्च-गुणवत्ता वाले कैरियर्स को लोड्स तक प्राथमिक पहुँच दी—और क्वालिटी नीचे चली गई। हर कोई चौंक गया—अरे, हम उच्च-गुणवत्ता वाले लोगों को काम तक जल्दी पहुँच दे रहे हैं और क्वालिटी घट रही है? क्या हो रहा है? इसका कोई मतलब नहीं। एक बुरा मैनेजर कहता, "अरे, तुम डेटा साइंटिस्ट, तुम बेवकूफ़ हो।" सौभाग्य से हमारे यहाँ एक बहुत अच्छे डेटा साइंस मैनेजर हैं—Ziad Ismail—जिन्होंने बढ़िया डेटा संस्कृति बनाई है। उन्होंने हमें इसमें गहराई से जाने दिया। तो मैंने इकॉनॉमिक्स की मैचिंग साहित्य के बारे में सोचना शुरू किया। मेरा परिकल्पना यह था कि क्योंकि हमने कैरियर्स के पूल को छोटा कर दिया था—भले ही वे उच्च-गुणवत्ता वाले थे—जॉब पर मैच क्वालिटी नीचे चली गई। हम इसे सत्यापित कर सके और फिर हमने रिग्रेशन विश्लेषण किया—जो दिखाता है कि मैच क्वालिटी का क्वालिटी पर कारणात्मक प्रभाव था। यह बहुत रोमांचक खोज थी—क्योंकि इससे पता चला कि हमारे प्लेटफ़ॉर्म पर मैचिंग कितनी महत्वपूर्ण है।
Hugo: अद्भुत। तो इसे अपने लिए स्पष्ट कर लूँ—उच्च-गुणवत्ता वाले कैरियर्स को लोड्स तक जल्दी पहुँच देने का मतलब यह हुआ कि उन्हें शिपर्स से मिलाने—मैचिंग एल्गोरिद्म—की क्वालिटी किसी अर्थ में घट गई—और उससे कैरियर्स की क्वालिटी में कमी आई?
Ben: हाँ। काम किस तरह अंजाम दिया गया, उसकी क्वालिटी—क्योंकि पात्र कैरियर्स का पूल छोटा था—और भले ही वे बेहतर थे—फिर भी मिलान के लिए संभावित लोगों की कम संख्या ने उनके उच्च-गुणवत्ता होने के तथ्य पर बढ़त ले ली।
Hugo: मेरा ख्याल है ब्राज़ील की कोई चींटी होती है, जिसमें 30%... मैं यह नहीं कह रहा कि यह प्रत्यक्ष अनुरूप है—पर मान लीजिए प्रत्येक कॉलोनी में 30% चींटियाँ कुछ नहीं करतीं। अगर आप उस 30% को हटा दें और एक दिन बाद लौटें, तो फिर से 30% चींटियाँ कुछ नहीं करतीं। मैं यह नहीं कह रहा कि वहाँ शिपर्स या कैरियर्स कुछ नहीं करते—पर कोई स्थिरीकरण-शक्ति जैसी चीज़ काम कर रही है। खैर, यह बहुत दिलचस्प है कि नतीजा उल्टा आया—जो सहज रूप से बेहतर क्वालिटी देनी चाहिए थी—उससे बदतर हुई।
Ben: हाँ। यह उत्कृष्ट उदाहरण है कि प्रयोग करना कितना महत्वपूर्ण है। जब हम यहाँ कोई प्रयोग चलाते हैं, तो हमने एक अच्छी परंपरा शुरू की—जहाँ लोग वोट करते हैं कि कौन-सा परिणाम जीतेगा। इससे पूरी कंपनी प्रयोगों में शामिल होती है—और आमतौर पर UX टीम विजेताओं को डोनट्स या कूल स्टिकर्स वगैरह देती है। हमारे पास ऐसे बहुत से प्रयोग रहे हैं जहाँ जो आप उम्मीद करते हैं, वह नहीं होता—क्योंकि किसी फीचर से प्रेम करना आसान होता है—जिसे आप शानदार मानते हैं—और वास्तविकता यह है कि ऐसा कुछ ढूँढना जो प्लेटफ़ॉर्म को आगे बढ़ाए—लगातार कठिन होता जाता है।
Hugo: एक अर्थ में इन प्रकार के प्रयोगों में—आप किसी तरह की प्रयोगशाला चला रहे हैं, है न?
Ben: हाँ, हम हैं—अपने व्यावसायिक प्रश्नों पर फोकस्ड।
Hugo: अगर यह कंपनी रणनीति या निजी सामग्री में बहुत घुसपैठ हो, तो मुझे बता दें। मैं बस यह जानना चाहता हूँ कि आप कैरियर्स की क्वालिटी—या किसी डिलिवरी की क्वालिटी—आदि का आकलन कैसे करते हैं?
Ben: ट्रकिंग में एक उद्योग-व्यापी समस्या है—लगभग 10% समय—जब कोई कैरियर किसी लोड को लेने के लिए प्रतिबद्ध होता है—तो वे बस नहीं आते—या आखिरी मिनट में बता देते हैं कि वे नहीं लेंगे—और आमतौर पर बहाना होता है कि मेरा ट्रक खराब हो गया। ट्रक 10% समय खराब नहीं होते। इसका मतलब होता है कि किसी ने उन्हें अधिक भुगतान वाला लोड ऑफ़र किया। कुछ कैरियर्स यह अक्सर करते हैं, और कुछ—मैंने उनका डेटा देखा है—जिन्होंने 100, 300 ट्रिप्स की हैं—और वे लगभग कभी फॉल ऑफ़ नहीं करते। तो फॉल ऑफ़—हम क्वालिटी मापने के लिए जिन प्रमुख घटकों का उपयोग करते हैं—उनमें से एक है—क्योंकि जब यह होता है तो यह हमारे लिए बेहद महँगा पड़ता है—क्योंकि हम शिपर्स को बहुत उच्च-गुणवत्ता वाला शिपिंग अनुभव देने के लिए प्रतिबद्ध हैं—और फिर हमें आखिरी मिनट में कोई और ट्रक ढूँढना पड़ता है—जो लोड कवर करे—और यह बहुत महँगा है।
Hugo: यह समझ में आता है। क्या आपकी कंपनी में सेल्फ-ड्राइविंग कारों या सेल्फ-ड्राइविंग ट्रक्स के आगमन के संदर्भ में कोई विचार-विमर्श होता है?
Ben: हाँ। मैं बस जोड़ दूँ कि क्वालिटी के लिहाज़ से हम और भी चीज़ें सोचते हैं—जैसे—
Hugo: ओह please, हाँ।
Ben: ड्राइवर का ऑन-टाइम परसेंटेज—हम कोशिश करते हैं कि वे ऐप का उपयोग करें—यह बहुत महत्वपूर्ण है—क्योंकि इससे हम compliance और safety में लागत घटा सकते हैं। ये सब बहुत महत्वपूर्ण हैं—लेकिन जिस विशिष्ट प्रयोग का मैंने ज़िक्र किया, उसमें फॉल ऑफ़ मुख्य चीज़ थी जिसकी मुझे फिक्र थी। हमें यह भी मिलता है कि अगर हम कैरियर्स को ऐप का उपयोग शुरू करने पर ला सकें—तो तरह-तरह की अच्छी चीज़ें होती हैं और संभव हो जाती हैं। तो डेटा साइंटिस्ट्स के तौर पर हम एक और बहुत ही इकॉनॉमिक्स-टाइप की चीज़ करते हैं—यानी प्लेटफ़ॉर्म पर इंसेंटिव्स को इस तरह स्ट्रक्चर करना—कि हमें वांछित व्यवहार मिले। उदाहरण के लिए—अगर कोई कैरियर ऐप का उपयोग करता है—तो उसे क्विक पे मिलता है। यानी हम उन्हें उसी दिन भुगतान कर देते हैं—जबकि उद्योग का मानक यह है कि कैरियर्स को काम करने के लगभग 30 दिन बाद भुगतान होता है—जिसका मतलब है कि वे आमतौर पर इस देयता को किसी फ़ैक्टरिंग कंपनी को बेचते हैं और अतिरिक्त 3% खो देते हैं। तो हम प्रभावी रूप से उन्हें 3% की वृद्धि दे रहे हैं—अगर वे... फ़ैक्टर के लिए लगभग 2-3%। तो अगर वे ऐप का उपयोग करते हैं—हम उन्हें 2-3% की वृद्धि दे रहे हैं।
Hugo: हाँ। यह बढ़ोतरी है—और इसका मतलब यह भी है कि उनके पास ज़्यादा लिक्विड असेट्स हैं, है न?
Ben: हाँ। मुझे नहीं पता आपके बारे में—पर जब मैं काम करता हूँ तो मुझे भुगतान मिलना पसंद है—और अगर मुझे 30 दिन इंतज़ार करना पड़े—तो यह सुखद अनुभव नहीं है। मुझे किराना, किराया और बाइक के पार्ट्स ख़रीदने हैं।
Hugo: सेल्फ-ड्राइविंग कारों और ट्रक्स के आगमन के संदर्भ में—क्या यह ऐसी चीज़ है जिस पर आप लोग Convoy में सक्रिय रूप से सोचते हैं?
Ben: हाँ। हम इस पर निश्चित रूप से सक्रिय रूप से सोचते हैं—और मुझे पता है फ़ाउंडर्स ने अपने नेटवर्क के ज़रिए इस पर बहुत समय बिताया है—और वे इससे बहुत जुड़े हुए हैं। अंततः, जब सेल्फ-ड्राइविंग ट्रक्स आएँगे—और यह शायद चरणबद्ध तरीके से होगा—जहाँ अलग-अलग स्तर का ऑटोमेशन होगा—उन्हें फिर भी फ्रेट से जुड़ना होगा—और हमारे पास एक प्लेटफ़ॉर्म है जो यह करता है। हमारा लक्ष्य होगा कि हम उसे प्लेटफ़ॉर्म की सप्लाई साइड में इंटीग्रेट कर दें।
डेटा साइंस में बहुपक्षीयता
Hugo: हम अब तक ट्रकिंग पर डेटा साइंस के प्रभाव की बात कर रहे थे—Convoy में आपके काम के संदर्भ में—और जैसा कि... हम डेटा साइंस के पास विभिन्न दिशाओं से पहुँचे हैं—यह स्पष्ट है कि इस अनुशासन में बहुत सी चीज़ें योगदान देती हैं—और आपके पास—आप कंप्यूटेशनल इकॉनॉमिस्ट, पूर्व-भौतिक विज्ञानी, और Amazon में पूर्व शोध वैज्ञानिक रहे हैं। मेरा प्रश्न है—ये सभी विधाएँ और इतिहास, डेटा साइंटिस्ट के रूप में आपकी भूमिका में कैसे योगदान देते हैं?
Ben: मेरा मानना है कि औज़ार कभी ज़्यादा नहीं होते। जब मैं युवा भौतिकविद था—मुझे सौभाग्य मिला—मैं John Wheeler के साथ काम करता था—और वे कहा करते थे—Niels Bohr को चैनल करते हुए—"जब तक आपको उत्तर न मालूम हो—कुछ उद्धृत मत करो।" यह एक प्रसिद्ध Wheelerism है—पर इसका मतलब यह है कि आपको अपने वैज्ञानिक प्रश्न के सही उत्तर का कुछ अंदाज़ा होना चाहिए। Feynman का एक प्रसिद्ध उदाहरण है—जहाँ Feynman आए और सोचा कि उन्होंने कुछ सिद्ध कर दिया—और Wheeler ने कहा—तुम गलत हो—और Feynman बहुत खीजे—क्योंकि Wheeler यह समस्या कैसे कर सकते हैं—Feynman ने अभी-अभी इसे पहली बार किया। Feynman की गणना में गलती थी। Wheeler का भौतिकी का ज्ञान इतना गहरा था कि उन्हें पता था—यह गलत होना चाहिए—यह समझ में नहीं आता। तो जैसे—अगर आप बाहर जाते हैं और अपने डायरेक्ट मेल कैंपेन पर लिफ्ट मापने के लिए कोई प्रयोग चलाते हैं—और 10% मिलता है—तो शायद यह गलत है। आप उम्मीद नहीं करेंगे कि यह सच हो। तो मुझे लगता है भौतिकी इस तरह बहुत मददगार है—जुगाड़ू बनने में और गणित—विशेषकर रैखिक बीजगणित—में दक्षता बनाने में। मेरा मानना है कि डेटा साइंस में सफलता के लिए रैखिक बीजगणित बेहद महत्वपूर्ण है—शायद कलन से भी ज़्यादा। अर्थशास्त्र ने मुझे व्यावसायिक समस्याओं पर सोचने के सैद्धांतिक औज़ार दिए—साथ ही इकोनोमेट्रिक्स के औज़ार—जिनसे आप सिद्धांत को डेटा से टकराते हैं। सॉफ्टवेयर इंजीनियरिंग में मेरे समय ने मुझे वह सॉफ़्टवेयर स्किल दी कि मैं सांख्यिकी को कोड में बदल सकूँ। आप जहाँ भी काम करें, उम्मीद है आप नए कौशल हासिल कर रहे होंगे—सीख रहे होंगे—यह डेटा साइंटिस्ट्स के लिए बेहद ज़रूरी है। साथ ही, सांस्कृतिक रूप से Amazon समस्याओं पर सोचने का बहुत परिपक्व तरीका सिखाता है—आवश्यकता का एहसास, प्रभाव पर फोकस—यह पीएचडी प्रोग्राम जैसा है—जहाँ आप दिन भर खुद से यह पूछना सीखते हैं—क्या जो मैं कर रहा हूँ वह मेरी पीएचडी पूरी कराएगा—और अगर जवाब ना है—तो आप गलत चीज़ पर काम कर रहे हैं।
Hugo: मुझे याद है आपने Data Science Pop-Up Seattle में Correctness in Data Science नाम की बहुत अच्छी बात कही थी। मुझे यह इसलिए पसंद आई क्योंकि आपने बताया कि किस तरह की गलतियाँ होती हैं—और हम एक सुव्यवस्थित अनुशासन बनाने के संदर्भ में—उन्हें कैसे सुधार सकते हैं—जो अभी एक अस्पष्ट मिश्रण है तकनीकों, अवधारणाओं और अनुप्रयोगों का। तो क्या आप बता सकते हैं कि आज आप डेटा साइंटिस्ट्स को कौन-सी बड़ी गलतियाँ करते देखते हैं?
Ben: मुझे खुशी है कि आपको वह बात पसंद आई।
Hugo: बहुत पसंद आई—और हम उसे शो नोट्स में भी डालेंगे—ताकि जो भी सुने वह देख सके।
Ben: बढ़िया। सबसे पहले, आशा है दर्शकों को यह पसंद आए—और मुझे लगता है वैज्ञानिक मॉडलों की शुद्धता बेहद महत्वपूर्ण है—और बहुत से लोग—खासकर शुरुआत में—सोचते हैं, ओह मेरा कोड सफलतापूर्वक चला—एक नंबर निकला—तो यह सही होगा। रुकिए। आपको सुनिश्चित करना चाहिए कि यह सही नंबर है। इसके बारे में सोचने के लिए एक एपिस्टेमोलॉजिकल फ़्रेमवर्क है—जो न्यूक्लियर इंडस्ट्री से निकला—जिसे verification, validation और uncertainty quantification कहा जाता है। मैं Robert Rosner—जो मेरे पोस्टडॉक सुपरवाइज़र और उससे भी बढ़कर Argonne के पूर्व निदेशक थे—का आभारी हूँ—जिन्होंने मुझे VV & UQ से परिचित कराया। VV & UQ के मूलतः तीन भाग होते हैं। पहला V—verification। यानी आपका कोड मॉडल को सही तरीके से लागू कर रहा है या नहीं—भले ही मॉडल सही हो या नहीं। इसका मतलब है—आपको यूनिट टेस्ट करने चाहिए—आप Monte Carlo तरीकों से सिंथेटिक डेटा—ज्ञात पैरामीटर्स के साथ—जेनरेट कर सकते हैं—और सुनिश्चित करें कि अपेक्षित परिणाम मिलते हैं—और इस तरह की चीज़ें करें—ताकि आपका कोड सही हो। Validation—यह सुनिश्चित करना कि आपके मॉडल की वास्तविकता से सुसंगति है—यानी बाद में प्रयोग चलाकर देखना कि आपका मॉडल वास्तविकता का सटीक प्रतिरूप है या नहीं। Uncertainty quantification—यह आपके मॉडल की सीमाओं के बारे में सोचना है—आपने क्या मान्यताएँ बनाई हैं? क्या वे लागू होती हैं? क्या कोई सुनामी आकर आपके न्यूक्लियर पावर प्लांट को धो सकती है? शायद आपको उसकी योजना बनानी चाहिए। तो ये कुछ बुनियादी बातें हैं। मुझे BI इंजीनियर्स से इंटरव्यू में पूछना पसंद है—आपको कैसे पता चलता है कि आपका SQL सही है—और वे आमतौर पर मुझे देखते हैं जैसे यह कोई अजीब सवाल है। पर SQL—या जो भी आप डेटा खींचने के लिए उपयोग कर रहे हैं—बहुत अहम है—क्योंकि अगर आपने कचरा डेटा सेट तैयार किया—तो बाद में आप जो भी करें—बेहतर नहीं होगा। चाहे आप कितनी भी फैंसी स्टैटिस्टिक्स कर लें—आप इस तथ्य को नहीं सुधार सकते कि आपने डेटा सही तरह असेंबल नहीं किया। इसलिए यह महत्वपूर्ण है कि डेटा असेंबल करते समय बहुत पद्धतिगत रहें और जाँचते रहें कि वह सही है—जॉइन प्लान्स पर सोचें—डेटा के सबसेट्स पर टेस्ट करें—और सुनिश्चित करें कि एग्रीगेट स्टैटिस्टिक्स और डिस्ट्रीब्यूशन्स समझ में आते हैं। समझदार चीज़ें जाँचें—जैसे कि आपके डायरेक्ट मेल कैंपेन पर 10% लिफ्ट नहीं आ गया। फिर एक और बहुत अहम बात—मॉडल्स प्रोडक्शन में जाते हैं—तो शायद आपको इंटीग्रेशन टेस्ट्स या अन्य टेस्ट्स की ज़रूरत होगी—ताकि सुनिश्चित हो सके कि प्रोडक्शन में जो है—वह रिसर्च में विकसित चीज़ के प्रति वफ़ादार है।
प्रोडक्शन में डेटा साइंस
Hugo: तो जहाँ... या तो जहाँ आपने पहले काम किया या अब Convoy में—डेटा साइंटिस्ट प्रोडक्शन में अपना काम डालने के संदर्भ में कहाँ बैठता है?
Ben: यह संगठन और समूह के अनुसार बहुत बदलता है। कुछ संगठनों या समूहों में डेटा साइंटिस्ट सिर्फ़ शुद्ध रिसर्च करेगा—और फिर चीज़ें "दीवार के पार" भेज देगा—और इंजीनियरिंग कुछ जादू करेगी। यह समस्यापूर्ण हो सकता है—चीज़ें ट्रांसलेशन में खो जाती हैं। कई इंजीनियर्स तब ख़ुश नहीं होते जब आप उन्हें R कोड देते हैं—आशा है Python से ख़ुश हों। Convoy में हम इस दिशा में काम कर रहे हैं कि डेटा साइंटिस्ट अपना मॉडल एंड-टू-एंड ओन करें—और हमारे पास एक मशीन लर्निंग प्लेटफ़ॉर्म हो—जो हमें मॉडल्स डिप्लॉय करने दे। हम अभी पूरी तरह वहाँ नहीं पहुँचे—इस संदर्भ में और काम बाकी है—पर मुझे लगता है यह सबके लिए बेहतर है—क्योंकि फिर इंजीनियर्स डेटा सर्विस को कॉल करके जो भी रिज़ल्ट चाहिए ले सकते हैं। साथ ही, Convoy में हमारा ऑर्गनाइज़ेशनल स्ट्रक्चर अच्छा डेटा साइंस करने के अनुकूल है—हम प्रोडक्ट ग्रुप्स में संगठित हैं—जो करीबी सहयोग करते हैं—पर एक प्रोडक्ट ग्रुप में एक प्रोडक्ट मैनेजर, एक या अधिक डेटा साइंटिस्ट्स और कई इंजीनियर्स होते हैं। हमारे प्रोडक्ट मैनेजर्स की बढ़िया बात यह है कि वे सभी बहुत टेक्निकल हैं—अधिकांश के पास कंप्यूटर साइंस में मास्टर्स या समकक्ष, अच्छा MBA है—और वे सभी SQL लिख सकते हैं। यहाँ एक प्रोडक्ट मैनेजर हैं—इंटरव्यू में मैंने उन्हें एक SQL प्रश्न पूछा—जिसमें left outer join का उपयोग था—और उन्होंने लगभग 60 सेकंड में हल कर दिया। मुझे लगता है वे इस उदाहरण से थक गए हैं—पर यही हमारे PMs का स्तर है। वे टेक्निकल, डेटा-ओरिएंटेड हैं—SQL लिख सकते हैं—अंडरग्रैज स्तर का स्टैट्स समझते हैं—और यह बहुत मददगार है—क्योंकि इससे वे सही ढंग से डेटा साइंस करने के पैरोकार बनते हैं—फिर हमारे पास बहुत-सा अतिरिक्त सामाजिक ढाँचा है जिससे सुनिश्चित हो कि डेटा साइंटिस्ट्स क्षैतिज रूप से जुड़े और सहयोग करते रहें। जैसे—हम डेटा साइंस ब्राउन बैग चलाते हैं। हमारे पास टेक्निकल वन-ऑन-वन होते हैं—जहाँ मैं अन्य डेटा साइंटिस्ट्स से मिलता हूँ—और सुनिश्चित करता हूँ कि वे सही दिशा में जा रहे हैं—और उनके किसी भी टेक्निकल प्रश्न का उत्तर दे सकूँ—ताकि वे ब्लॉक न हों।
Hugo: मुझे लगता है कि एक टेक्निकल प्रोडक्ट मैनेजर—as you say—कई फ़ायदे लाता है—पर सबसे बड़ा यह कि वह आपसे सच में बातचीत कर सकता है, है न?
Ben: हाँ। वे डेटा-ड्रिवन होने में बहुत निवेशित होते हैं। वे जानते हैं कि अगर वे किसी नए फीचर की योजना लिखते हैं—तो उन्हें डेटा साइंटिस्ट के साथ मिलकर Stack Overflow प्लान—या कोई अन्य प्लान—बनाना होगा—ताकि अपने विचारों को वेरिफ़ाई और वैलिडेट कर सकें। वे सभी डेटा के उपयोग के पैरोकार हैं—और हमारे यहाँ PMs का मानक बहुत ऊँचा है—पर ऐसी संस्था में यह अहम है कि वे डेटा की बातचीत में भाग ले सकें—क्योंकि अक्सर वही रिसर्च प्रश्नों को ड्राइव कर रहे होते हैं। यह दिखाने के लिए कि वे कितने डेटा-ड्रिवन हैं—Ziad Ismail—जो चीफ प्रोडक्ट ऑफिसर हैं—वे SQL लिखते हैं। मेरा मतलब, यह व्यक्ति रात में जागकर बिज़नेस समझने के लिए SQL लिखते हैं—और हमारे डेटा वेयरहाउस के डेटा का उन्हें उतना ही गहरा ज्ञान है जितना किसी को।
Hugo: बढ़िया। तो आपके पास—मुझे कहना होगा—सांख्यिकी, इकोनोमेट्रिक्स और डेटा साइंस तकनीकों का बहुत प्रभावशाली औज़ार-बक्सा है। आपका पसंदीदा तकनीक या कार्यप्रणाली क्या है?
Ben: हाँ, यह अच्छा प्रश्न है—और यह वैसा है जैसे पूछना—आपका पसंदीदा पंछी क्या है—या कैमरा। ब्रिटिश कहावत है—एक धागा कितना लंबा होता है?
Hugo: और कोई इसका उत्तर नहीं दे सकता।
Ben: है ना? तो मैं आमतौर पर...
Hugo: हाँ, आपको क्या पसंद है? किसमें रुचि है?
Ben: ...काम के लिए सबसे अच्छा औज़ार उपयोग करना। तो निश्चित रूप से... मैं ऐसे पीएचडी प्रोग्राम से आया हूँ जो पैनल डेटा मेथड्स में बहुत मजबूत था—जैसे UCL में लोग—Richard Blundell वगैरह—जिन्होंने इसे आगे बढ़ाने में बहुत योगदान दिया। तो यह मेरी ताकत है—पैनल डेटा मेथड्स का उपयोग। पर मुझे कोर ML टूल्स भी बहुत पसंद हैं। यह वाकई समस्या पर निर्भर करता है। मैं सबसे अच्छा औज़ार उपयोग करना चाहता हूँ। तो मुझे सबसे ज़्यादा ख़ुशी औज़ार उपयोग करने से नहीं—बल्कि दिलचस्प समस्याएँ सुलझाने से मिलती है। मैं अंततः एक एप्लाइड साइंटिस्ट हूँ। मैंने क्वांटम कॉस्मोलॉजी से लेकर बायोइन्फ़ॉर्मेटिक्स और ट्रकिंग तक—विभिन्न समस्याओं पर काम किया है। तो दिलचस्प समस्याएँ होना मायने रखता है—और उन्हें सुलझाने के लिए सही औज़ार ढूँढ़ पाना महत्वपूर्ण है—डेटा और सॉफ़्टवेयर के साथ।
डेटा साइंस का भविष्य
Hugo: हमने आधुनिक डेटा साइंस पर बहुत चर्चा की। आपके लिए भविष्य का डेटा साइंस कैसा दिखता है?
Ben: हम अद्भुत समय में हैं। अगर आपके पास गणित और सांख्यिकी के कौशल हैं—तो हर जगह डेटा फटकर बाहर आ रहा है। मेरा मानना है कि जब तक Elon Musk कोई ऐसा तरीका नहीं निकाल लेते कि हम सबको बेरोज़गार कर दें—तब तक हमारा समय बहुत मज़ेदार और रोचक रहने वाला है।
Hugo: तब तक क्या होगा?
Ben: किसी बिंदु पर ऐसे टूल्स आएँगे जो सरल मॉडलों के बहुत से हिस्सों को ऑटोमेट कर देंगे। आप अभी कंपनियों को कमोडिटी churn मॉडल्स वगैरह बेचने की कोशिश करते देखना शुरू कर रहे हैं—जो मेरे ख्याल से समस्यापूर्ण हो सकता है—क्योंकि अंततः हर कंपनी का डेटा अनोखा होता है—और आपको अपना churn मॉडल शुरू से बनाना चाहिए। पर आप शायद और अधिक कमोडिटी मॉडल्स देखेंगे—और ऐसे टूल्स—जो लो-हैंगिंग डेटा साइंस फलों को ऑटोमेट करेंगे। तो सफल और खुशहाल करियर के लिए आपको वैल्यू चेन में ऊपर जाना चाहिए—जहाँ वे चीज़ें हैं जिन्हें ऑटोमेशन जैसे ऑटोमेटेड फीचर इंजीनियरिंग नहीं बदल पाएगी। उदाहरण के लिए, Context Relevant—मेरी पिछली कंपनी—वे बड़ी समस्याओं की एक श्रेणी के लिए फीचर इंजीनियरिंग को ऑटोमेट करने में अच्छी प्रगति कर चुके थे।
Hugo: आप कौन-से कौशल सुझाएँगे—ताकि उदीयमान और अनुभवी डेटा साइंटिस्ट—अपनी नौकरियाँ ऑटोमेट होने से बचा सकें?
Ben: पहली बात—आप गणित कभी ज़्यादा नहीं जान सकते। इसमें निवेश करना बहुत फायदेमंद है—और यह कम उम्र से शुरू होता है। जब मैं Galvanize में पढ़ाता था—जहाँ वे डेटा साइंस बूटकैंप चलाते हैं—मैं आठ हफ्तों में किसी की प्रोग्रामिंग की कमी दूर कर सकता हूँ। मैं आठ या बारह हफ्तों में गणित की कमी दूर नहीं कर सकता—वह वर्षों की पढ़ाई है। तो मुझे लगता है आपको गणित में लगातार निवेश करना चाहिए। उसके बाद आपको कोर एल्गोरिद्म्स में महारत हासिल करनी चाहिए—फिर पढ़ते रहना चाहिए। पढ़ते रहना बहुत ज़रूरी है। बहुत से लोग इंडस्ट्री में आकर पढ़ना बंद कर देते हैं—और खासकर उन्नत लोगों के लिए—आपको कोई ऐसी स्पेशलाइज़ेशन चुननी चाहिए—जो आपकी रुचि से मेल खाती हो। तो प्रयोग (एक्सपेरिमेंटेशन) मुझे विशेष रूप से दिलचस्प लगता है—जैसे Bayesian मेथड्स—और ये दोनों ऐसी चीज़ें हैं जिनमें मैंने हाल के वर्षों में और गहराई से काम किया है। मुझे पता है बहुत से लोग डीप लर्निंग में जा रहे हैं—वह बहुत प्रतिस्पर्धी क्षेत्र है। तो मुझे लगता है डेटा साइंस में कई और रोचक और महत्वपूर्ण क्षेत्र हैं। तो हाँ, अगर आप डीप लर्निंग में जाना चाहते हैं—जाइए। पर थोड़ा कंट्रेरियन होने में भी फ़ायदा है।
आह्वान
Hugo: मुझे भी ऐसा लगता है। तो यह सब कहते हुए—क्या आपके पास उभरते और स्थापित दोनों प्रकार के डेटा साइंटिस्ट्स के लिए कोई अंतिम कॉल-टू-एक्शन है?
Ben: मैं किसी ऐसे व्यक्ति से—जो डेटा साइंस में आना चाहता है—मुख्यतः यही कहूँगा कि समझ लें—आप खुद को आजीवन सीखने के लिए तैयार कर रहे हैं—और यह मैराथन है—स्प्रिंट नहीं। यह पीएचडी करने जैसा है—आपको अपनी रफ़्तार साधनी होगी। इसे करने में कई साल लग सकते हैं। तो आपको लगातार निवेश करना होगा। तो शायद आपको रात में Netflix थोड़ा कम देखना चाहिए—और प्रासंगिक किताबें, पेपर्स पढ़ने, कोड लिखने, मॉडलों से खेलने में थोड़ा अधिक समय देना चाहिए—और अगर आपको डेटा के बारे में वह उत्साह महसूस नहीं होता—तो शायद कोई और जगह है जहाँ आप अधिक खुश होंगे।
Hugo: तो सीखते रहिए, पढ़ते रहिए, करते रहिए।
Ben: हाँ। मेरे लिए—और मुझे लगता है हममें से कई लोगों के लिए—डेटा एक Agatha Christie जैसा है—उसमें एक रहस्य छुपा है—और मैं उसे खोलना, सुलझाना चाहता हूँ—और पता लगाना चाहता हूँ कि क्या वह Colonel Mustard था—लिविंग रूम में—मोमबत्ती-दान के साथ।
Hugo: शानदार, Ben। तो आप अपना डेटा साइंस जीवन जासूसी कहानियों की तरह जी रहे हैं।
Ben: हाँ—कुछ ऐसा ही।
Hugo: यह अद्भुत है। मैं इससे बहुत जुड़ाव महसूस करता हूँ—क्योंकि डेटा देता ही जाता है। मेरे एक सहकर्मी हमें हमेशा बताते हैं—आपको अपने डेटा को सुनना चाहिए—वह बोलेगा—जब तक आप सुन रहे हैं, है न?
Ben: हाँ। और एक बात—जब आपने पहले गलतियों की बात की—एक गलती जो मैंने बहुत से वैज्ञानिकों में देखी—वे बिना EDA किए मॉडलिंग में कूद पड़ते हैं। EDA—Tukey का प्रसिद्ध शब्द—exploratory data analysis। EDA में कुछ समय लगाना क़ीमती है—क्योंकि आप चौंकाने वाली चीज़ें खोजेंगे। जब मैं Convoy में शामिल हुआ—मैंने डेटा पर EDA करना शुरू किया—और मुझे कुछ डेटा क्लीनिंग और आउट्लायर समस्याएँ मिलीं—जिनका समाधान नहीं हुआ था—और हमने उन्हें ठीक किया—और प्राइसिंग मॉडल में लगभग 10% सुधार मिला। यह जैसे मुफ़्त परफ़ॉर्मेंस थी।
Hugo: यह बहुत कुछ बताता है। यानी EDA—exploratory data analysis करना—क्योंकि मॉडल्स बनाने में कूद पड़ना आकर्षक होता है—पर मैं हमेशा लोगों को प्रोत्साहित करता हूँ कि वे अपने डेटा को 100 अलग-अलग तरीकों से विज़ुअलाइज़ करें—समरी स्टैटिस्टिक्स देखें—और बाकी सब—कुछ भी करने से पहले।
Ben: हाँ। और मैं छात्रों को बहुत पद्धतिगत, मानकीकृत दृष्टिकोण सिखाने की कोशिश करता हूँ—और यह उन चीज़ों में से एक है जो मुझे CRISP-DM में शानदार लगती हैं—जो cross-industry standard process for data mining है—और यह शायद किसी डेटा साइंस प्रोजेक्ट के लिए सबसे अच्छा वर्कफ़्लो है—और यह सुनिश्चित करने के लिए सभी चरणों से गुज़रना अच्छा है कि कुछ छूट न जाए। तो आप शुरुआत करते हैं—व्यावसायिक समस्या समझकर—फिर समझते हैं कि आपके पास क्या डेटा है। अपना डेटा तैयार करें। मॉडलिंग, मूल्यांकन और डिप्लॉय करें। और किसी भी बिंदु पर—आपको कोई गलती मिल सकती है—जिसे आपको पिछले चरणों में जाकर संबोधित करना होगा। तो आप मॉडलिंग शुरू करते हैं—और महसूस करते हैं—ओह, मैंने अपना फीचर इंजीनियरिंग सही नहीं किया—या मुझे कोई फीचर जोड़ना होगा ताकि किसी प्रमुख व्यवहार को कैप्चर कर सकूँ—जहाँ मॉडल असफल हो रहा है। इस तरह व्यवस्थित रहना बहुत अच्छा है—ताकि आप प्रयास न दोहराएँ—या चरण न छोड़ें—और अंततः शुद्धता (correctness) के संदर्भ में—जिसका हमने ज़िक्र किया—मैं CRISP-DM और VV & UQ को साथ जोड़ने का तरीका ढूँढ़ना चाहूँगा—और तब आप बहुत शक्तिशाली, पेशेवर और परिपक्व सेटअप में होंगे।
Hugo: शानदार। यह वास्तव में उस तरह की प्रणालीगत संरचना को दर्शाता है—कि भविष्य का डेटा साइंस कैसा दिख सकता है—या क्या समाहित कर सकता है।
Ben: हाँ। और इसका दूसरा पहलू यह है कि मॉडलिंग मज़ेदार हिस्सा है—और उत्तर तक पहुँचना—पर उससे पहले की चीज़ें बेहद महत्वपूर्ण हैं—और आपके समय का लगभग 80% लेती हैं। वह—डेटा साफ़ करना, तैयार करना। फिर मॉडलिंग तेज़ होती है—यह ऐसे होती है—और—धप्प—कहाँ गई? मैं वापस सामान्य पर। मुझे लगता है हम और टूल्स देखेंगे—आशा है—जो प्री-मॉडलिंग पीरियड को तेज़ करेंगे—क्योंकि वहीं आपको सबसे बड़े उत्पादकता लाभ मिलेंगे—अगर आप उस चरण में तेज़ हो पाएँ। तो यह निवेश करने की अच्छी जगह है। तो आपको UNIX जैसी चीज़ें सीखनी चाहिए—और कमांड लाइन टूल्स और अन्य टेक्नोलॉजी या प्लेटफ़ॉर्म्स में बहुत अच्छे हो जाना चाहिए—जो आपको डेटा को तेज़ी से मॉडल के लिए तैयार करने में मदद करेंगे।
Hugo: बिल्कुल। Ben, शो में आपका होना बहुत सुखद रहा।
Ben: धन्यवाद, Hugo। यहाँ आना बहुत अच्छा लगा—और शो के लिए आपको शुभकामनाएँ।
Hugo: धन्यवाद।