2.13 Datos listos para la IA

Esta lección es la culminación del pilar de datos. Las lecciones anteriores le enseñaron a leer, limpiar, transformar y describir datos geocientíficos. Esta define qué significa que un conjunto de datos esté listo para la IA (AI-ready), y demuestra los dos modos de falla que arruinan proyectos por lo demás cuidadosos: la fuga de datos por preprocesamiento y las particiones equivocadas para datos autocorrelacionados.

1. Una definición operativa de los datos listos para la IA¶

«Listo para la IA» no es una sensación. Un conjunto de datos está listo para la IA cuando pasa esta lista de verificación:

1. Procedencia, licencia y cita documentadas. ¿De dónde salió cada byte, quién es su dueño y cómo debe citarse? Si parte de los datos es sintética, se declara.
2. Metadatos legibles por máquina (una ficha de datos). Un archivo que viaja con los datos y declara qué son las variables, en qué unidades, cómo se recolectaron o generaron y cuáles son las limitaciones conocidas. Un README escrito para humanos no basta; la ficha debe poder analizarse por máquina (YAML, JSON).
3. Formas ordenadas (tidy). Una fila por observación y una columna por variable en las tablas; dimensiones explícitas y etiquetadas en los arreglos. Sin filas de encabezado fusionadas, sin unidades incrustadas en cadenas de texto.
4. Unidades explícitas. Cada variable física carga su unidad en los metadatos, no en un comentario que alguien perderá.
5. Una política de datos faltantes. Qué valores faltan, por qué, cómo están codificados (NaN, pd.NA, un valor centinela) y cuál es el manejo recomendado.
6. Particiones de referencia que viajan con los datos. La pertenencia a entrenamiento/validación/prueba se almacena como una columna o un archivo índice, de modo que cada usuario evalúe sobre los mismos datos apartados.
7. Controles contra fugas. El diseño de las particiones respeta la estructura de correlación de los datos (tiempo, espacio, pertenencia a eventos), y todos los estadísticos de preprocesamiento se calculan solo con la partición de entrenamiento.
8. Un inventario de clases y eventos. Cuántas muestras, cuántas de cada clase, cuántos eventos distintos. Los problemas de eventos raros se ven muy distintos de los balanceados, y los usuarios deben saberlo antes de entrenar.

El resto de este cuaderno construye un conjunto de datos pequeño que pasa la lista de verificación, y luego rompe las reglas 6 y 7 a propósito para que usted vea el daño en las métricas.

🖥️ Diapositivas — Sesión 10 (mié 21 oct)

2. Recordatorios del flujo de trabajo: de los datos crudos a un conjunto de datos de ML¶

Antes de poder satisfacer la lista de verificación, los datos tienen que existir en una forma usable. Un flujo de trabajo condensado, a partir de las lecciones anteriores:

1. Plantee el problema en términos generales. ¿Transformar $A$ en $B$? ¿Predecir $y$ a partir de $X$? Elegir una variable objetivo ya plantea el problema (regresión, clasificación, detección).
2. Establezca qué es realistamente posible. Revise la literatura, de ML y no. Si los expertos alcanzan una exactitud $x$, ese es su primer punto de referencia.
3. Compile y organice los datos temprano. Una sola ubicación, estructuras legibles por máquina (NumPy, Xarray, pandas), guardadas en formatos estándar (Parquet, netCDF, Zarr, HDF5). Nunca sobrescriba los datos crudos.
4. Caracterice los datos. Histogramas, distribuciones, gráficos cruzados, matrices de correlación (lecciones 2.4 y 2.7). Guarde los scripts de exploración.
5. Considere la extracción de características y la reducción de dimensionalidad. Características estadísticas, temporales o espectrales (lección 2.11); PCA o ICA (lección 2.12).
6. Considere el aumento de datos. Bootstrap, ruido sintético, copias transformadas — con procedencia declarada (lecciones 2.6 y 2.10).
7. Haga reproducible la cadena de procesamiento. Un script o un Pipeline de sklearn que vaya de los datos crudos al producto listo para la IA sin pasos manuales.

3. Construir el conjunto de datos: una serie tipo caudal de río con crecidas raras¶

