Tómatelo a pecho: Detección de tumores malignos de cáncer de mama con Inteligencia Artificial

by 2020La Paz
https://www.nationalbreastcancer.org/breast-cancer-facts

La Paz. Machine Learning. Segunda edición. 2020

Introducción

El cáncer de mama es la primera causa de muerte por tumores malignos en las mujeres a nivel mundial. Al menos en el año 2019 murieron cerca de 688 mil debido este padecimiento, lo cual nos da una tasa de mortalidad para mujeres mayores de 20 años de 24.7 por cada 100 mil.

Motivación

Existe una brecha de mortalidad por cáncer de mama entre países por nivel de ingresos, el 70%(483,000) de los fallecimientos ocurren en los países de ingresos medios y bajos. ¿A qué se deberá?, sucede que en los países de ingresos medios y bajos, hay una falta de acceso a servicios de diagnóstico y tratamiento de esta enfermedad.

Tasa de mortalidad e incidencia

  1. Norteamérica 22%
  2. Latinoamérica y el Caribe 38%
  3. África Sub-Sahariana 65%

Entre el 50 y 63% de las muertes por cáncer de mama en todo el mundo son prevenibles con detección temprana y tratamiento adecuado. Entre el 66 y 74% de estas muertes que son prevenibles ocurren en países en desarrollo. Asimismo, el cáncer de mama, detectado a tiempo y con tratamiento adecuado puede curarse. Y en caso de que no, puede elevar la calidad de vida de las pacientes al menos hasta 5 años (en Norteamérica).

De esta problemática surge nuestro proyecto social. Sabemos que la situación es muy desfavorable para las mujeres, así que podemos contribuir a generar un modelo de machine learning que pueda ayudar a la predicción de este tipo de tumores con el cual, en un futuro muchas mujeres podrían acceder a un método de detección barato y digno, aumentando así su calidad de vida al enfrentarse con esta enfermedad genética.

https://subscription.packtpub.com/book/big_data_and_business_intelligence/9781783980284/5/ch05lvl1sec30/using-decision-trees-
Detección de cáncer de mama usando el dataset de Diagnosis Wisconsin

Objetivo

Explorar distintos algoritmos de ML (Machine Learning, por sus siglas en inglés) supervisados y no supervisados utilizando el dataset de Wisconsin sobre diagnóstico (explicado más adelante), para compararlos y verificar cual es el que nos proporciona el mejor modelo de detección de cáncer de mama, así como revisar que variables proporcionan mayor información sobre la detección.

Como objetivo sería plantear una generalización de base de datos que pudiera implementarse en cualquier país al que se lleve este diagnóstico.

Proyecto

Se trabajó en una comparativa de ciertos modelos supervisados y no supervisados para determinar la precisión de cada uno y posteriormente utilizarlo para la predicción.

Dataset

Los datos que vamos a utilizar para este primer ejercicio son los proporcionados en el dataset de diagnóstico de Wisconsin que contiene variables sobre la forma del tumor (en términos de núcleo de las células) y su dianóstico, como se muestra a continuación:

  1. id: etiqueta por observación.
  2. diagnóstico: variable binaria que clasifica el tumor. (M=maligno, B=benigno)
  3. radio: media de las distancias del centro al perímetro.
  4. textura: desviación estándar de los valores gradiente de las imágenes.
  5. perímetro: medida del contorno del núcleo celular.
  6. área: medida del área del núcleo celular.
  7. suavidad: variación local de las longitudes del radio
  8. compacidad: medida calculada por ((perímetro²/area) -1)
  9. concavidad: severidad de las porciones cóncavas del contorno
  10. puntos de concavidad: número de las porciones cóncavas del contorno
  11. simetría: similitud entre partes con respecto a ejes.
  12. dimensión fractal: índice comparativo sobre el detalle de un patrón observado de células.

De las variables 3–12 asociamos las métricas: media, error estándar, error extremo.

Descripción del dataset con sus métricas

Análisis exploratorio

Después de haber revisado las variables del dataset procedemos a evaular la distribución del feature diagnostico para saber el balanceo de los datos, esto tiene una repercusión a la hora de entrenar a los modelos, porque como podemos ver en la gráfica siguiente tiene una mayor cantidad de datos asociada a diagnóstico de tumores benignos.

Variable diagnóstico

Posteriormente procederemos a ver los mapas de correlaciones entre variables para identificar si hay que hacer algún preprocesamiento antes de entrenar los modelos.

Mapa de correlaciones con las métricas

Las gráficas anteriores ilustran que en general los tres mapas muestran correlaciones similares, los promedios muestran una correlación más intensa que los valores extremos y a su vez, los valores extremos muestran una correlación más clara que el error estándar, sin embargo en los tres mapas se mantiene la tendencia entre variables.

Destacaremos las correlaciones más evidentes:

  1. radio con perimetro/área/puntos de concavidad: se debe a la forma de calcular estas variables dependen directamente del radio.
  2. perímetro con área/ concavidad/puntos de concavidad: estas correlaciones tienen que ver con lo mencionado en el 1.
  3. suavidad con compacidad
  4. compacidad con concavidad/puntos de concavidad/simetria

Después se realizaron los mapas de correlaciones más específicos que incluyen las tres métricas de las variables con relaciones más destacadas mencionadas anteriormente.

Mapas de correlaciones con las tres métricas

La siguiente gráfica tiene una particularidad, se observa que para las métricas del área los extremos están altamente correlacionados con la media. Y el error estándar es la métrica menos correlacionada con respecto a las otras dos.

Mapa de correlaciones del área

Por último mostraremos las distribuciones y diagramas de dispersión para la media por el tipo de diagnostico, lo cual nos da un indicador de como se comportan las densidades que se puede englobar en los siguientes grupos:

  1. Existe una separación casi total entre densidades: no comparten ni forma ni soporte.
  2. Existe una separación regular entre densidades: comparten forma o soporte.
  3. Existe una separación mínima entre densidades: comparten forma y soporte excepto ligeras variaciones.
Distribuciones sobre la media utilizando la variable diagnostico

Algoritmos no supervisados

PCA

Proponemos este análisis debido a que la estructura de nuestra base de datos tiene una dimensión alta (30 variables) por lo tanto esta técnica de análisis no supervisado nos ayudará a reducir la cantidad de componentes (variables) de nuestra base de datos, proyectando las variables originales a un subconjunto de las mismas.

El conjunto final de las variables escenciales después de este análisis, eliminará las que estén posiblemente correlacionadas. Tenemos ahora una aproximación apriori que terminará de definirse con este análisis, dado que queremos formar dos clusters por la forma binaria que tiene nuestra variable objetivo diagnostico.

La siguiente tabla muestra el porcentaje de varianza que acumula cada una de las componentes principales, consideramos en principio 10 componentes principales, como se observa en la tabla la primera y segunda componente explican el 44.27% y el 18.97% de la varianza respectivamente, lo que implica que las primeras dos componentes explican el 63.24% de la varianza.

PCA con n_components = 10

Así que repetiremos el procedimiento pero para ahora solo sacar 2 componentes, ya que obtienen más del 60% de la varianza total.

Distribución de 2 clústers para la variable diagnostico

Ahora vamos a intentarlo con n=3 y podremos observar el mismo comportamiento que con dos dimensiones. En conclusión hay un agrupamiento claro con respecto al tipo de diagnóstico, incluso podría separarse linealmente (con una recta en el caso bidimensional y con un plano en el caso tridimensional) salvo algunas observaciones que se diseminan por completo.

PCA n_componentes = 3

K-Means

Para este algoritmo de ML, utilizamos el dataset sin reducción, y entrenamos el modelo para que realizara una maximización de la separación de los clústers dadas las características que tenemos (28 variables, removiendo el label).

Para este caso una visualización tipo silueta puede ayudar mucho a explicar los resultados. El Silhouetter Score fue de 0.697 es decir, que tan bien separados están los clústers, recordando que 0 quiere decir que hay overlapping y 1 que están perfectamente delimitados.

Visualización de Silueta para los 2 clústers principales de la variable diagnostico

Para probar este modelo decidimos generar datos random con las variables seleccionadas del dataframe y estos fueron los resultados:

El modelo es capaz de clasificar si están en 1 (Benigno) y 0 (Maligno) dependiendo de los valores entrantes que fueron generados de manera random. Esto posteriormente con datos reales, podría detectar tumores de mama hasta con una probabilidad de 69%, lo cual es poco deseable. Más adelante con los algoritmos supervisados podremos elevar este porcentaje.

Algoritmos Supervisados

Regresión Logística

Nuestro proyecto entra en la categoría de clasificación binaria, debido a que tenemos una variable diagnostico que solo nos muestra si es benigno o maligno. Por tanto, este modelo nos beneficia al darnos una primera aproximación para la resolución del problema. En primera instancia, aplicamos el algoritmo de regresión logística para los datos en sus 30 dimensiones y para ver claramente como está funcionando este clasificador, emplearemos una matriz de confusión como se muestra a continuación.

Matriz de confusión sobre falsos positivos, falsos negativos, verdaderos negativos y verdaderos positivos

Dada la predicción anterior podemos incluir la precisión del modelo calculada con la métrica de sklearn accuracy_score fue de 0.962765. Resultado que es mucho mejor que nuestro anterior modelo no supervisado (KMeans).

Un diagnóstico más específico es la probabilidad de predicción por observación, es decir, qué tan probable es que esa observación sea clasificada como Benigno o Maligno. Así que vamos a ver su desempeño por cross-validation. Cross-Validation Accuracy Scores [0.94871795 0.92105263 0.94736842 0.92105263 0.97368421 0.97368421 0.97368421 0.94736842 0.92105263 0.94736842].

Por lo anterior concluimos que en promedio tenemos una precisión del 94.6%, sin embargo es necesario revisar la estructura del modelo y los supuestos del mismo.

Regresión Logística paso por paso

Después de la pasada primera aproximación del modelo es momento de revisar si se cumplen ciertos supuestos requeridos para el desarrollo de la regresión logística, algunos de estos supuestos los enunciaremos a continuación.

  1. La variable objetivo debe ser binaria. En nuestro caso diagnostico es ‘M’ o ‘B’.
  2. El resultado de la variable de interés asociado al “éxito” debe ser 1.
  3. Solo deben incluirse las variables significativas.
  4. Las variables deben ser independientes entre sí, para evitar el problema de multicolinealidad.
  5. Debe haber un tamaño de muestra “suficiente”

Procederemos a la construcción de la regresión lineal cuidando estos supuestos.

En un principio detectamos que nuestra muestra no estaba balanceada en cantidad de observaciones malignas (~37%) y benignas (~62%), para lo cual se utilizó la biblioteca SMOTE debido a que realiza una generación aleatoria de las observaciones faltantes basada en KNN.

Balancenado las observaciones para tener la misma cantidad de observaciones B y M

Nota: Solo sobremuestreamos en el conjunto de datos de entrenamiento, puesto que la información que hay en los datos de prueba no será incorporada en el modelo de entrenamiento.

Para “Solo deben incluirse las variables significativas”, es necesario identificar las variables que tengan el mejor rendimiento, así poder incluir finalmente variables o características más pequeñas y más representativas. Estas fueron las variables elegidas:

“radio_medio”,”textura_medio”,”perimetro_medio”,”area_media”,”suavidad_media”,”compacidad_media”,”concavidad_media”,”puntos_concavidad_media”,”simetria_media”,”dim_fractal_media”,”radio_ee”,”textura_ee”,”perimetro_ee”,”area_ee”,”suavidad_ee”,”compacidad_ee”,”concavidad_ee”,”puntos_concavidad_ee”,”simetria_ee”,”dim_fractal_ee”,”radio_extremo”,”textura_extremo”,”perimetro_extremo”,”area_extremo”,”suavidad_extremo”,”compacidad_extremo”,”concavidad_extremo”,”puntos_concavidad_extremo”,”simetria_extremo”,”dim_fractal_extremo”

Ahora implementaremos el modelo con las nuevas variables seleccionadas y los datos balanceados:

Verificando manualmente el valor p de cada una de las variables, quitamos aquellas tales que el valor p exceda .05 que es nuestro nivel de confianza. Ahora vamos a revisar el supuesto de independencia revisaremos nuevamente las correlaciones con las variables finales de nuestro modelo.

Correlaciones para las variables finales

El mapa de correlaciones anterior sugiere una alta correlación para radio_medio y perimetro_extremo por lo que quitaremos una de las dos basándonos en la calificación obtenida en el desempeño del modelo.

Logit sobre el modelo y ver la mejor calificación de radio_medio vs perimetro_extremo

Ahora las variables seleccionadas muestran una correlación en general baja, lo que aporta a la hipótesis de independencia. Ahora calificaremos nuevamente el desempeño de nuestro modelo. Primero obtendremos la nueva matriz de confusión y posteriormente la precisión.

Ya no hay variables dependientes o con altas correlaciones

Ahora nuestra precisión es de 0.918. Así se ve la matriz de confusión:

Matriz de confusión

Por último, vamos a comprobar con un ROC Curve que es una herramienta usada en modelos de clasificación binarios, la forma de interpretar esta gráfica es que un clasificador preciso debe estar lo más lejos de la línea identidad (excepto en los extremos).

ROC Curve para verificar la precisión del modelo

Después de este procesamiento, podemos concluir que tenemos una precisión del 92% en promedio la cual es inferior a la propuesta en el primer modelo de regresión logística, la ventaja de este último modelo es la reducción de dimensión de 30 variables a 6 además de que se apega más a los supuestos del modelo de Regresión Logística, esto puede tener implicaciones en cuanto a generalización (que funcione en otras bases de datos) y costo computacional (menos tiempo de procesamiento).

SVM

Este algoritmo tiene como objetivo clasificar con base en distancias a hiperplanos diferentes clases de observaciones, es preferido por su nivel de precisión y su bajo costo computacional. Además otra ventaja de este algoritmo es que funciona bien para grandes dimensiones, es decir para gran cantidad de variables explicativas.

Después de esta implementación obtuvimos una precisión del 92.98% sin embargo, hay ciertas observaciones que es importante resaltar sobre este algoritmo.

  • Este algoritmo no es muy preciso cuando no hay una clara separación entre las clases de variables, en nuestro caso puede observarse en la visualización de PCA que existen observaciones que están mezcladas entre clases.
  • Este algoritmo optimiza distancias, es decir que no existe un fundamento estadístico para la clasificación, no considera la distribución de los datos.

KNN

Implementaremos ahora el algoritmo de KNN que es un algoritmo no paramétrico usado con frecuencia como modelo de clasificación o regresión.

Primero graficaremos el número de clústers que maximiza la función.

La maximización de clústers

Obtuvimos una precisión del 96.27% que es mayor a las precisiones obtenidas en los modelos anteriores, sin embargo hay que hacer ciertas observaciones sobre este modelo:

  • Este modelo no tiene un buen desempeño cuando hay gran cantidad de variables. Esto implica que para un nivel de precisión fijo, conforme crece el número de variables explicativas la cantidad de observaciones debe crecer de manera exponencial.
  • Tiene poco poder de generalización, es decir, tiene problemas de sobreajuste.
  • Los puntos anteriores implican que existe un gran costo computacional correr este algoritmo.

