इंजीनियरिंग कार्य क्यों करता है?

20

हाल ही में मैंने सीखा है कि एमएल समस्याओं के लिए बेहतर समाधान खोजने का एक तरीका सुविधाओं का निर्माण है। उदाहरण के लिए, दो सुविधाओं को संक्षेपित करके ऐसा कर सकते हैं।

उदाहरण के लिए, हमारे पास दो प्रकार के "हमले" और कुछ प्रकार के नायक के "बचाव" हैं। हम फिर "कुल" नामक अतिरिक्त सुविधा बनाते हैं जो "हमले" और "रक्षा" का योग है। अब जो मुझे अजीब प्रतीत होता है वह यह है कि कठिन "हमला" और "रक्षा" लगभग पूरी तरह से "कुल" के साथ सहसंबद्ध हैं, हम अभी भी उपयोगी जानकारी प्राप्त करते हैं।

उसके पीछे क्या गणित है? या मैं गलत तर्क दे रहा हूं?

इसके अतिरिक्त, कि kNN जैसे वर्गीकरणकर्ताओं के लिए यह कोई समस्या नहीं है, कि "कुल" हमेशा "हमले" या "रक्षा" से बड़ा होगा? इस प्रकार, स्टैंडराइजेशन के बाद भी हमारे पास अलग-अलग रेंज के मूल्यों वाले फीचर होंगे?

machine-learning feature-construction

— MrKadek750
स्रोत

दो विशेषताओं को जोड़ने का अभ्यास निश्चित रूप से "फीचर इंजीनियरिंग" का प्रतिनिधित्व नहीं करता है।

— xji

21

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

पहले मैं जवाब दूंगा कि सामान्य तौर पर इंजीनियरिंग का काम क्यों होता है।

एक तस्वीर एक हजार शब्दों के बराबर होती है। यह आंकड़ा आपको सुविधा इंजीनियरिंग पर कुछ अंतर्दृष्टि और यह काम क्यों करता है (चित्र स्रोत ) बता सकता है :

कार्टेशियन निर्देशांक में डेटा अधिक जटिल है, और दो प्रकारों को वर्गीकृत करने के लिए एक नियम लिखना / मॉडल बनाना अपेक्षाकृत कठिन है।
ध्रुवीय निर्देशांक में डेटा बहुत आसान है: हम दो प्रकारों को वर्गीकृत करने के लिए पर एक सरल नियम लिख सकते हैं। $r$

यह हमें बताता है कि डेटा का प्रतिनिधित्व बहुत मायने रखता है। निश्चित स्थान में, अन्य स्थानों की तुलना में कुछ कार्यों को करना बहुत आसान है।

यहाँ मैं आपके उदाहरण में उल्लिखित प्रश्न का उत्तर देता हूँ (हमले और बचाव पर कुल)

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

तो, जवाब यह है कि आपके द्वारा उपयोग किए जाने वाले मॉडल के आधार पर, कुछ फ़ीचर इंजीनियरिंग कुछ मॉडलों पर मदद करेगी, लेकिन अन्य मॉडलों के लिए नहीं।

— हतौ दू
स्रोत

योग को जोड़ के साथ नहीं जोड़ा जाना चाहिए। उदाहरण के लिए देखें मेरा उत्तर

— कोडिएलॉजिस्ट

15

जिस मॉडल का हम उपयोग कर रहे हैं वह मौजूदा विशेषताओं के कुछ संयोजनों को सीखने में बहुत कुशल नहीं हो सकता है।

उदाहरण के लिए, अपने उदाहरण पर विचार करें कि सुविधाएँ कहाँ हैं aऔर d, और हम एक बाइनरी परिणाम का अनुमान लगाने के लिए एक निर्णय ट्री का उपयोग कर रहे हैं जो कि होता है यदि और यदि । $0$ $a+d<0$ $1$ $a+d\geq0$

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

जैसा कि आप देख सकते हैं कि यह नए डेटा के लिए पूरी तरह से सामान्य नहीं होगा। हमारे पास वास्तविक निर्णय रेखा के ऊपर वृत्त हो सकते हैं जो हमारी निर्णय सीमा के अंतर्गत हैं और क्रॉस के लिए इसके विपरीत हैं।

हालांकि, अगर हम a+dएक विशेषता के रूप में जोड़ते हैं, तो समस्या निर्णय वृक्ष के लिए तुच्छ हो जाती है। यह व्यक्तिगत aऔर dविशेषताओं को अनदेखा कर सकता है और एकल a+d<0निर्णय स्टंप के साथ समस्या को हल कर सकता है ।

हालाँकि, यदि आप रैखिक प्रतिगमन का उपयोग कर रहे थे, तो आपका मॉडल अतिरिक्त सुविधा को जोड़े बिना सीखने में पूरी तरह सक्षम होगा । $a+d$

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

— इमरान
स्रोत

1

