পাঠ ১ · ৩৩-এর মধ্যে · মডিউল ১
Home / AI Courses / MLOps / MLOps কী

MLOps কী, কেন দরকার

What is MLOps & why it matters
৬ মিনিট পড়া শুরু · Beginner Concept

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

  • MLOps-এর সংজ্ঞা — তিনটি ভিন্ন দৃষ্টিকোণে
  • Notebook ML বনাম production ML — মূল পার্থক্য কোথায়
  • "Hidden technical debt in ML systems" — Sculley et al. (২০১৫)-এর বিখ্যাত পেপারের মূল ধারণা
  • Model rot ও কেন একটি একবার-deploy করা মডেল যথেষ্ট নয়

১ · সমস্যাটা কোথায়

একজন data scientist Jupyter notebook-এ একটি দারুণ মডেল বানালেন — Bangla product review থেকে sentiment classify করে ৯২% accuracy দিচ্ছে। বস খুশি, demo সফল। তারপর প্রশ্ন: "এটা প্রোডাকশনে কীভাবে নিয়ে যাব?" — এখানেই বেশিরভাগ ML প্রজেক্ট থেমে যায়।

VentureBeat (২০১৯)-এর একটি জরিপে দেখা যায় — ৮৭% ML প্রজেক্ট কখনো production-এ পৌঁছায় না। যারা পৌঁছায় — তাদের অর্ধেক কয়েক মাসের মধ্যে ভেঙে পড়ে। কারণ — একটি মডেল চালু রাখা কেবল code deploy করা না; এটি data, infrastructure, monitoring, ও retraining-এর একটি সম্পূর্ণ system।

MLOps সংজ্ঞা

MLOps (Machine Learning Operations) হলো এমন practices, tools ও culture-এর সমষ্টি যা ML model-কে নির্ভরযোগ্যভাবে, পুনরাবৃত্তযোগ্যভাবে (reproducibly), ও দীর্ঘমেয়াদে production-এ চালু রাখে।

এটি তিনটি ক্ষেত্রের মিলন: ML (algorithm, training), DevOps (CI/CD, deployment, infra), ও Data Engineering (pipeline, versioning, quality)।

২ · Notebook ML বনাম Production ML

Notebook-এ একটি মডেল চালানো আর production-এ একই মডেল চালানো — দু'টো ভিন্ন জগৎ। নিচের তুলনাটা দেখুন।

  • Notebook: এক ব্যক্তি, এক laptop, এক static dataset, একবার চালানো, accuracy দেখানো — শেষ।
  • Production: অনেক ব্যবহারকারী, বহু server, প্রতি সেকেন্ডে নতুন data, ২৪×৭ চালু থাকতে হবে, ব্যর্থ হলে alert, version control, rollback ক্ষমতা।
ভাবুন — বাসায় একটি স্বাদের রান্না করা, আর সেই recipe নিয়ে ঢাকার একটি ৫০০-আসনের restaurant চালানো — দু'টো একদম আলাদা চ্যালেঞ্জ। উপাদান কেনা, hygiene, consistency, supply chain, staff training, customer feedback — সব কিছু সামলাতে হয়। MLOps হলো সেই restaurant চালানোর শিল্প — বাসার রান্না থেকে শুরু করে।

৩ · Hidden Technical Debt — Sculley (২০১৫)

Google-এর D. Sculley-এর নেতৃত্বে ২০১৫ সালে NeurIPS-এ প্রকাশিত একটি প্রভাবশালী পেপার — "Hidden Technical Debt in Machine Learning Systems" — দেখায় যে একটি real ML system-এ মডেল কোড কেবল ছোট একটা টুকরা। বাকিটা — সমস্ত technical debtTechnical Debtসফটওয়্যার system-এ এমন code/infrastructure যা দ্রুততার জন্য shortcut নেয়, পরে maintain করা ব্যয়বহুল হয়। ML-এ এটি বিশেষ রূপ পায় — data dependencies, glue code, configuration debt।।

পেপারের মূল চিত্রটি বিখ্যাত — মডেল কোডকে একটি ছোট কালো box হিসেবে দেখায়, চারপাশে data collection, feature extraction, configuration, monitoring, serving infrastructure, analysis tools — সবকিছু অনেক বড়। বার্তা স্পষ্ট: "ML system-এ মডেল ৫%, বাকি ৯৫% engineering।"

