Caso práctico I (Bloque I — Deep Learning) — Hackathon de HPO: dirigir a la IA y responder por lo que construye

Asignatura: Deep Learning para Business Analytics — Comillas (ICADE). Profesor: Eduardo C. Garrido-Merchán · ecgarrido@comillas.edu. Curso: 2026–2027. Bloque: I — Deep Learning (Temas 0–3, semanas 1–7). Modalidad: dos sesiones. La sesión A son 100 minutos de trabajo en el aula con IA permitida y dudas al profesor permitidas. La sesión B, en la clase siguiente, son los 30 primeros minutos: examen escrito y conceptual sobre lo que hicisteis, con los ordenadores cerrados y sin IA. Las cinco preguntas están publicadas en el §8. No hay entrega en Moodle: el código se queda con vosotros y el profesor lo revisa en pantalla al cierre de la sesión A. Agrupación: sesión A en grupos de tres, formados para este caso y sin relación con los grupos del proyecto final; el examen de la sesión B es individual. Peso: caso práctico evaluado con la rúbrica del §10.

1. Contexto de negocio

La mayoría de los problemas de analítica de una empresa no llegan como imágenes ni como texto: llegan como una tabla. Filas que son clientes, préstamos, empleados, pisos o transacciones; columnas que son variables numéricas y categóricas; y una columna objetivo que hay que predecir. ¿Se dará de baja este cliente? ¿Impagará este préstamo? ¿Cuánto vale este piso? Este es el pan de cada día de un equipo de Business Analytics.

El reflejo del sector para datos tabulares ha sido siempre el modelo clásico: regresión logística, árboles, gradient boosting (XGBoost, LightGBM). La dirección os hace dos preguntas: ¿merece la pena afinar una red neuronal para un problema tabular? y, si la usamos, ¿cómo se elige su configuración sin ir a ciegas? Una red tiene decenas de hiperparámetros (profundidad, anchura, tasa de aprendizaje, dropout, weight decay, tamaño de batch, optimizador, early stopping) y la distancia entre una configuración mediocre y una buena es enorme. La disciplina que convierte ese caos en método se llama optimización de hiperparámetros (HPO).

Hay una segunda capa, y es la que estructura el caso. En 2026 el código de este caso lo escribe una IA en cinco minutos. Lo que una empresa os paga es entender qué se ha construido y responder por ello delante de un comité que no lee código: qué se buscó, qué salió, qué significa y si conviene llevarlo a producción. El caso reproduce esa situación literalmente: la IA construye en la sesión A, vosotros explicáis en la B.

2. Objetivo

Dirigir a una IA para que construya una red neuronal (MLP) sobre un problema tabular real y una búsqueda de hiperparámetros sistemática; compararla contra un baseline clásico honesto; y después, en un examen a mano y con el ordenador cerrado, explicar qué hiperparámetros se buscaron y qué controla cada uno, qué dicen los valores que salieron, cómo era la red, qué la regularizaba y en qué consistían los datos.

El examen no pide código ni cuentas: pide entender. La nota vive casi entera ahí. Un grupo que gane el leaderboard y no sepa explicar qué hace el dropout que puso suspende el caso.

3. Estructura del caso: dos sesiones

Sesión A — el hackathon (100 minutos de trabajo, la clase completa).

IA permitida y fomentada durante toda la sesión. El profesor responde dudas de contenido, no solo de entorno: preguntad todo lo que queráis, porque esta es la única sesión en la que hay red.

Entre sesiones — estudio libre. Tenéis el código, el log y los días que haya hasta la clase siguiente. Estudiadlo como queráis, con IA incluida. El §6 dice exactamente qué hay que dominar.

Sesión B — el examen (primeros 30 minutos de la clase siguiente). Ordenadores cerrados y guardados, sin apuntes, sin IA. Cinco preguntas conceptuales, 10 puntos, 30 minutos, publicadas íntegras en el §8 desde el primer día. No se pide escribir código ni hacer cuentas: se pregunta qué elegisteis, qué significa lo que salió y por qué. Terminado el examen, la clase continúa con el temario normal.

4. Datos y métrica

La métrica es la misma para toda la clase: AUC-ROC sobre validación durante la búsqueda, y AUC-ROC sobre test una única vez al cierre de la sesión A. Se usa AUC y no accuracy porque las cuatro tablas de abajo están desequilibradas y un clasificador que diga siempre “no” acierta mucho sin predecir nada.

