Si treballes amb machine learning, és molt probable que hagis viscut aquesta escena: un model amb mètriques excel·lents al notebook, celebrat a la reunió de resultats... i que sis mesos després continua sense utilitzar-se en cap sistema real. No és mala sort ni un cas aïllat: és el destí de la majoria dels models que s'entrenen a la indústria. En aquesta lliçó veurem què és MLOps, per què existeix com a disciplina, què aporta respecte al DevOps clàssic i per què el salt del notebook a producció és tan difícil. També coneixerem CineClick, la plataforma fictícia de streaming que ens acompanyarà durant tot el curs com a fil conductor.

1. L'escena del crim: un model que mai no va arribar a producció
2. Definició de MLOps
3. Què aporta MLOps respecte al DevOps clàssic
4. La bretxa notebook → producció
5. El deute tècnic ocult dels sistemes de ML
6. Beneficis d'adoptar MLOps
7. CineClick: el nostre exemple motivador

Imagina't l'equip de dades de CineClick, una plataforma de streaming per subscripció. Una data scientist ha entrenat un model que prediu quins subscriptors es donaran de baixa (churn). El model funciona bé al seu notebook: bones mètriques, gràfiques convincents, aplaudiments a la demo.

I aleshores comencen les preguntes incòmodes:

• Com el fem servir? L'equip de retenció vol una llista diària de clients en risc. El model viu en un .ipynb al portàtil de la data scientist.
• Pots reentrenar-lo amb les dades d'aquest mes? El CSV original ja no existeix; es va sobreescriure. Ningú no sap exactament amb quines dades es va entrenar.
• Per què avui dona resultats diferents que ahir? Ningú no va fixar llavors aleatòries ni versions de llibreries.
• Qui el manté quan la data scientist sigui de vacances? Silenci.

Cap d'aquestes preguntes no és sobre machine learning. Totes són sobre enginyeria, processos i operació. Aquest és exactament el buit que MLOps ve a cobrir.

MLOps (Machine Learning Operations) és el conjunt de pràctiques, processos i eines que permeten portar models de machine learning a producció i mantenir-los funcionant de manera fiable, reproduïble i auditable al llarg del temps.

Dit d'una altra manera: MLOps és la disciplina que converteix un experiment de ML en un producte de programari amb totes les garanties. Combina tres mons:

• Machine Learning: entrenar i avaluar models.
• Enginyeria de programari: codi versionat, testat, empaquetat i desplegable.
• Operacions (Ops): automatització, monitoratge, resposta a incidències.

Convé subratllar el que MLOps no és:

• No és una eina concreta (tot i que en farem servir unes quantes en aquest curs).
• No és "pujar el model a un servidor" i oblidar-se'n.
• No és un rol d'una sola persona: és una manera de treballar de tot l'equip.

Una definició operativa que farem servir durant el curs: un model és "en producció" quan altres sistemes o persones depenen de les seves prediccions, i l'equip pot reentrenar-lo, redesplegar-lo i vigilar-lo sense heroïcitats.

Si vens del món del programari, potser penses: "això ja existeix i es diu DevOps". És una bona intuïció, i de fet MLOps ho hereta gairebé tot de DevOps: integració contínua, desplegament continu, infraestructura com a codi, monitoratge. Però hi ha una diferència fonamental.

En el programari clàssic hi ha un artefacte canviant: el codi. Si el codi no canvia, el sistema es comporta igual demà que avui.

En un sistema de ML hi ha tres artefactes canviants i interdependents:

1. El codi (preprocessament, entrenament, servei).
2. Les dades (canvien constantment, i amb elles el comportament del model).
3. El model (un binari generat a partir dels dos anteriors, amb la seva pròpia versió i cicle de vida).

Aquesta taula resumeix les diferències clau:

El punt més contraintuïtiu per a qui ve del programari és el tercer: un sistema de ML es pot trencar sense que ningú no hagi desplegat res. Si CineClick canvia els seus plans de preus, el model de churn entrenat amb els plans antics començarà a fallar silenciosament, encara que faci mesos que ningú no toca el seu codi. Això obliga a monitorar i reentrenar de manera contínua, una cosa que en el DevOps clàssic no té un equivalent directe (ho veurem en profunditat al mòdul 6).

Les xifres que circulen a la indústria varien segons l'estudi, però apunten en la mateixa direcció: una gran majoria dels models que s'entrenen no arriben mai a producció, o triguen mesos a fer-ho. Per què?

El notebook és una eina magnífica per explorar: iterar ràpid, visualitzar, provar idees. Però tot allò que el fa bo per explorar el fa dolent per produir:

• Execució fora d'ordre: les cel·les es poden executar en qualsevol ordre, així que l'estat final depèn de la història de clics, no del codi escrit. Dues persones amb el mateix notebook poden obtenir resultats diferents.
• Estat ocult: variables definides en cel·les ja esborrades continuen vives a la memòria. El notebook "funciona" fins que reinicies el kernel.
• Sense tests ni modularitat: tot és un script llarg; no hi ha funcions reutilitzables ni proves automàtiques.
• Dependències implícites: rutes absolutes al disc local, llibreries instal·lades a mà sense registrar-ne les versions.
• Dades sense versionar: el CSV que vas fer servir pot haver canviat o desaparegut.

