Procesamiento del Leguaje Natural (PLN) para el Análisis de Ofertas de Trabajo

by 2022Zaragoza

Zaragoza. Primera Edición. 2022

El mercado laboral que todos conocemos se desarrolla sobre un esquema a modo de dos grandes tablones de anuncios, uno frente al otro: el primero con los que ofrecen puestos de trabajo y el segundo con quienes los demandan. Y en muchas ocasiones es el segundo el que se adapta al primero.

Pero creemos que esto tiene que cambiar. Más que un encuentro en el que la mayor parte de las veces se elige por eliminación, las relaciones laborales deberían de parecerse un poco más a las personales, al menos en sus planteamientos iniciales. En las apps de contactos, hay que aportar muchos datos acerca de quiénes somos y también de lo que buscamos. De allí surgen candidatos y con eso se busca el MATCH por ambas partes.

No es cuestión de enamorarse a primera vista, pero sí creemos que es bueno conocer más en profundidad en qué consisten las ofertas de trabajo. Son datos públicos que nos pueden contar aspectos importantísimos tanto de la empresa, como del territorio donde están asentadas. Los requisitos que piden a sus futuros trabajadores y su análisis pueden ayudar tanto a las personas que buscan empleo, como al sector de la educación o a los gobiernos e instituciones de cara a prever situaciones de déficit o superávit en alguno de ellos. En una economía interdependiente y globalizada como la que vivimos, ofrecer un excelente comportamiento del flujo de la mano de obra puede ayudar a asentar empresas, y ser un buen apoyo para la economía y la toma de decisiones.

En el caso de Aragón, la situación se complica en lugares como Teruel, al aplicarse el factor de la despoblación en muchas zonas. Insistiendo en la misma idea que el objetivo de nuestro trabajo, la consejera de Presidencia de Aragón, Mayte Pérez en una reunión en Teruel comentó hace unos días la importancia de generar “foros y sinergias para adelantarnos a las necesidades de empleo que van a surgir. Debemos analizar el mercado laboral hoy, pero ver también las expectativas de futuro que tiene la provincia para acompañarlas de una oferta formativa cualificada” [1].

Figura 1: Elconfidencial.com 15/12/2021.
Figura 2: La Comarca 27/01/2022.

Las empresas de construcción, tanto de obra pública como civil, ya alertaron en otoño de la carencia de mano de obra para su sector, lo que podría ocasionar problemas.

Figura 3: El Periódico de Aragón 11/09/2021.
Figura 4: Heraldo de Aragón 05/07/2021.

Y no sólo la construcción.

Figura 5: Heraldo de Aragón 10/10/2021.

Se cifra ya en 30.000 millones de euros anuales las pérdidas por la falta de mano de obra en Europa [2].

Frente a estos datos, los del paro. En Aragón hay más de 61.000 personas en desempleo. La mayor parte, más de 42.000, son del sector servicios. Pero en el sector de la construcción hay 3.871 trabajadores en paro, en industria 7.000 y en agricultura y ganadería, 3.624. A todos ellos se suman más de 4.500 personas sin empleo anterior.

¿Por qué hay desempleo en un sector cuando hay más demanda? ¿las personas que están en el paro en ese sector no cumplen los requisitos? ¿no acceden a las ofertas por no estar en la misma población en la que se publican?

Se plantean muchos interrogantes, y muchos más cuando las empresas e instituciones planifican la actividad de aquí a los próximos diez años, para recuperar el parón que ha supuesto el COVID y ya marcan las necesidades de mano de obra que van a tener.

Figura 6: La Voz de Galicia 16/10/2021.

Problema

Nos enfocamos en el siguiente problema: ¿Cómo podríamos facilitar el análisis de las ofertas de empleo en Aragón para brindar a sus ciudadanos conclusiones relevantes?¿Cómo podemos ayudar a las empresas a encontrar mano de obra que se ajuste a sus necesidades?¿Pueden las instituciones planificar oferta y demanda de empleo conociendo mucho más el mercado laboral?

Tanto el problema identificado como el proyecto desarrollado están enmarcados en el ODS 8 (Objetivo de Desarrollo Sostenible) de trabajo decente y crecimiento económico [3], y está motivado por la carencia de herramientas que faciliten a los aragoneses estudiar en términos globales la situación actual de las ofertas de empleo en Aragón.

Objetivo general

Para resolver el problema identificado nos planteamos como objetivo general: Desarrollar una herramienta basada en técnicas de Procesamiento del Lenguaje Natural que facilite analizar las ofertas de empleo disponibles en Aragón a partir de diferentes criterios (sector, provincia, ciudad, oficina del INAEM, fechas, etc.) Su utilidad puede ser de interés para empresas, instituciones, planificación educativa, estudiantes, desempleados, empresas de formación, etc…

Con el propósito de cumplir con el objetivo planteado y llevar a cabo el proyecto de manera organizada, seguimos la metodología CRISP-DM (Cross-Industry Standard Process for Data Mining) [4], orientada a trabajos de Minería de Datos, que en nuestro caso se enfoca específicamente en técnicas básicas de Procesamiento del Lenguaje Natural (PLN) [11]. En la siguiente figura se presentan las diferentes fases que abarca la metodología.

