CineClick ja té experiments rastrejats i un model campió versionat i carregable per alias. Abans de servir-lo al mòdul 4 queda un risc silenciós: el model no consumeix dades crues, consumeix features, i aquestes features caldrà recalcular-les en producció. Si el càlcul de producció difereix en alguna cosa del de l'entrenament — un arrodoniment, un valor per defecte, una finestra temporal — el model rebrà números diferents dels que va aprendre i les seves prediccions es degradaran sense cap error visible. Aquest problema es diu training/serving skew, i la indústria ha construït una categoria sencera d'eines per atacar-lo: els feature stores. En aquesta lliçó entendràs què són, quins problemes resolen de debò (skew, point-in-time correctness, reutilització), i — igual d'important — quan no els necessites. Per a CineClick prendrem una decisió deliberadament modesta que el mòdul 4 aprofitarà.

1. Training/serving skew: la corrupció silenciosa
2. El cas ratio_tickets: una feature, dues implementacions
3. Què és un feature store: registre, magatzem offline i magatzem online
4. Point-in-time correctness: el leakage temporal
5. Components i flux d'un feature store
6. Panorama d'opcions: Feast i els gestionats
7. Mirada crítica: quan no el necessites (i què fa CineClick)
8. Tancament del mòdul 3

Recapitulem la cadena de CineClick: preparar_dades neteja el CSV, construir_features (el codi de features.py) transforma columnes crues en les features que el model espera, entrenar ajusta el RandomForest. Tot això passa en entrenament, amb pandas, sobre un fitxer històric.

Ara imagina el servei del mòdul 4 en producció: arriba una petició amb les dades crues d'un client i cal respondre en mil·lisegons. Algú ha de calcular les features d'aquest client en aquell moment, en un altre codi i un altre context. Aquí s'obre l'escletxa:

• Dues implementacions: la de l'entrenament (pandas, batch) i la del serving (potser Python pur, potser un altre equip, potser un altre llenguatge). Dos codis que "fan el mateix" divergeixen tard o d'hora.
• Fallada silenciosa: si la feature de producció val 0.8 on l'entrenament hauria dit 1.2, no hi ha excepció, no hi ha log d'error. El model prediu; simplement prediu pitjor. És el pitjor tipus de bug: el que no avisa.
• Detecció tardana: es descobreix setmanes després, quan algú nota que les campanyes de retenció rendeixen menys del que les mètriques offline prometien — si és que algú ho nota.

Aquest és el problema número 7 del diagnòstic del mòdul 1 ("les features es calculen al notebook i ningú no sap recrear-les fora"), i és dels que més models ha matat a la indústria. El paper clàssic del deute tècnic en ML el llista entre els patrons més costosos precisament per la seva invisibilitat.

Fem-ho concret. L'equip de retenció suggereix una feature nova amb bona pinta: la intensitat de fricció del client, ratio_tickets = tiquets_suport / antiguitat_mesos — no és el mateix 6 tiquets en 36 mesos que 6 tiquets en 3.

Laura la implementa a features.py per a l'entrenament:

Mesos després (escenari hipotètic però dolorosament realista), un altre desenvolupador implementa el càlcul al servei de predicció, llegint la descripció de la feature en un document:

Totes dues implementacions són raonables. Totes dues passen els seus tests. I no calculen el mateix: per a un client acabat d'arribar amb 3 tiquets, l'entrenament deia 3/1 = 3.0 (fricció altíssima, senyal fort de churn) i producció diu 0.0 (fricció nul·la). Just en el segment on la feature més informa — clients nous amb problemes —, el model en producció rep el valor oposat al que va aprendre. Ningú no veurà mai un error; només un model que "en producció no funciona tan bé".

Els remeis possibles, de menys a més maquinària:

1. Una única font de veritat de codi: entrenament i serving importen la mateixa funció del mateix paquet. Cap feature no s'implementa dues vegades.
2. Un feature store: les definicions de features viuen en un sistema central que les calcula i les serveix a tots dos mons.

