El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

El recomanador heurístic de la lliçó anterior ja és en producció, i funciona. Però AlpinaShop té dues preguntes que el SQL no pot respondre.

La primera és de la Marta, que porta el web: de cada cent cistelles que s'omplen, quines acabaran en compra? Si se sabés per endavant, es podria reservar el descompte de benvinguda per a qui està a punt d'abandonar en lloc de regalar-lo a qui comprava igualment. Això no és un patró que es llegeixi en una taula de coocurrències: depèn d'una dotzena de senyals que interactuen entre si.

La segona és del catàleg: 60 GB d'imatges de producte sense etiquetar. Ningú no sap, mirant el bucket alpinashop-catalogo, quines són motxilles, quines piolets i quines jaquetes, més enllà del que digui la fitxa del producte —que no sempre coincideix amb la foto que va pujar el proveïdor.

Les dues preguntes necessiten un model entrenat. I cap de les tres persones de l'equip no és enginyera d'aprenentatge automàtic.

AutoML existeix exactament per a això: entrenar models de qualitat raonable sobre les teves pròpies dades, sense escriure codi de modelatge, deixant que la plataforma prengui les decisions tècniques. Aquesta lliçó va de què fa per sota, fins on arriba, on es queda curt, i —el que més es descuida— com llegir els resultats sense enganyar-se.

Contingut

Què és AutoML i què fa realment per sota
Per a qui és i quins són els seus límits
Tipus de problema i requisits mínims de dades
Cas 1: predir la compra d'una cistella
La divisió temporal: per què l'aleatòria seria trampa
Pressupost d'entrenament i cost
Llegir els resultats sense enganyar-se
El llindar de decisió és una decisió de negoci
Importància de les característiques i explicabilitat
Cas 2: classificar les fotos del catàleg
Etiquetar bé: el cost que ningú no pressuposta
Desplegar: endpoint o predicció per lots
Els tres paranys: fuita, desequilibri i sobreajust
Quan AutoML no és la resposta
Biaix, decisions automatitzades i marc legal

Què és AutoML i què fa realment per sota

AutoML no és màgia ni un algorisme concret. És l'automatització de les tasques que un enginyer de ML faria a mà, executades de forma sistemàtica i amb més paciència de la que té una persona.

Quatre coses fa per tu:

Enginyeria de característiques. Detecta el tipus de cada columna, normalitza les numèriques, codifica les categòriques, extreu components de les dates (dia de la setmana, mes, si és festiu), imputa els valors absents i descarta les columnes inútils —les que tenen un sol valor o les que són un identificador únic per fila.

Cerca d'arquitectura i d'algorisme. Prova famílies diferents de models —arbres potenciats, xarxes neuronals, models lineals— i, dins de cadascuna, configuracions diferents. En imatge i text, a més, busca l'arquitectura de xarxa mitjançant neural architecture search.

Ajust d'hiperparàmetres. Optimitza taxes d'aprenentatge, profunditats, regularització i la resta, amb el mateix tipus de cerca bayesiana que vas veure a 05-01, però sense que l'hagis de declarar.

Assemblatge. El model final poques vegades és un de sol: sol ser una combinació ponderada de diversos, perquè combinar models diversos gairebé sempre supera el millor individual.

flowchart TD
    A[Les teves dades etiquetades] --> B[Analisi i neteja automatica]
    B --> C[Enginyeria de caracteristiques]
    C --> D[Cerca d arquitectures i algorismes]
    D --> E[Ajust d hiperparametres]
    E --> F[Avaluacio en el conjunt de test]
    F -->|queda pressupost| D
    F -->|pressupost exhaurit| G[Assemblatge del millor model]
    G --> H[Model al Model Registry]

El que no fa, i convé tenir-ho clar des del principi:

No decideix quin problema resoldre ni què significa l'èxit.
No aconsegueix dades ni arregla les que estan malament.
No detecta que hi has ficat una columna que filtra el futur.
No sap què és just, ni quines conseqüències té equivocar-se.

Tot això continua sent teu. I és, casualment, on hi ha la major part del valor i del risc.

Per a qui és i quins són els seus límits

AutoML té un públic molt definit: qui coneix el domini i les dades però no l'enginyeria de models. La Lucía n'és el cas exacte. Sap què és una sessió, què és una cistella abandonada i què significa cada columna de visitas. No sap triar entre XGBoost i una xarxa neuronal, i no li cal.

Avantatges	Límits reals
Resultat decent en hores, no en setmanes	Sol quedar per sota d'un bon model a mida
No requereix saber de modelatge	Poc control sobre el preprocessament
Avaluació i explicabilitat incloses	Cost d'entrenament més alt per resultat
Integrat amb Model Registry i endpoints	El model és una caixa bastant tancada
Bona línia base contra la qual comparar	No admet arquitectures ni pèrdues pròpies

I una funció que gairebé mai no s'esmenta però que és de les més valuoses: AutoML és un excel·lent detector de problemes mal plantejats. Si AutoML, amb tot el seu esforç, no aconsegueix res millor que l'atzar, és molt probable que el senyal no sigui a les dades, i cap model a mida no se'l va a inventar. I si AutoML aconsegueix un 99,8 % a la primera, gairebé segur que tens una fuita de dades. En tots dos casos t'ha estalviat setmanes.

Tipus de problema i requisits mínims de dades

Tipus de dada	Problemes admesos	Mínim tècnic	Mínim raonable a la pràctica
Tabular	Classificació binària i multiclasse, regressió, previsió	1.000 files	10.000+ files, i ≥100 exemples de la classe minoritària
Imatge	Classificació (una o diverses etiquetes), detecció d'objectes	10 imatges per etiqueta	100–500 per etiqueta, amb varietat real
Text	Classificació, extracció d'entitats, anàlisi de sentiment	20 exemples per etiqueta	100–1.000 per etiqueta
Vídeo	Classificació, reconeixement d'accions, seguiment	Desenes de clips	Centenars, i ben retallats

La diferència entre les dues últimes columnes importa molt. El mínim tècnic és el que la plataforma accepta; el mínim raonable és el que produeix un model utilitzable. Amb 10 imatges per etiqueta AutoML entrena i et dóna un número, però aquell model no serveix per a res en producció.

