revista latinoamericana de ingenieria de...

REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE ABRIL 2014 VOLUMEN 2 NUMERO 2 ISSN 2314-2642

PUBLICADO POR EL GISI-UNLa

EN COOPERACIÓN POR LOS MIEMBROS DE LA RED DE INGENIERÍA DE SOFTWARE DE LATINOAMÉRICA

ARTÍCULOS TÉCNICOS Guía para la Reingeniería de Sistemas Legados: Una Experiencia Práctica y Real Franco Bianchiotti y Sandra Casas

99-106

Desarrollo de un Sistema de Recuperación de Información para Publicaciones Científicas del Área de Ciencias de la Computación Horacio Kuna, Martin Rey, Esteban Martini, Lisandro Solonezen1, Lucas Podkowa

107-114

Comportamiento Adaptable de Chatbots Dependiente del Contexto Juan Manuel Rodríguez, Hernán Merlino, Enrique Fernández

115-136

REVISTA LATINAMERICANA

DE INGENIERIA DE SOFTWARE

La Revista Latinoamericana de Ingenieria del Software es una publicación tecnica auspiciada por la Red de Ingeniería de Software de Latinoamérica (RedISLA). Busca: [a] difundir artículos técnicos, empíricos y teóricos, que resulten críticos en la actualización y fortalecimiento de la Ingeniería de Software Latinoamericana como disciplina y profesión; [b] dar a conocer de manera amplia y rápida los desarrollos científico-tecnológicos en la disciplina de la región latinoamericana; y [c] contribuir a la promoción de la cooperación institucional entre universidades y empresas de la Industria del Software. La línea editorial, sin ser excluyente, pone énfasis en sistemas no convencionales, entre los que se prevén: sistemas móviles, sistemas, plataformas virtuales de trabajo colaborativo, sistemas de explotación de información (minería de datos), sistemas basados en conocimiento, entre otros; a través del intercambio de información científico y tecnológica, conocimientos, experiencias y soluciones que contribuyan a mejorar la cadena de valor del desarrollo en la industria del software.

Comité Editorial

RAUL AGUILAR VERA (México) Cuerpo Academico de Ingenieria de Software

Facultad de Matemáticas Universidad Autonoma de Yucatán

PAOLA BRITOS (Argentina)

Grupo de Ingeniería de Explotación de Información Laboratorio de Informática Aplicada Universidad Nacional de Río Negro

RAMON GARCÍA-MARTINEZ (Argentina)

Grupo de Investigación en Sistemas de Información Licenciatura en Sistemas

Departamento de Desarrollo Productivo y Tecnológico Universidad Nacional de Lanús

ALEJANDRO HOSSIAN (Argentina)

Grupo de Investigación de Sistemas Inteligentes en Ingeniería

Facultad Regional del Neuquén Universidad Tecnológica Nacional

BELL MANRIQUE LOSADA (Colombia) Programa de Ingeniería de Sistemas

Facultad de Ingeniería Universidad de Medellín

CLAUDIO MENESES VILLEGAS (Chile)

Departamento de Ingeniería de Sistemas y Computación Facultad de Ingeniería y Ciencias Geológicas

Universidad Católica del Norte

JONÁS MONTILVA C. (Venezuela) Facultad de Ingeniería

Escuela de Ingeniería de Sistemas Universidad de Los Andes

MARÍA FLORENCIA POLLO-CATTANEO (Argentina)

Grupo de Estudio en Metodologías de Ingeniería de Software

Facultad Regional Buenos Aires Universidad Tecnológica Nacional

JOSÉ ANTONIO POW-SANG (Perú) Maestría en Informática

Pontifica Universidad Católica del Perú

DIEGO VALLESPIR (Uruguay) Instituto de Computación

Universidad de la Republica

FABIO ALBERTO VARGAS AGUDELO (Colombia) Dirección de Investigación Tecnológico de Antioquia

CARLOS MARIO ZAPATA JARAMILLO (Colombia)

Departamento de Ciencias de la Computación y de la Decisión

Facultad de Minas Universidad Nacional de Colombia

Contacto

Dirigir correspondencia electrónica a:

Editor de la Revista Latinoamericana de Ïngenieria de Software RAMON GARCIA-MARTINEZ e-mail: [email protected]

e-mail alternativo: [email protected] Página Web de la Revista: http://www.unla.edu.ar/sistemas/redisla/ReLAIS/index.htm

Página Web Institucional: http://www.unla.edu.ar

Dirigir correspondencia postal a:

Editor de la Revista Latinoamericana de Ïngenieria de Software RAMON GARCIA-MARTINEZ Licenciatura en Sistemas. Departamento de Desarrollo Productivo y Tecnológico Universidad Nacional de Lanus Calle 29 de Septiembre No 3901. (1826) Remedios de Escalada, Lanús. Provincia de Buenos Aires. ARGENTINA.

Normas para Autores

Cesión de Derechos de Autor Los autores toman conocimiento y aceptan que al enviar una contribución a la Revista Latinoamericana de Ingenieria del Software, ceden los derechos de autor para su publicación electrónica y difusión via web por la Revista. Los demas derechos quedan en posesión de los Autores.

Políticas de revisión, evaluación y formato del envío de manuscritos La Revista Latinoamericana de Ingenieria del Software recibe artículos inéditos, producto del trabajo de investigación y reflexión de investigadores en Ingenieria de Software. Los artículos deben presentarse redactados en el castellano en el formato editorial de la Revista. El incumplimiento del formato editorial en la presentación de un artículo es motivo de retiro del mismo del proceso de evaluación. Dado que es una publicación electrónica no se imponen limites sobre la cantidad de paginas de las contribuciones enviadas. También se pueden enviar comunicaciones cortas que den cuenta de resultados parciales de investigaciones en progreso. Las contribuciones recibidas están sujetas a la evaluación de pares. Los pares que evaluaran cada contribución son seleccionados por el Comité Editorial. El autor que envíe la contribución al contacto de la Revista será considerado como el autor remitente y es con quien la revista manejará toda la correspondencia relativa al proceso de evaluación y posterior comunicación. Del proceso de evaluación, el articulo enviado puede resultar ser: [a] aceptado, en cuyo caso será publicado en el siguiente numero de la revista, [b] aceptado con recomendaciones, en cuyo caso se enviará al autor remitente la lista de recomendaciones a ser atendidas en la nueva versión del articulo y su plazo de envio; ó [c] rechazado, en cuyo caso será devuelto al autor remitente fundando el motivo del rechazo.

Temática de los artículos La Revista Latinoamericana de Ingeniería del Software busca artículos empíricos y teóricos que resulten críticos en la actualización y fortalecimiento de la Ingeniería de Software Latinoamericana como disciplina y profesión. La línea editorial pone énfasis en sistemas no convencionales, entre los que se prevén: sistemas móviles, sistemas multimediales vinculados a la televisión digital, plataformas virtuales de trabajo colaborativo, sistemas de explotación de información (minería de datos), sistemas basados en conocimiento, entre otros. Se privilegiarán artículos que contribuyan a mejorar la cadena de valor del desarrollo en la industria del software.

Política de Acceso Abierto La Revista Latinoamericana de Ingeniería de Software: Sostiene su compromiso con las políticas de Acceso Abierto a la información científica, al

considerar que tanto las publicaciones científicas como las investigaciones financiadas con fondos públicos deben circular en Internet en forma libre, gratuita y sin restricciones.

Ratifica el modelo de Acceso Abierto en el que los contenidos de las publicaciones científicas se encuentran disponibles a texto completo libre y gratuito en Internet, sin embargos temporales, y cuyos costos de producción editorial no son transferidos a los autores.

No retiene los derechos de reproducción o copia (copyright), por lo que los autores podrán disponer de las versiones finales de publicación, para difundirlas en repositorios institucionales, blogs personales o cualquier otro medio electrónico, con la sola condición de hacer mención a la fuente original de publicación, en este caso Revista Latinoamericana de Ingeniería de Software.

Lista de Comprobación de Preparación de Envíos Como parte del proceso de envío, se les requiere a los autores que indiquen que su envío cumpla con todos los siguientes elementos, y que acepten que envíos que no cumplan con estas indicaciones pueden ser devueltos al autor: 1. La contribución respeta el formato editorial de la Revista Latinoamericana de Ingenieria del

Software (ver plantilla). 2. Actualidad/Tipo de referencias: El 45% de las referencias debe hacerse a trabajos de publicados

en los últimos 5 años, así como a trabajos empíricos, para cualquier tipo de artículo (empírico o teórico).

3. Características artículos empíricos (análisis cuantitativo de datos): Se privilegian artículos empíricos con metodologías experimentales y cuasi experimentales, con pruebas estadísticas robustas y explicitación del cumplimiento de los supuestos de las pruebas estadísticas usadas.

4. Características artículos empíricos (análisis cualitativo de datos): Se privilegian artículos empíricos con estrategias de triangulación teórica-empírica, definición explícita de categorías orientadoras, modelo teórico de análisis, y análisis de datos asistido por computadora.

5. Características artículos de revisión: Para el caso de artículos de revisión, se evaluará que los mismos hayan sido desarrollados bajo el formato de meta análisis, la cantidad de referencias deben superar las 50, y deben explicitarse los criterios de búsqueda, bases consultadas y pertinencia disciplinar del artículo.

6. El artículo (en formato word y pdf) se enviará adjunto a un correo electrónico dirigido al contacto de la Revista en el que deberá constar la siguiente información: dirección postal del autor, dirección de correo electrónico para contacto editorial, número de teléfono y fax, declaración de que el artículo es original, no ha sido previamente publicado ni está siendo evaluado por otra revista o publicación. También se debe informar de la existencia de otras publicaciones similares escritas por el autor y mencionar la versión de la aplicación de los archivos remitidos (versión del editor de texto y del conversor a archivo pdf) para la publicación digital del artículo.

7. Loa Autores aceptan que el no cumplimiento de los puntos anteriores es causal de No Evaluación del articulo enviado.

Compromiso de los Autores de Artículos Aceptados La Revista Latinoamericana de Ingeniería del Software busca ser una revista técnica de calidad, en cuyo desarrollo estén involucrados los investigadores y profesionales latinoamericanos de la disciplina. En este contexto, los Autores de artículos aceptados asumen ante la Revista y la Comunidad Latinoamericana de Ingeniería del Software el compromiso de desempeñarse como pares evaluadores de nuevas contribuciones.

Bianchiotti, F., Casas, S. 2014. Guía para la Reingeniería de Sistemas Legados: una Experiencia Práctica y Real Revista Latinoamericana de Ingeniería de Software, 2(2): 99-106, ISSN 2314-2642

99

Guía para la Reingeniería de Sistemas Legados: Una Experiencia Práctica y Real

Franco Bianchiotti Departamento de Informática

Administración General de Vialidad Provincial Río Gallegos, Argentina [email protected]

Sandra Casas Instituto de Tecnología Aplicada

Universidad Nacional de la Patagonia Austral Río Gallegos, argentina

[email protected]

Resumen—Este trabajo presenta una experiencia real de

reingeniería de sistemas legados. La misma tuvo lugar en la Administración General de Vialidad Provincial (Santa Cruz) y demandó aproximadamente un año de trabajo. El proyecto de reingeniería tuvo dos objetivos muy concretos: a) desarrollar un marco de trabajo de reingeniería que se adecuara a los sistemas legados de la organización con la finalidad de poder ser replicado a otros sistemas legados de la organización. Este objetivo dio por resultado la elaboración de una guía para su posterior reutilización a estos contextos. b) su aplicación a uno de los sistemas legados de la organización. En esta primera instancia se aplicó al sistema de Patrimonio.

Palabras Clave—Sistemas legados, reingeniería, migración, mantenimiento.

I. INTRODUCCION Pragmáticamente los sistemas legados se han definido

como “software que es vital para la organización, pero no se sabe qué hacer con él” [1]. Los sistemas legados son uno de los principales problemas del mantenimiento de software. A pesar que la crisis Y2K forzó a muchas organizaciones a sustituir los sistemas antiguos, existe aún software que supera los 20 años. Se trata de software monolítico, dividido en subsistemas que cumplen funciones importantes para las organizaciones, pero de los cuales no se dispone documentación, los desarrolladores originales ya no trabajan en la organización y solo se dispone de los códigos fuentes e incluso en algunos casos ni siquiera eso.

Aunque tecnologías más modernas (aplicaciones cliente-servidor, BD relacionales, tecnologías OO / componentes, etc.) suponen mayor facilidad de mantenimiento y además ofrecen mas oportunidades, ocurre que el ciclo de vida de los sistemas se extiende más de lo debido. Sneed [2] afirma que las empresas no invierten recursos en ingeniería inversa o reingeniería a las nuevas tecnologías sobre la base de que los costes de mantenimiento son menores. Sin embargo, en un punto el mantenimiento adaptativo [3] obliga a realizar el mayor esfuerzo y más riesgoso, el desarrollo de un nuevo sistema, la migración de los datos, la recuperación de la lógica de negocios, es decir una reingeniería [4]. Los procesos de reingeniería son complejos, y no existen formulas preestablecidas que se puedan aplicar con éxito a todos los casos, por otro lado conllevan una importante carga de trabajo manual, aún cuando se puedan utilizar herramientas que automaticen ciertas actividades.

Este trabajo presenta una experiencia real de reingeniería de sistemas legados. La misma tuvo lugar en la Administración General de Vialidad Provincial (Santa Cruz) y demandó

aproximadamente un año de trabajo. El proyecto de reingeniería tuvo dos objetivos muy concretos: a) desarrollar un proceso de reingeniería que se adecuara los sistemas legados de la organización con la finalidad de poder ser replicado a otros sistemas legados de la misma. Este objetivo dio por resultado la elaboración de una guía para su posterior reutilización a estos contextos. b) su aplicación a uno de los sistemas legados de la organización.

La guía de reingeniería que se expone es un marco de trabajo, un conjunto de lineamiento que ordenan y organizan tareas, actividades y artefactos, con el objeto de administrar y conducir el proceso de migrar estos sistemas. Teniendo en cuenta que ha sido elaborada y usada en las siguientes condiciones: inexistencia de documentación alguna de los sistemas, ausencia del 30% de los códigos fuentes, diferencia entre el lenguaje de programación del actual y futuro sistema, como también en el soporte al modelo de datos.

Este artículo tiene la siguiente estructura: en la Sección II se exponen las motivaciones del trabajo, en la Sección III se describe el proyecto de reingeniería, en la Sección IV se presenta la Guía, en la Sección V su aplicación al sistema de Patrimonio, en la Sección VI se presentan algunos trabajos relacionados y finalmente las conclusiones y trabajos futuros.

II. MOTIVACIONES La Administración General de Vialidad Provincial (AGVP)

de la Pcia. de Santa Cruz, está facultada a administrar e invertir los fondos afectados para el estudio, trazado, construcción, mejoramiento y conservación de caminos y obras anexas en la red de caminos de su jurisdicción. Las tareas y funciones operativas, técnicas y administrativas se llevan a cabo en toda la pcia., a través de 7 distritos y la sede central, en los que se divide y/o compone la estructura. Los distritos se asientan en las localidades de Río Gallegos, Cmdte. Luis Piedra Buena, Puerto Deseado, Las Heras, Perito Moreno, Gdor. Gregores y El Calafate y la Casa Central, sita en la ciudad de Río Gallegos.

Se cuenta con diversas aplicaciones desarrolladas por la Dirección de Informática (Casa Central), que permiten el cumplimiento de sus funciones tales como Patrimonio (S1), Contabilidad (S2), Pago a proveedores (S3), Complementarias de sueldos (S4), Ordenes de Trabajo SC (S5), Viáticos SC (S6), Personal SC (S7) Asistencia SC (S8), Depósito SC (S9), Expedientes (S10), Viáticos Distritos (S11), Sueldos (S12), Judiciales (S13), Certificados (S14), Infracciones (S15), Convenios (S16) y Cargas (S17).

El primer sistema que se estudio fue el de Patrimonio (S1) y se identificaron las siguientes deficiencias y problemas de mantenimiento:


100

- Portabilibilidad: El sistema se ejecutaba originalmente bajo el sistema operativo D.O.S., por lo cual y conforme a la evolución de los sistemas operativos, el sistema de Patrimonio solo es compatible con la versión de Windows 98. Debido a que fue la última versión de Windows que posibilita la configuración manual de la memoria extendida, imprescindible para su funcionamiento. (D1)

- Impresión de formularios y reportes restringidos a impresoras de matriz de punto. (D2)

- Es un sistema mono-usuario que es utilizado en distintos puntos geográficos (distritos) de la pcia. y la actualización de sus datos son centralizados en el distrito central (Río Gallegos) utilizando diskette 3¼ o CD, lo que no permite contar con la información en tiempo real. (D3)

- Seguridad: No existe ningún esquema de seguridad en el sistema mediante autorización y autentificación de usuarios, lo cual se agrava dado que los archivos de datos (DBF) son fácilmente accesibles y modificables con herramientas tales como Excel.(D4)

- Falta de Código Fuente: Con el transcurso del tiempo y el traspaso de los archivos de un equipo a otro, debido a la actualización del equipamiento informático, varios códigos fuentes se extraviaron quedando solo los archivos compilados. (D5)

- Lenguaje en desuso: el software ha sido desarrollado en un lenguaje y con herramientas en desuso, utilizando técnicas y estilos de programación distintos a los actuales. (D6)

- Código: El código existente presenta varios síntomas indeseables que afectan su legibilidad y por ende su mantenimiento: modularización del código baja; presencia de segmentos de código repetido; uso abusivo de variables globales; designación de nombres de variables y módulos no significativos; bucles no estructurados, etc. (D7)

- Inexistencia de documentación técnica. (D8)

- Inexistencia de documentación operativa del sistema. (D9)

En la Tabla 1 se presenta el análisis que se llevó a cabo sobre los problemas observados (D1 a D9) en el sistema de Patrimonio y su existencia en los restantes sistemas de la organización (S2 a S17). Dicho análisis indica que la reingeniería debe ser aplicada a varios sistemas y por ende el proyecto debe comprender dos aspectos, la elaboración de un marco de trabajo adecuado y específico que pueda ser replicado, y su aplicación a cada una de las instancias (sistemas).

La decisión de migrar, aplicando una reingeniería los sistemas de AGVP, en lugar de desarrollar desde cero las aplicaciones, responden al hecho que los sistemas cuentan con la funcionalidad requerida para realizar las tareas de las áreas donde se encuentran instalados, cumpliendo además con la mayoría de los requerimientos de los usuarios. Debido al tiempo transcurrido desde su implementación, se encuentran suficientemente probados y los usuarios perfectamente adaptados a los mismos, pero las nuevas tecnologías de hardware y software obligan a realizar una reconstrucción de dichas aplicación como así también de los datos.

Se ha indicado al lenguaje de programación en desuso como una deficiencia, específicamente los sistemas señalados de

AGVP fueron codificados con herramientas xBase. Las aplicaciones que responden al modelo conocido como xBase (DBase III+, DBase IV, FoxPro para DOS/Window, Clipper, etc.) tuvieron gran auge en las décadas de los 80 y 90.

TABLA I. ANÁLISIS DE DEFICIENCIAS EN LOS SISTEMAS DE AGVP

D1 D2 D3 D4 D5 D6 D7 D8 D9 S1 X X X X X X X X X S2 X X X X X X X X X S3 X X X X X X X X X S4 X X X X X X X X X S5 - - X X - X X X X S6 - - X X - X X X - S7 - - X X - X X X X S8 - - X X - X X X X S9 - - X X - X X - X S10 - - X X - X X X X S11 - - X X - X X - X S12 - - X X - X X X X S13 - - X X - - - X X S14 - - X X - - - X X S15 - - X X - X X X X S16 - - X X - X X X X S17 - - X X - X X X X

Estas herramientas fueron acuñadas por los programadores,

por su facilidad de programación y manejo de ficheros (DBF) en microordenadores (PCs), en contraposición a otras herramientas de programación de la época (C, Cobol, Basic). Sin embargo la irrupción de internet, las intranets, BD relacionales, lenguajes de script, tecnologías OO y/o componentes jaquearon las bondades xBase. La falta de oportunidades está dada principalmente en aspectos como la portabilidad, escalabilidad, seguridad, procesamiento multiusuario, etc.

III. PROYECTO DE REINGENIERIA Como ilustra la Fig. 1, el proyecto de reingeniería se

planteo en dos etapas principales. La primer etapa del proyecto estuvo destina a la recolección de información y análisis de métodos, técnicas y herramientas de ingeniería inversa, reingeniería y migración de software y/o sistemas legados. Así en la Etapa 1 del proyecto, se analizaron los modelos de reingeniería de Sommerville [5], SICUMA [6], el modelo Herradura [7] y el modelo Cíclico [8]. Finalmente se decidió tomar como punto de partida el modelo Cíclico, el cual resulta ser bastante conocido y utilizado, y debido a que ofrecía mayor confiabilidad. Este modelo consta de una secuencia de seis etapas bien estructuradas, que hacen posible practicar la reingeniería de software de manera que genere resultados más concretos. Las seis etapas que define son, (i) Análisis de Inventario, (ii) Reestructuración de documentos, (iii) Ingeniería Inversa; (iv) Reestructuración de código, (v) Reestructuración de datos, y (vi) Ingeniería Directa. Estas etapas se pueden realizar de forma secuencial, pero también es posible que estas se puedan repetir generando un ciclo. Estas características hicieron a este modelo proclive a su aplicación, pero aún así fue necesario adaptarlo a las necesidades particulares. Es por ello, que las etapas fueron analizadas y redefinidas. La etapa (ii) Restructuración de documentos no es aplicable en función que no existe documentación alguna del sistema para modificar


101

y/o actualizar. De igual forma la etapa (iv) Restructuración del Código tampoco es aplicable, dado que se construirá un nuevo código en un lenguaje de programación totalmente diferente.

Elaboración de la Guía de

Reingeniería

Aplicación de la Guía

Guía de reingeniería

Metodos -herramientas

Sistema Legado

Es suficienteDocumentación de Reingenieria

NO

SI

Estudio y Análisis

Fig. 1. Esquema del Proyecto de Reingenieria

También se analizaron herramientas que permitieran automatizar alguna de las tareas/actividades. En este sentido, se estudió un conjunto amplio de herramientas conformados por: Rational Rose, Visual Paradigm, Enterprise Architect, Power Disigner, Imagix 4D, Codesurfer, Jeliot, Mogwai ER Designer, SchemaSpy, CASE Studio, ER/Studio, Toad Data Modeler, OllyDbg, Windbg, IDA Pro, Ciasdis, ExDec, Valkyrie Clipper, etc., en los siguientes aspectos: Clasificación (desamblador/decompilador/CASE/depurador/analizador de datos-código, etc.), Tipo de tarea que desempeña, salidas que produce (modelos/diseño/código/informes), Licencia (paga o libre), Lenguaje base de la herramienta, plataforma de ejecución (Linux/Window), entradas que requiere, etc.

La segunda etapa del proyecto consistió en la elaboración de la guía y su aplicación, casi en simultaneo, de manera tal de obtener una retroalimentación que completara la guía. La interacción implicó redefinir las actividades, incorporar más artefactos de documentación, en definitiva probar y mejorar el uso y utilidad de la propuesta.

IV. GUIA DE REINGENIERIA La Guía se ha utilizado para documentar y desarrollar el

Sistema de Patrimonio de A.G.V.P. Desde el inicio del proyecto el equipo de trabajo tenia clara convicción que el nuevo sistema a desarrollar sería una aplicación web. Ya que así se superaban las deficiencias y problemas observados. La nueva aplicación debía soportar todas las funciones y operaciones específicas en un entorno multiplataforma (diversas versiones de Windows y Linux), multiusuario, con acceso de distintos puntos geográficos de la pcia., con un entorno gráfico más actual y amigable. Además se buscaba que fuera mantenible, con facilidad para incorporar funcionalidad y con documentación disponible y actualizada.

Como se indicó, al inicio del proyecto, no se contó con planes de proyecto, estimaciones de costos, arquitectura, especificaciones, modelos de requisitos, o diseños. Tampoco existía documentación del usuario. Se disponía solo con el código fuente de la mayoría de los programas fuentes y los archivos de datos o tablas (DBF).

En la Tabla 2 se presenta las Fases de la guía y por cada una de ellas una breve descripción

TABLA II. GUÍA DE REINGENIERÍA

