मैं यह सुनिश्चित करने में कैसे मदद कर सकता हूं कि परीक्षण डेटा प्रशिक्षण डेटा में लीक नहीं होता है?


60

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

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

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

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

क्या कोई ऐसा तरीका है जिसे मैंने ओवरफिटिंग और परीक्षण रिसाव की समस्या को दूर करने में मदद करने के लिए अनदेखी की है जबकि अभी भी एक अनुभवहीन उपयोगकर्ता के लिए कुछ हद तक स्पष्ट है?


माइकल, मैंने एमएल साइट से एक डुप्लिकेट थ्रेड बंद कर दिया और यहां उत्तर मिला दिए। कृपया इस प्रश्न को संपादित करने के लिए स्वतंत्र महसूस करें कि आप जो भी बदलाव करना चाहते हैं, उसे प्रतिबिंबित करें - मैं अनजाने में अपने अर्थ को बदलने के डर से ऐसा नहीं करना चाहता।
whuber

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

जवाबों:


50

आप सही हैं, यह मशीन सीखने / सांख्यिकीय मॉडलिंग में एक महत्वपूर्ण समस्या है। अनिवार्य रूप से वास्तव में इस समस्या को हल करने का एकमात्र तरीका स्वतंत्र परीक्षण सेट को बनाए रखना है और अध्ययन पूरा होने तक इसे बाहर रखना है और अंतिम सत्यापन के लिए इसका उपयोग करना है।

हालांकि, अनिवार्य रूप से लोग परीक्षण सेट पर परिणामों को देखेंगे और फिर उसी के अनुसार अपना मॉडल बदलेंगे; हालांकि यह सामान्यीकरण के प्रदर्शन में आवश्यक रूप से सुधार नहीं करेगा क्योंकि विभिन्न मॉडलों के प्रदर्शन में अंतर मोटे तौर पर हमारे पास मौजूद परीक्षण डेटा के विशेष नमूने के कारण हो सकता है। इस मामले में, एक विकल्प बनाने में हम प्रभावी रूप से परीक्षण त्रुटि को ओवर-फिटिंग कर रहे हैं।

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

मैंने पाया है कि मॉडल चयन में इस तरह की ओवर-फिटिंग आम तौर पर सराहना की तुलना में बहुत अधिक परेशानी है, खासकर प्रदर्शन के संबंध में, देखें

GC Cawley और NLC टैलबोट, मॉडल चयन में ओवर-फिटिंग और प्रदर्शन मूल्यांकन में बाद के चयन पूर्वाग्रह, जर्नल ऑफ मशीन लर्निंग रिसर्च, 2010। रिसर्च, वॉल्यूम। 11, पीपी। 2079-2107, जुलाई 2010 (www)

इस तरह की समस्या विशेष रूप से बेंचमार्क डेटासेट के उपयोग को प्रभावित करती है, जिसका उपयोग कई अध्ययनों में किया गया है, और प्रत्येक नए अध्ययन का प्रभाव पूर्व के अध्ययनों के परिणामों से प्रभावित होता है, इसलिए देखा गया प्रदर्शन सच होने का अधिक आशावादी अनुमान होने की संभावना है विधि का प्रदर्शन। जिस तरह से मैं इसे प्राप्त करने की कोशिश करता हूं वह कई डेटासेट्स को देखने के लिए है (इसलिए विधि एक विशिष्ट डेटासेट के लिए ट्यून नहीं की गई है) और प्रदर्शन अनुमान के लिए कई यादृच्छिक परीक्षण / प्रशिक्षण विभाजन का भी उपयोग करते हैं (अनुमान के विचरण को कम करने के लिए)। हालांकि परिणामों को अभी भी चेतावनी की जरूरत है कि ये बेंचमार्क ओवर-फिट हैं।

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

यदि आप सांख्यिकीय रूप से शुद्ध परीक्षण सेट नहीं रख सकते हैं, तो मुझे डर है कि दो सबसे अच्छे विकल्प हैं (i) एक नया सांख्यिकीय शुद्ध परीक्षण सेट बनाने के लिए कुछ नए डेटा एकत्र करते हैं या (ii) नया मॉडल आधारित था। परीक्षण सेट त्रुटि को देखने के बाद की गई पसंद पर, इसलिए प्रदर्शन अनुमान में आशावादी पूर्वाग्रह होने की संभावना है।