El resultat és l'anomenada bretxa notebook → producció: la feina necessària per passar de "funciona a la meva màquina" a "funciona de manera fiable per al negoci" sol ser molt més gran que la feina d'entrenar el model. Els equips sense pràctiques MLOps creuen aquesta bretxa a mà, una vegada, amb dolor... i no ho poden repetir.

Important: la resposta no és prohibir els notebooks. Són l'eina correcta per a la fase d'exploració. El problema és quedar-s'hi. Al mòdul 2 veurem precisament com extreure la feina del notebook cap a codi estructurat i reproduïble.

L'any 2015, un grup d'enginyers de Google va publicar un paper molt influent, "Hidden Technical Debt in Machine Learning Systems", la idea central del qual es resumeix en una frase: en un sistema de ML real, el codi del model és una fracció diminuta del sistema total. Al voltant d'aquest petit nucli hi ha una enorme infraestructura de recollida de dades, verificació, gestió de recursos, servei, monitoratge... i és allà on s'acumula el deute.

Explicat amb les nostres paraules, el paper identifica formes de deute tècnic que només existeixen en sistemes de ML (o que en ML són molt pitjors):

• Erosió de fronteres (entanglement): en programari clàssic pots canviar un mòdul sense tocar els altres si respectes les interfícies. En ML, tot afecta tot: canviar una feature, afegir una columna o retocar el preprocessament canvia el comportament de tot el model. Ho resumeixen com a "CACE": Changing Anything Changes Everything (canviar qualsevol cosa ho canvia tot).
• Dependències de dades: són més perilloses que les dependències de codi perquè no hi ha compilador ni linter que les detecti. Si l'equip de facturació de CineClick reanomena la columna metode_pagament o en canvia els valors possibles, el model de churn es degrada sense que salti cap error.
• Bucles de realimentació ocults: el model influeix en el món que després genera les seves dades. Si el model de churn de CineClick fa que retenció truqui als clients en risc i molts es quedin, les dades futures diran que "aquests perfils no abandonen"... precisament perquè el model va actuar. El model acaba aprenent de les seves pròpies conseqüències.
• Codi d'enganxament i "jungles de pipelines": els sistemes de ML reals acumulen scripts solts que connecten fonts de dades, transformacions i sortides, fràgils i sense un propietari clar.
• Configuració com a ciutadà de segona: llindars, llistes de features, hiperparàmetres... sovint viuen en cel·les de notebook o al cap d'algú, sense versionar, quan s'haurien de tractar amb el mateix rigor que el codi.
• Experiments zombis: branques de codi amb condicionals d'experiments antics que ningú no gosa esborrar.

La lliçó pràctica: el deute de ML no es veu al notebook. Es manifesta mesos després, quan cal canviar alguna cosa i ningú no pot predir-ne les conseqüències. MLOps és, en gran part, un conjunt de pràctiques per pagar aquest deute de manera sistemàtica en lloc d'acumular-lo.

Adoptar MLOps té un cost inicial (eines, processos, aprenentatge), així que convé tenir clar què s'obté a canvi:

Hi ha un benefici menys tangible però igual de real: la moral de l'equip. Els data scientists que veuen els seus models utilitzats en producció, generant valor mesurable, estan més motivats que els que acumulen notebooks en un calaix.

Durant tot el curs treballarem amb CineClick, una plataforma fictícia de streaming per subscripció (pensa en un servei de sèries i pel·lícules amb plans mensuals). La seva situació de partida és deliberadament típica:

• L'equip de dades ha entrenat un model de predicció de churn: donat un subscriptor, estimar la probabilitat que es doni de baixa properament, fent servir dades fictícies com l'antiguitat, les hores de visualització o els tiquets de suport.
• El model viu en un notebook al portàtil d'una data scientist, amb tots els problemes que hem descrit en aquesta lliçó.
• El negoci el vol fer servir de debò: campanyes de retenció adreçades als clients en risc.

Al llarg dels sis mòduls convertirem aquest notebook en una plataforma MLOps completa: projecte reproduïble, experiments registrats, servei de predicció desplegat, automatització CI/CD i monitoratge en producció. A la lliçó 01-04 presentarem el projecte amb detall, incloent-hi el dataset i el notebook inicial; de moment queda't amb la foto general: CineClick és exactament al punt on moren la majoria dels models, i la nostra feina serà treure'l d'allà.

• Error: pensar que MLOps és comprar una eina. Les eines ajuden, però MLOps és sobretot procés i cultura. Un equip amb Git, disciplina i scripts ben organitzats fa millor MLOps que un amb una plataforma caríssima i notebooks caòtics.
• Error: demonitzar els notebooks. El notebook és l'eina correcta per explorar. L'antipatró és fer-lo servir com a entorn de producció, no fer-lo servir en general.
• Error: deixar el "pas a producció" per al final del projecte. La bretxa notebook→producció es creua millor si es pensa des del primer dia: rutes relatives, llavors fixades, dependències anotades. Petits hàbits estalvien setmanes.
• Error: creure que un sistema de ML estable no necessita manteniment. A diferència del programari clàssic, un model es degrada encara que ningú no toqui el codi, perquè les dades del món canvien. Pressuposta manteniment continu des del principi.
• Consell: quan avaluïs la salut d'un projecte de ML, no preguntis "quines mètriques té el model?", pregunta "podries reentrenar-lo i redesplegar-lo demà si calgués?". La resposta a aquesta pregunta és la mètrica MLOps més honesta.

