El recomendador heurístico de la lección anterior ya está en producción, y funciona. Pero AlpinaShop tiene dos preguntas que el SQL no puede responder.

La primera es de Marta, que lleva la web: de cada cien carritos que se llenan, ¿cuáles van a acabar en compra? Si se supiera con antelación, se podría reservar el descuento de bienvenida para quien está a punto de abandonar en lugar de regalarlo a quien iba a comprar de todas formas. Eso no es un patrón que se lea en una tabla de coocurrencias: depende de una docena de señales que interactúan entre sí.

La segunda es del catálogo: 60 GB de imágenes de producto sin etiquetar. Nadie sabe, mirando el bucket alpinashop-catalogo, cuáles son mochilas, cuáles piolets y cuáles chaquetas, más allá de lo que diga la ficha del producto —que no siempre coincide con la foto que subió el proveedor.

Las dos preguntas necesitan un modelo entrenado. Y ninguna de las tres personas del equipo es ingeniera de machine learning.

AutoML existe exactamente para esto: entrenar modelos de calidad razonable sobre tus propios datos, sin escribir código de modelado, dejando que la plataforma tome las decisiones técnicas. Esta lección va de qué hace por debajo, hasta dónde llega, dónde se queda corto, y —lo que más se descuida— cómo leer los resultados sin engañarse.

1. Qué es AutoML y qué hace realmente por debajo
2. Para quién es y cuáles son sus límites
3. Tipos de problema y requisitos mínimos de datos
4. Caso 1: predecir la compra de un carrito
5. La división temporal: por qué la aleatoria sería trampa
6. Presupuesto de entrenamiento y coste
7. Leer los resultados sin engañarse
8. El umbral de decisión es una decisión de negocio
9. Importancia de características y explicabilidad
10. Caso 2: clasificar las fotos del catálogo
11. Etiquetar bien: el coste que nadie presupuesta
12. Desplegar: endpoint o predicción por lotes
13. Las tres trampas: fuga, desequilibrio y sobreajuste
14. Cuándo AutoML no es la respuesta
15. Sesgo, decisiones automatizadas y marco legal

AutoML no es magia ni un algoritmo concreto. Es la automatización de las tareas que un ingeniero de ML haría a mano, ejecutadas de forma sistemática y con más paciencia de la que tiene una persona.

Cuatro cosas hace por ti:

Ingeniería de características. Detecta el tipo de cada columna, normaliza las numéricas, codifica las categóricas, extrae componentes de las fechas (día de la semana, mes, si es festivo), imputa los valores ausentes y descarta las columnas inútiles —las que tienen un solo valor o las que son un identificador único por fila.

Búsqueda de arquitectura y de algoritmo. Prueba familias distintas de modelos —árboles potenciados, redes neuronales, modelos lineales— y, dentro de cada una, distintas configuraciones. En imagen y texto, además, busca la arquitectura de red mediante neural architecture search.

Ajuste de hiperparámetros. Optimiza tasas de aprendizaje, profundidades, regularización y demás, con el mismo tipo de búsqueda bayesiana que viste en 05-01, pero sin que tengas que declararla.

Ensamblado. El modelo final rara vez es uno solo: suele ser una combinación ponderada de varios, porque combinar modelos diversos casi siempre supera al mejor individual.

Lo que no hace, y conviene tenerlo claro desde el principio:

• No decide qué problema resolver ni qué significa el éxito.
• No consigue datos ni arregla los que están mal.
• No detecta que has metido una columna que filtra el futuro.
• No sabe qué es justo, ni qué consecuencias tiene equivocarse.

Todo eso sigue siendo tuyo. Y es, casualmente, donde está la mayor parte del valor y del riesgo.

AutoML tiene un público muy definido: quien conoce el dominio y los datos pero no la ingeniería de modelos. Lucía es el caso exacto. Sabe qué es una sesión, qué es un carrito abandonado y qué significa cada columna de visitas. No sabe elegir entre XGBoost y una red neuronal, y no le hace falta.

Y una función que casi nunca se menciona pero que es de las más valiosas: AutoML es un excelente detector de problemas mal planteados. Si AutoML, con todo su esfuerzo, no consigue nada mejor que el azar, es muy probable que la señal no esté en los datos, y ningún modelo a medida la va a inventar. Y si AutoML consigue un 99,8 % a la primera, casi seguro que tienes una fuga de datos. En ambos casos te ha ahorrado semanas.