Generamos diez años de una serie diaria tipo caudal: un ciclo estacional de flujo base más ruido, con eventos raros de crecida inyectados como un proceso de Poisson. Como el generador es nuestro, conocemos la verdad de referencia: cada muestra carga una etiqueta (event) y un identificador de evento (event_id). Este es exactamente el tipo de conjunto de datos sintético que la lección 2.10 llamó admisible — lo usamos para desarrollar y evaluar metodología, y declaramos cómo se hizo.

La tarea que plantearemos: pronosticar de manera inmediata (nowcast) si hoy es un día de crecida a partir de los siete días previos de caudal. Las crecidas son raras, así que este es un problema de clasificación desbalanceada — común en las geociencias (crecidas, sismos, deslizamientos de tierra, floraciones algales).

El inventario de clases y eventos¶

Punto 8 de la lista de verificación. Importan dos números distintos, y no son intercambiables: la fracción de muestras etiquetadas con 1 y el número de eventos distintos. Los pliegues de la validación cruzada se cuentan en eventos, no en muestras: 40 eventos repartidos en cinco partes dejan solo ~8 eventos por pliegue, sin importar cuántos días de crecida haya.

4. La ficha de datos¶

Los puntos 1, 2, 4, 5 y 8 de la lista de verificación, en un solo archivo legible por máquina. Una ficha de datos viaja con los datos — la misma carpeta, el mismo repositorio, versionados juntos. Abajo está la ficha de este conjunto de datos, en YAML:

name: synthetic_discharge_floods
version: "1.0"
created: "2026-08-11"
description: >
  Ten years of synthetic daily river-discharge-like data with rare injected
  flood events, for teaching rare-event classification and split design.
provenance:
  synthetic: true                      # disclosed, per lesson 2.10
  generator: mlgeo_synth.inject_rare_events
  generator_params: {rate_per_year: 4.0, duration_days: [3, 15],
                     amplitude: [5.0, 60.0], shape: spike, seed: 2026}
  background: "25 + 12*cos(annual cycle) + N(0, 3.0), seed 2026"
license: CC-BY-4.0
citation: "MLGeo course materials, University of Washington, 2026 edition."
sampling:
  cadence: daily
  start: "2015-01-01"
  n_samples: 3652
variables:
  discharge_m3s: {dtype: float64, units: m^3/s, description: daily mean discharge}
  event:         {dtype: int64, units: null, description: "label: 1 = flood day"}
  event_id:      {dtype: int64, units: null, description: "flood id; -1 = background"}
  split:         {dtype: str, values: [train, val, test], description: benchmark split}
missing_data:
  policy: "no missing values by construction; real gauges gap during floods —
           document gaps, do not silently interpolate labels"
class_inventory:
  flood_sample_fraction: ~0.09
  distinct_events: ~40
splits:
  scheme: chronological
  train: "2015-01-01 to 2021-12-31"
  val:   "2022-01-01 to 2022-12-31"
  test:  "2023-01-01 to 2024-12-31"
  rule: "no event spans a split boundary check; preprocessing statistics
         from train only"
known_limitations:
  - synthetic; event shapes are idealized (linear rise, exponential decay)
  - no measurement gaps, rating-curve errors, or sensor drift

Nada de esto es decoración. Cada entrada responde una pregunta que un usuario futuro (incluido su yo futuro) tendría que adivinar de otro modo.

5. Características para un clasificador de crecidas¶

Construimos un conjunto de características deliberadamente simple: el caudal en cada uno de los siete días previos (características de rezago, q_lag1 = ayer, hasta q_lag7), más el ciclo anual codificado como el seno y el coseno del día del año. El caudal de hoy no es una característica — usarlo volvería trivial la tarea (un día de crecida es un día de caudal alto). Pronosticar de inmediato a partir del pasado mantiene honesto el problema y mantiene la etiqueta fuera de las características. El punto de esta lección no es el modelo — es lo que las particiones y el preprocesamiento le hacen a la evaluación.

6. Agregar una covariable en malla: la unión ráster-estación¶