Figura 7: Metodología CRISP-DM (esquema procedente de https://www.iic.uam.es/innovacion/metodologia-crisp-dm-ciencia-de-datos)

Conjunto de datos

Al iniciar el planteamiento de nuestra propuesta, consideramos estudiar el ámbito laboral en Aragón al completo, oferta y demanda. Para la oferta vimos que podíamos contar con el Instituto Aragonés de Empleo, INAEM [5], que de lunes a viernes facilita un PDF con las ofertas de empleo disponibles esa jornada en todo el territorio, distribuídas en 28 sectores productivos.

También planteamos usar Infojobs, pero la información que se facilita allí no se encuentra tan bien clasificada. Además, Infojobs aporta unos tipos de trabajo determinados. No suelen ser empleos de alta formación y sueldos elevados, lo que sesgaría las características del estudio.

Para la demanda pensamos en LinkedIn, que sí ofrece mucha información y buena indexación. Pero no todos los miembros de la comunidad LinkedIn buscan trabajo. Con lo cual quedaba descartado. Lo mismo sucedió con los demandantes de trabajo en Infojobs u otras páginas similares como Milanuncios.com. Suelen ser perfiles con urgencia en trabajar, que daría para otro estudio, quizá de carácter social, pero no en la línea que nosotras planteamos.

Por este motivo, decidimos acudir a la base, y crear un sistema capaz de interpretar la oferta diaria de puestos de trabajo en la comunidad autónoma de Aragón, e intentar sacar de allí el máximo partido al modelo de ficha con los datos básicos que encontramos en cada uno de los empleos que allí se anuncian. Hay también que tener en cuenta que el INAEM gestiona buena parte de los puestos de trabajo que salen al mercado laboral en Aragón, pero no el 100%. Por ello nuestras conclusiones, no podrán ser en ningún caso estrechamente ajustadas a la realidad, sino que se convierten en tendencias, aproximaciones y evoluciones cercanas a la oferta de empleo real.

El conjunto de datos que se obtuvo fue el resultado de analizar, extraer y preprocesar un conjunto de esos documentos PDF disponibles en el portal de INAEM [5], y también incorporando la información que aparece en la propia página web del INAEM, en el rango de fechas del 2021 hasta principios de marzo de 2022. En total 1152 ofertas de trabajo. Se distribuyen por sectores profesionales en Aragón (ver Figura 8). Cada oferta de empleo se divide en dos bloques. Uno más breve y esquemático con el título, provincia, ciudad, código, fecha de publicación y oficina. El segundo bloque es el de la descripción. Dentro de ella se obtiene información sobre las tareas a desempeñar, requisitos solicitados por la empresa, condiciones de trabajo, trámites y plazos, entre otras.

Figura 8: Ejemplo de una oferta de trabajo que encontramos en el documento PDF del INAEM.

Durante el proceso de extracción de la información textual desde los documentos de PDF se utilizó la librería de Python Tika [6]. El texto resultante de la extracción por cada documento PDF fue separado por sectores profesionales y luego por ofertas de empleo. De cada oferta, se extrajeron los textos de mayor interés a analizar (“sector”, “identificador de la oferta”, “fecha de publicación”, “título de la oferta”, “ciudad”, “provincia”, “oficina del INAEM”, “descripción global”, “descripción específica”, “tareas a desempeñar”, “requisitos solicitados por la empresa”, y “condiciones de trabajo”). Para ello, aplicamos expresiones regulares [7], también conocidas como regex por su contracción de las palabras inglesas regular expression, que no es más que una secuencia de caracteres que conforma un patrón de búsqueda sobre los textos. En la siguiente figura se puede ver un ejemplo para encontrar las “fechas de publicación” dentro de los textos de las ofertas.

A primera vista parecen tablas de datos con una pauta similar y un orden concreto. Pero lo cierto es que en la práctica se constata que no es así. Cada oficina tiene sus usos y costumbres, lo que dificulta el tratamiento de los datos. Por ejemplo, unas escriben las poblaciones con mayúsculas, y otras sólo la inicial va en mayúscula. Eso hace que se identifique como dos poblaciones distintas si vemos una oferta en BARBASTRO y otra en Barbastro, también se pueden diferenciar por los acentos (por ejemplo, Sabiñánigo y Sabiñanigo) o porque simplemente están mal escritas (por ejemplo, concinero en vez de cocinero, grú para referirse a grúa, etc.). También hay ofertas de trabajo duplicadas, y en cuanto a las características de la descripción global de la oferta, en algunas oficinas las detallan como “Requisitos” y en otras como “Tareas”,entre otras diferencias. Incluso algunas oficinas no ponen etiquetas que separen los distintos conceptos dentro de la descripción, lo que impide aplicar el modelo.

Ejemplo 1.- Lleva las etiquetas de TAREAS, REQUISITOS, CONDICIONES

Ejemplo 2.- Sin etiquetas ni separación. Únicamente aparece “Funciones” sin mayúscula ni negrita

En la fase de análisis y verificación de la calidad de los datos extraídos, identificamos este conjunto de problemas, que fueron tratados para su posterior explotación desde el dashboard: eliminamos ofertas de trabajo duplicadas (asegurando tener un identificador único por oferta), corrigiendo nombre de ofertas, ciudades, provincias, oficinas de empleo, y descripciones mal escritas a partir de diccionarios. También hemos tenido que unificar los textos que significan lo mismo para diferentes características.

Con el propósito de extraer información complementaria a la obtenida desde los documentos PDF, aplicamos en paralelo la técnica de web scraping al buscador de ofertas de empleo en Aragón de INAEM [5], como es el caso del “nivel profesional”, “requerimientos” y “duración del contrato” de las ofertas de empleo, que sólamente aparecían en la web. Adicionalmente, el web scraping permitió completar valores vacíos que no se consiguieron extraer desde los documentos PDF, tales como las “descripciones generales”, “condiciones de trabajo”, nombres de “ciudades” y “provincias”, al estar tanto en la web como en los documentos PDF. Tal vez el web scraping hubiera sido suficiente para tener una primera versión de los datos relacionados con las ofertas de empleo de INAEM, pero los campos “sector” y “oficina de empleo” de cada una de las ofertas sólo estaban presentes en los documentos PDF, los cuales considerábamos muy importantes para estudiar desde el dashboard. Por todo lo anterior, hay que resaltar que una gran parte del proyecto fue dedicada a la fase de extracción, análisis, limpieza y homogeneización de la información.

Dashboard de ofertas de empleo en Aragón

Con el propósito de facilitar el análisis de la situación actual de las ofertas de empleo en Aragón, desarrollamos un dashboard haciendo uso de la librería Streamlit [8]. Esta librería de python ofrece una plataforma de código abierto que permite crear y compartir fácilmente aplicaciones web personalizadas para ciencias de datos y aprendizaje automático. El código fuente del dashboard y de la extracción y preprocesamiento textual está disponible en nuestro repositorio de GitHub [9].

El dashboard cuenta con 4 apartados principales que vamos a desarrollar a continuación. Aunque hay más de una veintena de sectores, hemos querido fijarnos sobre todo en el turismo, por ser importante en la economía aragonesa y con requisitos y términos más conocidos para la sociedad:

  • 1.- Estudio de ofertas por criterio:

En este apartado conocemos el número de ofertas que hay según los siguientes criterios de búsqueda: sector, oficina y provincia.

Según el criterio seleccionado se genera una gráfica de barras.

Figura 9: Captura de pantalla de estudio de ofertas por criterio

Análisis:

Con el criterio “Sector” analizamos 24 de los 28 sectores que contempla la página web del Servicio nacional de empleo. Hay 4 sectores que el INAEM o bien no contempla, o bien no existen ofertas de trabajo para ellos. Esos 4 sectores son Información y Manifestaciones artísticas, Minería y primeras transformaciones, Pesca y acuicultura y Piel y cuero. Vemos que los tres ámbitos que más ofertas han presentado desde noviembre a aquí son Turismo y Hostelería (en plena temporada de nieve y con las vacaciones de Navidad), Administración y Oficinas y Edificación y Obras Públicas. Las que menos personal han solicitado en este tiempo son Producción, Transformación y Distribución de Energía, Seguros y finanzas y Artesanía. En esta gráfica en este periodo podemos observar la temporalidad, con mucha demanda en Hostelería (una de las temporadas altas del turismo en Aragón) y con una oferta contenida por ejemplo en Agricultura, ya que en invierno disminuyen las labores del campo.

Con el criterio “Oficina” observamos que con mucha diferencia, la de Zaragoza Ranillas es la que más ofertas de empleo gestiona en toda la comunidad. Le sigue la oficina de Huesca Capital. Zaragoza acumula cinco oficinas de empleo, dos de las cuales, Zaragoza Centro y Zaragoza Compromiso de Caspe, se sitúan las siguientes en el ránking de las cinco primeras, que cerraría la oficina de Teruel Capital. Fuera de las tres capitales provinciales, destaca Sabiñánigo en número de ofertas de trabajo. En esa sucursal se une la oferta industrial de la capital del Alto Gállego, al abundante sector hostelero y turístico del Valle de Tena, que se complementa con construcción y ganadería. En el listado hay una oficina que no corresponde con Aragón. Ello es debido a que desde las oficinas de Castellón y Castelldefels (Barcelona) han lanzado a Aragón unas ofertas buscando esquiladores.

Con el criterio “Provincia” observamos la proporción actual de ofertas que se reparten entre los tres territorios provinciales de Aragón.

  • 2.- Estudio de ofertas por fecha: En este apartado cruzamos varios de los datos que encontramos en las ofertas, para lograr conclusiones más específicas o perfiles más ajustados. Se genera una gráfica de temporalidad, que facilita el análisis del número de ofertas de trabajo combinando diversos criterios, tales como año, sector laboral y provincia.
Figura 10: Captura de pantalla de estudio de ofertas por fecha

Análisis:

Si seleccionamos el criterio “AÑO” podemos obtener sólo uno en concreto, como esta gráfica, correspondiente a 2021 para todo Aragón. Es evidente un pico en las ofertas de trabajo a mediados de diciembre, tras el puente, justo antes de las contrataciones de cara a la campaña navideña.

Para el año 2022 en todo Aragón, vemos escasa oferta en los primeros días, que aún son festivos, y un pico destacado al final del mes de enero. Llama la atención la caída en las ofertas llegado mitad del mes de febrero, que luego se recupera con un nuevo pico demanda de trabajadores a final de mes.

Y podemos unir los dos periodos que tenemos actualmente, 2021 y 2022. En esta gráfica, añadimos el criterio “PROVINCIA” seleccionando la de Zaragoza. Encontramos unas conclusiones similares en estos parámetros, con picos a mitad de diciembre y finales de enero, y una caída de ofertas a mitad de febrero, para encontrar una importante subida a final de este mes.

Analizamos ahora el número de ofertas aplicando el criterio “PROVINCIA” en este caso en la de Huesca para el año 2021 y 2022. Es muy llamativo el pico de ofertas a finales de enero, de cara parece a una contratación a más largo plazo. Destaca también el descenso de empleos propuestos a mitad de febrero.

En cuanto al número de ofertas en Teruel para el año 2021 y 2022, es también muy llamativo el pico a final del mes de enero, y también una caída significativa a mitad de mes de febrero:

Y también se puede analizar aplicando los tres criterios, es decir por cada uno de los sectores/años/provincia.

Por ejemplo, estudiamos aquí el sector TURISMO Y HOSTELERÍA y provincia ZARAGOZA para todos los años. Hay una subida a final del mes de enero, quizá preparando el puente festivo de San Valero o ante la previsión de la eliminación de algunas restricciones de hostelería, que se efectuó a principios de febrero.

En esta otra gráfica, hemos seleccionado el sector de la EDIFICACIÓN Y OBRA PÚBLICA, también en la provincia de Zaragoza, con demanda de trabajadores muy desigual en estos días.

  • 3.-Nube de palabras: Generamos una nube de palabras a partir de los textos que contienen los títulos y descripciones globales de las ofertas laborales, las cuales se pueden filtrar por sector profesional. Adicionalmente, se puede ajustar diferentes parámetros de configuración de la nube de palabras, tales como el color del fondo de la imagen, el color de las palabras más frecuentes, el número máximo de palabras a generar, el tamaño máximo del fondo, y el estado aleatorio para que muestre palabras diferentes por cada valor definido. Por otra parte, permite subir una imagen (de tipo “silhouette”) para generar la nube de palabras con la forma de la figura dibujada en la imagen. Nuestra idea de “conocer es amar” aplicada a este proyecto nos ha animado a darle forma de corazón. Es una herramienta muy valiosa, porque más allá del dato, permite identificar otros conceptos no detectables en un primer análisis sobre las ofertas de empleo. Lo explicamos a continuación.
Figura 11: Captura de pantalla de la nube de palabras.

Para realizar el análisis de los datos exploratorios del PLN [11], utilizamos la librería de Python WordCloud [10]. A partir de esta librería pudimos hacer una representación visual de las palabras (también conocido como nube de palabras) que conforman los textos de los títulos y descripciones globales de las ofertas de trabajo, en donde el tamaño es mayor para aquellas palabras que aparecen con más frecuencia. Las gráficas de nube de palabras, nos permitieron visualizar las palabras claves contenidas en los textos para su posterior estudio. Previo a la representación visual y como parte del procesamiento de datos en lenguaje natural, eliminamos del texto un conjunto de palabras vacías (conocidas como stop words), que son palabras sin significado como artículos, pronombres, preposiciones, etc.

Análisis:

Para la primera nube de palabras que analizamos, hemos seleccionado, por ejemplo, los criterios Oferta + Sector TURISMO Y HOSTELERÍA. Es decir, esta nube de palabras es con el encabezamiento de la Oferta.

En las nubes de palabras, aparecen los términos más usados o habituales dentro del texto. Era de esperar encontrar ‘Camarero’, ‘Cocinero’ o ‘Barra’. Pero encontramos otros términos que nos dan pistas de tendencias. Por ejemplo, aparecen varios municipios donde hay especial demanda de Hostelería (Rubielos, Garrapinillos, Montañana, Cariñena), y otros servicios de Hostelería que no son los mayoritarios (Residencia, planchistas, marmitones, ancianos o discapacidad). Ello nos permite analizar, por ejemplo, una tendencia emergente dentro de este sector dando servicio residencial, y varias especializaciones que se necesitan en Aragón, como por ejemplo Barrancos. Observamos el sesgo de género ya que se solicita mucho más los Camareros (muy grande) que las Camareras (muy pequeño), o Cocinero un poco más grande que Cocineras. Es llamativo que las demandas especifican el género.

Si nos vamos a otro criterio, podemos analizar el texto de la Descripción global de la oferta, también en el mismo sector de TURISMO Y HOSTELERÍA. Buena parte de esta nube se la llevan palabras que indican trámites administrativos derivados de la gestión laboral. Pero hay varios términos que nos ofrecen características del sector. Entre las palabras destacadas, por ejemplo se encuentra ‘Experiencia’ y también ‘jornada completa’ que se lee bastante grande, frente a ‘jornada parcial’ que también se encuentra en la nube pero mucho más pequeña. Por contra, aparece con más tamaño ‘contrato temporal’ que ‘contrato indefinido’. Entre los requisitos que se solicitan se encuentra también carnet de conducir o posibilidad de conducción para el trabajo.

Analizamos ahora otro sector muy distinto. Seleccionamos OFERTAS y sector SERVICIOS A LA EMPRESA. En un sector tan genérico, los términos que aparecen nos ofrecen valiosa información sobre los perfiles que se buscan. Entre los que más, Técnico, Riesgos Laborales, Prevención, Teleoperadores, Seguridad o Informático. Una manera muy sencilla de definir perfiles en este sector.

Aportamos un ejemplo más de OFERTA en este caso, el de INDUSTRIA ALIMENTARIA. En un sector tan diverso, las características del mercado aragonés se definen en su vertiente de carnicería. Despiece, Cárnica, Carnicero, Tripería, Cárnicos, Aviar, Animal, Matadero, Carnicería constituyen las mayoría de las palabras de la nube.

  • 4.- Mapa de ofertas: Con esta opción se genera un mapa donde se puede visualizar el número de ofertas por cada provincia, oficina de desempleo en Aragón y población donde se ofrece el puesto de trabajo, con círculos que amplían su radio proporcionalmente al número de empleos.
Figura 12: Captura de pantalla del mapa de ofertas.

MAPA 1.- Con el propósito de obtener automáticamente la latitud y longitud de las provincias, ciudades y oficinas de empleo en Aragón, usamos la librería GeoPy [12]. Por otra parte, la librería de Python pydeck [13] fue utilizada para visualizar los datos en el mapa de una manera interactiva. En la Figura 13, se muestra un ejemplo de visualización del mapa geográfico con el número de ofertas de empleo por cada una de las provincias de Aragón.

Figura 13: Ejemplo de mapa geográfico de ofertas por cada una de las provincias de Aragón.

Análisis:

Con esta primera imagen en mapa, de un simple vistazo nos hacemos una idea de cómo se reparte el volumen de ofertas del INAEM en Aragón entre sus tres provincias. Las proporciones mayores están en Zaragoza y Huesca, y se nota mayor distancia con las de la provincia de Teruel.

MAPA 2.- La siguiente posibilidad que ofrece nuestro modelo refleja las poblaciones donde se ofrecen los puestos de trabajo. Este mapa puede convertirse en una herramienta valiosa para la ordenación del territorio. Observando la evolución a lo largo de días o meses puede dar información, por ejemplo, de las necesidades de vivienda, educación o servicios, o al contrario, advertir del riesgo de despoblación o de que se inicien movimientos migratorios de los habitantes de una zona buscando trabajo en otro lugar.

MAPA 3.- La tercera posibilidad es conocer el volumen de ofertas de empleo de cada oficina del INAEM en Aragón. Podemos observarlo de manera general, incluyendo las de toda la comunidad autónoma como en este gráfico.

O bien acercarnos y descubrir las opciones de las distintas oficinas dentro de una misma ciudad, como ocurre en Zaragoza.

Conclusiones

En este artículo, hemos presentado el proyecto desarrollado en Saturdays.AI-Zaragoza, un primer paso para contribuir con la sociedad, ante la carencia de herramientas que faciliten a los aragoneses estudiar en términos globales la situación actual de las ofertas de empleo en su comunidad.

Tal y como hemos explicado, entre los problemas que nos hemos encontrado se encuentra la distinta indexación según cada oficina del INAEM. Si todas ellas rellenaran una misma plantilla online exactamente con los mismos criterios el tratamiento de los datos sería mucho más sencillo e inmediato. ¿De qué sirven los datos si no están semi-estructurados? ¿si no hay un patrón que facilite la extracción de la información? Si además nuestro enfoque se implementara y recopilara con esos datos día a día, sería una valiosa arma para la gestión del empleo en la comunidad de Aragón, permitiendo conocer puntualmente la evolución de los distintos sectores, de los lugares donde se ofrece trabajo, de los requisitos que solicitan las empresas para sus futuros empleados. Mucho de nuestro trabajo se ha invertido en solucionar detalles que no tendrían que estar allí. De no habernos encontrado esas diferencias en las formas de clasificación de datos, nuestro estudio nos permitiría hablar de otros análisis más profundos y precisos e incluso modelos de aprendizaje automático avanzados.

Simplemente continuar añadiendo los datos a diario a este trabajo, permitiría un estudio muy detallado de cómo se comporta el mercado laboral en un año, analizando así la evolución de sectores tan temporales como pueden ser el agrícola o el turismo, ambos con un peso muy relevante en la economía aragonesa e incluso pudiendo llegar a predecir las necesidades futuras del mercado laboral aragonés.

Además de todo ello, algunas de las principales aportaciones que realiza este trabajo son las siguientes:

  • Es una herramienta que aumenta el conocimiento sobre las ofertas de empleo en Aragón.
  • Consigue organizar los datos del INAEM a pesar de las dificultades.
  • Crea un sistema de interpretación del lenguaje natural del que obtenemos los datos deseados.
  • Generación automática de gráficas de barras según los datos por sectores, oficina y provincia.
  • Generación automática de gráficas según criterios independientes o combinados con año, sector y provincia.
  • Generación automática de nubes de palabras, que además de analizar la oferta, nos ofrece nuevas ideas o criterios, conceptos emergentes que son muy interesantes para analizar las ofertas.
  • Generación automática de mapas que permiten tener una visión de las ofertas directamente sobre el territorio, lo que ofrece una valiosa herramienta de comprensión sobre la evolución del empleo y su impacto en las distintas comarcas.

Para qué se puede aplicar:

  • Marcar líneas de formación para empresas o gobiernos.
  • Dar indicación a los jóvenes que buscan un horizonte laboral para tomar decisiones en cuanto a su formación de cara a futuro.
  • Dar información a las empresas de los requisitos que hay en el mercado para un puesto concreto, y conocer las condiciones medias de contratación.
  • Conocer el tiempo qué tarda en cubrirse una plaza en un sector.
  • Saber los lugares de Aragón dónde se demanda el empleo y dónde no.
  • Demanda de empleo según la época del año. Evolución de la temporalidad.
  • Planificación de la ordenación del territorio y de la sociedad según las necesidades de la población que pueda desplazarse buscando el empleo.

Como líneas de trabajo a seguir partiendo de lo que ya tenemos, se puede continuar con el desarrollo y mejora del dashboard.

Y de cara al futuro

  • Se podría desarrollar para que el programa se enriqueciera con más información que incorporara a diario de manera automática.
  • Se podría convertir en una aplicación web real y consultable por autoridades relacionadas con la gestión económica y social, empresas, trabajadores, sindicatos, estudiantes, etc.
  • Incorporar otras plataformas de empleo, puesto que la del INAEM no representa toda la oferta existente. Requeriría de un complejo estudio para encontrar en esas otras plataformas el modo de homogeneizar la información, es decir, unificar en un única característica aquellos textos que significan lo mismo pero se categorizan bajo etiquetas diferentes. Esto incluso podría pasar dentro de una misma plataforma, como tenemos en el INAEM.

Agradecimientos

Agradecemos la oportunidad que nos ha brindado Saturdays.AI para aprender los fundamentos básicos de Inteligencia Artificial, a pesar de no ser expertos en el ámbito. Y sobre todo a María del Carmen Rodríguez Hernández, por toda la ayuda que nos ha prestado y todas las horas de apoyo, sin las cuales, esto no sería una realidad.

Referencias

[1] Periódico La Comarca “Preocupación por la falta de mano de obra en Teruel” 27/01/2022 https://www.lacomarca.net/preocupacion-falta-mano-obra-teruel/ (Consultado el 25 de febrero de 2022)

[2] C. Porteiro, Diario La Voz de Galicia “Europa pierde 30.000 millones de euros anuales por la falta de mano de obra” 16/10/2021 https://www.lavozdegalicia.es/noticia/economia/2021/10/16/europa-pierde-30000-millones-euros-anuales-falta-mano-obra/0003_202110G16P28991.htm (Consultado el 3 de marzo de 2022)

[3] Objetivos de Desarrollo Sostenible. PNUD. https://www.undp.org/es/sustainable-development-goals (Consultado el 24 Febrero, 2022)

[4] P. Haya. La metodología CRIP-DM en ciencia de datos. https://www.iic.uam.es/innovacion/metodologia-crisp-dm-ciencia-de-datos (Consultado el 24 Febrero, 2022)

[5] INAEM: Ofertas de Empleo en Aragón. https://inaem.aragon.es/ofertas-de-empleo (Consultado el 2 de marzo 2022)

[6] C. Mattmann. Librería de Python Tika. https://github.com/chrismattmann/tika-python (Consultado el 24 Febrero 2022)

[7] López, F., & Romero, V. (2014). Dominar las expresiones regulares de Python. Publicación de paquetes. págs. 110. ISBN 978–1–78328–315–6.

[8] A. Treuille, A. Kelly y T. Teixeira. Streamlit. https://streamlit.io (Consultado el 25 Febrero 2022)

[9] M. Morao y E. P. Nogarol. Dashboard de Ofertas de Empleo en Aragón.
https://github.com/marianamorao/eq_1_demanda_empleo (Consultado el 4 Marzo, 2022)

[10] A. Mueller y et al. Librería de Python WordCloud. https://github.com/amueller/word_cloud (Consultado el 25 Febrero, 2022)

[11] H. Suresh. WordClouds: Basics of NLP. Medium. 03/06/2020 https://medium.com/@harinisureshla/wordclouds-basics-of-nlp-5b60be226414 (Consultado el 4 Marzo, 2022)

[12] K. Esmukov y et al. Librería de Python GeoPy. https://geopy.readthedocs.io (Consultado el 25 Febrero, 2022)

[13] X. Chen y et al. Librería de Python Pydeck. https://github.com/visgl/deck.gl/tree/master/bindings/pydeck (Consultado el 25 Febrero, 2022)

Integrantes

  • Mariana Morao Santos
  • Esther P. Nogarol

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/Zaragoza/eq_1_demanda_empleo-main/eq_1_demanda_empleo-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!

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!

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!

PANGEA: IA conversacional para viajeros

by 2021La Paz

La Paz. Deep Learning. 2021

Existen diversos servicios para viajeros, desde páginas de hoteles hasta ofertas turísticas a unos cuantos clics de distancia, no obstante, el ser humano ha conseguido su información por siglos y siglos a través de preguntas y bases de conocimiento, por lo que le es más natural hacer consultas de esa forma, así surge Pangea, como un servicio web de Inteligencia Artificial conversacional con el que el viajero puede interactuar y conseguir las respuestas a sus más inquietantes preguntas.

Un viajero prudente nunca se lanza a viajar si no tiene la información más relevante de su destino, en su cabeza se encuentran preguntas que en primera instancia cuestionan su seguridad, por lo que investiga al respecto y logra resolver sus dudas en probablemente muchos minutos, de igual forma si ya se aventuró a viajar y necesita conocer alguna costumbre, plato típico, música o lugares para visitar, son tantas las preguntas y mucho el tiempo invertido en responderlas, de esa forma los viajeros pierden tan importante recurso.

Por lo que al usar textos como datos a analizar en la tarea de respuesta a preguntas se requiere el uso de Natural Language Processing (NLP) o en español conocido como el procesamiento del lenguaje natural, entiéndase como la rama de la Inteligencia artificial (IA) que entrena a una computadora para comprender, procesar y generar lenguaje (conversacional).


Descripción del problema

Concretamente el problema es el tedioso y tardío acceso a respuestas inmediatas sobre dudas y consultas acerca de un destino turístico, como ser: comida, hospedaje, actividades turísticas, transporte, centros de salud, cultura, música, conflictos políticos, entre otros.


Objetivo

Desarrollar mediante Inteligencia Artificial un servicio web conversacional de pregunta-respuesta para viajeros aplicando NLP mediante la aplicación de un modelo de deep learning.


Técnicas implementadas

Se presentan las técnicas complementarias a la resolución del problema, ya que todo modelo de Deep Learning requiere ser alimentado por datos.


Búsqueda de datos

La Inteligencia Artificial conversacional Pangea se centra en responder preguntas y no sería posible sin cantidades ingentes de información con las cuales interactuar y usarlas como una fuente de conocimiento (contexto), en ese sentido, se realizó la búsqueda de páginas web que contengan las respuestas más coincidentes de acuerdo a la pregunta del usuario viajero; hacerlo de forma manual representaría demasiado trabajo, por lo cual, se decidió usar la biblioteca de Python, Google Search, el cual emplea al motor de búsqueda Google como fuente de información para brindar las URLs de los sitios webs requeridos.


Captura de datos

Una vez obtenidas las URLs de los sitios webs que contienen la información requerida, se empleó la técnica del Web Scraping para obtener el contenido literal de dichos sitios, es decir, los distintos párrafos y textos presentes en el sitio. Web Scraping es una técnica cuyo objetivo es recolectar información de la web a través de código. En este caso se usó la biblioteca Beautiful Soup disponible en pypi.


Selección y evaluación del modelo

Modelo Bert: es un codificador bidireccional de transformers, que aprende a interpretar el lenguaje.

Cuando al modelo Bert se le añade capas adicionales y es entrenado con un propósito o tarea especializada, se obtiene un modelo Bert que resuelve una tarea en específico.

En el proyecto se aplicó ya modelos ajustados para la tarea de pregunta y respuestas, que fueron previamente ajustados mediante el dataset de los conjuntos de datos de respuesta a preguntas Stanford(SQuAD).

Ambos modelos fueron obtenidos y reutilizados de la biblioteca hugging Face Transformers. Dichos modelos reciben una pregunta y un contexto para procesarlo y analizarlo con el fin de devolver las respuestas que mejor se ajusten a la pregunta.

La elección del mejor modelo fue dado en base a los resultados:

  • Bert en inglés:bert-large-uncased-whole-word-masking-finetuned-squad
  • Bert en español (Beto): distill-bert-base-spanish-wwm-cased-Finetuned-spa-squad2-es
Tabla 1. Evaluación de Modelos

Se seleccionó y grafico un caso en específico, para demostrar como se comportan ambos modelos a una misma pregunta y cuales son las respuestas textuales que dan cada uno en su respectivo lenguaje, figura 1.

Figura 1. Gráfico de barras — Representación de respuestas Modelo Bert y Beto a la misma pregunta.


Flujo de Trabajo del Sistema

El sistema consta de distintos procedimientos para resolver una determinada pregunta, por lo que el usuario viajero debe partir lanzando una pregunta, posteriormente el sistema realiza una búsqueda con Google Search en relación a tal pregunta y devuelve unas cuantas URLs (máximo 5) con las que el web scraper realiza la tarea de extraer todo el texto (párrafos) del sitio hospedado en la URL para pasarle como contexto al modelo, el modelo utiliza el contexto, la pregunta y lanza una respuesta, se captura la respuesta y la url,ambas son representadas en formato de mensaje de chat, figura 2.

Figura 2 . Elaboración propia


Análisis de resultados (Bert vs Beto)

Pangea devuelve las respuestas y la URLs de donde han sido obtenidas tales respuestas, según la cantidad de pruebas se puede observar que el uso de Beto se adecua más según el porcentaje de aciertos. Y en las gráficas se visualiza como el modelo Beto da respuestas con mayor precisión a la misma pregunta realizada en ambos idiomas de acuerdo al modelo.


Conclusión y recomendaciones

Las conclusiones obtenidas tras el desarrollo y resolución del objetivo general son:

  • Se obtuvo un 64.7 % de respuestas correctas de un total de 17 preguntas por parte del modelo BERT en español en relación al 30% del modelo BERT en inglés, en ese sentido, el modelo BERT pre-entrenado con mayor precisión en sus respuestas es el español, ya que las preguntas tuvieron a Bolivia como contexto principal y es razonable puesto que no muchos sitios en inglés tienen información actualizada y específica de Bolivia.
  • La técnica del Web Scraping aportó correctamente el contenido web necesario para que el modelo BERT pudiese responder las preguntas adecuadamente.
  • Dado que el servicio (Pangea) se desplegó por un momento se logró registrar el uso de 2.5 GB de memoria RAM con una demora de aproximadamente 30 segundos mientras el modelo responde a la pregunta.
  • El Servicio Web que se ofreció por unos instantes logró capturar la curiosidad y asombro de los usuarios por su diseño minimalista e interesante forma de interactuar.

Por otra parte las recomendaciones al respecto son:

  • El modelo BERT empleado fue afinado (fine-tuning ) con el dataset SQUAD el cual tiene un formato pregunta-respuesta de dominio parcialmente general, por lo que se tiene mayores expectativas con un afinado específico para el área de turismo.
  • La información recolectada por el servicio proviene de Google que es un motor de búsqueda, el sistema funcionaría mucho mejor y tendría una mayor calidad en sus respuestas si el motor de búsqueda y los datos que en él residen fueran recolectados cautelosa y selectivamente.
  • Como Pangea se centra en el servicio para viajeros y turistas, es recomendable incrementar distintos modelos BERT en varios lenguajes.


Autores del proyecto

  • Ana Paola Céspedes Sejas
  • Mauricio Serginho Matias Conde

«Equipo ElementAxiom»


Referencias

Google search, https://pypi.org/project/googlesearch-python/

Beautifulsoup, https://pypi.org/project/beautifulsoup4/

Modelo Bert en español, https://huggingface.co/mrm8488/distill-bert-base-spanish-wwm-cased-finetuned-spa-squad2-es

Modelo Bert en inglés, https://huggingface.co/bert-large-uncased-whole-word-masking-finetuned-squadSaturdays.AI

Saturdays.AIFollow


WRITTEN BY

Ana Paola Cespedes Sejas

Saturdays.AI

Presentación del proyecto: DemoDay

¡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!

Saturdays.AI

Saturdays.AI is an impact-focused organization on a mission to empower diverse individuals to learn Artificial Intelligence in a collaborative and project-based way, beyond the conventional path of traditional education.

facturas

Detección de datos de facturas manuales

by with No Comment 2021La Paz

La Paz. Deep Learning. 2021

Introducción

La declaración de facturas es uno de los deberes que tienen un porcentaje de la población boliviana, ya sean contribuyentes dependientes o independientes. Si bien es posible importar los datos de una factura electrónica por medio del escaneo de un código QR. El realizar dicha transcripción de una factura manual llega a ser más complicado, lento y moroso, a la hora de transcribir el número de NIT, el número de autorización y el número de factura de cada una. Especialmente para personas que no son muy familiarizadas con sistemas computacionales, siendo este una parte importante de la población adulta en Bolivia.

facturas

Figura 1. Imágenes de una Factura Manual

facturas

Figura 2. Imágenes de una Factura Manual y una Factura Digital

Es por ello, que el presente proyecto es un prototipo de un sistema de reconocimiento óptico de caracteres que identifique los valores previamente mencionados. Y por consiguiente permita al usuario exportar dicha información en un archivo CSV o XLSX, para su fácil importación en la plataforma de declaración de facturas SIAT (Sistema Integrado de Administración Tributaria).

Figura 3. Pantalla principal de la plataforma SIAT, para la importación de datos de facturación.

Figura 4. Botón de importación de archivos xls o xlsx.

Descripción del problema

El problema identificado es la cantidad de tiempo que se invierte a la hora de transcribir la información de cada una de las facturas manuales; tanto a personas con tiempo limitado por múltiples actividades personales o profesionales, como a personas con poca habilidad computacional.

Objetivo

El proyecto busca facilitar la detección de los datos más largos de facturas manuales, siendo estos el número de NIT de la empresa, el número de autorización, y el número de factura. Para su posterior exportación en formatos CSV o XLSX para su posterior importación en la página de Mis Facturas del SIAT (Sistema Integrado de Administración Tributaria).

Selección del modelo

CRAFT

Se utiliza CRAFT (Character-Region Awareness For Text detection) [1], esto debido a que nos permite localizar las regiones de caracteres individuales y vincular los caracteres detectados a una instancia de texto. Se podría haber utilizado Tesseract el cual es un módulo de ORC pero falla en textos con curvas y formas irregulares en ciertos tipos de fuentes.

CRAFT

Figura 5. Ilustración esquemática de la Arquitectura del modelo CRAFT

La arquitectura se basa en la red neuronal convolucional CNN, VGG-16 [2], es esencialmente para la extracción de características que se utiliza para codificar la entrada de la red en una determinada representación de características y el segmento de decodificación de la red CRAFT.

Figura 6. Modelo de la CNN VGG-16.

Técnicas implementadas

Las técnicas implementadas por el modelo CRAFT son las básicas para la detección de caracteres, como ser: cortes, rotaciones y/o también variaciones de colores.

Figura 7. Procedimiento de división de caracteres para lograr anotaciones a nivel de caracteres a partir de anotaciones a nivel de palabra: 1) Se recorta la imagen a nivel de palabra; 2) Se predice la puntuación de la región; 3) Se aplica el algoritmo watershed; 4) Se obtienen los cuadros delimitadores de caracteres; 5) Se desempaquetan los cuadros delimitadores de caracteres.