La diferencia entre las dos últimas columnas importa mucho. El mínimo técnico es lo que la plataforma acepta; el mínimo razonable es lo que produce un modelo utilizable. Con 10 imágenes por etiqueta AutoML entrena y te da un número, pero ese modelo no sirve para nada en producción.

Y una regla que vale para todo el módulo: la variedad importa más que la cantidad. Quinientas fotos de mochilas tomadas todas con el mismo fondo blanco y la misma luz enseñan al modelo a reconocer ese fondo, no la mochila. Doscientas fotos variadas —distintos fondos, ángulos, iluminaciones— generalizan mucho mejor.

Comprobación previa obligatoria antes de entrenar nada:

Si pct_positivos es 0,4 %, si sesiones_unicas es menor que filas (hay duplicados) o si sin_importe es la mitad del conjunto, tienes trabajo antes de entrenar. Entrenar primero y descubrirlo después cuesta horas de máquina.

El objetivo, escrito como decisión de negocio y no como problema técnico: estimar la probabilidad de que una sesión con carrito acabe en compra, para decidir a quién se le muestra un incentivo de cierre.

La tabla de partida es ml_sesiones, la que construiste en 05-01 cruzando visitas con v_pedidos_analitica. Vamos a enriquecerla con contexto del cliente y del carrito, cuidando que todo sea información disponible en el instante de la decisión:

El detalle que decide si este modelo sirve o no está en el último JOIN: h.fecha = DATE_SUB(v.fecha, INTERVAL 1 DAY). El historial del cliente se toma del día anterior a la sesión, no de hoy. Si se uniera con el historial actual, cada fila del entrenamiento llevaría información sobre pedidos posteriores a la sesión que se está prediciendo. El modelo aprendería que "los clientes con muchos pedidos compran", lo cual es cierto y también inútil: en producción, en el momento de decidir, ese pedido futuro no existe.

Este tipo de tabla —una foto del estado de cada entidad en cada fecha— se llama tabla histórica de características y es lo que evita casi todas las fugas temporales. Es exactamente lo que un Feature Store guarda por ti (05-01, apartado 7).

Crear el conjunto y lanzar el entrenamiento:

Desde la consola, el flujo pide: columna objetivo (compro), tipo de objetivo (clasificación binaria), columnas a excluir (sesion_id y fecha —la primera es un identificador, la segunda define la división y no debe entrar como característica), método de división, presupuesto y métrica de optimización.

En Python queda más explícito y, sobre todo, reproducible:

Dos elecciones que merecen justificación:

• maximize-au-prc en lugar de la exactitud. Con clases desequilibradas, el área bajo la curva de precisión-exhaustividad refleja lo que interesa —encontrar los positivos— mucho mejor que el porcentaje de aciertos. Volvemos a ello en el apartado 7.
• disable_early_stopping=False: si el modelo deja de mejorar, AutoML para y no te cobra el presupuesto restante. Desactivarlo solo tiene sentido en casos muy concretos.

AutoML divide por defecto en 80 % entrenamiento, 10 % validación y 10 % test, de forma aleatoria. Para el problema de AlpinaShop, eso está mal, y merece entenderse bien porque es el error conceptual más repetido.

Imagina que el 14 de febrero AlpinaShop lanza una campaña y las conversiones se disparan. Con división aleatoria, unas sesiones del 14 de febrero acaban en entrenamiento y otras en test. El modelo, entrenando, ve cómo se comportó ese día concreto y aprende a reconocerlo. Al evaluarse sobre las otras sesiones del mismo día, acierta espectacularmente.

Ese resultado no se reproducirá jamás en producción, porque en producción el modelo predice sobre días que nunca ha visto. La división aleatoria mide "¿sabe interpolar dentro de lo conocido?" cuando la pregunta real es "¿sabe extrapolar a lo desconocido?".

La regla: si el problema tiene dimensión temporal, la división debe ser temporal. Se entrena con el pasado, se valida con el pasado inmediato y se evalúa con el futuro.

Vertex AI acepta esta columna con predefined_split_column_name="conjunto", y los valores deben ser exactamente TRAIN, VALIDATE y TEST.

Hay un efecto secundario que conviene anticipar: las métricas bajarán. Es normal y es bueno. Si con división aleatoria el AUC era 0,91 y con división temporal es 0,83, el 0,83 es el número real. El 0,91 era una ilusión, y descubrirlo ahora es mucho más barato que descubrirlo tras el despliegue.

