MLOps Part 1: experiment tracking, model ও data versioning, model registry

reproducible ML lifecycle (Series 09, Episode 07)

🔴 ADVANCED Series 09 — Notebook থেকে Production AI Episode 07 / 09

📑 এই পর্বে যা যা আছে

🎬 ১. গল্প: "গত সপ্তাহের ভালো model-টা কই?"

Rahim তিন সপ্তাহ ধরে churn model-এর নানা version চেষ্টা করছিল — কখনো RandomForest, কখনো XGBoost, ভিন্ন feature, ভিন্ন hyperparameter। একদিন Boss বলল: "গত সপ্তাহে তো ৮৯% accuracy বলেছিলে, ওটাই deploy করো।" Rahim ঘামতে শুরু করল —

Rahim ভাবল: "কোন version ছিল সেটা? কোন feature দিয়ে? কোন hyperparameter? কোন data দিয়ে train করেছিলাম? আমি তো সব overwrite করে ফেলেছি!"

Maya শুনে বলল: "এটাই তো MLOps-এর মূল সমস্যা — reproducibility। প্রতিটা experiment-এর code, data, parameter আর result track না করলে তুমি নিজের ভালো ফলটাও আর ফিরে পাবে না। DevOps যেমন software-কে reproducible করে, MLOps তেমন ML-কে reproducible করে।"

২. সমস্যা: reproducibility-র দুঃস্বপ্ন

একটা ML result পুরোপুরি reproduce করতে চাইলে চারটা জিনিস লাগে:

Reproducible Model = Code + Data + Config + Environment | | | | | result কোন কোড কোন data কোন param কোন library version

software-এ শুধু কোড version করলেই (Git) চলে। কিন্তু ML-এ result নির্ভর করে data আর hyperparameter-এর উপরও। এই সবগুলো track না করলে "৮৯% accuracy"-র model আর কখনো ফিরে পাওয়া যায় না।

🔧 ৩. MLOps আসলে কী (DevOps + ML)

MLOps = ML system-কে নির্ভরযোগ্যভাবে build, deploy ও maintain করার practice ও tooling। এটা DevOps-এর ধারণা ML-এ প্রয়োগ করে, কিন্তু একটা বাড়তি চ্যালেঞ্জ যোগ করে: software-এ শুধু code বদলায়, ML-এ code + data + model — তিনটাই বদলায়
DevOpsMLOps (বাড়তি)
code version (Git)code + data + model version
build → test → deploy+ train → evaluate → track → register
app monitoring+ model monitoring (drift — পরের episode)

🧠 ৪. তিন স্তরে: কেন tracking ও versioning

Level 1 — intuition: একজন বিজ্ঞানী প্রতিটা experiment-এর ল্যাব-ডায়েরি রাখেন — কী উপকরণ, কী পরিমাণ, কী ফল। পরে কোনটা কাজ করেছিল দেখতে ডায়েরি খোলেন। Experiment tracking হলো ML-এর সেই ডায়েরি।
Level 2 — technical: প্রতিটা training run-এ আমরা log করি — parameters (model type, hyperparameters), metrics (accuracy, F1), artifacts (trained model file), আর কোন code/data version। একটা tool (MLflow) এগুলো সংরক্ষণ করে ও তুলনা করার UI দেয়।
Level 3 — engineer perspective: engineer একটা model registry-তে "best" model-কে stage করে (Staging → Production), version tag দেয়, আর deploy pipeline সেই registry থেকে model টেনে নেয়। ফলে "কোন model production-এ চলছে ও কেন" সবসময় জানা থাকে — audit ও rollback সহজ।

📔 ৫. Experiment Tracking: প্রতিটা run-এর ডায়েরি

কেন MLflow? এটা open-source, সহজ, Python-friendly, আর industry-তে ব্যাপকভাবে ব্যবহৃত (বিকল্প: Weights & Biases)। এটা প্রতিটা run-এর param, metric, model — সব এক জায়গায় রাখে ও তুলনা করতে দেয়।

💻 ৬. MLflow দিয়ে হাতে-কলমে tracking

# pip install mlflow scikit-learn import mlflow import mlflow.sklearn from sklearn.ensemble import RandomForestClassifier from sklearn.metrics import accuracy_score, f1_score mlflow.set_experiment("churn-prediction") def train_and_log(n_estimators, max_depth, X_tr, y_tr, X_te, y_te): with mlflow.start_run(): # 1) parameters log করি (কী দিয়ে train করলাম) mlflow.log_param("n_estimators", n_estimators) mlflow.log_param("max_depth", max_depth) model = RandomForestClassifier( n_estimators=n_estimators, max_depth=max_depth ) model.fit(X_tr, y_tr) # 2) metrics log করি (কেমন করল) preds = model.predict(X_te) mlflow.log_metric("accuracy", accuracy_score(y_te, preds)) mlflow.log_metric("f1", f1_score(y_te, preds)) # 3) model artifact save করি (এই run-এর model) mlflow.sklearn.log_model(model, "model")

