Modelul tau ML va muri in productie. Iata cum sa il opresti.

Ai livrat modelul. Si acum?

Modelul tau a obtinut 94% accuracy in notebook. Demo-ul a mers grozav. Stakeholder-ii au aplaudat. L-ai facut deploy vineri dupa-amiaza pentru ca te simteai curajos.

Trei saptamani mai tarziu, conversia a scazut cu 12% si nimeni nu a facut legatura cu modelul. Echipa de frauda a observat o crestere a negativelor false o luna mai tarziu. Pana atunci, modelul fusese gresit in liniste timp de sase saptamani.

Nu e un scenariu ipotetic. Conform unui studiu Gartner, aproximativ jumatate din modelele AI nu ajung niciodata in productie. Dar cele care ajung se confrunta cu o soarta mai rea: se degradeaza in liniste, iar echipele afla abia cand paguba de business e deja facuta. Cercetarea DataRobot a descoperit ca 67% din enterprise-uri au raportat probleme critice ale modelelor care au ramas neobservate mai mult de o luna.

Zillow a invatat asta pe pielea lor. Algoritmul lor de pricing, Zestimate, a fost antrenat pe o piata imobiliara relativ stabila. Cand volatilitatea din era pandemiei a lovit, modelul a continuat sa supraevalueze proprietatile. Zillow a cumparat mii de locuinte supraevaluate inainte ca cineva sa traga frana. Rezultatul: $421 milioane pierderi intr-un singur trimestru, 25% din angajati concediati si o scadere de $8 miliarde in capitalizarea de piata.

Modelul a functionat. Pana cand nu a mai functionat.

De ce se strica modelele: drift-ul este garantat

Daca produsul tau se schimba, utilizatorii se schimba, competitorii se schimba, exista sezonalitate sau pipeline-urile de date evolueaza - drift-ul nu este un risc. Este o certitudine.

Exista doua tipuri care omoara modelele:

Data drift se intampla cand distributia features de intrare se schimba. Un model de underwriting pentru credite, antrenat pe pattern-uri de venituri pre-pandemie, intalneste distributii de angajare complet diferite in 2025. Features (niveluri de venit, categorii de job, utilizare credit) se deplaseaza statistic fata de ce a invatat modelul. Predictiile devin nesigure, dar nu se arunca nicio eroare.

Concept drift se intampla cand relatia dintre intrari si iesiri se schimba. Un model de recomandari de continut care a invatat ca "utilizatorii care cauta remote work vor oferte de munca" descopera brusc ca in 2026, aceeasi cautare inseamna "instrumente de productivitate pentru munca remote." Intrarile arata la fel. Iesirea corecta s-a schimbat. Modelul nu are cum sa stie.

Ambele tipuri au o proprietate comuna: modelul nu se blocheaza. Nu arunca exceptii. Pur si simplu devine mai rau, incet, in moduri care sunt invizibile daca nu urmaresti metrici specifice.

Cum arata monitorizarea in practica

Majoritatea echipelor cred ca "monitorizare" inseamna sa verifici daca API-ul returneaza 200. Asta prinde defectiuni de infrastructura. Nu prinde niciuna din defectiunile ML.

Monitorizarea ML reala are trei niveluri:

Nivelul 1: Calitate date si tracking distributie. Inainte ca modelul sa ruleze, verifica daca intrarile corespund cu ce asteapta modelul. Urmareste distributiile features cu teste statistice (Population Stability Index, Kolmogorov-Smirnov). Daca feature-ul tau "varsta" are brusc 40% valori null pentru ca un pipeline upstream s-a stricat, vrei sa stii inainte ca modelul sa produca predictii inutile.

Instrumente care se ocupa de asta: Evidently AI (open source, bun pentru date tabulare si text), whylogs (logare usoara de date), Deepchecks (suite de validare). Toate trei sunt open source.

Nivelul 2: Monitorizare predictii. Urmareste distributia iesirilor modelului in timp. Daca clasificatorul tau binar prezice brusc "pozitiv" pentru 80% din intrari cand rata istorica era 30%, ceva e gresit. Nu ai nevoie de label-uri ground truth pentru asta. Doar urmareste predictiile.

O abordare simpla:

import numpy as np
from scipy import stats
 
def check_prediction_drift(reference_preds, current_preds, threshold=0.05):
    """Test KS pe distributii de predictii. Returneaza True daca drift detectat."""
    statistic, p_value = stats.ks_2samp(reference_preds, current_preds)
    return p_value < threshold, statistic, p_value
 
# Ruleaza zilnic fata de fereastra ta de referinta
ref = load_predictions(window="2026-02-01", days=30)
current = load_predictions(window="2026-03-15", days=7)
drifted, stat, pval = check_prediction_drift(ref, current)
if drifted:
    alert(f"Prediction drift detected: KS={stat:.3f}, p={pval:.4f}")