And last but not least…

Random Forest

Como esperábamos este modelo tiene una precisión del 97.36% que es la más alta con respecto a los demás modelos, algunos comentarios sobre este modelo son:

  • Este modelo es fundamentalmente predictivo, no explicativo, no tiene un sentido claro del procesamiento de información.
  • Para problemas complejos el costo computacional puede crecer demasiado.

Conclusiones

Después de probar los modelos anteriores notamos que cada una de las implementaciones tienen ventajas y desventajas, además existen modelos que se complementan entre sí como observamos en el caso de PCA, regresión logística y SVM, en donde un modelo de aprendizaje no supervisado puede trazar las posibilidades de clasificación y reducción de dimensiones, posteriormente implementar un modelo de aprendizaje supervisado para la predicción de la variable dependiente.

Cada problema tiene un contexto particular que debe ser considerado para la propuesta de modelos específicos, la cantidad y tipo de variables explicativas configuran el marco de referencia para la implementación de modelos.

En el caso particular de nuestro problema, el objetivo de predicción de la variable dependiente diagnóstico puede ser abordado en general desde dos perspectivas:

  • Por un lado, tenemos la meta de pronósticar con la mayor precisión si el diagnóstico para la paciente es favorable o lamentablemente desfavorable, de acuerdo a las métricas obtenidas si seguimos esta única meta el modelo de Regresión Logística nos da una precisión superior a los demás lo que se traduce en un error mínimo al clasificar, sin embargo es cuestionable su generalización a otras bases de datos relacionadas con este problema.
  • Por otro lado, tenemos la meta de generalizar este modelo a otras bases de datos, por lo que en este sentido nos inclinamos por el modelo de Regresión Logística paso a paso, dado que además de que se apega mejor a los supuestos específicos del modelo disminuye la dimensión del problema de 30 variables explicativas a 6 varaiables, esto último tiene impacto positivo en términos de procesamiento computacional y almacenamiento/recolección de datos.

Es cierto que para el objetivo de generalización perdemos puntos porcentuales de precisión (dado que la Regresión Logística paso a paso tiene una precisión del 92% en promedio) pero la ventaja de generalizar este modelo es una prioridad específicamente dadas las cifras de mortalidad que actualmente están asociadas al cáncer de mama.

Extender este modelo a bases de datos generadas por otros países, especialmente los de menor ingreso y peor cobertura de salud pública se traduce en menores tiempos de espera en diagnóstico, menor costo de procedimientos y tratamiento oportuno para las pacientes.

Otra ventaja en términos prácticos que sigue el mismo eje, es que las variables relevantes incluídas en el modelo final son 6, lo que representa una disminución del 80% en la dimensión del problema, para los países con menor presupuesto para investigación y salud será más barato crear bases de datos con solo 6 métricas por observación, también el almacenamiento y el posterior procesamiento de la información será más fácil y oportuno.

Referencias

Los datos presentados en la introducción fueron obtenidos de los siguientes artículos:

Integrantes

  • María José Sedano Castañeda
  • Dante Fernando Bazaldua Huerta
  • Carlos Alberto Gomez Vazquez

Presentación del proyecto: DemoDay

Repositorio

En el siguiente repositorio se encuentra el código usado para desarrollar esta aplicación: https://github.com/SaturdaysAI/Projects/tree/master/Lapaz/2021.ML2/Equipo%204

¡Más inteligencia artificial!

