وجہ دریافت: کیا کاکریل کی بانگ سورج کے طلوع ہونے کا سبب بنتی ہے؟

ازگر کوڈ کی 10 لائنیں کارآمد دریافت کو خودکار بنانے کے لیے جو آپ کو دیکھنے کو ملی ہیں۔

میری حالیہ تحقیق کا محور رہا ہے۔ causal inference بڑھتی ہوئی درخواستوں کی وجہ سے مجھے گاہکوں سے مشین لرننگ کی پیشین گوئیوں سے آگے بڑھ کر جواب دینے کے لیے "کیا-اگر؟" اثرات اور نتائج کو بڑھانے کے لیے سوالات ٹائپ کریں۔

ان چیزوں میں سے ایک جس نے مجھے ابتدائی طور پر متوجہ کیا تھا - "کازل ڈایاگرام کیسے بنائے جاتے ہیں؟"۔ بہت ساری آن لائن مثالوں میں ایسا لگتا ہے کہ وہ مکمل طور پر زندگی میں داخل ہوتے ہیں جس کی کوئی وضاحت نہیں ہوتی ہے کہ نوڈس اور لنکس کی شناخت کیسے کی گئی۔

اس کی وجہ سے میں نے جوڈیا پرل اور ڈانا میکنزی (کئی بار!) کی "دی بک آف کیوں" کو پڑھا اور ایک نقطہ نظر کا اظہار کیا گیا کہ آپ ڈیٹا سے ایک causal ڈایاگرام، جسے ڈائریکٹڈ Acyclic گراف (DAG) بھی کہا جاتا ہے، کو ریورس نہیں کر سکتے۔ اکیلے

ڈیٹا باہمی تعلق کو ظاہر کر سکتا ہے لیکن وجہ نہیں، تو یہ کیسے ممکن ہے کہ وجہ کو "دریافت" کیا جائے؟

نوٹ: اس مضمون کے تمام ڈیٹا سیٹ عوامی استعمال کے لیے لائسنس یافتہ ہیں، براہ کرم تمام ذرائع اور حوالہ جات کے لیے مضمون کے آخر میں حوالہ جات کا سیکشن دیکھیں۔

اس سے پہلے کہ ہم وجہ دریافت میں غوطہ لگائیں براہ کرم غور کریں…

میرے ریفرل لنک کے ساتھ میڈیم میں شامل ہونا (اگر آپ اس لنک کو استعمال کرکے سائن اپ کریں گے تو مجھے فیس کا ایک تناسب ملے گا)۔

جب بھی میں کوئی نئی کہانی شائع کرتا ہوں تو مفت ای میل کو سبسکرائب کرنا.

میرے پچھلے مضامین پر ایک سرسری نظر ڈالنا.

میرا مفت اسٹریٹجک ڈیٹا پر مبنی فیصلہ سازی کا فریم ورک ڈاؤن لوڈ کرنا.

میری ڈیٹا سائنس کی ویب سائٹ ملاحظہ کرنا — ڈیٹا بلاگ.

درج ذیل بائنری ڈیٹا سیٹ سے قدر کی گنتی پر غور کریں…

نوٹ: سورج طلوع / کاکریل ڈیٹا سیٹ مصنف کی طرف سے تخلیق کردہ مصنوعی ڈیٹا ہے، براہ کرم مکمل ماخذ اور حوالہ جات کی تفصیلات کے لیے مضمون کے آخر میں حوالہ جات کا سیکشن دیکھیں۔

ہم دیکھ سکتے ہیں کہ 90.25% مشاہدات میں سورج طلوع ہونے پر کاکریل بانگ دیتا ہے لیکن ہم کیسے جان سکتے ہیں کہ سورج کے طلوع ہونے سے مرغ بانگ دیتا ہے یا صرف اعداد و شمار کی بنیاد پر کاکریل کے بانگ سے سورج نکلتا ہے؟

