Hay una escena que se repite en casi todas las empresas que empiezan con aprendizaje automático, y AlpinaShop está a punto de vivirla.

Lucía abre un notebook en su portátil. Se descarga un CSV con los pedidos del último año, prueba tres modelos, y el tercero acierta un 84 % de las veces qué clientes van a comprar. Enseña el gráfico en la reunión del lunes y todo el mundo se entusiasma. Dirección pregunta cuándo estará en la web.

Y entonces empiezan las preguntas incómodas. ¿De dónde salió exactamente ese CSV? ¿Qué filtros aplicó? ¿Con qué versión de la librería lo entrenó? ¿Dónde está el modelo? ¿En su carpeta de Descargas? ¿Quién lo va a ejecutar cuando llegue una petición de la tienda, y en cuánto tiempo tiene que responder? ¿Qué pasa cuando los datos cambien dentro de seis meses? ¿Y si Lucía se va?

Ninguna de esas preguntas es sobre el modelo. Todas son sobre el sistema alrededor del modelo, y son precisamente las que separan un experimento interesante de un producto que funciona. Esta lección trata de eso: qué es Vertex AI, qué componente resuelve cada pregunta, y cómo se conecta con la plataforma de datos que has construido en el módulo 4.

Y trata también de algo que casi nunca se dice en un curso de machine learning: que la primera decisión honesta de un proyecto de ML es decidir si hace falta ML.

1. Por qué no basta con un notebook y un portátil
2. El ciclo de vida de un modelo
3. Qué componente de Vertex AI cubre cada etapa
4. Nota histórica: de AI Platform a Vertex AI
5. Workbench: notebooks gestionados conectados a los datos
6. Conjuntos de datos gestionados y pedidos-historico
7. Feature Store y el sesgo entrenamiento/servicio
8. Entrenamiento: trabajos personalizados e hiperparámetros
9. Model Registry, versiones y evaluación
10. Servir el modelo: endpoints en línea y predicción por lotes
11. Model Monitoring: cuando el mundo cambia y el modelo no
12. BigQuery ML: entrenar con SQL sin salir del almacén
13. Cuándo BigQuery ML y cuándo Vertex AI
14. Coste de la plataforma y los dos interruptores que hay que apagar
15. El problema de AlpinaShop: recomendar sin entrenar nada

El notebook de Lucía no está mal. Es el sitio correcto para explorar, y todo proyecto de ML empieza ahí. El problema aparece cuando el resultado tiene que sobrevivir fuera de esa sesión.

Los cinco fallos que se repiten siempre:

Una plataforma de ML es el conjunto de servicios que resuelve esos cinco problemas sin que tengas que construirlos. Vertex AI es la de Google Cloud: un paraguas con almacenamiento de características, entrenamiento gestionado, registro de modelos, servicio de predicciones, monitorización y orquestación, todo bajo el mismo IAM, la misma facturación y la misma red que el resto de tu proyecto.

La idea que conviene fijar antes de seguir: el modelo es la parte pequeña del sistema. Es un porcentaje mínimo del código y del esfuerzo real. Todo lo demás —recolección de datos, verificación, extracción de características, servicio, monitorización, gestión de configuración— es el sistema, y es donde fallan los proyectos.

Un modelo no se hace: se cultiva. Y no es una línea recta, es un bucle.

Las siete etapas, con la pregunta que responde cada una:

1. Problema de negocio. ¿Qué decisión va a cambiar por tener este modelo? Si la respuesta es "ninguna, pero es interesante", el proyecto ya ha fracasado.
2. Datos. ¿Qué información existe, cuánta, de qué calidad y con qué permiso legal para usarla? Aquí es donde el módulo 4 rinde: alpinashop_analitica está gobernado, catalogado y desidentificado.
3. Características. Transformar datos brutos en las señales numéricas que el modelo consume. Es la etapa que más determina el resultado final, muy por encima de la elección del algoritmo.
4. Entrenamiento. Ajustar los parámetros del modelo con los datos históricos.
5. Evaluación. ¿Es mejor que lo que había? ¿Mejor que una heurística simple? ¿Mejor para el negocio, no solo en una métrica?
6. Despliegue. Hacer que el modelo responda a peticiones reales, en línea o por lotes.
7. Monitorización. Vigilar que los datos que entran siguen pareciéndose a los de entrenamiento, y que las predicciones siguen siendo útiles.

El bucle es lo importante. Un modelo desplegado y olvidado es un pasivo: sigue decidiendo con una visión del mundo que ya caducó.