৪ · Model Rot — চুপচাপ মরে যাওয়া

একটি deploy করা মডেল সময়ের সাথে model rotModel Rot / Model Decayসময়ের সাথে production model-এর performance ক্ষয়। কারণ data drift (input distribution বদল), concept drift (input-output সম্পর্ক বদল), ও infrastructure পরিবর্তন।-এ পড়ে। কেন?

  • Data drift: ব্যবহারকারীর আচরণ বদলায়। ২০২০-এর pre-COVID e-commerce model ২০২১-এ মেলে না।
  • Concept drift: "fraud" কী — সেটাও বদলায়। অপরাধীরা নতুন pattern বের করে।
  • Upstream change: কোনো data source format বদলালে — মডেল চুপচাপ ভুল prediction দেয়, কেউ টের পায় না।
  • Library drift: NumPy/TensorFlow upgrade — সামান্য numerical পরিবর্তন, কিন্তু edge case-এ ভিন্ন output।
Model rot-এর সবচেয়ে বিপজ্জনক দিক — এটা silent। API ৫০০ error দেয় না, latency ঠিক থাকে, response আসে। কিন্তু prediction-এর মান ধীরে ধীরে কমতে থাকে — যতক্ষণ না কোনো ব্যবসায়িক সংখ্যা (revenue, fraud rate) সতর্ক করে।

৫ · MLOps যা সমাধান করে

একটি পরিপক্ব MLOps practice নিচের কাজগুলো নিশ্চিত করে:

  1. Reproducibility: একই code + একই data → একই model। যেকোনো সময়, যেকোনো মেশিনে।
  2. Versioning: code, data, model — তিনটিরই git-style history।
  3. Automation: data → train → test → deploy পর্যন্ত pipeline। মানুষের manual click ন্যূনতম।
  4. Monitoring: production-এ মডেল কেমন করছে — accuracy, latency, drift।
  5. Rollback: নতুন মডেল খারাপ পারফর্ম করলে — মুহূর্তে আগের version-এ ফিরে যাওয়া।
  6. Governance: "এই decision কে নিয়েছে?" — audit trail।
ML system — Sculley et al. (২০১৫) Model code is only 5% of a real ML system ML Code Data Collection ETL, cleaning, labeling Feature Extraction transforms, encoding Configuration hyperparams, infra Data Verification schema, quality Serving Infra API, batch, edge Monitoring drift, accuracy, alerts Process Mgmt workflows, on-call Analysis Tools debug, evaluation কেন্দ্রীয় ML কোড ছোট — চারপাশের সব infrastructure বিশাল
Sculley et al. (২০১৫) — একটি real ML system-এ মডেল কোড কেবল ছোট অংশ। MLOps সেই বাকি ৯৫% সামলায়।

৬ · প্রথম MLOps অভিজ্ঞতা — একটি সরল উদাহরণ

ধরা যাক আপনি একটি model train করেছেন। এখন এটি একটি API হিসেবে চালু করতে চান। নিচের কোডটি একটি minimal pattern দেখায় — এটি এখনো production-grade না, কিন্তু MLOps চিন্তার বীজ আছে।

Python · Minimal model API 
import joblib
from fastapi import FastAPI
from pydantic import BaseModel

# ১. Versioned model load — কোন মডেল চলছে তা log করি
MODEL_VERSION = "v1.3.0"
model = joblib.load(f"models/sentiment-{MODEL_VERSION}.joblib")

app = FastAPI()

class ReviewIn(BaseModel):
    text: str

@app.get("/healthz")
def health():
    return {"status": "ok", "model_version": MODEL_VERSION}

@app.post("/predict")
def predict(review: ReviewIn):
    # ২. Prediction + version trace — debug করতে সাহায্য করবে
    label = model.predict([review.text])[0]
    return {"label": label, "model_version": MODEL_VERSION}

    


    

      লক্ষ্য করুন — ৩টি MLOps চিন্তা ইতিমধ্যেই: MODEL_VERSION trace, /healthz endpoint, এবং response-এ version include। এই কোর্সে আমরা এর প্রতিটি অংশ সঠিকভাবে গড়ব।
    


    
