În peisajul în rapidă evoluție al operațiunilor de învățare automată (MLOps), capacitatea de a urmări, gestiona și implementa modele cu precizie nu este doar o bună practică – este o necesitate pentru menținerea scalabilității, reproducibilității și conformității. Unul dintre cele mai critice, dar adesea neglijate, componente ale MLOps este etichetarea automatizată a versiunilor modelelor, un proces care asigură faptul că fiecare iterație a unui model este identificabilă în mod unic, urmăribilă și implementabilă cu intervenție umană minimă. Fără un sistem robust de versionare, organizațiile riscă implementarea unor modele învechite, pierderea urmei îmbunătățirilor de performanță sau incapacitatea de a reproduce rezultatele, ceea ce poate duce la consecințe catastrofale în mediile de producție. Mizele sunt deosebit de mari în industriile în care performanța modelului afectează direct veniturile, siguranța sau conformitatea reglementară, cum ar fi finanțele, sănătatea sau administrația publică. De exemplu, în munca noastră cu Asistentul Virtual Public Universal (UVPA) pentru Primăria București, unde sistemul procesează cererile cetățenilor prin intrări vocale, text și documente, capacitatea de a reveni la o versiune anterioară a modelului în caz de degradare a performanței nu este doar o facilitate – este o cerință pentru menținerea încrederii publice și a continuității operaționale.

Costurile ascunse ale versionării manuale în învățarea automată sunt adesea subestimate până când se manifestă sub formă de eșecuri critice. Etichetarea manuală, unde oamenii de știință sau inginerii atribuie numere de versiune pe baza unor convenții ad-hoc, introduce o serie de ineficiențe și riscuri. În primul rând, este predispusă la erori: o etichetă greșită poate duce la implementarea unei versiuni incorecte, rezultând în performanță degradată sau chiar eșecuri ale sistemului. De exemplu, în timpul dezvoltării sistemului de diagnosticare tehnică pentru TASSID, care utilizează un model Mistral Large finisat pentru a identifica defectele în echipamentele de refrigerare, o eroare de etichetare manuală a dus la implementarea unei versiuni învechite a modelului care a clasificat greșit defectele critice ca probleme minore. Incidentul a rezultat într-o oprire de 12 ore a operațiunilor clientului și a necesitat o revenire de urgență, costând atât timp, cât și reputație. În al doilea rând, versionarea manuală este consumatoare de timp. Oamenii de știință petrec în medie 15-20% din timpul lor gestionând versiunile, timp care ar putea fi mai bine folosit pentru experimentare și optimizare. În experiența noastră, automatizarea procesului de etichetare pentru cele 400+ website-uri pe care le-am produs pentru firmele de construcții a redus timpul petrecut pe controlul versiunilor cu 90%, permițând echipei noastre să se concentreze pe rafinarea pipeline-ului de AI care genera conținutul. În al treilea rând, versionarea manuală lipseste de consistență. Fără convenții standardizate, echipele folosesc adesea scheme de denumire diferite, ceea ce face dificilă urmărirea modificărilor între modele sau colaborarea eficientă. Această inconsistență devine deosebit de problematică în scenarii de învățare federată, unde modelele sunt antrenate pe mai multe dispozitive periferice, sau în sisteme multi-modale, unde modelele de text, imagine și audio trebuie versionate în armonie.

Pentru a aborda aceste provocări, am adoptat versionarea semantică (SemVer) ca fundație pentru strategia noastră de versionare a modelelor, extinzând formatul familiar MAJOR.MINOR.PATCH pentru a acomoda cerințele unice ale modelelor de învățare automată. În dezvoltarea tradițională de software, SemVer este folosit pentru a comunica impactul modificărilor: o versiune MAJOR indică modificări majore, o versiune MINOR adaugă funcționalități compatibile înapoi, iar o versiune PATCH include corecții de bug-uri compatibile înapoi. Pentru modelele de AI, reinterpretăm aceste componente pentru a reflect modificările în comportamentul modelului, performanța și dependențele de date. O creștere a versiunii MAJOR semnalează o modificare majoră în comportamentul modelului, cum ar fi o schimbare în limita de decizie care ar putea afecta aplicațiile downstream. De exemplu, când am finisat modelul Mistral Large pentru sistemul UVPA, o creștere a versiunii MAJOR a fost declanșată când am introdus o nouă taxonomie de clasificare a intențiilor care a modificat modul în care cererile cetățenilor erau categorisite. O creștere a versiunii MINOR, pe de altă parte, indică îmbunătățiri compatibile înapoi, cum ar fi îmbunătățiri de performanță sau adăugarea de noi caracteristici care nu perturba funcționalitatea existentă. În cazul catalogului interactiv de case pentru CaseBineFacute.ro, o creștere a versiunii MINOR a fost folosită când am îmbunătățit acuratețea estimării costurilor a modelului cu 12% fără a schimba schema de intrare-ieșire. În cele din urmă, o creștere a versiunii PATCH este rezervată pentru corecții de bug-uri compatibile înapoi, cum ar fi corectarea unei clase etichetate greșit într-un model de clasificare sau rezolvarea unei probleme de scurgere de date în pipeline-ul de antrenare. Această abordare asigură faptul că părțile interesate – fie că sunt oameni de știință, ingineri sau utilizatori de afaceri – pot înțelege rapid implicațiile unei actualizări a modelului fără a intra în detaliile tehnice.

