Caracterización de eventos sísmicos usando tweets

Descripción del Problema

La influencia que tienen las redes sociales en gran parte del mundo hoy en día es inmensa, y nuestro país es un ejemplo de ello. El uso de Twitter en Chile, ha ido creciendo de manera vertiginosa en los últimos años, tanto así que es una herramienta muy utilizada para realizar diferentes investigaciones y estudios. Así es como actualmente se está desarrollando, por el Núcleo Milenio CIWS en coordinación con el Centro Sismológico Nacional CSN de la Universidad de Chile, una plataforma web que ayudará a determinar el área afectada por un sismo, utilizando la información que entrega la gente a través de la red social Twitter. Sin embargo, aún quedan cosas por hacer para que esta plataforma sea lo más funcional y completa posible. Algunas, por ejemplo, son el poder identificar cuándo en un tweet se habla de un movimiento en "tiempo real", o simplemente se esta comentando sobre un movimiento pasado; como también caracterizar los eventos de manera de poder comparar movimientos de diferentes intensidades, o eventos que sean similares, pero que sucedan en distintas partes de Chile; o evaluar que tan generalizable es el modelo, utilizando tweets de otros países (y por ende también, otros idiomas).

Una herramienta en tiempo real de detección de eventos sísmicos podría ser muy útil para la determinación de alertas preventivas, segundos después de ocurrido un temblor, incluso antes de saber el grado sísmico del evento.


Objetivo: Caracterizar eventos sísmicos en tiempo real utilizando tweets y herramientas de Minería de Datos.

Descripción de los Datos

La base de datos proporcionada está compuesta por 132 tablas, de las cuales 66 contienen los tweets y las otras 66 contienen la información correspondientes a los usuarios que publicaron cada tweet. Algunos atributos de la tabla de usuarios son:

  • Id
  • Nombre usuario
  • Nombre real
  • Ubicación
  • Cantidad de seguidores
  • Entre otros

Por otra parte, algunos atributos interesantes de las tablas de tweets son:

  • Fecha de publicación
  • Id del usuario
  • Si corresponde a un RT
  • Cantidad de veces que fue RT
  • Texto del tweet
  • Idioma del tweet

Los mensajes que fueron recolectados durante varios meses, prácticamente todos los días exceptuando algunos que por diversas razones, no se registraron tweets; e incluyen publicaciones de todo el mundo, en variados idiomas. En total, se contabilizaron más de 20 millones de datos para analizar.

Limpieza de los Datos

Una de las primeras cosas que se hicieron para poder comenzar a trabajar con los datos fue una limpieza de estos mismos. Para simplificar las cosas, se decidió seleccionar solo los tweets que estuvieran escritos en español (esto se determinaba mediante un atributo de las tablas de tweets). Además, para una primera instancia solo se considerarían los tweets, dejando el caso de los retweets (RT) para instancias posteriores.

Otro de los filtros que se le aplicaron a los datos fue que se utilizaron los tweets que tuvieran por lo menos alguna de las siguientes palabras claves: temblor, terremoto, temblando, sismo. De esta manera, se reducía en gran cantidad el numero de tweets, pero esto no aseguraba que hablaran o se refirieran a un evento sismico, dado que dichas palabras claves no son usadas exclusivamente para sismos (por ejemplo, terremoto se puede referir a la bebida alcoholica popular de chile; temblor puede ser parte de una estrofa de la canción de Soda Stereo; temblando puede estar incluido en un mensaje que exprese que alguien tiene frio, miedo; entre otros casos).

Luego de esto, y para comenzar desde lo mas simple a lo mas complejo (si es que el tiempo así lo permitía), se decidió eliminar todos los atributos de la tabla de tweets, y solo quedarse con el campo que contenía el tweet; esto porque también se cree que la información más relevante para caracterizar un mensaje escrito durante o justo despues de un evento sísmico se encuentra solamente en el mensaje, y no en el resto de los atributos. Sin embargo, no se descarta el incluir más atributos en caso de que sea necesario.

Exploración de los Datos

En primer lugar, era necesario conocer más características de los datos proporcionados. Como exploración inicial pudimos conocer el idioma predominante en los mensajes, como se observa en el siguiente gráfico. Confirmamos que el idioma con mayor mensajes es el español, superando por mucho al resto de los idiomas.

grafico-idiomas

Además, constatamos que el país predominante de mensajes, es Chile, ya que los datos fueron tomados con un bounding box en nuestro país. Otra característica importante encontrada, fue que el atributo de Geolocalización de los datos no estaba presente en todos, sólo se encontraba en un 10% de ellos, por lo que cualquier experimento que considerara ocupar la Geolocalización como atributo para clasificar, fue descartado. Todo lo anterior fue realizado por medio de consultas en SQL.

Por otra parte, también quisimos saber cuales eran las palabras más comunes visualizadas en la siguiente imagen:

palabras-recurrentes

Procesamiento de los Datos

Cuando se trabaja con Text Mining lo más común es trabajar con una matriz llamada Tf-idf, la cual normaliza los archivos de texto por medio de una matriz, donde cada palabra en los archivos corresponde a una dimensión. La matriz tiene la siguiente forma:

tabla-ejemplo

En nuestro proyecto, cada archivo de texto corresponde a un mensaje de Twitter, y cada palabra en esos tweets será considerada una dimensión. Esto producirá un problema de dimensionalidad, ya que palabras que probablemente no nos darán información relevante, serán consideradas como un atributo.

Para crear esta matriz y hacer minería de datos sobre los mensajes, se decidió usar Python con las herramientas NLTK y SciKit-Learn. La primera, entrega lo necesario para limpiar de forma correcta los mensajes, eliminando los stop words y puntuaciones en español (característica que SciKit-Learn no incluye, sólo en inglés). Con la segunda, se crea la matriz de Tf-idf y se pueden aplicar clasificadores sobre ésta.

A continuación se muestran parte de los códigos donde se utilizó NLTK y SK-Learn:

                                    

import nltk from nltk.corpus import stopwords from nltk import word_tokenize from nltk.data import load from nltk.stem import SnowballStemmer from string import punctuation #stopword list to use spanish_stopwords = stopwords.words('spanish') #spanish stemmer stemmer = SnowballStemmer('spanish') #punctuation to remove non_words = list(punctuation) #we add spanish punctuation non_words.extend(['¿', '¡']) non_words.extend(map(str,range(10))) stemmer = SnowballStemmer('spanish') def stem_tokens(tokens, stemmer): stemmed = [] for item in tokens: stemmed.append(stemmer.stem(item)) return stemmed def tokenize(text): # remove links from tweets text = re.sub(r"http\S+", "https", text) # remove punctuation text = ''.join([c for c in text if c not in non_words]) # remove repeated characters text = re.sub(r'(.)\1+', r'\1\1', text) # tokenize tokens = word_tokenize(text) # stem try: stems = stem_tokens(tokens, stemmer) except Exception as e: print(e) print(text) stems = [''] return stems

Con lo anterior se definen los stop words y se crea una función para "tokenizar" los mensajes, es decir, que cada palabra sea considerada independiente. Se agrega la característica de filtro para los URL incluídos en mensajes y sólo serán considerados como "https". Además, se aplica Stemmer, que considera raíces comunes en palabras. Por ejemplo, terremoto y terremoteado serán considerados ambos por terremot. Así, las dimensiones de la matriz Tf-idf son reducidas.

Luego, se aplicó SK-Learn a los mensajes utilizando TfidfVectorizer(), la cual recibe como parámetros los stop words, si se considerarán o no los acentos y si se pasará todo a minúsculas, además la opción de tokenizer. Recomendamos revisar la documentación aquí.

También recomendamos revisar el siguiente link sobre "Working with data text".

Teniendo la matriz, se eligieron los siguientes clasificadores incluídos en SK-Learn: Árbol de decisión, Stochastic Gradient Descent y Support Vector Machine. Para validar los resultados, se utilizó K-folds cross validation, con k=10,15,20.

Resultados

Se debe tener en cuenta que utilizaron dos Set de Entrenamiento, uno creado de clasificación manual de los mensajes pero no supervisada y otra, tomando mensajes que fueron emitidos durante varios sismos registrados durante el 25 de julio. Conociendo la hora exacta de estos eventos sísmicos, se filtraron los mensajes emitidos durante el sismo e inmediatamente después, los cuales fueron clasificados con 1 (evento en tiempo real) y también se tomaron mensajes que fueron emitidos donde no hubo sismos registrados y se etiquetaron con un 0 (no en tiempo real).

El problema con el primer set de entrenamiento fue que como hubo poca supervisión sobre la clasificación de los mensajes (fue una clasificación abierta al público), las clasificaciones no fueron hechas de forma correcta y sólo un 40% estuvo bien clasificado. Para no descartar esta herramienta, fue considerada para contrastar los resultados con el segundo set de entrenamiento, el cual tuvo un 70% de elementos bien clasificados.

A continuación se exponen los resultados para los tres clasificadores probados en el set de entrenamiento I y II:

Set de Entrenamiento I: Malo

Árbol de Desición

metricas-tree-1

SGD

metricas-sgd-1

SVM

metricas-svm-1

Set de Entrenamiento II: Bueno

Árbol de Desición

metricas-tree-2

SGD

metricas-sgd-2

SVM

metricas-svm-2

Conclusiones

  1. Al trabajar con Text Mining es fundamental la reducción de dimensiones, eliminando stop words, puntuaciones, acentos y mayúsculas. Además, considerar raíces comunes entre palabras.
  2. Como experiencia, recomendamos armar el Set de Entrenamiento supervisado, ya que es probable que la clasificación no se haga correctamente si se deja abierta al público.
  3. Claramente se observan diferencias entre los dos Set de entrenamiento utilizados.
  4. El clasificador con mayor desempeño es Stochastic Gradient Descent, lo cual se justifica con el hecho de que este clasificador es muy usado en clasificación de texto.
  5. En cambio, el con menor desempeño observado es Supor Vector Machine. El problema más probable debió ser la falta de cambio de kernel para trabajar mejor con la gran cantidad de dimensiones, por lo que el clasificador no pudo encontrar el hiperplano (o curva) que separe las clases.