Modelo multi agente que personaliza el material de

estudio en grupos colaborativos

Pablo Santana Mansilla1,2 y Rosanna Costaguta1

1
Instituto de Investigación en Informática y Sistemas de Información (IIISI)
Facultad de Ciencias Exactas y tecnologías (FCEyT)
Universidad Nacional de Santiago del Estero (UNSE)
2
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
{psantana, rosanna}@unse.edu.ar

Resumen. El uso de ambientes de Aprendizaje Colaborativo Soportado por

Computador en los procesos de enseñanza y de aprendizaje se ha expandido en
la última década. Estos ambientes cuentan con variadas herramientas de colabo-
ración, comunicación y coordinación que los estudiantes y docentes pueden uti-
lizar sin depender del tiempo ni el lugar desde donde lo hagan. Sin embargo,
por diferentes razones, alcanzar el aprendizaje esperado no está garantizado. En
este artículo se presenta un modelo multi agente aplicable a grupos de estudian-
tes colaborativos que personaliza la recuperación de material de estudio cuando
los mismos plantean dudas o manifiestan vacíos de conocimiento. Además, se
documenta la experimentación realizada con la herramienta Lucene en el análi-
sis y recuperación de material de estudio escrito en inglés y en español.

Palabras clave: agentes de software; aprendizaje colaborativo soportado por

computadora; personalización; recuperación de información.

1. Introducción
Con el rápido desarrollo de la sociedad basada en conocimiento ha crecido la im-
portancia que se le da a la creación colaborativa de conocimientos. En este contexto,
el Aprendizaje Colaborativo Soportado por Computadora (ACSC) se ha vuelto una
nueva forma de educación donde los estudiantes aprenden por medio de la interacción
con personas que pueden estar localizadas en marcos temporales y espaciales diferen-
tes [14]. Sin embargo, disponer de herramientas de software que soporten el aprendi-
zaje en grupo no garantiza que los estudiantes colaboren, puesto que factores tales
como: conocimiento insuficiente en el área de contenido, falta de acceso a recursos
apropiados, carencia de conocimiento en cómo usar recursos, déficit de habilidades, y
problemas con los materiales del curso, pueden obstaculizar el proceso de aprendizaje
de los estudiantes [6], [7], [8], [9], [15]. De acuerdo con Varvel [15] es responsabili-
dad de los e-tutores (docentes) identificar estos obstáculos en el aprendizaje grupal
para brindar asistencia en el momento adecuado y con los métodos apropiados.
En los entornos de ACSC se dispone de un registro completo de las actividades e
interacciones de los estudiantes. Un análisis posterior de este conjunto de actividades
e interacciones le tendría que permitir a los e-tutores reconocer la presencia de los
2 Modelo multi agente que personaliza el material de estudio en grupos colaborativos

obstáculos del proceso de aprendizaje antes mencionados. Pero, cuando se tiene una
cantidad considerable de interacciones el análisis manual es prácticamente inviable
debido al tiempo y esfuerzo que requiere [2], [10]. Además, la coordinación de discu-
siones supone para los e-tutores de ACSC una enorme demanda tanto temporal
como cognitiva, sobre todo cuando se tienen varios grupos trabajando en simultáneo
[11]. Si también se tiene en cuenta que los e-tutores podrían no ingresar al sitio del
curso por un largo tiempo debido a problemas de salud, viajes, problemas de cone-
xión, etc., queda claro que el proceso de aprendizaje grupal se vería ralentizado si los
estudiantes no fueran capaces de resolver por su cuenta los obstáculos que surjan a lo
largo de una actividad o curso [13].
En base a lo mencionado en el último párrafo, se propone un modelo multi agente
para tratar específicamente con el problema de conocimiento insuficiente en el área de
contenido. En el modelo propuesto, un agente se encargará de analizar las interaccio-
nes grupales con el fin de identificar temas o áreas de contenido donde los estudiantes
tengan dudas o dificultades. Detectada la falencia de conocimiento, otro agente suge-
rirá a los estudiantes los materiales de estudio (presentaciones power point, libros,
monografías, páginas web, videos, etc.) que podrían consultar para resolver su duda o
dificultad. En estos casos se alertará al docente para que asista a los estudiantes a fin
de lograr la completitud de la tarea o actividad.
Con este modelo multi agente se pretende aliviar la carga de trabajo de los docen-
tes, al igual que contribuir a que los estudiantes sean menos dependientes del docente.
Para los estudiantes el contar con un sistema que les recomiende los contenidos a
revisar les ayudaría a administrar mejor su propio tiempo ya que muchas veces están
limitados en este aspecto y no tienen la posibilidad de revisar todo el material de estu-
dio. Esta situación se agrava si se considera que muchos estudiantes universitarios
combinan sus estudios con trabajos de medio tiempo.
El reconocimiento de falencias en el conocimiento y la posterior recomendación
de los materiales de estudio no es tarea sencilla sobre todo cuando se trabaja con ma-
teriales escritos en más de un idioma. La búsqueda y recuperación de información
desde materiales escritos en múltiples idiomas es justamente el principal foco de aten-
ción de este trabajo. En el presente documento se hace la evaluación de la viabilidad
de utilizar Lucene como motor de búsqueda multilingüe dentro del modelo multi
agente de recomendación de material de estudio, en particular, libros.
El resto del documento se estructura como sigue. En la sección 2 se describe en
detalle el modelo multi agente de recomendación de material de estudio. En la sección
3 se presentan los métodos comúnmente usados para la búsqueda en documentos
multilingüe. En la sección 4 se describe el proceso de experimentación con diferentes
analizadores y filtros de Lucene. En la sección 5 se presenta la interfaz de usuario
sugerida para implementar el modelo multi agente propuesto. Finalmente, la sección 6
contiene algunas conclusiones.

2. Modelo de recomendación de material de estudio

La Figura 1 muestra un esquema del modelo multi agente para detección de falen-
cias en el conocimiento de los estudiantes y para recomendación de materiales de
3 Pablo Santana Mansilla y Rosanna Costaguta

estudio que puedan contribuir a rellenar esos vacíos en el conocimiento de los estu-
diantes.

Fig. 1. Representación gráfica del modelo multi agente de recomendación de mate-

riales de estudio

En el modelo existe un agente Detector de Carencia de Conocimiento que va a

