Aprenentatge continu

• Introducció
• Per què actualitzar models?
• Iteració de dades vs. iteració de model
  • Iteració de dades (Data Iteration)
  • Iteració de model (Model Iteration)
  • Quan usar cada estratègia?
  • Implicacions en el pipeline
  • Enfocament híbrid (més comú en producció)
  • Aplicar continual learning amb datasets estàtics
    • Estratègia: Dividir el dataset en fases temporals
    • Workflow conceptual de continual learning simulat
    • Limitacions
• Amb quina freqüència actualitzar?
  • Velocitat del canvi en les dades
  • Cost de l’actualització
  • Valor de la frescor (freshness)
  • Estratègies comunes
• Paradigmes d’actualització: Batch, Streaming, i Continual Learning
  • Què és Continual Learning?
  • Tres paradigmes d’actualització
  • Taula comparativa
  • Quan usar cada paradigma?
  • Desafiaments de Continual Learning
• Casos d’ús i estratègies de re-entrenament
  • Patrons observables
  • De ground truth a dataset d’entrenament
    • Pas 1: Guardar prediccions amb context
    • Pas 2: Vincular ground truth amb prediccions
    • Pas 3: Decidir la finestra de dades
    • Pas 4: Validar el dataset resultant
    • Resum del procés
• Entrenament amb estat vs. sense estat
  • Entrenament sense estat (Stateless training)
  • Entrenament amb estat (Stateful training)
  • Quin triar?
• Automatització del pipeline d’actualització
  • Components del pipeline
  • Estructura d’un script d’actualització
  • Programació amb cron
  • Comparació de models abans de desplegar
    • Per què comparar?
    • Què comparar?
    • Criteris de decisió
    • Resum de la comparació
• Test en producció
  • El problema
  • Shadow Deployment (Desplegament ombra)
  • A/B Testing
  • Canary Deployment (Desplegament canari)
  • Bandits (Multi-armed bandits)
  • Comparativa de les estratègies
  • Recomanació pràctica
• Consideracions pràctiques
  • Versionat de models
    • Per què és més crític en continual learning?
    • Metadata extesa per continual learning
    • Comparació automàtica abans de desplegar
    • Històric de desplegaments
  • Rollback
  • Documentació de canvis
• Resum

Introducció

Al capítol anterior hem vist com detectar quan les dades canvien i el model comença a degradar-se. La pregunta natural és: què fem quan això passa? La resposta és actualitzar el model, però això obre tot un conjunt de nous reptes.

L’aprenentatge continu (continual learning) és el procés d’actualitzar models en producció per adaptar-se a les dades canviants. No es tracta simplement de re-entrenar de tant en tant, sinó de crear un sistema que pugui evolucionar de manera fiable i segura.

En aquest capítol explorarem quan i com actualitzar models, i les estratègies per provar models nous en producció sense arriscar el servei.

Per què actualitzar models?

Recordem els tipus de drift que hem vist:

• Covariate shift: Les features canvien, cal que el model s’adapti a nous patrons d’entrada
• Label shift: La proporció de classes canvia, cal recalibrar
• Concept drift: La relació entre features i sortida canvia, el model ha après coses que ja no són certes

A més del drift, hi ha altres raons per actualitzar:

• Més dades disponibles: Hem acumulat més exemples que poden millorar el model
• Noves features: Tenim accés a dades noves que poden ser predictives
• Correccions de bugs: Hem descobert errors en el preprocessament o l’entrenament
• Millores algorítmiques: Volem provar un algoritme o arquitectura millor

Iteració de dades vs. iteració de model

Quan el rendiment del model degrada, tenim dues estratègies diferents que sovint es confonen:

Iteració de dades (Data Iteration)

Re-entrenar el model amb dades noves, mantenint l’arquitectura.

• Mateixa arquitectura de model i features
• Afegir mostres noves (nous patrons, concept drift)
• Exemple: Model de frau re-entrenat setmanalment amb nous casos de frau (mateixa arquitectura)

Iteració de model (Model Iteration)

Canviar l’arquitectura o afegir noves features.

