Aquesta última lliçó no construeix res de nou — i això és exactament el que la fa important. Després de sis mòduls afegint peces, toca fer un pas enrere i veure el sistema sencer: el mapa complet de la plataforma de CineClick, un incident real recorregut de punta a punta que exercita cada component, l'inventari del repo com a plantilla reutilitzable, i el tancament de l'arc que vam obrir al mòdul 1 — els deu problemes d'aquell diagnòstic, revisitats un per un. Acaba amb el teu projecte: replicar la plataforma completa en un altre domini, perquè la prova que saps MLOps no és haver seguit CineClick, sinó poder construir-lo sense ella.

1. El mapa complet de la plataforma
2. Un incident de punta a punta: la promo de primavera
3. Inventari del repo: cineclick-churn com a plantilla
4. Els deu problemes del mòdul 1, revisitats
5. El teu projecte: la plataforma de "LuzYa"
6. Guia d'adaptació: quan el teu cas no és CineClick
7. Exercicis de síntesi

Aquest és el sistema que has construït, amb les persones dibuixades exactament on el sistema s'atura a esperar-les:

Tres lectures del mapa abans de continuar:

• És un bucle, no una canonada. La fletxa de MON a DRIFT a RETRAIN i de tornada al registry és el que separa el nivell 2 de maduresa del nivell 1: el sistema es retroalimenta.
• Quatre humans, quatre judicis. Revisar codi, aprovar el desplegament del servei, aprovar la promoció del model, interpretar la deriva. Tot el mecànic entre ells és automàtic; cap dels quatre no és eliminable sense perdre una salvaguarda.
• Dues cadències conviuen: la del servei (desplegaments quan hi ha canvis de codi) i la del model (promocions quan hi ha challenger validat). Desacoblar-les va ser la decisió central del mòdul 5.

Res no demostra un sistema com un incident. Aquest escenari exercita, en ordre, gairebé totes les peces del mapa. Cada pas fa servir comandes i pantalles que ja coneixes — no hi ha res de nou per aprendre, només veure-ho tot funcionar junt.

Dia 0 — el món canvia. Màrqueting llança la promo de primavera: tres mesos a meitat de preu. Ningú no avisa l'equip de ML (mai no avisen). Comencen a entrar milers d'altes: clients joves, pla basic, antiguitat zero. El servei ni s'immuta — l'HPA escala de 3 a 5 rèpliques, p95 estable a ~90 ms. Pla de servei: verd. El dashboard de 06-01 comença a moure els proxies: la mescla per pla llisca cap a basic i l'histograma de probabilitats s'engreixa per dalt.

Setmana 2 — el sistema mira, i veu. Dilluns 07:00, el flow deteccio-deriva-churn compara l'última setmana de la taula de prediccions contra la referència versionada del champion. Resultat: PSI 0.31 a antiguitat_mesos (> 0.25), deriva també a pla i hores_setmana, drift_share per sobre del llindar. Alerta a #alertes-ml amb les features derivades i l'enllaç a l'informe HTML d'Evidently. Ningú no es va haver de recordar de mirar: aquest era el punt de tot el mòdul 6.

Setmana 2, mateix dia — playbook, no reflex. La Laura obre l'informe i aplica el playbook de 06-02. Error de dades aigües amunt? No: l'esquema_clients de pandera passa, els valors són plausibles, i les distribucions desplaçades expliquen una història coherent (clients nous de debò). Cohort legítima? Sí — dos missatges a màrqueting ho confirmen: és la promo. Impacte? La taxa de positius ha pujat al 23%, encara dins de la banda 10–25%, però el model està extrapolant sobre una població que amb prou feines va veure a l'entrenament. Decisió humana: tret extraordinari del reentrenament, documentada al fil de l'alerta.

