कारण संबंधी खोज: क्या मुर्गे के बांग देने से सूर्य उगता है?

कारण खोज को स्वचालित करने के लिए पायथन कोड की 10 पंक्तियाँ जो आपको देखने को मिली हैं

मेरे हालिया शोध का फोकस रहा है कारण अनुमान मशीन लर्निंग की भविष्यवाणियों से आगे बढ़कर "क्या होगा?" का उत्तर देने के लिए ग्राहकों से मिलने वाले बढ़ते अनुरोधों से प्रेरित हूं। प्रभाव और परिणाम जानने के लिए प्रश्न टाइप करें।

जिन चीजों में मुझे शुरू में दिलचस्पी थी उनमें से एक थी - "कारण आरेख कैसे बनाए जाते हैं?"। कई ऑनलाइन उदाहरणों में वे पूरी तरह से जीवन में आते प्रतीत होते हैं, बिना किसी स्पष्टीकरण के कि नोड्स और लिंक की पहचान कैसे की गई थी।

इसने मुझे ज्यूडिया पर्ल और डाना मैकेंज़ी द्वारा लिखित "द बुक ऑफ़ व्हाई" पढ़ने के लिए प्रेरित किया (कई बार!) और व्यक्त किया गया एक विचार यह है कि आप डेटा से एक कारण आरेख, जिसे डायरेक्टेड एसाइक्लिक ग्राफ़ (डीएजी) के रूप में भी जाना जाता है, को रिवर्स इंजीनियर नहीं कर सकते हैं। अकेला।

डेटा सहसंबंध को प्रकट कर सकता है लेकिन कार्य-कारण को नहीं, तो कार्य-कारण को "खोजना" कैसे संभव है?

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

इससे पहले कि हम कारण की खोज में उतरें, कृपया विचार करें...

मेरे रेफरल लिंक के साथ माध्यम से जुड़ना (यदि आप इस लिंक का उपयोग करके साइन अप करते हैं तो मुझे शुल्क का एक हिस्सा प्राप्त होगा)।

जब भी मैं कोई नई कहानी प्रकाशित करता हूं तो निःशुल्क ई-मेल की सदस्यता लेता हूं.

मेरे पिछले लेखों पर एक नज़र डालें.

मेरा मुफ़्त रणनीतिक डेटा-संचालित निर्णय लेने का ढाँचा डाउनलोड कर रहा हूँ.

मेरी डेटा विज्ञान वेबसाइट पर जाना - डेटा ब्लॉग.

निम्नलिखित बाइनरी डेटा सेट से मूल्य गणना पर विचार करें...

नोट: सन राइज/कॉकरेल डेटा सेट लेखक द्वारा बनाया गया सिंथेटिक डेटा है, कृपया पूर्ण स्रोत और संदर्भ विवरण के लिए लेख के अंत में संदर्भ अनुभाग देखें।

90.25% अवलोकनों में हम देख सकते हैं कि जब सूर्य उगता है तो मुर्गा बांग देता है, लेकिन अकेले आंकड़ों के आधार पर हम यह कैसे जान सकते हैं कि सूर्य उगने के कारण मुर्गा बांग देता है या मुर्गे के बांग देने के कारण सूर्य उगता है?

ऐसे उदाहरणों की संख्या जब कॉकरेल बांग देता है जब सूरज नहीं उग रहा होता है या जब सूरज उगता है लेकिन कॉकरेल चुप रहता है तो लगभग समान होते हैं (50,000 बनाम 47,500) इसलिए डेटा की सापेक्ष मात्रा की तुलना करके कारण उत्तर नहीं पाया जा सकता है।

एक दृष्टिकोण अस्थायी पहलू को देखना हो सकता है। यदि मुर्गे के बांग देने से पहले सूर्य लगातार उगता है तो यह कार्य-कारण का एक अच्छा संकेतक होगा, लेकिन क्या होगा यदि हमारा मुर्गा जल्दी उठता है?

इसका उत्तर है डोमेन विशेषज्ञों से परामर्श करना। यदि हम एक ज्योतिषी, एक भौतिक विज्ञानी और एक मुर्गीपालक के साथ एक टीम इकट्ठा कर सकें तो वे यह निष्कर्ष निकालेंगे कि सूरज मुर्गे के बांग देने का कारण बन रहा है, न कि इसके विपरीत!

