generaci´on de lenguas basada en conocimiento...

Escuela Tecnica Superior de Ingenieros

Informaticos

Universidad Politecnica de Madrid

Generacion de lenguas basada enconocimiento linguıstico

Trabajo Fin de Master

Master Universitario en Inteligencia Artificial

AUTOR: David Quesada LopezTUTOR/ES: Jesus Cardenosa Lera

Carolina Gallardo Perez

2018

i

AGRADECIMIENTOS

A mi familia. A mis amigos. A mis profesores.

ii

RESUMEN

El procesado de lenguaje natural es uno de los ambitos de la inteligencia artificialmas importante de cara a la interaccion entre personas y maquinas. Para que estainteraccion sea posible, hace falta que nuestro sistema sea capaz de comprender ellenguaje natural en un ambito concreto y que ademas pueda generar respuestas enun idioma que entienda el usuario.

En esta tesis se va a tratar sobre las aproximaciones que pueden tomarse paragenerar texto en lenguaje natural desde cualquier fuente de informacion, ya seatextual, numerica o de otro tipo. Para centrar el procesado de lenguaje en un ambitoconcreto se hara una revision del estado actual de los chatbot, un area de muchaatencion recientemente que cubre todos los aspectos del procesado de lenguaje. Paraaplicar las tecnicas estudiadas, haremos una pequena prueba de concepto con unchatbot acotado a un ambito especıfico. Con esto, se dara una idea de cuales puedenser algunas aproximaciones tanto a la comprension como a la generacion de lenguajepara resolver un problema concreto y se veran alternativas reales a la hora de crearun sistema conversacional.

iii

SUMMARY

Natural language processing is one of the most important subjects in artificialintelligence when dealing with machine person interaction. To make this interactionpossible we need our system to be able to understand natural language in a givendomain and to answer in a language that the user comprehends.

In this thesis, we will go through the techniques that can be used to generate textin natural language from any source, be it textual, numeric or other kind. We willthen focus natural language processing in the area of conversational systems. Thiskind of systems have got many attention in recent years and they serve as a greatexample of the whole process in NLP. Lastly, we will apply some of this methodsin the creation of a chatbot in a specific domain. This way, we will have an idea ofhow can natural language understanding and generation be approached.

iv

Indice

1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12. Estado del arte: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1. Natural Language Generation . . . . . . . . . . . . . . . . . . . . . . 2

2.1.1. Document Planner . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2. Microplanner . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3. Surface Realizer . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.4. Evaluacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Linguistic Descriptions of Data . . . . . . . . . . . . . . . . . . . . . 82.2.1. Computational Perceptions . . . . . . . . . . . . . . . . . . . 102.2.2. Perception Models . . . . . . . . . . . . . . . . . . . . . . . . 112.2.3. Evaluacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3. Entornos de generacion de lenguaje . . . . . . . . . . . . . . . . . . . 132.3.1. KPML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2. SimpleNLG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.3. OpenCCG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.4. rLDCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4. Sistemas conversacionales . . . . . . . . . . . . . . . . . . . . . . . . 192.4.1. Sistemas de dialogo . . . . . . . . . . . . . . . . . . . . . . . . 202.4.2. Sistemas conversacionales orientados a una funcion . . . . . . 22

2.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . 314. Hipotesis de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 335. Resolucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.1. Recopilacion de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2. Base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3. Modelo de procesado de preguntas . . . . . . . . . . . . . . . . . . . . 35

5.3.1. Gramatica libre de contexto . . . . . . . . . . . . . . . . . . . 365.3.2. Clasificacion de queries y division en entidades . . . . . . . . . 375.3.3. Conclusiones y eleccion . . . . . . . . . . . . . . . . . . . . . . 37

5.4. Preproceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4.1. Simplificacion de cadenas . . . . . . . . . . . . . . . . . . . . . 375.4.2. Tokenizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.4.3. Stopwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.5. Gramatica libre de contexto . . . . . . . . . . . . . . . . . . . . . . . 395.5.1. Producciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.5.2. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.6. Busqueda de viviendas . . . . . . . . . . . . . . . . . . . . . . . . . . 415.6.1. Recorrido del arbol de derivacion . . . . . . . . . . . . . . . . 415.6.2. Creacion de las queries . . . . . . . . . . . . . . . . . . . . . . 42

5.7. Generacion de respuestas . . . . . . . . . . . . . . . . . . . . . . . . . 435.7.1. Gramaticas de generacion . . . . . . . . . . . . . . . . . . . . 445.7.2. Redes de Markov . . . . . . . . . . . . . . . . . . . . . . . . . 46

v

5.8. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.9. Etapa final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486. Conclusiones y lıneas futuras . . . . . . . . . . . . . . . . . . . . . . . 49

vi

Indice de figuras

1. Framework de diseno de sistemas NLG propuesto por Reiter y Dale . 32. Arquitectura de LDCP . . . . . . . . . . . . . . . . . . . . . . . . . . 103. GLMP para describir la superficie de Marte [53] . . . . . . . . . . . . 124. Especificacion SPL de la frase ”La vida no es tan facil como parece” . 145. Especificacion SPL multilıngue de la frase El terremoto destruyo los

edificios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156. Elementos sintacticos de una frase que SimpleNLG permite establecer 167. Forma logica del verbo ”buy” y representacion de la frase ”Peter buys

a bike” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188. Esquema de la arquitectura de un sistema conversacional. Adaptado

de [64] para incluir los chatbots de lenguaje escrito . . . . . . . . . . 199. Ejemplo mostrado en [60] de una base de conocimiento y un sistema

de marcos para representar puntos de interes. . . . . . . . . . . . . . 2310. Posible estructura de control en base al ejemplo de marco en la figura 9 2411. Ejemplo de un etiquetado IOB en una frase. . . . . . . . . . . . . . . 2712. Ejemplo de la interfaz de busqueda de una casa a la venta en Madrid

en Idealista. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3113. Estructura de control de los estados posibles del chatbot. . . . . . . . 3614. Ejemplo del procesado de una pregunta al sistema. . . . . . . . . . . 4115. Vector generado de una derivacion. . . . . . . . . . . . . . . . . . . . 4216. Ejecucion del sistema y obtencion de una respuesta segura. . . . . . . 4717. Ejemplo de no comprension de una pregunta. . . . . . . . . . . . . . 48

1 Introduccion 1

1. Introduccion

Cuando queremos desarrollar un sistema que pueda procesar lenguaje natural,uno de los problemas mas importantes a los que solemos enfrentarnos es la depen-dencia del dominio que sufren. Estos sistemas estan estrechamente relacionados conel tipo de frases que pueden comprender y el tipo de respuestas que saben generar.Las tecnicas de comprension (NLU ) y de generacion (NLG) de lenguaje requierenun ambito bien acotado para poder realizar funciones especializadas. Esto significaque es necesario tener una idea clara de cual va a ser el tipo de lenguaje que se va aemplear para interactuar con el sistema, cual es el problema que se va a tratar y quetipo de respuestas se esperan de el. Esta es la causa de que cuando se quiere crearun sistema de procesado de lenguaje aplicado a un problema concreto, este sistematiene que ser hecho a medida para la situacion. Las tecnicas y estrategias usadaspara el procesado y la generacion de lenguaje son aproximaciones que deberan seramoldadas a nuestro caso.

La comprension y la generacion suelen formar parte de un mismo sistema si sequiere hacer el ciclo completo desde la entrada de texto hasta la salida. Las tecnicasde comprension no son las mismas que las de generacion pero en sentido inverso, yaque ambas abarcan tareas de diferente naturaleza. El procesado tiene que ver mascon comprender el que me estan diciendo, es una tarea de interpretacion, mientrasque la generacion debe elegir que informacion devolver en forma de texto, es unatarea de decision. Ambas tareas pueden aparecer juntas en un mismo sistema, comoen el caso de los sistemas conversacionales, o puede aparecer solo una de ellas, comolos sistemas que realizan busquedas especializadas en un entorno en base a unapregunta o los sistemas data2text, que generan texto en lenguaje natural a partir deuna entrada que no es textual.

Esta tesis tratara sobre la generacion de lenguaje natural, y para ejemplificar suaplicacion se creara un chatbot en un ambito acotado. Esto implica que tambiense tendra que emplear la comprension en lenguaje natural, de la cual se trataranalgunas tecnicas valoradas durante la implementacion, pero no se tratara este ambitode manera extensa en el estado del arte. En la siguiente seccion se tratara de daruna vision general del ambito de la generacion de lenguaje y un enfoque hacialos chatbots. Mas adelante, se describira una pequena prueba de concepto de unchatbot para aplicar algunas de las tecnicas vistas. Se trataran diferentes alternativasconsideradas a la hora de su creacion, como fue el proceso y que resultados se puedenextraer de el. Finalmente se extraeran las conclusiones finales de la tesis y las lıneasfuturas.

2 Estado del arte: 2

2. Estado del arte:

El area del procesado de textos en lenguaje natural ha sido un area muy activadesde mediados del siglo veinte. Este ambito comprende muchas areas populares deinvestigacion, como la generacion de textos para describir imagenes, la traduccionautomatica entre idiomas, la generacion de resumenes a partir de unos datos numeri-cos o los chatbots. El procesado de lenguage natural (NLP) se divide comunmenteen dos areas [48]: Natural Language Understanding (NLU) y Natural Language Ge-neration (NLG).

NLU es la rama de NLP que se centra en los sistemas cuya entrada son textosen lenguaje natural. La aproximacion que se sigue en este ambito es mas biende gestion: al recibir una entrada, el sistema tiene que decidir cual de lasmultiples interpretaciones que se le puede dar es la mas apropiada.

NLG se dedica a la transformacion de informacion en diferentes medios atextos en lenguaje natural que sean comprensibles. En este caso, el problemaque se afronta es el de elegir que informacion presentar y de que manerapresentarla.

El area del NLG esta subdividida a su vez en ambitos mas pequenos que secentran en problemas mas concretos: data-2-text [49] se centra en sistemas de NLGcuya entrada son datos numericos con origen en sensores o tablas; NLG interactivo[56] se centra en la generacion de texto mediante una interaccion entre el interlo-cutor humano y el sistema, ya sea esta por medio de texto o de datos numericosintroducidos; o NLG narrativo que se centra en la generacion de textos literariosen prosa o en verso [9]. Existe tambien el area de Linguistic Descriptions of Data,que ha coexistido con el data-to-text NLG sin mucha interaccion entre ambos hastahace poco tiempo [29]. Tambien existen ambitos complejos que mezclan tanto NLUcomo NLG, como en el caso de los traductores automaticos y los chatbots [32]. NLGy NLU estan estrechamente relacionadas, pero sus diferencias van mas alla de queel objetivo de una es el inverso de la otra.

2.1. Natural Language GenerationA pesar de que el area del NLG lleva muchos siendo desarrollada, no hay un

estandar extendido en la comunidad y cuando se presenta un problema de NLG sesuele aplicar una solucion hecha a medida. Aun ası, una de las arquitecturas masextendidas y reconocidas es la presentada por Reiter y Dale [48].

Esta arquitectura establece un pipeline con las tareas que los autores consideranindispensables a la hora de crear un sistema de NLG de cualquier subtipo. El procesose distribuye en tres fases desde la entrada de una serie de datos del tipo que sean(textuales, numericos, graficos, ...) hasta la creacion de un texto sobre ellos de lascaracterısticas requeridas. De este modo, las tareas iniciales estan mas relacionadascon que informacion se va a transmitir y las finales tratan el como de manera directa,


Fig. 1: Framework de diseno de sistemas NLG propuesto por Reiter y Dale

eligiendo las expresiones que se van a usar y en que orden colocarlas. Debido a esto,los modulos que se corresponden con estas tareas iniciales suelen ser los que hayque crear a medida para cada sistema, de tal forma que se adapte la extraccion deinformacion a nuestro dominio concreto y se defina una estructura del texto acordecon nuestro corpus o con nuestras necesidades, y los modulos finales de realizacion deltexto final se pueden hacer con metodos y tecnicas que se estudian con independenciadel problema a mano.

2.1.1. Document Planner

El primer modulo de esta arquitectura es el llamado Document Planner. Este secentra en los primeros pasos de identificar como se van a tratar los datos de entrada,que se va a decir sobre ellos, y que estructura va a seguir el documento final.

Determinacion del contenido. Esta subtarea se corresponde con el primerpaso de decidir a partir de los datos de entrada que informacion es relevan-te mencionar. Normalmente, estos contienen mucha mas informacion de laque podemos comunicar o informacion que es redundante. Como ejemplo, unsistema meteorologico que recibe de entrada una tabla con las velocidades ydirecciones del viento a diferentes horas del dıa debe decidir que momentostratar en el informe meteorologico: tiene mas sentido hablar sobre los momen-tos en los que habra cambios en la direccion y velocidad del viento que tratarsobre cuando se mantiene constante [50]. Esta subtarea esta profundamenterelacionada con el dominio de la aplicacion, ya que el analisis que tenemos que


realizar viene determinado por el tipo de entrada del que disponemos.

Estructuracion del texto. Una vez decidido que informacion se va a trans-mitir, hay que ver en que orden se va a presentar esta informacion. En elejemplo meteorologico anterior, probablemente sea adecuado ir desde una des-cripcion general del tiempo a primera hora del dıa hasta la noche, marcando sifuese necesario horas clave como el mediodıa. Esta ordenacion se ve claramen-te restringida dependiendo de las necesidades del dominio, y en las ocasionesen las que se disponga de un corpus de textos previos hechos por humanoseste punto suele incluır un profundo analisis de la estructura de estos. Esteproceso ha sido realizado tradicionalmente de forma manual, pero tambien sehan probado aproximaciones desde la aplicacion de la retorical structure theory(RST) [39] para generar estructuras de textos por medio de reglas basadas enel domino, que consigan objetivos concretos como la facilidad de comprension[62], o la aplicacion de tecnicas de aprendizaje automatico para inferir posiblesestructuras [1].

2.1.2. Microplanner

Tras este proceso se obtiene una planificacion del documento a gran escala, porlo que el siguiente paso es el de decidir como van a ser las frases concretas que sevan a utilizar en cada parrafo para transmitir la informacion que se ha decididopreviamente. Las subtareas que lo componen no tienen un orden fijo, y en ocasionesel resultado de una de ellas es util para otra, por lo que se realizaran segun requieranuestro dominio o nuestra implementacion.

Agregacion de frases. Cuando generamos el texto que tenemos planificadodesde la fase anterior, no siempre es necesario generar frases diferentes paracada fragmento de informacion que queremos transmitir. En muchas ocasionesel resultado es mas fluido y comprensible si combinamos varios mensajes en unasola frase [17]. El objetivo de esta agregacion puede verse como una reduccionde la redundancia final de la frase o como la reordenacion estructural del textopara facilitar su lectura y comprension. El problema es que estos objetivos sondependientes del dominio en el que nos encontremos: decir en tres oracionesseguidas la temperatura ambiente en un intervalo de tres horas cuando estasolo ha variado unos pocos grados puede ser redundante para una previsiontemporal de todo el dıa, pero puede no serlo para una prevision temporal deun intervalo concreto de 5 horas del dıa. Por este motivo, la creacion de reglaspara la agregacion de frases tradicionalmente se ha hecho a medida para cadadominio o aplicacion [17]. Sin embargo, se ha avanzado gradualmente hacia lageneracion automatica de estas reglas de agregacion a partir de un corpus delque sacarlas en base a la similaridad de unas frases y otras [11]. Tambien se hatratado el problema como uno de optimizacion, clasificando frases en parejaspara determinar si deberıan ser agregadas entre sı o no segun su similaridad[2].


Lexicalizacion. Esta es la fase del proceso en la que se empieza a generartexto en lenguaje natural a partir de las estructuras que tenemos de etapasanteriores. La dificultad de esta generacion esta estrechamente relacionada conla cantidad de alternativas que nuestro sistema es capaz de manejar para unmismo suceso: en un sistema sencillo de plantillas se puede hacer una simpleasignacion de un suceso a una expresion, pero la lexicalizacion se complicasi queremos que nuestro sistema sea capaz de generar varias frases diferentesatendiendo a matices, por ejemplo de quien lo va a leer [62] o de que expre-siones son menos ambiguas [50]. La complejidad buscada en la lexicalizacionviene muchas veces dada por el dominio en el que se trabaja: si se tienen yaestablecidas una serie de expresiones con un significado claro, normalmentesacada de un corpus previo o de expertos en la materia, es muy probable queen un dominio donde se quiere maximizar la claridad del texto se usen estasexpresiones, pero si para un mismo suceso existen varias formas aceptadas deexpresarlo que sean sinonimas entre sı y la variedad lexica es apreciada, habraque buscar matices que las distingan a un nivel mas profundo.

Generacion de referencias. Esta parte del proceso se centra en la generacionde expresiones para referirse a entidades o sucesos concretos y diferenciarlosdel resto. Esta subtarea, conocida en la literatura como Referring ExpressionGeneration (REG), es una de las que mas pueden abstraerse para poder ser tra-tada por separado, una de las razones por la cual ha recibido bastante atencioncomo subcampo dentro del NLG [34]. Un caso representativo que esta siendoinvestigado en gran medida es la generacion de textos que describan imagenesde manera automatica. En estos casos, es necesario reconocer los objetos oseres que aparezcan en la imagen y diferenciarlos claramente unos de otros aldescribir la escena. En la mayorıa de sistemas de NLG suele haber un modulode REG con mayor o menor nivel de sofisticacion [40]. El problema de REGsuele ser abordado desde el punto de vista de que caracterısticas posee unaentidad que puedan diferenciarla unıvocamente de otras entidades similares,por lo que los algoritmos clasicos consisten en busquedas heurısticas en el es-pacio de soluciones para encontrar este conjunto de caracterısticas: realizandobusquedas exhaustivas del conjunto mas pequeno posible (Full Brevity) [16],seleccionando incrementalmente (greedy forward) propiedades que reduzcan enmayor medida la entropıa [16] o seleccionando incrementalmente propiedadesen base a un criterio de importancia relacionado con el dominio [15]. En losultimos anos se ha invertido mucho esfuerzo en desarrollar nuevos algoritmosde REG desde puntos de vista nuevos de busquedas en grafos, satisfaccion derestricciones, probabilıstico o con representaciones del conocimiento modernas,ademas de sus diferentes metodos de evaluacion de las alternativas generadas[34].


