Intentaré hacerlo mediante un ejemplo práctico por eso de ser didácticos

Además veremos que tenemos distintas técnicas de hacer la validación del modelo y aplicarlas con Scikit Learn en Python.

Un nuevo Mundo

Al principio de los tiempos, sólo tenemos un conjunto Pangea que contiene todo nuestro dato disponible. Digamos que tenemos un archivo csv con 10.000 registros.

Para entrenar nuestro modelo de Machine Learning y poder saber si está funcionando bien, alguien dijo: Separemos el conjunto de datos inicial en 2: conjunto de entrenamiento (train) y conjunto de Pruebas (test). Por lo general se divide haciendo “80-20”. Y se toman muestras aleatorias -no en secuencia, si no, mezclado.

Para hacer el ejemplo sencillo, supongamos que queremos hacer clasificación usando un algoritmo supervisado, con lo cual tendremos:

• X_train con 8.000 registros para entrenar
• y_train con las “etiquetas” de los resultados esperados de X_train
• X_test con 2.000 registros para test
• y_test con las “etiquetas” de los resultados de X_test

Hágase el conjunto de Test

Lo interesante y a destacar de esto es que una vez los separamos en 8.000 registros para entrenar y 2.000 para probar, usaremos sólo esos 8.000 registros para alimentar al modelo al entrenarlo haciendo:

modelo.fit(X_train, y_train)

Luego de entrenar nuestro modelo y habiendo decidido como métrica de negocio el Accuracy (el % de aciertos) obtenemos un 75% sobre el set de entrenamiento (y asumimos que ese porcentaje nos sirve para nuestro objetivo de negocio).

Los 2.000 registros que separamos en X_test aún nunca han pasado por el modelo de ML. ¿Se entiende esto? porque eso es muy importante!!! Cuando usemos el set de test, haremos:

modelo.predict(X_test)

Como verás, no estamos usando fit()!!! sólo pasaremos los datos sin la columna de “y_test” que contiene las etiquetas. Además remarco que estamos haciendo predicción; me refiero a que el modelo NO se está entrenando ni <<incorporando conocimiento>>. El modelo se limita a “ver la entrada y escupir una salida”.

Cuando hacemos el predict() sobre el conjunto de test y obtenemos las predicciones, las podemos comprobar y contrastar con los valores reales almacenados en y_test y hallar así la métrica que usamos. Los resultados que nos puede dar serán:

1. Si el accuracy en Test es <<cercano>> al de Entrenamiento (dijimos 75%) por ejemplo en este caso si estuviera entre 65 ú 85% quiere decir que nuestro modelo entrenado está generalizando bien y lo podemos dar por bueno (siempre y cuando estemos conformes con las métricas obtenidas).
2. Si el Accuracy en Test es muy distinto al de Entrenamiento tanto por encima como por debajo, nos da un 99% ó un 25% (lejano al 75%) entonces es un indicador de que nuestro modelo no ha entrenado bien y no nos sirve. De hecho este podría ser un indicador de Overfitting.

Para evaluar mejor el segundo caso, es donde aparece el “conjunto de Validación”.

Al Séptimo día Dios creo el Cross-Validation

Si el conjunto de Train y Test nos está dando métricas muy distintas esto es que el modelo no nos sirve.

Para mejorar el modelo, podemos pensar en Tunear sus parámetros y volver a entrenar y probar, podemos intentar obtener más registros, cambiar el preprocesado de datos, limpieza, balanceo de clases, selección de features, generación de features… De hecho, podemos pensar que seleccionamos un mal modelo, y podemos intentar con distintos modelos: de árbol de decisión, redes neuronales, ensambles…

La técnica de Validación Cruzada nos ayudará a medir el comportamiento el/los modelos que creamos y nos ayudará a encontrar un mejor modelo rápidamente.

Aclaremos antes de empezar: hasta ahora contamos con 2 conjuntos: el de Train y Test. El “set de validación” no es realmente un tercer set si no que “vive” dentro del conjunto de Train. Reitero: el set de validación no es un conjunto que apartemos de nuestro archivo csv original. El set de validación se utilizará durante iteraciones que haremos con el conjunto de entrenamiento.

Técnicas de Validación Cruzada

Entonces volvamos a tener las cosas claras: SOLO tenemos conjunto de Train y Test, ok?. El de Test seguirá tratándose como antes: lo apartamos y lo usaremos al final, una vez entrenemos el modelo.