monitorear las interacciones grupales con el propósito de identificar temas o conteni-
dos que generen dificultades o dudas en los estudiantes y que sean necesarios para
completar una actividad. Para examinar las interacciones en busca de carencias de
conocimiento podrían utilizarse técnicas de minería de textos, o una aproximación
más simple basada en palabras clave. Con la segunda alternativa frases tales como
“Tengo dudas”, “No me queda claro”, “No entiendo”, “Esta técnica es muy complica-
da”, etc., estarían señalando que los alumnos poseen dificultades con los temas cu-
biertos por el curso o actividad. A la hora de analizar las comunicaciones grupales el
agente Detector de Carencia de Conocimiento también necesitaría tener en cuenta
cuales son los Conocimientos Requeridos y algún Método de Reconocimiento de Ca-
rencia de Conocimiento para distinguir situaciones donde las palabras clave (en el
caso de que se use esta técnica) señalan y no señalan faltantes de conocimiento. Po-
dría darse por ejemplo, que un alumno no conozca un tema pero que uno de sus com-
pañeros tenga conocimientos previos sobre el mismo. Una vez detectada la carencia
en el conocimiento de los estudiantes, el agente Detector de Carencia de Conocimien-
to informará al e-tutor y al agente Recomendador de Materiales de Estudio el tema o
contenido que los estudiantes deberían aprender. Notificado sobre una falencia en el
conocimiento de los estudiantes, el agente Recomendador de Materiales de Estudio le
consultará al agente Buscador de Materiales de Estudio sobre los materiales de estu-
dio que contienen información sobre el tópico que los estudiantes necesitan aprender.
Una vez que el agente Buscador de Materiales de Estudio indique los materiales de
4 Modelo multi agente que personaliza el material de estudio en grupos colaborativos

aprendizaje que podrían servirles a los estudiantes, el agente Recomendador de Mate-

riales de Estudio seleccionará el material teniendo en cuenta un perfil del grupo (esti-
los de aprendizaje, lenguaje nativo, discapacidades, etc.) y el historial de recomenda-
ciones. Luego de realizar la selección, el agente Recomendador de Materiales de
Estudio se comunicará con el grupo de estudiantes para sugerirles los materiales que
podrían consultar. Además de intervenir por solicitud del agente Detector de Caren-
cia de Conocimiento, el agente Buscador de Materiales de Estudio se activará cuando
los estudiantes deseen buscar materiales de aprendizaje sobre un tema concreto. El
agente Buscador de Materiales de Estudio tendrá la responsabilidad de pre procesar
las consultas tanto de los estudiantes como del agente Recomendador de Materiales
de Estudio (identificando tokens, eliminando stop words, realizando conversión a
minúsculas, etc.). Para indexar los materiales de estudio, así como realizar búsquedas
en el índice invertido, el agente Buscador de Materiales de Estudio recurrirá a Lucene
para realizar el análisis y la recuperación de información sobre materiales de estudio
escritos en más de un lenguaje.
Un aspecto a destacar del modelo multi agente propuesto es que el reconocimiento
de las carencias de conocimiento se hará de manera no intrusiva, esto es, la dinámica
grupal no se verá afectada. La evaluación del nivel de conocimiento de los estudiantes
suele hacerse mediante técnicas tales como cuestionarios [12], pero esta modalidad
implica que los alumnos se desvíen de las actividades que están realizando para con-
centrarse en contestar el cuestionario.

3. Métodos de búsqueda de documentos multilingües

El campo de la Recuperación de Información Multilingüe (RIM) aborda el proble-
ma de usar consultas en un lenguaje y recuperar documentos en varios lenguajes [5].
La estrategia comúnmente utilizada para resolver este problema es la traducción. Da-
do que el lenguaje de la consulta difiere del lenguaje de los documentos y que es ne-
cesario comparar la representación de la consulta con la de los documentos para esta-
blecer que tan similares son, se debe optar por traducir la consulta al lenguaje de los
documentos o por traducir los documentos al lenguaje de la consulta [5]. La traduc-
ción de los documentos o de la consulta puede hacerse mediante técnicas de traduc-
ción de máquina, métodos basados en corpus o basados en diccionario. No obstante,
ninguna de las tres aproximaciones ofrece una traducción perfecta ya que tienen difi-
cultades al tratar con: conceptos y frases compuestas por múltiples términos, vocabu-
lario que no forma parte del diccionario o corpus, y la ambigüedad [1].
Considerando las falencias de los métodos de traducción que se han venido em-
pleando en RIM y que se pretende recomendar materiales de estudio escritos en más
de un idioma, se necesita una estrategia o mecanismo que permita buscar pero sin
traducir la consulta ni los materiales de estudio. Se considera que una posible solución
a este dilema podría ser incorporar a Lucene como un componente del agente Busca-
dor de Materiales de Estudio que forma parte del modelo multi agente representado
en la Figura 1. Lucene cuenta con recursos de procesamiento de textos que son tanto
independientes del idioma como específicos para cada idioma. Por lo tanto, es necesa-
rio establecer qué recurso o combinación de recursos de Lucene permiten efectuar
búsquedas en un índice invertido construido a partir de documentos escritos en más de
5 Pablo Santana Mansilla y Rosanna Costaguta

un idioma. El hecho de trabajar con los materiales de estudio escritos en más de un

idioma es uno de los aspectos más desafiantes del proceso de desarrollo del agente
Buscador Materiales de Estudio porque plantea interrogantes tales como: ¿se debe-
rían utilizar analizadores para cada idioma?, ¿conviene emplear un analizador genéri-
co que sea independiente del idioma?, ¿se debería construir un solo índice para todos
los idiomas o un índice separado para cada idioma?, ¿se van a permitir realizar bús-
quedas por idioma?, etc.

4. Búsqueda de Documentos Multilingüe Mediante Lucene