सूरज के उगने और मुर्गों की बांग से बिना घबराए मैं किसी ऐसी चीज़ की तलाश में निकल पड़ा जो पहले से ही मौजूद थी जो डेटा के आधार पर कारण खोज का जादू करने में सक्षम हो सकती है।

"नोटियर्स" नामक एक एल्गोरिदम है जो कारण संबंधी खोज को लागू करने में सक्षम होने का दावा करता है, तो आइए इसे आज़माएं और देखें कि यह क्या कर सकता है ...

नोट: चेचक डेटा सेट लेखक द्वारा बनाया गया सिंथेटिक डेटा है, कृपया पूर्ण स्रोत और संदर्भ विवरण के लिए लेख के अंत में संदर्भ अनुभाग देखें।

यह डेटासेट चेचक के टीकाकरण में कारण-और-प्रभाव संबंधों का मॉडलिंग कर रहा है। आइए इसके विरुद्ध NOTEARS एल्गोरिदम चलाएं और देखें कि यह क्या कर सकता है...

[('प्रतिक्रिया?', 'टीकाकरण?'),
('चेचक?', 'प्रतिक्रिया?'),
('मृत्यु?', 'प्रतिक्रिया?'),
('मृत्यु?', 'चेचक?')]

यदि हम NOTEARS द्वारा उत्पादित परिणामों की कल्पना करें तो यह इस तरह दिखेगा...

यह बहुत अच्छा नहीं लग रहा है क्या? NOTEARS के अनुसार मृत्यु का कारण चेचक है। लौकिक पहलू हमें बताता है कि चेचक पहले आता है इसलिए यह मृत्यु का कारण नहीं हो सकता। न ही चेचक प्रतिक्रिया का कारण बन सकता है (टीका प्रतिक्रिया का कारण बनता है) और प्रतिक्रिया निश्चित रूप से टीकाकरण का कारण नहीं बन सकती है।

डोमेन विशेषज्ञों के ज्ञान का उपयोग करके हम आसानी से यह स्थापित कर सकते हैं कि टीकाकरण का इस पर एक कारणात्मक प्रभाव पड़ता है कि क्या रोगी को कोई प्रतिक्रिया होती है और क्या उनमें बीमारी विकसित होती है और प्रतिक्रिया और चेचक दोनों का मृत्यु के साथ एक कारणात्मक संबंध होता है...

इसलिए, हमने स्थापित किया है कि एक बहुत ही सरल कारण मॉडल में भी NOTEARS कारण खोज एल्गोरिदम सही परिणाम नहीं देता है। इसके अलावा, मेरे पिछले लेखों में से एक पाठक ने बताया कि NOTEARS Python 3.9 में काम नहीं करता है और जैसा कि मैं अपग्रेड करने वाला हूं यह एक और बड़ी समस्या है।

यदि आप कार्य-कारण के लिए नोटर्स की अनुपयुक्तता के बारे में अधिक पढ़ना चाहते हैं तो यहां एक उत्कृष्ट अकादमिक पेपर है - https://arxiv.org/pdf/2104.05441.pdf (मार्कस कैसर और मक्सिम सिपोस)।

इससे पहले कि हम पूरी तरह से स्वचालित कारण खोज को छोड़ दें, आइए NOTEARS के एक विकल्प, "लासो" एल्गोरिदम पर एक नज़र डालें -

नोट: जनगणना आय/स्नातक आय डेटा सेट को सार्वजनिक उपयोग के लिए लाइसेंस प्राप्त है, कृपया पूर्ण स्रोत और संदर्भ विवरण के लिए लेख के अंत में संदर्भ अनुभाग देखें।

हे प्रिय, लैस्सो एक आपदा है! इसने भविष्यवाणी की है कि हर चीज़ हर चीज़ का कारण बन रही है और नोड्स स्वयं भी इसका कारण बनते हैं!