I una regla que val per a tot el mòdul: la varietat importa més que la quantitat. Cinc-centes fotos de motxilles preses totes amb el mateix fons blanc i la mateixa llum ensenyen al model a reconèixer aquell fons, no la motxilla. Dues-centes fotos variades —fons, angles i il·luminacions diferents— generalitzen molt millor.

Comprovació prèvia obligatòria abans d'entrenar res:

SELECT
  COUNT(*)                                            AS filas,
  COUNTIF(compro = 1)                                 AS compraron,
  ROUND(100 * COUNTIF(compro = 1) / COUNT(*), 2)      AS pct_positivos,
  COUNT(DISTINCT sesion_id)                           AS sesiones_unicas,
  MIN(fecha)                                          AS desde,
  MAX(fecha)                                          AS hasta,
  COUNTIF(importe_carrito IS NULL)                    AS sin_importe
FROM `alpinashop-datos.alpinashop_analitica.ml_sesiones`;

Si pct_positivos és 0,4 %, si sesiones_unicas és menor que filas (hi ha duplicats) o si sin_importe és la meitat del conjunt, tens feina abans d'entrenar. Entrenar primer i descobrir-ho després costa hores de màquina.

Cas 1: predir la compra d'una cistella

L'objectiu, escrit com a decisió de negoci i no com a problema tècnic: estimar la probabilitat que una sessió amb cistella acabi en compra, per decidir a qui es mostra un incentiu de tancament.

La taula de partida és ml_sesiones, la que vas construir a 05-01 creuant visitas amb v_pedidos_analitica. L'enriquirem amb context del client i de la cistella, tenint cura que tot sigui informació disponible en l'instant de la decisió:

CREATE OR REPLACE TABLE `alpinashop-datos.alpinashop_analitica.automl_carritos` AS
SELECT
  v.sesion_id,
  v.fecha,
  -- Context de la sessio
  v.dispositivo,
  v.canal,
  v.paginas_vistas,
  v.minutos_sesion,
  v.productos_vistos,
  -- Context de la cistella
  v.unidades_carrito,
  ROUND(v.importe_carrito, 2)                                AS importe_carrito,
  ROUND(v.importe_carrito / NULLIF(v.unidades_carrito,0), 2) AS precio_medio_articulo,
  c.categoria_principal,
  -- Context temporal
  EXTRACT(DAYOFWEEK FROM v.fecha)                            AS dia_semana,
  EXTRACT(HOUR FROM v.hora_inicio)                           AS hora_dia,
  -- Context del client, calculat ABANS d aquesta sessio
  IFNULL(h.pedidos_previos, 0)                               AS pedidos_previos,
  IFNULL(ROUND(h.ticket_medio_previo, 2), 0)                 AS ticket_medio_previo,
  IFNULL(h.dias_desde_ultimo_pedido, 999)                    AS dias_desde_ultimo,
  -- Etiqueta
  v.compro
FROM `alpinashop-datos.alpinashop_analitica.ml_sesiones` v
LEFT JOIN `alpinashop-datos.alpinashop_analitica.carrito_categorias` c
  ON c.sesion_id = v.sesion_id
LEFT JOIN `alpinashop-datos.alpinashop_analitica.hist_cliente_diario` h
  ON h.cliente_hash = v.cliente_hash
 AND h.fecha        = DATE_SUB(v.fecha, INTERVAL 1 DAY)
WHERE v.unidades_carrito > 0;

El detall que decideix si aquest model serveix o no és a l'últim JOIN: h.fecha = DATE_SUB(v.fecha, INTERVAL 1 DAY). L'historial del client s'agafa del dia anterior a la sessió, no d'avui. Si s'unís amb l'historial actual, cada fila de l'entrenament portaria informació sobre comandes posteriors a la sessió que s'està predient. El model aprendria que "els clients amb moltes comandes compren", cosa que és certa i també inútil: en producció, en el moment de decidir, aquella comanda futura no existeix.

Aquest tipus de taula —una foto de l'estat de cada entitat en cada data— s'anomena taula històrica de característiques i és el que evita gairebé totes les fuites temporals. És exactament el que un Feature Store desa per tu (05-01, apartat 7).

Crear el conjunt i llançar l'entrenament:

gcloud ai datasets create \
  --project=alpinashop-datos --region=europe-west1 \
  --display-name=carritos-conversion \
  --metadata-schema-uri="gs://google-cloud-aiplatform/schema/dataset/metadata/tabular_1.0.0.yaml" \
  --metadata="{\"inputConfig\":{\"bigquerySource\":{\"uri\":\"bq://alpinashop-datos.alpinashop_analitica.automl_carritos\"}}}"

Des de la consola, el flux demana: columna objectiu (compro), tipus d'objectiu (classificació binària), columnes a excloure (sesion_id i fecha —la primera és un identificador, la segona defineix la divisió i no ha d'entrar com a característica), mètode de divisió, pressupost i mètrica d'optimització.

En Python queda més explícit i, sobretot, reproduïble:

from google.cloud import aiplatform

aiplatform.init(project="alpinashop-datos", location="europe-west1")

ds = aiplatform.TabularDataset("projects/.../datasets/1234567890")

job = aiplatform.AutoMLTabularTrainingJob(
    display_name="carritos-conversion-v1",
    optimization_prediction_type="classification",
    optimization_objective="maximize-au-prc",   # PR-AUC, no accuracy
)

model = job.run(
    dataset=ds,
    target_column="compro",
    predefined_split_column_name="conjunto",     # divisio temporal propia
    budget_milli_node_hours=2000,                # 2 nodes-hora
    model_display_name="automl-carritos-v1",
    disable_early_stopping=False,
)

Dues eleccions que mereixen justificació:

maximize-au-prc en lloc de l'exactitud. Amb classes desequilibrades, l'àrea sota la corba de precisió-exhaustivitat reflecteix el que interessa —trobar els positius— molt millor que el percentatge d'encerts. Hi tornem a l'apartat 7.
disable_early_stopping=False: si el model deixa de millorar, AutoML s'atura i no et cobra el pressupost restant. Desactivar-ho només té sentit en casos molt concrets.

La divisió temporal: per què l'aleatòria seria trampa

AutoML divideix per defecte en 80 % entrenament, 10 % validació i 10 % test, de forma aleatòria. Per al problema d'AlpinaShop, això està malament, i val la pena entendre-ho bé perquè és l'error conceptual més repetit.