La misión de Saturdays.ai es hacer la inteligencia artificial más accesible (#ai4all) mediante cursos y programas intensivos donde se realizan proyectos para el bien (#ai4good).

Infórmate de nuestro master sobre inteligencia artifical en https://saturdays.ai/master-ia-online/

Si quieres aprender más inteligencia artificial únete a nuestra comunidad en community.saturdays.ai o visítanos en nuestra web www.saturdays.ai ¡te esperamos!

Detectando emociones mediante imágenes con Inteligencia Artificial

by 2020Donostia
Logo del equipo

Donostia. Primera edición. 2020

Introducción

En la vida cotidiana, ¿Cuántas veces nos ocurre que preguntamos a una persona qué tal está, y la respuesta es positiva mientras que su rostro indica lo contrario? ¿Cuántas veces has ido a la peluquería y has pretendido salir contenta cuando realmente, no te gustaba el resultado final? ¿Alguna vez has querido recibir el feedback de miles de personas en una conferencia o en el transcurso de ella?

Frase de Carl Rogers

Si nos ponemos a reflexionar sobre las cuestiones mencionadas, probablemente nos daremos cuenta de que muchas veces se miente cuando se tratan las emociones, ¿pero nuestra cara también miente?

Definición del problema

Muchas veces se da más importancia a lo que se dice con la voz, que a lo que se dice con la expresión facial, siendo más fácil mentir o esconder la realidad con la primera de ellas. Con este proyecto queríamos, además de desplegar un proyecto real de inteligencia artificial, hacer algo que pudiese ser útil, pudiese detectar las emociones de las personas según su cara, mediante una imagen o la detección de la cara con una webcam. Las emociones surgen cuando ocurre algo relevante. Aparecen rápidamente, de forma automática, y hacen cambiar nuestro foco de atención.

La inteligencia emocional es algo que ha ido adquiriendo mucha relevancia los últimos años, la importancia en percibir, usar, comprender y manejar las emociones, tanto las correspondientes a uno mismo como a las del resto. Para ello, es evidente que necesitamos emociones reales, por lo que queríamos facilitar la forma en la que se pueden percibir las emociones. ¿Será una máquina capaz de detectar y clasificar las emociones mejor que el ser humano?

Facial Expression Recogniser será una aplicación encargada de detectar las emociones a tiempo real. En esta primera versión se utilizarán las imágenes y, a continuación, su función será clasificar las emociones en cuanto la cámara pueda detectar caras.

Dataset

El dataset utilizado para el desarrollo de este proyecto, que se obtuvo en Kaggle, consistía en una serie de imágenes divididas en carpetas en función de la expresión de rostro. Las etiquetas de las carpetas se dividían según la siguiente clasificación:

0 — Angry

1 — Disgust

2 — Fear

3 — Happy emotions

4 — Sad

5 — Surprise

6 — Neutral

El objetivo principal del proyecto era detectar y clasificar las emociones según estas etiquetas. Para dicha predicción, se usaría imágenes obtenidas mediante la webcam.

Data train

La aproximación

Tal y como ha sido mencionado con anterioridad, a la hora de describir el dataset utilizado, se ha visto que se contaba con imágenes y con las etiquetas de las emociones correspondientes. Esto ha hecho que el proceso de EDA haya restado importancia en este proyecto.

Sin embargo, si ha sido necesario cierto análisis y transformación de los datos. Para empezar, se ha tenido que crear dataframes partiendo del dataset. Para ello, se ha pasado de las fotos que se tenían a pixeles, y se han creado dos columnas en dicha tabla, una la relacionada con la emoción y la otra con los píxeles.

Formato dataset

Además, cabe destacar que desde un inicio se contaba con una clasificación del dataset entre train y test, por lo que la transformación de imágenes a pixels se hizo dos veces, terminando así con dos dataframes: train_data y test_data

Tamaño de tablas

Construyendo el model

El proyecto realizado se basa en Deep Learning, por lo que ha sido necesario el uso de redes neuronales. En nuestro caso, se han utilizado redes neuronales convolucionales, las cuales se utilizan sobre todo para tareas de visión artificial, pues son muy efectivas en la clasificación y segmentación de imágenes, entre otras aplicaciones.

Para ello, se ha presentado un modelo secuencial, lo que permite apilar capas secuenciales en orden de entrada a salida.

Las capas añadidas al modelo han sido:

– Conv2D

– Batch Normalization

– MaxPooling2D

– Flatten

– Dense

– Activation

– Dropout

Para crear el modelo anteriormente mencionado, se ha utilizado Tensorflow y Keras. Este último es una biblioteca de Redes Neuronales escrita en Python. Es capaz de ejecutarse sobre TensorFlow. Este último satisface las necesidades de los sistemas capaces de construir y entrenar redes neuronales para detectar y descifrar patrones y correlaciones.

Después de crear el modelo se inició el entrenamiento del modelo. Al principio, se entrenó el modelo con un solo epoch, lo que además de tardar mucho tiempo, solo obtuvo un accuracy del 0,29. Es por esto por lo que se tuvo que modificar el entrenamiento del modelo, aumentando los epochs, cambiando los pasos a dar en cada epoch, etc.

Además, debido a un problema de guardado se tuvo que crear un callback al ModelCheckpoint, para que almacenará un checkpoint cada vez que un epoch finalizara, así, se pudo obtener un modelo final con más epochs.

Al final, el modelo obtenido ha conseguido un accuracy final del 0.9602. Esto indica la precisión de lo que se entrenó. Sin embargo, si analizamos el val_accuracy, el cual se refiere a cuánto funciona su modelo en general para casos fuera del conjunto de entrenamiento, el valor obtenido ha sido del 0.6035.

Sin embargo, si calculamos la precisión del modelo con el dataset utilizado para el testeo, veremos que el accuracy es bastante bajo, del 0,1733, lo que implica tener mucho margen de mejora este modelo.

Predicción

Una vez tuviésemos el modelo listo, había que predecir y probarlo. Para ello, se codificó de forma que nos indicase aquellas emociones que se podían considerar en la expresión facial de la imagen introducida, y según el porcentaje, concluir con el sentimiento más significativo. Por ejemplo:

Imagen a predecir

Introducimos esta primera imagen, donde es evidente que el chico está mostrando cierto enfado. De esta forma, nuestro modelo lo ha clasificado de la siguiente manera:

Recalcando que el enfado es el sentimiento que predomina en la imagen. Si utilizamos nuestro modelo, con el fin de detectar alguna otra emoción, veremos que también funciona.

Imagen predecida

Tal y como se mencionara en las conclusiones, la intención era incorporar la detección de caras mediante las webcam y así, poder detectar las emociones de una forma más real.

Conclusiones

Una vez finalizado el proyecto, en una reflexión grupal, se comentó lo mucho que se ha aprendido en el desarrollo de este mismo, además de habernos dado cuenta de lo lejos que puede llegar la tecnología, y para ser más precisos la inteligencia artificial.

Hemos visto que en este ámbito de reconocimiento facial se están dando grandes avances, existen modelos que reconocen rostros incluso llevando la mascarilla puesta, y las aplicaciones de esta tecnología sólo están limitadas por nuestra imaginación. Desde el punto de vista de marketing, recoger el feedback de los usuarios y clientes es un proceso muy importante, pero obtener esta información suele costar, casi nadie nos paramos a rellenar un formulario para decir cómo ha sido nuestra experiencia a menos que haya sido negativa.

Es por ello que si somos capaces de detectar puntos rojos en la experiencia de los usuarios sin que suponga para ellos un esfuerzo más se podría mejorar el servicio, y gracias a esta tecnología esto sí es posible.

Próximos pasos

Los próximos pasos que se darán con este proyecto están directamente relacionados con los problemas que se han tenido en la culminación del proyecto. La primera dificultad sufrida por el equipo fue la correspondiente al despliegue en Amazon Web Services, lo que debía facilitar el entrenamiento, hizo que el proyecto quedase parado dada la inexperiencia de los integrantes del equipo con dicha herramienta. Esto ha hecho que el entrenamiento no se pudiese hacer en los servidores de Amazon, lo que ha tardado mucho tiempo y dificulta cualquier modificación y ejecución en el modelo. Es por esto por lo que, próximamente, se intentará realizar dicho despliegue para poder trabajar de una manera más eficiente y eficaz.

Este problema hizo que la desviación sufrida en el tiempo fuese muy elevada, lo que dificultó la culminación de toda la funcionalidad que previmos en primera instancia. Además, esto también estaba directamente relacionado con el pequeño margen que nos quedaba para entrenar el modelo, lo que implica que la eficacia y precisión del modelo no sea la óptima, y aun quede un margen bastante amplio de mejora. Es por esto por lo que se podría, mediante más entrenamientos, obtener un modelo de mayor calidad.

No considerábamos tener tantos problemas cuando definimos el proyecto que queríamos realizar, debido a la inexperiencia que teníamos en este ámbito. Una de las funcionalidades que planteamos al principio era la incorporación de una Web Cam que nos permitiera sacar fotos al instante y poder clasificar las emociones de dicha imagen, para poder hacerlo más real. Sin embargo, debido a la falta de tiempo, es un aspecto que no se ha podido desarrollar pero que sería lo primero que realizaríamos en el futuro.

Sería muy útil integrar nuestro modelo con webcams en las entradas/salidas de todos aquellos lugares que quieran valorar la satisfacción o experiencia del cliente en dicho lugar. Por ejemplo, restaurantes, tiendas, conferencias, etc.

Además, en el futuro sería genial programar que la aplicación fuese capaz de reconocer una imagen tomada en la salida de un lugar con aquella imagen tomada en la entrada a la misma persona. Eso haría que se pudiese comparar eficientemente los resultados de todos los usuarios, y sería un paso adelante enorme ya que dotaríamos a la empresa/institución que lo utilice de inteligencia empresarial. Si a eso le sumásemos una serie de gráficos que visualicen los resultados en una especie de dashboard, podría ayudar a los directivos a tomar diversas decisiones en base a la satisfacción del cliente.

Integrantes

Presentación del proyecto: DemoDay

Repositorio

En el siguiente repositorio se encuentra el código usuado para desarrollar esta aplicación: https://github.com/SaturdaysAI/Projects/tree/master/Donostia/Donostia2020/Facial_Expression_Saturdays

¡Más inteligencia artificial!

La misión de Saturdays.ai es hacer la inteligencia artificial más accesible (#ai4all) mediante cursos y programas intensivos donde se realizan proyectos para el bien (#ai4good).

Infórmate de nuestro master sobre inteligencia artifical en https://saturdays.ai/master-ia-online/

Si quieres aprender más inteligencia artificial únete a nuestra comunidad en community.saturdays.ai o visítanos en nuestra web www.saturdays.ai ¡te esperamos!

AlreSalud. Aplicación para medir la calidad del aire

AIreySalud: Modelación de la calidad del aire con Inteligencia Artificial

by 2020Latam
AlreSalud. Aplicación para medir la calidad del aire

Latam online. Primera Edición. 2020

¿Cómo adelantarnos al enemigo invisible?

Según la Organización Mundial de la Salud, la contaminación del aire representa uno de los mayores riesgos para la salud, mostrando una relación directa con la carga de morbilidad derivada de accidentes cerebrovasculares, diferentes cánceres de pulmón y neumopatías crónicas e incluso agudas, entre ellas el asma.

Existen estudios que confirman que alinearse a las directrices recomendadas por la OMS derivan en un impacto de hasta 22 meses más en el aumento de la esperanza de vida en la población (WHO, 2016).

Radiografía del aire

En 2016, el 91% de la población vivía en lugares donde no se respetaban las Directrices de la OMS sobre la calidad del aire. Según estimaciones de 2016, la contaminación atmosférica en las ciudades y zonas rurales provoca cada año 4.2 millones de defunciones prematuras. Un 91% de esas defunciones prematuras se producen en países de bajos y medianos ingresos, y las mayores tasas de morbilidad se registran en las regiones del Sudeste de Asia y el Pacífico Occidental.

En los países de bajos y medianos ingresos, la exposición a contaminantes en el interior y alrededor de las viviendas como consecuencia del uso de combustibles en estufas abiertas o cocinas tradicionales incrementa el riesgo de infecciones agudas de las vías respiratorias inferiores, así como el riesgo de cardiopatías, neumopatía obstructiva crónica y cáncer de pulmón en los adultos.

Existen graves riesgos sanitarios no solo por exposición a las partículas (PM10 y PM2.5, es decir, partículas menores que 10 y 2.5 micrómetros respectivamente), sino también al ozono (O3), el dióxido de nitrógeno (NO2) y el dióxido de azufre (SO2). Como en el caso de las partículas, las concentraciones más elevadas suelen encontrarse en las zonas urbanas. El ozono es un importante factor de mortalidad y morbilidad por asma, mientras que el dióxido de nitrógeno y el dióxido de azufre pueden tener influencia en el asma, los síntomas bronquiales, las alveolitis y la insuficiencia respiratoria.

Las industrias, los hogares, los automóviles y los camiones emiten mezclas complejas de contaminantes atmosféricos, muchos de los cuales son perjudiciales para la salud. De todos estos contaminantes, el material particulado fino tiene el mayor efecto sobre la salud humana. La mayor parte del material particulado fino proviene de la quema de combustible, tanto de fuentes móviles como vehículos, como de fuentes estacionarias como centrales eléctricas, industria, hogares o quema de biomasa.

Y esto… ¿cómo se mide?

La calidad del aire se mide a partir de las concetraciones de los contaminantes que están presentes en la atmósfera, en particular en el caso de las partículas finas se representa por la concentración media anual.

Aunque las partículas finas se mide en muchos lugares a lo largo del mundo, la cantidad de monitores en diferentes áreas geográficas varía, y algunas áreas tienen poco o ningún monitoreo. Para producir estimaciones globales de alta resolución, se requieren datos adicionales. La concentración media urbana anual de PM2.5 se estima con modelos mejorados utilizando la integración de datos de sensores remotos por satélite, estimaciones de población, topografía y mediciones terrestres.

Es aquí que nace AIreySalud

Con la finalidad de poder entender a nuestro amenazante enemigo, nos dimos a la tarea de hacerlo nuestro mejor amigo. Conocer hasta el más microscópico detalle para que con la ayuda de la Inteligencia Artificial nos pudiéramos adelantar a sus pasos.

Hipótesis

La concentración promedio diaria de PM2.5 se puede predecir a partir de los contaminantes y parámetros meteorológicos que se monitorean de manera rutinaria en la Ciudad de México.

Metodología de trabajo

En la literatura se recomienda seguir el siguiente plan de modelación:

  • Análisis exploratorio de datos (identificar si hay valores faltantes y valores extremos, definir el tratamiento que se les dará)
  • Si es necesario, transformar los datos
  • Ajustar modelos (definir el conjunto de entrenamiento y de prueba)
  • Ajustar un modelo univariado y validarlo.
  • Ajustar un modelo agregando fechas especiales (días de asueto y festivos) y validarlo.
  • Ajustar un modelo agregando fechas especiales y regresores adicionales y validarlo.
  • Ajustar los hiperparámetros del modelo y validarlo.
  • Seleccionar el mejor modelo de acuerdo a los criterios de minimizar errores

A estos pasos se agregaría un paso previo: seleccionar los datos para responder al problema a modelar.

Seleccionar los datos

En el tema de calidad del aire los gobiernos locales cuentan en la mayoría de las veces con información de este tipo, sin embargo, a veces llega a presentar un alto porcentaje de datos faltantes. Por otro lado, no toda la información se encuentra disponible de manera frecuente o pasa por un proceso de validación, por lo tanto se determinó emplear datos de una zona metropolitana, que cada mes publica la información validada, es el caso de la información del Sistema de Monitoreo Atmosférico de la Ciudad de México — SIMAT-).

Periodo de análisis: se consideró 5 años completos (2015 a 2019) y lo que va del año 2020.

Se descargaron los datos de contaminantes y parámetros meteorológicos de los sitios de monitoreo del SIMAT (monóxido de carbono -CO-, dióxido de nitrógeno -NO2-, óxidos de nitógeno -NOx-, óxido nitrico -NO-, ozono -O3-, partículas menorea a 10 micrómetros -PM10-, partículas PM coarse que corresponde a la diferencia entre PM10 y PM2.5 -PMCO-, partículas menores a 2.52 micrómetros -PM2.5-, dióxido de azufre -SO2-, temperatura ambiente -TMP-, humedad relativa -RH-, presión atmosférica -PA-, presión barométrica -PBa-, velocidad del viento -WSP- y dirección del viento -WDR-) y se generó una base única. La información inicial representa los registros horarios de 39 sitios (ACO, SUR, TAH, TLA, TLI, SJA, PED, SAG, SFE, TPN, XAL, CCA, MGH, AJM, VIF, UAX, UIZ, CAM, MON, CHO, COY, CUA, MER, INN, HGM, CUT, AJU, ATI, LLA, LPR, NEZ, FAC, IZT, BJU, GAM, LAA, MPA, FAR y SAC) de monitoreo automático, sin embargo, por la construcción propia de un sistema de monitoreo de calidad del aire, no todos los sitios monitorean todos los contaminantes y parámetros meteorológicos. Aunado a esto, en el año 2017 se registró un sismo en la Ciudad de México que dañó la infraestructura de algunas instituciones en las que se localizaba estaciones de monitoreo, lo cual derivó en retirar los equipos de medición de esos lugares. Otra característica que presenta este tipo de fenómenos es la dependencia de sus registros con los ciclos temporales ya que su comportamiento se ve influenciado por la época del año y la hora del día (efecto de inversiones térmicas, época de lluvias, estabilidad atmosférica, horas pico del día, ubicación de fuentes de contaminación, entre otras).

Tabla.1. Listado de los sitios de monitoreo de calidad del aire del SIMAT.

Listado de los sitios de monitoreo de calidad del aire del SIMAT
Mapa 1. Localización de los sitios de monitoreo de calidad del aire del SIMAT (2020).
Mapa 1. Localización de los sitios de monitoreo de calidad del aire del SIMAT (2020).

Todo esto implicó que se realizaran varios pasos para determinar la inclusión de los sitios para este análisis.

Preprocesamiento de datos

Selección de sitios:

  1. Aquellos que monitorean PM2.5 (a saber: TLA, SJA, PED, SAG, SFE, XAL, CCA, MGH, UAX, UIZ, CAM, COY, MER, NEZ, HGM, AJM, BJU, INN, AJU, GAM, MPA, MON, SAC y FAR)
  2. Aquellos que presentan registros en el año 2019 y cuentan con al menos el 75% de registros de ese año (a saber: TLA, PED, SFE, XAL, CCA, AJM, MON, MER, HGM, NEZ y GAM).
Mapa 2. Localización de los once sitios de monitoreo de calidad del aire del SIMAT que serán modelados.
Mapa 2. Localización de los once sitios de monitoreo de calidad del aire del SIMAT que serán modelados.

El registro continuo de este tipo de datos requiere un programa de aseguramiento y control de calidad de las mediciones, el cual implica la pérdida de registros, por ejemplo, cuando se realizan calibraciones y revisión del correcto funcionamiento de los equipos automáticos; así como, por la falta de insumo de energía eléctrica que conlleva la reactivación de los equipos. Esto se refleja en tener valores faltantes (missing values) en las bases de datos, por lo tanto, se debe plantear un tratamiento para el relleno de datos faltantes.

Análisis exploratorio de datos

  1. Se realizó la exploración de los sitios para identificar posibles asociaciones entre ellos por cada parámetro.
  2. Se revisó si existe alguna dependencia con rezago en las horas para cada parámetro.
  3. Se realizó la exploración asociada a la dirección del viento, para identificar alguna dependencia relacionada con la dirección de donde proviene el viento.

Para el análisis exploratorio se empleó la librería Open air de r-project.

Relleno de datos faltantes

  1. Se considera emplear modelos que permitan el ajuste aún con datos faltantes en la variable objetivo o respuesta (PM.2.5).
  2. De igual manera se considera emplear modelos que requieren que la variable respuesta no contenga faltantes, por lo que se emplearán varios métodos de imputación de valores faltantes para PM2.5 (cabe comentar que por la naturaleza de este tipo de datos rellenar con la media, mediana o alguna otra constante no es recomendable). Previamente se realizará una comparación de los métodos con un conjunto de datos completo en el que se simulan los faltantes y se evalúa el error de la imputación para seleccionar el mejor modelo de relleno de faltantes (se identifica el tipo de datos faltantes que rige a este fenómeno (MCAR, MAR o NMAR por sus siglas en inglés), que se refieren a un comportamiento completamente aleatorio, de forma aleatoria o bien no sigue un proceso aleatorio, respectivamente.
  3. En el caso de los modelos de pronóstico en el tiempo, se requiere que las variables regresoras no tengan faltantes en el período de entrenamiento ni en el periodo de prueba. Además, se requiere datos futuros para el pronóstico de PM2.5; por lo tanto, también se debe realizar imputación de datos faltantes.

Para el proceso de relleno de datos faltantes se exploraron varias técnicas sin llegar a buenos resultados ya que generaban valores constantes para el relleno (por ejemplo las opciones que tiene implementada la rutina Fancyimpute de Python), entre ellas:

  • SimpleFill: reemplaza las entradas que faltan con la media o mediana de cada columna.
  • KNN: imputación de vecinos más cercanos a través de la ponderación de registros usando la diferencia cuadrática media de las variables en las que dos filas tienen datos observados.
  • SoftImpute: compleción de la matriz mediante umbral suavizado iterativo de las descomposiciones de la SVD. Inspirado en el paquete SoftImpute para R, que se basa en algoritmos de regularización espectral para el aprendizaje de grandes matrices incompletas de Mazumder et. al.
  • IterativeImputer: una estrategia para imputar valores faltantes al modelar cada característica con valores perdidos como una función de otras características en forma rotativa. Un código auxiliar que se vincula al IterativeImputer de scikit-learn.
  • IterativeSVD: Compleción de la matriz mediante descomposición iterativa de SVD de bajo rango. Debería ser similar a SVDimpute de los métodos de estimación de valores perdidos para microarreglos de ADN de Troyanskaya et. al.
  • MatrixFactorization: factorización directa de la matriz incompleta en U y V de rango bajo, con una penalización por escasez de L1 en los elementos de U y una penalización de L2 en los elementos de V.
  • NuclearNormMinimization: implementación simple de Compleción de la matriz exacta a través de Optimización convexa por Emmanuel Candes y Benjamin Recht usando cvxpy. Demasiado lento para matrices grandes.
  • BiScaler: estimación iterativa de la media por fila/columna y desviación estándar para obtener una matriz doblemente normalizada. No se garantiza que converja, pero funciona bien en la práctica. Tomado de Completar matriz y SVD de bajo rango a través de mínimos cuadrados alternativos rápidos.

Por lo que se decidió rellenar a partir del perfil horario de la serie de datos, es decir considerando el promedio de registros para la misma hora a lo largo de la serie, esto asegura que se cuente con un valor diferenciado por hora y no se generan datos constantes para todos los registros faltantes.

Transformar los datos

En algunas ocasiones es recomendable transformar los datos para obtener un mejor ajuste, sin embargo algunas transformaciones pueden ocasionar falta de interpretación de los resultados, por lo cual se recomienda emplear transformaciones sencillas y fácil de revertir al momento de la interpretación.

En el caso de la variable respuesta (PM2.5) se transformará con el logaritmo natural para contar con un mejor comportamiento de los datos.

Y=ln(PM2.5)

En el caso de los regresores (o covariables) se estandarizan los datos en cada variable, debido a que cada una por su naturaleza está en unidades y escalas variadas.

Ajustar modelos

La librería Prophet de facebook (fbprophet),permite pronosticar datos de series de tiempo basado en un modelo aditivo donde las tendencias no lineales se ajustan a la estacionalidad anual, semanal y diaria, más los efectos de los días festivos. Funciona mejor con series de tiempo que tienen marcados efectos estacionales y varias temporadas de datos históricos. Prophet es robusto ante los datos faltantes y los cambios de tendencia, y normalmente maneja bien los valores atípicos.

Para modelar la serie temporal Prophet, separamos la señal en los siguientes componentes aditivos:

y(t)= g(t) + s(t) + h(t) + εt

Dónde:

  • y(t) es la variable a pronosticar
  • g(t) es la función de tendencia que modela cambios no periódicos usando un modelo de crecimiento de saturación no lineal o un modelo de regresión lineal por partes. Puede configurar esto usando parámetros.
  • s(t) es el funcional estacional (anual, semanal y diario) que modela los cambios periódicos en el valor de la serie temporal. Este componente se modela mediante una transformada de Fourier y, si lo desea, puede agregar sus propias estacionalidades.
  • h(t) representa la función para modelar días festivos y eventos de impacto especial. Puede agregar su propio conjunto de feriados personalizados y eventos especiales.
  • εt es el error/ruido de los modelos que se supone que tiene una distribución

Para un descripción más detallada del algoritmo consultar https://peerj.com/preprints/3190/

El algoritmo funciona mejor con series de tiempo que tienen fuertes efectos estacionales y varias temporadas de datos históricos. Prophet es robusto ante los datos faltantes en la variable de salida y a los cambios de tendencia, y normalmente maneja bien los valores atípicos (outliers).

Se establecieron los grupos de entrenamiento y prueba para evaluar los modelos considerando la secuencia de la información y a diferencia de tomarlos al azar, se estableció dejar los primeros cuatro años como periodo de entrenamiento y el último año como periodo de prueba.

Resultados

Seleccionar los datos

Se seleccionaron los datos de calidad del aire de las estaciones localizadas en la Zona Metropolitana de la Ciudad de México, que presentan registros entre los años 2015 y 2020, de estas estacione se realizó un filtro para tener las estaciones que contaban con registros de PM2.5, a estas estaciones se les realizó un segundo filtro para contar con las estaciones que registraron dato en el año 2019 y que contaron con suficiencia anual (al menos el 75% de registros horarios en el año) de esta manera se contó con un conjunto de once estaciones (ver Mapa 2).

Análisis exploratorio de datos

El análisis exploratorio permitió conocer el comportamiento de cada variables, en el caso de PM2.5 (Figura 1) se observó que hay diferencias entre las estaciones, ya que algunas presentan mayor cantidad de eventos atípicos, esto se debe principalmente al lugar en el que se localiza cada estación y las fuentes de contaminación asociadas a ellas.

Figura 1. Comportamiento de PM2.5 de los once sitios elegidos para la modelación

Para ejemplificar el resto de los resultados se presenta el caso de la estación Ajusco Medio (AJM), para su localización consulte el Mapa 2.

El análisis por variable deja ver que son frecuentes los periodos de ausencia de datos, la diferencia en el comportamiento de cada parámetro (algunos presentan distribuciones sesgadas a la derecha, otros a la izquierda y algunos su distribución es simétrica, algunos presentan más de una moda y suele haber datos atípicos) (Figura 2).

El comportamiento de PM2.5 con respecto a la dirección del viento, muestra una clara asociación en meses de invierno (enero y diciembre) en la dirección noreste y con una franja de influencia del norte al este, y en los meses de abril y mayo se repite con un ligero corrimiento hacia el sur (colores rojos en la Figura 3), también se identifica la dilución de este contaminante en los meses de lluvias, ya que predominan los colores azules, verdes y amarilos en todas las direcciones del viento.

Figura 2. Distribución de los registros horarios en la estación Ajusco Medio (AJM) y representación de la rosa de concentraci
Figura 2. Distribución de los registros horarios en la estación Ajusco Medio (AJM) y representación de la rosa de concentración desagregada por mes

La desagregación por época climática para cada año permite apreciar los cambios a lo largo del periodo, (cabe comentar que la época invernal considera el diciembre de un año y el enero y febrero del siguiente año), se identifica el cambio de rojos a naranjas a lo largo de los años en la época invernal y en 2020 no registró esos colores (presenta concentraciones menores). También se marca la influencia de la primavera (marzo a mayo) con concentraciones altas principalmente en 2016, 2017 y 2019 (Figura 4).

Figura 3. Representación de la rosa de concentración de PM2.5 desagregada por mes
Figura 4. Distribución por época climática (primavera, verano, otoño e invierno) de la rosa de concentración desagregada por
Figura 4. Distribución por época climática (primavera, verano, otoño e invierno) de la rosa de concentración desagregada por año.

La serie de tiempo de los registros horarios de PM2.5 se representa en la Figura 5, se puede apreciar los espacios en blanco correspondientes a los valores faltantes en esos días, así como la variación del fenómeno y los valores extremos.

Figura 5. Serie de tiempo de la concentración horaria de PM2.5 en el periodo 2015–2020 para la estación AJM.
Figura 5. Serie de tiempo de la concentración horaria de PM2.5 en el periodo 2015–2020 para la estación AJM.

La modelación se realizará con registros promedios diarios de PM2.5 por lo que se visualizó el comportamiento de estos en la Figura 6.

Figura 6. Series temporales de los promedios diarios para los diferentes contaminantes y parámetros meteorológicos en AJM (20
Figura 6. Series temporales de los promedios diarios para los diferentes contaminantes y parámetros meteorológicos en AJM (2015–2020).

La variación de PM2.5 a partir de registros diarios permite identificar la presencia de ciclos asociados a los meses y años (Figura 7).

Figura 7. Concentración diaria de PM2.5 en el periodo 2015–2020 para la estación AJM.

Transformar los datos

En el caso de PM2.5 la transformación fue con el logaritmo natural, la Figura 8 muestra el comportamiento original y la transformación, donde se busca tener una distribución más apegada a la simetría.

Figura 8. Distribución de PM2.5, original y transformada (AJM, 2015–2020).
Figura 8. Distribución de PM2.5, original y transformada (AJM, 2015–2020).

En el caso de los regresores se realizó la transformación por separado para el conjunto de datos de entrenamiento y de prueba (Figura 9).

Figura 9. Distribución de regresores estandarizados en el conjunto de entrenamiento y de prueba (AJM, 2015–2020)

Ajustar modelos

Comenzamos modelando la serie univariada de PM2.5 sin imputar faltantes ya que el modelo maneja la falta de información en la variable de salida.

Generamos el conjunto de entrenamiento desde el 2015–01–01 hasta el 2018–12–31 y el conjunto de prueba a partir del 2019–01–01 y hasta el 2020–09–30 para entrenar y evaluar el modelo respectivamente. Se incorporan los días festivos de México al modelo para lograr un mejor ajuste.

Fragmento de código con los valores de los hiperparametros utilizados para entrenar el algoritmo:

pro_change=Prophet(changepoint_range=0.9,yearly_seasonality=True,

holidays=holidays)

pro_change.add_country_holidays(country_name=’MX’)

forecast = pro_change.fit(train).predict(future)

fig= pro_change.plot(forecast);

a = add_changepoints_to_plot(fig.gca(), pro_change, forecast)

El modelo genera un valor predictivo llamado yhat, y un intervalo de confianza con límite inferior yhat_lower y límite superior yhat_upper para la concentración de PM2.5, fijamos el nivel de confianza del 95%.

Fragmento de código para hacer el cross validation

from fbprophet.diagnostics import cross_validation

cv_results = cross_validation( model = pro_change, initial = ‘731 days’, horizon = ‘365 days’)

En la Figura 10 los puntos negros representan los valores de concentración promedio diaria de PM2.5, la curva en azul oscuro es el pronóstico generado por el modelo y la zona azul celeste es el intervalo de confianza al 95 %.

Figura 10. Ajuste del modelo de PM2.5 en la estación AJM

En la Figura 11 se muestra la descomposición de la serie en su tendencia, los días festivos, la estacionalidad semanal y anual.

Figura 11. Descomposición de la serie de PM2.5 en la estación AJM.

La función performance_metrics se puede utilizar para calcular algunas estadísticas útiles para medir el desempeño de la predicción (yhat, yhat_lower y yhat_upper versus y), en función de la distancia desde el límite (qué tan lejos en el futuro estaba la predicción). Las estadísticas calculadas son el error cuadrático medio (MSE), la raíz cuadrada del error cuadrático medio (RMSE), el error absoluto medio (MAE), el error porcentual absoluto medio (MAPE), el error porcentual absoluto medio (MDAPE) y la cobertura de las estimaciones yhat_lower y yhat_upper. Estos se calculan en una ventana móvil de las predicciones en el dataframe después de clasificar por horizonte (ds menos cutoff). Por defecto, el 10% de las predicciones se incluirán en cada ventana, pero esto se puede cambiar con el argumento rolling_window.

Fragmento de código para la obtención de las métricas

Una vez que se corrieron los diferentes modelos, se realizó la comparación de las métricas para determinar el mejor modelo. En el caso de AJM, el mejor modelo a partir de RMSE fue el ajuste con hiperparámetros, seguido del modelo con regresores en general. Para todas las métricas, el modelo con menor error fue el de los hiperparámetros.

Tabla 2. Comparativa de las métricas de los modelos ajustados (AJM, 2015–2020)

A continuación se presenta la representación gráfica del mejor modelo ajustado, distinguiendo el periodo de entrenamiento, el de prueba y el pronóstico (Figura 12).

Figura 12. Ajuste del mejor modelo (AJM, 2015-2020)

Como resultado agregado al modelar estos datos, podemos detectar si en días futuros se puede presentar algún riesgo para la salud, con referencia a las Directrices de la Organización Mundial de la Salud para el promedio de 24 horas de PM2.5 (25 g/m³) y los rangos establecidos en el Índice AIRE y SALUD de México (NOM-172-SEMARNAT-2019).

Tabla 3. Niveles de riesgo de la calidad del aire (2020)

Fuente:Comisión Ambiental de la Megalópolis (CAMe)

En el caso de Ajusco Medio el pronóstico identifica registros posibles entre las bandas de calidad del aire buena y aceptable, y al considerar el intervalo de confianza del modelo (Figura 13) se identifica que los registros podrían llegar hasta la banda de calidad el aire mala, lo que podría presentar algún riesgo para la población.

Figura 13. Alertas por calidad del aire en AJM, datos medidos y pronóstico al 31/01/2021

Qué sigue

Se abre un mar de oportunidades para mejorar este primer acercamiento a modelar la calidad del aire por medio de inteligencia artificial. Los modelos se aplicaron a cada una de las estaciones, pero se puede desarrollar un modelo multiseries. De igual manera se estableció el total de variables contra las que se realizó el ajuste, pero se puede realizar una búsqueda entre los regresores que mayor aportación presentan al modelado de PM2.5.

Desarrollar una aplicación para dar difusión de los resultados.

Probar otros conjuntos de datos de diferentes ciudades.

y mucho más…

Referencias

Basheer O, et al. Imputation of Missing Values in Daily Wind Speed Data Using Hybrid AR-ANN Method Modern Applied Science 9(11):1, June 2015

Mazumder R., Hastie T., Tibshirani R. Spectral regularization algorithms for learning large incomplete matrices. The Journal of Machine Learning Research 11, 2287–2322

Medina F. y Galván M. Imputación de datos: teoría y práctica. CEPAL, 2007.

Shaadan N. and RahimN A M. 2019 J. Phys.: Conf. Ser. 1366 012107.

Taylor SJ, Letham B. 2017. Forecasting at scale. PeerJ Preprints 5:e3190v2

Troyanskaya G, et al. Missing Value Estimation Methods for DNA Microarrays June 2001. Bioinformatics 17(6):520–525

WHO, 2016. Health risk assessment of air pollution — general principles. Copenhagen: WHO Regional Office for Europe; 2016.

Librerías o paquetes

Carslaw, D. C. and K. Ropkins, (2012) openair — — an R package for air quality data analysis. Environmental Modelling & Software. Volume 27–28, 52–61.

Facebook Open Source, Prophet. https://facebook.github.io/prophet/

Fancyimpute https://github.com/iskandr/fancyimpute

Integrantes

Presentación del proyecto: DemoDay

Repositorio

En el siguiente repositorio se encuentra el código usado para desarrollar esa aplicación: https://github.com/SaturdaysAI/Projects/tree/master/LATAM_remote/SaturdaysAI-LATAM_AIreySalud_2020-main

¡Más Inteligencia artificial!

La misión de Saturdays.ai es hacer la inteligencia artificial más accesible (#ai4all) mediante cursos y programas intensivos donde se realizan proyectos para el bien (#ai4good).

Infórmate de nuestro master sobre inteligencia artifical en https://saturdays.ai/master-ia-online/

Si quieres aprender más inteligencia artificial únete a nuestra comunidad en community.saturdays.ai o visítanos en nuestra web www.saturdays.ai ¡te esperamos!

BasketTracker.AI

BasketTracker.AI: Inteligencia artificial para la bolsa de la compra

by 2020Latam
BasketTracker.AI

Latam online. Primera Edición. 2020

Lo que no se mide, no se puede mejorar…

Las altas y bajas en los precios son un fenómeno que todos vivimos a diario. Es tan cotidiano que muchos damos por hecho que se trata de una situación que no podemos cambiar y que sólo nos queda ajustar nuestro presupuesto ante los incrementos que suceden.

¿Será posible crear herramientas que nos ayuden a adaptarnos mejor al cambio en los precios? Nosotros creemos que sí.

En este artículo les mostraremos cómo fué que mientras aprendíamos un poco de Inteligencia Artificial también implementamos un prototipo para monitorear precios de tiendas en línea.

Muchas veces sin saber compramos bienes cuyo precio está en aumento y según la ley de oferta y demanda, solo reforzamos su tendencia alcista cuando consumimos estos productos. Si por el contrario, supiéramos cómo sustituir estos artículos caros con “equivalentes” de menor costo, a largo plazo ayudaríamos a generar un nivel de precios más bajo.

Así que nos propusimos hacer un prototipo para monitorear dichos precios. Desde los primeros intercambios de ideas que tuvimos nos dimos cuenta que eran varios los desafíos que debíamos superar para lograr nuestro propósito.

¿Y dónde están los precios?

La primera pregunta que planteamos fue cuáles serían los precios que nos interesaba recabar. Decidimos iniciar con algunos artículos de consumo básico: (a) huevo, (b) frijol, (c) papel higiénico, (d) café y (e) tortillas.

Lo más sorprendente de todo es que la mayoría de la información de precios se encontraba a nuestro alcance. Existe una gran cantidad de supermercados que publican catálogos de sus productos en línea. Para la fase inicial decidimos extraer los precios de los artículos de dos supermercados mexicanos: Soriana y Superama.

Nuestros compañeros Gabriela y Gustavo trabajaron en la extracción de precios, utilizando web scraping. El web scraping es una técnica que permite automatizar la extracción de datos alojados en páginas web. En la siguiente imagen mostramos la información que deseamos extraer desde el sitio web:

Captura de pantalla del sitio Soriana para el producto “huevo”
Captura de pantalla del sitio Soriana para el producto “huevo”

Con sus habilidades de Ingeniería de Datos, nuestros AI fellows desarrollaron una serie de scripts con Python, Selenium, entre otras herramientas. Como resultado de esta etapa de extracción, consiguieron generar nuestros primeros conjuntos de datos en bruto (Raw Datasets):

Precio de los huevos
Raw Dataset Superama
Precio de los huevos II
Raw Dataset Soriana

Entre los principales retos enfrentados fueron: (a) Simular el comportamiento de una persona. Si la velocidad de generación de consultas al sitio web es mayor que la que un usuario corriente haría, normalmente los sitios bloquean a los scripts. Por ello fue necesario considerar retrasos en las consultas para evitar ser bloqueados. (b) La estructura de los sitios web, aunque similar, es diferente. Fue necesario hacer pequeñas adecuaciones para cada uno de los sitios.

Integración de datos con AI

Cuando revisamos los primeros Raw Data sets generados, observamos que era necesario trabajar en homologar criterios de nomenclatura entre las fuentes Soriana y Superama, sobre todo en el campo “descripción”.

Ramón y Juan Esteban tomaron la iniciativa para aplicar técnicas de Natural Language Processing (NLP) para integrar los Raw Data sets obtenidos de Soriana y Superama.

Nuestros colegas propusieron enriquecer el Raw Dataset con las siguientes columnas:

  • Tipo: Es el tipo principal de producto. Por ejemplo, “huevo” puede ser un descriptor para cualquier marca de huevo.
  • Tipo_2 : Es el segundo descriptor, útil para construir una subcategoría al Tipo. Por ejemplo, huevo blanco y huevo rojo son dos tipos de huevo que se necesita diferenciar.
  • Marca: Información sobre marca y submarca de cada Tipo.
  • Empaque: Empaque de cada Tipo.
  • Contenido: Cantidad de cada Tipo en un Empaque.
  • Unidad de medida: Corresponde a cada cantidad en Contenido.

Los scripts que desarrollaron emplearon las siguientes bibliotecas de Python:

  • Nltk
  • Sklearn
  • Fancyimpute
  • Pandas
  • Numpy
  • Unidecode
  • Re

Este diagrama describe los pasos para unificar los datos de Soriana y Superama:

Diagrama de flujo para limpieza de datos
Diagrama de flujo para limpieza de datos

Adicional de las técnicas de lenguaje natural descritas en el diagrama, realizaron la simplificación del diccionario de categorías de forma manual, con la que evitaron considerar palabras derivadas o aquellas que no aportan información valiosa.

También realizaron la imputación de valores faltantes aplicando una técnica condicional con la que la inferencia de valores imputados se realiza utilizando una secuencia lógica. Por ejemplo, si conocemos que comúnmente la unidad de medida de la leche es por L o ml, la categorización sigue una secuencia lógica para imputar este valor.

Aplicando las técnicas de lenguaje natural más la imputación descrita, generaron el siguiente conjunto de datos enriquecido.

Conjunto de datos depurado
Conjunto de datos depurado

Los principales retos de la metodología empleada se exponen a continuación: (1) La creación manual de los diccionarios de palabras para poder categorizar en las columnas de interés correspondientes. Por ejemplo, la categorización del tipo de alimento que se describe. (2) Procesar palabras nunca antes vistas por el diccionario. Los anglicismos juegan un papel importante en el léxico hispano por lo que un reto importante es la traducción de los anglicismos o en su defecto incluirlos en el diccionario de categorías.

Precios como series de tiempo

Con un Data set depurado de precios, pareciera que tendríamos los elementos necesarios para hacer análisis más detallados como pronósticos de precios. Pero debido a que la dinámica de precios presenta cambios significativos en espacios de tiempo de una semana, para el tiempo que escribimos este artículo solo contábamos con unos cuantos puntos recolectados semanalmente.

De acuerdo con un artículo escrito por Box y Jenkins en 1976, se recomienda al menos 50 observaciones para realizar pronósticos confiables y en trabajos más actuales, como el de Otero y Trujillo en 1998, se han obtenido buenos resultados con 30 observaciones.

A pesar de esta situación adversa, dos miembros del equipo, John y Mario, quisimos iniciar el análisis de series de tiempo con un conjunto de datos independiente que si contara con dicha cantidad de observaciones, para simular el pronóstico de los precios futuros con el criterio de que el modelado sea automático, es decir, que se seleccione el modelo con mejor MAPE (Mean Absolute Percentage Error). Analizamos los siguientes algoritmos:(1) Auto Arima, (2) Suavizado Exponencial triple, (3) Facebook Prophet.

A continuación mostramos los resultados que obtuvimos al modelar cuatro acciones (spx, dax, ftse, nikkei) que se cotizan en diferentes bolsas, con el algoritmo que obtuvo el mejor desempeño:

BasketTracker.AI: Monitor de precios

Finalmente, coronamos el esfuerzo descrito anteriormente con una herramienta de visualización que nos permitiera sacar provecho de nuestro Dataset depurado y enriquecido, para ayudar a la toma de decisiones en precios.

Nuestro compañero Juan Manuel y nuestro mentor David, tomaron el liderazgo de la comunicación visual, así como del despliegue del monitor BasketTracker.AI en una aplicación web.

A continuación presentamos los elementos que elegimos comunicar visualmente: (1) Series de tiempo y predicción, (2) Cálculo de inflación de productos, (3) Comparativa entre marcas y tiendas, (4) Top 3 de artículos con mayor/menor costo y algunos KPIs

Consideramos que todo lo anterior debíamos consolidarlo en un solo punto. Debería ser algo de fácil acceso que reuniera todos los elementos que definimos desarrollar en un inicio y presentarlos de manera sencilla hacia el usuario final. Por esto decidimos que la mejor manera de lograrlo sería con un dashboard general de resultados.

Se crearon dos dashboards interactivos, el primero usando el software Tableau y el segundo la herramienta QuickSight de Amazon.

A continuación mostramos algunos screenshots de los dashboards:

Dashboard QuickSight
Dashboard Tableau

Conclusiones

En este artículo compartimos nuestra experiencia desarrollando un monitor de precios como proyecto de equipo en la primera edición de Saturdays AI Latinoamérica. Nos sentimos satisfechos de haber acoplado diferentes disciplinas dentro de la Inteligencia Artificial, como son NLP y pronóstico de series de tiempo, con aspectos de integración de datos y desarrollo web y de Business Intelligence para construir una prueba de concepto para monitorear precios.

Desde luego que hay todavía muchas mejoras que realizar y probablemente las desarrollaremos en futuras versiones de nuestro trabajo.

Esperamos que este artículo los motive a fortalecer sus habilidades en Inteligencia Artificial, poniendo en práctica sus conocimientos para aprender haciendo. Hasta la próxima.

Bibliografía

Box, G. E. P., and G. M. Jenkins. 1976: Time Series Analysis: Forecasting and Control. Ed. Holden-day. San Francisco.

Otero, J; Trujillo, F. 1998: “Forecasting Tourism Demand in the Short Term: The Case of Andalusian Hotel Establishments”, 4th International Forum on Tourism Statistics. Copenhague

Integrantes

  • Gabriela Vega
  • Gustavo Leyva
  • Juan Esteban Zurita
  • Juan Manuel Ahumada
  • John Jacho
  • Ramón Díaz
  • Mario Fonseca

Presentación del proyecto: DemoDay

Repositorio

En el siguiente repositorio se encuentra el código usado para desarrollar esta aplicación: https://github.com/SaturdaysAI/Projects/tree/master/LATAM_remote/equipo_dorado

¡Más inteligencia artificial!

La misión de Saturdays.ai es hacer la inteligencia artificial más accesible (#ai4all) mediante cursos y programas intensivos donde se realizan proyectos para el bien (#ai4good).

Infórmate de nuestro master sobre inteligencia artifical en https://saturdays.ai/master-ia-online/

Si quieres aprender más inteligencia artificial únete a nuestra comunidad en community.saturdays.ai o visítanos en nuestra web www.saturdays.ai ¡te esperamos!

Tipos de violencia de género

Identificar violencia en la música con Inteligencia Artificial. ¿Oímos o escuchamos música?

by 2020Latam

Latam online. Primera Edición. 2020

¿Te has puesto a pensar, qué escuchan tus hijos?

¿Alguna vez has pensado cómo influye la música en nuestra sociedad y viceversa?

Actualmente estamos rodeados de una gran cantidad de música que, aunque tiene ciertos filtros y criterios para su publicación, en ocasiones llega a oídos de cierta población que resulta afectada por el mensaje que se transmite. Hoy en día ya no es necesario contar con una disquera para promocionar una canción, ya que el acceso a las redes sociales permite que cualquier persona con un celular y acceso a internet se grabe y publique su canción llegando a miles de personas en el mundo, entre ellos menores de edad, como tus hijos.

Para que una canción llegue a ser escuchada existen varios canales de distribución como televisión, radio y las redes sociales, y si no se cuenta con un filtro adecuado, todo tipo de canciones con diferente contenido puede estar llegando a los oídos de menores de edad.

Nuestra propuesta se basa en identificar las canciones en las que, en su letra, exista contenido violento. De acuerdo al artículo “La violencia contra las mujeres en la música: Una aproximación metodológica”[1], dónde se habla sobre la violencia contra las mujeres en la música, indica que:

“en los casos más negativos se proyecta estereotipos que sitúan al hombre y a la mujer en posiciones sociales distintas, incluso llegando a justificar y potenciar la violencia contra las mujeres“.

Es por ello que este proyecto tiene como ambición contribuir al cumplimento de uno de los diecisiete Objetivos de Desarrollo Sostenible, planteados por las Naciones Unidas y aceptados por varios países en Latinoamérica, específicamente el objetivo cinco referente a la equidad de género. Para identificar y concientizar a la población sobre el mensaje que transmite la música y, de esta manera, empoderar a la población que tiene acceso a plataformas digitales de música, sobre los mensajes en las canciones que escucha.

Al inicio de este proyecto, se planteó una lluvia de ideas, se pensó en crear una app que al escuchar o ingresar una canción indique si esta contiene diversos tipos de violencia en sus letras, mediante el uso de Procesamiento Natural de Lenguaje (NLP), para lo cual se propuso el siguiente etiquetado:

Tipos de violencia de género
Tipos de violencia según artículo “La violencia contra las mujeres en la música: Una aproximación metodológica”, algunos iconos fueron obtenidos del artículo “De qué hablamos cuando hablamos de violencia contra la mujer”, de .infojusnoticias.gov.ar

Apto para menores de edad

No contiene ningún tipo de violencia, el mensaje y contexto de la canción debe ser revisado por un adulto.

Extracción de datos

Para ello, se empezó a analizar una muestra de 500 canciones, las cuales se seleccionaron de listas de popularidad de música latina, ya que el proyecto se plantea para la población hispanoparlante de América Latina, por lo que el flujo de trabajo quedó de la siguiente manera:

1) Se buscó en los rankings de Billboard y de Scanner Sound, la lista de canciones más tocadas con un web scraper, con lo que se obtuvo artista y título.

2) Mediante las herramientas de desarrollador de musixmatch se obtuvo la api el género musical de cada canción y si estas tienen lenguaje ‘explícito’, sin embargo solo nos proporcionaba el 40% de las letras.

3) De Google se obtuvo la letra de las canciones el cual se nutre de dos proveedores: Musixmatch y LyricFind, con lo que, finalmente, se obtuvieron los siguientes campos:

  • Artista
  • Género
  • Título
  • Si es explícita o no (lenguaje inapropiado)

Luego, se realizó la extracción de las letras de las canciones mediante API’s que ofrecen los sitios más populares de música (Musixmatch y el Billboard) mediante sus herramientas para desarrolladores.

Una vez que se obtuvieron las letras de las canciones se procedió al etiquetado manual, el cual se realizó de acuerdo a los tipos de violencia anteriormente expuestos. El equipo desarrollador de este proyecto, etiquetó las categorías de entrenamiento, con lo que se obtuvo una siguiente fuente de datos, su representación se puede ver a continuación:

Ejemplo de conjunto de datos obtenido en un primer etiquetado

Resulta importante destacar que, debido a que el etiquetado de cada categoría está sujeto a los criterios de cada integrante del equipo, el conjunto de datos podría tener un sesgo. Vale la pena mencionar, que esta etapa del proyecto es una prueba de concepto que nos servirá para validar la factibilidad de realizar un etiquetado automático de acuerdo al objetivo planteado. Además, al observar que el número de positivos en cada categoría no era suficiente para que el algoritmo pudiese tener un buen aprendizaje, se decidió agregar una categoría adicional, llamada ‘clase’, la cual indica si tiene contenido violento. Este cambio dentro del alcance se abordará más adelante.

EDA

Luego se procedió a realizar el Análisis Expiatorio de Datos (EDA). Para preparar los datos utilizando la librería ‘pandas’ para Python, así como matplotlib, seaborn y plotly para este primer análisis que nos permitiera tomar decisiones previas al preprocesamiento de los datos y tener un panorama de cómo se distribuían las clases en nuestra ‘data set’. y obtener un corpus que nos sirviera de base para iniciar con el análisis utilizando NLP.

Del conjunto de datos generado se obtuvieron algunos ‘insights’ interesantes mediante un primer Análisis Expiatorio de Datos (EDA):

Análisis/distribución de tipos de violencia

Gráfica de Barras que muestra el número de incidencias en cada clase del ‘data set’

En esta gráfica de barras podemos observar la distribución de los tipos de violencia que contiene la música seleccionada, en este caso, la mayor predominancia son géneros musicales de reggaeton, regional mexicano y pop en español debido a que se obtuvieron las canciones más escuchadas del momento, sin embargo, esta información no se utilizará para el algoritmo ya que podría crear un sesgo importante, como se puede observar en el histograma de acuerdo a los géneros. Vale la pena mencionar que este análisis se hizo antes de normalizar los datos para tener un panorama de cómo están distribuidos los datos.

Gráfica de barras que muestra cómo se distribuyen los tipos de violencia por género musical.

Se realizó un mapa de calor para descubrir cómo se relacionan los tipos de violencia dentro de las canciones que se consideraron.

Después del análisis de los tipos violencia, consideramos que separar la cantidad de canciones en las siete categorías seleccionadas no sería suficiente para hacer una buena clasificación ya que tenemos relativamente pocos positivos en cada categoría. Con base en esta observación, para una primera fase, se realizará la separación solo en 2 categorías: “violento” y “no violento”. Algo muy importante de destacar es, que aunque una canción no contenga violencia, no quiere decir que sea apto para infantes, debido a que podría tocar temas no aptos para ciertas edades.

Análisis con mapas de palabras con y sin la etiqueta de violencia

En una segunda aproximación, durante el preprocesamiento de los datos se obtuvieron mapas de palabras, como un segundo EDA, con el fin de identificar las palabras más frecuentes en contenido violento y no violento y reconocer algunas “stopwords” que debemos considerar o, en dado caso, palabras que deban lematizarse.

El preprocesamiento de los datos, en este caso, se realizó de la siguiente manera:

1) Normalización datos/letras de canciones (acentos, mayúsculas, signos de puntuación y eliminación de palabras como ‘oh’, ‘yeah’, ‘ma’, etc.)

2) Tokenizado de palabras