2.1.3. Surface Realizer

Una vez que ya hemos comletado las fases anteriores tenemos la estructura deltexto que vamos a generar y las frases que vamos a utilizar, hay que generar las ora-ciones en lenguaje natural finales del texto. Aunque hayamos decidido ya como van aser estas oraciones en el microplanner, necesitamos una serie de reglas gramaticalespara generar textos que sean sintactica y morfologicamente correctos. Hay un grannumero de formas diferentes de tratar esta tarea [22], de las cuales resaltaremos:

Plantillas. Las plantillas son un metodo muy eficaz en dominios muy con-cretos donde la variabilidad de los textos a generar es muy baja [57]. Usarplantillas hace que los textos generados tengan una estructura muy controladadonde no se permita la generacion de frases con errores gramaticales. Depen-diendo de la sofisticacion de estas, se pueden generar diferentes reglas parala introduccion de datos en ellas o la variacion de las plantillas en base a loslectores [50]. El principal problema de las plantillas tradicionalmente ha sidoque su creacion es un proceso costoso hecho a mano, aunque hay casos en losque se generan estas plantillas automaticamente a partir de un corpus [33].Ademas, en entornos mas abiertos donde las frases a generar no sean siempreiguales con diferentes datos de entrada los metodos con plantillas no escalanbien. Aun ası, en los dominios donde son aplicables consiguen resultados muybuenos, en ocasiones equiparables con textos escritos por humanos.

Sistemas basados en gramaticas. A lo largo de los anos han ido apare-ciendo sistemas de uso general independientes del contexto que permiten lageneracion de lenguaje natural. Estos suelen basarse en una gramatica escritaa mano donde establecen la estructura de las oraciones del lenguaje con elque se trabaja. Esta gramatica es la que se usa para generar frases en basea los componentes que queremos que tenga, pero es necesario establecer re-glas manuales para concretar que frase generar en un contexto donde variasson posibles, por ejemplo, reordenando los complementos verbales. Es por estoque estos sistemas suelen requerir una entrada muy detallada en el lenguajede programacion que usen, por lo que requieren un tiempo para adaptarse aellos. Como estos sistemas tienen su gramatica hecha a medida para el idiomacon el que se crearon, es necesario adaptarlos si se quieren usar en idiomas dis-tintos [55]. Algunos ejemplos de estos sistemas que se trataran mas adelanteson KMPL [3] o SimpleNLG [23].

Sistemas basados en gramaticas y metodos estadısticos. La base de estetipo de sistemas sigue siendo una gramatica hecha a mano para generar frasesa partir de la entrada proporcionada, pero en estos casos parte de las reglas quese usan para elegir entre diferentes frases posibles dada una entrada se sacan deun corpus de previo de manera automatica y se usan metodos estadısticos paraelegir entre las posibilidades disponibles. La primera aproximacion que se hizoa este tipo de sistemas fue Nitrogen / HALogen [35], donde se parte de la basede una pequena gramatica hecha a mano de la que se genera una serie de frases


en forma de arboles de entre las que se hace un ranking basado en un corpusy n-gramas para seleccionar la mas apropiada. Otra aproximacion se basa enguiar la generacion de frases desde la gramatica hasta un candidato “optimo”en vez de generar una gran cantidad de ellos y filtrar el mas adecuado. Unejemplo de esta aproximacion es pCRU [5], donde se utiliza un corpus paraderivar a partir de una gramatica libre de contexto la frase mas adecuada.Tambien hay casos en los que tanto la generacion de frases como el filtradode las mismas se realiza de manera atomatica, como en el caso de OpenCCG[61], un generador de texto open source que utiliza un corpus para generaruna serie de reglas combinatorias para la creacion de frases con la gramaticay despues realiza un re-ranking automatico. Ultimamente, la investigacion seha centrado mas en estos metodos relacionados con machine learning que conlas tradicionales plantillas, siendo aproximaciones como SimpleNLG tambienbastante populares por su facilidad de uso.

Lo mas comun es que, en los casos de la aplicacion de este framework [13], nose sigan en orden todos los pasos establecidos, se mezclen unos pasos con otros o sejunte este framework con otro distinto. Su idea principal no es mostrar un caminoestricto hacia la solucion de problemas de NLG, sino que se adapte esta arquitecturaa las necesidades de cada situacion.

Desde la creacion de los primeros sistemas de NLG por plantillas, estos han sidoaplicados a un gran numero de ambitos especializados diferentes, como en el casode las previsiones temporales con FoG [24] o SumTime-Mousam[50], la generacionde texto en casos medicos concretos como [45], sistemas de ayuda a la gestion delconsumo electrico [13], generacion de descripciones del funcionamiento de sistemasen un intervalo de tiempo [65], etc.

En el caso de estos sistemas, su aplicacion en ambitos tan especıficos da pie aque esta arquitectura por plantillas sea muy potente. Esto ocurre porque el rango defrases a generar esta bien definido y debe cenirse a un esquema que es normalmenteproporcionado por un corpus inicial de textos, aunque tambien hay casos en los queno se tenıa un corpus inicial [65]. Es un tema discutido en la literatura [18, 51]el si los sistemas tradicionales de NLG son o no mas eficaces que los basados enplantillas. Se discute sobre si uno de los dos es mas facil de mantener a largo plazoo si genera textos mejor estructurados y de mas calidad, pero no esta claro que unaaproximacion sea mejor que la otra.

2.1.4. Evaluacion

La creacion de estos sistemas tiene en comun que son proyectos de ingenierıadel software de un tamano considerable. Por ello, uno de los puntos que son demayor importancia es la evaluacion de los textos que resultan de ellos. Muchosinvestigadores dedican un gran esfuerzo a comprobar que sus textos automatizadosson igual o mas comprensibles que los hechos a mano. Hay bastante debate entornoa como realizar evaluaciones de sistemas de NLG, pero podemos distinguir dos tiposde evaluaciones en la literatura [4]: las llevadas a cabo con evaluadores humanos y


las realizadas por metricas automaticas. En los casos en los que se tienen evaluadoreshumanos [50, 65], esta evaluacion de lleva a cabo con los autores originales de lostextos que se esta intentando automatizar (si los hubiera) y con los lectores a los quevan dirigidos dichos textos con cuestionarios que buscan obtener notas numericassobre su facilidad de comprension, sobre si los terminos utilizados son del agradodel lector o sobre si se trata bien la ambiguedad, entre otros. Esto se conoce comoevaluacion intrınseca [27], y da una idea de la calidad de los textos que genera elsistema. La evaluacion extrınseca se realiza para ver como de efectivo es el sistema,ya sea para ver el impacto de los textos generados en los lectores [52, 63], la velocidada la que se leen los textos [62], o si los idiolectos usados por algunos autores ayudano dificultan la comprension final [50]. Por otro lado, la evaluacion por medio demetricas se basa en la comparacion de los textos generados con los textos de uncorpus hecho por autores humanos antes de la implementacion del sistema NLG.Tres de las metricas mas conocidas son: Bleu [44], Nist MT [20] y Rouge [38]. Estas,inicialmente ideadas para comprobar la bondad de las traducciones automaticas, sebasan en comparar la similitud de los textos producidos por sistemas de NLG concorpus de textos generados por humanos previos a la implementacion del sistema:a mayor similaridad con el corpus, de mayor calidad son los textos generados. Deentre ellos, Bleu es el que parece tener mas correlacion entre su ındice de bondad ylas evaluaciones por humanos [4], aunque no en todos los casos.

Estos metodos son faciles de aplicar y mucho mas rapidos que hacer evaluacionescon humanos, pero sufren de dos problemas: su aplicacion solo es posible cuandose dispone de un corpus, lo cual no siempre ocurre, y sus metricas solo miden lasimilaridad entre los textos del corpus y los generados. El consenso general es querealizar evaluaciones con expertos humanos ofrece una informacion de mas calidadacerca de lo bueno que es el sistema, pero no siempre es facil ni barato juntar ungrupo de expertos, y su evaluacion es solo valida en el momento en el que se realiza.En contraposicion, las evaluaciones automaticas ayudan a ver el progreso de unsistema en el tiempo de manera rapida y barata, pero no son un medio adecuadopara medir la calidad final del sistema en comparacion con otros.

Finalmente, cabe destacar que los sistemas de NLG suelen ser sistemas de undominio muy especializados y que generan textos que pueden ser intercambiados conotros hechos por humanos sin mayor problema. Sin embargo, la creacion de dichossistemas deriva en proyectos grandes en los que normalmente se parte de una basemeramente teorica: la explicacion de las implementaciones detras de los sistemas deNLG de la literatura es, cuanto menos, vaga. Por tanto, si se quiere implementar unsistema de este tipo, se tendra que partir desde cero o reusar alguno de los frameworkde uso general de NLG que existen, de los cuales se hablara mas adelante.

2.2. Linguistic Descriptions of DataAparte de las aproximaciones mencionadas anteriormente del Surface Realizer en

NLG, existe tambien el area de LDD como opcion adicional, aunque ha convividobastante tiempo con el NLG sin mucha interaccion entre ambas a pesar de que


investigan temas similares. La idea inicial de LDD aparece a mediados de los 90,cuando se trata de juntar el area de la logica borrosa con la generacion de lenguaje.Esto se presenta dentro del paradigma de Computing with Words (CWW), dondela informacion que queremos tratar se encuentra en forma de textos y no de maneranumerica. Ademas, el lenguaje natural acepta bien el uso de inexactitudes a la horade presentar informacion, por lo que la logica borrosa es aplicable en estos casos.

Uno de los primeros y el que sento las bases de lo que se usarıa mas adelante fueZadeh [66]. La idea principal de su trabajo se basa en construir resumenes liguısticosa partir de unos cuantificadores borrosos que son los que contienen la informacionque se quiere transmitir. Por ejemplo, de la formula “Q of X are A”, se puede sacarla frase “Most of the days of the week are rainy”, donde el cuantificador borrosoQ contiene la informacion extraıda de los datos de entrada, X define el elementodel que se esta hablando y A constituye la caracterıstica que se esta resumiendoen el conjunto total [13]. Este tipo de formula, protoform en la literatura, son unade las bases que permiten la creacion de frameworks de LDD. Sin embargo, comoapunta Kacprzyk [29], hay una escasez de estos protoforms y la creacion de nuevosy mas complejos darıa mas capacidad a los sistemas de LDD para generar textosmas complejos.

En LDD tampoco hay un consenso en cuanto a como crear sistemas para resolverproblemas concretos. Sin embargo, el objetivo que hay que cumplir es el de realizarresumenes linguısticos de unos datos de entrada por medio de cuantificadores borro-sos. Esta tarea es parecida a la de concretar el que se va a decir y el como se va a decirde NLG. En este caso y basandonos en el ejemplo expuesto antes, necesitamos unaserie de cuantificadores borrosos que se encarguen de exponer la informacion, comoen el caso de “most”, “all of ”, “some”, y una serie de variables que se refieran alentorno en el que estamos, en nuestro ejemplo de la meteorologıa “rainy”, “cloudy”o “sunny”. Todos estos elementos en conjunto forman sentences, que pueden ser detipo-I como en el caso de “Most of the days of the week are rainy” o pueden ser detipo-II si se les anade una segunda variable o una referencia temporal a informacionmencionada antes, como en “Most of the days of the week, as in the last one, arerainy and cold” [42].

Como la implementacion de estas “quantified sentences” esta basada en las tecni-cas de la logica borrosa, su creacion puede verse como un problema de busquedaen un espacio de soluciones: dada la estructura de tipo-I “Q of X are A”, hay queasignar un valor a la variable A para saber que es lo que se va a hablar en la frasey hay que dar valores concretos a Q, dentro de un conjunto cerrado borroso, y aX, de manera que generaremos una cierta cantidad de frases y nos quedaremos conlas que maximicen un criterio de evaluacion, teniendo en cuenta aspectos como laveracidad de la frase generada, su comprensibilidad o su redundancia con frases an-teriores. Este funcionamiento hace que la aproximacion de LDD este mas basada enteorıa matematica y de machine learning que la de NLG, aunque a la hora de aplicarambas los resultados son bastante parecidos y ultimamente ambas aproximacionesse han acercado en cuestion de las tecnicas y metodos empleados. La generacion defrases en LDD, como apunta Kacprzyk [29], se asemeja a los sistemas de NLG que


emplean plantillas, aunque el alude a los protoforms como “metatemplates”, dadoque tienen una capacidad de generacion mas grande que las plantillas tıpicas deNLG. Es importante resaltar en este punto que, aunque este esquema tiene su in-vestigacion sobre la base del ingles, es posible usarlo tambien en otros idiomas comoel espanol [47].

De la misma forma que ocurre en NLG, tampoco existe un framework en LDDque sea el estandar a usar de cara a un problema. Recientemente, se ha usado elmodelo de Linguistic Descriptions of Complex Phenomena (LDCP) para solucionarvarios tipos de problemas diferentes, como la generacion de textos para el ahorro deenergıa [13], la generacion de textos describiendo la actividad de uso de un simuladorde conduccion[21] o la generacion de informes en un entorno de Big Data en base alusuario al que va dirigido [12], por lo que esta aproximacion es lo mas cercano a unframework general que hay en el ambito.

Fig. 2: Arquitectura de LDCP

La arquitectura de LDCP se basa principalmente en dos componentes: el Gra-nular Linguistic Model of Phenomena (GLMP) y la plantilla del informe. El primerpaso del proceso es el que se corresponderıa con el document planning en cuestionesde la determinacion del contenido y del filtrado inicial de los datos de entrada delmodelo NLG de Reiter y Dale. El modulo del GLMP es el encargado del uso de losconjuntos borrosos para la interpretacion de los datos de entrada y su aplicacionpara completar los informes. El ultimo paso de generacion del informe coincidirıacon la parte de microplanner y realizacion linguıstica. Ambos modelos compartenpuntos en comun, pero LDCP se basa mas en la interpretacion de los datos de en-trada con el modulo de GLMP y se apoya en las plantillas de generacion que hayque completar.

El funcionamiento del GLMP esta basado en dos componentes, las computationalperceptions (CP) y los perception models (PM)[12].

2.2.1. Computational Perceptions

Son pequenos fragmentos linguısticos que explican con diferente nivel de detalleuna parte del suceso del que se habla. Estan formados por la tupla (A, W, R) donde:

A = (a1, a2, ..., an) es un vector de n cuantificadores que representen todo eldominio del que se esta hablando, en el ejemplo previo serıa el caso de (none,some, most, all).


W = (w1, w2, ..., wn) es un vector de los grados de validez en [0, 1] de cada unode los cuantificadores anteriores asignado en el contexto de cada CP. La sumatotal de todos debe ser 1.

R = (r1, r2, ..., rn) es un vector que indica en nivel de relevancia en [0, 1] decada uno de los cuantificadores. El nivel de relevancia indica, en el contexto dela CP, que cuantificadores son mas importantes a la hora de ser interpretadospor el lector. En este caso, la suma total no tiene por que sumar 1.

2.2.2. Perception Models

Son nodos que reciben una o mas CP’s y mediante una funcion de agregaciongeneran CP’s de un mayor nivel. Los PM’s son los puntos donde se genera el textoque constituye las CP’s y por consiguiente el texto final del sistema. Las PM estancompuestas por la tupla (U, y, g, T ) donde:

U = (u1, u2, ..., un) es un vector de n CPs de entrada. En las PM de primernivel (1PM) U es un vector numerico con datos procedentes de alguna fuente,como sensores o tablas.

y = (Ay, Wy, Ry) es la CP resultante.

g es la funcion de agregacion utilizada para generar y a partir de las CP deentrada U . Para las 1PM, se usan funciones de pertenencia triangulares otrapezoidales normalmente [41].

T es un algoritmo de generacion de texto. En los casos mas simples, se tratade plantillas en las que se introducen los cuantificadores mas adecuados segunlas CPs agregadas.

Los trabajos que implementan este modelo son bastante precisos en cuanto acomo estan implementadas sus GLMP’s y las funciones de agregacion que constitu-yen cada PM. Esto es uno de los puntos de mayor diferencia con respecto a NLG,donde las implementaciones del Surface Realizer son bastante vagas, centrandosemas en el proceso de ingenierıa del software y en el modelo seguido.

(Otras aproximaciones a la generacion de quantified sentences. Prog. evolutiva?Gramaticas?)

2.2.3. Evaluacion

Dado que la aproximacion inicialmente es desde la generacion de multiples frasesa partir de las variables y las protoformas disponibles en cada PM, se necesitanmetricas de evaluacion para ver cual de las frases generadas es mas adecuada quelas demas. Estas metricas tambien pueden ser interpretadas como una medida de lobien que cumplen su funcion los textos generados por el sistema, en contraposiciona la evaluacion humana llevada a cabo en NLG. Algunos de los criterios utilizadosson [30] [12]:


Fig. 3: GLMP para describir la superficie de Marte [53]

Grado de veracidad. Al elegir entre distintos cuantificadores borrosos, enbase a los datos de entrada unos seran mas ciertos que otros conforme a lo quedicten las funciones de pertenencia y de agregacion de las PM. La veracidadviene representada explıcitamente en las CP.

Grado de relevancia. Algunos cuantificadores borrosos son mas relevantespara los lectores de los textos finales en determinados dominios, por lo quepuede ser preferible una frase con un cuantificador que, aunque sea menosadecuado que otro en funcion de los datos, sea mas importante para los lectores.La relevancia viene representada tambien de manera explıcita en las CP.