এবার নানা config-এ চালাও, তারপর mlflow ui command দিয়ে browser-এ সব run পাশাপাশি তুলনা করো — "কোন run-এ ৮৯% ছিল" এক ক্লিকে খুঁজে পাবে। Rahim-এর দুঃস্বপ্ন শেষ।

🏷️ ৭. Model Versioning ও Model Registry

Tracking-এ সব run জমা হলো। কিন্তু কোনটা "official production model"? এখানেই Model Registry। এটা model-এর একটা central catalog — version সহ, stage সহ।

Model Registry: churn-model ┌──────────────────────────────────────────┐ │ version 1 -> Archived │ │ version 2 -> Staging (test চলছে) │ │ version 3 -> Production (এটাই live) │ └──────────────────────────────────────────┘ | deploy pipeline "Production" tag-এর model টেনে নেয়
সুবিধা: (১) কোন model live তা সবসময় জানা; (২) খারাপ হলে আগের version-এ এক ক্লিকে rollback; (৩) audit trail — কে, কখন, কোন model promote করল।

🗂️ ৮. Data Versioning: কোন data দিয়ে model শেখানো হলো?

Model reproduce করতে code যথেষ্ট নয় — কোন data দিয়ে train হয়েছিল সেটাও লাগে। কিন্তু বড় dataset Git-এ রাখা যায় না (Git কোডের জন্য, GB-scale data-র জন্য নয়)। সমাধান: DVC (Data Version Control)

# pip install dvc # ধারণা: DVC data-র একটা ছোট "pointer" Git-এ রাখে, # আসল বড় file থাকে আলাদা storage-এ (S3/drive) dvc init dvc add data/customers.csv # data track করা শুরু git add data/customers.csv.dvc .gitignore git commit -m "track dataset v1 with DVC" # পরে data বদলালে নতুন version; git checkout করলে # সেই সময়ের কোড + data দুটোই ফিরে পাবে
মূল ধারণা: Git for code, DVC for data — দুটো মিলে একটা ML result সম্পূর্ণভাবে reproducible হয়।

🔁 ৯. Visual: reproducible ML lifecycle

[ Data (DVC versioned) ] | v [ Train + log to MLflow ] --> params, metrics, model | v [ Compare runs (MLflow UI) ] --> best model বাছাই | v [ Model Registry ] Staging -> Production (version tag) | v [ Deploy pipeline pulls "Production" model ] (আগের episode-গুলো) | v [ Monitoring ] (পরের episode — loop বন্ধ করা)

🧪 ১০. Experiment: দুইটা run তুলনা করা

🇧🇩 ১১. বাংলাদেশের বাস্তব প্রসঙ্গ

বাংলাদেশের অনেক team এখনো model file-এর নাম দেয় model_final.pkl, model_final_v2.pkl, model_really_final.pkl — আর কেউ জানে না কোনটা live! এটা বাস্তব, হাসির, কিন্তু বিপজ্জনক। যে junior MLflow/registry দিয়ে এই বিশৃঙ্খলা ঠেকাতে পারে, সে দ্রুত মূল্যবান হয়ে ওঠে। fintech বা health-এর মতো regulated field-এ তো "কোন model কোন data দিয়ে, কে approve করল" — এই audit trail প্রায় বাধ্যতামূলক।

👷 ১২. AI Engineer perspective

Must Know (junior): কেন reproducibility জরুরি, experiment tracking-এর ধারণা, একটা MLflow run log করা।
Good to Know: model registry, DVC দিয়ে data versioning, run তুলনা।
Learn Later (specialization): feature store, automated pipeline (Kubeflow/SageMaker), full CI/CD for ML।

junior হিসেবে তোমার কাছে কেউ পুরো MLflow server চালাতে বলবে না — কিন্তু তুমি যদি experiment track করে, "এই model এই data ও এই param দিয়ে, এই ফল" পরিষ্কার দেখাতে পারো, সেটাই তোমাকে পরিণত (mature) engineer হিসেবে চিহ্নিত করে।

💼 ১৩. Boss Question

💼 Boss: "এই tracking-ট্র্যাকিং, registry — এগুলোতে সময় দিলে আমার কী লাভ? model তো এমনিতেই চলছে।"

উত্তর: লাভ তিনটা — (১) আমাদের সবচেয়ে ভালো model কখনো হারাব না, যেকোনো সময় ফিরে পাব; (২) নতুন model খারাপ করলে পুরনো ভালো version-এ মিনিটে rollback করা যাবে (downtime কম); (৩) কেউ যদি জিজ্ঞেস করে "এই সিদ্ধান্ত কোন model, কোন data দিয়ে?" — আমরা প্রমাণসহ উত্তর দিতে পারব (compliance/আস্থা)। মানে কম risk, দ্রুত recovery, আর বিশ্বাসযোগ্যতা।