Dentro del conjunto de Train, y siguiendo nuestro ejemplo inicial, tenemos 8.000 registros. La validación más común utilizada y que nos sirve para entender el concepto es “K-folds”, vamos a comentarla:

Cross-Validation: K-fold con 5 splits

Lo que hacemos normalmente al entrenar el modelo es pasarle los 8.000 registros y que haga el fit(). Con K-Folds -en este ejemplo de 5 splits- para entrenar, en vez de pasarle todos los registros directamente al modelo, haremos así:

• Iterar 5 veces:
  1. Apartaremos 1/5 de muestras, es decir 1600.
  2. Entrenamos al modelo con el restante 4/5 de muestras = 6400.
  3. Mediremos el accuracy obtenido sobre las 1600 que habíamos apartado.
• Esto quiere decir que hacemos 5 entrenamientos independientes.
• El Accuracy final será el promedio de las 5 accuracies anteriores.

Entonces fijémonos que estamos “ocultando” una quinta parte del conjunto de train durante cada iteración. Esto es similar a lo que explique antes, pero esta vez aplicado al momento de entrenamiento. Al cabo de esas 5 iteraciones, obtenemos 5 accuracies que deberían ser “similares” entre sí, esto sería un indicador de que el modelo está funcionando bien.

Ejemplo K-Folds en Python

Veamos en código python usando la librería de data science scikit-learn como podemos hacer el cross-validation con K-Folds:

from sklearn import datasets, metrics
from sklearn.model_selection import train_test_split
from sklearn.model_selection import cross_val_score
from sklearn.model_selection import KFold
from sklearn.linear_model import LogisticRegression

iris = datasets.load_iris()

X_train, X_test, y_train, y_test = train_test_split(iris.data, iris.target, test_size=0.2, random_state=0)

kf = KFold(n_splits=5)

clf = LogisticRegression()

clf.fit(X_train, y_train)

score = clf.score(X_train,y_train)

print("Metrica del modelo", score)

scores = cross_val_score(clf, X_train, y_train, cv=kf, scoring="accuracy")

print("Metricas cross_validation", scores)

print("Media de cross_validation", scores.mean())

preds = clf.predict(X_test)

score_pred = metrics.accuracy_score(y_test, preds)

print("Metrica en Test", score_pred)

En el ejemplo vemos los pasos descritos anteriormente:

• Cargar el dataset
• Dividir en Train y Test (en 80/20)
• Creamos un modelo de Regresión Logística (podría ser otro) y lo entrenamos con los datos de Train
• Hacemos Cross-Validation usando K-folds con 5 splits
• Comparamos los resultados obtenidos en el modelo inicial, en el cross validation y vemos que son similares.
• Finalmente hacemos predict sobre el Conjunto de Test y veremos que también obtenemos buen Accuracy

Más técnicas para Validación del modelo

Otras técnicas usadas y que nos provee sklearn para python son:

Stratified K-Fold

Statified K-fold es una variante mejorada de K-fold, que cuando hace los splits (las divisiones) del conjunto de train tiene en cuenta mantener equilibradas las clases. Esto es muy útil, porque imaginen que tenemos que clasificar en “SI/NO” y si una de las iteraciones del K-fold normal tuviera muestras con etiquetas sólo “SI” el modelo no podría aprender a generalizar y aprenderá para cualquier input a responder “SI”. Esto lo soluciona el Stratified K-fold.

Leave P Out

Leave P Out selecciona una cantidad P por ejemplo 100. Entonces se separarán de a 100 muestras contra las cuales validar y se iterará como se explico anteriormente. Si el valor P es pequeño, esto resultará en muchísimas iteraciones de entrenamiento con un alto coste computacional (y seguramente en tiempo). Si el valor P es muy grande, podría contener más muestras que las usadas para entrenamiento, lo cual sería absurdo. Usar esta técnica con algo de sentido común y manteniendo un equilibrio entre los scores y el tiempo de entreno.

ShuffleSplit

ShuffleSplit primero mezcla los datos y nos deja indicar la cantidad de splits (divisiones) es decir las iteraciones independientes que haremos y también indicar el tamaño del set de validación.

Instala tu ambiente de Desarrollo Python siguiendo esta guía paso a paso

Series Temporales: Atención al validar

Para problemas de Series temporales tenemos que prestar especial cuidado con los datos. Pues si pasamos al modelo “dato futuro” antes de tiempo estaríamos haciendo Data Leakage, esto es como si le hiciéramos spoiler al modelo y le contaremos el final de la película antes de que la vea. Esto causaría overfitting.

