Arhitectura unei platforme ML: feature store, model registry, serving

Lecțiile anterioare din Modulul 10 au parcurs preocupările transversale pe care orice platformă matură trebuie să le acopere: deployment multi-region, high availability, compliance. Lecția aceasta aplică aceeași lentilă platformei ML. Acum cinci ani, o „platformă de machine learning” însemna orice formă pe care o asamblase cea mai mare echipă din companie din script-uri Python, bucket-uri S3 și un job Jenkins care pornea o rulare de antrenament. Până în 2026, arhitectura s-a standardizat. Vocabularul e comun, straturile sunt recognoscibile între companii, iar întrebarea build-versus-buy pentru fiecare strat are un răspuns defendabil pentru majoritatea echipelor.

Lecția aceasta este turul arhitectural al acelor straturi. Modulul 9 al cursului de Python acoperă munca de modelare propriu-zisă; Modulul 10 acoperă specificul deep learning. Preocuparea arhitecturală e diferită. Nu e „ce model să antrenezi”, ci „care e substratul care permite unei echipe să antreneze, să facă deploy, să monitorizeze și să reantreneze modele fără ca fiecare pas să fie un efort eroic punctual”. Cu acel substrat, modelele devin un tip normal de artefact software, cu un pipeline previzibil de la idee la producție.

Cele cinci straturi

flowchart LR
    DW[(Data warehouse / lakehouse)] --> FS_off[Feature store: offline]
    FS_off --> Train[Training pipeline]
    Train --> Track[Experiment tracking]
    Track --> Reg[Model registry]
    Reg --> Serve[Serving: real-time / batch / streaming]
    FS_on[Feature store: online] --> Serve
    DW --> FS_on
    Serve --> Mon[Monitoring: drift, decay, latency]
    Mon -.retraining trigger.-> Train

Fluxul se citește de la stânga la dreapta. Data warehouse-ul sau lakehouse-ul din Modulul 5 e sursa de adevăr din amonte. Feature-urile sunt calculate o singură dată și stocate în două fețe ale feature store-ului: o față offline pentru antrenament și o față online cu latență mică pentru inferență. Pipeline-urile de antrenament trag feature-uri offline, rulează experimente urmărite într-un sistem care captează cod, date, parametri și metrice, și produc artefacte de model care sunt înregistrate cu metadate de versiune. Infrastructura de serving consumă registry-ul plus feature store-ul online și expune predicții către aplicații. Monitorizarea închide bucla, urmărind drift-ul de input și degradarea outputului, și trimițând semnale înapoi spre reantrenare.

Fiecare cutie e un strat cu un vocabular, un set de unelte standard și un calcul build-versus-buy.

Feature store

Feature store-ul e inovația arhitecturală care a făcut restul stivei posibilă de raționat. Treaba lui e să centralizeze calculul, stocarea și servirea feature-urilor astfel încât același feature să fie calculat în același fel la antrenament și în producție.

Bug-ul pentru care a fost construit are un nume: train-serve skew. Echipa de data science calculează un feature într-un notebook împotriva warehouse-ului, cu o anumită definiție SQL, o anumită tratare a null-urilor, un anumit timezone pentru aritmetica de date. Modelul e antrenat, evaluat și aprobat. Echipa de engineering reimplementează apoi același feature într-un serviciu de producție, într-un alt limbaj, cu o tratare subtil diferită a null-urilor. Modelul în producție vede input-uri care arată aproape, dar nu chiar, ca datele de antrenament, iar predicțiile se degradează în moduri greu de detectat pentru că modelul încă returnează numere care par rezonabile. Soluția arhitecturală e să muți calculul feature-urilor într-un singur strat pe care îl consumă atât antrenamentul, cât și serving-ul.

Un feature store are de obicei două fețe:

Offline store. Înregistrarea istorică a valorilor feature-urilor. Susținut de un tabel din warehouse sau lakehouse, optimizat pentru citiri batch la momentul antrenamentului. Pipeline-ul de antrenament cere „feature X pentru aceste entity ids la aceste timestamp-uri” și primește înapoi un dataframe, cu point-in-time correctness păstrat (valoarea feature-ului așa cum era cunoscută la timestamp-ul cerut, nu cum e cunoscută acum).
Online store. Cea mai recentă valoare a fiecărui feature, indexată după entity id, optimizată pentru lookup-uri cu latență mică la momentul inferenței. Susținut de un key-value store (lecția 18) precum Redis, DynamoDB sau un serviciu construit special.

Definiția feature-ului e contractul între cele două. O singură definiție de feature produce atât batch fill-ul istoric în offline store, cât și refresh-ul streaming sau programat al online store-ului, deci pipeline-ul de antrenament și pipeline-ul de serving au garanția că văd aceeași logică.