Imagina't que el 14 de febrer AlpinaShop llança una campanya i les conversions es disparen. Amb divisió aleatòria, unes sessions del 14 de febrer acaben a entrenament i d'altres a test. El model, entrenant, veu com es va comportar aquell dia concret i aprèn a reconèixer-lo. En avaluar-se sobre les altres sessions del mateix dia, encerta espectacularment.

Aquell resultat no es reproduirà mai en producció, perquè en producció el model prediu sobre dies que no ha vist mai. La divisió aleatòria mesura "sap interpolar dins del que és conegut?" quan la pregunta real és "sap extrapolar al desconegut?".

La regla: si el problema té dimensió temporal, la divisió ha de ser temporal. S'entrena amb el passat, es valida amb el passat immediat i s'avalua amb el futur.

CREATE OR REPLACE VIEW `alpinashop-datos.alpinashop_analitica.automl_carritos_split` AS
SELECT
  *,
  CASE
    WHEN fecha <  DATE '2025-11-01' THEN 'TRAIN'
    WHEN fecha <  DATE '2026-01-01' THEN 'VALIDATE'
    ELSE                                 'TEST'
  END AS conjunto
FROM `alpinashop-datos.alpinashop_analitica.automl_carritos`
WHERE fecha BETWEEN DATE '2024-01-01' AND DATE '2026-03-31';

Vertex AI accepta aquesta columna amb predefined_split_column_name="conjunto", i els valors han de ser exactament TRAIN, VALIDATE i TEST.

Hi ha un efecte secundari que convé anticipar: les mètriques baixaran. És normal i és bo. Si amb divisió aleatòria l'AUC era 0,91 i amb divisió temporal és 0,83, el 0,83 és el número real. El 0,91 era una il·lusió, i descobrir-ho ara és molt més barat que descobrir-ho després del desplegament.

Un matís addicional: el període de test ha de cobrir almenys un cicle de negoci complet. En una botiga de material de muntanya, dos mesos d'hivern no representen l'estiu. Si es pot, convé avaluar també sobre un període estacionalment diferent.

Pressupost d'entrenament i cost

El pressupost s'expressa en nodes-hora i limita quant explora AutoML. S'indica en mil·lèsimes: budget_milli_node_hours=2000 són 2 nodes-hora.

Situació	Pressupost orientatiu	Comentari
Primera prova, hi ha senyal?	1 node-hora	Barat i suficient per descartar
Model tabular de treball	3–6 nodes-hora	El punt habitual de rendiments decreixents
Conjunt gran i complex	10–20 nodes-hora	Només si la prova curta prometia
Imatge	Diverses hores	Cost per hora més gran que el tabular

El preu per node-hora varia per tipus de dada i per regió i canvia amb el temps: consulta'l sempre a la documentació oficial vigent. Com a ordre de magnitud, un entrenament tabular de poques hores es mou en desenes d'euros; un d'imatge amb moltes hores pot arribar a diversos centenars.

Tres consells que estalvien diners de debò:

Comença sempre amb 1 node-hora. Si amb aquell pressupost l'AUC és 0,52 —o sigui, atzar—, no ho arregla gastar-ne vint vegades més: el problema és a les dades.
Deixa l'aturada anticipada activada. No pagues el que no es fa servir.
Abans de gastar, compara contra BigQuery ML. Una regressió logística costa cèntims i en problemes tabulars senzills queda sorprenentment a prop. Si AutoML millora dos punts d'AUC sobre BigQuery ML, la pregunta legítima és si aquests dos punts valen la diferència de cost i d'opacitat.

Llegir els resultats sense enganyar-se

Aquí és on se separa qui fa servir AutoML de qui l'entén.

Suposem el resultat del model de cistelles sobre el conjunt de test, amb 10.000 sessions de les quals 1.200 van acabar en compra (12 %):

	Va predir compra	Va predir no compra
Va comprar de debò	780 (VP)	420 (FN)
No va comprar	890 (FP)	7.910 (VN)

Les mètriques que en surten:

Mètrica	Fórmula	Valor	Què significa aquí
Exactitud	(VP+VN)/total	86,9 %	Enganyosa: dir "ningú no compra" donaria 88 %
Precisió	VP/(VP+FP)	46,7 %	De cada 100 als quals dono l'incentiu, 47 anaven a comprar
Exhaustivitat	VP/(VP+FN)	65,0 %	En detecto 65 de cada 100 compradors reals
F1	mitjana harmònica	54,5 %	Equilibri entre les dues anteriors
ROC-AUC	—	0,83	Probabilitat d'ordenar bé un positiu sobre un negatiu
PR-AUC	—	0,51	La mètrica honesta amb classes desequilibrades

L'exactitud és la mètrica que més enganya, i amb diferència. En aquest cas, un model que respongués sempre "no compra" tindria un 88 % d'exactitud —més que el nostre— i seria completament inútil. Cada vegada que vegis presumir d'exactitud en un problema desequilibrat, pregunta quin és el percentatge de la classe majoritària.

ROC-AUC i PR-AUC no són intercanviables. El ROC-AUC incorpora els vertaders negatius, que aquí són 7.910 i abundantíssims, i això l'infla: un 0,83 sona bé. El PR-AUC només mira què passa amb els positius, i el seu 0,51 és una descripció molt més fidel de la dificultat real. Amb classes desequilibrades, mira sempre el PR-AUC.

I la referència que mai no s'ha d'oblidar: quant donaria una regla tonta? Si ordenar les sessions per import de la cistella ja identifiqués el 55 % dels compradors, el model aporta deu punts, no seixanta-cinc.

El llindar de decisió és una decisió de negoci

Un classificador no retorna "sí" o "no": retorna una probabilitat entre 0 i 1. Convertir-la en decisió requereix un llindar, i aquest llindar no el tria el model. El tries tu, i és una decisió econòmica.

Per a AlpinaShop, l'incentiu és un descompte del 10 %. Els números per sessió:

Vertader positiu: dono el descompte a qui anava a comprar → perdo el 10 % del marge innecessàriament. Sobre una cistella mitjana de 95 €, uns –4 €.
Fals positiu: dono el descompte a qui no anava a comprar → si el descompte convenç una part, guanyo; si no, no costa res perquè no hi ha venda. Valor esperat lleugerament positiu.
Fals negatiu: no dono el descompte a qui anava a abandonar → perdo una venda que podria haver recuperat, uns –20 € de marge esperat.
Vertader negatiu: no dono descompte a qui no anava a comprar → 0 €.

