Interpretabilidad, depuración y evaluación robusta de modelos neuronales

Inspección del modelo: del síntoma a la causa

Cuando un modelo neuronal falla, rara vez basta con “subir la precisión”. La inspección combina: (1) análisis de errores para entender patrones, (2) métricas y curvas para cuantificar trade-offs, y (3) calibración para saber si las probabilidades son confiables. El objetivo práctico es convertir fallos en hipótesis verificables sobre datos, etiquetas, arquitectura o entrenamiento.

Análisis de errores (error analysis) orientado a acciones

El análisis de errores consiste en revisar ejemplos mal clasificados y agruparlos por tipo. Esto suele revelar problemas de datos (etiquetas ruidosas, clases ambiguas), de cobertura (subdominios no vistos), o de umbral (probabilidades mal calibradas).

• Paso 1: recolecta predicciones con metadatos. Guarda para cada ejemplo: y_true, y_pred, p_pred, y atributos útiles (fuente, cámara, idioma, longitud del texto, etc.).
• Paso 2: ordena por “confianza equivocada”. Prioriza casos donde y_pred != y_true y max(p_pred) es alto: suelen indicar sesgo, fuga de información o etiquetas incorrectas.
• Paso 3: crea buckets. Ejemplos: “baja iluminación”, “texto muy corto”, “clase A vs B confusas”, “oclusiones”, “jerga regional”.
• Paso 4: cuantifica por bucket. Calcula tasa de error por grupo; si un grupo concentra errores, es un candidato a intervención (más datos, limpieza, augmentations, cambio de umbral, etc.).

# Esqueleto (pseudo-Python) para priorizar errores de alta confianza
errors = df[df.y_pred != df.y_true].copy()
errors["conf"] = errors.probs.apply(max)
errors.sort_values("conf", ascending=False).head(20)

Matriz de confusión: qué clases se confunden y por qué

La matriz de confusión muestra, por clase, cómo se distribuyen los aciertos y confusiones. Es especialmente útil en multiclase y en datasets desbalanceados, donde una métrica agregada puede ocultar fallos sistemáticos.

• Lectura práctica: una fila con muchos valores fuera de la diagonal indica que esa clase “se dispersa” (baja sensibilidad/recall). Una columna con muchos valores indica que el modelo “sobre-predice” esa clase (baja precisión/precision).
• Acción típica: si A se confunde con B, revisa: (1) definiciones de etiqueta, (2) ejemplos frontera, (3) features/representaciones que separen A y B, (4) balance de datos entre A y B.

Curvas ROC y PR: elegir umbrales con criterio

En clasificación binaria (o one-vs-rest), el modelo produce un score/probabilidad y luego se elige un umbral. Las curvas ayudan a seleccionar ese umbral según el costo de falsos positivos (FP) y falsos negativos (FN).

• ROC (TPR vs FPR): útil cuando las clases están relativamente balanceadas o cuando interesa el comportamiento global de ranking. Puede ser optimista en escenarios muy desbalanceados.
• PR (Precision vs Recall): más informativa cuando la clase positiva es rara. Muestra el trade-off entre “capturar positivos” (recall) y “no disparar alarmas falsas” (precision).
• Guía de umbral: define primero el objetivo operativo (p.ej., recall mínimo 0.95) y luego elige el umbral que lo cumpla con la mejor precision posible (o viceversa).

# Pseudo-código de selección de umbral por restricción de recall
# thresholds, precision, recall vienen de una curva PR
candidatos = [(t,p,r) for t,p,r in zip(thresholds, precision, recall) if r >= 0.95]
mejor = max(candidatos, key=lambda x: x[1])  # maximiza precision

Calibración de probabilidades: cuando “0.9” debe significar 90%

Un modelo puede discriminar bien (buen ranking) pero estar mal calibrado: asigna probabilidades demasiado altas o bajas. La calibración es crítica si usas probabilidades para decisiones (triage, priorización, costos), no solo para elegir la clase.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

• Diagnóstico: usa un diagrama de confiabilidad (reliability diagram) y el error de calibración (ECE). Si en el bin 0.8–0.9 la frecuencia real de acierto es 0.6, el modelo está sobreconfiado.
• Correcciones comunes: temperature scaling (frecuente en redes profundas), calibración isotónica o Platt scaling (según el caso). Se ajustan en un conjunto de validación separado para no “contaminar” el test.
• Consejo práctico: calibra después de entrenar el modelo y vuelve a evaluar PR/ROC si el umbral depende de probabilidades.

Interpretabilidad según el tipo de dato (y sus límites)

Interpretar no es “explicar la verdad”, sino obtener señales útiles sobre qué factores influyen en la predicción. Las técnicas varían por modalidad (tabular, imagen, texto) y pueden fallar si se usan fuera de su supuesto (correlación vs causalidad, inestabilidad, dependencia del preprocesado).

