1. Per què parlar de nivells de maduresa
2. Nivell 0: procés manual
3. Nivell 1: pipeline d'entrenament automatitzat
4. Nivell 2: CI/CD complet per a ML
5. Taula comparativa i autodiagnòstic
6. Els rols de l'equip de ML
7. Com col·laboren a la pràctica: handoffs i ownership compartit
8. CineClick: nivell 0 amb bitllet cap al nivell 2

Els nivells de maduresa que veurem són una síntesi, explicada amb les nostres paraules, dels models que van publicar Google (tres nivells: 0, 1 i 2) i Microsoft (una escala més granular de cinc nivells, que en essència descriu el mateix camí amb més esglaons). No són un estàndard oficial ni un examen que calgui aprovar: són un llenguatge comú per respondre preguntes molt pràctiques:

• On som avui i què ens falta?
• Quina inversió té sentit fer ara? (Saltar de 0 a 2 de cop sol fracassar.)
• Quin nivell necessita realment el nostre cas? No tots els equips necessiten el nivell màxim.

La idea que ordena els nivells és simple: què està automatitzat? Al nivell 0, res. Al nivell 1, l'entrenament. Al nivell 2, també la integració i el desplegament dels mateixos pipelines.

És el punt de partida de gairebé tots els equips, i no és cap vergonya: és el natural quan es comença. Els seus trets:

• Tot el flux és manual i interactiu: les dades s'extreuen a mà, l'entrenament passa en notebooks, el "millor model" es tria mirant resultats a ull.
• Desconnexió entre qui entrena i qui opera: el data scientist lliura un fitxer de model (un .pkl, per exemple) i un altre equip —o ningú— el posa a servir. El lliurament és l'artefacte, no el procés.
• Desplegaments infreqüents: el model s'actualitza poques vegades l'any, perquè cada actualització és un projecte manual.
• Sense monitoratge del model: es vigila, com a molt, que el servei no caigui. Ningú no mesura si les prediccions continuen sent bones.
• Sense registre sistemàtic: els experiments, dades i decisions viuen en carpetes personals i a la memòria de la gent.

El risc característic del nivell 0 és la degradació silenciosa: com que reentrenar és car i no hi ha monitoratge, el model envelleix en producció fins que el negoci nota que alguna cosa va malament — setmanes o mesos després que comencés a fallar.

Quan és acceptable quedar-se aquí? Per a prototips, proves de concepte o models que s'utilitzen una sola vegada. Tan bon punt un model s'utilitza de manera recurrent i el negoci en depèn, el nivell 0 es converteix en un deute.

El salt qualitatiu del nivell 1 és aquest: el que es desplega ja no és un model, sinó un pipeline que produeix models. En lloc de lliurar un .pkl, l'equip lliura un procés automatitzat que va de les dades al model validat sense intervenció manual.

Què implica a la pràctica:

• Pipeline d'entrenament executable de principi a fi: extracció i validació de dades, preprocessament, entrenament, avaluació i validació del model, tot encadenat i parametritzat (la construcció d'aquests pipelines és el tema del mòdul 2, i la seva orquestració es completa al mòdul 5).
• Entrenament continu (CT, continuous training): el pipeline es pot executar amb freqüència —per calendari o disparat per dades noves— i produir models frescos de manera rutinària.
• Simetria entre experimentació i producció: el codi que es fa servir per experimentar és el mateix que corre en producció, cosa que exigeix que la fase experimental ja treballi amb codi modular i versionat, no amb notebooks solts.
• Validació automàtica de dades i de model: el pipeline comprova que les dades d'entrada tenen la pinta esperada i que el model nou supera llindars abans de publicar-se.
• Registre d'experiments i de models: cada execució queda traçada (mòdul 3).

El que el nivell 1 no resol: el pipeline en si es desplega a mà. Si l'equip canvia el codi del pipeline (una feature nova, un altre algorisme), provar i desplegar aquesta nova versió del pipeline continua sent un procés manual. Amb pocs pipelines i pocs canvis, és assumible; quan hi ha molts models o molt canvi, apareix el coll d'ampolla que motiva el nivell 2.

Al nivell 2, també el cicle de vida del mateix pipeline està automatitzat. És el nivell d'organitzacions que operen molts models o que necessiten iterar-hi amb rapidesa i garanties.

Els seus components, explicats sense entrar en el detall que correspon al mòdul 5:

• Integració contínua (CI): cada canvi al codi dispara automàticament la construcció i les proves — i en ML les proves van més enllà del codi: es testen també les dades i el comportament dels models.
• Desplegament continu (CD): les noves versions del pipeline (i els models que produeix) arriben a producció mitjançant un procés automatitzat, amb validacions i sense rituals manuals.
• Tot el cicle instrumentat: monitoratge del servei i del model, amb la possibilitat que una alerta de degradació dispari automàticament un reentrenament (mòdul 6).
• Desplegaments freqüents i de baix risc: actualitzar un model passa de ser "el projecte del trimestre" a un esdeveniment rutinari, gràcies a estratègies de release progressives (que veurem al mòdul 5).

Matís important: el nivell 2 no vol dir "sense humans". Les decisions crítiques —aprovar un model per a producció, validar que un comportament és acceptable— continuen tenint punts d'aprovació humana. El que s'automatitza és tot allò mecànic al voltant d'aquestes decisions, perquè siguin informades, ràpides i traçables.

Per autodiagnosticar el teu equip, fes-te aquestes preguntes en ordre; la primera resposta "no" et diu el teu nivell:

1. Podeu reentrenar i publicar un model executant un procés automatitzat, sense passos manuals? Si no → nivell 0.
2. Un canvi al codi del pipeline arriba a producció mitjançant CI/CD (tests automàtics + desplegament automatitzat)? Si no → nivell 1.
3. Si totes dues són sí → nivell 2 (a la pràctica, un espectre dins del nivell 2: quant monitoratge, quant reentrenament automàtic...).

Dos consells sobre el diagnòstic: sigues honest (el nivell es mesura pel que passa, no pel que "podríem fer"), i recorda que diferents models de la mateixa organització poden estar en nivells diferents — el nivell és del sistema, no de l'empresa.

La maduresa no la construeixen les eines sinó les persones. Aquests són els rols habituals en un equip que opera ML en producció. Compte: són rols, no necessàriament persones diferents — en equips petits una persona en cobreix diversos; en organitzacions grans cada rol pot ser un equip sencer.

Algunes observacions que la taula no captura:

• L'ML engineer és el rol frontissa i el més "nou" de la llista: va néixer precisament de la bretxa notebook→producció. Comparteix llenguatge amb el data scientist (entén de models) i amb plataforma (entén de sistemes). Gran part d'aquest curs és, de fet, el temari d'un ML engineer.
• El data engineer treballa "aigües amunt" del model, però la seva feina condiciona tota la resta: la majoria dels incidents de ML en producció són, en origen, incidents de dades.
• Negoci no és un rol decoratiu: sense algú que defineixi què vol dir "funcionar" en euros o en clients retinguts, l'equip optimitza mètriques de ML en el buit. I com vam veure, les decisions d'acceptació de risc i aprovació final són humanes i solen ser seves.

Conèixer els rols no n'hi ha prou: els problemes reals apareixen a les fronteres entre ells. Hi ha dues maneres d'organitzar aquestes fronteres:

Model de handoffs (relleus): cada rol treballa la seva etapa i "llança el resultat per sobre del mur" al següent. El data scientist lliura un notebook a l'ML engineer, que el reescriu i lliura un contenidor a plataforma, que el desplega. És el model per defecte en organitzacions que separen equips per especialitat, i té problemes coneguts:

• Pèrdua d'informació a cada relleu: l'ML engineer reimplementa el preprocessament i alguna cosa canvia subtilment; el model de producció no es comporta com el del notebook.
• Cicles lents: cada millora del model ha de recórrer tota la cadena de relleus.
• Ningú no és propietari del resultat final: quan el model falla en producció, cada equip mira el del costat.

Model d'ownership compartit: un equip multidisciplinari és propietari del sistema de ML d'extrem a extrem — de la dada a la predicció monitorada. Els rols continuen existint, però comparteixen repositori, pipeline i responsabilitat de guàrdia. Les pràctiques que ho fan possible:

• Artefactes comuns en lloc de lliuraments: no es lliura "un notebook" sinó que tothom treballa sobre el mateix repositori versionat, el mateix pipeline i el mateix registre de models. L'eina compartida és el contracte.
• Contractes explícits on hi ha frontera inevitable: per exemple, un esquema de dades acordat i validat automàticament entre data engineering i el pipeline d'entrenament — així els canvis de dades trenquen un test, no el model en producció.
• Revisió creuada: l'ML engineer revisa el codi de features del data scientist; el data scientist revisa que el servei implementi el preprocessament correcte.
• Responsabilitat d'operació compartida: qui construeix el model participa a vigilar-lo. Res no millora tant la qualitat d'un pipeline com que el seu autor rebi les alertes.