Longitud del texto. En base a lo largo que se quiere que sea el texto final,puede ser preferible meter mas informacion en una CP de mayor nivel quedividirlo en dos CPs de menor nivel.

Grado de cobertura. Conforme limitamos el tamano de los textos a generar,limitamos tambien la cantidad de informacion que transmitimos con ellos. Siexigimos que los textos generados sean muy cortos, tendremos que dejar fueraCPs que cubran partes del texto que consideremos menos relevantes.

Grado de borrosidad. Conforme se van anadiendo mas cuantificadores bo-rrosos al texto en vez de datos exactos, el resultado tiende a ser cada vez mascierto en cuanto a la veracidad de la informacion transmitida, pero cada vez esmas difıcil de interpretar al ser mas inexacto. Por ejemplo, “Most of the days


during summer will be rather cold” es cierto para muchos valores distintos dedıas y temperaturas, pero frases como “Most of the days during summer willhave temperatures around 33 degrees celsius” son menos ambiguas y tienen ungrado de veracidad menor.

Ajustando la relevancia que le damos a cada uno de estos parametros, o cualesde ellos empleamos, modificaremos el funcionamiento de nuestro sistema LDD y porconsiguiente los textos que obtendremos.

Ademas, la evaluacion final de los textos se esta empezando a hacer con evalua-cion humana como en NLG [21], por medio de cuestionarios para evaluar puntos queno pueden ser medidos con metricas automaticas como lo bien que se entienden losresumenes generados, las palabras que cambiarıan los previos escritores de dichosresumenes o las preferencias de los lectores entre los textos previos a la implemen-tacion del sistema y los generados despues. Este tipo de evaluacion, aunque mascostosa, da una idea clara de la calidad de los textos del sistema y de que elementoshabrıa que mejorar en caso de un rendimiento suboptimo.

2.3. Entornos de generacion de lenguajeComo comentabamos anteriormente, a la hora de llevar a cabo la tarea del surface

realizer existen dos aproximaciones comunes: la creacion de un generador de lenguajea medida, como en el caso de las plantillas o de sistemas con su propio generador congramaticas, o emplear un entorno de uso general de generacion de lenguaje. Estosentornos suelen ser aplicables a gran variedad de dominios, pero tambien suelentener una sintaxis estricta para poder afrontar el problema de la ambiguedad a lahora de generar frases. Esta sintaxis es diferente de un entorno a otro y se requierede una buena documentacion para poder empezar a familiarizarse con ella.

2.3.1. KPML

Uno de los primeros entornos de generacion de lenguaje que aparecieron fueKPML, desarrollado por Bateman en 1997 [3]. La idea de este entorno fue concebidaen un principio como un entorno multilinguıstico, donde fuese posible representardiferentes idiomas sin necesidad de generar textos y despues traducirlos. Este entornoproporciona dos modos de uso: por una parte ofrece gramaticas de varios idiomas yun sistema de caja negra, de tal forma que es posible utilizarlo como un modulo alque se le hacen queries con las especificaciones semanticas de las frases que se van agenerar, y por otra parte proporciona una herramienta con la que poder crear nuestrapropia gramatica y diccionario adaptado a nuestro ambito. Esta ultima herramientaes util a la hora de generar nuestros propios recursos lexicos y es necesaria si lagramatica de ambito general y el diccionario que se distribuyen con KPML no sonsuficientes para el sistema que queramos desarrollar. Para que KPML pueda generartexto, ademas de una gramatica es necesario proporcionarle una entrada semanticacon la especificacion de dicha frase en Sentence Plan Language (SPL) [31]. Lasespecificaciones con SPL utilizan una jerarquıa de tipos semanticos llamada Upper


Model. Estos tipos semanticos son los que permiten acotar el dominio de la gramaticaa un ambito especıfico.

Fig. 4: Especificacion SPL de la frase ”La vida no es tan facil como parece”

En la especificacion SPL descrita en la Fig. 4, los tipos semanticos en este casoserıan Property-Ascription, Thing o Quality. Estos tipos tendran unas propiedadesdiferentes y generaran estructuras distintas dependiendo de la gramatica que seuse. Ası mismo, los tipos que definamos los podemos adecuar al tipo de frases quequeremos generar en nuestro sistema. Los elementos semanticos de la frase vienendefinidos como variables, en este caso LIFE, EASY y SEEM, las cuales pertenecena un tipo semantico y heredan sus propiedades. De estas propiedades, :lex es la queotorga una raız concreta a los elementos para que puedan ser conjugados o flexiona-dos. El nucleo de generacion de frases de KPML esta programado en ANSI standardCommon Lisp, y este funciona construyendo una red a partir de la gramatica pro-porcionada. Moviendose en esta red de izquierda a derecha se genera texto para cadaelemento de la especificacion. Los nodos de la red representan disyunciones en loselementos a generar. Estas disyunciones requieren un modulo de decision para elegirla definicion final de cada elemento gramatical. Estas decisiones solo se toman unavez para cada elemento, sin back tracking, y la eleccion de un elemento puede traerconsigo restricciones para el resto de elementos.

Uno de los puntos que hacen a KPML diferente del resto de entornos de gene-racion es su capacidad para la multilingualidad. Si se le proporcionan al entornomultiples gramaticas en diferentes idiomas, este permite la generacion de textos envarias lenguas. El problema es que es difıcil que la representacion SPL sea la mismapara todas las gramaticas, ya que los mismos verbos en diferentes idiomas pueden


comportarse de manera distinta y requerir diferentes atributos en sus tipos semanti-cos. En estos casos, es comun que las redes de las gramaticas de dos idiomas sesuperpongan en algunos puntos, permitiendo similitudes en la representacion SPLconjunta de una frase, pero necesitando diferenciarse.

Fig. 5: Especificacion SPL multilıngue de la frase El terremoto destruyo los edificios

En el ejemplo multilıngue de la Fig. 5, en ingles el terremoto es el sujeto de lafrase y el que destruye los edificios, mientras que en japones el sujeto es el edificioy es el que es derrumbado por el terremoto. Ambos sustantivos, el terremoto y eledificio, son variables que pueden ser reutilizadas en la especificacion de las frases ya las que se les pueden anadir atributos, pero ambos idiomas tienen formas no muyrelacionadas entre sı de representar un mismo suceso. En idiomas mas cercanos entresı, la cantidad de informacion comun es mayor y necesita menos diferenciacion.

2.3.2. SimpleNLG

Este motor de generacion de lenguaje fue creado en 2009 con el objetivo deservir como entorno de generacion multiproposito especialmente para la realizacionde resumenes data-to-text de grandes cantidades de datos numericos teniendo encuenta las necesidades del lenguaje que cada dominio concreto puede tener [23].SimpleNLG esta codificado como una librerıa de Java, de tal forma que la creacionde un modulo de generacion de lenguaje pueda ser un proceso accesible a cualquierproyecto. Para crear frases con SimpleNLG, el elemento que funciona como unaoracion es SPhraseSpec, al cual se le van estableciendo en sus atributos los distintoselementos sintacticos que queremos que tenga la frase. Uno de los objetivos de esteentorno es permitir la facilidad de generar texto “enlatado”, inmutable dentro de lasfrases, de manera que las partes de las frases que sean escritas siempre igual dada unaentrada puedan establecerse de este modo invariablemente y aquellas otras partesque requieran mas flexibilidad puedan usar la aproximacion anterior. Esto implicaque tanto frases enteras como complementos de estas pueden ser indicados comotexto enlatado.

Como en todos los entornos de NLG, para que la generacion de texto funcionees necesaria una serie de recursos lexicos ademas de las reglas de generacion. Sim-pleNLG tiene un diccionario por defecto para permitir la flexion de las palabras enfuncion de las caracterısticas que se les den, como el numero o el tiempo verbal. Estediccionario, escrito en XML, puede ser modificado o sustituido por otros, como el


Fig. 6: Elementos sintacticos de una frase que SimpleNLG permite establecer

NIH Specialist Lexicon 1, mas orientado al dominio medico y con mayor coberturageneral. Para crear una estructura sintactica completa, hay que generar los elemen-tos sintacticos que necesitemos, asignar sus atributos y combinar estos elementosentre sı con las operaciones que ofrece la interfaz. Al generar una frase, lo mas pro-bable es que haya varias especificaciones para ella dependiendo de como se convienenunos elementos con otros o de como se declaren los atributos de los mismos. Tras ladeclaracion de la estructura sintactica, esta se pasa al lineariser, el cual recorre loscomponentes de la oracion generando las flexiones adecuadas, decidiendo el ordende los complementos y aplicando la puntuacion necesaria. La generacion de textoa partir de los componentes esta pensada para que sea robusta, de tal forma quegenere texto aun si hubiese problemas con la estructura sintactica.

SPhraseSpec p = n l g f a c t o r y . c r ea teC lause ( ) ;p . s e tSub j e c t ( ”Mary” ) ;p . setVerb ( ” chase ” ) ;p . s e tObjec t ( ” the monkey” ) ;// Mary chases the monkeyp . se tFeature ( Feature .TENSE, Tense .PAST) ;// Mary chased the monkeyp . se tFeature ( Feature .NEGATED, true ) ;// Mary didn ’ t chase the monkeyp . addComplement ( ” very qu i ck ly ” ) ;// Mary didn ’ t chase the monkey very q u i c k l ySt r ing output = r e a l i s e r . r e a l i s e S e n t e n c e (p ) ;

SimpleNLG es un generador de texto facil de usar pero menos potente que otrosgeneradores como KPML, sin embargo una de sus principales ventajas es que esta encontinuo desarrollo 2. Su comunidad sigue sacando versiones nuevas y aplicandolo en

1 https://lexsrv3.nlm.nih.gov/LexSysGroup/Projects/lexicon/current/web/2 https://github.com/simplenlg/simplenlg


nuevos proyectos. Aunque su aplicacion objetivo no sean sistemas de NLG complejos,cumple su funcion de servir como modulo de generacion de lenguaje en aplicacionesque lo requieran. Ademas, un ultimo punto importante es el esfuerzo que ha puestoesta comunidad en sacar versiones de SimpleNLG en idiomas distintos del ingles,como frances, aleman, italiano y espanol [55].

2.3.3. OpenCCG

Este es otro generador implementado como un paquete de Java pero, a diferenciade SimpleNLG, utiliza un esquema basado en las Combinatory Categorial Grammars(CCG) de Steedman para la generacion de lenguaje [61]. Estas gramaticas vienendefinidas por un diccionario cuyas entradas son elementos lexicos pertenecientes adistintas categorıas en los cuales se establece los atributos que pueden tener. Unarepresentacion de los elementos de la frase “A musician that Bob saw” podrıa ser:

a . a :− np/nb . music ian :− nc . that :− (n\n )/( s | np)d . Bob :− npe . saw :− s \np/np

En el ejemplo de elementos lexicos anterior, cada elemento tiene definida unacategorıa, n o np en este caso. Las barras indican si el elemento tiene atributos ala izquierda (\) o a la derecha (/). Este diccionario en combinacion con una seriede reglas de derivacion que combinen las categorıas permite emplear las CCG pararealizar parsing de oraciones e identificar los componentes de los mismos. A la horade la generacion de lenguaje, para decidir la posicion de los elementos de la frasesi hay varias opciones utiliza una aproximacion estadıstica en base al corpus dederivaciones que tenga. OpenCCG se baso en el corpus de derivaciones sacadas delPenn Treebank [26] para crear la gramatica de uso general que tiene por defecto. Sise quiere crear o modificar la gramatica existente, aunque el entorno sea un paquetede Java da la opcion de codificar esta con XML o con un pseudocodigo parecidoa Java o C, de modo que no es necesario tener conocimientos de Java para usarOpenCCG. Con estos recursos lexicos, ofrece herramientas tanto para el parsingcomo para la generacion de lenguaje.

En el caso de la generacion de lenguaje, en vez de reconocer la estructura, lasfrases deben ser especificadas como como formas logicas, que son representacionessemanticas de las frases [6]. Cada categorıa sintactica requiere una forma logicapara describir su interaccion con el resto de palabras de la frase, y despues hay quegenerar la representacion de la frase que queremos.

OpenCCG es un entorno de parsing y generacion potente, pero requiere un co-nocimiento amplio de las CCG para generar los recursos lexicos necesarios y lageneracion de lenguaje necesita manejar las especificaciones de frases con las formaslogicas. El diccionario y la gramatica que viene por defecto son adecuados para unuso en un dominio general, pero en casos mas especıficos serıa necesario ampliarlos.Existen varios recursos disponibles para la creacion de gramaticas [8] y el codigo esta


Fig. 7: Forma logica del verbo ”buy” y representacion de la frase ”Peter buys a bike”

abierto para su uso 3, gracias a lo cual se ha mantenido el entorno y se ha empleadoen varios sistemas.

2.3.4. rLDCP

Este entorno fue desarrollado como un generador de lenguaje basado en el es-quema de LDCP[14], del cual es el unico entorno de uso general. Esta implementadocomo una librerıa de R open source 4. Para codificar el sistema LDCP que queremoscrear permite hacerlo por medio de XML y despues se realiza un parsing a codi-go en R, o se puede codificar ıntegramente en R5. Este entorno facilita la creacionde los dos elementos basicos en la arquitectura LDCP: el GLMP y la plantilla degeneracion de los informes. La mayor parte de las operaciones del entorno estanrelacionadas con el GLMP, ya que la estructura de datos que vamos a usar para laentrada y la plantilla de generacion que necesitamos vienen dadas por el dominio enel que nos encontremos.

La implementacion de un sistema debe cubrir los tres aspectos de la arquitecturaLDCP. Primero, a los datos de entrada se les puede hacer un preprocesado o pasarlosdirectamente al GLMP. De cara a la creacion del modulo de GLMP, es necesarioestablecer una serie de elementos: los CP, los PM, los conjuntos borrosos y las reglasde inferencia en base a los datos de entrada de estos conjuntos. Los CP tienen queser inicializados con las posibles expresiones linguısticas y los vectores de validez yrelevancia. Los PM se inicializan con los CP de entrada, la funcione de agregaciony la plantilla de generacion. Los conjuntos borrosos tienen que ser definidos confunciones triangulares o trapezoidales para establecer los valores de pertenencia decada expresion linguıstica y las funciones de inferencia que se van a aplicar a losvalores de entrada. La estructura de los CP y PM se define en base a cuales entrancomo atributo de los PM y cuales son producidos por ellos. Finalmente, se define laplantilla de generacion que agrega el resultado de todos los nodos.

3 https://github.com/OpenCCG/openccg4 http://phedes.com/rLDCP/5 https://cran.r-project.org/web/packages/rLDCP/rLDCP.pdf


Como entorno de generacion, rLDCP es sencillo y permite la creacion de sistemasLDCP complejos [13], pero los sistemas que se generen seran sistemas interpretes deplantillas expertos en un solo dominio. En este caso, la reutilizacion de los recursosde un sistema no es como en los sistemas que emplean gramaticas, donde los diccio-narios o las reglas de generacion pueden ser reutilizados. Dado que cada sistema estaespecializado en su propio ambito, no es comun que la estructura de los datos deentrada ni la plantilla de generacion coincidan. La estructura de las GLMP se puedemodificar para crear otra diferente en lugar de crearla de cero, pero los CP y PMtendran que ser modificados internamente. Los conjuntos borrosos y las reglas deinferencia son tambien dependientes del dominio, aunque se podran generar a partirde unos existentes. En definitiva, la reutilizacion entre sistemas no es muy elevada,pero esto es algo que afecta al esquema de LDCP como tal y no a rLDCP comogenerador. El entorno ofrece una buena aproximacion a la generacion de lenguaje sila arquitectura LDCP se adapta bien al dominio en que nos encontremos.

2.4. Sistemas conversacionalesUno de sus ambitos mas populares donde se aplica la generacion de lenguaje na-

tural es en los llamados sistemas conversacionales. En estos sistemas, se recorre todoel espectro de NLP, desde la comprension de lenguaje natural hasta la generacion.Como lo que se intenta simular es una conversacion en lenguaje natural, esta se vaa estructurar en lo que en la literatura se conoce como “turnos”. En cada turno, elusuario o el sistema proporcionara una frase al otro que servira como respuesta ocomo continuacion de la frase del turno anterior. Esta frase puede ser tanto de solouna oracion como de varias. Con esta estructura, se suponen inexistentes las inte-rrupciones de un interlocutor a otro propias de las conversaciones y el unico ruidoexistente sera el generado por el usuario cuando introduzca una frase erronea, tantogramatical como ortograficamente.

Fig. 8: Esquema de la arquitectura de un sistema conversacional. Adaptado de [64]para incluir los chatbots de lenguaje escrito

Los sistemas conversacionales pueden dividirse en dos tipos diferentes, depen-


diendo del tipo de funcion para el que estan disenados [28]:

Sistemas de dialogo. Estos chatbots son aquellos que tratan de simular unaconversacion con el usuario. Esta conversacion se entiende como una en la quese toman un numero indefinido de turnos entre los interlocutores y en la que seespera obtener algun resultado, ya sea simple entretenimiento u obtener algunresultado psicologico, por ejemplo.

Chatbots orientados a cumplir una funcion en concreto. Este es el caso de lossistemas que reciben una pregunta o una orden en lenguaje natural y realizanuna tarea en concreto. Por lo general, no son capaces de seguir muchos turnosde una conversacion. Este es el caso de sistemas recientes muy conocidos comoSiri o Alexa.

Dado que la funcion que intenta cumplir cada uno es de diferente naturaleza,la forma de abordar los problemas que emplean sera distinta. En las siguientessecciones se tratara cada caso por separado, viendo las aproximaciones de cada unoy las diferentes arquitecturas existentes.

2.4.1. Sistemas de dialogo