৭ · MLOps শেখার pathway


    
এই কোর্সে ৩৩টি পাঠ — চারটি মডিউলে সাজানো:


    
    
      
  • মডিউল ১ (এই মডিউল): ভিত্তি — lifecycle, maturity, Docker, K8s।
    • 
      
  • মডিউল ২: Training pipeline — MLflow, DVC, Feast, Kubeflow।
    • 
      
  • মডিউল ৩: Deployment — FastAPI, Triton, CI/CD, A/B test।
    • 
      
  • মডিউল ৪: Monitoring + LLMOps — drift, Prometheus, prompts, cost।
    • 
    


    

      প্রতিটি পাঠ একটি pillar — কোনোটা skip করলে পরের পাঠে ছিদ্র থেকে যাবে। বিশেষত মডিউল ১ (Docker, K8s) — এই দু'টো ছাড়া পরের সব lesson জটিল হবে।
    


  


  

    
    
  


  

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

    
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।


    

      
        প্র ০১
        "Notebook ভালো ≠ production ভালো" — শীর্ষ ৫টি কারণ কী যেগুলোর জন্য একটি দারুণ notebook মডেল production-এ ব্যর্থ হয়?
      
      

        

          এই প্রশ্নটা MLOps-এর প্রাণ। Notebook-এর সাফল্য আর production-এর সাফল্যের মধ্যে অনেক ফাঁক আছে — যেগুলো সাধারণত দেখা যায় না যতক্ষণ না সমস্যা ঘটে।
        

        
(১) Training-serving skew:

        
    
          
  • Notebook-এ আপনি pandas-এ feature engineering করেন। Production-এ একই transformation Java/Go-তে rewrite হয়।
    • 
          
  • সামান্য ভিন্নতা (যেমন decimal precision, default missing value handling) — মডেল prediction পুরো বদলে দিতে পারে।
    • 
          
  • এটি MLOps-এর সবচেয়ে কুখ্যাত bug — Feature Store (Lesson 12)-এর জন্ম এই কারণে।
    • 
        

        
(২) Latency budget:

        
    
          
  • Notebook-এ ১ সেকেন্ড prediction = ঠিক আছে। Production-এ bKash payment fraud check-এ ৫০ms-এর বেশি নিলে UX ভেঙে যায়।
    • 
          
  • সমাধান — quantization (Lesson 20), Triton (Lesson 17), batching। Notebook-এ এসব দরকার পড়ে না।
    • 
        

        
(৩) Concurrent request handling:

        
    
          
  • Notebook = এক request, এক time। Production = প্রতি সেকেন্ডে হাজার request।
    • 
          
  • Thread safety, GPU memory contention, batching — notebook-এ অদৃশ্য।
    • 
        

        
(৪) Data drift over time:

        
    
          
  • Notebook static dataset-এ test হয়। Production data প্রতিদিন বদলায়।
    • 
          
  • Pathao-র "ride demand prediction" model COVID-এর সময় পুরো ভেঙে পড়েছিল — কারণ training data normal lockdown reflect করে না।
    • 
        

        
(৫) Operational concerns:

        
    
          
  • মডেল কোথায় deploy? কে on-call? কীভাবে rollback? কে retrain trigger করবে?
    • 
          
  • Notebook-এ এসব প্রশ্ন কেউ জিজ্ঞেস করে না — production-এ এগুলোই সবচেয়ে গুরুত্বপূর্ণ।
    • 
        

        

          মূল উপলব্ধি: Notebook মডেল = lab experiment। Production মডেল = একটি live service। দু'টোর সফলতার মাপকাঠি ভিন্ন — accuracy বনাম reliability + latency + cost + maintainability।
        

      

    


    

      
        প্র ০২
        একটি ছোট স্টার্টআপ (১০ জন)-এর কি MLOps দরকার, নাকি এটি শুধু বড় কোম্পানির জন্য? কখন invest করতে হয়, কখন overkill?
      
      

        

          এটা practical decision — অনেক স্টার্টআপ এই ভুলে অনেক টাকা ও সময় হারায়। উত্তর — "depends" — কিন্তু কয়েকটা stage-ভিত্তিক rule আছে।
        

        
Stage 1 — Single model, low traffic (১-২ ML engineer):

        
    
          
  • সরল: Git + একটি Dockerfile + একটি cloud VM (DigitalOcean, Vultr Bangladesh) + manual deploy।
    • 
          
  • MLflow সরল mode-এ tracking — sqlite backend, local file artifacts।
    • 
          
  • Heavy MLOps platform এই stage-এ overkill — সময় production model-এ দিন, infrastructure-এ না।
    • 
        

        
