The post Sets de Entrenamiento, Test y Validación first appeared on Aprende Machine Learning.
]]>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.
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:
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:
Para evaluar mejor el segundo caso, es donde aparece el “conjunto de Validación”.
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.
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:
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í:
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.
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:
Otras técnicas usadas y que nos provee sklearn para python son:
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 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 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
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 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:
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.
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”.
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.
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!
Otros artículos interesantes en inglés:
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.
]]>The post Interpretación de Modelos de Machine Learning 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”.
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.
Interpretar el Modelos en Machine Learning es la habilidad de explicar su funcionamiento ó presentarlo de manera comprensible al humano.
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.
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:
Del análisis de los modelos podemos obtener:
Veamos algunas de esas técnicas y qué librerías de Python nos brindan estas funcionalidades:
¿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
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
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.
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”.
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.
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.
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.
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!
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)
The post Interpretación de Modelos de Machine Learning first appeared on Aprende Machine Learning.
]]>The post 12 Consejos útiles para aplicar Machine Learning first appeared on Aprende Machine Learning.
]]>No olvides seguir los 7 pasos del Machine Learning
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.
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.
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.
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.
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:
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.
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.
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!!!
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.
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!).
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”):
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.
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.
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
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.
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í
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.
]]>