Este tipo de chatbots dirigen una conversacion de multiples turnos entre losinterlocutores. De cara a su estructura interna, como ocurre en otros sistemas deprocesado de texto, esta se suele englobar en dos grupos: los basados en reglas y losbasados en un corpus.

Basados en reglas

Los primeros chatbots que aparecieron, como Eliza [58], estaban basados enreglas lexicas para analizar las frases entrantes y generar una respuesta acorde. Laidea es organizar las palabras en grupos con mayor o menor valor y en tener reglasque se apliquen a las frases en las que aparezcan estas palabras y ademas tengan unaestructura adecuada. Cuando un sistema de este tipo recibe una frase, analiza laspalabras que contiene a ver si alguna de ellas pertenece a su dominio. Si hay algunaque cumpla este requisito, entonces se prueban las reglas asociadas a esa palabracon la frase para tratar de generar una respuesta. En caso de no haber palabras deldominio o de no poder aplicar ninguna de las reglas, el sistema debera generar unarespuesta sin informacion algo acorde al dominio en el que se mueva. Poniendo comoejemplo el caso de Eliza, si el sistema no reconoce la frase que acaba de recibir estela reflejara al usuario como una pregunta, al estilo de los psiquiatras.

Este tipo de sistemas, sin embargo, requieren un gran esfuerzo para desarrollarlos.Es necesario un amplio conocimiento linguıstico para poder generar las reglas quepuedan aplicarse a cada palabra y a cada tipo de frase. Ademas, no son faciles demantener, ya que para nuevas frases y palabras que aparezcan hace falta expandirla base de reglas, un proceso no trivial. Pese a esto, este tipo de sistemas una vezdesarrollados dan buenos resultados en su ambito.


Basados en un corpus

Por otra parte, encontramos los sistemas que la informacion sobre la respuestaque generar la obtienen de un corpus previo de conversaciones entre personas o frasesprevias de una persona a una maquina y no exclusivamente de las frases de entrada.De entrada, la ventaja que presentan es no tener que crear a mano las reglas parael procesado de las frases de entrada, que deberan ser tratadas por otros medios.

Sin embargo, un claro problema que presentan estos sistemas es que su funcio-namiento esta profundamente relacionado con el corpus que tengan. Dado que lasfrases que generan las sacan de este, si vamos generando el corpus de manera nocontrolada, por ejemplo obteniendo de manera automatica conversaciones entre per-sonas de una red social como Twitter, no vamos a tener control sobre lo que puedadecir el sistema. Si elegimos otra fuente como conversaciones en libros o pelıculas,hay que tener cuidado con el registro que utilicen, ya que puede no ser adecuado parael ambito en el que nos encontremos. En estos sistemas el corpus es tan importantecomo las reglas en los sistemas anteriores, y va a requerir tiempo generar u obte-ner uno lo suficientemente bueno como para que el chatbot tenga un rendimientoadecuado.

En cuanto al modelo que emplean, una aproximacion a este tipo de chatbotses aplicando recuperacion de la informacion en el corpus. La idea principal es, apartir de una frase que le planteen al sistema, tratar de obtener una frase de res-puesta del corpus de una situacion similar. Los distintos ejemplos de este modelose diferencian entre sı en el tratamiento que hacen del corpus y en como calculanque una frase es una respuesta valida a un turno anterior. Una aproximacion comunes la de comparar la primera frase del turno con las primeras frases de los turnosdel corpus. Esta comparacion puede ser hecha con medidas como la distancia delcoseno o con cualquier otra metrica de la similitud entre vectores de palabras. Unavez hallado el turno de mayor similitud, se contesta con la segunda frase del turnodel corpus a lo que le hayan dicho al sistema. Estos sistemas no realizan ninguntipo de comprension de la estructura o el contenido de las frases que les plantean, sebasan en comparaciones de similitud entre situaciones previas y la actual. Dado que,como norma general, tampoco se realizan conversiones de las frases del corpus, esespecialmente importante que este sea rico y que este orientado al ambito concretodel chatbot, si es que lo hay.

Una ventaja de cara al mantenimiento de este tipo de chatbots, es que los turnosde los usuarios pueden ser empleados para ampliar el corpus. Esto, sin embargo, tieneque ser realizado con cuidado, ya que un sistema que guarde todas sus interaccionescon los usuarios va a terminar por tener un comportamiento descontrolado y, encomo en casos previos, inadecuado.

Otra aproximacion extendida es el uso de arquitecturas sequence to sequence(seq2seq) y aprendizaje automatico [37]. La idea de estos modelos es encontrar“transcripciones” entre las frases de entrada a un turno y las frases de contesta-cion, como si se tratara de encontrar una traduccion para la frase de entrada. Estosuele tener por debajo sistemas con redes neuronales que hace falta entrenar con elcorpus [54]. Esto a su vez genera problemas que han de ser solucionados al tratar


de aplicar redes profundas, como que la generacion de respuestas tiende a frasescortas que cortan abruptamente la conversacion, o que se centran exclusivamente encontestar la ultima frase introducida, por lo que sufren dificultades para seguir unaconversacion continuada.

La direccion que parece seguir la investigacion de los chatbots conversacionales esla de los sistemas basados en corpus, tanto con recuperacion de la informacion comocon aprendizaje automatico. Esta tendencia puede deberse al alto coste que tienegenerar un sistema basado en reglas y a su poca flexibilidad de cara al mantenimientode sistemas, ademas del interes que levantan los metodos que emplean tecnicas demachine learning.

Evaluacion

Como ocurre con todos los sistemas de NLP, los chatbots de dialogo tienen que serevaluados para comprobar su efectividad. En estos casos, la evaluacion automaticacon metricas clasicas como BLEU no resulta muy efectiva, dado que una frase deentrada puede tener un gran numero de respuestas validas y que es difıcil interpretarel valor de estas metricas.

La evaluacion con humanos es la mas extendida en este ambito, donde normal-mente se trata de comprobar como de “humanas” son las respuestas que genera elchatbot. En ocasiones, tambien se trata de hacer pasar al sistema por una especiede test de Turing, de modo que se le presenta a expertos textos de conversacionesentre humanos y conversaciones entre humanos y el chatbot para ver si es capaz dereconocer ambos casos.

Otro metodo de evaluacion que ha surgido recientemente es la evaluacion conadversario [37]. Esta evaluacion consiste en una especie de simulacion del test deTuring con humanos por una maquina. La idea subyacente es entrenar un sistemade clasificacion para que diferencie turnos entre humanos de turnos entre un humanoy una maquina. De este modo, si el sistema se equivoca al evaluar los resultados deun chatbot y clasifica sus turnos como de humano a humano, la evaluacion es queel sistema es efectivo en su ambito.

2.4.2. Sistemas conversacionales orientados a una funcion

Este tipo de chatbots no tratan de seguir un numero indefinido de turnos en unaconversacion, sino que tienen un objetivo concreto en un contexto determinado yquieren obtener algun tipo de informacion de las frases que introducen los usuarios.Segun su objetivo, se pueden distinguir [19]:

Los que buscan realizar una funcion concreta, como reservar una entrada paraver una pelıcula en el cine.

Los que se centran en contestar preguntas, como “¿Que restaurantes cercanoshay?” y en base a la respuesta tratar algun tipo de continuacion como “¿Cualesde ellos son de comida china?”


Los que sirven como un asistente personal, que son una mezcla de las funcio-nes de los dos anteriores, con ejemplos representativos en los asistentes parasmartphones como Siri.

En la literatura se hace tambien una distincion entre los chatbots que reciben delusuario lenguaje natural hablado en vez de escrito, requiriendo los primeros modelosde tratamiento diferentes para extraer informacion del formato de audio. En esteestado del arte no nos vamos a centrar en esos modelos de reconocimiento de voz,pero podemos encontrar una review actual de ellos en [64].

Representacion en marcos

Uno de los puntos importantes que tienen este tipo de chatbots y que difiere delos anteriores es la representacion de la informacion. Dado que en este caso se va atratar con una base de datos o una fuente de informacion de la que poder sacar lasrespuestas a las preguntas del usuario, es necesario estructurar el tipo de datos quetrata el sistema.

Para representar esta informacion, se utilizan modelos basados en marcos. De-pendiendo del sistema que sea, un marco modelara el objetivo concreto que tratade buscar el sistema. Por ejemplo, en la figura 9 se muestra un posible marco pa-ra representar direcciones de puntos de interes en una ciudad. Cada punto tieneasociado slots con la calle, la distancia a la que estan, el tipo de punto, el nombrey el estado del trafico en su direccion. La conversacion posterior muestra como lainformacion acerca de estos slots es extraıda de las frases que introduce el usuariopara su posterior uso y como se debe orientar la conversacion para obtener estosdatos y proporcionar una respuesta.

Fig. 9: Ejemplo mostrado en [60] de una base de conocimiento y un sistema de marcospara representar puntos de interes.

Una estructura de marcos adecuada al problema facilita centrarse en que in-formacion ha de extraerse de cada frase. Por eso, la estructura de control de laconversacion estara centrada alrededor de los marcos que hayamos creado. Esta es-tructura ha sido, tradicionalmente, parecida a una maquina de estados finita. Sitomamos como referencia el anterior ejemplo de un posible marco para un chatbotde direcciones, podrıamos sacar una estructura de control parecida a la de la figura


10 para guiar las conversaciones. En ella, cada estado tiene una forma diferente detratar las frases entrantes de cara a tratar un elemento concreto del sistema de mar-cos, y tiene una forma de responder orientada al siguiente estado al que vayamos allegar. No es necesario que cada estado trate un unico slot, o que haya un mayoro menor numero de estados, cada caso se adecuara a sus necesidades. Tambien esposible tratar con varios tipos de marcos, pero en este caso el sistema requeriraextraer mas informacion para poder completarlos, lo que hara la conversacion maslarga o el tipo de frases que se pueden procesar mas complejas.

Fig. 10: Posible estructura de control en base al ejemplo de marco en la figura 9

El cambio entre estados puede hacerse en base a la frase que introduzca el usuario,si tenemos que diferenciar entre una funcion u otra, o en base a los resultadosque obtengamos de lo pedido por el usuario, si podemos completar la funcion quetengamos que hacer o si nos faltan datos. Una ventaja de dividir la conversacion enestados diferenciables es que el modelo de procesado de lenguaje se puede dividiren sistemas mas pequenos orientados a su funcion de comprension y generacionconcreta. Estos sistemas son mas faciles de desarrollar y de mantener que un solosistema que cubra todos los casos de procesamiento de lenguaje. Para completar losmarcos que nos permitan realizar la funcion del chatbot, se utiliza comprension dellenguaje natural para extraer informacion de las frases y movernos entre estados.

Tecnicas de NLU

Los modelos de comprension varıan en funcion de si estamos tratando lenguajeescrito o hablado, pero el objetivo subyacente es el mismo. Lo la comprension buscaes poder rellenar los slots de los marcos del sistema que nos permitan poder realizarnuestra funcion. Por ejemplo, en el caso de un chatbot que permite reservar un vuelode avion, se querra rellenar un marco con el origen y destino del usuario, el dıa deida, el dıa de vuelta y el precio que esta dispuesto a pagar. Para esto, hace faltaanalizar las frases que ha introducido el usuario, obtener datos de ellas y preguntarsi es necesario por los datos que falten. Si el dominio del chatbot es mas amplio, talvez haga falta identificar tambien la funcion que quiere realizar el usuario y cualesson los marcos que debemos rellenar segun su intencion.


Uno de los metodos clasicos de localizacion y extraccion de informacion de unafrase es mediante reglas semanticas [28]. Estas reglas semanticas son creadas a manocon, normalmente, gramaticas libres de contexto (CFG) capaces de reconocer ele-mentos dentro de una frase. Las CFG consisten en una serie de producciones conuna parte izquierda donde solo aparece un sımbolo no terminal y una parte derechacon las posibles derivaciones de ese sımbolo. Cada regla de la gramatica consiste enuna estructura que puede ser reconocida por estas derivaciones y representada comoetiquetas en un arbol de derivacion. Las gramaticas pueden ir desde tener unas po-cas producciones hasta tener bases de varios miles de ellas, pero cuanto mas escalanmas complicadas son de mantener y puede afectar a su rendimiento.

Una vez se tiene la gramatica capaz de reconocer un tipo de frases en concreto,es necesario un algoritmo de parsing para recorrer las palabras de la frase que in-troduzcamos dentro de las posibles producciones de la gramatica. Lo que diferenciaun parser de otro es el orden en el que evaluan las producciones: si es desde arribaa abajo, es decir, desde los sımbolos iniciales de la gramatica hasta los sımbolosterminales, o de abajo arriba, si evalua las palabras iniciales primero o si empiezapor las ultimas o la regla que utiliza para elegir la proxima derivacion a probar. Nohay un parser que sea mas efectivo que cualquier otro, en cada ambito concreto ycon cada tipo de frases puede variar el rendimiento. De cara a un nuevo problema,hay que probar cual de los parsers posibles es el mas eficaz.

Cuando ha terminado el parsing se obtiene un arbol de derivacion con la fra-se original con cada palabra etiquetada como la derivacion a la que corresponde.Este arbol puede recorrerse para encontrar las etiquetas correspondientes a datosque pueden rellenar los slots dentro de nuestros marcos. La principal ventaja deeste tipo de sistemas es su alta precision, ya que si una frase es reconocida por lagramatica, vamos a poder extraer sin ningun problema toda la informacion necesa-ria. Sin embargo, conforme el dominio de la aplicacion se hace mas amplio, crece engran medida el esfuerzo necesario para crear reglas que reconozcan todas las frasesposibles a las que se puede enfrentar el sistema, y mantenerlo se vuelve mas costoso.

Otra posibilidad de diseno extendida es el uso de aprendizaje automatico paraidentificar el tipo de pregunta que le han hecho al sistema y la posicion de los datosrelevantes en la frase.

Para identificar el tipo de frase que nos presentan, lo mas comun es tener unsistema de clasificacion del tema de la pregunta basado en n-gramas. Este sistemapuede tener cualquier tipo de clasificador subyacente, desde un modelo de espacio devectores que clasifique por distancia relativa entre frases hasta modelos de regresionlogıstica o redes neuronales. Este modulo de identificacion se harıa en el caso de tenerun dominio amplio en el que es posible realizar mas de un tipo de preguntas dife-rentes. Para llevar esto a cabo, primero necesitamos una base de preguntas de cadatipo de manera que podamos crear los modelos de clasificacion de las nuevas pre-guntas entrantes. Por tanto, es necesario algun metodo de obtener estas preguntas,ya sea realizandolas a mano con ayuda de personas con conocimientos linguısticos orecogiendolas a partir de la clasificacion manual de las preguntas introducidas porlos usuarios con el tiempo.


Despues de reconocer el tipo de frase, si es necesario, hay que poder extraer losdatos relevantes de cada tipo de frase. Aparte de los metodos clasicos de gramaticas,se pueden emplear tecnicas conjuntas de aprendizaje automatico y algun tipo dereglas o unicamente basadas machine learning.

Un ejemplo de metodo hıbrido [28] consiste en comenzar entrenando un clasifica-dor que reconozca cuando hay un tipo concreto de dato en una frase y posteriormenteaplicar unicamente las reglas adecuadas a ese tipo de dato en la frase. Por ejemplo,si tenemos un sistema que trabaja de algun modo con direcciones, podemos entre-nar un clasificador que nos diga si en una frase en concreto aparece este dato o no.Para esto necesitaremos un dataset de frases etiquetadas binariamente si aparecedirecciones en ellas o no, un tipo de etiquetado sencillo. Una vez el sistema reconoz-ca la existencia de este dato en una frase pueden entrar en funcionamiento reglasespecıficas para este caso, como la busqueda del dato especıfico en base a los mar-cadores que lo preceden o buscandolo en un diccionario de posibles direcciones, porejemplo. Esto permite ser selectivo con el tipo de reglas de extraccion que se aplicana una frase, por lo que tendremos la precision del uso de reglas con un poco de masflexibilidad al no tener que amoldar todas las reglas a funcionar con cualquier tipode frase.

La otra opcion es utilizar tambien aprendizaje automatico tambien para obtenerlos datos relevantes de las frases [10]. El caso hıbrido de antes es posible convertirloen uno que solo emplea clasificadores si entrenamos tambien uno por cada datoque queremos extraer. En este caso, el dataset debera tener etiquetado en cadaejemplo el dato especıfico que se obtendrıa para cada clasificador y aplicarle los quecorrespondan segun el resultado de los datos que aparecen en una frase.

Aparte del uso de multiples clasificadores, tambien se pueden usar otras tecnicasque no separen la identificacion de la existencia de un dato con la extraccion delmismo. Aquı la clave esta en proporcionar datasets de ejemplos etiquetados especıfi-camente para poder realizar estas dos funciones al mismo tiempo. La aproximacionmas popular en estos casos con los modelos Seq2Seq, que tratan de encontrar unaequivalencia entre la secuencia de palabras de la frase inicial con la secuencia depalabras de los datos buscados.

Una posible forma de conseguir esto es utilizando redes neuronales profundas orecurrentes capaces de encontrar estas equivalencias entre una frase y los datos quecontiene [60]. Para poder entrenar las redes hace falta etiquetar los ejemplos deldataset de modo que tras tokenizar la cadena, cada token tenga asociado un tag sicorresponde o no a un slot que se quiera llenar. De este modo, tendremos cadenasen las que tengamos marcados los datos utiles de cara a entrenar la red para queesta sea capaz de identificarlos y extraerlos, uniendo en un solo paso la identificaciondel objetivo del usuario, la localizacion de informacion y su extraccion para rellenarslots de un marco. Un ejemplo de esta arquitectura usando una red recurrente sepuede encontrar en [25]. Un posible etiquetado para el corpus es el llamado “IOB”(Inside Outside Beginning). Este consiste en marcar todos los tokens que no seanparte de un dato como “O”, los tokens con los que comienza un dato como “B”y los que son parte de un dato como “I”. Este tagging se puede refinar anadiendo