Tal como se mencionó en la introducción, en el presente trabajo se pretenden eva-
luar las capacidades de Lucene para analizar y recuperar información sobre materiales
de aprendizaje escritos en más de un lenguaje. Si bien la idea es que los materiales de
estudio puedan estar escritos en varios idiomas y ser de múltiples tipos (presentacio-
nes power point, monografías, páginas web, etc.), a modo de evaluación inicial de
Lucene se optó por trabajar solamente con información sobre libros escritos inglés y
en español. Concretamente, se utilizó información sobre 200 libros pertenecientes a la
biblioteca del Departamento de Informática de la Facultad de Ciencias Exactas y Tec-
nologías (FCEyT) de la Universidad Nacional de Santiago del Estero (UNSE). De
esos 200 libros, el 76% está escritos en español y el 24% restante en inglés. En las sub
secciones incluidas a continuación se definen los campos que forman parte del índice
invertido, se detallan los campos por los cuales se pueden hacer búsquedas, se intro-
duce la noción de relevancia junto con las métricas empleadas para evaluar los resul-
tados de las búsquedas, y se describen los resultados de la experimentación realizada
con diversos analizadores y filtros de Lucene.

4.1 Definición de los campos a indexar

En la biblioteca del Departamento de Informática, para cada libro se mantiene un
archivo de texto plano que contiene la siguiente información: Autores (nombre de los
autores separados mediante una coma), Título (título bajo el cual fue publicado el
libro), Editorial (nombre de la editorial que lo publicó), Año (año en que se lo publi-
có), Original Cantidad (cantidad de ejemplares originales con los que se cuenta), Ori-
ginal Código (código alfanumérico que permite localizar el libro en las estanterías de
la biblioteca), Fotocopia cantidad (cantidad de ejemplares fotocopiados disponibles),
ISBN (número de ISBN, con los dígitos separados mediante guion medio sin guio-
nes), Fecha Alta Biblioteca (fecha en que se adquirió el ejemplar), Índice (índice de
contenidos del libro). Partiendo de los archivos de texto plano que contienen informa-
ción sobre los libros se tuvo que determinar cuáles campos se iban a indexar y cuáles
se iban a almacenar sin indexar. En el proceso de definición de los campos se tuvo
como primer objetivo reducir el tamaño del índice, de modo tal que la información
enviada por el agente Buscador de Materiales de Estudio fuera la mínima posible,
tanto en respuesta a las consultas del agente Recomendador de Materiales de Estudio
como a las efectuadas por los estudiantes. Analizada la información de los archivos de
texto plano se llegó a la conclusión que en el índice invertido se tenían que incorporar
los campos path e idioma. El campo path señala la localización del archivo de texto
6 Modelo multi agente que personaliza el material de estudio en grupos colaborativos

plano con información del libro. Este campo se utiliza para acceder al número de
ISBN y al índice de contenidos cuando el usuario desee ver más detalles de algún
libro en particular. En tanto que, el campo idioma indica el lenguaje en el que está
escrito el archivo de texto plano. La Tabla 1 detalla las características de los campos
con información sobre los libros que forman parte del índice invertido.

4.2 Campos utilizados para realizar búsquedas en el índice

invertido
De los ocho campos del índice invertido descriptos en la Tabla 1 solo cuatro se uti-
lizaron para buscar información sobre los libros. A continuación se describen detalle
de las búsquedas que se pueden realizar por nombre de autor, título de libro, índice de
contenidos, y número de ISBN.
En las consultas por nombre de autor no solo se buscó que el índice invertido con-
tuviera ocurrencias exactamente iguales al texto de la consulta sino también nombres
similares al de la consulta. La búsqueda de nombres similares es posible gracias al
operador de búsqueda difusa (~) que calcula la similitud de los términos en base al
algoritmo de la distancia de Levenshtein [3]. Con la incorporación del operador de
búsqueda difusa la sintaxis para buscar por nombre de autor es: Autores:NombreAutor
OR Autores: NombreAutor~
A la hora de realizar búsquedas por el campo título también se utilizó el operador
de búsqueda difusa, por lo cual, la expresión para buscar por título sería: Titulo: Titu-
loLibro OR Titulo: TituloLibro ~
Mediante una expresión del tipo ISBN:ISBNLibro OR ISBN:ISBNLibro~ se busca-
ron coincidencias exactas así como también aproximadas del campo número de ISBN.
La consulta con mayor grado de complejidad es la realizada por palabra clave, ya
que consiste en buscar en los campos Autor, Título, ISBN e Índice la presencia de los
términos que forman parte de la consulta. Esto significa que Palabra Clave no se refie-
re en realidad a un campo sino más bien incluye una serie de campos. Con la incorpo-
ración del operador de búsqueda difusa, la búsqueda por palabra clave tendría la si-
guiente estructura: (Autores:palabraClave OR Autores: palabraClave~)^1.6 OR (Ti-
tulo: palabraClave OR Titulo: palabraClave~)^2 OR (Indice: palabraClave OR Indi-
ce: palabraClave~) ^1 OR (ISBN: palabraClave OR ISBN: palabraClave~)^1.3
El operador ^ (operador de boosting) se incluyó en la expresión anterior para lograr
que la importancia dada a los documentos recuperados por el buscador varíe en fun-
ción del campo en el cual aparezcan los términos de la consulta. El uso de boosting
podría requerir un estudio en un escenario de uso real para determinar a cual campo o
aspecto de la información de un libro los usuarios le dan mayor importancia, o mejor
dicho, lo utilizan con más frecuencia para realizar las búsquedas. Sin embargo, en el
presente trabajo se considera que en los resultados de las búsquedas deben aparecer en
primer lugar los libros que contengan los términos de la consulta en el campo Titulo,
seguidos de los libros donde los términos de la consulta aparezcan en los campos
Autores y número de ISBN, y finalmente los libros que tienen los términos de la con-
sulta en el campo Índice.
7 Pablo Santana Mansilla y Rosanna Costaguta

Tabla 1. Descripción de los campos del índice invertido