मेरा अंतिम प्रयास GES, GIES और LINGAM एल्गोरिदम को आज़माना था लेकिन इन सभी के लिए R लाइब्रेरी की आवश्यकता होती है। मैं आर का उपयोग नहीं करता हूं और भले ही मैं कॉन्फ़िगरेशन सही करने में कामयाब रहा हूं, मैं कभी भी पोर्टेबल कोड नहीं बना पाऊंगा जिसे अन्य डेटा वैज्ञानिक उपयोग कर सकें।

जो कारण खोज पुस्तकालय और एल्गोरिदम उपलब्ध हैं, वे काम नहीं करते हैं और इसने "द बुक ऑफ व्हाई" में व्यक्त दृष्टिकोण को फिर से लागू किया है यानी कि कार्य-कारण को अकेले डेटा से रिवर्स इंजीनियर नहीं किया जा सकता है।

इस निष्कर्ष ने मुझे अपना दृष्टिकोण विकसित करने के लिए प्रेरित किया...

मेज पर कार्ड, मैंने कोई कारण खोज एल्गोरिदम नहीं लिखा है। बल्कि मेरा एल्गोरिथ्म एक मोड़ के साथ सहसंबंधी खोज को लागू करता है (कोई यमक इरादा नहीं!)।

जब मैंने कारण खोज पुस्तकालयों को छोड़ दिया था तब भी मुझे डोमेन विशेषज्ञों के साथ बातचीत के लिए शुरुआती बिंदु के रूप में कार्य-कारण की कल्पना करने का एक तरीका चाहिए था।

मैंने तर्क दिया कि मैं सुविधाओं/नोड्स के बीच सहसंबंधों की आसानी से गणना कर सकता हूं और यह कम से कम एक अच्छा प्रारंभिक बिंदु होगा।

मैंने अपनी सोच इस प्रकार विकसित की - कारण खोज मॉडल में हम आम तौर पर "प्रभाव" की पहचान करते हैं यानी वह डेटा सुविधा जिसमें हम रुचि रखते हैं (जैसे मशीन सीखने की भविष्यवाणियों में "लक्ष्य")। चेचक के उदाहरण में यह "मृत्यु?" है, और स्नातक आय के उदाहरण में यह "अधिक धन्यवाद50k" की कमाई है।

इसलिए यदि किसी विशेषता और "प्रभाव" के बीच सहसंबंध हैं तो कारण दिशा अन्य विशेषताओं से प्रभाव की ओर होनी चाहिए क्योंकि यह "पंक्ति के अंत" पर है।

मेरा अगला कदम एक पुनरावर्ती एल्गोरिदम विकसित करना था जिसे निम्नानुसार देखा जा सकता है ...

डुप्लिकेट और द्वि-दिशात्मक लिंक को जबरन बाहर रखा जाना चाहिए। मैं कनेक्शन (किनारों) को स्पष्ट रूप से शामिल करने या बाहर करने और सुविधाओं (नोड्स) को स्पष्ट रूप से बाहर करने में सक्षम होना चाहता था।

ये पुनरावर्ती पायथन कोड की 10 पंक्तियाँ हैं जिन्हें मैं कारण खोज को लागू करने के लिए लेकर आया हूँ

यह दिखाने के लिए कि समाधान कैसे काम करता है, मैंने होटल बुकिंग रद्दीकरण डेटा पर कुछ डेटा चुना है।

आइए डेटा को पढ़कर और सहसंबंधों पर एक नज़र डालकर शुरुआत करें...

नोट: होटल बुकिंग डेटा सेट सार्वजनिक उपयोग के लिए लाइसेंस प्राप्त है, कृपया पूर्ण स्रोत और संदर्भ विवरण के लिए लेख के अंत में संदर्भ अनुभाग देखें।

डिस्कवरी एल्गोरिदम के पहले रन में पुनरावृत्तियों को 1 से नीचे रखना शामिल है, इसलिए हम केवल "प्रभाव" के साथ सहसंबंध (जो कारणात्मक होना चाहिए) को देख रहे हैं यानी कि होटल बुकिंग रद्द की गई है या नहीं ...

ठीक है, यह एक बुरी शुरुआत नहीं है, आइए पुनरावृत्तियों/पुनरावृत्तियों/परतों की संख्या को 3 तक बढ़ाएं, सहसंबंध सीमा को थोड़ा मोड़ें और देखें कि हमें क्या मिलता है...

