A la lliçó anterior vam veure per què la majoria dels models moren al notebook i què aporta MLOps. Ara toca dibuixar el mapa complet: quines etapes travessa un model des que algú detecta un problema de negoci fins que les seves prediccions s'utilitzen —i es vigilen— en producció? Entendre aquest cicle de vida és imprescindible, perquè cada mòdul del curs equipa una de les seves etapes amb eines i automatització. A més, veurem una idea que estructura tot el MLOps: en ML no versionem un artefacte sinó tres (codi, dades i model), i cadascun evoluciona al seu propi ritme.

1. Visió general: un cicle, no una línia recta
2. Les etapes del cicle de vida, una per una
3. Els tres artefactes versionables i els seus ritmes de canvi
4. Els bucles de realimentació
5. Cicle de vida del programari clàssic vs. cicle de vida de ML

La paraula clau és cicle. Un projecte de ML no s'acaba quan el model es desplega; en cert sentit, és aleshores quan comença. El model en producció genera dades i evidència que alimenten la volta següent: reentrenaments, noves features, fins i tot la redefinició del problema.

Aquest és el cicle complet que anirem desgranant:

Fixa't que hi ha tres camins de tornada: el reentrenament rutinari (amb dades fresques), la tornada a la preparació de dades (quan calen noves features o correccions) i, en casos extrems, la tornada a la definició del problema (quan el negoci canvia tant que el plantejament original ja no serveix).

Recorrem cada etapa fent servir CineClick com a il·lustració conceptual. Recorda que aquí descrivim què passa a cada etapa; les eines concretes es veuen als mòduls indicats.

Tot comença (o hauria de començar) amb una pregunta de negoci, no amb un algorisme. A CineClick, la pregunta és: "perdem subscriptors cada mes; podem saber qui se n'anirà per intentar retenir-lo?".

En aquesta etapa es decideix:

• L'objectiu de negoci: reduir el churn mensual, per exemple del 5% al 4%.
• La traducció a un problema de ML: classificació binària — donat un subscriptor, predir si abandonarà en els propers 30 dies.
• Les mètriques d'èxit, en dos nivells: la mètrica de ML (per exemple, el recall sobre la classe "abandona") i la mètrica de negoci (baixes evitades, ingressos retinguts). Un model pot millorar la primera sense moure la segona; totes dues s'han de definir abans d'entrenar res.
• Les restriccions operatives: necessitem prediccions en temps real o n'hi ha prou amb una llista diària? Quina latència i quin cost són acceptables? Aquestes decisions condicionaran el patró de desplegament (ho veurem al mòdul 4).

És l'etapa més barata de corregir i la més cara de corregir tard: un model excel·lent que respon a la pregunta equivocada és un fracàs car.

Aquí es localitzen les fonts (a CineClick: base de dades de subscripcions, logs de visualització, sistema de tiquets de suport), s'extreuen, es netegen i es transformen en un dataset d'entrenament amb les seves features (antiguitat, hores setmanals, tiquets...) i la seva etiqueta (va abandonar o no?).

Punts clau de l'etapa:

• Sol consumir la major part del temps del projecte (la xifra folklòrica del "80% del temps és preparar dades" és exagerada però apunta bé).
• Definir l'etiqueta és més subtil del que sembla: què compta com a "abandonament"? Cancel·lar? No renovar? I si torna al cap de dos mesos?
• Aquí neix el primer requisit de reproduïbilitat: el dataset exacte utilitzat per entrenar s'ha de poder recuperar després. Del seu versionament se n'ocupa el mòdul 2 (DVC).

L'etapa que tothom associa amb "fer ML": triar algorismes, entrenar, ajustar hiperparàmetres, comparar resultats en un conjunt de prova. És un procés inherentment iteratiu i experimental: desenes o centenars d'execucions amb petites variacions.