3) Remoción de ‘stopwords’

4) Lematización (en una siguiente etapa se considera ver si ‘stemming’ podría ayudar a obtener mejores resultados)

5) Vectorización de las canciones (en esta etapa del proyecto se emplea Bag of Words).

Posterior a que se hizo el preprocesamiento, se emplearon nuevamente mapas de palabras para observar qué palabras podrían ser más recurrentes en una canción con violencia y sin violencia. Sin embargo, al obtener los mapas de palabras, se observó que en ambos casos predominan palabras como: haber, querer, hacer y tener. Por lo que se incluyeron a la lista de ‘stopwords’ y se volvió a hacer un análisis con una nube de palabras.

mapa de palabras «sin violencia» antes de quitar stop words muy comunes
mapa de palabras «con violencia» antes de quitar stop words muy comunes
mapa de palabras «sin violencia» después de quitar stop words muy comunes
mapa de palabras «con violencia» después de quitar stop words muy comunes

Como se puede observar, ambas clasificaciones siguen teniendo algunas palabras en común como “decir” y “saber”. Sin embargo, se pueden observar diferentes palabras en el mapa de las canciones ‘con violencia’, como “olvidar”, “morir”, “perder”, “dejar”, etc.

Una vez que se tuvo la ‘corpora’ preparada y se aplicó la vectorización Bag of Words, se trabajó con la etiqueta de “violento” o “no Violento”, que va a representar si la canción tiene cualquier tipo de violencia en su contenido.

