Detectar y prevenir la fuga de datos (data leakage) en Machine Learning

Planteamiento y casos de uso

Un modelo de fraude tiene un rendimiento excepcionalmente bueno en una división aleatoria fuera de línea (offline), pero se degrada sustancialmente en producción. Cada fila representa una transacción y el modelo debe decidir si la bloquea en el momento en que ocurre. La etiqueta indica si se confirma un contracargo dentro de los 30 días posteriores a la transacción. Las características candidatas provienen de eventos de transacciones, agregaciones del historial de la cuenta, resultados finales de contracargos y estados de revisión manual.

Explique la fuga de datos (data leakage), investigue la fuga por variable objetivo, temporal, por duplicación de entidades y de preprocesamiento, y rediseñe la generación de características, la división de entrenamiento/validación/prueba, la validación cruzada y la evaluación final. Explique también cómo distinguir la fuga de datos del sesgo entre entrenamiento y servicio (training-serving skew) y de la desviación genuina de la distribución (distribution drift).

Esta pregunta aparece en entrevistas de ingeniería de machine learning, ciencia de datos, riesgo y sistemas de recomendación. Los entrevistadores rara vez aceptan "dividir antes del preprocesamiento" como una respuesta completa. Preguntarán si una característica existía en el momento real de la predicción, si la misma entidad puede cruzar particiones y si el equipo realizó ajustes repetidos contra el conjunto de prueba.

Qué evalúa el entrevistador

Primero, ¿puede el candidato dar una definición operativa? La fuga de datos ocurre cuando el desarrollo o la evaluación del modelo utiliza información que no estaba disponible en el momento real de la predicción, o cuando la información de una partición de validación o prueba influye en el entrenamiento, la selección de características o la selección del modelo. La fuga a menudo hace que las métricas fuera de línea sean demasiado optimistas, pero una caída en producción por sí sola no demuestra que haya fuga. La desviación de datos, las etiquetas inconsistentes y el cálculo defectuoso de características en línea pueden verse similares.

Segundo, ¿define el candidato primero el contrato de predicción? Cada fila necesita un prediction_at, una ventana de observación de etiquetas, un límite temporal de disponibilidad de datos (cutoff) y una descripción de las entidades atendidas en producción. Sin ese límite, incluso las "transacciones en los siete días anteriores" pueden contener eventos posteriores a la predicción. Que un campo del negocio genere fuga depende de cuándo pasa a estar disponible, no de qué tan razonable suene su nombre.

Tercero, ¿la división reproduce el despliegue en producción? La división aleatoria ordinaria es adecuada únicamente para muestras independientes e idénticamente distribuidas. Los datos ordenados necesitan validación hacia adelante (forward validation). La estructura de grupos por usuario, dispositivo, comercio u otros requiere aislamiento de grupos o al menos una prueba de estrés basada en grupos. El escalamiento, la imputación, la selección de características y la codificación deben ajustarse dentro de cada pliegue (fold) de entrenamiento, y el conjunto de prueba final no debe participar en el ajuste de hiperparámetros.

Finalmente, ¿el diagnóstico forma una cadena de evidencia? Las comprobaciones útiles incluyen la reproducción puntual en el tiempo (point-in-time replay), un registro de disponibilidad de características, auditorías de duplicados entre particiones, ablación de características sospechosas, controles negativos por permutación de etiquetas y la comparación entre divisiones aleatorias y divisiones fieles al despliegue. Una respuesta sólida también reconoce el balance (trade-off): una evaluación más estricta a menudo reduce la puntuación y deja menos datos de entrenamiento, pero produce una estimación de generalización más creíble.

Preguntas para aclarar antes de responder