Des de l'òptica MLOps, l'important és que cada experiment quedi registrat: quin codi, quines dades, quins paràmetres i quines mètriques. Sense aquest registre, "el millor model" és un record, no un fet. El tracking d'experiments és el tema del mòdul 3 (MLflow).

Abans de desplegar, el model candidat passa un control de qualitat que va més enllà de "bona mètrica en test":

• Validació tècnica: funciona amb el format de dades real? La seva latència i mida són acceptables?
• Validació de comportament: rendeix de manera acceptable en subgrups rellevants (plans premium vs. bàsics, clients nous vs. antics), o la seva bona mètrica global amaga subgrups on falla?
• Comparació amb el model actual: és realment millor que el que ja és en producció (o que una regla simple de negoci)?
• Revisió i aprovació: algú —humà— decideix que el model és apte i en queda constància. Al mòdul 3 veurem com el model registry formalitza aquesta promoció, i al mòdul 5 com automatitzar part d'aquestes comprovacions.

El model validat s'integra allà on el negoci el necessita. Per al churn de CineClick podria ser un procés batch nocturn que puntua tots els subscriptors, o una API que respon en temps real; l'elecció entre batch, online i streaming és justament l'arrencada del mòdul 4, i l'empaquetament i l'escalat (FastAPI, Docker, Kubernetes) el seu desenvolupament.

L'essencial en aquesta etapa, conceptualment: el desplegament ha de ser repetible (no un ritual manual) i reversible (poder tornar al model anterior en minuts si alguna cosa va malament).

El model és en producció; ara cal vigilar-lo en dos plans:

• Com a servei de programari: és viu? Respon a temps? Quants errors dona? (el mateix que qualsevol API).
• Com a model: les dades que rep s'assemblen a les d'entrenament? Les seves prediccions continuen sent bones? Això últim és difícil perquè la veritat arriba amb retard: per saber si un subscriptor "anava a abandonar" cal esperar setmanes.

La degradació silenciosa —deriva de dades i de concepte— i la seva detecció són el cor del mòdul 6.

Tard o d'hora el model queda antiquat i cal reentrenar-lo amb dades fresques. Es pot disparar per calendari (cada mes), per alerta de monitoratge (la deriva va superar un llindar) o manualment. El reentrenament reutilitza les etapes 2-4: per això convé que estiguin automatitzades en un pipeline (mòduls 2 i 5), i per això el cicle és un cicle. El mòdul 6 tracta quan i com automatitzar-lo.

Ja vam avançar a la lliçó anterior que un sistema de ML té tres artefactes canviants. Ara ho podem precisar: cadascun té el seu propi ritme d'evolució, i aquesta asincronia és la raó per la qual necessiten un versionament independent però enllaçat.

Tres observacions importants:

• El model és un artefacte derivat: model = f(codi, dades, configuració). Si versiones el codi i les dades exactes, pots regenerar el model; si només guardes el binari, tens un resultat sense recepta.
• Poden canviar de manera independent: CineClick pot reentrenar el mateix codi amb dades de juny (nou model, mateix codi) o refactoritzar el codi de servei sense tocar el model (nou desplegament, mateix model). Cada combinació necessita la seva traçabilitat.
• La pregunta d'auditoria clau és transversal: "per a la predicció que va fer el sistema el dia X, quina versió del model es va utilitzar, amb quin codi es va entrenar i sobre quines dades?". Tota la cadena d'eines del curs (Git per al codi, DVC per a les dades, MLflow per als models) existeix per poder respondre-la.

Un sistema de ML en producció no només consumeix dades: també en genera. Aquest és el tret que més diferencia el seu cicle de vida del programari clàssic, i té una cara bona i una altra de perillosa.

La cara bona: el model en producció produeix la matèria primera de la seva pròpia millora.

1. El model de CineClick puntua avui cada subscriptor amb el seu risc d'abandonament.
2. Durant les setmanes següents, la realitat "etiqueta" aquests casos: alguns es donen de baixa, d'altres no.
3. Aquestes parelles (features del moment de la predicció, resultat real) són exemples d'entrenament nous i perfectament etiquetats.
4. El reentrenament següent fa servir aquestes dades: el sistema aprèn del present, no només del passat.