La progressió de maduresa i la col·laboració es reforcen mútuament: les eines dels nivells 1 i 2 (pipelines, registres, CI/CD) són precisament el que substitueix els relleus informals per artefactes compartits i verificables.

Fem el diagnòstic de CineClick amb les preguntes d'autodiagnòstic:

• Pot reentrenar i publicar amb un procés automatitzat? No: el model viu en un notebook al portàtil de la data scientist, les dades s'extreuen a mà i no hi ha procés de desplegament en absolut. → Nivell 0 de manual.
• Rols: hi ha una data scientist (la nostra protagonista), un data engineer que manté les bases de dades de la plataforma, i un petit equip de plataforma que opera la web de CineClick però mai no ha desplegat un model. No hi ha ML engineer... encara: aquest és el rol que tu, com a estudiant, exerciràs durant el curs.

El pla del curs és, literalment, l'escala de maduresa:

• Mòduls 2 i 3 construeixen els fonaments del nivell 1: codi estructurat i reproduïble, dades versionades, pipeline d'entrenament, experiments i models registrats.
• Mòdul 4 afegeix el que el nivell 1 pressuposa per servir: el model desplegat com a servei real.
• Mòdul 5 fa el salt al nivell 2: CI/CD per al codi, les dades i els models, i orquestració dels pipelines.
• Mòdul 6 completa el nivell 2 pel costat de l'operació: monitoratge, deriva i reentrenament automatitzat.