• ¿Cuándo ocurre la predicción? Asuma que la transacción se califica al llegar. La información producida con posterioridad no puede ingresar en las características de esa fila.
• ¿Cuándo madura la etiqueta? Un positivo significa un contracargo confirmado dentro de los 30 días. Las filas cercanas al límite temporal del conjunto de datos cuyas ventanas de observación estén incompletas no pueden tratarse como negativos.
• ¿El modelo atiende a entidades existentes o no vistas? Si la producción observa repetidamente cuentas antiguas, la división temporal es la evaluación principal. La generalización a nuevos comercios o dispositivos también requiere pruebas con aislamiento de entidades.
• ¿En qué momento se calculan las agregaciones históricas? Utilice el tiempo del evento y los datos realmente visibles en ese instante mediante cálculos puntuales en el tiempo/al momento (point-in-time/as-of), no la instantánea (snapshot) actual del almacén de datos rellenada retrospectivamente hacia el pasado (backfilled).
• ¿Existen duplicados o duplicados cercanos? Los reintentos de una transacción, los registros duplicados (mirrored logs), las múltiples filas para un mismo caso y el texto altamente similar pueden cruzar particiones.
• ¿Qué pasos aprenden parámetros a partir de los datos? La imputación, la normalización, los vocabularios, la selección de características, la reducción de dimensionalidad, la codificación de variables objetivo (target encoding) y la selección de umbrales cuentan. Auditar solo el modelo final es insuficiente.
• ¿Con qué frecuencia se ha consultado el conjunto de prueba? Si sus resultados guiaron cambios en las características o hiperparámetros, ha participado en la selección del modelo y se requiere un nuevo conjunto de retención (holdout) intacto.
• ¿Qué se degradó exactamente en producción? Compare distribuciones de entrada, valores faltantes en características, retraso en las etiquetas, reproducciones fuera de línea y registros del servicio en producción en lugar de calificar cada falla como fuga de datos.

Estructura de respuesta en 30 segundos

"Definiría el tiempo de predicción y la ventana de etiqueta de 30 días, y luego verificaría que cada característica estuviera realmente disponible en ese momento. Revisaría cuatro vías de fuga: campos posteriores al resultado, datos futuros, duplicados entre particiones y preprocesamiento ajustado sobre todos los datos. El desarrollo utiliza validación hacia adelante, con aislamiento de entidades cuando sea necesario, y cada transformación aprendida se ajusta únicamente en los pliegues de entrenamiento. Tras fijar el modelo y el umbral, evalúo el conjunto de retención final una sola vez. La reproducción puntual en el tiempo, las auditorías de solapamiento, la ablación de características y la permutación de etiquetas ayudan a localizar la fuga; el sesgo en el servicio (serving skew) y la desviación (drift) se comprueban por separado".

Análisis detallado paso a paso

Escriba el contrato de predicción antes de elegir una estrategia de división. Como mínimo, cada fila registra una entidad del negocio, event_at, el momento en que el sistema observó realmente el evento como available_at, prediction_at y label_ready_at. Una característica es elegible solo cuando available_at <= prediction_at y lo mismo se aplica a cada entrada upstream utilizada para calcularla.

La revisión de características para este escenario podría verse de la siguiente manera:

A continuación, clasifique la fuga según el límite cruzado. La fuga por variable objetivo (target leakage) incluye la etiqueta misma, una variable sustituta (proxy) de ella o una acción posterior al resultado, como el motivo del contracargo o un reembolso completado. La fuga temporal incluye eventos futuros, agregaciones móviles calculadas sobre la línea de tiempo completa, datos tardíos rellenados retrospectivamente y agregaciones realizadas antes de una división temporal. La fuga de entidad incluye copias de una transacción, múltiples filas de un mismo caso, texto casi duplicado o un modelo que memoriza cuentas de validación a través de un identificador (ID). La fuga de preprocesamiento ocurre cuando los valores de imputación, parámetros de escalamiento, vocabularios, selección de características o codificaciones de la variable objetivo se ajustan sobre todos los datos. En ese caso, el proceso de entrenamiento completo ha visto la partición de evaluación incluso si el clasificador final nunca vio sus etiquetas directamente.

La división debe seguir la lógica de producción:

1. Ordene por prediction_at. Utilice los períodos anteriores para el desarrollo y reserve el período contiguo más reciente con etiquetas maduras como el conjunto de prueba final.
2. Ejecute una validación cruzada hacia adelante dentro de los datos de desarrollo: cada pliegue se entrena con datos anteriores y se valida en el período siguiente. Si la observación de etiquetas cruza un límite, purgue el final del entrenamiento o inserte un intervalo (gap) para que las etiquetas de entrenamiento no dependan de resultados del período de validación.
3. Construya grupos de duplicados y grupos de entidades antes de asignar las filas. Si el objetivo es la generalización a entidades no vistas, mantenga cada grupo en un solo lado. Si la producción atiende repetidamente a entidades antiguas, la división temporal sigue siendo la métrica principal, pero informe también una prueba de estrés con aislamiento de cuenta, dispositivo o comercio.
4. Solo un pliegue de entrenamiento puede llamar a fit. Los pliegues de validación y el conjunto de prueba reciben transform a partir de los parámetros aprendidos en ese pliegue de entrenamiento. La codificación de variables objetivo dentro del entrenamiento utiliza ajuste cruzado (cross-fitting) para que la codificación de cada fila provenga de otros pliegues que excluyen su propia etiqueta.
5. Utilice la validación cruzada para seleccionar características, hiperparámetros y el umbral de decisión. Una vez congeladas todas las decisiones, reajuste el modelo una sola vez con todos los datos de desarrollo y evalúe la prueba final una única vez. Continuar modificando el modelo después de leer ese resultado requiere un nuevo conjunto de prueba.

El siguiente pseudocódigo ilustra el flujo de trabajo. forward_splits impone el orden temporal y la separación de la ventana de etiquetas, mientras que make_pipeline vincula cada transformación aprendida al modelo:

dev, test = point_in_time_split(rows, test_period="latest_mature_period")

for train_idx, valid_idx in forward_splits(
    dev,
    time="prediction_at",
    purge="label_horizon",
):
    pipeline = make_pipeline(
        imputer="fit_on_train_fold",
        scaler="fit_on_train_fold",
        target_encoder="out_of_fold",
        model="candidate",
    )
    pipeline.fit(dev[train_idx].X, dev[train_idx].y)
    record(pipeline, dev[valid_idx])

locked_pipeline = select_and_lock()
locked_pipeline.fit(dev.X, dev.y)
final_result = evaluate_once(locked_pipeline, test)

Luego, diagnostique. La primera capa es una auditoría de linaje estática: registre la tabla de origen, el tiempo del evento, el tiempo de disponibilidad, la ventana de agregación, el retraso de actualización y la dependencia de la etiqueta para cada característica, y rechace automáticamente los datos posteriores al límite temporal. La segunda es una auditoría de partición: compare hashes exactos, huellas digitales de duplicados cercanos e intersecciones de ID de entidades. Un grupo de duplicados debe ser una única unidad de división. La tercera es un control negativo experimental: elimine las características más sospechosas, permute las etiquetas dentro de grupos válidos y reemplace la división aleatoria con divisiones temporales o de grupo. Un resultado permutado debería regresar a la línea base sin señal (no-signal baseline). Una caída sustancial bajo una división fiel al despliegue es una alerta de fuga, no una prueba por sí sola.

La cuarta capa es la reproducción puntual en el tiempo. Elija transacciones históricas, congele el reloj del servicio de características en ese momento y compare la fila de entrenamiento fuera de línea con los campos realmente visibles en los registros de servicio. Un valor fuera de línea que incorpora datos rellenados con posterioridad es fuga temporal. Diferentes reglas de cálculo, valores predeterminados o versiones entre ambas rutas constituyen sesgo entre entrenamiento y servicio (training-serving skew). Incluso si ambos son correctos, el cambio en las poblaciones de usuarios o en las tácticas de fraude puede causar desviación de la distribución (distribution drift), por lo que debe comparar entradas, tasas de etiquetas y métricas de segmentos por cohorte de tiempo.

Finalmente, convierta los controles en infraestructura del producto: instantáneas inmutables de conjuntos de datos, manifiestos de división reproducibles, marcas de tiempo de disponibilidad en las definiciones de características, canalizaciones (pipelines) de entrenamiento versionadas y registros de acceso para el conjunto de retención final. Cada nueva característica debe responder a una pregunta: "Para esta fila, ¿podría el sistema de servicio haber calculado exactamente este valor en prediction_at?". Si la respuesta no es clara, no entra en el entrenamiento.

Respuesta de muestra de alta calidad