Para empezar al hacer el split inicial de datos estos deberán estar ordenados por fecha y no podemos mezclarlos.

Para ayudarnos con el cross-validation sklearn nos provee de TimeSeriesSplit.

TimeSeriesSplit

TimeSeriesSplit es una variante adaptada de K-folds que evita “la fuga” de datos. Para hacerlo va iterando los “folds” de a uno (usando una ventana de tiempo que se desplaza) y usando el “fold más reciente” cómo el set de validación. Se puede entender mejor viendo una animación:

Practicar con un ejercicio en Python de Series Temporales!

Pero entonces? Cuando uso Cross-Validation?

Es una buena práctica usar cross-validation en nuestros proyectos. De hecho usarlo nos ayudará a elegir el modelo correcto y nos da mayor seguridad y respaldo ante nuestra decisión.

PERO… (siempre hay un pero)

En casos en los que hacer 1 sólo entrenamiento “normal” tome muchísimo tiempo y recursos, podría ser nuestra perdición. Imaginen que hacer un k-folds de 10 implica hacer 10 entrenos -aunque un poco más pequeños-, pero que consumirían mucho tiempo y dinero.

Entonces en la medida de lo posible siempre usar validación cruzada. Y -vuelvo a reforzar el concepto- luego se probará el modelo contra el conjunto de Pruebas (test).

Para hacer tuneo de Hiper-parámetros como RandomSearch, GridSearch ó Tuneo Bayesiano es muy útil hacer Cross-Validation.

¿Si ya estoy “conforme” y quiero llevar el modelo a un entorno de Producción?

Supongamos que el entrenamiento haciendo Cross Validation y el predict() en Test nos están dando buenos accuracy (y similares) y estamos conformes con nuestro modelo. PUES si lo queremos usar en un entorno REAL y productivo, ANTES de publicarlo es recomendado que agreguemos el conjunto de test al modelo!!!, pues así estaremos aprovechando el 100% de nuestros datos. Espero que esto último también se entienda porque es super importante: lo que estoy diciendo es que si al final de todas nuestras iteraciones, pre procesado de dato, mejoras de modelo, ajuste de hiper-parámetros y comparando con el conjunto de test, estamos seguros que el modelo funciona correctamente, es entonces ahora, que usaremos las 10.000 muestras para entrenar al modelo, y ese modelo final, será el que publicamos en producción.

Es una última iteración que debería mejorar el modelo final aunque este no lo podemos contrastar contra nada… excepto con su comportamiento en el entorno real.

Si esta última iteración te causara dudas, no la hagas, excepto que tu problema sea de tipo Serie Temporal. En ese caso sí que es muy importante hacerlo o quedaremos con un modelo que no “es el más actual”.

Resumen, Conclusiones y por favor Que quede claro!

Lo más importante que quisiera que quede claro es que entonces tenemos 2 conjuntos: uno de Train y otro de Test. El “conjunto de validación” no existe como tal, si no, que “vive temporalmente” al momento de entrenar y nos ayuda a obtener al mejor modelo de entre los distintos que probaremos para conseguir nuestro objetivo. Esa técnica es lo que se llama Validación Cruzada ó en inglés cross-validation.

NOTA: en los ejemplos de la documentación de sklearn podremos ver que usan las palabras train y test. Pero conceptualmente se está refiriendo al conjunto de validación y no al de Test que usaremos al final. Esto es en parte el causante de tanta confusión con este tema.

Tener en cuenta el tamaño de split 80/20 es el usual pero puede ser distinto, y esta proporción puede cambiar sustancialmente las métricas obtenidas del modelo entrenado! Ojo con eso. El tamaño ideal dependerá del dominio de nuestro problema, deberemos pensar en una cantidad de muestras para test que nos aseguren que estamos el modelo creado está funcionando correctamente. Teniendo 10.000 registros puede que con testear 1000 filas ya estemos conformes ó que necesitemos 4000 para estar mega-seguros. Por supuesto debemos recordar que las filas que estemos “quitando” para testear, no las estamos usando al entrenar.

Otro factor: al hacer el experimento y tomar las muestras mezcladas, mantener la “semilla” ó no podremos reproducir el mismo experimento para comparar y ver si mejora o no. Este suele ser un parámetro llamado “random_state” y está bien que lo usemos para fijarlo.

Recomendaciones finales:

• En principio separar Train y Test en una proporción de 80/20
• Hacer Cross Validation siempre que podamos:
  • No usar K-folds. Usar Stratified-K-folds en su lugar.
  • La cantidad de “folds” dependerá del tamaño del dataset que tengamos, pero la cantidad usual es 5 (pues es similar al 80-20 que hacemos con train/test).
  • Para problemas de tipo time-series usar TimeSeriesSplit
• Si el Accuracy (ó métrica que usamos) es similar en los conjuntos de Train (donde hicimos Cross Validation) y Test, podemos dar por bueno al modelo.

Recibe los artículos del Blog

Recibe los próximos artículos sobre Machine Learning, estrategias, teoría y código Python en tu casilla de correo!

NOTA: algunos usuarios reportaron que el email de confirmación y/o posteriores a la suscripción entraron en su carpeta de SPAM. Te sugiero que revises y recomiendo que agregues nuestro remitente a tus contactos para evitar problemas. Gracias!

Recursos Adicionales

Otros artículos interesantes en inglés:

• Documentación Scikit Learn sobre Cross Validation y ejemplos en código Python
• 5 reasons why you should use Cross Validation
• Random Forest and K-fold cross validation

El libro del Blog

Si te gustan los contenidos del blog y quieres darme una mano, puedes comprar el libro en papel, ó en digital.

The post Sets de Entrenamiento, Test y Validación first appeared on Aprende Machine Learning.

La interpretación de las decisiones tomadas por nuestros algoritmos de Machine Learning pasa a un plano muy importante: para comprender el modelo y mejorarlo, evitar “biases” (ó descubrirlos), para justificar nuestra confianza en el modelo y hasta legalmente pues es requerido por leyes como la GDPR -para decisiones delicadas como puede ser dar ó no un crédito a una persona-.

Si nuestro algoritmo tuviera que detectar enfermedades y suponiendo que logramos una tasa de aciertos del 90% ¿no te parecería lógico comprender cómo lo ha hecho? ¿es puro azar? ¿está teniendo en cuenta combinaciones de características que nosotros no contemplamos?

Si de pequeño eras curioso y querías sabes cómo funcionaban las cosas: relojes, autos, ó hasta el mismísimo ordenador… serás un poco como yo… y… no siempre nos convence el concepto de “caja negra”.

Abriendo la Caja negra

El concepto de caja negra a veces es muy beneficioso, en sistemas decimos “yo al método le tiro estos parámetros y me devuelve true ó false”. Genial, con eso nos basta. Podemos trabajar en equipos distribuidos, intercambiar interfaces y listo. Podemos confiar en otras librerías ó paquetes “sin saber cómo lo hacen” pero que nos resuelven problemas. Y las encajamos como piezas de un puzzle.

Los algoritmos de Machine Learning, hasta ahora funcionaban muy de ese modo. Es decir, podemos hacer una red neuronal de 10 capas con 80 neuronas cada una, dropout, recurrencia y que nos dé unas buenas clasificaciones. Pero ¿qué pasa por dentro? ¿cómo hizo? ¿es magia?… esas oscuras épocas de incertidumbre deben acabar y deberemos tomar control de porqué se hacen las cosas como se hacen.

Explainable Machine Learning

Interpretar el Modelos en Machine Learning es la habilidad de explicar su funcionamiento ó presentarlo de manera comprensible al humano.

¿Por qué es importante interpretar los modelos?

Imaginemos que nuestro algoritmo decidirá a qué empleado le daremos un ascenso, dadas sus características e historia en la empresa. Y luego de entrenar el modelo vemos que “aparentemente da buenos resultados” pero… todas las elecciones para puestos gerenciales son siempre para hombres y ninguna mujer…. mmmm.. sospechoso, ¿no?

Ese modelo “aprendió” que durante los últimos 10 años, los cargos gerenciales de esa empresa siempre fueron para hombres. Si ese algoritmo pasa a producción, estará discriminando a las mujeres e impidiendo su ascenso.

Entonces ¿Cómo hacemos para interpretar el modelo?

Respuesta corta: con otro modelo que ayude a los humanos a interpretar los procesos.

Hay que decir que modelos como “1 árbol de decisión pequeño” ó clasificación lineal, pueden llegar a interpretarse por su gráfica y/o fórmula (repito: si son sencillos). Sin embargo un Random Forest ó las Redes Neuronales son complejas y prácticamente imposibles de comprender <<de un vistazo>>.

Los beneficios de la “interpretabilidad de los modelos “son:

• Dar confiabilidad en los resultados.
• Ayudar en el Debugging.
• Informar a la Ingeniería de Características (Feature Engineer).
• Detectar necesidad de colectar nuevas muestras.
• Ayudar a una persona en la toma de decisiones.
• Mayor seguridad/robustez en el modelo obtenido.

Técnicas de Interpretación de modelos

Del análisis de los modelos podemos obtener:

• Características más importantes (features)
• Para una predicción en particular del modelo, el efecto que tuvo en ella cada característica
• Efecto de cada característica en el global de las predicciones del modelo

Veamos algunas de esas técnicas y qué librerías de Python nos brindan estas funcionalidades:

1- Permutation Importance

¿Cuales de las features piensa el modelo que son más importantes? ¿Qué Características tienen mayor impacto en las predicciones? Estos conceptos son conocidos como “Feature Importante” y “Permutation Importance” y nos sirven para calcular nuestras características de entrada al modelo. Nos sirve para poder ver cuando nuestro modelo está funcionando de manera contra-intuitiva y también para demostrar a terceros cuando el funcionamiento es correcto.

Para hacer Permutation Importante debemos primero entrenar un modelo y “encajarlo” (fit). Luego tomamos el set de validación y tomamos las features una por vez: por ejemplo, tomamos la primer columna de entrada y mezclamos todos sus valores entre sus filas (pero el resto de features se mantienen igual). Entonces hacemos predicción usando el mismo modelo entrenado y deberían empeorar los resultados. Si “desmejoran mucho” es que esa feature era muy importante. En cambio, si no afecta demasiado, tampoco variarán mucho las predicciones obtenidas y quiere decir que esa característica no es relevante. Y así lo hacemos con todas las características, desordenando de a una a la vez.

Podemos utilizar la librería ELI5 para Python para visualizar la Permutation Importance

2- Partial Dependence Plots (PDP)

Los PDPs muestran el efecto marginal de una o dos características que tienen sobre la predicción dictada por un modelo. Los PDPs muestran cómo afectan las distintas características a las predicciones. El PDP puede mostrar la relación entre nuestra variable de salida y una ó dos características de entrada.

Lo que hacemos en tomar de a una sola fila, e ir variando los valores de una sola de las features (que queremos investigar) contra un modelo YA entrenado. Entonces veremos en que intervalos esa característica afecta a los resultados del modelo.

Lo podemos hacer hasta con 2 variables a la vez usando “2D Partial Plots” y visualizarlo.

Para esto podemos utilizar la librería PDPBox

3-SHAP Values (en predicciones individuales)

SHAP viene de “Shapley Additive exPlanation” y está basado en la teoría de Juegos para explicar cómo cada uno de los jugadores que intervienen en un “juego colaborativo” contribuyen en el éxito de la partida. Con esto podemos comprender una predicción y como impacta cada feature. Podemos decir que la interpretabilidad que nos ofrecen los valores SHAP es de las mejores.

De manera muy sencilla -e incompleta- de cómo se calculan estos valores podemos imaginar a una grupo de desarrolladores, testers, arquitectos y managers (features) que trabajan en conjunto (“juegan”/colaboran) para crear un Sistema de Software y queremos saber cuánto contribuyó cada uno de ellos en su producción. Lo que haremos es ir intercalando a los participantes en diversos “orden de aparación” ABCD, ABDC, ADBC, etc. e ir midiendo la <<contribución marginal>> de cada participante cada vez. Con ello sacar el promedio de cada uno y tendremos los valores Shapley que nos indican cuánto contribuyo cada jugador a conseguir el resultado obtenido.

Supongamos que tenemos que explicar a una persona por qué se ha rechazado su solicitud de un crédito -esto es, una única predicción, y no “el accuracy global” del modelo- los valores SHAP nos muestran cuales características que alimentan al modelo <<empujan>> a la denegación (ó aceptación) esa petición en concreto.

Utilizamos la librería SHAP para python para obtener estos valores.

4- Usos avanzados de Shap (comprensión global)

Si recopilamos muchos valores Shap podremos tener una mejor comprensión del modelo en su conjunto. De allí aparecen las gráficas “Shap Summary Plot” y “Shap Dependence Contribution Plot”.

Shap Summary Plot

Calculando los Shap Values de cada muestra, podemos obtener esta Visualización que nos muestra cuales características son las más importantes y el rango de valores donde afecta al set de datos.

Shap Dependence Contribution Plot

