El model de churn de MercaFresh ja és en producció: batch nocturn, API, Docker, desplegament gradual. Seria temptador donar el projecte per acabat — i seria un error. Un model d'aprenentatge automàtic és un dels pocs components de programari que es degraden sense que ningú toqui el codi: el model és una fotografia dels patrons del passat, i el món que genera les dades continua movent-se. En aquesta lliçó aprendràs per què passa (data drift i concept drift), com detectar-ho amb eines que ja coneixes (histogrames, percentils i tests estadístics del mòdul 2), què monitorar en un dashboard, i com organitzar el reentrenament i el versionatge perquè el model continuï sent útil any rere any.

1. Per què els models es degraden
2. Data drift: canvia el que entra
3. Concept drift: canvia la relació amb la resposta
4. Detecció de drift a les entrades
5. Monitorar prediccions i mètriques (amb etiquetes que arriben tard)
6. Dashboards i alertes: què vigilar
7. Reentrenament: quan i com
8. Registre de models i versionatge
9. El cicle de vida complet en producció

Quan vas entrenar el model de churn, el mòdul 6 va insistir en una condició perquè les mètriques de prova fossin creïbles: que les dades de producció s'assemblin a les d'entrenament. Aquesta condició es compleix el dia del desplegament… i comença a erosionar-se l'endemà. Les causes s'agrupen en dos fenòmens amb nom propi:

La distinció importa perquè es detecten i es tracten de manera diferent, com veurem. I totes dues comparteixen un tret perillós: el servei continua funcionant. L'API respon en mil·lisegons, el batch nocturn acaba sense errors, les probabilitats fan bona pinta… i són cada vegada pitjors. Sense monitoratge específic, la degradació d'un model és invisible fins que el negoci la nota.

El data drift (també anomenat covariate shift) és el cas més comú: la població sobre la qual prediu deixa d'assemblar-se a la d'entrenament.

Exemples concrets a MercaFresh:

• Expansió a una ciutat nova: el model es va entrenar amb clients de cinc ciutats; ara el 15 % de les peticions arriba de Saragossa, una categoria que el codificador del pipeline ni tan sols coneixia. La distribució d'antiguitat_mesos s'ensorra (tots són clients nous).
• Canvi d'hàbits: després de llançar la subscripció mensual, la distribució de frequencia_90d es desplaça cap amunt i la de recencia_dies cap avall. El model veu valors en zones on va tenir pocs exemples per aprendre.
• Canvis tècnics als sistemes d'origen: algú modifica el sistema font i despesa_mitjana passa d'euros a cèntims. Drift brutal i instantani — i sorprenentment freqüent: moltes "degradacions del model" són en realitat bugs de dades.

El model no falla de cop: simplement extrapola cada vegada més lluny del que va conèixer, i la seva fiabilitat cau de manera gradual i silenciosa.

En el concept drift, les entrades poden tenir el mateix aspecte de sempre, però el que signifiquen per a la resposta ha canviat: la funció que el model va aprendre ja no és la que regeix el món.

Exemples a MercaFresh:

• Una campanya canvia qui abandona: retenció contacta sistemàticament els clients d'alt risc (fent servir el nostre model!) i molts es queden. Ara un perfil que històricament significava "abandonament gairebé segur" ja no ho és. Fixa't en la ironia: l'èxit del model altera la realitat que el model descrivia — els sistemes de ML que actuen sobre el món generen aquest bucle de manera natural.
• Un competidor nou amb enviament gratuït: clients de perfil "fidel" (alta freqüència, baixa recència) comencen a marxar. Les X no han canviat; el significat de les X sí.
• Estacionalitat: el patró de compra nadalenc no implica el mateix al gener. Si l'entrenament no va cobrir cicles anuals complets, cada estació nova és un petit concept drift.

El concept drift és més difícil de detectar que el data drift, perquè no n'hi ha prou de mirar les entrades: cal comparar prediccions amb resultats reals — i aquests arriben tard, com veurem.

