MLOps Part 2: monitoring, model drift, retraining, CI/CD — 'খারাপ prediction বুঝব কীভাবে?'

production loop বন্ধ করা (Series 09, Episode 08)

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

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

🎬 ১. গল্প: "Model তো চলছে... নাকি চলছে না?"

Rahim-এর churn model তিন মাস ধরে production-এ। সব ঠিক দেখাচ্ছে — API up, latency ভালো, কোনো error নেই। হঠাৎ Boss একদিন রেগে হাজির:

💼 Boss: "গত দুই মাসে আমরা model-এর কথা শুনে অনেক customer-কে 'safe' ধরে ছেড়ে দিয়েছিলাম — তারা সব চলে গেছে! Model তো crash করেনি, তাহলে ভুল prediction দিল কীভাবে? আর আমরা টেরই পেলাম না কেন?"

Maya শান্তভাবে বলল: "এটাই production ML-এর সবচেয়ে ভয়ংকর সমস্যা — model crash করে না, নীরবে খারাপ হয়। API ঠিকই ২০০ status দেয়, শুধু prediction-গুলো ভুল হতে থাকে। এটাকে বলে drift। আর ধরার একমাত্র উপায় — monitoring।"

২. সমস্যা: model নীরবে খারাপ হয়

একটা সাধারণ software bug চিৎকার করে (error, crash, 500)। একটা model খারাপ হলে চুপ থাকে — সে আত্মবিশ্বাসের সাথে ভুল উত্তর দেয়। কারণ পৃথিবী বদলায় (নতুন customer আচরণ, নতুন দাম, নতুন trend), কিন্তু model পুরনো data-য় আটকে থাকে। তাই training ≠ চিরস্থায়ী সত্য — একবার ভালো মানে চিরকাল ভালো নয়।

🧠 ৩. তিন স্তরে: monitoring মানে কী

Level 1 — intuition: একটা গাড়ির dashboard — speed, জ্বালানি, engine temperature। এগুলো না থাকলে গাড়ি হঠাৎ বন্ধ হওয়া পর্যন্ত কিছু বুঝতে না। Monitoring হলো তোমার model-এর dashboard।
Level 2 — technical: আমরা নিয়মিত মাপি — কতগুলো request, latency, error rate (system), আর input data-র distribution ও prediction-এর distribution (model)। এগুলো সময়ের সাথে বদলালে alert দিই।
Level 3 — engineer perspective: engineer একটা feedback loop বানায় — prediction + (পরে পাওয়া) actual outcome মিলিয়ে model-এর live performance মাপে, drift ধরলে retraining trigger করে। এটাই production ML-কে "একবার deploy" থেকে "জীবন্ত system"-এ রূপ দেয়।

📊 ৪. দুই ধরনের monitoring: system বনাম model

ধরনকী মাপেউদাহরণ
System monitoringservice ঠিক চলছে কিনাlatency, error rate, CPU/RAM, request/sec, uptime
Model monitoringprediction ঠিক আছে কিনাinput distribution, prediction distribution, accuracy (actual পেলে), drift
Junior-রা প্রায়ই শুধু system monitoring করে (API up আছে তো!) — কিন্তু ভুলে যায় model monitoring। Rahim-এর সমস্যা ঠিক এখানেই: system সবুজ ছিল, model লাল হয়ে গিয়েছিল।

🌊 ৫. Model Drift: data drift বনাম concept drift

Data Drift (input বদলায়)
যে ধরনের input model দেখছে সেটাই বদলে গেছে।
উদাহরণ: churn model শিখেছিল পুরনো দামের customer-দের নিয়ে; এখন সব customer নতুন প্ল্যানে — input distribution আলাদা।
Concept Drift (সম্পর্ক বদলায়)
input আর output-এর সম্পর্কটাই বদলে গেছে।
উদাহরণ: আগে কম দাম = কম churn; এখন প্রতিযোগীর অফারে কম দামেও customer চলে যায় — নিয়ম বদলাল।

দুটোই model-কে অচল করে দেয় — তাই দুটোই নজরে রাখতে হয়।

🗺️ ৬. Visual: কীভাবে model নীরবে ভাঙে

Month 1 Month 2 Month 3 Month 4 accuracy 89% 87% 81% 72% <- নীরব পতন ✅ ✅ (ঠিক আছে?) 🟡 ❌ API status: 200 200 200 200 <- system সবসময় সবুজ! | monitoring না থাকলে এখানে টের পাই (customer হারানোর পর — অনেক দেরি)

💻 ৭. হাতে-কলমে: prediction ও input log করা

Drift ধরার প্রথম শর্ত — প্রতিটা prediction ও তার input সংরক্ষণ করা। FastAPI-তে সহজ:

# app/main.py — prediction log করা (drift analysis-এর কাঁচামাল) import json, time from app.logging_conf import logger @app.post("/predict", response_model=Prediction) def predict(customer: Customer): risk = predict_one(model, customer) # structured log -> পরে distribution বিশ্লেষণ করা যাবে logger.info(json.dumps({ "event": "prediction", "ts": time.time(), "input": customer.model_dump(), "risk": round(risk, 3), "model_version": "v3", })) return Prediction(churn_risk=risk, will_churn=risk >= 0.5)
এই log পরে একটা table/warehouse-এ জমিয়ে আমরা দেখতে পারি — input-এর গড়/distribution বদলাচ্ছে কিনা, prediction-এ হঠাৎ সব "safe" হয়ে যাচ্ছে কিনা। (privacy খেয়াল রেখো — sensitive field mask করো।)

🔍 ৮. Drift ধরার সহজ উপায়

বড় tool-এর আগে junior-friendly পদ্ধতি — reference (training) distribution বনাম live distribution তুলনা:

import numpy as np from scipy.stats import ks_2samp # training-এর সময়কার feature বনাম এখনকার live feature train_tenure = np.load("ref_tenure.npy") # reference live_tenure = np.array(recent_tenure_values) # সাম্প্রতিক # KS test: দুই distribution আলাদা কিনা stat, p_value = ks_2samp(train_tenure, live_tenure) if p_value < 0.05: print("⚠️ DATA DRIFT detected: input distribution বদলেছে") # -> alert পাঠাও / retraining বিবেচনা করো

Production-এ এর জন্য Evidently AI-এর মতো tool আছে যা drift report ও dashboard বানিয়ে দেয়। junior-এর জন্য এখন ধারণা বোঝাই যথেষ্ট — "reference বনাম live distribution তুলনা করে drift ধরা যায়।"

🔁 ৯. Retraining: কখন ও কীভাবে

Drift ধরা পড়লে সমাধান সাধারণত নতুন data দিয়ে retrain। কখন?

Retraining মানেই আবার আগের সব ধাপ — নতুন data (DVC-versioned) → train + track (MLflow) → evaluate → নতুন model registry-তে register → deploy। মানে Series 09-এর পুরো চক্রটাই আবার ঘোরে। এটাই "closing the loop"।

⚙️ ১০. CI/CD for models

সাধারণ software-এ CI/CD মানে: code push → auto test → auto deploy। ML-এ এর সাথে যোগ হয় model-এর ধাপ। (এই blog-এ একটা আলাদা CI/CD সিরিজ আছে — pipeline গভীরে বুঝতে দেখো।)

git push (নতুন কোড/model কোড) | CI: lint + unit test + model test | (নতুন model train হলে) Evaluate: নতুন model কি পুরনোটার চেয়ে ভালো? | হ্যাঁ -> না -> থামাও Register + Docker build + deploy (staging -> production) | Monitor -> drift -> (আবার শুরু)
ML-এর বিশেষ CI test: শুধু কোড test নয় — "model কি একটা minimum accuracy পার করছে?", "একটা known input-এ কি প্রত্যাশিত output দিচ্ছে?" — এগুলোও automated test হিসেবে রাখা হয়, যাতে খারাপ model ভুলেও production-এ না যায়।

🧪 ১১. Experiment: drift বানিয়ে দেখা

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

বাংলাদেশে COVID বা হঠাৎ বাজার পরিবর্তনের সময় অনেক fintech/e-commerce-এর model রাতারাতি অচল হয়ে গিয়েছিল — মানুষের কেনাকাটা, ঋণ পরিশোধের আচরণ পাল্টে গিয়েছিল (concept drift)। যাদের monitoring ছিল, তারা দ্রুত retrain করে টিকে গেল; যাদের ছিল না, তারা চুপচাপ ভুল সিদ্ধান্ত নিতে থাকল আর টাকা হারাল। তাই monitoring কোনো বিলাসিতা নয় — এটা model-কে বাস্তবের সাথে জীবিত রাখার শর্ত।

👷 ১৩. AI Engineer perspective

Must Know (junior): কেন model নীরবে খারাপ হয়, system বনাম model monitoring, drift-এর ধারণা।
Good to Know: prediction logging, simple drift check, retraining strategy।
Learn Later: Evidently/Prometheus/Grafana dashboard, automated retraining pipeline, full CI/CD for ML।
সবচেয়ে গুরুত্বপূর্ণ mindset: deploy করা মানে শেষ নয়, শুরু। একটা model-এর জীবন হলো — deploy → monitor → drift ধরা → retrain → আবার deploy। এই loop বোঝা junior থেকে সত্যিকারের production engineer হওয়ার চিহ্ন।

💼 ১৪. Boss Question

💼 Boss: "Production model খারাপ prediction দিলে আমরা বুঝব কীভাবে? আর বুঝলে করব কী?"

উত্তর: বুঝব monitoring দিয়ে — আমরা prediction ও input নিয়মিত মাপব, আর যখন live data training data থেকে সরে যাবে (drift) বা accuracy পড়বে, তখন alert পাব — customer হারানোর আগেই। আর করব retrain — নতুন data দিয়ে model আপডেট করে আবার deploy করব। মানে model আর "একবার বানিয়ে ভুলে যাওয়া" জিনিস নয়, এটা একটা জীবন্ত system যা আমরা নজরে রাখি — ঠিক যেমন আপনি মাসিক sales report দেখেন।

