Hi ha una escena que es repeteix en gairebé totes les empreses que comencen amb aprenentatge automàtic, i AlpinaShop està a punt de viure-la.

La Lucía obre un notebook al seu portàtil. Es descarrega un CSV amb les comandes de l'últim any, prova tres models, i el tercer encerta un 84 % de les vegades quins clients compraran. Ensenya el gràfic a la reunió del dilluns i tothom s'entusiasma. Direcció pregunta quan estarà al web.

I llavors comencen les preguntes incòmodes. D'on va sortir exactament aquell CSV? Quins filtres hi va aplicar? Amb quina versió de la llibreria el va entrenar? On és el model? A la seva carpeta de Baixades? Qui l'executarà quan arribi una petició de la botiga, i en quant de temps ha de respondre? Què passa quan les dades canviïn d'aquí a sis mesos? I si la Lucía se'n va?

Cap d'aquestes preguntes no és sobre el model. Totes són sobre el sistema que envolta el model, i són precisament les que separen un experiment interessant d'un producte que funciona. Aquesta lliçó tracta d'això: què és Vertex AI, quin component resol cada pregunta, i com es connecta amb la plataforma de dades que has construït al mòdul 4.

I tracta també d'una cosa que gairebé mai no es diu en un curs d'aprenentatge automàtic: que la primera decisió honesta d'un projecte de ML és decidir si cal ML.

1. Per què no n'hi ha prou amb un notebook i un portàtil
2. El cicle de vida d'un model
3. Quin component de Vertex AI cobreix cada etapa
4. Nota històrica: d'AI Platform a Vertex AI
5. Workbench: notebooks gestionats connectats a les dades
6. Conjunts de dades gestionats i pedidos-historico
7. Feature Store i el biaix entrenament/servei
8. Entrenament: treballs personalitzats i hiperparàmetres
9. Model Registry, versions i avaluació
10. Servir el model: endpoints en línia i predicció per lots
11. Model Monitoring: quan el món canvia i el model no
12. BigQuery ML: entrenar amb SQL sense sortir del magatzem
13. Quan BigQuery ML i quan Vertex AI
14. Cost de la plataforma i els dos interruptors que cal apagar
15. El problema d'AlpinaShop: recomanar sense entrenar res

El notebook de la Lucía no està malament. És el lloc correcte per explorar, i tot projecte de ML comença allà. El problema apareix quan el resultat ha de sobreviure fora d'aquella sessió.

Les cinc fallades que es repeteixen sempre:

Una plataforma de ML és el conjunt de serveis que resol aquests cinc problemes sense que els hagis de construir. Vertex AI és la de Google Cloud: un paraigua amb emmagatzematge de característiques, entrenament gestionat, registre de models, servei de prediccions, monitoratge i orquestració, tot sota el mateix IAM, la mateixa facturació i la mateixa xarxa que la resta del teu projecte.

La idea que convé fixar abans de continuar: el model és la part petita del sistema. És un percentatge mínim del codi i de l'esforç real. Tota la resta —recollida de dades, verificació, extracció de característiques, servei, monitoratge, gestió de configuració— és el sistema, i és on fallen els projectes.

Un model no es fa: es cultiva. I no és una línia recta, és un bucle.

Les set etapes, amb la pregunta que respon cadascuna:

1. Problema de negoci. Quina decisió canviarà pel fet de tenir aquest model? Si la resposta és "cap, però és interessant", el projecte ja ha fracassat.
2. Dades. Quina informació existeix, quanta, de quina qualitat i amb quin permís legal per utilitzar-la? Aquí és on el mòdul 4 rendeix: alpinashop_analitica està governat, catalogat i desidentificat.
3. Característiques. Transformar dades brutes en els senyals numèrics que el model consumeix. És l'etapa que més determina el resultat final, molt per damunt de l'elecció de l'algorisme.
4. Entrenament. Ajustar els paràmetres del model amb les dades històriques.
5. Avaluació. És millor que el que hi havia? Millor que una heurística simple? Millor per al negoci, no només en una mètrica?
6. Desplegament. Fer que el model respongui a peticions reals, en línia o per lots.
7. Monitoratge. Vigilar que les dades que entren continuen assemblant-se a les d'entrenament, i que les prediccions continuen sent útils.

El bucle és el que importa. Un model desplegat i oblidat és un passiu: continua decidint amb una visió del món que ja ha caducat.

No cal utilitzar-los tots. AlpinaShop, amb 40 persones, n'utilitzarà cinc o sis. Però convé saber que hi són, perquè l'alternativa a cadascun és construir-lo tu.