El dataset lo elige cada grupo, entre estas cuatro opciones, en los primeros cinco minutos de la sesión A. Los cuatro son tabulares, de clasificación binaria, de dominio empresarial, de descarga libre sin cuenta ni registro y de tamaño cómodo en un portátil. Los cuatro tienen su propia trampa, y esa trampa es exactamente la pregunta 5(c) del examen. Elegid uno y comprometeos con él: cambiar de tabla a mitad de sesión es tirar el presupuesto de trials.

Opción A — Telco Customer Churn. Una fila por cliente de una operadora de telecomunicaciones, con su antigüedad, su cargo mensual, su tipo de contrato y los servicios que tiene contratados. Es la tabla sobre la que está hecha la demo del profesor del §13, así que es la opción de menor fricción. Licencia CC0. Descarga directa: https://raw.githubusercontent.com/IBM/telco-customer-churn-on-icp4d/master/data/Telco-Customer-Churn.csv (también en https://www.kaggle.com/datasets/blastchar/telco-customer-churn). La trampa: TotalCharges llega como texto porque once clientes nuevos tienen la celda en blanco, de modo que pd.to_numeric(..., errors="coerce") la convierte y deja once NaN que hay que imputar o eliminar.

Opción B — Bank Marketing. Una fila por llamada de una campaña telefónica de un banco portugués, con datos del contactado, el historial de la campaña y cinco indicadores macroeconómicos del mes. Fichero bank-additional/bank-additional-full.csv dentro de https://archive.ics.uci.edu/static/public/222/bank+marketing.zip (zip anidado, y el CSV usa ; como separador). Licencia CC BY 4.0. La trampa es la mejor de las cuatro: la columna duration, la duración de la llamada en segundos, es una fuga de información. Solo se conoce después de colgar, y si dura cero segundos la respuesta es “no” por construcción; la propia documentación de UCI dice que hay que descartarla para tener un modelo realista. Un grupo que la deje dentro verá un AUC altísimo que no significa nada, y explicarlo vale la pregunta 5(c) entera. Trampa secundaria: los ausentes no vienen como NaN sino como la categoría unknown (8.597 filas solo en default), y con un 11 % de positivos es la tabla más desequilibrada del cuarteto.

Opción C — Adult / Census Income. Una fila por persona censada en Estados Unidos en 1994, con edad, nivel educativo, ocupación, estado civil y horas trabajadas. Ficheros adult.data y adult.test dentro de https://archive.ics.uci.edu/static/public/2/adult.zip; vienen sin cabecera, así que los nombres de columna hay que ponerlos a mano desde adult.names. Licencia CC BY 4.0. Las trampas son tres y con una explicada basta: los ausentes están codificados como ? en workclass (2.799), occupation (2.809) y native-country (857); fnlwgt es el peso muestral de la encuesta, no un atributo de la persona, y meterlo como predictora no tiene sentido; education y education-num son la misma variable dos veces, una como texto y otra como número. Además, las etiquetas de adult.test traen un punto final (>50K.) y su primera línea es basura, de modo que unir los dos ficheros sin limpiar produce cuatro clases en lugar de dos.

Opción D — Default of Credit Card Clients. Una fila por titular de tarjeta de un banco taiwanés en 2005, con su límite de crédito, seis meses de estado de pago, seis de facturación y seis de importes pagados. Fichero default of credit card clients.xls dentro de https://archive.ics.uci.edu/static/public/350/default+of+credit+card+clients.zip. Licencia CC BY 4.0. Es un Excel con dos filas de cabecera, así que se lee con pd.read_excel(..., header=1), y la columna ID hay que tirarla. La trampa: aquí todo llega como número, pero no todo es numérico. SEX, EDUCATION, MARRIAGE y los seis PAY_* son códigos categóricos, y escalarlos como si fueran continuos le dice a la red que “casado” está a media distancia entre dos cosas que no forman una escala. Encima EDUCATION trae los códigos 0, 5 y 6, que la documentación no define, y MARRIAGE un 0 igualmente indocumentado: categorías fantasma que hay que decidir qué hacer con ellas.

Partición: la que queráis. Aquí no hay código que copiar. Lo único que se exige es que sea honesta y que sepáis defenderla en la pregunta 5(b):

• Tres bloques disjuntos —entrenamiento, validación y test— o, si preferís, validación cruzada sobre el bloque de entrenamiento con un test apartado desde el principio. Lo que no vale es elegir la configuración mirando el mismo conjunto con el que después publicáis el número.
• Estratificada por la clase, porque las cuatro tablas están desequilibradas y una partición ciega puede dejaros un test con una proporción de positivos distinta a la del entrenamiento.
• Con semilla explícita, para que el cuaderno se reproduzca:

import numpy as np, random, torch
SEED = 20262027
random.seed(SEED); np.random.seed(SEED); torch.manual_seed(SEED)

• El test se mira una sola vez, al cierre de la sesión A, con la configuración ya congelada.

Un 60 / 20 / 20 estratificado es una elección perfectamente razonable y es la que usa la demo del profesor. Si preferís 70 / 15 / 15, o 5-fold sobre un 80 % con el 20 % restante apartado como test, adelante: lo que se puntúa en el examen es que sepáis decir por qué elegisteis eso y para qué sirve cada parte.

5. Sesión A — Construcción, HPO y entrega (100 min)

Con 100 minutos hay margen para hacer las cosas bien y, sobre todo, para entenderlas mientras se hacen. El cierre es firme: pasado el minuto 110 no se acepta código.

• 5.1 Preprocesado y baseline. One-hot de las categóricas, escalado de las numéricas, y el tratamiento que decidáis para los valores ausentes y para la trampa concreta de vuestra tabla. Un baseline clásico honesto: regresión logística y un gradient boosting con hiperparámetros razonables. Reportad su AUC de validación y de test.

• 5.2 MLP en PyTorch o Keras. Capas densas, activación ReLU o GELU, al menos una técnica de regularización (dropout, weight decay, batch/layer norm), early stopping sobre validación. Curvas de entrenamiento y validación de la configuración ganadora.

• 5.3 Búsqueda de hiperparámetros: cuatro, elegidos por vosotros. El requisito es un espacio explícito sobre exactamente cuatro hiperparámetros, escogidos de esta lista y con su rango escrito: tasa de aprendizaje, número de capas, anchura, dropout, weight decay, tamaño de batch, optimizador. Cuatro es el número: suficiente para que la búsqueda tenga sentido y pequeño para que en el examen sepáis defender cada uno. La combinación por defecto, si no queréis pensarla, es tasa de aprendizaje, anchura, dropout y weight decay; el resto se deja fijo y en el examen habrá que decir con qué criterio.

  La estrategia mínima es random search. Podéis además lanzar una búsqueda bayesiana (Optuna, TPESampler) sobre el mismo espacio y comparar las dos; el §5.8 lo puntúa como bonus. Mínimo 30 configuraciones registradas, y la elección se hace SIEMPRE con validación.

  Tenéis en casos/demo_hpo/ una demo ejecutada del profesor sobre la opción A (Telco), con estos cuatro hiperparámetros y las dos estrategias, con sus figuras y sus CSV. Miradla antes de la sesión A: la mecánica es idéntica sobre cualquiera de las cuatro tablas, solo cambia el preprocesado.

• 5.4 Log de la búsqueda. Un CSV, busqueda.csv, con una fila por configuración probada: trial, una columna por cada uno de vuestros cuatro hiperparámetros, epochs_ejecutadas y auc_val. Si comparáis dos estrategias, añadid una columna metodo. Este fichero es la materia prima de la pregunta 2 del examen.

• 5.5 Análisis de sensibilidad. Al menos una curva de AUC de validación frente a un hiperparámetro, con los otros tres congelados en sus valores ganadores. Es lo que convierte el log en una explicación, y es de donde saldrán vuestras respuestas de las preguntas 1 y 2.

• 5.6 Entended lo que estáis construyendo mientras lo construís. Cada vez que la IA os entregue un bloque, pedidle que os explique qué hace cada decisión antes de ejecutarlo, y preguntadle al profesor lo que no quede claro. Tened el §8 al lado: las cinco preguntas del examen están publicadas y son exactamente la lista de lo que hay que sacar de esta sesión.

• 5.7 Cierre y visto bueno (últimos 10 min). Congelad la mejor configuración según validación, reentrenad si vuestro protocolo lo requiere, y solo entonces evaluad el test, una única vez. No hay entrega en Moodle: el profesor pasa por cada grupo en estos diez minutos y mira la pantalla. Tened a la vista, en el cuaderno o en la carpeta del grupo:

  1. El cuaderno ejecutado y con los outputs visibles (.ipynb o el .py más su log). Debe correr de principio a fin sin intervención manual, con las semillas fijadas.
  2. busqueda.csv, el log completo del §5.4.
  3. La configuración ganadora con su auc_val, su auc_test y el número de trials, en una celda o en un resultado.txt.
  4. prompts.md: los prompts que usasteis, en orden, tal cual.

  Guardaos la carpeta: es vuestro material de estudio para la sesión B y lo único que tendréis entre las dos clases.

