Últim cas d'estudi del mòdul. Al mòdul 5 vas entrenar classificadors, regressors, xarxes i clustering sobre el dataset de 2000 lliuraments de Rutalia — en un notebook, amb dades netes i una mètrica al final. Aquesta lliçó tracta del que passa després: quan aquell model ha de prendre decisions cada minut, amb dades que canvien, usuaris que en depenen i conseqüències si s'equivoca. Veurem què canvia del laboratori a producció, recorrerem els grans dominis d'aplicació connectant-los amb el que ja vas construir (desenvolupant-ne de veritat un de nou: el filtratge col·laboratiu dels sistemes de recomanació), estudiarem el cicle de vida real d'un model —deriva (drift), reentrenament, monitoratge—, aprendrem de fallades cèlebres, i acabarem amb el que cap mètrica no captura: l'ètica i la regulació de les decisions automatitzades sobre persones.

1. Del notebook a producció: què canvia
2. Mapa de dominis: on treballa cada algorisme del mòdul 5
3. Cas desenvolupat: un sistema de recomanació amb filtratge col·laboratiu
4. El cicle de vida real: deriva, reentrenament i monitoratge
5. Fallades cèlebres i les seves lliçons
6. Ètica i regulació: decidir sobre persones
7. El cas Rutalia: dos usos del mateix model, dos veredictes
8. Tancament del mòdul: els quatre casos d'estudi

El model és el mateix; l'entorn ho canvia tot:

La conseqüència pràctica: en producció, el model és la peça petita. La major part del sistema és lampisteria de dades (el 06-03 que acabes de veure: ingesta, deduplicació, agregació), validació, monitoratge i governança. Els equips que fracassen solen fracassar en la lampisteria, no en l'algorisme.

Tres notes de modelatge abans del cas desenvolupat:

• L'ETA en logística és la versió en producció del que ja vas fer: el model de minuts_lliurament de 05-03 servint prediccions en temps real. Les apps de repartiment i navegació fan exactament això, amb més variables (trànsit en viu) i reentrenament continu.
• El frau és el regne de la trampa de l'exactitud de 05-02: amb un 0,3 % de positius, el model "mai no és frau" té un 99,7 % d'exactitud i valor zero. En producció s'opera sobre precisió/recall triant el llindar segons el cost asimètric (deixar passar un frau costa X, molestar un client legítim costa Y) — i DBSCAN (05-05) aporta la via no supervisada: el frau nou no està etiquetat, però sol ser soroll que no encaixa en cap patró de comportament.
• Visió i llenguatge: només panorama. Les xarxes que vas escriure en numpy a 05-04 són, conceptualment, el que hi ha dins — la retropropagació i el descens de gradient no canvien; canvien l'arquitectura (convolucions, atenció), l'escala (milers de milions de paràmetres) i el maquinari. No ho desenvolupem aquí: el punt del cas d'estudi és que ja coneixes el mecanisme bàsic.

La peça nova de la lliçó, lleugera però completa. Rutalia reparteix per a un marketplace i vol recomanar productes: "qui va comprar això també va comprar...". La tècnica clàssica és el filtratge col·laboratiu: no necessita saber res dels productes (ni categoria, ni preu) — només la matriu usuari-ítem d'interaccions. La hipòtesi: usuaris amb un historial semblant continuaran assemblant-se en el futur.

Et sona la recepta? És el k-NN de 05-01 amb dos canvis: l'"espai" són les files de la matriu usuari-ítem, i la distància se substitueix per la similitud cosinus (l'angle entre vectors, que ignora quant compra cadascú i mira només el patró). I és també, en el fons, la recomanació d'amistats de 06-02 —veïnatges que se solapen—, amb matriu en lloc de graf.

Llegeix el resultat de U-305 (motxilla, funda): els seus veïns són U-301 (comparteix totes dues) i U-302 (comparteix la motxilla), així que li recomana ampolla amb força — el patró "motxilla+funda" arrossega el de U-301. Ningú no li recomana el carregador: els seus compradors no s'assemblen a U-305 en res. Això és el filtratge col·laboratiu: l'estructura de co-compres fa tota la feina, sense una sola etiqueta ni descripció de producte.

El que separa aquesta joguina d'un sistema real (i on encaixen peces del curs):