1
+1 मैं इस बात से प्रभावित हूं कि इस उत्तर को अनुभव द्वारा कितनी अच्छी तरह बताया गया है और यह प्रश्न को प्रभावी ढंग से कैसे संबोधित करता है।
whuber

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

बहुत ही रोचक। (मैं भी सवाल ही upvoted है क्योंकि आपके उत्तर मुझे बेहतर सराहना कर दिया।)
whuber

2
(+1) अच्छी प्रतिक्रिया। एक ही डेटासेट पर कई क्लासिफायर का उपयोग, जो परीक्षण सटीकता की अधिक-आशावादी माप की उपज देता है , ऑप्टिमल क्लासिफायर चयन और त्रुटि दर अनुमान में नकारात्मक पूर्वाग्रह पर चर्चा की गई है : उच्च आयामी भविष्यवाणी , बीएमसी MRP 2009, 9:85 पर एक अनुभवजन्य अध्ययन ( यहां कुछ पीडीएफ स्लाइड्स के साथ), वर्गीकरण नियमों की तुलना में मल्टीपल-रूल पूर्वाग्रह में अन्य चर्चा के साथ (Yousefi et al।, Bioinformatics 2011, 27 (12): 1675)।
chl

कागजात के लिंक के लिए धन्यवाद, वे दिलचस्प दिखते हैं।
डिक्रान मार्सुपियल

15

यह सुनिश्चित करने का एक तरीका यह सुनिश्चित करना है कि आपने उन सभी चीजों को कोडित किया है जो आप मॉडल को फिट करने के लिए करते हैं, यहां तक ​​कि "टिंकरिंग" भी। इस तरह, जब आप प्रक्रिया को बार-बार चलाते हैं, तो क्रॉस-वैलिडेशन के माध्यम से कहते हैं, आप चीजों को रनों के बीच लगातार बनाए हुए हैं। यह सुनिश्चित करता है कि भिन्नता के सभी संभावित स्रोत क्रॉस-वेलिडेशन प्रक्रिया द्वारा कैप्चर किए गए हैं।

अन्य vitally महत्वपूर्ण बात यह सुनिश्चित करना है कि आपके पास एक प्रतिनिधि नमूना है, दोनों डेटा सेट में। यदि आपका डेटा सेट उस तरह के डेटा का प्रतिनिधि नहीं है जिसकी आप भविष्यवाणी करने के लिए उपयोग करने की उम्मीद करते हैं, तो ऐसा बहुत कुछ नहीं है जो आप कर सकते हैं। सभी मॉडलिंग इस धारणा पर टिकी हुई है कि "इंडक्शन" काम करता है - जिन चीजों को हमने नहीं देखा है वे उन चीजों की तरह व्यवहार करते हैं जिन्हें हमने देखा है।

एक सामान्य नियम के रूप में, जटिल मॉडल फिटिंग प्रक्रियाओं से दूर रहें जब तक कि (i) आपको पता न हो कि आप क्या कर रहे हैं, और (ii) आपने सरल तरीके आजमाए हैं, और पाया कि वे काम नहीं करते हैं, और जटिल विधि कैसे ठीक करती है सरल विधि के साथ समस्याओं। "सरल" और "जटिल" का अर्थ फिटिंग करने वाले व्यक्ति को "सरल" या "जटिल" के अर्थ में है। इसका कारण इतना महत्वपूर्ण है कि यह आपको उन परिणामों पर लागू करने की अनुमति देता है जो मुझे "सूँघने की परीक्षा" के लिए कहते हैं। क्या परिणाम सही दिखता है? आप ऐसी प्रक्रिया से परिणामों को "सूँघ" नहीं सकते, जिसे आप नहीं समझते हैं।

नोट: अगले, मेरा उत्तर की नहीं बल्कि लंबे समय तक हिस्सा मेरे अनुभव है, जो में है पर आधारित है क्षेत्र, के साथ संभवतः बड़े। मैं लगभग निश्चित हूं कि नीचे दी गई बातें या मामलों पर लागू नहीं होंगीN>>p p Np N<p