Amb aquests números, l'error car és el fals negatiu, i això empeny el llindar cap avall: convé ser generós repartint incentius. La taula del compromís:

Llindar	Sessions amb incentiu	Precisió	Exhaustivitat	Lectura de negoci
0,20	4.100	26 %	89 %	Gairebé tothom rep descompte; es regala marge
0,35	2.400	38 %	76 %	Compromís raonable
0,50	1.670	47 %	65 %	Per defecte, no necessàriament el millor
0,70	620	68 %	35 %	Molt selectiu; se'n perden dos terços

La manera correcta de triar és calcular el benefici esperat de cada llindar amb els valors de negoci, no mirar quin dóna millor F1:

WITH escenarios AS (
  SELECT
    umbral,
    COUNTIF(prob >= umbral AND compro = 1)      AS vp,
    COUNTIF(prob >= umbral AND compro = 0)      AS fp,
    COUNTIF(prob <  umbral AND compro = 1)      AS fn
  FROM `alpinashop-datos.alpinashop_analitica.predicciones_test`,
       UNNEST([0.2, 0.3, 0.35, 0.4, 0.5, 0.6, 0.7]) AS umbral
  GROUP BY umbral
)
SELECT
  umbral, vp, fp, fn,
  ROUND(vp * -4.0 + fp * 0.5 + fn * -20.0, 0) AS beneficio_estimado_eur
FROM escenarios
ORDER BY beneficio_estimado_eur DESC;

Aquesta consulta converteix una discussió tècnica en una taula que direcció entén. I explicita una cosa que sol quedar implícita: els coeficients -4, 0,5 i -20 són hipòtesis de negoci, no veritats. Escriure-les obliga a discutir-les, que és exactament el que cal fer.

Un advertiment final sobre el llindar: pot ser diferent per segment. Per a clients nous, on el valor de captació és més gran, potser interessa un llindar més baix. Això ja no és una decisió del model, és disseny de producte.

Importància de les característiques i explicabilitat

AutoML retorna dos nivells d'explicació, i serveixen per a coses diferents.

Importància global: quines característiques pesen més en el model en conjunt. Per al model de cistelles, un resultat plausible:

Característica	Importància	Interpretació
`pedidos_previos`	0,24	Qui ja va comprar torna a comprar
`minutos_sesion`	0,19	Sessions llargues indiquen intenció
`importe_carrito`	0,15	Les cistelles cares s'abandonen més
`dias_desde_ultimo`	0,12	Recència com a senyal de vinculació
`canal`	0,10	La cerca de marca converteix més que display
`dispositivo`	0,07	El mòbil converteix menys que l'escriptori
`hora_dia`	0,05	Marginal
`dia_semana`	0,03	Gairebé irrellevant

Com es llegeix aquesta taula, i com no. La importància és associació, no causalitat. Que minutos_sesion pesi molt no significa que allargar artificialment la sessió augmenti les compres: significa que qui comprarà tendeix a passar-hi més temps. Confondre les dues coses produeix decisions de producte absurdes.

El que sí que cal fer amb aquesta taula és una revisió de sensatesa. Si aparegués una característica amb importància 0,80 i les altres a zero, és senyal d'alarma: probablement aquella columna filtra el resultat. I si totes les importàncies fossin similars i baixes, és senyal que cap característica no té senyal real.

Atribucions locals: per què el model va predir el que va predir per a una fila concreta. Es demanen a la petició de predicció amb explain en lloc de predict, i retornen la contribució de cada característica a aquella predicció individual. Són imprescindibles quan cal justificar una decisió davant d'una persona, i tornaran a 05-07 com a part del checklist de ML responsable.

Cas 2: classificar les fotos del catàleg

El segon problema és diferent en naturalesa: entrada no estructurada, 60 GB d'imatges a alpinashop-catalogo sota productos/<sku>/original|web|thumb/.

L'objectiu: classificar cada foto en la taxonomia pròpia d'AlpinaShop —motxilla, piolet, casc, jaqueta, bota, grampó, corda, sac— per detectar fitxes amb imatges mal assignades i per enriquir les metadades del catàleg.

Per què no n'hi ha prou amb la Cloud Vision API. L'API preentrenada (lliçó 05-05) reconeix "motxilla" perfectament, però no distingeix una motxilla de travessa de 60 litres d'una d'atac de 25, i dirà "destral" a un piolet tècnic. AutoML Vision existeix precisament quan la taxonomia és pròpia i el vocabulari general no la cobreix.

Les dades d'entrada es declaren en un CSV d'índex a Cloud Storage:

TRAIN,gs://alpinashop-catalogo/productos/MOC-4471/web/01.jpg,motxilla
TRAIN,gs://alpinashop-catalogo/productos/PIO-1120/web/01.jpg,piolet
VALIDATE,gs://alpinashop-catalogo/productos/CAS-8802/web/02.jpg,casc
TEST,gs://alpinashop-catalogo/productos/BOT-3391/web/01.jpg,bota

Tres columnes: conjunt, URI de la imatge i etiqueta. Si s'omet la primera columna, Vertex AI divideix per tu.

Aquí la divisió sí que pot ser aleatòria —no hi ha dimensió temporal—, però amb una condició crítica: totes les fotos del mateix SKU han de caure en el mateix conjunt. Un producte sol tenir cinc o sis fotos gairebé idèntiques; si unes van a entrenament i d'altres a test, el model memoritza aquell producte concret i l'avaluació menteix. L'agrupació per entitat és al problema d'imatge el que la divisió temporal és al tabular.

job = aiplatform.AutoMLImageTrainingJob(
    display_name="catalogo-categorias-v1",
    prediction_type="classification",
    multi_label=False,
    model_type="CLOUD",          # servit en endpoint; EDGE per exportar
    base_model=None,
)

model_img = job.run(
    dataset=ds_imatges,
    budget_milli_node_hours=8000,   # 8 nodes-hora
    training_filter_split=None,
    model_display_name="automl-catalogo-v1",
    disable_early_stopping=False,
)

model_type="CLOUD" produeix un model optimitzat per servir-se a Vertex AI. "EDGE" genera una variant exportable (TensorFlow Lite, contenidor) per executar-se fora, més petita i una mica menys precisa. AlpinaShop no necessita edge: les seves imatges ja són al núvol.

Etiquetar bé: el cost que ningú no pressuposta