Un matiz adicional: el periodo de test debe cubrir al menos un ciclo de negocio completo. En una tienda de material de montaña, dos meses de invierno no representan el verano. Si se puede, conviene evaluar también sobre un periodo estacionalmente distinto.

El presupuesto se expresa en nodos-hora y limita cuánto explora AutoML. Se indica en milésimas: budget_milli_node_hours=2000 son 2 nodos-hora.

El precio por nodo-hora varía por tipo de dato y por región y cambia con el tiempo: consúltalo siempre en la documentación oficial vigente. Como orden de magnitud, un entrenamiento tabular de pocas horas se mueve en decenas de euros; uno de imagen con muchas horas puede alcanzar varios cientos.

Tres consejos que ahorran dinero de verdad:

1. Empieza siempre con 1 nodo-hora. Si con ese presupuesto el AUC es 0,52 —o sea, azar—, no lo arregla gastar veinte veces más: el problema está en los datos.
2. Deja la parada anticipada activada. No pagas lo que no se usa.
3. Antes de gastar, compara contra BigQuery ML. Una regresión logística cuesta céntimos y en problemas tabulares sencillos queda sorprendentemente cerca. Si AutoML mejora dos puntos de AUC sobre BigQuery ML, la pregunta legítima es si esos dos puntos valen la diferencia de coste y de opacidad.

Aquí es donde se separa quien usa AutoML de quien lo entiende.

Supongamos el resultado del modelo de carritos sobre el conjunto de test, con 10.000 sesiones de las cuales 1.200 acabaron en compra (12 %):

Las métricas que salen de ahí:

La exactitud es la métrica que más engaña, y con diferencia. En este caso, un modelo que respondiera siempre "no compra" tendría un 88 % de exactitud —más que el nuestro— y sería completamente inútil. Cada vez que veas presumir de exactitud en un problema desequilibrado, pregunta cuál es el porcentaje de la clase mayoritaria.

ROC-AUC y PR-AUC no son intercambiables. El ROC-AUC incorpora los verdaderos negativos, que aquí son 7.910 y abundantísimos, y eso lo infla: un 0,83 suena bien. El PR-AUC solo mira lo que pasa con los positivos, y su 0,51 es una descripción mucho más fiel de la dificultad real. Con clases desequilibradas, mira siempre el PR-AUC.

Y la referencia que nunca hay que olvidar: ¿cuánto daría una regla tonta? Si ordenar las sesiones por importe del carrito ya identificara al 55 % de los compradores, el modelo aporta diez puntos, no sesenta y cinco.

Un clasificador no devuelve "sí" o "no": devuelve una probabilidad entre 0 y 1. Convertirla en decisión requiere un umbral, y ese umbral no lo elige el modelo. Lo eliges tú, y es una decisión económica.

Para AlpinaShop, el incentivo es un descuento del 10 %. Los números por sesión:

• Verdadero positivo: le doy el descuento a quien iba a comprar → pierdo el 10 % del margen innecesariamente. Sobre un carrito medio de 95 €, unos –4 €.
• Falso positivo: le doy el descuento a quien no iba a comprar → si el descuento convence a una parte, gano; si no, no cuesta nada porque no hay venta. Valor esperado ligeramente positivo.
• Falso negativo: no doy el descuento a quien iba a abandonar → pierdo una venta que podría haber recuperado, unos –20 € de margen esperado.
• Verdadero negativo: no doy descuento a quien no iba a comprar → 0 €.

Con esos números, el error caro es el falso negativo, y eso empuja el umbral hacia abajo: conviene ser generoso repartiendo incentivos. La tabla del compromiso:

La forma correcta de elegir es calcular el beneficio esperado de cada umbral con los valores de negocio, no mirar cuál da mejor F1:

Esta consulta convierte una discusión técnica en una tabla que dirección entiende. Y explicita algo que suele quedar implícito: los coeficientes -4, 0,5 y -20 son hipótesis de negocio, no verdades. Escribirlas obliga a discutirlas, que es exactamente lo que hay que hacer.

Una advertencia final sobre el umbral: puede ser distinto por segmento. Para clientes nuevos, donde el valor de captación es mayor, quizá interese un umbral más bajo. Eso ya no es una decisión del modelo, es diseño de producto.

AutoML devuelve dos niveles de explicación, y sirven para cosas distintas.

Importancia global: qué características pesan más en el modelo en conjunto. Para el modelo de carritos, un resultado plausible:

Cómo se lee esta tabla, y cómo no. La importancia es asociación, no causalidad. Que minutos_sesion pese mucho no significa que alargar artificialmente la sesión aumente las compras: significa que quien va a comprar tiende a pasar más tiempo. Confundir ambas cosas produce decisiones de producto absurdas.

Lo que sí hay que hacer con esta tabla es una revisión de sensatez. Si apareciera una característica con importancia 0,80 y las demás a cero, es señal de alarma: probablemente esa columna filtra el resultado. Y si todas las importancias fueran similares y bajas, es señal de que ninguna característica tiene señal real.

Atribuciones locales: por qué el modelo predijo lo que predijo para una fila concreta. Se piden en la petición de predicción con explain en lugar de predict, y devuelven la contribución de cada característica a esa predicción individual. Son imprescindibles cuando hay que justificar una decisión ante una persona, y volverán en 05-07 como parte del checklist de ML responsable.

El segundo problema es distinto en naturaleza: entrada no estructurada, 60 GB de imágenes en alpinashop-catalogo bajo productos/<sku>/original|web|thumb/.

El objetivo: clasificar cada foto en la taxonomía propia de AlpinaShop —mochila, piolet, casco, chaqueta, bota, crampón, cuerda, saco— para detectar fichas con imágenes mal asignadas y para enriquecer los metadatos del catálogo.

Por qué no basta con la Cloud Vision API. La API preentrenada (lección 05-05) reconoce "mochila" perfectamente, pero no distingue una mochila de travesía de 60 litros de una de ataque de 25, y llamará "hacha" a un piolet técnico. AutoML Vision existe precisamente cuando la taxonomía es propia y el vocabulario general no la cubre.

Los datos de entrada se declaran en un CSV de índice en Cloud Storage:

Tres columnas: conjunto, URI de la imagen y etiqueta. Si se omite la primera columna, Vertex AI divide por ti.

Aquí la división sí puede ser aleatoria —no hay dimensión temporal—, pero con una condición crítica: todas las fotos del mismo SKU deben caer en el mismo conjunto. Un producto suele tener cinco o seis fotos casi idénticas; si unas van a entrenamiento y otras a test, el modelo memoriza ese producto concreto y la evaluación miente. La agrupación por entidad es al problema de imagen lo que la división temporal es al tabular.

model_type="CLOUD" produce un modelo optimizado para servirse en Vertex AI. "EDGE" genera una variante exportable (TensorFlow Lite, contenedor) para ejecutarse fuera, más pequeña y algo menos precisa. AlpinaShop no necesita edge: sus imágenes ya están en la nube.

Este apartado es el más aburrido de la lección y el que más proyectos hunde.

Para entrenar AutoML Vision hacen falta imágenes etiquetadas, y las 60 GB de AlpinaShop no lo están. Los números reales de etiquetar:

• 8 categorías × 300 imágenes = 2.400 imágenes que etiquetar.
• A unas 6 segundos por imagen con una buena interfaz, son unas 4 horas de trabajo humano.
• Más el tiempo de acordar la taxonomía, que siempre lleva más de lo previsto.

Y el problema no es el tiempo, es la coherencia. Las preguntas que surgen a la media hora de empezar:

• Una foto donde aparece una mochila con un piolet colgado, ¿qué es?
• Un casco de escalada y uno de esquí, ¿son la misma etiqueta?
• Una foto de detalle de la costura de una chaqueta, ¿es "chaqueta" o se descarta?
• Un pack de cuerda + mosquetones, ¿qué etiqueta lleva?

Si esas decisiones no se escriben antes y no son consistentes, el modelo aprende la incoherencia. Y un modelo entrenado con etiquetas contradictorias no puede superar la calidad de sus etiquetas: es un techo duro.

El protocolo mínimo, que cuesta una tarde y salva el proyecto:

1. Escribir la guía de etiquetado con la definición de cada categoría y al menos un caso límite resuelto por categoría.
2. Etiqueta otros para lo que no encaje. Sin ella, la gente fuerza etiquetas y contamina el conjunto.
3. Doble etiquetado de una muestra: dos personas etiquetan las mismas 200 imágenes. Si coinciden en menos del 90 %, la taxonomía es ambigua y hay que arreglarla antes de seguir.
4. Empezar por las fotos web/, que están normalizadas, antes que por las original/.

Vertex AI ofrece flujos de etiquetado en la consola y servicios de etiquetado gestionado con etiquetadores humanos. Ojo con esto último si las imágenes contienen algo sensible: enviar fotos de clientes a un servicio de etiquetado externo tiene implicaciones de privacidad que hay que valorar antes. Las fotos de catálogo de AlpinaShop no las tienen; las que suben los clientes en las opiniones, sí.