Entrenamiento y selección del modelo

Se probó con diferentes algoritmos, después de aplicar la representación ‘bag of words’ y usando la técnica de lematización con las herramientas de nltk, para los modelos se ocuparon las librerías de sklearn como Naive Bayes, Random Forest, Decision Tree, SVM y SGD.

Por cada modelo, se presentó un reporte de clasificación para visualizar su precisión ‘accuracy’ , pero también se consideró el f1-score para evaluarlos junto con un mapa de calor de la matriz de confusión.

Resultados obtenidos de los clasificadores, matriz de confusión y métricas obtenidas con las librerías sklearn y seaborn

Para poder comparar mejor el desempeño de los modelos, también se emplearon las curvas ROC. Lo cual nos muestra de una forma más visual el comportamiento de los modelos entre sí

Curvas ROC de los modelos obtenidas con las librerías sklearn y matplotlib

Curvas ROC de los modelos

Como se observa en la gráfica de curvas ROC, los modelos que tuvieron mejor desempeño fueron ‘Random Forest’ y ‘Naïve Bayes’, que tienen resultados muy similares. Sin embargo, si observamos las matrices de confusión y el ‘F1 Score’ podemos concluir que con los datos que se tienen, ‘Naïve Bayes’ es el modelo que mejor comportamiento tiene en esta etapa del proyecto. Ya que para nosotros es mejor tener una etiqueta de violencia aunque no la tenga, a que una canción con violencia sea erróneamente clasificada y llegue a menores de edad. Es decir, en términos técnicos es mejor para nosotros tener un error tipo I (falsos positivos), a un error tipo II (Falsos negativos).