Nombre de Características
Campo
Autores Tipo de campo: TextField
Field.Store.YES: como resultado de la búsqueda se muestra a los usuarios el nombre de
los autores de los libros.
Field.Index.YES: se realizan búsquedas en base al nombre de los autores de los libros.
Titulo Tipo de campo: TextField
Field.Store.YES: como resultado de la búsqueda se muestra a los usuarios el título de los
libros.
Field.Index.YES: se realizan búsquedas en base al título de los libros.
ISBN Tipo de campo: StringField
Field.Store.NO: como resultado de la búsqueda no se muestra a los usuarios el ISBN de
los libros.
Field.Index.YES: se realizan búsquedas en base al número de ISBN de los libros.
Año Tipo de campo: StringField
Field.Store.YES: como resultado de la búsqueda se muestra a los usuarios el año de publi-
cación de los libros.
Field.Index.NO: solo se necesita recuperar el año de publicación de los libros y no se
realizan búsquedas por este campo.
Indice Tipo de campo: TextField
Field.Store.NO: como resultado de la búsqueda no se muestra a los usuarios el índice de
contenidos de los libros.
Field.Index.YES: se realizan búsquedas en el índice de contenidos de los libros.
Editorial Tipo de campo: StringField
Field.Store.YES: como resultado de la búsqueda se muestra a los usuarios la editorial que
publicó cada uno de los libros.
Field.Index.NO: solo se necesita recuperar el nombre de la editorial que publicó cada libro
y no se realizan búsquedas por este campo.
Path Tipo de campo: StringField
Field.Store.YES: el índice invertido almacena la ruta de acceso al archivo de texto plano
que contiene información de cada libro pero la localización de los archivos no se muestra
a los usuarios.
Field.Index.NO: solo se necesita recuperar la localización de los archivos de texto plano
que contienen información sobre los libros y no se realizan búsquedas por este campo.
Idioma Tipo de campo: StringField
Field.Store.NO: como resultado de la búsqueda no se muestra a los usuarios el idioma en
el cual están escritos los libros.
Field.Index.YES: se pueden buscar libros en base al idioma en el que estén escritos.

4.3 Noción de relevancia para evaluar resultados de la búsqueda

La determinación de la relevancia de los resultados de la consulta es algo totalmen-
te subjetivo que depende de factores tales como: ser del tema correcto, ser apropiado
en tiempo, provenir de una fuente confiable, y satisfacer los objetivos del usuario.
Esto indica que una buena evaluación de relevancia de los resultados arrojados por el
agente Buscador de Materiales de Estudio tendría que realizarse con usuarios reales,
es decir, estudiantes trabajando en un entorno de ACSC. Dado que no existió la posi-
bilidad de una evaluación de relevancia con usuarios reales, para comparar los dife-
rentes recursos que brinda Lucene para la recuperación de información, se recurrió a
las siguientes dos nociones de relevancia que son menos subjetivas que el considerar
si los resultados de la búsqueda son de utilidad al uso que pretende darles el usuario:
8 Modelo multi agente que personaliza el material de estudio en grupos colaborativos

 Un documento es relevante si las palabras de la consulta aparecen frecuentemente

en el documento, en cualquier orden.
 Si las palabras de la consulta no aparecen frecuentemente en el documento, se
considerará que el documento es relevante cuando no haya una diferencia superior
al 30% entre los caracteres que forman parte de la consulta y los caracteres de las
palabras que aparecen en los documentos.
En Tabla 2 se ilustra la noción de relevancia mediante una consulta por nombre de
autor y sus hipotéticos resultados arrojados.

Tabla 2. Ejemplo de aplicación de la noción de relevancia

Consulta Resultados de la Búsqueda % de Coincidencia Relevante
James Autor: Baeza James 100% Si
Baeza Título: Administracion. 6ta Edicion
Autor: Arnold Ken, Baeza Jane 80% Si
Título: Object-Oriented Simulation: Reus-
ability, Adaptability, Maintainability
Autor: Senn James A. 50% No
Título: Análisis y Diseño de Sistemas de
información
Autor: Hammer Michael , Baez Marian 40% No
Título: Reingeniería

4.4 Proceso de selección del analizador

En esta sección se introducen en primer lugar las métricas que se utilizaron para
evaluar los resultados arrojados por Lucene ante diferentes consultas de prueba. Se-
guidamente, se incluyen los valores de estas métricas para diferentes analizadores,
filtros y combinaciones de analizadores y filtros de Lucene con los cuales se experi-
mentó.

4.4.1 Métricas de evaluación de los analizadores

Para comparar los resultados de las búsquedas obtenidos al aplicar diferentes anali-
zadores y filtros disponibles en Lucene se emplearon las métricas de precisión y recall
[4]. La precisión hace referencia a la fracción de documentos recuperados que son
relevantes para la consulta, es decir a la fracción de documentos recuperados que
cumplen con la noción de relevancia introducida en la sección 4.3. Por su parte, el
recall indica la fracción de documentos relevantes recuperados entre todos los docu-
mentos relevantes almacenados en el índice invertido.
Los valores de las métricas precisión y recall se calcularon a partir de las 86 con-
sultas de prueba diseñadas para evaluar las capacidades de Lucene. Las 86 consultas
de prueba se distribuyen de la siguiente manera: 15 para evaluar las búsquedas por el
campo Autores, 15 para evaluar las búsquedas por el campo Titulo, 8 para evaluar las
búsquedas por el campo ISBN y 48 para evaluar las búsquedas por palabra clave.
9 Pablo Santana Mansilla y Rosanna Costaguta

4.4.1.1 Experimentación con StandardAnalyzer

StandardAnalyzer descompone el texto en tokens (mediante StandardTokenizer),
lo convierte a minúsculas (recurriendo a LowerCaseFilter) y elimina las stop words
(con StopFilter). Durante la eliminación de stop words no se tuvo en cuenta la lista de
stop words que por defecto se usa en Lucene sino que se la reemplazó por las stop
words incluidas en el software de minería de textos tm1. La Tabla 3 contiene el valor
de las métricas de precisión y recall obtenidos para los diferentes campos de búsqueda
al usar StandardAnalyzer, así como también el promedio.

Tabla 3. Precisión y recall para las búsquedas realizadas con Standard Analyzer
Campo Busqueda Precisión Recall
Autores 0,700925926 0,916667
Titulo 0,159775154 0,966667
ISBN 1 0,875
Palabra Clave 0,445478933 0,764238
Promedio 0,576545003 0,880643

4.4.1.2 Experimentación con SimpleAnalyzer

SimpleAnalyzer combina LowerCaseFilter con LetterTokenizer para convertir el
texto a minúsculas y separarlo en tokens. En la Tabla 4 se muestra la precisión y el
recall para las consultas de prueba procesadas con Simple Analyzer.

Tabla 4. Precisión y recall de búsquedas realizadas con SimpleAnalyzer