जब आपके पास एक बड़ा नमूना होता है, तो दिए गए अवलोकन का उपयोग करने और न करने के बीच का अंतर बहुत छोटा होता है, बशर्ते आपका मॉडलिंग बहुत "स्थानीय" न हो। ऐसा इसलिए है क्योंकि किसी दिए गए डेटा बिंदु का प्रभाव आमतौर पर का क्रम होता है । इसलिए बड़े डेटा सेटों में, परीक्षण डेटा सेट को "होल्ड आउट" से प्राप्त होने वाले अवशिष्ट मूल रूप से वही होते हैं जो आपको प्रशिक्षण डेटा सेट में उपयोग करने से प्राप्त होते हैं। आप इसे कम से कम वर्गों का उपयोग करके दिखा सकते हैं। अवशिष्ट जो आपको वें अवलोकन को छोड़कर मिलता है (यानी यदि हम परीक्षण सेट में अवलोकन सेट करते हैं तो परीक्षण सेट त्रुटि क्या होगी) , जहाँ प्रशिक्षण अवशिष्ट है, और1Nieitest=(1hii)1eitraineitrainhii वें डेटा बिंदु का लाभ उठाने वाला है । अब हमारे पास , जहाँ प्रतिगमन में चर की संख्या है। अब यदि , तो किसी भी लिए परीक्षण सेट और प्रशिक्षण सेट त्रुटियों के बीच एक प्रशंसनीय अंतर बनाने के लिए काफी मुश्किल है । हम एक सरल उदाहरण ले सकते हैं, मान लीजिए (अवरोधन और चर), डिज़ाइन मैट्रिक्स (प्रशिक्षण और परीक्षण सेट दोनों), और उत्तोलन हैiihii=ppN>>phiip=21N×pX

hii=xiT(XTX)1xi=1Nsx2(1xi)(x2¯x¯x¯1)(1xi)=1+x~i2N

जहाँ , , और । अंत में, मानकीकृत भविष्यवक्ता चर है, और मापता है कि कितने मानक विचलन का अर्थ है। इसलिए, हम शुरुआत से जानते हैं कि परीक्षण सेट त्रुटि प्रशिक्षण सेट के "किनारे पर" टिप्पणियों के लिए प्रशिक्षण सेट त्रुटि से बहुत बड़ी होगी। लेकिन यह मूल रूप से है कि प्रतिनिधि फिर से जारी करते हैं - "बीच में" टिप्पणियों की तुलना में "किनारे पर" कम प्रतिनिधि हैं। इसके अतिरिक्त, यह ऑर्डर करना है । इसलिए यदि आपके पास अवलोकन हैं, भले हीx¯=N1ixix2¯=N1ixi2sx2=x2¯x¯2x~i=xix¯sxxi1N100x~i=5 (अधिकांश परिभाषाओं द्वारा एक्स-स्पेस में एक बाहरी स्थिति), इसका मतलब , और परीक्षण त्रुटि को केवल कारक से समझा जाता है । यदि आपके पास एक बड़ा डेटा सेट है, तो बोलें , यह और भी छोटा है, , जो से कम है । वास्तव में, के लिए टिप्पणियों, आप का एक निरीक्षण की आवश्यकता होगी के लिए एक बनाने के लिए के तहत अनुमान परीक्षण सेट त्रुटि के, प्रशिक्षण सेट त्रुटि का उपयोग कर।hii=26100126100=7410010000126100001%10000x~=5025%

तो बड़े डेटा सेट के लिए, एक परीक्षण सेट का उपयोग करना न केवल अक्षम है, यह अनावश्यक भी है, इसलिए । यह ओएलएस के लिए लागू होता है और जीएलएम के लिए भी लगभग लागू होता है (विवरण जीएलएम के लिए अलग हैं, लेकिन सामान्य निष्कर्ष समान है)। से अधिक आयामों में, "आउटलेयर" बड़े "प्रमुख घटक" स्कोर के साथ टिप्पणियों द्वारा परिभाषित किया गया है। यह लिख कर दिखाया जा सकता है कहाँ (ओर्थोगोनल) आइजन्वेक्टर के लिए मैट्रिक्स है , eigenvalue मैट्रिक्स के साथ । हमें जहांN>>p2hii=xiTEET(XTX)1EETxiEXTXΛhii=ziTΛ1zi=j=1pzji2Λjjzi=ETxi लिए प्रमुख घटक स्कोर है ।xi