No hace falta usarlos todos. AlpinaShop, con 40 personas, va a usar cinco o seis. Pero conviene saber que están, porque la alternativa a cada uno es construirlo tú.

Si buscas documentación o tutoriales antiguos, te vas a encontrar con nombres que ya no existen, y conviene saber traducirlos.

Hasta 2021, Google Cloud tenía dos ofertas de ML separadas y mal comunicadas entre sí:

• AI Platform (antes Cloud ML Engine): entrenamiento y predicción para quien escribía su propio código.
• AutoML (Vision, Natural Language, Tables…): productos independientes, cada uno con su consola y su API, para quien no escribía código.

Eran mundos distintos. Un modelo de AutoML y uno de AI Platform no compartían registro, ni monitorización, ni forma de desplegarse. Vertex AI los unificó bajo una sola API, un solo registro de modelos y una sola consola. Hoy AutoML no es un producto aparte: es una forma de entrenar dentro de Vertex AI.

AI Platform está retirada. Si encuentras un tutorial que use gcloud ai-platform jobs submit o el endpoint ml.googleapis.com, es material obsoleto. El equivalente actual es gcloud ai custom-jobs create sobre aiplatform.googleapis.com. La confusión es habitual porque el nombre de la API conservó las siglas antiguas.

Es un buen recordatorio de una regla general de este curso: en la nube, verifica siempre contra la documentación oficial vigente. Los nombres, los límites y los precios cambian, y un tutorial de hace tres años puede llevarte a un producto que ya no existe.

Vertex AI Workbench es un JupyterLab gestionado que corre sobre una VM en tu proyecto. Frente al portátil de Lucía tiene tres ventajas que importan:

• Está donde están los datos. En europe-west1, dentro de la VPC, sin sacar nada fuera.
• Usa una cuenta de servicio, no las credenciales personales. Los permisos son auditables y revocables.
• Escala. Si hace falta más memoria o una GPU para un experimento, se cambia el tipo de máquina y ya está.

Creación de la instancia de Lucía:

Tres opciones merecen explicación:

• --service-account: la instancia actúa como esa cuenta de servicio, que tendrá roles/bigquery.dataViewer sobre las vistas desidentificadas y no sobre las tablas crudas. Lo que aprendiste en 03-04 se aplica aquí sin cambios.
• --disable-public-ip: sin IP pública. El acceso va por IAP y la salida a internet por Cloud NAT, como en 03-01.
• idle-timeout-seconds=3600: se apaga sola tras una hora sin uso. Este parámetro es la diferencia entre 40 € y 400 € de factura a fin de mes.

Dentro del notebook, la conexión a los datos gobernados del módulo 4 es directa:

Qué hace y por qué así. bigquery.Client se autentica sola con la cuenta de servicio de la instancia: no hay claves ni ficheros JSON, que es exactamente lo que querías evitar tras 03-06. La consulta agrega en BigQuery y baja el resultado ya reducido: unas 2.400 filas en lugar de millones. Este es el patrón correcto y el error más caro es el contrario —SELECT * sobre lineas_pedido y agregar en pandas—, que descarga gigabytes, factura bytes leídos y probablemente agota la memoria del notebook.

Cuando el volumen ya no cabe en memoria, existe bigframes, una API tipo pandas que ejecuta las operaciones dentro de BigQuery en lugar de traer los datos. Es la salida natural cuando el to_dataframe() empieza a doler.

Un conjunto de datos gestionado (managed dataset) es un recurso de Vertex AI que apunta a tus datos y les añade lo que un CSV suelto no tiene: identidad, versión, esquema, divisiones train/validación/test y, en imagen y texto, un flujo de etiquetado.

AlpinaShop crea el suyo directamente desde el dataset gobernado:

Fíjate en un detalle nada casual: el origen es v_pedidos_analitica, la vista seudonimizada que creaste en 04-07, no la tabla pedidos. El modelo nunca ve un email. No porque haga falta para entrenar —no aporta nada—, sino porque cada copia de un dato personal es una obligación legal más y un riesgo más.

¿Es obligatorio usar un conjunto gestionado? No. El entrenamiento personalizado puede leer directamente de BigQuery o de Cloud Storage. Los conjuntos gestionados son obligatorios para AutoML y muy recomendables cuando hay que etiquetar a mano o cuando quieres que quede registrado con qué datos exactos se entrenó cada versión. Para un trabajo personalizado que ya lee de una vista versionada, aportan menos.

Este apartado explica el error más caro y más silencioso del machine learning aplicado. Merece leerse despacio.