Si busques documentació o tutorials antics, et trobaràs amb noms que ja no existeixen, i convé saber traduir-los.

Fins al 2021, Google Cloud tenia dues ofertes de ML separades i mal comunicades entre si:

• AI Platform (abans Cloud ML Engine): entrenament i predicció per a qui escrivia el seu propi codi.
• AutoML (Vision, Natural Language, Tables…): productes independents, cadascun amb la seva consola i la seva API, per a qui no escrivia codi.

Eren mons diferents. Un model d'AutoML i un d'AI Platform no compartien registre, ni monitoratge, ni manera de desplegar-se. Vertex AI els va unificar sota una sola API, un sol registre de models i una sola consola. Avui AutoML no és un producte a part: és una manera d'entrenar dins de Vertex AI.

AI Platform està retirada. Si trobes un tutorial que faci servir gcloud ai-platform jobs submit o l'endpoint ml.googleapis.com, és material obsolet. L'equivalent actual és gcloud ai custom-jobs create sobre aiplatform.googleapis.com. La confusió és habitual perquè el nom de l'API va conservar les sigles antigues.

És un bon recordatori d'una regla general d'aquest curs: al núvol, verifica sempre contra la documentació oficial vigent. Els noms, els límits i els preus canvien, i un tutorial de fa tres anys pot portar-te a un producte que ja no existeix.

Vertex AI Workbench és un JupyterLab gestionat que corre sobre una VM al teu projecte. Davant del portàtil de la Lucía té tres avantatges que importen:

• És on són les dades. A europe-west1, dins de la VPC, sense treure'n res a fora.
• Fa servir un compte de servei, no les credencials personals. Els permisos són auditables i revocables.
• Escala. Si cal més memòria o una GPU per a un experiment, es canvia el tipus de màquina i ja està.

Creació de la instància de la Lucía:

Tres opcions mereixen explicació:

• --service-account: la instància actua com aquell compte de servei, que tindrà roles/bigquery.dataViewer sobre les vistes desidentificades i no sobre les taules crues. El que vas aprendre a 03-04 s'aplica aquí sense canvis.
• --disable-public-ip: sense IP pública. L'accés va per IAP i la sortida a internet per Cloud NAT, com a 03-01.
• idle-timeout-seconds=3600: s'apaga sola després d'una hora sense ús. Aquest paràmetre és la diferència entre 40 € i 400 € de factura a final de mes.

Dins del notebook, la connexió a les dades governades del mòdul 4 és directa:

Què fa i per què així. bigquery.Client s'autentica sola amb el compte de servei de la instància: no hi ha claus ni fitxers JSON, que és exactament el que volies evitar després de 03-06. La consulta agrega a BigQuery i baixa el resultat ja reduït: unes 2.400 files en lloc de milions. Aquest és el patró correcte i l'error més car és el contrari —SELECT * sobre lineas_pedido i agregar en pandas—, que descarrega gigabytes, factura bytes llegits i probablement esgota la memòria del notebook.

Quan el volum ja no cap a memòria, existeix bigframes, una API tipus pandas que executa les operacions dins de BigQuery en lloc de portar-se les dades. És la sortida natural quan el to_dataframe() comença a fer mal.

Un conjunt de dades gestionat (managed dataset) és un recurs de Vertex AI que apunta a les teves dades i els afegeix el que un CSV solt no té: identitat, versió, esquema, divisions train/validació/test i, en imatge i text, un flux d'etiquetatge.

AlpinaShop crea el seu directament des del dataset governat:

Fixa't en un detall gens casual: l'origen és v_pedidos_analitica, la vista pseudonimitzada que vas crear a 04-07, no la taula pedidos. El model no veu mai un correu. No perquè calgui per entrenar —no aporta res—, sinó perquè cada còpia d'una dada personal és una obligació legal més i un risc més.

És obligatori fer servir un conjunt gestionat? No. L'entrenament personalitzat pot llegir directament de BigQuery o de Cloud Storage. Els conjunts gestionats són obligatoris per a AutoML i molt recomanables quan cal etiquetar a mà o quan vols que quedi registrat amb quines dades exactes es va entrenar cada versió. Per a un treball personalitzat que ja llegeix d'una vista versionada, aporten menys.

Aquest apartat explica l'error més car i més silenciós de l'aprenentatge automàtic aplicat. Val la pena llegir-lo a poc a poc.

Una característica (feature) és un senyal numèric o categòric que descriu una entitat i que el model fa servir per decidir. Per a AlpinaShop:

El problema apareix així. La Lucía entrena al notebook i calcula "comandes del client en els últims 90 dies" amb una consulta SQL sobre pedidos. Funciona: el model encerta. Mesos després, en Dani ha de servir el model al web, i necessita aquest mateix número en temps real, en mil·lisegons, per al client que està mirant la pantalla. No pot llançar una consulta a BigQuery dins la petició HTTP. Així que ho reimplementa en Python contra Cloud SQL.

I aquí, sense que ningú no ho noti, apareix la diferència. La consulta de la Lucía comptava les comandes amb estat entregado. La d'en Dani les compta totes, incloses les cancel·lades. El model rep en producció un número que significa una cosa diferent de la que va aprendre. Ningú no veu un error: no hi ha excepció, no hi ha registre vermell. Simplement el model encerta menys del que prometia, i l'equip triga mesos a entendre per què.

Això és el biaix entrenament/servei (training-serving skew): la característica es calcula de dues maneres diferents en dos llocs diferents.

Feature Store ho resol amb una idea simple: la característica es defineix i es calcula una sola vegada, es desa, i se serveix tant a l'entrenament (per lots, amb valors històrics correctes) com al servei en línia (amb latència baixa). Un sol codi, una sola definició.

A Vertex AI, la generació actual de Feature Store es recolza en BigQuery com a font de la veritat: defineixes una vista de característiques sobre una taula o vista, i un magatzem en línia la sincronitza per servir-la de pressa.

La clau és a --entity-id-columns=cliente_hash i a --cron. L'entitat s'identifica pel hash del client, el mateix que vas generar amb KMS a 04-07: el magatzem de característiques tampoc no conté dades personals directes. I la sincronització nocturna significa que les característiques tenen com a màxim 24 hores d'antiguitat, cosa perfectament acceptable per a "comandes en 90 dies" i no acceptable per a "productes vistos en aquesta sessió", que cal calcular en calent.

Un advertiment important sobre el temps: en construir el conjunt d'entrenament, cada fila ha de portar el valor que la característica tenia en el moment de l'esdeveniment, no el d'avui. Si entrenes un model de "comprarà?" amb el nombre de comandes actual del client, li estàs explicant el futur. Tornarem sobre aquest parany —la fuita de dades— a 05-02.

Necessita AlpinaShop un Feature Store avui? Amb un model i tres característiques, probablement no: és una capa més per mantenir. Amb cinc models que comparteixen característiques i un equip de tres persones, sí. La regla pràctica: quan la mateixa característica la fan servir dos models o la calculen dues persones, ha arribat el moment.

Un treball d'entrenament personalitzat és el teu codi executant-se en màquines de Google, sense que tu en gestionis cap. Dues maneres d'empaquetar-lo:

AlpinaShop ja té Artifact Registry de 02-05 i del pipeline del catàleg, així que la segona opció no li costa res extra.

Punt per punt:

• --worker-pool-spec defineix la màquina. Un sol replica-count és entrenament en una màquina; amb més rèpliques i la configuració adequada, distribuït (ho veuràs a 05-03).
• La imatge està etiquetada amb versió (1.0.3), mai latest. Si necessites reproduir l'entrenament del mes passat, latest ja no és el que era.
• Els artefactes s'escriuen a Cloud Storage, no dins del contenidor, que desapareix en acabar.

El treball escriu registres a Cloud Logging (06-06) i mor sol. No hi ha cap VM per apagar, que és el principal avantatge davant de muntar-te tu una instància amb GPU i oblidar-la encesa el cap de setmana.

Un paràmetre l'aprèn el model durant l'entrenament (els pesos). Un hiperparàmetre el decideixes tu abans: taxa d'aprenentatge, profunditat de l'arbre, mida del lot, dimensió de les incrustacions. I el seu efecte sobre el resultat és enorme.

Provar combinacions a mà és tediós i esbiaixat. Vertex AI Hyperparameter Tuning llança diverses execucions en paral·lel i busca la millor combinació amb optimització bayesiana: aprèn de les proves anteriors en lloc de tirar dards.

Dos detalls que estalvien diners i disgustos:

• scaleType: UNIT_LOG_SCALE per a la taxa d'aprenentatge. Els valors útils es reparteixen per ordres de magnitud, no linealment: buscar en escala logarítmica explora 0,0001, 0,001 i 0,01 en comptes de vint valors gairebé idèntics.
• parallelTrialCount: 4 davant de maxTrialCount: 20. Amb paral·lelisme alt acabes abans, però cada tanda aprèn menys de l'anterior. Amb paral·lelisme baix la cerca és més intel·ligent i més lenta. Una quarta part del total és un equilibri raonable.