ठीक है, बहुत बुरा भी नहीं है, लेकिन यह थोड़ा "व्यस्त" है इसलिए अगला कदम उन कुछ नोड्स को बाहर करना है जिनके बारे में हमें संदेह है कि वे कुछ शोर का कारण बन सकते हैं (ध्यान दें: वास्तविक दुनिया के व्यावसायिक मामले में हम बात करेंगे इस स्तर पर हमारे डोमेन विशेषज्ञ)।

यह बेहतर दिखने लगा है. याद रखें कि मेरा एल्गोरिदम आश्वस्त है कि "IsCanceled" के लिंक कारणात्मक हैं क्योंकि यह "प्रभाव" है, इसलिए इसके बाद कुछ भी नहीं आता है।

हालाँकि, पेड़ की अन्य परतें केवल सहसंबंधी हैं, तीरों की दिशा केवल उस क्रम के आधार पर जोड़ी गई थी जिसमें एल्गोरिदम ने उन्हें पाया था।

डोमेन विशेषज्ञों के साथ काम करते हुए (या इस उदाहरण में होटल बुकिंग का मेरा अपना अनुभव!) मैंने निम्नलिखित पर ध्यान दिया -

• "DifferentRoomAssigned" से "LeadTime" का लिंक गलत दिशा में है क्योंकि लंबी बुकिंग लीड समय से यह संभावना बढ़ जाती है कि कमरे की बुकिंग बदल जाएगी और इसके विपरीत नहीं।
• "बुकिंगचेंज" और "डिफरेंटरूमअसाइन्ड" के बीच सहसंबंध सीमा से नीचे है, लेकिन यह महत्वपूर्ण कारण हो सकता है इसलिए इसे शामिल करने की आवश्यकता है।

अगला प्रयास एल्गोरिदम को ये सुधार करने का निर्देश देता है -

एक "अनऑब्जर्व्ड कन्फ़ाउंडर" एक ऐसा कारक है जिसके बारे में हमारा मानना ​​है कि यह कुछ नोड्स के बीच एक लिंक प्रदान करके हमारे कारण मॉडल पर प्रभाव डाल रहा है, लेकिन इसे मापा नहीं गया है और इसलिए इसे आरेख में शामिल नहीं किया गया है।

होटलों में जाने के मेरे अनुभव और होटल डेटासेट के बारे में मेरी जानकारी से मुझे संदेह हुआ कि होटल डेटा को प्रभावित करने वाला एक "अनदेखा कन्फ़्यूडर" है।

डेटा में दो होटल हैं - एक "शहर" होटल और एक "रिसॉर्ट" होटल। यह मुझे इस परिकल्पना की ओर ले जाता है कि इस कारण मॉडल में न देखा गया कन्फ़ाउंडर है "होटल में रुकने का कारण".

मेरी परिकल्पना यह है छुट्टियाँ बिताने वाले लोग मुख्य रूप से रिज़ॉर्ट होटल में रुकते हैं और व्यवसायी लोग और शहर घूमने वाले लोग मुख्य रूप से शहर के होटल में रुकते हैं.

इसके अलावा मैंने परिकल्पना की है कि इन दोनों समूहों के व्यवहार अलग-अलग हैं और यह "अनऑब्जर्व्ड कन्फ़्यूडर" है (अअवलोकित क्योंकि डेटा "रहने का कारण" नहीं पकड़ता है)।

NOTEARS और अन्य समान एल्गोरिदम "अनऑब्जर्व्ड कन्फ़ाउंडर्स" का हिसाब नहीं दे सकते हैं, लेकिन मैंने जो एल्गोरिदम विकसित किया है, वह उन्हें स्पष्ट रूप से निम्नानुसार शामिल करके उन्हें ध्यान में रख सकता है ...

अंतिम पुनरावृत्ति का परिणाम होटल डेटा में कार्य-कारण के लिए एक प्रशंसनीय, पठनीय और समझने योग्य दृश्य है जिसे मैं डोमेन विशेषज्ञों के साथ अन्वेषण और परिष्कृत करने के लिए आश्वस्त हूं। ये हैं प्रमुख बिंदु...