Una característica (feature) es una señal numérica o categórica que describe una entidad y que el modelo usa para decidir. Para AlpinaShop:

El problema aparece así. Lucía entrena en el notebook y calcula "pedidos del cliente en los últimos 90 días" con una consulta SQL sobre pedidos. Funciona: el modelo acierta. Meses después, Dani tiene que servir el modelo en la web, y necesita ese mismo número en tiempo real, en milisegundos, para el cliente que está mirando la pantalla. No puede lanzar una consulta a BigQuery en la petición HTTP. Así que lo reimplementa en Python contra Cloud SQL.

Y ahí, sin que nadie lo note, aparece la diferencia. La consulta de Lucía contaba los pedidos con estado entregado. La de Dani cuenta todos, incluidos los cancelados. El modelo recibe en producción un número que significa algo distinto del que aprendió. Nadie ve un error: no hay excepción, no hay log rojo. Simplemente el modelo acierta menos de lo que prometía, y el equipo tarda meses en entender por qué.

Eso es el sesgo entrenamiento/servicio (training-serving skew): la característica se calcula de dos maneras distintas en dos sitios distintos.

Feature Store lo resuelve con una idea simple: la característica se define y se calcula una sola vez, se guarda, y se sirve tanto al entrenamiento (por lotes, con valores históricos correctos) como al servicio en línea (con baja latencia). Un solo código, una sola definición.

En Vertex AI, la generación actual de Feature Store se apoya en BigQuery como fuente de la verdad: defines una vista de características sobre una tabla o vista, y un almacén en línea la sincroniza para servirla rápido.

La clave está en --entity-id-columns=cliente_hash y en --cron. La entidad se identifica por el hash del cliente, el mismo que generaste con KMS en 04-07: el almacén de características tampoco contiene datos personales directos. Y la sincronización nocturna significa que las características tienen como mucho 24 horas de antigüedad, algo perfectamente aceptable para "pedidos en 90 días" y no aceptable para "productos vistos en esta sesión", que hay que calcular en caliente.

Una advertencia importante sobre el tiempo: al construir el conjunto de entrenamiento, cada fila debe llevar el valor que la característica tenía en el momento del evento, no el de hoy. Si entrenas un modelo de "¿comprará?" con el número de pedidos actual del cliente, le estás contando el futuro. Volveremos sobre esta trampa —la fuga de datos— en 05-02.

¿Necesita AlpinaShop un Feature Store hoy? Con un modelo y tres características, probablemente no: es una capa más que mantener. Con cinco modelos que comparten características y un equipo de tres personas, sí. La regla práctica: cuando la misma característica la usan dos modelos o la calculan dos personas, ha llegado el momento.

Un trabajo de entrenamiento personalizado es tu código ejecutándose en máquinas de Google, sin que tú gestiones ninguna. Dos formas de empaquetarlo:

AlpinaShop ya tiene Artifact Registry de 02-05 y del pipeline del catálogo, así que la segunda opción no le cuesta nada extra.

Punto por punto:

• --worker-pool-spec define la máquina. Un solo replica-count es entrenamiento en una máquina; con más réplicas y la configuración adecuada, distribuido (lo verás en 05-03).
• La imagen está etiquetada con versión (1.0.3), nunca latest. Si necesitas reproducir el entrenamiento del mes pasado, latest ya no es lo que era.
• Los artefactos se escriben en Cloud Storage, no dentro del contenedor, que desaparece al acabar.

El trabajo escribe logs en Cloud Logging (06-06) y muere solo. No hay VM que apagar, que es la principal ventaja frente a montarte tú una instancia con GPU y olvidarla encendida el fin de semana.

Un parámetro lo aprende el modelo durante el entrenamiento (los pesos). Un hiperparámetro lo decides tú antes: tasa de aprendizaje, profundidad del árbol, tamaño del lote, dimensión de los embeddings. Y su efecto sobre el resultado es enorme.

Probar combinaciones a mano es tedioso y sesgado. Vertex AI Hyperparameter Tuning lanza varias ejecuciones en paralelo y busca la mejor combinación con optimización bayesiana: aprende de las pruebas anteriores en lugar de tirar dardos.

Dos detalles que ahorran dinero y disgustos:

• scaleType: UNIT_LOG_SCALE para la tasa de aprendizaje. Los valores útiles se reparten por órdenes de magnitud, no linealmente: buscar en escala logarítmica explora 0,0001, 0,001 y 0,01 en vez de veinte valores casi idénticos.
• parallelTrialCount: 4 frente a maxTrialCount: 20. Con paralelismo alto acabas antes, pero cada tanda aprende menos de la anterior. Con paralelismo bajo la búsqueda es más inteligente y más lenta. Un cuarto del total es un equilibrio razonable.