I l'advertiment de cost: 20 proves costen 20 entrenaments. Abans de llançar un ajust, comprova que un entrenament solt funciona i mesura quant triga i quant val.

El Model Registry és el catàleg de models del projecte. Cada model té versions numerades, i cada versió desa el seu artefacte, el seu contenidor de servei, les seves mètriques i el seu llinatge.

Els àlies són la peça més útil i la menys utilitzada. En lloc que el codi de la botiga invoqui "la versió 7", invoca l'àlies produccion. Canviar de model és moure un àlies, i tornar enrere també:

L'avaluació es desa associada a la versió. Això és el que permet respondre, mesos després, a "per què es va substituir el model el 3 de juny?" amb dades i no amb records. I és la base de la porta de decisió que construiràs a 05-07: un model només es desplega si la seva avaluació supera la del model que hi ha en producció.

Hi ha dues maneres d'utilitzar un model, i triar malament és l'error d'arquitectura més car d'aquest mòdul.

Un endpoint és un servei HTTPS sempre encès amb una o més versions desplegades. Respon en mil·lisegons, escala sol, i cobra pel temps que les màquines són vives, hi hagi trànsit o no.

Una predicció per lots és un treball que arrenca, llegeix un fitxer o una taula, prediu milions de files, escriu el resultat i mor. Cobra pel treball, no pel temps d'espera.

El criteri d'elecció, en una frase: si el resultat depèn d'una cosa que acaba de passar i que no podies saber abans, necessites endpoint; si no, lots.

I aquí ve una decisió concreta d'AlpinaShop que convé fixar ara. Les recomanacions de producte no canvien cada segon: quins productes es compren junts és un patró estable de setmanes. Precalcular cada nit les 20 recomanacions de cadascun dels 2.400 SKU és una taula de 48.000 files que la botiga consulta en microsegons des de Firestore o Memorystore (02-06).

Cost orientatiu de la comparació, per donar-ne la magnitud —verifica sempre els preus vigents a la documentació oficial, que canvien—: un endpoint modest encès tot el mes ronda les desenes d'euros com a mínim, fins i tot sense trànsit; el treball per lots nocturn sobre 2.400 SKU són cèntims. Amb dos ordres de magnitud de diferència i sense cap avantatge funcional, la decisió no requereix debat.

Decisió DA-002. Les recomanacions de producte d'AlpinaShop es calculen per lots cada nit i se serveixen des d'una taula precalculada. Es reservarà un endpoint en línia només si apareix un cas que depengui del comportament de la sessió en curs.

Un model aprèn una foto del món. El món es mou, la foto no.

Dos fenòmens diferents que convé no confondre:

Model Monitoring compara contínuament les distribucions de les peticions reals contra una línia base (les dades d'entrenament) i avisa quan la distància supera un llindar.

• --feature-thresholds: llindar per característica. Un 0,3 a categoria significa "avisa'm si la barreja de categories que arriba s'allunya més que això de la barreja amb què vaig entrenar".
• --prediction-sampling-rate=0.2: s'analitza el 20 % de les peticions. Analitzar el 100 % ho detecta abans, costa més i gairebé mai no compensa.

Un avís realista: una alerta de deriva no és una avaria. A l'hivern la distribució de categories ha de canviar, i això és normal. L'alerta et diu "mira això", i el judici de si cal reentrenar és humà. Un llindar massa sensible produeix soroll, el soroll produeix indiferència, i la indiferència fa que ningú no miri l'alerta que sí que importava.

I ara, l'alternativa que molts equips haurien de provar abans que cap altra.

BigQuery ML permet crear i utilitzar models amb SQL, dins de BigQuery, sense moure ni un sol byte i sense escriure Python. Per a un equip que ja viu en SQL —com la Lucía després del mòdul 4— és la via més curta des de la dada fins a la predicció.

El cas d'AlpinaShop: predir la probabilitat que una sessió amb cistella acabi en compra, per decidir si val la pena mostrar un incentiu.

Primer, la taula d'entrenament. És on es juga el resultat:

El que importa d'aquesta consulta no és el SQL, són les decisions. El filtre unidades_carrito > 0 acota la població a les sessions que van arribar a tenir cistella: predir sobre visitants que només van mirar la portada barrejaria dos problemes diferents. I totes les columnes descriuen la sessió abans del desenllaç: no n'hi ha cap que només es conegui després de comprar. Si hi incloguessis metodo_pago, el model arribaria a un 99 % d'encert i seria completament inútil, perquè el mètode de pagament només existeix si hi va haver compra. Això és fuita de dades, i es mira amb lupa a 05-02.

Ara el model, en una sola sentència:

Les opcions, una a una:

• LOGISTIC_REG: regressió logística, un classificador simple, ràpid, barat i explicable. Començar pel model més simple que pugui funcionar no és conservadorisme: és l'única manera de saber si un model complex aporta res.
• auto_class_weights = TRUE: si només el 12 % de les sessions acaben en compra, un model mandrós pot dir "ningú no compra" i encertar el 88 %. Aquesta opció compensa el desequilibri.
• data_split_method = 'CUSTOM' amb es_test partint de la data: la divisió és temporal, no aleatòria. S'entrena amb el passat i s'avalua amb el futur, que és com funcionarà en producció. Una divisió aleatòria barrejaria sessions de març a l'entrenament i de febrer a l'avaluació, i el resultat seria optimista i fals.
• enable_global_explain = TRUE: habilita la importància de les característiques.

Avaluar i predir:

ML.EVALUATE retorna precisió, exhaustivitat, f1_score, log_loss i roc_auc. A 05-02 veuràs què significa cadascuna i per què l'exactitud a seques és la mètrica que més enganya.

BigQuery ML admet bastant més que regressió logística: arbres potenciats, DNN, k-means per a segmentació, ARIMA_PLUS per a sèries temporals, matrix factorization per a recomanació, importació de models de TensorFlow, i crides a models Gemini des de SQL amb ML.GENERATE_TEXT. Un model entrenat a BigQuery ML es pot exportar i registrar a Vertex AI per servir-lo en un endpoint, així que l'elecció no és una porta tancada.

La regla pràctica per a AlpinaShop: si la dada és a BigQuery, el problema és tabular i vols una resposta aquesta setmana, comença per BigQuery ML. Si no hi arriba —perquè necessites imatges, text lliure, una arquitectura pròpia o latència en línia—, puja a Vertex AI. El contrari, començar pel complex, costa setmanes i moltes vegades acaba en un model pitjor.

I una observació honesta: en una pime, la majoria dels problemes de ML útils són tabulars i caben a BigQuery ML. La sofisticació es reserva per a on de debò aporti.

Vertex AI factura per parts, i la majoria de les sorpreses vénen de dues d'elles.

Els dos interruptors, dits sense embuts:

1. Apaga els notebooks. Configura idle-timeout-seconds en crear la instància. Un e2-standard-4 oblidat un mes costa més que tots els entrenaments del projecte.

2. Desfés el desplegament dels endpoints que no fas servir. És l'error car del mòdul. Un endpoint desplegat per a una demostració del dimarts continua facturant a l'agost, sense trànsit i sense que ningú no el miri.

Afegeix a aquests recursos les etiquetes de facturació que vas definir a 01-04 (centro-coste:analitica) i una alerta de pressupost sobre elles. L'optimització de costos a fons arriba a 07-05; aquí n'hi ha prou amb la higiene mínima.

Tanquem amb la decisió que dóna sentit a tot el mòdul, i no és la que s'espera d'una lliçó d'aprenentatge automàtic.

El problema de negoci és concret: quan un client afegeix uns grampons a la cistella, què li suggereix el web? Avui no suggereix res. La pàgina de cistella és buida de contingut i la venda creuada és zero.

Un enginyer de ML entusiasta proposaria entrenar un model de recomanació amb incrustacions de client i de producte. És el que veuràs a 05-03, i és una bona solució. Però abans d'això cal fer-se una pregunta: què s'aconsegueix sense entrenar res?

I resulta que ja existeix la resposta, calculada a 04-03: la taula productos_juntos, la matriu de coocurrència que Spark va computar sobre cinc anys de línies de comanda, amb suport, confiança i lift per a cada parell de productes.

Llegeix-ho a poc a poc, perquè cada filtre és una decisió de negoci:

• soporte >= 0.001 elimina les casualitats. Dos productes que van coincidir en tres comandes de cinc anys no són un patró, són soroll.
• confianza >= 0.05 exigeix que l'associació sigui raonablement freqüent en una direcció concreta.
• lift > 1.2 és el filtre que evita l'error clàssic: sense ell, el recomanador suggeriria a tothom el producte més venut de la botiga. Un lift d'1 significa "es compren junts per pura popularitat". Només per damunt hi ha senyal real.
• activo = TRUE AND stock > 0 és la regla més avorrida i la que més diners salva: no recomanis mai el que no pots vendre. Cap model, per sofisticat que sigui, no corregeix per si sol un catàleg amb productes descatalogats.

Això són unes desenes de línies de SQL, s'executa en segons, costa cèntims, no necessita entrenament, no necessita endpoint, és completament explicable ("et suggerim això perquè el 23 % de qui compra grampons compra també aquest piolet") i es pot posar en producció aquesta setmana.

És tan bo com un model entrenat? No. Té tres límits coneguts: no personalitza —a tothom li suggereix el mateix per al mateix producte—, no sap res dels productes nous que encara no tenen historial (arrencada en fred), i no aprofita informació del client ni de la sessió.

Importa? Depèn de contra què es compari. I avui es compara amb no recomanar res. Passar de zero a una heurística decent captura la major part del valor. Passar d'aquesta heurística a un model entrenat captura un increment addicional, que pot valer la pena o no.

Decisió DA-003. AlpinaShop desplega primer el recomanador heurístic basat en productos_juntos com a línia base en producció. Qualsevol model de ML posterior haurà de demostrar que supera aquesta línia base en una prova A/B amb mètriques de negoci, no només en una mètrica offline. Si no la supera, no es desplega.

Aquesta decisió és la més important del mòdul, i val la pena dir-la clarament: la millor decisió d'aprenentatge automàtic de vegades és no fer aprenentatge automàtic. Un equip madur es distingeix per tenir una línia base contra la qual mesurar-se, i per estar disposat a acceptar que de vegades la línia base guanya.

Començar pel model i no per la decisió. Si ningú no sap què canviarà al web quan el model predigui, el projecte ja ha fracassat. Escriu primer la frase: "quan el model digui X, la botiga farà Y".

No tenir línia base. Un AUC de 0,84 no significa res per si sol. Quant donava una regla simple? Si la regla donava 0,81, el model aporta molt poc per al que costa mantenir-lo.

Deixar endpoints i notebooks encesos. L'error més car d'aquesta lliçó. Posa-ho al calendari: una revisió mensual de gcloud ai endpoints list i d'instàncies de Workbench.

Confondre divisió temporal amb divisió aleatòria. En qualsevol problema amb dimensió temporal —i gairebé tots els d'una botiga la tenen—, entrenar amb dades posteriors a les d'avaluació produeix mètriques fantàstiques que no es reprodueixen en producció.

Calcular les característiques dues vegades. El biaix entrenament/servei de l'apartat 7. Si el mateix número el calculen dues persones en dos llenguatges, tard o d'hora deixaran de coincidir.

Utilitzar latest a les imatges de contenidor. Trenca la reproductibilitat. Etiqueta amb versió sempre.

Ficar dades personals al model per inèrcia. Un model no necessita el correu per predir. Entrena sobre les vistes pseudonimitzades de 04-07 i tindràs menys risc i menys obligacions, sense perdre gens de qualitat.

Consell: escriu una fitxa de model des del primer dia. Quatre línies —per a què serveix, amb quines dades es va entrenar, quina mètrica té, quines limitacions conegudes— escrites quan encara te'n recordes. A 05-07 veuràs que és un requisit, no un adorn.

Consell: fixa la llavor aleatòria. Un model que dóna un resultat diferent cada vegada que s'entrena és impossible de depurar.

La Marta ha rebut la factura de Vertex AI del mes: 612 €, quan el mes anterior van ser 40 €. L'equip no ha entrenat res de nou. Enumera les causes més probables per ordre de probabilitat, indica quina comanda o vista faries servir per confirmar-les, i proposa tres mesures preventives.

La Lucía vol predir, per a cada SKU, quantes unitats es vendran la setmana vinent, per tal d'ajustar la comanda a proveïdors. Té ventas_diarias_sku a BigQuery amb cinc anys d'història. Decideix entre BigQuery ML i Vertex AI justificant l'elecció, escriu l'esquelet de la solució i respon: endpoint en línia o predicció per lots, i per què?

En Dani proposa entrenar un model que decideixi automàticament si una comanda és fraudulenta i, en cas afirmatiu, cancel·lar-la sense intervenció humana. Analitza la proposta des de tres angles: tècnic, de negoci i legal. Proposa un disseny alternatiu.

Solució 1

Causes, per probabilitat:

1. Un endpoint desplegat i oblidat. És la causa número u. Un endpoint amb dos nodes encès tot el mes explica per si sol la major part del salt, sense ni una sola petició.
2. Una instància de Workbench sense apagar, especialment si algú va provar amb GPU i no la va retirar.
3. Un ajust d'hiperparàmetres llançat sense mirar: 40 proves són 40 entrenaments.
4. Feature Store en línia aprovisionat en una prova i mai eliminat.
5. Prediccions per lots en bucle per un Scheduler mal configurat que dispara cada hora en comptes de cada nit.

Com confirmar-ho:

I a l'informe de facturació exportat a BigQuery (01-04), el desglossament que dóna la resposta directa:

Mesures preventives:

1. Alerta de pressupost sobre l'etiqueta centro-coste:analitica al 50 %, 80 % i 100 % de l'import esperat (01-04). No evita la despesa, però la detecta en dies en comptes d'en un mes.
2. idle-timeout-seconds obligatori a tota instància de Workbench, aplicat per política d'organització o per revisió en crear-la.
3. Revisió mensual programada d'endpoints i notebooks, amb la regla explícita: tot endpoint sense trànsit en 14 dies es retira. Es pot automatitzar consultant les mètriques de l'endpoint a Cloud Monitoring (06-04).

Solució 2

Elecció: BigQuery ML, i amb força claredat.

Justificació: la dada ja és a BigQuery a la taula ventas_diarias_sku; el problema és una sèrie temporal univariant per SKU, un cas que BigQuery ML cobreix nativament amb ARIMA_PLUS; la sortida és una comanda setmanal a proveïdors, així que no hi ha cap necessitat de latència baixa; i qui ho mantindrà és la Lucía, que treballa en SQL. Pujar això a Vertex AI afegiria setmanes de feina i cost sense cap avantatge.

Detalls que marquen la diferència:

• time_series_id_col = 'sku' entrena un model per SKU en una sola sentència. Amb 2.400 SKU això estalvia un projecte sencer.
• holiday_region = 'ES' incorpora els festius espanyols, que en una botiga de muntanya importen molt: Setmana Santa i els ponts són pics reals.
• L'interval de confiança és més útil que la predicció puntual. Per decidir una comanda a proveïdor interessa el rang, no el número màgic. Amb productes de rotació baixa, l'interval serà ample, i això és informació honesta: el model t'està dient que no ho sap.

Endpoint o lots: lots, sense discussió. La previsió es necessita un cop per setmana per fer una comanda. Un endpoint 24×7 per respondre a una consulta setmanal és la definició literal de despesa inútil. Es programa amb Cloud Scheduler i Workflows (04-06) els diumenges a la nit i escriu en una taula que la Lucía consulta el dilluns.

Cautela: els SKU amb poc historial o molt estacionals donaran previsions dolentes. Convé filtrar els que tinguin menys d'un any de dades i tractar-los amb una regla manual, i validar el model comparant la seva previsió contra les últimes quatre setmanes reals abans de refiar-se'n.

Solució 3

Angle tècnic. El frau és un problema de classes extremadament desequilibrades: potser 3 comandes fraudulentes de cada 10.000. Un model que digui "mai no hi ha frau" encerta el 99,97 %, i és inútil. A més, les dades disponibles gairebé amb seguretat no estan etiquetades: ningú no ha marcat històricament quines comandes van ser frau, i sense etiquetes no hi ha aprenentatge supervisat. I el frau és adversari: els defraudadors canvien de tàctica així que detecten la defensa, de manera que el model es degrada per disseny, no per accident.

Angle de negoci. Cal valorar els dos errors per separat, i no costen el mateix. Un fals negatiu costa l'import de la comanda. Un fals positiu cancel·la la compra d'un client legítim: perds el marge, perds probablement el client, i et guanyes una ressenya d'una estrella. Amb un 0,03 % de frau real, fins i tot un model bo generarà molts més falsos positius que fraus detectats. El cost esperat de l'automatització total és gairebé segur negatiu.

Angle legal. Aquest és el determinant. L'article 22 del RGPD regula les decisions basades únicament en tractament automatitzat que produeixin efectes jurídics o afectin significativament una persona. Cancel·lar la comanda d'un client automàticament i acusar-lo implícitament de frau hi encaixa de ple. Genera obligacions d'informació, dret a obtenir intervenció humana, a expressar el punt de vista i a impugnar la decisió. A això s'hi suma el Reglament Europeu d'IA (AI Act), amb requisits de gestió de riscos, documentació, transparència i supervisió humana segons la classificació del sistema. Aquesta anàlisi no substitueix un dictamen jurídic: la classificació concreta i les obligacions aplicables les ha de determinar un professional de compliment normatiu o el DPD abans de qualsevol implantació.

Disseny alternatiu: el model puntua, la persona decideix.

Quatre propietats que ho fan viable:

1. Cap cancel·lació no és automàtica. Sempre hi ha una persona en el bucle, cosa que resol el problema de l'article 22 i el requisit de supervisió humana.
2. Els llindars són decisions de negoci, ajustables segons quanta capacitat de revisió hi hagi. Si hi ha una persona a mitja jornada, es calibra perquè la cua càpiga en la seva jornada.
3. Cada decisió humana genera una etiqueta, que és justament la dada que avui no existeix. En sis mesos hi haurà un conjunt etiquetat real amb el qual entrenar de debò.
4. Cada decisió queda registrada amb la versió del model, la puntuació i el motiu. Això és el que s'ensenya en una auditoria o davant d'una reclamació.

I la primera versió de la puntuació no cal que sigui un model: mitja dotzena de regles —adreça d'enviament diferent de la de facturació, compte creat fa menys d'una hora, import molt per damunt de la mitjana, tres intents de pagament fallits— capturen bona part del frau evident, són explicables al client i s'implementen en un dia. La mateixa lògica de l'apartat 15.

Has vist per què un model en un portàtil no és un producte, i què cal al seu voltant perquè ho sigui: reproductibilitat, escala, servei, traçabilitat i vigilància. Aquests cinc buits són exactament els que omple una plataforma de ML.

Coneixes el cicle de vida complet —problema, dades, característiques, entrenament, avaluació, desplegament, monitoratge, reentrenament— i saps que és un bucle, no una línia: un model desplegat i oblidat és un passiu. I saps quin component de Vertex AI cobreix cada etapa, des de Workbench fins a Pipelines, amb la nota històrica que AI Platform i AutoML eren productes separats i avui tot viu sota el mateix paraigua.

Has muntat el Workbench de la Lucía amb compte de servei, sense IP pública i amb apagada automàtica, llegint de les vistes governades del mòdul 4 i agregant a BigQuery en lloc de descarregar gigabytes. Has creat el conjunt gestionat pedidos-historico apuntant deliberadament a v_pedidos_analitica i no a la taula amb correus. Has entès el biaix entrenament/servei —l'error silenciós de calcular la mateixa característica de dues maneres— i com el resol Feature Store, a més de quan encara no compensa muntar-lo.

Saps llançar treballs d'entrenament personalitzats amb contenidor versionat, ajustar hiperparàmetres amb cerca bayesiana sense arruïnar-te, versionar al Model Registry amb àlies que permeten promoure i revertir en segons, i triar entre endpoint en línia i predicció per lots amb un criteri clar: si el resultat no depèn d'una cosa que acaba de passar, va per lots. D'aquí va sortir la decisió DA-002. I saps vigilar la deriva sense convertir les alertes en soroll.

Has entrenat el teu primer model amb BigQuery ML en una sentència SQL, amb divisió temporal, pesos de classe automàtics i explicabilitat activada, i tens el criteri de quan n'hi ha prou amb SQL i quan cal pujar a Vertex AI. I tens els dos interruptors de cost ben identificats: apaga els notebooks, retira els endpoints.

Però el que més valdrà d'aquesta lliçó és la decisió DA-003. AlpinaShop posarà en producció un recomanador que no és un model: unes desenes de línies de SQL sobre la matriu productos_juntos que va calcular Spark, amb filtres de suport, confiança i lift, i amb la regla més important de totes —no recomanar el que no hi ha en estoc—. És explicable, costa cèntims, està a punt aquesta setmana, i qualsevol model que vingui després haurà de demostrar que el supera en negoci, no en una mètrica de laboratori.

A 05-02, AutoML, fem el següent pas natural: entrenar models de debò sense escriure codi. Veuràs què fa AutoML per sota —cerca d'arquitectura, enginyeria de característiques i assemblatge—, quins tipus de problema cobreix i amb quantes dades mínimes, i l'aplicaràs a dos casos d'AlpinaShop: predir la probabilitat de compra d'una cistella partint de visitas i v_pedidos_analitica, i classificar les fotos del catàleg amb AutoML Vision. Pel camí aprendràs a llegir de debò una matriu de confusió, a entendre per què el llindar de decisió és una decisió de negoci i no tècnica, i a detectar els tres paranys que arruïnen més projectes que cap altra cosa: la fuita de dades, el desequilibri de classes i el sobreajust.

I t'enduràs la línia base. Perquè a partir d'ara, cada model que entrenis té un rival a qui batre.