• 5.8 Bonus (opcionales, hasta 1 punto sobre la nota del caso). Se puntúan solo si lo obligatorio está completo y si sabéis defenderlos en el examen; un bonus que no sepáis explicar resta credibilidad al resto.

  1. Más de cuatro hiperparámetros (0,25). Ampliad el espacio a cinco, seis o los siete de la lista. En el examen tendréis que explicar qué controla cada uno de los que añadisteis, así que añadid solo los que entendáis.
  2. Búsqueda bayesiana contra random search (0,5). El mismo espacio, el mismo presupuesto de trials, la misma partición, y una figura de mejor AUC encontrado hasta el trial t para las dos estrategias. Lo que se valora es la lectura: en un espacio de cuatro dimensiones y 30 trials la diferencia puede ser pequeña, y decir eso con honestidad puntúa más que inventarse una victoria. Recordad que las primeras evaluaciones del TPE son aleatorias por diseño, así que antes de ese punto los dos métodos son lo mismo.
  3. Una CNN sobre un dataset sencillo de imágenes (0,5). La misma disciplina de HPO, cuatro hiperparámetros, aplicada a una red convolucional sobre digits de scikit-learn (1.797 imágenes de 8×8, sin descarga), MNIST o Fashion-MNIST. Sirven como hiperparámetros el número de canales de la primera convolución, la tasa de aprendizaje, el dropout de la cabeza densa y el weight decay. Es un bloque aparte del trabajo tabular y no un sustituto: la tabla que elegisteis en el §4 sigue siendo obligatoria. En casos/demo_hpo/ hay una versión ejecutada de este bonus.

El profesor mantiene un leaderboard en la pizarra con el AUC de validación de cada grupo, en una columna por dataset, actualizado en vivo. Solo se comparan entre sí los grupos que hayan elegido la misma tabla: un AUC de 0,79 en Bank Marketing y uno de 0,85 en Telco no miden lo mismo. Sirve de incentivo y pesa cero en la nota: lo que puntúa es el §10. Lo que hayáis construido al cierre es lo que tendréis que defender a mano en la sesión B.

6. Entre sesiones — qué hay que dominar

Estudiad como queráis, con IA incluida: nadie os va a preguntar cómo estudiasteis. Aviso, y va en serio: memorizar una respuesta redactada por una IA no funciona aquí, porque las preguntas van sobre vuestras decisiones y vuestros resultados, y porque todas piden mecanismo, no definición. La diferencia entre un aprobado y un sobresaliente es si sabéis decir qué le pasa al modelo cuando movéis algo.

Esta es la lista, y se corresponde una a una con las cinco preguntas del §8:

• Vuestros cuatro hiperparámetros. Cuáles son y, para cada uno, qué controla dentro de la red o del entrenamiento: qué pasa si sube y qué pasa si baja. Y qué dejasteis fijo, con qué criterio.
• Los valores que salieron. Los órdenes de magnitud de la configuración ganadora y, sobre todo, qué os dicen sobre este dataset. Qué configuraciones fueron mal y por qué. Si la red ganó al baseline clásico o no, con el número aproximado delante.
• La arquitectura. Cuántas capas, de qué anchura, qué activación, qué salida. Qué habría pasado con una red mucho más grande: sobre el ajuste, sobre la generalización y sobre el tiempo de búsqueda. Y qué pasa si se queda corta.
• La regularización. Cuál usasteis, qué le impide hacer al modelo, por qué eso ayuda con filas que no ha visto, y qué ocurre si se pasa de frenada.
• Los datos. Cuál de las cuatro tablas elegisteis y por qué, qué es una fila, qué columnas hay, qué se predice, cómo lo partisteis y para qué sirve cada parte, y qué trampa de esa tabla hubo que tratar antes de entrenar.

No hace falta memorizar cifras exactas ni líneas de código. Hace falta poder explicárselo a alguien que no programa.

7. Sesión B — El examen del caso (30 min)

Primeros 30 minutos de la clase siguiente. Ordenadores cerrados y guardados. Se responde a mano, en solitario, sin apuntes, sin IA y sin el log delante. Este examen es el entregable evaluado del caso.