"Fuga significa que la información cruzó el límite de predicción que pretendemos imponer. Este modelo califica una transacción cuando ocurre, por lo que definiría prediction_at por fila y esperaría la ventana de contracargo de 30 días antes de tratar su etiqueta como madura. Los motivos finales de contracargo y los estados finales de revisión manual son fugas evidentes del resultado. Un conteo de transacciones de la cuenta en siete días parece legítimo, pero también presenta fuga si la instantánea actual del almacén de datos agrega eventos tardíos o posteriores a la predicción a la fila histórica.

Mantendría el tiempo del evento, el tiempo de disponibilidad, la ventana de agregación y la dependencia de la etiqueta para cada característica, y luego reconstruiría los valores con uniones puntuales en el tiempo (as-of joins). El período de tiempo maduro más reciente se sella como el conjunto de prueba, y el desarrollo utiliza validación cruzada hacia adelante. Si la ventana de etiquetas cruza los límites de los pliegues, purgo el límite. Las transacciones duplicadas, los casos y los registros casi duplicados se convierten en grupos antes de la división. Que las cuentas deban aislarse por completo depende de si la producción predice cuentas recurrentes o no vistas; utilizo el caso fiel al despliegue como métrica principal y el aislamiento de entidades como una prueba de estrés de generalización.

La imputación, el escalamiento, la selección de características y la codificación residen en la canalización y se ajustan solo en cada pliegue de entrenamiento. La codificación de la variable objetivo se ajusta de forma cruzada para que la propia etiqueta de una fila no pueda ayudar a codificarla. Los resultados de validación eligen características, hiperparámetros y el umbral. Luego congelo el proceso, lo reajusto sobre todos los datos de desarrollo e inspecciono la prueba final una sola vez.

Para el diagnóstico, audito hashes, duplicados cercanos y solapamiento de entidades entre particiones; realizo ablaciones de características sospechosas y permutación de etiquetas dentro de grupos válidos; y comparo divisiones aleatorias con divisiones temporales o de grupo. También reproduzco características históricas contrastándolas con los registros de servicio. Una puntuación más baja bajo una división temporal solo convierte en sospechoso el límite original. Si los datos puntuales en el tiempo se cruzan, es fuga; si coinciden pero el cálculo en línea difiere, es sesgo entre entrenamiento y servicio; si las canalizaciones coinciden y luego hay degradación en cohortes posteriores, apunta hacia una desviación genuina. El proceso más estricto puede reducir la puntuación fuera de línea, pero produce una estimación adecuada para tomar una decisión de lanzamiento".

Errores comunes

• Llamar fuga únicamente a la exposición de las etiquetas de prueba → Esto pasa por alto características futuras, muestras duplicadas y preprocesamiento sobre datos completos → Audite la ruta de información completa desde los datos sin procesar hasta la selección del modelo.
• Declarar fuga cada vez que la producción se degrada → La desviación, el sesgo de etiquetas y los errores en el servicio también degradan el rendimiento → Compruebe el linaje puntual en el tiempo, la reproducción fuera de línea y las distribuciones de cohortes temporales por separado.
• Escalar o seleccionar características sobre todos los datos antes de dividir → Los datos de evaluación influyen en los parámetros de transformación aprendidos → Divida primero y ajuste la canalización dentro de cada pliegue de entrenamiento.
• Dividir aleatoriamente cada conjunto de datos → Muestras futuras o copias de la misma entidad pueden ingresar al entrenamiento → Elija una estrategia de división según la estructura temporal y de entidades del despliegue.
• Filtrar agregaciones solo por event_at → Los registros tardíos o rellenados retrospectivamente pueden no haber estado visibles en ese momento → Restrinja tanto el tiempo del evento como el tiempo de disponibilidad.
• Desduplicar filas ignorando duplicados cercanos y grupos de casos → El modelo aún puede memorizar muestras casi idénticas → Cree grupos de duplicados y grupos de negocio antes de la asignación.
• Calcular la codificación de la variable objetivo directamente en todas las filas de entrenamiento → La etiqueta de cada fila puede ingresar en su propia característica → Utilice codificación fuera del pliegue (out-of-fold) o una implementación con ajuste cruzado interno.
• Consultar repetidamente el conjunto de prueba y modificar el modelo → La prueba se convierte gradualmente en un conjunto de validación → Mantenga un conjunto de retención final con acceso controlado e inspecciónelo una sola vez tras congelar las decisiones.
• Esperar una "puntuación aleatoria" fija a partir de la permutación de etiquetas → La línea base sin señal varía según la métrica y la distribución de clases → Compare contra la línea base bajo las mismas reglas de muestreo y métricas.
• Eliminar todo el historial de la entidad para eliminar la fuga → Esto puede eliminar información útil genuinamente disponible en producción → Conserve la información disponible al momento de la predicción y evalúela con el límite correcto.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Cuándo es apropiada una división aleatoria?