🔎 ১৫. Job Requirement Decoder: "Model monitoring, drift detection, retraining, CI/CD"

  1. কী বোঝায়? deploy করা model-এর health/performance নজরে রাখা, drift ধরা, দরকারে retrain ও automated deploy।
  2. কেন চায়? model সময়ের সাথে খারাপ হয়; না ধরলে চুপচাপ ভুল সিদ্ধান্ত → business ক্ষতি।
  3. কোন সমস্যা সমাধান করে? "silent model failure" — crash ছাড়াই ভুল হওয়া।
  4. Junior-এর কী জানা লাগে? system vs model monitoring, drift (data/concept)-এর ধারণা, prediction logging, retraining কখন।
  5. এখনই কী master লাগে না? Prometheus/Grafana/Evidently dashboard বানানো, automated retraining pipeline, full ML CI/CD — পরে।
  6. GitHub-এ কীভাবে দেখাবে? prediction logging কোড + একটা simple drift-check script + README-তে "কীভাবে drift ধরব ও retrain করব"।
  7. Interview-তে কী জিজ্ঞেস করতে পারে? "model খারাপ হচ্ছে কীভাবে বুঝবে?", "data vs concept drift?", "কখন retrain করবে?", "system vs model monitoring?"

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

ভুল ১: শুধু "API up আছে" দেখে সন্তুষ্ট থাকা। → model monitoring-ও চাই।

ভুল ২: ধরে নেওয়া "একবার ভালো model চিরকাল ভালো"। → drift বাস্তব; পৃথিবী বদলায়।

ভুল ৩: prediction/input log না করা। → drift বিশ্লেষণের কাঁচামালই থাকবে না।

ভুল ৪: actual outcome না মিলিয়ে শুধু prediction দেখা। → live accuracy জানতে ground truth লাগে।

ভুল ৫: drift ধরেও retrain-এর plan না থাকা। → জানা কিন্তু কিছু না করা = লাভ নেই।

🎤 ১৭. Interview Prep

প্রশ্ন ১: "Production model খারাপ হচ্ছে কীভাবে বুঝবে?"
উত্তর: model monitoring — input/prediction distribution ও (ground truth পেলে) accuracy track; drift/drop-এ alert।

প্রশ্ন ২: "data drift আর concept drift-এর পার্থক্য?"
উত্তর: data drift = input distribution বদলায়; concept drift = input-output সম্পর্ক বদলায়।

প্রশ্ন ৩: "কখন retrain করবে?"
উত্তর: scheduled (নিয়মিত) বা triggered (drift/performance drop ধরা পড়লে); নতুন data দিয়ে।

প্রশ্ন ৪: "ML-এর CI/CD সাধারণ software থেকে আলাদা কেন?"
উত্তর: code test-এর সাথে model evaluation/validation test যোগ হয়; data ও model version-ও pipeline-এ থাকে।

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

Mini exercise:
১. তোমার /predict-এ input ও prediction structured log করো (উপরের মতো)।
২. test data-র একটা feature কৃত্রিমভাবে shift করে accuracy drop দেখাও (drift simulate)।
৩. ks_2samp দিয়ে reference বনাম shifted feature-এ drift ধরো।
৪. এক প্যারায় একটা retraining plan লেখো: কখন trigger, কোন data, কীভাবে deploy।
৫. তালিকা করো: তোমার service-এ কোন system metric ও কোন model metric নজরে রাখবে।

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

আমাদের flagship "Bangladesh Tech Career Assistant"-এ এখন prediction logging + একটা simple drift check যোগ হলো — যদি JD-তে নতুন ধরনের skill (নতুন framework) আসতে থাকে, আমরা টের পাব যে model-এর জ্ঞান পুরনো হয়ে যাচ্ছে, আর retrain করব। Production loop বন্ধ হলো।

✓ system বনাম model monitoring, ✓ data/concept drift, ✓ prediction logging + simple drift check, ✓ retraining strategy, ✓ CI/CD for models-এর ধারণা।
পরের episode-এ আমরা পুরো Series 09 এক জায়গায় জোড়া লাগাব — Notebook → Package → FastAPI → Docker → Cloud → Monitoring — একটা সম্পূর্ণ case study হিসেবে, যা তোমার portfolio-র কেন্দ্রবিন্দু (Project P10) হবে।
© 2025 Sheikh Thanbir Alam. All Rights Reserved. thanbirtamim.github.io
এই লেখা মূল লেখকের সম্পত্তি — লিখিত অনুমতি ছাড়া কপি করে অন্য কোনো ওয়েবসাইট, ব্লগ, বই বা প্ল্যাটফর্মে প্রকাশ/বিতরণ করা কঠোরভাবে নিষিদ্ধ। Content may not be copied or republished without permission.