Fase Objetivo Análisis de Inventario

Recabar información para obtener una descripción detallada del sistema legado.

Ingeniería Inversa

Analizar los programas (código fuente) con el fin de crear una representación de un nivel de abstracción más elevado que el código fuente. Extraer de los códigos existentes información del diseño arquitectónico y de proceso, e información de los datos.

Reestructuración de Datos

Analizar la arquitectura de datos actual y definir los modelos de datos necesarios.

Ingeniería directa Generar las nuevas especificaciones Desarrollo de la

nueva Aplicación Realizar todas aquellas actividades para la implementación del nuevo Sistema

A. Fases, Actividades y Artefactos A continuación se describen brevemente las fases,

actividades y artefactos que componen la guía. Análisis de inventario. Se recaba información que proporciona una descripción detallada, por ejemplo: tamaño, antigüedad, importancia para el negocio, etc., de todas las aplicaciones activas). Se elabora un documento con los siguientes apartados: Denominación, Funcionalidad, Desarrolladores del Sistema, Fecha de Desarrollo, Descripción del Sistema, enumeración de ficheros (fuentes y objeto), tablas y de datos.

Ingeniería Inversa. Es el proceso de análisis de los programas (fuentes y ejecutables) con el fin de crear una representación de un nivel de abstracción más elevado que el código fuente. Se extraerá de los códigos existentes información del diseño arquitectónico y de proceso, e información de los datos. Las actividades que se realizan son:

a) Análisis de la interfaz del Sistema: se interactúa con la todas las interfaces del sistema, el análisis de los menús y los submenús; formularios de datos, reportes generados por el sistema y se confecciona un diagrama de las distintas llamadas.

b) A partir del análisis de interfaz del Sistema, se obtiene un conjunto inicial de requerimientos funcionales y no funcionales del Sistema, el conjunto de entradas y salidas del sistema y un conjunto de entidades u objetos de datos preliminar pero relevante para el sistema.

c) Diagrama de flujo de los programas del Sistema: a partir del programa principal, y con la ayuda de alguna herramienta, se generan los diagramas de flujo de todos los programas. Se analiza el código fuente para obtener información, como las llamadas a funciones, procedimientos y otros programas, tablas utilizadas y acciones sobres las mismas, control de datos, etc.


102

d) Matriz de llamadas: a partir de la actividad anterior se confecciona una matriz por programa, en la cual se identifican las llamadas a funciones, procedimientos y/o programas.

e) Matriz de tablas: sobre las misma matrices generadas, se incorporan las tablas utilizadas en cada uno de los programas, procedimientos y/o funciones.

f) Matriz análisis de tablas: sobre las matrices de tablas, se identifican las operaciones que se realizan sobre las tablas utilizadas (alta, baja o modificación) por los programas, procedimientos y/o funciones.

g) Listado de archivos de datos potenciales: como resultado del análisis del código fuente y de las matrices resultantes de las actividades anteriores, se identifican los archivos que serian las posibles tablas que almacenan los datos del sistema.

h) Identificación de posibles claves: se analizan los datos de cada tabla y se establecen las posibles claves (primarias y ajenas).

Las actividades mencionadas generan información suficiente que permite construir representaciones y especificaciones de mayor nivel de abstracción como las que se indican en la Tabla 3.

Restructuración de datos. La reestructuración de datos toma como insumos la documentación y registros obtenidos en la etapa anterior: entidades identificadas, diccionarios de almacenamientos, DER, etc. Estos esquemas que denominamos arquitectura de datos actual, aunque no cumplan todos las condiciones de una arquitectura, se analiza minuciosamente y en profundidad. A continuación se define el nuevo modelo de datos necesario, que implica la identificación de los objetos de datos y atributos y, a continuación, se revisan las estructuras de datos a efectos de mejorar su calidad. Estas actividades continúan en la etapa siguiente.

a) Análisis de la estructura de datos: con las actividades precedentes se analiza la estructura de datos existente y se identifican los problemas en dichas estructuras.

b) Creación de nuevas tablas temporales: Se generan la estructura y sus correspondientes tablas que serán utilizados en forma temporal en procesos de adecuación y depuración de las estructuras.

c) Codificación de pequeños programas: se programan pequeños algoritmos para procesar y depurar los datos originales y almacenarlos en las tablas temporales.

Ingeniería directa. Con la información obtenida en las etapas anteriores en esta fase se plantea generar y documentar las nuevas especificaciones del nuevo sistema. También se toman decisiones que tienen fuerte influencia en la posterior implementación e imponen restricciones técnicas. Estas especificaciones refieren principalmente a las siguientes cuestiones:

a) Requisitos funcionales y no funcionales b) Plan de aseguramiento de calidad c) Normalización de las tablas heredadas d) Elección del motor de base de datos e) Elección de lenguaje de programación

f) Diseño de Interface g) Definición de clases

TABLA III. GUÍA DE REINGENIERÍA

Actividad/artefacto Representación (abstracción)

Análisis de la Interfaz del Sistema Recuperación de requerimientos funcionales

Diagrama de Contexto Lista de Eventos Lista de Entradas/salidas Especificación de requerimientos funcionales Casos de Uso

Diagramas de flujo de programas Matrices de llamadas datos y análisis de tablas

Diccionario de Datos Diccionario de Procesos actualización y control-validación) Diccionario de Almacenamientos

Listado de archivos Identificación de claves Diagrama Entidad Relación

Desarrollo de la nueva aplicación. Dado que se cuenta con las especificaciones funcionales y no funcionales y además decisiones técnicas de implementación tomadas, en esta etapa se procede a realizar tareas de implementación y pruebas.

a) Instalación y configuración de software de base (servidores de aplicaciones y/o de datos).

b) Codificación de interface. c) Codificación de clases. d) Codificación de procedimientos almacenados. e) Diseño y ejecución de pruebas.

V. APLICACION Como se mencionó la Guía fue aplicada al sistema de

Patrimonio, el cual fue desarrollado en año 1991, con el lenguaje FoxPro 2.6. El sistema está compuesto de 71 programas (archivos .prg o .fxp) los que suman un total de 20.787 líneas de código y 12 tablas en las que se almacenan los datos (tablas o ficheros DBF). Dada la extensión de la documentación resulta imposible incluirla completamente en este artículo, por lo cual se presentarán algunos esquemas representativos de cada fase.

La fase de Ingeniería Inversa es clave dado que requiere del examen del sistema existente para recuperar información fundamental. Un primer acercamiento a los requerimientos funcionales soportados y entidades relevantes del sistema se obtienen del análisis de la interfaz. Por ejemplo, la Fig. 3 presenta un submenú del sistema, el que corresponde a “motores” y todas las operaciones relacionadas (opciones), a continuación la representación en un árbol del submenú y el conjunto de requerimientos relacionados, en la Fig. 4. Así mismo de los formularios de carga de datos, se obtienen detalles de la entidad Motor y sus atributos.

Luego se analizan los programas fuentes. Para lo cual debieron ser de-compilados 22 programas de los 71, ante la ausencia de los códigos fuentes correspondientes. Se empleo la herramienta RE-Fox X para esta actividad. Por cada uno se obtiene un diagrama de flujo que permite más fácilmente comprender el flujo de control, identificar los archivos de datos y los campos utilizados.


103

Fig. 2. Guía de Reingenieria: etapas, actividades y artefactos

Fig. 3. Submenú de Motores

Los diagrama de flujo de datos se generaron automáticamente con la herramienta Visustin v7.04, cuyos diagramas aportan más información que la versión clásica de este tipo de diagramas. Dado que los archivos de datos son accedidos por distintos programas/procedimientos y con distintos objetivos (lectura/escritura), se procede a realizar un conjunto de matrices que tiene por objeto identificar los procesos de almacenamiento, procesos de validación, almacenamientos, flujos de datos. La Fig. 5 presenta la matriz correspondiente al programa BAJA.prg.

Aunque esta actividad demanda un gran esfuerzo, permite identificar segmentos de código repetido, operaciones de validación, reglas de negocio implícitas, datos relevantes, etc. Obtenidas las matrices correspondientes a todos los programas, es posible listar los archivos de datos que usa el sistema. Por cada una de estas tablas, se obtiene su estructura y se analiza el uso de cada uno de los campos por los programas y se realiza una verificación con las entidades identificadas en el análisis previo de la interfaz. Luego es posible realizar el Diagrama entidad-relación (DER) del sistema de Patrimonio (Fig. 6).

Requerimientos Funcionales 1 2 3 4

Realizar alta/baja/modificaciones de datos de los motores. Efectuar movimientos (cambio de automotor). Generar consultas por número de motor o por legajo, estos con la opción de mostrar datos históricos o solo datos actuales. Generar consulta por destino.

Entidad Motor

Atributos

Nro Motor Cuenta Subcuenta Estado Tipo Documento Nro mm/aa Legajo Original Destino Responsable Legajo Actual Observaciones

Fig. 4. Requerimientos funcionales y Entidades obtenidas del submenú y formularios


104

BAJAEL.PRG (C:\PATRIMO) Tablas

utilizadas Tablas

actualizadas Programas llamados

Procedi-mientos A B M

nomencla pantalla

bienes bienes mentop x x

legajo cartel

areas codigo

peralfa mensaje

historia historia siono x x

borratin borratin x x

Fig. 5. Matriz del programa BAJA.prg

La restructuración de datos, implicó analizar las tablas y sus campos, además de los usos de los mismos en los programas. Se identifican distintos tipos de problemas:

- Distintas entidades almacenadas en el mismo archivo (se usan campos de estado para su diferenciación)

- Diseño deficiente por falta de normalización - Definiciones de campos innecesarios (no utilizados) - Claves no declaradas - Estructuras ocultas no declaradas (por ejemplo es el

caso de la numeración de documentos para la cual se almacena el número del documento junto con el año en un campo de tipo carácter).

Se procede a una depuración que sanee estas inconsistencias. Se generan las nuevas estructuras y la migración se lleva a cabo por medio de programas codificados a tal fin. Estas actividades deben realizarse con extrema precaución dado que existe un volumen de datos que debe ser preservado y estar disponible en el futuro sistema. A medida que se realiza la migración de cada estructura se hacen actividades de chequeo que garantizan la total y correcta migración, como llevar un registro minucioso.

En la fase de Ingeniería Directa, no solamente se recupera la información de diseño del antiguo sistema de Patrimonio,

además, utiliza esta información en un esfuerzo por mejorar su calidad global. En la mayoría de los casos, el software procedente de una reingeniería vuelve a implementar la funcionalidad del sistema existente, y añade nuevas funciones y/o mejora el rendimiento global.

Se inicia desarrollando la nueva especificación de requerimientos, la cual incluye en principio los funcionales y fundamentalmente se definen y especifican los requerimientos no funcionales, (inexistentes en el sistema legado) los cuales se identifican y jerarquizan en:

- Atributos de calidad: desempeño, escalabilidad, facilidad de uso e ingreso de información, mantenimiento, operatividad, seguridad, validación de la información

- Arquitectura - Respaldos - Sistema de flujo de datos.

Se elabora el plan de aseguramiento de calidad que propone estándares (objetivos e indicadores) a cumplir en cuanto a tres factores: entrega del producto, interfaz de usuario y rendimiento del sistema. Los dos últimos factores implican un cambio importante para el usuario en su operatoria diaria con el futuro sistema.

Se finaliza con el diseño de los datos por lo cual se realiza la normalización de los datos y el diseño de la nueva base de datos.

Se elabora el diseño de la interfaz, el cual define el layout de pantallas, tipo y estructura de menúes, estructura de formularios, mensajes y otros componentes gráficos.

En la fase de Desarrollo de la Nueva Aplicación se realizan actividades que finalizan el diseño, pero principalmente se procede a la implementación de la funcionalidad y pruebas.

(0,1)

(0,n) (0,n)

(0,1) (0,n)

(0,1)

(0,1)

(0,1) (0,1)

(0,n)

(0,1)

(0,n)

(0,1) (0,1)(0,n) (0,n) (0,n)

(0,1)

Area

descrip

destino

responsa

esta

Peralfa

Bienes Autom

tiene Legajo

pertenece

Originposee

contiene

Histo

genera

Historia

cuen destinoestado

marca

mesano

nromotor

numdocresponsubcuen

tipodoc

destino

estadolegajo

mesano

nromotor

numdoc

observa

precio precio1

referrespon

scuentamo

tipodoc

Nomencla

suministra

marca

cargo

lega

descrip

Fig. 6. ER del Sistema de Patrimonio


105

Dado que se ha decidido que el nuevo sistema será una aplicación web, se decide utilizar herramientas Microsoft, SQL Server Express, SQL Management Studio Express, ya que dichos entornos permiten a los desarrolladores combinar un amplio grupo de herramientas gráficas y editores de scripts que proporcionan acceso a SQL Server Express, a los programadores y administradores de todos los niveles.

Se desarrollan las clases del sistema, lo cual no reviste dificultad en este punto del proyecto, la mayoría de las entidades están identificadas (Bienes, motores, nomenclador, etc.) y se añaden principalmente aquellas clases que tendrán las responsabilidades de gestión de las mismas. Se completan especificación de las mismas y sus relaciones.

Las actividades de diseño y ejecución de pruebas están orientadas a realizar pruebas de unidad, integración y del sistema con el objetivo de probar los requerimientos planteados. En la Tabla 4 se presenta por cada tipo de prueba algunas de las acciones llevadas a cabo.

TABLA IV. PRUEBAS Y ACCIONES

Pruebas Acciones

Integridad

Verificar el acceso al sistema. Verificar la recuperación correcta de las modificaciones realizadas en la base de datos. Verificar accesos simultáneos de lectura y escritura de datos.

Interfaz de

Usuario

Verificar la navegación a través de un conjunto de pantallas. Navegar a través del menú, verificando que cada interfaz de usuario se comprenda fácilmente.

Técnicas

Comprobar que los procedimientos almacenados y métodos de acceso a la base de datos funcionan correctamente. Inspeccionar la base de datos para asegurar que los datos son los correctos, que todos los eventos de la base de datos ocurren adecuadamente. Asegurar la navegación correcta entre formularios de la aplicación, la entrada, el proceso y recuperación de los datos. Realizar operaciones posibles en cada formulario con entradas válidas e inválidas para verificar los resultados esperados, mensajes de error o advertencias adecuadas. Crear y/o modificar pruebas para cada una de las ventanas.

Al finalizar esta etapa se cuenta con la nueva aplicación desarrollada, los datos migrados y la documentación técnica actualizada y disponible.

VI. TRABAJOS RELACIONADOS Varios esfuerzos de reingeniería han sido reportados en la

literatura. En [9] se describe un enfoque para la construcción de componentes reutilizables de grandes sistemas existentes mediante la identificación de los subsistemas estrechamente acopladas contenidos en el sistema. El enfoque se basa principalmente en el uso de métodos informales y experimentales y el objetivo principal era hacer observaciones acerca de las experiencias vividas con algunos sistemas grandes. Lewis y McConnell [10] describen un proceso de reingeniería y su aplicación a un sistema embebido en tiempo real. El proceso de siete pasos describe hitos de alto nivel que van desde la ingeniería inversa y la reingeniería de reorientación y la prueba final. En [11] se presenta un caso de estudio que ilustra cómo una combinación de técnicas de análisis orientado a objetos y estructurado y diseño

estructurado se pueden utilizar en conjunto para rediseñar una aplicación existente que es utilizada por Texas Instruments para analizar el tráfico en redes de área local. En [12] se presenta una experiencia de reingeniería de una aplicación científica heredada que resulta obsoleta en cuanto a operatividad, aspecto y software de base sobre el que se ejecuta, pero de probada eficiencia y que mantiene su funcionalidad. Se muestran las características de un proceso de desarrollo que se adapta a este tipo de aplicaciones, verificado mediante el caso de estudio, la transformación de una aplicación escrita en un lenguaje imperativo, no estructurado, a un nuevo lenguaje visual y orientado a objetos, describiendo las diversas fases de la metodología aplicadas a un caso concreto.

VII. CONCLUSIONES Se ha presentado una guía para la reingeniería de sistemas

legados que ha sido puesta en práctica a un sistema real. La elaboración y aplicación prácticamente en simultáneo ha permitido validar su razonabilidad y utilidad. Asimismo no es posible generalizar su aplicabilidad a cualquier sistema legado, acotamos su uso a los sistemas legados que responden a las características señalas. Las actividades y artefactos empleados en cada fase pueden ser ampliados y la principal desventaja que encontramos es que la mayor parte del trabajo ha sido manual. Aunque ha demandado mayor esfuerzo y tiempo ha permitido adquirir experiencia.

El trabajo futuro está dirigido a la reingeniería de los restantes sistemas legados de AGVP, pero antes nos abocaremos a: desarrollar algunas herramientas utilitarias que automaticen algunas de las tareas, por ejemplo la construcción de las matrices, las cuales han resultado ser un artefacto de gran utilidad en nuestra experiencia. Otro objetivo a cumplir es incorporar un modelo de estimación esfuerzo/tiempo, que nos permita planificar la reingeniería de cada sistema.

AGRADECIMIENTOS El presente proyecto ha sido parcialmente financiado por la Agencia Nacional de Promoción Científica y Tecnológica – MINCyT – Argentina.

REFERENCIAS [1] K. Bennett, “Legacy Systems: Coping with success”, IEEE

Software, vol. 12, no. 1, 1995, pp. 19 – 23. [2] H. Sneed, “Planning the Re-engineering of Legacy Systems”,

IEEE Software, vol. 12, no. 1, 1995, pp. 24 – 34. [3] B. Lientz y E. Swanson, “Software Maintenance Management”.

Addison Wesley, Reading, MA, 1980. [4] E. J. Byrne, “A Conceptual Foundation for Software

Reengineering,” Proceedings de Conference on Software Maintenance, pp. 226–235, IEEE, 1992.

[5] I. Sommerville, “Software Engineering”. 6ta edición. Addison Wesley, 2001.

[6] J. Leiva, “Construcción de especificaciones de interfaces en un proceso de reingeniería,” 2da. Conferencia Iberoamericana en Sistemas, Cibernética e Informática, 2003, USA, pp 202-208.

[7] J. Bergey, D. Smith, N. Weiderman y S. Woods, “Option Analysis for Reengineering (OAR): Issues and Conceptual Approach” (CMU/SEI-99-TN-014). Pittsburg, Pa.: Software Engineering Institute, Carnegie Mellon University, 1999.

[8] R. Pressman, “Ingeniería del software: Un enfoque práctico”. 6ta Edición. McGraw-Hill, 2005.

[9] J. Neighbors, “Finding reusable components in large systems,” Proceedings of the Third IEEE Working Conference on Reverse Engineering, pp. 2–10, IEEE, November 1996.


106

[10] B. Lewis y D. J. McConnell, “Reengineering Real-Time Embedded Software onto a Parallel Processing Platform,” Proceedings the Third Working Conference on Reverse Engineering, pp. 11–19, November 1996.

[11] G. Gannod, G. Sudindranath y M. E. Fagnani, “PACKRAT: A Software Reengineering Case Study”. Proceedings of the 5th Working Conference on Reverse Engineering, 1998, pp. 125-134, IEEE.

[12] J. Alvarez Garcia, M. Sanchez M. y M. Moreno Garcia, “Metodología De Reingeniería Del Software Para La Remodelación De Aplicaciones Científicas Heredadas”. Informe Técnico – DPTOIA-IT-2004-003 - 2004 – Repositorio documental de la Universidad de Salamanca

Franco Bianchiotti. Se gradúo de Licenciado en Sistemas en la Universidad Nacional de la Patagonia Austral. Ha sido becario de la Agencia Nacional de Promoción Científica y Tecnológica (MINCyT – Argentina). Actualmente se desempeña en la Dirección de Informática de la Administración General de Vialidad Provincial, desde el año 2007.

Sandra Casas. Es Profesora Asociada de la Universidad Nacional de la Patagonia Austral, (Argentina), dónde además es miembro del Instituto de Tecnología Aplicada (ITA). Se doctoró en la Universidad de Vigo en el año 2008 y su línea de investigación refiere a temáticas relacionadas al desarrollo de software. Dirige el grupo de investigación GISP del ITA y proyectos de investigación desde el año 2005.

Kuna, H., Rey, M., Martini, E., Solonezen, L., Podkowa, L. 2014. Desarrollo de un Sistema de Recuperación de Información para Publicaciones Científicas del Área de Ciencias de la Computación. Revista Latinoamericana de Ingeniería de Software, 2(2): 107-114, ISSN 2314-2642

107

Desarrollo de un Sistema de Recuperación de Información para Publicaciones Científicas del Área

de Ciencias de la Computación

H. Kuna1,2, M. Rey1, E. Martini1, L. Solonezen1, L. Podkowa1 1Departamento de Informática, Fac. de Cs. Exactas, Químicas y Naturales. Universidad Nacional de Misiones. Argentina

2Facultad de Ingeniería – Universidad Nacional de Itapúa, Paraguay [email protected]

Resumen — La recuperación de información desde la web es una actividad recurrente para el investigador en general que, dada su complejidad, puede insumir una cantidad de timpo considerable. En este contexto, la relevancia y la calidad de los resultados obtenidos en cada búsqueda realizada son cruciales. Los Sistemas de Recuperación de Información se presentan como herramientas de gran utilidad para optimizar el proceso de búsqueda de información en la web, específicamente cuando se generan para contextos de funcionamiento acotados. En el presente trabajo se presenta el desarrollo de un meta-buscador orientado exclusivamente a la recuperación de publicaciones científicas del área de ciencias de la computación. Se incluye la descripción de los componentes desarrollados a medida, considerando las particularidades del tipo de documentos a recuperar, para la mejora de la relevancia y calidad de los resultados a retornar al investigador, comenzando por el proceso de expansión de consultas y finalizando por el algoritmo de ranking que establece el orden final de los resultados para su presentación al usuario.

Palabras Clave — Recuperación de Información, Ontología, Algoritmo de Ranking, Búsqueda Web, Indicadores Biblio-métricos, Meta-buscador.

I. INTRODUCCIÓN En la actualidad internet facilita el acceso a grandes

volúmenes de información desde cualquier parte del mundo. La administración de tal cantidad de información es una tarea cuya complejidad ha crecido durante los últimos años, determinado esto por la cantidad y complejidad de los documentos disponibles en la web y su constante cambio.

La información en la web se busca y recupera de diversas maneras, una de ellas es a través de los motores de búsqueda, como por ejemplo: Google1, Yahoo2 o Bing3. Éstos han mejorado progresivamente y se puede decir que son bastante eficientes, aunque los resultados que proporcionan al usuario no sean del todo eficientes en cuanto a cantidad, calidad y, principalmente, correlación con el objetivo de la búsqueda realizada [1].

El objetivo del presente trabajo es desarrollar de un Sistema de Recuperación de Información de dominio específico, en particular un meta-buscador que se oriente exclusivamente a la recuperación de documentos científicos del área de ciencias de la computación. Se plantea el desarrollo de todos sus

1 www.google.com 2 www.yahoo.com 3 www.bing.com

componentes, incluyendo aquellos cuya finalidad es realizar la expansión de las consultas ingresadas por el usuario final haciendo uso de una ontología y la evaluación de los documentos recuperados para establecer un ranking considerando su calidad como artículo científico.

II. ANTECEDENTES

A. Sistemas de Recuperación de Información Un Sistema de Recuperación de Información (SRI) es un

proceso que posee capacidad suficiente para gestionar información, entendiéndose por esta gestión a su recuperación, almacenamiento y mantenimiento para diversos fines según el contexto de su aplicación [2], [3]. En la literatura del área de ciencias de la computación se pueden observar diversas propuestas sobre la organización interna de un SRI, en el marco del presente trabajo se utilizará aquella que se basa en los siguientes elementos [4]:

Los documentos, que constituyen la fuente de información sobre la cual se pretende realizar búsquedas.

Las consultas, generadas por los usuarios del SRI que tienen por objetivo recuperar información a la cual el sistema provee acceso.

La representación de los documentos, las consultas y las relaciones que se definan entre ellos que sean definidas teniendo en cuenta el ámbito de aplicación del SRI.

La función de evaluación, que determina la pertinencia de cada documento recuperado para dar solución a la consulta que haya ingresado el usuario. Los principales tipos de SRI que en la actualidad operan