🔎 ১৪. Job Requirement Decoder: "MLOps / experiment tracking / model versioning"

  1. কী বোঝায়? ML experiment, model ও data track/version করার practice ও tool ব্যবহার।
  2. কেন চায়? reproducibility, দ্রুত rollback, ও দলগত ML কাজ নিয়ন্ত্রণে রাখতে।
  3. কোন সমস্যা সমাধান করে? "কোন model/param/data ছিল?" ভুলে যাওয়া, বিশৃঙ্খল model file।
  4. Junior-এর কী জানা লাগে? MLflow দিয়ে run log, param/metric/model track, registry ও DVC-এর ধারণা
  5. এখনই কী master লাগে না? full MLOps platform, feature store, automated retraining pipeline — পরে।
  6. GitHub-এ কীভাবে দেখাবে? একটা repo-তে MLflow tracking কোড + README-তে run comparison screenshot; .dvc file দেখানো।
  7. Interview-তে কী জিজ্ঞেস করতে পারে? "কীভাবে experiment track করো?", "model version করো কীভাবে?", "একটা ML result reproduce করতে কী কী লাগে?", "Git কেন বড় data-র জন্য যথেষ্ট নয়?"

⚠️ ১৫. সাধারণ ভুল

ভুল ১: model file-এর নাম final_v2_really.pkl দিয়ে version করা। → registry ব্যবহার করো।

ভুল ২: শুধু accuracy log করা, param/data নয়। → পুরো context log করো, নাহলে reproduce হবে না।

ভুল ৩: বড় dataset Git-এ push করা। → DVC (pointer) ব্যবহার করো।

ভুল ৪: MLOps = tool ভাবা। → এটা মূলত practice/discipline; tool শুধু সাহায্য করে।

ভুল ৫: tracking overkill মনে করে skip করা। → পরে ঠিক এখানেই সবচেয়ে বেশি সময় নষ্ট হয়।

🎤 ১৬. Interview Prep

প্রশ্ন ১: "MLOps কী ও DevOps থেকে আলাদা কেন?"
উত্তর: ML system reliable-ভাবে build/deploy/maintain করার practice; DevOps শুধু code, MLOps code+data+model সব।

প্রশ্ন ২: "একটা ML result reproduce করতে কী লাগে?"
উত্তর: code + data + config/params + environment — চারটাই version/track করা থাকতে হবে।

প্রশ্ন ৩: "experiment tracking কীভাবে করো?"
উত্তর: MLflow দিয়ে প্রতিটা run-এ param, metric, model artifact log; UI-তে তুলনা।

প্রশ্ন ৪: "model registry-র লাভ কী?"
উত্তর: কোন version কোন stage-এ জানা যায়, promote/rollback সহজ, audit trail থাকে।

✍️ ১৭. হাতে-কলমে

Mini exercise:
১. Series 05-এর churn model-এ MLflow tracking যোগ করো; ৩টা ভিন্ন config-এ run করো।
২. mlflow ui খুলে ৩টা run তুলনা করো; best-টা চিহ্নিত করো।
৩. best model-টা MLflow থেকে load করে একটা নতুন input-এ prediction দাও।
৪. dvc init + dvc add দিয়ে তোমার dataset track করো; .dvc file দেখো।
৫. এক প্যারাগ্রাফে লেখো: "৩ মাস পর এই ঠিক model-টা কীভাবে ফিরে পাব?"

🚀 ১৮. Project Connection ও পরের পর্ব

আমাদের flagship "Bangladesh Tech Career Assistant"-এর ML/embedding অংশ এখন MLflow-এ tracked ও registry-তে versioned। "কোন model live, কোন data দিয়ে" — সব জানা। এটা production platform (V10)-এর দিকে একটা বড় ধাপ।

✓ MLOps = DevOps + (data+model), ✓ MLflow experiment tracking, ✓ model registry (stage/rollback), ✓ DVC দিয়ে data versioning — ML lifecycle এখন reproducible।
কিন্তু deploy হওয়া model সময়ের সাথে নীরবে খারাপ হতে পারে (data drift)। পরের episode (MLOps Part 2)-এ আমরা শিখব monitoring, model drift detection, retraining, এবং CI/CD for models — মানে "খারাপ prediction দিলে বুঝব কীভাবে?" — production loop বন্ধ করা।
© 2025 Sheikh Thanbir Alam. All Rights Reserved. thanbirtamim.github.io
এই লেখা মূল লেখকের সম্পত্তি — লিখিত অনুমতি ছাড়া কপি করে অন্য কোনো ওয়েবসাইট, ব্লগ, বই বা প্ল্যাটফর্মে প্রকাশ/বিতরণ করা কঠোরভাবে নিষিদ্ধ। Content may not be copied or republished without permission.