Scikit-learn: सुझाव: प्लॉट_कॉन्फ्यूजन_मैट्रिक्स से पूर्वानुमान हटाएं और केवल अनुमानित लेबल पास करें

हमें निश्चित रूप से पिछड़ा संगत रहना चाहिए, लेकिन y_pred कीवर्ड तर्क जोड़ना मेरे लिए उचित लगता है। यदि y_pred पास हो जाता है लेकिन X या अनुमानक भी पास हो जाता है तो हमें एक त्रुटि उठानी चाहिए।

क्या आप एक पीआर @jhennrich सबमिट करना चाहेंगे?

मैंने एक पीआर जमा किया है, लेकिन मुझे लगता है कि वर्तमान में सीआई के साथ एक समस्या है इसलिए यह अभी तक पारित नहीं हुआ है।

मैं सहमत हूं कि कई बार भविष्यवाणी की गणना से बचने के लिए हमें plot_XXX(y_true, y_pred) का समर्थन करना चाहिए।
हमारे पास प्लॉट_रोक_कर्व और प्लॉट_प्रेसिजन_रेकॉल_कर्व में भी इसी तरह के मुद्दे हैं।
Y_pred जोड़ना स्वीकार्य लगता है, लेकिन ईमानदारी से मुझे नहीं लगता कि यह एक अच्छा समाधान है।
उन कार्यों के लिए जो **kwargs स्वीकार करते हैं (उदाहरण के लिए, plot_precision_recall_curve), ऐसा लगता है कि पिछड़ा संगत रखना असंभव है?

पिछड़ी संगतता को बनाए रखना असंभव क्यों है? मुझे ऐसा लगता है कि #15883 में प्रस्ताव ठीक है

पिछड़ी संगतता को बनाए रखना असंभव क्यों है? मुझे ऐसा लगता है कि #15883 में प्रस्ताव ठीक है

क्योंकि हम प्लॉट_कॉन्फ्यूजन_मैट्रिक्स में **kwargs का समर्थन नहीं करते हैं। @निकोलसहुग

क्वार्ग एक समस्या क्यों है?

हम्म, तो एक और कष्टप्रद बात है, हम प्लॉट_रोक_कर्व और प्लॉट_प्रेसिजन_रेकॉल_कर्व (और प्लॉट_पार्टियल_डिपेंडेंस) में **kwargs का समर्थन करते हैं, लेकिन हम इसका समर्थन प्लॉट_कॉन्फ्यूजन_मैट्रिक्स में नहीं करते हैं

क्वार्ग एक समस्या क्यों है?

अगर हम **kwargs से पहले नया पैरामीटर जोड़ते हैं, तो हम पश्चगामी संगतता रख सकते हैं, है ना?

मेरे पीआर में परिवर्तन पश्चगामी संगत हैं और **kwargs अभी भी जोड़े जा सकते हैं। लेकिन मैं @ qinhanmin2014 से सहमत हूं, एक बहुत अधिक क्लीनर समाधान estimator और X को फेंक देना और स्थितिगत तर्कों (y_true, y_pred, ...) का उपयोग करना होगा जो कि अधिकांश के अनुरूप हैं अन्य स्केलेर सामान।

अगर हम **kwargs से पहले नया पैरामीटर जोड़ते हैं, तो हम पश्चगामी संगतता रख सकते हैं, है ना?

हां

बहुत अधिक क्लीनर समाधान ....

दुर्भाग्य से इसके लिए एक बहिष्करण चक्र की आवश्यकता होगी (जब तक कि हम इसे बगफिक्स रिलीज में बहुत तेज नहीं बनाते लेकिन मुझे इसमें संदेह है ...)

@thomasjpfan , अनुमानक को भविष्यवाणियों के बजाय इनपुट के रूप में पास करने का कोई कारण?

धन्यवाद, आइए पहले y_pred जोड़ें, **kwags एक और समस्या है।

दुर्भाग्य से इसके लिए एक बहिष्करण चक्र की आवश्यकता होगी (जब तक कि हम इसे बगफिक्स रिलीज में बहुत तेज नहीं बनाते लेकिन मुझे इसमें संदेह है ...)

यह असंभव लगता है, आह

@thomasjpfan , अनुमानक को भविष्यवाणियों के बजाय इनपुट के रूप में पास करने का कोई कारण?

मैं सहमत हूं कि हमें अपने एपीआई डिजाइन पर पुनर्विचार करने की जरूरत है। @amueller . को पिंग करने का भी प्रयास करें

यदि कोई उपयोगकर्ता अपना स्वयं का प्लॉटिंग भाग प्रदान करना चाहता है और अपना स्वयं का भ्रम मैट्रिक्स प्रदान करना चाहता है:

from sklearn.metrics import ConfusionMatrixDisplay
confusion_matrix = confusion_matrix(...)
display_labels = [...]

disp = ConfusionMatrixDisplay(confusion_matrix=confusion_matrix,
                              display_labels=display_labels)
disp.plot(...)

यह अन्य मीट्रिक प्लॉटिंग कार्यों के लिए भी ऐसा ही किया जा सकता है।