La misma disyuntiva de 05-01, y la respuesta vuelve a ser la misma por la misma razón.

Para el modelo de imagen, la tarea es clasificar 60 GB de fotos una vez, y después solo las nuevas que entren. Eso es un caso de libro de predicción por lotes:

Y los resultados se cargan en el dataset gobernado para cruzarlos con el catálogo:

Esta consulta es el producto real de todo el trabajo. No es un modelo desplegado: es una lista de fichas revisables por una persona, ordenada por confianza. Un modelo que produce una lista de trabajo priorizada aporta más valor con menos riesgo que uno que actúa solo.

Para las fotos nuevas, la clasificación se dispara desde el topic imagenes-subidas de Pub/Sub, con la implementación que llegará en 06-03 con Cloud Functions.

Fuga de datos (data leakage). Una característica contiene información que en producción no estará disponible en el momento de predecir. Síntoma inconfundible: métricas demasiado buenas. En AlpinaShop, las candidatas son metodo_pago (solo existe si hubo compra), direccion_envio_confirmada, codigo_descuento_aplicado y cualquier historial de cliente calculado a fecha de hoy en lugar de a fecha de la sesión. La prueba de olfato es siempre la misma pregunta: ¿este dato existía y era conocido en el instante exacto de la decisión? Si la respuesta es "más o menos", es que no.

Desequilibrio de clases. Cuando una clase es rara, el modelo aprende a ignorarla. Con un 12 % de conversión el problema es moderado; con un 0,3 % de fraude es grave. Remedios: elegir PR-AUC como objetivo, ponderar clases, y en casos extremos submuestrear la clase mayoritaria —nunca el conjunto de test, que debe conservar la proporción real para que las métricas signifiquen algo—. Y a veces el remedio correcto es reformular: en vez de clasificar, ordenar por riesgo y revisar los N primeros.

Sobreajuste. El modelo memoriza en lugar de generalizar. Síntoma: excelente en entrenamiento, mediocre en test. AutoML lo controla bastante bien con regularización y parada anticipada, pero no puede protegerte de dos causas que dependen de ti: pocos datos para la complejidad del problema, y filtración entre conjuntos —el mismo SKU o el mismo cliente en entrenamiento y en test—.

AutoML no es la respuesta cuando:

• El problema es genérico. "¿Esta imagen contiene una persona?" o "¿este texto es positivo?" los resuelven las APIs preentrenadas (05-04, 05-05) sin datos, sin entrenamiento y por céntimos.
• No tienes datos etiquetados y no vas a invertir en etiquetarlos. Sin etiquetas no hay AutoML.
• El dato es tabular y ya vive en BigQuery. Prueba BigQuery ML primero: es horas contra días y céntimos contra decenas de euros.
• Necesitas una arquitectura o una función de pérdida propias. Es el caso del recomendador two-tower de 05-03.
• Una heurística ya resuelve el 80 %. La lección DA-003 de 05-01 sigue vigente.
• Necesitas ejecutar el modelo fuera de la nube con requisitos estrictos. El modo EDGE ayuda, pero un modelo propio te da más control sobre tamaño y latencia.

Los dos modelos de esta lección tienen perfiles de riesgo muy distintos, y verlo en paralelo es la mejor forma de entender el marco.

El modelo de imagen es de bajo riesgo. Clasifica objetos inanimados. El peor error posible es etiquetar un piolet como hacha, y el remedio es que una persona lo corrija en una lista de revisión.

El modelo de carritos sí trata datos personales y sí afecta a personas. Y ahí hay que pensar antes de desplegar:

Sesgo. El modelo aprende de lo que pasó. Si históricamente los clientes que entran desde móvil convierten menos —porque la web móvil es peor—, el modelo aprenderá a no ofrecerles incentivos, con lo que convertirán todavía menos, con lo que el modelo se reafirmará. Es un bucle de retroalimentación: el modelo no describe la realidad, la fabrica. La forma de detectarlo es medir el rendimiento por segmento —dispositivo, canal, país, cliente nuevo o recurrente— y no solo en agregado. Un AUC global de 0,83 puede esconder un 0,86 en escritorio y un 0,61 en móvil.

