En el tema anterior vimos cómo entrenar un modelo en PyTorch. Aprendimos a preparar datos, definir una función de pérdida, usar un optimizador y repetir el ciclo de entrenamiento durante varias épocas.
Pero entrenar un modelo no alcanza. Después de entrenarlo necesitamos responder una pregunta fundamental:
Responder esa pregunta es precisamente el objetivo de la evaluación del modelo. En este tema veremos cómo medir el desempeño de una red neuronal y cómo evitar conclusiones engañosas.
Evaluar un modelo significa analizar qué tan bien realiza la tarea para la cual fue entrenado.
Esto implica observar su comportamiento sobre datos y medir sus resultados con criterios objetivos.
Por ejemplo, podríamos querer saber:
Evaluar no es “mirar si parece funcionar”, sino medirlo de una manera razonable.
Durante el entrenamiento es común observar la pérdida para ver si baja. Eso es útil, pero no basta para saber si el modelo realmente funciona bien.
Un modelo puede tener una pérdida baja sobre los datos con los que fue entrenado y, sin embargo, comportarse mal sobre datos nuevos.
Esto ocurre porque el entrenamiento y la evaluación no persiguen exactamente lo mismo:
Por eso, mirar solo el error de entrenamiento puede llevar a conclusiones equivocadas.
Uno de los conceptos más importantes en evaluación es la generalización.
Decimos que un modelo generaliza bien cuando no solo funciona con los datos que vio durante el entrenamiento, sino también con datos nuevos que no conocía.
Ese es el verdadero objetivo de la mayoría de los modelos de Machine Learning y Deep Learning: no memorizar, sino aprender patrones útiles.
Para evaluar correctamente un modelo, normalmente no usamos un único conjunto de datos para todo.
Lo habitual es dividir los datos en tres grupos:
Esta separación ayuda a medir mejor qué tan bien generaliza el modelo.
El conjunto de entrenamiento es el que usamos para enseñar al modelo. Allí ocurre el ciclo de forward, pérdida, backward y actualización de parámetros.
Como el modelo ve estos datos repetidamente, no sirve usar solo este conjunto para juzgar su calidad final.
Es parecido a practicar siempre con las mismas preguntas y luego asumir que ya dominamos todo el tema: puede ser una impresión engañosa.
El conjunto de validación sirve para observar cómo se comporta el modelo mientras aprende, pero sobre datos que no está usando directamente para ajustar parámetros en ese momento.
Esto permite detectar problemas como:
En muchos proyectos reales, el conjunto de validación cumple un papel muy importante para tomar decisiones durante el desarrollo.
El conjunto de prueba se reserva para el final. Su función es ofrecer una medición más imparcial del rendimiento del modelo ya entrenado y ajustado.
La idea es que estos datos permanezcan “intactos” hasta el momento de la evaluación final.
Si usamos constantemente el conjunto de prueba para tomar decisiones, deja de ser una referencia confiable.
En PyTorch, entrenar y evaluar no son exactamente el mismo proceso. Cuando entrenamos, el modelo puede comportarse de una manera distinta que cuando solo queremos medir su desempeño.
Por eso existen dos modos importantes:
model.train() para entrenamiento.model.eval() para evaluación.Esta diferencia se vuelve especialmente importante en modelos que usan capas como Dropout o Batch Normalization.
Antes de evaluar un modelo, en general conviene ponerlo en modo evaluación:
Esto le indica a PyTorch que el modelo ya no está en fase de entrenamiento y que debe comportarse de forma adecuada para medir resultados.
En redes simples quizás no se note demasiado la diferencia, pero es una práctica correcta y necesaria en muchos casos reales.
Durante la evaluación normalmente no necesitamos calcular gradientes, porque no vamos a actualizar parámetros.
Por eso, PyTorch ofrece un contexto especial:
Esto hace la evaluación más eficiente y evita trabajo innecesario del sistema de autograd.
En otras palabras, cuando solo queremos medir, no tiene sentido preparar cálculos para aprender.
Supongamos que ya tenemos un modelo entrenado y queremos evaluar su comportamiento sobre un conjunto de datos.
Esto genera las salidas del modelo sin calcular gradientes y en modo evaluación.
Con esas predicciones ya podemos compararlas contra las salidas reales y calcular métricas.
Las métricas son valores que resumen el desempeño del modelo.
No existe una única métrica universal. La elección depende del tipo de problema.
Por ejemplo:
Lo importante es que una métrica debe ayudarnos a interpretar de forma objetiva cómo funciona el modelo.
Si el modelo predice valores continuos, estamos en un problema de regresión.
En estos casos es frecuente usar métricas basadas en el error entre la predicción y el valor real.
Algunas opciones comunes son:
La idea general es simple: cuanto menor sea el error, mejor estará funcionando el modelo.
En ejemplos sencillos de regresión, a veces la misma función de pérdida que usamos para entrenar también puede servir como referencia para evaluar.
Aquí estamos obteniendo una medición numérica del desempeño del modelo sobre ese conjunto de datos.
En problemas de clasificación, en cambio, muchas veces lo más intuitivo es saber cuántos ejemplos fueron clasificados correctamente.
Allí aparece una métrica muy conocida: la accuracy o exactitud.
La accuracy indica la proporción de predicciones correctas sobre el total de casos evaluados.
Supongamos que evaluamos 100 ejemplos y el modelo acierta 87.
Entonces la accuracy sería:
Es decir, un 87% de aciertos.
Esta métrica es muy útil porque resulta fácil de entender, aunque no siempre alcanza por sí sola para describir bien el desempeño.
En clasificación, el modelo muchas veces produce puntajes o probabilidades. Para calcular accuracy, normalmente necesitamos convertir esa salida en una clase concreta.
Por ejemplo, en clasificación binaria podríamos usar un umbral. En clasificación multiclase, podríamos elegir la clase con valor más alto.
La idea central es que la evaluación de clasificación suele requerir un paso adicional para traducir la salida del modelo en una decisión.
Imaginemos que las etiquetas reales son:
y el modelo predice:
Comparando ambas listas, vemos que acertó 4 de 5 casos.
La accuracy sería entonces 0.8, es decir, 80%.
Aunque accuracy es útil, no siempre es suficiente. En algunos problemas puede dar una impresión engañosa.
Por ejemplo, si una clase aparece muchísimo más que otra, un modelo podría acertar mucho simplemente prediciendo siempre la clase más frecuente.
Por eso en algunos casos también se usan métricas como:
Más adelante, cuando trabajemos más con clasificación, estas métricas cobrarán mayor importancia.
Una práctica muy útil consiste en comparar la pérdida sobre entrenamiento con la pérdida sobre validación.
Si ambas bajan, eso suele ser una buena señal. Pero si la pérdida de entrenamiento baja mientras la de validación empeora, puede indicar overfitting.
Este tipo de observación es muy valiosa porque nos permite detectar cuándo el modelo empieza a aprender demasiado los detalles del conjunto de entrenamiento.
El overfitting ocurre cuando el modelo se adapta demasiado a los datos de entrenamiento y pierde capacidad de generalizar.
Desde el punto de vista de la evaluación, suele verse así:
Esto muestra por qué la evaluación con datos separados es tan importante.
El caso opuesto es el underfitting. Aquí el modelo ni siquiera logra aprender bien sobre el conjunto de entrenamiento.
En evaluación, esto suele verse como un rendimiento pobre tanto en entrenamiento como en validación.
Puede deberse a un modelo demasiado simple, pocas épocas de entrenamiento o una mala configuración de hiperparámetros.
Un error conceptual frecuente es pensar que evaluar forma parte del entrenamiento en el mismo sentido que actualizar parámetros.
Durante la evaluación no queremos que el modelo aprenda, sino que muestre qué tan bien aprendió hasta ese momento.
Por eso usamos model.eval() y torch.no_grad(): queremos medir, no entrenar.
Un flujo simple de evaluación en PyTorch podría resumirse así:
Este esquema se adapta tanto a regresión como a clasificación, con diferencias en la métrica y en la interpretación de la salida.
Supongamos que ya entrenamos un modelo de regresión. La evaluación podría escribirse así:
Este ejemplo ya muestra los elementos esenciales de una evaluación básica.
Además de usar métricas agregadas, muchas veces conviene mirar directamente algunas predicciones junto con sus valores reales.
Por ejemplo, podríamos imprimir pares como estos:
Esto ayuda a desarrollar intuición sobre el comportamiento del modelo y detectar errores groseros que una sola métrica podría ocultar.
La evaluación puede verse desde dos ángulos complementarios:
Las métricas son imprescindibles, pero también es valioso mirar resultados reales y preguntarse si tienen sentido.
Algunos errores frecuentes son:
model.eval().torch.no_grad().Evitar estos errores hace que la evaluación sea mucho más confiable.
Si estás comenzando, estas recomendaciones suelen ayudar mucho:
Estas prácticas te ayudarán a interpretar mejor el comportamiento real del modelo.
Podemos resumir la evaluación de un modelo así:
torch.no_grad().Este proceso es esencial para saber si el modelo realmente sirve para la tarea planteada.
Para poder probar todo el flujo sin tener que reconstruirlo por partes, aquí tienes un ejemplo completo y ejecutable. En este caso separamos explícitamente datos de entrenamiento y datos de prueba.
Este script permite ver en un solo bloque cómo se conectan entrenamiento, evaluación y predicción. Primero el modelo aprende con X_train e y_train, después se evalúa con X_test e y_test, y finalmente se usa para predecir un valor nuevo (7.0) que no pertenece ni al entrenamiento ni a la prueba.
model.eval() pone al modelo en modo evaluación.torch.no_grad() evita calcular gradientes innecesarios.La evaluación del modelo es una etapa indispensable en cualquier flujo serio de Deep Learning. Entrenar un modelo sin evaluarlo correctamente equivale a estudiar sin comprobar si realmente se aprendió.
Dominar esta etapa significa aprender a mirar el rendimiento de una red de forma crítica y objetiva, sin quedarse solo con la intuición o con una pérdida que baja durante el entrenamiento.
En el próximo tema daremos un paso más aplicado: veremos la clasificación con redes neuronales.