sobre internet son: los directorios, los buscadores y los meta-buscadores [1]. Se puede afirmar que existen implementaciones de SRI en la web que utilizan diferentes métodos de búsqueda sobre contextos generales o particulares, contando con implementaciones desarrolladas a medida para el incremento de la relevancia de los resultados a presentar al usuario [5], [6].

En el contexto del presente trabajo cobran una mayor notoriedad los meta-buscadores, ya que gracias a su modularidad, permiten que los componentes del SRI sean desarrollados a medida para las necesidades particulares de su contexto de aplicación. En este caso se presenta el desarrollo realizado particularmente sobre los siguientes componentes:


108

El componente que captura la consulta del usuario y la expande, generando consultas similares para expandir el espectro de búsqueda.

El componente que accede a las fuentes de datos sobre las que serán realizadas las búsquedas y recupera de cada una de ellas los documentos resultantes de la ejecución de una consulta.

El componente que aplica la función de evaluación de los documentos obtenidos desde cada fuente para ordenar el listado integral a presentar al usuario. En todos los casos se trata de desarrollos específicos

determinados por el ámbito de uso propuesto para la herramienta.

B. SRI para documentos científicos del área de ciencias de la computación Si bien se han detectado diversas iniciativas tendientes a la

generación de SRI de propósito específico en áreas particulares, como por ejemplo en ciencias de la salud [7], u otras con un perfil de aplicación más general [8], inclusive algunas que realizan búsquedas de referencias bibliográficas [9]; no se ha encontrado evidencia de la existencia de implementaciones de SRI que sean aplicadas específicamente a bases de datos de documentos científicos pertenecientes al área de ciencias de la computación. Tampoco de productos de este tipo que implementen soluciones complementarias para resolver aspectos clave como son la expansión de las consultas del usuario considerando el contexto de la búsqueda y la aplicación de métodos de evaluación de los documentos en base a la calidad de los mismos con la finalidad de mejorar la relevancia de los elementos del listado de resultados a presentar al usuario.

Explotando las capacidades de los meta-buscadores antes mencionadas, se considera factible generar un SRI que utilice bases de datos de otros buscadores que sean específicos para la recuperación de documentos científicos del área de ciencias de la computación. Así como también el desarrollo de componentes complementarios, tanto para el tratamiento de las consultas introducidas por el usuario, como para la aplicación de un algoritmo de ranking específico para evaluar el tipo de resultados con el que se desea operar, según diferentes métricas, ampliamente aceptadas por la comunidad científica considerando las características propias del área, asignando a cada resultado una calificación que servirá de referencia para establecer el orden de los resultados en el listado final a presentar al usuario [5].

C. Expansión de consultas en un SRI y ontologías Un SRI cuenta con varias alternativas para lograr

optimizar el proceso de búsqueda de información, una de ellas consiste en tomar la consulta que ingresa el usuario y ampliarla a partir de agregar diversos términos, usualmente obtenidos a través de fuentes externas, manteniendo coherencia con el dominio de la consulta. Este método es conocido como expansión de consultas (QE por su sigla en inglés); los términos adicionales generan nuevas consultas, denominadas expansiones [10], [11]. De esta manera el SRI adquiere la capacidad de acceder a una mayor cantidad de documentos relevantes para el usuario, para ello se ejecutan, en una misma sesión de búsqueda, las diferentes consultas sobre cada base de datos a la que posea acceso el SRI, obteniendo listados de resultados individuales por cada

expansión que posteriormente son unificados y ponderados antes de ser presentados al usuario [5], [12].

Existen diferentes opciones para la implementación de un proceso de expansión de consultas para un SRI, entre las cuales se pueden mencionar: uso de tesauros, diccionarios, sistemas expertos, entre otros [10], [13], [14]. En el caso particular de este trabajo se hace uso de una ontología de dominio específica para un sub-área temática de las ciencias de la computación.

En general se define a una ontología como una forma de representación del conocimiento de un ámbito específico, que utiliza los términos y relaciones que conforman su vocabulario base, agregando elementos que permiten extender el vocabulario, como son las relaciones entre conceptos, permitiendo organizarlos jerárquicamente, facilitando su utilización para la generación de conocimiento en forma automática [15].

Adaptando la definición anterior al área de ciencias de la computación, una ontología se puede considerar como un esquema conceptual correspondiente a un dominio acotado, que permite la comunicación y transmisión de información entre sistemas, tanto interna como externamente [16]. Constituye una herramienta de gran utilidad para la recuperación de información dado que facilita el tratamiento y análisis del conocimiento a través de una estructura de clases y subclases que adquiere sentido con las relaciones, propiedades y reglas definidas entre las instancias de las mismas [17].

D. Métricas para la Evaluación de Documentos Científicos El SRI planteado requiere el desarrollo de un método

particular para la evaluación de los documentos con los que trabajaría. Al tratarse de artículos científicos se hizo necesario determinar aquellas características de los documentos que serían evaluadas, quedando seleccionadas las siguientes [18], [19]:

La calidad de la fuente de publicación, que hace referencia a dónde se ha publicado el artículo, pudiendo ser una revista científica o un congreso o reunión científica de similares características.

La calidad de los autores, valorando la importancia que hubieran tenido las publicaciones que hayan realizado a lo largo de su carrera.

La calidad del artículo en sí, considerando la antigüedad del mismo y la cantidad de veces que haya sido citado en otros documentos. Para cada una de las características enunciadas se

distinguen diversos indicadores bibliométricos, ver tabla 1, que han sido validados por la comunidad científica.

Para el caso en que el tipo de fuente de publicación sea una revista existen dos índices que se utilizan para estimar su calidad: por un lado el Factor de Impacto (IF, por sus siglas en inglés) [20] desarrollado por la Web of Knowledge, que permite medir la importancia que ha tenido una revista a partir de las citas que han recibido los artículos que se han publicado en ella en un año en particular; y el índice SJR (SCImago Journal Rank) [21] desarrollado por el grupo homónimo que tiene en cuenta las publicaciones científicas de revistas listadas en la base de datos de Scopus.


109

TABLA I. MÉTRICAS ANALIZADAS PARA LA EVALUACIÓN DE ARTÍCULOS CIENTÍFICOS

Propiedad a evaluar Métricas Entidad que da

soporte a la métrica Factor de

Impacto (IF) [20]

Web of Knowledgea – Institute for Scientific

Information (ISI) Publicación en revista científica

SCImago Journal

Rank (SJR) [21]

Scopusb – Grupo SCImago, Univ. De

Extremadura, España

Calidad de la fuente de

publicación Publicación en Congreso

o Evento Científico

Ranking CORE [22]

Computer Research & Education of

Australiac

Índice H [23] - Calidad de los autores Índice G [24] -

Índice AR [25] - Calidad del artículo Cantidad de citas -

a. www.wokinfo.com – Accedido: 30/03/14 b. www.scopus.com – Accedido: 30/03/14 c. www.core.edu.au – Accedido: 30/03/14

Está inspirado en el PageRank de Google [26] para evaluar

el impacto de una publicación de acuerdo al número de citas recibidas con respecto a relevancia de las publicaciones que la citan. Este establece una clasificación de acuerdo a ciertos parámetros, como ser: área de conocimiento, categoría y país.

Mientras que en caso de que la publicación se realice en un congreso o evento similar se cuenta con el ranking CORE [22] desarrollado por la Computer Research & Education of Australia. Un congreso o conferencia es clasificado, según su importancia, en un determinado nivel preestablecido: A*, A, B y C, respectivamente. Este listado de congresos que es de carácter público, es accesible desde la propia web de dicho instituto.

Para estimar la calidad de la producción de un autor se dispone del índice H [23]. Este se calcula en base en la distribución de las citas que han recibido las publicaciones científicas de un determinado autor. De tal manera que, para hallarlo, solo basta ordenar de forma descendente las publicaciones de un autor por el número de veces que ha sido citada cada publicación, y, de esta manera, se identifica el punto en el que el número de orden coincide con el de citas recibidas por publicación, este número representa el índice H. Otra métrica igual de valida es el índice G [24]. Para calcularlo, primeramente los artículos de un autor son ordenados de manera descendente de acuerdo con el número de citas recibidas por cada uno de ellos, al igual que lo hace el índice H. Aquel número mayor en el orden del ranking donde la sumatoria de citas recibidas por el autor sea mayor o igual al cuadrado del número de orden, es considerado como el índice G de dicho autor.

Para evaluar la calidad de una colección de publicaciones se puede utilizar un índice como es el AR [25], dicho indicador combina la cantidad de citas con la antigüedad de cada publicación, para así establecer una valoración de la colección. La cantidad de citas recibidas, por sí solas, también es utilizada como métrica para evaluar la calidad de un documento científico en particular.

III. MATERIALES Y MÉTODOS

A. Estructura del SRI El trabajo abordado previamente por los autores ha

consistido en el planteo inicial de lineamientos generales sobre la estructura del SRI a desarrollar [27], basándose en desarrollos similares que fueron tomados como referencia [5], [6], [28].

La estructura general del meta-buscador desarrollado se compone de los siguientes módulos:

• Módulo para la gestión de las consultas (MC): encargado de realizar inicialmente la expansión de consultas utilizando el método basado en el uso de una ontología, para posteriormente adaptar las expansiones obtenidas y posibilitar su uso en los buscadores integrados.

• Módulos para la búsqueda en las bases de datos (buscadores) (MB): encargado de tomar las consultas adaptadas y controlar su ejecución sobre las diferentes fuentes de documentos incorporadas al SRI. Actualmente los buscadores consultados son: Google Scholar4, ACM Digital Library5, IEEE Xplore6.

• Módulo para la gestión de los resultados (MR): encargado de procesar los resultados a través del componente que permite la aplicación del algoritmo de ranking desarrollado a medida para el SRI dado su ámbito de trabajo [29]. Como resultado obtiene un valor representativo de la calidad de cada documento recuperado a partir de las búsquedas, que se utiliza como referencia para establecer el orden de aparición del documento en el listado final a presentar al usuario.

B. Funcionamiento del SRI El proceso de la búsqueda, ver figura 1, se compone de los

siguientes pasos: 1) El usuario ingresa la consulta al sistema. 2) El MC toma el texto de la consulta y ejecuta el proceso de

expansión basado en la ontología. 3) Para cada una de las expansiones generadas, el MC las

adapta según los requerimientos determinados por cada fuente de datos a consultar, considerando cantidad de resultados y conectores entre términos.

4) El MB toma todas las consultas adaptadas y las ejecuta sobre la fuente de datos correspondiente.

5) Por cada búsqueda iniciada, el MR recibe el listado de documentos generados de cada fuente y los filtra, eliminando aquellos que no se consideran relevantes en cuanto a su tipo (por ejemplo: resumen de citas de un documento).

6) Se unifican las colecciones de resultados obtenidas de los buscadores consultados, incluyendo un paso de limpieza de resultados duplicados.

7) Para cada documento individual del listado unificado, se aplica el algoritmo de ranking.

8) Se ordena el listado de documentos en base al valor obtenido por cada resultado particular al aplicarse el algoritmo de ranking.

9) Se formatea el listado ordenado para su presentación al usuario final, permitiendo al usuario visualizar los

4 scholar.google.com – Accedido 30/03/14. 5 dl.acm.org – Accedido 30/03/14. 6 ieeexplore.ieee.org/ - Accedido 30/03/14.


110

siguientes datos por cada documento: título, fuente de publicación, listado de autores, descripción general, cantidad de citas, link de acceso al documento, descripción del valor asignado por el algoritmo de ranking.

Figura 1. Proceso de búsqueda del SRI

C. Construcción de la ontología para la expansión de consultas El componente principal del método de expansión de

consultas desarrollado para el meta-buscador es la ontología en base a la cual se realiza la expansión. Su diseño requirió de las siguientes actividades [30]:

1) Definición del dominio de la ontología: dado el contexto de aplicación del SRI se comenzó por seleccionar un sub-área temática dentro de las ciencias de la computación a partir de la cual se realizaría la ontología. Se determinó que se comenzaría por el sub-área de Inteligencia Artificial (IA).

2) Determinación de los términos a incluir en la ontología: se generó un listado de términos a partir de una revisión del estado del arte de la disciplina, obteniendo un conjunto de conceptos que caracterizan a las subdivisiones de la IA, conjuntamente se definieron sinónimos de cada concepto que pudieran ser utilizados en el método de expansión [31]–[33].

3) Definición de la jerarquía de clases: utilizando el método top-down, se definió como clase a todo concepto que representara una categoría en la que la disciplina pudiera

subdividirse, definiendo dentro de cada clase aquellas instancias que serían consideradas como subclases, con el objetivo de que la ontología represente de la mejor manera posible la taxonomía original del área.

4) Definición de propiedades para las clases: para esta actividad se consideró como propiedad a aquellos atributos que pudieran describir a los conceptos, teniendo en cuenta las relaciones que pueden existir entre los mismos. Se definieron relaciones implícitas y explícitas, las primeras están dadas por la estructura subyacente de la ontología, es decir, que se definen a partir de las conexiones entre los conceptos, como ser:

• “Es un (padre)”, simbolizando la situación de que una clase contiene a otra.

• “Es un (hijo)”, relación inversa a la anterior, que representa que una clase es contenida por otra.

• “Es un (hermano)”, simbolizando a un conjunto de clases que comparten un mismo “padre”.

En cuanto a las relaciones explícitas, aquellas definidas para dar mayor valor a la ontología considerando su objetivo de aplicación, se determinó que sería representada la relación de sinonimia, utilizando para ello los términos relevados al inicio del proceso.

5) Creación de instancias para las clases: utilizando los términos de mayor atomicidad, se definieron los conceptos que conformarían las instancias de las clases de la ontología.

Concluido el diseño de la ontología, se seleccionó la herramienta software Protègè [34] para su implementación, reflejando en la misma el resultado del proceso descripto en la sección anterior.

D. Desarrollo del método de expansión de consultas El método para realizar la expansión de consultas tendría

por objetivo obtener de la ontología aquel concepto que guardara mayor similitud con la consulta ingresada por el usuario (consulta_original en adelante) y, a partir de ese concepto, obtener a los conceptos relacionados al mismo en forma implícita y explícita, es decir, su “padre”, sus “hermanos” y los sinónimos del término en sí.

Con tal objetivo en mente, el algoritmo se divide en dos etapas, inicialmente se busca al concepto de la ontología más similar a la consulta_original (concepto_candidato en adelante) y posteriormente se efectiviza la expansión al disponer de los conceptos relacionados.

La búsqueda del concepto_candidato consta de los siguientes pasos:

1) Para cada término de la consulta_original: se recorre la ontología en su totalidad almacenando en una colección temporal aquellos conceptos con mayor cantidad de coincidencias.

2) En base al contenido de la colección resultante del paso anterior:

a) Si no contiene ningún elemento: se finaliza la operación de expansión sin resultados válidos.

b) Si contiene un único elemento: se considera al mismo como el concepto_candidato.

c) Si contiene más de un elemento: se analiza cada concepto cuantificando la cantidad de coincidencias sintácticas con respecto a la consulta_original. En caso de empate, se procede a evaluar al elemento en base a las relaciones del mismo en la ontología:


111

Si todos tienen el mismo “padre”: tal concepto es seleccionado como concepto_candidato.

Si no tienen el mismo “padre”: se evalúa la cantidad de instancias contenidas por cada “padre”, aquel que presente la mayor cantidad será el concepto_candidato. En caso de un nuevo empate: cada uno de los “padres” involucrados será considerado concepto_candidato conformando una colección nueva.

Con el o los candidatos determinados se inicia la segunda etapa del método de expansión, que se compone de los siguientes pasos:

3) Se obtiene el concepto “padre” (concepto_padre en adelante) del concepto_candidato.

4) Se obtienen los conceptos del mismo nivel que el concepto_candidato, dando lugar a la colección [conceptos_hermanos].

5) Se obtienen, en caso de existir, los sinónimos del concepto_candidato, dando lugar a la colección [sinónimos_concepto].

6) Se expande la consulta_original haciendo uso de los elementos obtenidos a través de los pasos anteriores, las expansiones quedan conformadas según las fórmulas 1 a 4:

Expansión_1= consulta_original AND concepto_candidato (1)

Expansión_2= concepto_candidato AND concepto_padre (2)

Expansión_3= concepto_candidato OR [conceptos_hermanos] (3)

Expansión_4= concepto_candidato OR [sinónimos_concepto] (4)

Al finalizar la ejecución del algoritmo se cuenta con las cuatro expansiones de la consulta_original ingresada por el usuario al sistema.

E. Diseño del algoritmo de ranking Uno de los puntos claves a la hora de desarrollar el SRI, fue

definir la manera en que se ponderaría a cada uno de los resultados obtenidos, ya que su ubicación en la lista final de resultados, surgiría a partir de dicha ponderación. Para ello se optó por diseñar un algoritmo que evalúe diversos aspectos que hacen a la calidad de una publicación académica.

En primera instancia se definió que las características a evaluar serían: el lugar en donde se ha publicado o fuente de publicación, los autores de la publicación, y la calidad propia del artículo. Luego se relevaron, se analizaron y se incorporaron al algoritmo distintas métricas que valoren alguno de los 3 criterios. Las métricas que finalmente se utilizaron fueron:

Calidad del lugar de publicación: Para definir este criterio hay que tener en cuenta que un trabajo de investigación tiene dos grandes maneras de divulgarse, por un lado se encuentran las revistas científicas y por otro lado los congresos. En el caso de que el resultado se haya publicado en una revista científica, se optó por utilizar como métrica el índice SJR [21], este índice es desarrollado por Elsevier en base a los datos del buscador Scopus y posee ciertas ventajas [35], [36] frente a su principal alternativa, el IF de ISI [20], entre las que se destacan: que es de acceso abierto; que la cantidad de revistas que incluye, en combinación con la base de datos

de Scopus es superior; que incluye revistas en idiomas distintos al inglés; que utiliza una evaluación tanto cuantitativa, dado por la cantidad de citas recibidas, como cualitativa ya que las citas de revistas más prestigiosas poseen mayor valor respecto a las que no lo son. Y en el caso de que el resultado sea procedente de un congreso la métrica utilizada fue el ranking creado por la Computing Research and Education Association of Australia (CORE) [22].

Calidad de los autores: existen varias alternativas a la hora de elegir métricas para evaluar la producción científica de un autor, entre ellas se destaca el índice H [23], ya que es la pionera en este aspecto y pese a ser resistida por cierta parte de la comunidad científica, es ampliamente aceptada y utilizada [18], [19], además ha sido la base para la creación de otras métricas [24], [37], [38].

Calidad de la publicación: para el presente criterio se decidió incorporar al algoritmo una combinación adaptada de las 2 métricas relevadas, tanto el índice AR [25], autoproclamado como complemento del índice H, como la cantidad de citas, remarcando que la primera se adaptó para evaluar los documentos de manera independiente y no una colección como lo hace el índice original.

F. Desarrollo del algoritmo de ranking Luego de seleccionar las métricas que serían la base para el

armado del algoritmo, fue necesario normalizar sus valores, ya que en cada una de las métricas originales, los valores máximos y mínimos pueden llegar a ser muy diferentes, por ejemplo: un autor prolífico puede poseer un índice H que ronda un valor de 100, mientras que la revista más prestigiosa difícilmente alcance un índice SJR superior a 40. En otras palabras lo que se hizo fue adaptar las métricas para que sus valores estén en función de una escala común. Así las fórmulas correspondientes a cada uno de los parámetros quedaron conformadas de la siguiente manera:

Para el factor de la fuente de publicación, como se mencionó anteriormente, hay 2 métricas utilizadas: el índice SJR y el ranking CORE. En el caso de que la fuente haya sido una revista, se toma el índice SJR y se aplica a dicho índice el logaritmo en base 10 (fórmula 5) con lo que queda definido el factor. En el caso de que la fuente haya sido un congreso, se busca la categoría del congreso en el ranking y a partir de esa categoría se establece el valor según lo expresado en la fórmula 6.

fuentePublicación = log10(SJR) (5)

fuentePublicación��[A* =1;A = 0.75; B = 0.5; C = 0.25 (6)

Para el caso de los autores se considera el índice H de cada uno de ellos de la siguiente manera (fórmula 7): de cada autor se toma una fracción de su índice H según la ubicación que tengan en el artículo, así, del primer autor se toma la totalidad, del segundo la mitad, del tercero un tercio y así sucesivamente. Luego se suman todos los valores obtenidos y se aplica el logaritmo en base 10 a dicha sumatoria.

autores= log��(indiceH(autori)/i) (7)

Para el factor correspondiente a la calidad del documento en evaluación, se utilizaron los lineamientos propuestos


112

por el índice AR, en el mismo se trata de definir la vigencia de un trabajo a través del tiempo, esto se hizo, como puede verse en la fórmula 8, a partir del logaritmo en base 10 del cociente entre la cantidad de citas recibidas y la antigüedad del trabajo, la diferencia radica en que el índice mencionado somete dicho cociente a la raíz cuadrada.

calidadPublicación=log10(citasRecibidas/antiguedadPublicación). (8)

Una vez definida la manera de calcular cada parámetro, se le agregó a cada uno un factor de ajuste (alfa, beta y gamma), a partir del cual se podría hacer variar el peso de un parámetro en el puntaje final. Estos factores de ajuste pueden tomar valores entre 0 y 1, de esta manera cuando un factor de ajuste toma valor 0 el parámetro asociado a dicho factor se anula. Contrariamente cuando el factor toma valor 1 el parámetro aporta toda su ponderación al puntaje final.

En definitiva, el puntaje que se le otorga a un documento y a partir del cual se define su posición entre los resultados, viene dado por (fórmula 9): la suma de 3 parámetros (fuente de publicación, autores y calidad de la publicación) cada uno de ellos multiplicado por su factor de ajuste, el cual va a determinar la importancia de éste en el puntaje final. Para la fase de experimentación, y en forma conjunta con expertos en la temática, los valores establecidos para cada factor de ajuste fueron 0.5, 0.3 y 0.2 respectivamente.

valorFinal��*[fuentePublicación] +��*[autores] +��*[calidadPublicación] (9)

IV. EXPERIMENTACIÓN

A. Desarrollo del prototipo de SRI para la experimentación Una vez diseñado el meta-buscador y sus componentes, se

requirió contar con una implementación del mismo para poder desarrollar la experimentación que condujera a su validación. La tecnología utilizada para el desarrollo de la herramienta consistió en: los lenguajes Java, JSP, Javascript, xHTML y SQL, junto al motor de bases de datos MySQL, utilizando como plataforma para su implementación el servidor web Tomcat, habiéndose priorizado aquellas que permitieran usar el SRI desde la web y que fueran de código abierto.

El proceso de implementación del meta-buscador se descompuso en los siguientes pasos:

1) Diseño y desarrollo de los métodos para acceder, consultar y extraer los resultados de los sitios web de los buscadores Google Scholar, ACM Digital Library e IEEE Xplore.

2) Implementación del algoritmo de ranking con el acceso a las fuentes de datos que almacenan los valores de las diferentes métricas involucradas.

3) Desarrollo de los componentes visuales del meta-buscador, es decir, la interfaz de captura de las consultas del usuario y la correspondiente para la visualización del listado de resultados unificado y ordenado según el valor obtenido por cada documento al aplicar el ranking.

4) Integración de todos los componentes en un único producto software.

B. Validación del SRI desarrollado Para el proceso de validación se ha contado con la

colaboración de un grupo de expertos en el desarrollo de métodos de recuperación de información quienes han evaluado al SRI considerando la relevancia de los documentos que son

retornados por el mismo a partir de diferentes consultas. Se ha evaluado el proceso completo de búsqueda, desde la expansión de la consulta ingresada, la ejecución de las expansiones generadas en cada fuente de datos y el procesado posterior de los resultados a través del algoritmo de ranking.

El detalle de la experimentación se observa en la tabla 2, la cantidad de consultas ha sido la recomendada por los expertos, y la cantidad de resultados a obtener fue configurada a niveles adecuados para el correcto seguimiento de todo el proceso en forma manual por parte de los evaluadores. Se ha verificado la pertenencia de cada documento con respecto a la consulta ingresada, teniendo en cuenta la relación directa entre sus términos y aquellos resultantes a partir del proceso de expansión realizado a través de la ontología, además de analizar la posición que cada documento obtuvo en el listado de resultados final en base a su calificación por el algoritmo de ranking. A partir de la combinación de esos factores se ha determinado qué porcentaje de los resultados serían considerados como efectivamente relevantes para el usuario, sirviendo tal métrica como medida de desempeño del meta-buscador.