Deși versionarea semantică oferă un cadru clar, adevărata putere a etichetării automate a modelelor constă în capacitatea sa de a impune reguli de versionare programatic, asemănător cu ceea ce face Git pentru cod. Am dezvoltat un sistem de etichetare personalizat care imită fluxurile de lucru de ramificare și etichetare ale Git, dar adaptat la nuanțele învățării automate. De exemplu, sistemul nostru generează automat etichete pe baza regulilor personalizate care iau în considerare datele de antrenare ale modelului, hiperparametrii și metricile de performanță. Când un model este antrenat, sistemul verifică mai întâi linia de date folosind DVC (Data Version Control) pentru a se asigura că setul de date de antrenare nu a fost modificat de la ultima versiune. Dacă datele s-au schimbat, sistemul crește versiunea MAJOR, deoarece comportamentul modelului este probabil să difere semnificativ. Apoi, sistemul evaluează hiperparametrii folosiți în timpul antrenării. Dacă hiperparametrii cheie, cum ar fi rata de învățare sau mărimea lotului, au fost modificați, sistemul crește versiunea MINOR, deoarece aceste modificări duc de obicei la îmbunătățiri de performanță fără a modifica comportamentul fundamental al modelului. În cele din urmă, sistemul evaluează metricile de performanță ale modelului, cum ar fi acuratețea, scorul F1 sau latența. Dacă performanța modelului depășește pragurile predefinite – de exemplu, o îmbunătățire a scorului F1 de 5% sau mai mult – sistemul crește versiunea MINOR. Dacă performanța scade sub un anumit prag, sistemul marchează modelul pentru revizuire și împiedică etichetarea acestuia pentru implementare. Această abordare bazată pe reguli asigură faptul că creșterile de versiune sunt deterministe și reproducibile, eliminând ambiguitatea care afectează adesea etichetarea manuală.

Adevărata inteligență a unui sistem de versionare automatizată apare atunci când acesta utilizează metadate pentru a crea etichete bogate și conștiente de context. Metadatele oferă contextul necesar pentru a înțelege de ce un model a fost actualizat, cum diferă de versiunile anterioare și dacă este potrivit pentru implementare. În fluxurile noastre de lucru, capturăm și încorporăm metadate la fiecare etapă a ciclului de viață al modelului, inclusiv statistici ale datelor de antrenare, hiperparametri, metrici de performanță și detalii despre mediul de implementare. De exemplu, atunci când antrenăm un model pentru platforma eDezvoltator.ro, care agregă date imobiliare, includem metadate precum timestamp-ul snapshot-ului datelor de antrenare, numărul de proprietăți incluse și distribuția geografică a datelor. Aceste metadate sunt critice pentru detectarea derivării datelor, un fenomen în care proprietățile statistice ale datelor de intrare se schimbă în timp, ducând la degradarea performanței modelului. Prin compararea metadatelor versiunilor consecutive ale modelului, sistemul nostru poate detecta automat deriva și poate declanșa o creștere a versiunii MAJOR dacă deriva depășește un prag predefinit. În mod similar, încorporăm configurațiile hiperparametrilor în metadatele modelului, permițându-ne să urmăriți cum modificările parametrilor, cum ar fi rata de învățare sau puterea de regularizare, afectează performanța. De exemplu, în sistemul de diagnosticare tehnică pentru TASSID, am observat că modelele antrenate cu o rată de învățare de 0,001 au performat constant mai bine decât cele antrenate cu o rată de învățare de 0,01, ceea ce ne-a determinat să standardizăm rata de învățare mai mică în versiunile ulterioare. Metricile de performanță, cum ar fi acuratețea, precizia, recall-ul și latența, sunt de asemenea încorporate în metadate, permițând sistemului să eticheteze automat modelele în funcție de potrivirea lor pentru cazuri de utilizare specifice. De exemplu, un model cu acuratețe ridicată, dar latență mare, ar putea fi etichetat ca v2.1.0-latență-ridicată, indicând faptul că este potrivit pentru procesarea în loturi, dar nu pentru aplicații în timp real.

Integrarea etichetării automate a modelelor cu pipeline-urile CI/CD este esențială pentru a asigura faptul că versionarea nu este doar un exercițiu de etichetare post-hoc, ci o parte integrantă a procesului de implementare. În fluxurile noastre de lucru, tratăm antrenarea și evaluarea modelelor ca etape într-un pipeline CI/CD, unde fiecare etapă declanșează acțiuni specifice de versionare. De exemplu, când un om de știință introduce un nou script de antrenare într-un depozit Git, pipeline-ul CI inițiază automat un job de antrenare, evaluează performanța modelului și generează o etichetă candidată pe baza regulilor descrise anterior. Dacă modelul trece toate pragurile de performanță, pipeline-ul trece la următoarea etapă, unde împachetează modelul cu metadatele sale și îl încarcă într-un registru de modele, cum ar fi MLflow. Registrul atribuie apoi eticheta finală de versiune și face modelul disponibil pentru implementare. Această integrare asigură faptul că doar modelele validate sunt etichetate și implementate, reducând riscul de eroare umană. Mai mult, pipeline-ul CI/CD poate impune porți de aprobare, unde actualizările critice ale modelului – cum ar fi cele care necesită o creștere a versiunii MAJOR – trebuie revizuite manual de un om de știință senior înainte de implementare. De exemplu, în proiectul UVPA, orice actualizare a modelului care modifică taxonomia de clasificare a intențiilor necesită aprobare manuală, deoarece ar putea afecta capacitatea sistemului de a direcționa corect cererile cetățenilor. Prin încorporarea versionării în pipeline-ul CI/CD, permitem și mecanisme automate de revenire. Dacă un model implementat nu îndeplinește așteptările de performanță în producție, sistemul de monitorizare poate declanșa o revenire la versiunea stabilă anterioară, minimizând timpul de nefuncționare și atenuând riscurile.