plot_confusion_matrix स्कोरर की तरह डिज़ाइन किया गया है जो अनुमानकों के आउटपुट को अच्छी तरह से संभालने में सक्षम हैं। दूसरे शब्दों में, यह ConfusionMatrixDisplay और अनुमानक के साथ बातचीत करने के लिए एक सुविधाजनक आवरण है।

पहले अनुमानक को स्वीकार करके, प्लॉटिंग कार्यों के लिए एक समान इंटरफ़ेस होता है। उदाहरण के लिए, plot_partial_dependence आंशिक निर्भरता प्लॉट बनाने के लिए आवश्यक सभी गणना करता है और इसे PartialDependenceDisplay । एक उपयोगकर्ता अभी भी PartialDependenceDisplay स्वयं बना सकता है, लेकिन उस स्थिति में यह अधिक शामिल होगा।

हालांकि, मैं एक "फास्ट पाथ" के लिए तैयार हूं, जिससे y_pred को मेट्रिक्स से संबंधित प्लॉटिंग फ़ंक्शंस में पारित करने की अनुमति मिलती है, जिसे सीधे confusion_matrix और इसे सत्यापन से निपटने दें।

पीडीपी बनाने के लिए आवश्यक पूर्वानुमानों की गणना काफी जटिल है। साथ ही, ये पूर्वानुमान आमतौर पर अनुपयोगी होते हैं जैसे स्कोरर या मीट्रिक। वे केवल पीडीपी की साजिश रचने के लिए उपयोगी हैं। इसलिए इस मामले में केवल प्लॉट_पार्टियल_डिपेंडेंस में अनुमानक को स्वीकार करना समझ में आता है।

भ्रम मैट्रिक्स के लिए ओटीओएच, भविष्यवाणियां वास्तव में केवल est.predict(X) ।

मुझे नहीं लगता कि हम यहां एक समान इंटरफेस चाहते हैं। ये 2 बहुत अलग इनपुट उपयोग-मामले हैं

संपादित करें: इसके अलावा, पेड़-आधारित पीडीपी को भविष्यवाणियों की बिल्कुल भी आवश्यकता नहीं है

ऐसी और भी चीज़ें हैं जिन पर हम बिना अनुमानक के चलेंगे। उदाहरण के लिए यदि plot_precision_recall_curve को y_pred स्वीकार करना था, तो उसे pos_label आवश्यकता होगी क्योंकि अब इसका अनुमान नहीं लगाया जा सकता है। इस मामले में, मैं सीधे PrecisionRecallDisplay का उपयोग करना पसंद करूंगा और उपयोगकर्ता को साजिश के पुनर्निर्माण के लिए आवश्यक पैरामीटर की गणना करना होगा।

यह नीचे आता है कि हम इस एपीआई के साथ किस प्रकार के प्रश्न का उत्तर दे रहे हैं। वर्तमान इंटरफ़ेस एक अनुमानक का मूल्यांकन करने के इर्द-गिर्द घूमता है, इस प्रकार अनुमानक को एक तर्क के रूप में उपयोग करता है। यह "यह प्रशिक्षित मॉडल इस इनपुट डेटा के साथ कैसे व्यवहार करता है?" का उत्तर देकर प्रेरित होता है।

यदि हम y_pred, y_true स्वीकार करते हैं, तो अब प्रश्न यह हो जाता है कि "यह मीट्रिक इस डेटा के साथ कैसा व्यवहार करता है?" यह डेटा एक मॉडल द्वारा उत्पन्न किया जा सकता है या नहीं भी हो सकता है।

यह सच है कि इस विशिष्ट मामले में, @jhennrich आप सीधे ConfusionMatrixDisplay का उपयोग कर सकते हैं।

एक कमी यह है कि आपको display_labels निर्दिष्ट करने की आवश्यकता है क्योंकि इसमें कोई डिफ़ॉल्ट नहीं है।

@thomasjpfan क्या आपको लगता है कि हम सामान्य रूप से डिस्प्ले ऑब्जेक्ट्स के लिए समझदार डिफ़ॉल्ट प्रदान कर सकते हैं, इस प्रकार अभी भी डिस्प्ले ऑब्जेक्ट्स का प्रत्यक्ष उपयोग व्यावहारिक बना सकते हैं?

कुछ मापदंडों के लिए, जैसे display_labels , एक उचित डिफ़ॉल्ट है। अन्य Display ऑब्जेक्ट पैरामीटर में उचित डिफ़ॉल्ट भी हो सकते हैं। कुछ मापदंडों को प्रदान किया जाना चाहिए। उदाहरण के लिए, confusion_matrix को ConfusionMatrixDisplay या precision और recall लिए PrecisionRecallDisplay ।

इस तरह की चीज़ के लिए एक क्लासिक पैटर्न परिभाषित कर रहा है:

ConfusionMatrixDisplay.from_estimator(...)
ConfusionMatrixDisplay.from_predictions(...)

लेकिन यह विज्ञान-सीखने के लिए बहुत मुहावरेदार नहीं है।

