پلتفرم Ax متا موازنهٔ صحت مدل و هزینه محاسباتی را خودکار کرد

تصور کنید مجبور باشید بین داشتن مدلی که دقیق است اما روی سخت‌افزار شما اجرا نمی‌شود، و مدلی که سریع است اما اشتباهات زیادی دارد، یکی را انتخاب کنید. پلتفرم Ax از شرکت متا (Meta) این بازی حدس‌زدن را به یک فرآیند مهندسی دقیق تبدیل می‌کند تا بهینه‌ترین نقطه تلاقی بین عملکرد و هزینه پیدا شود. در واقع، Ax فرآیند موازنه بین دقت مدل و ردپای حافظه را از یک حدس و گمان به یک آزمایش ساختاریافته و تطبیقی تبدیل می‌کند که به طور خودکار بین عملکرد و هزینه پیمایش می‌کند.

بهینه‌سازی ابرپارامترها (Hyperparameter) — که شبیه تنظیم دقیق پیچ‌های یک ماشین برای رسیدن به بیشترین سرعت است — پیش از این بر پایه جست‌وجوی تصادفی یا شبکه‌ای (Grid Search) بود؛ روش‌هایی که هم از نظر محاسباتی گران بودند و هم نسبت به محدودیت‌های منابع سخت‌افزاری کور بودند. همان‌طور که در تحلیل قبلی ما درباره‌ی Meta Muse Code و رویکرد آن به مدیریت مخازن نرم‌افزاری در مقیاس بزرگ اشاره کردیم، متا اکنون با Ax رویکردی جراحی‌گونه را برای بهینه‌سازی مدل‌ها معرفی کرده است. این ابزار به مهندسان اجازه می‌دهد تا اندازه مدل را به جای اینکه به عنوان یک موضوع ثانویه یا afterthought در نظر بگیرند، به عنوان یک محدودیت درجه اول (First-class constraint) مدیریت کنند.

گردش کار تطبیقی

بر اساس راهنمای منتشر شده در ماه جاری توسط Marktechpost، هسته مرکزی Ax یک API کلاینت مدرن است که فضای جست‌وجوی ترکیبی (Mixed Search Space) را مدیریت می‌کند. این فضا شامل پارامترهای عدد صحیح (Integer)، اعشاری (Float)، مقیاس‌های لگاریتمی (Log-scaled) و دسته‌ای (Categorical) است که کنترل بسیار دقیقی روی معماری مدل ایجاد می‌کند.

برای نمایش این قابلیت، در این راهنما یک مدل جنگل تصادفی (Random Forest) — که شبیه مجموعه‌ای از تصمیم‌گیرنده‌های کوچک است که با رای‌گیری به یک جواب می‌رسند — روی یک مجموعه داده مصنوعی طبقه‌بندی (Classification) پیاده‌سازی شده است. این مجموعه داده شامل ۱٬۴۰۰ نمونه، ۲۰ ویژگی (که ۸ مورد آن‌ها اطلاعاتی و ۴ مورد زائد هستند) و ۳ کلاس مختلف است. برای اطمینان از ارزیابی مستحکم و بدون سوگیری، از استراتژی StratifiedKFold با ۳ تقسیم‌بندی (Split) استفاده شده است.

تابع ارزیابی در اینجا فقط صحت (Accuracy) را رصد نمی‌کند؛ بلکه یک معیار «اندازه مدل» را بر اساس حاصل‌ضرب تعداد تخمین‌زن‌ها (Estimators) و حداکثر عمق درختان محاسبه می‌کند. این مکانیسم به سیستم اجازه می‌دهد تا عملکرد پیش‌بینی و هزینه محاسباتی را به طور هم‌زمان اندازه‌گیری کند. این رویکرد یادآور تلاش‌های مشابه برای حفظ کیفیت در عین ارزان‌سازی مدل‌هاست که در ابزارهایی مانند World Model Optimizer برای کاهش هزینه‌های عملیاتی دنبال می‌شود.