Pentru a asigura consistența în versionarea modelelor, folosim Git hooks și verificări pre-commit pentru a impune convenții de denumire și a valida metadatele înainte ca un model să fie etichetat. Git hooks sunt scripturi care rulează automat la anumite puncte în fluxul de lucru Git, cum ar fi înainte de un commit sau push. Folosim hook-uri pre-commit pentru a valida structura etichetelor modelului, asigurându-ne că acestea respectă convențiile noastre de versionare semantică. De exemplu, hook-ul verifică dacă eticheta urmează formatul MAJOR.MINOR.PATCH și dacă fiecare componentă este un număr întreg nenegativ. De asemenea, validează faptul că eticheta include orice sufixe necesare, cum ar fi -staging sau -production, pentru a indica mediul de implementare. În plus, hook-ul verifică dacă fișierul de metadate al modelului – de obicei un fișier JSON sau YAML – conține toate câmpurile necesare, cum ar fi hash-ul datelor de antrenare, hiperparametrii și metricile de performanță. Dacă oricare dintre aceste verificări eșuează, commit-ul este respins, iar omul de știință este instruit să corecteze problemele. Această abordare asigură faptul că doar modelele bine formate, bogate în metadate, sunt etichetate, reducând riscul de inconsistențe în registrul de modele. De exemplu, în dezvoltarea catalogului interactiv de case, un hook pre-commit a prins un câmp de metadate lipsă care ar fi împiedicat implementarea modelului în mediul de producție, economisind ore de timp de depanare. În afară de Git hooks, folosim și validare bazată pe expresii regulate pentru a impune convenții de denumire pentru artefactele modelului. De exemplu, fișierele modelului trebuie să urmeze modelul model-{name}-v{MAJOR}.{MINOR}.{PATCH}.pkl, unde {name} este numele modelului, iar {MAJOR}.{MINOR}.{PATCH} este versiunea semantică. Această convenție asigură faptul că fișierele modelului sunt ușor de identificat și sortat, atât în sistemul de fișiere, cât și în registrul de modele.

Una dintre cele mai puternice caracteristici ale sistemului nostru de etichetare automatizată este capacitatea sa de a eticheta dinamic modelele pe baza pragurilor de performanță. Spre deosebire de software-ul tradițional, unde creșterile de versiune sunt de obicei legate de modificările de cod, modelele de învățare automată evoluează pe baza performanței lor, care poate fluctua datorită modificărilor în date, hiperparametri sau proceduri de antrenare. Pentru a ține cont de acest lucru, definim reguli de etichetare bazate pe performanță care cresc automat numărul versiunii atunci când anumite metrici depășesc sau scad sub pragurile predefinite. De exemplu, în sistemul de diagnosticare tehnică pentru TASSID, am stabilit o regulă care crește versiunea MINOR dacă scorul F1 al modelului se îmbunătățește cu 3% sau mai mult, deoarece acest lucru indică o îmbunătățire semnificativă a capacității modelului de a identifica corect defectele. În schimb, dacă scorul F1 scade cu 2% sau mai mult, sistemul marchează modelul pentru revizuire și împiedică etichetarea acestuia pentru implementare. În mod similar, folosim etichetare bazată pe latență pentru a ne asigura că modelele îndeplinesc cerințele de performanță ale cazului lor de utilizare intenționat. De exemplu, în proiectul UVPA, modelele destinate procesării în timp real trebuie să aibă o latență de inferență mai mică de 100 de milisecunde. Dacă latența unui model depășește acest prag, sistemul îl etichetează ca v2.1.0-latență-ridicată și îl direcționează către un pipeline de procesare în loturi în schimb. Această abordare de etichetare dinamică asigură faptul că modelele sunt întotdeauna etichetate în funcție de performanța lor reală, nu doar de îmbunătățirile lor teoretice, și că deciziile de implementare se bazează pe criterii obiective.

Etichetarea automatizată este deosebit de valoroasă în scenarii care implică testare A/B și implementări canary, unde mai multe versiuni de modele trebuie să coexiste în producție pentru a evalua performanța lor. În aceste cazuri, versionarea dinamică ne permite să etichetăm modelele în funcție de statutul lor experimental, asigurându-ne că sunt implementate pentru subsetul corect de utilizatori sau medii. De exemplu, când am implementat o nouă versiune a modelului de clasificare a intențiilor pentru sistemul UVPA, am folosit o strategie de implementare canary pentru a implementa treptat modelul pentru 10% dintre utilizatori. Modelul a fost etichetat ca v3.0.0-canary, indicând faptul că este o versiune experimentală destinată unui public limitat. Pe măsură ce performanța modelului a fost monitorizată și validată, eticheta a fost actualizată la v3.0.0-staging și, în final, la v3.0.0-production odată ce a fost complet implementat. Această convenție de etichetare ne permite să urmărim ciclul de viață al modelelor experimentale și asigură faptul că acestea nu sunt implementate accidental pentru întreaga bază de utilizatori înainte de validare. În mod similar, în scenarii de testare A/B, etichetăm modelele cu sufixe precum -variant-a și -variant-b pentru a distinge între versiunile concurente. De exemplu, în catalogul interactiv de case, am testat două versiuni ale modelului de estimare a costurilor – una antrenată pe date istorice și alta pe date sintetice – pentru a determina care performează mai bine în producție. Modelele au fost etichetate ca v2.1.0-variant-historic și v2.1.0-variant-sintetic, permițându-ne să comparăm performanța lor și să selectăm câștigătorul pe baza metricilor din lumea reală.