Como resultado de la experimentación, se ha determinado que el SRI desarrollado, a través de sus diversos componentes, constituye una herramienta para recuperar documentos científicos de calidad comprobable a partir de una consulta del usuario.

TABLA II. (A) RESULTADOS DE LA VALIDACIÓN DEL SRI POR PARTE DE LOS EXPERTOS

Consulta realizada Cantidad de resultados procesados

Efectividad evaluada por los expertos

intelligent agents AND web

information retrival 120 (40 por buscador) 68%

search methods AND deep-first-

search 120 (40 por buscador) 64%

TABLA II. (B) RESULTADOS DE LA VALIDACIÓN DEL SRI POR PARTE DE LOS EXPERTOS

unsupervised learning AND

backpropagation networks

120 (40 por buscador) 80%

genetic algorithms AND distributed

methods 120 (40 por buscador) 62%

natural language processing AND

ontologies 120 (40 por buscador) 72%

artificial intelligence AND computer

vision 120 (40 por buscador) 68%

classes of agents AND deliberative

agents 120 (40 por buscador) 60%

fuzzy controllers AND robotics 120 (40 por buscador) 76%

fuzzy sets AND expert systems 120 (40 por buscador) 74%

neural networks AND self organizing

maps 120 (40 por buscador) 88%


113

V. CONCLUSIONES En la actualidad la cantidad de información a la que se

puede tener acceso a través de internet, se ha vuelto irrisoria. Es por esto que cada vez cobra mayor importancia la eficiencia con la que se accede a ella y la relevancia de los resultados obtenidos con respecto a la consulta ingresada por el usuario. En este artículo se ha presentado el diseño, la implementación y validación de un SRI, específicamente un meta-buscador para un área de conocimiento específica como son las ciencias de la computación, limitando los documentos a recuperar a publicaciones científicas. Para poder alcanzar mejores resultados se trabajó sobre diferentes componentes como el acceso a múltiples fuentes, la realización de una expansión de la consulta del usuario utilizando ontologías, y la evaluación de cada resultado a través de un algoritmo de ranking específicamente desarrollado para cuantificar la calidad de cada documento recuperado y así poder ordenar los resultados a presentar al usuario en base a su relevancia.

Como trabajos a futuro se pueden mencionar: generar las ontologías restantes para cubrir todas las sub-áreas dentro de las ciencias de la computación de modo de completar el método de expansión de consultas, incorporar otros indicadores bibliométricos al algoritmo de ranking que sean adecuados para el tipo de documentos en evaluación, evaluar la incorporación de elementos que permitan automatizar la adaptación de los factores de ajuste del algoritmo de ranking en base a las preferencias del usuario, considerar la reputación de los autores de un determinado documento en el área temática en la que se haya producido la publicación como otro factor en el algoritmo de ranking, entre otros.

AGRADECIMIENTOS Los autores del presente trabajo agradecen a los miembros

del Grupo de Investigación SMILe dirigido por el Dr. J. A. Olivas Varela, perteneciente a la Universidad de Castilla-La Mancha, España, su colaboración en calidad de expertos en la evaluación del SRI desarrollado.

REFERENCIAS [1] J. A. Olivas, Búsqueda Eficaz de Información en la Web. La

Plata, Buenos Aires, Argentina: Editorial de la Universidad Nacional de La Plata (EDUNLP), 2011.

[2] G. Salton y M. Mcgill, Introduction to Modern Information Retrieval. McGraw-Hill, Inc., 1983.

[3] G. Kowalski, Information Retrieval Systems: Theory and Implementation, 1st ed. Norwell, MA, USA: Kluwer Academic Publishers, 1997.

[4] R. Baeza-Yates y B. Ribeiro-Neto, Modern information retrieval, vol. 463. ACM press New York., 1999.

[5] J. Serrano-Guerrero, F. P. Romero, J. A. Olivas, y J. de la Mata, «BUDI: Architecture for fuzzy search in documental repositories», Mathw. Soft Comput., vol. 16, n.o 1, pp. 71–85, 2009.

[6] J. de la Mata, J. A. Olivas, y J. Serrano-Guerrero, «Overview of an Agent Based Search Engine Architecture», en Proc. Of the Int. Conf. On Artificial Intelligence IC-AI’04, Las Vegas, USA, 2004, vol. I, pp. 62-67.

[7] S. Sastre-Suárez y E. Pastor-Ramon, «Evaluación de metabuscadores gratuitos especializados en ciencias de la salud», El Prof. Inf., vol. 20, n.o 6, pp. 639–644, 2011.

[8] J. L. Orihuela, «Guía de recursos en Internet para Investigadores», ECuaderno Recuperat, vol. 30, n.o 10, 2009.

[9] S. Jung, J. L. Herlocker, J. Webster, M. Mellinger, y J. Frumkin, «LibraryFind: System design and usability testing of academic metasearch system», J. Am. Soc. Inf. Sci. Technol., vol. 59, n.o 3, pp. 375-389, feb. 2008.

[10] M. de la Villa, S. García, y M. J. Maña, «¿De verdad sabes lo que quieres buscar? Expansión guiada visualmente de la cadena de búsqueda usando ontologías y grafos de conceptos», Proces. Leng. Nat., vol. 47, n.o 0, pp. 21-29, sep. 2011.

[11] Y. Chang, I. Ounis, y M. Kim, «Query reformulation using automatically generated query concepts from a document space», Inf. Process. Manag., vol. 42, n.o 2, pp. 453-468, mar. 2006.

[12] J. Ruiz-Morilla, J. Serrano-Guerrero, J. Olivas, y E. Viñas, «Representación Múltiple de Consultas: Una alternativa a la Expansión de Consultas en Sistemas de Recuperación de Información», en Actas del XV Congreso Español sobre Tecnologías y Lógica Fuzzy. ESTYLF, 2010, pp. 531–536.

[13] S. Gauch y J. B. Smith, «An expert system for automatic query reformation», J. Am. Soc. Inf. Sci., vol. 44, n.o 3, pp. 124-136.

[14] J. C. French, D. E. Brown, y N.-H. Kim, «A classification approach to Boolean query reformulation», J. Am. Soc. Inf. Sci., vol. 48, n.o 8, pp. 694-706, ago. 1997.

[15] S. Delisle, «Towards a better integration of data mining and decision support via computational intelligence», en Sixteenth International Workshop on Database and Expert Systems Applications, 2005. Proceedings, 2005, pp. 720 - 724.

[16] A. Muñoz y J. Aguilar, «Ontología para bases de datos orientadas a objetos y multimedia», Av. En Sist. E Informática, vol. 6, n.o 2, pp. 167–184, 2009.

[17] S. E. S. Sánchez López, «Modelo de indexacion de formas en sistemas VIR basado en ontologias», Maestría, Universidad de las Américas Puebla, México, 2007.

[18] J. Bollen, H. Van de Sompel, A. Hagberg, y R. Chute, «A Principal Component Analysis of 39 Scientific Impact Measures», PLoS ONE, vol. 4, n.o 6, p. e6022, jun. 2009.

[19] D. A. Pendlebury, «The use and misuse of journal metrics and other citation indicators», Arch. Immunol. Ther. Exp. (Warsz.), vol. 57, n.o 1, pp. 1-11, feb. 2009.

[20] Garfield E, «The history and meaning of the journal impact factor», JAMA, vol. 295, n.o 1, pp. 90-93, ene. 2006.

[21] B. Gonzalez-Pereira, V. Guerrero-Bote, y F. Moya-Anegon, «The SJR indicator: A new indicator of journals’ scientific prestige», arXiv:0912.4141, dic. 2009.

[22] CORE, CORE Conference Ranking. Computer Research & Education of Australia, 2008.

[23] J. E. Hirsch, «An index to quantify an individual’s scientific research output», Proc. Natl. Acad. Sci. U. S. A., vol. 102, n.o 46, pp. 16569-16572, nov. 2005.

[24] L. Egghe, «An improvement of the H-index: the G-index», ISSI Newsl., vol. 2, n.o 1, pp. 8–9, 2006.

[25] B. Jin, «The AR-index: complementing the h-index», ISSI Newsl., vol. 3, n.o 1, p. 6, 2007.

[26] L. Page, S. Brin, R. Motwani, y T. Winograd, «The PageRank Citation Ranking: Bringing Order to the Web.», 11-nov-1999. [En línea]. Disponible en: http://ilpubs.stanford.edu:8090/422/. [Accedido: 05-abr-2014].

[27] H. Kuna, M. Rey, E. Martini, L. Solonezen, R. Sueldo, y J. G. A. Pautsch, «Generación de sistemas de recuperación de información para la gestión documental en el área de las Ciencias de la Computación», presentado en XV Workshop de Investigadores en Ciencias de la Computación, 2013.

[28] J. A. Olivas, P. J. Garcés, y F. P. Romero, «An application of the FIS-CRM model to the FISS metasearcher: Using fuzzy


114

synonymy and fuzzy generality for representing concepts in documents», Int. J. Approx. Reason., vol. 34, n.o 2-3, pp. 201-219, nov. 2003.

[29] H. Kuna, M. Rey, E. Martini, L. Solonezen, y R. Sueldo, «Generación de un algoritmo de ranking para documentos científicos del área de las ciencias de la computación», presentado en XVIII Congreso Argentino de Ciencias de la Computación, 2013.

[30] N. F. Noy y D. L. Mcguinness, «Ontology Development 101: A Guide to Creating Your First Ontology», 2001.

[31] E. A. Feigenbaum, A. Barr, y P. R. Cohen, The handbook of artificial intelligence. Addison-Wesley New York, 1989.

[32] E. Rich y K. Knight, «Artificial intelligence», McGraw-Hill New, 1991.

[33] N. J. Nilsson, Principles of artificial intelligence. Springer, 1982.

[34] Stanford Center for Biomedical Informatics Research, Protègè. Stanford University, 2014.

[35] L. Leydesdorff, F. de Moya-Anegón, y V. P. Guerrero-Bote, «Journal maps on the basis of Scopus data: A comparison with the Journal Citation Reports of the ISI», J. Am. Soc. Inf. Sci. Technol., vol. 61, n.o 2, pp. 352–369, 2010.

[36] M. E. Falagas, V. D. Kouranos, R. Arencibia-Jorge, y D. E. Karageorgopoulos, «Comparison of SCImago journal rank indicator with journal impact factor», FASEB J., vol. 22, n.o 8, pp. 2623-2628, ene. 2008.

[37] C.-T. Zhang, «The e-Index, Complementing the h-Index for Excess Citations», PLoS ONE, vol. 4, n.o 5, p. e5429, may 2009.

[38] A. Sidiropoulos, D. Katsaros, y Y. Manolopoulos, «Generalized Hirsch h-index for disclosing latent facts in citation networks», Scientometrics, vol. 72, n.o 2, pp. 253–280, 2007.

Horacio D. Kuna es Licenciado en Sistemas egresado de la Universidad de Morón, Master en Ingeniería del Software egresado del ITBA y la Universidad Politécnica de Madrid. Profesor Titular, Director del Departamento de Informática y del Programa de Investigación en Computación de

la Fac. De Cs.Exactas Químicas y Nat. De la Universidad Nacional de Misiones. Doctorando de Ingeniería en Sistemas y Computación, Universidad de Málaga – Tesis depositada en 2014. Docente investigador, Facultad de Ingeniería, Universidad Nacional de Itapua, Paraguay.

Rey Martin es Licenciado en Sistemas de Información. Investigador del Departamento de Informática. Facultad de Ciencias Exactas Químicas y Naturales. Universidad Nacional de Misiones.

Esteban Martini es Analista en Sistemas de Computación y tesista de la Licenciatura en Sistemas de Información. Investigador del Departamento de Informática. Facultad de Ciencias Exactas Químicas y Naturales. Universidad Nacional de Misiones. Lisandro Solonezen es Analista en Sistemas de Computación y tesista de la Licenciatura en Sistemas de Información. Investigador del Departamento de Informática. Facultad de Ciencias Exactas Químicas y Naturales. Universidad Nacional de Misiones. Lucas Podkowa es tesista de la Licenciatura en Sistemas de Información. Investigador del Departamento de Informática. Facultad de Ciencias Exactas Químicas y Naturales. Universidad Nacional de Misiones.

Rodríguez, J., Merlino, H., Fernández, E. 2014. Comportamiento Adaptable de Chatbots Dependiente del Contexto Revista Latinoamericana de Ingeniería de Software, 2(2): 115-136, ISSN 2314-2642

115

Comportamiento Adaptable de Chatbots Dependiente del Contexto

Juan Manuel Rodríguez1, Hernán Merlino1,2, Enrique Fernández1,2 1. Cátedra de Sistemas de Programación no Convencional de Robots. Facultad de Ingeniería. Universidad de Buenos Aires 2. Laboratorio de Investigación y Desarrollo en Arquitecturas Complejas (LIDAC). Grupo de Investigación en Sistemas de

Información (GISI). Universidad Nacional de Lanús. Argentina [email protected]

Resumen—El objeto de este trabajo es el estudio de los sistemas llamados chatbots, sus limitaciones actuales y sus posibilidades de mejora. En particular aquellas basadas en la interpretación pragmática del discurso o contexto. Se proponen una serie de algoritmos tendientes a mejorar un chatbot existente: ALICE utilizando el algoritmo RAP (Resolution of Anaphora Procedure) y una red neuronal artificial.

Palabras Clave—Resolution of Anaphora Procedure (RAP), AIML, chatbot, ALICE, Perceptron, SOM, Kohone, PLN.

I. INTRODUCCIÓN El tema de este trabajo de investigación son los programas

(software) llamados comúnmente chatbots. Estos son algoritmos de computadora, que utilizan procesamiento de lenguaje natural (NLP: Natural Language Processing) en un sistema de preguntas y respuestas (QA systems: question-answering systems.) Estos sistemas han sido definidos también como sistemas expertos que usan razonamiento basado en casos (CBR: case base reasoning) [19].

El ideal perseguido detrás de estos sistemas es que puedan "comportarse" de forma indistinguible de un ser humano, donde en este caso "comportarse" significa que puedan dar respuestas satisfactorias a un interlocutor humano tal y como lo haría una persona durante un dialogo. Hoy en día los chatbots existentes están lejos de lograr este cometido aunque existen sistemas que han dado respuestas suficientemente satisfactorias como para engañar a un interlocutor humano al menos durante unos instantes, ejemplos de estos diálogos pueden verse en [11]; en este trabajo se analizarán en detalles los sistemas ALICE y ELIZA.

El interés detrás del ideal de funcionamiento de un chatbot va desde lo filosófico, hasta lo pragmático, el matemático británico Alan Turing sostuvo en [18] que un chatbot capaz de pasar cierta prueba, hoy conocida como Test de Turing era un fuerte indicio de que las maquinas podían pensar. Por otro lado el creador de AIML sostiene en [19] que un sistema capaz de comunicarse mediante el dialogo con un ser humano podría convertirse en un nuevo tipo de interfaz de usuario, en donde el usuario dejaría de utilizar comandos, ventanas, iconos, etc. para simplemente indicarle al sistema lo que quiere hacer de forma meramente coloquial.

A pesar de las obvias limitaciones de los chatbots actuales muchos son utilizados comercialmente de forma más o menos exitosa, son utilizados como agentes automáticos en videojuegos, asistentes de mesa de ayuda virtual o "amigos virtuales" en redes de mensajería (se pueden ver ejemplos concretos en la sección II.B.4)

Finalmente cabe destacar que el problema del correcto funcionamiento de los chatbots se enmarca dentro de la problemática del procesamiento del lenguaje natural, la cual es una de las áreas más complejas dentro de los llamados sistemas inteligentes.

A. Objetivos del trabajo El objetivo del presente trabajo es buscar una forma de

mejorar la calidad de las respuestas y del dialogo en general que puede generar un chatbot; para ello se tomará una tecnología (en el terminó más amplio posible, entiéndase: lenguaje de programación, conjunto de datos, metodología de trabajo y/o comportamiento general de un algoritmo) utilizada en un chatbot existente y se mejorará su comportamiento en relación con la interpretación pragmática del discurso (o dialogo en este caso). Más adelante, en la sección III.A se detallarán algunos de los problemas encontrados en los chatbots, como ser la dificultad que tienen estos sistemas para dar una respuesta satisfactoria cuando esta depende de elementos presentes en el "contexto", como ser la resolución anafórica de referentes.

II. ESTADO DE LA CUESTIÓN El presente capítulo describe los algoritmos y sistemas

relevantes sobre el tema de estudio al momento de escribir esta investigación así como los avances científicos en el área. La primera sección muestra el estado de los chatbots actuales en general (II.A), la segunda sección presenta la utilización de sistemas inteligentes en relación con el procesamiento de lenguaje natural (II.B), en la tercer sección (II.C) se hace una introducción a la problemática actual, la cual será desarrollada en el próximo capítulo y por último en la cuarta sección (II.D) del presente capítulo se detallan las tecnologías que serán utilizadas en la resolución del problema.

A. Chatbots Los chatbots son programas, software, (entiéndase un

conjuntos de algoritmos), que utilizan procesamiento de lenguaje natural (NLP: Natural Language Processing) en un sistema de preguntas y respuestas (QA systems: question-answering systems) [2]. Estos sistemas han sido definidos también como sistemas expertos que usan razonamiento basado en casos (CBR: case base reasoning) [19]. La finalidad de dichos sistemas es simular un dialogo inteligente con interlocutor humano, ya sea mediante mensajes de texto a través de una consola o bien mediante la voz.

1) Orígenes del planteo


116

En 1950 el matemático británico Alan Turing en una publicación científica propuso una forma de responder al interrogante: "¿Pueden pensar las maquinas?" [18]. Su método consistía en la implementación de un juego al que llamó: The imitation game (el juego de la imitación) en el cual participan dos personas y una maquina. Una de las personas actúa como juez o jurado y debe discernir quien de los restantes es la persona. Por supuesto que tanto la otra persona como la maquina no están en la misma habitación que el jurado, y este solo puede comunicarse con ambas mediante preguntas escritas, las cuales son respondidas en igual forma. Turing sostuvo que si la maquina podía engañar al jurado por una cantidad de tiempo a definir, entonces se podría considerar que dicha maquina piensa. A esta prueba se la llama comúnmente: Test de Turing

Al día de hoy no ha sido creado un sistema capaz de pasar de forma satisfactoria dicha prueba.

La premisa de Turing de que una máquina capaz de pasar dicha prueba es una máquina que puede pensar fue rebatida por Jhon Searle [16] con el argumento de la habitación china. También Roger Penrose [14] ha rebatido mediante otros argumentos el punto de vista de Turing.

2) Primera aproximación real: ELIZA

El primer chatbot que logró responder a interrogantes hechos a través de una consola de texto y confundir a una persona al punto de no saber esta si en verdad estaba hablando con una maquina o no fue ELIZA. Por supuesto que dicha confusión se daba solo en las primeras líneas del dialogo y con determinadas frases.

ELIZA fue diseñado en 1966 por Joseph Weizenbaum. El chatbot parodia a un psicólogo en su manera de responder ya que en general sus respuestas son reformulaciones de las frases de entrada del usuario [20]

De forma esquemática, el algoritmo detrás de ELIZA busca palabras claves en una frase de entrada de un usuario y luego utilizando el resto de la oración hace una reformulación de la sentencia original, esta forma de responder solo es coherente en el ámbito del psicoanálisis, entre las partes: paciente y doctor. Por ejemplo: ante la frase de entrada: "It seems that you hate me", ELIZA detectaría las palabras claves: "you" y "me". Aplicaría luego un template que descompondría la frase original en cuatro partes:

(1) It seems that (2) you (3) hate (4) me.

Finalmente realizaría la reformulación de la frase original, una respuesta posible sería: "What makes you think I hate you" [20]. ELIZA tiene además otros mecanismos para armar respuestas, pero el descripto es el principal.

3) Concurso Loebner (Loebner Prize)

El Premio Loebner de Inteligencia Artificial (The Loebner Prize for artificial intelligence) es la primera instancia formal de un Test de Turing. En 1990 Hugh Loebner acordó con el Centro de Estudios del Comportamiento de Cambridge (The Cambridge Center for Behavioral Studies) diseñar un certamen designado para implementar el Test de Turing. El Dr. Loebner ofreció un premio de 100 000 dólares y una medalla de oro para la primera computadora cuyas respuestas fueran indistinguibles de respuestas humanas. Todos los años en dicho certamen se otorga un premio de 2.000 dólares y una medalla de bronce a la computadora que se acerca más a un ser humano

en su forma de responder. El ganador del certamen anual es el mejor en relación con los otros concursantes de ese mismo año y no en un sentido absoluto [8]

Los primeros años los premios fueron ganados por chatbots que implementaban el funcionamiento básico de ELIZA. Sin embargo los años subsiguientes aparecieron otros tipos de chatbots más sofisticados que empezaron a ocupar los primeros puestos. Una tecnología que apareció para el desarrollo de chatbots más complejos fue AIML y en particular una implementación de chatbot con dicha tecnología: ALICE salió vencedor del certamen en tres oportunidades. [11] [1]

Alguno de los chatbots que han participado en el certamen se detallan debajo:

TABLA I. DETALLES PC THERAPIST

Nombre PC THERAPIST

Descripción Primer programa en ganar el Premio Loebner. Este chatbot fue escrito en 1986 y está basado en ELIZA

Creador Joseph Weintraub

TABLA II. DETALLES JULIA

Nombre Julia

Descripción Chatbot basado en Eliza, participó en el concurso Loebner del año 1994, salió cuarta de cinco chatbots.

Disponible

http://www.lazytd.com/lti/julia/

TABLA III. DETALLES BRIAN

Nombre Brian

Descripción Este chatbot está escrito en C++, extiende la idea general del "terapista" que utiliza ELIZA. Ganó el tercer lugar en el concurso Loebner 1998

Disponible

http://www.strout.net/info/science/ai/brian/

TABLA IV. DETALLES ALICE

Nombre ALICE

Descripción ALICE está desarrollado sobre AIML y fue ganador del premio Loebner en tres oportunidades.

Disponible

http://www.pandorabots.com/pandora/talk?botid=f5d922d97e345aa1

TABLA V. DETALLES EUGENE GOOSTMAN

Nombre Eugene Goostman

Descripción Segundo en el concurso Loebener de 2005.

Disponible

http://www.mangoost.com/bot/

TABLA VI. DETALLES JABBERWACKY

Nombre Jabberwacky

Descripción Jabberwacky fue ganador del premio Loebner en dos oportunidades.

Disponible

http://www.jabberwacky.com/

TABLA VII. DETALLES ULTRA HAL


117

Nombre Ultra Hal

Descripción Este chatbot ganó el primer lugar en el concurso Loebner del año 2007.

Disponible http://www.zabaware.com/webhal/index.html

Las transcripciones de las conversaciones entre los jurados

y los chatbots están todas disponibles de forma on-line. Además algunos de los chatbots están disponibles en internet para que cualquier persona pueda interactuar con ellos, sin embargo solo un par están disponibles para que cualquiera pueda observar su funcionamiento, de los últimos ganadores del certamen, ALICE es uno de estos.

4) Implementación y utilización comercial de chatbots

Si bien los chatbots aún tienen demasiados problemas para que sean adoptados como una tecnología solida hay casos puntuales en donde su utilización puede considerarse exitosa. Como ejemplos se pueden nombrar ciertos chatbots creados para el mensajero instantáneo de Microsoft (Messenger o MSN). Una empresa llamada IMI desarrolló un intérprete de AIML en C# para que sea posible crear en este lenguaje chatbots para Microsoft Messenger y ya se dispone de una lista de chatbots existentes para MSN, incluyendo algunos como Robin o Wilma creados para un propósito especifico distinto del mero interés académico.

Robin es un chatbot creado por el Ministerio de Sanidad y Consumo de España. Su función es informar a los jóvenes a través de Messenger sobre enfermedades de transmisión sexual y consumo de alcohol.

Microsoft creó su propio chatbot, Encarta Instant Answer, para promocionar su enciclopedia encarta, sin embargo con la finalización de dicho producto por parte de Microsoft el chabot fue dado de baja.