No memoritzis aquest pla: el veuràs desplegat amb detall (dataset, notebook inicial i stack d'eines inclosos) a la propera lliçó.

• Error: intentar saltar del nivell 0 al 2 d'una vegada. Muntar tota la plataforma de cop, sense haver consolidat abans un pipeline reproduïble, sol produir una infraestructura complexa que ningú no fa servir. Puja l'escala esglaó a esglaó; aquest curs està ordenat així a propòsit.
• Error: tractar el nivell 2 com a objectiu universal. Un equip amb un únic model que es reentrena dues vegades l'any pot viure perfectament en un nivell 1 ben fet. El nivell adequat depèn del nombre de models, la freqüència de canvi i el cost de la degradació — no del prestigi.
• Error: confondre "tenim les eines" amb "tenim la maduresa". Instal·lar un orquestrador i un registre de models no et puja de nivell si el procés real continua sent manual. El nivell es mesura per com va arribar a producció l'últim model, no per l'stack instal·lat.
• Error: contractar rols sense definir fronteres. Incorporar un ML engineer a un equip que continua treballant per relleus de notebooks només afegeix un relleu més. Defineix primer els artefactes compartits (repositori, pipeline, registre) i les responsabilitats sobre ells.
• Consell: en equips petits, no et preocupis per cobrir cinc rols amb cinc persones; preocupa't que les cinc responsabilitats tinguin un propietari explícit. Una taula de dues columnes (responsabilitat → persona) evita el clàssic "em pensava que això ho miraves tu".

Diagnostica el nivell de maduresa d'aquests tres equips i justifica la resposta:

1. Equip A: cada dilluns, un job programat reentrena el model amb les dades de la setmana, valida automàticament que supera el model vigent i, si és així, el publica al registre de models. Tanmateix, quan l'equip va voler afegir una feature nova el mes passat, va trigar tres setmanes: es va haver de provar el pipeline modificat a mà en una màquina de staging i desplegar-lo copiant fitxers.
2. Equip B: el model es reentrena "quan algú té una estona": la data scientist descarrega un extracte de la base de dades, executa el seu notebook, i si les mètriques li semblen bé envia el fitxer del model pel xat intern a l'enginyer, que el copia al servidor.
3. Equip C: cada push al repositori dispara tests de codi, de dades i de model; si passen, el pipeline actualitzat es desplega sol, i les alertes de deriva poden disparar un reentrenament automàtic que publica el model després d'una aprovació humana registrada.

A CineClick, la data scientist ha creat al seu notebook una feature molt predictiva: ratio_visualitzacio (hores vistes / hores de contingut nou publicat al seu pla). Lliura el notebook al futur ML engineer perquè la porti a producció. Descriu: (1) almenys dos problemes que pot causar aquest handoff tal com està plantejat, i (2) com ho organitzaria un equip amb ownership compartit i contractes explícits.

Assigna cada tasca al rol que hauria de liderar-la (data scientist, data engineer, ML engineer, plataforma/DevOps, negoci/product owner). Alguna tasca pot requerir la col·laboració de dos rols; indica-ho:

1. Decidir si un recall del 70% a la classe "abandona" és suficient per llançar la campanya de retenció.
2. Investigar per què el model falla més amb els clients que paguen amb PayPal.
3. Garantir que la taula de tiquets de suport arriba cada nit completa i amb l'esquema acordat.
4. Reduir el temps d'arrencada dels contenidors del servei de predicció al clúster.
5. Convertir el preprocessament del notebook en un mòdul Python testat que facin servir tant l'entrenament com el servei.

Solució 1:

1. Equip A: nivell 1. L'entrenament està completament automatitzat, amb validació i publicació incloses (això descarta el nivell 0). Però l'evolució del pipeline és manual —proves a mà, desplegament copiant fitxers—, que és exactament la limitació que defineix la frontera amb el nivell 2. Les tres setmanes per afegir una feature són el símptoma del coll d'ampolla característic del nivell 1.
2. Equip B: nivell 0. Procés manual de principi a fi, entrenament en notebook, lliurament de l'artefacte per xat, desplegament copiant el fitxer, sense validació sistemàtica ni traçabilitat. És el nivell 0 de llibre, incloent-hi la desconnexió entre qui entrena i qui opera.
3. Equip C: nivell 2. CI amb tests de codi, dades i model; CD del pipeline; i monitoratge connectat al reentrenament. Fixa't que l'aprovació humana abans de publicar no el fa baixar de nivell: el nivell 2 automatitza allò mecànic, no elimina les decisions humanes.

Solució 2:

1. Problemes del handoff: (a) Reimplementació divergent: l'ML engineer haurà de reescriure el càlcul de ratio_visualitzacio per a producció i qualsevol diferència subtil (hores de quina finestra temporal? què compta com a "contingut nou"?) farà que el model en producció vegi features diferents de les d'entrenament i rendeixi pitjor sense error visible. (b) Pèrdua de context: les decisions que la data scientist va prendre explorant (per què aquesta fórmula, quins casos límit va descartar, com va tractar les divisions per zero) no viatgen amb el notebook. (c) Cicle lent: cada ajust futur de la feature repetirà tot el relleu.
2. Amb ownership compartit: la feature viuria des del principi al repositori comú com una funció Python amb els seus tests (no en una cel·la de notebook); la data scientist i l'ML engineer la revisarien mútuament; i el mateix codi es faria servir al pipeline d'entrenament i al servei de predicció, eliminant la divergència per construcció. Si el càlcul depèn de dades que prepara el data engineer, hi hauria un contracte d'esquema validat automàticament. (Com estructurar aquest codi compartit és justament el tema amb què obre el mòdul 2.)

Solució 3:

1. Negoci/product owner, amb l'anàlisi del data scientist sobre què significa aquest 70% (a quants clients arriba, quants falsos positius genera). La decisió de risc és de negoci; els números que la informen, del data scientist.
2. Data scientist: és anàlisi d'errors del model per subgrups. Pot necessitar el data engineer si la causa resulta ser un problema de qualitat de la dada de metode_pagament.
3. Data engineer: la fiabilitat, la completesa i l'esquema d'una font de dades són el seu terreny natural.
4. Plataforma/DevOps, en col·laboració amb l'ML engineer (que coneix el contingut del contenidor i en pot reduir la mida o les dependències).
5. ML engineer: és la conversió de codi exploratori en codi de producció compartit — la seva missió definitòria. Idealment amb la revisió de la data scientist autora del preprocessament.

En aquesta lliçó hem guanyat dos mapes. El primer, vertical: els nivells de maduresa MLOps — nivell 0 (tot manual, el model com a fitxer que algú copia), nivell 1 (el pipeline d'entrenament automatitzat com a lliurable) i nivell 2 (CI/CD també per als mateixos pipelines, amb l'operació instrumentada) — juntament amb un mètode d'autodiagnòstic honest. El segon, horitzontal: els rols de l'equip (data scientist, data engineer, ML engineer, plataforma i negoci) i la diferència entre col·laborar per relleus, on la informació es perd a cada mur, i fer-ho amb ownership compartit sobre artefactes comuns. I hem deixat CineClick diagnosticat: nivell 0, sense ML engineer, amb un model de churn atrapat en un notebook — i amb aquest curs com a pla per portar-lo al nivell 2.

Amb els fonaments complets, toca baixar del mapa al territori. A la propera lliçó coneixerem el projecte del curs amb detall: el context de negoci del churn a CineClick, el dataset clients_churn.csv columna a columna, el notebook inicial complet de la data scientist —amb tots els seus pecats—, i l'stack d'eines amb què el transformarem mòdul a mòdul.