Detectarea și etichetarea modelelor pe baza derivării datelor și a derivării conceptului este un alt aspect critic al versionării automatizate, în special în mediile de producție unde distribuția datelor de intrare se poate schimba în timp. Derivarea datelor apare atunci când proprietățile statistice ale datelor de intrare se schimbă, în timp ce derivarea conceptului apare atunci când relația dintre datele de intrare și variabila țintă se modifică. Ambele fenomene pot degrada performanța modelului, făcând esențială detectarea și răspunsul proactiv la acestea. În fluxurile noastre de lucru, folosim teste statistice și sisteme de monitorizare pentru a detecta deriva și a eticheta automat modelele afectate. De exemplu, în platforma eDezvoltator.ro, monitorizăm distribuția prețurilor proprietăților, a suprafeței și a datelor de localizare pentru a detecta deriva datelor. Dacă testul Kolmogorov-Smirnov indică o diferență statistic semnificativă între datele de antrenare și datele de producție, sistemul declanșează o creștere a versiunii MAJOR și marchează modelul pentru reantrenare. În mod similar, folosim monitorizarea performanței pentru a detecta deriva conceptului. Dacă acuratețea sau scorul F1 al modelului scade sub un prag predefinit, sistemul presupune că procesul de generare a datelor de bază s-a schimbat și declanșează o creștere a versiunii MAJOR. De exemplu, în sistemul de diagnosticare tehnică, am observat o scădere bruscă a preciziei modelului când un nou tip de echipament de refrigerare a fost introdus pe piață. Sistemul a detectat degradarea performanței și a etichetat modelul ca v2.0.0-derivă-detectată, declanșând un ciclu de reantrenare cu datele actualizate. Prin automatizarea detectării și etichetării derivării, ne asigurăm că modelele sunt întotdeauna aliniate cu distribuția curentă a datelor, reducând riscul de eșecuri silențioase în producție.

Etichetele automate de revenire sunt un mecanism critic de siguranță în orice pipeline MLOps, permițând echipelor să revină rapid la o versiune anterioară a modelului în caz de eșecuri sau degradare a performanței. În fluxurile noastre de lucru, generăm automat etichete de revenire de fiecare dată când o nouă versiune a modelului este implementată în producție. Aceste etichete urmează convenția v{MAJOR}.{MINOR}.{PATCH}-rollback-{timestamp}, unde {timestamp} este momentul implementării. De exemplu, dacă un model etichetat v3.1.0 este implementat în producție și ulterior nu îndeplinește așteptările de performanță, sistemul de monitorizare poate declanșa o revenire la versiunea stabilă anterioară, care ar putea fi etichetată v3.0.0-rollback-202405151430. Această convenție de etichetare asigură faptul că versiunile de revenire sunt ușor de identificat și că procesul de revenire este determinist. Mai mult, eticheta de revenire include metadate despre motivul revenirii, cum ar fi metricile de performanță care au declanșat eșecul. Aceste metadate sunt valoroase pentru analiza post-mortem și ajută echipele să înțeleagă de ce un model a eșuat și cum să prevină probleme similare în viitor. De exemplu, în proiectul UVPA, o revenire a fost declanșată când acuratețea clasificării intențiilor modelului a scăzut cu 8% din cauza unui aflux brusc de cereri de la cetățeni legate de un nou serviciu municipal. Eticheta de revenire includea metadate despre scăderea acurateței și timestamp-ul incidentului, permițând echipei să identifice rapid cauza principală și să reantreneze modelul cu datele actualizate.

Deși instrumente precum MLflow oferă capacități robuste de versionare a modelelor din cutie, am extins funcționalitatea acestora pentru a răspunde nevoilor specifice ale fluxurilor noastre de lucru. Registrul de modele MLflow permite echipelor să urmărească versiunile modelelor, să le anoteze cu metadate și să gestioneze ciclul lor de viață de la staging la producție. Cu toate acestea, am constatat că sistemul de etichetare implicit al MLflow lipsea de flexibilitatea necesară pentru a gestiona cerințele complexe de versionare ale modelelor de învățare automată, în special în scenarii care implică modele multi-modale, învățare federată sau aplicații sensibile la conformitate. Pentru a aborda acest lucru, am dezvoltat un plugin personalizat pentru MLflow care se integrează cu sistemul nostru de etichetare bazat pe reguli. Plugin-ul generează automat etichete de versiune semantică pe baza metadatelor și a metricilor de performanță ale modelului, asigurându-se că fiecare model din registru respectă convențiile noastre de versionare. De exemplu, când un model este înregistrat în MLflow, plugin-ul evaluează metadatele sale – cum ar fi hash-ul datelor de antrenare, hiperparametrii și metricile de performanță – și generează o etichetă candidată. Dacă performanța modelului depășește pragurile predefinite, plugin-ul crește versiunea MINOR; dacă datele de antrenare s-au schimbat, crește versiunea MAJOR. Plugin-ul impune, de asemenea, etichete specifice mediului, cum ar fi -staging sau -production, pentru a asigura faptul că modelele sunt implementate în mediul corect. În plus, am extins capacitățile de metadate ale MLflow pentru a include câmpuri personalizate, cum ar fi cerințele hardware ale modelului, statutul de conformitate și metricile de explicabilitate. Aceste metadate sunt critice pentru a asigura faptul că modelele sunt implementate într-un mod care îndeplinește cerințele lor operaționale și reglementare. De exemplu, în proiectul UVPA, modelele etichetate pentru producție trebuie să includă metadate despre conformitatea lor cu GDPR, deoarece acestea procesează date personale de la cetățeni. Prin extinderea capacităților MLflow, ne asigurăm că registrul nostru de modele nu este doar un depozit de artefacte de modele, ci un sistem cuprinzător pentru gestionarea întregului ciclu de viață al modelului.