Aquest apartat és el més avorrit de la lliçó i el que més projectes enfonsa.

Per entrenar AutoML Vision calen imatges etiquetades, i els 60 GB d'AlpinaShop no ho estan. Els números reals d'etiquetar:

8 categories × 300 imatges = 2.400 imatges per etiquetar.
A uns 6 segons per imatge amb una bona interfície, són unes 4 hores de feina humana.
Més el temps d'acordar la taxonomia, que sempre porta més del previst.

I el problema no és el temps, és la coherència. Les preguntes que sorgeixen a la mitja hora de començar:

Una foto on apareix una motxilla amb un piolet penjat, què és?
Un casc d'escalada i un d'esquí, són la mateixa etiqueta?
Una foto de detall de la costura d'una jaqueta, és "jaqueta" o es descarta?
Un pack de corda + mosquetons, quina etiqueta porta?

Si aquestes decisions no s'escriuen abans i no són consistents, el model aprèn la incoherència. I un model entrenat amb etiquetes contradictòries no pot superar la qualitat de les seves etiquetes: és un sostre dur.

El protocol mínim, que costa una tarda i salva el projecte:

Escriure la guia d'etiquetatge amb la definició de cada categoria i almenys un cas límit resolt per categoria.
Etiqueta otros per al que no encaixi. Sense ella, la gent força etiquetes i contamina el conjunt.
Doble etiquetatge d'una mostra: dues persones etiqueten les mateixes 200 imatges. Si coincideixen en menys del 90 %, la taxonomia és ambigua i cal arreglar-la abans de continuar.
Començar per les fotos web/, que estan normalitzades, abans que per les original/.

Vertex AI ofereix fluxos d'etiquetatge a la consola i serveis d'etiquetatge gestionat amb etiquetadors humans. Compte amb això últim si les imatges contenen alguna cosa sensible: enviar fotos de clients a un servei d'etiquetatge extern té implicacions de privadesa que cal valorar abans. Les fotos de catàleg d'AlpinaShop no en tenen; les que pugen els clients a les ressenyes, sí.

Desplegar: endpoint o predicció per lots

La mateixa disjuntiva de 05-01, i la resposta torna a ser la mateixa per la mateixa raó.

Per al model d'imatge, la tasca és classificar 60 GB de fotos una vegada, i després només les noves que entrin. Això és un cas de llibre de predicció per lots:

gcloud ai batch-prediction-jobs create \
  --project=alpinashop-datos --region=europe-west1 \
  --display-name=clasifica-catalogo-inicial \
  --model=MODEL_ID \
  --input-paths-uri=gs://alpinashop-datalake/entradas/catalogo_imagenes.jsonl \
  --input-format=jsonl \
  --output-uri-prefix=gs://alpinashop-datalake/salidas/catalogo-clases/ \
  --output-format=jsonl

I els resultats es carreguen al dataset governat per creuar-los amb el catàleg:

CREATE OR REPLACE TABLE `alpinashop-datos.alpinashop_analitica.imagenes_clasificadas` AS
SELECT
  REGEXP_EXTRACT(instance.content, r'productos/([^/]+)/') AS sku,
  instance.content                                        AS uri_imagen,
  prediction.displayNames[OFFSET(0)]                      AS categoria_predicha,
  ROUND(prediction.confidences[OFFSET(0)], 3)             AS confianza
FROM `alpinashop-datos.alpinashop_analitica.raw_predicciones_imagen`;

-- Fitxes amb possible imatge equivocada
SELECT i.sku, p.categoria AS categoria_ficha,
       i.categoria_predicha, i.confianza, i.uri_imagen
FROM `alpinashop-datos.alpinashop_analitica.imagenes_clasificadas` i
JOIN `alpinashop-datos.alpinashop_analitica.productos` p USING (sku)
WHERE i.categoria_predicha != p.categoria
  AND i.confianza > 0.85
ORDER BY i.confianza DESC;

Aquesta consulta és el producte real de tota la feina. No és un model desplegat: és una llista de fitxes revisables per una persona, ordenada per confiança. Un model que produeix una llista de treball prioritzada aporta més valor amb menys risc que un que actua sol.

Per a les fotos noves, la classificació es dispara des del topic imagenes-subidas de Pub/Sub, amb la implementació que arribarà a 06-03 amb Cloud Functions.

Els tres paranys: fuita, desequilibri i sobreajust

Fuita de dades (data leakage). Una característica conté informació que en producció no estarà disponible en el moment de predir. Símptoma inconfusible: mètriques massa bones. A AlpinaShop, les candidates són metodo_pago (només existeix si hi va haver compra), direccion_envio_confirmada, codigo_descuento_aplicado i qualsevol historial de client calculat a data d'avui en lloc de a data de la sessió. La prova d'olfacte és sempre la mateixa pregunta: aquesta dada existia i era coneguda en l'instant exacte de la decisió? Si la resposta és "més o menys", és que no.

Desequilibri de classes. Quan una classe és rara, el model aprèn a ignorar-la. Amb un 12 % de conversió el problema és moderat; amb un 0,3 % de frau és greu. Remeis: triar PR-AUC com a objectiu, ponderar classes, i en casos extrems submostrejar la classe majoritària —mai el conjunt de test, que ha de conservar la proporció real perquè les mètriques signifiquin alguna cosa—. I de vegades el remei correcte és reformular: en comptes de classificar, ordenar per risc i revisar els N primers.

Sobreajust. El model memoritza en lloc de generalitzar. Símptoma: excel·lent en entrenament, mediocre en test. AutoML el controla bastant bé amb regularització i aturada anticipada, però no et pot protegir de dues causes que depenen de tu: poques dades per a la complexitat del problema, i filtració entre conjunts —el mateix SKU o el mateix client a entrenament i a test—.

Parany	Símptoma	Causa habitual	Què fer
Fuita	AUC > 0,97 sospitós	Columna del futur	Auditar cada columna amb la pregunta de l'instant
Desequilibri	Exhaustivitat ínfima	Classe rara	PR-AUC, pesos, replantejar com a rànquing
Sobreajust	Test molt pitjor que train	Poques dades o filtració	Agrupar per entitat, més dades, menys complexitat

Quan AutoML no és la resposta