ठीक यही बात है। सुविधाओं की पसंद और मॉडल की पसंद पर एक साथ विचार किया जाना चाहिए। यह मॉडल के प्रकार पर विचार किए बिना सुविधा चयन के बारे में प्रयास करने और तर्क करने के लिए एक सामान्य नुकसान है।

— इमरान

1

उदाहरण के लिए आप तो रेखीय प्रतीपगमन साथ एक ही बात करने की कोशिश की है, तो aऔर dपर्याप्त होगा और जोड़ने a+dएक सुविधा के रूप में एक फर्क नहीं होता।

— इमरान

मैंने इसे और अधिक स्पष्ट करने के लिए अपना उत्तर अपडेट कर दिया है।

— इमरान

1

इसके अलावा, विकर्ण रेखा के पार एक विभाजन की आवश्यकता होती है। आपके द्वारा खींची गई सीढ़ी "सात विभाजन" का उपयोग करती है।

— संचय

3

totalअगर यह उसी मॉडल में अन्य सुविधाओं के साथ दृढ़ता से सहसंबद्ध नहीं है तो जैसी निर्मित सुविधा अभी भी अनुमानित रूप से उपयोगी हो सकती है। totalविशेष रूप से आवश्यकता के साथ दृढ़ता से सहसंबद्ध नहीं होना चाहिए attackया defense। उदाहरण के लिए, यदि attackहै (8, 0, 4) और defenseहै (1, 9, 6), तो के सह-संबंध totalके साथ attack0 और की सह-संबंध totalके साथ defenseहै । $\frac{1}{7}$

इसके अतिरिक्त, कि kNN जैसे वर्गीकरणकर्ताओं के लिए यह कोई समस्या नहीं है, कि "कुल" हमेशा "हमले" या "रक्षा" से बड़ा होगा? इस प्रकार, स्टैंडराइजेशन के बाद भी हमारे पास अलग-अलग रेंज के मूल्यों वाले फीचर होंगे?

यदि आप अपने भविष्यवक्ताओं को मानकीकृत करना चाहते हैं, तो उन्हें यह सब करने के बाद करना चाहिए।

— Kodiologist
स्रोत

1

क्या यह सच है? निश्चित रूप से, एक सरल रैखिक मॉडल में, यह नहीं है: मैट्रिक्स [attack, defense, total]निश्चित रूप से रैंक 2 है। मैं एक दंडित रैखिक मॉडल की तरह कुछ में कल्पना कर सकता हूं यह अंतर कर सकता है, लेकिन यह पूरी तरह से काम करने के बजाय अंतर्ज्ञान पर आधारित है। क्या आप बता सकते हैं कि क्यों attackऔर यदि defenseउनका दृढ़ता से सहसंबंध नहीं है total(जो तब होता है attackऔर जब defenseवे नकारात्मक रूप से सहसंबद्ध होते हैं), totalतो सहायक क्यों हो सकते हैं?

— क्लिफ एबी

1

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

— कोडियोलॉजिस्ट

1

एक सामान्य जवाब देने के लिए, ज्यादातर मामलों में इंजीनियरिंग आपके डेटा से सार्थक सुविधाओं को निकालने के बारे में है, इसलिए यदि आप अपने मॉडल को अधिक जानकारी देते हैं, तो यह स्पष्ट रूप से बेहतर व्यवहार करना चाहिए। यह कहें कि आपके डेटा में 'name.surname@domain.country-code' के रूप में ई-मेल पते शामिल हैं। यदि आप उन्हें अपने मॉडल में उपयोग करते हैं, तो प्रत्येक व्यक्ति को एक विशिष्ट ई-मेल की विशेषता होगी, इसलिए यह हमें ज्यादा नहीं बताएगा। यह हमें केवल यह बताएगा कि एक ई-मेल संभवतः किसी दूसरे व्यक्ति का है तो किसी अन्य का। फीचर इंजीनियरिंग के साथ, ऐसे पतों से आप संभावित लिंग (नाम), पारिवारिक पृष्ठभूमि और जातीयता (उपनाम), राष्ट्रीयता (डोमेन) और कई और अधिक के बारे में जानकारी निकाल सकते हैं - यह आपको बहुत अधिक जानकारी देता है, है ना?

— टिम
स्रोत

1

आप अपने "फीचर" कुल के साथ क्या करने की कोशिश कर रहे हैं ? यदि आप केवल नायकों की तुलना कर रहे हैं, तो हमले और रक्षा अधिक उपयोगी हो सकते हैं। यदि आपको उपयोगी होने के लिए बिल्ड के प्रकार (कैसे आक्रामक-उन्मुख बनाम कैसे रक्षात्मक-उन्मुख) मिलेंगे , तो शायद हमला / रक्षा अधिक उपयोगी होगा। या हो सकता है MyAttack - YourDefense अधिक उपयोगी हो।

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

— वेन
स्रोत