Campo Búsqueda Precisión Recall
Autores 0,700925926 0,916667
Titulo 0,070947866 0,966667
ISBN 1 0,875
Palabra Clave 0,516419024 0,755558
Promedio 0,572073204 0,878473

SimpleAnalyzer se diferencia de StandardAnalyzer por el hecho de no incluir la

operación de eliminación de stop words. Con el propósito de determinar si la elimina-
ción de stop words conducía a los mismos valores de precisión y recall mostrados en
la Tabla 4, se combinó SimpleAnalyzer con StopFilter. Para lograr esta combinación
se tuvo que crear una extensión de la clase Analyzer de Lucene que reuniese Lower-
CaseFilter, LetterTokenizer y StopFilter en un solo analizador. La Tabla 5 incluye las
cifras de precisión y recall para SimpleAnalyzer cuando se le agrega la eliminación de
stop words en inglés mientras que, la Tabla 6 cuando se suprimen stop words del
español y del inglés.

1
http://tm.r-forge.r-project.org/
10 Modelo multi agente que personaliza el material de estudio en grupos colaborativos

Tabla 5. Precisión y recall de búsquedas realizadas combinando SimpleAnalyzer

con supresión de stop words en inglés
Campo Búsqueda Precisión Recall
Autores 0,788888889 0,916667
Titulo 0,159672472 0,933333
ISBN 1 0,875
Palabra Clave 0,524958534 0,743405
Promedio 0,618379974 0,867101

Tabla 6. Precisión y recall de búsquedas realizadas combinando SimpleAnalyzer

con supresión de stop words en inglés y en español
Campo Búsqueda Precisión Recall
Autores 0,722222222 0,916667
Titulo 0,191201343 0,9
ISBN 1 0,875
Palabra Clave 0,623178033 0,715014
Promedio 0,6341504 0,85167

4.4.1.3 Experimentación con SnowballAnalyzer

Mediante SnowballAnalyzer el texto del documento se convierte a minúscula
(LowerCaseFilter) y se realiza la eliminación de stop words (StopFilter ). SnowballA-
nalyzer no solo reconoce los diferentes tipos de tokens presentes en los documentos
(StandardTokenizer ) sino que también reemplaza los tokens por su forma raíz o stem.
Así, por ejemplo, las palabras “tornado”, “tornar” y “tornen” son reducibles al stem
“torn”. Puesto que SnowballAnalyzer ofrece algoritmos de stemming específicos para
cada idioma, a los documentos en español se los procesó con el algoritmo de stem-
ming para español, mientras que a los documentos en inglés se les aplicó el algoritmo
de stemming para inglés. La Tabla 7 muestra los valores de precision y recall para las
búsquedas realizadas aplicando SnowballAnalyzer.

Tabla 7. Precisión y recall de búsquedas realizadas empleando SnowballAnalyzer

Campo Busqueda Precisión Recall
Autor 0,744444444 0,916667
Titulo 0,121646835 1
ISBN 1 0,875
Palabra Clave 0,445848036 0,823365
Promedio 0,577984829 0,903758

4.4.1.4 Experimentación con SpanishAnalyzer

El hecho de que SpanishAnalyzer cuente con algoritmos de separación en tokens y
stemming que sean específicos para el idioma español sin duda ofrece ventajas al
procesar textos en español. No obstante, el aplicar estos algoritmos a documentos en
inglés puede conducirnos a resultados impredecibles. Por este motivo, se decidió pro-
cesar los documentos en español con SpanishAnalyzer y aplicar StandardAnalyzer
sobre los documentos en inglés. En Tabla 8 se incluyen los valores de las dos métricas
11 Pablo Santana Mansilla y Rosanna Costaguta

de evaluación de relevancia aplicadas a los resultados de las búsquedas efectuadas

combinando SpanishAnalyzer con StandardAnalyzer.

Tabla 8. Precisión y recall de búsquedas realizadas empleando SpanishAnalyzer

junto con StandardAnalyzer
Campo Busqueda Precisión Recall
Autor 0,744444444 0,916667
Titulo 0,115749151 0,933333
ISBN 1 0,875
Palabra Clave 0,486102754 0,79584
Promedio 0,586574087 0,88021

4.4.1.5 Experimentación con EnglishAnalyzer y SpanishAnalyzer

La última combinación de analizadores con la que se probó es EnglishAnalyzer y
SpanishAnalyzer. Cada uno de estos analizadores cuenta con algoritmos de descom-
posición en tokens y stemming específicos para cada idioma. Por esta razón, los do-
cumentos en español se analizaron con SpanishAnalyzer y los documentos en inglés
se procesaron con EnglishAnalyzer. Los resultados para las métricas de precisión y
recall pueden verse en la Tabla 9.

Tabla 9. Precisión y recall de búsquedas realizadas empleando SpanishAnalyzer

junto con EnglishAnalyzer
Campo Busqueda Precisión Recall
Autor 0,744444444 0,916667
Titulo 0,128336196 1
ISBN 1 0,875
Palabra Clave 0,461371392 0,802119
Promedio 0,583538008 0,898446

4.4.2 Comparación de los experimentos con analizadores

Las Figuras 2 y 3 muestran el promedio de las cifras de precisión y recall para los
experimentos realizados con los Analizadores de Lucene mencionados desde el apar-
tado 4.4.2.1 al apartado 4.4.1.5. El examen de estas dos figuras permite afirmar que
no existen diferencias sustanciales en la relevancia de los resultados de las búsquedas
ya sea que se utilice uno u otro analizador. El recall es siempre superior al 0.85 por lo
cual se puede afirmar que con cualquiera de los analizadores o combinación de anali-
zadores es posible recuperar casi la totalidad de los documentos que son relevantes
para las consultas. La precisión en la mayoría de los casos no llega al 0.6, y si bien
está cifra es aceptable, indica que alrededor del 40% de los resultados mostrados a los
usuarios no son relevantes para su consulta.
Si se considera solamente la precisión, en la Figura 2 puede verse que Sim-
pleAnalyzer se destaca por sobre el resto de los analizadores ya que permite lograr
que alrededor del 0.63 de los resultados sean relevantes para las búsquedas. Los valo-
res de las Tablas 4, 5, y 6 dejan en evidencia que la eliminación de stop words mejora
la precisión de las búsquedas ya que, con la incorporación de las stop words en espa-
12 Modelo multi agente que personaliza el material de estudio en grupos colaborativos