informacion de que tipo de dato es en los tags de “B” y “I”, como en el ejemplo 11.Aquı aparecen los datos que llenarıan un slot definidos, como la fecha con B-Fe yI-Fe o el destino con B-Des. El resto de palabras que no aportan nada a la hora derellenar el marco quedan etiquetadas como O.

Fig. 11: Ejemplo de un etiquetado IOB en una frase.

Para que este tipo de tecnica sea posible, hace falta un proceso de obtencion deuna base de preguntas amplia y un tiempo dedicado al etiquetado de cada pregunta.Una posible opcion es la implementacion de un sistema clasico de reglas primero eir recopilando todas las preguntas que le vayan haciendo al sistema, de modo queal etiquetarlas se pueda ir generando el dataset necesario para poder aplicar estemodelo. Ademas, este proceso es costoso de cara a la red neuronal necesaria, quetendra una estructura compleja y requerira de bastante tiempo para entrenarse.

Tecnicas de NLG

Como ocurrıa en los sistemas exclusivamente de generacion de lenguaje, es ne-cesario pasar por dos fases: la de determinacion del contenido (sentence planner) yla de realizacion de la frase (surface realizer). La diferencia en este caso, es que laplanificacion del contenido que debe tener la frase de respuesta viene determinadapor el control de estados del sistema, por lo que solo habra que centrarse en la formade realizar estas respuestas.

Una de las aproximaciones clasicas para la resolucion de este problema es me-diante el uso de frases deslexicalizadas [43]. Este es un modelo basado en un corpusde respuestas generadas en conversaciones humano-humano en el que las caracterısti-cas relacionadas con slots del marco correspondiente se sustituyen por tokens en lasfrases. Un ejemplo de una frase de un posible corpus serıa: “¿A que [tipo de lugar]le gustarıa ir el [dıa del evento]?”, el cual podrıa ser rellenado con informacion delmarco actual como “¿A que cine le gustarıa ir el viernes?”. Para obtener este cor-pus, se parte de frases de conversaciones humano-humano en las cuales se sustituyenlos datos referentes a slots por su token correspondiente, lo que llamamos el procesode deslexicalizacion.

Una vez visto este sistema de corpus de frases deslexicalizadas, la diferencia entreunas aproximaciones u otras es la forma de generar nuevas frases a partir del corpus.La aproximacion mas basica es la de simplemente rellenar los huecos de los tokenscon la informacion de los slots del marco, lo que serıa equivalente a un sistema deplantillas aplicado a esta arquitectura. Este sistema es lo mas simple que se puedeaplicar, y se basa exclusivamente en lo extenso que sea el corpus para el numero defrases que es capaz de generar.

Para conseguir mas variabilidad en las frases generadas, se trata de emplear lasfrases del corpus para generar otras nuevas que sigan siendo validas, ası como el uso


en ocasiones de frases iguales a las encontradas en el. De nuevo, se tienen dos posiblesaproximaciones segun la tecnologıa que se use: los metodos basados en reglas y losmetodos estocasticos.

La generacion basada en reglas vuelve a basarse en el uso de gramaticas libres decontexto para generar frases adecuadas en un contexto especıfico. Dependiendo dela determinacion de contenido hecha por el sistema, habra que crear una gramaticapara cada situacion de generacion posible. La gramatica final debera se capaz de ge-nerar las frases del corpus, ası como mezclas entre las que sea posible, produciendofinalmente frases similares con o sin tokens, segun corresponda. El proceso de ge-neracion a partir de una gramatica es similar al del parsing top-down, pero en estecaso se crea un solo arbol de derivacion, el cual genera la frase deslexicalizada derespuesta. Tambien se puede hacer de manera recursiva y generar tantas frases comosea capaz la gramatica. A partir de un corpus, la creacion de una gramatica para unambito especıfico no es un proceso muy costoso, pero mantenerla en el tiempo pue-de volverse complicado si esta crece desproporcionadamente. Este metodo tambienasegura la generacion de frases validas siempre que la gramatica no sea erronea.

La otra aproximacion se basa en el uso de metodos estadısticos o de modelos deredes neuronales para la generacion de nuevas frases en base al corpus. Los metodosestadısticos generan los n-gramas mas probables en cada situacion segun el corpus[43]. Un ejemplo de este tipo de modelos serıa la aplicacion con redes de Markov oun k-NN, que construyen modelos de la probabilidad de aparicion de determinadaspalabras tras un n-grama, con lo que van generando frases similares, o en ocasionesiguales, a las proporcionadas en el corpus. La mayor pega de estos sistemas es quesi no estan adecuadamente entrenados, las frases que generan pueden ser erroneaso carecer de sentido. Esta es la razon de que hagan falta corpus extensos y unaevaluacion minuciosa del sistema para comprobar que la generacion de lenguaje esaceptable y no proporciona respuestas incoherentes.

Las estrategias de generacion mas recientes en este ambito se basan en emplearredes neuronales profundas o recurrentes para la generacion de respuestas en base ala frase de entrada [59]. La idea es conseguir que la red aprenda la relacion entre losmarcos de una frase con un numero dado de slots llenos con las frases que se puedenusar como respuesta. La entrada al sistema sera una forma codificada de los valoresde los slots, como en [59], donde generan vectores binarios que representan el estadototal del marco. Con estas entradas, la red trata de obtener una serie de tokens queformen frases deslexicalizadas que se adapten al contexto. Como en los anteriorescasos, hay un paso de postprocesado que anade el valor de los slots a estas frasesgeneradas. Las aproximaciones de este tipo se diferencian entre si por la estructurade la red en cuestion, la forma de proporcionar el vector de entrada y el trato quese hace a las frases una vez generadas.

La efectividad de una u otra tecnica de generacion viene ligada al contexto enel que este el problema, no hay una tecnica superior a otra en cualquier caso. Losmetodos que usan gramaticas siguen siendo muy utilizados en la industria porqueno necesitan un corpus extenso para su funcionamiento. Los metodos estadısticos ode RNN presentan mucho potencial, pero su aplicabilidad viene limitada a casos en


los que tengamos suficientes ejemplos de conversaciones o casos de uso especıficos.

Evaluacion

Este tipo de chatbots se evalua por varias metricas adicionales a un chatbotconversacional.

En primer lugar, tenemos el ratio de error en el llenado de slots del marco (1). Sinuestro sistema no reconoce siempre bien todos los datos de una frase para completarlos slots del marco correspondiente, esta medida nos da una idea de la efectividaddel mismo. Pueden usarse tambien medidas analogas a esta, como la precision o elrecall del llenado de slots.

ratio de error de slots = # de slots llenados correctamente

# de slots presentes en la frase(1)

Otra medida de menos nivel de precision es el porcentaje de acciones completadascorrectamente. Esta medida consiste en ver si, tras reconocer la frase (o frases)introducida por el usuario, el sistema ha completado correctamente la funcion parala que esta creado. Un ejemplo de esto serıa si en un chatbot pensado para reservarcomidas en restaurantes, el sistema es capaz de hacer correctamente la reserva trasel intercambio de frases con el usuario o si algun punto de esta reserva no se harealizado correctamente por reservar a una hora erronea o algun fallo similar. Estamedida del porcentaje de veces que el sistema completa su funcion correctamentenos da una idea de como de eficaz es, pero no nos indica cual es el fallo que subyaceen caso de que este porcentaje sea bajo.

De cara a la evaluacion de las frases generadas por el chatbot, las medidas sonlas mismas que en el caso de los chatterbots. Existen medidas automatizadas comoBLEU, que pueden adaptarse peor o mejor al contexto, pero por lo general noson faciles de interpretar para ver si el sistema produce buenas respuestas o no. Elmetodo que sigue siendo mas valorado es la evaluacion con humanos, para comprobarsi los textos generados por el chatbot son adecuados para cada situacion y si danla sensacion de estar conversando con otro humano en vez de con una maquina. Encada contexto la evaluacion con humanos sera adecuada al tipo de textos generados,pero el inconveniente que siempre presenta es que es lenta y costosa, por necesitarvarias personas leyendo textos producidos por el sistema. Una ultima estrategiade evaluacion que ha surgido recientemente es la evaluacion con adversario. Estaconsiste en entrenar un sistema de clasificacion para que identifique textos escritospor maquinas y textos escritos por humanos. De este modo, si el sistema consiguehacer creer al clasificador adversario que sus textos han sido escritos por humanos,sera un buen indicador. El problema que presentan este tipo de sistemas es que esdifıcil entrenar a este clasificador: si le das ejemplos muy claros de textos escritospor un humano y textos escritos por maquinas, sera muy facil pasar este test, y sile proporcionas textos escritos por maquinas pero iguales o muy similares a los queescribirıa un humano, el sistema no sabra diferenciar entre unos u otros excepto encasos extremos. Aun ası, esta es una alternativa interesante de cara a un metodomas de evaluacion automatica.


2.5. ConclusionesLa generacion de lenguaje natural es un ambito que esta muy ligado al contexto

al que se va a aplicar. Cuando el problema es uno de generacion de texto a partirde datos o de generacion a partir de un texto, los metodos y arquitecturas tratadosen la literatura tienen que ser amoldados profundamente al problema a mano. Unproblema visible en este ambito es la escasez de literatura dedicada exclusivamente ala generacion de lenguaje, y la poca informacion que hay sobre las implementacionesconcretas de los metodos.

Por otra parte, la generacion como parte de problemas mas grandes, como latraduccion automatica o los chatbots vistos anteriormente, si que toma un papel deimportancia donde es un elemento necesario del proceso en conjunto. Las lıneas fu-turas de investigacion en generacion de lenguaje estan mas ligadas a estos problemasgrandes mas que a la investigacion por separado.

La investigacion mas reciente suele ir dirigida a los metodos basados en corpus yen los que emplean aprendizaje automatico, pero no se puede afirmar que estos seansuperiores a los demas en todos los ambitos. Los problemas de procesado de lenguajeson muy distintos dependiendo del contexto de cada uno, y un mismo metodo debeser adaptado de manera distinta para un problema como para otro. No existe unmetodo universal que de mejores resultados para cualquier problema, por lo queno se puede decir que los metodos que emplean aprendizaje automatico son siempresuperiores a los que no. Ademas, sigue estando extendido el uso de sistemas de reglastanto por sı mismos como de apoyo a otro tipo de modelos.

El caso de la generacion de lenguaje supone hacer frente a problemas de los queno se sabe bien como tratar, pero el conocimiento de casos de otros problemas delenguaje natural y los metodos empleados para resolverlos son de ayuda para vercomo afrontar uno nuevo. El procesado de lenguaje natural es mas bien un entornoen el que hay que aprender a tratar problemas nuevos y a adaptar tecnicas conocidasmas que a desarrollar metodos o arquitecturas universales que traten multitud decasos.

3 Planteamiento del problema 31

3. Planteamiento del problema

Para poner en practica algunas de las tecnicas de NLP, vamos a crear una prue-ba de concepto de un chatbot en un entorno especıfico. El problema que vamos atratar consiste en buscar viviendas por medio de lenguaje natural. En paginas debusquedas inmobiliarias como Idealista 6, el sistema consiste en introducir una seriede valores mediante checklists y listas desplegables de parametros, de modo que conesta informacion se realiza una busqueda en la base de datos de todas las viviendasque cumplan los requisitos. La idea del chatbot es convertir este proceso en uno guia-do exclusivamente por lenguaje natural, de modo que los usuarios puedan preguntaral sistema directamente por el tipo de vivienda que buscan y sus caracterısticas.Por tanto, nuestro objetivo sera poder extraer la informacion que nos sea relevan-te para nuestras busquedas de las preguntas introducidas por el usuario, realizaruna busqueda con ellas y mostrar los resultados al usuario junto con una frase enlenguaje natural.

Fig. 12: Ejemplo de la interfaz de busqueda de una casa a la venta en Madrid enIdealista.

El chatbot en cuestion cubrira todo el proceso de la comunicacion, desde lacomprension de la pregunta introducida por el usuario hasta la generacion de unarespuesta acorde tras buscar pisos adecuados con lo que le han pedido. Como es unchatbot especializado en un entorno muy concreto, el lenguaje y el tipo de frases queva a poder procesar seran las relacionadas con la busqueda de casas, no cualquiertipo de frases como un sistema conversacional del estilo de CleverBot 7. De igual

6 https://www.idealista.com/7 http://www.cleverbot.com/

3 Planteamiento del problema 32

manera, las respuestas las generara en funcion de las preguntas, ofreciendo ademasuna lista de viviendas que pueden resultar de interes al usuario.

El chatbot contribuirıa a que los usuarios pudiesen realizar busquedas en un en-torno mas sencillo por medio de preguntas y respuestas. Este tipo de sistemas puedendarle una apariencia de estar tratando con algo que verdaderamente comprende laspreguntas que le estamos haciendo. Una prueba de concepto del tipo de chatbot quese podrıa hacer para solucionar este problema y en este ambito es un buen ejemplode aplicacion de las tecnicas de generacion y de sistemas conversacionales tratadasen el estado del arte.

4 Hipotesis de trabajo 33

4. Hipotesis de trabajo

A continuacion, se listaran las limitaciones que se establecen para la construcciondel chatbot:

El entorno en el que se va a mover el chatbot es el de contestar preguntassobre si existen casas de determinadas caracterısticas. No se van a comprenderpreguntas relacionadas con otro tema diferente, como lo buena que es algunacasa en particular o cuales son las zonas mas baratas de una ciudad.

No se va a tratar de realizar un sistema conversacional general. El chatbot secentrara en contestar las preguntas que le hagan, pero no podra seguir unaconversacion con un usuario ni salir fuera de su ambito.

El chatbot realizara el camino completo desde comprender una pregunta so-bre casas con unas determinadas caracterısticas hasta su contestacion y elmostrado de un listado de casas que satisfacen lo preguntado.

El chatbot se ha pensado como una pequena prueba de concepto. Inicialmentese tomaron unas 30 preguntas de referencia y unos 300 pisos entre los quebuscar. La idea es obtener algo funcional a esa escala y proponer medidaspara adaptarlo a un entorno real.

No es posible que el sistema sea capaz de comprender todas las formas depreguntas existentes en nuestro entorno nada mas terminar su desarrollo. Paraque el sistema tenga mucho mayor nivel de flexibilidad es necesario mantenerloen el tiempo y tomar medidas explicadas en la siguiente seccion.

No hay un lımite en relacion a como de largas o cortas pueden ser las preguntas,pero se supone que constaran de una sola oracion.

Se limitara el numero de casas mostradas tras una pregunta a un maximo ar-bitrario de 10. No supone ningun problema mostrar mas o menos, este numeroes porque no parece adecuado mostrar al usuario mas de 10 viviendas sinpreguntarle si desea ver mas.

El tiempo de respuesta del sistema desde el momento en el que se realiza unapregunta no debe ser de mas de unos segundos como maximo.

5 Resolucion 34

5. Resolucion

A continuacion se describira todo el proceso seguido para la implementacion delchatbot, ası como las distintas alternativas que se trataron de cara a los diferen-tes problemas que surgieron y las decisiones finales en cada caso. Todo el codigodesarrollado esta disponible en GitHub8 bajo una licencia MIT.

5.1. Recopilacion de datosEl primer paso de cara a la creacion del sistema fue el de recopilar la informacion

necesaria de viviendas entre las que el chatbot pueda buscar. Para esto, decidimosconcentrarnos en la pagina de Idealista, dada la gran cantidad de casas que puedenencontrarse y a que la informacion de estas viene bastante bien estructurada en ca-racterısticas distinguibles. Idealista ofrece una API con la que poder hacer consultasa su base de datos, con un lımite diario. El problema que encontramos en ese puntoes que la API requiere una clave que hay que solicitar y esperar a que te la envıen. Envista de esto, y dado que no necesitamos toda la base de viviendas de Idealista pararealizar nuestra prueba de concepto, decidimos crear un pequeno webscraper pararecopilar datos de casas directamente desde el navegador de manera automatizada.

El webscraper esta codificado en Python utilizando BeautifulSoup y Selenium, yfue utilizado para crear una pequena base de 300 viviendas. Llegados a este punto,era necesario establecer el formato que iban a tener los pisos de cara a la implemen-tacion, y finalmente se decidio por:Piso = [ Operaci on , Tipo , Lugar , Precio , Tamano , Habitac iones , Banos ,

Estado , Muebles ]Operaci on = Compra | A l q u i l e rTipo = Chalet | Piso | Du plex | At i c o | Casa r u s t i c aLugar = Coslada | Alca l a | Mejorada | Torre j onPrec io = f l o a t [ 0 , +∞)Tamano = f l o a t [ 0 , +∞)Hab i tac iones = i n t [ 0 , +∞)Banos = i n t [ 0 , +∞)Estado = Nuevo | Segunda mano | A reformarMuebles = Amueblado | Cocina amueblada | Sin amueblar

Listing 1: Especificacion de un piso

Este serıa el marco que emplea el chatbot para representar los pisos, con losdiferentes slots detallados. Dado que nuestro sistema solo opera con este marco, lasfunciones de procesado de lenguaje que habra que desarrollar mas adelante tendranque ver con tratar de rellenar estos slots en base a analizar las frases que introduzcael usuario. Una vez relleno el marco, se podra emplear este para buscar viviendassimilares.

Por tanto, para crear una instancia de cada vivienda, habıa que recopilar toda lainformacion de la especificacion. El webscraper tiene que ir moviendose entre dife-rentes paginas para crear cada piso y guardarlo. Para conjuntos de datos pequenos,

8 https://github.com/dkesada/ChatBot

5 Resolucion 35

como el nuestro de 300 pisos, es una aproximacion adecuada, pero para conjuntosgrandes (cientos de miles) serıa mas rentable esperar al envıo de la clave de la API,dado que el proceso del paso de una pagina a otra no es instantaneo. En este puntoaun no se habıa creado una base de datos para el chatbot, por lo que los datos delas viviendas se almacenan en un archivo de texto.