Versionarea modelelor multi-modale, care combină text, imagini, audio sau alte tipuri de date, prezintă provocări unice datorită complexității spațiilor lor de intrare și ieșire. Spre deosebire de modelele tradiționale, care operează de obicei pe o singură modalitate de date, modelele multi-modale trebuie versionate într-un mod care ține cont de modificările din fiecare modalitate și de interacțiunile dintre acestea. De exemplu, în sistemul UVPA, care procesează cererile cetățenilor prin intrări vocale, text și documente, modelul constă din trei sub-component: un model de recunoaștere vocală, un model de clasificare a textului și un model de parsare a documentelor. Fiecare dintre aceste componente evoluează independent, dar performanța lor combinată determină comportamentul general al sistemului. Pentru a versiona astfel de modele, folosim un sistem de etichetare ierarhic care urmărește modificările atât la nivelul componentelor, cât și la nivelul sistemului. Fiecare sub-componentă este etichetată folosind versionarea semantică – de exemplu, modelul de recunoaștere vocală ar putea fi etichetat ca v1.2.0, în timp ce modelul de clasificare a textului este etichetat ca v2.1.0. Sistemul în ansamblu este apoi etichetat folosind o versiune compusă, cum ar fi v3.0.0-speech-v1.2.0-text-v2.1.0-doc-v1.0.0, care reflectă versiunile fiecărei sub-component. Această abordare asigură faptul că modificările din orice sub-componentă sunt urmăribile și că comportamentul sistemului poate fi reprodus prin implementarea versiunilor exacte ale fiecărei componente. Mai mult, sistemul de etichetare ierarhic ne permite să izolăm impactul modificărilor în componentele individuale. De exemplu, dacă performanța sistemului se degradează după o actualizare, putem determina rapid dacă problema provine din modelul de recunoaștere vocală, din modelul de clasificare a textului sau din interacțiunea lor. Această granularitate este critică pentru depanarea și optimizarea sistemelor multi-modale.

Învățarea federată, unde modelele sunt antrenate pe mai multe dispozitive periferice fără centralizarea datelor, introduce un alt nivel de complexitate în versionarea modelelor. În scenariile de învățare federată, fiecare dispozitiv periferic antrenează un model local pe datele sale, iar aceste modele locale sunt agregate periodic pentru a produce un model global. Provocarea constă în urmărirea liniei modelului global, care depinde de contribuțiile a sute sau mii de modele locale. Pentru a aborda acest lucru, am dezvoltat un sistem de etichetare automatizată pentru învățarea federată care urmărește versiunile atât ale modelelor locale, cât și ale celui global. Fiecare model local este etichetat cu un identificator unic care include ID-ul dispozitivului, runda de antrenare și un hash al datelor locale. De exemplu, un model local antrenat pe dispozitivul edge-42 în timpul rundei 5 ar putea fi etichetat ca v1.0.0-edge-42-round-5-data-{hash}. Când modelele locale sunt agregate pentru a produce un model global, sistemul generează o etichetă compusă care include versiunile tuturor modelelor locale contribuitoare. De exemplu, modelul global ar putea fi etichetat ca v2.1.0-global-round-5-local-{hash1}-{hash2}-…, unde {hash1}, {hash2}, … sunt hash-urile modelelor locale. Această convenție de etichetare asigură faptul că linia modelului global este complet urmăribilă, permițând echipelor să reproducă procesul de agregare sau să depaneze probleme prin examinarea contribuțiilor modelelor locale individuale. În plus, sistemul crește automat versiunea modelului global pe baza performanței modelului agregat. Dacă acuratețea modelului global se îmbunătățește cu 5% sau mai mult, sistemul crește versiunea MINOR; dacă procesul de agregare se schimbă – de exemplu, datorită unui nou algoritm de agregare – sistemul crește versiunea MAJOR.

Finisarea modelelor mari de limbaj (LLM) prezintă o provocare unică de versionare datorită interacțiunii dintre modelul de bază, setul de date de finisare și hiperparametrii. Spre deosebire de modelele tradiționale, unde creșterile de versiune sunt de obicei legate de modificările în datele de antrenare sau hiperparametri, LLM-urile necesită o abordare mai nuanțată care ține cont de proveniența modelului de bază și de specificitatea procesului de finisare. De exemplu, când am finisat modelul Mistral Large pentru sistemul UVPA, am început cu modelul de bază mistral-large-v1.0 și l-am finisat pe un set de date de 50.000 de cereri de la cetățeni. Modelul finisat a fost apoi etichetat ca uvpa-mistral-large-v1.0-finetuned-v1.0.0, unde v1.0.0 reflectă versiunea procesului de finisare. Dacă am actualizat ulterior setul de date de finisare pentru a include 10.000 de cereri suplimentare, sistemul ar fi crescut versiunea MINOR la v1.1.0, deoarece modificarea este compatibilă înapoi. Cu toate acestea, dacă am trecut la un model de bază diferit – de exemplu, mistral-large-v2.0 – sistemul ar fi crescut versiunea MAJOR la v2.0.0, deoarece modificarea ar putea altera semnificativ comportamentul modelului. Această convenție de etichetare asigură faptul că linia LLM-urilor finisate este complet urmăribilă și că părțile interesate pot înțelege rapid implicațiile unei actualizări a modelului. Mai mult, încorporăm metadate despre procesul de finisare în eticheta modelului, inclusiv dimensiunea setului de date, numărul de epoci de antrenare și rata de învățare. Aceste metadate sunt critice pentru reproducerea procesului de finisare și pentru depanarea problemelor care pot apărea în producție.

