/ Proyectos / Educación / CNN tipo VGG: batch size, dataset y regularización L1/L2
CNN tipo VGG en TensorFlow: cómo el batch size, el tamaño del dataset y la regularización L1/L2 cambian el resultado
Los parámetros de una red convolucional explicados según TensorFlow/Keras, y las gráficas que muestran por qué cada decisión de diseño tiene un costo.
El objetivo era entender, con evidencia y no con intuición, qué pasa realmente cuando cambias un hiperparámetro de una red convolucional. No agregar capas para "ver si mejora", sino aislar una arquitectura base tipo VGG y variar un solo factor a la vez: el tamaño de batch, el tamaño del set de entrenamiento, y la regularización L1/L2, midiendo siempre accuracy, loss y tiempo de cómputo.
La arquitectura base es intencionalmente simple: una capa Conv2D, un MaxPooling2D, y dos capas densas, entrenada sobre CIFAR-10. Simple no por limitación, sino por diseño: con una arquitectura mínima, cualquier cambio en el comportamiento del modelo solo puede venir del hiperparámetro que se está probando, no de la complejidad adicional de la red.
Diccionario de parámetros (según TensorFlow/Keras)
Antes de entrar a los experimentos, esto es lo que significa cada parámetro que vas a ver repetido en el código, tal como lo define la API de Keras:
| Parámetro | Dónde aparece | Qué controla |
|---|---|---|
filters | Conv2D | Cuántos mapas de características (feature maps) distintos aprende esa capa. Cada filtro detecta un patrón visual distinto (bordes, texturas, etc.) |
kernel_size | Conv2D | El tamaño de la ventana que se desliza sobre la imagen, ej. (3,3). Ventanas más grandes capturan patrones más amplios, pero cuestan más cómputo |
strides | Conv2D, MaxPooling2D | Cuántos píxeles se desplaza la ventana en cada paso. Un stride mayor a 1 reduce la resolución de salida |
padding | Conv2D, MaxPooling2D | 'same' agrega borde para conservar el tamaño espacial de salida; 'valid' no agrega nada, y la salida se reduce |
pool_size | MaxPooling2D | El tamaño de la ventana que se reduce a un solo valor (el máximo). No tiene parámetros entrenables, solo reduce resolución |
units | Dense | Cuántas neuronas tiene esa capa completamente conectada. Determina directamente cuántos parámetros entrenables aporta |
activation | Cualquier capa | La función no lineal que decide qué tan "activa" queda cada neurona. tanh y relu son comunes en capas ocultas; softmax en la salida para clasificación multiclase |
kernel_regularizer | Dense, Conv2D | Penaliza pesos grandes durante el entrenamiento. regularizers.L1(lambda), L2(lambda) o L1L2(lambda); el valor de lambda controla qué tan fuerte es la penalización |
batch_size | model.fit() | Cuántos ejemplos se procesan antes de actualizar los pesos una sola vez. No es un parámetro de la arquitectura, es un parámetro del proceso de entrenamiento |
epochs | model.fit() | Cuántas veces el modelo recorre el set de entrenamiento completo |
learning_rate | El optimizador (ej. RMSprop) | Qué tan grande es el paso que da el optimizador en cada actualización de pesos |
Mapa del casoContenido
- Diagrama de la solución. La arquitectura base capa por capa, con el conteo de parámetros de cada una
- Construcción de la solución. Cómo aislar un hiperparámetro a la vez dirigió cada decisión
- Condiciones del proyecto. Restricciones reales y opciones descartadas antes de experimentar
- Pasos. Qué se dejó al agente y qué criterio se aplicó en cada uno
- Proceso de iteración. El resultado contraintuitivo del batch size, y lo que quedó pendiente
- Descargables. Notebook, diagrama y repositorio del proyecto
- Lecciones importantes. La lección concreta que deja este caso
Estructura de alto nivelDiagrama de la solución
Pasa el cursor sobre cada capa para ver su configuración exacta y cómo se cuentan sus parámetros.
Esta misma arquitectura, sin cambiar una sola capa, es la que se reutiliza en los tres experimentos. Lo único que cambia entre corridas es batch_size, la cantidad de datos de entrenamiento, o el kernel_regularizer de las capas densas.
Cómo se construyóConstrucción de la solución
Condiciones del proyecto
| Restricción | Dato |
|---|---|
| Objetivo | Ejercicio didáctico para entender el efecto real de cada hiperparámetro, no llevar el modelo a producción |
| Dataset | CIFAR-10 (60,000 imágenes de 32×32px, 10 clases), reducido a subconjuntos más pequeños para acelerar el entrenamiento en clase |
| Épocas por experimento | Fijas en 20, para que la comparación entre configuraciones sea justa |
| Cómputo disponible | Se verifica la disponibilidad de GPU al inicio del notebook; no garantizada |
| Opción | Por qué se descartó |
|---|---|
| Empezar directamente con una arquitectura VGG completa (múltiples bloques Conv+Pool) | Mezclaría el efecto de la arquitectura con el efecto de cada hiperparámetro que se quiere aislar |
| Entrenar cada configuración "hasta converger" con épocas distintas | No sería una comparación justa de tiempo ni de desempeño entre configuraciones |
| Reportar solo el accuracy final de cada configuración | Oculta la dinámica de sobreajuste, que es donde está el hallazgo real |
| Arquitectura base fija + variar un solo hiperparámetro a la vez, midiendo accuracy/loss por época y tiempo de cómputo | Permite atribuir cualquier cambio de comportamiento a una sola causa, no a una mezcla de factores |
Pasos
Qué medir en cada experimento
Agente: propuso reportar solo el accuracy final de cada configuración.
Criterio aplicado: medir también el tiempo de cómputo con time.time() en cada corrida, y graficar accuracy/loss por época en entrenamiento y validación, porque el momento exacto en que ambas curvas se separan es más informativo que cualquier número final.
Diseño de la arquitectura base
Agente: propuso empezar directamente con varios bloques convolucionales tipo VGG completo.
Criterio aplicado: usar una sola capa Conv2D al inicio, para que el efecto de cada hiperparámetro que se prueba después no se confunda con la complejidad de la arquitectura.
Cómo variar el tamaño de batch
Agente: sugirió comparar solo dos valores de batch size.
Criterio aplicado: usar cuatro valores espaciados exponencialmente (32, 128, 512, 1024), para capturar tanto el extremo de convergencia lenta y estable como el de convergencia rápida y menos estable.
Cómo probar la regularización L1/L2
Agente: propuso un solo valor de lambda por tipo de regularización.
Criterio aplicado: probar valores extremos (10, 0.1, 0.0001) en las capas densas, para ver el rango completo de efecto: desde una penalización tan fuerte que "apaga" el aprendizaje, hasta una tan débil que no cambia nada observable.
Proceso de iteración
Ajuste documentado, no forzado
Los experimentos de batch size dieron un resultado que no cuadraba con la intuición inicial. En accuracy y loss de entrenamiento, un batch más chico (32-128) se comportó mejor que uno grande (512-1024), como se esperaría. Pero en la gráfica de loss de validación ocurrió justo lo contrario: los batches más grandes mostraron menor loss de validación que los chicos. La explicación más plausible es que, con un batch mayor, el gradiente se promedia sobre más ejemplos por actualización, lo que produce una estimación más estable aunque menos "ruidosa" para escapar de mínimos poco útiles. Además, la exploración planeada originalmente incluía Dropout, BatchNormalization y Data Augmentation, pero se decidió cerrar primero el ciclo de comparación aislada en regularización L1/L2 antes de sumar esas capas, para no mezclar demasiadas variables en una sola ronda de experimentos. Quedan como la iteración natural siguiente.
CierreLecciones importantes
Ningún hiperparámetro es gratis. Un batch más grande entrena más rápido, pero puede cambiar la dinámica de generalización de formas que no siempre son obvias. Más datos de entrenamiento mejoran el desempeño, pero también el tiempo de cómputo. Una regularización mal calibrada no "afina" el modelo, lo puede apagar por completo. La única forma de saber qué trade-off estás haciendo es medirlo, no asumirlo.
Por eso la disciplina de aislar una sola variable a la vez, y graficar siempre la dinámica completa del entrenamiento (no solo el número final), es la habilidad que realmente se practica en un ejercicio como este. Es la misma disciplina que se necesita después, en un proyecto real, para saber si un cambio en el modelo mejoró algo de verdad o solo movió el número por casualidad.
Si quieres profundizar en el efecto del tamaño de batch con más rigor experimental, este estudio reciente hace un barrido sistemático de batch size en varios datasets, incluido CIFAR-10: Large Batch vs. Small Batch Training: Generalization Tradeoffs in Deep Neural Networks.
Termina ya tu proyecto
¿Tienes un proyecto similar y no sabes por dónde empezar? Yo te ayudo a diseñarlo.
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro. Acceso inmediato