Escalabilidad del proyecto

Con base en los datos generados, se hizo el aprendizaje considerando sólo 2 categorías ‘con violencia’ y ‘sin violencia’, debido a que la cantidad de canciones utilizadas no serían suficientes para que el algoritmo pueda diferenciar entre 6 clases diferentes, incluso se piensa que en un futuro, con mayor cantidad de datos de aprendizaje, se pueda hace la clasificación en 3 o 4 categorías, dependiendo del número de positivos que podamos obtener.

De obtener buenos resultados, se podría crear una API para uso en aplicaciones móviles o como plug in, con el fin de facilitar el reconocimiento de una canción y saber si dicha canción tiene o no contenido violento.

El conocer de antemano si una canción tiene o no contenido violento, será de ayuda para empoderar a los usuarios y reflexionar sobre el impacto que tiene lo que se escucha en la cultura popular sobre nuestras vidas y la cultura de la población.

Un caso particular de una aplicación podría ser como herramienta de detección de ‘violencia mediática’, en una ley recientemente aprobada en México: la ley ‘Olimpia’, en la cual se integró este término, que como se puede leer en el periódico Excélsior[2], se define como:

Todo acto que a través de cualquier medio de comunicación:

-Promueva estereotipos sexistas.

-Haga apología de la violencia contra mujeres y niñas.

-Produzca o permita la producción y difusión de discursos de odio sexista.

-Promueva la discriminación de género o desigualdad entre mujeres y hombres.

-Cause daño a las mujeres y niñas de tipo psicológico, sexual, físico, económico, patrimonial o feminicida.

Ejemplo de API con el logo del equipo desarrollador

Glosario:

NLP: Procesamiento Natural del Lenguaje, por sus siglas en inglés (Natural Language Processing) es la rama de la Inteligencia Artificial que estudia la interacción del lenguaje humano con las computadoras.

Corpus (pl. corpora): Un corpus lingüístico es un conjunto amplio y estructurado de ejemplos reales de uso de la lengua. Estos ejemplos pueden ser textos (los más comunes), o muestras orales (generalmente transcritas). [3]

Lematización: Relaciona una palabra flexionada o derivada con su forma canónica o lema. Y un lema no es otra cosa que la forma que tienen las palabras cuando las buscas en el diccionario. [4]

Stopword: Palabras muy comunes y poco informativas desde el punto de vista léxico, tales como conjunciones (y, o, ni, qué), preposiciones (a, en, para, por, entre otras) y verbos muy comunes (ser, ir, y otros más).[4]

Referencias:

Integrantes

  • Álvarez Leandro
  • Cuadros Alejandra
  • Morales Leobardo
  • Ramírez Héctor
  • Samaniego Luis

Presentación del proyecto: DemoDay

Repositorio

En el siguiente repositorio se encuentra el código usado para desarrollar esta aplicación:https://github.com/SaturdaysAI/Projects/tree/master/LATAM_remote/NLP_Violencia-en-musica–master

¡Más inteligencia artificial!

