পাঠ ৩ · ৩৩-এর মধ্যে · মডিউল ১

Home / AI Courses / MLOps / Maturity levels

MLOps maturity levels

Maturity levels — 0, 1, 2

৬ মিনিট পড়া মধ্য · Intermediate Concept

এই পাঠে যা শিখবেন

Google-এর ৩-stage maturity model — concrete signal কী
প্রতিটি level-এ কোন tooling সাধারণত থাকে
নিজের org-কে কীভাবে assess করবেন
কখন level upgrade overkill — কখন essential

১ · কেন একটি maturity model দরকার

MLOps adoption একদিনে হয় না। ছোট স্টার্টআপ-এর জন্য full Kubeflow + Feature Store overkill — ১০০ data scientist-এর জন্য manual notebook চলে না। মাঝে স্পষ্ট সীমানা দরকার।

Google-এর ২০২০ সালের একটি technical paper ("MLOps: Continuous delivery and automation pipelines in machine learning") তিনটি level-কে সংজ্ঞায়িত করে। Microsoft-ও পরবর্তীতে অনুরূপ ৫-stage model বের করে। আমরা Google-এর 3-tier-এ ফোকাস করব — সবচেয়ে adopted।

Google-এর ৩ Levels

Level 0: Manual process — every step হাত দিয়ে; deploy = "model file scp"।
Level 1: ML pipeline automation — training pipeline triggered by event/schedule, but deployment স্বয়ংক্রিয় নয়।
Level 2: CI/CD pipeline automation — pipeline-এর code-ও tested, built, ও deployed automatically।

২ · Level 0 — Manual process

বেশিরভাগ ML team এখানে শুরু করে। Concrete signals:

Data scientist Jupyter-এ কাজ করেন।
Feature engineering, training, evaluation — সব notebook cell।
Best model "save and send" — কখনো Slack-এ pickle file।
Production engineer model file নেয়, একটি Flask app-এ wrap করে, server-এ deploy।
Monitoring শুধু infrastructure (CPU, latency)। Model accuracy কেউ দেখে না।
Retraining manual — যখন কেউ মনে করে "model পুরোনো"।

Level 0 ভুল না — শুরু হিসেবে। কিন্তু একটি model-এ ৬ মাসের বেশি থাকলে — drift detect হবে না, reproduce করা যাবে না, কে কী changed কেউ জানবে না। তখনই level 1-এ যাওয়া।

৩ · Level 1 — ML pipeline automation

মূল পরিবর্তন: training একটি reusable, parameterized pipeline। Notebook → Python module/DAG।

Training pipeline (Airflow, Kubeflow, Prefect) — schedule-এ বা event-এ trigger।
Feature engineering deterministic pipeline-এ — pickled transformer or Feature Store।
Experiment tracking (MLflow) — সব run logged।
Model registry — versioned, stage-tracked (Staging/Production)।
Model deploy — semi-automated; promotion-এ approval lagতে পারে।
Monitoring — drift + performance + infrastructure।
Retraining trigger — drift threshold বা new data arrival।

Level 1-এর আসল গুরুত্ব — continuous training (CT)। Production-এ model নিজে নিজে refresh হয়, মানুষের intervention ন্যূনতম।

৪ · Level 2 — CI/CD pipeline automation

Level 1-এ pipeline automated, কিন্তু pipeline-এর code update করতে এখনো manual deploy। Level 2-এ pipeline-এর code-ও CI/CD-তে।

Source repo → GitHub Actions / GitLab CI / Argo।
Test suite: unit (transformers), integration (pipeline end-to-end), data validation।
Successful CI → automated build & deploy of pipeline image।
Pipeline immediately re-run → new model in registry।
Canary or shadow deployment-এ traffic-এ যায়।
Multiple environments — dev, staging, production।

Level 2 সাধারণত team-of-team setup। একটি ML platform team pipeline maintain করে, ৫-১০টি model team সেই platform-এ deploy করে। Bangladeshi context-এ বড় ব্যাংক, top-tier টেক কোম্পানি (Pathao, bKash, Daraz) এই দিকে যাচ্ছে।

তিনটি level — manual থেকে full CI/CD পর্যন্ত। Goal নিজে level বাড়ানো না — business need-এর সাথে match করা।

৫ · একটি pragmatic upgrade checklist

YAML · Self-assessment checklist

# MLOps maturity self-check
# প্রতিটি item-এ yes/no — পরিষ্কার score পাবেন