Ademas de informacion de pisos, tambien se creo una baterıa de 30 posiblespreguntas que le podrıan hacer al chatbot, para tener una idea de que habrıa quepoder procesar mas adelante. Estas preguntas son del tipo:

¿Que pisos amueblados de 3 habitaciones puedo alquilar por 450€ al mes enCoslada?

¿Hay alguna casa a la venta en Torrejon de al menos 90m2 por menos de150000€?

Quiero ver pisos para alquilar que sean de menos de 500 euros al mes por lazona de Mejorada

En total, se trato de obtener el mayor numero de formas posibles de este tipode preguntas. Mas adelante, en el procesado de las mismas, se fueron viendo nuevoscasos no contemplados previamente y se fueron anadiendo preguntas nuevas.

La creacion del webscraper no tomo demasiado tiempo, y para cuando nos en-viaron la clave de la API no merecıa la pena hacer el cambio de vuelta. Sin embargo,como se ha comentado previamente, para que el sistema pueda hacer consultas entiempo real a toda la base de viviendas serıa necesario hacer peticiones a esta APIen vez de a la base de datos local.

5.2. Base de datosDe cara al guardado de los pisos se decidio crear una base de datos no relacional

con MongoDB. Se decidio usar Mongo por su facilidad de integracion con Python.Como los datos que recoge el webscraper son textuales, para guardarlos en la base

de datos se decidio transformarlos en datos numericos. Para ello se hizo un parserde cada uno de estos elementos para generar vectores numericos que representen lasviviendas. Todos los datos como el tipo de vivienda (pisos, duplex, ...) pueden serrepresentados con datos numericos como si se tratase de tipos enumerados, ya quesu numero es finito y reducido. Sin embargo, el lugar de la vivienda tiene demasiadosposibles valores, por lo que habrıa que dejarlo como un tipo textual. Con esto, cadacasa cargada por el webscraper se parsea a una lista numerica, que se guarda comoun diccionario en la base de datos.

5.3. Modelo de procesado de preguntasEn este punto se cogieron las preguntas y el marco generados en la anterior fase

para poder hacernos una idea del tipo de frases que hay que procesar. La esctructurade control que tendrıa el chatbot serıa la siguiente:

5 Resolucion 36

Fig. 13: Estructura de control de los estados posibles del chatbot.

A partir de esto, se dedujo que este tipo de preguntas se componen de una in-troduccion y de un conjunto de caracterısticas. Los modelos basados en aprendizajeautomatico no podran ser llevados a cabo, dada la necesidad de un amplio con-junto de ejemplos etiquetados necesario para que el sistema pueda ser entrenadocorrectamente. Dado el reducido dominio del chatbot, este tipo de corpus podrıa seradquirido con el tiempo a partir de las propias preguntas que los usuarios realicenal sistema, pero de entrada serıa demasiado grande y costoso en tiempo como paraconstruirlo a mano desde cero. Por tanto, las alternativas que se trataran no se ba-saran en modelos de este tipo. Finalmente, se tuvieron en cuenta dos alternativasviables de diseno:

5.3.1. Gramatica libre de contexto

Para poder procesar las preguntas en lenguaje natural, uno de los medios masextendidos es con una gramatica libre de contexto. Con este metodo, las frases sonanalizadas despues de tokenizarlas generando un arbol de derivacion y anadiendoleun tag a cada palabra que la define dentro de la frase. Uno de los beneficios de lasgramaticas es que su construccion en este tipo de ambitos es bastante rapida, essencillo hacer una gramatica que sea capaz de reconocer frases de un mismo tipo.El problema de las gramaticas es que son muy inflexibles de cara a lo que puedenreconocer y son complicadas de mantener. Como estan tan limitadas al tipo defrases que pueden reconocer, en cuanto te salgas de su contexto no van a ser capacesde funcionar correctamente. Ademas, para mantenerlas y anadir nuevos tipos defrases que puedan reconocer, habrıa que expandir la gramatica original con nuevasproducciones o terminales. Expandir la gramatica puede no ser trivial si esta es losuficientemente grande.

Con todo esto, las gramaticas son capaces de dar buenos resultados si son emplea-das en entornos bien acotados, que son adecuados para ellas. Si de entrada sabemosel tipo de frases al que nos vamos a enfrentar y estas no son muy variables, son unaalternativa efectiva y facil de desplegar.

5 Resolucion 37

5.3.2. Clasificacion de queries y division en entidades

Este metodo comienza creando una serie de preguntas tipo que el sistema sabereconocer. Estas preguntas tipo conforman entidades a las que hay que asignar lasfrases entrantes al sistema por medio de parafraseo. Cuando analizamos una fraseentrante, se buscan los datos que tiene por medio de, por ejemplo, marcadores dis-cursivos y se asigna a la entidad correspondiente. Tras esto, la pregunta la habremosparafraseado como una de las entidades y la trataremos como harıamos con todaslas pertenecientes a esa entidad. Un ejemplo de este tipo de sistema se encontroen [46] aplicado a un dominio mucho mas abierto, en el que es necesario acotar ladireccion de la pregunta y es necesaria mucha flexibilidad de cara a las preguntasentrantes.

Este metodo, en comparacion con el uso de gramaticas, es mas facil de mantener.Cada vez que entre una pregunta que el sistema no sepa clasificar en una entidad,solo hay que adaptar la entidad correspondiente. Tambien es mas adecuado paraambitos menos especıficos, ya que la cantidad de frases que es capaz de identificar espotencialmente mas amplia. Sin embargo, crear un sistema de estas caracterısticasrequiere tener un conocimiento linguıstico amplio en el ambito en el que estemos.Necesitamos saber las formas de realizar las preguntas a las que nos enfrentaremospara poder crear las entidades y que el sistema tenga una buena cobertura desde elprincipio. El despliegue de un sistema de estas caracterısticas es mas costoso, perotambien mas eficaz en ambitos no tan limitados y mas facil de mantener.

5.3.3. Conclusiones y eleccion

Finalmente, tras considerar ambas opciones se decidio aplicar una gramaticapara resolver este problema. El ambito del chatbot es lo bastante reducido comopara que la gramatica resulte efectiva, y el tiempo necesario para crear la gramaticaes bastante menor, por lo que se adapta mejor al ambito de la tesis. Tambien influyoel hecho de que existan librerıas de Python como NLTK que facilitan el desarrollode las gramaticas y el parsing.

5.4. PreprocesoPara poder tratar las preguntas, primero tenemos que tratar las cadenas de texto

entrantes para poder sacar su arbol de derivacion con la gramatica y para simplificarel proceso.

5.4.1. Simplificacion de cadenas

Al utilizar el espanol como idioma para el chatbot, el primer problema que nosencontramos de cara al uso de librerıas de procesado de lenguaje es la codificacionde las cadenas. Para la introduccion de texto con los caracteres propios del espanol,como las tildes o los signos de interrogacion iniciales, se emplean cadenas codificadasen UTF-8 o similares. Sin embargo, para poder tratar las cadenas sin problemas, es

5 Resolucion 38

necesario convertirlas a Unicode, la codificacion mas simple de caracteres que solorecoge los incluidos en el ingles.

Para solucionar este problema, uno de los pasos de preprocesado de las cadenases la conversion de estas a su correspondiente mas cercano en Unicode. Para esto seutilizo Unidecode, una librerıa de Python que trata todos los sımbolos que no existenen unicode y genera su equivalente mas cercano. Un ejemplo de esto serıa:

¿Hay algun piso en Torrejon con 3 habitaciones y amueblado por menos de600€ al mes?

?hay algun piso en torrejon con 3 habitaciones y amueblado por menos de600EUR al mes?’

Este paso simplifica el tratamiento de cadenas de texto en gran medida, evitandoproblemas de codificacion. En menor medida, tambien evita errores ortograficos portildes al eliminarlas completamente. Se tuvo tambien en cuenta la posibilidad deanadir un pequeno corrector ortografico, pero finalmente no se llevo a cabo.

5.4.2. Tokenizado

Para poder aplicar la gramatica a las cadenas de texto, es necesario dividir lapregunta inicial en tokens a nivel de palabra. Existen librerıas con tokenizadoresque tambien anaden tags a nivel de que es cada palabra, pero estan hechos parael ingles. De todas formas, con un tokenizador hecho con expresiones regulares nossirve para nuestro caso, ya que el tagging lo haremos mas adelante al construir elarbol de derivacion de la frase.

Ademas de separar la frase en palabras, el tokenizador realiza otras funciones co-mo eliminar signos de puntuacion y numeros. En el caso de los numeros, la gramaticano trata bien los numeros de mas de una cifra al considerarlos un token solo y novarios. Por ello, en el tokenizador los numeros de dos o mas cifras son sustituidospor el token NUM y guardadas en un buffer. Mas adelante, durante el tratamientode los arboles de derivacion, se extraen por orden las cifras que haya en este buf-fer, dado que el recorrido de estos arboles se hace inorden, por lo que las cifras seencuentran en la misma posicion que en la que se extrajeron. Tambien se podrıahaber insertado un espacio tras cada numero en la cadena para que la gramaticapudiese tratarlos, pero esto ralentizarıa innecesariamente la derivacion y complicarıasu extraccion mas adelante, por lo que esta opcion no merecio la pena.

5.4.3. Stopwords

Uno de los puntos mas importantes del preprocesado fue el tratamiento de laspalabras vacıas o stopwords. Estas palabras son las que no nos aportan informacionde cara a procesar las preguntas entrantes. Normalmente, hay palabras vacıas queno aportan informacion en muchos ambitos diferentes, como los verbos auxiliares,pero tambien pueden existir otras palabras, como adjetivos, que en un entorno noaporta informacion y en otros sı puede ser de importancia.

5 Resolucion 39

En el caso de nuestro chatbot, en un principio se penso en eliminar las palabrasvacıas para simplificar las cadenas entrantes. Sin embargo, cuando se comenzo acrear la lista de palabras vacıas del sistema se vio que esto era una gran ayuda parala gramatica que procesa las preguntas. En un principio se anadieron adjetivos rela-cionados con las casas de manera subjetiva, como “pisos amplios”, “casas coloridas”o “con muebles bonitos”. Este tipo de adjetivos, aunque sı que aportan informacion,no nos es de utilidad de cara a la busqueda en nuestra base de datos.

Ademas de adjetivos, tambien anadieron a esta lista expresiones como “por favor”y “gracias”. Anadir estas expresiones aquı y eliminarlas en el preprocesado evitatener que expandir la gramatica para que las reconozca y no haga nada con ellasmas adelante. Esto permite mejorar la capacidad de mantener el sistema sin tenerque expandir la gramatica, sino anadiendo nuevas expresiones que no hayamos tenidoen cuenta antes a la lista de stopwords. En el ambito especıfico de nuestro chatbot,el uso de las stopwords mejora en gran medida el funcionamiento del sistema, ya queanade cierta flexibilidad al tipo de frases que puede reconocer y deja la extraccion decaracterısticas mas sencilla para la gramatica. En un principio, se creo la gramaticade procesado de preguntas con las formas mas comunes de hacer estas preguntas,como por ejemplo “Quiero que me ensenes casas ...”, “Me gustarıa ver pisos ...”o “¿Que aticos hay ...?”. Despues, cuando se identificaron nuevas formas de poderhacer estas preguntas, se procesaron mediante la lista de stopwords, de forma quelas frases quedaban reconocibles por la gramatica sin necesidad de expandirla, porlo que el resultado fue bastante mejor de lo esperado.

Se considero tambien la opcion inversa, en vez de generar una lista de palabrasque eliminar, generar una lista de palabras “validas”. Esto harıa que la gramaticaencontrase siempre palabras que puede reconocer, pero da ninguna garantıa de queaumente el numero de frases capaz de reconocer. Dentro de la lista de palabrasvalidas tiene que haber palabras comunes, como por ejemplo preposiciones, por loque si llega un n-grama que no sabes reconocer pero este contiene una palabra quesı reconoces, el resultado final seguira siendo de no comprension. Este mismo casopuede solucionarse con la alternativa de la lista de stopwords si se anade una entradacon este n-grama. Por esto se dejo de considerar esta posibilidad y se continuo conla idea original.

5.5. Gramatica libre de contextoDe cara a la construccion de la gramatica libre de contexto, no se penso esta para

que reconociese frases en base a los sintagmas que la forman. En su lugar, fijandonosen la estructura de las preguntas que se le van a hacer al chatbot, estas suelen estarformadas por una introduccion (si la hubiese) de algun tipo concreto seguida de unaserie de caracterısticas. Por tanto, la gramatica esta orientada a reconocer esta seriede caracterısticas y la introduccion.

5 Resolucion 40

5.5.1. Producciones

Para su construccion, se tomo como referencia la baterıa de preguntas generadadurante la recopilacion de informacion. Se trato de hacer lo mas flexible posibledentro del ambito, de modo que le sea indiferente las caracterısticas que introduzcas,el orden o la introduccion, como muestran las producciones basicas de la gramatica.La idea es ir directamente al que nos esta preguntando el usuario.Pregunta −> Pet i c i on Caracs | CaracsPe t i c i on −> Quiero | Ensena | Que | Cual | Gustar ia | HayCaracs −> Carac Caracs | Carac Conj Caracs | CaracCarac −> Prec io | Lugar | Tamano | Estado | Muebles | Habit | Banos |

Alq | TipoP | TipoS | Accion | Disp

Listing 2: Producciones iniciales de la gramatica de entrada

De cara a la identificacion de las caracterısticas, la clave para identificarlas sonlos marcadores discursivos que las preceden. El ejemplo mas claro de esto esta enla caracterıstica de “Lugar”, que comienza siempre con un marcador que indica unasituacion geografica, como “en” o “alrededor de”. Estos marcadores suelen ser pre-posiciones, por lo que buscarlas resulto ser un buen punto por el que comenzar abuscar informacion dentro de las frases. Tambien fue necesario buscar otros elemen-tos como la “accion” que se quiere realizar (compra o alquiler), o el tipo de viviendabuscado.

5.5.2. Parsing

Para hacer funcionar la gramatica, es necesario un parser que vaya procesandotodos los tokens de la cadena inicial y vaya generando las producciones que seanposibles con cada uno. Antes de buscar ningun parser concreto, la gramatica se creoevitando la recursion a izquierdas para evitar posibles problemas con alguno de ellos.

NLTK ofrece multiples parsers, cada uno de ellos siguiendo un algoritmo distintode derivacion. Los hay que parten desde las producciones iniciales y tratan de llegar alos terminales (top-down) o los que desde los sımbolos terminales tratan de conseguirderivaciones hasta las producciones (bottom-up). Tambien varıa el tipo de busquedaque hacen, que puede ser en anchura o en profundidad, voraz, dinamica o recursivahasta encontrar todas las posibles derivaciones.

En la tabla 1 se muestran medias del tiempo que tarda el procesado de una frasedependiendo del parser que se elija. El primero de todos es un parser exhaustivoque busca por recursion todas las posibles derivaciones de la frase de entrada, poreso su tiempo es tan elevado. El siguiente es un parser que sigue un modelo vorazy no siempre encuentra una derivacion, aunque esta exista. En base a las pruebas,los parsers bottom-up son los que mejores resultados ofrecen. Esto es probablementedebido a que la gramatica tiene bastantes derivaciones distintas si se comienza desdeel sımbolo inicial, por lo que se extiende a lo ancho. Sin embargo, si se reconoce unaserie de tokens como los sımbolos terminales, los cuales no son tantos, la derivacioncorrespondiente es directa.

5 Resolucion 41

Parser Media (seg.) ResultadoRecursiveDescentParser 8.2136 Sı

ShiftReduceParser 0.0388 NoBottomUpLeftCornerChartParser 0.0192 Sı

LeftCornerChartParser 0.0163 SıIncrementalLeftCornerChartParser 0.0142 SıIncrementalTopDownChartParser 0.0658 Sı

Tab. 1: Tiempo medio de procesado con diferentes parsers de la pregunta ”¿Que pisosamueblados de 3 habitaciones puedo alquilar por 700€ al mes en Coslada?”

Tambien existe el caso con cualquiera de los parsers en el que el parsing fallaporque la gramatica no reconoce la frase introducida. En este caso, el arbol dederivacion producido sera vacıo, y se tratara como un posible resultado.

Finalmente, el proceso completo del reconocimiento de la pregunta introducidase ilustra en la figura 14, donde se ve la tokenizacion y el arbol de derivacion obtenidotras aplicarle el parsing con la gramatica libre de contexto. Una vez reconocidos loselementos de la pregunta, se procede a crear la query correspondiente para encontrarviviendas que sean de interes para el usuario.

Fig. 14: Ejemplo del procesado de una pregunta al sistema.

5.6. Busqueda de viviendasUna vez analizada la pregunta que se le ha hecho al sistema, hay que recorrer el

arbol de derivacion para encontrar los elementos relevantes a la hora de hacer unaquery a la base de datos.

5.6.1. Recorrido del arbol de derivacion

Por como hemos modelado la gramatica, a la hora de movernos por el arbol dederivacion los subarboles que nos interesan son los que la etiqueta de la base es“Carac”. Si obtenemos todos estos subarboles, tendremos todas las caracterısticasque nos ha pedido el usuario que busquemos.

5 Resolucion 42

En este punto, se crea una vivienda en su especificacion de array inicializada a0, y se recorren las caracterısticas identificadas para ir asignandole valores a estavivienda prototipo. Con esto, conseguimos los valores fısicos que podemos usar parabuscar casas similares a este vector en nuestra base de datos.

Fig. 15: Vector generado de una derivacion.

5.6.2. Creacion de las queries

Para crear la query con Pymongo, de cada una de las caracterısticas que encon-tremos en el arbol hay que anadir un campo nuevo especificando que se busca.