Stage 2 — Multiple models OR critical model (৩-১০ engineer):

        
    
          
  • এখনই MLOps invest শুরু। কারণ — একটি model retrain করতে ৩ ঘণ্টা লাগলে, সপ্তাহে ৫ বার retrain = ১৫ ঘণ্টা/সপ্তাহ developer time।
    • 
          
  • Tracking, registry, basic CI/CD — automation worth।
    • 
          
  • Drift monitoring — যদি model business-critical (fraud, recommendation)।
    • 
        

        
Stage 3 — ML platform team (১০+ engineer):

        
    
          
  • Full MLOps stack — feature store, K8s-based serving, A/B testing platform।
    • 
          
  • Self-service infra — যেন data scientists infra worry না করে শুধু model নিয়ে কাজ করে।
    • 
        

        
"Buy first, build later" নীতি:

        
    
          
  • Managed services (SageMaker, Vertex AI, Databricks) — অনেক MLOps চিন্তা নিজে নেয়।
    • 
          
  • স্টার্টআপ ১-২ বছর managed-এ থাকুন। ৫০% bill-এর চেয়ে বেশি হলে — তখন in-house platform বানানোর কথা ভাবুন।
    • 
        

        
কখন overkill:

        
    
          
  • একটি static model যা মাসে একবার update হয় — Kubeflow Pipelines unnecessary।
    • 
          
  • একটি batch-only model — full Triton + canary deployment overkill।
    • 
          
  • Internal tool, ১০০ requests/day — feature store overkill।
    • 
        

        

          মূল উপলব্ধি: MLOps maturity model-এর মূল ধারণা — যত বেশি model, যত বেশি team, যত বেশি risk — তত বেশি investment। ছোট স্টার্টআপ-এর জন্য "minimal MLOps" — version control + monitoring + reproducibility — যথেষ্ট। বাকি সব problem-driven।
        

      

    


    

      
        প্র ০৩
        MLOps team কেমন হওয়া উচিত? Data scientist, ML engineer, DevOps — কে কী করে? Bangladeshi tech কোম্পানিতে এই roles কীভাবে বিভক্ত?
      
      

        

          ML team structure-এর কোনো universal answer নেই — কোম্পানির size, maturity, ও domain-এর উপর নির্ভর। কিন্তু কিছু common pattern আছে।
        

        
(১) Pure roles (বড় কোম্পানি — Google, Meta-style):

        
    
          
  • Data Scientist: business problem → ML problem framing, exploratory analysis, model prototyping। SQL + Python + statistics।
    • 
          
  • ML Engineer: prototype → production code। Pipeline, feature engineering at scale, training infra।
    • 
          
  • MLOps / ML Platform Engineer: tooling, infrastructure, CI/CD, monitoring, serving systems।
    • 
          
  • Data Engineer: data pipeline, warehouse, lake, streaming।
    • 
          
  • Software Engineer (backend): API integration, business logic।
    • 
        

        
(২) Bangladeshi reality — মিশ্র roles:

        
    
          
  • একজন "ML Engineer" প্রায়ই data scientist + MLOps + sometimes data engineer-এর কাজ একসাথে করে।
    • 
          
  • bKash, Pathao, Daraz-এর senior team — ৫-১০ জনের ML group, এক-দু'জন বিশেষায়িত MLOps। বাকি সবাই full-stack ML।
    • 
          
  • স্টার্টআপ — সাধারণত একজনই সব করেন; এটাই বাস্তব, এতে দোষ নেই।
    • 
        

        
(৩) দায়িত্ব ভাগের একটি pragmatic mental model:

        
    
          
  • "Train" দায়িত্ব: data scientist + ML engineer। Notebook → trained model।
    • 
          
  • "Ship" দায়িত্ব: ML engineer + MLOps। Trained model → production API/batch।
    • 
          
  • "Run" দায়িত্ব: MLOps + on-call team। Production stability, incidents।
    • 
          
  • "Improve" দায়িত্ব: data scientist + product। A/B test, business metric review।
    • 
        

        
(৪) Organizational anti-patterns — যা এড়ানো উচিত:

        
    
          
  • "Throw over the wall" — DS notebook দেয়, MLOps "deploy কর" বলে শোনে। ফলাফল — broken integration, finger-pointing।
    • 
          
  • "MLOps as gatekeeper" — সব deployment-এ MLOps approval লাগে। Throughput কমে, frustration বাড়ে।
    • 
          
  • "Platform team without product team customer" — MLOps platform বানায় কিন্তু DS দল ব্যবহার করে না।
    • 
        

        
