Chapter 9 of 16
Real pipelines, real datasets, real decisions
Hyperparameter optimization নিয়ে পড়া আর সেটা বাস্তবে করা — দুটো সম্পূর্ণ ভিন্ন অভিজ্ঞতা। এই chapter-এ তিনটা সম্পূর্ণ, end-to-end প্রজেক্ট নিয়ে আলোচনা হবে — প্রতিটাতে বাস্তব data, বাস্তব সিদ্ধান্ত, বাস্তব ভুল করার সুযোগ, আর বাস্তব ফলাফল। প্রতিটা প্রজেক্ট model type, HPO algorithm, আর validation strategy-র ভিন্ন ভিন্ন সমন্বয় দেখায়, যা একেকটা বাস্তব production scenario-র প্রতিনিধিত্ব করে।
পরিস্থিতি। একটা আর্থিক প্রতিষ্ঠানের জন্য fraud detection model বানাচ্ছেন। Dataset tabular, মাঝারি রকম imbalanced (মাত্র ৫% positive class), আর ব্যবসার কাছে precision-এর চেয়ে recall বেশি গুরুত্বপূর্ণ — জালিয়াতি ধরা যত বেশি সম্ভব।
প্রথমে default hyperparameter দিয়ে একটা baseline XGBoost model বসিয়ে দেখা হয় সেটা কেমন করে। এরপর Optuna দিয়ে search space সাজানো হয় — n_estimators, max_depth, learning_rate, subsample, regularization প্যারামিটার, আর সবচেয়ে গুরুত্বপূর্ণভাবে scale_pos_weight — যেটা দিয়ে XGBoost class imbalance সামলায়। Evaluation metric হিসেবে accuracy নয়, average_precision ব্যবহার করা হয়, কারণ ৯৫% negative class-এর dataset-এ accuracy বিভ্রান্তিকর — সব example-কে "negative" বললেই ৯৫% accuracy পাওয়া যাবে। সবশেষে সেরা configuration দিয়ে পুরো training set-এ retrain করে, একেবারে শেষে test set-এ evaluate করা হয়।
লক্ষ্য করুন test set শুধু একেবারে শেষ ধাপে আসে, সব hyperparameter সিদ্ধান্ত চূড়ান্ত হওয়ার পরেই। এর আগে কোনো ধাপে test set দেখলেই generalization performance-এর estimate কলুষিত হয়ে যাবে।
এই প্রজেক্টের মূল সিদ্ধান্তগুলো — accuracy-র বদলে average precision ব্যবহার করা, scale_pos_weight-কে search space-এ রাখা, আর regularization প্যারামিটার log-uniform scale-এ search করা।
পরিস্থিতি। ১০-ক্লাসের একটা মোটামুটি balanced dataset-এ image classification-এর জন্য একটা CNN train করছেন। হাতে ২টা GPU, আর ৪ ঘণ্টার সময়সীমা।
এখানে architecture (conv layer সংখ্যা, filter সংখ্যা, dropout) আর optimization (learning rate, weight decay, batch size) — দুটোই একসাথে search করা হয়, কারণ এই দুই ধরনের hyperparameter একে অপরের সাথে interact করে। প্রতিটা trial-এ মিনিটের পর মিনিট সময় লাগে বলে pruning ব্যবহার করা জরুরি হয়ে পড়ে — মাঝপথে validation accuracy দেখে যে trial-গুলো সম্ভাবনাহীন মনে হচ্ছে, সেগুলোকে আগেভাগেই থামিয়ে দেওয়া হয়। প্রতিটা trial-এ একই fixed epoch সংখ্যা আর cosine annealing scheduler ব্যবহার করা হয়, যাতে trial-গুলো একে অপরের সাথে তুলনাযোগ্য থাকে।
পরিস্থিতি। কাস্টমার সাপোর্ট টিকিটকে ৮টা ক্যাটাগরিতে ভাগ করতে হবে, একটা pretrained BERT model fine-tune করে। প্রতিটা training run-এ একটা GPU-তে প্রায় ১৫ মিনিট লাগে, তাই বাজেট মোটামুটি ২০টা trial-এর মধ্যে সীমাবদ্ধ।
মাত্র ২০টা trial দিয়ে একসাথে অনেক hyperparameter search করার সুযোগ নেই। তাই priority অনুযায়ী কাজ করতে হয়:
| Priority | Hyperparameter | কারণ |
|---|---|---|
| ১ম | Learning rate | Fine-tuning-এ সবচেয়ে বেশি প্রভাব ফেলে; এটাই আগে ঠিক করুন। Range: 1e-5 থেকে 5e-5 (log-uniform)। |
| ২য় | Training epoch সংখ্যা | খুব বেশি epoch fine-tuning-এ catastrophic forgetting ঘটায়; খুব কম হলে underfitting হয়। Range: ২–৫। |
| ৩য় | Batch size | Gradient-এর noise আর hardware efficiency-কে প্রভাবিত করে। Choice: ১৬, ৩২, ৬৪। |
| ৪র্থ | Weight decay | Optimizer-এর L2 regularization। Range: 0 থেকে 0.1। |
| ৫ম | Warmup ratio | Learning rate warmup-এর জন্য training step-এর ভগ্নাংশ। Range: 0 থেকে 0.2। |
HuggingFace-এর Trainer.hyperparameter_search API এই পুরো loop-টা — বারবার model initialize করা, train করা, evaluate করা — স্বয়ংক্রিয়ভাবে সামলে দেয়।
প্রতিটা trial একই pretrained checkpoint থেকে fine-tune শুরু করে (আগের trial-এর weight থেকে নয় বলে), তাই প্রতিটা trial independent থাকে আর ফলাফল বৈধ থাকে। Trainer.hyperparameter_search বারবার model initialize করা, train করা, আর evaluate করার লুপটা স্বয়ংক্রিয়ভাবে সামলে দেয়।
৯৫% negative class-এর dataset-এ accuracy-র জন্য tune করা মডেল সব সময় "negative" predict করতে শিখে ফেলবে, আর ৯৫% accuracy পেয়ে যাবে। নিশ্চিত করুন আপনার optimization metric বাস্তবে ব্যবসা কী চায় সেটাই প্রতিফলিত করে।
Pruning ছাড়া ১০০-trial-এর একটা neural network HPO experiment ১০০টা মডেলকেই সম্পূর্ণভাবে train করবে। Median pruning দিয়ে খারাপ configuration epoch ৫০-এর বদলে epoch ৫-এই থেমে যায় — সেই trial-গুলোর জন্য compute-এ ১০ গুণ সাশ্রয়, যা বেশি সম্ভাবনাময় configuration-এর জন্য বাজেট মুক্ত করে দেয়।