यदि आपके परीक्षण सेट में अवलोकन हैं, तो आपको एक मैट्रिक्स संस्करण , जहां और परीक्षण सेट में डिज़ाइन मैट्रिक्स की पंक्तियाँ हैं। इसलिए, ओएलएस प्रतिगमन के लिए, आप पहले से ही जानते हैं कि "परीक्षण सेट" त्रुटियां डेटा के सभी संभावित विभाजन प्रशिक्षण और परीक्षण सेटों में क्या होती हैं। इस मामले में ( ), डेटा को विभाजित करने की कोई आवश्यकता नहीं है। आप वास्तव में डेटा को विभाजित किए बिना "सबसे अच्छा मामला" और "सबसे खराब स्थिति" परीक्षण लगभग किसी भी आकार की त्रुटियों की रिपोर्ट कर सकते हैं। यह बहुत सारे पीसी समय और संसाधनों को बचा सकता है।ke{k}test=(IkH{k})1e{k}trainH{k}=X{k}(XTX)1X{k}TX{k}N>>p

मूल रूप से, यह सभी BIC या AIC जैसे प्रशिक्षण और परीक्षण त्रुटियों के बीच अंतर के लिए एक दंड शब्द का उपयोग करने के लिए कम करता है। यह प्रभावी रूप से उसी परिणाम को प्राप्त करता है जैसा कि एक परीक्षण सेट का उपयोग करता है, हालांकि आप संभावित उपयोगी जानकारी को फेंकने के लिए मजबूर नहीं होते हैं। BIC के साथ, आप मॉडल के लिए प्रमाण प्रस्तुत कर रहे हैं, जो गणितीय रूप से दिखता है:

p(D|MiI)=p(y1y2yN|MiI)

ध्यान दें कि इस प्रक्रिया में, हम किसी भी आंतरिक मापदंडों का अनुमान नहीं लगा सकते हैं - प्रत्येक मॉडल को पूरी तरह से निर्दिष्ट किया जाना चाहिए या इसके आंतरिक मापदंडों को एकीकृत किया जाना चाहिए। हालांकि, हम उत्पाद नियम का उपयोग करके और फिर परिणाम का लॉग लेकर, इस लुक को क्रॉस वेलिडेशन (एक विशिष्ट नुकसान फ़ंक्शन का उपयोग करके) बना सकते हैं:Mi

p(D|MiI)=p(y1|MiI)p(y2yN|y1MiI)
=p(y1|MiI)p(y2|y1MiI)p(y3yN|y1y2MiI)
==i=1Np(yi|y1yi1MiI)
log[p(D|MiI)]=i=1Nlog[p(yi|y1yi1MiI)]

यह क्रॉस सत्यापन का एक रूप सुझाता है, लेकिन जहां प्रशिक्षण सेट लगातार अपडेट किया जा रहा है, परीक्षण सेट से एक बार में एक अवलोकन - कलमन फ़िल्टर के समान। हम वर्तमान प्रशिक्षण सेट का उपयोग करके परीक्षण सेट से अगले अवलोकन की भविष्यवाणी करते हैं, सशर्त लॉग-लाइबिलिटी का उपयोग करके मनाया मूल्य से विचलन को मापते हैं, और फिर नए अवलोकन को शामिल करने के लिए प्रशिक्षण सेट को अपडेट करते हैं। लेकिन ध्यान दें कि यह प्रक्रिया सभी उपलब्ध डेटा को पूरी तरह से पचाती है, जबकि एक ही समय में यह सुनिश्चित करती है कि हर अवलोकन को "आउट-ऑफ-सैंपल" मामले के रूप में जांचा जाता है। यह भी अपरिवर्तनीय है, इसमें कोई फर्क नहीं पड़ता कि आप "अवलोकन 1" या "अवलोकन 10" को क्या कहते हैं; परिणाम समान है (गणना दूसरों की तुलना में कुछ क्रमपरिवर्तन के लिए आसान हो सकती है)। यदि हम परिभाषित करते हैं तो नुकसान का कार्य भी "अनुकूली" है L i iLi=log[p(yi|y1yi1MiI)] , फिर का तेज पर निर्भर करता है , क्योंकि हानि फ़ंक्शन लगातार नए डेटा के साथ अपडेट किया जा रहा है।Lii

मेरा सुझाव है कि इस तरह से अनुमानित मॉडल का आकलन करना काफी अच्छा काम करेगा।