(৫) Bangladeshi context-এ পরামর্শ:

        
    
          
  • প্রথমে full-stack ML engineer hire — যে training + deployment দুটো করতে পারে।
    • 
          
  • Team ৫+ হলে — একজন dedicated MLOps/Platform engineer।
    • 
          
  • DevOps team থাকলে — তাদের ML-specific upskilling করুন (Docker → GPU Docker, K8s → GPU K8s, monitoring → drift)।
    • 
        

        

          মূল উপলব্ধি: "MLOps engineer" শব্দটা যেমন একটি title, তেমনি একটি responsibility set। কে এই কাজ করে — সেটা কোম্পানির আকার ও phase-এর প্রশ্ন। ছোট জায়গায় সবাই MLOps করে; বড় জায়গায় বিশেষজ্ঞ থাকে।
        

      

    


    

      
        প্র ০৪
        "MLOps না করার cost কত?" — একটি concrete scenario দিয়ে দেখান, যেখানে MLOps-এ invest না করায় ব্যবসা ক্ষতিগ্রস্ত হয়েছে।
      
      

        

          MLOps-এর ROI প্রায়ই abstract — "code quality উন্নত হয়", "deployment দ্রুত হয়"। কিন্তু সত্যিকার hidden cost-এর কয়েকটি ঘটনা দেখলে বোঝা যায়।
        

        
Scenario 1 — Daraz-style fraud detection silent failure:

        
    
          
  • একটি fraud detection model deploy হলো ২০২২-এ। Monitoring শুধু latency ও error rate-এ — accuracy নয়।
    • 
          
  • ৬ মাস পরে fraudster-রা নতুন pattern adopt করল। Model precision ৯২% → ৬৮%-এ namlo।
    • 
          
  • কেউ টের পেল না, কারণ alert শুধু infrastructure metric-এ।
    • 
          
  • Quarterly business review-এ দেখা গেল — chargeback ৩.৫× বেড়েছে। আনুমানিক ক্ষতি: ১.৫ কোটি BDT।
    • 
          
  • Drift monitoring (Lesson 25) থাকলে দু'সপ্তাহে ধরা পড়ত।
    • 
        

        
Scenario 2 — Untracked experiment loss:

        
    
          
  • একটি স্টার্টআপ-এর data scientist ৩ মাস ধরে ৪০টি experiment run করেছেন। কিছু hyperparameter excellent ছিল, ৯১% accuracy।
    • 
          
  • Notebook হারিয়ে গেছে (laptop crash, no MLflow)।
    • 
          
  • মডেল reproduce করতে আবার ৩ সপ্তাহ। Salary-cost: ৩ লাখ BDT। Plus opportunity cost।
    • 
          
  • MLflow tracking (Lesson 8) — এই scenario-তে valuation চমৎকার।
    • 
        

        
Scenario 3 — Training-serving skew:

        
    
          
  • Recommendation model training-এ feature normalize হয়, serving-এ ভুলে raw value পাঠানো হয়।
    • 
          
  • Click-through rate ৮% → ৫.২%-এ namlo। কিন্তু "model latency ঠিক" — তাই কেউ alert পেল না।
    • 
          
  • ২ মাস পর A/B test analysis-এ ধরা পড়ল।
    • 
          
  • Feature Store (Lesson 12) থাকলে — single source of truth, এই bug অসম্ভব।
    • 
        

        
Scenario 4 — Manual deployment mistake:

        
    
          
  • Engineer SSH করে server-এ ঢুকে নতুন model file copy করল। কিন্তু dependency mismatch — Python 3.9 vs 3.11।
    • 
          
  • Service ক্রাশ। ৪৫ মিনিট outage।
    • 
          
  • একটি payment service-এ ৪৫ মিনিট = কোটি টাকার ক্ষতি (Bangladeshi context-এ Eid-এর সময় বিশেষ)।
    • 
          
  • CI/CD + canary (Lesson 21, 22) থাকলে detect হত pre-production-এ।
    • 
        

        