• Afegir noves features (noves fonts de dades)
• Canviar arquitectura (algoritme diferent, més complexitat)
• Ajustar hiperparàmetres
• Exemple: Model de crèdit que afegeix “historial laboral” O canvia de regressió logística a XGBoost

Quan usar cada estratègia?

Implicacions en el pipeline

Pipeline d’iteració de dades:

1. Recollir dades noves amb ground truth — el resultat real que confirma si la predicció era correcta (veure De ground truth a dataset d’entrenament per al procés detallat)
2. Validar qualitat de dades
3. Re-entrenar mateixa arquitectura amb dades noves/actualitzades
4. Mantenir features i hiperparàmetres
5. Desplegar si la validació passa

Pipeline d’iteració de model:

1. Fixar datasets d’entrenament/validació/test (versionats!)
2. Afegir noves features O canviar arquitectura
3. Entrenar i comparar candidats sobre el mateix test set
4. Seleccionar millor configuració
5. Re-entrenar amb totes les dades i desplegar

Enfocament híbrid (més comú en producció)

• Iteració de dades regular (setmanal/mensual) → manté el model fresc
• Iteració de model ocasional (trimestral/anual) → millora capacitat fonamental

Relació amb valor de negoci:

• Iteració de dades → s’adapta al món canviant (patrons de frau evolucionen)
• Iteració de model → millora capacitat fonamental (nous senyals, millor arquitectura)

Aplicar continual learning amb datasets estàtics

Fins ara hem parlat de conceptes com si tinguéssim un flux continu de dades. Però durant l’aprenentatge i desenvolupament, sovint treballem amb datasets estàtics. Com apliquem aquests conceptes?

⚠️ Simulació per a aprenentatge: Aquesta secció mostra com practicar continual learning amb datasets estàtics. En producció real, els sistemes utilitzen flux continu de dades reals. Els splits estàtics són només per a aprenentatge i validació de la infraestructura. Per a simulació de drift amb dades estàtiques (modificar features artificialment per validar codi de detecció), consulteu el capítol de monitoratge.

Estratègia: Dividir el dataset en fases temporals

Quan treballem amb un dataset fix, la solució és dividir-lo de manera que simuli l’arribada de dades en el temps.

La idea és tractar diferents parts del dataset com si fossin moments diferents en el temps:

Divisió típica:

• Training Set (60%): Entrenar el model inicial
• Validation Set (20%): Ajustar hiperparàmetres i avaluar
• Production Set (20%): Subdividir en múltiples batches que simulen l’arribada de dades en el temps

Subdivisió del Production Set:

• Batch 1: Primeres “dades de producció” → establir baseline de rendiment
• Batch 2: “Dades noves” que arriben després → detectar drift, decidir si reentrenar
• Batch 3, 4…: Cicles addicionals per simular evolució temporal

Workflow conceptual de continual learning simulat

Fase 1: Entrenament inicial

• Entrenar model amb training set
• Validar amb validation set
• Guardar model inicial (versió 1.0.0)

Fase 2: Producció inicial (Batch 1)

• “Desplegar” el model
• Fer prediccions sobre Batch 1
• Calcular mètriques de referència (baseline)
• Guardar aquestes mètriques per comparació futura

Fase 3: Arribada de “dades noves” (Batch 2)

• Simular pas del temps: apareix Batch 2
• Detectar drift: Comparar distribució de Batch 2 vs Batch 1
• Avaluar degradació: El model manté el rendiment en Batch 2?
• Si hi ha degradació significativa → considerar reentrenament

Fase 4: Decisió de reentrenament

• Criteri: Si rendiment cau més d’un llindar (ex: 5% de degradació)
• Estratègies:
  • Reentrenar des de zero amb training + Batch 1
  • Fine-tuning del model existent amb Batch 1
• Validació: El nou model millora en Batch 2?
• Decisió: Si millora → desplegar nova versió; si no → mantenir model actual

Cicles addicionals:

• Repetir el procés amb Batch 3, 4, etc.
• Cada cicle pot decidir si reentrenar o no
• Acumulant dades: training + batch1 + batch2 + …
• Gestionant versions: v1.0.0 → v1.1.0 → v1.2.0

Limitacions

