Rules of Machine Learning

NOTA PRELIMINAR

Este apunte es un resumen del documento “Rules of Machine Learning” (Mejores practicas en aprendizaje automático) publicado por Martin Zinkevich en este link. Este resumen no representa lo expuesto en el texto original, es una interpretación. Un video del autor exponiendo mismo tema en la conferencia NIPS-2016 puede verse en este link. Para más referencias sobre el autor Martín Zinkevick, puede verse este link. En este resumen se usan las palabras “feature” y “variables” como sinónimos, y las sigla ML hace referencia al término “machine learning”.

OVERVIEW

En muchos proyectos de machine learning, la mayor  ganancia proviene de la definición de variables y no de algoritmos complejos. En general es importante considerar lo siguiente:

1. Asegurar que el sistema en el que se incluye una solución de machine learning es claro y consistente desde el inicio hasta el final
2. Utilizar conceptos de sentido común y evitar complejidad en primera version
3. Agrega complejidad únicamente cuando ya no existan mayor ganancia de conceptos de sentido común.
4. Revisa constantemente que el punto 1 se mantenga.

Rule #1: No tengas miedo de lanzar un producto sin una solución machine learning. Si no es absolutamente necesario un sistema de machine learning, no lo incluyas. Es mejor esperar hasta tener datos históricos suficientes del producto y luego pensar en machine learning.

Rule #2: Antes de machine learning, implementa métricas y reglas de negocio. Con esto se identifica cualquier dificultad de acceso a la información. Si consideras que una métrica está asociada con una variable, fijate si manipulando esa variable se refleja un cambio de la métrica. Si esto no pasa, entonces el supuesto es falso. Si notas un cambio desde la última actualización de un producto, haz una métrica de ese cambio, porque es determinante.

Rule #3:  Machine Learning es mejor que una heurística compleja

La mayoría de las tareas "predictivas" requieren actualización constante, y las heuristicas complejas son imposible de mantener. Si se tiene definido el objetivo a lograr y se tienen datos históricos, siempre es preferible un modelo de machine learning, porque este es mas fácil de actualizar y con el tiempo será mejor que la heuristica compleja.

FASE 1: Primera implementación

Rule #4: La primera implementación debe ser lo más simple posible y con la menor cantidad de variables posible. Algunas ventajas de tener pocas variables en una primera implementación:

• Pocas variables hacen que un algoritmo aprenda de forma comprensible.
• Al momento de poner en producción, las variables alimentan correctamente el modelo y los errores o desvíos son mínimos y fácil de detectar.
• Tener un modelo en producción con pocas variables y conceptos simples de negocio, permite tener un umbral para evaluar si vale la pena un modelo más complejo.

Rule #5: Valida la infraestructura del sistema independiente de la solución de machine learning

Rule #6: Al copiar un template de trabajo, asegura no estar borrando datos.

Rule #7: Convierte las políticas de negocio en variables. Usualmente los problemas que un modelo con machine learning trata de resolver no son problemas nuevos, y casi siempre existen soluciones (reglas, política de negocio, sistemas, etc.) creadas por un humano que intentan definir y solucionar el problema. Estas soluciones existentes pueden ser usadas de diferentes formas en un sistema de machine learning:

1. Si una regla es buena, agregala, sin profundizar mucho en por qué.
2. Crea variables usando el resultado de las reglas ya creadas.
3. Si existe una métrica que combina múltiples variables, considera agregar esas variables por separado en el sistema de machine learning.
4. Considera modificar el objetivo o variable que se quiere predecir. Por ejemplo, una clase a predecir puede tener mayor impacto si tiene una ponderación, “cantid descargas ponderado por popularidad”.

MONITORING

Rule #8: Identifica la importancia de un modelo actualizado. Si el negocio pierde el 10% de las ganancias por culpa de una desactualización del modelo con machine learning, entonces tiene sentido monitorearlo de forma regular.

Rule #9: Antes de subir un modelo a producción, asegura validarlo en todas las instancias o escenarios posibles.

Rule #10: Da seguimiento a las variables que usa el modelo en producción, haz estadísticas regulares de las variables, como máxima fecha de actualización de las tablas que son input del modelo, cantidad de nulos en último periodo en las tablas, entre otras.

Rule #11: Documenta las variables usadas, para seguirles el rastro cuando fallen.