Esta gráfica es similar a la de los PDPs (vistos en el punto 2) pero nos dan mucho mayor detalle.

No puedo dejar de mencionar a una gran librería para ML Interpretability llamada LIME (Local Interpretable Model Explanation) y que nos ofrece comprensión a humanos para modelos de NLP (destacando visualmente palabras en el texto) y para imágenes clasificadas por una CNN (mostrando las áreas en donde “mira” la red).
También mencionar otra Librería Python llamada Skater -es de Oracle- y aunque aún está en desarrollo, provee de buenas herramientas.

Conclusión

La importancia de la interpretabilidad de los modelos de Machine Learning es crucial para poder justificar y comprender las predicciones y/o resultados obtenidos y hasta legalmente. Es curioso que necesitemos “modelos que expliquen como funcionan los modelos” para poder “bajar” a entendimiento humano la complejidad de lo que ocurre en nuestras máquinas de aprendizaje. Finalmente, aplicando diversos métodos, Permutation Importance, los PDP y los Shap Values logramos obtener transparencia en nuestro desarrollo y un panorama claro sobre cómo funciona nuestro engranaje para obtener los resultados.

Suscribe al Blog

Recibe los nuevos artículos sobre Aprendizaje Automático, teoría y el código Python

NOTA: algunos usuarios reportaron que el email de confirmación a la suscripción entraron en la carpeta SPAM. Te sugiero que revises y recomiendo agregar el remitente a tus contactos. Gracias!

Recursos Adicionales

Te recomiendo sobre todo y para pasar al Código este curso completo en Kaggle: Machine Learning Explainability

Algunos artículos y videos sobre Interpretación de Modelos (en inglés)

• Libro muy bueno! Interpretable Machine Learning 
• artículo Hands-on Machine Learning Model Interpretation
• (artículo) Interpretable Machine Learning
• Video (1:30hs) Open the black box: an intro to model interpretability
• Video (1:30hs) Interpretable ML for Computer Vision
• One Method to Rule Them All: Shap Values
• Derisking ML and Artifitial Intelligence
• The Mythos of Model Interpretability

The post Interpretación de Modelos de Machine Learning first appeared on Aprende Machine Learning.

No olvides seguir los 7 pasos del Machine Learning

Vamos al grano!

Con el objetivo de ilustrar mejor estos consejos, nos centraremos en la aplicación del Machine Learning de Clasificar, pero esto podría servir para otros usos.

Los 3 componentes del Aprendizaje Automático

Supongamos que tienes un problema al que crees que puedes aplicar ML. ¿Qué modelo usar? Deberá ser una combinación de estos 3 componentes: Representación, evaluación y optimización.

• Representación: Un clasificador deberá poder ser representado en un lenguaje formal que entienda el ordenador. Deberemos elegir entre los diversos algoritmos que sirven para resolver el problema. A este conjunto de “clasificadores aptos” se les llamará “espacio de hipótesis del aprendiz”. Ej: SVM, Regresión Logística, K-nearest neighbor, árboles de decisión, Redes Neuronales, etc.
• Evaluación: Se necesitará una función de evaluación para distinguir entre un buen clasificador ó uno malo. También es llamada función objetivo ó scoring function. Ejemplos son accuracy, likelihood, information gain, etc.
• Optimización: necesitamos un método de búsqueda entre los clasificadores para mejorar el resultado de la Evaluación. Su elección será clave. EJ: Descenso por gradiente, mínimos cuadrados, etc.

Lo más importante es lograr la Generalización de la máquina

El objetivo fundamental del Machine Learning es lograr la generalización del conocimiento más allá de las muestras tomadas en el conjunto de entrenamiento. Es es porque por más que entrenemos con muchísimos datos, es poco probable que se vuelvan a dar esos mismos casos al testear nuestra máquina. Por más que usemos “un millón de fotos de gatitos” para entrenar, siempre habrá fotos nuevas ó distintas que nuestro modelo desconoce. Entonces la magia ocurrirá si nuestro algoritmo es capaz de generalizar lo aprendido durante el entrenamiento y puede detectar “al gatito millón uno”. Siempre es conveniente guardar una parte de nuestro set de datos para poder validar lo aprendido durante el entrenamiento, con muestras que la máquina nunca ha visto y comprobar que sigue dando un buen resultado.

Los datos solos, no alcanzan

Siendo la generalización el objetivo del ML trae como consecuencia que sólo con datos “no alcanza”, no importa con cuántos contemos.