Opțiunile majore în 2026: Feast (feature store-ul open-source dominant, ușor și agnostic față de framework-uri), Tecton (gestionat, de la echipa care a construit Michelangelo de la Uber, cu stream feature engineering ca preocupare de prim rang), Databricks Feature Store (împachetat cu Databricks și integrat cu Unity Catalog și MLflow) și AWS SageMaker Feature Store (opțiunea native AWS). Aritmetica build-versus-buy se potrivește cu lecția 71. O echipă cu doi data scientists și un ML engineer n-ar trebui să construiască un feature store; ar trebui să adopte Feast sau ce oferă vendorul lor de cloud. O echipă care rulează mii de modele cu stream features și cerințe de latență mică poate avea cu adevărat nevoie să construiască, sau să cumpere o opțiune mai grea precum Tecton.

Experiment tracking

Fiecare rulare de antrenament produce un experiment: o combinație de cod la un anumit commit, date la un anumit snapshot, hiperparametri, metrice de antrenament, metrice de evaluare și artefactul de model rezultat. Experiment tracking-ul e stratul care captează toate acestea, le indexează și le face căutabile.

Motivul pentru care e o preocupare de platformă și nu o preocupare de notebook e reproductibilitatea la nivel de echipă. Fără tracking, „modelul pe care l-am livrat trimestrul trecut” e un binar pe laptop-ul cuiva, cu o amintire vagă despre cum a fost antrenat. Cu tracking, același model e un rând într-o bază de date cu link-uri la codul exact, datele și metricele, iar reproducerea lui e un click pe buton.

Componenta de tracking a MLflow a devenit standardul open-source. Weights and Biases e alternativa comercială populară, cu funcționalități de colaborare mai puternice. Neptune și Comet ocupă nișe similare. Ofertele vendor-ilor de cloud (SageMaker Experiments, Vertex AI Experiments) acoperă bazele pentru echipele deja în interiorul unui cloud. Tracker-ul trebuie să scaleze la volumul de rulări pe care îl produce echipa și trebuie să se integreze cu feature store-ul și registry-ul de o parte și de alta; majoritatea echipelor subinvestesc aici până în ziua în care o cădere a tracker-ului blochează tot pipeline-ul ML.

Model registry

Registry-ul e sursa de adevăr pentru ce modele există, ce versiuni ale fiecăruia, care e descendența lor și ce versiune e momentan deployată unde. Un model în registry e un tuplu: nume, versiune, referință la rularea de antrenament, semnătură, metrice, etapă (development, staging, production, archived) și metadate despre datele de antrenament și cod.

MLflow Model Registry e din nou standardul de facto open-source, iar vendorii de cloud au fiecare al lor. Valoarea arhitecturală e aceeași ca pentru orice sursă de adevăr: fiecare alt strat al platformei se referă la registry, nu la o cale pe disc. Serving-ul cere registry-ului „versiunea de producție a modelului X”. Monitorizarea cere „metricele care au fost promise la momentul antrenamentului, ca să le pot compara cu ce vedem acum”. Registry-ul e și locul unde trăiește guvernanța: un model promovat în producție trebuie să fi trecut verificări asupra descendenței datelor de antrenament, pragurilor de evaluare, completitudinii model card-ului și planurilor de deployment, iar registry-ul e locul unde acele verificări sunt impuse și înregistrate.

Serving

Serving-ul e locul unde modelul întâlnește aplicația. Alegerile arhitecturale se încadrează în trei pattern-uri, fiecare cu propria formă de infrastructură.

Real-time inference. Modelul e împachetat într-un serviciu care expune un endpoint REST sau gRPC. O aplicație trimite un vector de feature-uri sau o cerere pe care serviciul o îmbogățește cu feature-uri din online store, iar serviciul returnează o predicție în zeci de milisecunde. Acesta e pattern-ul pentru personalizare, detectare de fraudă, ranking în search și orice suprafață cu utilizator.
Batch inference. Modelul rulează după un program pe un set mare de date de input și scrie predicțiile într-un tabel din warehouse sau în object storage. Acesta e pattern-ul pentru a scora toți clienții peste noapte, a genera recomandări pentru o campanie de email sau orice caz în care bugetul de latență e în ore, nu în milisecunde.
Streaming inference. Modelul consumă evenimente dintr-un topic Kafka (lecția 42), le îmbogățește cu feature-uri online, face o predicție și scrie predicția înapoi într-un alt topic. Acesta e pattern-ul pentru cazurile în care deciziile trebuie luate pe măsură ce evenimentele sosesc, dar consumatorul e el însuși un sistem din aval, nu un utilizator.

Uneltele acoperă o gamă largă. SageMaker, Vertex AI și Azure ML sunt opțiunile gestionate de cloud. BentoML și KServe sunt framework-uri open-source de serving care se integrează în Kubernetes (lecția 55). Seldon și Triton ocupă nișe similare, Triton fiind în mod special puternic pentru inferență pe GPU. Punctul arhitectural neevident: stratul de serving e infrastructură de aplicație, nu infrastructură de date. Cerințele lui de uptime, latență și capacitate se aliniază cu aplicația pe care o servește, nu cu warehouse-ul împotriva căruia a fost antrenat, iar granița dintre proprietatea echipei de date și proprietatea echipei de aplicație trebuie să reflecte asta.

Monitoring

Monitorizarea închide bucla. Sunt trei preocupări distincte.