Setmana 2-3 — el reentrenament proposa. La Laura llança reentrenament-churn des de la UI de Prefect amb motiu="extraordinari-PSI-antiguitat". El flow construeix el dataset nou amb tall point-in-time (la cohort de la promo entra amb les etiquetes que ja té; el grup de control manté les etiquetes netes), fa dvc repro, i avalua: test congelat recall 0.69 / precision 0.55 (llindar superat), test fresc recall 0.66. Registra v3 com a @challenger amb els seus tags de llinatge (dades_dvc_md5, finestra temporal, flow run) i notifica a #alertes-ml. En cap moment no toca @champion.

Setmanes 3-5 — l'ombra escolta. El PR de promoció s'obre, però abans: dues setmanes d'ombra obligatòries (ADR-007). S'activa MODE_OMBRA al ConfigMap churn-api-config; cada petició es puntua amb v2 (que respon) i v3 (que només es registra: probabilitat_ombra, versio_model_ombra). En tancar la finestra, l'anàlisi de la taula de prediccions mostra un desacord del 9%, concentrat gairebé del tot a la cohort nova — v3 assigna probabilitats més baixes als nouvinguts de la promo. És exactament el que havia de passar: v3 va aprendre que "antiguitat zero + pla basic + promo" no implica el risc que v2 els extrapolava. L'avaluació per subgrups (06-04) confirma que cap segment no empitjora; la model card de v3 es redacta amb la cohort com a novetat i les seves etiquetes encara joves com a limitació.