4
+1 - लीवरेज की अच्छी सलाह और दिलचस्प चर्चा (बड़े डेटासेट के लिए)। मैं उन डेटासेट्स का उपयोग करने के लिए तैयार हूं जो छोटे हैं, जहां ओवर-फिटिंग की संभावना है, और ऐसी स्थितियों में अक्सर सीमांत संभावना ("सबूत") को ओवर-फिट करना बहुत आसान होता है, और आपके साथ शुरू होने की तुलना में एक बदतर मॉडल के साथ समाप्त होता है। मुझे संदेह है कि AIC और BIC समान रूप से "भंगुर" हैं। अनिवार्य रूप से अनुकूलन आँकड़ों में सभी बुराई की जड़ है, जैसा कि आप जो भी विकल्प बनाते हैं या पैरामीटर करते हैं, आप एक परिमित नमूने के आधार पर ट्यून करते हैं, ओवर-फिटिंग की संभावना का परिचय देता है। सीमांकन अधिक सुरक्षित है, लेकिन आम तौर पर कम्प्यूटेशनल रूप से महंगा है।
डिक्रान मार्सुपियल

2
+1 - विशेष रूप से तीसरे पैराग्राफ पर (पहले सरल विधियों का उपयोग करें)। अच्छे राजभाषा 'परेटो-नियम की याद दिलाता है। अगर मशीन सीखने वाले अपने नए
ब्रेड

8

मुझे लगता है कि यह गारंटी देने का एकमात्र तरीका यह है कि किसी और के पास परीक्षण डेटा है । एक ग्राहक-सलाहकार संबंध में यह काफी आसानी से प्रबंधित किया जा सकता है: ग्राहक सलाहकार को प्रशिक्षण सेट देता है जिस पर मॉडल का निर्माण किया जाता है, और इस प्रशिक्षण सेट के भीतर सलाहकार डेटा को विभाजित करने के लिए जो भी आवश्यक हो, को विभाजित कर सकता है। पाए जाते हैं; बाद में मॉडल को उनके परीक्षण डेटा पर उपयोग करने के लिए क्लाइंट को वापस दिया जाता है।

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

हालाँकि अंततः यह इस बात पर निर्भर करता है कि मॉडल का उपयोग किस लिए किया जा रहा है। यदि आप कभी उस एकल डेटासेट पर भविष्यवाणी करने में रुचि रखते हैं, तो शायद आप सभी को पसंद कर सकते हैं? हालाँकि यदि आप अपने मॉडल को एक के रूप में बढ़ावा देने की कोशिश कर रहे हैं जो अच्छी तरह से सामान्य हो जाता है, या कुछ वास्तविक दुनिया के अनुप्रयोग में मॉडल का उपयोग करता है, तो निश्चित रूप से यह बहुत महत्व रखता है।

एक पक्ष मुद्दा है जो मुझे लगा कि मुझे उल्लेख करना चाहिए, जो यह है कि यदि आप सभी प्रक्रियाओं का सही ढंग से पालन करते हैं, तो भी आप उन मॉडलों के साथ समाप्त हो सकते हैं जो डेटा के सही मायने में नहीं होने के कारण ओवरफिट हैं । उदाहरण के लिए, यदि डेटा में अस्थायी सहसंबंध हैं, तो यदि आप 1-3 बार से अपने सभी प्रशिक्षण डेटा लेते हैं, और समय 4 पर परीक्षण करते हैं, तो आप पा सकते हैं कि भविष्यवाणी की त्रुटि उम्मीद से बड़ी है। वैकल्पिक रूप से प्रयोग-विशिष्ट कलाकृतियां हो सकती हैं, जैसे कि माप उपकरण का उपयोग किया जा रहा है, या मानव प्रयोगों में विषयों का पूल, जिससे मॉडल का सामान्यीकरण अपेक्षा से अधिक खराब हो सकता है।


हां, मुझे पता है कि वास्तव में आउट-ऑफ-सैंपल डेटासेट बनाना आश्चर्यजनक रूप से कठिन है क्योंकि यह अस्थायी रूप से सहसंबंधों के साथ गलती से समाप्त हो जाता है और क्या नहीं।
माइकल मैकगोवन

1
कुछ कंपनियां इसे नीति के रूप में लागू करती हैं, उदाहरण के लिए डेटाबेस viewअनुमतियाँ सेट करके कार्यान्वित की जाती हैं, जहां कुछ टीमें टेस्ट-डेटा-प्रिवी हैं और अन्य टेस्ट-डेटा-ब्लाइंड हैं।
जोजफ

6

यह एक बहुत अच्छा सवाल है और एक बहुत ही सूक्ष्म समस्या है। बेशक बुरी इरादों वाली गलतियाँ हैं, जो किसी को धोखा देने की कोशिश करती हैं। लेकिन इस बात का गहरा सवाल है कि आकस्मिक लीक से कैसे बचा जाए और ईमानदार गलतियों से कैसे बचा जाए।