پیکربندی فضای جست‌وجو

برای رسیدن به این بهینه‌سازی، Ax فضای جست‌وجو را با استفاده از RangeParameterConfig و ChoiceParameterConfig تعریف می‌کند. پارامترهای خاصی که در این فرآیند تنظیم می‌شوند عبارتند از:

• n_estimators: بازه اعداد صحیح از ۵۰ تا ۳۰۰
• max_depth: بازه اعداد صحیح از ۳ تا ۲۴
• max_features: بازه اعشاری از ۰.۲ تا ۱.۰
• min_samples_leaf: بازه اعداد صحیح از ۱ تا ۱۲
• ccp_alpha: بازه اعشاری از 1e-5 تا 1e-1، با بهره‌گیری از مقیاس لگاریتمی برای دستیابی به دقت بیشتر در مقادیر بسیار کوچک
• criterion: گزینه‌های دسته‌ای شامل "gini"، "entropy" و "log_loss"

بهینه‌سازی بیزی محدودشده

پلتفرم Ax از یک حلقه «پرسش-پاسخ» (ask-tell) برای اجرای بهینه‌سازی بیزی (Bayesian Optimization) محدودشده استفاده می‌کند. در اولین مطالعه، سیستم تلاش می‌کند صحت را به حداکثر برساند، اما یک شرط خروجی سخت‌گیرانه را اعمال می‌کند: اندازه مدل باید حتماً زیر ۲٬۵۰۰ واحد باقی بماند.

این رویکرد تضمین می‌کند که بهینه‌ساز هر پیکربندی را که با وجود عملکرد بالا، بیش از حد حجیم و bloated است، نادیده بگیرد. در این فرآیند، API کلاینت ابتدا آزمایش و اهداف بهینه‌سازی را پیکربندی کرده و سپس یک مطالعه شامل ۲۴ آزمایش (Trial) را اجرا می‌کند. نتیجه نهایی به صورت یک نمودار همگرایی نمایش داده می‌شود که نشان می‌دهد بهترین صحت ممکن در چارچوب سخت‌افزار هدف چیست و مدل حتماً قابلیت استقرار روی سخت‌افزار مقصد را دارد.

موازنه اهداف چندگانه

فراتر از محدودیت‌های ساده، Ax می‌تواند بهینه‌سازی چندهدفه (Multi-objective optimization) را مدیریت کند. در این حالت، سیستم به جای یک سقف سخت، سعی می‌کند به طور مشترک صحت را افزایش و اندازه مدل را کاهش دهد (که در پیکربندی هدف به صورت -model_size نمایش داده می‌شود).

در مطالعه‌ای با ۲۸ آزمایش، Ax به دنبال پیکربندی‌هایی می‌گردد که قوی‌ترین موازنه را بین عملکرد پیش‌بینی و ردپای محاسباتی ایجاد کنند:

• مرز پارتو (Pareto Frontier): Ax مجموعه‌ای از پیکربندی‌های بهینه پارتو را شناسایی می‌کند؛ نقاطی که در آن‌ها هیچ معیاری را نمی‌توان بهبود بخشید مگر اینکه معیار دیگر تضعیف شود.
• بصری‌سازی موازنه: توسعه‌دهندگان با رسم نمودار صحت در برابر اندازه مدل، می‌توانند «نقطه طلایی» را متناسب با نیاز استقرار خود انتخاب کنند. در این نمودارها، تمام آزمایش‌ها با رنگ خاکستری روشن رسم می‌شوند، در حالی که جبهه پارتو با رنگ قرمز تیره (Crimson) برجسته شده است.

محدودیت‌های سطح پارامتر

Ax همچنین از محدودیت روی خودِ پارامترهای ورودی پشتیبانی می‌کند، نه فقط روی نتایج خروجی. در یک تست سطح مصنوعی (Synthetic Surface Test)، بهینه‌ساز موظف بود فاصله تا نقطه هدف (۰.۹، ۰.۹) را به حداقل برساند، در حالی که مجموع دو متغیر (x1 + x2) حتماً زیر ۱.۵ باقی بماند.