मैं भ्रमित होने लगता हूँ। वर्तमान एपीआई का लक्ष्य कई बार गणना करने से बचना है यदि उपयोगकर्ता कई बार प्लॉट करना चाहते हैं, लेकिन अगर हम y_true और y_pred स्वीकार करते हैं, तो उपयोगकर्ताओं को अभी भी कई बार गणना करने की आवश्यकता नहीं है? (मुझे पता है कि पीडीपी में चीजें अलग हैं)

@jnothman वह एपीआई बहुत अच्छी लग रही है!

@ qinhanmin2014 एक estimator, X, y या y_true, y_pred पास करना "कई बार गणना न करें" एपीआई को संतुष्ट करने में काम करता है। दोनों ही मामलों में, भ्रम मैट्रिक्स की गणना की जाती है और Display ऑब्जेक्ट में संग्रहीत किया जाता है।

उनके बीच का अंतर वह जगह है जहां भ्रम मैट्रिक्स की गणना शुरू होती है। कोई y_pred को अनुमानक के "पूर्व-गणना" मान के रूप में पास करने के बारे में सोच सकता है।

इसलिए मुझे लगता है कि y_true, y_pred estimator, X, y (निश्चित रूप से पीडीपी में नहीं) से बेहतर है, क्योंकि कभी-कभी (अक्सर?) उपयोगकर्ता न केवल भविष्यवाणियों को प्लॉट करना चाहते हैं, वे भविष्यवाणियों का विश्लेषण भी करना चाहते हैं। वर्तमान एपीआई के साथ, उन्हें कई बार पूर्वानुमानों की गणना करने की आवश्यकता होगी।

मेट्रिक्स के लिए, मैं y_true, y_pred से अधिक estimator, X, y का उपयोग करने की प्राथमिकता देख सकता हूं। कल्पना कीजिए कि मेट्रिक्स के लिए प्लॉटिंग केवल y_true, y_pred

est = # fit estimator

plot_partial_dependence(est, X, ...)

# if plot_confusion_matrix accepts `y_true, y_pred`
y_pred = est.predict(X)
plot_confusion_matrix(y_true, y_pred, ...)

# if plot_roc_curve supports `y_true, y_score`
y_score = est.predict_proba(X)[: , 1]
plot_roc_curve(y_true, y_score, ...)
plot_precision_recall_curve(y_true, y_score, ...)

वर्तमान में एपीआई की तरह दिखता है:

est = # fit estimator
plot_partial_dependence(est, X, ...)
plot_confusion_matrix(est, X, y, ...)
plot_roc_curve(est, X, y, ...)

# this will call `predict_proba` again
plot_precision_recall_curve(est, X, y, ...)

मैं एक एपीआई रखना पसंद करूंगा जो दोनों विकल्पों (किसी तरह) का समर्थन करता हो।

मेट्रिक्स के लिए, मैं y_true, y_pred ओवर एस्टीमेटर, X, y का उपयोग करने की प्राथमिकता देख सकता हूं। कल्पना कीजिए कि मेट्रिक्स के लिए प्लॉटिंग केवल y_true, y_pred . का समर्थन करता है

हाँ, मेरा यही मतलब है।

मैं एक एपीआई रखना पसंद करूंगा जो दोनों विकल्पों (किसी तरह) का समर्थन करता हो।

मुझे लगता है कि यह एक व्यावहारिक समाधान है। एक कष्टप्रद बात यह है कि हम अंत में केवल y_pred जोड़ सकते हैं (यानी, प्लॉट_कॉन्फ्यूजन_मैट्रिक्स (अनुमानक, एक्स, y_true, ..., y_pred))

हाँ यह अंत में होगा और एपीआई इस तरह दिखेगा:

plot_confusion_matrix(y_true=y_true, y_pred=y_pred, ...)

जो मुझे लगता है कि मैं ठीक हूँ। यह अनिवार्य रूप से पीआर है https://github.com/scikit-learn/scikit-learn/pull/15883

हाँ यह अंत में होगा और एपीआई इस तरह दिखेगा प्लॉट_कॉन्फ्यूजन_मैट्रिक्स (y_true = y_true, y_pred = y_pred, ...)

मुझे लगता है कि आपका मतलब है कि हमें y_true जोड़ना चाहिए और एस्ट और एक्स को हटा देना चाहिए, है ना? मुझे लगता है कि यह असंभव है? (क्योंकि हम अंत में केवल y_pred जोड़ सकते हैं)

क्या हम इसे 0.22.1 में हल करना चाहते हैं? @NicolasHug @thomasjfox मुझे लगता है कि यह 0.22.1 में इस डाल करने के लिए सार्थक है, लेकिन एक ही समय में, लगता है कि इस एक नई सुविधा है।

नहीं, इसे 0.22.1 में न डालें। यह स्पष्ट रूप से सेवर का उल्लंघन है

@ qinhanmin2014 अंत में y_pred जोड़ना या est, X को हटाना एक नई सुविधा की तरह लगता है जो अगली रिलीज में है।