Vegem l'opció 2 seriosament abans de decidir.

Un feature store és una capa d'infraestructura dedicada a gestionar features com a actius de primera classe. Les seves tres peces:

• Registre de definicions: un catàleg central on cada feature es defineix una vegada — nom, entitat a la qual pertany (el client), tipus, lògica de càlcul, propietari. És la font única de veritat: entrenament i serving consumeixen la mateixa definició, amb la qual cosa l'skew d'implementació desapareix per construcció. A més, habilita la reutilització: si demà CineClick munta un segon model (per exemple, propensió a upgrade), reutilitza ratio_tickets en lloc de reimplementar-la.
• Magatzem offline: valors històrics de les features, amb marca temporal, optimitzats per llegir en massa. És d'on es construeixen els datasets d'entrenament — i el seu superpoder és la point-in-time correctness, que mereix el seu propi apartat.
• Magatzem online: els valors actuals de les features per entitat, en un magatzem de baixa latència (típicament Redis o similar). Quan arriba la petició del client 4812, el servei no calcula res de pesat: fa un lookup de mil·lisegons i obté les mateixes features, calculades per la mateixa lògica, que van alimentar l'entrenament.

El magatzem offline resol un segon problema, més subtil que l'skew: el data leakage temporal. Exemple amb CineClick:

Suposa que entrenem amb etiquetes de març: abandonament=1 significa "aquest client es va donar de baixa al març". Per construir el dataset, algú consulta tiquets_suport de la base de dades operacional... avui, al juliol. El client 4812 es va donar de baixa al març després d'obrir 4 tiquets furiosos aquell mateix mes de març, ja en procés de baixa, i després 2 més a l'abril barallant-se per la devolució. El dataset diu tiquets_suport=6 per a un client etiquetat amb dades de març — però en el moment de la predicció real (febrer, quan encara es podia retenir) en tenia 0.

El model aprèn una regla boníssima en entrenament i inútil en producció: "molts tiquets ⇒ churn"... perquè molts d'aquests tiquets són conseqüència de la baixa, no senyal previ. Mètriques offline inflades, rendiment real decebedor. És l'equivalent temporal d'entrenar amb la resposta filtrada.

La solució es diu point-in-time join (o time-travel join): per a cada fila d'entrenament, el magatzem offline recupera el valor que cada feature tenia en la data de l'etiqueta, i ni un dia després:

Fer això a mà amb pandas és possible (merge_asof, cura quirúrgica amb les dates) però és un camp de mines; els feature stores ho donen resolt perquè emmagatzemen l'historial amb marques temporals. És, probablement, la seva aportació tècnica més valuosa. (Nota honesta sobre el nostre projecte: clients_churn.csv és una foto estàtica sense marques temporals, així que aquest risc està latent però no actiu; es tornarà molt real quan al mòdul 6 parlem de reentrenar amb dades que arriben contínuament.)

El flux complet: les definicions (en codi, versionades a Git) es registren; els pipelines de materialització calculen els valors des de les fonts i els escriuen a tots dos magatzems; l'entrenament llegeix de l'offline amb point-in-time joins; el serving llegeix de l'online amb lookups. La simetria entrenament/serving queda garantida per construcció — aquest és el contracte del feature store.

Sense entrar en tutorials (no és l'objectiu d'aquesta lliçó), el mapa del terreny:

Perquè la idea de "definició declarativa" es vegi amb codi, així es declara una feature view a Feast — llegeix-lo com a esquema conceptual, no com a tutorial:

A partir d'una definició així, el mateix sistema respon get_historical_features(...) (offline, amb point-in-time) i get_online_features(...) (online, en mil·lisegons). La definició és una; els consumidors, dos.

I ara, la part que molts cursos ometen. Un feature store és infraestructura seriosa: un magatzem online que cal operar i pagar, pipelines de materialització que cal orquestrar i vigilar, un framework per aprendre, i una font nova d'incidències ("les features d'ahir no es van materialitzar"). Adoptar-lo sense necessitar-lo és deute operatiu pur — l'error simètric al que aquest curs porta combatent des del mòdul 1: tan dolent és el notebook sense enginyeria com l'enginyeria sense problema que la justifiqui.

