نکاتی در مورد Feature Scaling در عمل

تو دنیای Machine Learning خیلی وقت‌ها نتیجه‌ی کار یک مدل به چیزهای کوچیکی بستگی داره که ممکنه اولش به چشم نیاد. یکی از این جزئیات مهم، Feature Scaling هست. شاید در نگاه اول ساده یا حتی بی‌اهمیت به نظر بیاد، اما واقعیت اینه که درست یا غلط انجام دادنش می‌تونه روی دقت مدل، سرعت آموزش و حتی پایداری نهایی تأثیر جدی بذاره. همه‌ی روش‌های Scaling هم یکسان نیستن؛ بعضی وقت‌ها انتخاب درست به شدت کمک می‌کنه، اما انتخاب اشتباه حتی ممکنه اوضاع رو بدتر کنه.

وقتی دیتاست داریم، ویژگی‌ها یا همون Features معمولاً واحدها و بازه‌های مختلفی دارن. مثلاً سن به سال، درآمد به دلار یا ریال، مسافت به متر و… حالا اگر یک مدل بخواد با این داده‌ها کار کنه، به‌خصوص مدلی که از فاصله یا Gradient Descent استفاده می‌کنه، اون ویژگی که مقیاس بزرگ‌تری داره ناخودآگاه وزن بیشتری پیدا می‌کنه. اینجاست که Scaling اهمیت پیدا می‌کنه: یعنی تبدیل کردن مقادیر ویژگی‌ها به بازه یا مقیاسی که همه تقریباً در یک سطح اثرگذار باشن.

اهمیت این کار وقتی بیشتر معلوم میشه که بدونیم Gradient Descent در صورت وجود Featureهای با مقیاس‌های متفاوت مجبور میشه مسیر بهینه‌سازی رو به شکل زیگ‌زاگ طی کنه و این کار رو خیلی کند می‌کنه. یا مثلاً در مدل‌هایی مثل KNN، K-means و SVM اگر مقیاس‌ها متفاوت باشن، همون Feature با بازه بزرگ‌تر کل تصمیم‌گیری رو تحت تأثیر می‌ذاره. در عوض، وقتی از Standardization استفاده می‌کنیم (یعنی داده‌ها میانگین صفر و انحراف معیار یک پیدا می‌کنن)، ضرایب در مدل‌های خطی خیلی قابل مقایسه‌تر میشن. البته درخت تصمیم و Random Forest معمولاً به Scaling حساس نیستن و تقریباً بدون مشکل کار می‌کنن.

روش‌های مختلفی برای Scaling وجود داره. یکی از رایج‌ترین‌ها Normalization یا همون Min–Max Scaling هست که داده‌ها رو به بازه [0,1] میاره. این روش ساده و سرراست هست اما مشکلش اینه که به Outlier خیلی حساسه. روش دیگه Standardization یا Z-score هست که داده‌ها رو حول میانگین صفر و انحراف معیار یک پخش می‌کنه. اگر توزیع داده‌ها نرمال باشه عالی جواب می‌ده، ولی اگه توزیع خیلی نامتقارن باشه یا Outlier زیاد باشه، کیفیتش پایین میاد. برای همین گاهی سراغ Robust Scaling می‌ریم که به جای میانگین و انحراف معیار، از Median و IQR استفاده می‌کنه و نسبت به Outlierها مقاوم‌تره. یک روش دیگه هم Max-Abs Scaling هست که داده‌ها رو جوری تغییر می‌ده که بزرگ‌ترین مقدار مطلق هر Feature یک بشه.

البته Scaling همیشه هم جواب نمی‌ده. مثلاً در مدل‌های Tree-based تغییر خاصی ایجاد نمی‌کنه. از طرفی اگر روش اشتباه انتخاب بشه، نتیجه می‌تونه حتی بدتر از حالتی باشه که هیچ Scaling انجام نشده. نکته‌ی مهم دیگه اینه که Scaling باید فقط روی Training Set محاسبه بشه و همون پارامترها بعداً روی Validation و Test Set اعمال بشن؛ وگرنه Data Leakage اتفاق می‌افته و کل نتایج آزمایش بی‌اعتبار میشه.

تحقیقات جدید نشون دادن که تفاوت بین بهترین و بدترین روش Scaling روی یک مدل می‌تونه خیلی قابل توجه باشه. مثلاً برای Logistic Regression، SVM یا Neural Networks انتخاب درست Scaling خیلی حیاتی هست، ولی برای مدل‌هایی مثل Random Forest یا Gradient Boosting تأثیرش خیلی کمتره. در نتیجه، بهترین کار اینه که اگر مطمئن نیستیم، چند روش مختلف رو امتحان کنیم و با Cross-validation ببینیم کدوم بهتر جواب می‌ده.

پس در نهایت میشه گفت Feature Scaling چیزی نیست که بشه نادیده گرفت. تو بعضی پروژه‌ها می‌تونه هم سرعت و هم دقت رو چند برابر بهتر کنه، و تو بعضی مدل‌ها هم شاید هیچ فرقی ایجاد نکنه. اما اینکه با دقت انتخاب بشه و درست پیاده‌سازی بشه، همیشه ارزشش رو داره.

🔤🔤🔤🔤🔤🔤🔤

🥇 اهورا اولین اپراتور هوش مصنوعی راهبردی ایران در حوزه ارائه خدمات و سرویس‌های زیرساخت هوش مصنوعی

🌐 لینک ارتباط با اهورا

@reza_jafari_ai

گیت‌هاب ابزار Copilot CLI رو معرفی کرد. این سرویس ایجنت هوش مصنوعی خودش رو مستقیم به ترمینال وصل می‌کنه. باهاش کارهایی مثل ساخت، ویرایش، دیباگ و بازنویسی کد فقط با دستور به زبان طبیعی قابل انجامه.

کوپایلت کلی به طور پیش‌فرض از سرور MCP گیت‌هاب استفاده می‌کنه اما می‌شه اون رو به سرورهای MCP سفارشی متصل کرد. با دسترسی‌ای که به مخازن گیت‌هاب داره می‌شه از ترمینال، ایشیوها و پول‌ریکوئست‌ها رو هم با اون مدیریت کرد.

این نسخه در حالت پیش‌نمایش عمومیه و برای کاربرهای پلن‌های پرو، پرو پلاس، بیزنس و اینترپرایز گیت‌هاب در دسترسه. [L]

🤓 abolfazl @geekalerts