मुझे लगता है कि आपका मतलब है कि हमें y_true जोड़ना चाहिए और एस्ट और एक्स को हटा देना चाहिए, है ना? मुझे लगता है कि यह असंभव है?

अंत में मैं दोनों इंटरफेस का समर्थन करना पसंद करूंगा, क्योंकि उनके पास थोड़ा अलग उपयोग का मामला है।

1. est, X त्वरित विश्लेषण करना आसान है, क्योंकि फ़ंक्शन प्रतिक्रिया फ़ंक्शन को चुनने, परिणाम को टुकड़ा करने और इसे मीट्रिक में पास करने का काम करता है।
2. y_true, y_pred उन उपयोगकर्ताओं के लिए है जो समझते हैं कि अंतर्निहित मीट्रिक के साथ कैसे काम करना है और पूर्वानुमान पहले से सहेजे गए हैं।

https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -565489619 करने में क्या समस्या है?

मैंने इस पूरे धागे को नहीं पढ़ा है, लेकिन अगर हम यहां इंटरफ़ेस की अनुमति देते हैं, तो हमें इसे plot_roc_curve लिए भी करने की आवश्यकता है, जहां इंटरफ़ेस पूर्वानुमान प्रदान करने और अनुमानक प्रदान करने के बीच काफी भिन्न होगा (एक को pos_label की आवश्यकता होती है और दूसरे को इसकी आवश्यकता होती है) 'टी)।
तो मुझे लगता है कि दोनों को एक ही इंटरफ़ेस में अनुमति देना एक बुरा विचार है (कोई अनुमानक पास करते समय pos_label पास करेगा और परिणाम प्राप्त करेगा जिसकी वे अपेक्षा नहीं करते हैं)।

ConfusionMatrixDisplay.from_estimator(...)
ConfusionMatrixDisplay.from_predictions(...)

काम कर सकता है, लेकिन यह मूल रूप से plot_confusion_matrix बेमानी बना देगा, और इसलिए हम कार्यों को फिर से हटा देंगे और वर्ग और फ़ंक्शन के बीच जिम्मेदारियों को बदल देंगे (हमने कहा कि वर्ग गणना नहीं करता है)।

अगर हम from_predictions से plot_roc_curve जोड़ना चाहते हैं तो इसे मूल रूप से roc_curve इंटरफ़ेस को पूरी तरह से प्रतिबिंबित करने की आवश्यकता है। इसलिए मुझे नहीं लगता कि उपयोगकर्ता को roc_curve फ़ंक्शन को सीधे कॉल करना बहुत बुरा है और फिर परिणामों को डिस्प्ले ऑब्जेक्ट पर पास करना है।

डिस्प्ले ऑब्जेक्ट्स के डिज़ाइन का पूरा उद्देश्य @jhennrich द्वारा उल्लिखित

@amueller तकनीकी रूप से आप सही हैं, मेरे मुद्दे का वर्तमान समाधान केवल ConfusionMatrixDisplay । हालांकि यह उपयोग करने के लिए वास्तव में बेकार है:

• आपको लेबल को स्पष्ट रूप से पास करना होगा
• आपको पहले भ्रम मैट्रिक्स की गणना करनी होगी
• आपको कक्षा का ऑब्जेक्ट बनाना होगा और फिर भी plot विधि को कॉल करना होगा

सभी अनुप्रयोगों के लिए मैं सोच सकता हूं कि plot_confusion_matrix हस्ताक्षर के साथ (y_true, y_pred, ...) हमारे पास वर्तमान की तुलना में कहीं अधिक सुविधाजनक होगा। मेरी राय में बहुत अधिक उपयोग-मामले हैं जहां आप भविष्यवाणियों की स्पष्ट रूप से गणना करना चाहते हैं (हालांकि मुझे यकीन है कि मेरा विचार पक्षपातपूर्ण है)।

यदि आपके पास plot_confusion_matrix(y_true, y_pred) हस्ताक्षर है और आप वास्तव में इसे estimator , x , y डेटा पर उपयोग करना चाहते हैं, तो लिखने के लिए केवल बहुत कम अतिरिक्त कोड है : plot_confusion_matrix(y, estimator.predict(x)) ।
इसकी तुलना में, यदि आपके पास वर्तमान हस्ताक्षर है और आप y_true और y_pred से प्लॉट करना चाहते हैं, तो आपको बहुत अधिक कोड लिखना होगा।

मेरी राय में plot_confusion_matrix(y_true, y_pred) हस्ताक्षर डिफ़ॉल्ट होना चाहिए और एक अन्य फ़ंक्शन जो estimator लेता है, x , y शीर्ष पर बनाया जाना चाहिए।

अंतिम लेकिन कम से कम, मैं ईमानदारी से ConfusionMatrixDisplay वर्ग के पीछे के विचार को वास्तव में नहीं समझता। फ़ंक्शन में केवल एक कंस्ट्रक्टर और बिल्कुल एक विधि होती है, इसलिए जब भी आप इसका उपयोग करते हैं तो आप एक उदाहरण बनाते हैं और plot फ़ंक्शन को कॉल करते हैं। मैं नहीं देखता कि यह एक वर्ग क्यों होना चाहिए, न कि केवल एक समारोह। इसके अलावा अन्य *Display कक्षाएं (PrecisionRecall, ROC, ...) हैं, लेकिन उनके निर्माता- और plot() हस्ताक्षर पूरी तरह से अलग हैं, इसलिए उन्हें वैसे भी स्वैप नहीं किया जा सकता है।
शायद यह इस मुद्दे के दायरे से बाहर है।

