14 जुल॰ 2025·8 मिनट
Judea Pearl की कारणात्मक सोच: बेहतर AI, डिबगिंग, और निर्णय
Judea Pearl के कारणात्मक मॉडलों से सिखें कि कैसे टीमें AI व्यवहार समझें, विफलताओं को डिबग करें और correlations के परे स्पष्ट प्रोडक्ट निर्णय लें।
Judea Pearl के कारणात्मक मॉडलों से सिखें कि कैसे टीमें AI व्यवहार समझें, विफलताओं को डिबग करें और correlations के परे स्पष्ट प्रोडक्ट निर्णय लें।
एक टीम अपने डैशबोर्ड में कुछ “स्पष्ट” देखती है: जिन यूज़र्स को ज्यादा नोटिफिकेशन मिलते हैं वे अधिक बार लौटते हैं। तो वे नोटिफिकेशन की मात्रा बढ़ा देते हैं। एक हफ़्ते बाद retention घटता है और churn शिकायतें बढ़ जाती हैं। क्या हुआ?
मूल पैटर्न असली था—पर भ्रामक। सबसे एंगेज्ड यूज़र स्वाभाविक रूप से अधिक नोटिफिकेशन ट्रिगर करते हैं (क्योंकि वे प्रोडक्ट ज्यादा उपयोग करते हैं), और वे स्वाभाविक रूप से अधिक लौटते भी हैं। नोटिफिकेशन ने retention नहीं बढ़ाया; engagement दोनों का कारण था। टीम ने correlation पर काम लिया और अनजाने में खराब अनुभव बना दिया।
कारणात्मक सोच वह आदत है जो पूछती है: क्या किसका कारण है, और हम यह कैसे जानते हैं? “ये दोनों चीज़ें साथ बढ़ती हैं” पर रुकने के बजाय, आप अलग करने की कोशिश करते हैं:
यह डेटा पर संशय करने की बात नहीं है—बल्कि प्रश्न को विशिष्ट बनाने की बात है। “क्या नोटिफिकेशन और retention correlated हैं?” अलग है “क्या ज्यादा नोटिफिकेशन भेजने से retention बढ़ेगा?” दूसरा सवाल causal है।
यह पोस्ट तीन व्यावहारिक क्षेत्रों पर ध्यान देती है जहाँ पैटर्न-देखना अक्सर फेल होता है:
यह गणित-भारी causal inference टूर नहीं है। आपको do-calculus नॉटेशन सीखने की ज़रूरत नहीं होगी ताकि आपको यहाँ मान मिल सके। लक्ष्य कुछ मानसिक मॉडल और एक वर्कф्लो है जिसे आपकी टीम उपयोग कर सकती है ताकि आप:
अगर आपने कभी ऐसा बदलाव शिप किया है जो “डेटा में अच्छा दिखा” पर वास्तविकता में काम नहीं किया, तो causal सोच ही कमी हो सकती है।
Judea Pearl एक कंप्यूटर वैज्ञानिक और विज्ञान के दार्शनिक हैं जिनका काम कई टीमों के डेटा, AI और निर्णय-निर्माण के तरीके को बदलकर रख दिया। उनकी causal क्रांति से पहले, कंप्यूटिंग में डेटा से सीखना ज्यादातर सांख्यिकीय संबंधों पर केंद्रित था: पैटर्न खोजो, मॉडल फिट करो, अगला क्या होगा भविष्यवाणी करो। यह तरीका शक्तिशाली है—पर अक्सर टूट जाता है जब आप किसी प्रोडक्ट या इंजीनियरिंग सवाल में शब्द क्योंकि रखते हैं।
Pearl का मूल परिवर्तन यह था कि causality को एक प्रथम श्रेणी अवधारणा माना जाए, सिर्फ correlations के ऊपर की एक धुंधली intuition नहीं। सिर्फ यह पूछने की बजाय कि “जब X ऊँचा है तो क्या Y भी ऊँचा रहता है?”, causal सोच पूछती है, “अगर हम X बदलें तो क्या Y बदलेगा?” यह फर्क छोटा लग सकता है, पर यह prediction को decision-making से अलग कर देता है।
Association बताती है “क्या साथ-साथ होता है।” Causation का उद्देश्य है “अगर हमने हस्तक्षेप किया तो क्या होगा।” यह कंप्यूटिंग में मायने रखता है क्योंकि कई वास्तविक निर्णय intervention-shaped होते हैं: कोई फीचर शिप करना, रैंकिंग बदलना, गार्डरेल जोड़ना, ट्रेनिंग सेट बदलना, या नीति समायोजित करना।
Pearl ने causality को और व्यवहारिक बनाया इस तरह कि इसे एक मॉडलिंग विकल्प और स्पष्ट मान्यताओं के रूप में फ्रेम किया गया। सामान्यतः आप डेटा से अपने आप causality “खोज” नहीं लेते; आप एक causal कहानी प्रस्तावित करते हैं (अक्सर डोमेन ज्ञान पर आधारित) और फिर डेटा का उपयोग उसे टेस्ट, अनुमान और सुधारने के लिए करते हैं।
इन टूल्स ने टीमों को साझा भाषा दी जिससे वे पैटर्न-देखने से कारणात्मक सवालों के स्पष्ट और अनुशासित उत्तरों की ओर जा सके।
Correlation का मतलब है कि दो चीज़ें साथ चलती हैं: जब एक ऊपर जाती है, दूसरी भी वारंवार ऊपर जाती है (या नीचे)। यह बेहद उपयोगी है—खासकर डेटा-भारी टीमों में—क्योंकि यह prediction और detection में मदद करता है।
अगर आइसक्रीम की बिक्री तापमान बढ़ने पर spike करती है, तो correlated सिगनल (तापमान) forecasting में सुधार कर सकता है। प्रोडक्ट और AI काम में correlations रैंकिंग मॉडलों ("ऐसा दिखाओ जो समान यूज़र्स ने क्लिक किया"), anomaly spotting ("यह मीट्रिक आमतौर पर उस मीट्रिक के साथ ट्रैक करता है"), और त्वरित डायग्नोस्टिक्स ("latencty बढ़ने पर errors बढ़ते हैं") को संचालित करते हैं।
समस्या तब शुरू होती है जब हम correlation को एक अलग सवाल का उत्तर मान लेते हैं: अगर हम जानबूझकर कुछ बदलें तो क्या होगा? यही causation है।
एक correlated रिश्ता किसी तीसरे कारक से प्रेरित हो सकता है जो दोनों वैरिएबल्स को प्रभावित करता है। X बदलने से जरूरी नहीं कि Y बदले—क्योंकि X वह कारण नहीं हो सकता जिसकी वजह से Y पहले हिला।
कल्पना करें कि आप साप्ताहिक मार्केटिंग खर्च बनाम साप्ताहिक बिक्री प्लॉट करते हैं और मजबूत सकारात्मक correlation देखते हैं। यह कहना लुभावना है कि “ज्यादा खर्च अधिक बिक्री लाता है।”
पर मान लें कि छुट्टियाँ दोनों को बढ़ाती हैं। सीज़न (एक confounder) अधिक मांग पैदा करता है और साथ ही बड़े बजट को भी ट्रिगर करता है। अगर आप गैर‑हॉलीडे सप्ताह में खर्च बढ़ाते हैं, तो बिक्री ज्यादा नहीं बढ़ सकती—क्योंकि मूल मांग वहाँ नहीं है।
आप causal क्षेत्र में हैं जब आप खुद से पूछते सुनते हैं:
जब क्रिया क्रियाविशेषण के रूप में change, launch, remove, या reduce हो, correlation संकेत है—न कि निर्णय- नियम।
कारणात्मक आरेख—अक्सर एक DAG—टीम की मान्यताओं को दृश्यमान बनाने का सरल तरीका है। अस्पष्ट बहसें (“शायद मॉडल है” या “शायद UI”) करने के बजाय, आप कहानी कागज पर रखते हैं।
लक्ष्य पूर्ण सत्य नहीं है; लक्ष्य एक साझा ड्राफ्ट है कि “हम सिस्टम को कैसे समझते हैं” जिसे हर कोई आलोचना कर सके।
मान लीजिए आप आकलन कर रहे हैं कि नया ऑनबोर्डिंग ट्यूटोरियल (T) activation (A) बढ़ाता है या नहीं।
एक आम एनालिटिक्स reflex है “सभी उपलब्ध वैरिएबल्स के लिए control करो।” DAG शब्दावली में, इसका मतलब यह हो सकता है कि आप अनजाने में:
DAG के साथ, आप किसी वैरिएबल को ब्लॉक/adjust करने का कारण बताते हैं—आम तौर पर confounding पाथ्स को रोकने के लिए—न कि सिर्फ इसलिए कि वह मौजूद है।
एक वाइटबोर्ड और तीन स्टेप के साथ शुरू करें:
यहाँ तक कि एक मोटा DAG भी प्रोडक्ट, डेटा, और इंजीनियरिंग को एक ही causal प्रश्न पर संरेखित कर देता है इससे पहले कि आप नंबर चलाएँ।
Judea Pearl की causal सोच में एक बड़ा बदलाव यह है कि अवलोकन और परिवर्तन को अलग किया जाए।
अगर आप देखते हैं कि जिन्होंने नोटिफिकेशन सक्षम किया है वे बेहतर retain करते हैं, तो आपने एक पैटर्न देखा है। पर आप अभी भी नहीं जानते कि नोटिफिकेशन retention का कारण है या नहीं, या सक्रिय यूज़र बस नोटिफिकेशन ऑन करने के लिए अधिक प्रवृत्त हैं।
एक intervention अलग है: इसका मतलब है कि आप सक्रिय रूप से किसी वैरिएबल को किसी मान पर सेट करते हैं और देखते हैं कि आगे क्या होता है। प्रोडक्ट शब्दों में, यह “यूज़र ने X चुना” नहीं है, यह “हमने X शिप किया/फ़ोर्स किया” है।
Pearl अक्सर इस फर्क को इस तरह बताते हैं:
“do” विचार बुनियादी रूप से यह नोट है कि आप उसी कारणों को तोड़ रहे हैं जिनसे आम तौर पर वैरिएबल किसी मान पर पहुँचता है। जब आप intervene करते हैं, तो नोटिफिकेशन इसलिए ON नहीं हैं क्योंकि एंगेज्ड यूज़र ने opted-in किया; वे ON हैं क्योंकि आपने सेट किया। यही बात: interventions कारण‑पर‑प्रभाव अलग करने में मदद करते हैं।
अधिकांश वास्तविक प्रोडक्ट वर्क intervention-shaped है:
ये क्रियाएँ परिणाम बदलने के उद्देश्य से होती हैं, सिर्फ उन्हें वर्णन करने के लिए नहीं। causal सोच सवाल को ईमानदार रखती है: “अगर हम यह करें तो क्या बदलेगा?”
आप बिना मान्यताओं के किसी इंटरवेंशन की व्याख्या नहीं कर सकते (या अच्छा एक्सपेरिमेंट डिजाइन नहीं कर सकते)। आपकी causal डायग्राम—भले ही अनौपचारिक—जरूरी है।
उदाहरण के लिए, अगर सीज़न दोनों मार्केटिंग खर्च और साइन‑अप को प्रभावित करता है, तो बिना सीज़नालिटी को ध्यान में रखे खर्च बदलना भी आपको गुमराह कर सकता है। इंटरवेंशन्स शक्तिशाली हैं, पर वे तभी causal सवाल का उत्तर देती हैं जब अंतर्निहित causal कहानी कम से कम मोटे तौर पर सही हो।
एक counterfactual एक विशेष प्रकार का “what if?” सवाल है: यही खास केस—अगर हमने अलग किया होता तो क्या होता? यह औसत का सवाल नहीं है; यह है “क्या इस व्यक्ति/टिकट/लेनदेन के लिए परिणाम बदलता?”
Counterfactuals तब आते हैं जब कोई मार्ग‑दर्शन मांगता है:
ये प्रश्न यूज़र‑स्तर के होते हैं और उत्पाद परिवर्तन, नीतियों और स्पष्टीकरणों को मार्गदर्शित करने के लिए पर्याप्त ठोस होते हैं।
कभी एक लोन मॉडल को अस्वीकार कर दिया। correlation-based explanation कह सकती है, “कम बचत rejection के साथ correlated है।” एक counterfactual पूछता है:
अगर आवेदक की बचत $3,000 ज्यादा होती (बाकी सब वही रहता), क्या मॉडल उन्हें approve कर देता?
अगर उत्तर “हाँ” है, तो आपने एक क्रियाशील बदल पाया जो निर्णय पलट सकता है। अगर उत्तर “नहीं” है, तो आप भ्रामक सलाह देने से बच गए जैसे “बचत बढ़ाएँ” जब असली बाधा debt-to-income या अस्थिर रोजगार इतिहास हो।
Counterfactuals एक causal मॉडल पर निर्भर करते हैं—यह बताने वाली कहानी कि वैरिएबल्स कैसे एक-दूसरे को प्रभावित करते हैं—सिर्फ डेटासेट नहीं। आपको तय करना होगा कि क्या वास्तविक रूप में बदला जा सकता है, क्या परिणाम के रूप में बदलेगा, और क्या स्थिर रहना चाहिए। बिना causal संरचना के, counterfactuals असंभव परिकल्पनाएँ बन सकती हैं और उपयोगी या निष्पक्ष सिफारिशें नहीं देंगी।
जब कोई ML मॉडल प्रोडक्शन में फेल होता है, तो रूट कारण शायद ही कभी “अल्गोरिथ्म खराब हो गया” होता है। अधिकतर बार सिस्टम में कुछ बदला होता है: संग्रहण-तरीका, लेबलिंग, या यूज़र व्यवहार। causal सोच आपको अनुमान लगाना बंद करने और यह अलग करने में मदद करती है कि किस परिवर्तन ने degradation का कारण बनाया।
कुछ बार-बार होने वाले कारण टीमों में दिखाई देते हैं:
ये सब aggregate डैशबोर्ड में “ठीक” दिख सकते हैं क्योंकि correlation ऊँचा रह सकता है भले ही सही कारण बदल गया हो।
एक सरल कारणात्मक डायग्राम (DAG) debugging को एक नक्शे में बदल देता है। यह आपको पूछने पर मजबूर करता है: क्या यह फीचर लेबल का कारण है, इसका परिणाम है, या इसे मापने के तरीके का परिणाम है?
उदाहरण के लिए, अगर Labeling policy → Feature engineering → Model inputs है, तो आपने एक ऐसा पाइपलाइन बनाया हो सकता है जहाँ मॉडल policy को प्रेडिक्ट कर रहा है न कि अंतर्निहित घटना को। DAG उस रास्ते को दिखाता है ताकि आप उसे रोक सकें (फीचर हटाएँ, instrumentation बदलें, या लेबल को फिर से परिभाषित करें)।
केवल predictions.inspect करने के बजाय नियंत्रित इंटरवेंशन्स आज़माएँ:
कई “explainability” टूल एक संकुचित सवाल का जवाब देते हैं: मॉडल ने यह स्कोर क्यों आउटपुट किया? वे अक्सर प्रभावशाली इनपुट दिखाकर ऐसा करते हैं (feature importance, saliency maps, SHAP values)। यह उपयोगी हो सकता है—पर यह उस सिस्टम की व्याख्या नहीं है जिसमें मॉडल बैठा है।
एक prediction explanation स्थानीय और वर्णनात्मक है: “यह लोन अस्वीकार इसलिए हुआ क्योंकि आय कम और utilization अधिक थी।”
एक सिस्टम explanation कारणात्मक और संचालनात्मक है: “यदि हमने सत्यापित आय बढ़ाई (या utilization घटाया) इस तरह कि वह असली इंटरवेंशन को दर्शाए, क्या फैसला बदल जाएगा—और क्या downstream परिणाम बेहतर होंगे?”
पहला आपको मॉडल व्यवहार समझने में मदद करता है। दूसरा आपको यह निर्णय लेने में मदद करता है कि क्या करना है।
कारणात्मक सोच explanations को interventions से जोड़ती है। आप पूछते हैं कि कौन‑सी वैरिएबलें वैध लीवर्स हैं और उन्हें बदलने पर क्या प्रभाव होंगे।
एक causal मॉडल आपसे स्पष्ट होने को कहता है:
महत्व यह है कि “महत्वपूर्ण फीचर” भविष्यवाणी के लिए उपयोगी हो सकता है पर कार्रवाई के लिए खतरनाक भी।
पोस्ट‑hoc व्याख्याएँ भरोसेमंद दिख सकती हैं पर वे पूरी तरह से correlational रह सकती हैं। अगर “support टिकटों की संख्या” churn का मजबूत predictor है, तो एक feature-importance प्लॉट टीम को प्रेरित कर सकता है कि “टिकट घटाएँ” के लिए सपोर्ट को कठिन बनाकर। वह इंटरवेंशन churn बढ़ा सकता है, क्योंकि टिकट underlying प्रोडक्ट समस्याओं का लक्षण थे—कारण नहीं।
Correlation‑based explanations distribution shifts में भी नाज़ुक होती हैं: यूज़र व्यवहार बदल जाने पर वही हाइलाइट किए गए फीचर अब वही मतलब नहीं रखते।
कारणात्मक व्याख्याएँ खासकर तब उपयोगी होती हैं जब निर्णयों के परिणाम और जवाबदेही मायने रखते हैं:
जब कार्रवाई करनी हो, व्याख्या को causal बैकबोन चाहिए।
A/B टेस्ट causal inference का सबसे सरल, सबसे व्यवहारिक रूप है। जब आप यूज़र्स को यादृच्छिक रूप से variant A या B असाइन करते हैं, आप एक intervention कर रहे होते हैं: आप सिर्फ यह नहीं देख रहे कि लोगों ने क्या चुना, आप यह सेट कर रहे हैं कि वे क्या देखें। Pearl की भाषा में, randomization “do(variant = B)” को वास्तविक बनाती है—इसलिए परिणामों के अंतर को विश्वसनीय रूप से परिवर्तन के कारण माना जा सकता है, न कि एक्सपोज़र चुनने वालों के कारण।
रैंडम असाइंमेंट कई छिपे लिंक तोड़ देता है यूज़र गुण और एक्सपोज़र के बीच। पावर यूज़र्स, नए यूज़र, दिन का समय, डिवाइस प्रकार—ये सब मौजूद रहते हैं, पर औसतन वे समूहों में संतुलित होते हैं। वही संतुलन मेर्ट्रिक गैप को कारणात्मक दावे में बदल देता है।
शानदार टीम भी हमेशा साफ़ randomized टेस्ट नहीं चला सकती:
इन स्थितियों में भी आप कारणात्मक सोच सकते हैं—बस मान्यताओं और अनिश्चितता के बारे में स्पष्ट रहें।
सामान्य विकल्पों में शामिल हैं difference-in-differences (समूहों के बीच समय के साथ होने वाले बदलावों की तुलना), regression discontinuity (कटऑफ़ नियम का उपयोग जैसे “केवल स्कोर X से ऊपर”), instrumental variables (कोई प्राकृतिक नudge जो एक्सपोज़र बदलता है पर सीधे परिणाम नहीं), और matching/weighting ताकि समूह अधिक तुलनीय हों। हर विधि रैंडमाइजेशन के बदले मान्यताओं का व्यापार करती है; एक causal डायग्राम आपको वे मान्यताएँ स्पष्ट करने में मदद करेगा।
टेस्ट (या observational study) शिप करने से पहले लिख दें: प्राथमिक मीट्रिक, guardrails, लक्षित आबादी, अवधि, और निर्णय नियम। प्री‑रजिस्ट्रेशन bias खत्म नहीं करेगा पर मीट्रिक‑शॉपिंग कम करेगा और causal दावों को टीम के लिए अधिक भरोसेमंद और बहस‑योग्य बनाएगा।
अधिकांश प्रोडक्ट बहसें इस तरह सुनाई देती हैं: “Metric X शिप करने के बाद हिल गया—तो Y ने काम किया।” causal सोच इसे कसकर ऐसे सवाल में बदल देती है: “क्या बदलाव Y ने metric X को हिलाया, और कितना?” यह बदलाव डैशबोर्ड को प्रमाण से लेकर शुरुआत के बिंदु में बदल देता है।
प्राइसिंग बदलाव: “क्या कीमत बढ़ने से राजस्व बढ़ा?” की बजाय पूछें:
Onboarding tweak: “नए उपयोगकर्ता अब ज्यादा onboarding पूरा कर रहे हैं” की बजाय पूछें:
Recommendation ranking change: “CTR बेहतर हुई” की बजाय पूछें:
डैशबोर्ड अक्सर “जिसे बदलाव मिला” और “जो वैसे भी अच्छा करता” को मिला देते हैं। एक क्लासिक उदाहरण: आप नया onboarding flow शिप करते हैं, पर वह सबसे पहले उन यूज़र्स को दिखाया जाता है जिनके पास नया ऐप वर्ज़न है। अगर नया वर्ज़न अधिक एंगेज्ड यूज़र्स द्वारा अपनाया जाता है, तो आपका चार्ट एक लिफ्ट दिखा सकता है जो आंशिक (या पूरी तरह) वर्ज़न एडॉप्शन का है, न कि onboarding का।
अन्य सामान्य confounders:
एक उपयोगी PRD सेक्शन सचमुच “Causal Questions” शीर्षक का हो सकता है, और इसमें शामिल हो:
अगर आप तेज़ बिल्ड‑लूप का उपयोग कर रहे हैं (खासकर LLM‑सहायता वाले विकास के साथ), यह सेक्शन और भी महत्वपूर्ण बन जाता है: यह रोकता है कि “हम तेज़ी से शिप कर सकते हैं” का अर्थ न बन जाए “हमने बिना जानने के शिप कर दिया।” Koder.ai जैसी प्लेटफ़ॉर्म का उपयोग करने वाली टीमें अक्सर इन causal सवालों को प्लानिंग मोड में पहले से जोड़ती हैं, फिर feature-flagged वैरिएंट्स तेज़ी से इम्प्लीमेंट करती हैं, साथ में snapshots/rollback ताकि जब परिणाम (या साइड‑इफेक्ट्स) चौंकाएँ तो सुरक्षित रहें।
PM निर्णय और सफलता मानदण्ड परिभाषित करते हैं। डेटा साथी इसे मापने योग्य causal अनुमान और sanity checks में अनुवाद करते हैं। इंजीनियरिंग परिवर्तन को नियंत्रित बनाती है (feature flags, साफ़ exposure logging)। सपोर्ट गुणात्मक संकेत साझा करता है—प्राइसिंग बदल अक्सर “काम” करती दिखती है पर गुप्त रूप से रद्दीकरण या टिकट वॉल्यूम बढ़ा देती है। जब सभी एक causal प्रश्न पर सहमत हों, तब शिपिंग सीखने बन जाता है—सिर्फ शिप नहीं।
कारणात्मक सोच के लिए PhD की ज़रूरत नहीं है। इसे टीम की आदत बनाइए: अपनी causal कहानी लिखें, उसे परीक्षण में डालें, फिर डेटा (और एक्सपेरिमेंट्स जहाँ संभव हों) से उसे पुष्टि या सुधारने दीजिए।
अग्रिम रूप से चार इनपुट इकट्ठा करें:
व्यवहार में, तेज़ी मायने रखती है: जितनी जल्दी आप causal सवाल को नियंत्रित बदलाव में बदल सकेंगे, उतना ही कम समय आप अस्पष्ट पैटर्नों पर बहस में गंवाएंगे। यही कारण है कि टीमें Koder.ai जैसी प्लेटफ़ॉर्म अपनाती हैं ताकि “हाइपोथेसिस + योजना” से काम कर रहा, instrumented इम्प्लीमेंटेशन (वेब, बैकएंड, या मोबाइल) दिनों में बन सके—वो भी staged rollouts और rollback के साथ ताकि शॉर्ट‑सर्किट हुए नतीजों से सुरक्षित रहा जा सके।
यदि आप एक्सपेरिमेंट्स पर रिफ्रेशर चाहते हैं, तो देखें /blog/ab-testing-basics. सामान्य traps के लिए जो प्रोडक्ट मीट्रिक्स में “effects” की नकल करते हैं, देखें /blog/metrics-that-mislead.
कारणात्मक सोच का सार यह है: “क्या साथ‑चलता है?” से “अगर हमने कार्रवाई की तो क्या बदलेगा?” पर संक्रमण। Judea Pearl द्वारा लोकप्रिय किया गया यह बदलाव टीमों को वे आत्मविश्वासी कहानी बताने से बचाता है जो वास्तविक दुनिया के इंटरवेंशनों में टिकती नहीं।
Correlation एक सुराग है, उत्तर नहीं।
कारणात्मक डायग्राम (DAGs) मान्यताओं को दिखाते और बहस योग्य बनाते हैं।
Interventions (“do”) अवलोकनों (“see”) से अलग हैं।
Counterfactuals एकल मामलों को समझाते हैं: “इस एक चीज़ के अलग होने पर क्या होता?”
अच्छा कारणात्मक काम अनिश्चितता और वैकल्पिक व्याख्याओं को दस्तावेज़ करता है।
कारणात्मकता सावधानी मांगती है: छिपे confounders, मापन त्रुटियाँ, और चयन प्रभाव निष्कर्ष उल्टा कर सकते हैं। इसका इलाज पारदर्शिता है—मान्यताएँ लिखें, उपयोग किए गए डेटा को दिखाएँ, और वह बताएं कि आपकी दावे को खारिज करने के लिए क्या होना चाहिए।
यदि आप गहराई से जानना चाहते हैं, तो /blog पर संबंधित लेख पढ़ें और causal दृष्टिकोणों की तुलना अन्य एनालिटिक्स और “explainability” तरीकों से करें ताकि यह देखें कि कौन‑सा कब मददगार है—और कहाँ वह भ्रामक हो सकता है।
Correlation आपको भविष्यवाणी या डिटेक्शन में मदद करता है (जैसे “जब X बढ़ता है तो अक्सर Y भी बढ़ता है”)। Causation एक निर्णय-सवाल का जवाब देता है: “अगर हम जानबूझकर X बदलें तो क्या Y बदलेगा?”
पूर्वानुमान और मॉनिटरिंग के लिए correlation का उपयोग करें; जब आप कोई बदलाव शिप करने जा रहे हों, नीति तय कर रहे हों या बजट आवंटित कर रहे हों तो causal सोच का उपयोग करें।
क्योंकि उस सहसंबंध के पीछे confounding हो सकता है। नोटिफिकेशन के उदाहरण में, बहुत सक्रिय यूज़र अधिक नोटिफिकेशन ट्रिगर/प्राप्त करते हैं और साथ ही अधिक लौटते भी हैं।
अगर आप सबके लिए नोटिफिकेशन बढ़ा देते हैं, तो आपने अनुभव (experience) बदल दिया—एक intervention किया—बिना मूल engagement बदले। इसलिए retention नहीं बढ़ता और कभी-कभी घट भी सकता है।
DAG (Directed Acyclic Graph) एक सरल आरेख है जहाँ:
यह उपयोगी इसलिए है कि यह मान्यताओं को स्पष्ट करता है—कौन सी चीज़ें adjust करने योग्य हैं, किन्हें न करें, और कौन सा एक्सपेरिमेंट वास्तव में सवाल का जवाब देगा।
एक सामान्य गलती है “सब कुछ control कर लो”, जिससे आप अनजाने में mediators या colliders को adjust करके परिणाम को biased कर सकते हैं।
“See” वह है जो नेचुरली हुआ उसे देखना (उपयोगकर्ता opted in थे, स्कोर ऊँचा था)। “Do” वह है जब आप सक्रिय रूप से किसी वैरिएबल को सेट करते हैं (फीचर शिप करना, किसी डिफ़ॉल्ट को बदलना)।
कुंजी यह है: intervention सामान्य कारणों को तोड़ देती है कि कोई वैरिएबल क्यों किसी मान पर है; इसलिए यह observation की तुलना में अधिक विश्वसनीय रूप से कारण और प्रभाव को उजागर कर सकती है।
एक counterfactual पूछता है: इस खास केस के लिए, अगर हमने कुछ और किया होता तो क्या होता।
यह उपयोगी है:
यह एक causal मॉडल पर निर्भर करता है ताकि आप असंभव परिकल्पनाएँ न सुझाएँ।
ध्यान दें कि ऊपर क्या बदला—यह पता लगाना महत्वपूर्ण है और मॉडल अक्सर किसी आसान proxy का फायदा उठा लेता है:
एक causal दृष्टिकोण आपको targeted interventions (ablations, perturbations) चलाने के लिए प्रेरित करता है बजाय कि संयोगिक मीट्रिक मूवमेंट्स के पीछे भागने के।
जरूरी नहीं। फीचर इम्पोर्टेंस बताती है किसने prediction को प्रभावित किया, न कि क्या बदलना चाहिए।
एक बेहद “important” फीचर proxy या लक्षण हो सकता है (उदाहरण: support tickets churn का predictor)। proxy पर हस्तक्षेप (“support घटायें”) उल्टा असर कर सकता है। causal explanations महत्व को वैध लीवर्स और इंटरвенशन के नतीजों से जोड़ती हैं।
जब संभव हो तो randomized A/B टेस्ट सबसे अच्छा है। पर जब न काम करे तो वैकल्पिक तरीक़े हैं—जब:
ऐसे मामलों में quasi-experiments जैसे difference-in-differences, regression discontinuity, instrumental variables, या matching/weighting पर विचार करें—पर assumptions स्पष्ट रखें।
PRD में एक छोटा सेक्शन जोड़ें जो आरम्भ में स्पष्टता पैदा करे:
यह टीम को post-hoc dashboard-स्टोरीटेलिंग के बजाय एक causal सवाल पर aligned रखता है।