ان مثالوں کی تعداد جب کاکریل بانگ دیتا ہے جب سورج طلوع نہیں ہوتا ہے یا جب سورج طلوع ہوتا ہے لیکن کاکریل خاموش رہتا ہے وہ تقریباً ایک جیسے ہیں (50,000 بمقابلہ 47,500) اس لیے اعداد و شمار کے متعلقہ حجم کا موازنہ کرکے اس کا جواب تلاش نہیں کیا جاسکتا۔

ایک نقطہ نظر دنیاوی پہلو کو دیکھنا ہو سکتا ہے۔ اگر سورج کاکریل کے بانگ سے پہلے مسلسل طلوع ہوتا ہے تو یہ وجہ کا ایک اچھا اشارہ ہوگا لیکن اگر ہمارا کاکریل ابتدائی طلوع ہو تو کیا ہوگا؟

اس کا جواب ڈومین کے ماہرین سے مشورہ کرنا ہے۔ اگر ہم ایک نجومی، ماہر طبیعیات اور پولٹری فارمرز کے ساتھ ایک ٹیم جمع کر سکتے ہیں تو وہ یہ نتیجہ اخذ کریں گے کہ سورج کاکریل کو بانگ دے رہا ہے نہ کہ دوسری طرف!

سورج کے طلوع ہونے اور کاکریلوں کی بانگوں سے بے خوف ہو کر میں کسی ایسی چیز کی تلاش میں نکلا جو پہلے سے موجود تھی جو اعداد و شمار کی بنیاد پر کارآمد دریافت کا جادو کر سکے۔

"NOTEARS" نامی ایک الگورتھم ہے جو کازل دریافت کو لاگو کرنے کے قابل ہونے کا دعویٰ کرتا ہے، تو آئیے اسے آزمائیں اور دیکھیں کہ یہ کیا کر سکتا ہے…

نوٹ: چیچک ڈیٹا سیٹ مصنف کے ذریعہ تخلیق کردہ مصنوعی ڈیٹا ہے، براہ کرم مکمل ماخذ اور حوالہ کی تفصیلات کے لیے مضمون کے آخر میں حوالہ جات کا سیکشن دیکھیں۔

یہ ڈیٹا سیٹ چیچک کی ویکسینیشن میں وجہ اور اثر کے تعلقات کو ماڈل بنا رہا ہے۔ آئیے اس کے خلاف NOTEARS الگورتھم چلائیں اور دیکھیں کہ یہ کیا کر سکتا ہے…

[('رد عمل؟'، 'ویکسینیشن؟')
('چیچک؟'، 'رد عمل؟')
('موت؟'، 'رد عمل؟')
('موت؟'، 'چیچک؟')]

اگر ہم NOTEARS کے ذریعہ تیار کردہ نتائج کا تصور کریں تو یہ اس طرح نظر آئے گا…

یہ بہت اچھا نہیں لگتا ہے کیا؟ NOTEARS کے مطابق موت چیچک کا سبب بن رہی ہے۔ دنیاوی پہلو ہمیں بتاتا ہے کہ چیچک پہلے آتا ہے اس لیے یہ موت کی وجہ سے نہیں ہو سکتا۔ اور نہ ہی چیچک رد عمل کا سبب بن سکتا ہے (ویکسین رد عمل کا سبب بنتی ہے) اور ردعمل یقینی طور پر ویکسینیشن کا سبب نہیں بن سکتا۔

ڈومین کے ماہرین کے علم کو استعمال کرتے ہوئے ہم آسانی سے یہ ثابت کر سکتے ہیں کہ ویکسینیشن کا اس بات پر کوئی اثر ہوتا ہے کہ آیا مریض کو کوئی ردعمل ہوتا ہے یا نہیں اور آیا وہ بیماری کی نشوونما کرتا ہے اور رد عمل اور چیچک دونوں کا موت کے ساتھ ایک تعلق ہے…