Nivelul 3: Corelatie metrici business. Conecteaza predictiile modelului la rezultatele business downstream. Daca conversia scade, este corelata cu o schimbare in scorurile de incredere ale modelului? Aici se opresc majoritatea echipelor pentru ca necesita coordonare intre echipe. Dar aici este si valoarea reala.

Stiva de monitorizare nu trebuie sa fie complexa. Un setup Prometheus/Grafana cu metrici custom pentru distributii de features si statistici de predictie te duce 80% din drum. Cei 20% care lipsesc sunt disciplina: cineva trebuie sa se uite la dashboard-uri si sa actioneze pe alerte.

Aspectul reglementar pe care majoritatea echipelor il ignora

Daca modelul tau ML opereaza in UE si se califica drept high-risk conform EU AI Act, monitorizarea nu este optionala. Este lege.

Articolul 72 cere furnizorilor de sisteme AI high-risk sa stabileasca un sistem de monitorizare post-comercializare care colecteaza activ si analizeaza date de performanta pe intreaga durata de viata a sistemului. Articolul 15 cere ca sistemele high-risk sa "atinga un nivel adecvat de acuratete, robustetea si securitate cibernetica" si sa "functioneze in mod consistent pe intreaga durata a ciclului lor de viata."

Ultima parte - "functioneze in mod consistent pe intreaga durata a ciclului lor de viata" - este UE care iti spune sa detectezi drift-ul.

Regulamentul abordeaza si specific buclele de feedback: sistemele care continua sa invete dupa deployment trebuie proiectate sa "elimine sau reduca riscul ca iesirile posibil biasate sa influenteze intrarile pentru operatiuni viitoare." Daca motorul tau de recomandari isi intareste propriile bias-uri pentru ca nimeni nu monitorizeaza ciclul de feedback, asta este o problema de conformitate.

Suprapunerea practica intre MLOps bun si conformitate EU AI Act este aproape totala:

| Buna practica MLOps | Cerinta EU AI Act | |---|---| | Monitorizare calitate date | Art. 10 (guvernanta datelor) | | Detectie drift | Art. 15 (acuratete pe intreaga durata de viata) | | Versionare model si lineage | Art. 11 (documentatie tehnica) | | Dashboard-uri performanta | Art. 72 (plan monitorizare post-comercializare) | | Raspuns la incidente pentru defectiuni model | Art. 73 (raportare incidente grave) | | Monitorizare bias | Art. 15 (prevenire bucle de feedback) |

Companiile care deja ruleaza MLOps corect sunt 80% conforme cu cerintele de monitorizare. Companiile care sar peste monitorizare vor trebui sa construiasca totul de la zero cand termenele de conformitate vin.

Incepe cu aceste trei lucruri

Daca modelele tale sunt in productie fara monitorizare astazi, nu incerca sa construiesti o platforma completa de observabilitate. Incepe mic:

1. Logheaza fiecare predictie. Nu doar output-ul, ci features de intrare, versiunea modelului, timestamp-ul si scorul de incredere. Stocheaza intr-un loc unde poti face query. Costa aproape nimic si iti da datele pentru tot restul.

2. Seteaza o singura alerta de drift. Alege cel mai important feature al tau. Calculeaza un PSI sau KS statistic rulant fata de distributia de antrenare. Alerteaza cand trece un prag. Un feature, o alerta. Extinde de acolo.

3. Urmareste o metrica business corelata cu performanta modelului. Alege metrica pe care modelul tau ar trebui sa o imbunatateasca (conversie, rata de frauda, churn). Pune-o pe grafic alaturi de distributiile de incredere ale modelului pe acelasi dashboard. Cand divergeaza, investigheaza.

Acesti trei pasi ii ia unui inginer ML senior cam o saptamana sa ii implementeze. Sa ii sariti si sa speri ca modelul ramane acurat pentru totdeauna - asa devii urmatorul Zillow.

Am fost acolo

La DeviDevs, construim platforme ML unde monitorizarea face parte din arhitectura din prima zi, nu un add-on lipit dupa primul incident. De asemenea ajutam echipele sa isi dea seama care din modelele lor se califica drept high-risk conform EU AI Act, pentru ca cerintele de monitorizare pentru conformitate sunt aceleasi care previn defectiunile in productie.

Daca modelele tale ruleaza fara monitorizare, nu e o chestiune de daca se vor strica. E o chestiune de cand vei observa.

Despre DeviDevs: Construim platforme ML, securizam sisteme AI si ajutam companiile sa fie conforme cu EU AI Act. devidevs.com