Chapter 12 of 16
Hard-won rules for running HPO that doesn't waste compute
Algorithm, টুল, আর প্রজেক্ট — সব দেখা হয়ে গেছে। এই chapter সেই কষ্টার্জিত শিক্ষাগুলো একসাথে করে do's আর don'ts-এর একটা practical গাইডে পরিণত করেছে। এগুলো কোনো খামখেয়ালি নিয়ম নয় — প্রতিটাই তৈরি হয়েছে কারণ সেগুলো না মানলে বারবার compute অপচয় হয়, ফলাফল বিভ্রান্তিকর হয়, বা পুরো প্রজেক্টই ব্যর্থ হয়ে যায়।
যেকোনো HPO run-এ সবচেয়ে গুরুত্বপূর্ণ সিদ্ধান্তটা algorithm বাছাই নয় — সেটা হলো search space কীভাবে সংজ্ঞায়িত করা হচ্ছে। খারাপভাবে ডিজাইন করা search space পুরো বাজেটটাই স্পষ্টত খারাপ কোনো অঞ্চলে অপচয় করে ফেলতে পারে, বা ভালো অঞ্চলটাই একেবারে মিস করে ফেলতে পারে।
Learning rate, regularization strength, dropout rate-এর মতো hyperparameter loss landscape-এ multiplicatively কাজ করে — তাই এগুলোর জন্য সবসময় log-uniform scale ব্যবহার করুন, linear grid নয়। Search space-টা domain knowledge দিয়ে টাইট করে বাঁধুন — থেকে পর্যন্ত learning rate খোঁজা নিরাপদ নয়, এটা স্পষ্টত অযৌক্তিক অঞ্চলে বাজেট নষ্ট করে। যা জানা আছে সেখান থেকে শুরু করুন, দরকার হলে পরে বাড়ান। Hidden unit সংখ্যা, estimator সংখ্যার মতো যেসব quantity বহু order-of-magnitude জুড়ে বিস্তৃত, সেগুলোর জন্যও log scale ভালো। আর যেই hyperparameter সম্পর্কে আগে থেকেই শক্তিশালী ধারণা আছে, সেটাকে অজানা হিসেবে ধরে নেবেন না — domain knowledge আসলে বিনামূল্যের compute।
যদি কখনো নিজে হাতে learning rate সেট করতেন না, তাহলে automated search-এও সেটা রাখবেন না। স্পষ্টত অযৌক্তিক configuration-এ যেকোনো trial নষ্ট হওয়া মানে একটা সম্ভাবনাময় অঞ্চল explore করার সুযোগ হারানো।
| পরিস্থিতি | প্রস্তাবিত algorithm |
|---|---|
| Trial সস্তা (সেকেন্ড); অনেক hyperparameter | Random search — দ্রুত, space ভালোভাবে কভার করে, parallelize করা সহজ |
| Trial ব্যয়বহুল (মিনিট-ঘণ্টা); কম hyperparameter (২-৮টা) | Bayesian optimization (Optuna TPE) — আগের trial থেকে শিখে ভালো configuration প্রস্তাব করে |
| Checkpoint-সহ neural network training | Hyperband বা ASHA — খারাপ configuration আগেই বাদ দিয়ে ভালোগুলোতে বাজেট কেন্দ্রীভূত করে |
| খুব সীমিত বাজেট (২০টার কম trial) | Bayesian optimization, অথবা সবচেয়ে গুরুত্বপূর্ণ ১-২টা hyperparameter-এ কেন্দ্রীভূত manual search |
| Reproducibility জরুরি | ব্যবহৃত exact random seed আর algorithm রেকর্ড রাখুন; grid search সম্পূর্ণ reproducible ফলাফল দেয় |
বেশিরভাগ model-এর জন্য একটা স্বাভাবিক priority ক্রম আছে যা search-কে বেশি efficient করে তোলে:
১. Learning rate (neural network) বা capacity control (tree model)
এটা প্রায় সবসময় সবচেয়ে গুরুত্বপূর্ণ hyperparameter। বাকি সবকিছুর আগে এর মোটামুটি সঠিক range বের করুন।
২. Regularization
Capacity একবার ঠিকঠাক হলে overfitting আটকাতে regularization tune করুন — dropout rate, weight decay, min_samples_leaf, বা alpha।
৩. Model-specific parameter
Architecture-এর depth, width, head সংখ্যা, বা tree-specific parameter (max_features, subsample)। এগুলো প্রায়ই প্রথম দুইটার চেয়ে কম গুরুত্বপূর্ণ।
৪. Joint refinement
Importance analysis দিয়ে চিহ্নিত করা সেরা ২-৫টা parameter নিয়ে একটা joint search চালান। এটা তাদের মধ্যেকার interaction ধরে ফেলে।
Search শুরুর আগেই একটা compute budget ঠিক করুন — হয় wall-clock time দিয়ে (Optuna-তে timeout) নয়তো trial সংখ্যা দিয়ে (n_trials)। কোনো predefined stopping criterion না থাকলে search চলতেই থাকে, আর "আরেকটু try করে দেখি"-র লোভ validation set-এর ওপর overfitting-এ নিয়ে যায়। study.optimize(objective, n_trials=100) দিয়ে fixed trial সংখ্যায়, study.optimize(objective, timeout=3600) দিয়ে fixed wall-clock time-এ, বা best value কয়েক trial ধরে না বাড়লে থামার মতো callback দিয়েও budget বেঁধে দেওয়া যায়।
যেসব HPO সমস্যায় মাঝপথের checkpoint দেখে trial evaluate করা যায়, সেখানে early stopping প্রায় সবসময়ই চালু করার যোগ্য। Optuna-র MedianPruner-এ n_startup_trials=5 (pruning শুরুর আগে অন্তত ৫টা সম্পূর্ণ trial দরকার) আর n_warmup_steps=10 (epoch ১০-এর আগে prune না করা)-এর মতো setting দিয়ে neural network HPO-র সাথে pruner জুড়ে দেওয়া যায়। একটা median pruner সাধারণত ৪০-৭০% trial তাদের training budget-এর প্রথম ১০-২০% এর মধ্যেই বাদ দিয়ে দেয়, সেরা configuration খুঁজে পাওয়ার ওপর সামান্যই প্রভাব ফেলে।
একটা সাধারণ ভুল হলো — search-এ ব্যবহৃত একই cross-validation loop দিয়ে সেরা configuration বাছাই করা, তারপর সেই CV score-টাই final performance estimate হিসেবে রিপোর্ট করা। এটা overfitting — বাছাই করা configuration-টা সেই নির্দিষ্ট fold-এ ভাগ্যক্রমে ভালো করেছিল। সঠিক workflow হলো — search phase-এ validation set বা CV দিয়ে search পরিচালনা করুন, selection phase-এ সেরা configuration বাছুন, আর evaluation phase-এ পুরো training set-এ retrain করে search-এ কখনো ব্যবহার না হওয়া test set-এ evaluate করুন। শুধু evaluation phase-এর score-টাই model-এর generalization performance হিসেবে রিপোর্ট করা উচিত।
| লক্ষণ | সম্ভাব্য কারণ | সমাধান |
|---|---|---|
| সব trial প্রায় একই স্কোর দিচ্ছে | Search space খুব সংকীর্ণ; সব value একই রকম আচরণ করছে | Search space বাড়ান |
| সেরা configuration search space-এর একেবারে সীমানায় | আসল optimum range-এর বাইরে | সীমানার দিকে range বাড়ান |
| অনেক trial-এর পরও উন্নতি হচ্ছে না | সমস্যাটা সহজ (যেকোনো config কাজ করে), অথবা search converge করেছে | Hyperparameter importance দেখুন; সব কম হলে সমস্যাটা সত্যিই hyperparameter-এর প্রতি insensitive |
| একই configuration-এ বারবার run করলে score-এ বিশাল তারতম্য | Fold সংখ্যা কম / validation set খুব ছোট; high-variance evaluation | বেশি fold, stratification, বা বড় validation set ব্যবহার করুন |
| Search-এ সেরা trial test set-এ অনেক খারাপ করছে | Validation set-এর ওপর overfitting; হয় trial বেশি নয়তো validation set খুব ছোট | Nested CV বা সম্পূর্ণ আলাদা test set ব্যবহার করুন |
Search শেষে লিখে রাখুন — কেন এই search space বেছেছিলেন (আগের জ্ঞান, literature, domain expertise), কোন hyperparameter আসলে গুরুত্বপূর্ণ প্রমাণিত হলো, কোনো range বাড়ানো বা কমানো লাগলো কিনা, আর শেষ সেরা configuration কী ছিল আর কী performance দিলো। এই ডকুমেন্টেশনটাই একটা HPO run-এর সবচেয়ে মূল্যবান সম্পদ — একই বা সমজাতীয় সমস্যায় পরের search-কে পথ দেখায়।
Search-এ পাওয়া সেরা configuration বাছা হয়েছিল কারণ সেটার CV score সবচেয়ে ভালো ছিল। সেই score-টাই generalization estimate হিসেবে রিপোর্ট করা optimistically biased। সেরা config দিয়ে পুরো training set-এ retrain করে, test set-এ evaluate করুন।
২০০টা trial চালিয়ে কোন hyperparameter ফলাফল ঠিক করেছে সেটা বিশ্লেষণ না করেই সেরা configuration বেছে নেওয়া মানে পরের search-এর জন্য কিছুই শেখা হলো না। সবসময় hyperparameter importance প্লট করুন; এটা পরের search আরো efficient ভাবে design করতে দিকনির্দেশনা দেয়।