Datos personales y RGPD. Aunque se entrene sobre v_pedidos_analitica con el cliente seudonimizado, la seudonimización no es anonimización: sigue siendo dato personal a efectos del RGPD y siguen aplicando la base legal, la minimización, la limitación de la finalidad y los plazos de conservación. Aplican también los derechos de acceso, oposición y supresión, lo que implica poder retirar los datos de un cliente del conjunto de entrenamiento del próximo ciclo.

Decisiones automatizadas. Mostrar u ocultar un descuento comercial no es lo mismo que denegar un crédito. Pero la frontera del artículo 22 del RGPD —decisiones basadas únicamente en tratamiento automatizado con efectos significativos— no siempre es obvia, y una diferenciación sistemática de precios entre clientes puede acercarse más de lo que parece.

AI Act europeo. El Reglamento de IA clasifica los sistemas por nivel de riesgo, y de esa clasificación dependen obligaciones de gestión de riesgos, calidad de datos, documentación técnica, registro, transparencia y supervisión humana. Un sistema de recomendación comercial suele situarse en un nivel bajo, pero la clasificación depende del uso concreto, y el uso puede desplazarse con el tiempo sin que nadie lo revise.

Recomendación expresa. Antes de desplegar el modelo de carritos, un profesional de compliance o el DPO debe determinar la base legal del tratamiento, si el uso previsto constituye decisión automatizada del artículo 22, qué información hay que dar a los clientes, el plazo de conservación del conjunto de entrenamiento, y la clasificación del sistema bajo el AI Act con las obligaciones asociadas. Esta lección describe controles técnicos y no constituye asesoramiento jurídico. Todos los datos son ficticios.

Y una medida técnica que vale más que muchas declaraciones: evaluar por segmento y publicar esa tabla junto con la métrica global. Si nadie mira el rendimiento por grupo, el sesgo no se detecta.

Fiarse de la exactitud. Con clases desequilibradas es la métrica que más engaña. Mira PR-AUC, precisión y exhaustividad, y compáralas siempre contra el porcentaje de la clase mayoritaria.

Dejar la división aleatoria en un problema temporal. Produce métricas infladas que no se reproducen en producción.

Que las fotos del mismo producto caigan en conjuntos distintos. Filtración pura: el modelo memoriza el producto y la evaluación miente. Agrupa por entidad.

Meter el identificador como característica. sesion_id o sku como columna hace que el modelo memorice. AutoML suele descartar columnas de alta cardinalidad, pero no confíes en ello: exclúyelas tú.

Aceptar el umbral 0,5 sin pensar. Es un valor por defecto, no una recomendación. El umbral se calcula con los costes de cada tipo de error.

Etiquetar sin guía escrita. Etiquetas incoherentes ponen un techo a la calidad del modelo que ningún presupuesto de entrenamiento levanta.

Gastar el presupuesto grande a la primera. Una nodo-hora te dice si hay señal. Si no la hay, veinte tampoco la encontrarán.

Consejo: guarda las predicciones del test con su etiqueta real. Es lo que permite recalcular umbrales, analizar por segmento y comparar contra el siguiente modelo sin volver a entrenar.

Consejo: pon el resultado en manos de una persona antes que en manos de un proceso. La lista de fichas con imagen sospechosa aporta valor desde el primer día y sin riesgo.

Lucía entrena con AutoML un modelo para predecir si un pedido será devuelto. Obtiene una exactitud del 94,2 % y quiere desplegarlo. Sabes que el 6 % de los pedidos de AlpinaShop se devuelven. ¿Qué le preguntas antes de dar el visto bueno, y qué métricas pides?

Diseña el conjunto de entrenamiento para un modelo que prediga, en el momento de finalizar un pedido, si ese pedido llegará tarde (más de 5 días). Enumera las características que usarías, marca las que serían fuga de datos y explica cómo dividirías train/validación/test.

El modelo de clasificación de imágenes obtiene un 91 % de exactitud global. Al desglosar por categoría, crampón tiene un 34 % de exhaustividad y mochila un 98 %. Diagnostica las causas posibles y propón un plan de tres acciones.

Solución 1

La pregunta clave, antes que ninguna otra: ¿qué exactitud tendría un modelo que dijera siempre "no se devuelve"? Respuesta: 94 %. El modelo de Lucía aporta 0,2 puntos sobre no hacer nada. Con toda probabilidad ha aprendido a decir "no" casi siempre.

Métricas que hay que pedir:

1. Matriz de confusión completa sobre el test. Si los verdaderos positivos son casi cero, el diagnóstico está confirmado.
2. Precisión y exhaustividad de la clase "devuelto", que es la única que interesa. La exactitud global es irrelevante aquí.
3. PR-AUC, no ROC-AUC, por el desequilibrio 94/6.
4. Comparación con una línea base: ¿qué se consigue con la regla "categoría textil + talla en el extremo del rango"? Muchas devoluciones de ropa técnica son por talla, y una regla simple puede capturar buena parte.

Preguntas sobre los datos:

• ¿Qué columnas entraron? Si aparece motivo_devolucion, fecha_devolucion o estado_final, hay fuga y la exactitud no significa nada.
• ¿Cómo se dividió? Si fue aleatoria y hay estacionalidad —y en devoluciones la hay, con el pico de enero—, las métricas están infladas.
• ¿Cuántas devoluciones hay en el test? Con 6 % de 2.000 filas son 120 casos, un número pequeño para estimar nada con precisión.

Y la pregunta de negocio que lo enmarca todo: ¿qué se va a hacer con la predicción? Si es avisar al cliente de que revise la talla antes de confirmar, un modelo con exhaustividad moderada ya aporta. Si es bloquear pedidos, no se despliega: un falso positivo es perder una venta legítima y un cliente enfadado.

Recomendación: no desplegar. Reentrenar optimizando PR-AUC con auto_class_weights, auditar las columnas, dividir temporalmente y volver a evaluar contra la línea base.

Solución 2

Objetivo: clasificación binaria llego_tarde (entrega > 5 días naturales), decidida en el instante de confirmar el pedido.

Características válidas (todas conocidas al confirmar):

Fuga de datos — características que NO pueden entrar:

La última merece detenerse: la característica es válida, el cálculo es el que filtra. Debe ser una ventana móvil de los 30 días anteriores a la fecha del pedido, materializada en una tabla histórica diaria, exactamente como el hist_cliente_diario del apartado 4.

División: temporal, obligatoriamente. La logística es estacional en el peor sentido: la campaña de Navidad concentra los retrasos. Con división aleatoria, el modelo vería pedidos de diciembre en entrenamiento y aprendería el patrón de ese diciembre concreto.

Cautela importante sobre el periodo de test: si TEST cae íntegro en campaña de Navidad, las métricas serán pesimistas y no representativas del resto del año. Lo correcto es evaluar en dos periodos —uno de campaña y uno normal— y mirar ambos. Una métrica única sobre un periodo atípico es una métrica engañosa.

Nota final: fecha_entrega IS NOT NULL excluye los pedidos aún en tránsito. Es correcto para entrenar, pero introduce un sesgo si los pedidos muy retrasados tardan tanto que quedan fuera de la ventana. Conviene comprobar cuántos hay.

Solución 3

Diagnóstico. Las cuatro causas, por probabilidad:

1. Pocos ejemplos de crampón (la más probable). Es un producto de nicho: si hay 40 fotos de crampones frente a 600 de mochilas, el modelo apenas ha visto la clase. Además, la exactitud global del 91 % está dominada por las clases numerosas, así que el fallo se esconde.

2. Confusión con clases visualmente próximas. Un crampón y unos herrajes de piolet comparten metal, puntas y correas. Hay que mirar la matriz de confusión por clase para ver adónde van los errores: si el 50 % de los crampones se clasifican como "piolet", el problema es discriminación entre clases similares, no falta de datos.

3. Fotos poco representativas. Si los crampones se fotografían siempre sobre fondo blanco y desde arriba, y en test aparecen montados sobre una bota, el modelo no reconoce el objeto en contexto.

4. Etiquetado incoherente. ¿Un pack de crampón + funda es "crampón"? ¿Y una foto de la bota con crampón puesto? Si esas decisiones no se tomaron por escrito, hay ruido en la etiqueta.

Plan de tres acciones, en orden:

Acción 1 — Equilibrar y ampliar crampón. Subir de 40 a al menos 200 imágenes, y con variedad deliberada: distintos modelos, fondos, ángulos, montados y sueltos, con y sin funda. Si no hay 200 fotos propias, se pueden usar todas las variantes disponibles del catálogo (original, web, thumb cuentan como fotos distintas solo si difieren de verdad; si son la misma imagen reescalada, no aportan nada). Es la acción con mayor retorno.

Acción 2 — Aclarar la taxonomía. Si la matriz de confusión muestra que crampones y piolets se mezclan, hay dos salidas: fusionar en una etiqueta material_progresion_hielo si la distinción no aporta valor de negocio, o separar mejor con una guía explícita y ejemplos de cada caso límite. Aquí, la decisión correcta depende de para qué se usa la clasificación en la tienda, no del modelo.

