Existen los casos en que después de entrenar un modelo con resultados del 99% de accuracy, fracasa vergonzosamente cuando se lo expone a un nuevo dataset. En varias oportunidades, la razón de esto se debe al data leakage.
Demasiado bueno para ser verdad
Esto ocurre cuando, de alguna manera, información del test set pasa al training set dando resultados poco realistas.
Un error común es pasar información en la etapa de preproceso. cuando se hace una transformación, esta se debe hacer solo en el set de training, por ejemplo, si se usa PCA, se debe hacer solo en el training y después hacer transform (scikit-learn) en el test set. Si se hace la transformación sobre el total de los datos incluidos el set de prueba, se estaría pasando información por lo que los parámetros generados en el entrenamiento se generarían con cierto conocimiento del set de prueba.
Otro caso es cuando se utilizan datos con dependencia temporal en cross validation. Si no se hace un corte temporal, pueden pasar datos del futuro al set de entrenamiento mientras que después se verifican con datos del pasado resultando en una performance superior a la debida. Los campos de ID pueden generar este efecto y nunca agregan información al modelo.
Nested Cross Validation para Series de tiempo
Predict Second Half
se separa el dataset en dos en forma temporal donde la primera es el training set y la segunda el test set. En este caso hay que tener cuidado con que el validation set sea subsecuente al training set.
Day Forwarding-Chaining
En este caso se usa una porción como training y el día siguiente como test y se va avanzando con repetidos experimentos promediando los resultados de error.
Otros ejemplos se pueden dar donde uno de los atributos, features o columnas llevan implícito información sobre la clase a la que pertenecen. Es el caso de atributo TAMAÑO DE ARCHIVO en una dataset de análisis de comportamiento de usuario donde el archivo en cuestión es el audio del llamado del cliente. Claro está que si el cliente llamó para quejarse, el llamado dura más que si lo hace para otra cosa. Es así que el dataset lleva información a futuro que NO traerá un caso nuevo y si se estima sobre eso, dará resultado optimistas de predicción.
Si se está trabajando sobre una tienda online, y se está armando un modelo para predecir si un cliente comprará joyas basado en compras anteriores y sus montos en joyas, películas y electrónicos. La base de datos podrá verse como esta:
CUSTOMER JEWELRY MOVIES ELECTRONICS
11123 1003.23 24.99 1594.95
11124 0.00 96.45 0.00
11125 58.12 0.00 0.00
11126 0.00 549.20 190.67
11127 8.23 2400.10 523.45
... ... ... ...
Pero la base tiene leakage, generando que el modelo sea muy bueno pero prediga muy mal. El cliente 11125 gastó 0 en movies y electronics. Si el local vende solo jewelry, movies, y electronics, entonces la única manera que tiene de aparecer en la base es que haya gastado en jewelry. Así es como hace predicciones perfectas sobre los clientes que no hayan gastado nada en movies o electronics.
Otra posibilidad es el análisis de riesgo de clientes de un banco de default de crédito. El modelo aprende de una base que tiene los datos del cliente, ingresos, años como cliente, ranking de veraz y si defaulteó o no. Pero cuando se verifica contra el test set, acierta 100% porque el ranking de veraz es muy bajo después del default. Es decir que se tiene información en la base sobre el futuro que no se dispondría en caso de un nuevo cliente a ser evaluado.
En una empresa de telecomunicaciones se desea predecir el churn de sus clientes (cambio de compañía) y entre los datos con los que se entrena el modelo está el nombre del último representante que lo atendió. Resulta que asigna una enorme probabilidad de churn al cliente que es atendido por un determinado representante que resulta ser el encargado de las bajas o retención de clientes. Esto último es erróneo ya que al momento de querer predecir esto, el cliente no ha decidido hacer el cambio ni ha hablando con ningún representante del área.
fuente: TS NCV