Algunos sistemas informáticos como Remedy, utilizan chatbots para que los usuarios puedan evacuar consultas comunes de manera rápida, estos chatbots simulan un operario de Help Desk.

B. Procesamiento de Lenguaje Natural La presente sección describe la utilización de sistemas

inteligentes en relación con el procesamiento de lenguaje natural como se anticipó.

1) Pragmática

Si bien una cadena de palabras puede tener una o varias interpretaciones semánticas, estas interpretaciones pueden ser incompletas si no se añade la información dependiente del contexto sobre la situación actual de cada interpretación posible.

La pragmática o pragmalingüística es un subcampo de la lingüística que se interesa por el modo en que el contexto influye en la interpretación del significado. El contexto debe entenderse como situación, ya que puede incluir cualquier aspecto extralingüístico: situación comunicativa, conocimiento compartido por los hablantes, relaciones interpersonales, etc. La pragmática toma en consideración los factores extralingüísticos que condicionan el uso del lenguaje, esto es, todos aquellos factores a los que no se hace referencia en un estudio puramente formal.

Como en una conversación vía chat, dos entidades que se comunican no comparten más que sus palabras, todo el contexto queda limitado a eso, a lo que se dijo anteriormente. A

pesar de la reducción notable de lo que habría que evaluar para deducir el contexto, el problema sigue siendo de una complejidad enorme.

2) Resolución de referentes

Según [15]: "La necesidad más obvia de información pragmática es en la resolución del significado de referentes, que son frases que hacen referencia directamente a la situación actual. Por ejemplo en, en la frase «yo estoy en Boston hoy», la interpretación de los referentes «yo» y «hoy» depende de quién declare la frase.[...] El oyente que percibe un acto de habla debería también percibir qué hablante es y usar esta información para resolver el referente." Es decir que el oyente debería de poder discernir quien es "yo" y cuando es "hoy".

La resolución por referencia es la interpretación de un pronombre o una frase nominativa definitiva que hace referencia a un objeto en el mundo (En lingüística, mencionar algo que ya ha sido introducido se llama referencia anafórica. Referenciar algo que todavía tiene que ser introducido se llama referencia catafórica). La resolución se basa en el conocimiento del mundo en las partes previas al discurso. Consideremos el pasaje:

«Juan paró al camarero. Él pidió un sándwich de jamón.»

Para entender que «él» en la segunda oración se refiere a Juan, necesitamos haber entendido que en la primera oración menciona dos personas y que Juan está ejerciendo el papel de cliente y por ello es capaz de pedir mientras que el camarero no lo es. Usualmente, la resolución de referencias es un problema en donde se debe seleccionar una referencia de una lista de candidatas." [15]

Han sido diseñados una gran cantidad de algoritmos de resolución por referencia, dos de los más conocidos son, el algoritmo pronoun references [6] y Pronominal Anaphora Resolution [7]

C. Problemática actual En la actualidad según las publicaciones anuales de los

resultados del certamen: Loebner Prize (http://www.loebner. net/Prizef/loebner-prize.html) no hay diálogos entre chatbots y personas que logren pasar de forma satisfactoria el test de Turing, tampoco de que dichas conversaciones se asemejen a una conversación humana o incluso coherente. Hay varios problemas a superar, pero sin duda uno de los más evidentes es la interpretación pragmática de la conversación. Los chatbots no pueden seguir el hilo de una conversación por mucho tiempo (dando respuestas que satisfagan a su interlocutor) ya que no logran resolver las referencias anafóricas ya sean de tipo correferencial, de sentido o elípticas:

Sin embargo logran dar respuestas suficientemente satisfactorias a preguntas o frases armadas, en donde no hay ninguna referencia anafórica, como por ejemplo: "¿Qué edad tienes tú?" o "Mi nombre es Juan". Si bien en el primer ejemplo hay un único referente: "tú" este referencia directamente al chatbot y no es un referente que necesita ser buscado en el dialogo, como sería el caso de "¿Qué edad tiene él?". Este tipo de frases son mencionadas a lo largo de este trabajo como frases: "independientes del contexto" en oposición a las otras que son mencionadas como frases: "dependientes del contexto"

La mitad de la problemática reside en poder distinguir cuando una frase es "independiente del contexto" y cuando es "dependiente del contexto", la otra mitad es como transformar


118

las frases "dependientes del contexto" en frases "independientes del contexto".

D. Tecnología a utilizar Se presentan en esta sección las tres tecnologías principales

que serán combinadas para lograr mejorar la interpretación pragmática del dialogo en un chatbot. La primera es: redes neuronales artificiales; más específicamente la red back propagation o de retropropagación, que se explica maqs adelante en el punto y la red SOM (Kohnonen) o auto organizada que se explica en parrafos siguientes; la segunda tecnología es el algoritmo Pronominal Anaphora Resolution, por último se describirá el lenguaje AIML y su mecánica que es la base sobre la cual está construido el chatbot: ALICE que es el punto de partida del presente trabajo.

1) Redes neuronales artificiales

Las redes neuronales artificiales (RNA) imitan la estructura física del sistema nervioso, con la intención de construir sistemas de procesamiento de la información paralelos, distribuidos y adaptativos, que puedan presentar un cierto comportamiento «inteligente»" [12]

Para ampliar la definición anterior se debe añadir que están compuestas por pequeñas unidades llamadas neuronas artificiales, las cuales pueden recibir información de entrada, en general valores numéricos dentro de un rango (o valores de tensión para implementaciones de hardware), la cual pueden modificar y luego devolver como salida. Estas unidades pueden conectarse entre sí uniendo las entradas de unas a las salidas de otras formando verdaderas redes, incluso estas interconexiones, llamadas sinapsis, pueden ser ponderadas, por un valor llamado peso que modifica el valor de salida de una neurona antes de que ingrese en otra.

Las neuronas que reciben los datos iniciales conforman lo que se conoce como: "capa de entrada" mientras que las que devuelven el último valor sin que este lo recoja ninguna otra neurona conforman la "capa de salida". Entre ambas capas puede haber otras más, llamadas capas ocultas.

Estos conceptos pueden ser definidos de una manera mucho más rigurosa desde un punto de vista matemático. A continuación se da la definición de [13]:

Una red neuronal artificial es un grafo dirigido, con las siguientes propiedades:

1) A cada nodo i se asocia una variable de estado xi. 2) A cada conexión (i,j) de los nodos i y j se asocia un peso

wij ∈ ℜ 3) A cada nodo i se asocia un umbral θi. 4) Para cada nodo i se define una función ƒi(xj, wij, θi), que

depende de los pesos de sus conexiones, del umbral y de los estados de los nodos j a él conectados. Esta función proporciona el nuevo estado del nodo.

Donde los nodos son las neuronas y las conexiones son las sinapsis en la terminología más común. Y según la definición anterior:

Neurona de entrada: neurona sin sinapsis entrantes. Neurona de salida: neurona sin sinapsis salientes Neurona oculta: toda neurona que no es de entrada ni de

salida.

a) Perceptrón multicapa

Un perceptrón multicapa (MLP: Multi-Layer Perceptron) es un perceptrón simple con capas ocultas añadidas. Esta arquitectura suele entrenarse mediante el algoritmo denominado retropropagación de errores o Back Propagation o bien haciendo uso de alguna de sus variantes o derivados, motivo por el que en muchas ocasiones el conjunto arquitectura MLP + Aprendizaje con Back Propagation suele denominarse red de retropropagación o simplemente Back Propagation [12].

El perceptrón simple es un modelo neuronal unidireccional, compuesto por dos capas de neuronas, una de entrada y otra de salida (Figura 1). La operación de una red de este tipo, con n neuronas de entrada y m de salida, se puede expresar como:

(1)

Fig. 1. Perceptrón simple

Las neuronas de entrada no realizan ningún computo, únicamente envían la información a las neuronas de salida. La función de activación de las neuronas de la capa de salida podría ser por ejemplo la función escalón o bien la función sigmoidal que son dos de las más utilizadas.

Para poder expresar la función matemática de la forma de operatoria de un MLP con una capa oculta y neuronas de salida lineal, como el que se muestra en la Figura 2 denominaremos xi a las entradas de la red, yi a las salidas de la capa oculta y zk a las de la capa final (y globales de la red); tk serán las salida objetivo (target). Por otro lado, wij son los pesos de la capa oculta y θj sus umbrales, w'kj los pesos de la capa de salida y θ'k sus umbrales. Entonces tenemos una expresión como la siguiente:

(2) Siendo ƒ() de tipo sigmoidal (Figura 3) como por ejemplo:

(3)


119

Fig. 2. MLP

Fig. 3. función sigmoidal

b) Perceptrón multicapa como aproximador universal de funciones

En 1989 Funahashi [3] demostró que un MLP de una única capa oculta constituía un aproximador universal de funciones (aunque hubo otras demostraciones más o menos simultáneas.)

Teorema de [3]: Sea ƒ(x) una función no constante, acotada y monótona creciente. Sea K un subconjunto compacto (acotado y cerrado) de ℜn. Sea un número real ε ∈ ℜ, (error) y sea un entero k ∈ Z, tal que k ≥ 3, que fijamos (cantidad de capas). En estas condiciones se tiene que:

Cualquier mapping g:x ∈ K →(g1(x), g2(x),...,gm(x)) ∈ ℜm, con gi (x) sumables en K, puede ser aproximado en el sentido de la topología L2 en K por el mapping entrada-salida representado por una red neuronal unidireccional (MLP) de k capas(k-2 ocultas), con ƒ(x) como función de transferencia de las neuronas ocultas, y funciones líneales para las capas de entrada y de salida. En otras palabras:

∀ ε > 0, ∃ un MLP de las características anteriores que implementa el mapping:

(4) de manera que:

(5)

En resumen un MLP de una única capa oculta (podría ser cualquier cantidad de estas) puede aproximar hasta el nivel deseado cualquier función continua en un intervalo, por lo tanto, las redes neuronales multicapa unidireccionales son aproximadores universales de funciones.

c) Back Propagation

El concepto de propagar hacia atrás los errores, durante el proceso de actualización de los pesos sinápticos da lugar al nombre del algoritmo.

Fig. 4. MLP y Back Propagation

En primer lugar se calcula la expresión denominada: "señal de error" la cual es proporcional al error de salida actual de la red.

Con este valor se calcula la actualización de los pesos sinápticos de la capa de salida. A continuación se propagan hacia atrás los errores (señal de error) a través de las sinapsis de la capa oculta; con esta se calcula la actualización de los pesos sinápticos de las capas ocultas. Puede realizarse con cualquier cantidad de capas ocultas.

Sea un MLP de tres capas cuya arquitectura se presenta en la Figura 4. Y sea un patrón de entrada:

X μ = (μ=1,..,p): La operación global de esta arquitectura se expresa del

siguiente modo:

(6)

las funciones de activación de las neuronas ocultas ƒ(h) son de tipo sigmoidal, con h el potencial postsináptico o local. La función "coste" de la que se parte es el error cuadrático medio:

(7)

La minimización se lleva a cabo mediante el descenso por el gradiente, como en este ejemplo hay una capa oculta, se tendrá un gradiente respecto de los pesos de la capa de salida y otro respecto de los de la capa oculta. Las expresiones son las siguientes:


120

(8)

Las expresiones de actualización de los pesos se obtienen sólo con derivar teniendo en cuenta las dependencias funcionales y aplicando adecuadamente la regla de la cadena:

(9)

(10)

La actualización de los umbrales (bias) se realiza haciendo uso de estas mismas expresiones, considerando que el umbral es un caso particular de peso sináptico cuya entrada es una constante igual a -1. [12]

De forma esquemática sus pasos son los siguientes: 1. Inicializar los pesos y los umbrales iniciales de cada

neurona. Hay varias posibilidades de inicialización siendo las más comunes las que introducen valores aleatorios pequeños.

2. Para cada patrón del conjunto de los datos de entrenamiento:

a. Obtener la respuesta de la red ante ese patrón. Esta parte se consigue propagando la entrada hacia adelante, ya que este tipo de red (MLP) es feedforward. Las salidas de una capa sirven como entrada a las neuronas de la capa siguiente, procesándolas de acuerdo a la regla de propagación y la función de activación correspondientes.

b. Calcular los errores asociados según las ecuaciones 2.9 y 2.10

c. Calcular los incrementos parciales (sumandos de las sumatorias). Estos incrementos dependen de los errores calculados en 2.b

3. Calcular el incremento total, para todos los patrones, de los pesos y los umbrales según las expresiones en las ecuaciones 2.9 y 2.10

4. Actualizar pesos y umbrales 5. Calcular el error actual y volver al paso 2 si no es

satisfactorio.

d) Redes SOM, Kohonen

Se hará una breve introducción a este tipo de red ya que finalmente no fue utilizada en la implementación de la solución. Aunque sí fueron utilizadas durante las fases de prueba.

En 1982 T. Kohonen presentó un modelo de red neuronal con capacidad para formar mapas de características de manera similar a como ocurre en el cerebro. Este modelo tiene dos variantes denominadas LCQ (Learning vector quantization) y TPM (Topologu Preserving Map) o SOM (Self Organizing Map). Ambas se basan en el principio de formación de mapas topológicos para establecer características comunes entre informaciones (vectores) de entrada de la red, aunque difieren

en las dimensiones de estos, siendo de una sola dimensión en el caso de LVQ y bidimensional e incluso tridimensional en la red TPM. [García Martínez,Servente,Pasquini 2003]

La arquitectura de dicha red puede ser descripta como de dos capas: con N neuronas de entrada y M se salida (Figura 5)

Fig. 5. Estructura de una red de Kohonen

Cada una de las N neuronas de entrada se conecta a las M de salida a través de conexiones hacia adelante (feedforward). Entre las neuronas de la capa de salida, puede decirse que existen conexiones laterales de inhibición (peso negativo) implícitas, pues aunque no estén conectadas, cada una de estas neuronas va a tener cierta influencia sobre sus vecinas.

La influencia que cada neurona ejerce sobre las demás es función de las distancia entre ellas, siendo muy pequeñas cuando están muy alejadas. Es frecuente que dicha influencia tenga la forma de que se muestra en la Figura 6.

La versión del modelo denominado TPM trata de establecer una correspondencia entre los datos de entrada y un espacio bidimensional de salida, creando mapas topológicos de dos dimensiones, de tal forma que ante datos de entrada con características comunes se deben activar neuronas situadas en zonas próximas de la capa de salida:

Fig. 6. función de interacción lateral entre neuronas

e) Funcionamiento de una red de Kohonen

Dado un vector de entrada Ek, tal que Ek = (e1, e2, e3, .....en), para una red como la descripta anteriormente con N neuronas de entrada y M de salida; la salida general de una neurona de salida j será:


121

(11) Donde Intpj es una función como la de la Figura 6 que

representa la influencia lateral de la neurona p sobre la neurona j. La función de activación de las neuronas de salida ƒ(x) será del tipo continuo, líneal o sigmoidal, ya que esta red trabaja con valores reales.

La red revoluciona hasta alcanzar un estado estable en el que solo hay una neurona activada, la ganadora. La formulación matemática del funcionamiento de esta red puede simplificarse así [5]:

(12) Donde || Ek - Wj || es una medida de la diferencia entre el

vector de entrada y el vector de pesos de las conexiones que llegan a la neurona j desde la entrada. Es en estos pesos donde se registran los datos almacenados por la red durante el aprendizaje. Durante el funcionamiento, lo que se pretende es encontrar el dato aprendido más parecido al de entrada para averiguar qué neurona se activará y en qué zona del espacio bidimensional de salida se encuentra. [4]

2) Algoritmo Resolution of Anaphora Procedure

RAP (Resolution of Anaphora Procedure) es un algoritmo para identificar los sintagmas nominales (NP: Noun Phrase) antecedentes de pronombres en tercera persona y anáforas léxicas (reflexivas y reciprocas). El algoritmo se aplica a las propiedades sintácticas de una oración generadas con algún parser de procesamiento de lenguaje natural.

El sintagma es un tipo de constituyente sintáctico (palabra o secuencia de palabras que funcionan en conjunto como una unidad dentro de la estructura jerárquica de la oración) formado por un grupo de palabras que forman otros sub-constituyentes, al menos uno de los cuales es un núcleo sintáctico. Las propiedades combinatorias de un sintagma se derivan de las propiedades de su núcleo sintáctico. Por su parte el núcleo sintáctico es la palabra que da sus características básicas a un sintagma y es por tanto el constituyente más importante o de mayor jerarquía que se encuentra en su interior. RAP contiene los siguientes componentes principales [7]:

Un filtro sintáctico intraoracional para descartar la dependencia anafórica de un pronombre en una NP por razones sintácticas

Un filtro morfológico para descartar la dependencia anafórica de un pronombre en una NP por falta de coincidencias con persona, número o género.

Un procedimiento de identificación de un pleonasmo Un algoritmo de vinculación de anáforas para la identificación de posibles antecedentes asignados de una anáfora léxica dentro de la misma sentencia.

Un procedimiento para la asignación de valores a varios parámetros de relevancia (función gramatical, paralelismo entre funciones gramaticales, frecuencia de mención, proximidad) de un NP. Este procedimiento emplea una

jerarquía de funciones gramaticales según la cual se asignan pesos más relevantes a:

(i) sujeto sobre no sujeto (ii) los objetos directos más otros complementos, (iii) los argumentos de un verbo por sobre complementos

y objetos de frases preposicionales (PP: Prepositional Phrase) que actúan como complemento del verbo (si la frase preposicional está en el predicado, es complemento del verbo)

(iv) los núcleos sustantivos por sobre los complementos de los núcleos sustantivos

Un procedimiento para identificar NPs vinculados anafóricamente como clases equivalentes para las cuales el valor global prominente es la suma de los valores de sus elementos

Un procedimiento de decisión para seleccionar el elemento preferido de una lista de antecedente candidatos para un pronombre.

3) AIML

AIML (Artificial Intelligence Mark-up Language) permite a las personas ingresar conocimiento en chatbots basado en la tecnología de software libre ALICE.

AIML fue desarrollado por la comunidad Alicebot de software libre y el Dr. Richard Wallace durante los años 1995-2000. Fue adaptado de una gramática que no era XML aunque también se llamaba AIML y formó las bases para el primer Alicebot, A.L.I.C.E., (Artificial Linguistic Internet Computer Entity).

AIML describe una clase de objetos de datos llamados objetos AIML y (parcialmente) el comportamiento de los programas de computadora que procesan dichos objetos. Los objetos AIML están formados por unidades llamadas: "topic" y "category", que contienen datos analizados los cuales componen los elementos AIML que encapsulan conocimiento de la forma estímulo-respuesta. [19]

La unidad básica de conocimiento en AIML es una "category" como se mencionó. Cada category se compone de una pregunta de entrada, una respuesta de salida y un contexto opcional. La pregunta, o estímulo, se llama: "pattern". La respuesta se llama: "template". Los dos tipos de contexto opcionales se denominan: "that" y "topic". El lenguaje de los patrones (patterns) en AIML es simple, consiste solamente en palabras, espacios y los símbolos wildcard "_" (guión bajo) y "*" (asterisco). Que representan tanto una palabra, como una serie de palabras o bien nada, la única diferencia entre ellos es la prioridad. Las palabras pueden contener letras y números pero no otros caracteres. El lenguaje de los patrones es case insensitive. Las palabras están separadas por un espacio único.

Uno de los aspectos más importantes de AIML es que implementa recursividad con el operador: "srai". Como menciona el Dr. Wallace en [19] este operador tiene muchos usos:

Reducción simbólica: Reduce las formas gramaticales complejas a otras más simples.

Dividir sentencias largas en dos o más subdivisiones y combinar las respuestas de cada una.

Sinónimos: Muchas entradas diferentes se pueden vincular a una única respuesta.


122

Ortografía: Se puede utilizar para vincular una entrada mal escrita hacia la entrada correcta.

Detección de palabras clave en cualquier lugar de la entrada.

Condicionales: Ciertas formas de ramificación pueden ser implementadas con "srai"

Cualquier combinación de las anteriores. AIML funciona sobre XML, por lo que la base de datos de

conocimientos de un chatbot implementado con AIML no es otra cosa que uno o más archivos XML con varios tags de tipo "category" como el que se muestra a continuación:

<category>

<pattern>ARE YOU RELATED TO ALICE *</pattern> <template> Alice <person/> has been an influence on me. </template>

</category>

Si un chatbot AIML tuviese esta category implementada y un usuario ingresase una frase que comenzase con: "Are you related to Alice", el chabot respondería con la frase: "Alice <person/> has been an influence on me." Donde el tag "<person/>" sería cambiado por el contenido de la frase original que coincidió con el wildacard; por ejemplo si la frase de entrada hubiese sido: "Are you related to Alice Cooper", la respuesta sería: "Alice Cooper has been an influence on me."

a) Manejo del contexto en AIML

Como se mostró en el punto anterior AIML funciona como una gran tabla de dos columnas: patrones de coincidencia (patterns) y salidas (templates); en donde para una frase de entrada dada se busca el mejor patrón de coincidencia y se devuelve la respuesta asociada a dicho patrón. Esta salida podría ser, si está al operador "srai", una nueva frase de entrada, en cuyo caso se devolvería la nueva salida asociada.

Sin embargo AIML implementa tres mecanismos para manejar el contexto, o la interpretación pragmática estos son:

El tag "that”: que contiene una frase que podría haber sido dicha por el chatbot en la línea anterior del dialogo.

Las variables de sesión, variables que pueden ser completadas dinámicamente durante una conversación para ser utilizadas luego.

El tag "topic": que contiene un tema sobre el cual se podría estar hablando en un dialogo entre el chatbot y el usuario El uso del tag that será ilustrado con el siguiente dialogo de

ejemplo: chatbot: Do you like movies? usuario: yes chatbot: I like movies too.

Queda claro que la frase de entrada: "yes" no basta para dar la respuesta satisfactoria del ejemplo, por lo que AIML no buscará simplemente un pattern que coincida con "yes" sino que además buscará que el tag "that" coincida con "Do you like movies?". De esta forma se pueden tener muchas categories con patterns "yes" útiles para diferentes circunstancias.

Se muestra a continuación un ejemplo del uso de las variables de sesión, las cuales se setean en algunas categories, tomese una category como la siguiente:

<category> <pattern>MY NAME IS MIKE</pattern> <template> Hi <set name="name">Mike</set>, I know someone else named

Mike too. </template> </category> Si el usuario ingresó una frase como: "My name is Mike",

además de responder con el contenido del tag "template" el chatbot seteará una variable de sesión llamada: "name" con el nombre: "Mike". Más tarde podrá usar el contenido de esta variable para armar una respuesta a otra entrada diferente.

El tag topic funciona en parte como una variable más de sesión, para alguna category puede setearse la variable de sesión: "topic" para indicar que se está hablando de un tema en particular, por ejemplo:

<category> <pattern>yes</pattern> <that>Do you like movies?<that> <template> I like movies too. </template> <think> <set name="topic">movies</set> </think> </category>

Luego a medida que avanza la conversación, el intérprete AIML podrá verificar además de los tags pattern y that un tercero, que está por sobre category y es el tag topic. Al igual que el tag that no es un tag obligatorio pero si existe las categories dentro de él tendrán mayor prioridad que las otras.

b) ALICE

ALICE es el chatbot más exitoso de todos los implementados con la tecnología AIML. En 2003 contaba con una base de datos de más 40 000 categories. Fue presentado en el certamen The Loebner Prize for artificial intelligence (mencionado en el punto: II.A.3 ) y ganó en tres oportunidades: 2000, 2001 y 2004 [11]. Y en otras llegó a ser finalista.

ALICE corre sobre "Program D" un intérprete de AIML creado en 2001 y antes de eso corría sobre otro intérprete llamado "Program B"; al momento de escribir este informe ALICE se encuentra de forma online para que cualquier persona pueda interactuar con dicho chatbot en la siguiente dirección: "http://alice.pandorabots.com/" y la totalidad de los archivos AIML que componen su base de datos, también llamada "cerebro de ALICE" se encuentra disponible de forma libre y gratuita.

III. DEFINICIÓN DEL PROBLEMA En este capítulo se describe el problema abordado en esta

investigación comenzando con una descripción de la problemática actual (sección III.A) la cual se reducirá a ciertos casos puntuales y bien definidos que comprenderán el alcance de este trabajo (sección III.B); finalmente en la sección III.C se muestran ejemplos de casos reales obtenidos de las transcripciones de conversaciones entre personas y chatbots del concurso Loebner.