Input drift. Distribuția input-urilor către model se schimbă în timp. Clienții care se înregistrează azi nu sunt clienții de pe vremea când a fost antrenat modelul. Feature-urile s-au deplasat, iar predicțiile modelului pe distribuția deplasată pot fi mai slabe decât erau predicțiile pe distribuția de antrenament. Detectarea drift-ului rulează teste statistice pe feature-urile de input împotriva distribuției de antrenament și alertează când divergența traversează un prag.

Output decay. Predicțiile modelului sunt încă în forma corectă, dar calitatea s-a degradat. Asta necesită ground truth, care adesea sosește târziu (predicția era despre dacă un utilizator va face churn; ground truth-ul e dacă a făcut efectiv churn, observabil treizeci de zile mai târziu). Monitorizarea output decay-ului compară predicțiile cu ground truth-ul pe o fereastră glisantă și alertează când acuratețea, precizia, recall-ul sau o altă metrică relevantă pentru business scade.

Performance. Latență, throughput, rata de eroare. Aceleași preocupări de observability pe care le are restul platformei (lecția 59), cu preocuparea suplimentară că latența unui model ML tinde să fie mai variabilă decât cea a unui serviciu tipic, pentru că distribuția de input afectează calea de inferență.

Uneltele dedicate observabilității ML includ Arize, WhyLabs, Evidently (open-source) și Fiddler. Unele echipe construiesc bazele peste stiva lor existentă de observability (Prometheus, Datadog, Grafana) și adoptă o unealtă dedicată doar când volumul o justifică. Principiul arhitectural e același ca în altă parte: stratul de monitorizare trebuie să trimită feedback înapoi în pipeline-ul de reantrenare, astfel încât drift-ul sau decay-ul să deschidă automat un ticket, să declanșeze o rulare de reantrenare sau, în setup-urile cele mai automatizate, să programeze un refresh al modelului.

Calculul build-versus-buy, din nou

Pattern-ul din lecția 71 se repetă aici, strat cu strat. O echipă mică ce rulează o mână de modele ar trebui să cumpere sau să adopte unelte gestionate pe toată stiva: feature store-ul unui vendor de cloud, MLflow pentru tracking și registry, infrastructura de serving a cloud-ului, o unealtă de monitoring open-source. Cumpărarea e default-ul; povara de mentenanță a rulării platformei tu însuți e mai grea decât pare, iar costul vendor lock-in-ului la scară mică e mic.

O echipă care rulează sute de modele cu serving cu latență mică și stream features începe să vadă calculul cum se schimbă, iar o echipă la scara Uber sau Netflix a construit întregul sistem, pentru că la scara lor nici măcar ofertele gestionate nu sunt construite pentru ei. Platforma Michelangelo despre care a publicat Uber (lecția 48) și ecosistemul Metaflow al Netflix sunt artefactele tip studiu de caz. Lecția nu e „construiește-ți propria platformă ML”. Lecția e că straturile sunt reale, vocabularul e comun, iar forma arhitecturală e recognoscibilă în întreaga industrie. O echipă care cunoaște straturile poate citi un anunț de job, un blog de engineering sau un pitch de vendor și înțelege ce se descrie, iar acesta e ștacheta pe care o țintește cursul.

Referințe încrucișate

Platforma ML stă deasupra a aproape tot ce au introdus Modulele 5 până la 9. Data warehouse-ul și lakehouse-ul din lecțiile 33 până la 40 sunt amontele feature store-ului. Infrastructura de streaming din lecțiile 41 până la 48 e ce călărește stream features. Stratul de orchestrare din lecțiile 57 și 58 programează antrenamentul și inferența batch. Practicile de observability și SLO din lecțiile 59 și 60 se aplică direct straturilor de serving și monitoring. Munca de optimizare a costurilor din Modulul 9 e ce ține factura GPU să nu se dubleze în fiecare trimestru. Lecția următoare e capstone-ul cursului.

Citări și lectură suplimentară

Feast project, https://feast.dev/ (consultat 2026-05-01). Feature store-ul open-source dominant.
MLflow project, https://mlflow.org/ (consultat 2026-05-01). Standardul de facto open-source pentru tracking și registry.
Tecton, https://www.tecton.ai/ (consultat 2026-05-01). Feature store gestionat de la echipa Michelangelo.
Uber Engineering, “Meet Michelangelo: Uber’s Machine Learning Platform”, https://www.uber.com/blog/michelangelo-machine-learning-platform/ (consultat 2026-05-01). Studiul de caz care a pus feature store-urile pe harta industriei.
Netflix Tech Blog, “Metaflow: Open-source framework for real-life ML”, https://netflixtechblog.com/ (consultat 2026-05-01). Cealaltă platformă ML majoră publicată.
Chip Huyen, “Designing Machine Learning Systems”, O’Reilly, 2022. Referința de manual pentru preocupările arhitecturale acoperite de această lecție.
Evidently AI documentation on ML monitoring, https://docs.evidentlyai.com/ (consultat 2026-05-01). Unealta open-source de monitoring care merită cunoscută chiar dacă o echipă folosește altceva.