Y la advertencia de coste: 20 pruebas cuestan 20 entrenamientos. Antes de lanzar un ajuste, comprueba que un entrenamiento suelto funciona y mide cuánto tarda y cuánto vale.

El Model Registry es el catálogo de modelos del proyecto. Cada modelo tiene versiones numeradas, y cada versión guarda su artefacto, su contenedor de servicio, sus métricas y su linaje.

Los alias son la pieza más útil y la menos usada. En lugar de que el código de la tienda invoque "la versión 7", invoca al alias produccion. Cambiar de modelo es mover un alias, y volver atrás también:

La evaluación se guarda asociada a la versión. Esto es lo que permite responder, meses después, a "¿por qué se sustituyó el modelo el 3 de junio?" con datos y no con recuerdos. Y es la base de la puerta de decisión que construirás en 05-07: un modelo solo se despliega si su evaluación supera a la del modelo que está en producción.

Hay dos formas de usar un modelo, y elegir mal es el error de arquitectura más caro de este módulo.

Un endpoint es un servicio HTTPS siempre encendido con una o más versiones desplegadas. Responde en milisegundos, escala solo, y cobra por el tiempo que las máquinas están vivas, haya tráfico o no.

Una predicción por lotes es un trabajo que arranca, lee un fichero o una tabla, predice millones de filas, escribe el resultado y muere. Cobra por el trabajo, no por el tiempo de espera.

El criterio de elección, en una frase: si el resultado depende de algo que acaba de pasar y que no podías saber antes, necesitas endpoint; si no, lotes.

Y aquí viene una decisión concreta de AlpinaShop que conviene fijar ahora. Las recomendaciones de producto no cambian cada segundo: qué productos se compran juntos es un patrón estable de semanas. Precalcular cada noche las 20 recomendaciones de cada uno de los 2.400 SKU es una tabla de 48.000 filas que la tienda consulta en microsegundos desde Firestore o Memorystore (02-06).

Coste orientativo de la comparación, para dar la magnitud —verifica siempre los precios vigentes en la documentación oficial, que cambian—: un endpoint modesto encendido todo el mes ronda las decenas de euros como mínimo, incluso sin tráfico; el trabajo por lotes nocturno sobre 2.400 SKU son céntimos. Con dos órdenes de magnitud de diferencia y sin ninguna ventaja funcional, la decisión no requiere debate.

Decisión DA-002. Las recomendaciones de producto de AlpinaShop se calculan por lotes cada noche y se sirven desde una tabla precalculada. Se reservará un endpoint en línea solo si aparece un caso que dependa del comportamiento de la sesión en curso.

Un modelo aprende una foto del mundo. El mundo se mueve, la foto no.

Dos fenómenos distintos que conviene no confundir:

Model Monitoring compara continuamente las distribuciones de las peticiones reales contra una línea base (los datos de entrenamiento) y avisa cuando la distancia supera un umbral.

• --feature-thresholds: umbral por característica. Un 0,3 en categoria significa "avísame si la mezcla de categorías que llega se aleja más de eso de la mezcla con la que entrené".
• --prediction-sampling-rate=0.2: se analiza el 20 % de las peticiones. Analizar el 100 % detecta antes, cuesta más y casi nunca compensa.

Un aviso realista: una alerta de deriva no es una avería. En invierno la distribución de categorías tiene que cambiar, y eso es normal. La alerta te dice "mira esto", y el juicio de si hay que reentrenar es humano. Un umbral demasiado sensible produce ruido, el ruido produce indiferencia, y la indiferencia produce que nadie mire la alerta que sí importaba.

Y ahora, la alternativa que muchos equipos deberían probar antes que ninguna otra.

BigQuery ML permite crear y usar modelos con SQL, dentro de BigQuery, sin mover un solo byte y sin escribir Python. Para un equipo que ya vive en SQL —como Lucía después del módulo 4— es la vía más corta desde el dato hasta la predicción.

El caso de AlpinaShop: predecir la probabilidad de que una sesión con carrito acabe en compra, para decidir si merece la pena mostrar un incentivo.

Primero, la tabla de entrenamiento. Es donde se juega el resultado:

Lo importante de esta consulta no es el SQL, son las decisiones. El filtro unidades_carrito > 0 acota la población a las sesiones que llegaron a tener carrito: predecir sobre visitantes que solo miraron la portada mezclaría dos problemas distintos. Y todas las columnas describen la sesión antes del desenlace: no hay ninguna que solo se conozca después de comprar. Si incluyeras metodo_pago, el modelo alcanzaría un 99 % de acierto y sería completamente inútil, porque el método de pago solo existe si hubo compra. Eso es fuga de datos, y se ve con lupa en 05-02.

Ahora el modelo, en una sola sentencia:

Las opciones, una a una:

• LOGISTIC_REG: regresión logística, un clasificador simple, rápido, barato y explicable. Empezar por el modelo más simple que pueda funcionar no es conservadurismo: es la única forma de saber si un modelo complejo aporta algo.
• auto_class_weights = TRUE: si solo el 12 % de las sesiones acaban en compra, un modelo perezoso puede decir "nadie compra" y acertar el 88 %. Esta opción compensa el desequilibrio.
• data_split_method = 'CUSTOM' con es_test basado en la fecha: la división es temporal, no aleatoria. Se entrena con el pasado y se evalúa con el futuro, que es como funcionará en producción. Una división aleatoria mezclaría sesiones de marzo en el entrenamiento y de febrero en la evaluación, y el resultado sería optimista y falso.
• enable_global_explain = TRUE: habilita la importancia de características.

Evaluar y predecir:

ML.EVALUATE devuelve precisión, exhaustividad, f1_score, log_loss y roc_auc. En 05-02 verás qué significa cada una y por qué la exactitud a secas es la métrica que más engaña.

BigQuery ML soporta bastante más que regresión logística: árboles potenciados, DNN, k-means para segmentación, ARIMA_PLUS para series temporales, matrix factorization para recomendación, importación de modelos de TensorFlow, y llamadas a modelos Gemini desde SQL con ML.GENERATE_TEXT. Un modelo entrenado en BigQuery ML se puede exportar y registrar en Vertex AI para servirlo en un endpoint, así que la elección no es una puerta cerrada.

La regla práctica para AlpinaShop: si el dato está en BigQuery, el problema es tabular y quieres una respuesta esta semana, empieza por BigQuery ML. Si no llega —porque necesitas imágenes, texto libre, una arquitectura propia o latencia en línea—, sube a Vertex AI. Lo contrario, empezar por lo complejo, cuesta semanas y muchas veces acaba en un modelo peor.

Y una observación honesta: en una pyme, la mayoría de los problemas de ML útiles son tabulares y caben en BigQuery ML. La sofisticación se reserva para donde de verdad aporte.

Vertex AI factura por partes, y la mayoría de las sorpresas vienen de dos de ellas.

Los dos interruptores, dichos sin rodeos:

1. Apaga los notebooks. Configura idle-timeout-seconds al crear la instancia. Un e2-standard-4 olvidado un mes cuesta más que todos los entrenamientos del proyecto.

2. Deshaz el despliegue de los endpoints que no usas. Es el error caro del módulo. Un endpoint desplegado para una demo del martes sigue facturando en agosto, sin tráfico y sin que nadie lo mire.

Añade a estos recursos las etiquetas de facturación que definiste en 01-04 (centro-coste:analitica) y una alerta de presupuesto sobre ellas. La optimización de costes a fondo llega en 07-05; aquí basta con la higiene mínima.

Cerramos con la decisión que da sentido a todo el módulo, y no es la que se espera de una lección de machine learning.

El problema de negocio es concreto: cuando un cliente añade unos crampones al carrito, ¿qué le sugiere la web? Hoy no sugiere nada. La página de carrito está vacía de contenido y la venta cruzada es cero.

Un ingeniero de ML entusiasta propondría entrenar un modelo de recomendación con embeddings de cliente y de producto. Es lo que verás en 05-03, y es una buena solución. Pero antes de eso hay que hacerse una pregunta: ¿qué se consigue sin entrenar nada?

Y resulta que ya existe la respuesta, calculada en 04-03: la tabla productos_juntos, la matriz de coocurrencia que Spark computó sobre cinco años de líneas de pedido, con soporte, confianza y lift para cada par de productos.

Léelo despacio, porque cada filtro es una decisión de negocio:

• soporte >= 0.001 elimina las casualidades. Dos productos que coincidieron en tres pedidos de cinco años no son un patrón, son ruido.
• confianza >= 0.05 exige que la asociación sea razonablemente frecuente en una dirección concreta.
• lift > 1.2 es el filtro que evita el error clásico: sin él, el recomendador sugeriría a todo el mundo el producto más vendido de la tienda. Un lift de 1 significa "se compran juntos por pura popularidad". Solo por encima hay señal real.
• activo = TRUE AND stock > 0 es la regla más aburrida y la que más dinero salva: jamás recomiendes lo que no puedes vender. Ningún modelo, por sofisticado que sea, corrige por sí solo un catálogo con productos descatalogados.

