This work describes the system for the normalization of tweets in Spanish designed by the Language in the Information Society (LYS) Group of the University of A Corun˜a for Tweet-Norm 2013. It is a conceptually simple and flexible system, which uses few resources and that faces the problem from a lexical point of view.
El uso del lenguaje en microtextos como los
de Twitter y los SMS, denominado texting, se
aleja mucho del esta´ndar
Asimismo, aplicar t´ecnicas de
Procesamiento del Lenguaje Natural a los millones
de tuits generados a diario ser´ıa de gran
inter´es para la inteligencia empresarial, pero las
alteraciones del lenguaje antes descritas lo
dificultan. Una solucio´n es transformar dicho
texto a lenguaje esta´ndar, es decir,
normalizarlo. Si bien existen precedentes para otros
idiomas (predominando el ingl´es)
La estructura del art´ıculo es como sigue. La Seccio´n 2 aborda la arquitectura del sistema, su funcionamiento y los recursos empleados. La Seccio´n 3 detalla los resultados obtenidos. Finalmente, la Seccio´n 4 presenta nuestras conclusiones y trabajo futuro. 2.
Buscando simplicidad y flexibilidad, optamos por una arquitectura en pipeline que nos permit´ıa integrar, eliminar e intercambiar mo´dulos de forma sencilla. Dichos mo´dulos se comunican empleando un formato de representaci´on intermedia codificado como texto y de naturaleza estructurada y jerarquizada. En este esquema un tuit esta´ formado por t´erminos y para cada t´ermino existe una serie de candidatos para su normalizaci´on.
Dado que la tarea de normalizacio´n consiste en etiquetar una palabra fuera-devocabulario (OOV, out-of-vocabulary word ) como correcta o bien proponer su forma correcta, dicha tarea puede verse como un proceso en dos fases. Primero, identificar las palabras dentro-del-vocabulario (IV, invocabulary word ) del tuit, y as´ı saber cua´les son las OOVs. Segundo, proponer la forma correcta de las OOVs detectadas, lo que a su vez implica: (a) identificar si se trata de una palabra correcta pero desconocida (que denominaremos OOVs propias) o bien de una variante l´exica; (b) en este u´ltimo caso, obtener su forma esta´ndar normalizada.
Esto nos llev´o a plantear la arquitectura general del sistema en tres etapas: (1) los tuits se tokenizan y preprocesan; (2) identificamos las IVs en base al vocabulario del sistema, obteniendo el conjunto inicial de OOVs; (3) clasificamos las OOVs en propias y variantes l´exicas, y proponemos para ´estas su forma esta´ndar normalizada, aplicando para ello una serie de procesos de normalizaci´on sobre el conjunto inicial de OOVs, obteniendo as´ı sus normalizaciones candidatas para luego elegir la ma´s adecuada.
Sobre esa arquitectura general se plantearon dos versiones del sistema (v´ease Figura 1), las cuales describimos a continuacio´n. 2.1.
En un principio el sistema se concibio´ en
torno a dos herramientas: el
preprocesador multilingu¨e Twokenize
1http://aspell.net (a) tuits Twokenize [ARK Tools] BÚSQUEDA EN DICCIONARIOS (Aspell & ad-hoc) RECONOCIMIENTO
DE ENTIDADES (diccionarios ad-hoc) no implementada IDENTIFICACIÓN DE VARIANTES LÉXICAS Y NORMALIZACIÓN no implementada
tuits normalizados (b) tuits analyze [Freeling] Diccionario SMS PROCESA. RISAS GENERACIÓN DE CANDIDATOS REPETICIONES
DIACRÍTICOS ERRS. ORTOGRÁFICOS SELEC. CANDIDATOS
tuits normalizados
Figura 1: Arquitectura del sistema: (a) planteada inicialmente; (b) implementada
Otras opciones barajadas fueron el
tokenizador gen´erico del corpus
Europarl
Finalmente, en la tercera fase del proceso clasificar´ıamos y normalizar´ıamos las OOVs.
Sin embargo, tal arquitectura no fue la que
finalmente se implement´o, siendo ´esta la que se
muestra en la parte derecha de la Figura 1.
La razo´n fue que, por un error de
interpretaci´on, cre´ımos que no se permit´ıa emplear
el mismo tipo de preprocesamiento llevado a
cabo por la organizacio´n para la creacio´n del
corpus de entrenamiento y que empleaba la
herramienta analyze de Freeling
Llegados a este punto, con el conjunto inicial de OOVs identificado, se pasa a la fase de normalizaci´on. Primero se detectan y normalizan las onomatopeyas de risas (p.ej. jajaa) usando patrones. Seguidamente se generan, de forma acumulativa, posibles normalizaciones para las OOVs remanentes en base a los mecanismos de variacio´n considerados, que describimos en la Seccio´n 2.3. Dicho proceso es iterativo y se recoge en el Algoritmo 1.
Usar una cola de prioridad (Qgen) como estructura de almacenamiento nos permite primar los candidatos segu´n sean o no IVs, lo complejo de su generacio´n, y lo frecuente y factible del mecanismo de variacio´n. Es ma´s f´acil, por ejemplo, que una OOV sea una variante por repetici´on de vocales que lo sea por repetici´on de vocales, eliminacio´n de diacr´ıticos y errores ortogra´ficos todo a la vez. De este modo el supuesto mejor candidato sera´ siempre el primero.
Finalmente, una vez generados las posibles normalizaciones de cada OOV, ´estas son normalizadas al primero, y mejor, de sus candi2Ficheros de configuraci´on en http://devel.cpl. upc.edu/freeling/svn/trunk/src/main/twitter/.
3Descubrimos despu´es que, por algu´n error, el volcado del diccionario conten´ıa u´nicamente entradas hasta la K, mientras que su web (http://www. diccionariosms.com) parece haber sido ya cerrada. datos. Aunque no lo parezca, impl´ıcitamente se esta´ realizando la mencionada clasificacio´n de las OOVs en OOVs propias, aqu´ellas normalizadas a ellas mismas por no tener candidatos mejores, y en variantes l´exicas, aqu´ellas que cuentan con otros candidatos mejores y que son normalizadas a dichos t´erminos. 2.3.
Actualmente consideramos u´nicamente tres posibles fuentes de variacio´n, que son abordadas desde una perspectiva l´exica para as´ı limitar la complejidad del sistema.
En primer lugar, la repeticio´n de caracteres. Si una OOV contiene dos o ma´s letras iguales seguidas podr´ıa ser una variante de este tipo (p.ej. besooos vs. besos). Las normalizaciones consideradas sera´n, por orden: la palabra sin repeticiones, con repeticiones de ma´ximo longitud dos, y las palabras resultantes de eliminar todas sus repeticiones excepto una, reducida a longitud dos.4
A continuacio´n, los errores en los diacr´ıticos. Cualquier OOV con vocales podr´ıa ser una variante de este tipo (p.ej. camion vs. camio´n). Se eliminan sus diacr´ıticos (de tenerlos) y se comprueba si el t´ermino resultante es una IV. Si lo es, se toma como u´nico candidato. En los otros casos se generan con Aspell sus correcciones candidatas,5 qued´andonos so´lo con aqu´ellas que difieren u´nicamente en los diacr´ıticos.
Finalmente, otros errores ortogra´ficos.
Cualquier OOV podr´ıa ser una forma mal escrita de otra palabra (p.ej. palabar vs. palabra). Los candidatos sera´n las correcciones devueltas por Aspell.
Asimismo se intent´o incorporar, sin ´exito,
un cuarto mecanismo de normalizaci´on
basado en bu´squeda fon´etica empleando el
algoritmo del meta´fono
4Asimismo, se priorizan las repeticiones de ciertas letras en base a su naturaleza y frecuencia en el diccionario. Por orden: e, o, r, l, c y n.
5Se emplean siempre simult´aneamente los suggestion modes ultra y normal de Aspell.
Algoritmo 1 Generaci´on de normalizaciones candidatas.
toov: t´ermino OOV a normalizar. gi(): funci´on generadora de normalizaciones candidatas para el fen´omeno vi, donde V = (v1, . . . , vN ) son los fen´omenos de variaci´on abordados, ordenados por precedencia y frecuencia.
apli(): funci´on booleana que detecta si un t´ermino podr´ıa ser una variante l´exica de tipo vi.
Qgen: lista de candidatos para la normalizaci´on. Actu´a a modo de cola de prioridad donde los candidatos han sido almacenados por orden de inserci´on priorizando aqu´ellos que son IVs sobre los OOVs. De este modo los candidatos IVs se situar´an en la parte anterior de la cola y los OOVs en la posterior, y a su vez, dentro de cada clase, los candidatos estar´an por orden de creaci´on, habiendo sido generados de forma acumulativa aplicando los diferentes mecanismos de normalizaci´on asociados a V. En resumen: primero, los candidatos IVs generados a partir de toov empleando g1; luego los generados empleando g2; los generados aplicando, secuencialmente, g1 y g2; los generados con g1 y g3; con g2 y g3; con g1, g2 y g3; etc.; y a continuaci´on lo mismo para los candidatos OOVs, con el propio toov en primer lugar. (*. . . sino, encolamos el nuevo candidato. *)
Por limitaciones de tiempo so´lo tenemos dos tipos de runs: (a) un baseline sin normalizar que toma directamente la salida de analyze (base ); y (b) el resultado del proceso de normalizacio´n descrito anteriormente (norm). Los resultados obtenidos se muestran en el Cuadro 1, indicando: el nu´mero de errores de alineamiento (err ), el nu´mero de OOVs normalizadas de forma correcta (pos) e incorrecta (neg ), y el accuracy, tanto el calculado mediante el script Python inicial (accupy) como con el script PHP final (accuphp).
Su rendimiento, del 33-34 %, nos situ´a a la cola de los participantes, si bien muy cerca de otros, por lo que dada la simplicidad de nuestra aproximaci´on y los pocos fen´omenos de variacio´n tratados, no es un mal resultado. 4.
E´sta ha sido nuestra primera incursi´on formal en la normalizaci´on de tuits en espan˜ol. Se trata de un sistema sencillo, que opera a nivel l´exico usando pocos recursos, y que tiene una arquitectura en pipeline que lo hace muy flexible. Su rendimiento ha sido satisfactorio a pesar de su simplicidad.
En el futuro, adema´s de abordar el resto de fuentes de variacio´n ma´s comunes, pretendemos incluir diversas mejoras: un formato de representaci´on intermedia entre mo´dulos en XML; integrar un detector del idioma y un reconocedor de entidades; emplear puntuaciones; y usar informacio´n contextual para mejorar el filtrado de candidatos.
V´eronis, J. 1999. MULTEXT-corpora. An annotated corpus for five European languages. CD-ROM. Distribido por ELRA/ELDA.