لہٰذا، ہم نے یہ قائم کیا ہے کہ ایک انتہائی سادہ کازل ماڈل میں بھی NOTEARS causal Discovery algorithm درست نتائج نہیں دیتا۔ اس کے علاوہ، میرے پچھلے مضامین میں سے ایک کے ایک قاری نے نشاندہی کی کہ Python 3.9 میں NOTEARS کام نہیں کرتا اور جیسا کہ میں اپ گریڈ کرنے جا رہا ہوں یہ ایک اور بڑا مسئلہ ہے۔

اگر آپ NOTEARS کی وجہ کے لیے غیر موزوں ہونے کے بارے میں مزید پڑھنا چاہتے ہیں تو یہاں ایک بہترین علمی مقالہ ہے۔ https://arxiv.org/pdf/2104.05441.pdf (مارکس قیصر اور میکسم سیپوس)۔

اس سے پہلے کہ ہم مکمل طور پر خودکار وجہ دریافت کو ترک کر دیں، آئیے نوٹیئرز کے متبادل پر ایک نظر ڈالتے ہیں، "لاسو" الگورتھم -

نوٹ: مردم شماری کی آمدنی / گریجویٹ آمدنی کا ڈیٹا سیٹ عوامی استعمال کے لیے لائسنس یافتہ ہے، براہ کرم مکمل ماخذ اور حوالہ کی تفصیلات کے لیے مضمون کے آخر میں حوالہ جات کا سیکشن دیکھیں۔

اوہ عزیز، لاسو ایک آفت ہے! اس نے پیش گوئی کی ہے کہ ہر چیز ہر چیز کا سبب بن رہی ہے اور یہ کہ نوڈس بھی خود کا سبب بنتے ہیں!

میری آخری کوششیں GES، GIES اور LINGAM الگورتھم کو آزمانا تھیں لیکن ان سب کو R لائبریریوں کی ضرورت ہوتی ہے۔ میں R کا استعمال نہیں کرتا اور یہاں تک کہ اگر میں نے ترتیب کو صحیح طریقے سے حاصل کرنے کا انتظام کیا تو میں کبھی بھی پورٹیبل کوڈ نہیں بنا سکوں گا جسے دوسرے ڈیٹا سائنسدان استعمال کر سکیں۔

کارآمد دریافت کی لائبریریاں اور الگورتھم جو دستیاب ہیں وہ کام نہیں کرتے ہیں اور اس نے "دی بک آف کیوں" میں بیان کردہ نظریہ کو دوبارہ نافذ کیا ہے یعنی کہ وجہ کو صرف ڈیٹا سے ریورس انجنیئر نہیں کیا جاسکتا۔

اس نتیجے نے مجھے اپنا نقطہ نظر تیار کیا…

میز پر کارڈ، میں نے ایک causal دریافت الگورتھم نہیں لکھا ہے. بلکہ میرا الگورتھم ایک موڑ کے ساتھ ارتباطی دریافت کو نافذ کرتا ہے (کوئی پن کا ارادہ نہیں!)

جب میں نے causal دریافت کی لائبریریوں کو ترک کر دیا تھا تو مجھے اب بھی ڈومین کے ماہرین کے ساتھ گفتگو کے نقطہ آغاز کے طور پر وجہ کو دیکھنے کے لیے ایک طریقہ درکار تھا۔

میں نے استدلال کیا کہ میں آسانی سے خصوصیات / نوڈس کے مابین ارتباط کا حساب لگا سکتا ہوں اور یہ کم از کم ایک اچھا نقطہ آغاز ہوگا۔

میں نے اپنی سوچ کو اس طرح تیار کیا — کارآمد دریافت کے ماڈلز میں ہم عام طور پر "اثر" یعنی ڈیٹا فیچر کی نشاندہی کرتے ہیں جس میں ہماری دلچسپی ہے (جیسے مشین لرننگ کی پیشین گوئیوں میں "ٹارگٹ")۔ چیچک کی مثال میں یہ ہے “موت؟