Cinco preguntas, 10 puntos, publicadas íntegras en el §8 desde el primer día. No hay preguntas sorpresa, no se pide escribir código, no se pide hacer cuentas y no hacen falta cifras exactas: los números que se piden son los órdenes de magnitud que recordéis. Todas preguntan por vuestras decisiones y vuestros resultados, así que no hay nada que se pueda traer escrito de casa: lo que se puede traer es haber entendido lo que hicisteis.

Las respuestas son breves. Se valora la precisión conceptual, no la extensión: media cara bien escrita puntúa más que dos caras de relleno.

8. La hoja del examen — las cinco preguntas

Esto es exactamente lo que se reparte en la sesión B. Los tiempos orientativos van entre paréntesis.

Pregunta 1 — Los hiperparámetros que elegisteis. (2,5 puntos · ~7 min)

(a) ¿Qué hiperparámetros metisteis en la búsqueda? Nombradlos.

(b) Para cada uno, explicad qué controla dentro del modelo o del entrenamiento: qué cambia en la red o en el proceso cuando ese valor sube y qué cambia cuando baja.

(c) ¿Por qué esos y no otros? ¿Qué dejasteis fijo y con qué criterio?

Pregunta 2 — La interpretación de los valores obtenidos. (2,5 puntos · ~7 min)

(a) ¿Qué valores salieron en la configuración ganadora? Interpretadlos: ¿qué os está diciendo el dataset sobre el modelo que necesita? Por ejemplo, un dropout alto o una red estrecha no son un accidente, dicen algo sobre cuántos datos hay y cuánta señal tienen.

(b) ¿Qué configuraciones salieron claramente mal, y por qué creéis que fallaron?

(c) Comparado con el baseline clásico, ¿mereció la pena la red? Contestad sí o no y justificadlo en dos líneas.

Pregunta 3 — La arquitectura. (2 puntos · ~6 min)

(a) ¿Cuál era la arquitectura de vuestra red? Describidla: tipo de red, cuántas capas, de qué tamaño, qué activación y qué salida.

(b) ¿Qué habría pasado si hubierais usado una red bastante más compleja (muchas más capas o mucho más anchas) sobre estos mismos datos? Hablad de lo que le pasa al ajuste, a la generalización y al tiempo de búsqueda.

(c) ¿Y si hubiera sido demasiado pequeña?

Pregunta 4 — La regularización. (1,5 puntos · ~5 min)

(a) ¿Qué técnica o técnicas de regularización usasteis?

(b) Explicad qué hace la que más peso tuvo: qué le impide al modelo hacer, y por qué eso ayuda a que funcione mejor con datos que nunca ha visto.

(c) ¿Qué pasa si se regulariza demasiado?

Pregunta 5 — El conjunto de datos. (1,5 puntos · ~5 min)

(a) ¿Cuál de las cuatro tablas elegisteis y en qué consistía? Qué representa una fila, qué tipo de columnas hay y qué se está prediciendo.

(b) ¿Cómo repartisteis los datos y para qué sirve cada parte? ¿Por qué no basta con partir en dos?

(c) ¿Qué trampa o peculiaridad de esos datos hubo que tratar antes de entrenar?

Quien haya hecho alguno de los bonus del §5.8 tendrá que poder defenderlo dentro de estas mismas preguntas: los hiperparámetros extra entran en la 1, la comparación entre random search y búsqueda bayesiana entra en la 2 y la CNN entra en la 3.

9. Tabla Concepto → Aplicación → Entradas → Salidas → KPI

Tabla de referencia del caso, para orientar el trabajo de la sesión A. No se pregunta en el examen.

10. Rúbrica

La nota del caso se reparte así:

Desglose de los 10 puntos del examen:

Criterio transversal de corrección: describir no es explicar. Un valor correcto sin mecanismo se lleva la mitad de su parte; un mecanismo bien contado con el valor olvidado se lleva la parte entera.

Condición de aprobación: un examen que no sepa decir qué hiperparámetros se buscaron y qué controla cada uno (pregunta 1) ni describir el conjunto de datos y para qué sirve cada parte de la partición (pregunta 5) suspende el caso, con independencia del leaderboard y del AUC de test.

Esta rúbrica se desvía de la rúbrica común del curso (que rige en los casos II y III y en el proyecto final) porque este caso no tiene memoria escrita, ni slides, ni defensa oral: se trabaja en clase y se evalúa con un examen.

11. Política de IA