Es razonable cuando las muestras son aproximadamente independientes e idénticamente distribuidas, el tráfico de producción y los datos recopilados comparten un proceso generativo, y no existe una estructura significativa de tiempo, usuario, dispositivo, lote de experimentos o grupos de duplicados. Los duplicados y los límites de preprocesamiento aún requieren auditoría. Si la tarea en producción predice el futuro, una retención temporal suele ser más fiel.

Pregunta de seguimiento 2: ¿Por qué el etiquetado tardío requiere una purga o un intervalo (gap)?

La etiqueta de una transacción de entrenamiento puede decidirse hasta 30 días después. Si el entrenamiento finaliza inmediatamente antes de que comience la validación, esa etiqueta de entrenamiento puede depender de resultados dentro del período de validación, información no disponible al inicio real de la validación. El límite debe cubrir el horizonte de observación de la etiqueta, o cada límite de entrenamiento debe incluir únicamente etiquetas ya maduras en ese momento.

Pregunta de seguimiento 3: ¿Puede el historial de la misma cuenta ser una característica?

Sí, si el servicio en producción realmente dispone de ese historial en el momento de la predicción y la agregación utiliza únicamente eventos pasados visibles en ese instante. Que una cuenta pueda cruzar entrenamiento y prueba depende del objetivo: consérvela a lo largo del tiempo cuando atienda a cuentas recurrentes, y aísle las cuentas al evaluar la generalización a cuentas no vistas. Informar ambos escenarios evita que una sola puntuación responda a dos preguntas diferentes.

Pregunta de seguimiento 4: ¿Cómo previene el ajuste cruzado (cross-fitting) la fuga en la codificación de la variable objetivo?

Divida los datos de entrenamiento en pliegues. Calcule las estadísticas de categoría de cada pliegue a partir de las etiquetas de los otros pliegues y luego codifique ese pliegue reservado. Por lo tanto, la propia etiqueta de una fila no puede ayudar directamente a construir su característica. La validación y la prueba utilizan asignaciones aprendidas a partir de los datos de entrenamiento correspondientes. El ajuste cruzado corrige la fuga dentro del codificador; no reemplaza la validación temporal o grupal externa correcta.

Pregunta de seguimiento 5: ¿Cómo se distingue la fuga de datos de la desviación de la distribución (distribution drift)?

Primero, utilice la reproducción puntual en el tiempo para demostrar que cada característica fuera de línea estaba disponible en el momento de la predicción. Luego, verifique que los sistemas en línea y fuera de línea calculen los mismos valores para las mismas filas. El fallo en la primera comprobación es fuga; el fallo en la segunda es sesgo entre entrenamiento y servicio. Después de que ambas superen la prueba, los cambios en las entradas, las tasas de etiquetas y las métricas de segmentos a través de cohortes posteriores proporcionan evidencia de desviación. Pueden coexistir múltiples fallas.

Pregunta de seguimiento 6: ¿Qué riesgos adicionales de fuga surgen con modelos preentrenados o modelos de lenguaje grandes (LLM)?

Las muestras de evaluación o duplicados cercanos pueden existir previamente en los datos de preentrenamiento, índices de recuperación o ejemplos de prompts, una vía que no figura en el manifiesto local de entrenamiento/prueba. Utilice conjuntos de retención creados después de la fecha límite de entrenamiento, conjuntos generados de forma privada o conjuntos auditados para detectar duplicados cercanos, y versione los índices de recuperación y los prompts. Cuando no se pueda establecer una ausencia total de solapamiento con los datos de preentrenamiento, describa el resultado como una estimación sujeta a riesgo de contaminación en lugar de una generalización absoluta.