Aquesta simulació és útil per aprendre, prototipar pipelines i validar estratègies de reentrenament. Però no pot replicar aspectes de producció real com el delay en obtenir etiquetes, patrons temporals reals (estacionalitat, tendències), o el volum continu de dades. En producció, cal infraestructura de streaming i monitoratge continu.

Amb quina freqüència actualitzar?

No hi ha una resposta universal. Depèn de:

Velocitat del canvi en les dades

Si les dades canvien ràpidament (per exemple, tendències en xarxes socials), necessitem actualitzacions freqüents. Si són estables (per exemple, detecció de defectes en manufactura), podem actualitzar menys sovint.

Cost de l’actualització

Cada actualització té costos:

• Computacional: Temps de GPU/CPU per entrenar
• Humà: Temps d’enginyers per validar i desplegar
• Risc: Possibilitat d’introduir regressions

Valor de la frescor (freshness)

No sempre tenir el model més recent és millor. Cal preguntar-se: quant guanyem amb dades més recents?

Un estudi de Facebook va mostrar que passar d’entrenament setmanal a diari reduïa la pèrdua del model en un 1%. Per a alguns casos, aquest 1% pot valer milions; per a altres, no justifica l’esforç.

Estratègies comunes

Paradigmes d’actualització: Batch, Streaming, i Continual Learning

El terme “aprenentatge continu” (continual learning) pot ser ambigu. Aquí definirem clarament tres paradigmes diferents.

Què és Continual Learning?

Continual Learning no es refereix només a algoritmes d’aprenentatge incremental, sinó a crear infraestructura que permeti actualitzar models ràpidament quan calgui — des de zero o amb fine-tuning — i desplegar-los de manera àgil.

És una qüestió d’infraestructura i procés, no només d’algoritme.

Tres paradigmes d’actualització

1. Batch Retraining (Aprenentatge per lots)

• Model entrenat des de zero a intervals discrets
• Re-entrenament programat (setmanal, mensual)
• Pipeline de desplegament lent (dies a setmanes)
• Exemple: Re-entrenament mensual amb aprovació manual

2. Streaming Retraining (Re-entrenament amb finestres)

• Model re-entrenat des de zero sobre finestres de dades recents
• Finestra lliscant o expansiva d’exemples recents
• Pipeline més ràpid (hores a dies)
• Exemple: Re-entrenament diari amb els últims 30 dies de dades

3. Continual Learning (Infraestructura per actualitzacions ràpides)

• Infraestructura que suporta actualitzacions ràpides quan calgui
• Pot usar re-entrenament stateless (des de zero) O stateful (fine-tuning)
• Pipeline de desplegament ràpid (minuts a hores)
• Monitoratge, validació, i desplegament automatitzats
• Exemple: Re-entrenament automàtic quan es detecta drift, amb A/B testing i rollback automàtic

Taula comparativa

Quan usar cada paradigma?

Batch Retraining:

• Canvis en dades lents i predictibles
• Revisió manual requerida (mèdic, financer)
• Equip petit, infraestructura simple
• Freqüència de setmanes/mesos acceptable

Streaming Retraining:

• Dades arriben contínuament, patrons canvien moderadament
• Equilibri entre frescor i validació
• Es poden definir finestres temporals significatives

Continual Learning:

• Patrons canvien ràpidament i impredictiblement (frau, spam)
• Necessitat de respondre a drift en hores
• Recursos d’enginyeria per pipelines automatitzats
• Flexibilitat: re-entrenament des de zero O fine-tuning

Desafiaments de Continual Learning

Challenge: Validació automatitzada

• Solució: Test suites complets, holdout sets, A/B testing

Challenge: Detecció de drift i triggering

• Solució: Monitoritzar distribucions, performance, confiança; activar per llindars

Challenge: Pipeline de desplegament ràpid

• Solució: Contenidors, CI/CD, testing automatitzat

Challenge: Rollback i versionat

• Solució: Model registry, blue-green deployment, rollback automàtic

Evitar sobre-enginyeria: La majoria de sistemes usen batch o streaming. Només implementar continual learning quan:

1. Negoci requereix actualitzacions ràpides (hores, no dies)
2. Patrons canvien ràpidament
3. Tens recursos d’enginyeria per mantenir pipelines automatitzats