Esto son unas decenas de líneas de SQL, se ejecuta en segundos, cuesta céntimos, no necesita entrenamiento, no necesita endpoint, es completamente explicable ("te sugerimos esto porque el 23 % de quienes compran crampones compran también este piolet") y se puede poner en producción esta semana.

¿Es tan bueno como un modelo entrenado? No. Tiene tres límites conocidos: no personaliza —a todo el mundo le sugiere lo mismo para el mismo producto—, no sabe nada de los productos nuevos que aún no tienen historial (arranque en frío), y no aprovecha información del cliente ni de la sesión.

¿Importa? Depende de contra qué se compare. Y hoy se compara con no recomendar nada. Pasar de cero a una heurística decente captura la mayor parte del valor. Pasar de esa heurística a un modelo entrenado captura un incremento adicional, que puede merecer la pena o no.

Decisión DA-003. AlpinaShop despliega primero el recomendador heurístico basado en productos_juntos como línea base en producción. Cualquier modelo de ML posterior deberá demostrar que supera a esta línea base en una prueba A/B con métricas de negocio, no solo en una métrica offline. Si no la supera, no se despliega.

Esta decisión es la más importante del módulo, y merece decirse claramente: la mejor decisión de machine learning a veces es no hacer machine learning. Un equipo maduro se distingue por tener una línea base contra la que medirse, y por estar dispuesto a aceptar que a veces la línea base gana.

Empezar por el modelo y no por la decisión. Si nadie sabe qué va a cambiar en la web cuando el modelo prediga, el proyecto ya ha fracasado. Escribe primero la frase: "cuando el modelo diga X, la tienda hará Y".

No tener línea base. Un AUC de 0,84 no significa nada por sí solo. ¿Cuánto daba una regla simple? Si la regla daba 0,81, el modelo aporta muy poco para lo que cuesta mantenerlo.

Dejar endpoints y notebooks encendidos. El error más caro de esta lección. Ponlo en el calendario: una revisión mensual de gcloud ai endpoints list y de instancias de Workbench.

Confundir división temporal con división aleatoria. En cualquier problema con dimensión temporal —y casi todos los de una tienda la tienen—, entrenar con datos posteriores a los de evaluación produce métricas fantásticas que no se reproducen en producción.

Calcular las características dos veces. El sesgo entrenamiento/servicio del apartado 7. Si el mismo número lo calculan dos personas en dos lenguajes, tarde o temprano dejarán de coincidir.

Usar latest en las imágenes de contenedor. Rompe la reproducibilidad. Etiqueta con versión siempre.

Meter datos personales en el modelo por inercia. Un modelo no necesita el email para predecir. Entrena sobre las vistas seudonimizadas de 04-07 y tendrás menos riesgo y menos obligaciones, sin perder nada de calidad.

Consejo: escribe una tarjeta de modelo desde el primer día. Cuatro líneas —para qué sirve, con qué datos se entrenó, qué métrica tiene, qué limitaciones conocidas— escritas cuando aún te acuerdas. En 05-07 verás que es un requisito, no un adorno.

Consejo: fija la semilla aleatoria. Un modelo que da un resultado distinto cada vez que se entrena es imposible de depurar.

Marta ha recibido la factura de Vertex AI del mes: 612 €, cuando el mes anterior fueron 40 €. El equipo no ha entrenado nada nuevo. Enumera las causas más probables por orden de probabilidad, indica qué comando o vista usarías para confirmarlas, y propón tres medidas preventivas.

Lucía quiere predecir, para cada SKU, cuántas unidades se venderán la semana que viene, con el fin de ajustar el pedido a proveedores. Tiene ventas_diarias_sku en BigQuery con cinco años de historia. Decide entre BigQuery ML y Vertex AI justificando la elección, escribe el esqueleto de la solución y responde: ¿endpoint en línea o predicción por lotes, y por qué?

Dani propone entrenar un modelo que decida automáticamente si un pedido es fraudulento y, en caso afirmativo, cancelarlo sin intervención humana. Analiza la propuesta desde tres ángulos: técnico, de negocio y legal. Propón un diseño alternativo.

Solución 1

Causas, por probabilidad:

1. Un endpoint desplegado y olvidado. Es la causa número uno. Un endpoint con dos nodos encendido todo el mes explica por sí solo la mayor parte del salto, sin una sola petición.
2. Una instancia de Workbench sin apagar, especialmente si alguien probó con GPU y no la retiró.
3. Un ajuste de hiperparámetros lanzado sin mirar: 40 pruebas son 40 entrenamientos.
4. Feature Store en línea aprovisionado en una prueba y nunca eliminado.
5. Predicciones por lotes en bucle por un Scheduler mal configurado que dispara cada hora en vez de cada noche.

Cómo confirmarlo:

Y en el informe de facturación exportado a BigQuery (01-04), el desglose que da la respuesta directa:

Medidas preventivas:

1. Alerta de presupuesto sobre la etiqueta centro-coste:analitica al 50 %, 80 % y 100 % del importe esperado (01-04). No evita el gasto, pero lo detecta en días en vez de en un mes.
2. idle-timeout-seconds obligatorio en toda instancia de Workbench, aplicado por política de organización o por revisión al crear.
3. Revisión mensual programada de endpoints y notebooks, con la regla explícita: todo endpoint sin tráfico en 14 días se retira. Se puede automatizar consultando las métricas del endpoint en Cloud Monitoring (06-04).

Solución 2

Elección: BigQuery ML, y con bastante claridad.

Justificación: el dato ya está en BigQuery en la tabla ventas_diarias_sku; el problema es una serie temporal univariante por SKU, un caso que BigQuery ML cubre nativamente con ARIMA_PLUS; la salida es un pedido semanal a proveedores, así que no hay ninguna necesidad de latencia baja; y quien lo va a mantener es Lucía, que trabaja en SQL. Subir esto a Vertex AI añadiría semanas de trabajo y coste sin ninguna ventaja.

Detalles que marcan la diferencia:

• time_series_id_col = 'sku' entrena un modelo por SKU en una sola sentencia. Con 2.400 SKU esto ahorra un proyecto entero.
• holiday_region = 'ES' incorpora los festivos españoles, que en una tienda de montaña importan mucho: Semana Santa y los puentes son picos reales.
• El intervalo de confianza es más útil que la predicción puntual. Para decidir un pedido a proveedor interesa el rango, no el número mágico. Con productos de rotación baja, el intervalo será ancho, y eso es información honesta: el modelo te está diciendo que no sabe.

Endpoint o lotes: lotes, sin discusión. La previsión se necesita una vez por semana para hacer un pedido. Un endpoint 24×7 para responder a una consulta semanal es la definición literal de gasto inútil. Se programa con Cloud Scheduler y Workflows (04-06) los domingos por la noche y escribe en una tabla que Lucía consulta el lunes.

Cautela: los SKU con poco historial o muy estacionales darán previsiones malas. Conviene filtrar los que tengan menos de un año de datos y tratarlos con una regla manual, y validar el modelo comparando su previsión contra las últimas cuatro semanas reales antes de fiarse.

Solución 3

Ángulo técnico. El fraude es un problema de clases extremadamente desequilibradas: quizá 3 pedidos fraudulentos de cada 10.000. Un modelo que diga "nunca hay fraude" acierta el 99,97 %, y es inútil. Además, los datos disponibles casi con seguridad no están etiquetados: nadie ha marcado históricamente qué pedidos fueron fraude, y sin etiquetas no hay aprendizaje supervisado. Y el fraude es adversario: los defraudadores cambian de táctica en cuanto detectan la defensa, de modo que el modelo se degrada por diseño, no por accidente.

Ángulo de negocio. Hay que valorar los dos errores por separado, y no cuestan lo mismo. Un falso negativo cuesta el importe del pedido. Un falso positivo cancela la compra de un cliente legítimo: pierdes el margen, pierdes probablemente al cliente, y te ganas una reseña de una estrella. Con un 0,03 % de fraude real, incluso un modelo bueno generará muchos más falsos positivos que fraudes detectados. El coste esperado de la automatización total es casi seguro negativo.

Ángulo legal. Este es el determinante. El artículo 22 del RGPD regula las decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos o afecten significativamente a una persona. Cancelar el pedido de un cliente automáticamente y acusarle implícitamente de fraude encaja de lleno. Genera obligaciones de información, derecho a obtener intervención humana, a expresar el punto de vista y a impugnar la decisión. A esto se suma el Reglamento Europeo de IA (AI Act), con requisitos de gestión de riesgos, documentación, transparencia y supervisión humana según la clasificación del sistema. Este análisis no sustituye a un dictamen jurídico: la clasificación concreta y las obligaciones aplicables las debe determinar un profesional de compliance o el DPO antes de cualquier implantación.