ñol e inglés se pasó del 0.57 (SimpleAnalyzer sin stop words) al 0.63. A su vez, este
incremento en la precisión no tiene aparejada una disminución significativa del recall
(ver Figura 3).
Una revisión de las cifras incluidas en Tablas 4 a 9 pone en evidencia que mien-
tras la precisión para las búsquedas por el campo Título no supera el 0.19, en las bús-
quedas por el resto de los campos la precisión es siempre mayor al 0.44. Esto significa
que, las consultas para el campo Título son el talón de Aquiles para cualquiera de los
analizadores. Con el propósito de mejorar la precisión de las búsquedas por Titulo se
decidió emplear el algoritmo de stemming de Porter [3] en lugar de los algoritmos de
stemming usados por SnowballAnalyzer, EnglishAnalyzer y SpanishAnalyzer. Los
resultados de los nuevos experimentos se discuten en la próxima sección.

4.4.3 Mejora de la precisión mediante PorterStemFilter

En pos de mejorar la precisión de las búsquedas sobre el campo Título, cuando tan-
to a los documentos como a las consultas se les aplica el algoritmo de stemming de
Porter (PorterStemFilter), se creó una extensión de la clase Analyzer de Lucene. Me-
diante esta extensión se combinó PorterStemFilter con LowerCaseTokenizer, Stan-
dardTokenizer, StopFilter, y LowerCaseFilter. Las métricas de precisión y recall para
los resultados de las búsquedas que se hicieron acoplando los cuatro recursos antes
mencionados a PorterStemFilter se muestran en la Tabla 10.

Fig. 2. Precisión de los resultados de las búsquedas con diversos analizadores

Fig. 3. Recall de los resultados de las búsquedas con diversos analizadores

13 Pablo Santana Mansilla y Rosanna Costaguta

Las dos celdas sombreadas en la Tabla 10 señalan los valores más altos de preci-
sión y recall a los que se pudo llegar en las búsquedas por el campo Título. Como
puede verse la estrategia más conveniente para mejorar la efectividad de las búsque-
das por Título consiste en aplicar PorterStemFilter junto con StandardTokenizer y
StopFilter con stop words en español e inglés. El 0.28 de precisión en la celda resalta-
da representa un incremento del 47% si se tiene en cuenta que con el resto de los ana-
lizadores se había obtenido 0.19 como valor máximo para la precisión. Por su parte, el
recall se mantiene dentro de los valores alcanzados con los otros analizadores.
En un primer examen a la tercera columna de la Tabla 10 se pensó que Por-
terStemFilter junto con StandardTokenizer y StopFilter mejoraban la relevancia de los
resultados de las búsquedas, al menos por el campo Título, porque el índice invertido
que se había generado contenía mayor cantidad de términos que los índices construi-
dos al combinar PorterStemFilter con otros filtros. Sin embargo, en la Figura 4 se
aprecia claramente que no existe una relación directa entre el número de términos del
índice y la relevancia de los resultados de las búsquedas. La precisión puede tanto
mejorar como empeorar a medida que aumenta la cantidad de términos en el índice.

Tabla 10. Precisión y recall de búsquedas por Título empleando PorterStemFilter

Combinaciones de Filtros Precisión Recall Cantidad de
Términos del Índice
PorterStemFilter - LowerCaseTokenizer 0,060297548 0,9 11763
PorterStemFilter - LowerCaseTokenizer- 0,118608388 1 11573
StopFilter con stop words en ingles
PorterStemFilter - LowerCaseTokenizer- 0,154940214 1 11385
StopFilter con stop words en ingles y español
PorterStemFilter- StandardTokenizer 0,145454926 0,966667 20345
PorterStemFilter -StandardTokenizer - 0,068436596 1 15863
LowerCaseFilter
PorterStemFilter - StandardTokenizer - Low- 0,120936808 0,933333 15641
erCaseFilter - StopFilter con stop words en
ingles
PorterStemFilter- StandardTokenizer - Low- 0,155218863 1 15489
erCaseFilter - StopFilter con stop words en
ingles y español
PorterStemFilter - StandardTokenizer - 0,2369131 0,966667 19953
StopFilter con stop words en ingles
PorterStemFilter - StandardTokenizer - Stop- 0,279647474 0,966667 19653
Filter con stop words en ingles y español

Habiendo determinando que la combinación de PorterStemFilter con Standardar-

Tokenizer y StopFilter (con stop words en inglés y español) mejoraba la relevancia de
los resultados de las búsquedas por título, se procedió a aplicar esta combinación de
filtros a las búsquedas por Autor, ISBN y palabra clave para comprobar si se mantenía
el efecto que habían tenido en las búsquedas por título. La Tabla 11 refleja los valores
de precisión y recall a los que se arribó en las búsquedas por Autor, ISBN y palabra
clave.
14 Modelo multi agente que personaliza el material de estudio en grupos colaborativos

Fig. 4. Relación entre precisión y cantidad de términos del índice para las búsque-
das por Título

Tabla 11. Precisión y recall de búsquedas realizadas cuando PorterStemFilter se

combina con StandardTokenizer y StopFilter
Campo Busqueda Precisión Recall
Autor 0,788888889 0,916667
Titulo 0,279647474 0,966667
ISBN 1 0,875
Palabra Clave 0,541919152 0,731982
Promedio 0,652613879 0,872579

