Modelul tău ML nu are plan de rollback. Repară-l înainte de 3 dimineața

Ai pus un model în producție. Îl poți scoate?

Un scenariu care se întâmplă mai des decât recunoaște oricine: echipa ta de ML antrenează un nou model de recomandări. Metricile arată excelent în notebook. Testul A/B din staging a fost promițător. Îl pui în producție marți după-amiază. Miercuri la 3 dimineața, conversia a scăzut cu 12%, iar inginerul de gardă se uită la un dashboard Grafana și se întreabă ce versiune de model rulează, de fapt.

Potrivit analizei VentureBeat, citată pe scară largă, aproximativ 87% din proiectele de ML nu ajung niciodată în producție. Dar proiectele care AJUNG au o altă problemă: sunt puse în producție fără un plan pentru ce se întâmplă când lucrurile merg prost. Un articol MarkTechPost din martie 2026 a constatat că cele mai multe echipe de ML din producție încă tratează lansarea unui model ca pe lansarea unui software. Îl dai drumul și speri să fie bine. Diferența e că un deploy de software stricat de obicei cade vizibil. Un deploy de model stricat se degradează în tăcere.

Lansarea unui model ML nu e același lucru cu publicarea unui nou endpoint de API. Modelele cedează fără zgomot. Acuratețea derivă. Distribuțiile de feature-uri se mută. Iar dacă strategia ta de rollback e „intru cu SSH pe server și schimb fișierul modelului", ești deja cu ore în urmă.

Trei strategii de deploy care chiar funcționează

Există patru abordări obișnuite pentru lansarea sigură a modelelor ML: canary, shadow, blue-green și testarea A/B. Primele trei țin de siguranță. Testarea A/B ține de învățare. Dacă nu folosești măcar una dintre strategiile de siguranță, dai cu zarul în producție.

1. Canary: testul pe 5%

Un deploy canary trimite un procent mic din traficul de producție spre noul model, iar modelul vechi preia restul. Dacă noul model se comportă bine, crești traficul treptat. Dacă se strică ceva, trimiți totul înapoi la modelul vechi.

Pe Kubernetes, Argo Rollouts face asta simplu. Iată o configurație minimă pentru un canary de servire a modelului:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: recommendation-model
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: {duration: 30m}
        - setWeight: 20
        - pause: {duration: 1h}
        - setWeight: 50
        - pause: {duration: 2h}
      analysis:
        templates:
          - templateName: model-accuracy-check
        startingStep: 1
        args:
          - name: model-version
            value: "{{templates.recommendation-model.podTemplateHash}}"
  selector:
    matchLabels:
      app: recommendation-model
  template:
    metadata:
      labels:
        app: recommendation-model
    spec:
      containers:
        - name: model-server
          image: registry.example.com/rec-model:v2.3
          ports:
            - containerPort: 8080

Partea esențială e secțiunea analysis. Argo Rollouts poate interoga Prometheus, Datadog sau orice furnizor de metrici ca să decidă automat dacă promovează noua versiune sau face rollback. Dacă latența predicțiilor sare sau acuratețea scade sub un prag, rolloutul se oprește și revine. Nu e nevoie de niciun om la 3 dimineața.

Pentru o analiză canary specifică ML, definești un AnalysisTemplate care verifică metrici la nivel de model:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: model-accuracy-check
spec:
  metrics:
    - name: prediction-latency-p99
      successCondition: result[0] < 200
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            histogram_quantile(0.99,
              sum(rate(model_predict_duration_seconds_bucket{
                model="recommendation",
                version="{{args.model-version}}"
              }[5m])) by (le)
            ) * 1000
    - name: error-rate
      successCondition: result[0] < 0.01
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(model_predict_errors_total{
              model="recommendation",
              version="{{args.model-version}}"
            }[10m]))
            /
            sum(rate(model_predict_requests_total{
              model="recommendation",
              version="{{args.model-version}}"
            }[10m]))

Începi cu 5% din trafic. Aștepți 30 de minute. Verifici metricile. Dacă totul e curat, treci la 20%. Așa pui un model în producție fără să pariezi firma pe un singur push.

2. Shadow: testezi fără risc

Un deploy shadow rulează noul model în paralel cu modelul de producție. Amândouă primesc aceleași cereri. Doar predicțiile modelului de producție ajung la utilizatori. Ieșirile modelului shadow se loghează ca să le compari.