El registro de nuestra estación de aforo es una serie de tiempo puntual, pero los predictores que importan en los problemas ambientales reales suelen vivir en una malla: temperatura y precipitación de reanálisis, humedad del suelo satelital, temperatura superficial del mar, un modelo digital de elevación (DEM). Casi todo proyecto de ML ambiental termina, por lo tanto, realizando la misma operación — extraer los valores de la malla en las coordenadas de la estación y luego unirlos al eje temporal de la estación — y vale la pena hacerla una vez, con cuidado, nombrando cada decisión. Usamos el campo sintético del curso de temperatura mensual en malla (mlgeo_synth.climate_field), así que no hay ninguna descarga nueva y la estructura del campo es conocida.

Hay que resolver dos desajustes, y cada uno es una decisión:

1. Espacio: el aforo es un punto; la malla es un conjunto de centros de celda. ¿Celda más cercana o interpolación?
2. Tiempo: la malla es mensual; el aforo es diario. ¿Qué valor mensual recibe un día dado?

Espacio: .sel frente a .interp¶

xarray ofrece ambos estimadores en una línea cada uno: .sel(..., method="nearest") salta al centro de celda más cercano, .interp(...) interpola bilinealmente desde las cuatro celdas circundantes. Para un campo suave como la temperatura, la bilineal es la mejor estimación puntual; para un ráster categórico (cobertura del suelo, unidad geológica), la interpolación no tiene sentido — promediar «granito» y «basalto» produce un disparate — y la celda más cercana es la única opción correcta. Declare cuál usó: en esta malla gruesa (4.5°) las dos difieren, y en los problemas reales a escala de kilómetros la diferencia puede dominar.

Tiempo: una unión causal¶

La serie extraída es mensual; la tabla de características es diaria. La jugada tentadora es interpolar la temperatura a resolución diaria — pero la interpolación lineal entre centros de mes usa el valor del mes siguiente, que es información del futuro: una característica de pronóstico construida así fuga, exactamente en el sentido de la sección 7. La unión causal es pandas.merge_asof(..., direction="backward"): cada día recibe el valor mensual más reciente disponible y nada del futuro. Ese es el valor por defecto correcto para las características predictivas; la interpolación suave está bien para el análisis retrospectivo, y en cualquiera de los dos casos la decisión pertenece a la ficha de datos.

Unimos la covariable a una copia de la tabla de características y volvemos a correr el clasificador de crecidas sobre las características de la sección 5, con ella y sin ella, usando la partición cronológica incluida y el preprocesamiento ajustado solo con el entrenamiento.

El puntaje apenas se mueve — y ese es el resultado honesto: este campo sintético de temperatura no tiene ninguna conexión causal con las crecidas inyectadas, y una covariable correctamente unida que no carga información sobre el objetivo no debería cambiar la métrica. El punto de esta sección es la unión, que ahora es segura contra fugas, con unidades etiquetadas y reproducible; en un proyecto real, las mismas seis líneas traen la precipitación de reanálisis a una estación de aforo, la temperatura superficial del mar a una boya o la humedad del suelo a un pozo, y allí la covariable a menudo aporta la habilidad de pronóstico (skill).

Lo que la malla sintética nos ahorró, y una real no lo hará: reproyectar entre sistemas de referencia de coordenadas (rioxarray/rasterio para cualquier cosa en un CRS proyectado), la verificación de longitudes 0–360 frente a ±180 que señalamos arriba, el hecho de que el valor de una celda de malla es un promedio de área y no una medición puntual (un error de representatividad que crece con el relieve), y la semántica de las marcas de tiempo (¿«2015-01» estampa el inicio, el medio o el final del intervalo de promediado?). Cada uno de estos es una entrada de la ficha de datos: la procedencia de la columna unida — la malla de origen, el método de extracción, la regla de unión temporal — es ahora parte de la procedencia de su conjunto de datos (puntos 1 y 2 de la lista de verificación).

7. Fuga de datos por preprocesamiento¶

Punto 7 de la lista de verificación, primera parte. Cada estadístico que usted calcula a partir de los datos — una media, una desviación estándar, una base de PCA, un valor de imputación — es parte del modelo. Si lo calcula con el conjunto de datos completo y luego particiona, información del periodo de prueba ya fluyó hacia las características con las que el modelo entrena. Esto es fuga de datos por preprocesamiento.

Aquí estandarizamos las características de dos maneras:

• Mal: ajustar el StandardScaler con todos los datos, y luego particionar y entrenar.
• Bien: particionar primero, ajustar el escalador solo con los datos de entrenamiento y aplicarlo (congelado) a los datos de prueba.

Las crecidas de los años de prueba desplazan la media y la varianza del conjunto completo, así que la versión incorrecta le dice al modelo, en silencio, algo sobre el periodo de prueba. Calificamos con la precisión promedio (el área bajo la curva precisión-exhaustividad), la métrica apropiada para una clase positiva rara — la exactitud (accuracy) sería de ~97 % para un modelo que nunca predice una crecida.

En este conjunto de datos los dos puntajes son esencialmente idénticos: la serie es larga, aproximadamente estacionaria, y un escalador carga solo dos números por característica, que una regresión logística puede absorber en sus pesos. No se consuele con eso. La brecha crece cuando los datos son cortos, cuando el periodo de prueba se aleja del periodo de entrenamiento o cuando el preprocesamiento es más rico que un escalador — las bases de PCA, los modelos de imputación, la selección de características y la normalización por percentiles globales fugan mucho más que una media y una desviación estándar. La disciplina no cuesta nada: particione primero y luego ajuste cada paso de preprocesamiento solo con la partición de entrenamiento. En sklearn, ponga el escalador y el modelo en un solo Pipeline para que la validación cruzada reajuste el preprocesamiento dentro de cada pliegue automáticamente.

Una fuga que destroza la métrica: sobremuestrear antes de particionar¶

Aquí hay una fuga de preprocesamiento con dientes, y uno de los errores más comunes con los eventos raros. Para combatir el desbalance de clases, los estudiantes a menudo sobremuestrean la clase rara — duplican los días de crecida hasta balancear las clases — y luego particionan al azar en entrenamiento y prueba. Las copias duplicadas del mismo día de crecida caen a ambos lados de la partición. El modelo se evalúa entonces sobre copias exactas de sus muestras de entrenamiento.

La versión con fuga reporta un puntaje perfecto o casi perfecto — pura ficción, producida enteramente por las muestras duplicadas a caballo de la partición. Cualquier preprocesamiento que cree, duplique, seleccione o transforme muestras usando conocimiento del conjunto completo debe ocurrir dentro de la partición de entrenamiento, nunca antes.

8. Particiones para datos autocorrelacionados¶

Punto 7 de la lista de verificación, segunda parte, y la mayor fuente de puntajes inflados en el ML geocientífico. Nuestras características son ventanas de siete días de una serie suave: el día $t$ y el día $t+1$ comparten seis de sus siete valores de rezago. Una partición aleatoria dispersa los días de una misma crecida entre el entrenamiento y la prueba. El modelo entonces «predice» un día de prueba por haber memorizado a sus vecinos casi duplicados en el entrenamiento. El puntaje es real; la habilidad no, y no se transferirá a una crecida que el modelo nunca ha visto.

La solución es particionar a lo largo de la estructura de correlación:

• TimeSeriesSplit entrena con el pasado y prueba con el futuro — el escenario de despliegue del pronóstico.
• GroupKFold mantiene los grupos intactos: todos los días de una misma crecida quedan del mismo lado de la partición. Agrupamos los días de crecida por event_id y los días de fondo en bloques mensuales.

Una decisión deliberada más: cambiamos de la regresión logística a un bosque aleatorio. Un modelo lineal casi no tiene capacidad de memorizar muestras individuales, así que esconde el problema de la partición. Un bosque aleatorio memoriza los casi duplicados con gusto — y esa capacidad es exactamente lo que una partición aleatoria premia. Corremos la cadena idéntica (escalador + clasificador, para que el preprocesamiento se reajuste dentro de cada pliegue) bajo los tres esquemas de validación cruzada.

El KFold aleatorio reporta el puntaje más alto por un margen amplio, y es el menos confiable de los tres: sus pliegues de prueba están llenos de muestras que son casi copias de muestras de entrenamiento, así que el bosque se califica sobre crecidas que, en la práctica, ya vio. TimeSeriesSplit y GroupKFold responden la pregunta que de verdad le importa — ¿detecta el modelo crecidas que nunca ha visto? — y la responden con menos halagos. (TimeSeriesSplit también da el puntaje más bajo, en parte porque sus primeros pliegues entrenan con solo una fracción de los datos.)