¿Entonces cómo podemos pretender que nuestras máquinas aprendan algo? Afortunadamente, en este proceso de inducción que realizamos con los algoritmos logramos llegar a ciertos niveles que nos dan buenos resultados.

El machine learning no hace magia. Sin datos no funcionará. Lo que hace es “sacar más con poco“. Y claro, cuantos más datos mejor. Pero no lo son todo. Deberemos combinar “conocimiento” con los datos.

El Overfitting tiene muchas caras

Si al entrenar nuestro modelo obtenemos resultados <<demasiado buenos>> con 100% aciertos y en el set de test apenas alcanzamos un 50% (ó menos!) es muy probable que nos hayamos topado con en “el gran problema del ML”: el overfitting.

Pero debemos saber que podemos “caer” en el overfitting de diversas maneras, a veces sin darnos cuenta. Dos de sus caras son:

• Bias (ó sesgo): es la tendencia a aprender -equivocadamente- algo falso.
• Varianza: es la tendencia a aprender algo random no relacionado con la realidad.

A veces puede ocurrir que un algoritmo -aprendiz- que “parece menos potente”, obtenga mejor resultado que uno “super poderoso” que cae en overfitting. A tener en cuenta

Es difícil evitar el Overfitting, se puede utilizar Regularización ó la validación cruzada (cross validation), u otras técnicas pero ninguna nos asegura evitarlo del todo. Muchas veces ocurre que al querer corregir la varianza, caemos en Bias… y viceversa. Lograr evitar ambos en simultáneo es “el desafío” que tenemos.

A veces falla “la intuición” con muchas dimensiones

Cuando tenemos muchas features, por ejemplo 100 ó más, puede que alguno de nuestros algoritmos de aprendizaje “se vuelva loco”… es decir, que no logre generalizar ó que lo haga mal. A esto se le llamó “la maldición de la dimensionalidad” (Bellman, 1961). Esto dependerá también de la distribución de los datos de entrada, pero para entenderlo: con k-nearest neighbor es <<fácil visualizar en 2 ó 3 dimensiones>> los clusters. Pero al aumentar dimensiones puede ocurrir que para el algoritmo todos los puntos sean vecinos cercanos unos de otros, devolviéndonos resultados aleatorios.

Debemos tener esto en cuenta y si fuera el caso utilizar algún algoritmo de reducción de dimensiones – PCA, t-SNE- para aplacar el problema.

Que se cumplan supuestos teóricos no nos garantiza nada

Al aprender ML podemos leer en papers, ó en cursos y artículos algunas afirmaciones teóricas que intentan ayudarnos y guiarnos. Bueno, como el ML es un fenómeno muy complejo y depende tanto de cada problema en particular, las dimensiones y los datos de entrada (su distribución), los casos positivos/negativos que tengamos de las muestras y de tantas otras variables, es posible que muchos de esos supuestos teóricos NO nos ayuden en nuestro “problema particular”.

Esto puede sonar muy decepcionante, y en parte lo es. Pero esto debemos saberlo para contrastar nuestros datos y no confiar en que “como a Fulanito le dio así, a mi también me funcionará”. Con sólo variar un parámetro, o un sólo dato de entrada de nuestro conjunto de entrenamiento, podemos obtener resultados completamente distintos. Estar alertas!!!

La clave está en la Ingeniería de Características (Feature Engineer)

Seguramente pasemos mucho más tiempo seleccionando los features, transformando, preprocesando que el tiempo dedicado a preparar/ejecutar el algoritmo de Machine Learning. Muchas veces el desafío será si tenemos pocas dimensiones ser creativos y poder generar nuevas y útiles características, ó en caso de tener muchas poder seleccionar cuales serán realmente valiosas y cuales descartar.

Deberemos ser cuidadosos: si tenemos muchas features, podemos evaluarlas individualmente y pensar que algunas no aportan demasiado valor. Sin embargo, esas mismas características puede que sean imprescindibles si las consideramos en combinación con otras. Eh ahí nuestro ingenio y mucha prueba y error.

Una gran herramienta es la Interpretación de Modelos por Importancia de Features, Los SHAP Values y más gráficas que comento en este nuevo artículo!

Más muestras superan a un algoritmo complejo

Conseguir más muestras para entrenamiento utilizando un algoritmo “simple”, puede ser mejor que un algoritmo complejo que “tarde tanto en ejecutar y no termina nunca”.