OBJETIVOS

Rule #12: No inviertas más de lo necesario pensando cual métrica optimizar. Elige la más simple con impacto moderado, porque muchas métricas impactan de forma positiva en otras. Tampoco pierdas tiempo tratando de entrenar un modelo que prediga cosas subjetivas como la felicidad o satisfacción.

Rule #13: Crea una capa lógica por encima del sistema de machine learning, que permita incluir políticas de negocio (policy layer). Estas pueden ser las strong rules o reglas duras que no necesitan ser evaluadas por el algoritmo.

Rule #14: Identificar errores implementando un modelo simple, como regresión lineal o regresión logística (que están basados en modelos de probabilidad), que permite interpretar la predicción como una probabilidad o un valor esperado y luego analizar los errores de predicción muy marcados para detectar errores.

Rule #15: Si es spam, agregalo a la capa de strong rules (ver rule #13), no lo pienses mucho.

FASE 2: Feature Engineering

Rule #16: Nada es para siempre. No esperes que el modelo que implementes sea definitivo o el último, es común actualizarlo trimestral o anualmente. Los motivos pueden ser:

• Agregar nuevas variables.
• Ajustar los parámetros del algoritmo o combinar variables ya existentes
• Ajuste del objetivo o variable a predecir
• Desvíos muy marcados en el modelo en producción

Considera tener dos o tres copias o variantes del modelo, ejecutándose en paralelo. Esto permite comparar los modelo y, en caso necesario, cambiar un modelo por otro de forma rápida en escenarios de urgencia o "ataque".

Rule #17: El primer modelo debe tener variables observables. Las variables o feature que provienen del resultado o predicción de otros modelos son útiles, pero suelen tener muchos inconvenientes y características a validar, por lo que es recomendable no considerarlas en la primera implementación.

Rule #18: Buscar variables en otros contextos. Evaluar el significado de la clase que quieres predecir en otro contexto y crear variables de otros contextos puede ser un gran aporte. Ej: un cliente con alta frecuencia de compra tiene contextos diferentes en marketing y en el área de fraude.

Rule #19: Usar variables directas tanto como se pueda. Cuando se tienen muchos datos, es más fácil entrenar el algoritmo con muchas variables simples, y no con pocas variables complejas.

Rule #20: Transformación de variables. Los métodos más comunes de transformar variables son:

• Discretización: convertir variables continuas en discretas. En estos casos con obtener simplemente los cuantiles es suficiente.
• Cruce (o combinación de variables): Consiste en combinar variables (como multiplicación de dos o más variables). Debe considerarse que este proceso puede producir sobre-aprendizaje  (overfit).

Rule #21: La cantidad de variables que un algoritmo puede aprender está relacionada con la cantidad de observaciones:

• 1000 observaciones: una docena de variables (aprox)
• 10 millones de observaciones: cientos o miles de variables (aprox)
• miles de millones de observaciones: millones de variables (aprox).

Rule #22: Elimina variables que no estés usando, para que las variables más prometedoras puedan ser evaluadas rápidamente.

Rule #23: No evalúes tú mismo el resultado, busca un tercero. Se pueden usar fishfooding, que es testear el producto con compañeros de trabajo y dogfooding, que es testear el producto con compañeros de la misma empresa. Estas pruebas pueden ser útiles, pero con ellas cualquier resultado que sea razonablemente “bueno” tenderá a aceptarse, y los errores no podrán analizarse en detalle y saber por qué suceden. Las personas involucradas en el desarrollo del producto de machine learning no deberían testearlo por dos razones: 1) Están muy cerca del algoritmo y van a buscar errores específicos. 2) El tiempo invertido por una persona del área de desarrollo es muy costoso, y tendría un resultado similar o mejor considerar personas específicas para esto. Siempre considerar que el testeo se haga por personas de ambos sexos.

Rule #24:  Siempre calcula la diferencia entre la predicción y la datos nuevos. También considerar que la suma del error en la predicción sobre los datos de entrenamiento debe ser cercana a cero, si no pasa así puede existir un error.

Rule #25: Lo mas importante al final  siempre es: “qué vas a hacer con la predicción?”. Si existe la oportunidad de mejorar la predicción, pero degradando el desempeño del sistema, debe mirarse otras variables. Si esto pasa con frecuencia, es tiempo de revisar el objetivo del modelo.