मुझे कुछ परिचालन अच्छे प्रथाओं की सूची दें। वे सभी गलतियाँ हैं जो मैंने किसी बिंदु पर की हैं:

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

प्रशिक्षण / मूल्यांकन सेटों के बारे में एक सवाल था और मैंने उस पर एक सैद्धांतिक अवलोकन दिया machinelearning.stackexchange.com/a/196/114 - स्तरीकृत होल्डआउट, के-फोल्ड क्रॉस सत्यापन और दोहराया प्रयोगों की व्याख्या करते हुए। मेरे अशिक्षित दिमाग के लिए, वे विधियां उपरोक्त प्रश्न को पूरी तरह से संबोधित करती हैं, और बाकी सिर्फ "शिक्षक की समस्या" है। इसके अलावा, आपकी सूची की सभी प्रथाएं "बस मैला, अस्वीकार्य गलतियों" को ठीक करने के लिए प्रतीत होती हैं और मुझे वहां कोई सूक्ष्मता नहीं दिखती है। मैं यह समझने के लिए बहुत उत्सुक हूं कि मुझे क्या याद आ रहा है - क्या आप टिप्पणी कर सकते हैं?
andreister

मैं मानता हूं कि वे सभी फूहड़ता से आते हैं। मैंने यह भी उल्लेख किया था कि वे सैद्धांतिक नहीं हैं (कहा जा रहा है कि वे चालू हैं)। मैंने अपनी पोस्ट को थोड़ा एडिट किया है।
अगस्त

5

पहले से दिए गए उत्कृष्ट उत्तरों में कई महत्वपूर्ण बिंदुओं को शामिल किया गया है।

हाल ही में, मैंने इस व्यक्तिगत जाँच सूची को डेटा की सांख्यिकीय स्वतंत्रता के लिए विकसित किया है:

  • डेटा पदानुक्रम के उच्चतम स्तर पर भाजित डेटा (जैसे रोगी-वार विभाजन)
  • स्प्लिट स्वतंत्र रूप से ज्ञात या संदिग्ध कन्फ्यूडर के लिए, जैसे दिन-प्रतिदिन के उपकरणों में बदलाव आदि।
  • (माप के यादृच्छिक क्रम का ध्यान रखना चाहिए **)
  • पहले (आमतौर पर पूर्व-प्रसंस्करण) कदम के साथ शुरू होने वाली सभी गणना चरणों में एक से अधिक रोगी शामिल होते हैं * जिन्हें पुन: नमूनाकरण सत्यापन में प्रत्येक सरोगेट मॉडल के लिए फिर से तैयार करने की आवश्यकता होती है। होल्ड-आउट / स्वतंत्र परीक्षण सेट मूल्यांकन के लिए, इस चरण से पहले परीक्षण रोगियों को अलग करने की आवश्यकता होती है ।
    • यह परवाह किए बिना कि क्या गणना को प्रीप्रोसेसिंग कहा जाता है या वास्तविक मॉडल का हिस्सा माना जाता है।
    • विशिष्ट अपराधी: मध्य केंद्रित, विचरण स्केलिंग (आमतौर पर केवल हल्के प्रभाव), पीसीए या पीएलएस जैसे आयाम में कमी (भारी पूर्वाग्रह पैदा कर सकते हैं, उदाहरण के लिए परिमाण के क्रम में त्रुटियों की संख्या कम नहीं)
  • किसी भी तरह के डेटा-संचालित अनुकूलन या मॉडल चयन को अंतिम मॉडल को स्वतंत्र रूप से मान्य करने के लिए एक और (बाहरी) परीक्षण की आवश्यकता होती है।
  • कुछ प्रकार के सामान्यीकरण प्रदर्शन हैं जिन्हें केवल विशेष स्वतंत्र परीक्षण सेटों द्वारा मापा जा सकता है, उदाहरण के लिए कि भविष्य में मापे जाने वाले मामलों के लिए पूर्वानुमानात्मक प्रदर्शन कैसे बिगड़ता है (मैं समय श्रृंखला पूर्वानुमान के साथ काम नहीं कर रहा हूं, बस उपकरण बहाव के साथ)। लेकिन इसके लिए एक अच्छी तरह से डिज़ाइन किए गए सत्यापन अध्ययन की आवश्यकता है।
  • मेरे क्षेत्र में डेटा रिसाव का एक और अजीब प्रकार है: हम जैविक ऊतकों के स्थानिक रूप से हल किए गए स्पेक्ट्रोस्कोपी करते हैं। परीक्षण स्पेक्ट्रा के संदर्भ लेबलिंग को स्पेक्ट्रोस्कोपिक जानकारी के खिलाफ अंधा करने की आवश्यकता है, भले ही यह क्लस्टर विश्लेषण का उपयोग करने के लिए आकर्षक हो और फिर यह पता लगाएं कि प्रत्येक क्लस्टर किस वर्ग का है (यह अर्ध-पर्यवेक्षित परीक्षण डेटा होगा जो नहीं है सभी पर स्वतंत्र)।

  • अंतिम लेकिन निश्चित रूप से कम से कम नहीं: जब कोड को फिर से शुरू करने का सत्यापन होता है, तो मैं वास्तव में जांचता हूं कि क्या प्रशिक्षण सूचकांकों में प्रशिक्षण रोगियों, दिनों आदि से परीक्षण पंक्तियों को हथियाने के लिए नेतृत्व नहीं किया गया है।

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