Si se compara a la Tabla 11 con las cifras de la Tabla 6, sale a la luz que: la rele-
vancia de los resultados de las búsquedas por Autor también mejoro; no hubo cam-
bios en las búsquedas por ISBN; y hubo un decrecimiento de la precisión de los resul-
tados para palabra clave que de cierto modo, se compensa con un pequeño incremento
en el recall. Los promedios de precisión y recall de la Tabla 11 son 3% superiores a
los conseguidos mediante SimpleAnalyzer (Tabla 6) por lo cual se podría concluir
que para procesar información de libros escritos en inglés y español conviene em-
plear: StandardarTokenizer, StopFilter con stop words en inglés y español, y Por-
terStemFilter. No obstante, el problema con esta combinación de recursos de Lucene
es que las búsquedas son case sensitive. Cuando se utiliza StandardarTokenizer,
StopFilter y PorterStemFilter no se convierte a minúsculas al texto de las consultas ni
al texto de los archivos con información de los libros. Esto implica que si un usuario
realiza una búsqueda por la palabra “Sommerville” y luego realiza otra consulta re-
emplazando la letra “S” por su equivalente minúscula, es decir “sommerville”, puede
obtener resultados completamente diferentes. De hecho, van a existir resultados para
la consulta “Sommerville” si la palabra “Sommerville” estaba presente en la colección
de documentos y en consecuencia en el índice invertido. Del mismo modo, para la
consulta “sommerville” se van a mostrar los libros que tienen la palabra “sommervi-
lle” pero no los libros donde figura la palabra “Sommerville”. SimpleAnalyzer no
sufre del inconveniente de las búsquedas case sensitive porque efectúa la conversión a
minúscula mediante LowerCaseFilter.
En base a lo expuesto en los párrafos precedentes es posible concluir que la estra-
tegia más conveniente consiste en procesar tanto los documentos (información de los
15 Pablo Santana Mansilla y Rosanna Costaguta

libros) como las consultas mediante SimpleAnalyzer complementado con la supresión

de stop words en inglés y español (StopFilter).

5. Descripción de la Interfaz de Usuario para el Modelo Multi

Agente
La interfaz de usuario que se propone para el modelo multi agente de recomenda-
ción de material de estudio debería tener una apariencia similar a la mostrada en la
Figura 5. A la izquierda la interfaz contendría una herramienta de chat que mostraría a
los usuarios los mensajes publicados durante una conversación (A1) y les daría la
posibilidad de ingresar nuevos mensajes (A2). Los mensajes de los estudiantes son los
que el agente Detector de Carencia de Conocimiento se encargaría de monitorear,
buscando evidencias de una carencia en los conocimientos requeridos para completar
una tarea o actividad. Notificado del tema que les causa dificultades o dudas a los
estudiantes, el agente Recomendador de Materiales de Estudio mostraría en la zona
derecha de la interfaz (B1) los materiales que convendría que los estudiantes revisen.
El agente Buscador de Materiales de Estudio también estaría accesible directamente
desde la interfaz (B2) para darles a los alumnos la posibilidad de buscar materiales
por su cuenta.

Fig. 5. Interfaz de usuario propuesta para el modelo multi agente

Sin bien hasta el momento no se han programado los tres agentes del modelo pro-
puesto, ni se ha implementado la interfaz de chat de la Figura 6, se ha creado una
aplicación que usa SimpleAnalyzer para realizar búsquedas de libros escritos en espa-
ñol e inglés. La interfaz de usuario de esta aplicación es la misma que usará el agente
Buscador de Materiales de Estudio y se describe a continuación mediante un ejemplo.
16 Modelo multi agente que personaliza el material de estudio en grupos colaborativos

Fig. 6. Interfaz de usuario del agente Buscador de Materiales de Estudio

Para buscar un libro el usuario tiene que indicar el texto a buscar (a la izquierda
del botón buscar) y seleccionar el campo por el cual realizar la búsqueda: Autor, Títu-
lo, ISBN o todos los campos. Esta última opción implica que se busca en Autor, Títu-
lo, ISBN y en el índice de contenidos simultáneamente. Suponiendo que el texto a
buscar en el conjunto de libros del Departamento de Informática fuese “java”, y que
se busca por todos los campos, los libros recuperados serían los que muestra la Fig.7.

Fig. 7. Resultados de una búsqueda en la interfaz de usuario del agente Buscador

de Materiales de Estudio

Un click sobre cualquiera de las filas de la tabla que aparece en la Figura 7 mos-
traría detalles sobre el libro correspondiente. Suponiendo que se hubiera hecho un
click en la primera fila de la tabla de resultados de la Figura 7, se obtendría informa-
ción adicional sobre el libro “Estructura de datos y algoritmos en JAVA” tal como se
muestra en la Figura 8.
17 Pablo Santana Mansilla y Rosanna Costaguta

Fig. 8. Detalles del libro seleccionado

6. Conclusiones
El trabajo realizado no sólo permitió proponer un modelo multi agente aplicable a
grupos de estudiantes colaborativos que personaliza la recuperación de materiales de
estudio, teniendo en cuenta las necesidades de los mismos, sino que también permitió
experimentar con las facilidades disponibles en la herramienta Lucene para el análisis
y recuperación de documentos escritos en inglés y español.
Una de las primeras cuestiones en las que se debería seguir trabajando es en mejo-
rar la precisión de los resultados de las búsquedas por Título, ya sea que se utilice
SimpleAnalyzer o cualquier otro analizador. La precisión se mantiene siempre baja
debido a la forma en la que se construyó la consulta para buscar por el campo Título.
Cuando se hacen consultas por Título no sólo se recuperan los libros cuyo campo
Título coincida exactamente con la cadena de búsqueda, sino también los libros que
tengan en el campo Título alguna de las palabras que forman parte de la consulta.
Esto provoca que para cada consulta por título se les muestren a los usuarios mayor
cantidad de resultados de los que son realmente necesarios para satisfacer sus necesi-
dades de información. Así, por ejemplo, una búsqueda por el campo título con la ca-
dena “Administración de Sistemas Operativos” daría como resultado el libro cuyo
título sea “Administración de Sistemas Operativos” pero también los libros que ten-
gan las palabras “Administración”, “Sistemas” y “Operativos” como parte de su títu-
lo. La ventaja que tiene el no trabajar solamente con coincidencias exactas de la con-
sulta es que el buscador muestra resultados a los usuarios incluso cuando alguno de
los términos de la consulta tiene errores de ortografía.
Por otro lado, dos posibles modificaciones al proceso de búsqueda que quizás me-
joren la precisión y el recall son: detección automática del idioma de la consulta y
expansión de sinónimos para las consultas. Actualmente si un usuario realiza una
búsqueda por título con la cadena “Introducción a la Programación”, va obtener como
resultado el libro en cuyo título figure la cadena “Introducción a la Programación”.
Sin embargo, la colección de libros con la que se trabajó contiene un libro titulado
“Fundamentos de Programación. Algoritmos y Estructura de Datos”, con casi los
mismos temas que el libro “Introducción a la Programación”. En consecuencia, podría
18 Modelo multi agente que personaliza el material de estudio en grupos colaborativos