level_0_baseline:
  has_git_for_code: yes_or_no
  has_dockerfile: yes_or_no
  has_basic_monitoring: yes_or_no  # latency, error rate

level_1_indicators:
  uses_experiment_tracking: yes_or_no   # MLflow / W&B
  has_model_registry: yes_or_no         # versioned
  uses_pipeline_orchestrator: yes_or_no # Airflow / KFP
  has_drift_monitoring: yes_or_no
  feature_engineering_reused: yes_or_no # not re-coded for serving
  retraining_automated: yes_or_no

level_2_indicators:
  pipeline_code_in_ci: yes_or_no
  automated_tests_for_pipeline: yes_or_no
  multi_environment_deployment: yes_or_no  # dev / staging / prod
  canary_or_shadow_used: yes_or_no
  ds_team_can_deploy_self_service: yes_or_no

# Score:
#   level_1_indicators 6/6 → you are at Level 1
#   level_2_indicators 5/5 → you are at Level 2
#   anything missing → identify the gap, prioritize

এই checklist team-এর সাথে ১ ঘণ্টায় run করুন। প্রতিটি "no"-এর জন্য — সবচেয়ে কম effort-এ কোনটা "yes" করা যাবে — সেটাই পরবর্তী quarter-এর priority।

৬ · Microsoft-এর alternative: 5-stage

Microsoft-এর model একটু differently — Stage 0 (No MLOps) → Stage 1 (DevOps but no MLOps) → Stage 2 (Automated training) → Stage 3 (Automated model deployment) → Stage 4 (Full MLOps + retraining)। ধারণা একই — granularity আলাদা। নিজেদের জন্য যেটা match করে — ব্যবহার করুন।

ভাবনার প্রশ্ন

প্র ০১ আপনার organization (real বা imaginary) কোন level-এ? Concrete signal দিয়ে justify করুন এবং পরবর্তী level-এ যেতে সবচেয়ে কম effort-এর কোন একটি step?

Self-assessment-এর গুরুত্ব — অনুমান বা wishful thinking নয়, evidence-based।

Concrete signals to look for (not "we think we're at L1"):

"আমাদের MLflow আছে" → Level 1 indication। কিন্তু "৬ মাসের পুরোনো run কেউ কিছুই কখনো check করে না" → Level 0 reality।
"GitHub Actions আছে" → হতে পারে Level 2। কিন্তু ML pipeline-এ trigger না করলে → Level 1 max।
"Drift monitoring আছে" → Level 1। কিন্তু alert কখনো action-এ নিয়ে যায় না → effective Level 0।

Realistic Bangladeshi mid-size example (একটি fintech startup):

Code git-এ ✓, Dockerfile আছে ✓ — Level 0 baseline complete।
MLflow tracking আছে কিন্তু registry empty — partial Level 1।
Airflow আছে data ETL-এ, কিন্তু training pipeline manual — Level 0/1 hybrid।
Drift monitoring নেই — Level 0।
CI/CD only application code-এ, ML pipeline-এ না — Level 0।

Verdict: Effective Level 0.5। অর্থাৎ — Level 0 baseline ✓, Level 1-এর পথে।

সবচেয়ে কম effort-এর next step:

MLflow registry-তে current production model register — ১ ঘণ্টার কাজ, big traceability gain।
Drift monitoring (PSI on top-3 features) — basic implementation ২-৩ দিন।
Training pipeline Airflow-এ wrap — ১ সপ্তাহ।

সাধারণ "low-hanging fruits":

MLflow tracking + auto-log: ১ লাইনের code change, immediate value।
Data validation (Great Expectations): pipeline-এ pre-step, drift-এর forerunner।
Model versioning convention: model-name/v1.2.3 + git tag।

মূল উপলব্ধি: Maturity level-কে binary না — gradient হিসেবে দেখুন। প্রতিটি practice-এর adoption percentage হিসাব করুন। "Level 1" — মানে ৭০-৮০% practices in place, ১০০% না।

প্র ০২ "Level 0 → Level 1 transition cost কত — ৬ জনের ML team-এর জন্য?" Realistic effort-cost estimation।

Concrete planning-এর জন্য numbers। Bangladeshi context-এ realistic।

Major work items:

MLflow setup: server, backend store, artifact store। ১ engineer × ১ সপ্তাহ। Tracking integration: প্রতি model-এ ২ ঘণ্টা × ৫ models = ১০ ঘণ্টা।
Pipeline orchestrator (Airflow): infrastructure setup + first DAG। ২-৩ সপ্তাহ for one engineer।
Model registry usage: conventions + promotion process। ১ সপ্তাহ + ongoing।
Basic drift monitoring: PSI computation + alerting। ২-৩ সপ্তাহ।
Documentation + training: team adoption-এর জন্য। ১ সপ্তাহ।

Total effort estimate: ~১২-১৬ engineer-week for one dedicated engineer, plus ১০-২০% time from other DS।

Cost in BDT (junior+senior mix):

Senior engineer 3 months @ ১.৫ লাখ/month = ৪.৫ লাখ BDT।
Cloud infrastructure (managed databases, K8s cluster small): $৪০০-৬০০/month × ৩ months = ১.৫-২ লাখ BDT।
Tool licenses (mostly OSS, but maybe SaaS like W&B): $০-২০০/month।
Total: ৬-৭ লাখ BDT one-time setup, plus ১.৫-২ লাখ BDT/year ongoing।

Faster path — managed services:

Databricks / SageMaker / Vertex AI — much faster setup, but lock-in।
Setup time: ২-৪ weeks vs ১২-১৬ weeks self-hosted।
Recurring cost higher: $২,০০০-৫,০০০/month for medium workload।

ROI calculation:

Without Level 1: ১ ML incident/month × ১০ hours debug = ১২০ hours/year × ১,০০০ BDT/hour = ১.২ লাখ/year just incidents।
Plus: lost experiments, untraceable models, slow retraining।
Realistic savings: ৫-১০ লাখ BDT/year for a 6-engineer team।
ROI achieved within ১ year for self-hosted, ~৬ months for managed।

মূল উপলব্ধি: Level 1 transition একটি measurable investment — emotional decision না। Concrete cost vs benefit calculate করুন। Bangladeshi context-এ managed service-এর recurring cost বেশি কিন্তু upfront low — startup-এর জন্য usually better।

প্র ০৩ "Level 2 কখন overkill?" — ৩টি specific scenario দিন যেখানে Level 1-এই থামা ভাল।

"More mature = better" — এটি common myth। Level upgrade করার আগে ROI critically evaluate করুন।

Scenario 1 — Single model, slow change:

একটি static model — মাসে একবার retrain, কম traffic।
উদাহরণ: একটি local NGO-এর "donor scoring" model।
Level 2-এর CI/CD complexity না — manual review-deploy-এ ভাল control।
Level 2 এখানে শুধু operational overhead।

Scenario 2 — Highly regulated, slow approval:

একটি bank-এর credit scoring model — প্রতিটি deployment regulator approval দরকার।
Auto-deploy প্রস্তাব করেও — compliance team স্বীকার করবে না।
Level 1 + manual gate — সঠিক fit।
Bangladesh Bank guideline-এ এমন model auto-deploy দু'মুখী risk।

Scenario 3 — Small team, all-Python stack:

৩-জনের team, একটি Python service, একটি training pipeline।
GitHub Actions-এ basic CI আছে। সবাই code review করে।
Multi-env (dev/stg/prod) overhead-এর benefit ছোট — কারণ team small।
Level 2-এর "self-service deploy" — যেখানে team-ই ৩ জন — meaningful না।

Anti-pattern — "premature Level 2":

Kubeflow + ArgoCD + Tekton + Tilt — সব tool installed।
Reality: ১ team, ১ model, monthly retrain।
৬ মাস infrastructure-এ time spent — actual model performance improve হয়নি।
Premature optimization-এর ML version।

"Right-sized" indicator:

Engineer hours: model improvement vs infrastructure ratio। যদি < 60% model time → infrastructure too heavy।
Time-to-deploy new model: ১-২ দিন acceptable; ১ সপ্তাহ-এর বেশি = upgrade needed; <১ ঘণ্টা = probably over-engineered for small team।

Cardinal rule:

Level upgrade করার আগে — current level-এ কোন pain felt? Pain না থাকলে — investment-এর justification কঠিন।

মূল উপলব্ধি: Maturity model-এর প্রকৃত উদ্দেশ্য — current state diagnose করা। Goal হলো business need-এর সাথে maturity match — highest level reach না। Level 1 কয়েক বছর ধরে happy থাকলে — সেটাই perfect।

প্র ০৪ "Org-cultural prerequisites" — Level upgrade-এ technical-এর বাইরে কী প্রয়োজন? কোন cultural barrier সবচেয়ে কঠিন?