Setmanes 5-6 — canary i promoció. Revisió humana del PR de promoció: checklist de docs/promocio-model.md, evidència d'ombra adjunta, subgrups, model card. Aprovat. Canary de model: 5% → 25% → 100%, 24-48 h per esglaó, amb les mètriques de guàrdia vigilant (5xx, p95, taxa de positius en banda). Sense ensurts. promocionar_champion.py mou l'alias: v3 = @champion. L'endpoint /versio ho confirma; la referència del detector de deriva s'actualitza sola al dataset de v3 (el mecanisme de l'exercici 3 de 06-02).

Setmana 6 — tancament. ADR nou a docs/decisions/: context (promo no comunicada), decisió (reentrenament extraordinari i política acordada amb màrqueting: avisar de campanyes amb dues setmanes d'antelació), conseqüències. El dashboard torna al verd amb una anotació a la línia temporal: "v3 promocionat". Del dia 0 al tancament: el sistema va detectar sol, l'humà va decidir quatre vegades, i cap client no va notar res.

El repo que has vist créixer és, a hores d'ara, una plantilla reutilitzable. L'inventari complet, amb la lliçó on va néixer cada peça:

Per al teu proper projecte, aquesta taula és la llista de la compra: cada fila és una peça que sabràs construir, i l'ordre de les lliçons és un ordre de construcció raonable.

A 01-04 vam diagnosticar el punt de partida de CineClick: un model prometedor morint al notebook de la Laura. Aquells deu problemes, tancats un per un:

L'arc complet del curs cap en aquesta taula. Fixa't que cap fila no es va resoldre amb "més model": el recall va passar de 0.43 (v1) a 0.68 (v2) al mòdul 3, i tota la resta va ser convertir aquell model en un sistema.

Ara et toca a tu. El projecte final consisteix a replicar la plataforma completa amb un altre cas: LuzYa, una comercialitzadora elèctrica fictícia que vol predir l'impagament de factures per anticipar avisos i plans de pagament. Mateix esquelet, domini nou — que és exactament la situació en què et trobaràs a la feina. Totes les dades han de ser sintètiques, generades per tu (com ho van ser les de CineClick).

El dataset (factures_luzya.csv, genera ~20.000 files sintètiques amb ~12% d'impagament):

Fases, mapades als mòduls del curs, amb criteris d'autoavaluació:

• Fase 1 (M2) — Reproduïbilitat. Repo luzya-impagament amb paquet, entorn amb lock, DVC i pipeline dvc repro de 4 etapes.
  • [ ] Un company (o tu en una altra màquina) reprodueix l'entrenament amb 3 comandes.
  • [ ] dvc repro sense canvis no re-executa res.
• Fase 2 (M3) — Experiments i registry. MLflow, com a mínim dues versions registrades (base + millora), alias @champion, features.py com a font única. Defineix EL TEU criteri de negoci (p. ex. recall ≥ 0.65 amb precision ≥ 0.45 — justifica'l: què costa més, un avís de més o un impagament no detectat?).
  • [ ] Pots respondre "amb quines dades i codi es va entrenar el champion?" només amb MLflow + DVC.
• Fase 3 (M4) — Serving. API FastAPI (/predir, /salut, /versio), Docker multi-stage, desplegament a Kubernetes local (kind/minikube) amb 2+ rèpliques; batch mensual de scoring de la facturació.
  • [ ] p95 mesurat i pressupost de latència definit i documentat.
• Fase 4 (M5) — Automatització. CI amb tests de codi/dades (pandera)/model i el teu llindar bloquejant; CD desacoblat; flow de scoring programat; pla de release per escrit (ombra? canary? quines mètriques de guàrdia?).
  • [ ] Un PR que degrada el recall per sota del llindar es bloqueja sol.
• Fase 5 (M6) — Operació. /metrics + proxies, taula de prediccions, deriva amb Evidently programada, flow de reentrenament amb point-in-time (num_impagaments_previs i pla_pagament_actiu són les teves trampes de leakage i intervenció: resol-les com CineClick va resoldre les seves — tall temporal i grup de control), model card, dos ADRs i la checklist de governança de 06-04 completada.
  • [ ] Simula una deriva (genera un mes de dades amb una altra distribució de tarifa) i verifica que el teu detector la veu.
  • [ ] Respon el simulacre d'auditoria de l'exercici 1 de 06-04, versió LuzYa.

Consell d'abast: fes-ho en sèrie, no en paral·lel, i no passis de fase sense complir la seva checklist — l'ordre dels mòduls era també un ordre de dependències. Un projecte amb les fases 1-3 impecables val més que les cinc a mitges.

L'esquelet és el mateix gairebé sempre; aquests són els ajustos típics, en pinzellades:

• Models de deep learning: el bucle no canvia (registry, challenger, ombra, deriva), però l'entrenament s'encareix — hi entra el tracking de checkpoints, datasets que no caben en un CSV (DVC continua valent; canvia el remote i el format), i avaluació més cara. Els fonaments de modelatge els cobreix el curs de deep_learning del portal.
• Amb GPU: afecta dos llocs — l'entrenament (cues i nodes GPU a l'orquestrador; el flow de reentrenament demana recursos diferents) i de vegades la inferència (batching de peticions, i el pressupost de latència/cost de 04-05 es recalcula per complet). A Kubernetes, node pools i resources.limits amb GPU: curs de kubernetes.
• Equip gran: el que a CineClick era "la Laura i tu" es converteix en plataforma compartida — registry i tracking centralitzats multiprojecte, entorns per equip, i les aprovacions humanes es formalitzen en CODEOWNERS i environments protegits. La disciplina de branques, revisions i pipelines a escala: cursos de ci_cd i docker per reforçar la base de lliurament.
• Regulació forta (banca, salut, assegurances): el mòdul 6-04 passa de "bona pràctica" a requisit dur; la checklist creix amb validació independent de models i comitès — però fixa-t'hi: l'estructura és la mateixa, només canvia l'exigència de cada casella.

• Començar el projecte de LuzYa per la fase 4 o 5. La temptació d'"anar a l'interessant" (CI/CD, deriva) sense una fase 1 sòlida reprodueix l'error original de CineClick: automatitzar sobre sorra. Si dvc repro no funciona en una màquina neta, res del que muntis a sobre no és de fiar.
• Copiar els números de CineClick en lloc de derivar els teus. El llindar recall ≥ 0.60/precision ≥ 0.50, la banda 10-25% de positius o el pressupost de 300 ms surten del negoci de CineClick. A LuzYa el cost d'un fals negatiu (impagament no detectat) i d'un fals positiu (avís injust a un bon client) són uns altres — fes els comptes abans de fixar el llindar, com a la fase 2.
• Tractar les trampes del dataset com a detalls opcionals. num_impagaments_previs sense tall temporal és leakage pur (comptaràs impagaments que encara no havien passat) i pla_pagament_actiu és una intervenció que contamina l'etiqueta, igual que el descompte de retenció de CineClick. Si el model de la fase 2 et dona mètriques sospitosament bones, gairebé segur que has caigut a la primera.
• Confondre "tenir les peces" amb "tenir la plataforma". L'escenari de la promo ho va ensenyar: el valor no és a Evidently ni a Prefect per separat, sinó en el fet que l'alerta porti a un playbook, el playbook a un reentrenament amb llinatge i aquest a un camí de release segur. En autoavaluar-te, recorre un incident inventat de punta a punta — és la checklist que de debò importa.
• Saltar-se els humans del mapa. Si a la teva rèplica el flow de reentrenament acaba movent @champion directament "perquè total, soc jo sol", has tornat al nivell 0 amb més YAML. La disciplina de challenger + revisió s'entrena en projectes petits perquè existeixi en els grans.

Sobre l'escenari de la promo de primavera (no requereixen escriure codi):

1. El contrafactual. Recorre l'incident imaginant que CineClick s'hagués quedat com al final del mòdul 4 (sense mòdul 5 ni 6): en quin moment s'hauria detectat el problema, qui l'hauria detectat, i què hauria passat amb la campanya de retenció durant aquelles setmanes? Assenyala les dues peces l'absència de les quals hauria fet més mal.

2. Els quatre humans. Durant l'incident hi ha quatre intervencions humanes (playbook, llançament del reentrenament, revisió del PR de promoció, decisió sobre el canary). Per a cadascuna, explica quin judici aporta aquesta persona que el sistema no pot automatitzar amb el que s'ha construït al curs — i quina de les quatre creus que seria la primera candidata a automatitzar-se en un hipotètic nivell 3 de maduresa, amb quina salvaguarda a canvi.

3. La peça que va fallar silenciosament. A l'escenari, màrqueting no va avisar de la promo i el sistema la va detectar per deriva dues setmanes després. L'ADR de tancament afegeix l'avís previ de campanyes com a política. Què t'ensenya això sobre els límits de la solució tècnica — és a dir, quina classe de problemes d'un sistema de ML en producció no es resolen amb més monitoratge?

1. Sense mòdul 6 no hi ha detecció: ni proxies, ni Evidently, ni alerta. El problema s'hauria descobert quan algú de màrqueting notés — setmanes o mesos després — que la campanya de retenció "funcionava estrany": massa clients nous marcats en risc (v2 extrapolant antiguitat zero com a perill), pressupost de descomptes disparat sobre una cohort que potser no el necessitava, i clients veterans en risc competint per lloc a la campanya amb falsos positius. Sense mòdul 5, a més, la resposta hauria estat artesanal: reentrenar a mà al portàtil de la Laura, sense ombra ni canary, amb el risc de substituir un problema conegut per un de desconegut. Les dues absències més doloroses: la taula de prediccions (sense ella no hi ha ni diagnòstic retrospectiu: no sabries ni quants clients de la promo van ser marcats) i el camí segur challenger → ombra → canary (sense ell, la correcció és tan arriscada com el problema).

2. Playbook: distingeix causes que requereixen context extern al sistema (és una promo? un bug de l'equip de dades?) — el sistema veu que la distribució ha canviat, no per què; aquest perquè viu en converses amb altres equips. Llançament del reentrenament: decideix si el canvi mereix la resposta cara (còmput, risc, revisió) — un judici de cost/benefici amb informació de negoci. Revisió del PR: responsabilitat — algú amb nom assumeix que l'evidència (ombra, subgrups, model card) justifica el canvi; és tant control com rendició de comptes. Canary: interpretar mètriques de guàrdia en context (aquest pic de p95 és el model o és el partit de futbol?). La candidata natural a automatitzar en un nivell 3 és la progressió del canary (els llindars ja són objectius i el rollback automàtic ja existeix): s'automatitzaria l'avanç 5→25→100 quan les mètriques de guàrdia porten N hores netes, amb la salvaguarda que qualsevol alerta congela la progressió i notifica — l'humà passa d'aprovar cada esglaó a supervisar per excepció. Les altres tres involucren context extern o responsabilitat, i automatitzar-les eliminaria el judici, no el tràmit.

3. Que el monitoratge és un detector de símptomes, no un substitut de la comunicació entre equips: el sistema tècnic perfecte va detectar la promo amb dues setmanes de retard perquè el problema no era tècnic — era organitzatiu (una decisió de negoci que afecta les dades no va arribar a qui opera el model). Cap quantitat de PSI no converteix una sorpresa en un avís. Per això el tancament de l'incident és un ADR amb una política de comunicació i no una eina nova: hi ha una classe sencera de problemes (canvis de negoci, decisions de producte, esdeveniments externs previsibles) la solució barata dels quals és avisar abans i la solució tècnica dels quals és només l'airbag. MLOps, com el seu parent DevOps, és en última instància una disciplina sociotècnica: la meitat de la plataforma són pipelines; l'altra meitat, acords entre persones — els quatre humans del mapa, els ADRs, el playbook i una promo comunicada a temps.

Aquí acaba el viatge. Va començar al mòdul 1 amb un notebook al portàtil de la Laura: un random forest prometedor amb recall 0.43 i deu problemes que li impedien tocar la realitat. Acaba amb la plataforma del mapa d'aquesta lliçó: un paquet reproduïble amb dades versionades (M2); experiments traçats i un registry on v2 — i ara v3 — porten el seu llinatge complet (M3); un servei a Kubernetes amb p95 de 92 ms i un batch setmanal que alimenta la campanya de retenció (M4); CI que converteix el criteri de negoci en llindar bloquejant, CD desacoblat amb humans als punts de responsabilitat, i releases amb ombra, canary i rollback assajat (M5); i un sistema que mira sol — dos plans de monitoratge, deriva detectada cada dilluns, reentrenament amb tret i point-in-time correctness, governança auditable per disseny (M6). CineClick va creuar al nivell 2 de maduresa, i tu hi vas creuar amb ella.

El que saps fer ara, en concret: estructurar un projecte de ML com a paquet reproduïble amb entorn fixat; versionar dades i pipelines amb DVC; traçar experiments i gestionar el cicle champion/challenger a MLflow; servir models online amb FastAPI, empaquetar-los amb Docker i operar-los a Kubernetes amb pressupost de latència; muntar CI amb tests de codi, dades i model, i CD desacoblat per a servei i model; orquestrar amb Prefect; dissenyar releases amb ombra, canary i A/B; monitorar en dos plans i construir una taula de prediccions auditable; detectar deriva amb PSI i Evidently i reaccionar amb un playbook; automatitzar el reentrenament sense cedir la decisió de promoció; i documentar i governar el sistema — model cards, ADRs, subgrups, privadesa — fins a poder superar un simulacre d'auditoria en minuts.

Per continuar aprofundint, tres camins naturals: cap al modelatge (el curs de deep_learning del portal, si els teus models creixen més que els teus pipelines), cap a la infraestructura (els cursos de kubernetes, docker i ci_cd, si vols operar la plataforma que altres fan servir), i cap a la pràctica — que és el camí que de debò consolida: el projecte de LuzYa t'està esperant, i després d'ell, el primer model real del teu equip que avui estigui morint en un notebook. Ja saps exactament què fer-ne.