En ciencias de la computación, solíamos tener dos limitantes: tiempo y recursos cómo la memoria. Ahora, con el Machine Learning aparece una tercera: los datos de entrenamiento. Actualmente podemos encontrar cantidades masivas de datos y nuestro “cuello de botella” es el tiempo.

Si bien contar con “más y más datos” es bueno y hasta impulsa la creación de modelos (algoritmos) más complejos para aprovecharlos, se da una paradoja: en la práctica algoritmos “más simples” pueden obtener buenos resultados en tiempo razonable contra algoritmos complejos que tardan una eternidad.

Entonces el consejo es: al afrontar un problema, empecemos probando con los modelos más sencillos a más complejos (si hiciera falta!).

Ensamble de Modelos

Está bien aplicar un modelo para resolver el problema. Pero estudios han demostrado que hacer ensamble de modelos muchas veces mejora significativamente los resultados. Esto consiste en combinar más de un modelo (por ej. una red neuronal, K-nn, árboles, etc). Las tres técnicas más utilizadas son (ejemplo para clasificadores de “perros y gatos”):

• Bagging: alimentamos diversos modelos haciendo resamplig de las muestras y finalmente hacemos una votación (voting) con la clasificación obtenida (Supongamos que dos de tres modelos dicen “gato” y uno dice “perro”, ganarían los felinos)
• Boosting: en este caso, utilizamos un modelo “potenciandolo” a detectar únicamente perros y otro a detectar sólo gatitos.
• Stacking: utilizaremos diversos modelos, apilados “uno detrás de otro”, es decir, la salida del primero puede ser la entrada (ó un feature) del siguiente modelo y así sucesivamente. Para una famosa competición de Netflix, el ganador había encadenado más de 100 modelos!!

Simplicidad no implica precisión

Hubo un postulado algo confuso que parecía decir que al aplicar un modelo simple obteníamos la mayor precisión (frente a uno complejo). Sin embargo no hay que confundir: la simpleza no implica mayor precisión, esto se puede comprobar fácilmente con el punto anterior, pues al hacer ensamble de stacking de modelos vemos claramente que no se deteriora el resultado y en todo caso lo puede mejorar. Entonces podemos optar por modelos simples que “ya cuentan” con ventajas intrínsecas -probablemente en tiempo y coste- pero no necesariamente por la precisión del resultado.

Un problema “Representable”, no implica que pueda resolverse con Aprendizaje Automático

Podemos tender a pensar que para cualquier problema que podamos representar podrá ser construida una máquina que lo resuelva. Sin embargo hay problemas que nunca podrán ser “aprendidos” por una máquina, pues por ejemplo no tenemos las muestras suficientes para que generalice. En esos casos, podemos fácilmente encontrar la representación pero no lograremos dar con una solución en ML.

La correlación no implica causa

Para alimentar nuestras máquinas de Aprendizaje Automático utilizamos datos que son “muestras observables” donde la variable predictiva no está bajo control del algoritmo (en contraposición a muestras experimentales). Por esto es que las correlaciones que encontremos pueden ser interpretadas como señales de “responsabilidad” de la causa del problema. La realidad es que no necesariamente esa correlación implica la causa si no que son una buena pista para ponernos a investigar las conexiones que llevan a esos resultados.

Recomendado: Aprende a hacer el Análisis Exploratorio de Datos con Pandas/Python

Conclusión

Este gran paper de Pedro Domingos nos abre un poco los ojos sobre diversas trampas en las que podemos caer al trabajar en Machine Learning. Hace unos -pocos- años surgieron papers sobre Interpretación de Modelos de ML que comento en mi nuevo artículo y que dan luz a poder maniobrar ante situaciones problemáticas.

Moraleja en tiempos de IA

Personalmente creo que la “gran enseñanza” que nos deja es que debemos estar atentos, no confiarnos ni de datos, ni de algoritmos, ni de soluciones mágicas. Debemos ser muy profesionales y científicos, mucha prueba y error, validación y comprobación de los resultados. Y una vez hecho esto… volver a comprobar!

Descarga el paper original desde aquí

Suscripción: Nuevos artículos

Recibe los nuevos artículos sobre Aprendizaje Automático, teoría y práctica Python en tu casilla de correo!

NOTA: algunos usuarios reportaron que el email de confirmación a la suscripción entraron en la carpeta SPAM. Te sugiero que revises y recomiendo agregar el remitente a tus contactos. Gracias!

The post 12 Consejos útiles para aplicar Machine Learning first appeared on Aprende Machine Learning.