Conformitatea cu cerințele reglementare, cum ar fi GDPR, HIPAA sau standarde specifice industriei, este o considerație critică în versionarea modelelor, în special în sectoare precum sănătatea, finanțele sau administrația publică. Modelele care procesează date sensibile trebuie etichetate într-un mod care să reflecte statutul lor de conformitate, asigurându-se că sunt implementate doar în medii în care îndeplinesc standardele legale și etice necesare. De exemplu, în proiectul UVPA, care procesează date personale de la cetățeni, toate modelele trebuie să fie conforme cu GDPR. Pentru a impune acest lucru, etichetăm automat modelele cu statutul lor de conformitate, folosind sufixe precum -conform-gdpr sau -conform-hipaa. Statutul de conformitate este determinat pe baza metadatelor modelului, care includ informații despre sursele de date, tehnicile de procesare a datelor și măsurile de securitate utilizate în timpul antrenării. De exemplu, dacă un model este antrenat pe date anonime și nu stochează nicio informație personală, este etichetat ca -conform-gdpr. În schimb, dacă un model procesează date personale brute, este etichetat ca -neconform-gdpr și este restricționat de la implementarea în medii de producție. În plus, folosim verificări automate de conformitate în pipeline-ul nostru CI/CD pentru a valida statutul de conformitate al modelului înainte de implementare. Dacă un model eșuează verificarea de conformitate, pipeline-ul se oprește și marchează modelul pentru revizuire. Această abordare asigură faptul că doar modelele conforme sunt implementate, reducând riscul de încălcare a reglementărilor și al sancțiunilor asociate. De exemplu, în sistemul de diagnosticare tehnică pentru TASSID, care procesează date de la echipamentele de refrigerare din bucătăriile comerciale, etichetăm modelele cu statutul lor de conformitate pentru reglementările de siguranță alimentară, asigurându-ne că acestea îndeplinesc standardele stabilite de autorități precum FDA sau UE.

Modelele ansamblu, care combină predicțiile mai multor sub-modele pentru a îmbunătăți performanța, introduc un alt nivel de complexitate în versionare. Spre deosebire de modelele simple, unde creșterile de versiune sunt legate de modificările din modelul însuși, modelele ansamblu necesită un sistem de versionare ierarhic care urmărește modificările atât în ansamblu, cât și în sub-component. De exemplu, în platforma eDezvoltator.ro, folosim un ansamblu de modele pentru a prezice prețurile proprietăților, fiecare sub-model specializându-se într-o regiune geografică diferită. Modelul ansamblu este etichetat folosind versionarea semantică – de exemplu, v2.1.0 – în timp ce fiecare sub-model este etichetat cu un identificator unic care include regiunea și versiunea sa – de exemplu, v1.0.0-bucurești sau v1.2.0-cluj. Eticheta modelului ansamblu include referințe la versiunile sub-modelelor sale, asigurându-se că comportamentul ansamblului poate fi reprodus prin implementarea versiunilor exacte ale fiecărui sub-model. De exemplu, modelul ansamblu ar putea fi etichetat ca v2.1.0-ansamblu-bucurești-v1.0.0-cluj-v1.2.0. Acest sistem de etichetare ierarhic ne permite să izolăm impactul modificărilor în sub-modelele individuale și să depanăm probleme prin examinarea contribuțiilor fiecărei componente. Mai mult, asigură faptul că performanța ansamblului este reproducibilă, deoarece versiunile exacte ale sub-modelelor sunt înregistrate în etichetă. Dacă un sub-model este actualizat – de exemplu, datorită unei performanțe îmbunătățite în regiunea Cluj – versiunea ansamblului este crescută în consecință, iar noua etichetă reflectă versiunile actualizate ale sub-modelelor.

Controlul Versiunii Datelor (DVC) este un instrument esențial pentru gestionarea liniei și reproducibilității modelelor de învățare automată, în special în scenarii în care datele de antrenare evoluează în timp. DVC permite echipelor să urmărească modificările în seturile de date, modele și pipeline-uri, asigurându-se că fiecare experiment este reproducibil și că linia datelor este complet urmăribilă. În fluxurile noastre de lucru, integrăm DVC cu sistemul nostru de etichetare automatizată pentru a ne asigura că versiunile modelelor sunt întotdeauna legate de setul exact de date și pipeline-ul folosit pentru antrenare. De exemplu, când un model este antrenat, DVC înregistrează hash-ul setului de date de antrenare, versiunea scriptului de antrenare și hiperparametrii folosiți. Aceste informații sunt apoi încorporate în metadatele modelului și folosite pentru a genera eticheta de versiune. Dacă setul de date de antrenare se modifică – de exemplu, datorită adăugării de noi date – sistemul detectează modificarea folosind DVC și crește versiunea MAJOR, deoarece comportamentul modelului este probabil să difere semnificativ. În mod similar, dacă scriptul de antrenare sau hiperparametrii se schimbă, sistemul crește versiunea MINOR. Această integrare asigură faptul că versiunile modelelor sunt întotdeauna reproducibile, deoarece setul exact de date și pipeline-ul folosit pentru antrenare pot fi retrase din DVC. Mai mult, capacitățile de linie a datelor ale DVC ne permit să urmărim proveniența datelor de antrenare, ceea ce este critic pentru depanarea problemelor sau reproducerea rezultatelor. De exemplu, în catalogul interactiv de case, am folosit DVC pentru a urmări linia datelor de antrenare pentru modelul de estimare a costurilor, asigurându-ne că putem reproduce performanța modelului chiar și după ce setul de date a fost actualizat cu noi liste de proprietăți.