Casos d’ús i estratègies de re-entrenament

Un cop hem vist els paradigmes d’actualització, vegem com s’apliquen en contextos reals. La taula següent mostra diferents casos d’ús amb les seves característiques i l’estratègia de re-entrenament més adequada.

Ground truth (veritat de referència): el resultat real i verificat que ens indica si la predicció del model era correcta. Per exemple, en detecció de frau, el ground truth és la confirmació posterior de si la transacció era realment fraudulenta. La manera com obtenim aquest ground truth (automàticament, manualment, o amb quin delay) determina quina estratègia de re-entrenament podem seguir.

Patrons observables

Analitzant aquests casos, veiem diversos patrons que ens ajuden a decidir l’estratègia:

Ground truth automàtic + delay curt → Continual Learning o Streaming

• Exemples: Spam filtering, detecció de frau, predicció de transport
• Permet actualitzacions freqüents i automatitzades
• Avantatge: model sempre actualitzat amb els patrons més recents

Ground truth manual → Batch

• Exemples: Diagnòstic mèdic, classificació de documents
• Requereix revisió humana, actualitzacions menys freqüents
• Avantatge: alta qualitat de les etiquetes, validació experta

Ground truth mixt → Streaming

• Exemples: Moderació de contingut, sistemes de recomanació
• Equilibri entre automatització i qualitat
• Avantatge: combina volum (automàtic) amb precisió (manual)

Crític per seguretat/salut → Batch amb validació humana

• Exemples: Diagnòstic mèdic, detecció de defectes crítics
• Encara que hi hagi drift, la revisió manual és imprescindible
• Avantatge: control de qualitat abans de desplegament

Consell pràctic: Comença sempre amb Batch i evoluciona cap a Streaming o Continual Learning només si:

1. Tens prou dades noves cada dia/setmana
2. Pots automatitzar la validació de manera fiable
3. El valor de negoci justifica la complexitat addicional

De ground truth a dataset d’entrenament

Hem vist quins tipus de ground truth existeixen i amb quin delay arriben. Però com passem d’obtenir ground truth a tenir un dataset llest per re-entrenar? Aquest pas sovint es dona per fet, però requereix un disseny explícit.

Pas 1: Guardar prediccions amb context

Cada vegada que el model fa una predicció en producció, cal guardar-la juntament amb la informació necessària per vincular-la amb el ground truth futur:

Sense aquest registre, quan arribi el ground truth no podrem associar-lo amb la predicció original.

Pas 2: Vincular ground truth amb prediccions

Quan el ground truth arriba (hores, dies, o setmanes després), cal fer el join amb les prediccions guardades:

Ground truth automàtic (clicks, sensors, verificacions):

• Un procés periòdic consulta la font de ground truth (base de dades de transaccions verificades, logs de clicks, lectures de sensors)
• Fa join per prediction_id o per clau de negoci (ex: transaction_id)
• Marca les prediccions com a “etiquetades”

Ground truth manual (experts, revisors):

• Les prediccions pendents d’etiquetar es presenten als revisors (interfície d’anotació, cua de revisió)
• Els revisors assignen l’etiqueta correcta
• Es fa join amb la predicció original

Ground truth que mai arriba:

• No totes les prediccions rebran ground truth (l’usuari no fa click, el revisor no arriba a revisar-ho)
• Cal decidir: descartar-les? Assumir que la predicció era correcta? Usar-les només per monitoratge de distribucions?
• En general, no incloure al dataset d’entrenament registres sense ground truth confirmat

Pas 3: Decidir la finestra de dades

Un cop tenim prediccions etiquetades, cal decidir quines incloure al dataset de re-entrenament:

Finestra expansiva (expanding window):

• Totes les dades acumulades des del principi: training original + batch 1 + batch 2 + ...
• Avantatge: més dades, més representativitat històrica
• Desavantatge: el dataset creix indefinidament; patrons antics poden diluir els recents

Finestra lliscant (sliding window):

• Només les dades dels últims N dies/setmanes: últims 90 dies
• Avantatge: el model s’adapta als patrons recents
• Desavantatge: perd context històric; pot fallar en patrons estacionals

Híbrid (comú en producció):