@जेनरिच

यदि आपके पास एक प्लॉट_कॉन्फ्यूजन_मैट्रिक्स (y_true, y_pred) हस्ताक्षर है और आप वास्तव में इसे अनुमानक, x, y डेटा पर उपयोग करना चाहते हैं, तो लिखने के लिए केवल बहुत कम अतिरिक्त कोड है: प्लॉट_कॉन्फ्यूजन_मैट्रिक्स (y, अनुमानक। भविष्यवाणी (x))।

भ्रम मैट्रिक्स मामले के लिए, यदि हमारे पास y_true, y_pred इंटरफ़ेस था तो estimator.predict में पास करना आसान है। दूसरी ओर, plot_roc_auc , उपयोगकर्ता को स्लाइसिंग करने की आवश्यकता होगी:

y_pred = est.predict_proba(X)
plot_roc_curve(y_true, y_pred[:, 1])

# or
y_pred = est.decision_function(X)
plot_roc_curve(y_true, y_pred[:, 1])

अंतिम लेकिन कम से कम, मैं ईमानदारी से ConfusionMatrixDisplay वर्ग के पीछे के विचार को वास्तव में नहीं समझता। फ़ंक्शन में केवल एक कंस्ट्रक्टर और बिल्कुल एक विधि होती है, इसलिए जब भी आप इसका उपयोग करते हैं तो आप एक उदाहरण बनाते हैं और प्लॉट फ़ंक्शन को कॉल करते हैं। मैं नहीं देखता कि यह एक वर्ग क्यों होना चाहिए, न कि केवल एक समारोह।

Display ऑब्जेक्ट्स का उद्देश्य गणना किए गए मानों को संग्रहीत करना है जिससे उपयोगकर्ता plot बिना किसी पुनर्गणना के कई बार कॉल कर सकते हैं। इसे plot_partial_dependence का उपयोग करके देखा जा सकता है:

# Does expensive computation
disp = plot_partial_dependence(est, ...)

# change line color without needing to recompute partial dependence
disp.plot(line_kw={"c": "red"})

ईमानदारी से, मैं इस मुद्दे को लेकर बाड़ पर हूं। मैं मेट्रिक्स की साजिश रचने और est, X, y इंटरफ़ेस को हटाने के लिए मीट्रिक इंटरफ़ेस की प्रतिलिपि बनाने की ओर बढ़ने के लिए +0.1 हूं। :/

भ्रम मैट्रिक्स मामले के लिए, अनुमानक में पास करना आसान है। अगर हमारे पास y_true, y_pred इंटरफ़ेस था तो भविष्यवाणी करें। दूसरी ओर, plot_roc_auc के लिए, उपयोगकर्ता को स्लाइसिंग करने की आवश्यकता होगी:

हां, लेकिन ऐसा करने से, हम कई बार भविष्यवाणी की गणना करने से बचते हैं (हालांकि भविष्यवाणी करना अक्सर इतना महंगा नहीं होता है)

शायद यह 0.23 में प्लॉट_XXX (जब लागू हो) में y_true, y_pred का समर्थन करने के लिए एक व्यावहारिक समाधान है।

@jhennrich लेबल को स्पष्ट रूप से पास किए बिना आप confusion_matrix दिए गए लेबल से अनुमान लगाया जा सकता है तो वह आपके लिए करेगा।

लेकिन वास्तव में आप सही कह रहे हैं, यह एक के बजाय तीन पंक्तियाँ हैं।

भ्रम_मैट्रिक्स के मामले में मैं इस बात से सहमत हूं कि अधिक सामान्य मामला y_true और y_pred ।
इंटरफ़ेस वर्तमान में अन्य मीट्रिक प्लॉटिंग फ़ंक्शंस के अनुरूप होने का कारण है। जैसा कि @thomasjpfan ने कहा, साजिश के लिए रॉक वक्र कम स्पष्ट है।

अभी एक भ्रम मैट्रिक्स की साजिश रचने और एक आरओसी वक्र की साजिश रचने के लिए कोड समान हैं। आपके सुझाए गए परिवर्तन के साथ, वे अब पहले जैसे नहीं रहेंगे, और उन्हें समान बनाने का कोई आसान तरीका नहीं होगा।

सवाल यह है कि क्या इस मामले में लगातार इंटरफेस होना या एक सरल इंटरफेस होना बेहतर है।
@jhennrich मेरे लिए असली सवाल यह है कि plot_roc_curve लिए सही इंटरफ़ेस क्या है। क्या आपके पास उस पर विचार हैं?

@thomasjpfan क्या आप roc auc की साजिश रचने के लिए y_store लेने की ओर झुकते हैं?

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