Criteri	API preentrenada	BigQuery ML	AutoML	Entrenament personalitzat
Dades pròpies necessàries	Cap	Sí, a BigQuery	Sí, etiquetades	Sí, etiquetades
Temps fins al resultat	Minuts	Hores	Hores o dies	Setmanes
Coneixement requerit	Cridar una API	SQL	Interfície + criteri	ML i enginyeria
Control sobre el model	Cap	Baix	Baix	Total
Cost d'entrenament	0	Molt baix	Mitjà-alt	Alt
Cost per predicció	Per unitat	Molt baix	Mitjà	Variable
Sostre de qualitat	El del proveïdor	Mitjà	Alt	El més alt
Quan triar-lo	El problema és genèric	Tabular i ja a BigQuery	Taxonomia pròpia, sense equip de ML	Requisits que res més no cobreix

AutoML no és la resposta quan:

El problema és genèric. "Aquesta imatge conté una persona?" o "aquest text és positiu?" els resolen les APIs preentrenades (05-04, 05-05) sense dades, sense entrenament i per cèntims.
No tens dades etiquetades i no invertiràs a etiquetar-les. Sense etiquetes no hi ha AutoML.
La dada és tabular i ja viu a BigQuery. Prova BigQuery ML primer: són hores contra dies i cèntims contra desenes d'euros.
Necessites una arquitectura o una funció de pèrdua pròpies. És el cas del recomanador two-tower de 05-03.
Una heurística ja resol el 80 %. La lliçó DA-003 de 05-01 continua vigent.
Necessites executar el model fora del núvol amb requisits estrictes. El mode EDGE ajuda, però un model propi et dóna més control sobre mida i latència.

Biaix, decisions automatitzades i marc legal

Els dos models d'aquesta lliçó tenen perfils de risc molt diferents, i veure-ho en paral·lel és la millor manera d'entendre el marc.

El model d'imatge és de risc baix. Classifica objectes inanimats. El pitjor error possible és etiquetar un piolet com a destral, i el remei és que una persona ho corregeixi en una llista de revisió.

El model de cistelles sí que tracta dades personals i sí que afecta persones. I aquí cal pensar abans de desplegar:

Biaix. El model aprèn del que va passar. Si històricament els clients que entren des de mòbil converteixen menys —perquè el web mòbil és pitjor—, el model aprendrà a no oferir-los incentius, amb la qual cosa convertiran encara menys, amb la qual cosa el model es reafirmarà. És un bucle de retroalimentació: el model no descriu la realitat, la fabrica. La manera de detectar-ho és mesurar el rendiment per segment —dispositiu, canal, país, client nou o recurrent— i no només en agregat. Un AUC global de 0,83 pot amagar un 0,86 en escriptori i un 0,61 en mòbil.

Dades personals i RGPD. Encara que s'entreni sobre v_pedidos_analitica amb el client pseudonimitzat, la pseudonimització no és anonimització: continua sent dada personal a efectes del RGPD i continuen aplicant-se la base legal, la minimització, la limitació de la finalitat i els terminis de conservació. S'apliquen també els drets d'accés, oposició i supressió, cosa que implica poder retirar les dades d'un client del conjunt d'entrenament del pròxim cicle.

Decisions automatitzades. Mostrar o amagar un descompte comercial no és el mateix que denegar un crèdit. Però la frontera de l'article 22 del RGPD —decisions basades únicament en tractament automatitzat amb efectes significatius— no sempre és òbvia, i una diferenciació sistemàtica de preus entre clients pot acostar-s'hi més del que sembla.

AI Act europeu. El Reglament d'IA classifica els sistemes per nivell de risc, i d'aquella classificació depenen obligacions de gestió de riscos, qualitat de dades, documentació tècnica, registre, transparència i supervisió humana. Un sistema de recomanació comercial se sol situar en un nivell baix, però la classificació depèn de l'ús concret, i l'ús es pot desplaçar amb el temps sense que ningú no ho revisi.

Recomanació expressa. Abans de desplegar el model de cistelles, un professional de compliment normatiu o el DPD ha de determinar la base legal del tractament, si l'ús previst constitueix decisió automatitzada de l'article 22, quina informació cal donar als clients, el termini de conservació del conjunt d'entrenament, i la classificació del sistema sota l'AI Act amb les obligacions associades. Aquesta lliçó descriu controls tècnics i no constitueix assessorament jurídic. Totes les dades són fictícies.

I una mesura tècnica que val més que moltes declaracions: avaluar per segment i publicar aquella taula juntament amb la mètrica global. Si ningú no mira el rendiment per grup, el biaix no es detecta.

Errors Habituals i Consells

Refiar-se de l'exactitud. Amb classes desequilibrades és la mètrica que més enganya. Mira PR-AUC, precisió i exhaustivitat, i compara-les sempre contra el percentatge de la classe majoritària.

Deixar la divisió aleatòria en un problema temporal. Produeix mètriques inflades que no es reprodueixen en producció.

Que les fotos del mateix producte caiguin en conjunts diferents. Filtració pura: el model memoritza el producte i l'avaluació menteix. Agrupa per entitat.

Ficar l'identificador com a característica. sesion_id o sku com a columna fa que el model memoritzi. AutoML sol descartar columnes d'alta cardinalitat, però no t'hi refiïs: exclou-les tu.

Acceptar el llindar 0,5 sense pensar. És un valor per defecte, no una recomanació. El llindar es calcula amb els costos de cada tipus d'error.

Etiquetar sense guia escrita. Etiquetes incoherents posen un sostre a la qualitat del model que cap pressupost d'entrenament no aixeca.

Gastar el pressupost gran a la primera. Un node-hora et diu si hi ha senyal. Si no n'hi ha, vint tampoc no el trobaran.

Consell: desa les prediccions del test amb la seva etiqueta real. És el que permet recalcular llindars, analitzar per segment i comparar contra el següent model sense tornar a entrenar.

Consell: posa el resultat en mans d'una persona abans que en mans d'un procés. La llista de fitxes amb imatge sospitosa aporta valor des del primer dia i sense risc.

Exercicis

Exercici 1

La Lucía entrena amb AutoML un model per predir si una comanda serà retornada. Obté una exactitud del 94,2 % i vol desplegar-lo. Saps que el 6 % de les comandes d'AlpinaShop es retornen. Què li preguntes abans de donar el vistiplau, i quines mètriques demanes?

Exercici 2