Perquè aquest bucle funcioni cal dissenyar-lo: registrar les prediccions amb les seves features en el moment de fer-les, i unir després cada predicció amb el seu resultat real. Si no es registra, la informació es perd i cada reentrenament parteix de zero.

La cara perillosa: si el negoci actua sobre les prediccions, el model contamina les seves pròpies dades futures. És el bucle ocult que vam veure a la lliçó anterior: retenció truca als clients d'alt risc, molts es queden, i les dades futures diuen que aquest perfil "no abandona". Un reentrenament ingenu aprendria justament el contrari de la realitat.

No cal resoldre això avui (hi ha tècniques: registrar quins clients van rebre intervenció, mantenir grups de control...); el que sí que cal des del disseny és saber que el bucle existeix i registrar la informació necessària per tractar-lo. Hi tornarem quan parlem del reentrenament al mòdul 6.

Tanquem el mapa amb la comparació dels dos cicles de vida, que resumeix per què el de ML necessita disciplines addicionals:

La conclusió pràctica: planifica el projecte de ML com un cicle permanent, no com un projecte amb final. Pressupostar només fins al primer desplegament és l'error de planificació més comú en equips que venen del programari tradicional.

• Error: començar per l'etapa 3 (entrenar) saltant-se la 1 (negoci). És temptador anar directe al model. Sense una mètrica de negoci definida, no sabràs si el model serveix, només si encerta. Escriu l'objectiu de negoci i la seva mètrica abans de la primera línia de codi.
• Error: tractar la validació com "mirar l'accuracy en test". La validació pre-producció inclou subgrups, latència, comparació amb el model vigent i aprovació explícita. Un model amb millor mètrica global pot ser pitjor per al negoci si falla en el segment que més importa.
• Error: no registrar les prediccions de producció. Sense aquest registre no hi ha bucle de realimentació bo: no podràs construir datasets frescos ni mesurar el rendiment real del model. Registrar prediccions (amb les seves features i timestamp) és barat avui i impagable d'aquí a sis mesos.
• Error: versionar només el model (el binari). Un .pkl sense el codi i les dades que el van generar és una caixa negra irrecuperable. Versiona la recepta, no només el plat.
• Consell: dibuixa el cicle de vida del teu projecte actual i marca en vermell les etapes que avui són manuals, indocumentades o inexistents (típicament: validació formal, monitoratge i reentrenament). Aquest dibuix és el teu full de ruta MLOps personal, i encaixa amb els nivells de maduresa que veurem a la propera lliçó.

Ordena cronològicament aquestes activitats de l'equip de CineClick i assigna cadascuna a la seva etapa del cicle de vida:

• (a) Es detecta que les prediccions de juliol són notablement pitjors que les de març.
• (b) S'acorda que l'objectiu és reduir el churn mensual i que la mètrica de ML serà el recall de la classe "abandona".
• (c) Es llança un procés que torna a entrenar el model amb les dades dels últims sis mesos.
• (d) Es construeix el dataset unint subscripcions, logs de visualització i tiquets de suport.
• (e) Es comprova que el model candidat supera l'actual també en el segment de clients amb pla bàsic, i un responsable n'aprova el pas a producció.
• (f) Es proven tres algorismes amb diferents combinacions d'hiperparàmetres.
• (g) El model aprovat comença a puntuar subscriptors cada nit.

El model de churn de CineClick fa 3 mesos que és en producció. L'equip de retenció ha estat oferint un descompte a tots els clients que el model marca amb risc alt, i el 60% d'ells s'ha quedat. Ara toca reentrenar. Explica: (1) quin problema té fer servir directament les dades d'aquests 3 mesos com si res, i (2) quina informació s'hauria d'haver registrat des del principi per poder tractar-lo.