Passem CineClick per aquesta taula: un model, un equip (Laura, Marc i tu), features que es calculen en microsegons a partir de les columnes del mateix client, sense agregacions d'historial ni streaming. Columna dreta de cap a peus. Decisió: CineClick no adopta un feature store avui. Però el problema de l'skew és real i cal tancar-lo igualment, així que adoptem el remei proporcionat — l'opció 1 de l'apartat 2, elevada a regla de projecte:

features.py és l'única font de veritat de les features. Tota transformació de dades crues a features viu a src/cineclick_churn/features.py, dins del paquet instal·lable. El pipeline d'entrenament la importa (ja ho fa, via l'stage construir_features), i el servei de predicció del mòdul 4 importarà exactament la mateixa funció — mateix paquet, mateixa versió, mateix .clip(lower=1). Prohibit reimplementar una feature fora d'aquest mòdul.

Això és un "feature store de pobres" perfectament digne: resol l'skew d'implementació pel mateix mecanisme (definició única) sense cost d'infraestructura. No dona point-in-time correctness ni magatzem online — el dia que CineClick tingui tres models, features d'agregació sobre esdeveniments de visionament en streaming i un requisit de latència que obligui a precomputar, la taula de dalt dirà una altra cosa i la migració a Feast serà natural, perquè les definicions ja estan centralitzades i testejades. L'arquitectura correcta no és la més completa, és la proporcionada al problema — revisada quan el problema canvia.

• Adoptar un feature store "perquè és el que es fa": si el teu cas és a la columna dreta de la taula, acabes operant Redis i pipelines de materialització per servir features que un import resolia. Avalua senyals, no modes.
• El contrari: negar el problema de l'skew perquè no fas servir feature store: l'skew no es cura ignorant-lo. Si no hi ha store, hi ha d'haver una altra garantia de definició única (paquet compartit com CineClick) i, al mòdul 5, tests que la vigilin.
• Copiar "només aquesta funció" de features.py al servei "per no dependre del paquet sencer": és exactament així com neix la segona implementació de ratio_tickets. La dependència del paquet és la garantia, no una nosa.
• Construir datasets històrics consultant valors actuals: el leakage temporal de l'apartat 4. Si les teves etiquetes tenen data, les teves features han de ser les d'aquella data. Amb o sense feature store, fes-te sempre la pregunta: "aquest valor es coneixia en el moment de la predicció?".
• Confondre feature store amb "la taula de features al warehouse": una taula compartida ajuda a la reutilització, però no dona point-in-time joins ni serving online ni registre de definicions. Pot ser suficient — però sigues conscient de què et falta.
• Oblidar que les definicions de features també es versionen: si ratio_tickets canvia de fórmula, els models entrenats amb la fórmula vella la continuen esperant. Les definicions van a Git (amb o sense store) i el lineage del model (lliçó anterior) ha de permetre saber amb quina versió es va entrenar.

1. Caçar l'skew. A més del cas d'antiguitat_mesos=0, troba dues altres maneres subtils en què la implementació de serving de ratio_tickets de l'apartat 2 podria divergir de la de l'entrenament, fins i tot corregint el cas del zero. Pista: pensa en tipus de dades i en el significat de tiquets_suport a cada context.

2. Diagnòstic de leakage temporal. Marc proposa afegir la feature hores_setmana_ultim_mes (mitjana d'hores de visionament de l'últim mes) fent servir la taula de visionaments actual per a etiquetes de fa tres mesos. Explica (a) quin valor tindria aquesta feature en entrenament per a un client que es va donar de baixa fa deu setmanes, (b) per què això infla les mètriques offline, i (c) què necessitaria el dataset per construir aquesta feature correctament.

3. Feature store sí o no? Per a cada escenari, decideix amb la taula de senyals i justifica en una o dues frases: (a) una fintech amb 14 models que comparteixen features de comportament transaccional agregades per finestres d'1/7/30 dies, servides online amb pressupost de 50 ms; (b) un equip de dues persones amb un model batch mensual de propensió a compra sobre un extracte estàtic del CRM; (c) CineClick d'aquí a dos anys, amb cinc models (churn, upgrade, recomanació...) que comparteixen agregats d'esdeveniments de visionament en temps gairebé real.

1. Exemples de divergència subtil (n'hi ha més): (a) tipus i arrodoniment — a pandas la divisió produeix float64 a partir de columnes enteres; si el servei rep el JSON amb tiquets_suport com a string ("3") o algú arrodoneix a 2 decimals "per netejar la resposta", els valors deixen de ser idèntics bit a bit i als talls dels arbres a prop del llindar la predicció pot canviar. (b) semàntica de la font — en entrenament tiquets_suport ve del CSV històric (tiquets acumulats segons l'extracte); en producció el servei podria llegir del sistema de suport en viu, que potser també compta tiquets oberts-i-cancel·lats o exclou els de facturació. Mateix nom de camp, població diferent. La moralitat: l'skew no és només codi diferent, també és font diferent — per això la regla de font única cobreix la funció i el contracte de les seves entrades (la signatura del model del registry ajuda amb el segon).

2. (a) A prop de 0: el client porta deu setmanes de baixa, així que el seu visionament "de l'últim mes" (comptat des d'avui) és nul — quan l'etiqueta es va generar, era un client actiu amb hores reals. (b) El model aprèn "hores_ultim_mes ≈ 0 ⇒ abandonament", una regla gairebé perfecta al dataset... que en producció no serveix, perquè allà la feature es calcula per a clients encara actius: la mètrica offline mesura la capacitat de reconèixer baixes ja consumades, no de predir-les. (c) Historial de visionament amb marques temporals i un càlcul point-in-time: per a cada client, la mitjana d'hores del mes anterior a la seva data d'etiqueta. Exactament el join que un magatzem offline dona fet — i que sense ell exigeix un merge_asof acurat sobre l'històric.

3. (a) Sí, clarament: molts models compartint features cares (finestres temporals), serving online amb latència estricta — tots els senyals de la columna esquerra alhora. (b) No: un model, batch, dades estàtiques, equip mínim; una features.py compartida i disciplina de font única basten, i el cost operatiu de l'store no s'amortitza. (c) Probablement sí, i és el moment de reavaluar: features d'agregació sobre esdeveniments compartides entre cinc models activen els senyals de reutilització, cost de càlcul i point-in-time. L'avantatge de la decisió presa avui és que la migració parteix de definicions ja centralitzades i testejades a features.py, no de cinc còpies divergents.

El mòdul 3 tanca el capítol de "gestionar el que s'aprèn". L'experiment churn-cineclick de MLflow desa cada execució amb els seus paràmetres, mètriques, commit i hash de dades — la pregunta "què era la v2?" ja no pot tornar a existir. El registry converteix el guanyador en el model churn-cineclick versió 2, promocionat a @champion (recall 0.68, precision 0.55, F1 0.61) amb revisió humana documentada i rollback a un alias de distància. I les features tenen font única: features.py, al paquet instal·lable, compartida per l'entrenament i pel serving que ve — amb el criteri clar de quins senyals justificarien, demà, un feature store de debò. Repassa l'inventari: codi reproduïble, dades versionades, pipeline declarat, experiments amb memòria, model campió amb nom, versió i signatura, features sense doble implementació. Tot el que un servei de producció necessita carregar està identificat i és traçable — models:/churn-cineclick@champion espera que algú el cridi. El mòdul 4 fa exactament això: triar el patró de desplegament adequat (batch, online o streaming), aixecar un servei de predicció amb FastAPI que carregui el campió i importi les features de la font única, i empaquetar-lo amb Docker perquè corri igual a qualsevol lloc. Laura ja té model; li falta que CineClick pugui fer-lo servir.