MLOps adoption-এ ৭০% culture, ৩০% technology। Tool-এর চেয়ে adoption-এর pattern গুরুত্বপূর্ণ।

Cultural prerequisite #1 — DS team-এর software engineering acceptance:

Many DS-রা notebook prefer করেন — code modularity, testing, version control "engineer-এর কাজ" মনে করেন।
Level 1 mandates: Python module, function-based code, unit test।
Cultural shift: "research code" এবং "production code" — single codebase-এ থাকা।
Bangladesh-এ many DS PhD/MS background থেকে — academic notebook habit গভীর।

Cultural prerequisite #2 — DevOps/Platform team-এর ML appreciation:

Traditional DevOps team — model file-কে আরেকটা artifact ভাবে। Reality: model + data + features = একসাথে। MLOps-এর অতিরিক্ত dimension।
Drift, retraining, A/B test — DevOps-এ exist করে না। Skill upgrade দরকার।
Bangladesh-এ majority DevOps team এই concepts-এ unfamiliar।

Cultural prerequisite #3 — Leadership-এর "process over hero" mindset:

Level 0 অনেক সময় "rockstar engineer"-এর উপর depend করে। Manual process work করে কারণ X জানে।
Level 1+ — process-driven। X ছুটিতে গেলেও pipeline চলে।
Hero culture-এ leaders comfortable — "X-কে একটু feedback দিলেই হয়ে যায়।"
Process culture: "X লেখা না থাকলে — গ্যাপ identify, fill the gap।"

Cultural prerequisite #4 — Failure tolerance:

CI/CD-তে — early break, fix, learn। Failure cheap হতে হবে।
"Production deploy কখনো ভুল হয় না" — এই expectation-এ Level 2 ভাঙবে।
Postmortem culture, blameless review।

সবচেয়ে কঠিন barrier — DS-DevOps wall:

"We do data, you do infra" — এই mental wall MLOps-এর প্রধান শত্রু।
সমাধান: ML platform engineer hire — যে দু'টো language জানে। Translator হিসেবে কাজ করে।
Joint Slack channel, joint sprint planning, joint on-call।

Practical adoption tips:

Champion engineer চিহ্নিত করুন — যিনি early adopter।
Small wins celebrate করুন — "এই deployment-এ rollback ১ মিনিটে হলো" → loud।
Lunch & learn — concept-by-concept introduce।
Start with low-risk model — high-risk fraud model দিয়ে Level 2 শুরু করবেন না।

মূল উপলব্ধি: MLOps maturity tool-এর তালিকা না — practice ও culture-এর তালিকা। Bangladeshi tech ecosystem-এ DevOps + DS bridge বানানো সবচেয়ে strategic invest। যে company দু'টো team-কে একসাথে কাজ করাতে পারে — তারাই দ্রুততম mature হবে।

অনুশীলন

Self-assess: উপরের YAML checklist নিজের team-এ apply করুন (real বা imagined)। Score লিখুন। সবচেয়ে কম effort-এর next "yes" কোনটা?

সাধারণ pattern: Level 0 baseline complete (git, docker), Level 1 partial (MLflow আছে, registry empty), Level 2 absent। Lowest-effort next step usually = registry usage convention বা PSI drift monitoring।
লিখুন: bKash-এর fraud detection system imagine করুন। Level 0, 1, 2-এ সেটি কেমন দেখাবে — ৩-বাক্যে প্রতিটি।
- L0: Notebook-এ train; pickle file engineering team-কে handover; manual deploy; alert হলে ম্যানুয়ালি retrain।
- L1: Airflow-এ daily training pipeline; MLflow-এ tracked; registry-তে versioned; PSI drift alert; auto-retrain।
- L2: Code change → CI test → auto-deploy training pipeline → new model → canary 5% traffic → full rollout if metrics OK।
চিন্তা: আপনার team L1-এ। CTO চান L2-তে যেতে। আপনার ৩-bullet-point counter-argument তৈরি করুন (যদি আপনি believe করেন L1 যথেষ্ট)।
- "আমাদের ৩টি model, monthly retrain — daily auto-deploy-এর demand নেই।"
- "L2-এ ৩ মাস infra time → ৬০ লাখ opportunity cost; same time-এ ৩ নতুন model possible।"
- "L1-এ যে gap আছে (better drift detection, lineage) — সেটা solve হলে L2 prerequisite naturally accumulate হবে। Premature jump এড়িয়ে।"