Sesión A: IA permitida y fomentada, sin restricciones de herramienta. Escribid con ella el preprocesado, el MLP, el bucle de HPO y el análisis del log, y usadla además para que os explique cada decisión que ha tomado. Cuanto más produzca, más habrá que entender, que es de lo que va el caso. Requisito único: prompts.md completo y a la vista en el visto bueno del §5.7.

Entre sesiones: IA permitida sin límite para estudiar, repasar y pediros explicaciones de vuestro propio código.

Sesión B: IA prohibida, ordenadores cerrados y guardados, sin apuntes. Usarla o consultar apuntes supone un cero en el caso (regla C de la política de IA del Día 01).

La decisión de qué tabla usar y qué cuatro hiperparámetros buscar, y la comprensión de qué hace cada uno, son vuestras y se responden a mano.

12. Fechas y logística

• Sesión A: semana 5, durante el Tema 3, la clase completa. Enunciado y hoja de preguntas publicados una semana antes; traedlo leído y con el dataset del §4 ya elegido y descargado, porque los 100 minutos son de trabajo.
• Entrega: ninguna. No se sube nada a Moodle. El trabajo de la sesión A se enseña al profesor en el aula (§5.7) y la carpeta se la queda el grupo.
• Sesión B: primeros 30 minutos de la clase inmediatamente siguiente. Después se continúa con el temario.
• Feedback y notas: una semana tras el examen.
• Grupos: de tres personas, cerrados en los primeros cinco minutos de la sesión A y válidos solo para este caso; nada que ver con los grupos del proyecto final, y se recomienda expresamente que no coincidan. Si el número de asistentes no es múltiplo de tres, el profesor cierra los grupos sueltos de dos o de cuatro. El examen es individual, así que el grupo no reparte nota: los tres tienen que haber entendido lo que se construyó.
• Qué traer a la sesión A: un portátil por grupo como mínimo, con Python, PyTorch (o Keras), scikit-learn y pandas ya instalados y probados, o bien Colab con sesión iniciada, y el fichero del dataset elegido ya descargado en local. Diez minutos peleando con un pip install o con un zip anidado son diez minutos menos de búsqueda. Si vais a la opción D necesitáis además xlrd (pip install xlrd), porque el fichero es un .xls del formato antiguo que openpyxl no sabe leer.
• Qué traer a la sesión B: bolígrafo. Nada más.

13. Ayudas

Durante la sesión A el profesor responde cualquier duda, de entorno o de contenido: es la sesión con red y hay que aprovecharla. Entre sesiones, el foro primero y el profesor después. Para la búsqueda, empezad simple: random search sobre cuatro hiperparámetros bien elegidos y entendidos rinde más en el examen que una búsqueda bayesiana de cien trials que no sabéis leer.

La demo del profesor: casos/demo_hpo/. Está publicada con el enunciado y es el mejor punto de partida. El corazón es demo_hpo.ipynb, un cuaderno Jupyter ejecutado y lleno de figuras que explica la búsqueda de hiperparámetros paso a paso sobre la opción A, Telco. Si vuestro grupo eligió otra tabla, todo lo que viene abajo os sirve igual: cambia el read_csv y el preprocesado, y el resto es idéntico.

1. Qué es una evaluación: las curvas de entrenamiento y validación de una configuración buena y una mala, y dónde para el early stopping.
2. El paisaje: la superficie de AUC sobre (tasa de aprendizaje, dropout) calculada a la fuerza bruta con 169 entrenamientos, para ver lo que un buscador nunca llega a ver.
3. Rejilla contra sorteo: por qué el grid search desperdicia el presupuesto.
4. Random search y su log.
5. El mecanismo de la búsqueda bayesiana: las densidades de configuraciones buenas y malas, y cómo salen de ahí las propuestas.
6. Las dos, cara a cara: convergencia y mapa del progreso a los 5, 10 y 20 trials.
7. Cómo se lee un log: coordenadas paralelas y curvas de sensibilidad.
8. El bonus de la CNN: filtros aprendidos, matriz de confusión y errores.

El mismo cuaderno está en demo_hpo.pdf, resuelto y paginado, por si preferís leerlo sin ejecutar nada. Además están demo_hpo.py (todo el código, ejecutable con python demo_hpo.py --trials 30 --seeds 3 --paisaje 13 --bonus-cnn), los CSV de las búsquedas, resultado.txt y todas las figuras sueltas en PNG.

Copiad su estructura, no sus resultados: el trabajo de la sesión A es vuestro y el examen pregunta por vuestras decisiones.