Etichetarea modelelor în funcție de mediul de implementare – cum ar fi staging, producție sau edge – este o practică critică pentru a asigura faptul că modelele sunt implementate în contextul corect și că performanța lor este monitorizată în mod corespunzător. În fluxurile noastre de lucru, etichetăm automat modelele cu mediul lor de implementare intenționat, folosind sufixe precum -staging, -production sau -edge. De exemplu, un model destinat implementării într-un mediu de staging ar putea fi etichetat ca v2.1.0-staging, în timp ce același model implementat în producție ar fi etichetat ca v2.1.0-production. Această convenție de etichetare asigură faptul că modelele nu sunt implementate din greșeală în mediul greșit și că performanța lor este monitorizată în conformitate cu cerințele mediului. De exemplu, modelele implementate în producție sunt supuse unor praguri de performanță și monitorizare mai stricte decât cele din staging, deoarece impactul lor asupra utilizatorilor este mai mare. În plus, folosim metadate specifice mediului pentru a urmări performanța modelului în fiecare mediu. De exemplu, metadatele pentru un model de producție ar putea include latența medie, rata de eroare și feedback-ul utilizatorilor, în timp ce metadatele pentru un model de staging ar putea include rezultatele testelor A/B sau implementărilor canary. Aceste metadate sunt critice pentru evaluarea pregătirii modelului pentru producție și pentru depanarea problemelor care pot apărea în medii specifice. De exemplu, în proiectul UVPA, am observat că un model etichetat pentru producție avea o rată de eroare mai mare decât același model în staging, din cauza diferențelor în distribuția datelor de intrare. Metadatele specifice mediului ne-au permis să identificăm rapid problema și să reantrenăm modelul cu datele actualizate.

Versionarea automatizată nu se referă doar la urmărirea modificărilor în performanța modelului sau în date – este și despre asigurarea explicabilității și auditabilității modelului. În industriile reglementate, cum ar fi sănătatea sau finanțele, modelele trebuie să fie explicabile pentru a respecta cerințele legale și pentru a construi încredere cu părțile interesate. Pentru a aborda acest lucru, etichetăm automat modelele cu statutul lor de explicabilitate, folosind sufixe precum -explicabil sau -cutie-neagră. De exemplu, un model care utilizează valori SHAP sau LIME pentru explicabilitate ar putea fi etichetat ca v2.1.0-explicabil, în timp ce un model care lipsește caracteristici de explicabilitate ar putea fi etichetat ca v2.1.0-cutie-neagră. Această convenție de etichetare asigură faptul că doar modelele explicabile sunt implementate în medii reglementate și că părțile interesate pot evalua rapid transparența modelului. În plus, încorporăm metrici de explicabilitate în metadatele modelului, cum ar fi valoarea medie SHAP pentru fiecare caracteristică sau scorul global de interpretabilitate al modelului. Aceste metadate sunt critice pentru auditarea deciziilor modelului și pentru depanarea problemelor care pot apărea în producție. De exemplu, în sistemul de diagnosticare tehnică, am folosit valori SHAP pentru a explica predicțiile modelului tehnicienilor, asigurându-ne că aceștia pot avea încredere în recomandările modelului. Metadatele de explicabilitate au fost încorporate în eticheta modelului, permițându-ne să urmărim transparența modelului pe versiuni.

Optimizarea hardware-ului este un alt factor critic în versionarea modelelor, în special pentru modelele implementate în medii cu resurse limitate, cum ar fi dispozitivele edge sau aplicațiile mobile. Modelele optimizate pentru hardware specific – cum ar fi GPU-uri, TPU-uri sau modele cuantificate – trebuie etichetate într-un mod care să reflecte cerințele lor hardware, asigurându-se că sunt implementate în mediul corect. De exemplu, un model optimizat pentru inferență pe GPU ar putea fi etichetat ca v2.1.0-gpu, în timp ce un model cuantificat optimizat pentru dispozitive edge ar putea fi etichetat ca v2.1.0-cuantificat. Această convenție de etichetare asigură faptul că modelele sunt implementate în medii în care pot atinge performanța optimă și că cerințele lor hardware sunt comunicate clar părților interesate. În plus, încorporăm metadate specifice hardware-ului în eticheta modelului, cum ar fi latența modelului, utilizarea memoriei și consumul de energie pe diferite platforme hardware. Aceste metadate sunt critice pentru evaluarea potrivirii modelului pentru cazuri de utilizare specifice și pentru optimizarea performanței sale. De exemplu, în proiectul UVPA, am implementat o versiune cuantificată a modelului de clasificare a intențiilor pe dispozitive edge, unde a atins o latență de 50 de milisecunde și o utilizare a memoriei de 100 MB. Modelul a fost etichetat ca v3.0.0-cuantificat-edge, iar metadatele sale specifice hardware-ului au fost încorporate în etichetă, permițându-ne să urmărim performanța sa în diferite medii de implementare.

Versionarea modelelor pentru aplicații multi-lingvistice introduce o complexitate suplimentară, deoarece modelele trebuie etichetate într-un mod care să reflecte performanța și compatibilitatea lor specifice limbii. De exemplu, în platforma Transfăgărășan.Travel, care suportă patru limbi (română, engleză, franceză și germană), am antrenat modele separate pentru fiecare limbă pentru a asigura performanța optimă. Fiecare model specific limbii a fost etichetat cu un sufix care indică limba sa – de exemplu, v2.1.0-ro pentru română sau v2.1.0-en pentru engleză. Sistemul în ansamblu a fost apoi etichetat cu o versiune compusă care includea versiunile tuturor modelelor specifice limbii – de exemplu, v3.0.0-multilingv-ro-v2.1.0-en-v2.0.0-fr-v2.0.0-de. Această convenție de etichetare asigură faptul că modificările din orice model specific limbii sunt urmăribile și că comportamentul sistemului poate fi reprodus prin implementarea versiunilor exacte ale fiecărui model. Mai mult, ne permite să izolăm impactul modificărilor în limbi individuale și să depanăm probleme prin examinarea performanței fiecărui model specific limbii. De exemplu, dacă performanța sistemului se degradează în franceză, putem determina rapid dacă problema provine din modelul francez sau din interacțiunea acestuia cu celelalte modele lingvistice. În plus, încorporăm metadate specifice limbii în eticheta modelului, cum ar fi acuratețea, precizia și recall-ul modelului pentru fiecare limbă. Aceste metadate sunt critice pentru evaluarea performanței modelului în aplicații multi-lingvistice și pentru optimizarea comportamentului său.