Classifica cadascun d'aquests problemes segons si és (a) un problema de machine learning, (b) un problema que també existiria en programari clàssic (DevOps) o (c) un problema específic de sistemes de ML que MLOps ha de resoldre:

1. El model té un recall massa baix a la classe minoritària.
2. Ningú no sap quina versió del codi hi ha desplegada al servidor.
3. El model funcionava bé al gener, però al juny les seves prediccions són molt pitjors, sense que ningú no hagi canviat res.
4. El servei de predicció cau quan rep moltes peticions simultànies.
5. No és possible reproduir el model entrenat fa tres mesos perquè el CSV original es va sobreescriure.

A la lliçó hem vist el concepte CACE (Changing Anything Changes Everything) del paper de deute tècnic en ML. Descriu un escenari concret a CineClick on canviar alguna cosa aparentment innòcua a les dades d'entrada degradi el model de churn sense produir cap error visible.

Pensa en un model (real o hipotètic) de la teva pròpia feina que visqui en un notebook. Escriu una llista d'almenys cinc preguntes del tipus "què passaria si...?" que en revelarien la fragilitat operativa (fes servir com a inspiració les preguntes incòmodes de la primera secció).

Solució 1:

1. (a) — És un problema de modelatge: elecció d'algorisme, balanceig de classes, llindar de decisió. MLOps no el resol (tot i que sí que ajuda a detectar-lo i a iterar més ràpid).
2. (b) — És un problema clàssic de DevOps: manca de traçabilitat de desplegaments. Existeix igual en qualsevol aplicació web.
3. (c) — Deriva de dades o de concepte: el món va canviar i el model no. És el problema específic de ML per excel·lència; no en té equivalent el programari determinista. El tractarem al mòdul 6.
4. (b) — Escalabilitat d'un servei: problema clàssic d'operacions, tot i que en ML té matisos propis (ho veurem al mòdul 4).
5. (c) — Manca de versionament de dades: en programari clàssic n'hi ha prou de versionar el codi; en ML, sense les dades exactes no pots reproduir l'artefacte. Ho resoldrem amb DVC al mòdul 2.

Solució 2 (exemple de resposta):

L'equip de producte de CineClick decideix que el camp tiquets_suport deixi de comptar els tiquets resolts automàticament pel chatbot i només compti els atesos per humans. És un canvi raonable de negoci i no trenca cap esquema: la columna continua existint i continua sent un enter. Però la seva distribució canvia (els valors baixen dràsticament), i el model de churn —que havia après que "molts tiquets" assenyalava risc d'abandonament— comença a subestimar el risc dels clients insatisfets. No hi ha error, no hi ha excepció, no hi ha alerta: només prediccions cada cop pitjors. Això il·lustra tant el CACE com la fragilitat de les dependències de dades.

Solució 3 (exemple de resposta, les teves dependran del teu cas):

1. Què passaria si hagués de reentrenar el model avui amb dades noves? Sabria exactament quins passos seguir?
2. Què passaria si el meu portàtil s'espatllés? Sobreviurien el model i la seva història?
3. Què passaria si un company executés el meu notebook de dalt a baix a la seva màquina? Obtindria el mateix model?
4. Què passaria si em preguntessin amb quines dades exactes es va entrenar la versió que està en ús?
5. Què passaria si la font de dades canviés una columna demà? Com me n'assabentaria?
6. Què passaria si el model comencés a predir malament? Qui ho notaria primer: el meu equip o el negoci?

Si diverses respostes són "no ho sé" o "seria un desastre", tens un candidat perfecte per aplicar el que aprendràs en aquest curs.

En aquesta lliçó hem definit MLOps com el conjunt de pràctiques que converteixen experiments de ML en productes de programari fiables, i hem vist per què és necessari: a diferència del programari clàssic, un sistema de ML té tres artefactes canviants (codi, dades i model), es pot degradar sense que ningú no toqui res, i acumula formes de deute tècnic pròpies —de l'entrellaçament CACE als bucles de realimentació ocults— que el paper de Google sobre deute ocult va descriure magistralment. La bretxa notebook→producció no es creua amb heroïcitats puntuals, sinó amb processos repetibles, i això és exactament el que construirem per a CineClick.

Ara que sabem per què existeix MLOps, el pas següent és entendre què cal gestionar: a la propera lliçó recorrerem el cicle de vida complet d'un model de ML en producció, des de la definició del problema de negoci fins al monitoratge i el reentrenament, i veurem com els tres artefactes versionables evolucionen a ritmes diferents al llarg d'aquest cicle.