• Mostra representativa de dades històriques + totes les dades recents
• Exemple: 20% mostreig aleatori de dades antigues + 100% dels últims 30 dies
• Equilibri entre memòria històrica i adaptació a canvis recents

Pas 4: Validar el dataset resultant

Abans de re-entrenar, verificar que el dataset és coherent:

• Volum mínim: Suficients mostres per classe (evitar classes amb 2-3 exemples)
• Distribució d’etiquetes: No ha canviat dràsticament sense explicació (possible error en el procés de join)
• Completesa de features: No hi ha features amb molts nuls nous
• Temporalitat: Les dates de ground truth són posteriors a les prediccions (no hi ha fuites temporals)

Resum del procés

Producció          Ground Truth           Dataset
─────────          ────────────           ───────
Predicció ──────► Guardar amb context
                        │
                  (passa el temps)
                        │
                  Arribar GT ──────► Join per ID
                                        │
                                  Triar finestra
                                        │
                                  Validar qualitat
                                        │
                                  Dataset per re-entrenar

Aquest procés és el que connecta la taula de casos d’ús anterior (quin ground truth tenim i amb quin delay) amb les decisions d’entrenament que veurem a continuació: entrenar des de zero o incrementalment, i com automatitzar-ho.

Entrenament amb estat vs. sense estat

Quan re-entrenem, tenim dues opcions principals:

Entrenament sense estat (Stateless training)

Entrenem el model des de zero amb totes les dades disponibles (històriques + noves).

Avantatges:

• Simple conceptualment
• El model veu totes les dades
• No arrossega errors anteriors

Desavantatges:

• Costós computacionalment si hi ha moltes dades
• Pot “oblidar” patrons antics si les dades recents dominen

Entrenament amb estat (Stateful training)

Continuem entrenant el model existent amb només les dades noves.

Avantatges:

• Molt més ràpid
• Menys recursos computacionals
• Ideal per a actualitzacions freqüents

Desavantatges:

• Risc d’oblit catastròfic (catastrophic forgetting): el model oblida el que sabia
• Pot acumular errors

Exemple real: Grubhub va passar d’entrenament setmanal sense estat a entrenament diari amb estat, reduint el cost computacional 45 vegades i augmentant les conversions un 20%.

Quin triar?

Una estratègia comuna és combinar-los:

• Entrenament amb estat per a actualitzacions freqüents (diari/setmanal)
• Entrenament sense estat periòdicament (mensual/trimestral) per “netejar” el model

Automatització del pipeline d’actualització

Per fer l’actualització sostenible, necessitem automatitzar-la. Aquí presentem un esquema basat en scripts Python simples.

Components del pipeline

Estructura d’un script d’actualització

Un script d’actualització automàtica (update_model.py) segueix aquest flux:

1. Carregar dades noves des de la font configurada (el dataset construït al pas anterior)
2. Validar dades (nuls, mínim de mostres, schema — veure també Pas 4 de la secció anterior)
3. Entrenar model candidat amb les dades
4. Avaluar i calcular mètriques (F1, accuracy)
5. Comparar amb model actual (si existeix)
6. Decidir: Si el candidat és millor o igual → guardar i desplegar; si no → rebutjar
7. Registrar mètriques i metadata

L’script retorna exit code 0 (èxit) o 1 (error/rebutjat), permetent integració amb CI/CD i cron.

Programació amb cron

Per executar l’script automàticament, podem usar cron:

# Executar cada dia a les 3:00 AM
0 3 * * * /usr/bin/python3 /scripts/update_model.py >> /logs/cron.log 2>&1

Comparació de models abans de desplegar

Un dels passos més importants del pipeline d’actualització és comparar el model candidat amb el model actual abans de desplegar. Sense aquesta comparació, podem desplegar models pitjors accidentalment.

Per què comparar?

Problema sense comparació:

• Entrenem un model nou → sembla “bo” (F1 = 0.78)
• El despleguem → les mètriques empitjoren
• Resulta que el model anterior era millor (F1 = 0.82)!

Solució: Sempre comparar candidat vs actual.

Què comparar?

Mètriques tècniques:

• F1, precision, recall, accuracy
• ROC-AUC, PR-AUC
• Per regressió: MAE, RMSE, R²

Mètriques operacionals:

• Latència de predicció (p50, p95, p99)
• Mida del model (MB)
• Temps d’inferència

Mètriques de negoci (si disponibles):

• Cost estimat de prediccions errònies
• ROI esperat
• Impacte en conversió/vendes

Criteris de decisió

Definir regles clares per decidir si desplegar el candidat. Criteris típics:

La lògica és: si el model candidat és igual o millor en mètriques i no empitjora significativament en aspectes operacionals → desplegar. Si no → mantenir l’actual.

Resum de la comparació

Essencial per continual learning:

• ✅ Sempre comparar candidat vs actual
• ✅ Usar múltiples dimensions (mètriques + latència + mida)
• ✅ Definir criteris clars de desplegament
• ✅ Fer backup abans de reemplaçar

Flux recomanat:

1. Entrenar model candidat
2. Comparar amb actual (mètriques, latència, mida)
3. Decidir automàticament basant-se en regles
4. Si aprovat → backup + desplegament
5. Si rebutjat → descartar candidat

Amb comparació automàtica, evitem desplegar models pitjors i mantenim qualitat constant!

Test en producció

Un cop tenim un model candidat que sembla bo en les proves offline, com sabem si funcionarà bé en producció real? Aquí és on entren les estratègies de test en producció (testing in production).

El problema

Les proves offline (amb dades històriques) tenen limitacions:

• No capturen el comportament real dels usuaris
• No detecten problemes d’integració amb altres sistemes
• No mesuren l’impacte en mètriques de negoci reals

Per això, necessitem estratègies per provar models en producció de manera controlada.

Shadow Deployment (Desplegament ombra)

El nou model rep les mateixes peticions que el model actual, però les seves prediccions no s’utilitzen. Només serveixen per comparar.

Avantatges:

• Zero risc per als usuaris
• Podem comparar prediccions directament
• Detectem problemes d’integració

Desavantatges:

• Duplica el cost computacional
• No mesura l’impacte real en el comportament dels usuaris

Implementació: L’API carrega ambdós models. Per cada petició, executa els dos però només retorna la predicció del model actual. Les prediccions del shadow es registren per anàlisi posterior.

A/B Testing

Dividim el tràfic entre el model actual (A) i el nou model (B), i mesurem quina versió funciona millor segons mètriques de negoci.

Avantatges:

• Mesura l’impacte real en mètriques de negoci
• Estadísticament rigorós si es fa bé

Desavantatges:

• Part dels usuaris reben el model potencialment pitjor
• Requereix més temps per tenir resultats significatius
• Necessita infraestructura per dividir tràfic

Implementació: Usar un hash del user_id per assignar consistentment cada usuari a la versió A o B (així el mateix usuari sempre rep la mateixa versió). Registrar la versió amb cada predicció per poder analitzar mètriques per grup.

Canary Deployment (Desplegament canari)

Similar a l’A/B testing, però amb l’objectiu de detectar problemes, no de comparar rendiment. Enviem un petit percentatge del tràfic al nou model i augmentem gradualment si tot va bé.

Avantatges:

• Limita l’impacte de problemes
• Permet rollback ràpid
• Detecta problemes que no apareixen en tests

Desavantatges:

• Requereix monitoratge proper durant el desplegament
• Més lent que un desplegament directe

Bandits (Multi-armed bandits)

Els bandits són una alternativa més sofisticada a l’A/B testing. En lloc de dividir el tràfic de manera fixa, el sistema aprèn dinàmicament quina versió funciona millor i li envia més tràfic.

Inici:     Model A: 50% | Model B: 50%
Dia 3:     Model A: 60% | Model B: 40%  (A sembla millor)
Dia 7:     Model A: 80% | Model B: 20%  (A confirmat millor)

Avantatges:

• Minimitza el “regret” (tràfic enviat al model pitjor)
• S’adapta automàticament

Desavantatges:

• Més complex d’implementar
• Menys control sobre la divisió del tràfic
• Pot ser prematur si les diferències són petites

Per al nostre context, l’A/B testing o el canary deployment són més pràctics i fàcils d’entendre i implementar.