Evaluación de modelos

Al ser un modelo pre-entrenado de KERAS-OCR, con el modelo de CRAFT [3]. Podemos ver su eficacia con respecto a otros modelos similares para la detección de caracteres:

.

Figura 8. Comparativa de diferentes modelos, donde se utilizaron los dataset ICDAR y MSRA-TD500. Dónde: P es la Precisión, R es Recall, H es la H-mean y FPS los cuadros analizados por segundo [4].

Análisis de resultados

Una vez importada la imagen de la factura, se obtienen todos los valores que son detectados en la misma. Por lo que cortamos la imagen en dos, para tener solamente la parte derecha; donde se encuentran los datos que intentamos recopilar. Ya que como se ve en la Figura 9, la cantidad de datos es excesiva.

Figura 9. Detección de caracteres de una factura manual.

Una vez tenemos todos los datos detectados y convertidos en tipo STRING, en un dataframe creado con Pandas. Comparamos cada una de las columnas, buscando el texto deseado. Por tal motivo, comparamos la cantidad de caracteres que tiene el NIT del proveedor (de 8 a 10 caracteres), el Número de autorización (14 a 16 caracteres) y el Número de factura (4 a 6 caracteres). Por lo que, hallamos tras la búsqueda de columnas el valor deseado.

Figura 10. Detección de valores deseados, transformación a un dataframe con Pandas y conversión de los datos a STRING para su posterior comparación.