@qinhanmin2014
मुझे लगता है कि y_pred से plot_confusion_matrix जोड़ना ठीक रहेगा। सवाल यह है कि क्या हम y_score को plot_roc_curve और plot_precision_recall_curve जोड़ना चाहते हैं। अगर हम ऐसा करते हैं तो हमें pos_label भी जोड़ना होगा जैसा कि मैंने ऊपर कहा, और चीजें और अधिक जटिल हो जाएंगी।

मैं इसमें से तीन तरीके देखता हूं:
a) केवल y_pred को plot_confusion_matrix जोड़ें, लेकिन y_score को plot_roc_curve आदि में न जोड़ें। नकारात्मक पक्ष: predict_proba पर कॉल करने की समस्या इन मेट्रिक के लिए कई बार मौजूद रहता है.
बी) सीधे Display ऑब्जेक्ट का उपयोग करना आसान बनाएं (हालांकि मैं वास्तव में नहीं जानता कि कैसे)।
ग) मीट्रिक इंटरफ़ेस को प्रतिबिंबित करने वाली कोई अन्य विधि या फ़ंक्शन जोड़ें। नकारात्मक पक्ष: बड़ी एपीआई सतह।

मुझे नहीं लगता कि plot_X फ़ंक्शन मिरर एक ही समय में स्कोरर और मीट्रिक इंटरफ़ेस दोनों का होना सामान्य रूप से एक अच्छा विचार है।

मुझे लगता है कि इसे किसी तरह से हल करना बहुत अच्छा होगा @adrinjalali क्या आप अगली बैठक में इस पर चर्चा करना चाहते हैं?

मुझे कभी-कभी इस मुद्दे के बारे में बुरे सपने आते हैं। शायद हम एक स्थिर विधि जोड़ सकते हैं जो सीधे मीट्रिक का आउटपुट लेती है:

result = confusion_matrix(...)
ConfusionMatrixDisplay.from_metric(result).plot()

रॉक वक्र के लिए:

result = roc_curve(...)
RocCurveDisplay.from_metric(*result).plot()

एक तरफ ध्यान दें, कोडबेस को देखने से, मुझे लगता है कि स्कोर इंटरफ़ेस की तुलना में अधिक उपयोगकर्ता मेट्रिक्स इंटरफ़ेस से परिचित हैं।

मुझे कभी-कभी इस मुद्दे के बारे में बुरे सपने आते हैं।

नहीं ओ :(

एक तरफ ध्यान दें, कोडबेस को देखने से, मुझे लगता है कि स्कोर इंटरफ़ेस की तुलना में अधिक उपयोगकर्ता मेट्रिक्स इंटरफ़ेस से परिचित हैं।

मुझे लगता है कि यह निश्चित रूप से सच है। लेकिन मुझे यह भी पूरा यकीन है कि लोग y_pred का उपयोग तब करते हैं जब उन्हें y_score का उपयोग करना चाहिए और गलत परिणाम मिल रहे हैं क्योंकि इंटरफ़ेस आपको यह नहीं बताता है कि आपको कुछ अलग करने की आवश्यकता है और नहीं- कोई कभी डॉक्स पढ़ता है।

मुझे यकीन नहीं है कि आप जिस स्थिर विधि का प्रस्ताव देते हैं वह कन्स्ट्रक्टर से अलग है लेकिन शायद मैं कुछ देख रहा हूं।

नमस्ते, मैंने अभी-अभी इस मुद्दे पर अप-वोट दिया है - एक लंबे समय के स्केलेर उपयोगकर्ता के रूप में, मुझे plot_confusion_matrix लिए वर्तमान API बहुत... अच्छा, भ्रमित करने वाला मिला। मुझे वास्तव में इसका जोड़ (कम कॉपी-पेस्टिंग) पसंद है, लेकिन मेट्रिक्स फ़ंक्शन हमेशा (y_true, y_pred) योजना का उपयोग करते हैं जो कि अधिक लचीला है और जिसका मैं पहले से ही उपयोग कर चुका हूं।

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

मेरे मामले में अनुमानक को पास करने का कोई मतलब नहीं है, क्योंकि यह बहुत धीमा मॉडल है और मैं भविष्यवाणियों को लोड करना चाहता हूं

आपके सहयोग के लिए धन्यवाद। यदि वर्तमान एपीआई भ्रमित कर रहा है, तो यह अधिक मेट्रिक्स-एपीआई जैसे इंटरफ़ेस पर जाने और एक दर्दनाक बहिष्करण चक्र के माध्यम से जाने के लिए और अधिक समझ में आता है।

मेट्रिक्स इंटरफ़ेस का उपयोग करने के साथ हमारी सबसे बड़ी चिंता यह है:

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

@pzelasko इस मामले पर आपके क्या विचार हैं?

@thomasjpfan मैं इस मुद्दे को समझता हूं, यह एक कठिन है। हो सकता है कि इस फ़ंक्शन के लिए केवल कीवर्ड तर्कों की अनुमति देने के लिए एक उचित समझौता होगा (अब आपको पायथन 2 का समर्थन करने की आवश्यकता नहीं है)? जैसे: def plot_confusion_matrix(*, y_true, y_pred, ...) । यह अभी भी बाकी मेट्रिक्स से अलग है, लेकिन 1) इसके लिए इसका एक अच्छा कारण है, 2) यह कम से कम अन्य कार्यों के समान प्रकार के इनपुट का उपयोग कर रहा है।

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