A. Problemática actual Uno de los problemas que enfrentan los chatbots

actualmente es la interpretación pragmática del discurso. La mayoría de los chatbots que, solo pueden ser analizados a


123

través de las respuestas que dan, muestran un comportamiento que parece obviar toda información, o buena parte de esta, del dialogo excepto la frase de entrada inmediata. Aún restringiendo la situación comunicativa al conocimiento compartido por los hablantes en el dialogo puntual que se está llevando a cabo. En el caso de AIML, una de las tecnologías actualmente más solidas para la construcción de este tipo de sistemas, el chatbot responde a una frase de entrada según con que patrón de su base de datos de conocimiento coincidió. En algunos casos toma en consideración una variable llamada "topic", ver punto 2.4.3.1 (Manejo del contexto en AIML), para determinar que el patrón de coincidencia pertenezca al mismo tópico de la conversación y en otros verifica también la respuesta dada anteriormente (uso del tag "that".) Sin embargo como muestra el análisis hecho a partir de las transcripciones de las conversaciones del certamen Loebner, estos mecanismos no son suficientes para una completa evaluación del contexto.

Esta falta de "lectura" del contexto, de no considerar en cada nueva respuesta a todo el dialogo como un input y solo tomar como tal a la última frase, lleva al chatbot a cometer un error al generar la respuesta (se considerará error a toda respuesta a una frase de entrada del usuario que no satisface las expectativas de este de igual forma en que lo haría la respuesta de un interlocutor humano en condiciones similares como en el caso de un test de Turing) Dichos errores pueden ser provocados por alguno de los problemas que se listan a continuación:

Resolución de referentes: La resolución del significado de referentes o de anáforas se da cuando se quiere interpretar un pronombre que aparece en la oración y hace referencia a un objeto previamente introducido en el discurso. Ya que por ejemplo el chabot, podría contar en su base de datos con una respuesta satisfactoria para la frase: "Who is Richard Wallace?", sin embargo si un usuario ingresa: "Who is him?" y "him" hiciese referencia a "Richard Wallace" el chatbot no daría una respuesta satisfactoria.

Ambigüedad Léxica: Este problema se da cuando una palabra o frase tiene más de un significado posible y este queda revelado solo en la evaluación del contexto de la conversación, por ejemplo la frase: "The batter hit the ball" parece tener una interpretación no ambigua en la cual un jugador de baseball golpea la bola, pero obtendremos una interpretación diferente si la frase previa es: "the mad scientist unleashed a tidal wave of cake mix towards the ballroom." (En la primer oración "batter" parecería significar: "bateador", "hit": "golpeó" y "ball": pelota, sin embargo al anteponer la segunda oración "batter" significa "masa", "hit": "alcanzó" y "ball": "baile")

Elipsis: La elipsis en lingüística se refiere a ciertas construcciones sintácticas en las que no aparece alguna palabra que se refiera a una entidad lógica necesaria para el sentido de la frase. Por ejemplo en la frase: "Yo corría por la vereda y ellos por la calle". Se omite el verbo "correr" anterior a "por la calle". Incluso hay casos aún más complejos dentro de la problemática de los chatbots como el de la sentencia: "I couldn't open the door" en donde la oración está completa (no falta en principio ninguna palabra) y está correctamente formada pero no contiene mucha información. En el caso de AIML una sentencia de entrada como esa podría coincidir con un patrón con wildcards y devolver una respuesta genérica relacionada con abrir puertas. Sin embargo si la sentencia anterior fuese: "I got home and", se estaba dando más

información y si pudieran ser combinadas ambas sentencias para buscar un patrón, se lograría una respuesta más acorde. Suponiendo, por supuesto, que haya un patrón de coincidencia en AIML para una frase similar a: "I couldn't open [my] home door", por ejemplo. La solución parcial a este problema en AIML es el uso de la variable "topic", esta debería de setease en "home" cuando el usuario ingrese la primer frase, y luego tendría que existir un patrón de coincidencia para: "I couldn't open the door" dentro de dicho topic.

Referencias inexistentes: Este caso es el inverso al primero, el usuario hace referencia a algo o alguien que nunca fue introducido en el discurso y el chatbot responde como si "supiese" de quien o de que se está hablando. Por ejemplo, si un usuario comienza una conversación con "Do you like her?", el chatbot probablemente dará una respuesta del tipo: "yes, I like." que podría pasar desapercibida en la mayoría de los casos pero no en este escenario; No respondería como lo haría un ser humano quien inmediatamente preguntaría por la referencia insatisfecha del pronombre: her. Ejemplo: "Who is her?" o "Who are you talking about?"

Respuestas a interrogaciones cerradas: En muchos casos el chatbot hace preguntas al usuario y luego de que este responde, el chatbot no logra generar una nueva respuesta acorde a las expectativas de su interlocutor. Muchos de esos casos se dan con interrogaciones cerradas, preguntas que pueden ser respondidas con sí o con no ("yes" o "no".) Por ejemplo, si el chatbot emite como "respuesta" la siguiente pregunta cerrada: "Do you like movies?" y el usuario simplemente ingresa como respuesta: "yes" o bien "no", el chatbot buscará a continuación (es el caso de AIML) un patrón que coincida con "yes" o con "no", según sea el caso y terminará dando una respuesta genérica sin relación con el tema de conversación: "movies" en este caso. En cambio si el usuario hubiese ingresado una respuesta como: "yes, I like movies", el chatbot buscaría un patrón de coincidencia con dicha sentencia y encontraría una respuesta más acorde. AIML intenta solucionar este problema de forma más o menos satisfactoria con el tag "that", sin embargo la base de datos de ALICE no tiene entradas para todos los casos de preguntas cerradas posibles dentro del conjunto de preguntas que puede formular el propio chatbot.

B. Alcance propuesto Los problemas mencionados en el punto anterior, no

conforman la totalidad de problemas devenidos de la falta de interpretación pragmática pero son los más evidentes. Si se compara la forma en la cual trabaja el cerebro humano al dialogar, ya sea interpretando oraciones que recibe de su interlocutor o generando las respuestas, con la forma en la cual funcionan los chatbots quedarían en evidencia problemas más profundos y difíciles de resolver, pero eso escapa al objetivo de esta investigación.

El trabajo se centrará en tres problemas básicos, de los mencionados arriba, relacionados con la interpretación pragmática: resolución de referentes, referencias inexistentes y respuestas a interrogantes cerrados.

Para el caso de la resolución de referentes se utilizará el algoritmo: RAP (Resolution of Anaphora Procedure) de Lappin-Leass. Dicho algoritmo ha dado buenos resultados, 74 % de tasa de éxito en la resolución de anáforas ínter-sentencias y 89 % de tasa de éxito en la resolución de anáforas intra-sentencias [7]


124

Para el caso de resolución de referencias inexistentes, se tomarán los casos en donde el algoritmo anterior no haya devuelto referencias y se formulará una pregunta que indague sobre la referencia insatisfecha.

Finalmente se implementará un algoritmo sencillo de reemplazos, para convertir las preguntas en afirmaciones para los casos de respuestas monosilábicas.

Con las soluciones planteadas, que se desarrollarán en el punto siguiente (4), se espera tener un éxito moderado, sabiendo que no solucionarán en su totalidad dichos problemas, se pretende reducir la tasa de respuestas erróneas cada vez que el chatbot se encuentre con alguno de los problemas mencionados.

La implementación de las soluciones propuestas plantea un nuevo problema, que es la conservación de los casos favorables, es decir aquellos casos "pregunta-respuesta" que funcionan correctamente en la actualidad y no necesitan ningún tipo de reformulación ni cambio. La manera de solucionar este nuevo problema será clasificar los casos en favorables y no favorables mediante una red.

C. Ejemplos de casos reales Los siguientes ejemplos fueron obtenidos de las

transcripciones del certamen Loebner 2009 [11]: http://loebner.net/Prizef/2009_Contest/loebner-prize-2LL009.html, 2006:

http://loebner.net/Prizef/2006_Contest/loebner-prize-2006.html y 2004:

http://loebner.net/Prizef/2004_Contest/loebner-prize-2004.html

Ejemplo 1) A continuación se muestra un problema de ambigüedad

léxica y el error en la respuesta del chatbot presentado por: David Levy, llamado: "Do-Much-More" quien resultó vencedor en el certamen del año 2009. (Extracto de la conversación el Juez 2)

chatbot: I don't suppose cars will burn coal, but I wouldn't now for sure. Everything about cars is confidential.

human: Are you experiments confidential? chatbot: Yes I am experiments, but don't worry.

Experiments don't bite! En este ejemplo se muestra como el chatbot "interpretó" de

una forma diferente la sentencia de la persona. Probablemente porque internamente la frase de entrada del usuario hizo coincidencia con un patrón con wildcards (como sería en AIML o ELIZA) "Are you * ", donde la mayoría de las veces "Are you" significa "Eres tu…" y no "Son tus..."

Ejemplo 2) A continuación se muestra un problema de elipsis y el error

en la respuesta del chatbot presentado por: Rollo Carpenter, llamado: "Joan" quien resultó vencedor en el certamen del año 2006.

human: Do you read books? chatbot: Sure I read books. human: Who is your favourite author? chatbot: I don't know. There are so many. Who's your

favourite author?

human: I like Philip Roth chatbot: Are they scary? Aquí el chatbot da una respuesta no satisfactoria a la frase

del usuario "I like Philip Roth", no considera la frase : "my author favorite is Philip Roth".

Ejemplo 3) A continuación se muestran tres problemas juntos: de

resolución de referentes, de referencias inexistentes y elipsis; en el dialogo entre del chatbot presentado por: Rollo Carpenter, llamado: "Joan" quien resultó vencedor en el certamen del año 2006, y el Juez 3 del certamen.

chatbot: I am familiar with her writings. human: Really like what? chatbot: It used to be in a smallish building. It is now in a

part of a larger building. Someday they hope to build a new library

human: Is it safe? chatbot: Probably. human: Is it safe? chatbot: Do you think it's safe? human: Is it safe? chatbot: Of course. human: Is it safe? chatbot: Yes. human: Are you sure? chatbot: It's easy to be sure about something like that

when you're 26 years old! El dialogo que se presenta arriba presenta demasiadas

dificultades juntas para un chatbot, aunque resulte trivial para un ser humano. Primero se tiene la interrogación del usuario: "Is it safe?" la cual presenta una referencia anafórica, aunque no está muy claro a que hace referencia el pronombre "it" podría ser "larger building", en dicho caso la frase quedaría como: "Is [the] larger building safe ?". Ante dicha interrogación, el chatbot responde de forma genérica: "Probably". Luego el usuario vuelve a preguntar nuevamente por tres veces: "Is it safe?", con lo cual queda claro de que la referencia del pronombre "it" no existe, cualquier persona respondería ante la misma situación con un interrogante del estilo: "What do you mean with that question?"

Por último el usuario pregunta: "Are you sure?", aquí hay una elipsis ya que está implícito en la oración "it is safe", si se reformulase la sentencia para eliminar la elipsis la frase quedaría como: "Are you sure that it is safe?". Sin embargo el chatbot devuelve una respuesta genérica que solo hacer referencia a la palabra "sure"

Ejemplo 4) A continuación se muestra un problema de resolución de

referentes y el error en la respuesta del chatbot presentado por: Richard Wallace, llamado: "ALICE" quien resultó vencedor en el certamen del año 2004. (Extracto de la conversación el Juez 2)

human: visiting Dr Loebner, but I live in New Jersey chatbot: I have no idea where that is. Tell me a little

about your life in visiting Dr Loebner but you live in New Jersey.


125

human: it's right across the river from here chatbot: Do you experience any effects of global

warming there? human: oh sure, all the time En la frase del usuario: "it's rigth across the river from

here.", el pronombre "it" está haciendo referencia a "Dr. Loebner('s house)", si la frase se reformulara para eliminar la anáfora quedaría como: "Dr Loebner is rigth across the river from here". Al tener acceso al código y a la base de datos de ALICE es fácil ver que el patrón de coincidencia utilizado fue: "IT IS * HERE", (siendo * un wildcard), la respuesta dada por el chatbot fue una respuesta genérica.

En este caso en particular se presenta otro problema de la lengua y del procesamiento de lenguaje natural en general, no necesariamente relacionado con la interpretación pragmática; la metonimia, La metonimia es una figura del habla en la cual se emplea un objeto para sustituir otro objeto. Aquí "Dr Loebener" en verdad es una figura que se usa en "reemplazo" de "la casa del Dr Loebener".

Ejemplo 5) A continuación se muestra un problema de resolución de

referentes y el error en la respuesta del chatbot presentado por: Richard Wallace, llamado: "ALICE" quien resultó vencedor en el certamen del año 2004. (Extracto de la conversación el Juez 1)

human: What is your favorite operating system? chatbot: Linux is the best operating system. human: What do you like about it? chatbot: it? What do I like about it? human: What do you like about Linux? chatbot: The special effects are the best. En este ejemplo, queda claro para cualquier persona que en

la frase: "What do you like about it?", "it" es una referencia a "Linux". El chatbot no puede resolver esta anáfora y responde a la pregunta textual: "What do you like about it?", el usuario elimina la anáfora y vuelve a hacer la pregunta: "What do you like about Linux?" en este caso el chatbot da una respuesta un poco más satisfactoria, aunque no del todo.

El patrón de coincidencia que encuentra AIML para la última frase de entrada del usuario es: "WHAT DO YOU LIKE ABOUT *", con lo que la respuesta es bastante genérica. Sería igual para: "What do you like about cookies?" por ejemplo.

IV. SOLUCIÓN PROPUESTA En el presente capítulo se describe la solución propuesta a

los problemas planteados en el punto anterior; En el punto 4.1 se esboza el aspecto general de la solución y la forma en que cada una de las tecnologías propuestas se ajustaría a un requerimiento dado. En el punto 4.2 se analizan las diferencias entre las líneas de dialogo: usuario-chatbot consideradas correctas o coherentes (casos favorables) y aquellas consideradas incorrectas (casos desfavorables) que será de mucha importancia para entender el punto 4.3, en donde se describe como se utilizará una RNA para clasificar los casos. En el punto 4.4 se explica la necesidad de utilizar una base de datos relacional en lugar de archivos XML para gestionar la base de datos de conocimiento de ALICE. Por último los puntos 4.5, 4.6 y 4.7 explican los tres mecanismos propuestos

para mejorar la forma de responder de un chatbot basado en AIML teniendo en cuenta la interpretación pragmática.

A. Esbozo general de la solución La premisa general de la investigación es mejorar un

chatbot, o una tecnología de diseño de chatbots, que esté actualmente en el estado del arte (o de la cuestión) y no crear un nuevo chatbot desde cero. Para ello se utilizará como punto de partida el lenguaje AIML y la base de datos de conocimiento de ALICE, ambos libres y disponibles al público general.

El primer paso para encarar la solución consiste en separar los casos favorables de los desfavorables (ver punto siguiente) de forma que para todas aquellas frases de entrada para las cuales ALICE ha dado buenos resultados no haya modificaciones y para todas aquellas frases para las cuales ALICE da respuestas no satisfactorias, aún cuando estas coinciden con algún patrón de la base de datos de conocimientos, se activen mecanismos que revisen la información de contexto, dada solamente por todas las líneas de dialogo anteriores, y la utilicen para convertir el caso desfavorable en un caso favorable.

Para realizar la clasificación se utilizará una red neuronal artificial de tipo Back Propagation, luego para convertir los casos desfavorables en casos favorables se utilizarán tres mecanismos diferentes, el primero y más importante es un algoritmo de resolución de referentes anafóricos (RAP, descripto en 2.42), el segundo es un procedimiento simple para reformular preguntas cerradas como sentencias declarativas, ejemplo: "Do you like movies?" será reformulada como "I like movies" si el usuario hubiese ingresado "yes" como respuesta. El tercer mecanismo es un procedimiento que se activará cuando los demás hayan fallado, se trata de un procedimiento que busca referentes insatisfechos y pregunta por su significado. Por ejemplo si el algoritmo de resolución de referentes anafóricos, falló al tratar de identificar el pronombre "her", en la oración: "Do you like her?" este procedimiento hará que el chatbot devuelva una pregunta como la siguiente: "Who is her?"

B. Distinción entre casos favorables y casos desfavorables Tomando al chatbot ALICE, como modelo inicial a

mejorar, lo primero que se propone hacer es clasificar los casos en favorables y desfavorables. Es decir, para todas aquellas frases de entrada de un usuario, en el conjunto universo de frases posibles, determinar cuáles obtendrán por parte del chatbot, una respuesta satisfactoria (una respuesta que deje al interlocutor satisfecho en igual forma que si hubiese respondido un ser humano en iguales condiciones) y cuáles no.

Planteado en términos absolutos el problema es inabarcable por varia cuestiones a saber:

1) Casos limitados en la base de datos de conocimiento de ALICE

2) Restricción del idioma (en esta investigación se restringe al idioma inglés)

3) Frases inválidas, mal formadas o con errores sintácticos, ortográficos u otros.

4) La imposibilidad de saber de forma objetiva que espera un ser humano al hacer una pregunta. ¿Cómo determinar de forma objetiva que una respuesta es correcta desde el punto de vista de la coherencia de la oración y no de su significado?


126

Con la intensión de acotar el alcance al problema anterior de clasificación se analizaron los casos favorables en los diálogos de ALICE. Se muestran a continuación algunos ejemplos que provienen del certamen Loebener de 2004 [21]. Caso 1)

Judge 1: Do you like movies? Alice: Yes I love film, especially science-fiction

and comedy. Caso 2)

Judge 1: What is your favorite movie? Alice: My favorite movie is Teknolust. Have you

seen it? Caso 3)

Judge 1: Do you have a pet? Alice: No but I like cats very much.

Caso 4) Judge 1: Please, call me Ryan. Alice: Thank you for your request. I am very

pleased to meet you Ryan. Lo que tienen en común estos casos, (como muchos otros

casos favorables analizados) es que la frase de entrada, lo que en estos diálogos está representado por lo que dijo "Judge 1", no presentan referencias, ni elipsis, ni ambigüedades léxicas (evidentes) tampoco son frases monosilábicas o respuestas cortas a alguna pregunta anterior.

De forma intuitiva se puede pensar en que este tipo de frases podrían ser las iniciadoras de un dialogo con una persona ya que al iniciar un dialogo hay muy poca información de contexto. Si el dialogo es de forma escrita y los interlocutores están en habitaciones separadas, la información contextual es aún menor. Es decir, una persona "A" podría decirle a otra "B" como primera frase de una conversación:

"Do you like movies?", "What is your favorite movie?" o "Please, call me Ryan" y la persona "B" sería capaz de responder de forma satisfactoria, casi tan satisfactoria como si la misma frase estuviese ubicada a la mitad de un dialogo. No quiere decir que sean frases para iniciar una conversación, por supuesto, ya que un saludo de despedida como "See you soon" también estaría dentro de este conjunto de casos.

Sin embargo lo anterior no es completamente cierto ya que en un contexto demasiado forzado podrían dejar de ser casos favorables para un chatbot AIML, por ejemplo si el usuario dijese antes de "Do you like movies?", "there are new candies called movies" el chatbot daría la misma exacta respuesta: "Yes I love film, especially science-fiction and comedy." Tampoco serían validos en los casos en donde un usuario emplease recursos como la ironía o eufemismos, pero esta clase de problemas escapan en parte a lo que es la interpretación pragmática y al objetivo de este trabajo de estudio.

A pesar de que un contexto forzado podría invalidar los casos, estos serían validos en la mayoría de los diálogos con lo cual la definición de "caso favorable" pasa a ser una definición probabilística que podría definirse como sigue:

El caso "A" pertenece al conjunto de casos favorables si en el X % de los diálogos, cuando un usuario ingresa la frase: "A" obtiene por parte el chatbot una respuesta coherente que satisface sus expectativas tal

y como lo haría la respuesta de una persona en circunstancias similares.

Donde X es un número menor que 100, aleatoriamente alto. La definición anterior es una definición practica que es cómoda a los efectos de clasificar frases de entrada como casos favorables para el objeto de estudio de esta investigación, sin embargo la tarea de clasificar casos utilizando la definición anterior es casi imposible debido a que habría que evaluar de forma subjetiva cuando una frase obtuvo una respuesta satisfactoria y cuando no en todos los diálogos posibles (o bien en algún número suficientemente grande de diálogos.)

Volviendo al ejemplo de cómo se podría clasificar de forma intuitiva un caso; así como la persona "A" al iniciar el dialogo con la persona "B" podría utilizar frases como las anteriores, no podría hacerlo con frases como: "Do you like her?", "What's your favorite?", "yes" o incluso frases como "I'm opened the door" que contienen poca información en el sentido que le da Shannon en [Shannon 1948] y esperar una respuesta igual a la que recibiría si dichas sentencias se hallasen a mitad de un dialogo en donde ya se "sabe" a quien hace referencia el pronombre "her" o que se está hablado de "movies" o que "yes" responde a determinada pregunta o que "door" fue abierta.

De alguna forma, los casos favorables son aquellos en donde la frase de entrada no depende del contexto (en la mayoría de los casos) y los casos desfavorables son aquellos en donde la frase de entrada depende del contexto. Los primeros están compuestos por frases que serán llamadas a lo largo de esta investigación: "independientes del contexto" y los segundos de frases que serán llamadas "dependientes del contexto", aún cuando no exista en la base de datos de conocimiento del chatbot un patrón de coincidencia para la frase. (Se estaría en este caso ante otro problema relacionado con la completitud de la base de datos de conocimiento.)

Los casos serán clasificados según la categoría anterior utilizando una red neuronal artificial.

C. Clasificación de los casos usando una RNA Parte importante de esta investigación es crear una red

neuronal artificial que sea capaz de detectar cuando una frase es dependiente o independiente del contexto. La otra parte es la transformación de una frase dependiente del contexto en una frase independiente del contexto, que es aquella, como fue explicado en el punto 4.1, que constituye un caso favorable para un chatbot basado en AIML.

Para la construcción de la RNA se propone crear, primeramente, un conjunto de entrenamiento en donde haya frases en inglés y por cada frase se indique si es o no dependiente del contexto. Las frases en inglés serán transformadas en un mapa que será utilizado como entrada de la RNA.

El mapa se generará no a partir de las frases en sí, sino a partir de los tipos básicos de palabras que la conforman, el orden de estas en la oración, si la oración es una interrogación o no y el tiempo verbal en el cual está formulada la oración. Se hará especial hincapié en los distintos tipos de pronombres, el resto de las palabras serán clasificadas en alguno de los siguientes tipos básicos: sustantivo (noun), verbo (verb), adjetivo (adjective), adverbio (adverb), artículos y palabras auxiliares (aux)

El tipo de arquitectura de red neuronal escogido es el de Back Propagation, descripto en el punto 2.4.1 debido a que entre los tipos de redes con aprendizaje supervisado esta es una


127

de las más exitosas, utilizada en casos de reconocimiento de texto, de voz, clasificación de patrones, etc.

Durante la fase de entrenamiento se creará una red con una capa oculta ya que de esta forma se pueden clasificar elementos encerrados en regiones polinomiales convexas del espacio y otra con dos capas ocultas que permitirá clasificar elementos encerrados en conjuntos de formas arbitrarias sobre el espacio dado ya que no conocemos la distribución espacial de las frases dependientes e independientes del contexto (según los mapas utilizados). La capa de salida tendrá una única neurona ya que se espera un solo valor boleano: verdadero o falso, 1 ó 0 que indicaría si es independiente del contexto o no. Las capas intermedias serán creadas con una cantidad de neuronas igual a la mitad de las utilizadas en la primera capa, al menos en su configuración inicial. La capa de entrada tendrá tantas neuronas como los mapas propuestos necesiten.

Se proponen dos mapas posibles como input de la red neuronal, ambos se describen en los puntos siguientes.

1) Mapa 1 propuesto como input de la RNA

Sobre la frase original en inglés se realizan 3 procesos diferentes:

I) Se reemplaza cada palabra por su tipo: sustantivo (noun), verbo (verb), adjetivo (adjective), adverbio (adverb), artículos y palabras auxiliares (aux). (Por palabra se entiende una o más cadenas de caracteres separadas por espacio que juntas tienen un significado univoco distinto del que tienen por separado, ejemplo: "Buenos Aires" es una palabra compuesta por dos cadenas de caracteres). Cada tipo de palabra tiene un valor numérico asociado.