Acción 3 — Cambiar la métrica de seguimiento y el uso. Sustituir la exactitud global por la exhaustividad media por clase (macro), que trata igual a la categoría rara y a la mayoritaria, y publicar siempre la tabla por clase. Y mientras tanto, usar el modelo con umbral de confianza: aceptar automáticamente las predicciones por encima de 0,90 y enviar el resto a revisión humana. Con eso, la clase mala deja de ser un problema de producción y se convierte en una cola de trabajo corta, mientras se recogen más ejemplos —que además vienen ya etiquetados por el revisor, alimentando la Acción 1.

Lo que NO hay que hacer: subir el presupuesto de entrenamiento. El problema son los datos, no el tiempo de cómputo, y gastar más nodos-hora sobre 40 imágenes no crea información que no existe.

Has visto qué hace AutoML por debajo —ingeniería de características, búsqueda de arquitectura, ajuste de hiperparámetros y ensamblado— y, sobre todo, qué no hace: no elige el problema, no consigue datos, no detecta que has metido una columna del futuro y no sabe qué consecuencias tiene equivocarse. Eso sigue siendo trabajo humano, y es donde está el valor.

Conoces los tipos de problema soportados y la diferencia entre el mínimo técnico y el mínimo razonable de datos, con la regla de que la variedad importa más que la cantidad.

Has construido el caso tabular de AlpinaShop —predecir la conversión de un carrito— cuidando lo único que de verdad decide el resultado: que cada característica estuviera disponible en el instante de la decisión, uniendo el historial del cliente con el día anterior y no con hoy. Y has entendido por qué la división temporal es obligatoria cuando hay tiempo de por medio, y por qué las métricas bajan al aplicarla: porque las anteriores eran mentira.

Sabes leer una matriz de confusión y ya no te fías de la exactitud: con un 12 % de conversión, decir "nadie compra" da un 88 %. Distingues ROC-AUC de PR-AUC y sabes cuál mirar cuando las clases están desequilibradas. Y has convertido la elección del umbral en lo que realmente es: una tabla de beneficio esperado con los costes de cada tipo de error, discutible por dirección y no por el equipo técnico. Sabes leer la importancia de características como asociación y no como causalidad, y usarla como revisión de sensatez.

Has aplicado AutoML Vision a las 60 GB del catálogo, entendiendo por qué la API preentrenada no basta cuando la taxonomía es propia, por qué todas las fotos de un SKU deben caer en el mismo conjunto, y qué cuesta de verdad etiquetar bien: no las horas, sino la coherencia. Y el resultado que has puesto en producción no es un modelo que decide solo, sino una lista priorizada de fichas sospechosas que revisa una persona —más valor y menos riesgo.

Tienes identificadas las tres trampas —fuga, desequilibrio y sobreajuste— con su síntoma y su remedio, y la tabla que decide entre API preentrenada, BigQuery ML, AutoML y entrenamiento personalizado. Y tienes claro el marco de responsabilidad: medir el rendimiento por segmento para detectar sesgo antes de que el bucle de retroalimentación lo consolide, tratar la seudonimización como lo que es —dato personal—, y pasar por compliance antes de desplegar cualquier modelo que afecte a personas, con el RGPD y el AI Act sobre la mesa.

Pero AutoML tiene un techo, y AlpinaShop está a punto de tocarlo. El recomendador que quiere Marta —que aprenda a la vez cómo son los clientes y cómo son los productos, y que sepa colocarlos en el mismo espacio para medir afinidad— no es un problema de clasificación tabular. No hay una columna objetivo que predecir: hay que aprender una representación. Eso requiere una arquitectura concreta, una función de pérdida concreta y control sobre cómo se leen los datos.

En 05-03, TensorFlow en GCP, bajamos al código. Verás lo mínimo de TensorFlow y Keras para seguir sin ser experto, construirás el recomendador de AlpinaShop con embeddings de cliente y de producto siguiendo la intuición del two-tower, aprenderás a leer eficientemente desde Cloud Storage con tf.data y TFRecord, empaquetarás el entrenamiento para Vertex AI eligiendo entre CPU, GPU y TPU con criterio, usarás checkpoints para sobrevivir a las VMs Spot, seguirás el entrenamiento con TensorBoard gestionado y Experiments, y acabarás guardando un SavedModel en el Model Registry listo para servir.

Y seguirás teniendo que batir a un SQL de treinta líneas.