La misión de Saturdays.ai es hacer la inteligencia artificial más accesible (#ai4all) mediante cursos y programas intensivos donde se realizan proyectos para el bien (#ai4good).

Infórmate de nuestro master sobre inteligencia artifical en https://saturdays.ai/master-ia-online/

Si quieres aprender más inteligencia artificial únete a nuestra comunidad en community.saturdays.ai o visítanos en nuestra web www.saturdays.ai ¡te esperamos!

CARDIOSIGHT: Calculadora de Riesgo Cardiovascular mediante Inteligencia Artificial

by 2020Guadalajara

Guadalajara. Segunda Edición 2020

¿Sabias que las enfermedades cardiovasculares (ECV) son la principal causa de muerte en todo el mundo?

En México, el 19% de mujeres y hombres de 30 a 69 años mueren de enfermedades cardiovasculares, y se estima que el 70.3% de la población adulta vive con al menos un factor de riesgo cardiovascular.

Las enfermedades cardiovasculares son un grupo de desórdenes que afectan al corazón y/o los vasos sanguíneos , las cuales representan un problema de salud pública en México .

Estudios epidemiológicos han permitido identificar un conjunto de variables denominadas factores de riesgo de tipo cardiovascular (FRCV), que son todas aquellas características biológicas no modificables y características conductuales modificables (estilos de vida), cuya presencia se relaciona con una mayor probabilidad de sufrir una enfermedad cardiovascular en el futuro. Su identificación temprana es fundamental para implementar cambios en los hábitos de los pacientes con el objetivo de prevenir un evento de enfermedad cardiovascular primario.

En los últimos años México ha implementado varias estrategias enfocadas en el sector salud que prometen buenos resultados. A pesar de esto, se han encontrado inconsistencias en los procesos de atención primaria, práctica clínica e instrumentos de vigilancia que limitan la monitorización cardiovascular de la población.

¿Qué es CARDIOSIGHT?

El proyecto de CARDIOSIGHT nace debido a la presente necesidad en nuestro país de crear métodos y herramientas de identificación temprana para los individuos con alto riesgo de sufrir enfermedades cardiovasculares. Con el fin de prevenir eventos cardíacos primarios y ayudar a disminuir la incidencia de nuevos casos, por medio de hábitos de prevención. Este método de detección será diseñado con ayuda de la inteligencia artificial.

Ventajas de la aplicación:

● La población tendrá la facilidad de conocer su nivel de riesgo sin la necesidad de asistir a una unidad médica de salud. Acelerando de esta manera la identificación de los individuos con un riesgo alto antes de que se desarrolle un evento cardiovascular primario.

● Posterior a la identificación, dependiendo del resultado, se le sugerirá al usuario visitar las páginas disponibles del Instituto Mexicano del seguro social que brindan la información sobre las campañas preventivas actuales relacionadas a este tipo de enfermedades, en las cuales encontrarán la información necesaria para educarse sobre la problemática, además de la posibilidad de encontrar su clínica más cercana para realizar su primer chequeo médico.

¡Experimentando con los datos!

Se decidió trabajar con el dataset Cardiovascular Disease encontrado en la página Kaggle. El cual consiste en 70,000 datos recabados de pacientes, contiene 11 características y una variable objetivo, información recabada por medio de resultados médicos, compartida por el paciente o de forma factual.

Figura 1. Relación entre BMI (Indice de masa corporal) y la presencia o no de ECV.

Tras realizar el análisis exploratorio y transformación de nuestros datos se decidió experimentar con el modelo de Random Forest debido a su excelente capacidad de clasificación.

Figura 2. Modelo Random Forest

Tras realizar varias pruebas y tuneo de hiperparámetros se encontró el modelo ideal para nuestra aplicación.

Con un accuracy de 0.73 y una curva ROC de 0.8, se decidió obtener gráficas complementarias del modelo para entender de una forma más profunda su comportamiento probabilístico.

Figura 3. Curva ROC Y AUC

Uno de los retos más grandes en el desarrollo de este proyecto fue encontrar un punto de corte para decidir si una persona tenia una alto o bajo riesgo de sufrir de una enfermedad cardiovascular. Es aquí donde la confianza probabilística entra en juego, y también poner en la balanza cuál situación es mejor: Decirle a los pacientes que tendrán una enfermedad cardiovascular cuando no la tienen, o decirles que no, cuando sí la tienen. En mi caso preferí que mi modelo identificara al mayor numero de personas de sufrir de una enfermedad cardiovascular, con la premisa de que los falsos positivos pueden ser detectados al realizar pruebas clínicas complementarias.

Figura 4. Relación entre probabilidad y punto de corte

Como apoyo para la selección de este punto de corte nos basamos en el modulo de Youden, gráficas de calibración y los valores de predicción obtenidos.

Figura 5. Curva de calibración obtenida

Debido a que se deseaba que la población pudiera hacer uso de este recurso, se decidió implementar una aplicación web usando la plataforma streamlit. En la cual el usuario podría consultar su indicador de riesgo por medio del llenado de sus FRC. En caso de que su resultado fuera “Alto” se le redireccionaría a la pagina oficial del IMSS.

Resultados

Se logró obtener un algoritmo capaz de indicar si un individuo tiene alto riesgo de sufrir una enfermedad cardiovascular o no, con resultados comparables a los mencionados en la bibliografía consultada.

Tras un análisis del poder predictivo de los datos se encontró que tener un grado de hipertensión y ser mayor de 50 años, puede influir a que seas un individuo con alto riesgo. El colesterol y el índice de masa corporal también son características a considerar, ya que, si sus niveles son más altos de lo normal, también pueden influir a un riesgo mayor. Una identificación temprana de estas variables de riesgo es fundamental para poder prevenir un episodio de enfermedad cardiovascular primario.

¿Esto es todo?

No, este proyecto sirve como precedente para saber si la metodología utilizada es útil y qué tipo de recursos son necesarios para realizar una investigación más elaborada enfocada a la población mexicana.

Cómo siguientes pasos, es indispensable trabajar con un dataset enfocado en la población mexicana, con él se podría hacer un análisis más profundo respecto a cómo las variables de alimentación, sociales, económicas y educacionales afectan a las predicciones. Además de que se podría crear un algoritmo de cálculo de factor de riesgo, enfocado a esta población.

Se desea trabajar más con el algoritmo creado, para mejorar su desempeño de clasificación aplicando feature selection y otros algoritmos de machine learning.

Todavía queda mucho por hacer, pero definitivamente esta experimentación le da dirección a los próximos esfuerzos, te invito a que me sigas, para que puedas seguir leyendo sobre este proyecto.

Integrantes

Rebeca Sarai Nuñez Ramirez

Presentación del proyecto: DemoDay

Repositorio

En el siguiente repositorio se encuentra el código usado para desarrollar esta aplicación: https://github.com/SaturdaysAI/Projects/tree/master/Guadalajara/July2020/Cardiosight

¡Más inteligencia artificial!

La misión de Saturdays.ai es hacer la inteligencia artificial más accesible (#ai4all) mediante cursos y programas intensivos donde se realizan proyectos para el bien (#ai4good).

Infórmate de nuestro master sobre inteligencia artifical en https://saturdays.ai/master-ia-online/

Si quieres aprender más inteligencia artificial únete a nuestra comunidad en community.saturdays.ai o visítanos en nuestra web www.saturdays.ai ¡te esperamos!

Detector distancia mínima COVID-19 mediante Inteligencia artificial

by 2020Donostia

Donostia. Primera Edición. 2020

El fatídico 11 de marzo del 2020, la OMS declaró la pandemia mundial por COVID-19. Más de 300 días después, hemos decidido hacer público y accesible para el mundo entero el trabajo que hemos venido desarrollando durante más de 8 semanas.

Prepárense, gobiernos e instituciones sanitarias del planeta, pues lo que van a ver en este artículo establecerá los cimientos de un nuevo sistema de vigilancia que permitirá asegurar el cumplimiento de una de las medidas que más se ha repetido durante estos fatídicos 300 días: la distancia de seguridad interpersonal de metro y medio.

Nuestro incombustible grupo, formado por 3 “locos” ingenieros (alguno de ellos en proceso) ha trabajado día y noche para traer la mejor solución posible a este problema.

El proyecto, que comenzó bajo el nombre de WATCHDOG (perro guardián) por la misión inicial que teníamos en mente (un robot con autonomía de movimientos que vigilase el cumplimiento de la distancia de seguridad y que ladrase cada vez que esta fuera quebrantada) iba a ofrecer, más allá del obvio beneficio de un constante recordatorio a las personas de la necesidad de cumplir con la medida de la distancia interpersonal, una herramienta para el mapeo y creación de “puntos calientes” en los que la distancia se incumpliese más a menudo.

Para todo ello, el equipo ha tratado de crear una convergencia entre los mundos de la electrónica y la Inteligencia Artificial, haciendo uso de los medios más innovadores que tenía a su mano. Con una Raspberry Pi 3, un microcontrolador de bajo nivel equivalente a Arduino Mega, diferentes medios para la comunicación, algoritmos, librerías y redes neuronales convolucionales se ha tratado de alcanzar la solución con la mayor satisfacción posible.

El proyecto

Para el proyecto de Saturdays.AI se ha pensado en desarrollar un proyecto Watchdog (perro guardián) que vigila la distancia mínima recomendada por los protocolos Anti-COVID.

El planteamiento inicial ha sido el de programar un robot capaz de emitir un ladrido cuando la distancia de seguridad (requerido por los protocolos Anti-COVID) fuera quebrantada, enviando los datos adquiridos a un servidor y realizar un mapeo (mapa de calor) en tiempo real.

El objetivo básico del proyecto es converger el mundo OT con el mundo IT, es decir, la convergencia de la electrónica con el de la IA (inteligencia artificial) muy de moda en el mundo IT, utilizando técnicas de Deep Learning, que es una de las ramas del Machine Learning. De hecho, a pesar de que esta primera edición de AI Saturdays Euskadi se haya orientado al Machine Learning en general, hemos decidido profundizar en el Deep Learning por voluntad propia.

Poco a poco se están desarrollando tarjetas electrónicas autónomas que funcionan At The Edge (es decir que la misma tarjeta de control aplica los algoritmos) sin utilizar el Cloud para ello, o sin utilizar una unidad PC más potente para su procesado. Este fenómeno, conocido como Edge Computing, permite aliviar la carga de procesamiento a servidores centrales delegando tareas que puedan ser sencillas pero repetitivas a los nodos externos.

Funcionamiento

Cuando se detectan 2 personas, manda la posición de la detección y la imagen de violación de la distancia a un servidor Web, creado con Flask.

En lo que al mapeo respecta, la idea inicial era realizar un mapeo SLAM (simultaneous localization and mapping) utilizando un sensor LIDAR o una cámara 3D, pero nos hemos encontrado con limitaciones para hacer un Point Cloud que nos permitiera ejecutar el mapeo. Se describe esta limitación en los Trabajos a Futuro.

Objetivo

El objetivo inicial era plasmar todo el código dentro de una tarjeta Raspberry PI 3 (de aquí en adelante RPi3), pero a pesar de existen librerías para controlar los módulos de entradas y salidas (GPIO), el dispositivo no es lo suficientemente potente para poder procesar todo en tiempo real. Para ello existen módulos dedicados y deterministas que facilitan estas tareas.

Para tratar de cumplir con el objetivo aquí propuesto se ha utilizado un microcontrolador STM32F411RET. Se trata de un microcontrolador de gama baja equivalente a un Arduino Mega, pero con un sistema operativo de tiempo real (Real Time Operating System o RTOS), al ser determinista se tiene el control del timing y tareas, pudiendo tener un mayor control para la adquisición de datos y respuesta de los actuadores.

Se decidió utilizar esta tecnología por la gran cantidad de librerías robustas que existen para controlar los periféricos.

Algoritmo YOLOv4

El algoritmo final que se ha usado ha sido por goleada YOLO (para nuestro caso), respecto a otros conocidos como SSD (Single Shot Detection) o la más precisa de todas las tecnologías RESNET.

El reto en este apartado ha sido buscar la tecnología que mejor se adapta al tiempo real y nos basamos en las reglas de oro que dijo uno de los mentores:

1. ¿Qué pasa en el mercado? ¿Cuál es la tendencia del mismo? ¿Qué tipo de arquitectura es más viable con las restricciones presupuestarias y de tiempo que tenéis?

2. Mirad lo que hacen los grandes. ¿Podemos pensar igual a ellos? Es decir, ¿tenemos que plantearnos entrenar redes extremadamente complejas, o tenemos que poner los pies en la tierra y plantear ejemplos más rápidos para construir un Producto Mínimo Viable (MVP)?

3. ¡Adáptate!

En esta fórmula, el resultado de 1+1 en ingeniería sería determinista pero en la vida real el resultado es estocástico, así que depende. ?

Este proyecto está acotado para capacidad computacional de gama media y se ha querido estrujar al máximo desde ese punto de vista. Por ello, el mejor algoritmo que encontramos, el cual estaba puramente escrito en C (siendo un terrible reto el aplicar funciones matemáticas a pelo; aprovechamos para agradecer a Joseph Redmon) es lo más rápido comparado con librerías escritas a mayor alto nivel (TensorFlow, pyTorch).

Como curiosidad, usando la versión para embebidos de SSD se llega a unos 18 Frames por Segundo (FPS) comparado con YOLO, que llega a 24 FPS. Sin haber añadido telecomunicaciones nos dimos cuenta cuál era el camino a seguir, pero se encontraron todo tipo de resoluciones de las distintas tecnologías.

“Cabe destacar que para el equipo, el algoritmo o tecnología más completo y adaptado si se tuviera un poco más de capacidad computacional serían RNN o FAST-RNN, ya que de una tirada no solo tendríamos la posición de los objetos, sino cada pixel de la imagen estaría vinculado a una clase y con esto se podría dotar al proyecto de la capacidad de contextualizarse en el entorno. Y esto nos llevaría a más poder de adaptación, teniendo en particular un efecto positivo para el ámbito del Machine Learning, donde se dispondría de más DATO al que poder darle valor sacado del entorno.”

Si se tiene aún más curiosidad al respecto, os dejamos este link.

Como esto se extendería hasta el infinito, no se van a explicar los detalles del funcionamiento a fondo; se adjunta un link donde se explica detalladamente el algoritmo en su versión v3. La diferencia está en que en la versión v4 aumenta la precisión pero en su versión tiny la velocidad se mantiene constante.

EDA: Y ahora… ¡Metemos los “Datos” de nuestros sensores a la caja negra!

La analogía del “EDA” realizado en nuestro proyecto de Deep Learning tendría que ver, entre otros, con limpieza y preprocesamientos hechos de las imágenes obtenidas. El primer preprocesamiento ejecutado sería el que ofrece la función BLOB de OpenCV que reduce la escala de 8 bits (255 RGB) a escala porcentual unitaria.

Este detalle es muy importante ya que pasa el resultado de cualquier cámara a la que el algoritmo necesita de entrada. ¿Lo malo? Que se vuelen datos de coma flotante y eso requiere más gasto computacional pero de ese problema ya se encargaron sus autores.

El “tuning” de los parámetros en este aspecto que hemos hecho ha sido pasar la imagen de entrada a la escala más pequeña (316 x 316 píxeles).

Habiendo hecho este primer paso, la imagen pasará por múltiples filtros internos cambiando la dimensionalidad de la entrada y readaptando al mejor estilo de Nolan con películas del calibre de Tenet o Inception. ¿El resultado?

El algoritmo YOLOv4 entrega los datos de la imagen en una matriz compuesta de 13x13x (A x ((B+P) + C)), siendo:

  • A: La cantidad de anchor boxes (siendo una anchor box un “espacio en el que se puede detectar la posible presencia de un objeto”).
  • B: Las coordenadas de posición del objeto.
  • P: La probabilidad de confianza de que hay objeto.
  • C: Las clases que deseamos identificar y su respectiva probabilidad.
Dentro del archivo “coco.names” están las clases asociadas a sus respectivos nombres pero de este resultado se filtran “únicamente” los resultados en la que la clase es una persona

? ¿Y por qué no reentrenar la red aplicando transfer learning?

Mucho ojo, ya que nuestro equipo se peleó para mejorar la respuesta de este algoritmo para aumentar y darle más valor a la matriz de salida de la versión tiny.

Los resultados, por desgracia, no fueron los esperados. El mapa de características que se crea en estos modelos se basa en cantidades muy grandes de datos y de mucha variedad en el tema de la visión, donde son necesarias grandes cantidades (10.000 imágenes) para que el procesamiento pueda ser fluido. Y es cierto, si se reentrenara partiendo de transfer learning nos ahorraríamos muchas imágenes de entrada, pero también hay que tener en cuenta las clases de objetos que se quieran reconocer. Mientras más clases de objetos haya el mapa de características aprende mejor a separar cada clase.

Por ello, se han usado los pesos de la versión COCO para el algoritmo YOLO, ya que era la más similar para nuestro caso.

A continuación, se aplica un segundo filtro, usado para aplicar el BBOX de los distintos anchor boxes para ver cuál es el mejor.

Estos pasos anteriores formarían el proceso EDA como tal. Sin embargo, y en comparación con un proceso de ML, el filtro que se aplicaría dependería del grado de confianza que se tenga de la detección de un objeto, mientras que en un proceso de ML la “manipulación” se suele hacer sobre el mismo dato.

Todo esto se ensambla en una función llamada “Impure Detector” que nos va a devolver los datos que más nos interesan en una lista de Python de la siguiente forma:

[Coordenadas de las Personas, Index_Impuros]

RPI3

La Raspberry 3B+ cuenta con el sistema operativo Raspbian y librerías OpenCV (4.1.0.22).

El funcionamiento de manera general es sencillo: Se procesan los datos de la imagen y se reenvían a un servidor Web Flask instalado en un PC.

Podemos ver más detalles sobre el código de la RPi en CLIENT.py:

● Comunicación Serie

Tenemos una comunicación serie con el microcontrolador. Después de unas cuantas pruebas nos hemos dado cuenta de que, a la velocidad máxima con la que puede trabajar la RPi con python es con un BaudRate 115200 Bits/s, lo que limita la capacidad de mejorar el tiempo de espera entre Cliente-Servidor. Anotamos este aspecto como Trabajo futuro.

● MQTT

También se ha usado MQTT para enviar los datos respecto a la “violación” de la distancia de seguridad” a otro servidor. Sin embargo, como se ha mencionado antes, no se ha llegado a hacer un mapa de calor con el área de los “delitos de distancia de seguridad” a tiempo real, pero conseguimos enviar los datos e insertarlos en un archivo remoto, guardándolos en un fichero CSV dentro del servidor.

Un trabajo a futuro al que, por desgracia no pudimos llegar, era el de generar un pequeño script para graficar o plotear esos datos.

El diagrama de bloques obtenido para nuestro proceso.

Las imágenes son bastante problemáticas ya que enviar los paquetes de información tan largos y en la que la que el orden influya es complicado, es necesario indexarlos. Se han probado muchas, pero muchas metodologías distintas y la que mejores resultados ha dado ha sido usando una REST API del servidor.

Servidor FLASK:

En Internet se encuentra de todo excepto lo que realmente se quiere, por lo tanto hemos tenido que desarrollar el sistema de envío de imágenes comprimidas por HTTP.

Para ello se han utilizado las funciones de imágenes por excelencia, recogidas en el paquete Open Source OpenCV utilizando un buffer dinámico, evitando la escritura en el disco. Esto se debe ya que por experiencia se ha visto que, a la larga, si no se cuidan, los servidores “envejecen” o “degeneran”. Esto evita por ejemplo forzar los soportes de memoria flash y controlar los ciclos de lectura/escritura aplicados.

Después de emplear OpenCV, nuestro sistema crea la captura en un buffer, lo comprime y se envía al servidor, quien lo descomprime y escribe a disco, dejándolo preparado para su almacenamiento y/o post procesamiento. Este envío se hace en formato JSON ya que se tenían errores al enviarlos en otros formatos.

? ¿Cómo enviar datos que son variables en el tiempo de forma constante?

Normalmente, para que dos personas y/o máquinas se comuniquen tienen que hablar el mismo idioma. En Machine Learning, además, los datos suelen enviarse en bloques constantes de información y de tamaño reducido. En nuestro caso, los pasos que va a ejecutar nuestro cliente son secuenciales y si se tropieza en algún punto todo se va al traste.

Por tanto, se han creado datos “ficticios” para enviarlos como mínimo para que todas las piezas del proyecto puedan funcionar sincronizadamente y en armonía.

Los “impuros” nos van a marcar el index del objeto al que esté pecando pero en los negativos no se va a fijar. Por tanto, esa es la razón por la que el proyecto consigue funcionar sin que se note este pequeño bug.

Esquema general del funcionamiento del servidor Flask.

Microcontrolador

Se ha elegido este microcontrolador (STM32F411RET) por una opción que un Arduino no ofrecía:

La programación de distintas subtareas para que se ejecuten de manera concurrente además de las interrupciones.

Programar en el STMCubeIde nos da la opción de tener la facilidad de programación de Arduino, así como librerías de entornos más industriales.

A diferencia del Arduino en el que el uso de multitareas metiéndolas en un proceso Round Robin es muy complejo, sumado a la limitación de la cantidad de temporizadores o timers que ofrece Arduino Uno 3, con el STM32F404RE estos problemas para insertarlos en la industria se mitigan.

Por tanto, una vez que el micro haya ejecutado la configuración inicial (tareas, interrupciones, timers…) el programa empezará a ejecutar las tareas aplicando un Round Robin, las cuales se agrupan en el siguiente esquema:

Esquema de las Tareas o Programas Concurrentes existentes.

Dentro de las tareas o programas concurrentes existentes existen tres:

1. ADC

Este subprograma se encarga de leer las entradas digitales y procesarlas en 10–12 bits; aspecto que en una lectura por Arduino solo ofrecerá 8 bits de conversión.

Una vez acabadas una por una en orden secuencial, insertará los datos aplicando sus respectivas conversiones en un vector global int32, siendo el motivo para guardarlos como int y no en float que la cantidad de espacio que ocupan se duplicaría (de 32 a 64 bits, por la coma flotante).

Como se puede apreciar en la imagen del envío del Transmisor-Receptor Asíncrono Universal (UART), se envían 4 datos por cada sensor. El último dato es el que quedaría detrás de la coma flotante para su posterior preprocesamiento sencillo en la RPi.

Ejemplo de esto sería recibir del sensor de distancia un valor de 1004 y transformarlo a 100, 4 en este caso simulando metros de profundidad.

Sensores conectados por UART al microcontrolador

2. ACTUATORS

Dentro de los actuadores podemos encontrar que se conmutarán los estados de las salidas digitales pertenecientes al Buzzer y LED_EXT encargados de dotar al robot de notificar al entorno de manera acústica y visual.

No se ha añadido el actuador del motor porque se cree que separado se entiende mejor a la hora de distribuir el código.

3. MOTOR

Los servomotores trabajan entre 500 y 2500 ticks por lo que nuestra tarea TASK_MOTOR se aprovechará de las interrupciones del timer_4 para cambiar su valor ON/OFF.

Además, se ha añadido un acumulador, de tal manera que si mientras se detecta una violación de la distancia de seguridad y antes de que la función se apague se vuelve a recibir una interrupción por la violación de distancia, aumentará el tiempo de espera 5 segundos más en esa posición. Con esto nos aseguramos de que hay un mayor control de las presencias detectadas.

Interrupciones

Las interrupciones son peticiones síncronas o asíncronas al reloj en la que el procesador va a dejar de lado la tarea que esté realizando para centrarse en la interrupción.

Nosotros hemos definido 4 tipos de interrupciones.

1. IRQ_EXT:

Es la interrupción externa por botón a la que se va a acceder en caso de que haya un error tanto de comunicación o de cualquier otro tipo para resetear la configuración del microcontrolador sin que resetee todo. Reenviará la información y nos avisará enviando un “DONE” por el puerto serial.

2. IRQ_TIM4

Se ha configurado el timer_4 del microcontrolador para que se ejecute cada 1 MHz.

En resumen, para que tardemos 50 Hz que es la velocidad del servomotor tenemos que añadir un registro contador de 0–2000 unidades para que entre en la interrupción cada 50 Hz.

Es decir, que en cada 200 ms recibiremos 20000 ticks. O dicho de otra manera, cada 200 milisegundos nuestro micro interrumpirá la interrupción de ese timer.

3. IRQ_TX:

Esta interrupción únicamente va a encender un LED interno del microcontrolador para saber de manera rápida que todo está funcionando correctamente.

En la figura inferior, además de ver la distribución de los pines se puede ver el pin del LED interno así como el pulsador interno del microcontrolador.

Distribución de los pines del proyecto.

4. IRQ_RX:

A pesar de estar la última en la lista, es la interrupción más importante. Para que la RPi actúe como “cabeza pensante”, es necesaria una interrupción que esté atenta a cualquier señal asíncrona que reciba del microPC y que alerte a la RPi.

Los comandos que se van a enviar desde la RPi son dos:

  • “SEND”
  • “ALRM”

Cuando recibamos SEND el microcontrolador enviará los datos que tenga en ese momento en el vector “sens”.

Si recibe ALRM ejecutará los actuadores y si antes de que se acabe vuelve a recibir una entrada ALRM, aumentará el tiempo del mismo.

Figura que muestra el envío de señales a las tareas.

Conclusiones

Se trata de un proyecto aparentemente simple, pero que detrás de todo existe un ecosistema muy complejo al que se le quería meter mano. Solo hay que ver la arquitectura de la infraestructura que ha quedado:

  • Sensores – Unidad del Microcontrolador (MCU).
  • MCU – RPi.
  • RPi – PC: Uso de protocolo HTTP con peticiones POST al servidor web (REST API montada en Flask).

Aunque el objetivo era aplicar temas de Machine Learning, estos temas requieren de una determinada arquitectura y funciones para comunicaciones, tratamiento de imágenes etc. El tema de SLAM + ML se ha quedado a las puertas pero sí se han dado pasos para poder continuar con la misma.

Y a la larga, el objetivo que se había planteado que era aplicar esta tecnología al mundo real aparte de la IT y darle una aplicación más industrial, creemos que aunque no se haya logrado, se está un paso más cerca con el uso de estas “herramientas caseras”.

Como reflexión obtenido, hemos detectado que si se va a empezar a usar el Cloud Computing, para las próximas generaciones hará falta un cifrado de la información muy densa que se envíe (aunque se sacrifique la latencia), ya que es un tema muy serio al que poca importancia se le está dando actualmente.

Trabajo a futuro

Hemos detectado diferentes tareas como trabajo futuro de cara a este proyecto:

  1. El mapeo del entorno, así como la geolocalización indoor. Hemos realizado pruebas con el sistema GPS que adquirimos, pero este sistema requiere que esté en un espacio abierto para su funcionamiento. Para facilitar esta geolocalización con sistemas alternativas, consideraríamos el uso de geolocalización indoor (mediante AprilTags, Bluetooth de Baja Energía o BLE, etc.).
  2. La mejora del microcontrolador, aspecto que podría ayudar a mejorar en más del doble la velocidad de procesamiento de la RPI, lo que nos podría ayudar a compensar el retardo generado en la comunicación Cliente-Servidor.
  3. La creación de un script de plotting para graficar los datos obtenidos mediante la conexión MQTT.

Integrantes

Presentación del proyecto: DemoDay

Repositorio

En el siguiente repositorio se encuentra el código usado para desarrollar esta aplicación: https://github.com/SaturdaysAI/Projects/tree/master/Donostia/Donostia2020/Impure_Detector-main

¡Más inteligencia artificial!

La misión de Saturdays.ai es hacer la inteligencia artificial más accesible (#ai4all) mediante cursos y programas intensivos donde se realizan proyectos para el bien (#ai4good).

Infórmate de nuestro master sobre inteligencia artifical en https://saturdays.ai/master-ia-online/

Si quieres aprender más inteligencia artificial únete a nuestra comunidad en community.saturdays.ai o visítanos en nuestra web www.saturdays.ai ¡te esperamos!

Anxietweet AI

Anxietweet AI: Detección de estrés en tweets mediante Inteligencia Artificial

by 2020Latam

Detección de estrés en tweets durante la pandemia SARS-CoV-2(COVID-19)

Anxietweet AI

Latam online. Primera Edición 2020

El estrés: una ‘epidemia’ silenciosa que puede afectar a cualquier persona durante la era moderna, ahora es más notoria debido a la mayor crisis sanitaria enfrentada durante este siglo. Los niveles de preocupación, impacto económico y emocional que han tenido que afrontar las personas han sido factores que han impactado no solo la salud física también la mental de millones de personas.

En este trabajo de inteligencia artificial (ciencia de datos), se realiza un esfuerzo para analizar, predecir y determinar, si una persona está estresada con el uso de sus mensajes a través de la red social de Twitter.

Problema general

¿Es posible que una máquina pueda determinar si una persona está estresada solo con la expresión escrita?

Motivación

Social: ayudar a identificar y reconocer el estrés durante la crisis sanitaria para así conocer el estado emocional de las personas sin necesidad de un estudio en persona

Profesional: obtener, extender y aplicar los conocimientos sobre ciencia de datos e inteligencia artificial, en el análisis de lenguaje humano y en reconocimiento de emociones

Metodología

La metodología con la que se trabajó en este proyecto está basada en la metodología tradicional de CRISP-DM [1]. A continuación se muestra el diagrama general de los pasos que se llevaron a cabo en este trabajo.

Diseño del modelo de reconocimiento:

Recolección de datos

Para llevar a cabo el análisis se recolectaron datos de tweets de 3 diferentes ciudades para poder tener muestras variadas y esperar resultados diferentes. Las ciudades fueron elegidas solamente tomando en cuenta que fueran ciudades grandes en diferentes países angloparlantes.

Las ciudades de las que se obtuvieron los datos fueron las siguientes:

  • Brisbane, Australia (2225 tweets)
  • San Francisco, Estados Unidos (5000 tweets)
  • Vancouver, Canadá (1699 tweets)

Cabe mencionar que los datos fueron recolectados el 24 de octubre y los tweets tienen fecha máxima de publicación una semana anterior a la fecha de recolección y mínima del mismo día de la recolección.

Las palabras claves que se utilizaron para la recolección fueron las siguientes:

covid OR COVID OR coronavirus OR corona OR coronavirus OR #coronavirus OR #covid19 OR covid19 OR sarscov2 OR #covid-19 OR #sarscov2 OR sars OR cov2 OR sars OR #quarantine OR pandemic OR #pandemic OR #2019ncov OR 2019ncov OR quarantine OR lockdown OR #lockdown OR social distancing OR #socialdistancing OR #COVID OR #covid”

La estructura de los datos es idéntica para los 3 datasets. Cada dataset está organizado en 3 columnas:

  • user_location: Ubicación aproximada del usuario (si su ubicación está activada).
  • date: Fecha de publicación del tweet.
  • text: Texto del tweet.

Los datos anonimizados se obtuvieron a través de la API de Twitter a través de un script de Python utilizando Tweepy [2].

tweepy

Etiquetado

Para el etiquetado de los datos, fue utilizada una herramienta llamada TensiStrength, la cuál está desarrollada en Java, y ayuda a evaluar el nivel de relajación o ansiedad que se puede encontrar en un texto sencillo. Esta herramienta funciona por medio de diccionarios de emociones en los cuales se asignan valores a las palabras positivas o negativas y a su vez también cuenta con un diccionario de palabras (booster words) que incrementan el valor de la expresión/emoción.

TensiStrength logra catalogar los textos de dos maneras disponibles, binaria o ternaria; la ternaria los clasifica en 1, 0, -1, positivo, neutral y negativo respectivamente. El esquema para la clasificación de emociones utilizado en nuestro modelo, utiliza la clasificación de tipo binaria, que consiste en usar las etiquetas 1 y 0, las cuales corresponden a “estrés” y “no estrés”.

Las clases se encuentran distribuidas con un porcentaje de:
Tweets con estrés = 49.972%
Tweets sin estrés = 50.028%

Exploración de los datos:

Cantidad de tweets con estrés.

Porcentaje de estrés por ciudad

Porcentaje de estrés por ciudad, representa la cantidad de tweets con estrés respecto al total de tweets.

Palabras más usadas en los tweets, excluyendo conectores.

Palabras más usadas en los tweets, excluyendo conectores y palabras relacionadas con Covid.

Distribución de las palabras en los Tweets según su longitud

Pre-procesamiento de los datos:

Después de recolectar los datos, se llevó a cabo un pre-procesamiento con el fin de que los datos se pudieran utilizar para entrenar un modelo clasificador. Este paso es uno de los más importantes y es aquel que comúnmente consume más tiempo en un proyecto de aprendizaje de máquina.

  • Reducción de Ruido: se eliminaron espacios extras, carácteres especiales y ligas a otras páginas.
  • Normalización: los carácteres se transformaron a minúsculas, se eliminaron puntuaciones y se expandieron las contracciones.
  • Eliminación de palabras vacías o Stopwords: se removieron aquellas palabras que no tienen un significado por sí mismas (artículos, pronombres, preposiciones y algunos verbos)
  • Lematización: se llevó a cabo una lematización, la cual consiste en convertir la palabra a su forma base (i.e. mesas a mesa).
  • Tokenización: finalmente los textos se separaron en palabras, también llamados tokens.

Antes del pre-procesamiento, el texto se visualiza de la siguiente manera:

Posterior a la limpieza y previo a la tokenización, el texto se visualiza de la siguiente manera:

Visualización de datos

Fue realizada por medio de nubes de palabras, en general y dividiendo los datos por clase.

Palabras más recurrentes en general:

Palabras más recurrentes dentro de los datos clasificados como SIN estrés

Palabras más recurrentes dentro de los datos clasificados como CON estrés

LDA (Latent Dirichlet Allocation)

Se utilizó un clasificador de modelo generativo LDA (no supervisado), que permite que a partir de una bolsa de palabras, se genere un conjunto de observaciones que puedan ser explicadas por algunas de las partes de los datos que son similares o que tienen cierta concordancia. Este es un modelo de categorías y fue presentado como un modelo de grafos para descubrir categorías por David Blei, Andrew Ng y Michael Jordan en 2002.

En nuestro trabajo se utilizó a partir de de la vectorización de la data tratada y limpia de los tweets obtenidos, una tokenización y generando una vectorización de las palabras.
Obteniendo un clasificador de 2 tópicos, en las cuales sus principales palabras fueron:

Tópico 0: Covid case new health vaccine death year trump plan day

Tópico 1: Covid people trump go new case mask know say need

y utilizando la librería pyLDAvis
se obtuvo el visualizador:

Modelado

Para este proyecto se evaluaron cinco modelos de Machine Learning. Como modelo base se utilizó Naive Bayes y se comparó con:

  • Regresión Logística
  • K-Nearest Neighbors
  • Random Forest
  • Gradient Boosting.

Para la vectorización [4] de los tweets se evaluaron 2 técnicas: Bag of Words y TF-IDF (term frequency — inverse document frequency) y dos estrategias para sus n-gramas: Bigrama y Trigramas [5].

Los resultados se midieron por medio del AUC (Area Bajo la Curva) y se evaluaron con validación cruzada (k = 10). Tanto el preprocesamiento, entrenamiento y evaluación del modelo se llevaron a cabo dentro de un “pipeline” creado dentro de una clase utilizando el lenguaje de programación de Python.

Nivel de precisión para cada modelo implementado con “Bigrams”
Nivel de precisión para cada modelo implementado con “Trigrams”

En las gráficas de AUC previas se muestra que la combinación ganadora es la de: RFt + BoW + Bigramas, ya que es la mejor en discernir los mensajes que tienen alguna relación con estrés de aquellos que no la tienen.

A continuación podemos observar la matriz de confusión del modelo ganador, así como los resultados de sus métricas.

Optimización (‘Tuneo’) del modelo:

El ajuste fue realizado para tres modelos con el fin de mejorar su desempeño.

Logistic Regression
Se genera una búsqueda de grilla utilizando grid search al cual se le definen ciertos valores con los que se ejecutará el modelo para obtener la versión con mejor Accuracy. Para esto se consideró:
1.- Valor C
2.- Penalty del modelo: L1 (Lasso) y L2 (Ridge)

Random Forest Classifier
Se genera una búsqueda de grilla utilizando grid search al cual se le definen ciertos valores con los que se ejecutará el modelo para obtener la versión con mejor Accuracy. Para esto se consideró:
1.- Número de Estimadores: número de árboles utilizados en el bosque. Este valor empezará en 200 e irá de 10 en 10 hasta llegar a 2000.
2.- Max_Features: es el número de atributos a considerar para la mejor división. Se prueba con “auto” que se refiere a que el máximo de atributos será la raíz cuadrada del número de atributos.
3.- Max_depth: esto se refiere a la máxima profundidad del árbol. Para este caso se parte en 10 hasta 110 avanzando de 11.
4.- Min_Samples_split: es el número mínimo de muestras requeridas para la división interna del nodo. Se prueba con 2, 5 y 10.
5.- Min_samples_leaf: el número mínimo de muestras requeridas para ser una hoja de nodo. Se considera 1, 2 y 4 para realizar la búsqueda de grilla.
6.- Bootstrap: Si es Verdadero, usará bottstrap en la construcción de los árboles. Si es falso no se utilizará. Se probará con ambas.

Gradient Boosting Classifier
Se genera una búsqueda de grilla utilizando grid search al cual se le definen ciertos valores con los que se ejecutará el modelo para obtener la versión con mejor Accuracy. Para esto se consideró:
1.- Loss: se usa desviance para evaluar como regresión logística la función de pérdida
2.- Learning:rate: es la medición que mide la contribución de cada árbol.
3.- Max_Features: es el número de atributos a considerar para la mejor división. Se prueba con “sqrt” que se refiere a que el máximo de atributos será la raíz cuadrada del número de atributos, en el caso de “log2” se usa el logaritmo del número de atributos.
4.- Max_depth: esto se refiere a la máxima profundidad del árbol. Para este caso se usa 3, 5 y 8.
5.- Min_Samples_split: es el número mínimo de muestras requeridas para la división interna del nodo. Se prueba con un linspace de 0.1, 0.5 y 12.
6.- Min_samples_leaf: el número mínimo de muestras requeridas para ser una hoja de nodo. Se prueba con un linspace de 0.1, 0.5 y 12.
7.- Numero de Estimadores: número de árboles utilizados en el bosque. Este valor empezará en 200 e irá de 10 en 10 hasta llegar a 2000.

Evaluación:

El modelo generado con mayor eficacia fue el de Random Forest, ya que es capaz de reconocer si un tweet contiene o no estrés con una precisión de 88%, lo cual es una métrica muy buena, ya que la velocidad con la que se puede evaluar un conjunto masivo de tweets con esta exactitud ayuda enormemente en una tarea que un humano tardaría mucho más tiempo, y de esta manera es posible encontrar o tratar posibles casos que requieran asistencia sin necesidad de esperar a que esto lleve a un problema mayor como lo es la depresión.

Análisis de resultados:

Para poder adentrarnos más en por qué el modelo se comporta de la manera que lo hace, hicimos uso de SHAP, una técnica de teoría de juegos utilizada para explicar los modelos. El modelo utilizado fue un Random Forest con 100 estimadores.

En este caso utilizamos un TreeExplainer de la librería shap. Para calcular estos valores se tuvo que usar solamente el 5% de los datos de entrenamiento y 10,000 features, de otro modo, el tiempo de ejecución sobrepasa la hora y media en Google Colab.

Resultados para tweets que NO tienen estrés:

Resultados para tweets que SÍ tienen estrés:

Casos de uso para el modelo generado:

Instituciones públicas, gubernamentales o privadas que estén interesadas en conocer o monitorear el estado anímico de una población, o conjunto de personas por zona geográfica, para evaluar el nivel de estrés.

Personal que labore en el área médica enfocada en la salud mental, para lograr identificar las condiciones sobre la estabilidad emocional de algún sector de la población.

Empresas privadas que puedan ofrecer servicios de consultoría para el bienestar emocional y que ofrezcan análisis o proyección de campañas de salud mental en la sociedad.

Desarrollo de Modelo en un App Web

Para alojar nuestro modelo de Machine Learning usamos el framework Flask. Este es usado por su facilidad de uso, ser muy escalable y además, está desarrollado para Python. Lo cual permite en un lenguaje realizar todo el desarrollo. Hay que tener claro que una aplicación web tiene dos partes fundamentales.

Partes de una App Web:

  1. El Front-end el cual es una página desarrollada con Html y Css. Sin ninguna parte de JavaScript ya que es una app sencilla de utilizar.
  2. El Back-end será desarrollado con Flask, donde permite crear la integración con el Front-end y además correr el modelo ya entrenado.

Desarrollo de la interfaz de usuario

En esta parte fueron utilizadas dos herramientas en línea bastante útiles que son Flask y Heroku.
Flask es un framework para desarrollo web con gran interacción con Python; Heroku es usado como un servidor para el despliegue y disponibilidad pública de la aplicación.

La aplicación se encuentra disponible en:

ANXIE-TWEET Heroku

Integrantes

  • Elías Garcés (Ing. Civil)
  • Daniela Gómez (Ing. Industrial y de Sistemas )
  • Enrique Ramos García(Lic. en Matemáticas )
  • Fernando Vizcarra Salva( Ing. Mecatrónico )
  • Jonathan Chávez(Desarrollador Web)

Presentación del proyecto: DemoDay

Repositorio

En el siguiente repositorio de encuentra el código usado par desarrollar esta aplicación: https://github.com/SaturdaysAI/Projects/tree/master/LATAM_remote/DataExtraction-master

¡Más inteligencia artificial!

La misión de Saturdays.ai es hacer la inteligencia artificial más accesible (#ai4all) mediante cursos y programas intensivos donde se realizan proyectos para el bien (#ai4good).

Infórmate de nuestro master sobre inteligencia artifical en https://saturdays.ai/master-ia-online/

Si quieres aprender más inteligencia artificial únete a nuestra comunidad en community.saturdays.ai o visítanos en nuestra web www.saturdays.ai ¡te esperamos!