CI/CD pentru modele AI 2026: pipeline, testare, rollback

Un model care trece testele pe laptopul tău nu e un model gata de producție — e un model căruia nu i-a dat încă nimeni cu trafic real. CI/CD pentru modele AI înseamnă exact disciplina care lipsește de obicei între cele două: un pipeline care versionează model și date ca artefacte separate de cod, testează automat pe seturi de validare înainte de orice deploy, scoate modelul nou în fața traficului real în trepte controlate și știe, din construcție, cum se dă înapoi când ceva nu merge.

De ce pipeline-ul unui model nu e pipeline-ul unei aplicații obișnuite

Un pipeline CI/CD clasic rulează teste pe cod, construiește un artefact (un container, un binar) și îl promovează prin medii. Codul e determinist: aceeași sursă dă mereu același build. Pentru un model AI, construcția codului e doar jumătate din poveste — cealaltă jumătate e antrenarea, care produce un artefact nou (ponderile modelului) dintr-o combinație de cod, date și hiperparametri. Schimbă oricare dintre cele trei și obții un model diferit, chiar dacă fiecare pare, izolat, o modificare minoră.

De aici vin trei diferențe structurale față de CI/CD clasic:

1. Artefactul de promovat nu e codul, ci modelul antrenat — codul care l-a produs e doar o parte din ce trebuie versionat.
2. Testele nu verifică un comportament fix, ci compară metrici (precizie, F1, latență) pe un set de validare față de un prag și față de modelul curent din producție.
3. „Deploy" nu înseamnă doar a porni un proces nou — înseamnă, de obicei, a muta treptat trafic de la un model la altul, cu posibilitatea reală de regresie silențioasă (modelul răspunde, dar greșit).

Pipeline-ul MLOps complet — de la ingestia datelor până la retraining automat — e tratat pe larg în MLOps: De la Prototip la Producție, care acoperă toate cele șapte stadii ale ciclului de viață al unui model. Imaginea de ansamblu a acelui ciclu, cu stack-ul complet și modelul de maturitate, e descrisă în ghidul MLOps de la prototip la producție în 2026. Acest articol se oprește asupra unui singur segment din acel ciclu, cel mai des implementat greșit sau deloc: livrarea continuă — versionare, poarta de testare, staging/canary, rollout și rollback. Monitorizarea în producție și retraining-ul automat, tratate pe larg acolo, nu sunt reluate aici.

Cele trei artefacte pe care le versionezi: cod, date, model

Înainte de orice pipeline, ai nevoie de un răspuns clar la întrebarea „ce versiune de model rulează acum în producție, cu ce date a fost antrenat și cu ce cod?". Fără el, un incident de producție se transformă în arheologie.

Codul

Se versionează ca orice altă aplicație, cu Git. Diferența e că trebuie să poți lega fiecare rulare de antrenare de un commit exact (hash-ul), nu de o ramură care s-a schimbat între timp.

Datele

Datasetul de antrenare nu e static — crește, se corectează, se re-etichetează. Unelte precum DVC (Data Version Control) țin datele mari în afara Git-ului, dar versionate alături de cod, prin fișiere mici de tip pointer (.dvc, dvc.yaml) care trăiesc în același repo și trimit la conținutul real dintr-un storage extern (S3, GCS sau un server SSH). Așa poți reconstitui, pentru orice commit, exact ce date au stat la baza modelului.

Modelul: registry, nu fișier pe un server

Cea mai frecventă greșeală la echipele mici este tratarea modelului ca pe un fișier .pkl copiat manual pe server. Un model registry (MLflow Model Registry e cel mai răspândit open-source) rezolvă asta cu o structură formală: fiecare antrenare produce o versiune numerotată, iar versiunile primesc aliasuri — referințe denumite și mutabile către o anumită versiune, de exemplu champion pentru versiunea care servește trafic de producție. Promovarea unui model nou nu înseamnă să rescrii un fișier, ci să muți aliasul: models:/fraud-detector@champion indică automat spre noua versiune, iar rollback-ul înseamnă pur și simplu mutarea aliasului înapoi (MLflow Model Registry — Aliases).

Poarta de testare automată: ce oprește un model înainte să ajungă în staging

Înainte ca un pipeline să promoveze o versiune nouă, trebuie să treacă printr-o poartă automată — echivalentul testelor unitare din CI/CD clasic, dar centrată pe metrici, nu pe assert-uri exacte. Trei verificări sunt minimul rezonabil:

• Comparație cu modelul curent (champion vs. challenger). Versiunea nouă rulează pe același set de validare (golden set) ca versiunea din producție, iar pipeline-ul blochează promovarea dacă metrica principală (F1, AUC, RMSE, în funcție de problemă) scade sub un prag absolut sau se degradează față de champion cu mai mult decât o marjă acceptată.
• Validarea datelor de intrare, nu doar a modelului — o schimbare de schemă sau o distribuție deplasată în datele de antrenare poate produce un model „bun" pe hârtie, dar antrenat pe date corupte.
• Teste comportamentale țintite pe cazurile cunoscute ca fragile (sub-grupuri demografice, valori extreme, intrări adversariale simple) — nu doar media pe tot setul de validare, care poate ascunde o regresie concentrată pe un segment.

Cum se construiește efectiv un astfel de harness de evaluare — scoring exact match vs. LLM-as-a-judge, golden set, metrici operaționale — e tratat în detaliu în AI evals: cum evaluezi un model AI (LLM) în producție. Ce ne interesează aici e integrarea acelei evaluări ca poartă în pipeline, nu metodologia de scoring în sine: rezultatul evaluării trebuie să fie un cod de ieșire (pass/fail), nu un raport citit manual de cineva înainte de deploy.

Exemplu: un pipeline CI/CD pentru modele cu GitHub Actions

Mecanica de mai sus devine concretă în două workflow-uri separate. Primul rulează la fiecare pull request care modifică codul de antrenare sau pointerul către date, antrenează pe datele versionate și aplică poarta de testare:

# .github/workflows/evaluate-model.yml
name: Evaluate candidate model
on:
  pull_request:
    paths: ["training/**", "data/**.dvc"]

jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Train on versioned data
        run: python training/train.py --commit ${{ github.sha }}
      - name: Run offline eval against golden set
        run: |
          python eval/run_suite.py \
            --candidate runs:/latest \
            --baseline models:/fraud-detector@champion
      - name: Fail the job if below promotion threshold
        run: python eval/gate.py --min-f1 0.86 --max-regression 0.01

Al doilea workflow nu rulează automat — se declanșează manual (workflow_dispatch), după ce cineva a decis că versiunea candidată merită promovată, și e legat de un environment GitHub numit production:

# .github/workflows/promote-production.yml
name: Promote model to production
on:
  workflow_dispatch:
    inputs:
      model_version:
        required: true

jobs:
  promote:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Move the champion alias
        run: |
          python - <<'PY'
          from mlflow import MlflowClient
          MlflowClient().set_registered_model_alias(
              "fraud-detector", "champion", "${{ github.event.inputs.model_version }}"
          )
          PY
      - name: Start canary rollout (10% traffic)
        run: ./scripts/deploy_canary.sh --traffic 10

Legătura dintre environment: production și un om care apasă „aprobă" nu e cod, ci configurare: un environment GitHub poate avea reviewer-i obligatorii — până la șase persoane sau echipe, dintre care e nevoie de o singură aprobare ca job-ul să continue — plus opțiunea de a împiedica autoaprobarea de către persoana care a declanșat rularea, un temporizator de așteptare înainte ca job-ul să poată porni și restricții pe ce branch-uri sau tag-uri pot folosi environment-ul. Secretele din acel environment (de exemplu, credențialele către registry sau endpoint-ul de producție) nu sunt vizibile job-ului până nu trece de regulile de protecție (GitHub Docs — Using environments for deployment). E exact mecanismul prin care „cine aprobă promovarea în producție" încetează să mai fie o convenție verbală și devine o regulă aplicată de platformă.

Staging și canary: cum validezi cu trafic real fără să rupi producția

Trecerea testelor pe un set de validare static nu garantează comportamentul pe trafic real — distribuția cererilor live diferă mereu, cât de puțin, de orice set offline. De aici, trei pattern-uri de rollout, în ordinea crescătoare a riscului asumat:

Shadow deployment

Modelul nou primește o copie a traficului real, dar răspunsurile lui nu ajung niciodată la utilizator — sunt doar logate și comparate cu ce a răspuns modelul din producție. Risc zero pentru utilizator, cost dublu de infrastructură cât timp rulează ambele modele în paralel. E pasul potrivit când modelul candidat are o arhitectură foarte diferită de cea curentă și vrei încredere înainte de a-i da orice trafic real cu efect.

Canary: felii mici de trafic real, cu efect