Tabular: importancia de características por permutación

La importancia por permutación mide cuánto empeora la métrica si desordenas una característica, rompiendo su relación con la etiqueta mientras mantienes el resto igual. Es un método agnóstico al modelo (sirve para redes, árboles, etc.).

• Paso 1: elige una métrica alineada al objetivo (AUC-PR, F1, log-loss, etc.) y calcula el baseline en validación.
• Paso 2: para cada feature, permuta sus valores en el conjunto de validación (manteniendo las demás columnas intactas).
• Paso 3: vuelve a evaluar. La caída de desempeño es la importancia.
• Paso 4: repite varias permutaciones y promedia para reducir varianza.

# Pseudo-código de permutación
baseline = metric(model(X_val), y_val)
importancias = {}
for col in features:
    drops = []
    for _ in range(10):
        Xp = X_val.copy()
        Xp[col] = shuffle(Xp[col])
        drops.append(baseline - metric(model(Xp), y_val))
    importancias[col] = mean(drops)

Limitaciones técnicas: (1) features correlacionadas comparten información: al permutar una, otra puede “compensar” y subestimar la importancia; (2) si el preprocesado genera interacciones (embeddings, normalizaciones por lote), la permutación puede crear ejemplos fuera de distribución; (3) mide dependencia predictiva, no causalidad.

Imágenes: mapas de activación y saliency

En visión, se busca localizar qué regiones influyen en la decisión. Dos familias comunes: (1) saliency por gradiente (sensibilidad de la salida respecto a píxeles) y (2) mapas tipo CAM/Grad-CAM (usan activaciones de capas convolucionales para resaltar regiones).

• Guía práctica (Grad-CAM): (1) elige una capa convolucional profunda, (2) calcula gradientes de la clase objetivo respecto a los mapas de activación, (3) pondera activaciones por esos gradientes, (4) aplica ReLU y reescala al tamaño de la imagen, (5) superpone como heatmap.
• Qué buscar: si el heatmap se centra en el fondo (marca de agua, borde, texto del dataset), sospecha de atajos (shortcut learning) o fuga de información.

Limitaciones técnicas: (1) los mapas pueden ser sensibles a pequeñas perturbaciones; (2) una región resaltada no implica que sea la única evidencia; (3) diferentes métodos pueden dar explicaciones distintas; (4) en modelos con fuerte augmentación o normalización, la interpretación puede cambiar con el pipeline.

Texto: atención como señal auxiliar (no como explicación definitiva)

En modelos con mecanismos de atención, es tentador interpretar los pesos de atención como “importancia” de tokens. Puede ser útil como señal auxiliar para inspección (p.ej., detectar que el modelo se fija en URLs o nombres propios), pero no debe tratarse como explicación causal.

• Uso recomendado: inspecciona tokens con alta atención junto con técnicas adicionales (p.ej., ablation: enmascarar tokens y medir cambio en la salida).
• Chequeo rápido: si al enmascarar tokens “atendidos” la predicción casi no cambia, la atención no está reflejando dependencia real.

Limitaciones técnicas: (1) atención puede redistribuirse sin cambiar la salida; (2) hay múltiples cabezas/capas y la agregación es ambigua; (3) la importancia puede depender del tokenizador y del contexto.

Depuración sistemática: un checklist que evita días perdidos

La depuración en deep learning se beneficia de un enfoque por capas: primero validar datos y shapes, luego el forward pass, después gradientes, y finalmente dinámica de entrenamiento y generalización. La idea es aislar fallos con pruebas pequeñas y repetibles.

1) Verificación de shapes y contratos de entrada/salida

• Paso 1: imprime shapes en puntos críticos (entrada, salida de cada bloque, logits, loss). En texto, revisa (batch, seq_len); en imágenes, (batch, channels, height, width) o el formato que uses.
• Paso 2: valida que la última capa coincide con el problema: número de clases, activación (si aplica) y tipo de loss (p.ej., logits vs probabilidades).
• Paso 3: revisa el dtype y el dispositivo (CPU/GPU) para evitar casts silenciosos o copias costosas.

2) Prueba con subconjuntos pequeños (sanity checks)

Antes de entrenar “en serio”, confirma que el modelo puede sobreajustar un conjunto diminuto. Si no puede, hay un bug en datos, labels, arquitectura, loss o backprop.

• Paso 1: toma 32–256 ejemplos y entrena hasta casi 0 error de entrenamiento.
• Paso 2: desactiva regularización fuerte (dropout alto, augmentations agresivas) para esta prueba.
• Paso 3: si no sobreajusta, revisa: etiquetas alineadas, normalización, learning rate, saturación de activaciones, y si la loss disminuye.