* मैं केवल विवरण की आसानी के लिए डेटा में सबसे ऊपरी पदानुक्रम के रूप में रोगियों का उपयोग कर रहा हूं।
** मैं विश्लेषणात्मक रसायनज्ञ हूँ: साधन बहाव एक ज्ञात समस्या है। वास्तव में, रासायनिक विश्लेषण विधियों के सत्यापन का हिस्सा यह निर्धारित करता है कि सत्यापन नमूनों के खिलाफ कितनी बार अंशांकन की जांच की जानी चाहिए, और कितनी बार अंशांकन को फिर से करने की आवश्यकता है।


एफडब्ल्यूआईडब्ल्यू: व्यवहार में, मैं अनुप्रयोगों के साथ सौदा करता हूं जहां

  • p के परिमाण के क्रम में है ,102103
  • pnrows आमतौर पर से बड़ी होती हैं , लेकिनp
  • एन पी एक टी मैं एन टी एस « पी 10 0 - 10 1 10 2nbiol.replicates या is (परिमाण का क्रम: , शायद ही कभी )npatientsp100101102
  • स्पेक्ट्रोस्कोपिक माप पद्धति के आधार पर, एक की सभी पंक्तियों, कहते हैं, रोगी बहुत समान या बल्कि असमान हो सकता है क्योंकि विभिन्न प्रकार के स्पेक्ट्रा में सिग्नल-टू-शोर अनुपात (इंस्ट्रूमेंट त्रुटि) भी परिमाण के क्रम से भिन्न होता है।

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


2

अगर मुझे सही से याद है, तो कुछ पूर्वानुमान प्रतियोगिता (जैसे नेटफ्लिक्स या कागले वाले) इस योजना का उपयोग करते हैं:

"उत्तर" के साथ एक प्रशिक्षण सेट है। # 1 परीक्षण सेट है, जिसके लिए शोधकर्ता उत्तर प्रदान करता है। शोधकर्ता अपने स्कोर का पता लगाता है। # 2 का टेस्ट सेट है, जिसके लिए शोधकर्ता उत्तर प्रदान करता है, लेकिन शोधकर्ता अपने स्कोर का पता नहीं लगाता है। शोधकर्ता को यह पता नहीं है कि कौन सी भविष्यवाणी के मामले # 1 और # 2 में हैं।

कुछ बिंदु पर, सेट # 2 को दृश्यमान बनना है, लेकिन आपने कम से कम संदूषण को सीमित कर दिया है।


2

कुछ मामलों में, जैसे कि जैविक अनुक्रम-आधारित भविष्यवक्ता, यह सुनिश्चित करने के लिए पर्याप्त नहीं है कि मामले एक से अधिक सेट में प्रकट नहीं होते हैं। आपको अभी भी सेट के बीच निर्भरता के बारे में चिंता करने की ज़रूरत है।

उदाहरण के लिए, अनुक्रम-आधारित भविष्यवक्ताओं के लिए, किसी को यह सुनिश्चित करके अतिरेक को दूर करने की आवश्यकता होती है कि विभिन्न सेटों (विभिन्न क्रॉस-वैरिफिकेशन सेटों सहित) में अनुक्रम उच्च स्तर के अनुक्रम समानता को साझा नहीं करते हैं।


2