ser de utilidad incluir en la lista de resultados no sólo el libro “Introducción a la Pro-

gramación” sino también a “Fundamentos de Programación. Algoritmos y Estructura
de Datos”. En esta situación las palabras “Introducción” y “Fundamentos” pueden ser
tomadas como sinónimos ya que los libros que tienen estas palabras en su título sue-
len referirse a cuestiones básicas o imprescindibles del área o disciplina que cubren.
Más allá de las mejoras que se podrían implementar en los procesos de indexación
y de búsqueda, con el desarrollo del presente trabajo se pudo establecer que para
abordar con Lucene el problema de análisis y recuperación de información de docu-
mentos escritos en más de un lenguaje conviene utilizar SimpleAnalyzer complemen-
tado con supresión de stop words. SimpleAnalyzer se diferencia de SnowballA-
nalyzer, EnglishAnalyzer y SpanishAnalyzer no sólo por lograr mejores niveles de
relevancia en los resultados de las búsquedas sino también por el hecho de no utilizar
filtros específicos para cada idioma.
Otro aspecto que distingue a SimpleAnalyzer, y que de cierto modo justifica su
mejor desempeño, es el no aplicar la operación de stemming. El stemming perjudica
la relevancia de los resultados de una búsqueda porque aumenta la similitud de térmi-
nos que en realidad no son tan similares. Tómese por ejemplo las palabras “progra-
mación” y “programming” que pueden reducirse al stem “program”. Si se aplicase
stemming, una búsqueda con la palabra “programación” daría como resultado todos
los documentos que poseen la palabra “programación” pero además los documentos
con la palabra “programming”. Pero, la palabra “programming” solo comparte el 60%
de los caracteres con “programación” y en consecuencia no cumple con la noción de
relevancia introducida en la sección 4.3.
Contrariamente a lo que sucede con la operación de stemming, la eliminación de
stop words no incrementa la similitud entre términos que no son realmente similares
sino que evita sucedan este tipo de situaciones. Supóngase que se tiene dos libros
cuyos autores son “De la Mora” y “De la Mont”. Una consulta con la cadena “De la
Mora” sobre un índice invertido construido sin aplicar supresión de stop words daría
como resultados relevantes a los libros escritos por “De la Mora” y “De la Mont”. La
Cadena de consulta comparte con “De la Mora” el 100% de los caracteres en tanto
que con “De la Mont” comparte el 75% de los caracteres, por lo cual ambos libros
cumplen con el criterio de relevancia. Con la eliminación de stop words a la consulta
“De la Mora” se la convertiría en “Mora”. Para esta consulta transformada solamente
el término “Mora” del índice invertido sería relevante porque el término “Mont” solo
comparte el 50% de los caracteres. Finalmente, cabe resaltar que el modelo multi
agente ideado y propuesto en este trabajo será próximamente implementado en el
marco de un Trabajo Final de Graduación de la carrera de Licenciado en Sistemas de
Información perteneciente a la Universidad Nacional de Santiago del Estero.

Referencias
1. Ballesteros., L., y Croft, W. Phrasal Translation and Query Expansion Techniques for Cross-
Language Information Retrieval. In Proc. 20th Annual International ACM SIGIR conference on Re-
search and development in information retrieval, pp.84-91, 1997.
2. Chen, W. Supporting teachers’ intervention in collaborative Knowledge building. Journal of Network and Computer
Applications, 29: 200-215, 2006.
3. Hatcher, E., y Gospodnetic, O. Lucene in Action. Manning Publications, USA, 2005.
4. Konchady, M. Building Search Applications - Lucene, LingPipe and Gate. Mustru Publishing, 2008.
19 Pablo Santana Mansilla y Rosanna Costaguta

5. Korra, R., Sujatha, P., Chetana, S., y Kumar, M. Performance Evaluation of Multilingual Information
Retrieval (MLIR) System over Information Retrieval (IR) System. In Proc.IEEE-International Confer-
ence on Recent Trends in Information Technology (ICRTIT 2011), pp. 722-727, 2011.
6. Olivares, O. Collaborative vs. Cooperative Learning: The Instructor’s Role in Computer Supported
Collaborative Learning. En: Orvis K. L. y Lassiter A. L.R (eds) Computer-Supported Collaborative
Learning. Information Science Publishing, pp. 20-39, 2007.
7. Onrubia, J., y Engel, A. The role of teacher assistance on the effects of a macro-script in collaborative
writing tasks. Int. Journal of Computer-Supported Collaborative Learning, 7(1): 161-186, 2012.
8. O'Rourke, J. Tutoring in open and distance learning: a handbook for tutors. The Commonwealth of
Learning, 2003
9. Orvis, K., y Lassiter, A. Computer-Supported Collaborative Learning: The Role of the Instructor. En:
Ferris S. y Godar S.H. (eds) Teaching and learning with virtual teams. Information Science Publishing,
pp. 158-179, 2006.
10. Rosé, C., Wang, Y., Cui, Y., Arguello, J., Stegmann, K., Weinberger, A., y Fischer, F. Analyzing collaborative
learning processes automatically: Exploiting the advances of computational linguistics in computer-supported collab-
orative learning. International Journal of Computer-Supported Collaborative Learning, 3 (3): 237—271, 2008.
11. Schwarz, B., y Asterhan, C. E-Moderation of Synchronous Discussions in Educational Settings: A
Nascent Practice. Journal of the Learning Sciences, 20 (3): 395-442, 2011.
12. Shishehchi, S., Banihashem, S., y Mat Zin, N. A Proposed Semantic Recommendation System for E-
Learning. A Rule and Ontology Based E-learning Recommendation System. In Proc. International
Symposium in Information Technology (ITSim), pp. 1-5, 2010.
13. Souali, K., El Afia, A., Faizi, R., y Chiheb, R. A New Recommender System For E-Learning Envi-
ronments. In Proc. Int. Conference on Multimedia Computing and Systems (ICMCS), pp.1-4, 2011.
14. Suh, H., y Lee, A. Collaborative Learning Agent for Promoting Group Interaction. ETRI Journal,
28(4): 461-474, 2006.
15. Varvel, V. Master Online Teacher Competencies. Online Journal of Distance Learning Administration, 10 (1), 2007.