Prácticas recomendadas de backfill
Por diversas razones, puede que necesites hacer un backfill de datos, ya sea por errores en los datos, por información nueva (como nuevas características) o para conciliar datos entre dos sistemas. Cuando hagas un backfill, sigue los principios de este artículo para mantener la calidad de los datos y el rendimiento del modelo.
Cuándo es necesario rellenar datos históricos
El relleno de datos históricos (backfilling) es el proceso de completar retroactivamente un conjunto de datos con datos históricos. Algunos escenarios comunes son:
| Escenario | Descripción | Ejemplo |
|---|---|---|
| Nuevas características | Identificaste una nueva métrica que es importante para tu modelo y tienes los registros históricos sin procesar para calcularla. | Agregas la “tasa de click-through” como característica y necesitas tres meses de historial para que el modelo tenga suficientes datos de los que aprender. |
| Recuperación de datos | Tu canalización de datos falló en días específicos, lo que generó vacíos en los datos entregados a Decisioning Studio Pro. | Una interrupción de la canalización el martes dejó un vacío. Después de implementar la corrección, rellenas esos registros faltantes desde el sistema de origen. |
| Cambios de lógica | Actualizaste la fórmula del cálculo de una característica o cambiaste la definición de un evento. | Redefiniste “usuario activo” y necesitas volver a exportar los datos históricos para que el modelo se entrene con la definición actualizada. |
Requisitos
Para que Decisioning Studio Pro funcione correctamente, todos los datos entrantes deben admitir la carga retroactiva de periodos históricos. El periodo retrospectivo específico requerido (medido en meses) depende de los requisitos de entrenamiento del modelo de IA. Consulta con tu equipo de AI Decisioning Services para confirmar el valor correcto para tu caso de uso.
Al realizar una carga retroactiva de datos históricos, los siguientes estándares son obligatorios:
- Coherencia del proceso: Las instantáneas históricas de características deben generarse mediante un proceso totalmente coherente con la creación de instantáneas en vivo. Si tu canalización en vivo aplica transformaciones, agregaciones o filtros, esos mismos pasos deben aplicarse a los datos cargados retroactivamente.
- Coherencia del esquema: El esquema de los datos cargados retroactivamente debe coincidir exactamente con el de la canalización diaria habitual, incluidos los mismos campos, tipos de datos y convenciones de nomenclatura de columnas.
Errores comunes
Fuga de datos (sesgo de anticipación)
La fuga de datos es el error más crítico al completar datos históricos. Ocurre cuando el proceso de relleno incorpora sin querer información que no habría estado disponible en el momento en que se generó el registro histórico.
Por qué es importante
Si el modelo se entrena con datos que “conocen el futuro”, parecerá tener un buen rendimiento durante el entrenamiento, pero producirá malos resultados en producción, porque las decisiones en tiempo real no tienen acceso a datos futuros.
Por ejemplo, imagina que calculas una característica histórica de “valor de duración del ciclo de vida” usando el gasto total de un cliente hasta la fecha (es decir, hasta hoy) y luego usas ese valor para predecir un comportamiento que ocurrió hace meses. En el momento de ese evento histórico, todavía no se conocía el valor de duración del ciclo de vida completo.
Para evitarlo, reconstruye cada característica histórica a partir de la información disponible en la marca de tiempo histórica correspondiente.
Desviación del esquema y de la lógica
Las estructuras de datos y las definiciones de negocio evolucionan con el tiempo. Las incoherencias entre los datos históricos y los datos en vivo pueden degradar en silencio la calidad del modelo.
- Desviación del esquema: Si un campo (por ejemplo,
zip_code) se añadió recientemente a tu base de datos, los registros rellenados anteriores a ese cambio contendrán valores nulos en ese campo. Asegúrate de que tu canalización gestione correctamente los campos que faltan y de que el modelo no dependa demasiado de campos con poca cobertura histórica. - Desviación de la lógica: Si la definición de una métrica cambió en un momento concreto (por ejemplo, “usuario activo” se redefinió en 2024), aplicar la nueva definición de forma uniforme a datos más antiguos (por ejemplo, registros de 2022) puede crear picos o caídas artificiales que en realidad no ocurrieron. Siempre que sea posible, aplica la definición vigente en el momento de cada registro histórico o documenta claramente el punto de ruptura para que el modelo pueda tenerlo en cuenta.
Registros duplicados por trabajos de relleno fallidos
Los trabajos de relleno que fallan a mitad de ejecución y se reinician pueden producir registros duplicados si el proceso no está diseñado para evitarlo. Los registros duplicados inflan artificialmente las métricas e introducen ruido en el entrenamiento del modelo.
La solución: Diseña todos los scripts de relleno para que sean idempotentes: ejecutar el mismo trabajo dos veces debe producir el mismo resultado que ejecutarlo una sola vez. Usa uno de los siguientes patrones:
- Upsert (actualizar o insertar): Usa como clave un ID de transacción único o una marca de tiempo, de modo que volver a insertar un registro existente lo actualice en lugar de crear un duplicado.
- Eliminar y luego insertar: Elimina los registros existentes del intervalo de tiempo de destino antes de insertar, para que el conjunto de datos siempre se reemplace de forma limpia.