II) Se aplica un procedimiento para detectar si la frase es una interrogación o no. (Aunque no tenga el signo de interrogación)

III) Se aplica un procedimiento que mediante una serie de expresiones regulares detecta el tiempo verbal de la oración.

Una vez hecho lo anterior se crea un vector de números en punto flotante de 15 posiciones que será finalmente el input de la RNA. Se instancian todas las posiciones en cero. Luego en la posición 0 del vector se marca si la frase es una interrogación con un uno (1) o con un cero (0) sino. La posición 1 del vector indica el tiempo verbal, el cual puede tomar uno de los siguientes valores: 0.0; 0.5; 0.7; -1.0; -1.3; 0.8; 0.6; -1.4; -1.5; 1.1; 1.2; 1.3; 1.5; 1.9 para los tiempos verbales respectivos (en inglés): infinitive, simple present, present continuous, past, past continuous, present perfect, present perfect continuous, past perfect, past perfect continuous, simple future, future continuous, future perfect, future perfect continuous, conditional. El resto de las posiciones del vector representan en orden, a los diferentes tipos de palabras que conforman la oración (las primeras 13 palabras), según su valor numérico. Los tipos de palabras y sus valores numéricos asociados son:

auxiliary words 0.1 noun 1.9 adjetive 1.3 indicative 2.3 intterrogative pronouns 2.0 verbs 1.5

personal pronouns fisrt person: 2.5 personal pronouns third person: 3.0 personal pronouns second person: 3.5

El mapa puede ser representado de forma esquemática como se muestra en la Figura 7

Fig. 7. Mapa 1

2) Mapa 2 propuesto como input de la RNA

Para la generación del input 2 de la RNA utilizada se cambió el mapa de entrada para hacerlo más sensible. Lo que se hizo fue aumentar el número de neuronas de entrada. Este nuevo mapa reserva una neurona especial para un valor de entrada que indica si la frase es o no una pregunta, al igual que en el caso anterior se realizan las siguientes acciones sobre la frase de entrada:

I) Se reemplaza cada palabra por su tipo: sustantivo (noun), verbo (verb), adjetivo (adjective), adverbio (adverb), artículos y palabras auxiliares (aux).

II) Se aplica un procedimiento que detecta si la frase es una interrogación o no.

Pero no se realiza la detección de tiempo verbal, se eliminó la neurona que respondía ante el tiempo verbal encontrado identificado en la oración.

El resto del mapa de entrada se definió como una matriz de 15 x 5 números de punto flotante, en donde la longitud, 15, representa una a una las primeras 15 palabras de la frase de entrada y el ancho o profundidad: 5, indica según la posición que tome un valor distinto de cero, que tipo de palabra es. En donde la posición 0 del vector vertical toma un valor distinto de cero si la palabra es auxiliar o bien si esta es un pronombre interrogativo (interrogative pronouns). En el caso de una palabra auxiliar, el valor que toma es de 0.2, en el caso de un pronombre interrogativo es de 3.0 (en este caso se verá reforzado además por la neurona que indica que es una pregunta.) La posición 1 del vector vertical toma valor igual a 1.0 si la palabra es un verbo (verb) o bien si es un adverbio (adverb). La posición 2 toma un valor igual a 1 si es un adjetivo (adjective). La posición 3 toma un valor igual a 1 si es un sustantivo (noun) común o igual a 2 si es un sustantivo propio. Por último la posición 4 toma un valor distinto de cero si la palabra es un pronombre personal (personal pronoun) o un pronombre demostrativo (demostrative pronoun). En estos casos puede tomar diferentes valores, tomará el valor 1 para pronombres personales en primera persona, 2 para pronombres personales en tercera persona y 3 para pronombres personales en segunda persona. Para pronombres demostrativos toma el valor 2.5.

Esquemáticamente el mapa quedó como se muestra en la Figura 8:


128

Fig. 8. Mapa 2

3) Pasos para la clasificación

La clasificación de casos incluye analizar todos los patrones (patterns) de cada una de las categorías (category) de ALICE para indicar si la frase contenida en el tag pattern es o no independiente del contexto.

Como primera medida se clasificarán todas las categorías (category) cuyos patterns esten conformados por frases que utilicen wildcards como dependientes del contexto ya que a priori no se puede saber qué tipo de frase de entrada de usuario coincidirá con un patrón con wildcards.

Como segunda medida se clasificarán como independientes del contexto a todas aquellas categorías (category) que utilicen el tag "that", ya que si bien el pattern en sí es dependiente del contexto, la category ya lo tiene contemplado.

Como tercera medida se utilizará la RNA previamente entrenada, para clasificar todas las categorías restantes.

El nuevo campo a agregar en cada category, para indicar si es o no un caso favorable se llamará "can_answer" ya que este nombre es más general. (Una category con tag that es dependiente del contexto, pero puede ser utilizada para responder ya que conforma un caso favorable.)

Una vez que el sistema esté funcional, trabajará inicialmente de forma idéntica a como lo hace ahora AIML, es decir seguirá de forma esquemática los siguientes pasos:

1) Esperar una frase de entrada del usuario

2) Buscar una category cuyo tag pattern coincida lo mejor posible con la frase anterior.

3) Tomar la frase contenida en el tag template.

Pero al llegar a este punto, revisará el nuevo campo "can_answer". Si este campo es uno (1) el sistema procederá de la forma usual, si es cero utilizará la RNA para clasificar la frase de entrada del usuario. Si el resultado es (1): independiente del contexto, procederá de la forma usual. Si es cero (0): dependiente del contexto aplicará los mecanismos antes descriptos para convertir la frase del usuario en una frase independiente del contexto.

4) Utilización de redes neuronales artificiales autoorganizadas (SOM)

La red autoorganizada: SOM del modelo propuesto por Kohonen será tenida en cuenta como un clasificador de frases que podría ser utilizada previo al uso del perceptrón. Se utilizará la herramienta indicada en [17]. Una forma común de reducir el error cuadrático medio del algoritmo Back Propagation, es dividir el conjunto de pruebas original en subconjuntos donde los elementos agrupados presenten similares características. Una forma de lograr estos subconjuntos es mediante la clasificación realizada a través de redes autoorganizadas.

Los inputs que tomaría, eventualmente, esta red serían los mismos propuestos para la red perceptrón.

D. Implementación de AIML sobre mySQL Para simplificar la tarea de análisis y clasificación de los

tags AIML, la totalidad de la base de datos de conocimiento de ALICE será migrada a una base de datos relacional mySQL.

Durante todo el proceso de pruebas y correcciones se utilizará una implementación de AIML sobre mySQL, la cual reemplazará al algoritmo de pattern-matching de los intérpretes AIML por el propio engine mySQL. Dicha implementación será respaldada por una serie de pruebas que garanticen que la implementación sobre mySQL funcione de igual forma que el intérprete "program-D" utilizado en la actualidad en el sitio de ALICE online.

E. Resolución de referentes La resolución de referentes es el mecanismo más

importante con el que se cuenta para convertir los casos desfavorables en casos favorables, dicho con la nomenclatura de esta investigación convertir las frases dependientes del contexto en frases independientes del contexto. Para ello se utilizará el algoritmo: RAP (Resolution of Anaphora Procedure.) El cual ha dado buenos resultados según [7]: 74 % de tasa de éxito en la resolución de anáforas ínter-sentencias y 89 % de tasa de éxito en la resolución de anáforas intra-sentencias.

Este algoritmo entraría en ejecución luego de que una frase de entrada del usuario haya sido detectada como caso desfavorable y la RNA haya devuelto el valor cero al procesar el mapa asociado a dicha frase. Entonces el algoritmo RAP tomaría como input las últimas 10 líneas del dialogo y la última frase del usuario. Buscaría en la frase alguna referencia anafórica y trataría de vincularla con algún sustantivo presente en las líneas previas del dialogo. Como salida, el algoritmo devolvería la frase del usuario reformulada como una nueva oración independiente del contexto cuyo significado es el mismo.

De forma ilustrativa se propone el siguiente ejemplo: supóngase la siguiente conversación con el chatbot ALICE, utilizando su base de conocimientos y su funcionamiento actual:

Human: Tell me about Richard Wallace ALICE: Are you asking about my botmaster? Human: He is a great inventor ALICE: Maybe you should tell him how you feel

about him. La frase de entrada: "He is a great inventor", coincide con

el patrón "HE IS A GOOD %", con lo cual la respuesta dada por el chatbot no es más que una respuesta genérica que no considera a Richard Wallace como sujeto de la oración.

Con los cambios propuestos implementados la frase: "He is a great inventor" sería clasificada como dependiente del contexto por la RNA, y lo es ya que el pronombre "he" es una referencia anafórica por resolver. Se aplicaría luego el algoritmo RAP, que utilizaría como input las dos líneas anteriores del dialogo y la frase actual para devolver lo siguiente:

"Richard Wallace is a great inventor".

Esta frase sería utilizada como una nueva entrada de usuario por el chatbot la cual coincidiría con otro patrón:


129

"RICHARD WALLACE IS %". Este patrón considera a "Richard Wallace" como sujeto de la oración con lo cual devolvería una respuesta más coherente en relación al dialogo.

F. Reformulación de respuestas a preguntas cerradas Este es otro mecanismo capaz de convertir respuestas

dependientes del contexto en respuestas independientes del contexto pero su algoritmia es mucho más sencilla que la del parser RAP aunque su alcance es también mucho más limitado.

Fue concebido como una forma sencilla de resolver un problema harto común en los diálogos de los chatbots. En particular se notó que ALICE cuenta en su base de datos de conocimiento con respuestas (más correctamente hablando frases contenidas por el tag template) las cuales no son más que preguntas cerradas, como por ejemplo:

"Do you like chocolate ?" "Do you like computers?" "Are you a woman ?" "Are you an english teacher?"

Este tipo de interrogantes suelen ser respondidos mediante un sí (yes) o un no (no), o bien mediante algún sinónimo más coloquial: "sure", "of course", "no way", etc. En la base de datos de ALICE no hay entradas para cada una de estas posibles respuestas que utilicen el tag that para remarcar la pregunta anterior; y agregarlas, por otro lado, sería poco eficiente ya que implicaría repetir muchas entradas. Sin embargo sí cuenta con patrones como "I am a woman" o "I like chocolate". En base a estas observaciones se pensó en una forma de convertir las frases como: "yes", "no", "sure", etc. en frases independientes del contexto como "I like chocolate" siempre y cuando dichas frases sean respuestas a preguntas cerradas.

De forma ilustrativa se propone el siguiente ejemplo: Supóngase la siguiente conversación con el chatbot ALICE, utilizando su base de conocimientos y su funcionamiento actual:

Human: I hate cats ALICE: Do you like dogs? Human: yes ALICE: Hmm.

En este ejemplo la frase de entrada "yes" coincidió con el patrón "yes", para el cual hay asignada una respuesta genérica, en este caso "Hmm". Si el cambio propuesto estuviese implementado, la frase de entrada "yes" habría sido detectada como dependiente del contexto por la RNA , luego se hubiese procedido a verificar si la frase anterior del chatbot era una respuesta cerrada; entonces las frases "yes" y "Do you like dogs?" hubiesen sido combinadas y reformuladas como: "I like dogs", una frase independiente del contexto. Dicha sentencia sería entonces utilizada como frase de entrada por el chatbot (en lugar de "yes") y habría coincidido con un patrón idéntico "I LIKE DOGS" cuya respuesta asociada (contendido el tag template) es: "Which breed is your favorite?”

G. Preguntas por referencias no encontradas Se pretende construir un subsistema que sirva como backup

para los casos en los cuales el RAP no logre resolver la referencia anafórica. El funcionamiento es simple de explicar, cuando una frase dependiente del contexto que presente un pronombre no logre ser reformulada, este subsistema detectará dicho pronombre y formulará una frase de interrogación que

será devuelta al usuario. En dicha respuesta se pedirá la información faltante.

De forma ilustrativa se propone el siguiente ejemplo: Supóngase la siguiente conversación con el chatbot ALICE, utilizando su base de conocimientos y su funcionamiento actual:

Human: He is a great inventor ALICE: Maybe you should tell him how you feel

about him. Esta conversación es idéntica a la presentada en el punto

4.4, solo que en este dialogo no se hace referencia a Richard Wallace sino que empieza directamente con la frase: "He is a great inventor". Se puede ver que la respuesta de ALICE tendría sentido si se supiese de quien se está hablando, es decir, a quien hace referencia la palabra "he". Claramente un interlocutor humano no respondería de esa forma sino que preguntaría por la referencia perdida, una respuesta "más humana" sería: "Who are you taking about?"

Suponiendo que estuviesen implementados los cambios propuestos el algoritmo RAP se aplicaría sobre la frase: "he is a great inventor" pero no podría encontrar la referencia anafórica de "he" sencillamente porque no existe. Entonces actuaria la "última línea de defensa", que es este subsistema, el cual buscaría la palabra "clave" de una lista de palabras posibles y la utilizaría para formular una pregunta, que podría ser: "Who is he?".

Cabe destacar que este subsistema, o procedimiento según como termine siendo implementado no significa ninguna novedad, AIML mismo o incluso los chatbots basados en ELIZA son capaces de buscar una palabra "clave" en una frase y a partir de ella formular una pregunta. Lo que se presenta aquí como novedoso es la forma y la situación en la cual se lo pretende emplear.

V. DESARROLLO DE LA SOLUCIÓN El objetivo de este apartado es el análisis del conjunto

concreto de necesidades para proponer una solución a corto plazo, que tenga en cuenta restricciones técnicas y operativas. La solución obtenida como resultado de este estudio debe ser la definición de un proyecto que afecte a sistemas existentes o bien cree uno nuevo. Se identificarán, para ello los requisitos que se han de satisfacer y se estudiará la situación actual.

A. Establecimiento del alcance del sistema En este apartado se estudiará el alcance de la necesidad

planteada realizando una descripción general de la misma. Se determinarán los objetivos y se iniciará el estudio de los requisitos. Se analizarán además las posibles restricciones, tanto generales como específicas, que puedan condicionar el estudio y la planificación del trabajo de investigación.

1) Resumen de la propuesta de investigación La solicitud en este caso está determinada por la propuesta

de investigación, esta propuesta sugiere la implementación de una mejora en los sistemas actuales conocidos como chatbots.

Los chatbots actualmente no logran reproducir el comportamiento humano en una conversación ni dar respuestas satisfactorias que puedan ser consideradas coherentes. Solo responden de manera satisfactoria a determinadas frases. Ejemplos de estas conversaciones pueden obtenerse en [9], [10] y [11].

El estudio de las transcripciones de las conversaciones sostenidas entre estos sistemas y un individuo dado muestran


130

diversos problemas, entre los cuales se encuentra la falta de evaluación del contexto (de la conversación) al responder.

La mejora propuesta consiste en modificar un chatbot existente de tal manera que pueda responder a una frase de un individuo teniendo en cuenta información de contexto, entendiendo por contexto frases mencionadas anteriormente en una misma conversación.

2) Descripción del sistema a construir y objetivos

El sistema a construir será un chatbot que se encuentre

dentro del estado del arte (o de la cuestión) de este tipo de programas, es decir que pueda responder a frases de entrada al menos tan satisfactoriamente como cualquier otro chatbot reconocido. Pero este chatbot además deberá de poder responder correctamente en situaciones en las cuales un chatbot actual no lo hace.

Se tomará como punto de partida para el desarrollo de dicho sistema, un chatbot existente cuyo código fuente y base datos se encuentren disponibles y en lo posible se disponga de documentación acerca de su funcionamiento. Se estudiarán los casos en los cuales el chatbot responde de manera no satisfactoria por no tener en cuenta el contexto. Se evaluarán posibles mejoras para dichos casos y se aplicarán sin modificar el comportamiento para los casos en los cuales el sistema ya funciona adecuadamente.

3) Diagramas de flujo En la Figura 9 que se muestra a continuación, está

representado, mediante un diagrama de flujo el funcionamiento de un chatbot actual. En el siguiente diagrama se representa de manera esquemática como afectarían los cambios propuestos a dicho sistema.

Fig. 9. Flujo, chatbot actual

A partir de la observación del segundo diagrama se desprende que las modificaciones implican la creación de un sub-sistema capaz de decidir cuando una frase de entrada de un usuario dado puede ser "respondida" correctamente por el chatbot y cuando es necesario buscar información de contexto (en frases anteriores) para responder correctamente. En otras palabras dicho sub-sistema debería de poder determinar si una frase es dependiente o independiente de su contexto. Este sub-

sistema estaría actuando también como un filtro que permite dividir el funcionamiento del chatbot en dos, la parte o los casos satisfactorios y los no satisfactorios. A continuación entra en juego un segundo sub-sistema que tomando una frase de entrada que está dentro del conjunto de los casos no satisfactorios le agrega información de contexto que obtiene de frases anteriores, cambiando de esta manera la frase del usuario. Siguiendo el flujo, si el sub-sistema encontró la información faltante y pudo reformular, con ella la frase, esta vuelve al flujo principal del chatbot.

Fig. 10. Flujo, chatbot modificado

En este caso el chatbot podrá responder de manera satisfactoria (o no, pero en caso de no hacerlo el problema no debería de ser la evaluación del contexto sino otro, como falta de información en su base de datos.) Para el caso en el cual el sub-sistema anterior no fue capaz de encontrar la información de contexto faltante, o de reformular la pregunta se enviará una frase de salida al usuario, pidiendo la información de contexto faltante.

4) Requisitos A partir del análisis anterior es posible identificar una serie

de requisitos mínimos, al menos en una primera estimación, necesarios para llevar adelante el desarrollo del sistema propuesto:

- El código fuente y base de datos de un chatbot que esté en el estado del arte y que se pueda modificar, el mismo servirá como punto de partida.

- Desarrollar un sub-sistema capaz de decidir si una frase de entrada puede ser respondida de manera correcta por el chatbot anterior o si es necesario información de contexto para ello, es decir que verifique si una frase dada es independiente del contexto o no. (sub-sistema detector)

- Desarrollar un sub-sistema que pueda convertir una frase dependiente del contexto por otra que mantenga su sentido y significado pero sea independiente del contexto. Utilizando para ello frases anteriores de un mismo dialogo. (sub-sistema conversor)


131

5) Especificación del alcance del sistema A partir de los objetivos y requisitos planteados en los ítems

anteriores, es posible elaborar una primera serie de tareas necesarias para cumplir dichos objetivos:

I. Investigación de los algoritmos y/o modelos actuales que permiten dilucidar el contexto en una conversación y estudiar como son aplicados en modelos de chatbots.

II. Selección de un chatbot, comprensión y entendimiento de su funcionamiento.

III. Definición y especificación de mejoras a realizar en el modelo de chatbot escogido para lograr que este adapte su comportamiento a partir de la evaluación del contexto.

IV. Construcción e implementación de un sub-sistema capaz de determinar si una frase es independiente del contexto o no. (sub-sistema detector)

V. Construcción e implementación de un sub-sistema capaz de convertir una frase dependiente del contexto en una frase independiente del contexto. (sub-sistema conversor)

VI. Implementación del modelo de chatbot con las mejoras propuestas con la integración de los sub-sistemas necesarios.

VII. Pruebas de integración, desarrollo de una interfaz de usuario para que cualquier persona pueda interactuar con el nuevo chatbot.

VIII. Corroboración de los supuestos teóricos, corridas de prueba, comparación con los modelos tradicionales y correcciones necesarias.

TABLA VIII. Estimación PERT

Tarea \ Estimación (días) O M P PERT

1: investigación 6 12 20 12,33

2: Selección chatbot 5 7 10 7,17

3: Definición mejoras 10 15 20 15

4: sub-sistema detector 15 17 21 17,33

5: sub-sistema conversor 12 15 25 16,17

6: integración sub-sistemas y chatbot 5 6 7 6

7: Pruebas integración/interfaz 5 6 7 6

8: Pruebas generales/correcciones 4 7 8 6,67

. La tabla anterior proporciona una noción aproximada del

esfuerzo requerido para la elaboración del sistema final en días/hombres. Pero para saber el tiempo de entrega de cada tarea, y por ende el tiempo que se demorará en la finalización del sistema es necesario conocer la cantidad de horas por semana que se dedicarán al desarrollo y confección del sistema.

Días por semana: 2 (un total de 16 hs. por semana en promedio.) En la siguiente tabla se muestra el tiempo de entrega estimado.

El número de días fue redondeado ya que esta primera estimación es grosera y el tiempo de dedicación semanal puede variar.

TABLA IX. Tiempo de entrega de cada tarea

Tarea entrega en días 1: investigación 40

2: Selección chatbot 24 3: Definición mejoras 50

4: sub-sistema detector 60 5: sub-sistema conversor 55

6: integración sub-sistemas y chatbot 20 7: Pruebas integración/interfaz 20

8: Pruebas generales/correcciones 20 Total: 289

Colocando en un diagrama de Gantt los números anteriores,

para un solo recurso asignado a todas las tareas, obtenemos un gráfico como el siguiente:

Fig. 11. Gantt de proyecto

B. Estudio de la situación actual En la actualidad existe una cantidad demasiado grande de

chatbots, los cuales no están catalogados, descriptos ni enumerados en ningún documento confiable y no siempre es posible describir el funcionamiento de estos porque simplemente no hay documentación disponible ni acceso al su código fuente. De todos los chatbots, solo interesan al objeto de este proyecto, aquellos que estén entre los mejores según algún criterio medianamente objetivo y que además su código fuente y base de datos estén disponibles.

La selección de dichos sistemas será hecha en base a tres criterios:

1. Aquellos chatbots que hayan sido finalistas en el concurso llamado "The Loebner Prize in Artificial Intelligence", el cual es una primera aproximación al Test de Turing [18]. El concurso es anual y se presentan, en EE.UU., diferentes chatbots que funcionan en inglés; gana el que se aproxime más a un ser humano en su modo de responder.

2. Chatbots o engines de chatbots que sean utilizados de manera comercial o productiva de manera exitosa.

3. Aquellos chatbots cuyo código fuente y base de datos estén disponibles para ser examinadas y modificadas.

En base a los requisitos 1 y 2 se confeccionó una lista de chatbots: Ultra Hal: Este chatbot ganó el primer lugar en el concurso

Loebner del año 2007. [9] disponible:

http://www.zabaware.com/webhal/index.html ALICE: ALICE está desarrollado sobre AIML y fue

ganador del premio Loebner en tres oportunidades.


132

disponible: http://www.pandorabots.com/pandora/talk?botid=f5d922d97e345aa1

Jabberwacky: Jabberwacky fue ganador del premio Loebner en dos oportunidades.

disponible: http://www.jabberwacky.com/ ELIZA: Eliza fue el primer chatbot exitoso construido,

extendiendo a Eliza se construyó "PC therapist" un chatbot que fue ganador en los primeros tres años del concurso Loebner. Y luego volvió a ganar en el año 1995.

Disponible: http://www-ai.ijs.si/eliza-cgi-bin/ eliza_script

JULIA: chatbot basado en Eliza, participó en el concurso Loebner del año 1994, salió cuarta de cinco chatbots.

disponible: http://www.lazytd.com/lti/julia/ MITBOLEL: Es un chatbot susceptible de ser adaptado y

cambiado (cuztomizable) disponible:

http://www.romahi.com/yazann/Mitbolel/Mitbolel.html

THOUGHT TREASURE: En este chatbot el enfoque es diferente, ThoughtTreasure es una plataforma que comprende y procesa lenguaje natural, y que puede "razonar con sentido común", según su creador Erik T. Mueller.

disponible: http://www.signiform.com/tt/htm/tt.htm

BRIAN: Este chatbot está escrito en C++, extiende la idea general del "terapista" que utiliza ELIZA. Ganó el tercer lugar en el concurso Loebner 1998.

disponible: http://www.strout.net/info/science/ai/brian/

DR ABUSE: Un programa basado en ELIZA que responde en castellano.

disponible: http://dr-abuse.softonic.com/ (hay que descargarlo)

Eugene Goostman: Segundo en el concurso Loebener de 2005.

disponible: http://www.mangoost.com/bot/ Robin: Es un chatbot creado por el Ministerio de

Sanidad y Consumo de España. Su función es informar a los jóvenes a través de Messenger sobre enfermedades de transmisión sexual y consumo de alcohol (utiliza una implementación de AIML en .NET)