Per a cadascun d'aquests tres canvis a CineClick, indica quin(s) dels tres artefactes (codi, dades, model) canvia(en) de versió, raonant la cadena d'efectes:

1. Un enginyer corregeix un bug a la funció que calcula hores_setmana (comptava també les hores amb el reproductor en pausa).
2. Arriba el tancament de mes i s'incorporen les dades de juny per al reentrenament programat, sense tocar res més.
3. Es refactoritza el codi del servei de predicció per fer-lo més ràpid, sense canviar el preprocessament ni l'entrenament.

Solució 1:

Ordre: b → d → f → e → g → a → c

• (b) Etapa 1, definició del problema de negoci.
• (d) Etapa 2, obtenció i preparació de dades.
• (f) Etapa 3, entrenament i avaluació.
• (e) Etapa 4, validació (comportament per subgrups + aprovació humana).
• (g) Etapa 5, desplegament (patró batch nocturn).
• (a) Etapa 6, monitoratge (detecció de degradació).
• (c) Etapa 7, reentrenament, que reobre el cicle per l'etapa 3 (o la 2, si a més es revisen les dades).

Solució 2:

1. El problema: és el bucle de realimentació perillós. Els clients marcats com a "risc alt" van rebre una intervenció (descompte) que va canviar el seu comportament: molts que anaven a abandonar no ho van fer. Si es reentrena amb aquestes dades tal qual, el model aprendrà que els perfils de risc alt "no abandonen", és a dir, aprendrà a desaprendre justament el senyal que el feia útil. El model es degradaria precisament per haver funcionat.
2. Què registrar: com a mínim, (a) les prediccions de cada client amb les seves features i data; (b) quins clients van rebre la intervenció (el descompte) i quan; i idealment (c) un grup de control: una fracció de clients de risc alt als quals no es va oferir el descompte. Amb aquesta informació es pot entrenar excloent o corregint els casos intervinguts, i el grup de control permet a més mesurar l'efecte real de la campanya. Sense aquest registre, les dades dels 3 mesos són irrecuperablement ambigües.

Solució 3:

1. Codi, dades i model, tots tres. Canvia el codi (nova versió de la funció). En recalcular hores_setmana, el dataset d'entrenament regenerat és diferent (nova versió de les dades). I amb dades diferents, el reentrenament produeix un model diferent (nova versió del model). És un exemple perfecte de CACE: una "reparació petita" propaga versions noves per tota la cadena — i per això els tres versionaments han de quedar enllaçats.
2. Dades i model. El codi no canvia; les dades sí (incorporen juny) i el model resultant també. És el cas rutinari de reentrenament: mateix codi, recepta nova per ingredients nous.
3. Només codi. El servei és més ràpid, però el preprocessament i l'entrenament no es toquen: el model desplegat continua sent exactament el mateix binari, i les dades ni hi intervenen. Cal desplegar la nova versió del servei, però no reentrenar ni revalidar el model (sí que convé revalidar que el servei retorna les mateixes prediccions que abans).

Hem recorregut el mapa complet del cicle de vida d'un model en producció: definició del problema de negoci, dades, entrenament, validació, desplegament, monitoratge i reentrenament — un cicle que es realimenta, no una línia amb final. Hem vist que en ML es versionen tres artefactes (codi, dades, model) que evolucionen a ritmes diferents però han de quedar enllaçats, i que el model en producció genera les dades de la seva pròpia millora... i de vegades de la seva pròpia contaminació, si no es dissenyen els bucles de realimentació amb cura.

Aquest mapa ens diu què cal fer, però no quant d'això està automatitzat en un equip donat, ni qui s'encarrega de cada etapa. Aquestes són exactament les dues preguntes de la lliçó següent: els nivells de maduresa MLOps —del procés completament manual al CI/CD complet— i els rols de l'equip que col·laboren al llarg del cicle. Allà situarem CineClick al seu punt de partida i traçarem cap on el portarà aquest curs.