MLOps: De la Notebook la Producție Matură

Codul de antrenare este doar o mică parte dintr-un sistem ML real; restul este infrastructură: colectare și validare de date, serving, monitorizare. După această lecție vei putea evalua nivelul de maturitate MLOps al unei organizații, vei măsura progresul cu metricile DORA adaptate pentru ML și vei recunoaște anti-pattern-urile care blochează drumul de la notebook la producție. Afli și ce schimbă LLMOps și EU AI Act pentru pipeline-urile ML.

Introducere: De ce MLOps contează mai mult ca niciodată

Majoritatea organizațiilor enterprise au deja cel puțin un model ML în producție. Doar o minoritate îl țin cu adevărat sub control. Între aceste două realități încape tot ce doare în Machine Learning aplicat: modele care se degradează în tăcere, drift nedetectat până când un client reclamă, incidente de producție pe care nimeni nu le vede venind. În 2026, ML nu mai este un experiment de laborator, ci infrastructură critică — iar discrepanța dintre a rula un model și a rula un pipeline MLOps matur (nivel 2 sau superior) generează costuri semnificative și pierderi de valoare, un decalaj recunoscut consecvent în studiile din industrie.

MLOps — Machine Learning Operations — reprezintă setul de practici, instrumente și principii culturale care permit livrarea fiabilă, reproductibilă și scalabilă a sistemelor ML în producție. Este echivalentul DevOps pentru machine learning, dar cu provocări suplimentare unice: date care se schimbă, modele care se degradează și pipeline-uri care sunt ordine de mărime mai complexe decât cele software tradiționale.

1. Datoria Tehnică Ascunsă în Sistemele ML

Paper-ul fondator: „Hidden Technical Debt in ML Systems"

În 2015, o echipă de la Google a publicat unul dintre cele mai influente paper-uri din domeniu: „Hidden Technical Debt in Machine Learning Systems" (Sculley et al.). Mesajul central este devastator de simplu:

┌─────────────────────────────────────────────────────┐
│              Sistem ML în Producție                  │
│                                                     │
│  ┌───────────────────────────────────────────────┐  │
│  │          Configuration                        │  │
│  ├───────────────────────────────────────────────┤  │
│  │      Data Collection & Verification           │  │
│  ├───────────────────────────────────────────────┤  │
│  │        Feature Extraction                     │  │
│  ├───────────────────────────────────────────────┤  │
│  │   ┌─────────────────────────┐                │  │
│  │   │  ML Code (cutie mică)  │                │  │
│  │   └─────────────────────────┘                │  │
│  ├───────────────────────────────────────────────┤  │
│  │     Serving Infrastructure                    │  │
│  ├───────────────────────────────────────────────┤  │
│  │     Monitoring & Testing                      │  │
│  ├───────────────────────────────────────────────┤  │
│  │   Process Management & Resource Mgmt          │  │
│  ├───────────────────────────────────────────────┤  │
│  │   Analysis Tools & ML Infrastructure          │  │
│  └───────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────┘

Codul de antrenare a modelului este doar o mică „cutie" în mijlocul unui sistem ML real. Restul — partea covârșitoare — este infrastructură: colectare date, validare, feature engineering, serving, monitorizare, configurare. (Figura originală din Sculley et al., 2015, este calitativă — lucrarea nu oferă procente per componentă; proporțiile exacte variază de la sistem la sistem.) Această realitate se menține și în 2026 — ba chiar s-a accentuat odată cu GenAI, unde prompt management, guardrails și evaluarea output-urilor adaugă straturi suplimentare.

Categorii de datorie tehnică ML