ما راه هایی را برای نگاشت داده های خام به بردارهای ویژگی مناسب بررسی کرده ایم، اما این تنها بخشی از کار است. اکنون باید بررسی کنیم که چه نوع مقادیری در واقع ویژگی های خوبی را در آن بردارهای ویژگی ایجاد می کنند.
از مقادیر ویژگی های گسسته که به ندرت استفاده می شود خودداری کنید
مقادیر ویژگی خوب باید بیش از 5 بار یا بیشتر در یک مجموعه داده ظاهر شوند. انجام این کار یک مدل را قادر می سازد تا نحوه ارتباط این مقدار ویژگی با برچسب را بیاموزد. به این معنا که داشتن مثال‌های زیاد با مقدار گسسته یکسان به مدل این فرصت را می‌دهد تا ویژگی را در تنظیمات مختلف ببیند و به نوبه خود تعیین کند که چه زمانی پیش‌بینی‌کننده خوبی برای برچسب است. به عنوان مثال، یک ویژگی 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 ارائه شده است یا خیر. به این ویژگی Boolean نامی مانند 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"