Dissenya el conjunt d'entrenament per a un model que prediga, en el moment de finalitzar una comanda, si aquella comanda arribarà tard (més de 5 dies). Enumera les característiques que faries servir, marca les que serien fuita de dades i explica com dividiries train/validació/test.

Exercici 3

El model de classificació d'imatges obté un 91 % d'exactitud global. En desglossar per categoria, grampó té un 34 % d'exhaustivitat i motxilla un 98 %. Diagnostica les causes possibles i proposa un pla de tres accions.

Solucions

Solució 1

La pregunta clau, abans que cap altra: quina exactitud tindria un model que digués sempre "no es retorna"? Resposta: 94 %. El model de la Lucía aporta 0,2 punts sobre no fer res. Amb tota probabilitat ha après a dir "no" gairebé sempre.

Mètriques que cal demanar:

Matriu de confusió completa sobre el test. Si els vertaders positius són gairebé zero, el diagnòstic està confirmat.
Precisió i exhaustivitat de la classe "retornada", que és l'única que interessa. L'exactitud global és irrellevant aquí.
PR-AUC, no ROC-AUC, pel desequilibri 94/6.
Comparació amb una línia base: què s'aconsegueix amb la regla "categoria tèxtil + talla a l'extrem del rang"? Moltes devolucions de roba tècnica són per talla, i una regla simple en pot capturar bona part.

Preguntes sobre les dades:

Quines columnes hi van entrar? Si apareix motivo_devolucion, fecha_devolucion o estado_final, hi ha fuita i l'exactitud no significa res.
Com es va dividir? Si va ser aleatòria i hi ha estacionalitat —i en devolucions n'hi ha, amb el pic de gener—, les mètriques estan inflades.
Quantes devolucions hi ha al test? Amb un 6 % de 2.000 files són 120 casos, un número petit per estimar res amb precisió.

I la pregunta de negoci que ho emmarca tot: què es farà amb la predicció? Si és avisar el client que revisi la talla abans de confirmar, un model amb exhaustivitat moderada ja aporta. Si és bloquejar comandes, no es desplega: un fals positiu és perdre una venda legítima i un client enfadat.

Recomanació: no desplegar. Reentrenar optimitzant PR-AUC amb auto_class_weights, auditar les columnes, dividir temporalment i tornar a avaluar contra la línia base.

Solució 2

Objectiu: classificació binària llego_tarde (lliurament > 5 dies naturals), decidida en l'instant de confirmar la comanda.

Característiques vàlides (totes conegudes en confirmar):

Grup	Característiques
Comanda	Unitats, import, nombre de línies, pes total estimat, volum
Producte	Categoria dominant, si algun article està sense estoc, si ve de proveïdor extern
Destinació	Província, si és zona rural, si és Balears o Canàries, codi postal agrupat
Enviament	Transportista assignat, tipus de servei, si és recollida en punt
Temporal	Dia de la setmana, hora, si és vigília de festiu, setmana de l'any, si és campanya
Històric	Retard mitjà del transportista a aquella província en els últims 30 dies, retard mitjà del proveïdor extern

Fuita de dades — característiques que NO poden entrar:

Característica	Per què és fuita
`fecha_entrega`	És l'etiqueta disfressada
`dias_transito`	Ídem
`numero_incidencias`	Les incidències passen durant l'enviament
`estado_actual`	Només existeix després
`veces_reintentado_reparto`	Posterior a l'enviament
`retraso_medio_transportista` calculat sobre tot l'històric	Inclou períodes posteriors a aquesta comanda

L'última mereix aturar-s'hi: la característica és vàlida, el càlcul és el que filtra. Ha de ser una finestra mòbil dels 30 dies anteriors a la data de la comanda, materialitzada en una taula històrica diària, exactament com el hist_cliente_diario de l'apartat 4.

CREATE OR REPLACE TABLE `alpinashop-datos.alpinashop_analitica.ml_entregas` AS
SELECT
  p.pedido_id,
  p.fecha_pedido,
  p.unidades, p.n_lineas, ROUND(p.peso_kg,2) AS peso_kg,
  p.provincia, p.transportista, p.tipo_servicio,
  EXTRACT(DAYOFWEEK FROM p.fecha_pedido) AS dia_semana,
  EXTRACT(WEEK      FROM p.fecha_pedido) AS semana,
  t.retraso_medio_30d,                      -- finestra ANTERIOR a la comanda
  IF(DATE_DIFF(p.fecha_entrega, p.fecha_pedido, DAY) > 5, 1, 0) AS llego_tarde,
  CASE
    WHEN p.fecha_pedido < DATE '2025-10-01' THEN 'TRAIN'
    WHEN p.fecha_pedido < DATE '2025-12-15' THEN 'VALIDATE'
    ELSE                                         'TEST'
  END AS conjunto
FROM `alpinashop-datos.alpinashop_analitica.pedidos_entrega` p
LEFT JOIN `alpinashop-datos.alpinashop_analitica.hist_transportista_diario` t
  ON t.transportista = p.transportista
 AND t.provincia     = p.provincia
 AND t.fecha         = DATE_SUB(p.fecha_pedido, INTERVAL 1 DAY)
WHERE p.fecha_entrega IS NOT NULL;

Divisió: temporal, obligatòriament. La logística és estacional en el pitjor sentit: la campanya de Nadal concentra els retards. Amb divisió aleatòria, el model veuria comandes de desembre a entrenament i aprendria el patró d'aquell desembre concret.

Cautela important sobre el període de test: si TEST cau íntegre en campanya de Nadal, les mètriques seran pessimistes i no representatives de la resta de l'any. El correcte és avaluar en dos períodes —un de campanya i un de normal— i mirar tots dos. Una mètrica única sobre un període atípic és una mètrica enganyosa.

Nota final: fecha_entrega IS NOT NULL exclou les comandes encara en trànsit. És correcte per entrenar, però introdueix un biaix si les comandes molt retardades triguen tant que queden fora de la finestra. Convé comprovar quantes n'hi ha.

Solució 3

Diagnòstic. Les quatre causes, per probabilitat:

1. Pocs exemples de grampó (la més probable). És un producte de nínxol: si hi ha 40 fotos de grampons davant de 600 de motxilles, el model amb prou feines ha vist la classe. A més, l'exactitud global del 91 % està dominada per les classes nombroses, així que la fallada s'amaga.