Diseño alternativo: el modelo puntúa, la persona decide.

Cuatro propiedades que lo hacen viable:

1. Ninguna cancelación es automática. Siempre hay una persona en el bucle, lo que resuelve el problema del artículo 22 y el requisito de supervisión humana.
2. Los umbrales son decisiones de negocio, ajustables según cuánta capacidad de revisión haya. Si hay una persona media jornada, se calibra para que la cola quepa en su jornada.
3. Cada decisión humana genera una etiqueta, que es justamente el dato que hoy no existe. En seis meses habrá un conjunto etiquetado real con el que entrenar en serio.
4. Cada decisión queda registrada con la versión del modelo, la puntuación y el motivo. Eso es lo que se enseña en una auditoría o ante una reclamación.

Y la primera versión de la puntuación no necesita ser un modelo: media docena de reglas —dirección de envío distinta de la de facturación, cuenta creada hace menos de una hora, importe muy por encima de la media, tres intentos de pago fallidos— capturan buena parte del fraude evidente, son explicables al cliente y se implementan en un día. La misma lógica del apartado 15.

Has visto por qué un modelo en un portátil no es un producto, y qué hace falta alrededor para que lo sea: reproducibilidad, escala, servicio, trazabilidad y vigilancia. Esos cinco huecos son exactamente los que rellena una plataforma de ML.

Conoces el ciclo de vida completo —problema, datos, características, entrenamiento, evaluación, despliegue, monitorización, reentrenamiento— y sabes que es un bucle, no una línea: un modelo desplegado y olvidado es un pasivo. Y sabes qué componente de Vertex AI cubre cada etapa, desde Workbench hasta Pipelines, con la nota histórica de que AI Platform y AutoML eran productos separados y hoy todo vive bajo el mismo paraguas.

Has montado el Workbench de Lucía con cuenta de servicio, sin IP pública y con apagado automático, leyendo de las vistas gobernadas del módulo 4 y agregando en BigQuery en lugar de descargar gigabytes. Has creado el conjunto gestionado pedidos-historico apuntando deliberadamente a v_pedidos_analitica y no a la tabla con emails. Has entendido el sesgo entrenamiento/servicio —el error silencioso de calcular la misma característica de dos maneras— y cómo lo resuelve Feature Store, además de cuándo todavía no compensa montarlo.

Sabes lanzar trabajos de entrenamiento personalizados con contenedor versionado, ajustar hiperparámetros con búsqueda bayesiana sin arruinarte, versionar en el Model Registry con alias que permiten promover y revertir en segundos, y elegir entre endpoint en línea y predicción por lotes con un criterio claro: si el resultado no depende de algo que acaba de ocurrir, va por lotes. De ahí salió la decisión DA-002. Y sabes vigilar la deriva sin convertir las alertas en ruido.

Has entrenado tu primer modelo con BigQuery ML en una sentencia SQL, con división temporal, pesos de clase automáticos y explicabilidad activada, y tienes el criterio de cuándo basta con SQL y cuándo hay que subir a Vertex AI. Y tienes los dos interruptores de coste bien identificados: apaga los notebooks, retira los endpoints.

Pero lo que más va a valer de esta lección es la decisión DA-003. AlpinaShop va a poner en producción un recomendador que no es un modelo: unas decenas de líneas de SQL sobre la matriz productos_juntos que calculó Spark, con filtros de soporte, confianza y lift, y con la regla más importante de todas —no recomendar lo que no hay en stock—. Es explicable, cuesta céntimos, está listo esta semana, y cualquier modelo que venga después tendrá que demostrar que lo supera en negocio, no en una métrica de laboratorio.

En 05-02, AutoML, damos el siguiente paso natural: entrenar modelos de verdad sin escribir código. Verás qué hace AutoML por debajo —búsqueda de arquitectura, ingeniería de características y ensamblado—, qué tipos de problema cubre y con cuántos datos mínimos, y lo aplicarás a dos casos de AlpinaShop: predecir la probabilidad de compra de un carrito partiendo de visitas y v_pedidos_analitica, y clasificar las fotos del catálogo con AutoML Vision. Por el camino aprenderás a leer de verdad una matriz de confusión, a entender por qué el umbral de decisión es una decisión de negocio y no técnica, y a detectar las tres trampas que arruinan más proyectos que ninguna otra cosa: la fuga de datos, el desequilibrio de clases y el sobreajuste.

Y llevarás contigo la línea base. Porque a partir de ahora, cada modelo que entrenes tiene un rival al que batir.