"Cost of NOT doing MLOps" calculator:

        
    
          
  • Average time-to-debug একটি ML production issue ছাড়া MLOps: ৮-১২ ঘণ্টা।
    • 
          
  • সঙ্গে: ১-২ ঘণ্টা (proper logging, version traceability)।
    • 
          
  • ৫ engineer × ১০ incident/year × ৬ ঘণ্টা savings = ৩০০ ঘণ্টা/বছর = ~১৫ লাখ BDT।
    • 
        

        

          মূল উপলব্ধি: MLOps cost সাধারণত prevent করা ক্ষতির চেয়ে অনেক ছোট — কিন্তু "প্রতিরোধ" দেখা যায় না, "ঘটনা" দেখা যায়। তাই business case তৈরিতে — actual incident থেকে hour-cost calculate করুন। এটাই সবচেয়ে effective argument।
        

      

    

  


  

    
 অনুশীলন

    
    
      
  1. 
        সংজ্ঞা: নিজের ভাষায় MLOps-এর ৩-বাক্যের সংজ্ঞা লিখুন। DevOps-এর সাথে কোথায় মিল, কোথায় ভিন্নতা — উল্লেখ করুন।
        
    
          
          
    
            
    
              নমুনা উত্তর: "MLOps হলো ML model-কে নির্ভরযোগ্যভাবে production-এ চালু রাখার practices ও tools-এর সমষ্টি। এটি DevOps-এর ধারণা (CI/CD, automation, monitoring) ML-এ প্রসারিত করে — কিন্তু code-এর পাশাপাশি data ও model-ও version, test, ও monitor করতে হয়। DevOps-এর সাথে মূল পার্থক্য — ML system-এ data ও model behavior সময়ের সাথে স্বাধীনভাবে বদলায়, তাই continuous retraining ও drift monitoring অতিরিক্ত responsibility।"
            
    
          
    
        
    
      
    2. 

      
  2. 
        চিন্তা: আপনার পরিচিত একটি Bangladeshi product/service (e.g., Pathao, bKash, Foodpanda) যেখানে ML ব্যবহৃত হয়। একটি model failure scenario ভাবুন এবং MLOps-এর কোন অংশ সেটা prevent করত — লিখুন।
        
    
          
          
    
            
    
              নমুনা: Foodpanda-র "delivery time prediction" model। বৃষ্টির দিনে accuracy দ্রুত কমে। MLOps সমাধান —
            
    
            
      
              
    • Drift monitoring (PSI on weather feature) — alert।
      • 
              
    • Conditional retraining — যদি drift > threshold।
      • 
              
    • Multi-model strategy — normal vs rainy day classifier।
      • 
              
    • A/B test framework — নতুন model deploy এর আগে।
      • 
            
    
          
    
        
    
      
    3. 

      
  3. 
        হিসাব: ধরা যাক আপনার team ৫ জন ML engineer। প্রতি বছরে গড়ে ১০টি production incident, প্রতিটিতে গড়ে ৬ ঘণ্টা debugging। Engineer-এর hourly cost ১,০০০ BDT। MLOps invest করে যদি প্রতি incident-এর debug time ২ ঘণ্টায় নামিয়ে আনা যায় — বার্ষিক savings কত?
        
    
          
          
    
            
    
              হিসাব:
            
    
            
      
              
    • Time saved per incident: ৬ − ২ = ৪ ঘণ্টা।
      • 
              
    • Total incidents/year: ১০ (per engineer assumption সরল রাখি — ১০ overall)।
      • 
              
    • Cost saved per incident: ৪ × ১,০০০ = ৪,০০০ BDT।
      • 
              
    • Annual savings: ১০ × ৪,০০০ = ৪০,০০০ BDT (একটি ছোট estimate)।
      • 
              
    • যদি ৫ জন engineer প্রত্যেকে নিজস্ব incident handle করে — ৫× = ২ লাখ BDT/বছর।
      • 
            
    
            
    
              এর সাথে অগণিত "near-miss"-ও যোগ হয় যেগুলো monitoring না থাকলে প্রকাশ পেত না।
            
    
          
    
        
    
      
    4. 
    

  


  

    
 আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

    

    

      Sculley et al. (২০১৫) পেপারটি পড়তে চান? Google-এ "Hidden Technical Debt in Machine Learning Systems" search করুন — NeurIPS-এর full PDF ফ্রি পাওয়া যায়।
    

  







  
  
     এই পাঠে ভুল পেয়েছেন? জানান
  





  
    
 কোর্সে ফিরে যান

    
MLOps কোর্সের সূচি