Rule #26: Analiza los ejemplos donde el modelo de machine learning se equivoca, y crea nuevas variables que ayuden al modelo a corregir esos errores.

Rule #27: Si existen errores de predicción y son medibles, considera hacer variables de los mismos

Rule #28: Futuro no aprendido. Considera que un cambio de comportamiento no va a estar reflejado en un modelo ya entrenado.

DIFERENCIA EN LAS PREDICCIONES EN PRODUCCIÓN

Rule #29: Guarda los datos que el modelo en producción está usando para predecir. Si no puedes guardar los logs de todos los datos que usa el algoritmo para predecir, hazlo al menos para una pequeña muestra de datos, para luego verificar la consistencia entre los datos de train y los datos de producción.

Rule #30: Borrar datos en train, por el simple hecho de que se tienen muchos, no es una justificación válida. Siempre que sea posible, la mejor opción será usar todos los datos disponibles al momento de entrenar un modelo.

Rule #31: Cambios de las variables. Los datos usados por un modelo en producción pueden cambiar en cualquier momento, y es recomendable hacer reportes para analizar la "sanidad" de los datos.

Rule #32: Usar un único lenguaje, en la medida que sea posible, para entrenar y para la puesta en producción

Rule #33: Fecha de Train y Test. Las fechas de los datos de train y test deben ser lo más cercana posible. Si entrenaste con datos hasta el último día de enero, los datos de test deben ser de los primeros días de febrero.

Rule #34: Sacrifica performance (cuando sea posible) para ganar datos más limpios.

Rule #35: Dispararle a la silla que se mueve. Considera que los datos de entrenamientos pueden estar afectados por una predicción anterior. Ej: un producto es muy elegido porque un algoritmo diferente (o el mismo algoritmo en un momento anterior) hace que siempre se muestre ese producto. Para evitar sesgo, se debe hacer énfasis en la generalización del aprendizaje. (ver doc original para detalle)

Rule #36: Si un producto tiene mejor exposicion, es posible que sea el producto mas elegido, pero no el mejor. Agrega variables de posición o vulnerabilidad para que el algoritmo tambien aprenda esto.

Rule #37: Valida las diferencias entre el performance o desempeño en test y en producción. Algunas de las causas pueden ser estas:

• La diferencia entre training data y holdout data

• Diferencia de performance entre holdout data y datos del día siguiente a la última fecha de datos de train. Si existe mucha diferencia, significa que algunas variables son sensibles al tiempo.
• Cambio en los datos de producción al momento de finalizado el proceso de train.
• Las variables en producción dejaron de actualizarse.
• Una implementación de una versión incorrecta del modelo.

FASE III: Refinando…

Rule #38: Si el objetivo se ha desvirtuado, no pierdas tiempo buscando nuevas variables,debe redefinirse el objetivo o buscar otra métrica a optimizar.

Rule #39: No existen decisiones fáciles al momento de implementar un sistema ML, ya que no es común obtener ganancia en todas las métricas.

Rule #40: Ensambles. Un modelo que aprende de variables directas es el más fácil de interpretar, pero los ensambles que unifican varios modelos tienen mejor resultados, aunque no se puedan interpretar. Para mantener los ensambles simples, un modelo de ensamble debe alimentarse de la salida de otros modelos o del espacio de variables directas, pero no de ambos (ver doc original para mas detalle).

Rule #41 Cuando ya no hay ganancia agregando variables directas, es momento de pensar en una arquitectura completamente diferente que permita agregar variables más complejas. También es momento de empezar a pensar en deep learning.

Rule #42: El contenido popular no está relacionado con la relevancia, la diversidad, o la personalización. Un sistema de recomendación, por ejemplo, puede predecir un contenido popular a un usuario simplemente porque es popular, no por ser relevante para ese usuario. Para los sistemas de ML lo ordinario o común es difícil de describir. Para mejorar esto hay que crear features que apunten a la personalización. (ver detalle en doc original)

Rule #43: Usar un modelo de un producto o sistema similar suele ser común y en algunos casos funciona. Pero en otras situaciones no funciona, aun cuando la semejanza sea muy alta. Esto pasa por el contexto, que puede tener un cambio abismal entre cosas muy parecidas.