Home »
Blog »
AI/ML Engineer সিরিজ » Series 09 » Episode 08
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 তো চলছে... নাকি চলছে না?"
- ২. সমস্যা: model নীরবে খারাপ হয়
- ৩. তিন স্তরে: monitoring মানে কী
- ৪. দুই ধরনের monitoring: system বনাম model
- ৫. Model Drift: data drift বনাম concept drift
- ৬. Visual: কীভাবে model নীরবে ভাঙে
- ৭. হাতে-কলমে: prediction ও input log করা
- ৮. Drift ধরার সহজ উপায়
- ৯. Retraining: কখন ও কীভাবে
- ১০. CI/CD for models
- ১১. Experiment: drift বানিয়ে দেখা
- ১২. বাংলাদেশের বাস্তব প্রসঙ্গ
- ১৩. AI Engineer perspective
- ১৪. Boss Question
- ১৫. Job Requirement Decoder: "model monitoring / drift"
- ১৬. সাধারণ ভুল
- ১৭. Interview Prep
- ১৮. হাতে-কলমে
- ১৯. Project Connection ও পরের পর্ব
🎬 ১. গল্প: "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 monitoring | service ঠিক চলছে কিনা | latency, error rate, CPU/RAM, request/sec, uptime |
| Model monitoring | prediction ঠিক আছে কিনা | 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। কখন?
- Scheduled — নির্দিষ্ট সময় পর পর (যেমন প্রতি মাসে), যদি data নিয়মিত বদলায়।
- Triggered — drift বা performance drop ধরা পড়লে তখনই 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 বানিয়ে দেখা
- তোমার churn model-এর test data-র একটা feature কৃত্রিমভাবে বদলে দাও (যেমন সব
tenure-এ +24 যোগ করো)।
- এই বদলানো data-য় accuracy মাপো — পড়ে যাবে (এটাই drift-এর প্রভাব)।
- উপরের KS test চালিয়ে দেখো 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"
- কী বোঝায়? deploy করা model-এর health/performance নজরে রাখা, drift ধরা, দরকারে
retrain ও automated deploy।
- কেন চায়? model সময়ের সাথে খারাপ হয়; না ধরলে চুপচাপ ভুল সিদ্ধান্ত → business ক্ষতি।
- কোন সমস্যা সমাধান করে? "silent model failure" — crash ছাড়াই ভুল হওয়া।
- Junior-এর কী জানা লাগে? system vs model monitoring, drift (data/concept)-এর ধারণা,
prediction logging, retraining কখন।
- এখনই কী master লাগে না? Prometheus/Grafana/Evidently dashboard বানানো, automated
retraining pipeline, full ML CI/CD — পরে।
- GitHub-এ কীভাবে দেখাবে? prediction logging কোড + একটা simple drift-check script +
README-তে "কীভাবে drift ধরব ও retrain করব"।
- 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) হবে।