Reglas prácticas:

• Series de tiempo → particione en el tiempo (TimeSeriesSplit, o una retención cronológica como nuestra columna split incluida).
• Datos por eventos (sismos, tormentas, crecidas) → particione por evento (GroupKFold sobre el identificador de evento). Nunca deje que las ventanas de un mismo evento queden a caballo de la partición.
• Datos espaciales → particione por región, no por píxel; los píxeles cercanos son casi duplicados.
• En caso de duda, pregúntese: ¿podría una muestra del conjunto de prueba reconstruirse trivialmente a partir de muestras del conjunto de entrenamiento? Si la respuesta es sí, la partición está mal.

Por esto el punto 6 de la lista dice que las particiones viajan con los datos: quien construye el conjunto de datos conoce su estructura de correlación mejor que cualquier usuario posterior, y una partición almacenada hace comparables todos los puntajes publicados.

9. Conjuntos de entrenamiento, validación y prueba¶

Cuál es el papel de un conjunto de entrenamiento y de uno de prueba¶

Un conjunto de datos de entrenamiento es el cimiento de los modelos de aprendizaje automático. Proporciona los datos que el algoritmo usa para aprender los patrones, las relaciones y las representaciones necesarias para hacer predicciones o tomar decisiones. La meta principal del conjunto de entrenamiento es permitir que el modelo minimice el error o la función de pérdida optimizando sus parámetros.

Un conjunto de datos de prueba se usa para evaluar el desempeño del modelo sobre datos no vistos. Prepararlo implica:

1. Partición de los datos: el conjunto de prueba es un subconjunto de los datos, separado del conjunto de entrenamiento, a menudo del 10-30 % del conjunto — elegido teniendo en mente la estructura de correlación, como arriba.
2. Principio de retención: los datos de prueba nunca deben traslaparse con los de entrenamiento o validación, y deben tocarse una sola vez, al final. Cada vez que usted mira los puntajes de prueba y cambia el modelo en respuesta, el conjunto de prueba se degrada en un conjunto de validación.
3. Representatividad del mundo real: los datos de prueba deben reflejar los escenarios donde se desplegará el modelo, para garantizar una evaluación robusta del desempeño.

Aprendizaje automático clásico (CML) frente a aprendizaje profundo (DL)¶

1. CML: los modelos son más simples, con menos hiperparámetros que ajustar (los hiperparámetros son las configuraciones que usted elige antes de entrenar — la profundidad del árbol, la tasa de aprendizaje — a diferencia de los parámetros que el modelo aprende de los datos). Un conjunto de entrenamiento se usa para ajustar el modelo, que luego se evalúa con el conjunto de prueba. La validación cruzada (como en la sección 8) evalúa el desempeño y reduce el sobreajuste, y a menudo elimina la necesidad de un conjunto de validación separado.

2. DL: los modelos son complejos, a menudo con millones de parámetros, y necesitan un conjunto de validación además de los conjuntos de entrenamiento y prueba. El conjunto de validación se usa durante el entrenamiento para ajustar los hiperparámetros (la tasa de aprendizaje, el número de capas) y para vigilar el sobreajuste (detención temprana cuando la pérdida de validación deja de mejorar).

Una partición típica para DL:

• Conjunto de entrenamiento: 70-80 % de los datos.
• Conjunto de validación: 10-20 % de los datos.
• Conjunto de prueba: 10-20 % de los datos.

El conjunto de validación protege al de prueba: el ajuste de hiperparámetros consume el conjunto de validación, así que el conjunto de prueba permanece genuinamente no visto.

10. Esta lista de verificación se califica¶

El conjunto de datos listo para la IA que usted construya para el hito de su proyecto se evaluará contra la lista de verificación de la sección 1: la procedencia y la licencia, una ficha de datos, formas ordenadas y unidades, una política de datos faltantes, particiones de referencia incluidas, controles contra fugas y un inventario de clases y eventos. Vea la tarea del capítulo y la descripción del proyecto final.

Si recuerda una sola oración de este pilar: la partición y el preprocesamiento son parte del conjunto de datos, no una ocurrencia tardía del modelo.