हमने ऐसे तरीके ढूंढे हैं जिनसे रॉ डेटा को सही फ़ीचर वेक्टर में मैप किया जा सके. हालांकि, यह काम का सिर्फ़ एक हिस्सा है. अब हमें यह पता लगाना होगा कि उन फ़ीचर वेक्टर में किस तरह के मान असल में अच्छी सुविधाएं देते हैं.
बहुत कम इस्तेमाल होने वाली अलग-अलग सुविधाओं की वैल्यू से बचना
किसी डेटा सेट में अच्छी सुविधा की वैल्यू पांच से ज़्यादा बार दिखाई देनी चाहिए.
ऐसा करने से, मॉडल को यह जानने में मदद मिलती है कि सुविधा का यह मान लेबल से किस तरह जुड़ा है.
इसका मतलब है कि एक ही अलग वैल्यू वाले कई उदाहरण होने से, मॉडल को
सुविधा को अलग-अलग सेटिंग में देखने का मौका मिलता है. साथ ही, इससे यह तय किया जाता है कि
यह लेबल के लिए कब अच्छा अनुमान लगाता है. उदाहरण के लिए, किसी house_type सुविधा में ऐसे कई उदाहरण हो सकते हैं जिनमें उसकी वैल्यू victorian थी:
✔This is a good example:house_type: victorian
वहीं, अगर किसी सुविधा की वैल्यू सिर्फ़ एक बार या बहुत कम दिखती है, तो मॉडल उस सुविधा के आधार पर अनुमान नहीं लगा सकता. उदाहरण के लिए, unique_house_id
खराब सुविधा है. ऐसा इसलिए, क्योंकि हर वैल्यू का इस्तेमाल सिर्फ़ एक बार किया जाएगा. इसलिए, मॉडल इससे कुछ भी नहीं सीख सकता:
The following is an example of a unique value. This should be avoided.✘unique_house_id: 8SK982ZZ1242Z
साफ़ और आसान शब्दों को प्राथमिकता दें
प्रोजेक्ट में शामिल सभी लोगों के लिए, हर सुविधा का मतलब साफ़ तौर पर और साफ़ तौर पर दिखना चाहिए. उदाहरण के लिए, इस अच्छी सुविधा का नाम साफ़ तौर पर बताया गया है और वैल्यू से नाम के बारे में पता चलता है:
✔The meaning of the following value is clear from the label and value.house_age_years: 27
इसके ठीक उलट, इस सुविधा के मान का मतलब कोई और समझ नहीं पाता है, लेकिन इसे बनाने वाले इंजीनियर को समझ नहीं आता है:
✘The following is an example of a value that is unclear. This should be avoidedhouse_age: 851472000
कुछ मामलों में, खराब इंजीनियरिंग विकल्पों के बजाय शोर वाले डेटा की वजह से वैल्यू साफ़ नहीं होती हैं. उदाहरण के लिए, नीचे दिया गया user_age_years ऐसे स्रोत से आया है जिसने सही वैल्यू की जांच नहीं की थी:
✘The following is an example of noisy/bad data. This should be avoided.user_age_years: 277
"जादू" वैल्यू को असल डेटा के साथ न मिलाएं
फ़्लोटिंग-पॉइंट की अच्छी सुविधाओं में ऐसी वैल्यू नहीं होती हैं जो रेंज से बाहर की हों. उदाहरण के लिए, मान लीजिए कि किसी सुविधा में फ़्लोटिंग-पॉइंट की वैल्यू 0 और 1 के बीच होती है. इसलिए, इस तरह की वैल्यू ठीक हैं:
✔The following is a good example:quality_rating: 0.82 quality_rating: 0.37
हालांकि, अगर उपयोगकर्ता ने quality_rating नहीं डाला है, तो शायद डेटा सेट
अपने न होने को इस तरह के मैजिक वैल्यू से दिखाता हो:
✘The following is an example of a magic value. This should be avoided.quality_rating: -1
मैजिक वैल्यू को साफ़ तौर पर मार्क करने के लिए, बूलियन सुविधा बनाएं. इससे यह पता चलेगा कि quality_rating दिया गया है या नहीं. इस बूलियन सुविधा को
is_quality_rating_defined जैसा नाम दें.
ओरिजनल सुविधा में, मैजिक वैल्यू को इस तरह बदलें:
- जिन वैरिएबल में वैल्यू का सीमित सेट (अलग-अलग वैरिएबल) होता है उनके लिए, सेट में एक नई वैल्यू जोड़ें. साथ ही, इसका इस्तेमाल यह बताने के लिए करें कि सुविधा की वैल्यू मौजूद नहीं है.
- लगातार वैरिएबल के लिए, पक्का करें कि जो वैल्यू मौजूद नहीं हैं वे सुविधा के डेटा की मीन वैल्यू का इस्तेमाल करके मॉडल पर असर न डालें.
अपस्ट्रीम अस्थिरता की वजह
किसी सुविधा की परिभाषा समय के साथ नहीं बदलनी चाहिए. उदाहरण के लिए, यह वैल्यू काम की है, क्योंकि शायद शहर का नाम नहीं बदलेगा. (ध्यान दें कि हमें अब भी "br/sao_paulo" जैसी स्ट्रिंग को वन-हॉट वेक्टर में बदलना होगा.)
✔This is a good example:city_id: "br/sao_paulo"
हालांकि, किसी दूसरे मॉडल से अनुमानित वैल्यू इकट्ठा करने के लिए, अतिरिक्त शुल्क देना पड़ता है. शायद "219" वैल्यू फ़िलहाल साओ पाओलो को दिखाती है, लेकिन यह अनुमान आने वाले समय में दूसरे मॉडल के चलने पर आसानी से बदल सकता है:
✘The following is an example of a value that could change. This should be avoided.inferred_city_cluster: "219"