La bona notícia: per detectar data drift no necessites etiquetes, només comparar la distribució actual de cada variable amb la de referència (les dades d'entrenament). I les eines són les del mòdul 2.

Nivell 1 — Estadístics descriptius i percentils (02-01): desa, juntament amb el model, mitjana, desviació i percentils (p5, p25, p50, p75, p95) de cada variable en entrenament. Cada nit, calcula els mateixos números sobre les dades del scoring i compara. És simple, barat i detecta els casos gruixuts (el bug d'euros/cèntims salta a la vista a la mediana).

Nivell 2 — Tests estadístics (02-04): per detectar desplaçaments més fins, formalitza la comparació com un test d'hipòtesis: H0 = "totes dues mostres venen de la mateixa distribució".

• Variables numèriques → test de Kolmogorov-Smirnov (compara les distribucions acumulades completes).
• Variables categòriques → test khi quadrat sobre les freqüències de cada categoria.

Dos matisos d'ús professional:

• Amb mostres grans, tot surt "significatiu" (ho vas veure a 02-04: amb una n enorme, diferències trivials donen p-valors minúsculs). Per això en monitoratge es mira també la mida de l'efecte — l'estadístic KS (proporció màxima de separació entre distribucions) més que el seu p-valor, amb llindars pràctics acordats (p. ex. investigar si KS > 0,1).
• El test assenyala que hi ha canvi, no si importa. Un drift gran en una variable de poca importància per al model és menys urgent que un de moderat en la variable principal. Creuar el drift amb la importància de variables (07-03) prioritza les alertes.

Mirar les entrades no n'hi ha prou; cal mirar també el que surt del model, en dos nivells segons què estigui disponible:

Nivell A — La distribució de les prediccions (disponible sempre, a l'instant). Desa cada nit l'histograma i els percentils de prob_churn sobre tota la base de clients. Si la probabilitat mitjana de churn passa de 0,18 a 0,31 en dues setmanes, o el percentatge de clients sobre el llindar d'acció es duplica, alguna cosa ha canviat — en les dades, en el món o en el mateix pipeline — i cal investigar abans de saber si les prediccions encerten. Aquest és el canari a la mina: barat i sense retard.

Nivell B — Les mètriques reals (disponibles amb retard). Aquí apareix la dificultat específica del churn: l'etiqueta veritable triga mesos a conèixer-se. Si defineixes churn com "sense compres en 90 dies", la predicció que fas avui només es pot avaluar d'aquí a 90 dies. Conseqüències pràctiques:

• Organitza l'avaluació per cohorts: "els scores emesos al maig" s'avaluen a l'agost, quan les seves etiquetes maduren, calculant precision, recall, AUC i la matriu de confusió de 06-02 sobre aquesta cohort.
• Grafica cada mètrica per cohort al llarg del temps: un pendent descendent sostingut és la signatura de la degradació (i, si les entrades no mostren drift, apunta a concept drift).
• Compte amb el biaix d'intervenció: si retenció actua sobre els clients assenyalats, les seves etiquetes ja no reflecteixen el que hauria passat sense actuar. Mantenir un petit grup de control sense contactar (com a l'A/B de 08-02) manté l'avaluació honesta.

El monitoratge complet combina tots dos nivells: l'A dona alarmes primerenques sense confirmació; el B dona la veritat, amb mesos de retard.

Tot l'anterior es materialitza en un dashboard que qualsevol de l'equip pugui llegir, amb alertes automàtiques quan alguna cosa creua un llindar. Què ha de contenir, en dos blocs:

Dos principis de disseny:

• Cada alerta ha de tenir un propietari i una acció. Una alerta que ningú atén entrena l'equip a ignorar alertes. Poques, ben calibrades, accionables.
• El dashboard de negoci mana. El model pot tenir un AUC estable i estar fallant al negoci (o a l'inrevés). L'objectiu mai no va ser l'AUC: era retenir clients amb un pressupost (06-04).

Detectat el deteriorament (o abans que arribi), la resposta natural és reentrenar amb dades recents. Les dues preguntes clau:

Quan reentrenar? Dues estratègies, no excloents:

A la pràctica, la combinació és l'habitual: un reentrenament trimestral programat, més la possibilitat d'avançar-lo si les alertes ho justifiquen. Per a MercaFresh: reentrenament trimestral del model de churn, avançable davant d'esdeveniments com l'obertura d'una ciutat.

Com reentrenar? No és "executar fit una altra vegada i llestos":

1. Finestra de dades: decideix amb quina història entrenar. Tot l'històric (més dades, però arrossega patrons vells) o una finestra mòbil dels últims 18–24 mesos (més fresc, menys volum)? Amb concept drift confirmat, la finestra recent acostuma a guanyar; es pot comparar empíricament.
2. Mateix rigor que l'original: el reentrenament repeteix el procés complet dels mòduls 6 i 7 — divisió temporal correcta, CV, cerca d'hiperparàmetres sobre el pipeline— de manera automatitzada (un script o pipeline d'entrenament, no un notebook a mà).
3. Validació abans de reemplaçar: el candidat ha de superar el model en producció sobre un conjunt d'avaluació comú i recent que cap dels dos no va veure en entrenament. Si no el supera, no es desplega — reentrenar no garanteix millorar.
4. Desplegament gradual i rollback: el candidat aprovat entra pel mateix camí que vas veure a 08-02 (ombra → A/B → rollout), amb la versió anterior llesta per tornar. El reentrenament no és un esdeveniment especial: és un altre desplegament.

Amb reentrenaments periòdics, en un any tindràs v3, v4, v5… i preguntes com "quin model va generar els scores del 12 de març?" o "amb quines dades es va entrenar el que va fallar?". Respondre-les exigeix disciplina de registre. Per a cada versió, desa com a mínim:

• L'artefacte (pipeline serialitzat) i la seva suma de verificació.
• Dades: finestra temporal i consulta/snapshot amb què es va entrenar.
• Codi i entorn: commit del repositori i requirements.txt exacte.
• Mètriques de validació i comparació amb la versió anterior.
• Historial de desplegament: quan va entrar en producció, quan en va sortir, per què.

Això pot començar sent una convenció de carpetes i un fitxer de metadades (com a 08-02). Quan el volum creix, es fa servir un registre de models dedicat: eines com MLflow ofereixen exactament això — seguiment d'experiments (paràmetres i mètriques de cada entrenament), un registre central de models amb etapes (staging/producció/arxivat) i traçabilitat entre dades, codi i artefacte. Conceptualment no afegeix res que no hagis vist: sistematitza la disciplina d'aquesta secció perquè no depengui de la memòria de ningú. No el desenvolupem aquí; la seva documentació és accessible amb el que ja saps.

El diagrama que resumeix el mòdul fins ara — i explica per què aquesta pràctica s'anomena de vegades MLOps: tractar el cicle sencer com un procés d'enginyeria continu, no com un projecte amb final.

Observa que és un cicle, no una línia: l'estat normal d'un model útil és estar donant voltes per aquest graf durant anys.

• "Desplegat = acabat". L'error de mentalitat del qual neixen tots els altres: sense monitoratge, la primera notícia de la degradació te la donarà el negoci, mesos tard.
• Monitorar només el servei (latència, errors) i no el model. Una API sana al 100 % pot estar servint prediccions cada vegada pitjors. Són dos monitoratges diferents i calen tots dos.
• Refiar-se del p-valor amb mostres enormes. Amb cent mil files, un KS amb p < 0,001 pot reflectir una diferència irrellevant. Mira la mida de l'efecte i fixa llindars pràctics.
• Oblidar el retard de les etiquetes. Avaluar "el recall d'aquesta setmana" amb etiquetes de churn immadures infraestima el churn real i dona una falsa sensació d'encert. Avalua per cohorts madures.
• Reentrenar i desplegar sense validar contra el model actual. Reentrenar amb dades amb drift no garanteix un model millor; sense la comparació prèvia, pots reemplaçar un model mediocre per un de pitjor.
• Ignorar l'efecte de les pròpies intervencions. Si actues sobre els clients que el model assenyala, les etiquetes posteriors estan contaminades per la teva intervenció; sense grup de control, el model semblarà "equivocar-se" just quan funciona.
• Consell: desa des del primer dia un snapshot de referència (dades d'entrenament amb els seus estadístics) juntament amb l'artefacte. Sense referència no hi ha comparació, i reconstruir-la mesos després acostuma a ser impossible.

Exercici 1. Classifica cada situació com a data drift, concept drift o bug de dades, i justifica-ho: (a) després d'integrar un proveïdor logístic nou, incidencies_lliurament passa a arribar gairebé sempre a 0 perquè el proveïdor no reporta incidències; (b) MercaFresh llança una targeta de fidelització amb enviament gratuït i, amb els mateixos perfils RFM de sempre, la taxa real de churn dels clients d'alta freqüència cau a la meitat; (c) una campanya de captació a xarxes porta una onada de clients joves amb cistells petits, un segment minoritari a l'entrenament.

Exercici 2. El monitoratge nocturn de MercaFresh aplica KS a despesa_mitjana amb les dades de referència (n = 80.000) davant de les del dia (n = 75.000) i obté KS = 0,012 amb p = 0,00004. El responsable proposa reentrenar de seguida. Què li diries?

Exercici 3. Dissenya en 5-7 línies el pla d'avaluació contínua del model de churn sabent que l'etiqueta es defineix com "sense compres en 90 dies": què es monitora cada dia, què es calcula cada mes, i quin paper hi juga el grup de control.

Solució 1. (a) Bug de dades (encara que es manifesti com a drift): la variable no ha canviat al món, ha deixat de mesurar-se bé. L'acció és corregir la integració al sistema d'origen, no reentrenar — reentrenar aprendria que "0 incidències" no significa res. (b) Concept drift: P(X) gairebé no canvia (mateixos perfils RFM), però la relació X→y sí — el mateix perfil ara abandona menys. Només es detectarà a les mètriques per cohort, no als tests sobre les entrades. (c) Data drift: canvia la composició de la població d'entrada (P(X)); la relació perfil→churn pot continuar sent la mateixa, però el model ara prediu sovint en una zona on va tenir pocs exemples. Vigilar les mètriques d'aquest segment i valorar reentrenar incloent-lo més ben representat.

Solució 2. Que distingeixi significància de rellevància (02-04): amb n ≈ 80.000 per mostra, el test KS detecta com a "significativa" qualsevol diferència minúscula; la mida de l'efecte és KS = 0,012 — les distribucions acumulades se separen com a màxim un 1,2 %, un canvi gairebé amb tota seguretat irrellevant per al model. Abans de reentrenar: comparar percentils per veure on és la diferència, revisar si la variable és important per al model i comprovar la resta d'indicadors (distribució de prediccions, mètriques de cohorts). Reentrenar per un p-valor amb un efecte menyspreable és cost i risc sense benefici.

Solució 3. Pla tipus: Diari — estadístics i KS/khi² de cada variable davant de la referència; distribució de prob_churn (mitjana i percentils) i % de clients sobre el llindar; salut del batch i de l'API. Mensual — es "tanca" la cohort de scores emesa fa 90 dies (les seves etiquetes ja han madurat) i es calculen precision, recall i AUC d'aquesta cohort, afegint-les a la sèrie temporal de mètriques per veure'n la tendència. Grup de control — una fracció aleatòria petita de clients en risc no es contacta; les seves etiquetes permeten mesurar el churn "sense intervenció", de manera que l'avaluació del model no quedi distorsionada per l'èxit de les campanyes, i de passada mesura el benefici causal real de la retenció davant del control.

Ja saps per què un model perfecte el dia del desplegament deixa de ser-ho: el data drift mou les entrades (la ciutat nova, els hàbits que canvien) i el concept drift reescriu la relació amb la resposta (la campanya que canvia qui abandona). I saps vigilar-ho amb un sistema en capes: estadístics i tests KS/khi quadrat sobre les entrades cada nit, la distribució de prediccions com a canari, les mètriques reals per cohorts quan les etiquetes maduren, i un dashboard on negoci i tècnica es llegeixen junts — tot alimentant un cicle de reentrenament validat, versionat i amb rollback, que converteix el model en un sistema viu. Queda una dimensió que cap dashboard no mesura sola: el model de churn decideix quines persones es contacten, amb quines ofertes i fent servir quines dades — i això planteja preguntes de biaix, equitat, transparència i privadesa. A elles dediquem l'última lliçó del mòdul: les consideracions ètiques de posar aprenentatge automàtic davant de persones reals.