y_true और y_pred का उपयोग करने का वर्तमान तरीका यहां दिखाया गया है: https://scikit-learn.org/stable/auto_examples/miscellaneous/plot_display_object_visualization.html#create -confusionmatrixdisplay

मुझे पता है कि मैं यहाँ खींच रहा हूँ लेकिन इसके बारे में क्या:

plot_confusion_matrix(estimator='precomputed', y_true, y_pred, ...)

जहां दूसरी स्थिति y_true को भविष्यवाणियों के रूप में स्वीकार करती है यदि estimator='precomputed ।

यदि आप और भी अधिक फैलाना चाहते हैं तो मैं plot_confusion_matrix((estimator, X, y), ...) या plot_confusion_matrix((y_true, y_pred), ...) करूंगा लेकिन मुझे यकीन नहीं है कि यह मीट्रिक-जैसी एपीआई के संबंध में @amueller द्वारा उठाए गए मुद्दों को हल कर रहा है

कुछ नई प्लॉटिंग उपयोगिताएँ हैं जहाँ metric API की अनुमति देना वास्तव में समझ में आता है:

• plot_prediction_error https://github.com/scikit-learn/scikit-learn/pull/18020 में
• plot_calibration_curve में https://github.com/scikit-learn/scikit-learn/pull/17443 (CC @lucyleeow )

मैं इस मुद्दे को समझता हूं कि @amueller ने pos_label आदि पास करने की आवश्यकता के बारे में उल्लेख किया है, लेकिन यह उपरोक्त कार्यों में से किसी के लिए कोई समस्या नहीं है।

क्या हम इन दोनों के लिए स्कोरर और मेट्रिक्स एपीआई दोनों का समर्थन करने के लिए ठीक हैं? हमें वहां पिछड़ी संगतता के बारे में चिंता करने की आवश्यकता नहीं है।

मैं अभी भी precomputed का उपयोग करने के अपने सुझाव के लिए हूं, जिसे हम आमतौर पर अपने अनुमानकों में उपयोग करते हैं। इस मामले में, हस्ताक्षर होंगे:

plot_confusion_matrix(estimator='precomputed', y_true, y_pred, ..., metric_kwargs=None)

मैं यह देखने के लिए पीआर को एक साथ रखूंगा कि यह कैसा दिखता है।

मैं वास्तव में अभी तक एपीआई पर चर्चा नहीं कर रहा हूं, मैं केवल यह पूछ रहा हूं कि क्या हम नए पीआर के लिए दोनों विकल्पों का समर्थन करने के लिए ठीक हैं।

(लेकिन एपीआई के संबंध में, मुझे नहीं लगता कि 'प्रीकंप्यूटेड' बहुत मदद करता है: हम X बारे में क्या करते हैं? मुझे लगता है कि हमें ठीक से त्रुटि करके (y_pred) और (अनुमानक, एक्स) परस्पर अनन्य रखना चाहिए इसके अलावा अनुमानक के लिए पूर्व-गणना किए जाने का क्या अर्थ है?)

या estimator='none' , estimator='predictions' , estimator='precomputed_predictions' , और फिर X y_pred या y_score । यह लगभग वैसा ही है जैसे हम अनुमानकों में X साथ पूर्व-गणना की गई दूरियों को कैसे संभालते हैं।

क्या हम इन दोनों के लिए स्कोरर और मेट्रिक्स एपीआई दोनों का समर्थन करने के लिए ठीक हैं?

हम दोनों विकल्पों का समर्थन कैसे करेंगे? दो कार्यों के साथ?

मुझे यह भी पसंद आया होगा:

CalibrationDisplay.from_estimator(...)
CalibrationDisplay.from_predictions(...)

जो दो तरीके होंगे।

टुपल्स https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -670590882 का उपयोग करने का गिलाउम का सुझाव एक विकल्प है। मुझे लगता है कि यह सबसे अच्छा विकल्प होता अगर हम शुरुआत से ही वहीं से शुरू कर देते। लेकिन मुझे डर है कि टुपल्स का उपयोग मौजूदा उपयोगिताओं के साथ स्थिरता को तोड़ता है।

पारस्परिक बहिष्करण के साथ plot_XYZ(estimator=None, X=None, y=None, y_pred=None) एक अन्य विकल्प है, और फिलहाल मैं इसी की वकालत कर रहा हूं।

मुझे CalibrationDisplay.from_estimator(...) , लेकिन जैसा कि एंडी ने नोट किया, हमें तब plot_XYZ फ़ंक्शंस को हटाना होगा। यह विचार करने योग्य हो सकता है।

मुझे लगता है कि हम टुपल्स में जा सकते हैं और वर्तमान व्यवहार को हटा सकते हैं। (जब तक हम टुपल्स का उपयोग करने के लिए सहमत हैं)