Finalmente, guardamos estos valores en un dataframe creado, con la misma distribución que pide el sistema de mis facturas de la plataforma SIAT. Y exportamos en CSV, o XLSX. Y como se ve en la figura 11.

Figura 11. Exportación de datos generados a los archivos CSV y XLSX.

Conclusión

Por medio de este prototipo, se puede identificar los valores más relevantes y complicados de transcribir para la mayoría de las personas que realizan su declaración de facturas. Además, que el importarlos desde una foto o imagen escaneada reduce drásticamente el tiempo de transcripción de datos. Lo que sería de mucha ayuda para personas no muy familiarizadas con las computadoras, como un buen porcentaje de adultos mayores en el país.

Si bien, muchos datos son identificados. El mayor problema reside en la calidad de la imagen tomada, ya que si esta no tiene una buena nitidez o tamaño llega a tener problemas con la identificación de algunos caracteres. Y que para trabajos futuros se podría intentar solventar con un entrenamiento más personalizado y no basándose en uno pre entrenado.

A su vez, el realizar una GUI (Interfaz gráfica de usuario), ayudaría bastante en poder llevar a este prototipo a ser más amigable con el usuario. Y por ende, facilita la importación de imágenes o facturas escaneadas para su reconocimiento de caracteres y exportación final.

Código

https://github.com/albmarale/SaturdaysAIDeepLearning

Bibliografía

[1] “PyTorch: Scene Text Detection and Recognition by CRAFT and a Four-Stage Network | by Nikita Saxena | Towards Data Science.” https://towardsdatascience.com/pytorch-scene-text-detection-and-recognition-by-craft-and-a-four-stage-network-ec814d39db05 (accessed Jul. 13, 2021).

[2] M. ul Hassan, “VGG16-Convolutional Network for Classification and Detection,” en l{\’\i}nea].[consulta 10 abril 2019]. Dispon. en https//neurohive. io/en/popular-networks/vgg16, 2018.

