Ciencia De Datos Para Startups: Data Pipelines - Parte 1
Apr 12, 202016 minutes read
Source: TheDigitalArtist at pixabay.com
La tercera parte de mi serie en curso sobre la construcción de una disciplina de ciencia de datos en una startup. Puedes encontrar enlaces a todas las publicaciones en la introducción, y un libro basado en esta serie en Amazon.
La construcción de pipelines (tuberias) de datos es un componente básico de la ciencia de datos en una startup. Para poder construir productos basados en datos, es necesario ser capaz de recolectar puntos de datos de millones de usuarios y procesar los resultados casi en tiempo real. Mientras que mi anterior entrada en el blog hablaba de qué tipo de datos hay que recolectar y cómo enviar los datos a un endpoint de una API, esta entrada tratará de cómo procesar los datos que se han recolectado, permitiendo a los científicos de datos trabajar con los datos.
La próxima entrada del blog sobre la producción de modelos discutirá cómo desplegar modelos en esta plataforma de datos.
Típicamente, el destino de una tubería de datos es un lago de datos (data lake), como Hadoop o archivos de parquetes en S3, o una base de datos relacional, como Redshift. Un conducto de datos ideal debería tener las siguientes propiedades:
Baja latencia de eventos: Los científicos de datos deberían ser capaces de consultar los datos de eventos recientes en la tubería, en cuestión de minutos o segundos después de que el evento sea enviado al punto final de recolección de datos. Esto es útil para fines de testing y para construir productos de datos que necesitan actualizarse casi en tiempo real.
Escalabilidad: Una tubería de datos debería poder escalar a miles de millones de puntos de datos, y potencialmente a trillones a medida que el producto se va escalando. Un sistema de alto rendimiento no sólo debería poder almacenar estos datos, sino también poner a disposición el conjunto completo de datos para su consulta.
Consulta interactiva: Un sistema de datos de alto rendimiento debería permitir tanto consultas por lotes de larga duración como consultas interactivas más pequeñas que permitan a los científicos de los datos explorar tablas y comprender el esquema sin tener que esperar minutos u horas al tomar muestras de los datos.
Versiones: Debería ser capaz de hacer cambios en su tubería de datos y en las definiciones de los eventos sin que la tubería se caiga y se pierdan los datos. En este post se discutirá cómo construir una tubería que soporte con diferentes definiciones de eventos, en el caso de cambiar un esquema de eventos.
Monitoreo: Si un evento ya no se recibe, o si ya no se reciben datos de seguimiento para una región en particular, entonces el conducto de datos debería generar alertas a través de herramientas como PagerDuty.
Testing: Debería poder probar su tubería de datos con eventos de prueba que no terminen en su lago de datos o base de datos, pero que sí prueben los componentes en la tubería.
Hay una serie de otras propiedades útiles que un conducto de datos debe tener, pero este es un buen punto de partida para una startup. A medida que comience a construir componentes adicionales que dependen de su tubería de datos, querrá configurar herramientas para la tolerancia a las fallas y la automatización de tareas.
Este artículo mostrará cómo configurar un conducto de datos escalable que envíe datos de seguimiento a un lago de datos, una base de datos y un servicio de suscripción para su uso en productos de datos. Discutiré los diferentes tipos de datos en un conducto, la evolución de los conductos de datos, y recorreré un ejemplo de conducto implementado en GCP con PubSub, DataFlow y BigQuery.
Antes de desplegar una tubería de datos, querrá responder a las siguientes preguntas, que se asemejan a nuestras preguntas sobre las especificaciones de rastreo o tracking:
¿Quién es el propietario del conducto de datos?
¿Qué equipos consumirán los datos?
¿Quién controlará la tubería?
En una organización pequeña, un científico de datos puede ser el responsable del conducto, mientras que las organizaciones más grandes suelen tener un equipo de infraestructura que se encarga de mantener el conducto en funcionamiento.
También es útil saber qué equipos consumirán los datos, de modo que se puedan transmitir los datos a los equipos apropiados. Por ejemplo, es posible que el departamento de marketing necesite datos en tiempo real de las visitas a una landing page para realizar la atribución de las campañas de marketing.
Y, por último, la calidad de los datos de los eventos pasados al conducto debe ser inspeccionada minuciosamente de manera regular.
A veces, la actualización de un producto hará que un evento de tracking deje caer datos relevantes, por lo que se debe establecer un proceso para capturar estos tipos de cambios en los datos.
Tipos de datos Los datos en una tuberia suelen denominarse con diferentes nombres en función de la cantidad de modificación que se haya realizado. Los datos se clasifican típicamente con las siguientes etiquetas:
Datos en bruto (Raw data): Es el seguimiento de datos sin procesamiento aplicado. Son datos almacenados en el formato de codificación de mensajes utilizado para enviar eventos de rastreo, como JSON. Los datos brutos no tienen todavía un esquema aplicado. Es común enviar todos los eventos de rastreo como eventos sin procesar, porque todos los eventos pueden ser enviados a un solo endpoint y los esquemas pueden ser aplicados más tarde en la tubería.
Datos procesados (Proceseed Data): Los datos procesados son datos sin procesar que han sido decodificados en formatos específicos de eventos, con un esquema aplicado. Por ejemplo, los eventos de seguimiento JSON que se han traducido en eventos de inicio de sesión con un esquema fijo se consideran datos procesados. Los eventos procesados suelen almacenarse en diferentes tablas de eventos/destinos en un conducto de datos.
Datos cocinados (Cooked Data): Los datos procesados que han sido agregados o resumidos se denominan datos cocinados. Por ejemplo, los datos procesados podrían incluir eventos de inicio y fin de sesión y utilizarse como entrada de datos cocinados que resumen la actividad diaria de un usuario, como el número de sesiones y el tiempo total de permanencia en el sitio para una página web.
Los científicos de los datos trabajarán normalmente con datos procesados y utilizarán herramientas para crear datos cocinados para otros equipos.
En este post se discutirá cómo construir un pipeline de datos que produzca datos procesados, mientras que en el post de Inteligencia de Negocios se discutirá cómo agregar datos cocinados a su pipeline.
La evolución de los data pipelines
En las últimas dos décadas el paisaje para la recolección y análisis de datos ha cambiado significativamente. En lugar de almacenar datos localmente a través de archivos de registro, los sistemas modernos pueden rastrear la actividad y aplicar machine learning casi en tiempo real.
Las startups podrían querer utilizar uno de los enfoques anteriores para los testing iniciales, pero realmente deberían buscar enfoques más recientes para construir tuberías de datos.
Basándome en mi experiencia, he observado cuatro enfoques diferentes para las tuberías:
La era de archivo plano: Los datos se guardan localmente en servidores
La era la base de datos: Los datos se ponen en escena en archivos planos y luego se cargan en una base de datos
La era del Data Lake: Los datos se almacenan en Hadoop/S3 y luego se cargan en un DB
La era sin servidores (Serverless): Los servicios administrados se utilizan para el almacenamiento y la consulta
Cada uno de los pasos de esta evolución apoya la recopilación de conjuntos de datos más grandes, pero puede introducir una complejidad operacional adicional.
Para una startup, el objetivo es ser capaz de escalar la recolección de datos sin escalar los recursos operacionales, y la progresión hacia los servicios administrados proporciona una buena solución para el crecimiento.
La tubería de datos por la que caminaremos en la siguiente sección de este post se basa en la era más reciente de tuberías de datos, pero es útil caminar a través de diferentes enfoques porque los requisitos para diferentes empresas pueden encajar mejor con diferentes arquitecturas.
La era de los archivos planos
Components in a pre-database Analytics Architecture
Nota: Hablaremos sobre "Game" servers debido a que el autor trabaja en Zynga
Me inicié en la ciencia de los datos en Electronic Arts en 2010, antes de que EA tuviera una organización construida alrededor de los datos. Mientras que muchas compañías de juegos ya estaban recolectando cantidades masivas de datos sobre la jugabilidad, la mayoría de la telemetría se almacenaba en forma de archivos de registro u otros formatos de archivos planos que se almacenaban localmente en los servidores.
Nada podía ser consultado directamente, y calcular las métricas básicas como los usuarios activos mensuales (MAU) requería un esfuerzo considerable.
En Electronic Arts, se incorporó un feature de "replay" en el Madden NFL 11 que proporcionó una fuente inesperada de telemetría del juego.
Después de cada juego, se enviaba un resumen del mismo en formato XML a un servidor de juegos que enumeraba cada jugada llamada, los movimientos realizados durante el juego y el resultado de la caída.
Esto resultó en millones de archivos que podían ser analizados para aprender más sobre cómo los jugadores interactuaban con el videojuego de fútbol de Madden en la vida real.
Almacenar los datos localmente es, con mucho, el enfoque más fácil de tomar cuando se recogen datos de juego.
Por ejemplo, el enfoque PHP presentado en el último post es útil para establecer un endpoint de análisis ligero. Pero este enfoque tiene inconvenientes significativos.
Este enfoque es simple y permite a los equipos guardar los datos en cualquier formato que se necesite, pero no tiene tolerancia a fallos, no almacena los datos en una ubicación central, tiene una latencia significativa en la disponibilidad de los datos, y tiene herramientas estándar para construir un ecosistema para el análisis.
Los archivos planos pueden funcionar bien si sólo tienes unos pocos servidores, pero no es realmente una tubería de análisis a menos que muevas los archivos a una ubicación central.
Puedes escribir scripts para llevar los datos de los servidores de registro a una ubicación central, pero generalmente no es un enfoque escalable.
La era de las bases de datos
Componentes de una arquitectura analítica basada en ETL
Mientras estaba en Sony Online Entertainment, teníamos servidores de juegos que guardaban archivos de eventos en un servidor de archivos central cada dos minutos.
El servidor de archivos luego ejecutaba un proceso ETL una vez por hora que cargaba rápidamente estos archivos de eventos en nuestra base de datos de análisis, que era Vertica en ese momento.
Este proceso tenía una latencia razonable, alrededor de una hora desde que un cliente de un videojuego enviaba un evento a los datos que se podían consultar en nuestra base de datos analítica.
También se escaló a un gran volumen de datos, pero requirió el uso de un esquema fijo para los datos de evento.
Cuando era empleado en Twitch, usábamos un proceso similar para una de nuestras bases de datos analíticas.
La principal diferencia con el enfoque de Sony era que en lugar de tener los archivos scp de los servidores de juegos en una ubicación central, usábamos Amazon Kinesis para transmitir eventos de los servidores a un área de montaje en el S3.
Luego usamos un proceso ETL para cargar rápidamente los datos en Redshift para su análisis. Desde entonces, Twitch ha cambiado a un enfoque de lago de datos, con el fin de escalar a un mayor volumen de datos y proporcionar más opciones para la consulta de los conjuntos de datos.
Las bases de datos utilizadas en Sony y Twitch eran inmensamente valiosas para ambas compañías, pero nos encontramos con desafíos a medida que escalábamos la cantidad de datos almacenados.
A medida que recogíamos información más detallada sobre el juego, ya no podíamos mantener un historial completo de eventos en nuestras tablas y necesitábamos truncar los datos más antiguos de unos pocos meses.
Esto está bien si se pueden crear tablas de resumen que mantengan los detalles más importantes sobre estos eventos, pero no es una situación ideal.
Uno de los problemas de este enfoque es que el servidor staging se convierte en un punto central de fracaso. También es posible que surjan cuellos de botella cuando un juego envía demasiados eventos, haciendo que los eventos se eliminen en todos los títulos.
Otro problema es el rendimiento de las consultas al aumentar el número de analistas que trabajan con la base de datos. Un equipo de unos pocos analistas que trabajen con unos pocos meses de datos de juego puede funcionar bien, pero después de recopilar años de datos y aumentar el número de analistas, el rendimiento de las consultas puede ser un problema importante, lo que hace que algunas consultas tarden horas en completarse.
Los principales beneficios de este enfoque son que todos los datos de los eventos están disponibles en un solo lugar que puede ser consultado con SQL y que se dispone de grandes herramientas, como Tableau y DataGrip, para trabajar con bases de datos relacionales.
Las desventajas son que es costoso mantener todos los datos cargados en una base de datos como Vertica o Redshift, los eventos deben tener un esquema fijo, y puede ser necesario truncar las tablas para mantener el rendimiento de los servidores.
Otro problema de la utilización de una base de datos como interfaz principal para los datos es que las herramientas de machine learning, como MLlib de Spark, no pueden utilizarse eficazmente, ya que los datos pertinentes deben descargarse de la base de datos antes de que se puedan utilizar.
Una de las formas de superar esta limitación es almacenar los datos de juego en un formato y una capa de almacenamiento que funcionen bien con las herramientas de Big Data, como por ejemplo, guardar eventos como archivos de parquete en S3.
Este tipo de configuración se hizo más poblada en la siguiente era, y evita las limitaciones de tener que truncar las tablas y reduce el costo de mantener todos los datos.
La era del Data Lake
Components in a Data Lake Analytics Architecture
El patrón de almacenamiento de datos que era más común mientras trabajaba como científico de datos en la industria de los videojuegos era un lago de datos.
El patrón general es almacenar datos semiestructurados en una base de datos distribuida, y ejecutar procesos ETL para extraer los datos más relevantes a bases de datos analíticas.
Para la base de datos distribuida se pueden utilizar diferentes herramientas: en Electronic Arts usamos Hadoop, en Microsoft Studios usamos Cosmos, y en Twitch usamos S3.
Este enfoque permite a los equipos escalar a volúmenes masivos de datos, y proporciona una tolerancia adicional a las fallas.
El principal inconveniente es que introduce una complejidad adicional, y puede dar lugar a que los analistas tengan acceso a menos datos que si se utilizara un enfoque de base de datos tradicional, debido a la falta de herramientas o políticas de acceso.
La mayoría de los analistas interactuarán con los datos de la misma manera en este modelo, utilizando una base de datos analítica poblada de ETLs de lago de datos.
Una de las ventajas de este enfoque es que admite una variedad de esquemas de eventos diferentes, y puede cambiar los atributos de un evento sin afectar a la base de datos analítica.
Otra ventaja es que los equipos de análisis pueden utilizar herramientas como Spark SQL para trabajar directamente con el lago de datos.
Sin embargo, en la mayoría de los lugares en los que trabajé se restringió el acceso al lago de datos, eliminando muchos de los beneficios de este modelo.
Este enfoque se escala a una cantidad masiva de datos, soporta esquemas de eventos flexibles, y proporciona una buena solución para consultas por lotes de larga duración.
La desventaja es que puede implicar una sobrecarga operacional significativa, puede introducir grandes latencias de eventos, y puede carecer de herramientas maduras para los usuarios finales del lago de datos.
Un inconveniente adicional de este enfoque es que normalmente se necesita un equipo completo sólo para mantener el sistema operativo. Esto tiene sentido para las grandes organizaciones, pero puede ser exagerado para las empresas más pequeñas.
Una de las formas de aprovechar la utilización del lago de datos sin el costo de los gastos generales de funcionamiento es utilizar servicios gestionados.
Era sin servidores
Components in a managed Analytics Architecture (GCP)
En la era actual, las plataformas analíticas incorporan una serie de servicios gestionados, que permiten a los equipos trabajar con los datos casi en tiempo real, ampliar los sistemas según sea necesario y reducir los gastos de mantenimiento de los servidores.
Nunca experimenté esta era mientras trabajaba en la industria de los videojuegos, pero vi señales de que esta transición estaba ocurriendo.
Riot Games está usando Spark para los procesos de ETL y el machine learning, y necesitaba hacer girar la infraestructura según la demanda. Algunos equipos están usando métodos de computación elástica para los servicios de juegos, y tiene sentido utilizar este enfoque para el análisis también.
Este enfoque tiene muchos de los mismos beneficios que el uso de un lago de datos, auto-escalas basadas en las necesidades de consulta y almacenamiento, y tiene un mínimo de gastos operativos.
Las principales desventajas son que los servicios gestionados pueden ser costosos, y la adopción de este enfoque probablemente dará lugar a la utilización de herramientas específicas de la plataforma que no son portables a otros proveedores de nubes.
En mi carrera tuve el mayor éxito trabajando con el enfoque de la era de la base de datos, ya que proporcionaba al equipo de análisis acceso a todos los datos relevantes. Sin embargo, no fue una configuración que continuara escalando y la mayoría de los equipos en los que trabajé se han trasladado desde entonces a entornos de lago de datos.
Para que un entorno de lago de datos tenga éxito, los equipos de análisis necesitan acceso a los datos subyacentes, y herramientas maduras para apoyar sus procesos.
Para una startup, el enfoque sin servidores suele ser la mejor manera de empezar a construir un conducto de datos, porque puede escalarse para ajustarse a la demanda y requiere un mínimo de personal para mantener el conducto de datos.
En la siguiente post se explicará cómo construir un conducto de muestra con servicios gestionados.
CréditosLos modelos predictivos se han convertido en un asesor de confianza para muchas empresas y por una buena razón. Estos modelos pueden "prever el futuro", y hay muchos métodos diferentes disponibles, lo que significa que cualquier industria puede encontrar uno que se ajuste a sus retos particulares.Cuando hablamos de modelos predictivos, nos referimos a un modelo de regresión (salida continua) o a un modelo de clasificación (salida nominal o binaria). En los problemas de clasificación, utilizamos dos tipos de algoritmos (dependiendo del tipo de salida que este crea):Salida de clase: Algoritmos como Support Vector Machine y K Nearest Neighbors crean una salida de clase. Por ejemplo, en un problema de clasificación binaria, las salidas serán 0 o 1. Sin embargo, hoy en día tenemos algoritmos que pueden convertir estas salidas de clase en probabilidad.Salida de probabilidad: Algoritmos como la Regresión Logística, el Bosque Aleatorio, potenciación del Gradiente, el Adaboost, etc. dan salidas de probabilidad. Convertir las salidas de probabilidad en salidas de clase es sólo cuestión de crear un umbral de probabilidadPuedes leer más artículos de Data Science en español aquí Lea también:Tipos Claves De Regresiones: ¿Cuál Usar?IntroducciónSi bien la preparación de los datos y el entrenamiento de un modelo de aprendizaje de máquina es un paso clave en el proceso de aprendizaje automático, es igualmente importante medir el rendimiento de este modelo entrenado. Lo bien que el modelo generaliza sobre los datos no vistos es lo que define los modelos de aprendizaje automático adaptables frente a los no adaptables.Al utilizar diferentes métricas para la evaluación del rendimiento, deberíamos estar en posición de mejorar el poder de predicción general de nuestro modelo antes de que lo pongamos en marcha para la producción sobre datos no vistos antes.Si no se realiza una evaluación adecuada del modelo aprendizaje automático utilizando diferentes métricas, y se usa sólo la precisión, puede darse un problema cuando el modelo respectivo se despliega sobre datos no vistos y puede dar lugar a malas predicciones.Esto sucede porque, en casos como éste, nuestros modelos no aprenden sino que memorizan; por lo tanto, no pueden generalizar bien sobre datos no vistos.Métricas de evaluación del modeloDefinamos ahora las métricas de evaluación para valorar el rendimiento de un modelo de aprendizaje automático, que es un componente integral de cualquier proyecto de ciencia de los datos. Su objetivo es estimar la precisión de la generalización de un modelo sobre los datos futuros (no vistos/fuera de muestra).Matriz de confusiónUna matriz de confusión es una representación matricial de los resultados de las predicciones de cualquier prueba binaria que se utiliza a menudo para describir el rendimiento del modelo de clasificación (o "clasificador") sobre un conjunto de datos de prueba cuyos valores reales se conocen.La matriz de confusión es relativamente sencilla de comprender, pero la terminología relacionada puede ser confusa.Matriz de confusión con 2 etiquetas de clase.Cada predicción puede ser uno de cuatro resultados, basado en cómo coincide con el valor real:Verdadero Positivo (TP): Predicho Verdadero y Verdadero en realidad.Verdadero Negativo (TN): Predicho Falso y Falso en realidad.Falso Positivo (FP): Predicción de verdadero y falso en la realidad.Falso Negativo (FN): Predicción de falso y verdadero en la realidad.Ahora entendamos este concepto usando la prueba de hipótesis.Lea también:Falsos Positivos Vs. Falsos Negativos Una hipótesis es una especulación o teoría basada en pruebas insuficientes que se presta a más pruebas y experimentación. Con más pruebas, una hipótesis puede ser probada como verdadera o falsa.Una Hipótesis Nula es una hipótesis que dice que no hay significancia estadística entre las dos variables de la hipótesis. Es la hipótesis que el investigador está tratando de refutar.Siempre rechazamos la hipótesis nula cuando es falsa, y aceptamos la hipótesis nula cuando es realmente verdadera.Aunque las pruebas de hipótesis se supone que son fiables, hay dos tipos de errores que pueden ocurrir.Estos errores se conocen como errores de Tipo I y Tipo II.Por ejemplo, cuando se examina la eficacia de una droga, la hipótesis nula sería que la droga no afecta a una enfermedad.Error de Tipo I: equivalente a los Falsos Positivos(FP).El primer tipo de error posible implica el rechazo de una hipótesis nula que es verdadera.Volvamos al ejemplo de una droga que se utiliza para tratar una enfermedad. Si rechazamos la hipótesis nula en esta situación, entonces afirmamos que la droga tiene algún efecto sobre una enfermedad. Pero si la hipótesis nula es cierta, entonces, en realidad, la droga no combate la enfermedad en absoluto. Se afirma falsamente que la droga tiene un efecto positivo en una enfermedad.Error de tipo II:- equivalente a Falsos Negativos(FN).El otro tipo de error que ocurre cuando aceptamos una hipótesis falsa nula. Este tipo de error se llama error de tipo II y también se conoce como error de segundo tipo.Si pensamos de nuevo en el escenario en el que estamos probando una droga, ¿cómo sería un error de tipo II? Un error de tipo II ocurriría si aceptáramos que la droga no tiene efecto sobre la enfermedad, pero en realidad, sí lo tiene.Un ejemplo de la implementación Python de la matriz de confusión.Puedes leer más artículos de Data Science en español aquí import warningsimport pandas as pdfrom sklearn import model_selectionfrom sklearn.linear_model import LogisticRegressionfrom sklearn.metrics import confusion_matriximport matplotlib.pyplot as plt%matplotlib inline #ignore warningswarnings.filterwarnings('ignore')# Load digits dataseturl = "http://archive.ics.uci.edu/ml/machine-learning-databases/iris/iris.data"df = pd.read_csv(url)# df = df.valuesX = df.iloc[:,0:4]y = df.iloc[:,4]#test sizetest_size = 0.33#generate the same set of random numbersseed = 7#Split data into train and test set. X_train, X_test, y_train, y_test = model_selection.train_test_split(X, y, test_size=test_size, random_state=seed)#Train Modelmodel = LogisticRegression()model.fit(X_train, y_train)pred = model.predict(X_test)#Construct the Confusion Matrixlabels = ['Iris-setosa', 'Iris-versicolor', 'Iris-virginica']cm = confusion_matrix(y_test, pred, labels)print(cm)fig = plt.figure()ax = fig.add_subplot(111)cax = ax.matshow(cm)plt.title('Confusion matrix')fig.colorbar(cax)ax.set_xticklabels([''] + labels)ax.set_yticklabels([''] + labels)plt.xlabel('Predicted Values')plt.ylabel('Actual Values')plt.show()Matriz de confusión con 3 etiquetas de clase.Los elementos diagonales representan el número de puntos para los cuales la etiqueta predicha es igual a la etiqueta verdadera, mientras que cualquier cosa fuera de la diagonal fue mal etiquetada por el clasificador. Por lo tanto, cuanto más altos sean los valores diagonales de la matriz de confusión, mejor, indicando muchas predicciones correctas.En nuestro caso, el clasificador predijo perfectamente las 13 plantas de setosa y 18 de virginica en los datos de prueba. Sin embargo, clasificó incorrectamente 4 de las plantas versicolor como virginica.También hay una lista de tasas que a menudo se calculan a partir de una matriz de confusión para un clasificador binario:1. ExactitudEn general, ¿con qué frecuencia es correcto el clasificador?Exactitud = (TP+TN)/totalCuando nuestras clases son aproximadamente iguales en tamaño, podemos usar la precisión, que nos dará valores clasificados correctamente.La precisión es una métrica de evaluación común para los problemas de clasificación. Es el número de predicciones correctas hechas como una proporción de todas las predicciones hechas.Tasa de clasificación errónea (Tasa de error): En general, con qué frecuencia se equivoca. Dado que la exactitud es el porcentaje que clasificamos correctamente (tasa de éxito), se deduce que nuestra tasa de error (el porcentaje en que nos equivocamos) puede calcularse de la siguiente manera:Tasa de clasificación errónea = (FP+FN)/total#import modulesimport warningsimport pandas as pdimport numpy as npfrom sklearn import model_selectionfrom sklearn.linear_model import LogisticRegressionfrom sklearn import datasetsfrom sklearn.metrics import accuracy_score#ignore warningswarnings.filterwarnings('ignore')# Load digits datasetiris = datasets.load_iris()# # Create feature matrixX = iris.data# Create target vectory = iris.target#test sizetest_size = 0.33#generate the same set of random numbersseed = 7#cross-validation settingskfold = model_selection.KFold(n_splits=10, random_state=seed)#Model instancemodel = LogisticRegression()#Evaluate model performancescoring = 'accuracy'results = model_selection.cross_val_score(model, X, y, cv=kfold, scoring=scoring)print('Accuracy -val set: %.2f%% (%.2f)' % (results.mean()*100, results.std()))#split dataX_train, X_test, y_train, y_test = model_selection.train_test_split(X, y, test_size=test_size, random_state=seed)#fit modelmodel.fit(X_train, y_train)#accuracy on test setresult = model.score(X_test, y_test)print("Accuracy - test set: %.2f%%" % (result*100.0))La precisión de la clasificación es del 88% en el conjunto de validación.2. PrecisiónCuando predice sí, ¿con qué frecuencia es correcto?Precisión=TP/predicciones síCuando tenemos un desequilibrio de clase, la precisión puede convertirse en una métrica poco fiable para medir nuestro desempeño. Por ejemplo, si tuviéramos una división de 99/1 entre dos clases, A y B, donde el evento raro, B, es nuestra clase positiva, podríamos construir un modelo que fuera 99% exacto con sólo decir que todo pertenece a la clase A. Claramente, no deberíamos molestarnos en construir un modelo si no hace nada para identificar la clase B; por lo tanto, necesitamos diferentes métricas que desalienten este comportamiento. Para ello, utilizamos la precisión y la sensibilidad en lugar de la exactitud.Puedes leer más artículos de Data Science en español aquí 3. ExhaustividadCuando en realidad es un sí, ¿con qué frecuencia predice un sí?Tasa positiva verdadera = TP/Si realesLa Exhaustividad nos da la tasa positiva verdadera (TPR), que es la proporción de los verdaderos positivos a todo lo positivo.En el caso de la división 99/1 entre las clases A y B, el modelo que clasifica todo como A tendría una exhaustividad del 0% para la clase positiva, B (la precisión sería indefinida - 0/0). La exhaustividad proporciona una mejor manera de evaluar el rendimiento del modelo ante un desequilibrio de clases. Nos dirá correctamente que el modelo tiene poco valor para nuestro caso de uso.Al igual que la exactitud, tanto la precisión como la exhaustividad son fáciles de calcular y comprender, pero requieren umbrales. Además, la precisión y la exhaustividad sólo consideran la mitad de la matriz de confusión:4. Puntuación F1La puntuación F1 es la media armónica de la precisión y exhaustividad, donde la puntuación de la F1 alcanza su mejor valor en 1 (precisión y exhaustividad perfectas) y el peor en 0.¿Por qué la media armónica? Dado que la media armónica de una lista de números se inclina fuertemente hacia últimos elementos de la lista, tiende (en comparación con la media aritmética) a mitigar el impacto de los grandes valores atípicos y a agravar el impacto de los pequeños.Una puntuación F1 castiga más los valores extremos. Idealmente, un puntaje F1 podría ser una métrica de evaluación efectiva en los siguientes escenarios de clasificación:Cuando los Falsos Positivos y la Falsos Negativos son igualmente costosos - lo que significa que se pasan verdaderos positivos o se encuentran falsos positivos - ambos impactan el modelo casi de la misma manera, como en nuestro ejemplo de clasificación de detección de cáncerAñadir más datos no cambia el resultado de manera efectivaLa TN es alta (como en las predicciones de inundaciones, predicciones de cáncer, etc.)Un ejemplo de implementación en Python de la puntuación F1.import warningsimport pandasfrom sklearn import model_selectionfrom sklearn.linear_model import LogisticRegressionfrom sklearn.metrics import log_lossfrom sklearn.metrics import precision_recall_fscore_support as score, precision_score, recall_score, f1_scorewarnings.filterwarnings('ignore')url = "https://raw.githubusercontent.com/jbrownlee/Datasets/master/pima-indians-diabetes.data.csv"dataframe = pandas.read_csv(url)dat = dataframe.valuesX = dat[:,:-1]y = dat[:,-1]test_size = 0.33seed = 7model = LogisticRegression()#split dataX_train, X_test, y_train, y_test = model_selection.train_test_split(X, y, test_size=test_size, random_state=seed)model.fit(X_train, y_train)precision = precision_score(y_test, pred)print('Precision: %f' % precision)# recall: tp / (tp + fn)recall = recall_score(y_test, pred)print('Recall: %f' % recall)# f1: tp / (tp + fp + fn)f1 = f1_score(y_test, pred)print('F1 score: %f' % f1)Puedes leer más artículos de Data Science en español aquí 5. EspecificidadCuando es no, ¿con qué frecuencia predice el no?Tasa negativa real = TN/no realEs la verdadera tasa negativa o la proporción de verdaderos negativos a todo lo que debería haber sido clasificado como negativo.Obsérvese que, en conjunto, la especificidad y la sensibilidad consideran la matriz de confusión completa:6. Curva de características operativas del receptor (ROC)Medir el área bajo la curva ROC es también un método muy útil para evaluar un modelo. Al trazar la tasa positiva verdadera (sensibilidad) frente a la tasa de falsos positivos (1 - especificidad), obtenemos la curva de Característica Operativa del Receptor (ROC). Esta curva nos permite visualizar el equilibrio entre la tasa de verdaderos positivos y la tasa falsos positivosLos siguientes son ejemplos de buenas curvas ROC. La línea discontinua sería una suposición aleatoria (sin valor predictivo) y se utiliza como línea de base; cualquier cosa por debajo de eso se considera peor que una suposición. Queremos estar hacia la esquina superior izquierda:Una ejemplo de implementación en Python de las curvas ROC#Classification Area under curveimport warningsimport pandasfrom sklearn import model_selectionfrom sklearn.linear_model import LogisticRegressionfrom sklearn.metrics import roc_auc_score, roc_curvewarnings.filterwarnings('ignore')url = "https://raw.githubusercontent.com/jbrownlee/Datasets/master/pima-indians-diabetes.data.csv"dataframe = pandas.read_csv(url)dat = dataframe.valuesX = dat[:,:-1]y = dat[:,-1]seed = 7#split dataX_train, X_test, y_train, y_test = model_selection.train_test_split(X, y, test_size=test_size, random_state=seed)model.fit(X_train, y_train)# predict probabilitiesprobs = model.predict_proba(X_test)# keep probabilities for the positive outcome onlyprobs = probs[:, 1]auc = roc_auc_score(y_test, probs)print('AUC - Test Set: %.2f%%' % (auc*100))# calculate roc curvefpr, tpr, thresholds = roc_curve(y_test, probs)# plot no skillplt.plot([0, 1], [0, 1], linestyle='--')# plot the roc curve for the modelplt.plot(fpr, tpr, marker='.')plt.xlabel('False positive rate')plt.ylabel('Sensitivity/ Recall')# show the plotplt.show()En el ejemplo anterior, la AUC está relativamente cerca de 1 y es mayor de 0,5. Un clasificador perfecto hará que la curva ROC vaya a lo largo del eje Y y luego a lo largo del eje X.7. Pérdida logarítmicaLa pérdida logarítmica es la métrica de clasificación más importante basada en probabilidades.A medida que la probabilidad predicha de la clase verdadera se acerca a cero, la pérdida aumenta exponencialmente:Mide el desempeño de un modelo de clasificación en el que la entrada de la predicción es un valor de probabilidad entre 0 y 1. La pérdida logarítmica aumenta a medida que la probabilidad predicha se aleja de la etiqueta real. El objetivo de cualquier modelo de aprendizaje automático es minimizar este valor. Por lo tanto, una pérdida logarítmica menor es mejor, con un modelo perfecto teniendo una pérdida logarítmica de 0.Una muestra de la implementación en Python de la pérdida logarítmica#Classification LogLossimport warningsimport pandasfrom sklearn import model_selectionfrom sklearn.linear_model import LogisticRegressionfrom sklearn.metrics import log_losswarnings.filterwarnings('ignore')url = "https://raw.githubusercontent.com/jbrownlee/Datasets/master/pima-indians-diabetes.data.csv"dataframe = pandas.read_csv(url)dat = dataframe.valuesX = dat[:,:-1]y = dat[:,-1]seed = 7#split dataX_train, X_test, y_train, y_test = model_selection.train_test_split(X, y, test_size=test_size, random_state=seed)model.fit(X_train, y_train)#predict and compute loglosspred = model.predict(X_test)accuracy = log_loss(y_test, pred)print("Logloss: %.2f" % (accuracy))Logloss: 8.02Puedes leer más artículos de Data Science en español aquí 8. Índice JaccardEl índice Jaccard es una de las formas más simples de calcular y averiguar la exactitud de un modelo de clasificación de aprendizaje automático. Entendamoslo con un ejemplo. Supongamos que tenemos un conjunto de pruebas etiquetadas, con etiquetas como -y = [0,0,0,0,0,1,1,1,1,1]Y nuestro modelo ha predicho las etiquetas como…y1 = [1,1,0,0,0,1,1,1,1,1]El anterior diagrama de Venn nos muestra las etiquetas del conjunto de pruebas y las etiquetas de las predicciones, y su intersección y unión.El índice Jaccard o coeficiente de similitud Jaccard es una estadística utilizada para comprender las similitudes entre los conjuntos de muestras. La medición enfatiza la similitud entre conjuntos de muestras finitas y se define formalmente como el tamaño de la intersección dividido por el tamaño de la unión de los dos conjuntos etiquetados, con la fórmula como -Índice Jaccard o Intersección sobre Unión(IoU)Así, para nuestro ejemplo, podemos ver que la intersección de los dos conjuntos es igual a 8 (ya que ocho valores se predicen correctamente) y la unión es 10 + 10-8 = 12. Por lo tanto, el índice Jaccard nos da la precisión como -Así que la precisión de nuestro modelo, según el índice Jaccard, se convierte en 0.66, o 66%.Cuanto mayor sea el índice Jaccard, mayor será la precisión del clasificador.Una muestra de implementación en Python del índice Jaccard.import numpy as npdef compute_jaccard_similarity_score(x, y): intersection_cardinality = len(set(x).intersection(set(y))) union_cardinality = len(set(x).union(set(y))) return intersection_cardinality / float(union_cardinality)score = compute_jaccard_similarity_score(np.array([0, 1, 2, 5, 6]), np.array([0, 2, 3, 5, 7, 9]))print "Jaccard Similarity Score : %s" %scorepassPuntaje de similitud Jaccard: 0.3759. Gráfico de Kolmogorov SmirnovEl gráfico K-S o Kolmogorov-Smirnov mide el rendimiento de los modelos de clasificación. Más exactamente, K-S es una medida del grado de separación entre las distribuciones positivas y negativas.La frecuencia acumulativa de las distribuciones observadas y de las hipótesis se traza en relación con las frecuencias ordenadas. La doble flecha vertical indica la máxima diferencia vertical.La K-S es 100 si las puntuaciones dividen la población en dos grupos separados en los que un grupo contiene todos los positivos y el otro todos los negativos. Por otra parte, si el modelo no puede diferenciar entre los positivos y los negativos, entonces es como si el modelo seleccionara casos al azar de la población. El K-S sería 0.En la mayoría de los modelos de clasificación la K-S caerá entre 0 y 100, y cuanto más alto sea el valor mejor será el modelo para separar los casos positivos de los negativos.La K-S también puede utilizarse para comprobar si dos distribuciones de probabilidad unidimensionales subyacentes difieren. Es una forma muy eficiente de determinar si dos muestras son significativamente diferentes entre sí.Un ejemplo de la implementación en Python del Kolmogorov-Smirnov.from scipy.stats import kstest import random # N = int(input("Enter number of random numbers: ")) N = 10 actual =[] print("Enter outcomes: ") for i in range(N): # x = float(input("Outcomes of class "+str(i + 1)+": ")) actual.append(random.random()) print(actual) x = kstest(actual, "norm") print(x)La hipótesis nula utilizada aquí asume que los números siguen la distribución normal. Devuelve estadísticas y valor p. Si el valor p es < alfa, rechazamos la hipótesis Nula.Alfa se define como la probabilidad de rechazar la hipótesis nula dado que la hipótesis nula(H0) es verdadera. Para la mayoría de las aplicaciones prácticas, se elige alfa como 0,05.Puedes leer más artículos de Data Science en español aquí 10. Gráfico de ganancia y elevaciónLa ganancia o el levantamiento es una medida de la eficacia de un modelo de clasificación calculado como la relación entre los resultados obtenidos con y sin el modelo. Los gráficos de ganancia y elevación son ayudas visuales para evaluar el rendimiento de los modelos de clasificación. Sin embargo, en contraste con la matriz de confusión que evalúa los modelos en toda la población, el gráfico de ganancia o elevación evalúa el rendimiento del modelo en una porción de la población.Cuanto mayor sea la elevación (es decir, cuanto más lejos esté de la línea de base), mejor será el modelo.El siguiente gráfico de ganancias, ejecutado en un conjunto de validación, muestra que con el 50% de los datos, el modelo contiene el 90% de los objetivos, la adición de más datos añade un aumento insignificante en el porcentaje de objetivos incluidos en el modelo.Gráfico de ganancia/elevaciónLos gráficos de elevación suelen presentarse como un gráfico de ascenso acumulativo, que también se conoce como gráfico de ganancias. Por lo tanto, los gráficos de ganancias a veces se denominan (quizás de forma confusa) "gráficos de elevación", pero son más exactos como gráficos de ascenso acumulativo.Uno de sus usos más comunes es en el marketing, para decidir si vale la pena llamar a un posible cliente.11. Coeficiente de GiniEl coeficiente de Gini o Índice de Gini es una métrica popular para los valores de clase desequilibrados. El coeficiente oscila entre 0 y 1, donde 0 representa la igualdad perfecta y 1 la desigualdad perfecta. Aquí, si el valor de un índice es mayor, entonces los datos estarán más dispersos.El coeficiente de Gini puede calcularse a partir del área bajo la curva ROC usando la siguiente fórmula:Coeficiente de Gini = (2 * curva_ROC) - 1Puedes leer más artículos de Data Science en español aquí ConclusiónComprender lo bien que un modelo de aprendizaje automático va a funcionar con datos no vistos es el propósito final de trabajar con estas métricas de evaluación. Métricas como la exactitud, la precisión, la exhaustividad son buenas formas de evaluar los modelos de clasificación para conjuntos de datos equilibrados, pero si los datos están desequilibrados y hay una disparidad de clases, entonces otros métodos como el ROC/AUC, el coeficiente de Gini funcionan mejor en la evaluación del rendimiento del modelo.Bueno, esto concluye este artículo. Espero que hayan disfrutado de su lectura, no duden en compartir sus comentarios/pensamientos/opiniones en la sección de comentarios.Gracias por leerlo!!!
Juan Guillermo Gómez Ramírez
Apr 12, 2020
Join our private community in Discord
Keep up to date by participating in our global community of data scientists and AI enthusiasts. We discuss the latest developments in data science competitions, new techniques for solving complex challenges, AI and machine learning models, and much more!