3) Inspección de gradientes: detectar vanishing/exploding y capas “muertas”

• Paso 1: registra estadísticas por capa: norma del gradiente, media, porcentaje de ceros.
• Paso 2: busca patrones: gradientes ~0 en capas tempranas (vanishing), gradientes enormes (exploding), o parámetros que nunca cambian (bloque congelado accidentalmente).
• Paso 3: si hay inestabilidad, prueba: bajar learning rate, usar clipping, revisar inicialización, normalización y precisión numérica.

# Pseudo-código: logging de norma de gradiente
for name, p in model.named_parameters():
    if p.grad is not None:
        log(name, l2_norm(p.grad), p.grad.mean())

4) Detección de overfitting: señales y respuestas

El overfitting se manifiesta como brecha creciente entre entrenamiento y validación. No es solo “mala generalización”: suele indicar datos insuficientes, fuga de información, o distribución distinta entre train/val.

• Señales: loss de train baja continuamente, métricas de val se estancan o empeoran; calibración se degrada; errores se concentran en subgrupos.
• Respuestas técnicas: revisar split (estratificación, leakage por usuario/tiempo), aumentar datos o augmentations realistas, ajustar capacidad, early stopping, regularización, y/o cambiar el criterio de selección de modelo (p.ej., AUC-PR en desbalance).

5) Chequeos de datos: la fuente más común de fallos

• Etiquetas: estima ruido con auditorías de ejemplos de alta confianza mal clasificados; revisa consistencia entre anotadores.
• Distribución: compara estadísticas train vs val/test (longitud de texto, iluminación, resolución, frecuencia de clases, dominios).
• Preprocesado: confirma que el pipeline es idéntico en entrenamiento e inferencia (tokenización, normalización, resize/crop).
• Fugas: busca features que codifican la etiqueta indirectamente (IDs, timestamps, nombres de archivo, marcas de agua).

Evaluación robusta: más allá de un único test set

Una evaluación robusta estima cómo se comportará el modelo ante ruido, cambios de dominio y sesgos técnicos del dataset. Esto reduce sorpresas en producción y mejora la confiabilidad del sistema.

Sensibilidad a ruido y perturbaciones

Evalúa degradación controlada: añade ruido o perturbaciones realistas y mide cómo cae el desempeño. La clave es que las perturbaciones representen el mundo real del caso de uso.

• Imágenes: ruido gaussiano, blur, compresión JPEG, cambios de brillo/contraste, oclusiones parciales.
• Texto: typos, variaciones de mayúsculas, eliminación de stopwords, cambios de orden en frases cortas (si aplica), ruido de OCR.
• Tabular: missingness artificial, jitter en variables continuas, discretización distinta.

• Paso a paso: (1) define una familia de perturbaciones y niveles, (2) genera versiones perturbadas del set de evaluación, (3) reporta curvas de desempeño vs nivel de ruido, (4) identifica el “punto de quiebre” donde el modelo deja de ser útil.

Validación por dominios (domain-based validation)

Si tus datos provienen de múltiples fuentes (hospitales, países, dispositivos, clientes, periodos de tiempo), un split aleatorio puede sobreestimar el desempeño. La validación por dominios separa por fuente para medir generalización real.

• Estrategias: leave-one-domain-out (entrenar en todos menos uno y testear en el excluido), splits por tiempo (entrenar en pasado, evaluar en futuro), o por entidad (usuario/cliente) para evitar leakage.
• Reporte recomendado: métricas por dominio + promedio ponderado; incluye calibración por dominio si las probabilidades se usan para decisión.

Consideraciones técnicas de sesgo en datos

El sesgo puede aparecer como diferencias sistemáticas de error entre subpoblaciones o condiciones. Técnicamente, se manifiesta en métricas desagregadas, cambios de calibración y distintos umbrales óptimos por grupo.

• Paso 1: define grupos observables (cuando sea legal y apropiado): dispositivo, región, idioma, rango de edad, tipo de sensor, etc.
• Paso 2: evalúa desagregado: matriz de confusión por grupo, PR/ROC por grupo, y calibración por grupo (reliability/ECE).
• Paso 3: analiza fuentes: desbalance de representación, calidad de datos distinta (ruido, resolución), o diferencias de prevalencia (base rate) entre grupos.
• Paso 4: mitigación técnica: recolección dirigida, reponderación, ajustes de umbral por dominio/grupo (si procede), y monitoreo continuo de drift.

Para practicar estas técnicas con datasets reales y notebooks guiados, puedes apoyarte en plataformas como Kaggle Learn, DeepLearning.AI y los cursos de fast.ai, enfocándote en ejercicios de evaluación, análisis de errores e interpretabilidad aplicada.