اس لیے اگر کسی خصوصیت اور "اثر" کے درمیان باہمی ربط موجود ہے تو اس کی وجہ کی سمت دیگر خصوصیات سے اثر تک ہونی چاہیے کیونکہ یہ "لائن کے آخر" میں ہے۔

میرا اگلا مرحلہ ایک بار بار چلنے والا الگورتھم تیار کرنا تھا جس کا تصور اس طرح کیا جا سکتا ہے…

ڈپلیکیٹس اور دو طرفہ لنکس کو زبردستی خارج کر دیا جانا چاہیے۔ میں کنکشنز (کناروں) کو واضح طور پر شامل یا خارج کرنے اور خصوصیات (نوڈس) کو واضح طور پر خارج کرنے کے قابل بھی ہونا چاہتا ہوں۔

یہ 10 لائنیں تکراری پائیتھن کوڈ کی ہیں جو میں نے کارآمد دریافت کو نافذ کرنے کے لیے پیش کی ہیں۔

یہ بتانے کے لیے کہ حل کیسے کام کرتا ہے میں نے ہوٹل کی بکنگ منسوخی کے ڈیٹا پر کچھ ڈیٹا منتخب کیا ہے۔

آئیے ڈیٹا کو پڑھ کر اور ارتباط پر ایک جھانک کر شروع کریں…

نوٹ: ہوٹل کی بکنگ کا ڈیٹا سیٹ عوامی استعمال کے لیے لائسنس یافتہ ہے، براہ کرم مکمل ماخذ اور حوالہ کی تفصیلات کے لیے مضمون کے آخر میں حوالہ جات کا سیکشن دیکھیں۔

دریافت الگورتھم کے پہلے رن میں تکرار کو 1 تک کم رکھنا شامل ہے لہذا ہم صرف "اثر" کے ساتھ ارتباط کو دیکھ رہے ہیں (جس کا سبب ہونا چاہئے) یعنی ہوٹل کی بکنگ منسوخ ہو گئی ہے یا نہیں …

ٹھیک ہے، یہ کوئی بری شروعات نہیں ہے، آئیے تکرار / تکرار / تہوں کی تعداد کو 3 تک بڑھاتے ہیں، ارتباط کی حد کو تھوڑا سا موافقت کرتے ہیں اور دیکھتے ہیں کہ ہمیں کیا ملتا ہے …

ٹھیک ہے، زیادہ برا بھی نہیں ہے، لیکن یہ تھوڑا سا "مصروف" ہے لہذا اگلا مرحلہ کچھ ایسے نوڈس کو خارج کرنا ہے جن کے بارے میں ہمیں شبہ ہے کہ شاید کچھ شور پیدا ہو رہا ہے (نوٹ: حقیقی دنیا کے کاروباری معاملے میں ہم بات کر رہے ہوں گے۔ اس مرحلے پر ہمارے ڈومین ماہرین)۔

یہ بہتر نظر آنے لگا ہے۔ یاد رکھیں کہ میرا الگورتھم پراعتماد ہے کہ "IsCancelled" کے لنکس کارآمد ہیں کیونکہ یہ "اثر" ہے، اس لیے اس کے بعد کچھ نہیں آتا۔

درخت کی دوسری پرتیں محض ارتباطی ہیں اگرچہ، تیروں کی سمت صرف اس ترتیب کی بنیاد پر شامل کی گئی تھی جس میں الگورتھم نے انہیں پایا تھا۔

ڈومین کے ماہرین کے ساتھ کام کرتے ہوئے (یا اس مثال میں ہوٹل کی بکنگ کا میرا اپنا تجربہ!) میں نے درج ذیل کو دیکھا -