En un principio, en vez de buscar por campos en la base de datos y dado que yase tienen todas las viviendas en forma de vector, se penso en hacer esta busquedapor distancia entre vectores. Los vectores mas cercanos, con la precondicion de quese cumplan algunos de los campos mas estrictos como el de que coincida la comprao la venta y el tipo de vivienda, serıan los que mas posibilidades tienen de ser deinteres para el usuario. Sin embargo, dado que los vectores iniciales que se obtienentras el scraping son convertidos a diccionarios e introducidos en la base de datos,tiene mas sentido realizar la busqueda con las queries de MongoDB.

Llegados aquı y de cara a como plantear estas busquedas, se vieron las siguientessituaciones:

Esta el caso en el que encontremos viviendas que cumplen perfectamente los re-quisitos establecidos por el usuario, por lo que dirıamos que tenemos viviendasque con un cierto nivel de certeza le resultaran utiles.

Existe la situacion en la que, aunque no hayamos encontrado casas justo comose quieren, hemos encontrado casas parecidas a ello, en mayor o menor medida.En este caso, aunque no estamos tan seguros, tenemos tambien viviendas quepueden ser de interes.

Si no encontramos nada parecido a lo que el usuario busca, tendremos quecomunicarle que no tenemos nada para ofrecerle con esas caracterısticas.

Finalmente, tambien puede ocurrir que el sistema no entienda la pregunta quese le ha hecho.

En el caso de no haber comprendido la pregunta, el parsing comunica al moduloque realiza la busqueda que no es necesario, dado que no sabemos que buscar.

En los otros casos, y basandonos en esta idea de la certidumbre del sistema encuanto a los resultados, el sistema trata de encontrar primero las viviendas que masse ajusten a las caracterısticas introducidas. Primero busca casas en la zona que sequiere de menor o igual precio que el pedido, con el numero de habitaciones o banos

5 Resolucion 43

que se busca y en el estado que se quiere. Si esta busqueda no obtiene resultados,entonces se reduce la exhaustividad, buscando casas con caracterısticas similares,pero no exactamente las mismas que se han pedido.

Si tras estas dos queries no se han encontrado resultados, entonces se suponeque no se tiene nada que cumpla las especificaciones del usuario. En este caso nopodremos devolver una lista de casas.

En base a este nivel de certidumbre que tengamos, de cara a la generacion derespuestas afectara al tipo de frase resultante si hemos encontrado algo exactamentecomo nos lo han pedido, si hemos encontrado algo similar o si, por el contrario, nohemos podido encontrar nada.

De cara al cambio entre usar una base de datos local de MongoDB y usar la APIde, en este caso, Idealista el sistema de queries es el mismo. Los cambios que hayentre ambas aproximaciones es en cuanto a como crear la query de cada uno. En elcaso de MongoDB, la query se crea pasando el vector del piso a un diccionario, quesera el introducido en la funcion find. Sin embargo, para el caso de la API habrıa quecrear una consulta de HTML. Quedarıa por ver el tiempo que se tardarıa en obteneruna respuesta utilizando la API y el numero de consultas diarias que permite paraver si su uso en tiempo real es adecuado.

5.7. Generacion de respuestasUna vez que se ha realizado la busqueda de las viviendas, hay que crear una

respuesta en lenguaje natural que darle al usuario. Como antes, sigue habiendocuatro posibles situaciones en funcion de si se ha comprendido la pregunta y deque se ha encontrado. Para la generacion, de estas situaciones se sacaron dos casosdistintos:

Los casos en los que se han encontrado viviendas que cumplan los requisitos.Aquı tenemos tanto la pregunta original como la certidumbre y los resultadosobtenidos como material para generar las respuestas. Como mınimo, la pregun-ta y la respuesta tienen que estar coordinadas y concordadas, de modo que sepregunte y se conteste por las mismas viviendas y con el nivel de certidumbreadecuado.

Si por el contrario, o no se ha encontrado nada o no se ha comprendido lapregunta, no hay muchas formas de expresar esta situacion.

A raız de esto, se penso en cuales de las tecnicas vistas en el estado del artepodrıan resultar mas adecuadas a cada caso. Primero, se comprobo si merecıa la penaaplicar alguno de los entornos de generacion revisados. De todos ellos, SimpleNLGes el unico que tiene implementacion en Python. Sin embargo, la librerıa que locompone es un simple wrapper de las funciones de Java a Python, por lo que sepenso en tomar otra aproximacion por la falta de cobertura y completitud quepudiese encontrarse.

Podıa haberse aplicado un sistema por plantillas, que en base a las viviendasque se encontrasen y al nivel de certidumbre rellenase la respuesta de la forma

5 Resolucion 44

correspondiente. Se decidio, sin embargo, no usar plantillas y usar otro metodo quetuviese mas interes a la hora de la generacion.

Como el caso de generacion es similar al de comprension, una gramatica y reglaspara la concordancia y la coordinacion puede ser una solucion valida. En este caso,la gramatica se usarıa en sentido inverso, usando las producciones para generar unafrase en lugar de para reconocerla. Tambien se planteo la posibilidad de usar unagramatica probabilıstica, siendo este caso bastante similar al anterior. Por ultimo, seconsideraron metodos basados en un corpus. Pueden usarse metodos probabilısticoscomo las redes de Markov o metodos basados en tablas, donde cada caracterısticade la frase que se pretende escribir tiene asociada una serie de formas de construirse.El principal problema que se vio es que para que estos sistemas funcionasen esque requieren un corpus extenso, y como no se tiene de antes, requieren tiempoconocimiento linguıstico para crearlos.

En vista de las opciones disponibles, finalmente se opto por usar una gramaticay reglas para los casos en los que encontrasemos viviendas, de modo que pudiesemosemplear la derivacion de la pregunta original de cara a la respuesta. Esta aproxi-macion es una mezcla entre los sistemas de gramaticas y los de un corpus de frasesdeslexializadas como el de [43] visto en el estado del arte. Para los casos en los queno se entiende la pregunta o no se encuentran resultados, no hay mucha informa-cion con la que trabajar. En vez de emplear frases enlatadas predefinidas o algunaplantilla se decidio probar a utilizar redes de Markov, para ver cuanta efectividadse puede conseguir en un caso como este.

5.7.1. Gramaticas de generacion

Cuando se comenzo con la idea de las gramaticas para las respuestas, primero sepenso en crear varias gramaticas pequenas para cada posible pregunta reconocidaen la derivacion. De este modo, si se preguntaba de la forma “¿Hay algun piso ...?”se contestarıa con la gramatica especializada en responder al tipo Hay, o si la frasereconocida era del tipo de “Dime pisos en ...” la respuesta serıa para ese tipo depreguntas en concreto. A esta aproximacion se le encontraron dos problemas. Elprimero fue que las respuestas, en su mayorıa, eran las mismas para unas u otraspreguntas. Solo hay diferencias especıficas que pueden ser tratadas con reglas en vezde crear una gramatica distinta para esa situacion, como en el caso de las preguntastipo Hay, que se puede anadir un “sı” o “no” al principio, pero el resto de la respuestaes similar. El segundo problema que se vio era que, al utilizar la lista de stopwordsen el preprocesado, no se reconocen todos los tipos de preguntas. Algunos de los quefueron anadidos tras la creacion de la gramatica se trataron en la lista como verbosauxiliares. Por esto, al hacer mas facil de mantener la gramatica tambien se generancasos en los que no se reconoce la introduccion de la pregunta, pero sı el contenido.

En vista de que no se iba a conseguir mucha diferencia a nivel del tipo de pre-gunta, se considero hacer dos gramaticas: una para las preguntas que encontramosjusto con las especificaciones pedidas y otra para cuando el nivel de certeza estareducido al relajar estas condiciones. En estos dos casos, las respuestas difieren losuficiente como para que sea interesante crear dos gramaticas en vez de una sola que

5 Resolucion 45

cubra ambas situaciones.La gramatica en este caso concreto se usara para generar la base de la respues-

ta que usaremos. A partir de esta base y fijandonos en el arbol de derivacion dela pregunta que le hicieron al sistema, habra que ajustar esta frase por medio dereglas. Es importante que el sistema de una respuesta adecuada a la pregunta quele realizaron, para que de la mayor sensacion posible de comprension.

Las bases generadas por la gramatica contienen tokens que seran luego adap-tados como corresponda. Por ejemplo, una base que puede ser generada serıa “Heencontrado Sn Carac como lo que buscas:”. Aquı habrıa que generar un sintagmanominal que concuerde con el usado en la pregunta, de modo que si, por ejemplo,preguntaron por aticos, tendremos que generar un sintagma nominal en plural y cu-yo nucleo sea “aticos”, en este caso “estos aticos”. Con esto sustituirıamos el token“Sn” de la base. Si, como puede ocurrir, no hubiese un sintagma nominal con elque concordar, siempre se puede acudir al caso generico de “estas casas”, u omitirlosi la coherencia de la base lo permite. Para completar el token “Carac”, la idea escoger una de todas las caracterısticas que hayan introducido en la pregunta paragenerar un sintagma preposicional que complemente al nombre. Como ocurre conlos problemas de generacion de lenguaje, las tecnicas tienen que ser adaptadas acada caso concreto.

Ambos casos, el de mayor y menor certeza, generan frases diferentes que reflejanel haber encontrado exactamente lo que se pedıa o no. Sin embargo el proceso esel mismo, lo que varıa entre uno y otro es la gramatica que utiliza. De cara a laconstruccion de cada una, se hizo primero un conjunto de posibles respuestas delchatbot para hacernos una idea del tipo de gramatica que habıa que construir. Enfuncion de esto, se agrupan las respuestas que puedan ser generadas con elemen-tos intercambiables en tipos. Cada tipo podra disponer de tokens diferentes, segunpermita la frase. Una vez hecha la gramatica hay dos opciones: se van eligiendo de-rivaciones segun algun criterio hasta que se obtiene una frase, o se generan todas lasfrases posibles de la gramatica y se selecciona una. La segunda opcion es considera-blemente mas lenta cuanto mas crezca la gramatica y aumente el numero de frasescapaz de generar. Conseguir una gramatica con capacidad para generar un numerode respuestas diferentes que ronde las 100 es relativamente sencillo, y si contamosla producidas una vez que se concuerdan con la pregunta inicial, el numero crece engran medida.

Tras desarrollar estos apartados para el chatbot, se llego a la conclusion de queeste metodo por gramaticas y reglas es bastante eficaz en entornos acotados. Losresultados que ofrece son bastante buenos sin requerir un corpus previo. Este metodopuede mejorar enormemente si se desarrolla junto con personas que tengan formacionlinguıstica, ya que se identificaran muchas mas formas de contestar posibles parael chatbot, y las gramaticas generadas seran mucho mas ricas. Aun ası, no es tanseguro que un metodo de generacion por gramaticas sea tan eficaz en entornos masamplios, o que requieran generar texto mas alla de algunas oraciones. Para la pruebade concepto del chatbot ha funcionado satisfactoriamente, pero habrıa que probarloen un caso menos limitado para ver su escalabilidad. En general, es una opcion a

5 Resolucion 46

tener en cuenta dependiendo del contexto.

5.7.2. Redes de Markov

Al empezar con la idea de las redes de Markov, no estaba claro como iban afuncionar. Al ser un metodo que necesita un corpus para funcionar, este tenıa queser hecho a medida para el problema concreto. Como la alternativa era usar frasespredefinidas, tampoco se perdıa nada intentando generar un pequeno corpus paraprobar este metodo, ya que de todas formas esas frases iban a ser utilizadas.

Si nos centramos en el caso de no comprension de la pregunta, las respuestas queva a dar el sistema tienen que ser para comunicar al usuario que no se ha entendidola pregunta, que la formule de nuevo o que intente usar otras palabras. Lo unico quepodemos obtener de la pregunta original son las palabras no comprendidas por lagramatica si las hubiera, ya que tambien puede darse el caso de que se comprendantodas las palabras pero la estructura de estas no sea reconocida. En vista de esto, lounico que podrıa hacerse mas alla de preguntar de nuevo al usuario serıa mostrarleque palabras no se han comprendido, para que pueda parafrasear la pregunta condistintas palabras. Teniendo esto en cuenta, el numero de formas en que podemoscomunicar la no comprension es limitado. Una primera aproximacion a este tipo derespuestas serıan desde frases sencillas como “¿Podrıas repetirme la pregunta?” hastaotras mas complejas como “No estoy seguro de que me has preguntado, ¿podrıaspreguntarmelo de nuevo?”.

Para que la red de buenos resultados, es necesario que se le proporcionen su-ficientes ejemplos para que entrene su modelo probabilıstico. Cuantas mas frasesse le proporcionan, mejora la prediccion de que palabras pueden aparecer antes ydespues de otra. Lo que no estaba claro era el numero mınimo de frases necesariaspara que el rendimiento empezase a ser aceptable. Con las pruebas que se realiza-ron, el sistema requerıa al menos un corpus de alrededor de 50 frases para obtenerresultados aceptables. Esta cifra resulto un tanto inesperada, ya que no se pensabaque el sistema produjera resultados utiles con un corpus tan corto.

La implementacion de esta red se hizo empleando el paquete Markovify de Pyt-hon. Ademas de un corpus, tambien se le puede proporcionar una serie de parametrosque condicionan la generacion de frases: el porcentaje maximo de similitud entre lafrase resultante y las frases originales del corpus y el numero maximo de palabrasque pueden coincidir entre la frase final y las del corpus. A raız de esto, tambien sepuede establecer el numero de intentos que se le da a la red hasta que encuentre unafrase valida que cumpla con los umbrales. Dado que la red tiene capacidad para ge-nerar frases que no se encuentren en el corpus original, se puede ajustar este umbralde similitud para que no haga frases completamente identicas. En nuestro caso, estalimitacion no es necesaria, ya que las respuestas originales del corpus tambien sonvalidas y no hay por que excluirlas. Ademas, las frases en este contexto tienden a sercortas y el porcentaje de similitud se alcanza facilmente, por lo que aun colocandoun umbral de aceptacion elevado el resultado no mejora con respecto a no ponerumbral directamente. El lımite de palabras iguales en cambio si parece ayudar enalgun modo a la generacion de frases distintas. Este da la posibilidad de generar

5 Resolucion 47

las mismas frases cortas que tiene el corpus, pero fomenta la mezcla entre frases albuscar respuestas mas largas.

Al ir realizando pruebas con respecto a tamano del corpus, se fue viendo quela principal desventaja de este modelo es que puede generar frases sin sentido. Altratarse de un modelo probabilıstico, si no se cuenta con el suficiente numero deejemplos puede ocurrir que aparezcan palabras que no deberıan en ese contextodespues de otras. Este problema se daba sobre todo con palabras que tiene bastantevariedad en cuanto a que va antes y despues de ellas. Un ejemplo de nuestro casoconcreto se daba con la palabra “pregunta”, dado que en el corpus inicial aparecıanfrases como “¿Podrıas repetirme la pregunta?” y “¿Puedes hacerme esa pregunta conotras palabras, por favor?”, se podıa dar el caso de que generase una frase como “Nocomprendo la pregunta con otras palabras”. Para solventar este problema, se amplioel corpus poniendo especial atencion a aumentar el numero de frases que empleasencorrectamente la palabra “pregunta”, de modo que el modelo probabilıstico tuviesemas seguro que puede aparecer antes y despues de palabras conflictivas como esta.

5.8. ResultadosTras la aplicacion de las gramaticas deslexicalizadas y las redes de Markov, el

sistema realiza las tareas de comprension y de generacion previstas para el. Los resul-tados de la busqueda de casas se obtienen como vectores numericos para comprobarsu grado de similitud con el tipo de viviendas pedidas. En una version final, serıanecesario guardar el enlace de cada casa devuelta para poder redirigir al usuario a lamisma. Se penso en anadir la direccion de enlace a la hora de hacer el webscraping,pero no merece la pena, ya que el webscraper deberıa ser abandonado para usar laAPI en una version futura.

Los tiempos de ejecucion rondan las centesimas de segundos para el procesocompleto de comprension, busqueda y generacion de una respuesta. En los casos deno comprension, los mas rapidos, los tiempos son de alrededor de 0.01 segundos,mientras que en los casos en los que se puede generar un arbol de derivacion lostiempos varıan de los 0.01 segundos en frases cortas a 0.04 segundos para fraseslargas que contengan 4 caracterısticas o mas, por lo que el tiempo de respuesta delprototipo es adecuado. Habrıa que comprobar el tiempo de respuesta del servidor alas peticiones realizadas a la API para ver el funcionamiento en tiempo real, pero eltratamiento de lenguaje no serıa un inconveniente en este caso.

Fig. 16: Ejecucion del sistema y obtencion de una respuesta segura.

5 Resolucion 48

Fig. 17: Ejemplo de no comprension de una pregunta.

5.9. Etapa finalLlegados a este punto, el sistema cubrıa el recorrido completo desde la entrada de

una pregunta hasta la generacion de una respuesta. Seguıan faltando elementos porcompletar del mismo, como la extension de la gramatica para comprender estruc-turas diferentes como “el mas barato” o frases como “Cuales son los pisos con mashabitaciones en Torrejon”. Tambien hay elementos que no llegaron a implementarse,como un pequeno corrector ortografico que habrıa ayudado al reconocimiento. Faltatambien una interfaz grafica de cara a una version final, la cual irıa de la mano concomo se quieren mostrar los resultados de la busqueda, en este caso procedente dela API y con enlaces a la pagina web. La siguiente etapa de desarrollo serıa anadirestas caracterısticas y proceder a ampliar los recursos del modelo de lenguaje delchatbot, para que mejorase su cobertura.

6 Conclusiones y lıneas futuras 49

6. Conclusiones y lıneas futuras

