Las tablas son la forma más rápida de “aterrizar” la verificación: si sabes montar 2–3 tablas simples, puedes ver en minutos si tu pronóstico mejora a la climatología (baseline) o si solo suena bien. Aquí vamos a lo práctico: qué columnas poner, cómo separar baseline climatológico y persistencia, cómo leer matrices de confusión sin autoengaños, y cómo evitar trampas típicas (accuracy engañosa, AUC mal interpretada, ETS sin contexto). Incluimos ejemplos con lluvia intensa, viento y niebla, porque ahí se nota si una métrica “sirve” o solo decora.

Este artículo forma parte del tema Verificación en WikiMeteo.es, donde reunimos conceptos y guías prácticas para entender mejor el tiempo y el clima.

1. Qué es y por qué importa

Una tabla bien hecha te obliga a ser honesto: pone al lado tu sistema y los baselines (climatología y persistencia). Si no mejoras eso, no hay valor añadido. La gracia es que no necesitas 20 métricas: necesitas 3–6 bien presentadas y leídas con contexto (base rate, umbral, ventana).

2. Idea clave en 30 segundos

• En una frase: una tabla útil siempre compara sistema vs baseline, no solo “score” suelto
• Señal típica: AUC alta pero sin mejora en ETS/CSI frente a persistencia
• Confusión común: celebrar accuracy cuando el evento es raro

3. Antes de hacer tablas: define 4 cosas

• Qué verificas: continuo (viento, temperatura) o evento (lluvia>X, niebla sí/no).
• Ventana temporal: hora, 6 h, día… (y si es nowcasting, cada cuánto).
• Umbral: por ejemplo, lluvia>20 mm/1h, racha>80 km/h, visibilidad<200 m.
• Baseline: climatología estacional (frecuencia/percentiles) y persistencia (si aplica).

4. Tabla 1: “Ficha resumen” (lo mínimo que siempre deberías tener)

Una sola fila por sistema y por baseline. Columnas recomendadas:

• N (muestras): cuántos casos verificas
• Base rate: frecuencia del evento observado (si es binario)
• Error continuo: MAE o RMSE (si aplica)
• Bias: sesgo medio (si aplica)
• Evento: POD, FAR, CSI (si aplica)
• Probabilístico: Brier (si aplica) y AUC (si lo usas)
• Notas: ventana/umbral/baseline usado

5. Tabla 2: Matriz de confusión (evento binario)

La matriz es la base para no engañarte con un solo número. Incluye siempre: aciertos (hits), fallos (misses), falsas alarmas y correctos negativos. De ahí salen POD/FAR/CSI y te da “olfato” de qué está pasando.

6. Tabla 3: Tabla por umbrales (sensibilidad)

Para lluvia y viento, 1 umbral no basta. Una tabla por umbrales te muestra si tu sistema solo funciona en lo moderado o si aguanta en lo intenso. Ejemplo de umbrales típicos (orientativos):

• Lluvia: >1, >5, >10, >20 mm/h
• Viento racha: >50, >70, >90 km/h
• Niebla: visibilidad <1000, <500, <200 m

En cada umbral, reporta base rate, POD, FAR, CSI (y ETS si lo usas).

7. Tabla 4: Comparación sistema vs baselines (lo que realmente importa)

Esta es la tabla “de decisión”. Columnas típicas:

• Score del sistema (p. ej., RMSE o CSI)
• Score climatología
• Score persistencia
• Mejora vs clima (delta o %)
• Mejora vs persistencia
• Comentario (qué significa operativamente)

8. Cómo leer tablas sin autoengaños (trampas típicas)

• Accuracy alta con evento raro: sospecha inmediata; mira base rate y CSI/ETS.
• AUC alta: indica discriminación, no calibración; puedes discriminar y aun así tener FAR alto.
• ETS: útil porque ajusta por aciertos al azar, pero depende de umbral y base rate; no lo compares entre climas distintos sin cuidado.
• POD vs FAR: si sube POD pero FAR se dispara, quizá tu umbral operativo está mal.
• Persistencia: si tu sistema no gana a persistencia en nowcasting, hay que revisar enfoque.

9. Ejemplos (lluvia intensa, viento, niebla)

9.1 Lluvia intensa (tormentas convectivas)

• Qué tabla manda: por umbrales + comparación vs persistencia y clima.
• Señal útil: CSI cae rápido al subir umbral; si con neighborhood mejora, el problema era desplazamiento.
• Qué evitar: celebrar AUC alta sin mirar FAR y ETS.

9.2 Viento (rachas)

• Tabla útil: continuo (RMSE/bias) + evento por umbral (racha>X).
• Señal útil: bias positivo constante (sobreestima) aunque RMSE sea aceptable.

9.3 Niebla (nowcasting)

• Baseline duro: persistencia por franja horaria.
• Tabla útil: matriz + POD/FAR y comparación vs persistencia.
• Señal de problema: sube POD pero FAR se dispara (alertas demasiado generosas).

10. Errores comunes

• No poner baselines en la tabla (clima/persistencia).
• No reportar base rate ni N.
• Mezclar periodos/estaciones y comparar ETS como si fuera igual.
• Usar AUC como “aprobado” sin mirar calibración o FAR.
• Usar un único umbral para todo.

11. Buenas prácticas

• Tablas pequeñas: 1 ficha + 1 matriz + 1 por umbrales (mínimo).
• Siempre: N, base rate, ventana, umbral, baseline.
• Comparación explícita: sistema vs climatología vs persistencia.
• Para convectiva: añade columna “operador” (punto a punto vs neighborhood).

12. Resumen y claves finales

• Una tabla útil siempre incluye baselines
• Base rate y N son obligatorios
• Eventos raros: accuracy engaña; mira CSI/ETS y matriz
• AUC discrimina, no calibra
• Nowcasting: persistencia es el baseline a batir

13. Mini-glosario

• Base rate: frecuencia observada del evento
• CSI: índice de acierto en eventos (hits / (hits+misses+false alarms))
• ETS: acierto ajustado por azar
• FAR: falsas alarmas sobre pronósticos de evento
• POD: probabilidad de detección
• AUC: área bajo la curva ROC

14. Referencias y lecturas recomendadas

• Met Office: guías de verificación y lectura de tablas/ROC
• NOAA: recursos de verificación (matrices, scores, base rate)
• WMO: glosarios y recomendaciones de verificación