T-1692

Universidad Mayor de San AndrésFacultad de Ciencias Puras y Naturales

Carrera de Informática

�Modelo de Recuperación de Información para elCastellano�

Tesis de GradoPara optar al titulo de Licenciatura en Informática

mención en Ciencias de la Computación

Postulante: Univ. Grover Leopoldo Aliaga Candia

Docente Tutor: M.Sc. Fátima C. Dolz Salvador

Docente Revisor: M.Sc. Lucio Torrico Diaz

La Paz - Bolivia

2008

Resumen

En la era actual, donde la información en forma textual disponible en medios electrónicos

crece de manera exponencial y donde el tiempo es un recurso critico, se ha vuelto imposible

leer toda esta información. Es por esta razón, que surge la importancia de desarrollar métodos

que permitan a los usuarios buscar y localizar de una manera e�ciente, información contenida

dentro de grandes colecciones de documentos. El desarrollo de un Modelo de Recuperación de

Información (RI) para el Castellano, cumple con estos objetivos incrementando la precisión de

los documentos recuperados tras presentarse una necesidad de información.

El modelo planteado en este trabajo toma como partida el modelo booleano de RI y se

le incorporan herramientas para el Tratamiento de Lenguaje Natural diseñadas para nuestro

idioma, ademas con el objetivo de incrementar la precisión se incorporan métodos de puntuación

y clasi�cación de documentos.

En contraste a otros trabajos, este le da gran énfasis al problema del idioma en la RI. Se

diseña un prototipo que consiste de dos subsistemas: el buscador (una aplicación web) y el

indizador (una aplicación de escritorio). Finalmente, para mostrar lo útil del modelo se calculan

dos medidas de evaluación con ayuda de la herramienta trec_eval y el juicio de relevancia

de siete Secretarios Técnicos de las Brigadas Parlamentarias Departamentales tomando como

colección de documentos la Legislación Boliviana - Compendio de Leyes de 1825 a 2007.

ii

�El lenguaje es la mayor manifestación de la inteligencia humana. A través

del lenguaje expresamos necesidades básicas y nuestros anhelos, técnica-

mente nuestro conocimiento trabaja y escapa a la fantasía. Las ideas se

comparten de manera grandiosa alejada de la distancia y el tiempo.�

Fragmento tomado de Natural Language Processing in Python

iii

Agradecimientos

Se agradece a los Secretarios Técnicos de las Brigadas Parlamentarias Departamentales por

haberme colaborado en el proceso de evaluación del Modelo de Recuperación de Información

planteado y al Ing. Armando de la Parra - Director de la FUNDAPPAC por haber hecho posible

el contactar con los mismos.

En general, se agradece a la Carrera de Informática por haberme acogido y educado durante

estos años. Al Lic. Lucio Torrico por haber revisado este trabajo y por despertar en mí el deseo

de descubrir.

A Dios y a mi querida familia ... gracias por soportarme todos los días.

La Paz, diciembre de 2008

iv

Índice general

I Introducción 1

1. Marco Preliminar 2

1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Planteamiento y Descripción del Problema . . . . . . . . . . . . . . . . . . . 3

1.2.1. Problema General . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.2. Objetivos Especí�cos . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5. Justi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5.1. Teórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.2. Práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.3. Metodológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.6. Metodología y Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.7. Alcances y Aportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.7.1. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.7.2. Aportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

II Marco Teórico 9

2. Recuperación de Información (RI) 10

2.1. Evolución de los Sistemas de Recuperación de Información . . . . . . . . . . . 12

2.2. Componentes de un Sistema de Recuperación de Información . . . . . . . . . 13

2.3. Modelos Clásicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1. Modelo Booleano . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.2. Modelo Espacio Vectorial . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.3. Modelo Probabilístico . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4. Evaluación de Sistemas RI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.1. Evaluación de Sistemas RI sin clasi�cación . . . . . . . . . . . . . . . 22

v

2.4.2. Evaluación de Sistemas RI con clasi�cación . . . . . . . . . . . . . . . 22

3. Tratamiento del Lenguaje Natural y Análisis Morfológico 24

3.1. Breve historia del tratamiento del lenguaje natural (TLN) . . . . . . . . . . . 24

3.2. Características Morfológicas del Castellano . . . . . . . . . . . . . . . . . . . 27

3.2.1. El Sustantivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.2. El Adjetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.3. El Pronombre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.4. El Verbo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3. Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3.1. Procesamiento en Lenguaje Natural . . . . . . . . . . . . . . . . . . . 32

3.4. Nombres Propios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4.1. Procesamiento en Lenguaje Natural . . . . . . . . . . . . . . . . . . . 33

3.5. Tokenizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.6. Tratamiento Stop Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.7. Normalización de Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.7.1. Lematización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.7.2. Stemming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4. Metodologías y Herramientas de Desarrollo 37

4.1. Modelo incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2. Proceso de Ingeniería Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3. Herramienta de modelado UML . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.1. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.2. Diagrama de Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.3. Diagrama de Secuencia . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3.4. Diagrama de Actividad . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4. Arquitectura Modelo Vista Controlador (MVC) . . . . . . . . . . . . . . . . . 42

4.4.1. De�nición de las partes . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.5. Herramientas de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5.1. Lenguaje de Programación Python . . . . . . . . . . . . . . . . . . . 44

4.5.2. Natural Language ToolKit (NTLK) . . . . . . . . . . . . . . . . . . . 45

4.5.3. XPDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5.4. Framework Web Django . . . . . . . . . . . . . . . . . . . . . . . . . 47

III Desarrollo 48

5. Modelado del Sistema RI 50

5.1. Formulación y Recopilación de requisitos . . . . . . . . . . . . . . . . . . . . 50

5.1.1. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.1.2. Modelo de contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.1.3. Modelo de interacción . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.4. Modelo Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2. Diseño de la aplicación web . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.2.1. Diseño arquitectónico . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.3. Diseño de la Interfaz de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.3.1. Análisis del Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.3.2. Análisis y modelado de tareas . . . . . . . . . . . . . . . . . . . . . . 60

5.3.3. Análisis del Contenido . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.3.4. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6. Herramientas para el tratamiento lingüístico 63

6.1. ISO 8859-1: Codi�cación Latin1 . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.2. Diseño del Tokenizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.2.1. Expresiones Regulares en Python . . . . . . . . . . . . . . . . . . . . 64

6.2.2. Construcción de las Expresiones Regulares . . . . . . . . . . . . . . . 64

6.2.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3. Stemmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3.1. Algoritmo de Porter - Snowball . . . . . . . . . . . . . . . . . . . . . 66

6.3.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.4. Corrector Ortográ�co . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.4.1. Distancia de Edición . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.4.2. Coe�ciente de Jaccard . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.4.3. Indices k-grama para corrección de ortografía . . . . . . . . . . . . . . 74

6.4.4. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7. Construcción del Indice y Tratamiento de Consultas 77

7.1. Indice invertido estándar posicional . . . . . . . . . . . . . . . . . . . . . . . 77

7.1.1. Compresión del Indice Invertido . . . . . . . . . . . . . . . . . . . . . 79

7.2. Puntuación de Documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.2.1. Frecuencia de término y peso en el documento . . . . . . . . . . . . . 80

7.2.2. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.3. Indice invertido k-grama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.4. Tratamiento de Consultas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

IV Evaluación 87

8. Evaluación del Modelo 88

8.1. Relevancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8.2. Curva precisión-cobertura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

8.3. 11 puntos interpolados de precisión media . . . . . . . . . . . . . . . . . . . 90

8.4. Término Medio de Precisión (MAP) . . . . . . . . . . . . . . . . . . . . . . . 91

8.5. El evaluador: trec_eval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.6. Evaluación del prototipo con trec_eval . . . . . . . . . . . . . . . . . . . . . 93

8.6.1. 11 puntos interpolados de precisión media . . . . . . . . . . . . . . . 93

8.6.2. Término Medio de Precisión (MAP) . . . . . . . . . . . . . . . . . . . 94

V Conclusiones 96

9. Conclusiones y Trabajo Futuro 97

9.1. Lineas de investigación abiertas . . . . . . . . . . . . . . . . . . . . . . . . . 98

VI Anexos 100

Anexo A: Proceso de Evaluación 101

Anexo B: Documentos 102

Referencias 103

Índice de �guras

1.1. Proceso de Consulta en un Sistema de Recuperación de Información. Fuente:

Elaboración personal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1. Un completo sistema de búsqueda. Fuente: (MANNING y cols., 2008). . . . . 13

3.1. Morfología del verbo amábamos. Fuente: (L. J. L. GARCIA, 2002) . . . . . . . 29

3.2. Lista de terminaciones. Fuente: (L. J. L. GARCIA, 2002) . . . . . . . . . . . . 30

4.1. El proceso de Ingeniería Web. Fuente: (PRESSMAN, 2007). . . . . . . . . . . 39

4.2. Ejemplo de la Clase lavadora. Fuente: (SCHMULLER, n.d.). . . . . . . . . . . 40

4.3. Ejemplo de un diagrama de secuencia. Fuente: (SCHMULLER, n.d.). . . . . . 41

4.4. Ejemplo de un diagrama de actividad. Fuente: (SCHMULLER, n.d.). . . . . . 42

4.5. La arquitectura MVC. Fuente: (PRESSMAN, 2007). . . . . . . . . . . . . . . 43

5.1. Casos de uso del Sistema de Recuperación de Información �Yatiri�. Fuente: Crea-

ción personal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2. Árbol de datos para una consulta. Fuente: Creación personal. . . . . . . . . . 54

5.3. Clases de análisis para el caso de uso �Búsqueda sobre la colección de documen-

tos�. Fuente: Creación personal. . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4. Diagrama de secuencia para el caso de uso �Búsqueda sobre la colección de

documentos�. Fuente: Creación personal. . . . . . . . . . . . . . . . . . . . . 55

5.5. Diagrama de actividad para el método evaluar(void) de la Clase Consulta. Fuen-

te: Creación personal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.6. Diagrama de actividad para el método corregirConsulta(String) de la Clase Con-

sulta. Fuente: Creación personal. . . . . . . . . . . . . . . . . . . . . . . . . 57

5.7. Diagrama de actividad para el método hallarResultados(void) de la Clase Con-

sulta. Fuente: Creación personal. . . . . . . . . . . . . . . . . . . . . . . . . 58

5.8. Diagrama de actividad para el proceso indizar(ruta). Fuente: Creación personal. 59

5.9. Arquitectura de contenido para la aplicación web. Fuente: Creación personal. . 60

5.10. Diagrama Carril para el caso de uso búsqueda sobre la colección de documentos.

Fuente: Elaboración personal. . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.11. Formato de pantalla preliminar. Fuente: Elaboración personal. . . . . . . . . . 62

ix

6.1. Algoritmo para calcular la distancia de edición entre las cadenas s1 y s2. Fuente:

(MANNING y cols., 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2. Ejemplo del cálculo de la distancia de Levenshtein. Las celdas de color naran-

ja (inferiores derechas de cada entrada (i, j)) es el mínimo de las otras tres

entradas. Fuente: Creación Personal. . . . . . . . . . . . . . . . . . . . . . . 73

6.3. Correspondencia en 3-gramas, para los 3-gramas del termino código. Fuente:

(MANNING y cols., 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.1. Estructura de un índice posicional, que guarda las posiciones en cuanto a carac-

teres y tokens de un termino. Fuente: Elaboración personal . . . . . . . . . . . 78

7.2. Construcción de un índice por clasi�cación y agrupamiento. La secuencia de

términos en cada documento, etiquetado por su identidad de documento `docID'

(izquierda) está ordenada alfabéticamente (centro). Un término es agrupado por

palabra y luego por `docID'. Los términos y docID son luego separados hacia

afuera (derecha). El diccionario almacena los términos, y tiene un puntero a

la lista de postings para cada término. Cada lista postings almacena la lista de

documentos en los cuales el término ocurre y pueden almacenar otra información

adicional, tal como la frecuencia y las posiciones del término en cada documento.

Fuente: (MANNING y cols., 2008). . . . . . . . . . . . . . . . . . . . . . . . 79

7.3. Vector documento para el documento con docID = 1546. Note que el termino

à' tiene puntuación casi nula y el termino àzurduy ' recibe una puntuación muy

alta. Fuente: Elaboración personal. . . . . . . . . . . . . . . . . . . . . . . . 83

7.4. Posting del término azurduy modi�cado, para que se pueda utilizar la puntua-

ción. Esta es la estructura del índice que utilizaremos en el prototipo. Fuente:

Elaboración personal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.5. Ejemplo de una lista postings en un indice 3-grama. Las coincidencias en el

vocabulario de términos son ordenadas lexicogra�camente en el posting. Fuente:

(MANNING y cols., 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.6. Árbol in�jo de una consulta. Fuente: Elaboración personal. . . . . . . . . . . . 85

8.1. Grá�co precisión/cobertura. Fuente: (MANNING y cols., 2008) . . . . . . . . 90

8.2. Grá�co promedio de 11 puntos interpolados de precisión media a través de 50

consultas para un sistema representativo TREC. El termino medio de precisión

para este sistema es 0.2553. Fuente: (MANNING y cols., 2008) . . . . . . . . 91

8.3. Grá�co promedio de 11 puntos interpolados de precisión media a través de 50

consultas para el sistema de recuperación de información �Yatiri�. El termino

medio de precisión para este sistema es 0.6860. Fuente: Creación Personal. . . 94

Índice de cuadros

2.1. �¾Recuperación de datos o Recuperación de Información?� Fuente:(RIJSBERGEN,

n.d.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. Distribución de la aparición de un término en los documentos relevantes y no

relevantes. Fuente: (HERRERA, 2006) . . . . . . . . . . . . . . . . . . . . . 20

3.1. Stop Words, tomadas de la colección �Legislación Boliviana - Compendio de

leyes de 1825 a 2007� . Fuente: Creación personal. . . . . . . . . . . . . . . . 34

6.1. Operadores y caracteres comunes de expresiones regulares en Python. . . . . . 64

7.1. La frecuencia de colección (cf) y la frecuencia de documentos (df) se com-

portan de modo diferente, como en el ejemplo de la colección Reuters. Fuen-

te:(MANNING y cols., 2008) . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.1. Promedio de los 11 puntos interpolados de precisión media a través de 50 con-

sultas para el Sistema de Recuperación de Información �Yatiri�. Fuente: Creación

Personal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

xi

Introducción

Considere el siguiente escenario: Ud. desea saber �¾Quién descubrió América?� , entonces

acude a Internet1 realiza su búsqueda en el conocido buscador de páginas web �Google�, a

continuación como respuesta casi inmediata obtiene un número signi�cante de resultados. En

los cuales Ud. busca de manera manual el que más se ajuste a sus necesidades, en este caso en

particular, busca el documento que contenga información sobre Quién descubrió América. Una

vez encontrado el documento Ud. ha logrado satisfacer su necesidad de información.

Revisemos un poco el escenario anterior: Ud., la persona que tiene algún requerimiento

de información (sin importar los �nes) se denomina Usuario, Google el sistema que realizó la

búsqueda en las páginas web se denomina Sistema de Recuperación de Información o Motor de

Búsqueda, la pagina web encontrada se denomina documento2.

La pregunta importante aquí es: �¾Cómo se realiza el proceso de búsqueda en la colección

de documentos?�

A lo largo de este documento se irá respondiendo a esta pregunta de manera detallada,

por ahora podemos decir que el área que estudia este problema se denomina �Recuperación de

Información�.

La Recuperación de Información no es un área de investigación nueva, comenzó en los

años 40, cuando se dio un crecimiento en la literatura cientí�ca. Desde entonces, esta ha ido

evolucionando para contar actualmente con grandes Sistemas de Recuperación de Información

que trabajan sobre billones de documentos distribuidos en diferentes lugares (como es el caso

de Internet).

Estado del Arte

En la actualidad, la información textual disponible en formato electrónico crece constan-

temente debido a la cantidad de nuevas fuentes de información: investigadores, escritores o

1Internet es en la actualidad la fuente de información más grande, en la cual se encuentran millares de

documentos de diferente índole (desde recetas de cocina, hasta investigaciones cientí�cas).2Sin importar en que formato se encuentre: .DOC, .PDF, .PPT, .HTML, etc.

xii

xiii

simples a�cionados a la pluma electrónica, cuentan con los medios para hacer públicos los do-

cumentos de su autoría, esto hace que información de todo tipo esté disponible ya sea �dedigna

o no, esta información se ajusta a las necesidades del usuario quien requiere información variada

y en diferentes matices.

Los Sistemas de Recuperación de Información actuales brindan con buenos niveles de calidad

resultados óptimos que en un buen porcentaje satisfacen de gran manera las necesidades del

usuario, haciendo que la recuperación de información se convirtiera en la forma estándar y

preferida de acceder a la información.

Los resultados que obtenemos de estos sistemas dependen mucho de la forma en que se

realiza la consulta, puesto que los resultados de cualquier consulta van ligados al lenguaje y en

cierto modo al nivel de educación y cultura del usuario.

El hecho de realizar las consultas en un lenguaje natural hace que exista dependencia entre

el idioma en el que se realiza la consulta y el idioma en el que están escritos los documentos,

esta a�rmación destaca en trabajos como (HERENCIA, 2004), (VALLEZ y PEDRAZA, 2007)

y (FERNANDEZ y SERRANO, n.d.). Además, estos sistemas producen listas interminables de

resultados que pueden llegar a invalidar su utilidad, debido a que hace virtualmente imposible

encontrar lo deseado y puede provocar desasosiego en el usuario, que se ve impotente para

digerir el volumen de datos que le proporciona el sistema. Según (BENGOCHEA y PATRICIO,

2005) esto también puede atribuirse a la forma en que se presenta la información recuperada.

En los países de habla hispana todavía no se han logrado avances signi�cativos (FIGUEROLA,

n.d.), y si bien podemos utilizar las mismas herramientas teóricas utilizadas por nuestros colegas

de habla inglesa debemos distinguir claramente las diferencias entre su lenguaje y el nuestro,

esto con el objetivo de hallar las mejores respuestas a una consulta dada. Estas son precisamente

las barreras que el lenguaje impone en la recuperación de información. Aunque algunos autores

(PADILLA, 2005) consideran que el uso de técnicas lingüísticas en un contexto de recupera-

ción automatizada es poco útil para mejorar los resultados de dicha recuperación. Entonces

se a�rma que el papel de dichas técnicas lingüísticas en el proceso de recuperación se da en

el contexto de interacción. La interactividad con el usuario a la hora de ayudar a expresar a

este su necesidad de información y también a la hora de navegar por los documentos obte-

nidos en la recuperación, a �n de obtener �nalmente los más adecuados. Sin embargo, no es

el objetivo lograr una comprensión absoluta del lenguaje natural, en este caso castellano, sino

realizar un análisis lo su�cientemente trabajado sintáctica y semánticamente, para lograr que

los documentos relevantes en una consulta satisfagan las necesidades del usuario.

Esto nos da a pensar en la recuperación de información como un área multidisciplinaria,

donde profesionales de las áreas de informática, lingüística y bibliotecología deben trabajar

juntos para obtener los mejores resultados posibles.

xiv

Organización de la tesis

El propósito de este estudio consiste en desarrollar un Modelo de Recuperación de Informa-

ción para el idioma Castellano, apoyado en el Tratamiento del Lenguaje Natural (TLN) y las

técnicas de Recuperación de Información actuales.

Para tal efecto, se clasi�ca el trabajo en cuatro etapas: (1) El preprocesamiento de los

documentos. En esta primera etapa se realiza un análisis lingüístico computacional a los docu-

mentos y a las consultas haciendo énfasis en los problemas subyacentes en el idioma castellano,

este análisis nos sera útil para el diseño del tokenizador, lematizador y el corrector de errores

ortográ�cos, herramientas importantes para tratar las consultas y los documentos de forma

automatizada. (2) El indexado. Una vez realizado el análisis lingüístico computacional y desa-

rrolladas las herramientas, desarrollamos el índice general, el vocabulario de términos, el indice

k-grama (que es útil para realizar correcciones ortográ�cas y manejo de comodines3) y el aná-

lisis de tratamiento a las consultas. (3) Diseño del Prototipo. Comenzamos con el diseño del

prototipo que consiste de dos subsistemas: el indizador (una aplicación de escritorio) y el mo-

tor de búsqueda (una aplicación web). El motor de búsqueda cumple la importante tarea de

presentar la información al usuario, así su diseño se realiza teniendo en cuenta este y otros

aspectos. (4) Evaluación. Es necesario realizar una evaluación del modelo propuesto para ver

su desempeño, en esta etapa realizamos la evaluación al prototipo haciendo uso de medidas

diseñadas especialmente para sistemas de recuperación de información, además utilizamos la

herramienta de evaluación trec_eval usada para la evaluación de sistemas de recuperación de

información de gran envergadura.

La estructura de la tesis contiene los siguientes capítulos: (1) Marco Preliminar: donde se

realiza una introducción al problema, sus soluciones y una metodología del trabajo a realizar. (2)

Marco Teórico: breve descripción de los Sistemas de Recuperación de Información y de las herra-

mientas de diseño y programación a utilizar. (3) Tratamiento del Lenguaje Natural: se revisa las

características morfológicas del idioma castellano, para abarcar los posibles problemas de este

y continuar con el diseño de las herramientas para el tratamiento lingüístico de los documentos

y las consultas, que se realiza en el capítulo (4) Metodologías y Herramientas de Desarrollo:

se presenta los métodos y herramientas que utilizaremos a lo largo del trabajo destacando el

por qué fueron elegidas. (5) Modelado del Sistema RI: para probar si nuestra hipótesis es cierta

necesitamos realizar experimentos sobre un prototipo y colección de documentos real, de esta

forma comenzamos con el diseño de un prototipo; en este capítulo de�nimos los componentes de

nuestro prototipo y cómo este interactua con el usuario (interfaz de usuario). (6) Herramientas

para el tratamiento lingüístico: diseñamos el tokenizador, el stemmer y el corrector ortográ�-

co; se diseñan de manera separada para que puedan ser utilizadas en trabajos posteriores. (7)

Construcción del Índice y Tratamiento de Consultas: se diseña el índice general y una formali-

3Se re�ere a caracteres como *,?,etc. que son utilizados en búsquedas avanzadas.

xv

zacion para el tratamiento de consultas. (8) Evaluación del Modelo: la evaluación del modelo

requiere que se realice una evaluación al prototipo, esta se realiza haciendo uso de medidas

especialmente diseñadas para este tipo de sistemas y la herramienta de evaluación trec_eval.

(9) Conclusiones y Recomendaciones: resume los resultados obtenidos y las recomendaciones

para trabajos posteriores.

Parte I

Introducción

1

Capítulo 1

Marco Preliminar

1.1. Antecedentes

La recuperación de información como disciplina académica y aplicada data de hace más de

60 años, cuando por 1940 se veía un gran crecimiento en la literatura cientí�ca y disponibilidad

de las primeras computadoras que levantaban el interés en la clasi�cación automatizada de

documentos, por el año 1958 IBM mostraba sus máquinas �auto-indexadoras�, aunque estas

solo trabajaban con autores, títulos y palabras clave(MANNING, RAGHAVAN, y SCHÜTZE,

2008). Fue mucho después que se pensó en integrar buscadores de texto completo. Se consideró

el proceso de recuperación como un proceso totalmente automatizado: tanto en la indización

o representación del contenido de los documentos, como en la expresión de las necesidades

de los usuarios (consultas), y la estimación del parecido, cercanía o similitud entre consulta

y documentos. Así, actualmente podemos pensar en un sistema en el que los documentos se

indexan automáticamente y las consultas se formulan en lenguaje natural.

Las técnicas, métodos y metodologías que se aplican para el proceso de Recuperación de

Información, nacen a partir de las funciones convencionales de una biblioteca: �reunir, procesar,

difundir, almacenar y usar la información documental para dar servicio a la sociedad� .

La Lingüística es una de las ramas de investigación más antiguas, con una historia de logros

extraordinariamente rica y productiva. Desde los estudios de Noam Chomsky en 1957 publicados

en la obra �Gramática Generativa�, esta dio un giro trascendental abriendo paso a una nueva línea

de investigación en la cual se vislumbra una forma de automatizar el tratamiento del lenguaje

natural. Aunque hasta la fecha se han presentado muchas propuestas de gramáticas generativas

todavía no se puede tratar bien el problema del contexto que in�uye mucho en la interpretación

de una oración. Estos estudios, dieron paso a un nuevo campo de investigación el �Tratamiento

del Lenguaje Natural�, mismo que nos brinda herramientas que hacen el tratamiento de texto

posible, tales como lematizadores, etiquetadores, tokenizadores, entre otros.

El Tratamiento del Lenguaje Natural (TLN) es la herramienta fundamental a la hora de

2

CAPÍTULO 1. MARCO PRELIMINAR 3

organizar1 los documentos, para ofrecer los resultados de manera óptima. El TLN es una ciencia

interdisciplinaria que se ubica entre la Lingüística y la Informática, con énfasis en la Lingüística.

Cuyo �n es la elaboración de modelos computacionales que reproduzcan uno o más aspectos

del lenguaje humano. Dos áreas aledañas a esta son sin duda la Estadística y la Inteligencia

Arti�cial.

Como antecedentes externos, tenemos:

�La investigación sobre Recuperación de la Información en español�, artículo publicado

por Carlos Figuerola en la Universidad de Salamanca, España. En este se puntualiza la

importancia del lenguaje en la Recuperación de Información y la falta de un estudio para

nuestro idioma.

�Google�, �Yahoo�, �AltaVista�, etc. buscadores web que son sin duda los mayores refe-

rentes un cuanto a Sistemas de Recuperacion de Informacion se re�ere.

�Westlaw�, �Mistral�, �Stairs�, etc. buscadores a nivel empresarial.

�Apple's Mac OS X Spotlight�, �Windows Vista's Instant Search�, etc. buscadores de

escritorio en Sistemas Operativos tales como MacOS y Windows Vista respectivamente,

que no son muy utilizados en la actualidad. Pero demuestran la necesidad actual de

mantener la información organizada y rápidamente accesible.

El presente trabajo de investigación hace referencia a los anteriores antecedentes como una

forma de evidenciar los pocos trabajos dirigidos a la Recuperación de Información exclusiva para

el idioma Castellano.

1.2. Planteamiento y Descripción del Problema

Las consultas que realiza un usuario a los Sistemas Recuperadores de Información, dan inicio

cuando el usuario introduce su consulta (en lenguaje natural o en algunos casos en lenguaje

formal), similar a una consulta a un profesional de Ciencias de la Documentación (Bibliotecario),

la respuesta del sistema consiste en una o más referencias a documentos (usualmente en formato

digital) que se aproximan mejor (mientras mas aproximación tiene un documento con una

consulta �para el usuario� el documento es más preciado) a las necesidades del usuario2.

El mencionado proceso de consulta se torna tedioso, insatisfactorio e incluso confuso, con-

siderando tales aspectos:1Se habla de organizar o clasi�car de una forma similar a ordenar libros en un estante. Salvo que no movemos

físicamente los documentos.2Debe hacerse una distinción importante: la información necesaria es el tema sobre el cual el usuario desea

saber más, y este diferenciado de una consulta, la cual es la que el usuario da a conocer al sistema en un intento

para comunicarle la información que necesita


Figura 1.1: Proceso de Consulta en un Sistema de Recuperación de Información. Fuente: Ela-

boración personal.

Se obtiene un gran número de resultados, que desembocan en una nueva búsqueda manual

para encontrar lo que realmente se está buscando.

El usuario no consigue expresar de manera correcta su necesidad de información. Esto

se da cuando los sistemas son poco propensos a errores ortográ�cos o carecen de una

interfaz amigable. Entonces el usuario no obtiene resultados satisfactorios.

La consulta no devuelve buenos resultados, esto puede deberse a factores como el anterior

pero se le atribuye en su mayoría a una mala indización resultante de un mal tokenizado3 de

los documentos, ya que estos tokenizadores no están diseñados para el idioma castellano4.

1.2.1. Problema General

Se tiene poca facilidad para búsquedas en lenguaje natural sobre colecciones de documentos

en nuestro idioma. Dado que los resultados dependen del lenguaje en el que se realiza la consulta

y el lenguaje en el que están escritos los documentos. Además de otros factores como la forma

en que se presenta la información recuperada al usuario, el nivel de educación del usuario (que

se re�eja en la forma de realizar las consultas, o los errores ortográ�cos de la misma) y la región

en que vive (a causa de modismos propios de la región).

3Proceso de dividir el texto de un documento en términos (no siempre palabras) llamados token's que serán

indizados en nuestro Indice General.4Un ejemplo de como el tokenizado afecta en la indización puede ser el siguiente: Como dividimos la palabra

U.M.S.A.? como �U� �M� �S� �A� (4 token's) o como �U.M.S.A� (1 token).


1.3. Objetivos

1.3.1. Objetivo General

Facilitar y optimizar las búsquedas en lenguaje natural sobre colecciones de documentos en

nuestro idioma mediante un modelo de Recuperación de Información para el idioma Castellano,

apoyado en el Tratamiento del Lenguaje Natural y las técnicas de Recuperación de Información

estándar.

1.3.2. Objetivos Especí�cos

Organización o clasi�cación parcial de la información.

Realizar un análisis lingüístico computacional a las consultas y a los documentos.

Obtener varios resultados que correspondan mejor a una consulta.

Presentar la información de manera adecuada al usuario.

Búsquedas sobre texto estructurado o semi-estructurado e�cientes.

Análisis de las reglas morfológicas para el idioma Castellano.

Incrementar el grado de satisfacción del usuario entre los documentos deseados y los

documentos obtenidos.

1.4. Hipótesis

Mediante un modelo de recuperación de información para el Castellano, es posible incremen-

tar el grado de precisión de búsquedas sobre colecciones de documentos en el mismo idioma.

Donde la precisión es la fracción de resultados devueltos que son relevantes5 para responder

la necesidad de información.

1.5. Justi�cación

Utilizamos sistemas de recuperación de información a diario, casi sin darnos cuenta, cuando

buscamos en el Internet o en una Enciclopedia Digital6. Existen muchas personas, sobre todo

5un documento es relevante si este se dirige a a�rmar o negar la información necesaria con respecto a la

necesidad personal de información del usuario, no si este contiene por casualidad todas la palabras utilizadas en

la consulta.6Como la enciclopedia Encarta


investigadores y operadores de justicia, que requieren información a diario y dependen mucho

de tales sistemas. Así que se obtienen las siguientes justi�caciones.

1.5.1. Teórica

El análisis sobre la colección de documentos y las consultas, nos dará una visión completa

sobre los tópicos del idioma Castellano actuales y como tratarlos de manera automatizada

(apoyado en el Tratamiento del Lenguaje Natural).

1.5.2. Práctica

Los bene�ciarios son la sociedad en su conjunto, destacando los profesionales jurídicos,

médicos, informáticos, investigadores, estudiantes, etc. Y cualquier otra persona que requiera

mantener la información que posee de manera organizada y fácil de consultar.

1.5.3. Metodológica

Se realiza el diseño de herramientas importantes que se pueden reutilizar sin ningún pro-

blema, como ser: el lematizador, el tokenizador y el corrector ortográ�co como referentes para

posteriores trabajos de investigación, sobre todo en el área del tratamiento del lenguaje natural.

También, se realiza el diseño de un modelo de recuperación de información completo, que

puede ser implementado, reutilizado y mejorado tanto en sus componentes como de manera

íntegra. Además, del diseño de la interfaz adecuada y el proceso de evaluación detallado para

este tipo de sistemas que puede ser aplicado a otros SRI.

1.6. Metodología y Herramientas

Se aplicará la metodología de investigación cientí�ca deductiva, siguiendo los lineamientos

descritos en (BUNGE, n.d.):

Observación: Se realiza una observación sistemática al proceso de consultas en una colección

de documentos, mediante un sistema de recuperación de información. Para teorizar las

necesidades y falencias de este proceso con respecto al idioma Castellano.

Formulación de la Hipótesis: Se plantea incrementar el grado de precisión de búsquedas

sobre colecciones de documentos de texto en Castellano, mediante un modelo de recupe-

ración de información para el idioma Castellano.

Diseño de la Aplicación: Se procede al diseño de la solución propuesta, desarrollando un

modelo de recuperación de información para el idioma castellano.


Pruebas: Para validar el modelo propuesto, se procede a la implementación de este mediante

un sistema de recuperación de información, se somete al sistema a una evaluación propia

de la teoría de la recuperación de información.

Conclusiones: Redacción del informe �nal respecto a la investigación realizada en la cual

están involucrados, procesos como el tokenizado, indexado, consultas a la colección, fa-

cilidad de uso.

Las herramientas principales para la idealización y realización del modelo y su posterior

desarrollo son:

Herramientas de diseño:

� Modelo incremental y proceso de ingeniería web

� Herramienta de modelado UML

� Arquitectura Modelo Vista Controlador (MVC)

Herramientas de desarrollo:

� Lenguaje de Programación - Python

� Librería - Natural Language ToolKit (NLTK) para Python

� Programa - XPDF para convertir archivos en formato PDF a texto plano

� Framework Web Django para Python

Herramienta de evaluación:

� Programa - trec_eval utilizado para evaluación de SRI en TREC

1.7. Alcances y Aportes

1.7.1. Alcances

El sistema de recuperación de información a desarrollar permitirá que los usuarios realicen

sus consultas sobre una colección de documentos de manera simple y satisfactoria. El sistema

propone realizar el tokenizado, steeming y corrección ortográ�ca (mediante la aplicación de los

principios del Tratamiento del Lenguaje Natural), el proceso de indexado y consultas (mediante

la aplicación de técnicas de la Recuperación de Información) el diseño de la interfaz de usuario

(mediante la aplicación de snippet, pequeños trozos de texto del documento recuperado).

Se considera los siguientes puntos como hechos:


La colección de documentos se encuentra en formato .PDF (esto solo para la conversión

de los archivos a texto plano) y que todos los documentos de dicha colección se encuentran

escritos en el idioma Castellano o similares.

La colección de documentos se trata con la codi�cación Latin1 es decir el ISO 8859-1

que de�ne la codi�cación del alfabeto latino (incluyendo diacríticos y letras especiales).

1.7.2. Aportes

Los aportes de la investigación son:

1. La construcción del modelo de recuperación de información para el idioma Castellano.

2. Diseño de un tokenizador para el idioma Castellano.

3. Diseño de un steemer para el idioma Castellano.

4. Diseño de un corrector ortográ�co para el idioma Castellano.

Parte II

Marco Teórico

9

Capítulo 2

Recuperación de Información (RI)

Tal como se menciona en (RIJSBERGEN, n.d.) La recuperación de información está muy

distante. Se puede encontrar muchas de�niciones de este término, algunas tomadas muy a la

ligera, pero nosotros nos interesamos en sistemas1 automáticos de recuperación de información2.

Desafortunadamente la palabra información puede ser muy confusa, dentro el contexto de la

recuperación de información y además no es fácil de cuanti�car como se puede constatar en el

trabajo de Claude E. Shanon �Una teoría matemática de la información�. Sin embargo, en este

trabajo nos quedamos con la de�nición, dada en (MANNING y cols., 2008):

Recuperación de Información (RI) es el hallazgo de material (usualmente documen-

tos) de naturaleza no estructurada (usualmente texto) que satisface la necesidad de

información desde amplias colecciones (usualmente almacenadas en computadoras).

Datos de naturaleza �no estructurada� se re�ere a datos que no están claros, semánticamente

hablando, datos que no están organizados de manera fácil para una computadora. Esto es lo

opuesto a los datos estructurados, como una base de datos relacional. Pero en realidad, ningún

dato está realmente �no estructurado� si en este momento Ud. revisa un libro notara que

está dividido en capítulos, estos a su vez en secciones, estos a su vez en párrafos, etc., la

estructura esta comúnmente representada en los documentos por enriquecimiento explícito. Así

RI es también utilizada para realizar la búsqueda en documentos �semiestructurados� tal como

encontrar un documento que contiene una palabra en el titulo y otra en su cuerpo. También en

clasi�cación de documentos o clustering.

En cuanto a �satisface la necesidad de información�, esto tiene mucho que ver con las

necesidades del usuario. Pues si bien los sistemas pueden devolvernos abundante información

tras una consulta, igualmente puede resultarnos poco útil si ninguno de esos documentos se

1Debe notar que �recuperación de información - RI� es la base teórica que da origen al diseño de �sistemas

de recuperación de información - SRI�.2Automático contrario a manual e información contrario a dato, así las �bases de datos� quedan fuera de

nuestro contexto.

10

CAPÍTULO 2. RECUPERACIÓN DE INFORMACIÓN (RI) 11

ajusta a nuestras necesidades. Como ya se indicó, esto está muy ligado a la educación del usuario

y al cómo se realiza la consulta, aunque de lo que se trata es de que el sistema se adecue a

las necesidades del usuario y no el usuario a lo que puede hacer el sistema. La evaluación de

los sistemas de recuperación de información considera este problema ampliamente, como lo

veremos más adelante.

Y cuando se menciona �amplias colecciones�, se re�ere a colecciones que van desde centenas

de documentos a billones de documentos (como es el caso de Internet). Esto da paso a una

clasi�cación de los sistemas de recuperación de información en base al tamaño de las colecciones

que manejan, (MANNING y cols., 2008) considera tres escalas:

Billones de documentos almacenados en millones de computadoras�buscadores web� , don-

de se ve la necesidad de recoger documentos (mediante crawlers), explotación de hiper-

texto y no resultar engañado por el proveedor que puede manipular su contenido para

aparecer siempre con mejor puntuación o rank.

Empresa y dominio especi�co de búsqueda, donde se realiza la recuperación sobre sistemas

centralizados de archivos, tal como documentos internos de una empresa (como en un

periódico).

recuperación de información individual, donde se ve la necesidad de organizar los archi-

vos en una computadora personal, manipular diferentes tipos de documentos (imágenes,

música, texto, etc.) y ser lo su�cientemente ligeros para no incomodar al usuario.

Para marcar la diferencia entre la recuperación de datos (RD) y la recuperación de informa-

ción (RI), en la Tabla 2.1 mostramos algunas de las características de ambas.

Recuperación de Recuperación de

Datos (RD) Información(RI)

Coincidencia Coincidencia exacta Coincidencia parcial, la mejor

Inferencia Deducción Inducción

Modelo Deterministico Probabilístico

Clasi�cación Monothetic Polythetic

Lenguaje de Consulta Arti�cial Natural

Especi�cación de Consulta Completa Incompleta

Artículo buscado Coincidente Relevante

Respuesta al error Sensible Insensible

Tabla 2.1: �¾Recuperación de datos o Recuperación de Información?� Fuente:(RIJSBERGEN,

n.d.)


A lo largo de este capítulo comenzamos con un breve resumen de la evolución de los sistemas

de recuperación de información, describimos los componentes de un sistema de recuperación

de información completo y revisamos los modelos de recuperación de información: booleano,

espacio vectorial y probabilistico. Finalizando, con una revisión sobre las diferentes medidas de

evaluación para sistemas de recuperación de información.

2.1. Evolución de los Sistemas de Recuperación de In-

formación

Antes que detallar la evolución de estos sistemas desde sus principios, tomamos la resumida

presentación que expone Baeza-Yates en (BAEZA-YATES y RIBEIRO-NETO, 1999), que se

enfoca en el índice que es el núcleo de todo sistema de recuperación de información, presentando

la evolución de los sistemas RI entorno a estos en tres fases fundamentales:

De Manual a Automático : Al principio se construían los indices de manera manual con

objetivo de organizar colecciones de libros en su mayoría, se remonta al nacimiento de

la bibliotecologia como ciencia. Posteriormente, el avance tecnológico hace posible la

construcción de amplios indices de manera automática.

Recuperación de Información en las bibliotecas : las bibliotecas fueron las primeras ins-

tituciones que adoptaron los sistemas RI. La primera generación se distingue por la au-

tomatización básica de la tecnología previa (tal como índices en tarjetas). La segunda

generación, incrementa la funcionalidad de búsqueda adicionando búsquedas por palabra

clave, por resumen y consultas mas complejas. La tercera generación, brinda interfa-

ces grá�cas, formularios electrónicos, presentando hipertexto y arquitecturas de sistema

abierto.

World Wide Web : Internet revolucionó muchos campos, pero en el que hizo mas eco fue

en la explosión de fuentes de información. Gracias a la comunicación digital podemos

acceder de manera rápida a sitios que se encuentran en otros países, y por primera vez

en la historia las personas tienen libre acceso a la información. A su vez Internet también

presentó nuevos retos, como el análisis de links, diseño de crawlers3 y principalmente el

indexado sobre una colección de documentos inmensa y dinámica.

3Pequeño programa que recorre Internet en busca de documentos nuevos o actualizados, una vez encontrados

procede a su indexado para la posterior actualización del indice.


2.2. Componentes de un Sistema de Recuperación de

Información

Revisemos los componentes básicos de un sistema de recuperación de información propuesto

por (MANNING y cols., 2008), que permitirá búsquedas de texto libre, booleanas, de zona y

campo.

Figura 2.1: Un completo sistema de búsqueda. Fuente: (MANNING y cols., 2008).

La Figura 2.1 es una traducción (para brindar una mejor comprensión) de la presentada en

(MANNING y cols., 2008). Se inicia con la colección de documentos, cada uno de los docu-

mentos de esta colección es sometido a un análisis gramatical y a un procesamiento lingüístico

(tokenizacion, stemming o lematización). Los tokens resultantes de la colección de documentos

alimentan a dos módulos. Primero, se retiene una copia de cada documento en un documento

cache (esto nos permite generar resultados por partes, como: título, cuerpo, etc.). Una segun-

da copia se provee al grupo de indexadores que crean cuatro indices cada uno para diferentes

propósitos (de izquierda a derecha: recuperación inexacta de los mejores K, para puntuación de

documentos; zona y campo, para búsquedas por zonas y campos; invertido posicional, el índice

más común que guarda las posiciones de los términos en los documentos; k-grama, usado para

correcciones ortográ�cas y recuperación tolerante).

Para una mejor comprensión, describamos los pasos que se siguen en el proceso de indizado:

1. El primer paso consiste en obtener una colección de documentos, donde se asume que


estos están escritos correctamente, es decir, sin faltas de ortografía.

2. Cada documento de esta colección ingresa al analizador gramatical, donde se determina

el idioma en el que está escrito y su codi�cación4.

3. Una vez determinado el idioma del documento, este pasa por un procesamiento lingüístico

cuyo éxito depende fuertemente del idioma (ahí la importancia del paso anterior). Donde

se tokeniza5 el texto.

4. Esta lista de tokens6 pasa por un proceso de normalizado (stemming o lematización, vea

el apartado sobre normalización), con el �n reducir el tamaño del indice y mejorar la

proximidad de las búsquedas.

5. Se indiza el grupo de tokens de todos los documentos, de forma ordenada comúnmente

por docID7, por los diferentes indizadores.

6. Para mejorar el tiempo de cómputo en consulta y el espacio que ocupa el indice, este

suele ser comprimido.

El proceso de búsqueda inicia con una consulta que pasa por un analizador gramatical para

consultas (el mismo que no elimina los operadores de búsqueda, como lo haría un tokenizador

normal) del cual se obtiene los tokens de la consulta que son enviados uno para búsqueda en

los índices y otro al corrector ortográ�co y posteriormente a los índices. Se obtienen dos grupos

de resultados, uno correspondiente a la consulta original y otro correspondiente a la consulta

corregida por el corrector ortográ�co, la unión de estas da como resultado un conjunto de

documentos que corresponden con la consulta. Este conjunto pasa por algoritmos de puntuación

y clasi�cación para posteriormente ser mostrados al usuario (ordenados según su puntuación)

como una página de resultados.

Para �nalizar, describamos los pasos que se siguen en el proceso de consulta:

1. Se inicia con una consulta: de texto libre, booleana, por frase exacta, con comodines de

búsqueda, etc.

2. La consulta pasa por un analizador gramatical, parecido pero no igual al utilizado en el

proceso de indizado. Obteniendo una lista de tokens.

4La codi�cación depende del idioma en el que fue escrito, por ejemplo en Bolivia utilizamos la codi�cación

Latin-1 de la ISO-8859-15Proceso de tokenizado (partir un texto en tokens), usualmente eliminando marcas gramaticales que solo

sirven para dar enriquecimiento al texto.6Es una instancia de una secuencia de caracteres en algún documento que está agrupado a su vez con una útil

unidad semántica, referido comúnmente como término o palabra, en el apartado sobre tokenizacion aclaramos

más la idea.7Identi�cador de documento


3. Con esta lista de tokens se realiza la búsqueda sobre los indices que correspondan, y

además se pasa una copia de la lista de tokens al corrector ortográ�co con cuyo resultado

se realiza otra búsqueda sobre los índices que correspondan. Esto se realiza de esta forma,

pues si la consulta presentase algún error ortográ�co no devolvería resultados y pasando

ambas listas nos aseguramos de obtener resultados deseados.

4. Se realiza la unión de estas dos listas de resultados y se procede a obtener la puntuación

de los documentos para su debida clasi�cación. Esta puntuación suele seguir algoritmos

basados en la cantidad de información relevante para esa consulta en un documento o la

probabilidad de que ese documento sea relevante para esa consulta.

5. Finalmente, se presenta los resultados al usuario de una forma amigable y comprensiva.

2.3. Modelos Clásicos

Existen varios modelos de RI y seguramente irán apareciendo más con el paso del tiempo,

justamente el motivo de este trabajo es el de proponer un modelo de RI para nuestro lenguaje

en especí�co. Cada modelo presenta ventajas e inconvenientes. Sin embargo, nosotros solo re-

visaremos los modelos clásicos pues no es nuestro objetivo presentar un modelo completamente

nuevo, sino tomar uno existente y agregarle herramientas de procesamiento lingüístico desarro-

lladas especí�camente para el castellano de tal forma que esto disminuya la distancia entre los

documentos requeridos por el usuario y los documentos que obtiene. Es por eso que se realiza

un análisis morfológico completo en el Capítulo 3, como no ocurre en otros trabajos.

Ahora presentamos una revisión a los modelos de recuperación de información clásicos, cuyo

resumen se obtuvo de (MANNING y cols., 2008) y (HERRERA, 2006).

2.3.1. Modelo Booleano

Es el primer modelo planteado para la recuperación de información en el cual nosotros

planteamos cualquier consulta en términos de una expresión Booleana, es decir, estos términos

están combinados con los operadores AND, OR y NOT. El modelo ve un documento como un

conjunto exacto de palabras clave (términos). A continuación introducimos sus componentes

principales.

Indización de Documentos

Se asocia un peso a cada término del índice de manera implícita: 0 si el termino no aparece

en el documento y 1 si aparece aunque sea solo una vez. Las búsquedas consisten en expresiones

de palabras claves conectadas con algún(os) operador(es) lógico(s). El grado de similitud entre


un documento y una consulta será también binario y un documento sera relevante cuando su

grado de similitud sea igual a 1, de lo contrario el documento no tendrá ninguna relevancia en

cuanto a la consulta.

En palabras más sencillas, un documento es relevante si un término o más de la consulta

está en ese documento. Y no es relevante en caso contrario. Como se puede observar este no

presenta ningún tipo de puntuación o clasi�cación de documentos.

Consulta en el Modelo Booleano

Como hemos comentado, las consultas en este modelo se compondrían de expresiones Boo-

leanas que comprenden el conjunto de términos T y los operadores Booleanos AND, OR y

NOT. Un ejemplo de este tipo de consultas seria:

(t1 AND t2) OR (NOT t3)

Cuando se ejecuta la consulta, se halla el conjunto de documentos resultante de la misma.

En este modelo, la operación es muy sencilla ya que no existe grado de relevancia.

La ventaja es que es un modelo muy simple, basado en el Álgebra de Boole, lo que le da un

marco teórico solido. Su principal desventaja es el criterio de recuperación binario tan tajante y

estricto, por lo que es más un sistema de recuperación de datos que de información.

Aun con tales desventajas el Modelo Booleano, sigue siendo el preferido de muchos sobre

todo de los profesionales en el área de bibliotecologia. Además, actualmente el modelo Booleano

extendido8 incorpora operadores adicionales tal como operadores de proximidad de términos.

Un operador de proximidad es un método de especi�cación en el que dos términos en una

consulta deben estar el uno cerca del otro dentro del documento, donde la proximidad puede ser

cuanti�cada por reducción del número permitido de intervenciones de palabras o por referencia

a unidades estructuradas tal como una oración o párrafo.

2.3.2. Modelo Espacio Vectorial

Salton fue el el primero en proponer los sistemas de RI basados en Espacio Vectorial a �nales

de los 60, dentro del marco del proyecto SMART. Partiendo de que se pueden representar

los documentos como vectores de términos, los documentos podrían situarse en un espacio

vectorial de n dimensiones, es decir, con tantas dimensiones como elementos tenga el vector.

Situado en ese espacio vectorial, cada documento cae entonces en un lugar determinado por sus

coordenadas, al igual que en un espacio de tres dimensiones cada objeto queda bien ubicado si

se especi�can sus tres coordenadas espaciales. Se crean así grupos de documentos que quedan

8Algunos autores consideran el modelo extendido booleano como un modelo sobre la lógica difusa, ese

enfoque no se considera en este trabajo.


próximos entre si a causa de las características de sus vectores. Estos grupos o clusters están

formados, en teoría, por documentos similares, es decir, por grupos de documentos que serian

relevantes para la misma clase de necesidades de información. En una base de datos documental

organizada de esta manera, resulta muy rápido calcular la relevancia de un documento a una

pregunta, y siendo muy rápida también la ordenación por relevancia, ya que, de forma natural

los documentos ya están agrupados por su grado de semejanza.

En la fase de la consulta, cuando se formula una pregunta, también se la deja caer en este

espacio vectorial y, así, aquellos documentos que queden más próximos a ella serán, en teoría,

los mas relevantes para la misma. La representación de los documentos y las consultas se realiza

mediante la asociación de un vector de pesos no binarios (un peso por cada término del indice).

Por ejemplo, di = (ti1, ti2, ti3, . . . , tin).

El hecho de que tanto los documentos como las consultas tengan la misma representación

dota al sistema de una gran potencialidad.

Indización de Documentos

Para indizar, lo más habitual seria trabajar con una función de evaluación normalizada donde

los vectores tengan los pesos reales, entre I = [0, 1]. La bondad de la indización utilizando la

frecuencia de la inversa del documento (idf) está en que pondera la importancia de los términos

en función de su aparición en el resto de los documentos además de su frecuencia de aparición

en el documento actual, como se menciona en el Capitulo 7.

Consulta en el Modelo Vectorial

Como hemos indicado, en este modelo tanto las consultas como los documentos tienen la

misma representación, es decir, vectores n-dimensionales, donde n es el número de términos

índice considerados. Cada una de las posiciones del vector contiene un peso, el cual indica

la importancia relativa del término concreto de la consulta o del documento. Este peso es

un número real positivo que puede estar o no normalizado. Cuando un usuario formula una

pregunta, la mayoría de los pesos de la misma serán 0, con lo que bastará con proporcionar los

términos con peso distinto de 0 para poder de�nirla. El sistema se encargara de representar la

consulta completa en forma de vector n-dimensional de modo automático.

Una de las diferencias que existen entre este modelo y el Booleano es que los términos

individuales considerados en la consulta no están conectados por ningún operador (ni conjunción,

ni disyunción, ni negación). En el modelo vectorial, la consulta se considera como un todo. La

ventaja del modelo vectorial es que permite hacer correspondencias parciales, es decir, ordena

los resultados por grado de relevancia. Su principal inconveniente es que no incorpora la noción

de correlación entre términos (problema de todos los modelos clásicos). Aunque este modelo se


creó hace cuatro décadas y se ha investigado mucho sobre el, no se ha extendido su uso en los

sistemas RI comerciales, donde sigue demandándose el modelo Booleano a pesar de todos sus

inconvenientes.

Evaluación en el Modelo Vectorial

El mecanismo de evaluación de los sistemas de modelo vectorial empareja la consulta Q

contra la representación (el vector) asociado a cada documento de la colección, di ∈ D, para

obtener el grado de relevancia del documento di con respecto a la consulta. El sistema de

recuperación vectorial toma un valor real que seria tanto mayor cuanto mas similares sean

documento y consulta.

Existen diferentes funciones para medir la similitud S entre documentos y consultas. Todas

ellas están basadas en considerar ambos como puntos en un espacio n-dimensional. Como

ejemplo, citaremos las siguientes:

Producto Escalar:

S(q, d) =n∑

j=1

dj · qj (2.1)

donde dj y qj son, respectivamente, los pesos asociados al término tj en la representación

del documento d y la consulta q.

Medida del coseno:

S(q, d) =

∑nj=1 dj · qj√∑nj=1 d

2j · q2

j

(2.2)

Índice de Dice:

S(q, d) =2 ·∑n

j=1 dj · qj∑nj=1(d

2j + q2

j )(2.3)

Índice de Jaccard:

S(q, d) =

∑nj=1 dj · qj∑n

j=1(d2j + q2

j − dj · qj)(2.4)

Distancia Euclidea:

S(d, q) = −√√√√ n∑

j=1

d2j − q2

j (2.5)

2.3.3. Modelo Probabilístico

El marco del modelo probabilístico está compuesto por conjuntos de variables, operaciones

con probabilidades y el teorema de Bayes.


Todos los modelos de recuperación probabilísticos están basados en el que hemos traducido

como el �Principio de la ordenación por probabilidad�, conocido originalmente como �the pro-

bability ranking principle�. Este principio, formulado por Robertson, asegura que el rendimiento

óptimo de la recuperación se consigue ordenando los documentos según sus probabilidades de

ser juzgados relevantes con respecto a una consulta, siendo estas probabilidades calculadas de

la forma más precisa posible a partir de la información disponible. Así, y atendiendo a este prin-

cipio, el objetivo primordial de cualquier modelo probabilístico, pasa por calcular p(R | q di).

Es decir, la probabilidad de relevancia que se tiene dado el documento y la consulta.

Son muchos los modelos probabilisticos, pero solo revisaremos uno. Si desea saber más se

le recomienda la lectura de (HERRERA, 2006), (MANNING y cols., 2008) y (RIJSBERGEN,

n.d.).

El modelo de recuperación con independencia binaria, en ingles �Binary Independence Re-

trieval (BIR)", que fue inicialmente planteado por Maron y Kuhns, continuado por Robertson

y Spark Jones y concluido por van Rijsbergen, una eminencia en el área.

En el, los documentos y las consultas se representan por un vector binario. Así, un documento

cualquiera tiene la siguiente forma:

dj = (t1, t2, . . . , tn) (2.6)

donde ti = 0 o 1 indica la ausencia o presencia del término i-esimo, respectivamente, y

n el número de términos de la colección. Existen dos eventos mutuamente excluyentes: w1,

que representa el hecho de que un documento sea relevante, y w2, que indica que no lo sea.

Este modelo asume que se conocen, o por lo menos se suponen, el conjunto de documentos

relevantes (R) y no relevantes (R̄) de una consulta dada.

El objetivo que se persigue es calcular p(w1|dj) y p(w2|dj), decir, la probabilidad de que el

documento dj sea relevante y no relevante, respectivamente, dada una consulta q y desarrollar

una función que ofrezca un valor de relevancia para así poder ordenar los documentos según

ella. En este caso, esa función tendrá la forma:

S(dj, q) =p(w1|dj)

p(w2|dj)(2.7)

Haciendo suposiciones de independencia entre términos y aplicando el teorema de Bayes, se

llega a:

S(dj, q) ∼n∑

i=1

log

(p(ti = 1|w1) · (1− p(ti = 1|w2))

p(ti = 1|w2) · (1− p(ti = 1|w1))

)ti + c (2.8)

donde:

c =n∑

i=1

log

(1− p(ti = 1|w1)

1− p(ti = 1|w2)

)(2.9)


siendo p(ti = 1|w1) la probabilidad de que un termino ti este presente en el conjunto de

documentos relevantes y p(ti = 1|w2) en los no relevantes. El logaritmo que multiplica el peso

binario ti en la expresión (2.8) se conoce como el peso de relevancia del término: el valor

que se le asigna a cada término cuando se esta llevando a cabo una indización probabilística,

expresando la capacidad de discriminación de este entre documentos relevantes y no relevantes.

Relevante No Relevante

Aparece nRi ni − nR

i ni

No Aparece |R| − nRi N − ni − |R|+ nR

i N − ni

|R| N − |R| N

Tabla 2.2: Distribución de la aparición de un término en los documentos relevantes y no rele-

vantes. Fuente: (HERRERA, 2006)

La Tabla 2.2 representa una tabla de contingencia para un termino de la colección y muestra

la distribución de apariciones o no del termino i-esimo en los documentos relevantes y no

relevantes para una consulta. Dado que R es el conjunto de documentos relevantes, y |R| sucardinal, N es el número total de documentos de la colección, ni es el número de documentos en

los que aparece ti y nRi es el número de veces que aparece el término en documentos relevantes,

las probabilidades p(ti = 1|w1) y p(ti = 1|w2) se estiman según las siguientes expresiones:

p(ti = 1|w1) =nR

i

|R|p(ti = 1|w2) =

N − nRi

N − |R|(2.10)

El uso del modelo probabilístico que se acaba de presentar es el siguiente: el usuario formula

una consulta al sistema y este, mediante la expresión (2.8), calcula un valor de relevancia para

cada documento, generando así una lista ordenada de documentos.

Cuando el usuario ha formulado una primera consulta, el sistema no tiene información para

poder estimar p(ti = 1|w1) y p(ti = 1|w2), según las expresiones (2.10), por lo que se deben

establecer estimaciones iniciales, a partir de la colección completa, que pueden ser:

p(ti = 1|w1) = 0.5 p(ti = 1|w2) =ni

N(2.11)

Croft y Harper ofrecen, varias estimaciones iniciales para cuando no hay información rele-

vante y los rendimientos alcanzados con cada una de ellas. Por otro lado, Spark Jones, establece

varias expresiones cuando la información de la que se dispone es muy poca para obtener las

tablas de contingencia de cada término.

A partir de la primera lista de documentos, el usuario emite sus juicios de relevancia con

respecto a los documentos que �guran en ella y el sistema genera la Tabla 2.2, donde se podrá


aplicar directamente las expresiones (2.11) y reiterar este proceso hasta que el usuario quede

satisfecho.

Existen otros modelos probabilísticos que surgieron como variación o mejora de este anterior.

Entre ellos podemos destacar el conocido como modelo de indización de independencia binaria,

que se desarrollo a partir del modelo de Maron y Kuhns.

Mientras el modelo de recuperación de independencia binaria trabaja con los documentos

de la colección y una consulta, este modelo trabaja con un conjunto de consultas y el peso de

cada término lo calcula con respecto a las consultas que usan ese termino.

Los problemas que presentan el Modelo Vector Espaciar y el Modelo Probabilístico, radica

en la elección de los mejores documentos. Pues tienen que realizar varias comparaciones (en

teoría, debería realizarse con toda la colección), antes de encontrar los documentos que tengan

mejor puntuación. Para resolver este problema se proponen soluciones como: el indice de los

mejores K inexactos, la lista de campeones, recorte de grupos, etc. (MANNING y cols., 2008).

2.4. Evaluación de Sistemas RI

Un sistema RI, además de cumplir con los requerimientos (normalmente regidos por la inge-

niería del software) de cualquier otro sistema de información. Debe someterse a una evaluación

más especi�ca diseñada especialmente para este tipo de sistemas.

La medida de efectividad de los sistemas RI, es la relevancia. En torno a esta se han de�nido

y planteado otras medidas, diferenciando su aplicación según el tipo de sistema a evaluar:

sistemas de recuperación de información que no utilizan ningún algoritmo de clasi�cación y

sistemas de recuperación de información que utilizan uno o más algoritmos de clasi�cación.

Según (MANNING y cols., 2008), para medir la efectividad de un sistema RI, necesitamos

una colección de prueba consistente de tres cosas:

1. Una colección de documentos.

2. Un grupo de prueba de necesidades de información, expresable como consultas.

3. Un conjunto de juicios relevantes, una valoración binaria entre relevante y no relevante

para cada par consulta-documento.

La evaluación estándar de sistemas RI gira sobre la noción de documento relevante y do-

cumento no relevante con respecto a las necesidades del usuario, luego un documento en la

colección de prueba es determinado como relevante o no relevante. A esta decisión se le llama la

base de oro sobre el juicio de relevancia. Además, cabe aclarar que un documento se considera


relevante si este llega a satisfacer las necesidades del usuario, no si este contiene por casualidad

todas las palabras de la consulta.

Existen muchas colecciones de prueba ya realizadas por diferentes institutos y organizaciones.

Lastimosamente, no existe ninguna colección especí�ca para nuestro idioma. Sin embargo,

contamos con la herramienta de evaluación trec_eval, desarrollada por NIST (Instituto Nacional

de Estándares y Tecnología) de los Estados Unidos. Que utilizaremos para evaluar nuestro

prototipo.

2.4.1. Evaluación de Sistemas RI sin clasi�cación

Aquí se consideran los resultados obtenidos por el sistema como subconjuntos de documentos

de la colección. Las medidas más frecuentes y básicas son: precisión y cobertura.

La Precisión (P) es la fracción de documentos recuperados que son relevantes:

Precision =#(items_relevantes_recuperados)

#items_recuperados= P (relevantes|recuperados) (2.12)

La Cobertura (R) es la fracción de documentos relevantes que son recuperados:

Cobertura =#(items_relevantes_recuperados)

#items_relevantes= P (recuperados|relevantes) (2.13)

Una de las ventajas de considerar la precisión y cobertura es que una es más importante

que la otra en muchas circunstancias. Un usuario común de un buscador sobre la web, quiere

encontrar el resultado en la primera página (alta precisión) pero no tiene interés en revisar todos

los resultados. Un profesional buscador o investigador está interesado en buscar todo cuanto se

puede cubrir con la cobertura del sistema.

2.4.2. Evaluación de Sistemas RI con clasi�cación

La precisión y cobertura son medidas basadas en conjuntos no ordenados de documentos.

Si hablamos de evaluación de sistemas RI con puntuación, debemos considerar el orden de los

resultados ofrecidos por el sistema. En este contexto los conjuntos de documentos recuperados

son determinados por los mejores k documentos recuperados.

Las medidas más importantes en este contexto son: el termino medio de precisión (MAP),

precisión en k y la precisión R.

El término medio de precisión (MAP), es la media del valor de precisión obtenido para el

conjunto de los mejores k documentos existentes después de que cada documento relevante es

recuperado, y este valor se promedia sobre la necesidad de información.


Precisión en k, es la medida de precisión en constantes de niveles bajos de resultados recu-

perados. Utilizada en evaluación de buscadores web, pues considera cuántos buenos resultados

están en la primera pagina o en las tres primeras paginas (por decir algo).

Precisión R, cuenta con un conjunto de documentos relevantes conocido como Rel, a partir

del cual calculamos la precisión de los mejores documentos Rel retornados. El conjunto Rel

es formado por juicios de relevancia para los grupos de mejores k resultados de un sistema

particular en un conjunto de experimentos.

Por otro lado, ademas de los criterios anteriores que se centran principalmente en el punto

de vista del diseñador del sistema, se debe considerar también el punto de vista del usuario ya

que los criterios de evaluación del diseñador y del usuario no tienen por que coincidir. Los seis

criterios siguientes han sido identi�cados como los más importantes en lo que respecta a las

características que un sistema RI debe ofrecer al usuario:

1. La exhaustividad, o habilidad del sistema para presentar todos los items relevantes.

2. La precisión, o habilidad del sistema para presentar solamente items relevantes.

3. El esfuerzo, intelectual o físico, requerido por el usuario en la formulación de las consultas,

en el manejo de la búsqueda y en el proceso de examinar los resultados.

4. El intervalo de tiempo transcurrido entre que el sistema recibe la consulta del usuario y

presenta las respuestas.

5. La forma de presentación de los resultados de la búsqueda, la cual in�uye en la habilidad

del usuario para utilizar la información recuperada.

6. El alcance o cobertura de la colección documental, o la proporción en la que están incluidos

en la recuperación todos los items relevantes del sistema ya conocidos por el usuario.

Una vez repasados los distintos factores que se pueden considerar en el proceso de evaluación

de un SRI, es importante destacar que existen muchas más medidas de diferentes tipos. Una

revisión muy buena puede encontrarse en el trabajo de (MENDEZ, 2002), donde incluso se

propone un nuevo modelo de evaluación. Trabajos como (RIJSBERGEN, n.d.), (BAEZA-YATES

y RIBEIRO-NETO, 1999) y (MANNING y cols., 2008) tratan este tema en capítulos completos.

Nosotros, regresaremos a este tema en el Capítulo 8. Donde realizamos la evaluación de

nuestro prototipo y describimos las medidas a utilizar de manera más completa.

Capítulo 3

Tratamiento del Lenguaje Natural y

Análisis Morfológico

El tratamiento de lenguaje natural utiliza técnicas y formalismos de la Lingüística Compu-

tacional y la Inteligencia Arti�cial para la construcción de sistemas computacionales para la

comprensión y la generación de textos en lenguaje natural. Ademas, tiene a�nidad con la Lin-

güística (quizá, la mas formalizada de las Ciencias Humanísticas) ya que el lenguaje presenta

unas características altamente estructuradas.

Como consecuencia, cualquier aplicación seria del Lenguaje Natural descansa en teorías

o modelos lingüísticos previamente establecidos. En nuestro caso, solo trabajaremos con las

formas mínimas de los elementos lingüísticos: �las palabras� , entonces es necesario realizar un

análisis morfológico completo. Aunque siempre desde el punto de vista de la recuperación de

información.

Comenzamos el capitulo con una revisión a la historia del tratamiento del lenguaje natural,

seguimos con una revisión a la morfología del castellano y terminamos con la descripción de las

herramientas de tratamiento de lenguaje natural que son utilizadas en el área de recuperación

de información.

3.1. Breve historia del tratamiento del lenguaje natural

(TLN)

En (L. J. L. GARCIA, 2002) y (RODRIGUEZ, 2007), encontramos de manera detallada la

historia del TLN, acá solo mostramos un pequeño resumen.

La segunda guerra mundial causó grandes adelantos en diversas áreas, una de estas fue

el tratamiento del lenguaje natural utilizado para realizar criptoanálisis antes de 1945. Cuando

terminó la guerra los investigadores pudieron dedicarse a otros tipos de aplicaciones, ampliándose

24

CAPÍTULO 3. TRATAMIENTO DEL LENGUAJE NATURAL Y ANÁLISIS MORFOLÓGICO25

la gama de estudios sobre procesamiento del lenguaje natural.

En 1946, Weaver y Booth presentaron el primer sistema de traducción automática, seguido

por el �Georgetown Automatic Translator� en 1961 por el Centro de Estudios para la Traducción

Automática en Grénoble. Como los sistemas automáticos de traducción no eran capaces de

producir resultados �uidos, el documento debería ser editado a �n de convertirlo en comprensible

para la máquina y posteriormente la traducción debía ser también editada. La introducción de la

pre-edición y la post-edición de los textos traducidos por la máquina introdujo la idea de que en

tareas que eran todavía muy difíciles para que el ordenador las realizara por sí mismo, éste podía

usarse como una herramienta para asistir a las personas. Bar-Hillel concluyó que la Traducción

Completamente Automática de Alta Calidad (Fully-Automatic High-Quality Translation) era

imposible sin conocimiento. Revisó los proyectos del momento y concluyó que los métodos

usados � que en esencia relacionaban parejas de palabras � estaban destinados a fallar. La

razón era simple: los traductores humanos añaden su capacidad cognitiva a las estructuras del

lenguaje en las que están trabajando.

A mitad de los años 60 la inversión pública estadounidense para el desarrollo de la tra-

ducción automática alcanzaba unos 20 millones de dólares anuales. El Comité Asesor para el

Procesamiento Automático del Lenguaje (ALPAC: Automatic Language Processing Advisory

Committee) realizó un informe sobre los resultados de la inversión y concluyó que �no existe

una máquina de traducción de textos cientí�cos y no se espera que aparezca ninguna a corto

plazo�.

Algunos sugieren que el Tratamiento del Lenguaje Natural desapareció virtualmente de

escena después del informe ALPAC; la evidencia contradice este punto de vista. Es cierto que se

realizaron menos trabajos en Tratamiento del Lenguaje Natural; sin embargo, hubo importantes

desarrollos y sistemas en los 15 años siguientes � algunos de los cuales siguen teniendo in�uencia

hoy en día. Los temas sobre los que se ha trabajado son:

REDES DE TRANSICIÓN AUMENTADAS. Es un método de representación del

conocimiento con el que se pueden representar potentes gramáticas para procesar la sinta-

xis. Sería un error verlo sólo como un procesador sintáctico, pues es más que un analizador

de la estructura del lenguaje: proporciona un formalismo para expresar el conocimiento

sobre el dominio de la aplicación.

GRAMÁTICA DE CASOS. Lenguajes como el Español expresan la relación entre

verbos y nombres por medio del uso de preposiciones de encadenamiento. Considérese la

siguiente sentencia:

Juan compró un billete para María en la estación de autobuses

Por la posición de las palabras Juan y billete se sabe que Juan es el agente instigador de la

acción y que billete es el objeto de la misma. María es la bene�ciaria de la acción debido


al uso de la preposición para antes del sustantivo. La preposición en indica que la acción

se realiza en la estación de autobuses. En otros lenguajes que no usan preposiciones, la

información la lleva la palabra o la posición que ocupa.

REPRESENTACIONES SEMÁNTICAS. Se han desarrollado signi�cativos avances

en el procesamiento semántico. Schank y sus colaboradores introdujeron la noción de

Dependencia Conceptual: un método para expresar el lenguaje en términos de primitivas

semánticas � estos sistemas se escribían sin incluir procesamiento sintáctico. Quillian

introduce la idea de red semántica que está constituida por nodos1 y enlaces2; éstas

son usadas para la representación del conocimiento en muchos sistemas. Willian Woods

empleó la idea de semántica procedimental como una representación intermedia entre el

sistema del procesamiento del lenguaje y un sistema de bases de datos.

Los sistemas más destacados son:

SHRDLU. El sistema SHRDLU de Terry Winograd simulaba un robot que manipulaba

bloques sobre una mesa. Este podía manipular instrucciones como Pick up the red pyramid

y responder a cuestiones como What does the blue box contain? La importancia de

SHRDLU radica en que muestra que la sintaxis, la semántica y el razonamiento sobre el

mundo pueden ser combinados para producir un sistema que entienda el lenguaje natural.

Se trata de un sistema muy limitado que sólo es capaz de manejar un pequeño número

de sentencias y su dominio está limitado al mundo de los bloques. El trabajar con un

dominio muy pequeño hace que el sistema sea muy potente; sin embargo, al ampliar el

dominio, la efectividad del sistema decrece.

LUNAR. Es un sistema de interfaz con bases de datos el cual trabaja con redes de

transición aumentadas y la semántica procedimental de Woods. Su nombre proviene de

una base de datos usada para el almacenamiento de información sobre rocas lunares.

La demostración informal del sistema se realizó en la Segunda Conferencia Anual sobre

Ciencia Lunar en 1971.

LIFER/LADDER. Es uno de los sistemas de Lingüística Computacional más imprevi-

sibles. Fue diseñado como una interfaz en lenguaje natural con una base de datos sobre

barcos de la marina estadounidense. Usa una gramática orientada a la semántica: emplea

etiquetas como BARCO o ATRIBUTO más que las sintácticas como nombre o verbo.

Ello implica que se limita a trabajar en un dominio restringido como lo hace el sistema

SHRDLU.1Un nodo es una estructura que tiene asociada una correspondencia con un objeto, evento, actor, entidad o

cualidad del ámbito de representación.2Un enlace es una relación entre nodos.


A esta lista, se puede adicionar los sistemas precursores que utilizaban métodos rudimentarios

como los analizadores de pattern matching, utilizados en sistemas como Eliza, Sir, Student

o Baseball. En los últimos años, también se han realizado algunos de estos para el Español

como Dr. Abuse, que puede entablar una conversación con una persona.

En lo que respecta a las tecnologías de la lengua y el Español, los primeros trabajos de análisis

computacionales del Español fueron realizados por un equipo de informáticos y lingüistas entre

los que se encuentran Francisco Marcos Marín y Manuel Ariza, en el Centro de Cálculo de la

Universidad Complutense en los años 71 y 72.

Siguiendo el camino recorrido por la lingüística computacional en español, debe mencionarse

el Programa de Tecnología Lingüística de la Sociedad Estatal Quinto Centenario: se desarrolló

entre los años 1990 y 1992 y es donde se ha asignado la mayor cantidad de recursos sobre

lingüística computacional en el mundo hispano.

Presentamos un listado de las diferentes asociaciones concernientes al tema en España.

Asociación de Historia de la Lengua Española

Sociedad Española de Lingüística

Asociación Española de Lingüística Aplicada

Sociedad Española para el Procesamiento del Lenguaje Natural (SEPLN). Esta esta mas

directamente relacionada con la Lingüística Computacional y celebra todos los años un

congreso donde se presentan los últimos avances sobre el tema.

En Bolivia por los anos 1980 se publico el manuscrito Problemática Lógico-Lingüística de

la Comunicación Social con el Pueblo Aymara por Ivan Guzman de Rojas, donde se presenta la

lógica trivalente presente en la sintaxis del idioma Aymara. Como resultado de estos estudios el

año 2006 en Ginebra se presento el traductor multilingue �Atamiri�.

3.2. Características Morfológicas del Castellano

En nuestro campo, la recuperación de información tomamos palabras normalizadas común-

mente llamadas términos, que no son más que palabras que sufrieron una normalizacion median-

te un steemer o lematizador. De ahí que es importante el análisis morfológico de las palabras

en castellano. Ya que un steemer o lematizador se diseña para un lenguaje en especí�co.

El problema principal que presenta el morfema como elemento básico de la morfología es

que el castellano contiene palabras que solo pueden segmentarse arbitrariamente, a pesar de

que estas palabras pertenecen a las mismas clases gramaticales a las que pertenecen otras que


si son segmentables en morfemas; ni siquiera haciendo la distinción de los estructuralistas entre

morfema y morfo se resuelve completamente el problema en las lenguas �exivas.

Se reconoce que existen morfemas que carecen de signi�cado autónomo fuera de las palabras

en que aparecen y la unidad mínima con signi�cado propio pasa del morfema a la palabra.

Es decir, existen morfemas sin signi�cado constante y palabras que no pueden dividirse en

morfemas.

Las características principales de las lenguas �exivas son (L. J. L. GARCIA, 2002):

1. Di�cultad para segmentar neta y coherentemente las palabras en morfos.

2. Falta de correspondencia entre los segmentos de palabra y los morfemas � las raíces y las

terminaciones no son siempre las mismas y las terminaciones son multifuncionales.

3. Las palabras llevan terminaciones con información sintáctica y semántica.

4. La formación de palabras admite movilidad en sus elementos.

5. El orden de las palabras en la oración es relativamente libre.

En (L. J. L. GARCIA, 2002), podemos encontrar una revisión completa de las reglas morfo-

lógicas, que toma en cuenta las diferentes categorías gramaticales y los accidentes o �exiones

que pueden sufrir cada una de ellas. Considera: sustantivos, adjetivos, adverbios, verbos y otras

expresiones que carecen de �exión � preposiciones, conjunciones, interjecciones, palabras de

otros idiomas y algunas locuciones. Es un trabajo muy completo, y se debería consultar tras

cualquier duda. En (ANDIA, 2006), podemos encontrar una revisión por clases de palabras

según la Gramática Estructural. Se consideran seis clases: sustantivo, verbo, adverbio, adje-

tivo, preposición y conjunción. A continuación describimos los puntos que consideramos más

importantes para nuestro trabajo, desde el punto de vista morfológico.

3.2.1. El Sustantivo

Categoría gramatical compuesta por uno o mas lexemas que admite morfemas de número,

indicadores de género, determinantes y a�jos.

3.2.2. El Adjetivo

Categoría gramatical compuesta por uno o mas lexemas que admite morfemas constitutivos

de número, de género y morfemas facultativos o de grado, llamados también a�jos.


3.2.3. El Pronombre

Unidad lingüística que puede cumplir las funciones de sustantivo, adjetivo determinativo y

eventualmente las funciones del adverbio.

El pronombre personal átono enclítico

Hacen referencia al actor o actores del discurso en la oración gramatical; pueden ser: tónicos

o átonos. El pronombre personal átono va asociado de un sintagma verbal, por esta razón se

denomina también incremento verbal. Se dicen átonos por que no pueden aparecer por si solos,

no son autónomos, son absolutamente dependientes de una unidad verbal. Pueden ubicarse en

dos posiciones: proclíticos, cuando se anteponen; y enclíticos, cuando se posponen al verbo:

amandote.

1ra. Persona: me, nos

2da. Persona: te, os

3ra. Persona: lo, la, los, las, se

3.2.4. El Verbo

Expresa la acción de un fenómeno, el proceso de realización de una actividad. Puede adquirir

dos formas una forma apredicada y otra forma predicada. Las formas apredicadas son:

In�nitivo: ar, er, ir

Gerundio: ando, endo, yendo

Participio: do, da, to, ta, cho, cha, so, sa

Está compuesto por un lexema, que aporta valor conceptual o semántico, y diversos morfe-

mas, mediante los cuales expresa tiempo, modo, voz, aspecto, número y persona; estos suelen

llamarse accidentes gramaticales del verbo y constituyen las formas predicadas del verbo.

Figura 3.1: Morfología del verbo amábamos. Fuente: (L. J. L. GARCIA, 2002)


Dado que no todas las formas verbales tienen todos los segmentos morfológicos iguales,

es conveniente señalar que un verbo predicado, consta de dos partes como se muestra en la

Figura 3.1: una raíz léxica y una terminación. Absolutamente todos los verbos pueden predicarse,

incluyendo aquellos verbos defectivos e impersonales que solo se predican en tercera persona

singular.

Figura 3.2: Lista de terminaciones. Fuente: (L. J. L. GARCIA, 2002)

La verbalizacion es la obtención de verbos a partir de nombres y suele utilizar las siguientes

terminaciones: achar, ajar, ar, azar, ear, ecer, edar, eguar, ejar, i�car, iguar, iquear,


iscar, itar, izar, orrar, orriar, otear, ucar, ujar, uscar, uzar. La Figura 3.2 muestra una lista

de terminaciones según su aplicación a formas verbales y no verbales.

3.3. Abreviaturas

Según (F. GARCIA y GROSS, 1987), es la representación de una palabra por medio de

una o varias de sus letras. No existe regla absoluta para la formación de abreviaturas. Aunque

en general se adoptan las primeras letras de la palabra, terminando de preferencia en una

consonante, y se cierra la abreviatura con un punto. A veces se agregan, en caracteres mas

pequeños y en alto, la o las ultimas letras de la voz; otras se unen las primeras y las ultimas

letras de la voz (pral. - principal) o algunas de sus consonantes mas notables (Lbs. - libras).

Aunque las reglas que las rigen tienen abundantes excepciones lo que hace que, las posibi-

lidades que se dan en cuanto a su forma, sean muchas y variadas. Esto lo comprueba el hecho

de que cada texto que las usa, las explique, generalmente en las primeras páginas. Cualquier

palabra puede ser abreviada, esto da paso a que se presenten abreviaturas para cada área, por

ejemplo, la informática.

Sin embargo, podemos tomar las siguientes consideraciones presentadas en (MUNDOLENGUAJE,

2007):

1. Se escriben, indistintamente, con mayúscula o minúscula. En general, se tien-

de a pensar que la letra correcta es la mayúscula. Sin embargo, constantemente, nos

encontramos con abreviaturas en minúscula, como: etc.

Ministro - Min. páginas - pag.

2. Van seguidas de punto. El punto no puede omitirse, aunque, a continuación aparezca

cualquier otro signo ortográ�co.

Observaron las esculturas, etc., pero eligieron las tallas de madera

3. Llevan tilde, si la vocal que lo tenia en la palabra aparece en ellas. Si entre las

silabas que se eligieron para la abreviatura �gura una vocal tildada, ese tilde se conservará.

médico - méd.

4. Se pluralizan de dos maneras diferentes.

Si tienen más de una letra, se agregara una `s' al �nal

Páginas - Págs.

Si tienen solo una letra, esta se duplica


Estado Unido - E.U.

Estados Unidos - EE.UU.

5. Se desarrollan en la lectura. A diferencia de las siglas, que se leen como tales, las

abreviaturas, en la lectura, desaparecen y ocupan el lugar de la palabra que les dio origen.

Tal vez, estas cinco reglas sean las únicas que se aplican a la mayoría de las abreviaturas.

Sin embargo, hay excepciones, en cuanto a la utilización del punto que suelen llevar. No se usa

punto en las abreviaturas de:

1. Los símbolos de los elementos químicos: H2O (agua)

2. Las unidades de medida: kg (kilogramo)

3. Los puntos cardinales: N (Norte)

En la pagina http://www.msmorell.com/htm/abreviaturas.htm, encontramos un listado de

las abreviaturas empleadas en el diccionario del verbo español, hispanoamericano y dialectal.

3.3.1. Procesamiento en Lenguaje Natural

En cuanto a su procesamiento, comúnmente se suele utilizar una lista de las abreviaciones

más comunes para el lenguaje en cuestión, para separarlas de forma adecuada como un solo

token.

Esto es necesario pues a menudo nos encontramos con abreviaciones como: a.m. - am. o

U.M.S.A. - UMSA.

Si el usuario ingresa la consulta: �U.M.S.A.� , el querrá obtener documentos que contengan

UMSA, umsa, y u.m.s.a., así es necesario realizar un preprocesamiento después de haber iden-

ti�cado la abreviación. Sin embargo, suponga que el usuario ingresa la consulta: �umsa�, este

escenario es mucho más desalentador pues, no sabremos si se trata de una palabra o de una

abreviación. Y no obtendremos documentos con u.m.s.a., por ejemplo, que pueden ser deseados.

3.4. Nombres Propios

Según (F. GARCIA y GROSS, 1987) el nombre propio es el que se da a una persona, animal

o cosa, para distinguirlo de los demás. El nombre propio siempre lleva mayúscula y no tiene

ortografía.

http://www.msmorell.com/htm/abreviaturas.htm


3.4.1. Procesamiento en Lenguaje Natural

Comúnmente nos topamos con nombres propios, en los documentos y en las consultas. Los

cuales no podemos tratar como tokens comunes, pues esto podría ocasionar la recuperación de

documentos no deseados. Imagine la siguiente consulta: �Universidad Mayor de San Andres�,

si solo separamos los términos en tokens tendríamos [universidad, mayor, de, san, andres],

donde esta claro que podríamos obtener documentos con la frase: ...andres es mayor y va

a la universidad..., entre otros. Así, si separamos los tokens respetando los nombres propios

tendríamos [universidad mayor de san andres] o en el peor de los casos [universidad, mayor, de,

san andres], que es aceptable.

El mayor problema en la identi�cación de nombres propios, es que existen muchos de tal

forma que es ine�ciente en tiempo de cómputo utilizar una lista de ellos (como un diccionario),

sin embargo, esto se puede aplicar con buenos resultados a colecciones de documentos que estén

delimitadas por un contexto dado. Así, la identi�cación de nombres propios se debe contemplar

en la tokenizacion o como un paso antes de esta.

3.5. Tokenizacion

Dada una secuencia de caracteres y una parte del documento de�nida, tokenizacion es la

tarea de trozar esta en piezas, llamadas tokens, quizá al mismo tiempo ignorar ciertos caracteres,

tales como signos de puntuación, etc.

Estos tokens son a menudo referidos como términos o palabras (sin embargo note que hay

muchos casos especiales por lo que en este trabajo nunca se habla de palabras sino de términos),

pero es importante distinguir entre tipo y token. Un token es una instancia de una secuencia

de caracteres en algún documento en particular que está agrupado a la vez con una útil unidad

semántica para procesamiento. Un tipo es la clase de todos los tokens contenidos en la misma

secuencia de caracteres. Un término es un tipo que está incluido en el diccionario del sistema

de recuperación de información (es decir, el que es indexado, una palabra normalizada).

3.6. Tratamiento Stop Words

A veces tenemos muchas palabras comunes las que al parecer tienen poco valor al ayudarnos

a elegir documentos que concuerden con las necesidades del usuario, estas son excluidas del

vocabulario completamente. Estas palabras son llamadas stop words.

Para determinar una stop list (lista de stop words) hay que clasi�car los términos por

frecuencia de recolección (el número total de veces que cada término aparece en la colección

de documentos), entonces tomamos los términos más frecuentes (aunque a menudo se realiza


un �ltrado manual por el contenido semántico relativo al área del documento a ser indexado)

como una stop list, los miembros de la cual son entonces descartados durante el indexado.

En la Tabla 3.1 presentamos una stop list, obtenida de la colección de documentos �Legis-

lación Boliviana - Compendio de leyes de 1825 a 2007� , consideramos términos con frecuencia

mayor o igual a 30000:

término frecuencia

de 502131

la 254111

el 139717

y 129605

en 103800

del 101237

los 99296

a 87719

que 70833

por 70517

se 57990

las 56354

para 54734

ley 53771

nacional 46490

al 39702

artículo 35117

congreso 30860

con 30115

Tabla 3.1: Stop Words, tomadas de la colección �Legislación Boliviana - Compendio de leyes de

1825 a 2007�. Fuente: Creación personal.

Podemos ver que algunos términos como: artículo, congreso y nacional se consideran stop

words; algo completamente falso. La solución es incrementar el umbral de 30000 a 50000 por

decir algo. Aquí es claro que el umbral crece de acuerdo al número de documentos de la

colección.

Si utilizamos una stop list grande, podemos reducir el tamaño del índice. Sin embargo,

perdemos precisión en las consultas de frase exacta. Suponga que alguien realiza la consulta:

�Presidente de la República de Bolivia� , entonces como las stop words no están en el índice

tendríamos que buscar Presidente AND República AND Bolivia (claro utilizando el modelo


booleano). Que esta claro que no buscaría los que esperamos.

3.7. Normalización de Tokens

Una vez que hemos obtenido los tokens de nuestros documentos, el caso sencillo se da

cuando los tokens en la consulta son iguales a los tokens en los documentos. Sin embargo,

existen muchos cuando dos secuencias de caracteres no son del todo iguales, pero Ud. está

interesado en las equivalencias que ocurren.

La normalización de tokens es el proceso de canonalizacion de tokens de tal forma que las

correspondencias ocurran a pesar de diferencias super�ciales en la secuencia de caracteres de

los tokens. La mayoría de los métodos para realizar la normalización es la creación implícita de

clases de equivalencia, a las cuales comúnmente se les pone el nombre como un mismo miembro

del conjunto.

Por ejemplo, considere los tokens: subconjunto y sub-conjunto, podríamos crear una clase

de equivalencia llamada subconjunto, cuyos miembros serian los dos anteriores. Esto bene�cia a

una consulta pues, imagine que se ingresa la consulta: sub-conjunto, entonces obtendríamos do-

cumentos que también contendrían el token subconjunto. Esto se logra utilizando, obviamente,

el mismo tokenizador en los documentos y las consultas.

Una alternativa en la creación de clases de equivalencia, es la de mantener relaciones entre

tokens no normalizados, tal como una lista de sinónimos.

Otras formas de normalización son:

Acentuación y Marcas Gramaticales: Podemos quitar los acentos y las marcas gramati-

cales, aunque esto puede ocasionar un cambio dramático en el signi�cado de la palabra.

Por ejemplo, papa y papá. No obstante, la pregunta importante es ¾como el usuario

escribiría sus consultas para esta palabra? En muchos casos, el usuario ingresa sus con-

sultas sin marcas gramaticales, por razones de prisa, pereza o limitación del software,

o por habito, o por causa del dispositivo de entrada (teclado). Así, una solución a este

problema consiste en igualar la palabra con todas las palabras que se moldeen sin marcas

gramaticales (buscar el término de la consulta, tal como esta y también buscar el término

sin marcas gramaticales).

Capitalización: Una estrategia común es la de convertir todas las letras del token en mi-

núsculas. Esto suele ser una buena idea, permitiendo que el índice sea mas pequeño y

obtener documentos que contengan el token en mayúscula, minúscula y capitalizado. Por

lo común, convertir todo a minúsculas es una solución practica.


3.7.1. Lematización

En (BASSI, n.d.), se de�ne como el proceso mediante el cual las palabras de un texto que

pertenecen a un mismo paradigma �exivo o derivativo son llevadas a una forma normal que

representa a toda la clase. Esta forma normal, llamada lema, es típicamente la palabra utilizada

como entrada en los diccionarios de la lengua.

Una de sus variaciones consiste en encontrar el lexema de las palabras analizadas, es de-

cir separar las palabras analizadas en un núcleo conceptual (lexema) y agregados morfológicos

(morfemas). Para la mayoría de las lenguas europeas, esto se traduce por encontrar una com-

binación raíz + su�jo en que la raíz corresponde al lexema buscado y el su�jo a un morfema

o combinación de morfemas. El proceso de eliminar su�jos morfológicos se conoce como stem-

ming, algunos lo consideran una variante de la lematización pero en este trabajo le mostramos

la diferencia sutil entre ambos.

Tiene importancia en la búsqueda pues pone en mani�esto relaciones entre palabras, que

nos permite agruparlas en clases, mejorando la recuperación aunque puede ser a expensas de

la precisión (un factor importante en RI) cuando diferentes conjugaciones morfológicas de una

misma raíz están asociadas a conceptos distintos.

3.7.2. Stemming

El stemming se ha planteado de diversas maneras y comienza a estudiarse en los años 60,

siendo los más difundidos el stemmer de Lovins (Lovins 1968), el stemmer de Paice (Paice 1990)

y el stemmer de Porter (Porter 1980). Aunque la mayoría de los trabajos están orientados al

tratamiento de textos en inglés, contamos también con algoritmos para lenguas especi�cas la

mayoría de los cuales son presentados en las conferencias de TREC (Text Retrieval Conferen-

ce), irónicamente estos algoritmos son presentados por personas que no tienen el idioma en

cuestión como como su lengua materna, esto hace que no sean muy efectivos. En general, estas

aplicaciones consistieron en la utilización de los mismos algoritmos que para el inglés, aunque

con su�jos y reglas para el idioma en cuestión.

En los últimos años se han realizado varios lematizadores y stemmers para el español, como

COES, MACO, FLANOM, Porter Snowball, TreeTagger.

Capítulo 4

Metodologías y Herramientas de

Desarrollo

En este capítulo revisamos las metodologías y herramientas de desarrollo, que utilizare-

mos para la construcción de nuestro prototipo. Iniciamos el capítulo describiendo el proceso

de ingeniería de software que seguiremos, presentamos la herramienta de modelado UML, la

arquitectura MVC y �nalizamos presentando las herramientas de desarrollo que utilizaremos,

tales como: lenguajes de programación y frameworks.

4.1. Modelo incremental

Tal como se describe en (PRESSMAN, 2007). El modelo incremental combina elementos

del modelo en cascada (que sigue un enfoque secuencial, que inicia con la especi�cación de

requerimientos del cliente y continua con la planeación, el modelado, la construcción y el

despliegue para culminar en el soporte del hardware terminado) aplicado en forma iterativa.

El modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el

tiempo en el calendario. Cada secuencia lineal produce �incrementos� del software. Los primeros

incrementos son versiones �incompletas� del producto �nal, pero proporcionan al usuario la

funcionalidad que necesita y una plataforma para evaluarlo.

4.2. Proceso de Ingeniería Web

Se seguirán los siguientes actividades empleando un �ujo de proceso incremental como se

muestra en la Figura 4.1, propuestas en (PRESSMAN, 2007):

Comunicación con el cliente. Se caracteriza por dos grandes tareas: análisis del negocio y

la formulación. El análisis de negocio de�ne el contexto empresarial-organizativo para

cambios en el ambiente o los requisitos del negocio, y se de�ne la integración entre la

37

CAPÍTULO 4. METODOLOGÍAS Y HERRAMIENTAS DE DESARROLLO 38

aplicación web y otras aplicaciones de negocios, bases de datos y funciones. La formula-

ción es una actividad de recopilación de requisitos que involucra a todos los participantes.

El intento es describir el problema que la aplicación web habrá de resolver (junto con los

requisitos básicos para la misma) con el aprovechamiento de la mejor información dispo-

nible. Ademas, se intenta identi�car áreas de incertidumbre y donde ocurrirán cambios

potenciales.

Planeación. Se crea el plan del proyecto para el incremento de la aplicación web. Consistente

de una de�nición de tareas y un calendario de plazos respecto al periodo proyectado para

el desarrollo del incremento de la aplicación web.

Modelado. Las labores convencionales de análisis y diseño de ingeniería del software se adap-

tan al desarrollo de la aplicación web, se mezclan y luego se funden en la actividad de

modelado. El intento es desarrollar análisis �rápidos� y modelos de diseño que de�nan

requisitos y al mismo tiempo representen una aplicación web que los satisfará.

Construcción. Las herramientas y la tecnología de aplicaciones web se aplican para construir

la aplicación web que se ha modelado. Una vez que se construye el incremento, se dirige

una serie de pruebas rápidas para asegurar que se descubran los errores en el diseño (es

decir: contenido, arquitectura, interfase, navegación). Pruebas adicionales abordan otras

características de las aplicaciones web.

Despliegue. La aplicación web se con�gura para su ambiente operativo, se entrega a los

usuarios �nales y luego comienza un periodo de evaluación. La retroalimentacion acerca

de la evaluación se presenta al equipo y el incremento se modi�ca conforme se requiera.

4.3. Herramienta de modelado UML

El UML proporciona una cantidad impresionante de diagramas que pueden utilizarse para el

análisis y diseño del software y del sistema. Nosotros solo utilizaremos unas cuantas, de acuerdo

a nuestras necesidades. Las siguientes descripciones y resúmenes fueron obtenidos de los libros

(CONALLEN, 2002), (ALARCON, 2000) y (SCHMULLER, n.d.).

4.3.1. Casos de Uso

El caso de uso es una estructura que ayuda a los analistas a trabajar con los usuarios para

determinar la forma en que se usará un sistema, es decir, ayuda a obtener los requerimientos

desde el punto de vista del usuario. Con una colección de casos de uso se puede hacer el bosquejo

de un sistema en términos de lo que los usuarios intenten hacer con el.


Figura 4.1: El proceso de Ingeniería Web. Fuente: (PRESSMAN, 2007).

Elementos

Los elementos que pueden aparecer en un Diagrama de casos de uso son: actores, casos de

uso y relaciones entre casos de uso.

Actores, es una entidad externa al sistema que realiza algún tipo de interacción con el mismo.

Se representa mediante una �gura humana dibujada con palotes. Esta representación sirve

tanto para actores que son personas como para (otros sistemas, sensores, bases de datos,

etc.).

Caso de Uso, es una descripción de la secuencia de interacciones que se producen entre un

actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especi�ca.

Expresa una unidad coherente de funcionalidad y se representa mediante una elipse con

el nombre del caso de uso en su interior. El nombre debe re�ejar la tarea especi�ca que

el actor desea llevar a cabo usando el sistema.

Relaciones entre casos de uso, entre dos caso de uso puede haber las siguientes relaciones:

Inclusión: cuando un caso de uso utiliza a otro (se utiliza comúnmente para agrupar

pasos comunes en dos casos de uso). Su símbolo es una �echa hacia el caso de uso

que se incluye, con la etiqueta << include >>


Extensión: cuando un caso de uso es muy parecido a otro y varia solo en algunas

actividades, entonces se puede extender este caso de uso de otro existente. Su

símbolo es una �echa hacia el caso de uso original, con la etiqueta << extend >>.

Generalización: es una forma de herencia, donde el caso de uso secundario hereda

las acciones y signi�cado del primario, y ademas agrega sus propias acciones. Se

simboliza con una �echa sin rellenar hacia el caso de uso original.

Agrupamiento: es la tarea de organizar en un paquete los casos de uso que se relacionen.

El símbolo de un paquete es una carpeta tabular, los casos de uso agrupados aparecen

dentro de la carpeta.

4.3.2. Diagrama de Clases

Una clase sirve para capturar los atributos y acciones de un objeto abstracto. Una clase se

dibuja como un rectángulo dividido en tres áreas la superior contiene el nombre de la clase, la

del medio los atributos de la misma y la inferior los métodos (acciones) de la clase.

Figura 4.2: Ejemplo de la Clase lavadora. Fuente: (SCHMULLER, n.d.).

Un diagrama de clase, muestra un conjunto de clases, interfaces y colaboraciones, así como

sus relaciones. Estos diagramas son muy comunes en el modelado de sistemas orientados a

objetos y cubren las vista de diseño estática o la vista de procesos estática (si incluyen clases

activas).

Las relaciones posibles entre clases son:

Asociaciones, cuando las clases se conectan entre si de forma conceptual.

Multiplicidad, cantidad de objetos de una clase que se relacionan con un objeto de la clase

asociada.


Asociaciones cali�cadas, cuando la multiplicidad de una asociación es de uno a muchos, es

necesario cali�car un objeto de la clase. Su símbolo es un pequeño rectángulo adjunto a

la clase que hará la búsqueda.

Asociaciones re�exivas, una asociación de la clase con sigo misma. Esto ocurre cuando una

clase tiene objetos que pueden jugar diversos papeles.

Herencia y generalización, la cualidad de una clase de heredar los atributos y operaciones

de otra.

Dependencias, cuando una clase utiliza a otra, depende de ella.

4.3.3. Diagrama de Secuencia

El diagrama de secuencia muestra la forma en que los objetos se comunican entre si al

transcurrir el tiempo. Consta de objetos que se representan del modo usual: rectángulos con

nombre (subrayado), mensajes representados por lineas continuas con una punta de �echa y el

tiempo representado como una progresión vertical.

Figura 4.3: Ejemplo de un diagrama de secuencia. Fuente: (SCHMULLER, n.d.).

4.3.4. Diagrama de Actividad

Ha sido diseñado para mostrar una visión simpli�cada de lo que ocurre durante una operación

o proceso, resalta las actividades de una operacion.

Cada actividad es representada por un rectángulo con las esquinas redondeadas. El proceso

dentro de una actividad se lleva a cabo y, al realizarse, se continua con la siguiente actividad.

Una �echa representa la transición de una a otra actividad. Se cuenta con un punto inicial


(representado por un circulo relleno) y un punto �nal (representado por una diana). Es muy

parecido a un diagrama de �ujo.

Figura 4.4: Ejemplo de un diagrama de actividad. Fuente: (SCHMULLER, n.d.).

Los ejemplos mostrados son muy sencillos y la información sobre UML muy escasa. Esto se

debe a que este no es un libro sobre UML. Al lector interesado se le invita a leer los libros sobre

UML citados anteriormente.

4.4. Arquitectura Modelo Vista Controlador (MVC)

La arquitectura de modelo-vista-controlador es un modelo de infraestructura web sugerido

para desacoplar la interfaz del usuario de la funcionalidad y el contenido de la información de la

aplicación web. Donde la vista es la página HTML y el código que provee de datos dinámicos

a la página, el modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio y el

controlador es el responsable de recibir los eventos de entrada desde la vista.

La arquitectura MVC fue introducida como parte de la versión Smalltalk-80 del lenguaje de

programación Smalltalk. Fue diseñada para reducir el esfuerzo de programación necesario en la

implementación de sistemas múltiples y sincronizados de los mismos datos.


Figura 4.5: La arquitectura MVC. Fuente: (PRESSMAN, 2007).

4.4.1. De�nición de las partes

Modelo: contiene todo el contenido especí�co de la aplicación y la lógica de procesamiento, e

incluye todos los objetos de contenido, el acceso a fuentes de datos/información externa

y toda la funcionalidad de procesamiento que son especí�cas de la aplicación. El Modelo

no tiene conocimiento especí�co de los Controladores o de las Vistas, ni siquiera contiene

referencias a ellos. Es el propio sistema el que tiene encomendada la responsabilidad de

mantener enlaces entre el Modelo y sus Vistas, y noti�car a las Vistas cuando cambia el

Modelo.

Vista: contiene todas las funciones especi�cas de la interfaz y habilita la presentación del

contenido y la lógica de procesamiento, e incluye todos los objetos de contenido, acceso a

fuentes de datos/información externa y a toda la funcionalidad de procesamiento requerida

por el usuario �nal. Genera una representación visual del Modelo y muestra los datos al

usuario. Interactúa con el Modelo a través de una referencia al propio Modelo.

Controlador: gestiona el acceso al modelo y a la vista y coordina el �ujo de datos entre ellos.

Es el objeto que proporciona signi�cado a las órdenes del usuario, actuando sobre los

datos representados por el Modelo. Cuando se realiza algún cambio, entra en acción, bien

sea por cambios en la información del Modelo o por alteraciones de la Vista. Interactúa

con el Modelo a través de una referencia al propio Modelo.


En una aplicación web, �la vista la actualiza el controlador con datos provenientes del modelo

con base en la entrada del usuario�. En la Figura 4.5 se muestra una representación esquemática

de la arquitectura MVC.

4.5. Herramientas de Desarrollo

Para el desarrollo de nuestro prototipo utilizaremos el lenguaje de programación Python, la

herramienta de procesamiento de lenguaje natural Natural Language ToolKit (NLTK) que está

totalmente escrita en Python, el programa XPDF que nos permitirá extraer el texto de nuestra

colección de documentos respetando la codi�cación Latin1 - ISO 8859-1, el FrameWork Web

Django también escrito totalmente en Python que cuenta con un miniservidor, que utilizaremos

en las pruebas y en el uso del prototipo en una sola máquina.

Como Ud. notará realizamos el prototipo con software libre y alta compatibilidad (todo

escrito en Python), además esto nos permite hacer que el prototipo sea multiplataforma. A

continuación describiremos cada una de las herramientas de programación que utilizaremos,

resaltando sus bondades y el por qué las elegimos (que es más que un capricho).

4.5.1. Lenguaje de Programación Python

Python ha sido diseñado por Guido van Rossum en 1989 y está en un proceso de conti-

nuo desarrollo por una gran comunidad de desarrolladores. Aproximadamente cada seis meses

se hace pública una nueva versión de Python. Que lo enriquece manteniendo en lo posible

la compatibilidad con los programas escritos para versiones anteriores. Nosotros utilizaremos

características de la versión 2.5 de Python.

Python presenta una serie de ventajas que lo hacen muy atractivo. Entre las más interesantes

tenemos:

Python es un lenguaje interpretado: lo que signi�ca que no es necesaria una compilación

del código para que este sea ejecutado, aunque esto puede parecer una desventaja Python

cuenta con JIT su compilador.

Python ofrece un entorno interactivo que facilita la realización de pruebas y ayuda a

despejar dudas acerca de ciertas características del lenguaje.

Python es un lenguaje muy expresivo, es decir, los programas Python son muy compactos:

un programa Python suele ser bastante más corto que su equivalente en lenguajes como

C.


Python está escrito en C++ : es posible escribir código para python en C++, para aquellas

rutinas que exijan más velocidad todavía (rutinas de cuello de botella), aunque esto suele

no ser necesario pues los módulos que tiene el lenguaje son muy rápidos.

Python es muy legible. La sintaxis de Python es muy elegante y permite la escritura de

programas cuya lectura resulta más fácil que si utilizáramos otros lenguajes de programa-

ción.

El entorno de ejecución de Python detecta muchos de los errores de programación que

escapan al control de los compiladores y proporciona información muy rica para detectarlos

y corregirlos.

Python puede usarse como lenguaje imperativo procedimental o como lenguaje orientado

a objetos.

Posee un rico juego de estructuras de datos que se pueden manipular de modo sencillo.

Presenta una gran funcionalidad para manejos de string e incluso tiene el tipo de dato

unicode, que nos permite manejar texto con cualquier tipo de codi�cación.

Una ventaja fundamental de Python es la gratuidad de su intérprete. Puedes descargar el

intérprete de la página web http://www.python.org. El intérprete de Python tiene versiones

para prácticamente cualquier plataforma en uso: sistemas PC bajo Linux, sistemas PC bajo

Microsoft Windows, sistemas Macintosh de Apple, etc. Actualmente, Python se ha convertido

en un lenguaje multifuncional (gracias a una serie de librerías) y viene instalado por defecto en

muchas distribuciones Linux (sino en todas), las que he podido veri�car son: Debian 4, Suse

10.1, Fedora 9, Ubuntu 8.04, Knoppix 5, Mandriva 2008.

En los últimos años ha habido un aumento en el numero de programadores y empresas que

lo utilizan, entre ellos Google.

4.5.2. Natural Language ToolKit (NTLK)

Tal como su nombre lo indica NLTK es una Herramienta para el tratamiento del lenguaje

natural, fue creada originalmente como parte de un curso de lingüística computacional en el

Department of Computer and Information Science de la University of Pennsylvania el 2001.

Actualmente es utilizada en cursos de decenas de universidades, e hizo el papel básico de

muchos proyectos de investigación.

Fue diseñada por Steven Bird, Ewan Klein y Edward Loper quienes actualmente trabajan

en la herramienta y le dan soporte en una comunidad abierta, esto permite que la herramienta

pueda mejorar e implementarse en diferentes idiomas. Originalmente solo podía utilizarse los

diferentes módulos en el idioma Inglés, pues fue escrita y diseñada para ese idioma, pero en

http://www.python.org


la actualidad puede soportar otros idiomas como el Portugués, gracias al aporte de programa-

dores en diferentes partes del mundo. Lamentablemente no ofrece soporte para el castellano.

Sin embargo, podemos hacer uso del tokenizador mediante expresiones regulares y de algunas

herramientas estadísticas.

NLTK está escrito completamente en Python, ya destacamos las propiedades de este len-

guaje, de cualquier modo no esta por demás incluir de manera textual la justi�cación que los

autores de NLTK dan por el uso de este lenguaje:

Elegimos Python como lenguaje para la implementación de NLTK puesto que cuen-

ta con una curva de aprendizaje super�cial, esto es porque su sintaxis y semántica

son transparentes, y este tiene buena funcionalidad para el manejo de cadenas.

Como un lenguaje scripting, Python facilita la exploración interactiva. Como un

lenguaje orientado a objetos, Python permite que los datos y métodos sean encap-

sulados y fácilmente reutilizados. Como un lenguaje dinámico, Python permite que

atributos sean adicionados a los objetos al vuelo, y permite que las variables sean

categorizadas de manera dinámica, facilitando el rápido desarrollo. Python llega con

una extensa librería estándar, incluyendo componentes para programación grá�ca,

procesamiento numérico, y procesamiento de datos web.

Python es altamente utilizado en la industria, investigación cientí�ca, y educación

alrededor del mundo. Python es frecuentemente alabado por la forma en que facilita

la productividad, calidad, y mantenimiento de software.

NLTK provee clases elementales para representar datos relevantes para el procesamiento del

lenguaje natural; interfaces estándar para realizar tareas como: tokenizacion, stemmer, tagging y

parsing; las implementaciones elementales para cada tarea pueden ser combinadas para resolver

problemas complejos.

4.5.3. XPDF

XPDF es un visor de código abierto para archivos PDF. El proyecto XPDF también incluye

un extractor de texto de los archivos PDF, un conversor a formato PS, y otras herramientas.

XPDF tiene versiones para UNIX, OS/2, Windows, DOS. Es pequeño y e�ciente.

Nosotros utilizamos la herramienta pdftotext, que extrae todo el texto del archivo PDF y por

defecto respeta la codi�cación Latin1, aunque se puede con�gurar para diferentes codi�caciones.

Ud. puede encontrar la versión actual de XPDF en http://www.foolabs.com/xpdf/ y viene

en muchas distribuciones Linux, aunque no suele instalarse por defecto.

http://www.foolabs.com/xpdf/


4.5.4. Framework Web Django

Django es un framework de desarrollo web, escrito completamente en Python, que ahorra

tiempo y hace que el desarrollo web sea divertido. Django se aproxima al patrón de arquitectura

de diseño Modelo-Vista-Controlador (MVC). Ya hemos mencionado las ventajas de este enfoque.

Django nació en el 2003 en Kansas, cuando los programadores web del diario Lawrence Jour-

nal World, Adrian Holovaty y Simon Willson vieron la necesidad de contar con un framework

de desarrollo web que les ahorrara tiempo debido a las nuevas características que los periodis-

tas (y directivos) exigían para los sitios locales de noticias que ellos producían y mantenían,

respectivamente.

En julio del 2005 el equipo de World Online, decidió liberar el framework como software de

código abierto y lo llamaron Django, por el guitarrista de jazz Django Reinhardt.

La pagina de Django, cuenta con una serie de tutoriales y con el libro de Django del cual

tomamos el siguiente texto pues creo que no hay una mejor explicación para de�nir que es

Django.

Django es un framework web de alto nivel en Python que fomenta el desarrollo

rápido y el diseño limpio y pragmático.

Obviamente, este texto tiene una descomposición extensa y muy descriptiva. Que no mos-

tramos aquí, pero invitamos a que la lea de forma completa y Ud. mismo se convenza del poder

de Django.

Parte III

Desarrollo

48

49

Para realizar las pruebas construiremos un prototipo del sistema de RI, el cual denomina-

remos: �Yatiri� en Aymara; �Yachayniyuq� en Quechua; �Arandu� en Guaraní; �El que sabe� en

Castellano. Que a partir de ahora sera referenciado con cualquiera de estos nombres.

Este consta de dos subsistemas: el indizador que es una aplicación de escritorio y el buscador

que es una aplicación web. El indizador toma como colección de datos �Legislación Boliviana -

Compendio de leyes de 1825 a 2007� en su formato electrónico que fue presentada recientemente

(28 de mayo 2008) por la Vicepresidencia de la República en cooperación con la FUNDAPPAC

(Fundación de Apoyo al Parlamento y a la Participación Ciudadana) y Konrad Adenauer Stif-

tung. Una vez indizada la colección, el buscador procesará las consultas realizadas sobre dicha

colección.

Este prototipo será evaluado posteriormente por siete Secretarios Técnicos de las Brigadas

Parlamentarias Departamentales que trabajan con leyes cotidianamente. Sus juicios de relevan-

cia, son sumamente importantes en el proceso de evaluación.

Capítulo 5

Modelado del Sistema RI

En la Sección 4.2, de�nimos el proceso de ingeniería web que nosotros seguiremos para el

desarrollo del prototipo. Siguiendo las actividades establecidas, presentamos en este capitulo

los requisitos que debe satisfacer nuestra aplicación web y los escenarios de interacción (casos

de uso). A partir de los casos de uso, identi�caremos el contenido de la aplicación web y las

funciones que se desarrollaran. Cabe recalcar que el sistema de recuperación de información

�Yatiri�, está compuesto por dos subsistemas: El indizador que es una aplicación de escritorio y

el buscador que es una aplicación web.

5.1. Formulación y Recopilación de requisitos

5.1.1. Casos de Uso

Caso de Uso: Búsqueda sobre la colección de documentos

Actor: Visitante

1. El visitante necesita información sobre alguna ley de Bolivia.

2. El visitante ingresa al sitio web del buscador �Yatiri�.

3. El visitante expresa su necesidad de información como una consulta.

4. El visitante ingresa su consulta y presiona el botón buscar.

5. El sistema valida la consulta.

5.1 Si la consulta es válida, se pasa al punto 6.

5.2 Si la consulta no es válida, se muestra el mensaje �No se hallaron resultados�.

6. El sistema busca en el conjunto de índices y genera un conjunto de resultados.

7. El sistema asigna puntuaciones a los documentos resultantes.

8. El sistema ordena los resultados por puntuación en orden descendente.

9. El sistema aplica un algoritmo de corrección ortográ�ca a la consulta ingresada sobre

el índice k-grama, obteniendo como resultado la corrección ortográ�ca más adecuada.

10. El sistema muestra los resultados y la corrección ortográ�ca de la consulta al visitante.

50

CAPÍTULO 5. MODELADO DEL SISTEMA RI 51

Caso de Uso: Creación del conjunto de índices

Actor: Administrador

1. El administrador ingresa al sistema.

2. El administrador introduce su clave de usuario.

2.1 Si la clave es válida, se pasa al punto 3.

2.2 Si la clave no es válida, no se puede ingresar al sistema.

3. El sistema despliega la interfaz de usuario con los botones �buscar ubicación� e �indizar�.

4. El administrador presiona el botón �buscar ubicación�.

5. El sistema despliega el cuadro de dialogo �buscar directorio�.

6. El administrador elije el directorio a indizar y presiona el botón �aceptar�.

7. El sistema despliega la interfaz de usuario con los botones �buscar ubicación� e �indizar�.

8. El administrador presiona el botón �indizar�.

9. El sistema despliega el cuadro de progreso �Indizando�, y procede a crear los índices

de la colección.

En la Figura 5.1 tenemos el diagrama de casos de uso construido a partir de los dos escenarios

anteriores: Búsqueda sobre la colección de documentos y Creación del conjunto de índices. Como

se puede notar estos son los dos casos de uso globales (funcionalidades del sistema), pero estos

a su vez están comprendidos de otros casos de uso más especí�cos, mismos que detallamos a

continuación:

Caso de Uso: Ingresa consulta

El sistema despliega una página web con un cuadro de texto (para escribir la consulta)

y con el botón �buscar�. El visitante expresa su necesidad de información como una consulta

(por ejemplo, si el visitante desea saber que ley contiene las �estipulaciones de la autonomía

universitaria� el podría introducir la consulta, �estipulaciones + autonomía + universitaria� ).

El visitante ingresa su consulta en el cuadro de texto de la pagina web y presiona el botón

�buscar�.

Caso de Uso: Validación

El sistema somete a la consulta a un proceso de validación, que consiste en veri�car si

la consulta corresponde a una expresión in�ja1 correcta. Por ejemplo, la consulta �autonomía

+ unibersitaria�, es una operación in�ja correcta pero obviamente el token unibersitaria tiene

errores ortográ�cos. La consulta �autonomía ( universitaria OR universidad )� es una expresión

in�ja incorrecta, pues falta un operador entre el token autonomía y el token (. Si la consulta es

una expresión in�ja incorrecta se retorna el mensaje �No se encontraron resultados�.

1Una expresión in�ja, se usa comúnmente para escribir una fórmula matemática o lógica donde se puede

especi�car la jerarquía de los operadores. Por ejemplo la operación '*', tiene mayor jerarquía que la operación

'+' por lo que debe ser evaluada primero.


Figura 5.1: Casos de uso del Sistema de Recuperación de Información �Yatiri�. Fuente: Creación

personal.

Caso de Uso: Búsqueda en índices y generación de resultados

Entonces el sistema divide la consulta en tokens y genera la expresión post�ja correspon-

diente a la expresión in�ja de la consulta. Esta se evalúa según los operadores que contenga

sobre el índice, obteniendo �nalmente un conjunto de identi�cadores de documentos �docID�

que son los documentos que corresponden con la consulta.

Caso de Uso: Asignar puntuación a los resultados

Obtenidos los documentos que corresponden con la consulta, el sistema le asigna una puntua-

ción con respecto a la consulta a cada uno mediante un algoritmo de puntuación por frecuencia.

Caso de Uso: Ordena resultados por puntuación

Una vez que cada documento tiene asignada una puntuación con respecto a la consulta. El

sistema ordena los documentos por puntuación de forma descendente (de mayor a menor). De

tal forma que los documentos con más puntuación se muestren primero.


Caso de Uso: Corrección de ortografía

Como el ejemplo que se mostró en el caso de uso de validación, si la consulta es una expresión

in�ja correcta pero uno o mas tokens están escritos de manera incorrecta, es decir con errores

de ortografía, el sistema realiza la corrección de ortografía de los tokens que no son operadores

en la consulta ingresada. Obteniendo así una nueva consulta con los tokens corregidos.

Caso de Uso: Muestra resultados

El sistema despliega una página web que contiene los resultados que coinciden con la consulta

ingresada (consistente en el nombre del documento y un trozo de texto del documento más

signi�cativo para la consulta) y la consulta con los tokens corregidos, junto con el mensaje �¾Ud.

quiso escribir? :�. Esto por que la colección de documentos puede tener errores ortográ�cos que

hayan pasado desapercibidos o son causados por el uso de mayúsculas. Por ejemplo, código,

CÓDIGO y CODIGO todas se consideran con ortografía correcta en la gramática del castellano.

Caso de Uso: Ingresa al sistema

El sistema despliega la interfaz de usuario. El administrador del sistema ingresa su Id. de

usuario y su clave la Id. de usuario y la clave son sometidas a un proceso de veri�cación, si son

correctas el administrador ingresa al sistema, caso contrario no puede ingresar.

Caso de Uso: Veri�car usuario

Dados el Id. de usuario y su clave, el sistema realiza una veri�cación comparando las Id.

de usuario y su clave con las que están guardadas (de forma codi�cada) en el sistema. Si son

iguales, el usuario es un usuario valido caso contrario es un usuario no válido.

Caso de Uso: Elegir ubicación de la colección

El sistema despliega la interfaz de usuario con los botones �buscar ubicación� e �indizar�. El

administrador presiona el botón �buscar ubicación�. El sistema despliega el cuadro de diálogo

�buscar directorio� con los botones �aceptar� y �cancelar�, el administrador busca el directorio

que quiere indizar y presiona el botón �aceptar� si lo encuentra, presiona el botón �cancelar�

en caso contrario. Si el administrador encontró el directorio que estaba buscando el sistema

habilita el botón �indizar�, no lo habilita en caso contrario.

Caso de Uso: Crear el índice de la colección

El administrador presiona el botón �indizar�. El sistema despliega el cuadro de progreso

�Indizando� que contiene una barra de progreso y comienza a crear el conjunto de índices del

directorio especi�cado, mostrando cada instante el progreso actual de la operación de indizado.


5.1.2. Modelo de contenido

Contiene elementos estructurales que proporcionan una importante visión de los requisitos de

contenido para una aplicación web. Incluyen objetos de contenido (por ejemplo: texto, grá�cas,

imágenes, audio) que se presentan como parte de la aplicación web (PRESSMAN, 2007).

Relaciones y Jerarquía de Contenido

Figura 5.2: Árbol de datos para una consulta. Fuente: Creación personal.

Clases de Análisis

Figura 5.3: Clases de análisis para el caso de uso �Búsqueda sobre la colección de documentos�.

Fuente: Creación personal.


5.1.3. Modelo de interacción

Este nos sirve para analizar la forma en la que el usuario interactua con la aplicación web,

destacando la funcionalidad, el contenido y el comportamiento de la aplicación (PRESSMAN,

2007).

Diagrama de Secuencia

Los diagramas de secuencia UML nos ofrecen una representación abreviada de la forma en

la cual las acciones del usuario colaboran con las clases de análisis. La Figura 5.4, muestra el

diagrama de secuencia para el caso de uso: Búsqueda sobre la colección de documentos.

Figura 5.4: Diagrama de secuencia para el caso de uso �Búsqueda sobre la colección de docu-

mentos�. Fuente: Creación personal.

5.1.4. Modelo Funcional

De�ne las operaciones que se aplicarán al contenido de la aplicación web y describe otras

funciones de procesamiento, independientes del contenido pero necesarias para el usuario �nal

(PRESSMAN, 2007).

Las operaciones adicionales (que no pertenecen a ninguna clase) serán diseñadas por separa-

do siguiendo una estructura procedimental. Esto es muy útil pues algunas de estas operaciones

adicionales, se utilizarán en el proceso de indizado.

Para justi�car esto recuerde la Figura 2.1, en la que se muestra los componentes de un

sistema de recuperación de información. Como Ud. podrá notar todavía no hemos de�nido


algunos de estos componentes, es decir, no se encuentran como métodos de alguna clase. Sin

embargo, estos se harán más evidentes cuando realicemos los diagramas de actividad de los

métodos más importantes de las Clases.

Diagramas de actividad

La Figura 5.5 muestra el diagrama de actividad del método evaluar(void). Donde podemos

distinguir cuatro operaciones adicionales: Tokenizar(String), Arbol CrearArbolIn�jo(List), List

ConvertirPost�ja(Arbol) y List EvaluaExpPost�ja(List).

Figura 5.5: Diagrama de actividad para el método evaluar(void) de la Clase Consulta. Fuente:

Creación personal.

La Figura 5.6 muestra el diagrama de actividad del método corregirConsulta(String). Donde

podemos distinguir dos operaciones adicionales: Tokenizar(String), CorregirOrtogra�a(String).


La operacion CorregirOrtogra�a(String) se compone a su vez de otras operaciones tal como:

Coe�cienteDeJaccard(String, String) y DistanciadeLevensthein(String, String).

Lo mismo ocurre con otras operaciones, pero nosotros las desarrollamos en el siguiente

capítulo de manera detallada.

Figura 5.6: Diagrama de actividad para el método corregirConsulta(String) de la Clase Consulta.


La Figura 5.7 muestra el diagrama de actividad del método hallarResultados(void). Donde

podemos distinguir la operación adicional: elige_trozo(String, List).

La operación adicional elige_trozo(String, List), busca en el documento �docID� el trozo

de texto que contenga los términos y que sea más representativo para la consulta en cuestión.

Es una operación muy importante que genera el contenido de la aplicación web de manera

dinámica.


Figura 5.7: Diagrama de actividad para el método hallarResultados(void) de la Clase Consulta.


La Figura 5.8 muestra el diagrama de actividad del proceso de indizado perteneciente al

caso de uso Crear el indice de la colección. Este proceso no pertenece a ninguna clase de análisis

puesto que en el caso de uso Creación del conjunto de índices no se pudo hallar ninguna clase.

Sin embargo, el diagrama de actividad de este proceso nos ayudara a encontrar operaciones

adicionales que este proceso pueda utilizar.


Figura 5.8: Diagrama de actividad para el proceso indizar(ruta). Fuente: Creación personal.

5.2. Diseño de la aplicación web

5.2.1. Diseño arquitectónico

Arquitectura de contenido

Se centra en la forma en la que los objetos de contenido (u otros compuestos como las

páginas web) se estructuran para su presentación y navegación. Utilizamos una estructura lineal,

como se muestra en la Figura 5.9.

Arquitectura de la aplicación web

Aborda la forma en la que la aplicación se estructura para gestionar la interacción del usuario,

manejar las tareas de procesamiento internas, efectuar la navegación y presentar el contenido.


Figura 5.9: Arquitectura de contenido para la aplicación web. Fuente: Creación personal.

Como describimos en la Sección sobre MVC, utilizaremos la arquitectura Modelo-Vista-

Controlador contando así con tres capas: interfaz, navegación y comportamiento de la aplicación

con el �n de simpli�car la implementación y mejorar la mantención.

5.3. Diseño de la Interfaz de Usuario

5.3.1. Análisis del Usuario

Los usuarios de este sistema tienen una edad mayor a los 15 años, no cuentan necesariamente

con estudios superiores y pueden cometer errores sin ninguna consecuencia. Ademas deben estar

minimamente acostumbrados al uso de la computadora.

5.3.2. Análisis y modelado de tareas

Consideremos el caso de uso Búsqueda sobre la colección de documentos descrito en la

Sección 5.1.1 en base al cual, diseñamos el diagrama de carril2 que se muestra en la Figura

5.10.

5.3.3. Análisis del Contenido

En la Sección 5.1.2, realizamos el modelado de contenido obteniendo un árbol de datos para

una consulta. Identi�camos contenido que utilizaremos en la interfaz pero que se obtiene de

otros componentes de la aplicación, tales como: Corrección de Consulta, Nombre Documento,

Puntuación Documento y Trozo Documento.

2Variación útil del diagrama de actividad, que permite la representación del �ujo de actividades descritas

por el caso de uso y, al mismo tiempo, indicar que actor o clase tiene la responsabilidad de la acción descrita

mediante un triangulo de actividad


Figura 5.10: Diagrama Carril para el caso de uso búsqueda sobre la colección de documentos.

Fuente: Elaboración personal.

Es momento de de�nir el formato y la estética de los mismos. La Figura 5.11 muestra un

formato de pantalla preliminar para nuestro prototipo.

5.3.4. Diseño

Como podemos apreciar en la Figura 5.11, el único contenido que no hemos generado

todavía es el trozo del documento.

El trozo del documento es el contenido mas importante de la interfaz de usuario de cualquier

sistema de recuperación de información, pues es la única parte del documento que se muestra al

usuario de forma inmediata y este muchas veces decide en función de esta parte si el documento

es relevante o no.


Figura 5.11: Formato de pantalla preliminar. Fuente: Elaboración personal.

Entonces, ¾como elegimos el trozo del documento?

Nosotros utilizamos el concepto del mas próximo, es decir, recuperamos los tokens de la

consulta y buscamos los tokens que se encuentren mas próximos en el documento. Posterior-

mente recortamos trozos del documento donde estén estos tokens próximos. En caso de estar

aun lejanos cortamos el texto guiándonos por un umbral, por decir algo 100 caracteres.

Con esto aseguramos que las palabras de la consulta se encuentren tan cercanas como sea

posible, tratando se asegurar que se encuentren en la misma oración.

Ya tenemos claros los requerimientos y las funciones que nuestro sistema de recuperación

de información debe cumplir. Ademas, debemos tener en cuenta en todo momento que el

objetivo de este trabajo es el reducir la distancia entre la información que el usuario necesita y

la información que obtiene. Sin lugar a duda la forma en la que ha sido diseñada la aplicación

será un factor importante a la hora de evaluar el modelo de recuperación de información.

Capítulo 6

Herramientas para el tratamiento

lingüístico

Como se mencionó en el Capitulo 3, en este trabajo se hace énfasis en la morfología,

así pues las herramientas que diseñaremos trabajan sobre palabras como unidades únicas e

independientes. Sin la consideración de que rol estén jugando en la oración en estudio.

Se inicia este capítulo con una revisión de la ISO 8859-1, que regulariza la codi�cación

para los países de habla hispana. Para luego pasar al diseño de las diferentes herramientas

(tokenizador, stemmer y corrector ortográ�co), asumiendo que se tienen simples caracteres sin

ningún problema de codi�cación o decodi�cación.

6.1. ISO 8859-1: Codi�cación Latin1

El estándar ISO 8859-1 de�ne la codi�cación del alfabeto latino, incluyendo los diacríticos

(como letras acentuadas, ñ, ç), y letras especiales (como ÿ, Ø), necesarios para la escritura de las

siguientes lenguas originarias de Europa occidental: afrikaans, alemán, aragonés, catalán, danés,

escocés, español, feroés, �nés, francés, gaélico, gallego, inglés, islandés, italiano, neerlandés,

noruego, portugués, sueco y vasco. También conocida como Alfabeto Latino 1 o ISO Latín 1.

Esta norma pertenece al grupo de juegos de caracteres de la ISO conocidos como ISO-8859

que se caracterizan por poseer la codi�cación ASCII en su rango inicial (128 caracteres) y otros

128 caracteres para cada codi�cación, con lo que en total utilizan 8 bits. Los caracteres de

ISO-8859-1 son además los primeros 256 caracteres del estándar ISO 10646 (Unicode).

6.2. Diseño del Tokenizador

Tal como se describió en la Sección 3.5, el diseño de un tokenizador requiere un análisis al

texto completo por lo que utilizamos expresiones regulares para este propósito. En la actualidad

63

CAPÍTULO 6. HERRAMIENTAS PARA EL TRATAMIENTO LINGÜÍSTICO 64

son muchos los lenguajes de programación que incorporan funcionalidad para el manejo de

expresiones regulares, este es el caso de Python que incorpora esta funcionalidad en el módulo

re.

6.2.1. Expresiones Regulares en Python

Las expresiones regulares son una notación para expresar cadenas de texto. Se usan para

especi�car patrones de búsqueda y de substitución.

Para el uso de expresiones regulares contamos con operadores y caracteres especiales. En

la Tabla 6.1 presentamos en forma muy resumida los operadores y caracteres más comunes

utilizados en Python1

∗ cero o más

+ uno o más

? cero o uno (opcional)

[ ] conjunto o rango de caracteres

( ) agrupación

{m,n} de m a n caracteres

\b palabra vacía (longitud cero)

\d cualquier dígito decimal

\s cualquier carácter en blanco

\w cualquier carácter alfanumérico

\t cualquier tabulado

\n salto de linea

Tabla 6.1: Operadores y caracteres comunes de expresiones regulares en Python.

Una combinación apropiada de estos operadores y caracteres nos permitirá encontrar pala-

bras, abreviaciones, nombres propios, monedas, etc.

6.2.2. Construcción de las Expresiones Regulares

¾El problema principal es cuales son los tokens correctos a usar? Es decir qué palabras

deberíamos buscar en el texto para conservarlas y cuales deberíamos eliminar o no tomar en

cuenta.

Como partimos el texto en tokens depende mucho del propósito, en nuestro caso queremos

términos que puedan ser buscados directamente, como nombres personales, nombres de empre-

1Estos operadores pueden variar dependiendo del lenguaje de programación.


sas, diminutivos, abreviaciones, fechas, horas, números, porcentajes, etc. Vayamos construyendo

las expresiones que más se ajustan a nuestro idioma.

1. palabra = r'(\w+)'

2. numeral = r'(\d+[?:ºª])'

3. numero = r'((\d*\.\d+)+,{0,1}\d*|\d+,\d+|\d+)'

4. porcentaje = numero+'%'

5. montos = '\$\s?'+numero

6. fecha = r'((\d{1,4}[/-]){2}\d{1,4})'

7. hora = r'((\d{1,2}:){1,2}\d{1,2})'

8. puntuacion = r'((\.{3})|[_;\[\]\'"¾\?!½])'

Ahora pasemos a explicar cada una de las expresiones regulares, para comprenderlas mejor:

1. Denominamos palabra a todos los tokens que contengan uno o más caracteres alfanumé-

ricos.

2. Denominamos numeral a todos los tokens que tengan como cuerpo un dígito o más

seguido del símbolo numeral.

3. Denominamos numero a todos los tokens que llevan cero o mas dígitos seguidos de un

punto y uno o más dígitos seguidos de cero o una coma y cero o más dígitos o aquellos

que tengan uno o más dígitos seguidos de una coma y uno o más dígitos o aquellos que

tienen uno o más dígitos.

4. Denominamos porcentaje a todos los tokens número que sean seguidos por un símbolo

porcentaje.

5. Denominamos montos a todos los tokens que inicien con un símbolo de pesos seguidos

o no de un espacio en blanco y un número. Tales como: $ 198.123,56 o $3.567 , etc.

6. Denominamos fecha a todos los tokens que inicien con 1-4 dígitos seguidos de guion o

barra, tres veces. Como ser: 1999/9999/2008, esta claro que esto no es una fecha.

7. Denominamos hora a todos los tokens que inicien con 1-2 dígitos seguidos de dos puntos

hasta tres veces. Como ser: 12:08:05 o 99:99:99.

8. Denominamos puntuacion a todos los tokens que se consideran signos de puntuación,

como ser: .,...;[]'"¾?!½, etc.

Ademas, debemos tomar en cuenta las abreviaciones y los nombres propios que considera-

remos, estos serán tomados como tokens.


6.2.3. Diseño

El orden es importante, así que primero recuperamos las abreviaciones. Luego quitamos los

signos de puntuación y comenzamos a recuperar tokens tales nombres propios, palabras, fechas,

montos, etc. Debemos realizar la recuperación siguiendo el orden indicado anteriormente.

Como Ud. podrá notar la única di�cultad en el diseño del tokenizador es de�nir las expre-

siones regulares de manera adecuada. De tal forma que obtengamos tokens que re�ejen las

palabras que un hablante del idioma conozca, brindándole al token una unidad semántica que

lo eleva al grado de término.

6.3. Stemmer

Basándonos en la Sección 3.2 sobre análisis lingüístico, se realizo un stemmer para el cas-

tellano, este algoritmo es una variación del algoritmo de Porter - Snowball (PORTER, 1980)

para el español. Presentamos el algoritmo original y posteriormente las consideraciones tomadas

para crear la variación del algoritmo.

6.3.1. Algoritmo de Porter - Snowball

Las letras en español incluyen las siguientes formas acentuadas:

á é í ó ú ü ñ

Se comienza, identi�cando tres regiones, R1, R2 y RV que se de�nen como sigue:

R1, es la región que sigue después de la primera no vocal detrás de una vocal, o es la región

nula del �nal de la palabra si no se encuentra tal vocal. Ejem: �campos� ,entonces R1 es

la región: �pos� la primera no vocal detrás de una vocal es `m'.

R2, es la región que sigue después de la primera no vocal detrás de una vocal en R1, o es la

región nula del �nal de la palabra si no se encuentra tal vocal siguiendo nuestro ejemplo:

R1 es �pos�, entonces R2 es � �, pues la primera no vocal detrás de una vocal en este caso

es vació � �.

RV, si la segunda letra es una consonante, es la región detrás de la siguiente vocal, o si las

primeras dos letras son vocales, es la región detrás de la siguiente consonante, y en otro

caso es la región detrás de la tercera letra. Pero si no se encuentran estas posiciones, RV

apunta al �nal de la palabra.

Luego realizamos los siguientes pasos (siempre se realiza los pasos 0 y 1):


Paso 0: Pronombre adjunto

buscamos uno de los siguientes su�jos

me se sela selo selas selos la le lo las les los nos

y lo quitamos, si viene detrás de cualquiera de estos

(a) iéndo ándo ár ér ír

(b) iendo ando ar er ir

(c) yendo detrás de u

en RV. En el caso de (c), yendo debe estar en RV, pero le precede u y puede encontrarse

fuera de RV.

En el caso de (a), se quita y luego se remueve el acento (por ejemplo, haciéndola →haciendo).

Paso 1: los su�jos corrientes son removidos

Buscamos a lo largo de los siguientes su�jos, y realizamos la acción indicada.

anza anzas ico ica icos icas ismo ismos able ables ible ibles ista istas

oso osa osos osas amiento amientos imiento imientos

quitandolo si esta en R2

adora ador ación adoras adores aciones ante antes ancia ancias

quitandolo si esta en R2, y si la antecede ic borrarla si esta en R2

logía logías

cambiando con log si esta en R2

ución uciones

cambiando con u si esta en R2

encia encias

cambiando con ente si esta en R2

amente


quitarlo si esta en R1. Si esta precedido por iv, quitarlo si esta en R2 (y si despues esta

precedido por at, quitarlo si esta en R2), de otra forma, si esta precedido por os, ic o

ad, quitarlo si esta en R2

mente

quitarlo si esta en R2. Si esta precedido por ante, able o ible, quitarlo si esta en R2

idad idades

quitarlo si esta en R2. Si esta precedido por abil, ic o iv, quitarlo si esta en R2

iva ivo ivas ivos

quitarlo si esta en R2. Si esta precedido por at, quitarlo si esta en R2

Realizar el Paso 2a, si ningún su�jo ha sido removido en el Paso 1

Paso 2a: Su�jos de verbos que inician con y

Busque cualquiera de los siguientes su�jos en RV, y si lo encuentra, borrelo si es precedido

por u.

ya ye yan yen yeron yendo yo yó yas yes yais yamos

(Note que la u que precede no estará en RV.)

Realizar el Paso 2b si el Paso 2a se realiza, pero no logra remover su�jos.

Paso 2b: Otros su�jos de verbo

Busque a lo largo de los siguientes su�jos en RV, y realice la acción indicada.

en es éis emos

quite, y si esta precedida por gu quitar la u (gu no está necesariamente en RV)

arían arías arán arás aríais aría aréis aríamos aremos

ará aré erían erías erán erás eríais ería eréis eríamos

eremos erá eré irían irías irán irás iríais iría iréis

iríamos iremos irá iré aba ada ida ía ara iera ad ed

id ase iese aste iste an aban ían aran ieran asen

iesen aron ieron ado ido ando iendo ió ar er ir as

abas adas idas ías aras ieras ases ieses ís áis abais


íais arais ierais aseis ieseis asteis isteis ados idos

amos ábamos íamos imos áramos iéramos iésemos ásemos

quitarlos

Siempre realizar el Paso 3.

Paso 3: residuos de su�jos


os a o á í ó

quitelos si están en RV

e é

quitelos si están en RV, y si está precedido por gu con la u presente en RV quite la u

Y �nalmente quite todos los acentos.

6.3.2. Diseño

Si revisamos el algoritmo de stemmer de porter notamos que inicia asignando 3 regiones,

luego se ejecutan 4 pasos , el paso 0 intenta remover el pronombre enclítico adjunto, el paso

1 intenta remover los su�jos corrientes (los que se usan en sustantivos, adjetivos y algunos

adverbios), el paso 2a intenta remover los su�jos de los verbos que inician con `y', el paso 2b

remueve otros su�jos de verbos, �nalmente el paso 3 quita los residuos de los su�jos y todos

los acentos.

La variación consiste en incluir los siguientes casos:

Paso 0: Se realiza como el algoritmo original, pero ademas se consideran los siguientes su�jos:

te os

y en los incisos (a), (b) consideramos también el gerundio: endo

Paso 1: Se realiza como en el algoritmo original, pero además se consideran los siguientes

casos:

Buscar cualquiera de los siguientes su�jos en R2 (usados para obtener verbos a partir de

nombres - verbalización)

achar ajar ar azar ear ecer edar eguear ejar i�car iguar

iquear iscar itar izar orrar orriar otear ucar ujar uscar uzar


y quítelos.

Busque los siguientes su�jos (adjetivos superlativos) en R2

ísimo ísimos ísima ísimas

y quítelos.

Busque los siguientes su�jos (aumentativos aplicados a sustantivos, adjetivos y algunos

adverbios) en R2

ón azo ona aza ones onas azos azas ote

acho ota acha otes otas achos achas

y quitarlos.

Busque los siguientes su�jos (despectivos aplicados a sustantivos y adjetivos) en R2

ejo eja ejos ejas ucho ucha uchos uchas

y quítelos, si los anteceden ec o ez quitarlos también (estos no están necesariamente en

R2).

Busque los siguiente su�jos (diminutivos) en R2

ecezuelas ecezuelos ecezuela ecezuelo

ececinas ececines ececina ececón ececicas ececicos

ececica ececico ececillas ececillos ececilla ececillo

ececitas ececitos ececita ececito ezuelas ezuelos

ezuela ezuelo ecinas ecines ecina ecín ecicas ecicos

ecica ecico ecillas ecillos ecilla ecillo ecitas ecitos

ecita ecito zuelas zuelos zuela zuelo cinas cines

cina cín cicas cicos cica cico cillas cillos cilla

cillo citos citas cita cito uelas uelos uela uelo inas

ines ina ín icas icos ica ico illas illos illa illo

itas itos ita ito

y quítelos.

Paso 2b: Otros su�jos de verbo, reformulamos este paso de forma completa.


abas aban ábamos abais aba ada adas ado ados ad


áis ais amos án an ando

arás aras arán aran arais áramos ará ara

ares aren áremos aremos aréis areis aré are

arían arías aríamos aríais aría aron ar

as ás ase aseis ásemos asen ases aste asteis

aya ayáis ayamos ayan ayas az

ed erás eras erán eran erais eramos erá era

eres eren éremos eremos eréis ereis eré ere

erían erías eríamos eríais ería eron ero eró er

eses esen ésemos eseis ese és es

ía ían ías íais íamos íd id ído ido idos ída ida idas

ieses iesen iésemos ieseis iese ieron ieres ieren

iéremos iereis iere ieras ieran iéramos ierais

iera iendo ímos imos ió io ír ir ís isteis iste

irás irán irá iréis iremos iré irías irían iríamos iríais iría

jeses jesen jésemos jeseis jese jeron jeres jeren

jéremos jereis jere jeras jeran jéramos jerais jera

ois omos on ón os oy

quitarlos.

en es éis eis emos

quítelos y si está precedido por gu quitar la u (gu no esta necesariamente en RV).

Esas son las modi�caciones al algoritmo original. Como se puede notar se incluye el corte de

adjetivos superlativos, aumentativos, despectivos y diminutivos, ademas del corte de una mayor

cantidad de su�jos de verbos.

6.4. Corrector Ortográ�co

Como se indica en (MANNING y cols., 2008), existen dos principios básicos fundamentales

en la mayoría de algoritmos de corrección ortográ�ca.


1. De diversas alternativas de corrección ortográ�ca para una consulta, elija las que sean

más �próximas�. Esto requiere que tengamos una noción de aproximación o proximidad

entre un par de consultas.

2. Cuando dos consultas escritas de manera correcta son ligadas (o casi ligadas), elija la

que sea mas común. La noción simplista de �más común�, es el elegir la corrección de tal

manera que la más común sea elegida de entre las consultas escritas por otros usuarios.

Es decir, si una palabra es escrita de manera más frecuente en una consulta, entonces

es más probable que el usuario haya pretendido escribir esa palabra, antes que la palabra

que escribió.

Se considera ademas dos tipos de corrección ortográ�ca, la corrección de término aislado

y la corrección sensible al contexto. En la corrección de término aislado, se intenta corregir un

término de la consulta a la vez (por lo que puede fracasar en algunos casos), en la corrección

sensible al contexto se intenta corregir la oración como un todo. En este trabajo solo realizamos

un corrector de término aislado, impulsando a los lectores a realizar uno sensible al contexto.

Revisemos a continuación las medidas de proximidad que consideraremos, para posterior-

mente realizar el diseño de nuestro corrector ortográ�co.

6.4.1. Distancia de Edición

Dadas dos cadenas de caracteres s1 y s2, la distancia de edición entre estas es el mínimo

numero de operaciones de edición requeridas para transformar s1 en s2. Las operaciones de

edición permitidas y más comunes son: (i) insertar un carácter en una cadena; (ii) borrar

un carácter de una cadena y (iii) reemplazar un carácter de una cadena por otro carácter; la

distancia de edición es a veces conocida como distancia de Levenshtein en honor al ruso Vladimir

Levenshtein, quien se ocupara de esta distancia en 1965.

La noción de distancia de edición puede ser generalizada, permitiendo diferentes pesos para

diferentes tipos de operaciones de edición; pesos basados en la distancia de las teclas en el

teclado suele ser muy efectivo en la práctica, también se puede tomar pesos basándonos en la

posibilidad de aparición de una letra después de otra según el lenguaje (por ejemplo, es más

probable que una a vaya después de una consonante [b, c, d, ...] que después de una vocal)

aunque este método puede ser muy trabajado y solo un poco más e�ciente que el anterior.

La Figura 6.1, muestra el algoritmo para calcular la distancia de edición entre dos cadenas.

Este algoritmo da el valor de uno a cualquier operación de edición. El algoritmo llena las entradas

(enteras) en una matriz m cuyas dos dimensiones corresponden a las longitudes de las dos

cadenas cuyas distancias de edición están computadas; la entrada (i, j) de la matriz mantiene

(después de que el algoritmo es ejecutado) la distancia de edición entre la cadena consistente

de los primeros i caracteres de s1 y los primeros j caracteres de s2. El proceso central está


Figura 6.1: Algoritmo para calcular la distancia de edición entre las cadenas s1 y s2. Fuente:

(MANNING y cols., 2008).

descrito en las lineas 8-10, donde se toma el mínimo de las tres cantidades (correspondientes a

las tres posibles operaciones), para utilizarlo en el ciclo siguiente.

La Figura 6.2, muestra un ejemplo del cálculo de la distancia de Levenshtein sobre las

cadenas: codigo y código.

Figura 6.2: Ejemplo del cálculo de la distancia de Levenshtein. Las celdas de color naranja

(inferiores derechas de cada entrada (i, j)) es el mínimo de las otras tres entradas. Fuente:

Creación Personal.


6.4.2. Coe�ciente de Jaccard

Es un índice de similitud, que es utilizado para medir la asociación entre muestras. En

contraste con la mayoría de los coe�cientes de distancia, las medidas de similitud no son

métricas, ya que siempre pueden encontrarse dos muestras A y B más similares a otra que

la sumatoria de sus similitudes con una muestra distante C. Por lo tanto, las similitudes no

pueden ser utilizadas para ubicar muestras en la relación con otra en un espacio métrico.

En (SALAZAR, HERNÁNDEZ, y NUÑEZ, 2006) se lo describe como un coe�ciente bi-

nario, es decir se funciona comparando muestras descritas por la ausencia o la presencia de

características, una comparación que debe excluir la doble ausencia.

También es llamado coe�ciente de comunidad, hay variantes de este como el coe�ciente

de Dice, y también se le da muchos usos sobre todo en el campo de la genética. La Ecuación

6.1, es la que se de�ne en (BAEZA-YATES y RIBEIRO-NETO, 1999) y (MANNING y cols.,

2008) para calcular el coe�ciente de Jaccard aplicado a un modelo booleano y con algunas

aclaraciones.

CJA,B =|A ∪B|

|A|+ |B| − |A ∪B|(6.1)

Donde:

|A ∪B|, es el numero de características comunes entre A y B.

|A|, es el numero de características en A.

|B|, es el numero de características en B.

Comúnmente el coe�ciente de Jaccard se encuentra entre [0, 1], siendo 0 ninguna similitud

y 1 similitud total.

6.4.3. Indices k-grama para corrección de ortografía

Comúnmente dada una consulta, con la intención de hallar la corrección para esta, se debe

hallar la distancia de edición entre la consulta y todos los elementos del vocabulario de la

colección. Pero esto es impráctico y costoso, así una alternativa es utilizar el indice k-grama

(vea la Sección 7.3) con objeto de hallar un subconjunto del vocabulario, el conjunto de posibles

correcciones de la consulta, reduciendo así el cálculo de distancias de edición.

Lo que buscamos es formar el subconjunto con los términos que tengan �muchos k-gramas

en común� con la consulta, como se muestra en la Figura 6.3.

Esto no es su�ciente pues también consideraremos términos que no podrían ser correcciones

para nuestra consulta. Así, podemos utilizar ademas el coe�ciente de Jaccard para decidir si un

término debe considerarse o no, considerándolo si el coe�ciente de Jaccard es mayor o igual que


Figura 6.3: Correspondencia en 3-gramas, para los 3-gramas del termino código. Fuente: (MAN-

NING y cols., 2008).

el umbral2 y dejándolo fuera del subconjunto en otro caso. Donde el umbral, suele ser menor

que 0.5.

6.4.4. Desarrollo

Normalmente suele combinarse las herramientas presentadas para contar con un algoritmo

e�ciente y rápido, como se explica a continuación:

1. Usar el indice k-grama para encontrar un conjunto de términos del vocabulario candi-

datos a ser correcciones potenciales de la consulta, utilizando como �ltro o medida de

superposición el coe�ciente de Jaccard entre la consulta y todos los términos que posean

un numero menor de k-gramas coincidentes con el número de k-gramas de la consulta.

2. Entonces calculamos la distancia de edición a partir de la consulta para cada término en

el conjunto calculado en el paso anterior, seleccionando términos con pequeña distancia

de edición para la consulta.

3. Finalmente, del conjunto obtenido en el paso anterior seleccionamos el más común ya sea

en cuanto a consultas anteriores o en cuanto a frecuencia en los documentos.

En el paso 1, primero hallamos el subconjunto de términos que contengan el numero máximo

de k-gramas coincidentes con la consulta y hallamos otro conjunto a partir del anterior, que

contenga los términos con coe�ciente de Jaccard mayor o igual al umbral. Para esto, debemos

de utilizar la ecuación 6.1 con las siguientes modi�caciones:

CJq,t =|c|

|q|+ |t| − |c|(6.2)

2Se re�ere a un número que se debe superar para considerarse como aceptado.


Donde:

|c|, el numero de k-gramas coincidentes entre la consulta q y el termino t.

|q|, el numero de k-gramas de la consulta.

|t|, el numero de k-gramas del termino.

El paso 2 y el paso 3, no requieren mayor explicación. Al �nal solo contaremos con un

término que podemos presentar al usuario, de las siguientes formas (MANNING y cols., 2008):

1. Dada la consulta siempre recuperamos documentos que incluyan la consulta así como

también cualquier corrección ortográ�ca variante de la consulta.

2. Recuperamos documentos con la corrección ortográ�ca, siempre que el término de la

consulta no este en el diccionario.

3. Como en (1), pero solo cuando la consulta devuelve menos que un número predeterminado

de documentos.

4. Cuando la consulta devuelve menos que un numero predeterminado de documentos, la

interfaz del buscador presenta una sugerencia ortográ�ca (que es la corrección ortográ�ca

hallada) al usuario, como lo hace el conocido buscador Google.

En nuestro caso, recuperamos documentos con la consulta indicada y presentamos la co-

rrección ortográ�ca como una sugerencia al usuario (es decir, no recuperamos documentos de

la corrección ortográ�ca). No consideramos si la consulta devuelve o no resultados.

Capítulo 7

Construcción del Indice y

Tratamiento de Consultas

Un índice como su nombre lo indica es una estructura cuyos elementos apuntan a términos

en los documentos, tal como un índice en un diccionario o como el que esta al principio de

este documento. Estos suelen denominarse índices invertidos, aunque esto se considera un poco

redundante.

Los tipos de índices más conocidos son los posicionales y los no posicionales, la diferencia

entre ambos es que los primeros contienen una lista con las posiciones de los términos en los

documentos y los segundos solo contienen un listado de los documentos en los cuales esta el

término. Esto hace que el indice posicional ocupe más espacio en disco, pero son justamente

estas posiciones las que nos permiten acelerar la búsqueda y utilizar operadores (tal como la

distancia entre términos, /k) del modelo de recuperación de información booleano extendido.

A lo largo de este capítulo, mostraremos como se diseñaron los indices para nuestra colección

de documentos, mencionando cuando sea necesario las justi�caciones de las decisiones tomadas.

Comenzamos con el diseño del índice invertido estándar posicional, le agregamos el subsistema

de puntuación, luego pasamos al diseño del índice k-grama y �nalizamos describiendo la forma

en la que tratamos las consultas.

7.1. Indice invertido estándar posicional

Pasos para la creación de un índice invertido presentados en (MANNING y cols., 2008):

1. Recolectar los documentos a ser indexados.

2. Tokenizar el texto (partir en palabras u otro criterio).

3. Realizar un preprocesamiento lingüístico a los tokens.

77

CAPÍTULO 7. CONSTRUCCIÓN DEL INDICE Y TRATAMIENTO DE CONSULTAS 78

4. Indexar los documentos según la ocurrencia de cada término en el documento.

El primer punto ya lo tenemos resuelto, nosotros contamos con una colección de documentos.

Para el tokenizado ya diseñamos nuestro tokenizador, siguiendo los tópicos importantes de

nuestra colección y fundamentalmente de nuestro idioma. El preprocesamiento lingüístico suele

dividirse en dos etapas: quitar los tokens que se consideren inservibles o que no contribuyan con

mucha información, los stop words; normalizar los tokens, que serán llamados términos después

de este proceso, aplicando un lematizador o un stemmer. Finalmente, indexar los documentos

se considera la tarea más complicada, pues tenemos que ser conscientes del hardware con

el que contará el usuario y ademas que nuestro programa no es el único que funcionará en

la computadora, un usuario común pretenderá por ejemplo: escuchar música, mientras lee un

documento, cuando se está realizando el indexado. Aunque en los capítulos anteriores, indicamos

que se puede dividir un sistema RI en tres grupos y el nuestro seguramente se ubicará en

el segundo grupo (buscadores a nivel empresarial o dedicados a colecciones especí�cas). En

nuestro caso nuestro indizador trabaja sobre una colección estática. Los casos sobre colecciones

dinámicas, pueden leerse en (MANNING y cols., 2008).

Como se puede constatar nosotros utilizamos las herramientas que diseñamos en el capítulo

anterior (es decir, el tokenizador y el stemmer). Para completar los pasos 2 y 3, para el paso 4

diseñamos un algoritmo de intersección de listas.

En la construcción de un indice posicional, se puede almacenar las posiciones de los términos

en cuanto a caracteres o las posiciones en cuanto a tokens o almacenar ambas. La Figura 7.1

ilustra esto y ademas muestra la estructura que puede utilizarse.

Figura 7.1: Estructura de un índice posicional, que guarda las posiciones en cuanto a caracteres

y tokens de un termino. Fuente: Elaboración personal

Sin embargo, se consideren las posiciones o no. El proceso de construcción de un indice, sea

posicional o no siempre es similar. La Figura 7.2 muestra el proceso de construcción de un índice

invertido estándar no posicional. Donde claramente se puede ver que la parte más di�cultosa

del proceso de indizado es unir los términos de todos los documentos de forma ordenada, esto

destaca en la parte central de la �gura.


Figura 7.2: Construcción de un índice por clasi�cación y agrupamiento. La secuencia de tér-

minos en cada documento, etiquetado por su identidad de documento `docID' (izquierda) está

ordenada alfabéticamente (centro). Un término es agrupado por palabra y luego por `docID'.

Los términos y docID son luego separados hacia afuera (derecha). El diccionario almacena los

términos, y tiene un puntero a la lista de postings para cada término. Cada lista postings

almacena la lista de documentos en los cuales el término ocurre y pueden almacenar otra in-

formación adicional, tal como la frecuencia y las posiciones del término en cada documento.

Fuente: (MANNING y cols., 2008).

7.1.1. Compresión del Indice Invertido

Realizar la compresión del índice trae un bene�cio inmediatamente claro, reducir el tamaño

del índice. Pero además puede hacer que las respuestas a una consulta sean más rápidas, pues

dependiendo del tamaño del índice, puede ser más rápido copiar parte del índice que nos interesa

a la memoria y después descomprimirlo que copiar la misma parte del índice descomprimida a la

memoria (esto por la transferencia de datos que se supone es menor si el índice está comprimido).


Se tienen dos tipos de compresión: con pérdida y sin pérdida. En recuperación de informa-

ción, la compresión con pérdida comprende la eliminación de stop words y la normalizacion de

términos (stemming o lematizacion), y la compresión sin pérdida hace referencia a algoritmos

como el código variable byte o el código γ que se realizan a nivel de bits, se puede encontrar

descripciones de tales algoritmos en (MANNING y cols., 2008).

Nosotros utilizamos la compresión con pérdida dada por el stemmer y la compresión sin

perdida dada por el algoritmo gz, implementado en Python.

7.2. Puntuación de Documentos

Hasta aquí construimos el indice de forma que soporte consultas booleanas: un documento

corresponde o no a una consulta. Cuando tenemos colecciones de documentos grandes, el

número resultante de documentos que corresponden con una consulta puede sobrepasar por

mucho el número que un usuario puede revisar completamente. En consecuencia, es esencial

que un sistema de RI pueda ordenar en un ranking los documentos que corresponden con una

consulta. Para hacer esto, el motor de búsqueda calcula para cada par (consulta, documento)

una puntuación, con respecto a la consulta dada.

Son varios los métodos para realizar esta puntuación algunos están incluidos por defecto

en algunos modelos de recuperación de información, como es el caso del modelo vectorial. El

modelo booleano, no cuenta por defecto con un método para dar soporte a la puntuación1.

Sin embargo, podemos utilizar el método de frecuencia de término y peso en el documento

presentado en (MANNING y cols., 2008), para incorporar a nuestro prototipo la funcionalidad

de la puntuación.

7.2.1. Frecuencia de término y peso en el documento

Tal como se describe en (MANNING y cols., 2008) un documento que hace mención de un

término de la consulta con más frecuencia tiene más relación con la consulta y en consecuencia

debe recibir una puntuación alta. Entonces podríamos pensar en calcular la puntuación como

la suma, sobre los términos de la consulta, de las puntuaciones de correspondencia entre cada

término de la consulta y el documento.

Para este �n, asignamos a cada término en el documento un peso, que dependerá del número

de ocurrencias del término en el documento. El objetivo es calcular una puntuación entre un

término de la consulta t y un documento d, en base al peso de t en d. Una aproximación sencilla

consiste en asignar el peso como el número de ocurrencias del termino t en el documento d.

1Aun así sigue siendo el más utilizado por contar con muchas ventajas como el operador de distancia entre

términos /k y la búsqueda por frase exacta.


Este esquema de peso hace referencia a frecuencia de término y es denotado por tft,d, con la

denotacion de subíndice del término y el documento en ese orden.

Para un documento d, el conjunto de todos los pesos de los términos tf citados anterior-

mente2 puede ser visto como un cuantitativo compendio de este documento.

Siguiendo nuestras aceptadas limitaciones3, un documento d para nosotros puede ser visto

como una bolsa de palabras, así el orden exacto de los términos en el documento d es ignorado,

pero el número de ocurrencias de cada término es esencial (en contraste con el modelo de

recuperación booleano). Solo retenemos información del número de ocurrencias de cada término,

entonces dos documentos (o más) con bolsas de palabras similares son similares en contenido.

Este modelo es conocido en el campo de estudio como modelo de bolsa de palabras.

En el apartado sobre stop words revisamos la idea de que todas las palabras en un documento

no son igualmente importantes, es decir algunas palabras aportan poca (o ninguna) información

relevante que nos sirva para la recuperación y la puntuación. También indicamos que estas

palabras eran las que aparecían de manera más frecuente en un documento, esto da paso a las

siguientes consideraciones.

Frecuencia de la inversa del documento

Considerar la frecuencia de los términos en bruto sufre de un problema crítico: todos los

términos son considerados igualmente importantes cuando estos se usan para hallar la relevancia

de un documento para una consulta. Dado que ciertos términos tienen poco o ningún poderío

crítico en determinar la relevancia (como las stop words). Por ejemplo, en una colección de

documentos sobre la auto industria es muy probable que tenga el término auto en casi cada

documento. Para este �n, introducimos un mecanismo para atenuar el efecto de los términos que

ocurren muy frecuentemente en la colección para que sean signi�cativos para la determinación

de la relevancia. Una idea inmediata es escalar el peso del término hasta el peso de los términos

con alta frecuencia de colección, cf de�nido como el número total de ocurrencias de un término

en la colección. La idea va a ser reducir el peso tf de un termino por un factor que crece con

su frecuencia de colección cf (MANNING y cols., 2008).

Sin embargo, ya que lo que intentamos es clasi�car documentos suele ser mejor utilizar un

estadístico a nivel de documento. Entonces utilizamos la frecuencia de documento dft, de�nido

como el número de documentos en la colección que contienen el término t.

En la Tabla 7.1, se ve un simple ejemplo que muestra la diferencia entre la frecuencia de

colección y la frecuencia de documento.

Por lo argumentado, para escalar el peso de un término t utilizamos la frecuencia de la

inversa de un documento (idf) del término t como sigue:

2En general, cualquier función de pesos que mapea el número de ocurrencias de t en d en un numero real.3Trabajar con palabras independientes antes que con oraciones


Palabra cf df

try 10422 8760

insurance 10440 3997

Tabla 7.1: La frecuencia de colección (cf) y la frecuencia de documentos (df) se comportan de

modo diferente, como en el ejemplo de la colección Reuters. Fuente:(MANNING y cols., 2008)

idft = logN

dft

(7.1)

donde, N es el número total de documentos en la colección.

Así el idf de un término poco común es alto, ya que el idf de un término frecuente es

probablemente bajo. El logaritmo está en base 10, aunque la base exacta no es importante para

la clasi�cación.

Pesos tf−idf

Ahora combinamos las de�niciones de frecuencia de término y frecuencia de la inversa del

documento, para generar un peso compuesto para cada término en el documento. El esquema

de pesos tf−idf asigna al término t un peso en el documento d dado por:

tf−idft,d = tft,d ∗ idft (7.2)

En otras palabras, tf−idft,d asigna al término t un peso en el documento d que es:

1. elevado cuando t ocurre muchas veces en un pequeño numero de documentos (así presta

alto poder discriminante a aquellos documentos);

2. disminuye cuando el término ocurre menos veces en un documento, o ocurre en muchos

documentos (así ofrece una menor señal de relevancia);

3. pequeño cuando el término ocurre en prácticamente todos los documentos.

Vector Documento

Para obtener la puntuación de cada documento para una consulta dada, podemos asociar

a cada documento un vector que llamaremos vector documento4, que contendrá campos para

todos los términos del diccionario, junto con un peso para cada término que está dado por la

ecuación 7.2. Para los términos del diccionario que no ocurren en un documento, este peso es

cero. La Figura 7.3, muestra el vector documento para el documento con docID = 1546.

4de manera similar a como se realiza en el modelo vector espaciar.


Figura 7.3: Vector documento para el documento con docID = 1546. Note que el termino

à' tiene puntuación casi nula y el termino àzurduy ' recibe una puntuación muy alta. Fuente:

Elaboración personal.

Utilizaremos este vector para la puntuación y clasi�cación de documentos. Finalmente in-

troducimos la medida de puntuación de superposición: la puntuación de un documento d es la

suma de los pesos tf−idf de cada termino en d.

Puntuacion(c, d) =∑t∈c

tf−idft,d (7.3)

7.2.2. Desarrollo

Está claro que crear un vector documento para cada documento en la colección, sería

sumamente costoso en cuanto a espacio de almacenamiento. Asi que nosotros incorporaremos

la puntuación para cada término en la lista posting de cada documento.

Recuerde la Figura 7.2, en la derecha de esta �gura vemos la estructura de las listas postings

para los términos de los documentos Doc1 y Doc2. La estructura consta de las siguientes

partes: el término, la frecuencia del termino en la colección y la lista posting. La lista posting,

contiene como elementos los docIDs de los documentos que contienen el término. Siguiendo

esta estructura, nosotros modi�camos cada elemento de la lista posting, adicionando además

la puntuación de ese término para el documento dado. Así, claramente podemos incorporar la

puntuación, sin tener con�ictos en cuanto a espacio de almacenamiento pues si un término no

aparece en un documento, ese documento no aparece en la lista posting del término. La Figura

7.4 muestra una lista posting, con la modi�cación que se acaba de explicar.


Figura 7.4: Posting del término azurduy modi�cado, para que se pueda utilizar la puntuación.

Esta es la estructura del índice que utilizaremos en el prototipo. Fuente: Elaboración personal.

Entonces, lo único que tenemos que modi�car para implementar el subsistema de puntuación

en nuestro prototipo, será modi�car las listas posting y calcular la puntuación para cada término

dada por la Ecuación 7.2.

7.3. Indice invertido k-grama

El índice invertido k-grama a diferencia del índice invertido estándar se aplica sobre el

vocabulario de la colección de documentos.

Un k-grama es una secuencia de k caracteres. Así cód, ódi, dig y igo son 3-gramas que

acontecen en el termino código, aunque para tratamiento de comodines de consulta también

suele incluirse los caracteres $ al principio y �n de la cadena y después dividirla en k-gramas

(nosotros no haremos esto, pues utilizaremos el índice k-grama para corrección ortográ�ca).

En un índice k-grama, el diccionario contiene todos los k-gramas que ocurren en cualquier

término del vocabulario. Cada lista posting apunta desde un k-grama a todos los términos del

vocabulario que contienen ese k-grama. La Figura 7.5 muestra una lista posting en un indice

3-grama.

Figura 7.5: Ejemplo de una lista postings en un indice 3-grama. Las coincidencias en el vocabu-

lario de términos son ordenadas lexicogra�camente en el posting. Fuente: (MANNING y cols.,

2008).

Nosotros realizamos un índice 2-grama pues este presenta más sensibilidad a la hora de

corregir errores ortográ�cos aunque requiere más tiempo de cómputo.


7.4. Tratamiento de Consultas

El prototipo que nosotros construiremos sigue el modelo de recuperación de información

booleano. Así que las siguientes consultas se consideran válidas:

autonomía AND ( universitaria OR departamental )

autonomía AND universitaria OR departamental

autonomía /1 universitaria

ley AND ( autonomía /1 universitaria )

etc.

Es decir, todas las consultas se consideran validas si respetan una notación in�ja. Con una

excepción, el operador /k es un operador a nivel de distancia entre términos y no tienen sentido

consultas de este tipo:

ebrios /1 ( consuetudinarios AND quienes )

( consuetudinarios AND quienes ) /1 ebrios

Esto se considera ambiguo pues en el primer caso el prototipo intentara encontrar docu-

mentos que contengan el término ebrios seguido del término consuetudinario y quienes. Lo que

es ambiguo. Pero si planteamos la consulta de diferente forma, podremos obtener resultados.

( ebrios /1 consuetudinarios ) AND ( ebrios /1 quienes )

Además de considerar válida una consulta si respeta una notación in�ja, le asignamos mayor

prioridad al operador /k y los operadores AND, OR se consideran con igual prioridad.

Figura 7.6: Árbol in�jo de una consulta. Fuente: Elaboración personal.


Para el tratamiento de nuestras consultas seguimos los siguientes pasos:

1. Obtenemos la consulta del interfaz.

2. La dividimos en tokens.

3. Creamos un árbol in�jo a partir de los tokens.

4. Realizamos un recorrido post�jo, para crear la expresión post�ja.

5. Finalmente, evaluamos la expresión post�ja obteniendo un resultado.

La Figura 7.6 muestra el árbol de expresión in�jo para la consulta (ebrios /1 consuetudina-

rios) AND cárcel, al realizar el recorrido post�jo generamos una expresión post�ja, siguiendo el

ejemplo tenemos: ebrios consuetudinarios /1 cárcel AND. Al evaluar la expresión obtenemos el

conjunto de resultados correspondientes a la consulta.

Parte IV

Evaluación

87

Capítulo 8

Evaluación del Modelo

En la Sección 2.4 se dio un vistazo a la evaluación de los sistemas de recuperación de

información. Sin embargo, para realizar una buena evaluación del modelo (que desencadena en la

evaluación del prototipo), es necesario describir con más exactitud las medidas que utilizaremos.

Además, debemos considerar el factor humano ya que todas las medidas que utilizamos se basan

en el juicio de relevancia (de un experto en el área), y es lógico pensar que un conjunto de

documentos tras una consulta pueda satisfacer a un usuario, pero no a otro.

En este Capítulo realizamos una evaluación a nuestro modelo utilizando la evaluación de

sistemas de recuperación de información con clasi�cación. Comenzamos revisando a detalle las

medidas que utilizaremos para evaluar nuestro modelo, luego utilizamos el programa trec_eval

para evaluar el prototipo y obtener las evaluaciones de las consultas por separado y en forma

global, �nalmente dibujamos el grá�co de los 11 puntos interpolados de precisión media y

mostramos el Término Medio de Precisión (MAP) obtenido por nuestro prototipo.

A lo largo de este trabajo hemos argumentado que la consideración del idioma es importante,

que la presentación de la información al usuario juega un papel fundamental, entre otros. Ha

llegado el momento de veri�car si nuestra hipótesis es correcta, o si al contrario estos factores

no alteran o alteran poco los resultados devueltos por el sistema.

8.1. Relevancia

Ya de�nimos qué es la relevancia en la Sección 2.4, cuando un documento es considerado

relevante y la base de oro que es la decisión humana de si un documento es relevante o no.

Sin embargo, el concepto mismo de relevancia puede resultar tan sencillo, que puede pasar

desapercibido el hecho de que los humanos (que son los que emiten el juicio de relevancia) no

son una fuente �dedigna del juicio de base de oro, sino que estos presentan juicios peculiares y

variables.

88

CAPÍTULO 8. EVALUACIÓN DEL MODELO 89

El problema mencionado es realmente muy difícil de tratar1, por lo que es necesario espe-

ci�car las características de las personas cuyos juicios consideraremos para la evaluación. Para

ilustrar esto recordemos los elementos de una colección de prueba:

1. Una colección de documentos.

2. Un grupo de prueba de necesidades de información, expresable como consultas.

3. Un conjunto de juicios relevantes, una valoración binaria entre relevante y no relevante

para cada par consulta-documento.

La colección de documentos será la Legislación Boliviana - Compendio de Leyes de 1825

a 2007 presentada por FUNDAPPAC. El grupo de necesidades de información, fue tomado

de 7 profesionales (Secretarios Técnicos de las Brigadas Parlamentarias Departamentales) que

trabajan diariamente con las leyes de Bolivia donde ellos especi�caron su necesidad de informa-

ción. Los juicios de relevancia, se dieron por los mismos profesionales a tiempo de expresar su

necesidad de información (indicando en que número de ley o leyes se encuentra la información

que ellos están buscando), puesto que ellos conocen muy bien el conjunto de leyes sobre el que

se trabajó.

Es posible que el concepto de relevancia, deje descontento a más de uno de los lectores

de este trabajo. A pesar de ser esta la medida actualmente más utilizada en esta área. Sin

embargo, en (MANNING y cols., 2008) se discute sobre las justi�caciones y desventajas de usar

esta medida, además se propone el uso del estadístico kappa utilizado en Ciencias Sociales para

medir el grado de concordancia entre juicios de personas.

8.2. Curva precisión-cobertura

Cuando hablamos de recuperación de información con clasi�cación, los mejores conjuntos

de documentos son determinados por los mejores k documentos recuperados. Para conjunto

originado por una consulta, los valores de precisión y cobertura pueden ser representados por

un grá�co dado por la curva precisión-cobertura.

Esta curva presenta una forma de diente de sierra: si el (k + 1)th documento recuperado

es no relevante entonces la cobertura es la misma que para los mejores k documentos, pero

la precisión sufre un decrecimiento; si este es relevante, entonces ambos precisión y cobertura

incrementan haciendo que la curva forme dientes arriba y a la derecha. Para quitar estos dientes

suele utilizarse la precisión interpolada, en un nivel de cobertura certero r se de�ne como una

alta precisión hallada para cualquier nivel de cobertura r′ ≥ r:

1La Informática, suele tratar de cuanti�car conceptos muy difíciles, como el de información, relevancia,

usabilidad, etc. Aunque con muy buenos resultados.


Figura 8.1: Grá�co precisión/cobertura. Fuente: (MANNING y cols., 2008)

pinterp(r) = maxr′≥r

p(r′) (8.1)

8.3. 11 puntos interpolados de precisión media

Para presentar de una mejor forma la información presentada por la curva precisión-cobertura,

suele utilizarse los 11 puntos interpolados de precisión media. El proceso para realizar este grá-

�co es el siguiente: para cada necesidad de información, la precisión interpolada es medida en

los 11 niveles de cobertura 0.0, 0.1, . . . , 0.1.

Lo anterior se realiza para una sola necesidad de información, pero como el propósito es

concentrar la información para la evaluación del sistema, se utiliza en su mayoría la curva

de precisión-cobertura compuesta que consiste en calcular la media aritmética de la precisión

interpolada para cada nivel de cobertura para cada necesidad de información en la colección de

prueba. Como resultado se obtienen 11 puntos que representan el promedio de los 11 puntos

de precisión-cobertura para un numero n de necesidades de información.

La Figura 8.2, muestra el promedio de los 11 puntos de precisión-cobertura para 50 consultas

en un sistema TREC.


Figura 8.2: Grá�co promedio de 11 puntos interpolados de precisión media a través de 50

consultas para un sistema representativo TREC. El termino medio de precisión para este sistema

es 0.2553. Fuente: (MANNING y cols., 2008)

8.4. Término Medio de Precisión (MAP)

El MAP es el mayor estándar en la comunidad TREC, el cual suministra un único coe�ciente

de medida de calidad a través de los niveles de cobertura, según TREC ha demostrado tener

buena discriminación y estabilidad.

El término medio de precisión (MAP), es la media del valor de precisión obtenido para el

conjunto de los mejores k documentos existentes después de que cada documento relevante es

recuperado, y este valor se promedia sobre la necesidad de información. Es decir, si el conjunto

de documentos relevantes para una necesidad de información qj ∈ Q es {d1, . . . , dmj} y Rjk

es el conjunto de recuperación clasi�cada que proviene de los mejores resultados hasta que se

consiga el documento dk, entonces:

MAP (Q) =1

|Q|

|Q|∑j=1

1

mj

mj∑k=1

Precision(Rjk) (8.2)

Cuando un documento relevante no es recuperado, el valor de precisión en la Ecuación 8.2

empieza por ser 0. Para una única necesidad de información, la media de precisión se aproxima

al área debajo de la curva no interpolada precisión-cobertura, y así el MAP es apenas el área

media por debajo de la curva precisión-cobertura para un conjunto de consultas (MANNING y

cols., 2008).


El uso de MAP, �ja niveles de cobertura que no son elegidos, y no hay interpolacion. El valor

de MAP para una colección de prueba es la media aritmética de valores promedio de precisión

para necesidades individuales de información.

8.5. El evaluador: trec_eval

El programa trec_eval escrito por Chris Buckley, disponible desde el sitio web de TREC

http://trec.nist.gov/trec_eval/. Este es utilizado en las evaluaciones TREC y calcula muchas

medidas de efectividad y recuperación clasi�cada.

Para realizar la evaluación de un sistema de recuperación de información, se siguen los

siguientes pasos:

1. Se crea un conjunto de necesidades de información ( existentes en la colección de docu-

mentos ) expresables en consultas, un mínimo de 50 es aceptable. Estas se realizan por

expertos en el área que abarca la colección de documentos.

2. Cada necesidad de información es creada indicando que documentos la satisfacen (de ahí

la importancia de contar con expertos en el área). Estos se denominan juicios de relevan-

cia, pues se indica que documentos son relevantes para cada necesidad de información,

también son conocidos como QRELS.

3. Con la ayuda de un grupo de personas (de preferencia también profesionales en el área),

se realiza una cantidad de corridas. Cada participante envía una cantidad de corridas que

consisten de los primeros k documentos recuperados ( 1000 como máximo ) para cada

necesidad de información. Un subconjunto de todas estas corridas de cada participante

se considera como una corrida o�cial ( se realiza de esta forma por que la consulta varia

con cada persona ).

4. Se toman los primeros r ( comúnmente 100 ) documentos por necesidad de información de

cada corrida o�cial para formar un grupo combinado para cada necesidad de información,

removiendo duplicados.

5. Con los juicios de relevancia (QRELS) y el conjunto de corridas se procede a la evaluación

con el programa trec_eval.

Usualmente se siguen los pasos anteriores para colecciones pequeñas y especi�cas (es decir

de una sola área). Cuando se trata de colecciones grandes y variadas, suele utilizarse un método

distinto a la hora de obtener los juicios de relevancia, se recomienda la lectura de (TOLOSA

y BORDIGNON, 2007) donde se explica el proceso de evaluación recomendado por el NIST

(Instituto Nacional de Estándares y Tecnología).


8.6. Evaluación del prototipo con trec_eval

Siguiendo los pasos para la evaluación de un sistema de recuperación de información presen-

tados en la sección anterior. Se crea un conjunto de 50 necesidades de información expresables

en consultas (con sus respectivos juicios de relevancia), por profesionales en el área referente a

nuestra colección de documentos (área jurídica).

Los mismos profesionales, proceden a realizar las consultas (corridas) de las cuales se toman

los primeros 10 documentos recuperados para cada necesidad de información. Posteriormente

tomamos subconjuntos que representan las corridas o�ciales de cada profesional, para formar

el grupo combinado para cada necesidad de información.

Finalizamos sometiendo los resultados de las corridas y los juicios de relevancia al programa

trec_eval, obteniendo como resultado los siguientes valores para las medidas revisadas anterior-

mente. Cabe recalcar, que el programa trec_eval, ofrece muchas otras medidas pero nosotros

solo tomamos en cuenta las que consideramos más importantes.

8.6.1. 11 puntos interpolados de precisión media

La Tabla 8.1, muestra el promedio de los 11 puntos interpolados de precisión media, hallados

por el programa de evaluación trec_eval para el sistema de recuperación de información �Yatiri�.

Nivel de Precisión

Cobertura Interpolada

0.00 0.8247

0.10 0.8233

0.20 0.7980

0.30 0.7891

0.40 0.7724

0.50 0.7376

0.60 0.6464

0.70 0.5912

0.80 0.5746

0.90 0.5627

1.00 0.5627

Tabla 8.1: Promedio de los 11 puntos interpolados de precisión media a través de 50 consultas

para el Sistema de Recuperación de Información �Yatiri�. Fuente: Creación Personal.

La Figura 8.3, muestra el Grá�co de los 11 puntos interpolados de precisión media de la

Tabla 8.1. Note que cuando la cobertura es 1.00 la precisión se mantiene alta 0.5627. Es decir,


cuando recuperamos una gran cantidad de documentos (todos los relevantes, cuando existe

cobertura 1.00), mas de la mitad de estos corresponden con la consulta (son relevantes). Y en

general el sistema mantiene una precisión alta (si revisamos el grá�co), esto se debe al tamaño

de la colección (11, 864 documentos) que es muy pequeño y a pesar de haber reducido el umbral

de los mejores k documentos a solo 10.

Figura 8.3: Grá�co promedio de 11 puntos interpolados de precisión media a través de 50

consultas para el sistema de recuperación de información �Yatiri�. El termino medio de precisión

para este sistema es 0.6860. Fuente: Creación Personal.

Son varios los factores que in�uyen en el momento de la evaluación: el criterio de lo mejores

k, la cantidad de necesidades de información y el tamaño de la colección de prueba, sin hablar de

los juicios de relevancia que consideramos correctos. Sin embargo, antes de sacar conclusiones

vale la pena destacar que las colecciones estándar de prueba de sistemas de recuperación con

�nes especí�cos (justamente el tipo de recuperación que estamos realizando) van desde los 1000

documentos hasta 806, 791 documentos y presentan necesidades de información entre 50 y 150

con sus respectivos juicios de relevancia. Si desea conocer cuales son las colecciones estándar

de prueba mas importantes, revise la Sección 8.2 de (MANNING y cols., 2008).

8.6.2. Término Medio de Precisión (MAP)

El valor de precisión obtenido para el conjunto de los 10 mejores documentos existentes

(según el sistema) después de recuperar cada documento relevante, promediado sobre las 50

necesidades de información para el sistema de recuperación de información �Yatiri� es de 0.6860.


Es un buen resultado aunque es necesario recalcar que el valor MAP es una medida que

se encuentra en el intervalo [0, 1]. Nosotros obtuvimos un valor MAP de 0.6860 un resultado

alentador, en este punto seria muy importante contrastar este valor con valores MAP obtenidos

por otros sistemas sobre consultas realizadas en español, lastimosamente tales valores no están

disponibles pues todavía no se realizaron estudios al respecto.

Parte V

Conclusiones

96

Capítulo 9

Conclusiones y Trabajo Futuro

La importancia de la información desde las primeras décadas del hombre moderno ha llevado

al mismo a documentar sus trabajos hasta el punto de contar actualmente con tanta información

que hace difícil pensar siquiera en organizarla. Sin embargo, tras décadas de investigación

hoy podemos contar con herramientas que facilitan el acceso a información que se encuentra

distribuida en diferentes partes del mundo, logrando lo que bien puede llamarse una organización

parcial y virtual de la información. Áreas como la recuperación de información y el tratamiento

del lenguaje natural han jugado un papel fundamental a la hora del diseño de estas herramientas,

lamentablemente estas no han sido desarrolladas especialmente para nuestro idioma, lo que hace

que los resultados obtenidos no sean siempre satisfactorios.

A lo largo de esta trabajo nuestro objetivo ha sido, por un lado, diseñar herramientas que

faciliten el tratamiento de lenguaje natural para el castellano; y por otro, el de adecuar estas

herramientas a un modelo clásico de recuperación de información. Estos dos subobjetivos a

su vez, convergen en uno mucho mas ambicioso que consistente en facilitar y optimizar las

búsquedas en lenguaje natural sobre colecciones de documentos en nuestro idioma.

Para lograr esto hemos tenido que profundizar en el área de la recuperación de información

y el tratamiento de lenguaje natural. Cabe recalcar que la recuperación de información es una

área madura en países de habla inglesa mas no todavía en países de habla hispana, lo mismo

ocurre con el tratamiento de lenguaje natural.

Para tal propósito, hemos diseñado las herramientas para tratamiento lingüístico por separa-

do para luego adecuarlas en el modelo booleano de recuperación de información, no conformes

con esto tomamos los conceptos de recuperación clasi�cada del modelo vectorial y los incorpora-

mos al modelo booleano. Obteniendo como resultado un modelo híbrido diseñado especialmente

para el castellano.

Los principales aportes, de este trabajo son:

1. Breve estudio del idioma Castellano, mostrando como solucionar los problemas que este

representa.

97

CAPÍTULO 9. CONCLUSIONES Y TRABAJO FUTURO 98

2. Hemos desarrollado un modelo de recuperación de información booleano con clasi�cación

para el castellano que aporta lo siguiente:

a) Un modelo booleano con clasi�cación.

b) Un tokenizador diseñado para el castellano.

c) Una mejora al algoritmo de Stemming de Porter SnowBall, incorporando el recorte

de una mayor cantidad de su�jos, obteniendo un mayor grado de normalizacion de

términos.

d) Un corrector ortográ�co para el castellano.

De entre las conclusiones vertidas a lo largo de este trabajo, podemos destacar las siguientes:

1. El lenguaje in�uye de gran manera a la hora de recuperar información. Que puede perci-

birse mas, si se normaliza los términos no solo con el objetivo de lograr una compresión

del indice, sino utilizar también la normalizacion en el proceso de búsqueda.

2. El algoritmo de tokenizado de texto no representa una solución completa, pues la exis-

tencia de errores de escritura o falta de reglas, puede causar que montos, abreviaciones,

etc. no sean tokenizados de manera correcta.

3. El proceso de normalizacion de términos, esta muy lejano todavía. Pero el problema se

hace tratable en buen grado utilizando stemmers o lematizadores, aunque el ultimo casi

siempre depende de un lemario1.

4. La corrección ortográ�ca alcanza niveles bastante aceptables, sin hacer uso de un diccio-

nario de términos.

5. Se da una mejora en la precisión de la recuperación, re�ejado por la medida MAP obtenida

en la etapa de evaluación.

9.1. Lineas de investigación abiertas

Se espera que este trabajo, sea una motivación para el estudio de los siguientes temas:

Planteamiento de nuevos modelos de recuperación de información: actualmente

se esta proponiendo modelos basados en lógica difusa (dejando atrás a la lógica booleana),

y se esta utilizando heuristicos para mejorar la recuperación de información, haciendo que

los sistemas puedan �aprender�, por ejemplo: las preferencias en cuanto a búsqueda de los

usuarios.1Un diccionario de lemas.

CAPÍTULO 9. CONCLUSIONES Y TRABAJO FUTURO 99

Diseño de nuevas herramientas para el tratamiento de lenguaje natural: co-

rrectores ortográ�cos, lematizadores, tokenizadores, etiquetadores, etc. El diseño de un

algoritmo que realice cualquiera de estas tareas de forma e�ciente puede signi�car un

trabajo de investigación muy complejo.

Creación de Corpus lingüísticos y lemarios: actualmente no existen corpus lingüís-

ticos gratuitos para nuestro idioma, que hagan posible el diseño de nuevas herramientas

lingüísticas.

Creación de colecciones especializadas para evaluación de sistemas de recu-

peración de información: no existen colecciones especializadas para la evaluación de

SRI en nuestro idioma. La creación de una de estas colecciones sin lugar a duda puede

representar un gran aporte a la comunidad de investigadores en el área de recuperación

de información.

Parte VI

Anexos

100

Anexo A: Proceso de Evaluación

Para realizar la evaluación, fue necesario contar con los juicios de relevancia de expertos en

el área que corresponda a la colección de documentos. En nuestro caso siendo la colección de

documentos la Legislación Boliviana - Compendio de leyes de 1825 a 2007, era necesario contar

con profesionales que trabajaran con leyes.

Afortunadamente, se contó con la colaboración de siete Secretarios Técnicos de las Brigadas

Parlamentarias Departamentales que trabajan cotidianamente con leyes. Se realizo un taller en

la ciudad de Cochabamba donde estos emitieron sus juicios de relevancia que hicieron posible

la evaluación de este prototipo.

Por tal razón, se adjunta un acta que rati�ca el proceso de evaluación.

101

Anexo B: Documentos

102

Referencias

ALARCON, R. (2000). Diseño orientado a objetos con uml. EIDOS.

ANDIA, E. (2006). Curso elemental de gramática castellana. Airesis.

BAEZA-YATES, R., y RIBEIRO-NETO, B. (1999). Modern information retrieval. Addison-

Wesley.

BASSI, A. (n.d.). Lematización basada en análisis de corpus no etiquetados. Departamento de

Ciencias de la Computación, Universidad de Chile.

BENGOCHEA, L., y PATRICIO, M. A. (2005, Junio). Sistemas de visualizacion para bibliotecas

digitales. Revista Española de Documentacion Cienti�ca, 28 .

BUNGE, M. (n.d.). La ciencia. su método y su �losofía.

CONALLEN, J. (2002). Building web application with uml (Second ed.). Addison-Wesley.

FERNANDEZ, P. M., y SERRANO, A. G. (n.d.). Utilizando recursos linguisticos para mejora de

la recuperación de información en la web. Universidad Carlos III de Madrid, Departamento

de Informatica, Grupo de Bases de Datos Avanzadas.

FIGUEROLA, C. (n.d.). La investigación sobre recuperacion de la información en español.

Facultad de Documentación, Universidad de Salamanca.

GARCIA, F., y GROSS, J. P. V. (1987). Pequeño larousse ilustrado. Sebastián de Amorrortu

e hijos.

GARCIA, L. J. L. (2002). Automatización del análisis sintáctico del español. Tesis doctoral no

publicada, Universidad de Las Palmas de Gran Canaria.

HERENCIA, V. J. P. (2004). Uso de sintagmas alineados como recurso de traducción en un

enfoque híbrido para recuperacion de información translingue. Departamento de Lenguajes

y Sistemas Informáticos ETS. de Ingeniería Informática - UNED.

HERRERA, D. A. G. L. (2006). Modelos de sistemas de recuperación de información documental

basados en información lingüística difusa. Tesis doctoral no publicada, Universidad de

Granada - Escuela Técnica Superior de Ingeniería Informática - Departamento de Ciencia

de la Computación e Inteligencia Arti�cial.

MANNING, C. D., RAGHAVAN, P., y SCHÜTZE, H. (2008). An introduction to in-

formation retrieval. Cambridge University Press, England. Available from http://

www.informationretrieval.org/

MENDEZ, F. J. M. (2002). Propuesta y desarrollo de un modelo para la evaluación de la

103

http://www.informationretrieval.org/

http://www.informationretrieval.org/

Referencias 104

recuperación de información en internet. Tesis doctoral no publicada, Universidad de

Murcia - Facultad de Ciencias de la Documentación, Departamento de Información y

Documentación.

MUNDOLENGUAJE. (2007). Las abreviaturas. Pagina Web. Available from http://www

.todo.com.uy/lenguaje/mundoleng.htm

PADILLA, A. P. (2005, Febrero). Técnicas linguísticas aplicadas a la búsqueda multilingue: Am-

biguedad, variación terminilógica y multilinguismo. Revista Española de Documentacion

Cienti�ca, 28 , 239-240.

PORTER, M. F. (1980, Julio). An algorithm for su�x stripping.

PRESSMAN, R. S. (2007). Ingeniería del software - un enfoque practico (Sexta ed.). Mc Graw

Hill.

RIJSBERGEN, C. J. (n.d.). Information retrieval (U. of Glasgow, Ed.). Department of Com-

puting Science.

RODRIGUEZ, H. (2007). Apuntes de tratamiento de lenguaje natural. Departamento de

Lenguajes y Sistemas Informáticos. Universidad Politécnica de Catalunya.

SALAZAR, M. E. R., HERNÁNDEZ, S. A., y NUÑEZ, E. B. (2006). Coe�cientes de asociacion.

Plaza y Valdez.

SCHMULLER, J. (n.d.). Aprendiendo uml en 24 horas. Prentice Hall.

TOLOSA, G., y BORDIGNON, F. (2007). Introducción a la recuperación de información -

conceptos, modelos y algoritmos básicos. Departamento de Ciencias Basicas - Universidad

Nacional de Luján, Argentina.

VALLEZ, M., y PEDRAZA, R. (2007, 12 Mayo). El procesamiento del lenguaje natural en la

recuperación de información textual y áreas a�nes. Hipertext .NET , 5 . Available from

http://www.hipertext.net

http://www.todo.com.uy/lenguaje/mundoleng.htm

http://www.todo.com.uy/lenguaje/mundoleng.htm

http://www.hipertext.net

Documents

T-1692