• "DifferentRoomAssigned" سے "LeadTime" تک کا لنک غلط سمت میں ہے کیونکہ بکنگ کا ایک طویل وقت اس امکان کو بڑھاتا ہے کہ کمرے کی بکنگ بدل جائے گی نہ کہ اس کے برعکس۔
• "BookingChanges" اور "DifferentRoomAssigned" کے درمیان تعلق حد سے نیچے ہے لیکن یہ ایک اہم وجہ ہو سکتا ہے اس لیے اسے شامل کرنے کی ضرورت ہے۔

اگلی کوشش الگورتھم کو یہ اصلاحات کرنے کی ہدایت کرتی ہے -

ایک "غیر مشاہدہ کنفاؤنڈر" ایک ایسا عنصر ہے جس کے بارے میں ہمیں یقین ہے کہ کچھ نوڈس کے درمیان ایک ربط فراہم کرکے ہمارے کازل ماڈل پر اثر انداز ہو رہا ہے، لیکن اس کی پیمائش نہیں کی گئی ہے اور اس لیے اسے خاکہ میں شامل نہیں کیا گیا ہے۔

ہوٹلوں میں جانے کے میرے تجربے اور ہوٹلوں کے ڈیٹاسیٹ کے بارے میں میرے علم نے مجھے شک کیا کہ ہوٹلوں کے ڈیٹا کو متاثر کرنے والا کوئی "غیر مشاہدہ کنفاؤنڈر" ہے۔

ڈیٹا میں دو ہوٹل ہیں - ایک "شہر" ہوٹل اور ایک "ریزورٹ" ہوٹل۔ یہ مجھے اس مفروضے کی طرف لے جاتا ہے کہ اس causal ماڈل میں غیر مشاہدہ کنفاؤنڈر ہے۔ "ہوٹل میں قیام کی وجہ".

میرا مفروضہ یہ ہے۔ چھٹیاں منانے والے بنیادی طور پر ریزورٹ ہوٹل میں ٹھہرتے ہیں اور کاروباری لوگ اور شہر توڑنے والے بنیادی طور پر سٹی ہوٹل میں ٹھہرتے ہیں.

مزید برآں میں نے یہ قیاس کیا ہے کہ ان دونوں گروہوں کے رویے مختلف ہیں اور یہ "غیر مشاہدہ کنفاؤنڈر" ہے (غیر مشاہدہ شدہ کیونکہ ڈیٹا "قیام کی وجہ" کو نہیں پکڑتا)۔

نوٹس اور اسی طرح کے دوسرے الگورتھم "غیر مشاہدہ شدہ کنفاؤنڈرز" کا حساب نہیں دے سکتے لیکن میں نے جو الگورتھم تیار کیا ہے وہ ان کو مندرجہ ذیل طور پر واضح طور پر شامل کر کے ان کو مدنظر رکھ سکتا ہے …

حتمی تکرار کا نتیجہ ہوٹل کے اعداد و شمار میں وجہ کے لیے قابل فہم، پڑھنے کے قابل اور قابل فہم تصور ہے جسے میں ڈومین کے ماہرین کے ساتھ دریافت کرنے اور بہتر کرنے کے لیے پراعتماد ہوں گا۔ یہ اہم نکات ہیں…

• ایک "غیر مشاہدہ کنفاؤنڈر" ہے جو قیام کی بنیادی وجہ ہے (چھٹی بمقابلہ کاروبار / شہر کا وقفہ)۔
• غیر مشاہدہ کنفاؤنڈر پر "ملک" کا ایک سبب اثر ہوتا ہے - کچھ ممالک سے سفر کرنے والوں کے چھٹی پر ہونے کا امکان زیادہ ہوتا ہے۔
• یہی بات "TotalGuests" پر لاگو ہوتی ہے۔ بڑی پارٹیوں کے چھٹیاں منانے، سنگلز کا بزنس ٹرپ پر اور شہر کے وقفوں پر ڈبلز کا زیادہ امکان ہوتا ہے۔
• غیر مشاہدہ شدہ "قیام کی وجہ" کا "لیڈ ٹائم"، "ہوٹل ٹائپ" اور "ڈپازٹ ٹائپ" پر ایک کارآمد اثر پڑتا ہے۔
• "LeadTime"، "DifferentRoom Assigned"، "HotelType"، "DepositType" اور "Reason for Stay" (U) سب کا "Is Canceled" پر کارآمد اثر ہوتا ہے۔