तो ऐसा लगता है जैसे नामस्थानों पर चर्चा करना, है ना?
चाहे हमारे पास एक फ़ंक्शन और एक कंस्ट्रक्टर, या दो क्लासमेथड्स, या दो फ़ंक्शन हों, यह बिल्कुल समान कार्यक्षमता और मूल रूप से एक ही कोड है।

@pzelasko @jhennrich आप दो क्लासमेथड्स या दो फ़ंक्शन रखने के बारे में कैसा महसूस करते हैं? या आप एक एकल फ़ंक्शन पसंद करेंगे, जो कि अजगर में थोड़ा गड़बड़ है।

और यदि आप दो कार्यों या दो वर्ग विधियों को पसंद करते हैं, तो क्या आपको खोज योग्य होने के बावजूद कोई लाभ दिखाई देता है? डिस्कवरेबिलिटी क्लासमेथड्स करने के लिए पर्याप्त कारण हो सकती है, हालांकि, मुझे दो कार्यों के लिए एक मजबूत तर्क नहीं दिख रहा है।

क्या हम यहां अवरोधक लेबल जोड़ सकते हैं? ऐसा लगता है कि यह #18020 और #17443 पर प्रगति को रोक रहा है (cc @cmarmo)

ब्लॉकर लेबल रिलीज ब्लॉकर्स के लिए है (ऐसी चीजें जिन्हें रिलीज से पहले ठीक करने की जरूरत है), पीआर ब्लॉकर्स के लिए नहीं

आह जानकर अच्छा लगा।

@pzelasko @jhennrich आप दो क्लासमेथड्स या दो फ़ंक्शन रखने के बारे में कैसा महसूस करते हैं? या आप एक एकल फ़ंक्शन पसंद करेंगे, जो कि अजगर में थोड़ा गड़बड़ है।

और यदि आप दो कार्यों या दो वर्ग विधियों को पसंद करते हैं, तो क्या आपको खोज योग्य होने के बावजूद कोई लाभ दिखाई देता है? डिस्कवरेबिलिटी क्लासमेथड्स करने के लिए पर्याप्त कारण हो सकती है, हालांकि, मुझे दो कार्यों के लिए एक मजबूत तर्क नहीं दिख रहा है।

मुझे दो-वर्ग के तरीके सबसे अधिक पसंद हैं, विशेष रूप से from_xxx पैटर्न - sth जैसे @thomasjpfan प्रस्तावित:

CalibrationDisplay.from_estimator(...)
CalibrationDisplay.from_predictions(...)

ऐसा लगता है कि 2 वर्ग विधियों का उपयोग करने का कोई प्रबल विरोध नहीं है, तो चलिए ऐसा करते हैं। हमें आवश्यकता होगी:

• वर्तमान में मौजूदा भूखंडों के लिए वर्ग विधियों का परिचय दें:

  • ConfusionMatrixDisplay
  • PrecisionRecallDisplay
  • RocCurveDisplay
  • DetCurveDisplay
  • PartialDependenceDisplay । इसके लिए, हम from_predictions वर्ग पद्धति का परिचय नहीं देना चाहते क्योंकि इसका कोई मतलब नहीं होगा, हम केवल from_estimator ।

• ऊपर सूचीबद्ध सभी प्रदर्शनों के लिए, उनके संगत plot_... फ़ंक्शन को हटा दें। हमें plot_det_curve को पदावनत करने की आवश्यकता नहीं है क्योंकि इसे अभी तक जारी नहीं किया गया है, हम इसे केवल हटा सकते हैं।

• #१७४४३ और #१८०२० जैसे नए पीआर के लिए हम plot फ़ंक्शन शुरू करने के बजाय तुरंत वर्ग विधियों को लागू कर सकते हैं।

यह थोड़ा सा काम है लेकिन मुझे लगता है कि हम इसे 0.24 से पहले कर सकते हैं ताकि #17443 और #18020 पहले ही आगे बढ़ सकें।

कोई आपत्ति @thomasjpfan @jnothman @amueller @glemaitre ?

@jhennrich @pzelasko , क्या आप डिस्प्ले ऑब्जेक्ट्स में से किसी एक में क्लास विधियों को पेश करने के लिए पीआर सबमिट करने में रुचि रखते हैं?

@NicolasHug निर्णय लेने के लिए धन्यवाद! मैं #17443 पर पहुंचूंगा (आपत्तियों की प्रतीक्षा करने के बाद)

मुझे कोई आपत्ति नहीं है।

आपत्ति भी नहीं है।

मैं तब अन्य कक्षाओं का ध्यान रखूंगा और अपने रुके हुए पीआर को आगे बढ़ाऊंगा।
@lucyleeow मामले में मैंने उन सभी को नहीं किया और आप कुछ

मुझे योगदान देना अच्छा लगेगा लेकिन मैं इस समय बहुत अधिक परियोजनाओं में लगा हुआ हूं। सुझावों को सुनने के लिए धन्यवाद!

बढ़िया है :)