E strategia cea mai sigură. Impact zero asupra utilizatorilor. Amazon SageMaker are testarea shadow inclusă, dar o poți implementa cu orice service mesh. Iată o configurație simplă de oglindire în Istio:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: recommendation-service
spec:
  hosts:
    - recommendation-service
  http:
    - route:
        - destination:
            host: recommendation-service
            subset: v1
          weight: 100
      mirror:
        host: recommendation-service
        subset: v2-shadow
      mirrorPercentage:
        value: 100.0

Capcana: deployurile shadow îți dublează costul de infrastructură pe durata testului. Rulezi două modele pe traficul de producție. Pentru cele mai multe echipe, 48-72 de ore de shadow dau destul semnal. Compari distribuțiile predicțiilor, profilurile de latență și ratele de eroare între v1 și v2. Dacă v2 arată bine, îl promovezi cu un rollout canary.

3. Blue-green: schimbarea instantanee

Blue-green ține două medii de producție identice. Unul e live (blue), celălalt e în așteptare (green). Pui noul model pe green, îl validezi, apoi muți traficul. Rollbackul înseamnă doar să muți înapoi pe blue.

E cea mai simplă strategie de rollback: o schimbare de DNS sau o actualizare a load balancerului și ești înapoi pe versiunea anterioară. Dezavantajul e costul. Întreții permanent infrastructura dublă.

Pentru ML, blue-green merge cel mai bine combinat cu InferenceService din KServe, care gestionează nativ versiunile modelelor:

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: recommendation-model
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
      storageUri: "s3://models/recommendation/v2.3"
    canaryTrafficPercent: 10

KServe gestionează împărțirea traficului și evidența versiunilor de model. Când pui canaryTrafficPercent pe 0 sau îl scoți, tot traficul merge pe ultima versiune stabilă. Dacă ai nevoie de rollback, îndrepți storageUri spre artefactul modelului anterior.

Rollbackul care durează secunde, nu ore

Firul comun al celor trei strategii: rollbackul e o schimbare de configurație, nu un nou deploy. Dacă rollbackul modelului cere reconstruirea unei imagini Docker, tragerea ei dintr-un registru și redeployul podului, o faci greșit. Cum spunea analiza Duckweave: „Dacă rollbackul cere redeployul serviciului, ești deja prea lent. Modelul stă într-un registru, cu digesturi fixate. Rollbackul devine: întorci politica, refaci pragul, fixezi modelul vechi. Secunde, nu ore."

Artefactele modelelor ar trebui versionate într-un registru de modele (MLflow, Vertex AI Model Registry sau chiar S3 cu versionare strictă). Stratul de servire ar trebui decuplat de pipeline-ul de antrenare. Când ceva merge prost, schimbi artefactul pe care îl încarcă serverul. Atât.

Cum abordează DeviDevs problema

Am văzut echipe care au pierdut zile de venituri pentru că „planul lor de rollback" era un fir pe Slack care începea cu „își mai amintește cineva ce model rula înainte?". Ajutăm firmele să-și construiască pipeline-uri de livrare progresivă pentru ML: analiză canary cu porți automate de promovare, testare shadow pentru actualizările de model cu risc mare și registre de modele care fac din rollback o operație de o linie.

Dacă echipa ta pune modele în producție fără rollback automat, ești la o predicție proastă distanță de o noapte foarte lungă. Am construit astfel de pipeline-uri pentru sisteme de recomandări, modele de detecție a fraudei și servicii NLP. Tiparele de infrastructură sunt aceleași. Liniștea merită costul de configurare.

Dacă construiești infrastructură de ML și vrei să faci deployul cum trebuie, vezi resursele noastre de MLOps și listele de verificare pentru conformitate, cu șabloane practice pe care le poți folosi de azi.

Ce înseamnă asta pentru echipa ta

Dacă reții un singur lucru din articol: separă artefactele modelelor de infrastructura de servire. Versionează tot. Automatizează declanșarea rollbackului. Scopul nu e zero incidente. Scopul e ca, atunci când apare un incident, revenirea să dureze secunde în loc de ore.

Începe cu canary. E schimbarea cu efortul cel mai mic și impactul cel mai mare pe care o poți face în pipeline-ul de deploy ML. Adaugă testare shadow pentru modelele cu miză mare. Treci la blue-green complet dacă bugetul îți permite.

Modelele tale se vor strica în producție. Întrebarea e dacă afli dintr-o alertă de monitorizare la 10 dimineața sau de la un VP furios la 3 dimineața.

Despre DeviDevs: construim platforme de ML și sisteme AI securizate și ajutăm firmele să se conformeze cu EU AI Act. devidevs.com