Causal Discovery کیا کارل لنکس کو دریافت کرنے کے لیے ارتباطی روابط سے آگے جانے کا عمل ہے (یعنی تیر کا تعلق ارتباطی لکیر کے کس سرے پر ہے؟)۔ یہ ممکن نہیں ہے، یا کم از کم ممنوعہ طور پر مشکل ہے، NOTEARS جیسے الگورتھم کے ساتھ خودکار کرنا کیونکہ جوابات صرف ڈیٹا میں موجود نہیں ہیں۔

تاہم، اب بھی وجہ کو دیکھنے کی ایک اہم ضرورت ہے تاکہ اس کو ڈومین کے ماہرین کے ساتھ دریافت کیا جا سکے تاکہ ایک کازل ڈایاگرام بنایا جا سکے (جسے ڈائریکٹڈ ایسکلک گراف یا ڈی اے جی بھی کہا جاتا ہے)۔

اس مضمون میں ازگر کے کوڈ کی صرف 10 لائنوں کا استعمال کرتے ہوئے متعلقہ دریافت کو بڑھانے پر مبنی ایک الگورتھم تجویز کیا گیا ہے جسے ڈومین ماہرین کے ساتھ حساسیت (تھریشولڈ) کو بار بار بہتر کرنے اور لنکس (تیر) کو درست کرنے، شامل کرنے یا ہٹانے اور غیر متعلقہ کو خارج کرنے کے لیے استعمال کیا جا سکتا ہے۔ نوڈس

مستقبل کے مضامین میں یہ causal diagrams کا استعمال ایک مکمل فلون causal مشین لرننگ ماڈل بنانے کے لیے کیا جائے گا جو پیچیدہ جواب دے سکتا ہے "کیا ہو گا؟" صارفین اور کاروباری رہنماؤں سے سوالات ٹائپ کریں۔

اگر آپ کو یہ مضمون پسند آیا تو براہ کرم غور کریں…

میرے ریفرل لنک کے ساتھ میڈیم میں شامل ہونا (اگر آپ اس لنک کو استعمال کرکے سائن اپ کریں گے تو مجھے فیس کا ایک تناسب ملے گا)۔

جب بھی میں کوئی نئی کہانی شائع کرتا ہوں تو مفت ای میل کو سبسکرائب کرنا.

میرے پچھلے مضامین پر ایک سرسری نظر ڈالنا.

میرا مفت اسٹریٹجک ڈیٹا پر مبنی فیصلہ سازی کا فریم ورک ڈاؤن لوڈ کرنا.

میری ڈیٹا سائنس کی ویب سائٹ ملاحظہ کرنا — ڈیٹا بلاگ.

سورج طلوع / کاکریل کراؤنگ ڈیٹا

چیچک کا ڈیٹا

گریجویٹ کی آمدنی / مردم شماری کی آمدنی کا ڈیٹا

ہوٹل بکنگ کا ڈیٹا

وجہ دریافت: کیا کاکریل کی بانگ سورج کے طلوع ہونے کا سبب بنتی ہے؟ ماخذ https://towardsdatascience.com/causal-discovery-does-the-cockerel-crowing-cause-the-sun-to-rise-f4308453ecfa?source=rss—-7f60cf5620c9—4 سے https://towardsdatascience کے ذریعے دوبارہ شائع کیا گیا۔ com/feed

<!–

->