ML System Lifecycle
- ●একটি ML system শুধু model train করা নয় — data collection থেকে monitoring পর্যন্ত একটি পূর্ণ lifecycle।
- ●Offline (training) আর online (serving) দুটি আলাদা জগৎ, আর এদের মাঝে inconsistency থেকে train/serve skew তৈরি হয়।
- ●সাধারণ software-এ logic ফিক্সড থাকে, কিন্তু ML system-এ data বদলালেই behavior বদলে যায় — তাই monitoring অপরিহার্য।
সমস্যাটা কী?
ধরো তুমি একটা e-commerce সাইট বানাচ্ছ, আর তোমাকে বলা হলো "একটা model বানাও যেটা predict করবে কোন user কোন product কিনবে।" নতুন developer-রা প্রায়ই ভাবে কাজটা মানে শুধু একটা Jupyter notebook খুলে কিছু data নিয়ে model.fit() চালানো। কিন্তু বাস্তবে সেই notebook-টা পুরো গল্পের মাত্র ১০ শতাংশ।
আসল চ্যালেঞ্জ হলো — data কোথা থেকে আসবে, কীভাবে পরিষ্কার হবে, model কীভাবে production-এ যাবে, প্রতিদিন কোটি কোটি request কীভাবে handle করবে, আর কয়েক মাস পর model-টা যখন "বুড়ো" হয়ে যাবে তখন কী হবে। এই পুরো চক্রটাই হলো ML System Lifecycle। এটা বুঝতে না পারলে model ভালো হলেও system fail করে।
মূল ধারণা
ML System Lifecycle হলো সেই ধারাবাহিক ধাপগুলো — data collection → feature engineering → training → evaluation → deployment → monitoring — যেগুলোর মাধ্যমে একটি machine learning model ধারণা থেকে production-এ স্থায়ীভাবে চলতে থাকে।
মূল কথাটা হলো: ML system একটা জীবন্ত system, একবার বানিয়ে ছেড়ে দেওয়ার জিনিস নয়। সাধারণ software-এ তুমি যে rule লিখে দাও সেটা একইভাবে বছরের পর বছর চলে — if (age > 18) কখনো নিজে থেকে বদলায় না। কিন্তু ML model শেখে data থেকে। আর পৃথিবীর data প্রতিদিন বদলায়: নতুন product আসে, user-দের পছন্দ বদলায়, ঈদের সময় কেনাকাটার pattern সম্পূর্ণ ভিন্ন হয়ে যায়। তাই lifecycle-টা একটা লুপ — শেষ ধাপ (monitoring) থেকে আবার প্রথম ধাপে (নতুন data দিয়ে retraining) ফিরে আসে।
কীভাবে কাজ করে
ছয়টি মূল ধাপ
প্রতিটি ধাপের একটা স্পষ্ট দায়িত্ব আছে:
| ধাপ | কী করে | উদাহরণ |
|---|---|---|
| Data Collection | raw data জোগাড় ও সংরক্ষণ | user-এর click, order, search log |
| Feature Engineering | raw data থেকে model-উপযোগী signal বানানো | "গত ৭ দিনে কতবার কিনেছে" |
| Training | data থেকে model parameter শেখা | gradient descent দিয়ে weight শেখা |
| Evaluation | model কতটা ভালো তা যাচাই | precision, recall, AUC মাপা |
| Deployment | model-কে production-এ সেবা দিতে বসানো | REST API হিসেবে serve করা |
| Monitoring | চলন্ত অবস্থায় নজরদারি | accuracy drop, latency, drift |
Offline vs Online
এটা সবচেয়ে গুরুত্বপূর্ণ পার্থক্য। ML system-এর দুটো ভিন্ন "জগৎ" থাকে:
- Offline (training জগৎ): এখানে বড় batch data নিয়ে ধীরে-সুস্থে কাজ হয়। সময় বেশি লাগলেও সমস্যা নেই, GPU ঘণ্টার পর ঘণ্টা চলতে পারে। লক্ষ্য — সবচেয়ে ভালো model বানানো।
- Online (serving জগৎ): এখানে real-time-এ একটা একটা request আসে, আর কয়েক মিলিসেকেন্ডে উত্তর দিতে হয়। লক্ষ্য — দ্রুত আর নির্ভরযোগ্য prediction।
| বিষয় | Offline | Online |
|---|---|---|
| Data | বিশাল batch | একটা request |
| Latency | মিনিট/ঘণ্টা চলে | মিলিসেকেন্ড লাগে |
| লক্ষ্য | সেরা model শেখা | দ্রুত উত্তর দেওয়া |
| পরিবেশ | training cluster | production server |
Train/Serve Skew
যখন training-এর সময় feature compute করার logic আর serving-এর সময়ের logic আলাদা হয়, তখন একই input-এ model আলাদা ফল দেয়। একে বলে train/serve skew। যেমন — training-এ তুমি দাম "টাকায়" রাখলে, কিন্তু serving-এ ভুলবশত "ডলারে" পাঠালে model বিভ্রান্ত হবে। এটাই ML system-এর সবচেয়ে কুখ্যাত bug।
ভাবো একটা রেস্টুরেন্টের শেফ-কে (model) তুমি প্রশিক্ষণ দিচ্ছ। অনুশীলনের সময় সব সবজি আগে থেকে কেটে, মেপে, ধুয়ে তার সামনে রাখা হলো (offline feature)। কিন্তু আসল রাতে customer যখন order দিল (online), রান্নাঘরে সবজি না-কাটা, না-মাপা অবস্থায় এলো। শেফ একই রান্নাও আর সেই স্বাদে দিতে পারবে না — কারণ প্রশিক্ষণের পরিবেশ আর আসল পরিবেশ আলাদা হয়ে গেল। এটাই train/serve skew।
প্রকারভেদ
ML lifecycle-এর pipeline মূলত দুই ধরনের হয়:
- Batch pipeline: নির্দিষ্ট সময় পরপর (যেমন প্রতি রাতে) পুরো data নিয়ে retrain বা prediction চলে। সহজ, কম খরচ, কিন্তু freshness কম।
- Streaming/Online pipeline: data আসা মাত্রই process হয়, feature প্রায় real-time-এ update হয়। জটিল ও ব্যয়বহুল, কিন্তু সবসময় তাজা।
আবার deployment কৌশলেও ভাগ আছে — shadow deployment (নতুন model চুপচাপ চলে, কিন্তু উত্তর user-কে দেখানো হয় না), canary (অল্প traffic-এ পরীক্ষা), আর A/B test (দুই model তুলনা)।
কখন ব্যবহার করবে / করবে না
পূর্ণ ML lifecycle তখনই গড়বে যখন:
- সমস্যাটা data থেকে pattern শেখার মতো (যেমন recommendation, fraud detection)।
- data নিয়মিত বদলায়, তাই retraining দরকার।
- ভুল prediction-এর একটা সহনীয় সীমা আছে।
ML লাগবে না যখন:
- সহজ business rule দিয়েই কাজ চলে (
if amount > 100000 then flag— এর জন্য model লাগে না)। - পর্যাপ্ত quality data নেই।
সবচেয়ে বড় ভুল হলো model-কে "একবার deploy করেই কাজ শেষ" ভাবা। Production-এ data ধীরে ধীরে বদলায় (data drift), ফলে যে model আজ ৯০% accurate, ছয় মাস পর সেটা ৭০%-এ নামতে পারে — অথচ কোনো error log দেখা যাবে না। Monitoring ছাড়া এই নীরব ক্ষয় ধরা অসম্ভব।
বাস্তব উদাহরণ
Netflix-এর কথা ধরো। তাদের recommendation system প্রতি রাতে কোটি কোটি viewing record নিয়ে offline-এ feature বানায় ও model retrain করে। কিন্তু তুমি যখন app খোলো, তখন কয়েক মিলিসেকেন্ডে online serving system সেই pre-computed feature আর live signal (এখন কী দেখছ) মিলিয়ে তোমার homepage সাজায়।
তারা train/serve skew এড়াতে একই feature transformation code training আর serving — দুই জায়গায় শেয়ার করে। আর প্রতিটি নতুন model production-এ পাঠানোর আগে shadow mode-এ চালিয়ে দেখে আসল model-এর সাথে কতটা মেলে। এই পুরো লুপ — log জমা → feature → train → evaluate → deploy → monitor → আবার নতুন log — নিরবচ্ছিন্নভাবে ঘুরতে থাকে। এটাই একটা পরিণত ML lifecycle-এর চেহারা।
Interview-এ যখন "design a ML system" জিজ্ঞেস করবে, কখনোই সরাসরি model architecture দিয়ে শুরু করো না। আগে পুরো lifecycle এঁকে দাও — data source, feature pipeline, training, evaluation metric, serving, আর সবচেয়ে গুরুত্বপূর্ণ monitoring + retraining loop। তারপর train/serve skew কীভাবে এড়াবে সেটা উল্লেখ করলে interviewer বুঝবে তুমি production ML বোঝো, শুধু notebook ML নয়।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Train/serve skew সাধারণত কেন হয়?
2. সাধারণ software আর ML system-এর মূল পার্থক্য কোনটি?
3. Model deploy করার পরও monitoring কেন দরকার?