• Escala: milions d'usuaris × milions d'ítems, matriu 99,9 % buida. Es fan servir representacions disperses, hashing (01-04) i veïns aproximats; el càlcul de similituds per lots és una feina divideix-agrupa-combina (06-03).
• Arrencada en fred: un usuari nou no té fila. Es cobreix amb popularitat o amb atributs de l'ítem (contingut) fins a acumular historial.
• Retroalimentació: el sistema recomana → l'usuari veu només el que se li recomana → les dades futures reflecteixen les recomanacions, no les preferències. Els biaixos d'aquesta lliçó comencen aquí.

Al laboratori, el flux era lineal: dades → entrenar → avaluar → fi. En producció és un cicle, perquè el món no signa un contracte d'estabilitat amb el teu model:

La deriva és el nom de l'enemic, en dos sabors:

• Deriva de dades: la distribució d'entrada canvia. Rutalia obre repartiment en una ciutat nova: les distàncies i zones ja no s'assemblen a les del dataset de 2000 lliuraments. El model no "es trenca": respon amb seguretat sobre un món que ja no existeix — està extrapolant, el pecat que ja vas veure a la regressió de 05-03.
• Deriva de concepte: canvia la relació entre entrada i sortida. Mateix trànsit, mateixes distàncies, però es reformen els carrers del centre: els mateixos trets ara impliquen altres temps.

Defenses estàndard, totes amb eines que ja tens:

• Monitorar l'entrada, no només la sortida: comparar la distribució recent de cada variable amb la d'entrenament (mitjanes, percentils, histogrames — els resums d'una passada de 06-03). Les alarmes de deriva de dades no necessiten etiquetes i avisen abans que l'error pugi.
• Monitorar dues capes de mètriques: les del model (error de predicció quan arriba l'etiqueta real: el minuts_lliurament observat) i les de negoci (queixes per retard no avisat, taxa de clics de les recomanacions). Poden divergir — un model pot millorar el seu MSE i empitjorar l'experiència si millora on no importa. Mana la mètrica de negoci.
• Reentrenar amb criteri: amb calendari (setmanal/mensual) o disparat per alarmes de deriva. Sempre contra un conjunt de validació temporal — entrenar amb passat, validar amb present; mai a l'inrevés (és la versió temporal del train/test de 05-02).
• Pipeline reproduïble: dades versionades, codi versionat, llavors fixes, model etiquetat. Si el model de la setmana 12 falla, has de poder reconstruir-lo exactament per diagnosticar. Sense reproduïbilitat no hi ha depuració, només arqueologia.

Casos genèrics, tots documentats a la indústria repetides vegades:

• Biaix a les dades → model esbiaixat. Una empresa entrena un filtre de currículums amb les seves contractacions històriques; com que històricament va contractar pocs perfils d'un cert grup, el model aprèn a penalitzar trets correlacionats amb aquest grup. El model no "es va equivocar": va aprendre exactament el que hi havia a les dades — el biaix històric era el patró dominant. Lliçó: les dades són un mirall del passat; si el passat és injust, el model automatitza la injustícia amb aparença d'objectivitat. L'auditoria de la dada (a qui representa? a qui no?) va abans que la del model.
• Fuga de dades (data leakage): el model que copiava. Un model hospitalari "predeia" perfectament una malaltia… fent servir una variable que només s'emplenava després del diagnòstic. A Rutalia: predir el retard fent servir l'hora real de lliurament, o una mitjana de retards calculada sobre TOT l'històric (inclòs el futur del registre). Resultats de test espectaculars, producció inútil. Lliçó: per a cada variable, pregunta "estaria disponible en el moment de predir?". Un resultat massa bo no se celebra: s'investiga.
• Correlació ≠ causalitat. El model detecta que els lliuraments amb embalatge de regal arriben més tard i algú proposa "eliminar l'embalatge de regal per reduir retards". Però l'embalatge no causa el retard: les comandes de regal es concentren en campanyes de pics de demanda. Treure l'embalatge no mourà res. Lliçó: els models del mòdul 5 són màquines de correlació excel·lents per predir; fer-los servir per intervenir ("si canvio X, passarà Y") exigeix anàlisi causal o un experiment controlat (test A/B). Predicció i intervenció són preguntes diferents.

Quan la sortida d'un model afecta persones —un preu, un crèdit, una sanció, una oportunitat—, la conversa deixa de ser només tècnica:

• Transparència: qui rep la decisió ha de poder saber que hi va haver un sistema automatitzat implicat i, en l'essencial, quins factors hi van pesar. Els models interpretables (els arbres i regressions de 05-02/05-03, els coeficients i regles dels quals es llegeixen) tenen aquí un avantatge real sobre caixes més negres: a igualtat aproximada de rendiment, l'interpretable sol ser millor elecció en decisions sensibles.
• Supervisió humana: les decisions amb efectes significatius sobre persones no haurien de ser completament autònomes. El patró sa és el que ja vas veure a 06-01 amb l'optimització: el sistema recomana, la persona decideix — i la persona ha de tenir informació i autoritat reals per contradir-lo, no pas fer de segell automàtic.
• Regulació: a Europa, el RGPD limita les decisions basades únicament en tractament automatitzat amb efectes significatius, i el Reglament europeu d'IA classifica els sistemes per nivell de risc i imposa als d'alt risc (ocupació, crèdit, serveis essencials...) obligacions de gestió de riscos, qualitat de la dada, documentació i supervisió humana. No cal memoritzar l'articulat; cal el reflex: si el teu model puntua persones, assumeix que ets en terreny regulat i que les decisions de disseny (quines dades, quina mètrica, quin llindar) s'hauran d'explicar davant d'algú. Per al detall d'un cas concret, consulta els especialistes legals de la teva organització — és el seu terreny, no el de l'algorisme.

El classificador de retards de 05-02 (arribarà tard aquest lliurament?) es pot desplegar de dues maneres. Mateix model, mateix F1 — i veredictes oposats:

Aquest contrast és la síntesi de la lliçó: la pregunta ètica no és "és bo el model?" sinó "quina decisió alimenta i sobre qui recau l'error?". El mateix F1 pot ser un bon producte o un problema legal i moral, segons l'ús. I nota la ironia tècnica de l'ús B: el retard depèn de la zona, la zona la va assignar un algorisme, i el model l'hi cobraria al repartidor — un sistema penalitzant una persona per les decisions d'un altre sistema. Quan encadenes algorismes (que és just el que aquest mòdul ensenya), també n'encadenes les responsabilitats.

El patró comú als quatre: cap problema real no es va resoldre amb un algorisme. Es va resoldre modelant (traduir el negoci a problemes canònics), combinant (encadenar peces de mòduls diferents) i mesurant (línia base honesta, mètrica de negoci, validació temporal). Aquesta tríada és el que aquest mòdul va afegir sobre els cinc anteriors.

• Optimitzar la mètrica del model i ignorar la de negoci. Un F1 millor que no mou les queixes de clients és un número de vanitat. Defineix la mètrica de negoci abans d'entrenar.
• Avaluar sense respectar el temps. Barrejar passat i futur en train/test (o deixar que una variable "del futur" s'hi coli: fuga de dades) infla els resultats. Validació temporal sempre que les dades tinguin data.
• Confiar en un model que extrapola. Si l'entrada actual no s'assembla a la d'entrenament (deriva), la confiança del model no val res. Monitora la distribució d'entrada, no només l'error.
• Fer servir prediccions per intervenir. "El model diu que X s'associa a retard" no implica que canviar X redueixi retards. Per a intervencions, experimenta (A/B) o analitza causalment.
• Automatitzar la decisió quan bastava automatitzar la recomanació. El salt de "el sistema suggereix" a "el sistema decideix" és el que dispara el risc ètic i regulatori. Fes-lo només deliberadament, amb supervisió i via d'apel·lació.
• Consell: davant de qualsevol desplegament, escriu en una pàgina: què decideix el sistema, sobre qui recau cada tipus d'error, com es detectarà que es degrada i qui el pot aturar. Si no pots escriure aquesta pàgina, no estàs a punt per a producció.

1. Recomanador ítem-ítem. El filtratge de l'exemple compara usuaris. Implementa'l a l'inrevés: similitud cosinus entre columnes (ítems), i recomana a cada usuari els ítems més similars als que ja va comprar. Compara les recomanacions per a U-305 amb les de l'enfocament usuari-usuari. Per què l'enfocament ítem-ítem sol preferir-se en producció quan hi ha molts més usuaris que ítems?
2. Detector de deriva. Amb el generador del dataset de 2000 lliuraments de 05-01, crea un "mes nou" amb les distàncies augmentades un 40 % (la ciutat va créixer). Sense fer servir l'etiqueta, detecta la deriva comparant la mitjana i els percentils 10/50/90 de cada variable entre l'històric i el mes nou, i defineix un llindar d'alarma. Comprova després quant empitjora l'error del model de regressió de 05-03 sobre el mes nou.
3. Caça la fuga de dades. Un company proposa aquestes variables per predir retard en el moment d'assignar la comanda: (a) distància de la comanda, (b) hora de sortida planificada, (c) mitjana de retards del repartidor en els últims 30 dies, (d) minuts reals del lliurament, (e) mitjana de retards de la zona calculada sobre tot el dataset, (f) dia de la setmana. Classifica cadascuna com a vàlida, fuga directa o fuga subtil, i justifica-ho.

1. Per a U-305 (motxilla, funda), la matriu de co-compra dona com a ítems més propers als seus l'ampolla (co-comprada amb motxilla i amb funda via U-301) — coincideix amb l'enfocament usuari-usuari, com és habitual en matrius petites. La preferència industrial per ítem-ítem: amb molts més usuaris que ítems, la matriu de similitud ítem-ítem és petita i estable (els gustos agregats sobre un ítem canvien a poc a poc; un usuari canvia amb cada compra), així que es pot precalcular per lots (06-03) i servir a l'instant; a més és explicable: "perquè vas comprar una motxilla" és una justificació que l'usuari entén — transparència, que connecta amb la secció d'ètica.
2. Esquema: genera hist i nou (amb distancia * 1.4), i per a cada variable calcula (mitjana_nou - mitjana_hist) / desviacio_hist i les diferències de percentils. La distància saltarà diverses desviacions (alarma clara amb un llindar tipus |z| > 0,5); les altres variables no. En aplicar el model antic al mes nou, l'error de minuts_lliurament puja de manera notable, perquè el model extrapola fora del rang de distàncies vist (05-03). L'ordre importa: l'alarma d'entrada dispara abans que existeixi l'etiqueta amb què mesurar l'error — aquesta antelació és el valor del monitoratge de la deriva.
3. (a) vàlida — es coneix en assignar. (b) vàlida — planificada, no real. (c) vàlida amb compte — és legítima si la mitjana fa servir només els 30 dies anteriors a aquesta comanda; si es calcula sobre una finestra que inclou la mateixa comanda o dates posteriors, es torna fuga subtil. A més, com que puntua una persona, arrossega les implicacions ètiques de la lliçó. (d) fuga directa — és (gairebé) la resposta: no existeix fins que el lliurament acaba. (e) fuga subtil — l'agregat "sobre tot el dataset" inclou el futur del registre que s'està predint; en test lluirà de meravella i en producció no estarà disponible tal qual. S'ha de calcular només amb dades anteriors a cada comanda. (f) vàlida. Regla general aplicada: reconstrueix l'instant de la predicció i pregunta a cada variable "ja existies?".

Amb aquesta lliçó es tanca el mòdul de casos d'estudi. Has portat l'aprenentatge automàtic del mòdul 5 al món real: vas veure què canvia del notebook a producció (les dades es mouen, la mètrica que mana és la de negoci, el model és la peça petita del sistema), vas desenvolupar un sistema de recomanació per filtratge col·laboratiu reutilitzant el k-NN de 05-01 amb similitud cosinus sobre la matriu usuari-ítem, vas aprendre a vigilar la deriva i a reentrenar amb validació temporal, vas extreure les lliçons de les fallades cèlebres —biaix a les dades, fuga de dades, correlació que no és causalitat— i vas contrastar dos usos del mateix model de retards de Rutalia: avisar un client (baix risc, bon producte) davant de penalitzar un repartidor (decisió automatitzada sobre una persona, esbiaixada per decisions d'un altre algorisme i en terreny regulat). El mòdul sencer deixa una sola idea repetida quatre vegades: els problemes reals no es resolen amb un algorisme, sinó modelant, combinant i mesurant — optimització a la indústria (06-01), grafs a les xarxes socials (06-02), dades que no caben en una màquina (06-03) i models amb conseqüències (06-04). Ja no queda res del curs per presentar-te: al mòdul 7 el cas d'estudi el tries tu. Definiràs un projecte final integrador (07-01), el desenvoluparàs combinant les peces d'aquests sis mòduls (07-02) i el presentaràs mesurant resultats com hem fet aquí (07-03). Les eines són teves; ara, a construir.