2. Confusió amb classes visualment properes. Un grampó i uns ferratges de piolet comparteixen metall, puntes i corretges. Cal mirar la matriu de confusió per classe per veure on van els errors: si el 50 % dels grampons es classifiquen com a "piolet", el problema és discriminació entre classes similars, no manca de dades.

3. Fotos poc representatives. Si els grampons es fotografien sempre sobre fons blanc i des de dalt, i en test apareixen muntats sobre una bota, el model no reconeix l'objecte en context.

4. Etiquetatge incoherent. Un pack de grampó + funda és "grampó"? I una foto de la bota amb el grampó posat? Si aquelles decisions no es van prendre per escrit, hi ha soroll a l'etiqueta.

-- Quants exemples per classe i on van els errors
SELECT etiqueta_real, COUNT(*) AS ejemplos
FROM `alpinashop-datos.alpinashop_analitica.imagenes_etiquetadas`
GROUP BY etiqueta_real ORDER BY ejemplos;

SELECT etiqueta_real, categoria_predicha, COUNT(*) AS casos
FROM `alpinashop-datos.alpinashop_analitica.eval_imagenes`
WHERE etiqueta_real = 'grampo'
GROUP BY 1,2 ORDER BY casos DESC;

Pla de tres accions, en ordre:

Acció 1 — Equilibrar i ampliar grampó. Pujar de 40 a almenys 200 imatges, i amb varietat deliberada: models, fons i angles diferents, muntats i solts, amb funda i sense. Si no hi ha 200 fotos pròpies, es poden fer servir totes les variants disponibles del catàleg (original, web, thumb compten com a fotos diferents només si difereixen de debò; si són la mateixa imatge reescalada, no aporten res). És l'acció amb més retorn.

Acció 2 — Aclarir la taxonomia. Si la matriu de confusió mostra que grampons i piolets es barregen, hi ha dues sortides: fusionar en una etiqueta material_progresion_hielo si la distinció no aporta valor de negoci, o separar millor amb una guia explícita i exemples de cada cas límit. Aquí, la decisió correcta depèn de per a què es fa servir la classificació a la botiga, no del model.

Acció 3 — Canviar la mètrica de seguiment i l'ús. Substituir l'exactitud global per l'exhaustivitat mitjana per classe (macro), que tracta igual la categoria rara i la majoritària, i publicar sempre la taula per classe. I mentrestant, utilitzar el model amb llindar de confiança: acceptar automàticament les prediccions per damunt de 0,90 i enviar la resta a revisió humana. Amb això, la classe dolenta deixa de ser un problema de producció i es converteix en una cua de treball curta, mentre es recullen més exemples —que a més vénen ja etiquetats pel revisor, alimentant l'Acció 1.

El que NO cal fer: apujar el pressupost d'entrenament. El problema són les dades, no el temps de còmput, i gastar més nodes-hora sobre 40 imatges no crea informació que no existeix.

Conclusió

Has vist què fa AutoML per sota —enginyeria de característiques, cerca d'arquitectura, ajust d'hiperparàmetres i assemblatge— i, sobretot, què no fa: no tria el problema, no aconsegueix dades, no detecta que hi has ficat una columna del futur i no sap quines conseqüències té equivocar-se. Això continua sent feina humana, i és on hi ha el valor.

Coneixes els tipus de problema admesos i la diferència entre el mínim tècnic i el mínim raonable de dades, amb la regla que la varietat importa més que la quantitat.

Has construït el cas tabular d'AlpinaShop —predir la conversió d'una cistella— tenint cura de l'única cosa que de debò decideix el resultat: que cada característica estigués disponible en l'instant de la decisió, unint l'historial del client amb el dia anterior i no amb avui. I has entès per què la divisió temporal és obligatòria quan hi ha temps pel mig, i per què les mètriques baixen en aplicar-la: perquè les anteriors eren mentida.

Saps llegir una matriu de confusió i ja no et refies de l'exactitud: amb un 12 % de conversió, dir "ningú no compra" dóna un 88 %. Distingeixes ROC-AUC de PR-AUC i saps quin mirar quan les classes estan desequilibrades. I has convertit l'elecció del llindar en el que realment és: una taula de benefici esperat amb els costos de cada tipus d'error, discutible per direcció i no per l'equip tècnic. Saps llegir la importància de les característiques com a associació i no com a causalitat, i utilitzar-la com a revisió de sensatesa.

Has aplicat AutoML Vision als 60 GB del catàleg, entenent per què l'API preentrenada no basta quan la taxonomia és pròpia, per què totes les fotos d'un SKU han de caure en el mateix conjunt, i què costa de debò etiquetar bé: no les hores, sinó la coherència. I el resultat que has posat en producció no és un model que decideix sol, sinó una llista prioritzada de fitxes sospitoses que revisa una persona —més valor i menys risc.

Tens identificats els tres paranys —fuita, desequilibri i sobreajust— amb el seu símptoma i el seu remei, i la taula que decideix entre API preentrenada, BigQuery ML, AutoML i entrenament personalitzat. I tens clar el marc de responsabilitat: mesurar el rendiment per segment per detectar biaix abans que el bucle de retroalimentació el consolidi, tractar la pseudonimització com el que és —dada personal—, i passar per compliment normatiu abans de desplegar qualsevol model que afecti persones, amb el RGPD i l'AI Act sobre la taula.

Però AutoML té un sostre, i AlpinaShop està a punt de tocar-lo. El recomanador que vol la Marta —que aprengui alhora com són els clients i com són els productes, i que sàpiga col·locar-los al mateix espai per mesurar afinitat— no és un problema de classificació tabular. No hi ha una columna objectiu per predir: cal aprendre una representació. Això requereix una arquitectura concreta, una funció de pèrdua concreta i control sobre com es llegeixen les dades.

A 05-03, TensorFlow a GCP, baixem al codi. Veuràs el mínim de TensorFlow i Keras per seguir sense ser expert, construiràs el recomanador d'AlpinaShop amb incrustacions de client i de producte seguint la intuïció del two-tower, aprendràs a llegir eficientment des de Cloud Storage amb tf.data i TFRecord, empaquetaràs l'entrenament per a Vertex AI triant entre CPU, GPU i TPU amb criteri, faràs servir punts de control per sobreviure a les VM Spot, seguiràs l'entrenament amb TensorBoard gestionat i Experiments, i acabaràs desant un SavedModel al Model Registry a punt per servir.

AutoML: models a mida sense escriure codi