Comparativa de les estratègies

Recomanació pràctica

Un flux recomanat per a equips petits:

1. Shadow deployment primer: Verificar que el model nou funciona sense errors
2. Canary amb 5-10%: Detectar problemes d’integració
3. Si tot va bé, desplegament complet o A/B test si volem mesurar impacte

Consideracions pràctiques

Versionat de models

El versionat de models (semantic versioning, metadata, estructura de directoris, symlinks) es tracta en detall al capítol de desplegament. Aquí ens centrem en els aspectes específics del continual learning.

Per què és més crític en continual learning?

Quan els models canvien freqüentment (setmanal, diari, o més), el versionat passa de ser una bona pràctica a ser imprescindible:

• Cal comparar nou model vs actual abans de desplegar
• Si un model nou falla, necessitem rollback immediat
• Hem de poder auditar quin model va fer quina predicció i quan

Metadata extesa per continual learning

A més de la metadata bàsica (versió, mètriques, features), el continual learning requereix:

• Dataset info: Quantes dades, de quin període, hash del dataset
• Data version: Quin split de dades es va usar per entrenar
• Training time: Quan es va entrenar i quant temps va trigar

Aquesta informació és essencial per reproduir entrenaments i diagnosticar regressions.

Comparació automàtica abans de desplegar

Abans d’actualitzar el symlink current -> v1.3.0, cal comparar les mètriques del candidat vs. l’actual. Si el candidat és igual o millor → desplegar; si no → mantenir l’actual. Aquesta comparació s’hauria d’automatitzar dins del pipeline d’actualització.

Històric de desplegaments

Mantenir un fitxer deployment_history.json que registri cada desplegament: versió, data, raó del canvi, i quina versió l’ha reemplaçat. Això permet auditar l’historial i entendre per què s’han fet canvis.

Rollback

Sempre hem de poder tornar a la versió anterior ràpidament:

#!/bin/bash
# rollback.sh - Torna a la versió anterior del model

set -e  # Sortir si hi ha errors

CURRENT=$(readlink -f /models/current_model.pkl || echo "")
if [ -z "$CURRENT" ]; then
    echo "Error: No s'ha trobat el model actual"
    exit 1
fi

PREVIOUS=$(find /models -name 'model_v*.pkl' -type f | grep -v "$CURRENT" | sort -r | head -1)
if [ -z "$PREVIOUS" ]; then
    echo "Error: No hi ha model anterior disponible"
    exit 1
fi

echo "Rollback de $CURRENT a $PREVIOUS"
ln -sf "$PREVIOUS" /models/current_model.pkl

# Reiniciar el contenidor per carregar el model antic
if docker restart model_api; then
    echo "Rollback completat amb èxit"
else
    echo "Error: Fallida al reiniciar el contenidor"
    exit 1
fi

Documentació de canvis

Mantenir un registre de tots els canvis:

# Changelog de models

## v1.1.0 (2024-02-01)
- Afegides 3 noves features
- Re-entrenat amb dades de gener
- Accuracy: 0.89 (+0.02)

## v1.0.0 (2024-01-15)
- Versió inicial
- Accuracy: 0.87

Resum

En aquest capítol hem après:

• L’aprenentatge continu és necessari perquè els models s’adaptin als canvis en les dades
• La freqüència d’actualització depèn de la velocitat del canvi, el cost, i el valor de la frescor
• El pas de ground truth a dataset d’entrenament requereix guardar prediccions amb context, vincular-les amb el resultat real quan arribi, i decidir la finestra de dades adequada
• L’entrenament amb estat és més eficient però pot acumular errors; combinar-lo amb entrenament sense estat periòdicament és una bona estratègia
• Un pipeline automatitzat amb scripts Python pot gestionar la recollida de dades, entrenament, validació, i desplegament
• Les estratègies de test en producció (shadow, A/B testing, canary) permeten validar models amb tràfic real de manera controlada
• El versionat i la capacitat de rollback són essencials per a operacions segures

Amb això completem la visió del cicle de vida d’un model en producció: des del desplegament inicial amb Docker i FastAPI, passant pel monitoratge i detecció de drift, fins a l’actualització contínua i el test en producció.