disponible como contacto MSN: [email protected] Encarta(R) Instant Answer: Otro chatbot para MSN,

diseñado por Microsoft para promocionar Encarta (utiliza una implementación de AIML en .NET),

disponible como contacto MSN: encarta@ botmetro.net

Si sobre la lista anterior se aplica el tercer requisito, quedan

solo dos chatbots: ALICE, y Eliza. En ambos casos no solo se

dispone de acceso al código fuente e información de su base de datos (o base de conocimientos) sino que además hay numerosa documentación sobre ellos, incluyendo la especificación en sus modo de funcionamiento ver [20] y [19]. Además el engine de ALICE, AIML, es utilizado en la construcción otros chatbots que tienen fines prácticos reales, como los últimos dos mencionados en la lista anterior.

1) Descripción de los sistemas de información existentes En esta sección se hará un una descripción detallada de los

sistemas existentes que se han tomado como casos de estudio. La forma escogida para mostrar su funcionamiento principal es la de un diagrama de flujo. De esta forma se podrá visualizar claramente similitudes y diferencias entre ambos chatbots y porque ALICE puede imitar el funcionamiento básico de ELIZA.

a) Diagramas de flujo de ALICE y ELIZA A continuación se describirá de manera esquemática,

mediante diagramas de flujo el funcionamiento de los dos chatbots antes seleccionados. Los gráficos anteriores describen el comportamiento general de los sistemas pero no dicen como evalúan el contexto, si es lo que hacen, en una conversación.

En primer lugar el contexto de cada palabra individual dentro de una frase o ambigüedad léxica se maneja de manera bastante satisfactoria en ambos sistemas ya que trabajan a nivel de oraciones completas (frases), la mínima unidad que pueden analizar como entrada es una frase. Incluso en el caso particular de que la frase de entrada esté compuesta por una sola palabra esta será tratada como una frase.

Fig. 12. Diagrama de flujo de ALICE

En segundo lugar el manejo de la ambigüedad sintáctica y la metonimia que son problemas de referencia interna dentro de una misma frase son manejados particularmente bien en ALICE ya que AIML mapea, generalmente, una frase entera a un patrón asociado a la respuesta, no descompone la frase o trata de analizarla.


133

Fig. 13. Diagrama de flujo de ELIZA

Aunque puede darse el caso, cuando la frase coincide solo parcialmente con el patrón y este en vez de una respuesta tiene asociado una instrucción de recursividad (mediante el tag srai.) En relación a la pragmática, donde el problema reside en completar la información faltante de una frase con información del contexto, Eliza y ALICE funcionan de manera diferente. Ambas pueden dar respuestas diferentes a una misma frase de entrada en función de las frases anteriores intercambiadas entre el chatbot y el usuario.

En el caso de Eliza, cuando no tiene reglas asociadas o no encuentra palabras claves en una frase de entrada, uno de los procedimientos que puede ejecutar consiste en armar una respuesta, no sobre la frase actual, sino sobre alguna frase anterior del usuario distinta a la que se elaboró originalmente. De esta manera simula reencauzar o bien darle continuidad a una conversación como si en efecto la estuviese siguiendo aunque no es una verdadera respuesta en función del contexto ya que lo que logra es crear una conversación nueva.

En el caso de ALICE la funcionalidad para responder teniendo en cuenta el contexto está más y mejor elaborada. ALICE tiene dos maneras, que pueden actuar simultáneamente, para responder en base al contexto. Una es el uso de variables de estado. ALICE asocia a algunas respuestas variables de sesión. Cuando encuentra una respuesta dada, antes de imprimirla setea ciertos valores; por ejemplo, la respuesta a una frase de entrada que no tuvo ninguna coincidencia especifica podría ser "What’s your favorite car?", en este caso ALICE saeteará la variable de sesión "topic" en "CARS". De este modo si para la próxima frase del usuario hay dos coincidencias iguales, ALICE escogerá la respuesta que esté dentro del tópico "CARS" (Las respuestas pueden estar dentro de "tópicos") [19]. La segunda manera en la cual ALICE puede responder en base al contexto es el tag especial de AIML "that", este tag está asociado a ciertas respuestas y lo que contiene es la frase

textual que ALICE respondió anteriormente. El siguiente ejemplo, ilustrará mejor la función de este tag: Si ALICE a cierta frase de entrada de un usuario responde con "Do you like movies?" y el usuario responde a su vez a ello con la frase de entrada "yes". ALICE podría buscar en su base de datos, no solo un patrón que coincida con "yes", sino un patrón que coincida con "yes" y tenga asociado un tag "that" que coincida con "Do you like movies?".

Sí bien estas funcionalidades le permiten a ALICE manejar mejor el contexto, no bastan, como demuestran las transcripciones de sus conversaciones (o la de los otros chatbots basados en AIML.) El tag "that" exige que se duplique exponencialmente la base de datos de ALICE y solo permite contemplar la frase anterior a la actual.

La siguiente observación puede aclarar el porqué se siguen observado problemas en la evaluación del contexto en las conversaciones sostenidas por chatbots basados en AIML: si ALICE tiene en su base de datos de respuestas, hipotéticamente, 100 preguntas susceptibles de ser respondidas solo con "sí" (yes) o "no" (no) tendrá que tener 100 patrones "sí" y 100 patrones "no" asociados a cada pregunta y no se estarían contemplando los casos en los cuales el usuario decidió explayarse en la respuesta (por ejemplo "I like movies" en lugar de solo "yes" o "I don't like movies" en lugar de solo "no", solo para estos casos tendríamos 200 patrones más en la base.) (No habría problema con los sinónimos de "si" o "no", es decir si el usuario responde "afirmative" no sería necesario crear una nueva entrada, solo una tabla de sinónimos mediante el tag "srai")

C. Definición de requisitos del sistema En el punto anterior se mostró una lista preliminar de

requisitos de sistema que sirvió para entender mejor los puntos que siguieron y definir la situación actual.

A los requisitos anteriores habría que agregarle el siguiente: construcción de algún sistema auxiliar que permita discriminar la información en la base de datos del chatbot: esto es requerido para poder separar y analizar las frases y respuestas del sistema y distinguir los casos favorables, aquellos que deben seguir funcionando igual y los que deben ser modificados. Está tarea se puede descomponer en tres sub tareas que formarán parte de las tareas 2 a 4 descriptas anteriormente.

1) Estudio de alternativas de solución

A partir de este punto se presentan tres conjuntos de dos alternativas cada uno. Por un lado tomar a Eliza como punto de partida para el sistema que se pretende construir y por el otro lado utilizar a ALICE. Además están los subsistemas que se integrarán al chatbot: el sub-sistema detector y el sub-sistema conversor. Cada uno de estos sub-sistemas puede ser implementado de varias formas diferentes, en este estudio se evaluarán solo dos posibles formas: algorítmica y mediante una red neuronal.

Fig. 14. Tres opciones


134

2) Chatbots En primer lugar se analizará cual de los dos chatbots, se

tomará como punto de partida, para ello se utilizará la siguiente tabla comparativa:

TABLA X. ALICE VS ELIZA (1)

ALICE Intenta responder como lo haría una persona, su conversación no

define un propósito o ámbito especifico. Ha ganado tres veces el certamen "Loebner", ha sido finaliza otras

dos. ganó por última vez en el 2004

Se utiliza su engine para hacer chatbots con propósitos reales. No posee grandes problemas de ambigüedad léxica, ambigüedad

sintáctica y resolución de metonimia Posee dos mecanismos diferentes para evaluar el contexto y emitir

en base a ellos una respuesta. AIML puede ser utilizado para construir un chatbot que simule el

comportamiento de Eliza

TABLA XI. ALICE VS ELIZA (2)

Eliza Intenta responder como lo haría un pisco terapeuta

Ganó el mismo certamen 4 veces y salió cuarta en otra oportunidad. (en verdad chatbots basados en Eliza, no Eliza

propiamente dicha) ganó por última vez en 1995

Finalidad meramente académica No posee grandes problemas de ambigüedad léxica. Pero

ambigüedad sintáctica y resolución de metonimia no están contemplados

no posee un verdadero mecanismo de evaluación del contexto (ver punto: 5.1.2.2)

Eliza (o su engine) no puede simular el comportamiento de ALICE

3) Sub-sistema detector

El sistema que se encargará de definir si una oración determinada es independiente del contexto o no, deberá poder hacer esta clasificación haciendo manejo de alguna técnica de procesamiento de lenguaje natural.

Desde el punto de vista algorítmico el tratamiento del lenguaje natural según Stuar Rusell y Peter Norving en [15] requiere de lo siguiente:

1. Definir un léxico, esto es una "lista de palabras permitidas. Las palabras [del léxico a su vez] se agrupan en categorías o partes del habla conocidas por los usuarios del diccionario: sustantivos, pronombres y nombres para denotar cosas, verbos para denotar sucesos, adjetivos para modificar sustantivos y adverbios para modificar verbos [...]" [15]

2. Una gramática para dicho léxico, "Una gramática es un conjunto finito de reglas que especifican un lenguaje." [15]. Como los lenguajes naturales al contrario que los lenguajes artificiales no tienen gramáticas formalmente definidas y la cantidad de reglas es muy grande hay que recurrir a la utilización de Gramáticas Aumentadas y

otras herramientas como la subcategorización de verbos, etc.

3. Un algoritmo que a partir del léxico y la gramática realice un análisis sintáctico de una frase. Este algoritmo dependiendo de la precisión requerida, puede ser realizado de diversas maneras: ascendente, descendente, utilizando grafos, etc.

4. Finalmente sobre el árbol sintáctico que devuelve la función encargada de realizar el análisis sintáctico, se aplica un nuevo algoritmo encargado de realizar una interpretación semántica, esto es: la extracción del significado de la frase. Sin embargo, tal vez, no es necesario conocer el significado de una frase para poder decidir si es independiente o no del contexto. Del análisis semántico solo interesa una parte: la interpretación pragmática, la cual "[se encarga] del problema de la completitud de la información mediante la adición de información dependiente del contexto sobre la situación actual de cada interpretación candidata [que generó el análisis semántico]" [15]

A partir de este punto no hay una manera conocida y eficiente para realizar la interpretación pragmática, el casó más simple de resolver es el "significados de referentes", que son frases que hacen referencia directamente a la situación (contexto) actual, ejemplo: él, ello, allá, etc. Para estos casos se puede utilizar un algoritmo conocido, como el pronoun references de Hobbs [6] que logra una eficacia considerablemente alta aunque requiere de un análisis gramatical correcto o el Pronominal Anaphora Resolution de [7] que logra una eficacia similar o mayor en algunos casos.

Requisitos para un desarrollo basado en redes neuronales: en este caso lo que se necesita es una red que pueda recibir como parámetro de entrada una frase, o una serie de valores numéricos que representen a la frase y una salida booleana (suponiendo que no se utilizará lógica borrosa) que devuelva verdadero (ó 1) si la frase es independiente del contexto y falso (ó 0) si no lo es. Dentro de los dos grandes tipos de redes neuronales: auto-organizadas (SOM) y supervisadas habría que descartar a priori las redes SOM ya que en este escenario no buscamos agrupar datos por similitud o clasificar las frases en conjuntos inciertos sino en dos conjuntos bien definidos: frases independientes del contexto y frases dependientes del contexto.

Según Bonifacio Martín del Brío y Alfredo Sanz Molina en [12] un perceptrón multicapa "es capaz de representar complejos mappings y de abordar problemas de clasificación de gran envergadura, de una manera eficaz y relativamente simple." Además cuenta con el aval de haberse utilizado satisfactoriamente en muchos casos complejos y diversos como, por ejemplo, para determinar que bancos entrarían en quiebra durante la crisis bancaria española entre 1977 y 1985. Por otro lado un perceptrón multicapa (con una única capa oculta) es un aproximador universal de funciones como quedó demostrado con el teorema de Funahashi [3]. Estas consideraciones hacen al perceptrón una red neuronal artificial adecuada para emprender el proceso de construcción del sistema.

Como algoritmo de aprendizaje para esta red hay que considerar al más difundo y utilizado: BackPropgation el cual si bien presenta el inconveniente de que "busca minimizar la función de error pudiendo caer en un mínimo local o algún punto estacionario sin llegar a encontrar el mínimo global" [4]. No necesariamente un mínimo global es la única solución para


135

que el perceptrón proporcione un resultado exitoso como sucede en los sistemas de Codificación de la información, Traducción de texto en lenguaje hablado o Reconocimiento de caracteres en los cuales se utiliza de manera satisfactoria el algoritmo BackPropagation. [4]

4) Sub-sistema conversor

Para la implementación de este sistema ya se cuenta con algunos desarrollos bastante exitosos que podrían ser adaptados, por ejemplo el algoritmo de Hobbs de resolución por referencia, mencionado anteriormente. Sin embargo esto no cubre la totalidad del trabajo que debería realizar este subsistema ya que debe de poder encontrar información de contexto en casos más generales, como por ejemplo, si un usuario responde "yes" a la pregunta "Do you like movies?". En este caso debería de poder transformar "yes" en "I like movies" y aún más deberá de poder pedir información de contexto en casos en los cuales está no esté presente en el dialogo.

Si se piensa en una implementación para este sistema del tipo basado en redes neuronales, dicha red debería de poder determinar "que" es lo que la frase necesita para que esta sea independiente del contexto y luego tomando el dialogo como entrada de la red extraer dicha información, con lo cual se requerirá convertir todo el dialogo entre el usuario y el chatbot en una serie de valores de entrada para la red y luego mapear el resultado de salida a alguna porción de frase del dialogo. Con lo cual es de esperar que dicha red tuviera un grado considerable de complejidad.

D. Valoración de alternativas La tabla XI muestra claramente que ALICE es un sistema

más moderno y por lo tanto más complejo y que ha dado mejores resultados que Eliza en el área de los chatbots inteligentes, también es posible ver que incorpora rudimentos de detección de información contextual (interpretación pragmática). Todo esto posiciona a ALICE y a su lenguaje de construcción: AIML por encima de Eliza.

El problema de identificación de independencia del contexto en una frase es un problema que involucra las siguientes características:

No hay una regla clara que pueda usarse a priori para diferenciar estas dos clases de frases.

Las frases que pueden ser clasificables son en principio infinitas.

Es un problema relativamente sencillo para un ser humano.

La regla si es que existe hay que extraerla de un conjunto de ejemplos.

Los métodos algorítmicos implican el desarrollo de un analizador sintáctico (y quizás semántico) considerable-mente preciso.

Si bien los ítems anteriores son bastante evidentes tampoco terminan de definir la mejor solución, sin embargo por la naturaleza del problema apuntan más hacia una solución de tipo no algorítmica. Por lo cual, según los casos analizados, la utilización de una red neuronal será la solución más propicia.

El sub-sistema conversor presenta características clásicas de sistemas algorítmicos como búsqueda de palabras (referentes) y reemplazo de sub cadenas. Por ello y por el hecho de que existen sistemas algoritmos que podrían ser utilizados como

referencia o puntos de partida la solución adoptada para este subsistema será finalmente algorítmica.

E. Selección de la solución En este punto ya se ha escogido una solución y una manera

de encarar el desarrollo de la investigación, se ha obtenido una planificación tentativa y un detalle de los módulos que contendrá y de los sistemas que servirán como base de la misma. Esta información se resume en la siguiente lista de módulos:

Modulo ALICE original ◦ importación de todo su base de datos a una base

de datos relacional Sub-sistema detector (red neuronal) ◦ sub-sistema para convertir frases en entrada de la

red neuronal. Sub-sistema conversor (algorítmico)

VI. CONCLUSIONES Para el problema de la clasificación de frases en los grupos

"dependiente del contexto" e "independiente del contexto", no se encontró una solución óptima, sin embargo se encontró una solución suficientemente buena como para completar el desarrollo de la Investigación. El perceptrón multicapa con Back Propagation que utilizó como input el primer mapa generado compuesto de un vector de números en punto flotante de 15 posiciones logró un 54 % de efectividad mientras que el perceptrón multicapa con Back Propagation que utilizó el segundo input, la matriz de 15x5 números en punto flotante logró una efectividad de solo el 36 %.

Por su parte la red SOM, Kohonen no logró construir conjuntos de frases de forma tal que la red Back Propagation aplicada a cada uno de los subconjuntos generase un error cuadrático medio por debajo del error cuadrático medio hallado para el conjunto total. En cada caso existió un conjunto con un error cuadrático medio igual o superior al que la red generaba (tras un mismo número de iteraciones) sobre el conjunto general.

Es difícil ignorar la incompletitud de la base de datos "Lexico" utilizada para generar los mapas y la posibilidad de saber hasta qué punto los mapas creados representan las propiedades de las frases que interesa analizar. Sin duda ambos pueden ser mejorados, la dificultad radica en saber cómo generar mejores mapas de entrada y en como optimizar la clasificación de las palabras para aumentar los casos positivos.

Si bien el método normal de resolver problemáticas relacionadas con la sintaxis de una sentencia es a través de algoritmos deterministicos, la implementación de esta solución a través de redes neuronales tuvo un resultado satisfactorio.

El algoritmo de resolución de referentes: RAP, si bien no logró una tasa tan alta de efectividad como la descripta en [7] logró una efectividad suficientemente buena como para que el chatbot logre responder de forma satisfactoria a muchas de las frases con referencias anafóricas (que anteriormente no lograba responder correctamente). La disminución en la efectividad se debió a dos factores: el cambio del parser de procesamiento de lenguaje natural, ya que no se consiguió el mismo utilizado y fue reemplazado por otro de la biblioteca "Open-NLP" (que difiere levemente en su forma de comportarse.) La segunda razón es el cambio radical del tipo de discurso empleado, en [7] midieron la eficacia utilizando textos de manuales de computadoras y no diálogos coloquiales casuales.


136

Por último el procedimiento encargado de reformular las respuestas a preguntas cerradas logró un éxito considerable, mayor del esperado ya que de una forma muy simple logra transformar las preguntas del chatbot en sentencias declarativas. Es un cambio que podría implementarse de forma productiva tal y como está de forma independiente de las otras mejoras.

VII. FUTURAS LÍNEAS DE INVESTIGACIÓN Dentro de la misma problemática de la interpretación

pragmática en chatbots quedan varios aspectos para seguir investigando y mejorando la calidad de las respuestas. Por un lado se tiene el problema de la clasificación de las frases en “independientes del contexto” y “dependientes del contexto”, dicha problemática podría ser mejorada, en principio, de dos formas:

Mejorando los sistemas inteligentes propuestos en esta investigación para así obtener una tasa de efectividad más elevada al clasificar los casos, lo cual podría lograrse, por ejemplo, aplicando lógica borrosa y sistemas difusos para todos aquellos casos que no pueden ser definidos de forma univoca dentro de uno u otro conjunto.

La otra forma de mejorar la clasificación sería utilizando métodos algorítmicos deterministicos, sería interesante medir la tasa de efectividad de estos en la clasificación de casos contra una clasificación hecha con sistemas inteligentes. Una forma algorítmica de encarar el problema podría ser a partir del algoritmo RAP, modificándolo para que cumpla este objetivo.

Por otro lado se podría aumentar la tasa de éxito del algoritmo RAP, mejorarla adaptando el algoritmo al tipo de discurso propio de los diálogos casuales sería una opción interesante como trabajo de investigación. También se podría incorporar un sistema para que el algoritmo "aprenda" de los diálogos; en el sentido de incorporar nuevas palabras y nuevos casos de conocimiento del tipo "respuesta-estimulo" como es el caso de AIML, también nuevos sustantivos, en especial nombres propios para el caso de RAP, ya que los nombres propios son sustantivos muy comunes y difícilmente estén todos en una base de datos armada previamente. Nuevas líneas de investigación se abren al encarar otros problemas devenidos también por la falta de interpretación pragmática en los chatbots al generar sus respuestas. Estos problemas fueron descriptos en el punto 3, son la ambigüedad léxica en una sentencia, la elipsis, etc.

REFERENCIAS [1] CIRG. 2008. Cybernetic Intelligence Research (Group) –

Loebner Prize 2008. http://www.rdg.ac.uk/cirg/loebner/cirg-loebner-main.asp, página vigente al 31/08/08

[2] Fitrianie, S. 2002, My_Eliza A multimodal Communication System, Master of Science thesis, Delft University of Technology. http://www.kbs.twi.tudelft.nl/Publications/MSc/2002-Fitriani-MSc.html. página vigente al 31/08/08

[3] Funahashi, K. I. 1989 On the approximate realization of continuous mappings by neural networks. Neural Networks, 2, pag. 183-192

[4] Ramón García Martínez, Magdalena Servente, Diego Pasquini 2003. Sistemas Inteligentes. Editorial Nueva Libreria.

[5] Hilera J. R., Martínez V.J. 1995. Redes Neuronales Artificiales: Fundamentos, Modelos y Aplicaciones. Editorial RA-MA

[6] Hobbs, Jerry 1978.Resolving pronoun references, Lingua 44, pag. 311-338.

[7] Lappin, S. and Leass, H.J. (1994). An algorithm for pronominal anaphora resolution. Computational Linguistics 20(4),pag. 535-561

[8] Loebner Contest, 2006. Loebener Prize 2006 Information, http://loebner.net/Prizef/2006_Contest/loebner-prize-2006.html, página vigente al 04/04/09

[9] Loebner Contest, 2007. 17th Annual Loebner Prize for Artificial Intelligence, http://loebner.net/Prizef/2007_Contest/loebner-prize-2007.html, página vigente al 04/04/09

[10] Loebner Contest, 2008. Loebener Prize 2008 Information, http://loebner.net/Prizef/2008_Contest/loebner-prize-2008.html, página vigente al 04/04/09

[11] Loebner Contest, 2009. Loebener Prize 2009 Information, http://www.loebner.net/Prizef/loebner-prize.html, página vigente al 04/04/09

[12] Bonifacio Martín del Brío, Alfredo Sansz Molina 2001. Redes Neuronales y Sistemas Difusos. Editorial RA-MA

[13] Müller, B., Reinhardt, J. Neural Networks. An Introduction, Springer-Verlag, 1990

[14] Penrose, Roger 1989. The Empreror's New Mind. Oxford Univesity Press.

[15] Stuart Rusell, Peter Norving 2003. Inteligencia Artificial, Un enfoque Moderno. Editorial Prentice Hall

[16] Searle, John 1980. Mind, brains and programs. Behavioral and Brain, Sciences. vol 3, nº 3, pag. 417-457

[17] SOM_PACK. The self-Organizing Map Program Package. Helsinki University of Technology, Finland, abril 1995.

[18] Turing, A. 1950. Computing Machinery and Intelligence. Mind. Vol. LIX, N° 236, pag. 433-460

[19] Wallace, R. 2003. The Elements of AIML Style. ALICE A.I. Foundation.

[20] Weizenbaum, J. 1966. ELIZA – A computer Program for the Study of natural Language Communication Between Man And Machine, Communication of the ACM. Vol 9, N° 1, pag. 36-45

[21] Loebner Contest, 2004. Loebener Prize 2004 Information: http://loebner.net/Prizef/2004_Contest/Wallace.html página vigente al 04/04/09

Juan Manuel Rodríguez. Es Ingeniero en Informática en la Universidad de Buenos Aires en el año 2012. Actualmente es docente de las materias: Sistemas de Soporte para Celdas Producción Flexible y Sistemas de Programación no convencional de Robots. Su campo de interés en

investigación es el procesamiento del lenguaje natural.

Hernán Merlino. Es Magister en Ingeniería de Software por la Universidad Politécnica de Madrid. Es Profesor Titular de la Licenciatura en Sistemas y Director del Laboratorio de Investigación t Desarrollo en Arquitecturas Complejas de la Universidad Nacional de Lanús. Es Docente Investigador del Programa de Incentivos de la Secretaria de Políticas Universitarias del Ministerio

de Educación. Su área de investigación es patrones de diseño y de desarrollo de software.

Enrique Fernández. Es Doctor en Ciencias Informáticas por la Universidad Nacional de La Plata. Es Investigador Adscripto al Grupo de Investigación en Sistemas de Información de la Licenciatura en Sistemas de la Universidad Nacional de Lanús. Es Docente Investigador del

Ministerio de Educación de la Republica Argentina.

revista latinoamericana de ingenieria de...

Documents