Etichetarea automatizată pentru ciclurile de reantrenare a modelelor este esențială pentru a asigura faptul că modelele rămân precise și relevante în mediile de producție, unde distribuția datelor de intrare se poate schimba în timp. În fluxurile noastre de lucru, folosim două strategii principale pentru reantrenare: reantrenare bazată pe timp și reantrenare bazată pe performanță. Reantrenarea bazată pe timp implică reantrenarea modelului la intervale regulate – de exemplu, în fiecare lună sau trimestru – pentru a asigura faptul că rămâne aliniat cu distribuția curentă a datelor. Reantrenarea bazată pe performanță, pe de altă parte, implică reantrenarea modelului atunci când performanța sa scade sub un prag predefinit. Ambele strategii necesită etichetare automatizată pentru a asigura faptul că modelele reantrenate sunt versionate corect și că linia lor este urmăribilă. Pentru reantrenarea bazată pe timp, etichetăm automat modelul reantrenat cu un sufix care indică ciclul de reantrenare – de exemplu, v2.1.0-reantrenare-202405 pentru un model reantrenat în mai 2024. Această convenție de etichetare asigură faptul că ciclul de reantrenare este urmăribil și că părțile interesate pot identifica rapid cea mai recentă versiune a modelului. Pentru reantrenarea bazată pe performanță, etichetăm automat modelul reantrenat cu un sufix care indică motivul reantrenării – de exemplu, v2.1.0-reantrenare-scădere-performanță dacă acuratețea modelului a scăzut sub un prag. Această convenție de etichetare asigură faptul că motivul reantrenării este documentat și că părțile interesate pot evalua impactul ciclului de reantrenare. În plus, încorporăm metadate de reantrenare în eticheta modelului, cum ar fi metricile de performanță care au declanșat reantrenarea și timestamp-ul ciclului de reantrenare. Aceste metadate sunt critice pentru evaluarea eficacității procesului de reantrenare și pentru depanarea problemelor care pot apărea în producție.

Ultima piesă a puzzle-ului versionării automatizate este integrarea etichetării cu sistemele de monitorizare pentru modelele live. În mediile de producție, modelele trebuie monitorizate continuu pentru a asigura faptul că performanța lor rămâne în limite acceptabile și că nu prezintă semne de derivă sau degradare. Pentru a realiza acest lucru, integrăm sistemul nostru de etichetare automatizată cu instrumente de monitorizare precum Prometheus, Grafana sau dashboard-uri personalizate, care urmăresc performanța modelului în timp real. Când un model este implementat, sistemul de monitorizare îl etichetează automat cu timestamp-ul implementării și începe să urmărească metricile sale de performanță, cum ar fi acuratețea, latența și rata de eroare. Dacă performanța modelului scade sub un prag predefinit, sistemul de monitorizare declanșează o alertă și etichetează automat modelul cu un sufix care indică problema – de exemplu, v2.1.0-performanță-degradată. Această convenție de etichetare asigură faptul că problemele de performanță sunt documentate și că părțile interesate pot identifica și remedia rapid aceste probleme. În plus, sistemul de monitorizare poate declanșa proceduri automate de reantrenare sau revenire pe baza performanței modelului. De exemplu, dacă acuratețea modelului scade cu 5% sau mai mult, sistemul de monitorizare poate declanșa automat un ciclu de reantrenare și poate eticheta modelul reantrenat cu o nouă versiune. Această integrare asigură faptul că modelele sunt întotdeauna aliniate cu distribuția curentă a datelor și că performanța lor este optimizată continuu. De exemplu, în platforma eDezvoltator.ro, am integrat sistemul de monitorizare cu pipeline-ul nostru de etichetare automatizată pentru a asigura faptul că modelul de predicție a prețurilor proprietăților rămâne precis chiar și pe măsură ce piața imobiliară evoluează. Când performanța modelului s-a degradat din cauza unei schimbări în distribuția datelor, sistemul de monitorizare a declanșat automat un ciclu de reantrenare și a etichetat modelul reantrenat cu o nouă versiune, asigurându-se că predicțiile platformei rămân fiabile.

Etichetarea automatizată a versiunilor modelelor nu este doar o necesitate tehnică – este un facilitator strategic pentru MLOps, asigurându-se că modelele sunt urmăribile, reproducibile și implementabile cu risc minim. Prin utilizarea versionării semantice, a etichetelor bogate în metadate și a automatizării bazate pe reguli, am transformat versionarea dintr-un proces manual, predispus la erori, într-un flux de lucru fără probleme, determinist, care se scalează cu complexitatea sistemelor moderne de învățare automată. Beneficiile acestei abordări sunt evidente în proiectele noastre, de la sistemul UVPA, unde etichetarea automatizată asigură conformitatea și fiabilitatea într-un mediu de administrație publică cu mize ridicate, până la sistemul de diagnosticare tehnică, unde versionarea dinamică permite iterații și implementări rapide. Pe măsură ce învățarea automată continuă să evolueze, necesitatea sistemelor robuste de versionare automatizată va crește doar, în special în scenarii care implică modele multi-modale, învățare federată sau aplicații sensibile la conformitate. Prin adoptarea etichetării automatizate, organizațiile pot reduce riscurile, îmbunătăți colaborarea și accelera implementarea soluțiilor de AI, conducând în final la o valoare mai mare a investițiilor lor în învățarea automată.