این مورد در ۱۴ آزمایش تست شد. در حالی که یک جست‌وجوی بدون محدودیت مستقیماً و دقیقاً به نقطه (۰.۹، ۰.۹) می‌رسید، Ax به مرز تعیین‌شده احترام گذاشت. این سیستم با موفقیت بهترین نقطه ممکن در نزدیکی بهینه محدودشده را یافت که ثابت می‌کند Ax برای محدودیت‌های پیچیده مهندسی که در آن متغیرهای ورودی به هم وابسته هستند، کاملاً قابل اعتماد است.

تحلیل و پایداری

برای اینکه آزمایش‌ها تکرارپذیر باشند، Ax ابزارهای تحلیل داخلی و قابلیت‌های پایداری (Persistence) دارد. این پلتفرم می‌تواند با استفاده از compute_analyses کارت‌های تشخیصی برای بررسی حساسیت و اعتبارسنجی متقابل (Cross-validation) تولید کند.

علاوه بر این، کل وضعیت یک آزمایش را می‌توان در یک فایل JSON ذخیره کرد (با استفاده از save_to_json_file). این قابلیت به تیم‌ها اجازه می‌دهد:

• حفظ وضعیت: ذخیره مطالعه تکمیل‌شده در فایلی مانند ax_study1.json.
• بارگذاری و تایید: استفاده از Client.load_from_json_file برای بازیابی آزمایش و تایید اینکه بهترین پارامترها با نتایج اولیه مطابقت دارند.
• ادامه کار: بهینه‌سازی را بدون نیاز به شروع مجدد تمام آزمایش‌ها از نقطه صفر ادامه دهند.

جزئیات پیاده‌سازی

برای کسانی که قصد تکرار این گردش کار را دارند، نصب ax-platform و scikit-learn از طریق pip ضروری است. مکانیزم‌های فنی کلیدی که در این پیاده‌سازی به کار رفته‌اند عبارتند از:

• حلقه Ask-Tell: تابع run_study از client.get_next_trials برای درخواست پارامترهای جدید و از client.complete_trial برای گزارش داده‌های خام به بهینه‌ساز استفاده می‌کند.
• دسته‌بندی (Batching): آزمایش‌ها در دسته‌های کوچک (مثلاً ۴ تایی) پردازش می‌شوند تا جریان ارزیابی‌ها به طور بهینه مدیریت شود.
• کنترل لاگ: برای جلوگیری از شلوغ شدن خروجی در محیط‌هایی مثل گوگل کولب، سطح لاگ Ax روی logging.WARNING تنظیم شده و هشدارهای پایتون فیلتر می‌شوند.

این چرخش به سمت آزمایش‌های تطبیقی یعنی توسعه‌دهندگان دیگر مجبور نیستند بین مدل «کوچک و سریع» یا «بزرگ و دقیق» یکی را انتخاب کنند. آن‌ها اکنون می‌توانند مرز سخت‌افزاری خود را به صورت ریاضی تعریف کنند و اجازه دهند بهینه‌ساز، سقف عملکرد را در آن چارچوب پیدا کند.

برای یک متخصص، این یعنی کاهش چرخه تکرار دستی از چند روز به چند دقیقه. در واقع تنظیم ابرپارامترها از یک هنر مبتنی بر آزمون و خطا، به یک دیسیپلین مهندسی تکرارپذیر تبدیل شده است.

گام بعدی شما

• کتابخانه‌های ax-platform و scikit-learn را نصب کنید تا اولین فضای جست‌وجوی محدودشده خود را بسازید.
• در پروژه‌های فعلی خود، اندازه مدل را به عنوان یک معیار (Metric) در کنار صحت تعریف کنید تا نقاط بهینه پارتو را بیابید.
• از قابلیت ذخیره JSON برای مستندسازی تجربیات بهینه‌سازی در تیم‌های مشترک استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.