En conclusion, el sistema desarrollado cumple los objetivos que se plantearonpara el en su ambito reducido. Como prueba de concepto, muestra que se puedenobtener resultados para este tipo de problemas con sistemas conversacionales. Se hanempleado tecnicas vistas en el estado del arte amoldadas al problema concreto. Gra-cias a esto, conseguimos un pequeno sistema que procesa lenguaje natural y es capazde generarlo basandose en las preguntas que le han hecho, devolviendo las posiblesviviendas resultado a estas preguntas. El tiempo de ejecucion total del procesado yla generacion es de menos de un segundo, por lo que su velocidad final dependera deltiempo de respuesta de las queries. Ampliar las gramaticas aumentarıa tambien eltiempo que se tarde en procesado, dado que el sistema cuenta con mas produccionesque explorar de cara a la entrada de una frase nueva. Este es el caso general, ya quesi las nuevas producciones son procesadas despues de las antiguas, no va a afectarvisiblemente a las frases que ya podıan reconocerse. En el caso de la generacion,ampliar las gramaticas en anchura no afecta al tiempo de generacion, y ampliarlasen profundidad no hara que sean notablemente mas lentas. Expandir el corpus de lasredes de Markov hara que tarde mas el entrenamiento del modelo, pero su ejecucionno deberıa verse afectada de manera visible a no ser que crezca desmesuradamenteel numero de palabras con las que cuenta la red. Las lıneas futuras de desarrollo delchatbot deberıan orientarse a mejorar su cobertura, buscando asistencia linguısticapara encontrar el mayor numero de posibles preguntas que puedan entrar al chatboty poder expandir la gramatica y la lista de stopwords. Tambien es de importanciaampliar el corpus inicial de las redes de Markov para mejorar su rendimiento. Fi-nalmente, para una presentacion final de cara al publico es necesaria una interfazgrafica adecuada.

La cobertura y flexibilidad del chatbot no es la ideal de cara a problemas demayor envergadura, pero utilizando las alternativas de diseno propuestas se podrıanabordar. Realizar el cambio de la base de datos para que funcione en tiempo real nosupondrıa un gran contratiempo, dado que es mas un problema de como hacer lasconsultas que de como generar estas. El sistema de generacion de los vectores de lasviviendas serıa el mismo, habrıa que adaptar el tratamiento que dichos vectores. Estoya no serıa un problema de procesado de lenguaje. Por otra parte, la situacion detener que comprender una pregunta para buscar su respuesta es un caso comun al queeste chatbot sirve como iniciacion. En problemas mas complejos, la implementaciondel mismo probablemente no fuese la mas adecuada, pero la estructura del mismosirve como una primera aproximacion.

En cuanto a la investigacion actual en generacion de lenguaje, la direccion masinvestigada es la orientada a la aplicacion de aprendizaje automatico. Sin embargo,esta aplicacion no es necesariamente superior a los metodos tradicionales. El prin-cipal problema al que se suelen enfrentar estas tecnicas es la necesidad que tienende un corpus previo de ejemplos. Este corpus, ademas de tener que ser extenso pa-ra garantizar unos resultados buenos, debe ser adecuado al problema que se estetratando, cosa que no es facil de conseguir en todos los casos. Si tomamos como


referencia el problema tratado en el chatbot de la tesis, el corpus necesario estaacotado al ambito de generar respuestas para un tipo de preguntas concreto. Enun entorno ası, la mejor opcion serıa la de construir tu propio corpus, y habrıa quevalorar si esto merece el esfuerzo o no. En otros ambitos, como en la traduccionautomatica bidireccional, es mas comun la existencia de corpus alineados entre dosidiomas de los mas hablados. Sin embargo, es muy probable que, si se encuentraalguno adecuado, haya que expandirlo para especializarlo en el entorno en el que sevaya a mover. Con esto, se ve que los metodos mas nuevos basados en aprendizajeautomatico pueden dar resultados muy buenos si se cuenta con los recursos parahacerlos funcionar y se pueden adaptar bien al contexto, pero es importante seguirdesarrollando metodos que no esten atados a estas restricciones.

Otro problema que se ve de cara al contexto actual de la generacion de lenguaje esla poca informacion real que se da de la implementacion de los metodos presentados,ası como la escasa cantidad de nuevos estudios en este ambito. Parece que, mas quetratarse de un ambito

Las lıneas futuras de la investigacion en generacion de lenguaje parecen centrar-se mas en la resolucion de problemas especıficos que en la generacion de nuevosmetodos, dada la dependencia de estos del problema que se tenga a mano. Tambienha habido cierto aumento de interes en el area de NLG como resultado de otrosproblemas diferentes. Este es el caso por ejemplo de la generacion de descripcionesde imagenes, donde el problema principal es la identificacion de objetos dentro deuna foto pero tambien hace falta un modelo de generacion para crear las frases enlenguaje natural, o los problemas de NLU como los propios chatbots o la traduccionautomatica, donde la generacion es uno de los varios problemas que surgen. Pareceque el futuro de la investigacion en generacion de lenguaje natural esta mas orientadaa este ultimo caso de tratar problemas que no son exclusivamente de generacion.


ANEXOS


Referencias

[1] Althaus, E., Karamanis, N., & Koller, A. (2004, July). Computing locally cohe-rent discourses. In proceedings of the 42nd Annual Meeting on Association forComputational Linguistics (p. 399). Association for Computational Linguistics.

[2] Barzilay, R., & Lapata, M. (2006, June). Aggregation via set partitioning fornatural language generation. In Proceedings of the main conference on HumanLanguage Technology Conference of the North American Chapter of the Associa-tion of Computational Linguistics (pp. 359-366). Association for ComputationalLinguistics.

[3] Bateman, J. A. (1997). Enabling technology for multilingual natural languagegeneration: the KPML development environment. Natural Language Enginee-ring, 3(1), 15-55.

[4] Belz, A., & Reiter, E. (2006). Comparing automatic and human evaluation ofNLG systems. In 11th Conference of the European Chapter of the Associationfor Computational Linguistics.

[5] Belz, A. (2008). Automatic generation of weather forecast texts using com-prehensive probabilistic generation-space models. Natural Language Enginee-ring, 14 (4), 431-455.

[6] Berg, M. M., Isard, A., & Moore, J. D. (2013, June). An OpenCCG-basedapproach to question generation from concepts. In International Conference onApplication of Natural Language to Information Systems (pp. 38-52). Springer,Berlin, Heidelberg.

[7] Bobrow, D. G., Kaplan, R. M., Kay, M., Norman, D. A., Thompson, H., &Winograd, T. (1977). GUS, A frame driven dialog system. Artificial Intelligence,8, 155–173.

[8] Bozsahin, C., Kruijff, G. J. M., & White, M. (2005). Specifying grammars forOpenCCG: A rough guide. Included in the OpenCCG distribution.

[9] Callaway, C. B., & Lester, J. C. (2002). Narrative prose generation. ArtificialIntelligence, 139 (2), 213-252.

[10] Celikyilmaz, A., Deng, L., & Hakkani-Tur, D. (2018). Deep Learning in Spo-ken and Text-Based Dialog Systems. In Deep Learning in Natural LanguageProcessing (pp. 49-78). Springer, Singapore.

[11] Cheng, H., & Mellish, C. (2000, June). Capturing the interaction between ag-gregation and text planning in two generation systems. In Proceedings of thefirst international conference on Natural language generation-Volume 14 (pp.186-193). Association for Computational Linguistics.


[12] Conde-Clemente, P., Trivino, G., & Alonso, J. M. (2017). Generating automaticlinguistic descriptions with big data. Information Sciences, 380, 12-30.

[13] Conde-Clemente, P., Alonso, J. M., & Trivino, G. (2018). Toward automatic ge-neration of linguistic advice for saving energy at home. Soft Computing, 22 (2),345-359.

[14] Conde-Clemente, P., Alonso, J. M., & Trivino, G. (2017, July). rLDCP: Rpackage for text generation from data. In Fuzzy Systems (FUZZ-IEEE), 2017IEEE International Conference on (pp. 1-6). IEEE.

[15] Dale, R., & Reiter, E. (1995). Computational interpretations of the Griceanmaxims in the generation of referring expressions. Cognitive science, 19 (2),233-263.

[16] Dale, R. (1989, June). Cooking up referring expressions. In Proceedings of the27th annual meeting on Association for Computational Linguistics (pp. 68-75).Association for Computational Linguistics.

[17] Dalianis, H. (1999). Aggregation in natural language generation. ComputationalIntelligence, 15 (4), 384-414.

[18] Deemter, K. V., Theune, M., & Krahmer, E. (2005). Real versus template-basednatural language generation: A false opposition?. Computational Linguistics,31 (1), 15-24.

[19] Deng, L. (2017). Three generations of spoken dialogue systems (bots), talkat AI Frontiers Conference. https://www.slideshare.net/AIFrontiers/li-deng-three-generations-of-spoken-dialogue-systems-bots.

[20] Doddington, G. (2002, March). Automatic evaluation of machine translationquality using n-gram co-occurrence statistics. In Proceedings of the second in-ternational conference on Human Language Technology Research (pp. 138-145).Morgan Kaufmann Publishers Inc..

[21] Eciolaza, L., Pereira-Farina, M., & Trivino, G. (2013). Automatic linguisticreporting in driving simulation environments. Applied Soft Computing, 13 (9),3956-3967.

[22] Gatt, A., & Krahmer, E. (2018). Survey of the State of the Art in Natural Lan-guage Generation: Core tasks, applications and evaluation. Journal of ArtificialIntelligence Research, 61, 65-170.

[23] Gatt, A., & Reiter, E. (2009, March). SimpleNLG: A realisation engine forpractical applications. In Proceedings of the 12th European Workshop on NaturalLanguage Generation (pp. 90-93). Association for Computational Linguistics.

[24] Goldberg, E., Driedger, N., & Kittredge, R. I. (1994). Using natural-languageprocessing to produce weather forecasts. IEEE Expert, 9 (2), 45-53.


[25] Hakkani-Tur, D., Tur, G., Celikyilmaz, A., Chen, Y. N., Gao, J., Deng, L., &Wang, Y. Y. (2016, June). Multi-Domain Joint Semantic Frame Parsing UsingBi-Directional RNN-LSTM. In Interspeech (pp. 715-719).

[26] Hockenmaier, J., & Steedman, M. (2007). CCGbank: a corpus of CCG deriva-tions and dependency structures extracted from the Penn Treebank. Compu-tational Linguistics, 33 (3), 355-396.

[27] Jones, K. S., & Galliers, J. R. (1995). Evaluating natural language processingsystems: An analysis and review (Vol. 1083). Springer Science & Business Me-dia.

[28] Jurafsky, D., & Martin, J. H. (2017). Speech and language processing (3rd ed.draft). Prentice Hall.

[29] Kacprzyk, J., & Zadrozny, S. (2010). Computing with words is an implemen-table paradigm: fuzzy queries, linguistic data summaries, and natural-languagegeneration. IEEE Transactions on Fuzzy Systems, 18 (3), 461-472.

[30] Kacprzyk, J., & Yager, R. R. (2001). Linguistic summaries of data using fuzzylogic. International Journal of General System, 30 (2), 133-154.

[31] Kasper, R., & Whitney, R. (1989). SPL: A sentence plan language for textgeneration. University of Southern California.

[32] Kluwer, T. (2011). From chatbots to dialog systems. International Journal,1-22.

[33] Kondadadi, R., Howald, B., & Schilder, F. (2013). A statistical nlg frameworkfor aggregated planning and realization. In Proceedings of the 51st Annual Mee-ting of the Association for Computational Linguistics (Volume 1: Long Papers)(Vol. 1, pp. 1406-1415).

[34] Krahmer, E., & Van Deemter, K. (2012). Computational generation of referringexpressions: A survey. Computational Linguistics, 38 (1), 173-218.

[35] Langkilde-Geary, I. (2002). An empirical verification of coverage and correctnessfor a general-purpose sentence generator. In Proceedings of the internationalnatural language generation conference (pp. 17-24).

[36] Lee, C., Jung, S., Kim, S., & Lee, G. G. (2009). Example-based dialog modelingfor practical multi-domain dialog system. Speech Communication, 51 (5), 466-484.

[37] Li, Y. (2017). Deep reinforcement learning: An overview. arXiv preprint ar-Xiv:1701.07274.


[38] Lin, C. Y., & Hovy, E. (2003, May). Automatic evaluation of summaries usingn-gram co-occurrence statistics. In Proceedings of the 2003 Conference of theNorth American Chapter of the Association for Computational Linguistics onHuman Language Technology-Volume 1 (pp. 71-78). Association for Compu-tational Linguistics.

[39] Mann, W. C., & Thompson, S. A. (1987). Rhetorical structure theory: A theoryof text organization (pp. 87-190). University of Southern California, InformationSciences Institute.

[40] Mellish, C., Scott, D., Cahill, L., Paiva, D., Evans, R., & Reape, M. (2006). Areference architecture for natural language generation systems. Natural langua-ge engineering, 12 (1), 1-34.

[41] Mencar, C., & Fanelli, A. M. (2008). Interpretability constraints for fuzzy in-formation granulation. Information Sciences, 178 (24), 4585-4618.

[42] Niewiadomski, A. (2008). A type-2 fuzzy approach to linguistic summarizationof data. IEEE Transactions on Fuzzy Systems, 16 (1), 198-212.

[43] Oh, A. H., & Rudnicky, A. I. (2000, May). Stochastic language generation forspoken dialogue systems. In Proceedings of the 2000 ANLP/NAACL Workshopon Conversational systems-Volume 3 (pp. 27-32). Association for Computatio-nal Linguistics.

[44] Papineni, K., Roukos, S., Ward, T., & Zhu, W. J. (2002, July). BLEU: a met-hod for automatic evaluation of machine translation. In Proceedings of the 40thannual meeting on association for computational linguistics (pp. 311-318). As-sociation for Computational Linguistics.

[45] Portet, F., Reiter, E., Gatt, A., Hunter, J., Sripada, S., Freer, Y., & Sykes,C. (2009). Automatic generation of textual summaries from neonatal intensivecare data. Artificial Intelligence, 173 (7-8), 789-816.

[46] Quarteroni, S., & Manandhar, S. (2009). Designing an interactive open-domainquestion answering system. Natural Language Engineering, 15 (1), 73-95.

[47] Ramos-Soto, A., Bugarin, A. J., Barro, S., & Taboada, J. (2015). Linguisticdescriptions for automatic generation of textual short-term weather forecastson real prediction data. IEEE Transactions on Fuzzy Systems, 23 (1), 44-57.

[48] Reiter, E., & Dale, R. (2000). Building natural language generation systems.Cambridge university press.

[49] Reiter, E. (2007, June). An architecture for data-to-text systems. In Proceedingsof the Eleventh European Workshop on Natural Language Generation (pp. 97-104). Association for Computational Linguistics.


[50] Reiter, E., Sripada, S., Hunter, J., Yu, J., & Davy, I. (2005). Choosing words incomputer-generated weather forecasts. Artificial Intelligence, 167(1-2), 137-169.

[51] Reiter, E. (1995). NLG vs. templates. arXiv preprint cmp-lg/9504013.

[52] Reiter, E., Robertson, R., & Osman, L. M. (2003). Lessons from a failure:Generating tailored smoking cessation letters. Artificial Intelligence, 144 (1-2),41-58.

[53] Sanchez-Valdes, D., Alvarez-Alvarez, A., & Trivino, G. (2013). Linguistic des-cription about circular structures of the Mars’ surface. Applied Soft Computing,13 (12), 4738-4749.

[54] Serban, I. V., Sankar, C., Germain, et al. (2017). A deep reinforcement learningchatbot. arXiv preprint arXiv:1709.02349.

[55] Soto, A. R., Gallardo, J. J., & Diz, A. B. (2017). Adapting SimpleNLG to Spa-nish. In Proceedings of the 10th International Conference on Natural LanguageGeneration (pp. 144-148).

[56] Stent, A., & Bangalore, S. (Eds.). (2014). Natural language generation in in-teractive systems. Cambridge University Press.

[57] Sripada, S., Reiter, E., & Davy, I. (2003). SumTime-Mousam: Configurablemarine weather forecast generator. Expert Update, 6(3), 4-10.

[58] Weizenbaum, J. (1966). ELIZA – A computer program for the study of naturallanguage communication between man and machine. Communications of theACM, 9 (1), 36–45.

[59] Wen, T. H., Gasic, M., Kim, D., Mrksic, N., Su, P. H., Vandyke, D., & Young, S.(2015). Stochastic language generation in dialogue using recurrent neural net-works with convolutional sentence reranking. arXiv preprint arXiv:1508.01755.

[60] Wen, H., Liu, Y., Che, W., Qin, L., & Liu, T. (2018). Sequence-to-SequenceLearning for Task-oriented Dialogue with Dialogue State Representation. arXivpreprint arXiv:1806.04441.

[61] White, M. (2006, July). CCG chart realization from disjunctive inputs. In Pro-ceedings of the Fourth International Natural Language Generation Conference(pp. 12-19). Association for Computational Linguistics.

[62] Williams, S., & Reiter, E. (2008). Generating basic skills reports for low-skilledreaders. Natural Language Engineering, 14 (4), 495-525.

[63] Young, R. M. (1999). Using Grice’s maxim of quantity to select the content ofplan descriptions. Artificial Intelligence, 115 (2), 215-256.


[64] Young, S., Gasic, M., Thomson, B., & Williams, J. D. (2013). Pomdp-basedstatistical spoken dialog systems: A review. Proceedings of the IEEE, 101 (5),1160-1179.

[65] Yu, J., Reiter, E., Hunter, J., & Sripada, S. (2003, June). SumTime-turbine:a knowledge-based system to communicate gas turbine time-series data. In In-ternational Conference on Industrial, Engineering and Other Applications ofApplied Intelligent Systems (pp. 379-384). Springer, Berlin, Heidelberg.

[66] Zadeh, L. A. (1996). Fuzzy logic = computing with words. IEEE transactionson fuzzy systems, 4 (2), 103-111.

generaci´on de lenguas basada en conocimiento...

Documents