• एक "अनऑब्जर्व्ड कन्फ़्यूडर" है जो ठहरने का प्राथमिक कारण है (छुट्टियाँ बनाम व्यवसाय / शहर ब्रेक)।
• "देश" का अनदेखे कन्फ़्यूडर पर एक आकस्मिक प्रभाव पड़ता है - कुछ देशों से यात्रा करने वालों के छुट्टी पर होने की अधिक संभावना होती है।
• यही बात "टोटलगेस्ट्स" पर भी लागू होती है। बड़ी पार्टियों में छुट्टियों पर जाने की अधिक संभावना होती है, एकल लोगों के लिए व्यावसायिक यात्राओं पर और युगल लोगों के शहर में छुट्टी पर जाने की अधिक संभावना होती है।
• अज्ञात "रहने का कारण" का "लीडटाइम", "होटलटाइप" और "डिपॉजिटटाइप" पर एक कारणात्मक प्रभाव पड़ता है।
• "लीडटाइम", "डिफरेंटरूमअसाइन्ड", "होटलटाइप", "डिपॉजिटटाइप" और "रहने का कारण" (यू) सभी का "रद्द किया गया" पर एक कारण प्रभाव पड़ता है।

कारण की खोज सहसंबंधी कड़ियों से आगे जाकर कारणात्मक कड़ियों की खोज करने की प्रक्रिया है (अर्थात तीर सहसंबंधी रेखा के किस छोर पर है?)। NOTEARS जैसे एल्गोरिदम के साथ स्वचालित करना संभव नहीं है, या कम से कम निषेधात्मक रूप से कठिन है, क्योंकि उत्तर अकेले डेटा में मौजूद नहीं हैं।

हालाँकि, अभी भी कार्य-कारण की कल्पना करने की गंभीर आवश्यकता है ताकि एक कारण आरेख (जिसे डायरेक्टेड एसाइक्लिक ग्राफ़ या डीएजी भी कहा जाता है) बनाने के लिए डोमेन विशेषज्ञों के साथ इसका पता लगाया जा सके।

इस आलेख में पायथन कोड की केवल 10 पंक्तियों का उपयोग करके संवर्धित सहसंबंध खोज पर आधारित एक एल्गोरिदम प्रस्तावित किया गया है जिसका उपयोग डोमेन विशेषज्ञों के साथ संवेदनशीलता (थ्रेसहोल्ड) को बार-बार परिष्कृत करने और लिंक (तीर) को सही करने, जोड़ने या हटाने और अप्रासंगिक को बाहर करने के लिए किया जा सकता है। नोड्स.

भविष्य के लेखों में इन कारण आरेखों का उपयोग एक पूर्ण विकसित कारण मशीन लर्निंग मॉडल बनाने के लिए किया जाएगा जो जटिल "क्या होगा?" का उत्तर दे सकता है। ग्राहकों और व्यापारिक नेताओं से प्रश्न टाइप करें।

यदि आपको यह लेख अच्छा लगा हो तो कृपया इस पर विचार करें...

मेरे रेफरल लिंक के साथ माध्यम से जुड़ना (यदि आप इस लिंक का उपयोग करके साइन अप करते हैं तो मुझे शुल्क का एक हिस्सा प्राप्त होगा)।

जब भी मैं कोई नई कहानी प्रकाशित करता हूं तो निःशुल्क ई-मेल की सदस्यता लेता हूं.

मेरे पिछले लेखों पर एक नज़र डालें.

मेरा मुफ़्त रणनीतिक डेटा-संचालित निर्णय लेने का ढाँचा डाउनलोड कर रहा हूँ.

मेरी डेटा विज्ञान वेबसाइट पर जाना - डेटा ब्लॉग.

उगता हुआ सूरज / मुर्गे के बाँग देने का आँकड़ा

चेचक के आंकड़े

स्नातक आय/जनगणना आय डेटा

होटल बुकिंग डेटा

कारण संबंधी खोज: क्या मुर्गे के बांग देने से सूर्य उगता है? स्रोत https://towardsdatascience.com/causal-discovery-does-the-cockerel-crowing-cause-the-sun-to-rise-f4308453ecfa?source=rss—-7f60cf5620c9—4 से https://towardsdatascience के माध्यम से पुनर्प्रकाशित। com/फ़ीड

<!–

->