मैं कहता हूं कि "k- गुना क्रॉस वैधीकरण" सैद्धांतिक दृष्टिकोण से सही उत्तर है, लेकिन आपका प्रश्न संगठनात्मक और शिक्षण सामग्री के बारे में अधिक लगता है इसलिए मैं अलग तरीके से उत्तर दूंगा।


जब लोग "अभी भी सीख रहे हैं" तो यह अक्सर सोचा जाता है जैसे कि वे सीख रहे हैं कि कैसे "जल्दी और गंदगी से" एल्गोरिदम लागू करें और सभी "अतिरिक्त" ज्ञान (समस्या प्रेरणा, डाटासेट तैयारी, सत्यापन, त्रुटि विश्लेषण, व्यावहारिक गोच और इतने पर) ) "बाद में" सीखा जाएगा जब वे "अधिक तैयार" होंगे।

यह सरासर गलत है।

  1. यदि हम एक छात्र चाहते हैं या जो कोई भी एक टेस्ट सेट और एक प्रशिक्षण सेट के बीच अंतर को समझना चाहते हैं, तो सबसे बुरी बात यह होगी कि दो सेट दो अलग-अलग लोगों को दिए जाएंगे जैसे कि हम सोचते हैं कि "इस स्तर पर" "अतिरिक्त ज्ञान"। नुकसान पहुचने वाला। यह सॉफ्टवेयर विकास में झरने के दृष्टिकोण की तरह है - शुद्ध डिजाइन के कुछ महीने, फिर शुद्ध कोडिंग के कुछ महीने, फिर शुद्ध परीक्षण के कुछ महीने और अंत में एक दयालु परिणाम।

  2. सीखना झरना के रूप में नहीं जाना चाहिए। सीखने के सभी भागों - समस्या प्रेरणा, एल्गोरिथ्म, व्यावहारिक गोच, परिणाम मूल्यांकन - छोटे चरणों में एक साथ आना चाहिए। (सॉफ्टवेयर विकास में चुस्त दृष्टिकोण की तरह)।

शायद यहां हर कोई एंड्रयू एनजी के ml-class.org के माध्यम से चला गया है - मैं एक मजबूत "चुस्त" के उदाहरण के रूप में अपना पाठ्यक्रम डालूंगा, अगर आप करेंगे, सीखने की शैली - वह जो कभी भी "कैसे" का सवाल पैदा नहीं करेगा। सुनिश्चित करें कि परीक्षण डेटा प्रशिक्षण डेटा में लीक नहीं होता है "।


ध्यान दें कि मैंने आपके प्रश्न को पूरी तरह गलत समझा हो सकता है, इसलिए क्षमा करें! :)


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

और मैं इसे सॉफ्टवेयर एंड से ज्यादा सोच रहा था। एक उपयोगकर्ता एक मॉडल बनाता है जिसे प्रशिक्षण पर 90% सटीकता और परीक्षण पर 75% सटीकता प्राप्त होती है। वे तब सॉफ्टवेयर में कुछ knobs और सेटिंग्स ट्विक करते हैं और "परीक्षण" पर 80% सटीकता प्राप्त करते हैं। वे फिर से वापस जाते हैं और अधिक मोड़ लेते हैं और "परीक्षण" पर 85% सटीकता प्राप्त करते हैं। लेकिन यह तथाकथित "परीक्षण" डाटासेट अब बाहर का नमूना नहीं है, और मॉडल इसे ओवरफिट कर दिया गया है।
माइकल मैकगोवन

ठीक ठीक। यह एक मानव सीखने की समस्या है (शिक्षक समस्या, यदि आप करेंगे)। इसे जल्द से जल्द प्रकट किया जाना चाहिए, बल्कि "X को Y में लीक नहीं करना सुनिश्चित करता है" के कृत्रिम साधनों द्वारा छिपाया गया
andreister

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

@MichaelMcGowan - आप लीक के फायदों को भी नजरअंदाज कर रहे हैं - कि टेस्ट सेट (यानी ट्रेन + टेस्ट केवल ट्रेन की तुलना में अधिक डेटा) का उपयोग करके आपके एल्गोरिथ्म को बेहतर बनाया गया है। यह वास्तव में सिर्फ एक अलग ट्रेड-ऑफ, बेहतर सटीकता बनाम सटीकता की माप है। मेरे लिए पूर्व अधिक महत्वपूर्ण है।
प्रायवेसीलोगिक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.