[3] F. Morales, “keras-ocr — keras_ocr documentation,” 2021, Accessed: 13-Jul-2021. [Online]. Available: https://keras-ocr.readthedocs.io/en/latest/.

[4] Y. Baek, B. Lee, D. Han, S. Yun, and H. Lee, “Character region awareness for text detection,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, 2019, pp. 9365–9374.

Este proyecto fue elaborado por:

  • Albert Martínez Alegría
  • Alvaro Alanoca Huaycho
  • Belinda Alcón Sullcani
  • Rodrigo Aliaga

Para el programa Saturdays.AI La Paz.

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/Lapaz/2021.DL/Deteccion-facturas-manuales-main

¡Más inteligencia artificial!

La misión de Saturdays.ai es hacer la inteligencia artificial más accesible (#ai4all) a la vez que se realizan proyectos de impacto social (#ai4good).

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

Si quieres aprender más sobre este proyecto (y otros) únete a nuestra comunidad en o aprende a crear los tuyos en nuestro programa AI Saturdays.

WRITTEN BY

Albert Mario Martínez Alegría

res.txt machine learning

res.txt: Resumen y traducción de texto con Machine Learning

by with No Comment 2021La Paz
res.txt machine learning

La Paz. 2021

Introducción

El resumen de texto es el proceso de extraer la información más importante de un texto fuente para producir una versión abreviada para un usuario. Los seres humanos llevamos a cabo la tarea de resumen, ya que tenemos la capacidad de comprender el significado de un documento y extraer características destacadas para resumir los documentos utilizando nuestras propias palabras. Sin embargo, los métodos automáticos para el resumen de texto son cruciales en el mundo actual, donde hay falta de trabajadores y de tiempo para interpretar los datos.

Figura 1:  Cantidad de datos generados de manera anual

Problema

internet languages

Figura 2: Idiomas predominantes en internet

Hoy en día, con el constante crecimiento de la información el estar actualizados en cualquier tema es una necesidad. Pero las fuentes de información usualmente son extensas y poseen una gran cantidad de texto pero lo más importante es que la información está en inglés.

Objetivo

Desarrollar una aplicación que pueda ayudar a la comprensión de un documento de texto en inglés y acorte el tiempo de comprensión de un texto largo.

Solución propuesta

Hacer la aplicación en base a métodos de DeepLearning enfocados a attention mechanism. Estas técnicas imitan la atención cognitiva. Esto provoca la mejora en las partes más importantes de los datos de entrada y desvanece el resto.

Dataset

CNN Daily Mail es un conjunto de datos de más de 300 mil artículos en inglés escritos por periodistas en CNN y en Daily Mail. El tamaño del conjunto de datos es de 1.27 GiB en la versión actual, esta admite el resumen extractivo y abstracto, aunque la versión original se creó para la lectura y comprensión automática y la respuesta a preguntas abstractas. Los datos se pueden usar para entrenar un modelo para el resumen abstracto y extractivo

Modelo de DL

Figura 3: Esquema BART

BART es una arquitectura que se basa tanto en BERT y GPT, BART utiliza la arquitectura de transformer seq2seq estándar pero, después de GPT, que modificamos las funciones de activación de ReLU a GeLU. La arquitectura está estrechamente relacionada con BERT, con las siguientes diferencias:

  1. Cada capa del decodificador, además, realiza una atención cruzada sobre la capa oculta final del codificador (como en el modelo de secuencia a secuencia del transformador)
  2. BERT utiliza una feed-forward network antes de la predicción de palabras, lo que BART no hace.

Entonces en pocas palabras usa la comprensión de texto o input de BERT y GPT para el output o la generación de palabras.

Para trabajar con este modelo se lo hizo mediante el modelo base que nos provee HuggingFace.

HuggingFace es una plataforma Open Source que se enfoca en NLP, nos ayuda a construir, entrenar e implementar modelos que son estado del arte. En este caso nos ayudó a construir el modelo y con el dataset.

Entrenamiento del modelo

El proyecto fue realizado en base a los modelos provistos por la página de Hugging Face, la cual posee una gran colección tanto de modelos como de datasets para tareas de NLP (Procesamiento de Lenguaje Natural). De todas las opciones se seleccionó el modelo de sumarización abstractiva BART.

El código hace uso de las librerías “datasets” y “transformers” de HuggingFace, además de nltk para realizar la evaluación.

# Imported libraries
from datasets import load_dataset, load_metric
from transformers import AutoTokenizer
from transformers import AutoModelForSeq2SeqLM, 
DataCollatorForSeq2Seq, Seq2SeqTrainingArguments, Seq2SeqTrainer
import nltk
import numpy as np
from transformers import pipeline

Para realizar el fine tuning se hizo uso del dataset “cnn_dailymail”, para la evaluación se utilizó la métrica “rouge”, y el modelo base que se usó fue “facebook/bart-base”.

raw_datasets = load_dataset(“cnn_dailymail”, “3.0.0”)
metric = load_metric(“rouge”)
model_checkpoint = “facebook/bart-base”

Se cargaron un tokenizer y un modelo haciendo referencia al modelo base seleccionado.

tokenizer = AutoTokenizer.from_pretrained(model_checkpoint)model = AutoModelForSeq2SeqLM.from_pretrained(model_checkpoint)

Del dataset “cnn_dailymail” se extrajeron los elementos que se encuentran bajo las etiquetas de “article” y “highlights” como datos de entrada y salida respectivamente.

max_input_length = 512
max_target_length = 128def preprocess_function(examples):
 inputs = [doc for doc in examples[“article”]] model_inputs = tokenizer(inputs, max_length=max_input_length, truncation=True)
# Setup the tokenizer for targets
 with tokenizer.as_target_tokenizer():
 labels = tokenizer(examples[“highlights”], max_length=max_target_length, 
 truncation=True)model_inputs[“labels”] = labels[“input_ids”] return model_inputstokenized_datasets = raw_datasets.map(preprocess_function, batched=True)

Antes de entrenar el modelo se realiza la configuración de hiperparámetros.

batch_size = 4
args = Seq2SeqTrainingArguments(
 “BART_Finetuned_CNN_dailymail”,
 evaluation_strategy = “epoch”,
 learning_rate=2e-5,
 per_device_train_batch_size=batch_size,
 per_device_eval_batch_size=batch_size,
 gradient_accumulation_steps=2,
 weight_decay=0.01,
 save_total_limit=2,
 num_train_epochs=1,
 predict_with_generate=True,
 fp16=True,
)

Se crea una función para realizar el cómputo de métricas haciendo uso de rouge score.

def compute_metrics(eval_pred):
 predictions, labels = eval_pred
 decoded_preds = tokenizer.batch_decode(predictions, skip_special_tokens=True)
 # Replace -100 in the labels as we can’t decode them.
 labels = np.where(labels != -100, labels, tokenizer.pad_token_id)
 decoded_labels = tokenizer.batch_decode(labels, skip_special_tokens=True)

# Rouge expects a newline after each sentence
decoded_preds = [“\n”.join(nltk.sent_tokenize(pred.strip())) for pred in decoded_preds]decoded_labels = [“\n”.join(nltk.sent_tokenize(label.strip())) for label in decoded_labels]

result = metric.compute(predictions=decoded_preds, references=decoded_labels, use_stemmer=True)
# Extract a few results
result = {key: value.mid.fmeasure * 100 for key, value in result.items()}

# Add mean generated length
prediction_lens = [np.count_nonzero(pred != tokenizer.pad_token_id) for pred in predictions]result[“gen_len”] = np.mean(prediction_lens)

return {k: round(v, 4) for k, v in result.items()}

Una vez inicializado el modelo, definidos los hiperparámetros, datasets, tokenizer y métricas creamos un Trainer.

trainer = Seq2SeqTrainer(
 model,
 args,
 train_dataset=tokenized_datasets[“train”],
 eval_dataset=tokenized_datasets[“validation”],
 data_collator=data_collator,
 tokenizer=tokenizer,
 compute_metrics=compute_metrics
)

Descargamos punkt tokenizer que nos permite transformar un texto por oraciones.

nltk.download(‘punkt’)

Finalmente realizamos el entrenamiento y la evaluación

trainer.train()trainer.evaluate()

Resultados

Figura 4: Pérdida a lo largo del entrenamiento

Una vez finalizada la fase de entrenamiento podemos observar la pérdida a lo largo del entrenamiento realizado en el dataset “train”.

Si bien se muestran buenos resultados, se pueden mejorar haciendo mejor sintonización y tiempos de entrenamiento con el modelo.

Los resultados obtenidos al evaluar el modelo entrenado con la métrica rouge score fueron los siguientes:

eval_loss: 1.5510817766189575

eval_rouge1: 46.8771

eval_rouge2: 23.5647

eval_rougeL: 39.6525

eval_rougeLsum: 43.3625

eval_gen_len: 17.8154

Conclusiones

Se logró realizar una aplicación que resume y traduce el texto dado, se vio que los resultados obtenidos son óptimos para la tarea.

Se usó dos modelos para hacer la aplicación, el primer modelo es el que se entrenó de resumen este modelo ya esta en huggingface , para la parte de traducción se usó un modelo ya entrenado de huggingface. (https://huggingface.co/Helsinki-NLP/opus-mt-en-es).

Trabajo Futuro

Mejorar los tiempos de inferencia que tienen los modelos al usar servicios en la nube.

Expandir los tipos de entradas que pueda tener, puesto que ahora solo soporta texto puro. (txt, docx)

Integrantes

Sergio Flores. — www.linkedin.com/in/sergio-flores-ll

Anna Montevilla. — www.linkedin.com/in/anna-i-montevilla

Koichi Sato. — www.linkedin.com/in/koichi-sato-316902182

Josmar Suarez. — www.linkedin.com/in/josmar-suarez-l

Referencias

https://arxiv.org/abs/1910.13461v1

https://huggingface.co/datasets/cnn_dailymail

https://huggingface.co/transformers/model_doc/bart.html

https://arxiv.org/abs/1810.04805

https://medium.com/walmartglobaltech/the-journey-of-open-ai-gpt-models-32d95b7b7fb2

¡Más inteligencia artificial!

La misión de Saturdays.ai es hacer la inteligencia artificial más accesible (#ai4all) a la vez que se realizan proyectos para el bien (#ai4good). Los talleres que realizamos forman parte del programa AI 4 Schools para que cualquier persona “aprenda haciendo” IA sin importar su especialidad o nivel de partida.

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 este link o visítanos en nuestra web www.saturdays.ai ¡te esperamos!

WRITTEN BY

DETECTAA-AI: Inteligencia Artificial en el diagnóstico presuntivo de trastornos del desarrollo en niños

by with No Comment 2021Quito

Quito. 2021

Utilizamos la Inteligencia Artificial para ayudarnos a realizar el diagnóstico presuntivo de trastornos en niños en edad escolar.

Saturdays.AI es una iniciativa a nivel global, cuyo principio es promover escenarios para la democratización del aprendizaje de la Inteligencia Artificial para todos y de forma ubicua. Democratizar, significa facilitar el acceso a todos los ciudadanos que deseen alcanzar una formación pertinente, relevante y de calidad, en cualquiera de los niveles educativos o profesionales. Por ese motivo, el equipo de investigación y desarrollo, conformado por: {Andrea Mariana Escobar, Danny Aguirre, Luis Chamba Eras, Marco Chiluiza, Paúl Quezada}, decidió participar en la Tercera Edición del Saturdays AI Quito, que de manera inédita, ubicua y flexible, se desarrolló de manera virtual.

En la primera sesión, se desarrolló la lluvia de ideas, con el objetivo de identificar la línea de investigación base, sobre el cual se desarrollaría el proyecto, sobre todo que tenga un impacto social y relacionado con los objetivos-metas de la Agenda 2030.

Originalmente se propuso el tema “Chatbot para la gestión de emociones de niños autistas”, obteniendo el primer árbol de problemas (Fig. 1), luego, se puso en marcha la estrategia de búsqueda de literatura que permita definir el alcance a la propuesta, se encontró 27 artículos científicos vinculados a esa línea base (ver Tabla 1).

Figura 1. Árbol de problemas inicial.

La literatura científica permitió conocer y comprender lo que se ha hecho y lo que se puede hacer en temas con el autismo, con ello se concluyó que el tema es muy amplio y con mucho futuro de trabajo para proyectos vinculados a la parte informática con un fin social. Además, se identificó que no existe un conjunto de datos de acceso libre que sirva como punto de partida para el tema planteado.

Otro punto clave, fue hacer búsquedas en grupos afines al tema del autismo, tanto en redes sociales como en la Web, con ello se observó que es un tema muy delicado y complejo, desde el punto de vista de los que conviven con el autismo, o los que no lo hacemos. Posiblemente es un tema que no ha tenido una visibilidad y democratización que permita, definir políticas para apoyar y educar a todos los que nos relacionamos con personas con autismo, sea de manera directa o indirecta. Con esto, se necesitó acudir con los profesionales o especialistas en campo, para despejar muchas dudas surgidas por la exploración preliminar, y con ello ver la viabilidad de la propuesta.

En el camino surgieron nuevas pistas, se encontró un conjunto de datos en Kaggle (https://www.kaggle.com/gpiosenka/autistic-children-data-set-traintestvalidate), relacionado con el autismo, que ha sido utilizado para construir algunos modelos que permiten por medio de la visión por computador predecir por medio de una fotografía si un niño tiene o no autismo. Con ello, cambió la perspectiva del proyecto, de pasar de las emociones (sin un conjunto de datos) al reconocimiento facial (con un conjunto de datos) en el mismo ámbito del autismo.

Para seguir en línea de conocer la opinión profesional sobre la propuesta, se realizó dos entrevistas, la primera con la especialista Amparito Morales, a la cual, se le presentó nuestra nueva idea, de que por medio de la tecnología se podía ayudar a mejorar en los diagnósticos en el área del autismo, inicialmente, se tuvo resistencia en el uso de la tecnología, pero eso fue bueno, porque permitió como equipo, convencer a la profesional de la utilidad real en escenario como en los grandes colegios o escuelas, en dónde el trabajo de los pocos especialistas (Departamento de Consejería Estudiantil (DECE)) puede ser apoyado por una herramienta que apoye en las tareas de automatización, en este caso, reconociendo cuáles de los niños por medio de una fotografía podría tener su atención prioritaria en la detección temprana del autismo.

De la primera entrevista surgió la segunda, con la reconocida investigadora Catalina López, pionera en el Ecuador por su enfoque senso-perceptivo para identificar los perfiles de autismo de acuerdo a la idiosincrasia de un país.

Actualmente, se encuentra terminando una herramienta de tamizaje orientado para niños y adolescentes de 4 a 17 años (características para alerta al diagnóstico clínico), además, durante la entrevista, Catalina López, validó la idea del proyecto, agregándole nuevas ideas vinculadas con las tecnologías, y que han surgido de sus investigaciones, como por ejemplo, realidad virtual para aplicar las herramientas de tamizaje, automatización de la herramienta de tamizaje considerando la protección de datos, privacidad, anonimato, confidencialidad, código de ética bajo principios mundiales, consentimiento informado, entre otros.

Finalmente, la investigadora propuso que un chatbot mediante la interacción sea por voz o texto, permitiría identificar patrones de comportamiento y el tema de emociones. Esta entrevista, fijó el trabajo o líneas futuras que se derivan del proyecto, centrándo el tema de reconocimiento fácil y una herramienta de tamizaje (Fig. 3), como el límite para la propuesta final del proyecto DETECTAA-AI, con la que se trabajó en el Saturdays AI.

Figura 2. Entrevista con Catalina López, Especialista en Perturbaciones de la Comunicación Humana de la Universidad Andina Simón Bolívar.
Figura 3. Lluvia de ideas del modelo inicial del proyecto DETECTAA-AI.

Contexto

Los trastornos del desarrollo, técnicamente conocidos como trastornos del neurodesarrollo, son trastornos con base neurológica que pueden afectar la adquisición, retención o aplicación de habilidades específicas o conjuntos de información. Consisten en alteraciones en la atención, la memoria, la percepción, el lenguaje, la resolución de problemas o la interacción social. Estos trastornos pueden ser leves y fácilmente abordables con intervenciones conductuales y educativas o más graves, de modo que los niños afectados requieran un apoyo educativo particular. Entre los trastornos del neurodesarrollo tenemos: trastorno de déficit de atención/hiperactividad, trastornos del espectro autista, dificultades del aprendizaje, como la dislexia y las deficiencias en otras áreas académicas, discapacidad intelectual, síndrome de Rett.

“El autismo es un trastorno neurológico complejo que generalmente dura toda la vida. Es parte de un grupo de trastornos conocidos como trastornos del espectro autista (TEA). Actualmente se diagnostica con autismo a 1 de cada 68 individuos y a 1 de cada 42 niños varones, haciéndolo más común que los casos de cáncer, diabetes y SIDA pediátricos combinados. Se presenta en cualquier grupo racial, étnico y social, y es cuatro veces más frecuente en los niños que en las niñas. El autismo daña la capacidad de una persona para comunicarse y relacionarse con otros. También, está asociado con rutinas y comportamientos repetitivos, tales como arreglar objetos obsesivamente o seguir rutinas muy específicas. Los síntomas pueden oscilar desde leves hasta muy severos” [1].

El autismo en Ecuador

De acuerdo a la especialista Catalina López, se tiene los siguientes avances:

A nivel mundial se estima que el 1% puede estar dentro del TEA, según la Organización Mundial de la Salud, en 2018 se reportaron 1.521 en Ecuador, y aproximadamente un 13,75% se tiene diagnósticos erróneos.

¿Cuál es el problema?

El personal que labora en los departamentos de consejería estudiantil de las unidades educativas (DECE) debe realizar evaluaciones para determinar los alumnos que pudiesen presentar problemas de comportamiento. Debido a la gran cantidad de estudiantes asignados a cada profesional de estos departamentos, el proceso de evaluación consume la mayor cantidad de tiempo disponible por este personal, dejando muy pocos recursos para profundizar el diagnóstico y apoyo a los niños que realmente presentan trastornos del desarrollo. En la Fig. 4 se observa el árbol de problemas, que se lo obtuvo, previa lluvia de ideas, lectura de la literatura y luego de las entrevistas.

Figura 4. Árbol de problemas relacionados con el proyecto DETECTAA-AI.

¿Cómo lo pensamos resolver?

Se desarrollará una aplicación Web formada por dos componentes (Fig. 3).

El primer componente ayudará a predecir qué estudiantes pueden o no tener el TEA basado en una imagen fotográfica (tipo tamaño carné) por medio de visión por computador. Los rasgos que se determinen dependen de las bases de datos disponibles. En una primera fase se utilizará la base de datos disponible en Kaggle (https://www.kaggle.com/gpiosenka/autistic-children-data-set-traintestvalidate) para detección facial de TEA, considerando definir un proceso de entrenamiento del sistema que permita detectar nuevos factores de comportamiento a medida que se disponga de bases de imágenes adicionales.

Técnicamente, el tamizaje corresponde a la aplicación de un test o procedimiento a personas “asintomáticas”, con el objetivo de separarlos en dos grupos; aquellos que tienen una condición que podría beneficiarse de una intervención temprana; y aquellos que no.

El segundo componente realizará un tamizaje, usando el test MCHAT, y que sea la base para en el futuro implementar el procesamiento de lenguaje natural (chatbot de preguntas y respuestas).

¿Cómo se vincula el proyecto con los objetivos de desarrollo sustentables?

Se vincula con dos objetivos:

Primero, con el de Salud y bienestar (ODS 3), meta: reforzar la capacidad de todos los países, en particular los países en desarrollo, en materia de alerta temprana, reducción de riesgos y gestión de los riesgos para la salud nacional y mundial.

Segundo, con la Reducción de las desigualdades (ODS 10), meta: el avance en la reducción de la desigualdad, tanto dentro de los países como entre ellos, ha sido desigual. Todavía se debe dar más peso a la opinión de los países en desarrollo en los foros decisorios de las instituciones económicas y financieras internacionales. Además, si bien las remesas pueden ser un medio de supervivencia para las familias y las comunidades de los trabajadores migrantes internacionales en sus países de origen, el elevado costo de transferir dinero sigue reduciendo los beneficios.

¿Cuál es la hipótesis del proyecto?

El uso de la Inteligencia Artificial permitirá crear un prototipo que permita apoyar al diagnóstico presuntivo de trastornos del desarrollo en niños de edad escolar.

¿Cuál es la población objetivo?

  • Niños de 0 a 12 años
  • Padres, madres, cuidadores
  • Educadores
  • Especialistas de los DECE
  • Investigadores

¿Qué nos dice la literatura científica sobre proyectos relacionados con el reconocimiento facial?

La literatura científica que soporta nuestro proyecto se resume en la Tabla 2.

¿Qué es la visión por computador?

Es un campo de la Inteligencia Artificial enfocado a que las computadoras puedan extraer información a partir de imágenes, ofreciendo soluciones a problemas del mundo real (Fig. 5).

Figura 5. El reconocimiento facial puede ayudar a mejorar los diagnósticos, foto derecha, niño sin TEA, niño de la izquierda niño con TEA.

¿Qué áreas del conocimiento se vinculan?

  • Ciencias de la Salud (Salud Mental).
  • Ciencias de la Computación (Inteligencia Artificial, Visión por Computador).

Metodología

La metodología que se utilizó fue Desing Thinking, en la Fig. 6 se observa un resumen de cada una de las etapas desarrolladas.

Figura 6. Descripción de cada una de las etapas de la metodología de acuerdo con el proyecto DETECTAA-AI.

En la Fig. 7, se tiene un lienzo de trabajo proporcionado por https://www.analogolab.co/, para poner en marcha los principios de la metodología Desing Thinking. En este enlace Web, se observa el diseño completo del proyecto.

Figura 7. Idea general del proyecto, Mapeo de actores vinculados con el proyecto, definir los clientes o interesados en el proyecto, futuros beneficiarios, Declaración de la idea, Factores positivos, oportunidades, problemas y soluciones.

Resultados

Arquitectura

La arquitectura del proyecto está dividida en una aplicación de Frontend y una aplicación de Backend (ver Fig. 8). El Frontend, desarrollado con Flask (Framework de Python), contiene todas las interfaces con las cuales el usuario final interactúa. Esta, a su vez, se conecta mediante un endpoint al Backend. En el Backend se encuentra una API, desarrollada con Flask, que contiene un modelo de Deep Learning entrenado con librerías de TensorFlow y un conjunto de imágenes obtenidas desde Kaggle. El Frontend también interactúa con un modelo entrenado en Teachable Machine (una plataforma de Google para entrenar modelos de machine learning de forma rápida y fácil).

Figura 8. Arquitectura propuesta para DETECTAA-AI.

Enlaces Web a las API y a la aplicación de DETECTAA-AI:

Flujo de trabajo de DETECTAA-AI

Los resultados obtenidos para el primer caso (niño con TEA) son bastante favorables, ya que tanto los modelos como el cuestionario dan un porcentaje alto de detección de TEA en la persona evaluada, tal como se muestra en la Fig. 9.

Figura 9. Flujo de trabajo, caso 1.

Los resultados del segundo caso (niña sin TEA), presentan porcentajes aceptables en el diagnóstico de TEA. Tal como muestra la Fig. 10, los resultados obtenidos fueron: Teachable Machine: 100%, TensorFlow: 85.28% y M-Chat: Riesgo Bajo.

Figura 10. Flujo de trabajo, caso 2.

En el tercer caso (niño sin TEA) los resultados obtenidos de los modelos y M-chat reflejan resultados diferentes, ya que los modelos de machine learning devuelven diagnósticos acertados en cuanto a la prueba realizada, sin embargo, el M-chat retorna un Riesgo alto de tener un diagnóstico de TEA, como se muestra en la Fig. 11.

Figura 11. Flujo de trabajo, caso 3.

Conclusiones

Con el desarrollo del proyecto DETECTAA-AI se llegó a las siguientes conclusiones:

  • Es posible detectar indicios de TEA en las personas mediante el uso de modelos de inteligencia artificial.
  • Para que un modelo tenga una tasa de confiabilidad más alta, es necesario una mayor cantidad de imágenes de entrenamiento y mejor procesamiento de esa información.
  • Los algoritmos de inteligencia artificial sirven como un apoyo a los profesionales de la salud, más no como un reemplazo.
  • Es necesario un vínculo entre la academia, estado, empresas, gremios, sociedades, para que estas iniciativas se puedan poner en marcha de acuerdo al contexto Ecuatoriano.
  • Combinar la investigación científica a procesos profesionales, permite construir prototipos escalables en el tiempo.
  • El prototipo DETECTAA-AI, debe usarse con fines académicos y de investigación, como ejemplo de prueba de concepto, y no para ofrecerla como herramienta de diagnóstico final, ya que se necesita un equipo de profesionales que aporten en la detección del TEA.

Líneas futuras

  • Implementar la herramienta de tamizaje con NLP, de tipo de preguntas y respuestas, utilizando el cuestionario propuesto por la Dra. Catalina López en el contexto Ecuatoriano, considerando la privacidad, protección de datos, entre otros.
  • Obtener una base de datos propia de imágenes en el contexto de Ecuador, para realizar pruebas al prototipo DETECTAA-AI.
  • Es recomendable aumentar una tercera herramienta de detección de TEA por NLP, el cual permita detectar presencia de tea mediante el análisis de patrones en la voz de la persona que se requiera diagnosticar.
  • Concientizar a la población que la tecnología puede ser un apoyo muy importante en el contexto de la Salud.

Recursos del proyecto DETECTAA-AI

Referencias

[1] https://www.uasb.edu.ec/reconocimiento-a-la-directora-del-area-de-salud-catalina-lopez-id1550289/

Presentación del proyecto: DemoDay

¡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!Saturdays.AI

Public domain.

WRITTEN BY

Luis Chamba-Eras

Profesor e investigador de la Universidad Nacional de Loja. Investigación en Inteligencia Artificial en Educación.

Saturdays.AI

Saturdays.AI

Saturdays.AI is an impact-focused organization on a mission to empower diverse individuals to learn Artificial Intelligence in a collaborative and project-based way, beyond the conventional path of traditional education.

Clasificación de idiomas originarios de Bolivia con Machine Learning

by with No Comment 2021La Paz

La Paz. 2021

Usamos técnicas de Machine Learning para la clasificación de idiomas.

Bolivia lucha para que no desaparezcan los idiomas indígenas, sin embargo, es aún muy complicado acceder a recursos que ayuden la asimilación y aprendizaje de los mismos. Es por ello que planteamos crear una herramienta con Machine Learning para la clasificación de idiomas, que si bien es una tarea sencilla es elemental para realizar tareas más complejas como la traducción automática, el análisis de sentimientos, conversión de habla a texto, texto a habla, etc. Este modelo de clasificación se creó usando herramientas de NLP (procesamiento de lenguaje natural) y ML (aprendizaje automático), obteniendo una precisión superior al 99%.

Desde 2006 Bolivia es líder en la defensa y reivindicación de los pueblos y las culturas indígenas en su territorio y en el mundo.

“Hoy en día, las 36 lenguas originarias en Bolivia son idiomas oficiales. En Bolivia se tiene que hablar y enseñar inicialmente un idioma originario” [1].

Pero todo esté trabajo ¿realmente tiene resultados positivos en la asimilación y aprendizaje de las lenguas originarias en Bolivia?.


Descripción del problema

Si bien en nuestro país se lucha porque no desaparezcan estos idiomas indígenas es aún muy complicado acceder a recursos que ayuden la asimilación y aprendizaje de los mismos.
Sin embargo, actualmente se puede usar la tecnología como un aliado para solucionar este problema y la detección de idiomas es un punto inicial y primordial para crear herramientas de traducción automática de texto, de conversión de texto a voz, voz a texto, voz a voz, entre muchas otras aplicaciones.


Objetivo

Crear una herramienta con Machine Learning capaz de identificar y clasificar idiomas originarios de Bolivia, para agilizar tareas relacionadas como la traducción, recuperación de la información, etc.


Límites y alcances

LÍMITES: Debido a la dificultad de conseguir un conjunto de datos suficientemente grande de los idiomas más hablados en Bolivia (quechua, guaraní, aymara), solo nos centramos en el idioma quechua.

ALCANCES: La herramienta de identificación, en una primera etapa, será capaz de clasificar el idioma de frases ya sea como quechua o español.


Metodología

Para la clasificación de idiomas mediante Machine Learning se utilizó una metodología iterativa incremental, que conlleva las siguientes fases:

Figura 1. Metodología (Dataiku)


Captura de datos

Posterior a la creación del dataset nos dimos cuenta que éste estaba desbalanceado porque el número de frases en quechua duplicaban el de español, por esa razón decidimos balancear los datos agregando frases de español obtenidos de un dataset de Kaggle.

Figura 2. Captura de datos (Imagen extraída de un sitio web)


Pre-procesamiento

En esta etapa se realizaron diversas formas de pre-procesamiento, desde la ingeniería de características (feature engineering) hasta la vectorización. Las cuales se describen a continuación.

Limpieza de caracteres irrelevantes

Las frases en español de Kaggle tenían caracteres de otros idiomas e irrelevantes para la clasificación, es por ello que antes de unir con el dataset que se tenía se pasó a realizar una limpieza de todos esos caracteres de las frases de Kaggle. Una vez unido el dataset aún se tenían caracteres que no aportaban información como: dígitos, signos de puntuación, etc. y por tanto se realizó una limpieza de estos caracteres.

Técnicas implementadas

En base a la información del dataset se pudo notar que había un dato mal tabulado y se realizó la imputación de datos por valores nulos. Por otro lado, como el dataset cuenta con solo un feature y el target, no se tuvo la necesidad de reducir las dimensiones.

Análisis de los features

Cada idioma tiene sus propias reglas gramaticales y el idioma Quechua no es ajeno a eso, por ende se investigó las reglas de este idioma y se pudo notar ciertas características interesantes que lo diferencian de otros idiomas, por mencionar algunas:

  1. El alfabeto quechua cuenta con 28 consonantes (algunas consonantes son diferentes al de español como: ch’, chh, qh, p’) y 3 vocales (a, i, u)
  2. Las consonantes del quechua se clasifican según el modo de articulación, algunas de estas son:
  • Oclusivas (p, t, k, q)
  • Aspiradas (ph, th, chh, kh, qh)
  • Glotalizadas (p’, t’, ch’, k’, q’)
  • Semiconsonantes (w, y)

3. Para diferenciar el género de una persona se usan las palabras: warmi y qhari

4. La interrogación en el quechua se realiza agregando a la palabra el sufijo -chu.

Estas y muchas más características de la gramática Quechua, así como la gramática del Español fueron tomadas en cuenta para realizar las gráficas, las cuales nos permiten corroborar estas diferencias entre las reglas gramaticales en el dataset.

Uno de los gráficos que realizamos fue la frecuencia de las vocales por idioma en el dataset (Figura 3). La frecuencia de las vocales fueron calculadas según el número de caracteres de cada frase.

Figura 3. Frecuencia de vocales (Elaboración propia)

Otras gráficas que realizamos fueron la frecuencia de las consonantes como: K, H, M, R (Figura 4) y caracteres especiales como: á, é, í, ó, ú, ä, ü, ‘ (Figura 4), según el idioma.

Figura 4. Histograma de caracteres (Elaboración propia)

Estas gráficas nos permitieron aclarar algunas dudas sobre las diferencias gramaticales entre el idioma Español y Quechua, y representaron un punto clave para realizar el pre-procesamiento de los datos.

Por las diferencias de algunas letras y caracteres utilizados para cada idioma, además de ciertos sufijos o prefijos propios, numeración y demás características, decidimos vectorizar las frases según el modelo n-gram de caracteres. Para capturar características importantes en ambos idiomas delimitamos el modelo n-gram de 1 a 5, esto por temas de rendimiento y también porque consideramos que este número nos permite abstraer aquellas características gramaticales que citamos anteriormente.

Figura 5: Pre-procesamiento y vectorización de los features (Elaboración propia)

Además de vectorizar las frases según la frecuencia de caracteres únicos que tiene cada frase se aplicó la frecuencia TF-IDF, medida estadística que evalúa cuán relevante es un término para un documento en una colección. En este caso cada término es representado por cada carácter y el documento es representado por la frase del idioma en el dataset (colección de frases).


Selección y evaluación de modelos

Con los datos listos se procedió a construir los modelos de predicción. Se utilizaron modelos de clasificación debido a que tenemos un problema de clasificación binaria, sólo se tienen dos posibles etiquetas, “Quechua” y “Español”.

Por lo tanto, se utilizaron los siguientes algoritmos de aprendizaje supervisado:

  • Naive Bayes
  • Support vector Machine
  • Logistic regression

Para encontrar la mejor combinación de hiperparámetros se utilizo GridSearch de la biblioteca Sklearn.

Las matrices de confusión para los 3 modelos son:

Figura 6. Matrices de confusión, balanced accuracy y tiempo de ejecución de los 3 modelos (Elaboración propia)


Clasificación de nuevos datos

Una vez seleccionado nuestro mejor modelo, es necesario probarlo con algunas frases nunca antes vistas, por ello probamos frases que solo contienen palabras de un idioma, frases que contienen palabras de ambos idiomas que es usual en el habla coloquial de los quechua hablantes y por último una frase sin sentido. Nuestro modelo seleccionado se comporta bien con los dos primeros tipos de frases, sin embargo, al ingresar frases sin sentido que no pertenece ni al español o al quechua, estas frases son clasificadas directamente como quechua, esto se debe a que como manejamos un modelo binario el texto ingresado sea cual sea debe etiquetarlos con una etiqueta u otra.

Figura 7. Resultados del modelos (Elaboración propia)


Conclusión

En general, el modelo de Machine Learning para la clasificación de idiomas basado en Support Vector Machine ofrece el mejor resultado predictivo con una puntuación de precisión balanceada superior al 99%.

Específicamente, el modelo funciona bien para clasificar Español y Quechua dada la alta precisión, y puntajes f1 para estos dos idiomas.

Si bien la mejor precisión se obtuvo con SVM, considerando las variables precisión y rendimiento el mejor modelo sería el basado en Regresión Logística, ya que ofrece un tiempo de ejecución menor al de SVM y tiene una precisión superior al 99%, lo cual es un factor importante en aplicaciones en real time.

Se logró abstraer algunas características del idioma quechua, por lo que es posible realizar el mismo análisis con otros idiomas originarios de Bolivia


Trabajos futuros

Si bien este problema aparenta ser sencillo es un paso necesario para:

  • Traducción automática
  • Detección de idioma para el uso de boots
  • Análisis de sentimientos, etc.

El codigo fuente de este proyecto se puede encontrar en: github


Referencias

ONU – Bolivia, a la vanguardia en la protección y promoción de las lenguas indígenasSaturdays.AI


WRITTEN BY

EVELYN CUSI LOPEZ

Saturdays.AI

Repositorio

En el siguiente repositorio se encuentra el código usado para desarrollar esa aplicación: https://github.com/SaturdaysAI/Projects/tree/master/Lapaz/clasificacion-idiomas-machine-learning-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!

Detección de Discurso de Odio

Detección de Discurso de Odio en Redes Sociales mediante Transformers y Natural Language Processing

by with No Comment 2021La Paz
Detección de Discurso de Odio

La Paz. Deep Learning. 2021

De acuerdo con las Naciones Unidas, el discurso de odio se define como “Todas las formas de expresión que comparten, alienten, justifiquen o promueven la humillación, el menosprecio, la estigmatización o amenaza contra una persona o grupo como las mujeres y las niñas”.

Actualmente, estamos experimentando una oleada de discurso de odio en varios ámbitos y hacia diferentes minorías. Por ejemplo, después de la final de la Eurocopa 2020 se desató una ola de ataques racistas en redes sociales contra jugadores de la sección inglesa después de haber fallado penales. En particular, se destaca el uso de Internet para la propagación de este tipo de agresiones gracias a que éste proporciona anonimidad, distanciamiento, ausencia de normativa de los contenidos, entre otros.

Las redes sociales y otras plataformas en Internet cuentan con algunos mecanismos automáticos para detectar discursos de odio. Estas herramientas han adquirido mayor relevancia ante diversos sucesos que han disparado la proliferación de contenido con discurso de odio. La siguiente gráfica muestra cómo el discurso de odio aumentó durante el año de pandemia, según los mensajes de odio eliminados por Facebook:

Figura 1:Número de publicaciones con discurso de odio eliminadas en Twitter. Fuente: https://es.statista.com/grafico/21710/publicaciones-de-discurso-del-odio-eliminadas-por-facebook/

Sin embargo, estas herramientas no se encuentran disponibles para cualquier ciudadano que quisiera analizar contenidos para determinar la existencia de discurso de odio. Es por esta razón que decidimos construir un método que sirviera como herramienta o base para la construcción de tecnologías que pudieran ayudar en la detección de este tipo de comentarios y así poder detener su propagación.

En este artículo, describimos cómo aplicamos métodos de Deep Learning y Procesamiento de Lenguaje Natural (NLP, por sus siglas en inglés) para la detección de discurso de odio en comentarios de Twitter en idioma español. Este trabajo es una continuación del proyecto Violentómetro Online. En dicho proyecto tuvimos un primer acercamiento al problema de detección de discurso de odio contra mujeres mediante el uso de técnicas clásicas de Machine Learning.

En esta sección, describimos la metodología (Transformers y Data Augmentation), así como los datos que utilizamos durante la realización de este proyecto. También detallamos los parámetros del modelo y las técnicas de interpretación que empleamos para entender sus predicciones.

Conjunto de Datos

MEX-A3T: Fake News and Aggressiveness Analysis es un evento organizado por la comunidad de NLP en México para detectar noticias falsas y textos con discurso de odio. Los organizadores compartieron con el equipo el conjunto de datos de entrenamiento que consiste en Tweets en el idioma español. El conjunto tiene las siguientes características:

  • 7 mil 332 registros
  • 2 columnas:
  • Text: Texto del Tweet (no contiene handlers).
  • Category:
  • 1: Contiene odio en general (2110 registros)
  • 0: No contiene odio (5222 registros)
Figura 2: Distribución del conjunto de datos MEX-A3T

Data Augmentation

La distribución del conjunto de datos (Figura 2) muestra que se tienen menos registros de la categoría 1 (discurso de odio). Este problema afecta en particular a los modelos de Deep Learning por lo que fue necesario aplicar técnicas que nos permitieran generar nuevos ejemplos (sintéticos) para tener una cantidad de registros cercana a la de la categoría 2.

Las operaciones de data augmentation que se aplicaron al 50% de mensajes de discurso de odio del dataset para obtener más ejemplos son las siguientes:

  • Synonym Replacement: Reemplazo de algunas palabras por su sinónimo.
  • Random Deletion: Borrado de algunas palabras de manera aleatoria con probabilidad p.
  • Random Swap: Intercambio de palabras de manera aleatoria.
  • Random Insertion: Inserción de un sinónimo en una posición aleatoria n.

Modelo

Para crear el modelo utilizamos la librería de Transformers de Hugging Face (Figura 4) que contiene modelos de Deep Learning pre entrenados para varios propósitos como clasificación de texto, extracción de información, traducción, entre otros. En particular utilizamos el modelo BETO, el cual es un modelo con la arquitectura BERT entrenado con un corpus en español, para obtener la representación vectorial del texto (embeddings). Además se utilizaron dos capas adicionales: multi-layer bi-directional GRU y otra lineal que obtiene las predicciones. Es posible utilizar otras arquitecturas en lugar de multi-layer bi-directional GRU, pero para este proyecto decidimos utilizar ésta ya que es más eficiente computacionalmente que LSTM.

Figura 3: Arquitectura de Transformers. Fuente: https://lilianweng.github.io/lil-log/2018/06/24/attention-attention.html#transformer

Nota: El código completo se puede consultar en el repositorio del proyecto violentometro-online.

Mejores Parámetros

Probamos diferentes variaciones de BETO para obtener los mejores parámetros de entrenamiento para el modelo final. Evaluamos cada modelo utilizando la métrica F1 ya que ésta es comúnmente utilizada en problemas de clasificación de textos además de tomar en cuenta las siguientes variaciones:

  • Model: Variación de BETO (cased y uncased).
  • Epochs: Número de iteraciones en el entrenamiento.
  • Preprocessed: Preprocesamiento del texto que incluye operaciones como remover emojis, dígitos, stopwords, entre otros.
  • Sample frac: Proporción de ejemplos sintéticos en el conjunto de datos.

La siguiente tabla muestra los modelos con los que obtuvimos los mejores resultados:

Tabla 1: Resultados de los mejores parámetros del modelo

Como podemos observar, el mejor modelo (BETO-Uncased) no requirió un preprocesamiento del texto además de que fue necesario generar una importante cantidad de datos sintéticos. Dicho modelo obtuvo el mejor valor (0.842) de la métrica F1. Queremos resaltar que dicho resultado es mucho mejor al que habíamos obtenido anteriormente utilizando el modelo de Random Forest..

Explicación de las Predicciones

Utilizamos la API Lime para obtener una explicación detallada de las predicciones del modelo. Lime es capaz de explicar cualquier modelo de clasificación que haga predicciones de una o más clases. Para poder utilizar Lime es necesario crear una función que regrese un arreglo de Numpy con las probabilidades de cada una de las clases. Lime muestra los pesos de cada una de las palabras del texto en la predicción. La Figura 4 contiene la explicación de la predicción de un texto:

Figura 4: Ejemplo de explicación de la predicción de un texto con discurso de odio

Se puede observar que en la predicción del modelo, se le dio más peso a la palabra que aparece primero en la lista además de la representación en texto del emoji.

Aplicación Web

Desarrollamos el prototipo de una aplicación web con el modelo que obtuvo los mejores resultados. Dicha aplicación web se puede consultar aquí. El prototipo fue desarrollado con el framework Streamlit y se utilizó GitHub Actions para desplegarlo (integración continua) en AWS. La siguiente imágen muestra el prototipo:

Figura 5: Aplicación Web Violentómetro Online

Los usuarios pueden introducir cualquier texto en la aplicación. Cuando los usuarios pulsan las teclas Ctrl+Enter, la aplicación (modelo) devuelve como resultado las siguientes categorías:

  • 1 = Contiene discurso de odio
  • 0 = No contiene discurso de odio

El objetivo de nuestro proyecto es desarrollar un método efectivo para detectar automáticamente la violencia verbal en idioma español que ocurre en discursos en línea. Con este proyecto pudimos crear un método que tiene una efectividad bastante razonable utilizando técnicas avanzadas como Deep Learning y data augmentation, además de estar construido con herramientas gratuitas y de código abierto. También se utilizó una API que nos permitió entender las predicciones del modelo.

Entre los siguientes pasos de nuestro proyecto podemos destacar lo siguiente:

  • Utilizar otras variantes del idioma español.
  • Recolectar más ejemplos de discurso de odio que se encuentren dirigidos a diferentes minorías (mujeres, religiones, opiniones, entre otros) para obtener un modelo más robusto.
  • Incorporar un mecanismo de feedback para los usuarios de la aplicación web.

Queremos agradecer a María José Díaz-Torres, Paulina Alejandra Morán-Méndez, Luis Villasenor-Pineda, Manuel Montes-y-Gómez, Juan Aguilera, Luis Meneses-Lerín, autores del Dataset MEX-A3T y del artículo Automatic Detection of Offensive Language in Social Media: Defining Linguistic Criteria to build a Mexican Spanish Dataset. También queremos agradecer al equipo que hizo posible Saturdays.AI La Paz por todo su trabajo y dedicación en la organización del programa.

Integrantes

SophieB

Presentación del proyecto: DemoDay

¡Más inteligencia artificial!

La misión de Saturdays.ai es hacer la inteligencia artificial más accesible (#ai4all) a la vez que se realizan proyectos para el bien (#ai4good). Los talleres que realizamos forman parte del programa AI 4 Schools para que cualquier persona “aprenda haciendo” IA sin importar su especialidad o nivel de partida.

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 este link o visítanos en nuestra web www.saturdays.ai ¡te esperamos!