Spre deosebire de shadow, într-un deployment canary modelul nou chiar răspunde unei felii din trafic. Amazon SageMaker expune asta explicit ca mod de traffic shifting pentru un endpoint: traficul se mută în două trepte — întâi o porțiune mică (fleet-ul „canary"), apoi restul — iar pe durata unei perioade de observare (baking period) pipeline-ul monitorizează alarme CloudWatch legate de fleet-ul nou; dacă vreo alarmă se declanșează, tot traficul revine automat la fleet-ul vechi (AWS — Blue/Green Deployments, SageMaker AI). Google Cloud oferă același concept la nivel de endpoint Vertex AI, prin împărțirea explicită a traficului între versiunile de model implementate — de exemplu, 20% către versiunea nouă și 80% către cea veche, crescând progresiv procentul pe măsură ce metricile confirmă stabilitatea (Google Cloud — Deploy a model by using the Vertex AI API).

Rollout gradual: trepte, nu un singur salt

Dincolo de canary (două trepte), SageMaker expune și un mod linear: o porțiune fixă de trafic se mută în N pași egali, fiecare urmat de propria perioadă de observare — mai lent și mai costisitor (ambele fleet-uri rulează mai mult timp în paralel), dar cu blast radius minim la fiecare pas (AWS, idem). Alegerea dintre „dintr-o dată", canary sau linear nu e o preferință de stil — e o decizie de cost vs. risc: cu cât modelul afectează decizii cu consecințe mai mari (credit scoring, triaj medical, moderare de conținut), cu atât mai multe trepte merită costul suplimentar.

Flag-urile de funcționalitate (de tipul celor din Unleash sau LaunchDarkly) sunt un al patrulea instrument, complementar, nu alternativ: în loc să controlezi procentul de trafic la nivelul infrastructurii de serving, controlezi la nivel de aplicație care segment de utilizatori (un cont de test, o companie dintr-un pilot, un procent aleatoriu) vede modelul nou — util mai ales când rollout-ul trebuie coordonat cu o decizie de produs, nu doar cu una tehnică.

Rollback: automat, manual, și cine apasă butonul

Rollback-ul nu e un „plan B" scris într-un document — e un cod de ieșire care face exact ce a făcut promovarea, în sens invers.

Rollback automat: alarme care trag frâna

În modelul SageMaker descris mai sus, rollback-ul automat nu e o decizie umană — e o consecință a alarmelor atașate perioadei de observare. Dacă o alarmă CloudWatch legată de fleet-ul nou se declanșează în timpul baking period-ului, tot traficul revine la fleet-ul vechi fără intervenție (AWS, idem). Pentru ca asta să funcționeze, alarmele trebuie să existe înainte de rollout — rata de erori, latența P99, dar și metrici specifice modelului (procentul de predicții cu încredere scăzută, rata de fallback la regula de siguranță) acolo unde infrastructura de monitorizare le expune.

Rollback manual: revii la alias, nu la arheologie

Când problema nu declanșează o alarmă automată dar e vizibilă pentru cineva (un analist, un client, o echipă de suport), rollback-ul manual trebuie să fie la fel de simplu ca promovarea: muți aliasul champion înapoi la versiunea anterioară în registry și redeschizi fluxul de rollout invers. Dacă rollback-ul necesită să reconstruiești manual „versiunea de acum două săptămâni" dintr-un folder local sau un email cu atașament, pipeline-ul de versionare de mai sus nu și-a făcut treaba.

Cine aprobă promovarea în producție

Poarta automată de testare decide dacă o versiune e eligibilă din punct de vedere al metricilor. Nu decide dacă e momentul potrivit să fie promovată — asta rămâne, de obicei, o decizie umană, separată de pipeline prin exact mecanismul de environment protection descris mai sus: cine a antrenat modelul sau a deschis pull request-ul nu ar trebui să fie și singurul care aprobă promovarea lui (de aici opțiunea „prevent self-review" din GitHub). În echipele cu operare matură, acel reviewer e de obicei cineva din rolul de platformă sau SRE, nu neapărat autorul modelului — exact persoana care, în caz de incident, execută și runbook-ul de remediere. Tratarea runbook-urilor de remediere ca acțiuni executabile, cu aprobare, în loc de documentație statică citită sub presiune, e unul dintre subiectele acoperite pe larg în AI pentru DevOps și SRE (AIOps).

Pentru sisteme cu risc ridicat (decizii cu efect asupra oamenilor — credit, angajare, triaj), merită reținut că promovarea unui model nou nu e doar o decizie tehnică de rollout, ci și un eveniment care ar trebui să lase o urmă verificabilă: cine a aprobat, pe ce metrici, cu ce versiune de date. Un model registry cu aliasuri și un environment cu reviewer-i obligatorii produc, ca efect secundar, exact acest audit trail — fără cod suplimentar scris special pentru conformitate.

Greșelile care strică pipeline-ul de livrare continuă

• Promovare pe baza unui singur run de evaluare. Dacă setul de validare e mic sau zgomotos, o singură rulare poate trece pragul din întâmplare. Compară pe o fereastră, nu pe un punct.
• Niciun plan de rollback scris înainte de primul deploy. Rollback-ul testat pentru prima dată în timpul unui incident real e un rollback care eșuează la rândul lui.
• Canary fără alarme reale atașate. O perioadă de observare fără metrici care pot trage un rollback automat e doar o pauză de cafea, nu o poartă de siguranță.
• Alias de producție mutat manual, în afara pipeline-ului, „doar de data asta". Prima excepție devine procedura standard — și pierzi exact trasabilitatea pe care registry-ul trebuia să o garanteze.
• Tratarea modelului ca pe un microserviciu obișnuit. Un model se poate degrada fără erori HTTP — răspunde 200, dar greșit. Alarmele dintr-un pipeline clasic (rată de erori, latență) nu prind asta; e nevoie de metrici specifice calității predicției.
• Aprobarea devine o formalitate. Dacă reviewer-ul aprobă mereu fără să se uite la raportul de evaluare, environment protection rules devine teatru de securitate, nu un control real.

Checklist: ce pui în pipeline-ul tău de CI/CD pentru modele

1. Cod, date și model versionate separat, cu trasabilitate de la o versiune de model înapoi la commit-ul de cod și la hash-ul datelor.
2. O poartă automată de testare care compară versiunea candidată cu modelul curent din producție pe un set de validare fix, nu doar cu un prag absolut.
3. Un model registry cu aliasuri (nu fișiere copiate manual), astfel încât promovarea și rollback-ul să fie o singură operație atomică.
4. Un mediu de staging/canary cu procent de trafic configurabil și o perioadă de observare minimă înainte de următoarea treaptă.
5. Alarme legate explicit de perioada de observare, capabile să declanșeze rollback automat — nu doar dashboard-uri verificate manual.
6. Un environment separat pentru promovarea în producție, cu reviewer obligatoriu diferit de autorul modelului.
7. Un rollback manual testat măcar o dată în afara unui incident real, nu doar documentat.
8. O urmă scrisă (audit trail) a fiecărei promovări: cine a aprobat, ce metrici, ce versiune de date.

Întrebări frecvente

Ce diferență e între CI/CD pentru software și CI/CD pentru modele AI? CI/CD clasic testează și promovează cod determinist. Pentru un model, artefactul promovat e rezultatul antrenării (cod + date + hiperparametri), iar testele compară metrici pe un set de validare față de un prag și față de modelul curent din producție, nu verifică un comportament fix.

Ce este un model registry și de ce nu ajunge un fișier pe server? Un model registry (de exemplu MLflow Model Registry) ține evidența versiunilor unui model și le atribuie aliasuri mutabile, de tipul champion. Promovarea sau rollback-ul devin o singură operație — mutarea aliasului — în loc să presupună copierea manuală a unui fișier și riscul de a pierde urma versiunii anterioare.

Care e diferența dintre canary și shadow deployment? Într-un shadow deployment, modelul nou primește o copie a traficului, dar răspunsurile lui nu ajung niciodată la utilizator — servesc doar comparației. Într-un canary, modelul nou răspunde efectiv unei felii mici din traficul real, cu efect asupra utilizatorilor din acea felie, monitorizată cu alarme înainte de a crește procentul.

Rollback-ul unui model trebuie să fie întotdeauna automat? Nu. Rollback-ul automat, declanșat de alarme în timpul unei perioade de observare, prinde regresiile care se văd în metrici operaționale (erori, latență, rate de fallback). Pentru probleme vizibile doar calitativ (un utilizator sau un analist semnalează un răspuns greșit), rollback-ul manual — mutarea aliasului de producție înapoi la versiunea anterioară — trebuie să fie la fel de rapid și de simplu.

Cine ar trebui să aprobe promovarea unui model în producție? O practică frecventă în echipele cu operare matură este separarea rolurilor: cine a antrenat sau a propus modelul nu e singurul care aprobă promovarea lui. Un environment cu reviewer obligatoriu, diferit de autor, transformă asta dintr-o convenție verbală într-o regulă aplicată automat de platforma de CI/CD.

Concluzie

Un model testat manual și „deployat" prin copiere pe server nu are, de fapt, un pipeline CI/CD — are o speranță. Diferența dintre cele două stă în patru decizii luate înainte de primul deploy real: cum versionezi model și date ca artefacte separate de cod, ce metrici opresc automat o promovare proastă, cât trafic real primește modelul nou înainte de a primi tot traficul și cât de rapid — automat sau manual — revii la versiunea anterioară când ceva nu merge. Niciuna dintre ele nu cere infrastructură exotică; cer doar ca rollback-ul să fie la fel de testat ca deploy-ul.

Articol tehnic. Sursele oficiale (MLflow, AWS SageMaker, Google Cloud Vertex AI, GitHub Docs) au fost consultate la 18 octombrie 2026. Fragmentele YAML urmează structura documentată de GitHub Actions și MLflow, dar sunt ilustrative — nu au fost rulate într-un pipeline real.