DESCRIPCIÓN Y OBJETIVOS:
El
objetivo de la práctica es programar un "jugador de Trivial"
automático, consistente en un sistema
de
QA sencillo capaz de responder a preguntas cortas tipo "Trivial Pursuit".
Para garantizar la máxima
cobertura dicho sistema empleará la Web
como base documental. De este modo, dada una pregunta, nuestro
"jugador" buscará en la Web la respuesta a dicha pregunta,
localizando primero documentos que traten el tema de la pregunta para
luego procesarlos en mayor profundidad y así localizar y extraer
la
respuesta.
El resto de la mecánica del
juego
(mover fichas, tirar dados, etc.) no se implementarán, dado que
no nos aportan nada al estudio de la asignatura. Por otra parte, y tal
como su
título sugiere, emplearemos inicialmente el inglés como
idioma de trabajo.
LOS DOCUMENTOS
Trabajaremos sobre la Web en lugar de buscar sobre un
repositorio de documentos local. De este modo la fase de recuperación de documentos será
"externalizada",
ya
que
emplearemos
motores
de
búsqueda
(i.e.
buscadores
web
como
Google, Yahoo, Bing, etc.) para localizar un
conjunto inicial de documentos que [presumiblemente] traten el tema de
la pregunta. Dichos documentos serán luego procesados
en fases subsiguientes para localizar y devolver la respuesta a la
pregunta empleando las técnicas vistas en clase. A la hora de
realizar la búsqueda (habiendo generado previamente y de forma
automática la consulta), ésta puede realizarse
automáticamente (mediante alguna de las APIs disponibles,
mediante una URL construida automáticamente, etc.) o
manualmente. Lo mismo a la hora de descargar los documentos devueltos.
Naturalmente, la primera opción, hacerlo de forma
automática, es más compleja, por lo que se
valorará más, si bien también resulta más
cómoda una vez implementada. De todos
modos una
opción es hacerlo primero manualmente y, una vez os funciona el
resto del sistema, implementar esa parte.
AVISO: cuidado con los
"terms of use"/"terms of service",
a
los
buscadores
no
les
gustan
las
búsquedas
automáticas,
y
si
detectan varias
búsquedas muy seguidas desde la misma dirección os pueden
bloquear.
AVISO: En el caso de Google, debéis tener en
cuenta que, en principio, en el caso del navegador, ya no devuelve la
salida en HTML (antes se podía deshabilitar
"Instant Search" en: Opciones (tuerca en esquina superior
derecha) -> Configuración de búsqueda y se solucionaba, pero ahora parece
que ya no).
Respecto al formato de los documentos, debe tenerse en cuenta que los
documentos disponibles en la Web son de muy diferente tipo (HTML, PDF,
PPT, DOC, ODT, etc.), e incluso puede estar en columnas, con
diferentes frames, etc. No obstante, a la hora de procesar el documento
lo que
necesitaremos es un simple fichero de texto. Debe
tenerse en cuenta que éste es un problema que tendríais
que abordar igualmente de ser un caso real. Sin embargo, al ser esto
una práctica, podemos ser menos estrictos, por lo que de nuevo
se plantean varias opciones para abordar dicho problema: pasar
los documentos a texto bien de forma manual con un
copy-paste o
algún comando de conversión (ej.
pdftotext), hacer dicha
conversión automáticamente, ignorar
aquellos que no estén disponibles en .HTML (más
fácilmente convertibles de forma automática), etc. En
todo caso deberéis indicar en la memoria la solución
adoptada, ya que será también un punto a valorar.
LAS PREGUNTAS
Dada la dificultad intrínsica de desarrollar un sistema de QA,
nos limitaremos a trabajar con
preguntas factuales
(denominadas
factoid
en la literatura), es decir, preguntas concretas y "directas"
referentes a nombres,
cantidades, fechas, lugares, personas, etc. (i.e. las más
comunes del
"Trivial Pursuit"),
de
tal
forma
que
no
sea
necesario
realizar
inferencia
alguna
a
mayores.
Se evitarán, pues, las preguntas de corte subjetivo (ej.
"¿Quién es la persona
más importante de
Alemania?"), las definiciones (ej.
"¿Qué es un
coche?"), las de pregunta doble embebida (ej.
"¿Qué
presidentes visitaron el país más pobre del mundo en
1994?") y las de respuesta múltiple (ej.
"Nombre tres obras
de Zorrilla"). Lo que sí puede ocurrir, aunque al emplear
la Web será raro el caso, es que la colección no contenga
respuesta conocida alguna para una
pregunta (comentado más adelante).
A modo de ejemplo, el alumno
dispone de un
conjunto
de
preguntas
de
ejemplo.
El
formato de las preguntas
es el
siguiente (NOTA: en este ejemplo emplearemos español en vez de
inglés):
0001
¿Cuál
es
la
capital
de
España?
Donde, columna por columna, los campos que la componen son:
- Identificador de la pregunta (numérico)
- Pregunta propiamente dicha
LAS RESPUESTAS
Se permite devolver hasta un
máximo
de
tres
respuestas posibles
por pregunta. Dichas respuestas deben aparecer ordenadas (véase
campo '
answer
rank' más adelante) en base a algún tipo de medida
de
confianza y/o puntuación (véase campo '
score' más
adelante). Básicamente, una
respuesta
está constituida por un par
[texto_de_respuesta,
docid] (aunque añadiremos algún dato más a
mayores, como veremos más abajo):
- texto_de_respuesta:
se permiten 2 opciones de texto de respuesta diferentes, siendo el
alumno el que decida cuál empleará su sistema:
- Presentar
la respuesta exacta, es decir,
únicamente el texto con las
palabras exactas de la respuesta buscada (mucho más preciso,
pero también más complejo)
- Presentar una ventana de
texto de 50 caracteres del documento del que se extrajo y en la
cual esté contenida la respuesta (menos preciso pero más
sencillo)
El sistema no tiene porqué ser capaz de trabajar con ambas,
con que utilice una es suficiente. Por otra parte, dentro de una misma
ejecución no se pueden mezclar respuestas exactas y respuestas
en ventana, todas deben ser del mismo tipo.
NOTA: se recomienda a los alumnos que, en caso de optar por un sistema
de respuesta exacta, implementen primero igualmente un sistema basado
en ventanas de texto y, una vez logren que funcione adecuadamente, lo
modifiquen para trabajar con respuestas exactas.
- docid: identificador
del
documento
del que se ha extraído la respuesta. En este caso, al trabajar
sobre la web, emplearemos la URL
completa de la página/documento
del que se ha extraído la respuesta. Dicho documento no
sólo debe contener la respuesta, sino que deberá
además justificarla, es
decir, de su contenido debe desprenderse que ésa es la respuesta
a la pregunta formulada, y así evitar que la respuesta sea
correcta sólo por casualidad. Por ejemplo, para la pregunta "¿Cuál es la
capital de España?", y habiendo devuelto correctamente
como respuesta "Madrid", no
valdría un documento que, aún conteniendo la palabra "Madrid", no se infieriese de
él al leerlo que Madrid es la capital de
España.
En el caso de que no encontremos respuesta para una pregunta, o de
que creamos que no la hay (por ejemplo, si hemos fijado un umbral de
confianza y la respuesta candidata no lo cumple), devolveremos
simplemente la cadena "
NIL"
en
lugar
del
par
[texto_de_respuesta,
docid]. Sin embargo, al trabajar en esta ocasión sobre la
Web, sería raro que se diese el caso, dada la
redundancia de
información que existe en ella.
En lo que respecta al
formato de
salida el que se han de devolver dichas respuestas, es el
siguiente. Para una misma ejecución ,las
respuestas a todas las preguntas formuladas se devolverán juntas
en un mismo fichero y ordenadas por el identificador de la pregunta a
la que responden, de menor a
mayor. Igualmente, para cada pregunta individual, se devolverán
sus repuestas (máximo de 3), ordenadas por preferencia, de mayor
a menor, indicándose dicha preferencia por un campo '
answer rank' con
un valor numérico del 1 al 3 (ver más abajo). Cada
entrada del fichero de respuestas contiene, pues, 6 columnas:
- EJEMPLO 1 (respuesta
exacta):
1 plnnex031ms 1 3456 http://www.red2000.com/spain/madrid/1madrid.html
Madrid
1 plnnex031ms 2 678
http://www.missviajes.com/napoles-bella-napoles-10002 Nápoles
1 plnnex031ms 3 500 http://www.visitarparis.com/ París
...
- EJEMPLO 2 (respuesta
exacta):
1 plnnex031ms 1 3456
http://www.red2000.com/spain/madrid/1madrid.html Madrid
2 plnnex031ms 1 7854 NIL
...
- EJEMPLO
3 (ventana de
texto):
...
789 plnnst031ms 1 482.78 http://www.infohostal.com/guia/madrid/30 Su
capital y también capital de España es Madrid.
...
donde, columna a columna, los campos que componen dicha respuesta son:
- Identificador de la pregunta a la que se
está contestando.
- Identificador de la
ejecución (run-tag).
Contiene
la
siguiente
información:
- Los 3 primeros caracteres deberán ser 'pln'
- El siguiente carácter será el código
identificativo que el profesor asignará a ese grupo de
prácticas ('a', 'b', 'c', ...)
- Los 2 caracteres siguientes serán 'ex' en el caso de
que se haya optado por devolver respuestas exactas en el texto_de_respuesta
(opción 1) o 'st'
en el caso de devolver una
ventana de 50 caracteres (opción 2)
- Los siguientes caracteres deberán ser '031ms'
Resumiendo, este campo tendrá 11 caracteres tal que
así: pln[a-z](ex|st)031ms
- Orden de la respuesta
(answer
rank). Como se ha dicho, se permite devolver hasta 3 respuestas
por pregunta, las cuales presentaremos de
"mejor"
a
"peor",
asignándoles a sus campos 'answer
rank'
unos valores ascendentes del 1 al 3, como se muestra en el Ejemplo 1 de
más arriba. De este modo la respuesta que creemos mejor
tendrá 'answer
rank' 1, la siguiente 2, y la última, la peor, 3.
- Puntuación
(score). Muy a menudo este
tipo de sistemas asocia a cada respuesta candidata algún tipo
de puntuación numérica
que se ha ido calculando durante
el proceso de obtención de la respuesta. Dicho valor (o bien uno
derivado o normalizado a partir de él) se muestra en este campo.
El formato permitido es el de un valor numérico entero o real
con un máximo de 8 caracteres (punto inclusive). Si el sistema
no
calculase puntuación alguna o simplemente no se quisiese
mostrar, entonces devolveremos 0 en este campo.
- Identificador del documento
(docid)
del que hemos extraído la respuesta y que la justifica, y que en
este caso, como se ha dicho ya, será la URL completa de la
página/documento.
Recuérdese que en el caso de que el sistema no encontrase
respuesta para una
pregunta o bien se considerase que no hay respuesta correcta en la
colección, entonces devolveremos la cadena "NIL" en este campo, y dejaremos
el texto_de_respuesta
vacío, tal y como se muestra en el Ejemplo 2 anterior.
- Repuesta a la pregunta (texto_de_respuesta).
Recuérdese
que en el caso de que el sistema devuelva NIL para una pregunta
(véase punto anterior), dejaremos
este campo vacío, tal y como se muestra en el Ejemplo 2.
Recuérdese también que se
permiten dos tipos de respuesta:
- Respuesta exacta (Ejemplos 1 y 2)
- Ventana de texto de 50 caracteres (Ejemplo 3)
Las columnas irán separadas por espacios (al menos uno) y con
una respuesta por
línea.
EVALUACIÓN
Desgraciadamente, al contrario que en los sistemas de IR, la
evaluación de un sistema de QA es una tarea básicamente
manual. De esta forma, partiendo de la lista de preguntas formuladas y
una lista con sus respectivas respuestas correctas deseadas,
deberemos ir examinando una a una las respuestas devueltas por el
sistema, así como
los documentos que las justifican.
A este respecto, se le proporcionan inicialmente al alumno, a modo de
conjunto de
entrenamiento, un conjunto de
preguntas
de
ejemplo
(0001-0050)
junto con sus
respuestas
correspondientes, si bien sólo se indican las respuestas en
sí, sin indicar los documentos de los que fueron
extraídas y que
las justifican. De este modo el alumno puede emplear estos pares
pregunta-respuesta durante la fase de desarrollo del sistema como
conjunto de entrenamiento para
estudiar el tipo de preguntas al que deberá responder,
realizar pruebas, etc.
Los resultados
obtenidos durante dichas pruebas
(véase más adelante las estadísticas a emplear),
deberán ser recogidos en la memoria para que quede
constatación de la evolución del sistema, del trabajo que
habéis hecho y para que éste pueda ser valorado.
Nótese
que habrá modificaciones que resultarán en mejoras y
otras que todo lo contrario. No pasa nada, lo normal es que
suceda eso, pero recogedlas igualmente en la memoria. Asimismo, de cara
a la
evaluación final, se le suministrará al alumno más
adelante un segundo conjunto de preguntas, el
conjunto de test.
Volvamos de nuevo a la pregunta ejemplo
"¿Cuál es la
capital de España?". Si se ha optado por la
presentar únicamente la respuesta exacta a modo de
texto_de_respuesta
(opción 1), las siguientes respuestas pueden considerarse
correctas:
- Madrid
- madrid
mientras que éstas otras no se considerarían respuestas
exactas correctas:
- con 3.000.000 habitantes, Madrid
- bella Madrid
- ella le dijo: Madrid es una
- Madri
- Sevilla
Sin embargo, si se optó por la devolver una ventana de texto
(opción 2), los casos (a), (b) y (c) sí
serían correctos.
De
todos modos debe tenerse en cuenta que el concepto de corrección
es, hasta cierto punto, subjetivo, ya que está sujeto a la
interpretación de la persona que valora la respuesta. De esta
forma las respuestas serán comprobadas por evaluadores humanos
(en este caso, vosotros) que deberán asignar a cada respuesta
una de las siguientes
cuatro valoraciones posibles:
- Incorrecta (W): el texto_de_respuesta no contiene
una respuesta correcta o la respuesta no es completa.
- No justificada (U): el texto_de_respuesta sí
contiene una respuesta correcta, pero el documento indicado (docid) no justifica la misma.
- Inexacta (X):
(sólo aplicable en
el caso de haber optado por devolver respuestas exactas; i.e.
opción 1) el texto_de_respuesta
sí contiene una respuesta
correcta y el documento indicado la justifica, pero en dicho string
faltan o sobran caracteres o palabras, es decir, la respuesta no es
completamente exacta al 100%.
- Correcta (R): el texto_de_respuesta
es la respuesta exacta (en el caso de devolver
respuestas exactas; i.e. opción 1) o bien contiene la respuesta
(en el caso de devolver ventanas de texto; i.e. opción 2) y
además el documento indicado es justificativo (en ambos casos,
tanto para respuestas exactas como para ventanas).
CASO
PARTICULAR:
Una respuesta equivocada por parte del
sistema deberá evaluarse como correcta (R) si el documento del
que
se extrajo la respuesta y con el cual se justifica la misma
contiene dicho error. Por ejemplo, si un documento dice que Florencia
es la capital de España, y devolvemos Florencia como respuesta
justificándola con dicho documento, entonces deberá
considerarse dicha respuesta como válida.
A
continuación se dan algunas indicaciones para la
realización de dicho proceso de evaluación:
- Supongamos de nuevo la pregunta ejemplo "¿Cuál es la
capital de España?". Si nuestro sistema devuelve un
documento en el que sí se habla de Madrid pero en el cual, al
leerlo, no dice nada acerca de que Madrid es la capital de
España, se considerará que dicha respuesta ha sido
acertada por casualidad, ya que dicha respuesta NO está
convenientemente justificada en el documento. En ese caso se
consideraría dicha respuesta como no justificada (U).
- Respecto a las fechas de sucesos pasados, por lo general se
requiere la fecha completa (día+mes+año),
a
menos
que
la
pregunta
especifique
lo
contrario
(por
ejemplo,
que
pregunte
sólo
el
año)
o
que
la
fecha completa no
esté disponible en parte alguna (en cuyo caso debe acotarse lo
más posible, devolviendo mes+año
a poder ser, o simplemente año
si es lo único que hay disponible). Por ejemplo, para la
pregunta "¿Cuándo
murió Napoleón?", donde
la respuesta correcta (R)
completa sería "5 de mayo de
1821",
la respuesta "5 de mayo"
sería incorrecta (W),
mientras que "mayo de 1821" o
"1821" sí
podrían llegar a ser correctas
(R) dependiendo de si la fecha más concreta apareciese o
no en algún otro documento de la colección.
- En el caso de localizaciones geográficas, la respuesta
debería incluir el
"nombre oficial" del lugar, es decir, aquél que aparece en mapas
y atlas. Por ejemplo, "Rías
Bajas" sería correcto
(R), pero "Rías"
sólamente sería incorrecto
(W).
Existen casos, sin embargo, en los cuales una misma localización
puede tener más de una alternativa válida, como en el
caso de"Mar Cantábrico"
y "Cantábrico", donde
ambas serían correctas (R).
- En el caso tanto de fechas como de cantidades, si el sistema
devuelve respuestas exactas
(y no ventanas de texto), ciertas partículas
como artículos o preposiciones no invalidan una respuesta exacta. De este modo, "5 de mayo de 1821", "el 5 de mayo de 1821" y "a 5 de mayo de 1821" serían
todas respuestas exactas
correctas (R). De igual modo, en el caso de las aposiciones "año", "día",
etc. en "año 1821", "en el año 1821" o "el día 5 de
mayo de 1821" seguríamos teniendo también fechas exactas correctas (R).
- Respecto
a las respuestas NIL,
sólo serán consideradas correctas
(R) si no hay respuesta para dicha pregunta en la
colección. Es
decir, si el sistema del alumno ha devuelto NIL, pero en la web sí
existen documentos donde aparece una respuesta, entonces se
considerará incorrecta (W).
A la hora de evaluar el sistema emplearemos como medida de
evaluación el
mean
reciprocal
rank
(MRR), el cual se calcula de la siguiente forma.
Para cada pregunta, examinamos
POR ORDEN las respuestas devueltas (recuérdese que se
permitían hasta 3 respuestas devueltas posibles, de mejor a
peor), y vemos en qué posición está la
primera respuesta correcta y
así calcular su puntuación (
reciprocal rank):
- Si la primera respuesta correcta la encontramos en la primera
respuesta devuelta, le asignamos a la pregunta una puntuación de
1/1=1.
- Si la primera respuesta correcta la encontramos en la segunda
respuesta devuelta, le asignamos a la pregunta una puntuación de
1/2=0.500.
- Si la primera respuesta correcta la encontramos en la tercera
respuesta
devuelta, le asignamos a la pregunta una puntuación de 1/3=0.333.
- Si no hemos devuelto ninguna respuesta correcta para dicha
pregunta, le asignamos a la pregunta una puntuación de 0.
Nótese que tan pronto encontremos una respuesta correcta le
asignamos su puntuación correspondiente y ya pasamos a la
siguiente pregunta ignorando las respuestas restantes. Es decir:
- Examinamos la primera respuesta devuelta, y si es correcta, le
asignamos a la pregunta una puntuación de 1/1=1 y pasamos a la
siguiente pregunta ...
- ...
sino examinamos la segunda respuesta, y si es correcta le asignamos a
la pregunta una puntuación de 1/2=0.500 y pasamos a la siguiente
pregunta ...
- ... sino examinamos la tercera respuesta, y
si es correcta le asignamos a la pregunta una puntuación de
1/3=0.333 y pasamos a la siguiente pregunta ...
- ... sino le asignamos a la pregunta una puntuación de 0 y
pasamos a la siguiente pregunta.
El MRR se calcula como la
media de
dichas puntuaciones
para todas las preguntas. Además, en el caso
de esta práctica
haremos una
doble evaluación,
ya
que
calcularemos
esta
medida
para
2
casos
de
evaluación
diferentes:
- Estricta: Sólo
aceptaremos como respuestas correctas aquéllas donde el texto de
la respuesta sea válido y además el texto del documento
justifique dicha respuesta. Es decir, sólo nos valen las
respuestas tipo R.
- Permisiva: aceptaremos
como respuestas correctas TODAS aquéllas
donde el texto de la respuesta sea válido aunque el texto del
documento no justifique la respuesta. Es decir, nos valen tanto las
respuestas tipo R como las de
tipo U.
Dicho esto, para cada fichero de resultados presentado se
indicarán los siguientes datos obtenidos para dicha
ejecución (recuérdese que si bien sólo se exige
uno, el alumno es libre de presentar más para diferentes
configuraciones del sistema):
- Identificador de la ejecución (run-tag).
- MRR calculada para el caso "estricto".
- MRR calculada para el caso "permisivo".
- Número de preguntas para las que conseguido devolver la
respuesta correcta para el caso "estricto"
(independientemente de si estaba en la posición 1, 2 o 3).
- Número de preguntas para las que conseguido devolver la
respuesta correcta para el caso "permisivo"
(ídem).
- Número de preguntas para las que se ha devuelto NIL como respuesta.
- Número de preguntas para las que se ha devuelto NIL como respuesta y
ésta era además la respuesta correcta.
Dichas cifras deberán calcularse
tanto para el conjunto de
preguntas de entrenamiento (el suministrado inicialmente),
como para el
conjunto de test.
RECURSOS
INICIALES
Para resumir, el alumno cuenta
inicialmente con:
- Conjunto
de
preguntas
de
entrenamiento
(0001-0050)
- Respuestas
para
dichas
preguntas
NOTA: dispone se ha añadido a mayores un tercer fichero que
presenta conjuntamente los pares
pregunta-respuesta de dichas preguntas, facilitando de esta forma
la lectura.
a los que se les unirá, de cara a la evaluación final, un
segundo conjunto de preguntas de test. A mayores, en caso de que el
alumno quiera crear un segundo conjunto de entrenamiento/test
"propio" y usarlo como complemento a los que os suministramos
para realizar pruebas extra, existen diversas
páginas de fans del Trivial con preguntas y respuestas de todo
tipo. Véanse, por ejemplo:
En todo caso se debe tener
cuidado con leerlas previamente para filtrar aquéllas que NO
sean factuales 100%, que tengan una formulación confusa o que
requieran de un procesamiento demasiado complejo. Hay
algunas por ejemplo,
que son preguntas dobles embebidas (ej.
"¿Qué
presidentes
visitaron
el
país más pobre del mundo en
1994?"), de respuesta
múltiple (
"What is the Daily
Planet in Australia? Biggest Brothel and a Listed company"), de
definición (
"What is a
geoduck? Clam"; "If you had 'podobromhidrosis' what would you have?
Smelly feet"), de puntos en común ("
Which actor appears in both 'The
Magnificent Seven' and 'The Dirty Dozen'? Charles Bronson;
Bam, Yat and Holon are in which country?
Israel") y otras varias demasiado complejas por requerir
razonamientos más complejos o estar insuficientemente
especificadas ("
An elephant has
400000 what in it's trunk? Muscles;
Between 1659 and 1681 what was it illegal
to celebrate in Massachusetts? Christmas").
Asimismo, para facilitar su procesado, nos hemos restringido a
preguntas en las que el interrogativo está al principio de la
pregunta, por lo que algunas de las preguntas disponibles han sido
reformuladas para adaptarlas a este formato. Por ejemplo, "
King Zog ruled which country?" ha
sido reformulada como "
Which country
was ruled by King Zog?".
NORMAS Y ENTREGA:
La práctica se realizará en grupos de 3-4
personas (salvo casos excepcionales y previa autorización
del
profesor), siendo preferibles los grupos de 3 personas. Asimismo,
por cuestiones de operatividad, el
grupo
deberá elegir un portavoz
de entre sus miembros, que
actuará de interlocutor con el profesor.
Cada grupo deberá enviar un
mail al profesor indicando los nombres, logins y direcciones de correo
de todos los componentes del grupo, indicando además
quién de
ellos actuará como portavoz.
NOTA:
El
servidor
de
correo
de
la UDC tiene problemas desde hace tiempo con
Hotmail, de forma que en
ocasiones los correos enviados de uno a otro (y viceversa) son
rechazados o extraviados.
La fecha límite de
entrega es el jueves 30 de enero de 2014, a las 22:00.
El portavoz
entregará al profesor Jesús Vilares (en mano en su
despacho 0.20 o bien en su casillero) un
CD/DVD
conteniendo
los
siguientes
directorios
y ficheros:
- src/: se
incluirá en él todo aquél
código fuente que el grupo haya implementado o modificado (caso
de emplear herramientas ya existentes).
- res/: fichero(s) con
las respuestas obtenidas.
- doc/: memoria de la
práctica (en Word, OpenOffice o PDF). En la misma se
indicará, como mínimo:
- En la portada: nombre, login y mail de los miembros del grupo
(e identificando al portavoz).
- Arquitectura detallada del sistema, identificando claramente
los módulos de los que consta, su función, interacciones
y entradas/salidas.
- Herramientas de terceros, de haberlas, empleadas en el
diseño e
implementación del sistema. En caso de ser herramientas libres
se
indicará dónde se pueden obtener.
- Manuales de instalación y uso del
sistema.
- "Diario
de Trabajo"
en la que se detallen y expliquen las decisiones de
diseño e implementación que se han tomado, qué
técnicas se han probado (o simplemente considerado), en
qué consistían, de dónde sacó dicha
información, si dichas técnicas funcionaron
o no, etc. Se recomienda encarecidamente al alumno que vaya escribiendo
la documentación (o al menos tomar notas) desde un principio, en
particular
en lo que respecta al Diario, ya que de lo contrario puede
olvidarse de muchas de estas cosas.
- Bibliografía empleada.
La práctica será defendida individualmente
por todos los miembros del grupo
en los días siguientes a la fecha de entrega, siendo la nota del
grupo
la media de las notas obtenidas por sus miembros en la defensa.
De igual modo el profesor de reserva el derecho a convocar a los grupos
a celebrar reuniones
de
seguimiento de la práctica
antes de la entrega
final, bien con todo el grupo, bien con el
portavoz. Las fechas de dichas reuniones se anunciarían en la
página de Moodle de la asignatura.
Asimismo se habilitarán una serie de foros de
discusión
en dicha página de Moodle para que los alumnos puedan discutir
entre sí diversos aspectos de la práctica y/o compartir
información o recursos (ver más adelante).
Debe tenerse muy en cuenta que no se trata de una práctica
clásica "cerrada", es decir, con enunciado, metodología
y objetivos únicos, claros y definidos. Por el contrario se
trata de una práctica "abierta", enmarcada dentro de una
asignatura ECTS, donde se plantean únicamente un enunciado y
objetivos generales, y que será el alumno quién deba
estudiar la mejor forma de llevarlos a cabo. De este modo, a la hora de
evaluar la práctica se tendrán en cuenta, al menos, los
siguientes factores:
- El trabajo de investigación y preparación previos a
la implementación.
- El grado de comprensión de los conocimientos adquiridos.
- La
iniciativa del alumno a la hora de probar diferentes
posibilidades. Esto quiere decir que se valorará muy
positivamente que el alumno intente aplicar al sistema diferentes
aproximaciones y técnicas, aunque los resultados obtenidos con
ellas no sean del todo satisfactorios y opte luego por abandonarlas en
favor de otras opciones. A
este respecto es muy importante el Diario
de
Trabajo contenido en
la memoria, donde se deberá reflejar todo este trabajo.
- Los resultados obtenidos por el sistema.
- Claridad de la memoria.
- Cooperación y trabajo en grupo.
- Participación e interés.
A modo de resumen podríamos decir que
lo que se
pretende valorar
es el trabajo personal realizado por los alumnos durante el
desarrollo de
la práctica, y no tanto los resultados, ya que el
objetivo
principal
de
la
práctica
no
es
sólo
implementar
un
sistema
de
QA,
sino
que
el
alumno
complete
su
formación en los diferentes
ámbitos del PLN a nivel tanto teórico como aplicado.
Debe tenerse también en cuenta que una misma tarea puede
casi siempre realizarse de múltiples formas
o puede abordarse desde diferentes perspectivas. Por ejemplo, la
arquitectura general de un sistema de QA vista
en
clase
es
sólo un modelo
base, uno de los múltiples posibles. Hay sistemas, por ejemplo,
que no distinguen entre fase de
recuperación y selección de pasajes, realizando dichas
tareas en un único paso; o al contrario, sistemas que
añaden nuevas
(sub)fases con diferentes grados de especialización. De esta
forma el alumno puede aplicar las técnicas y soluciones que
él crea pertinente, hayan sido de las vistas en clase, obtenidas
de la literatura, o de cosecha propia.
Del mismo modo, el alumno puede, si lo desea, adaptar el
enunciado a sus preferencias, e incluso proponer cambios más
significativos. En todo caso el alumno
deberá siempre
consultar
previamente
con
el
profesor. Algunas posibilidades
podrían ser, por ejemplo:
- Trabajar con español, gallego u otra lengua en lugar del
inglés.
NOTA: adviértase sin embargo que la gran mayoría de los
recursos y herramientas disponibles lo están para inglés,
lo que por una parte añade dificultad a la práctica a la
vez que limita las soluciones aplicables y, por
otra, va en detrimento de los resultados.
- Añadir interactividad con el usuario al proceso a la hora
de realizar los procesos de PLN.
Finalmente recordar de nuevo al alumno que lo que se pide
es
implementar un sistema de QA, sin establecer requisitos mínimos
ni restricciones respecto a las técnicas o soluciones a aplicar.
De este modo, por ejemplo, si el alumno implementa finalmente un
sistema de QA Clase 0 (i.e.
aplicando únicamente técnicas de IR) porque con la
aplicación de técnicas de NLP más complejas no
obtenía buenos resultados, esto es perfectamente válido.
Como igual de válido es que otro alumno desarrolle un sistema de
Clase 1 (o Clase 2 o Clase 3, o incluso combinando técnicas de
varias clases) si con ello obtiene el resultado deseado.
LA COMPETICIÓN:
Dependiendo
de
la
evolución
del
trabajo
realizado
por
los
diferentes
grupos,
se
plantea
la
posibilidad
de realizar una pequeña
competición entre los diferentes sistemas implementados por los
grupos de prácticas. Para ello se reservaría un aula
durante un par de horas. Durante ese tiempo los sistemas
deberían intentar responder correctamente a una serie de
preguntas. El que más preguntas respondiese correctamente
resultaría vencedor. De finalmente realizarse sería
simplemente para pasárselo bien compitiendo (i.e. no
tendría efecto sobre la nota), la participación
sería voluntaria y después de la defensa de la
práctica en sí (fecha a acordar). Podría ser
incluso después de la entrega de actas.
CONSEJOS Y ADVERTENCIAS:
- Se trata de una práctica compleja que requiere,
forzosamente, de la cooperación de todos los miembros del grupo.
Esto permitirá al alumno familiarizarse con las mecánicas
de trabajo propias de grupos pequeños, como las que se
encontrará después en su vida laboral.
Una persona sola no puede abordar una práctica como ésta
en un
plazo razonable, no quepa
duda.
- Una
práctica de este tipo no es directamente abordable sin un
trabajo previo: primero, consultar la literatura; segundo, pensar;
tercero implementar.
- Lo que funciona para unos no tiene porqué funcionar para
otros, y viceversa.
- No matar moscas a cañonazos. Las soluciones sencillas
suelen ser más robustas e incluso funcionar mejor.
- Con una adecuada distribución de las tareas entre los
miembros del grupo podréis trabajar en paralelo en diferentes
aspectos de la práctica. Por ejemplo, mientras uno de vosotros
trabaja en la parte de recuperación, otro puede trabajar sobre
la parte de extracción de la respuesta partiendo de
resultados preliminares del otro miembro o, simplemente, a partir de
documentos y/o pasajes seleccionados a mano.
-
Nótese
que algunos
buscadores empiezan a integrar capacidades de QA. Por supuesto
esté prohibido hacer uso de dichas capacidades.
- No se permite
que dos grupos se copien
o compartan módulos.
- Sin embargo la
cooperación inter-grupos sí está
permitida en los
aspectos que no se refieran a la implementación del sistema
propiamente dicha.
Podéis, por ejemplo, compartir bibliografía, recursos
(software, diccionarios, theasurus...),
etc. Podéis incluso poneros de acuerdo varios grupos (o todos)
para no
tener que repetir trabajo tonto y realizar tareas que podríamos
llamar "secundarias" como, por ejemplo, generar/buscar un
pequeño conjunto de documentos o pasajes
relevantes para las preguntas y así la(s) persona(s) que
trabaja(n) con la parte de extracción de la respuesta no tengan
que esperar por la(s) persona(s) que trabaja(n) en la
recuperación y selección de pasajes. Para todo ello se
habilitarán en la página de Moodle una serie de foros de
discusión.
- Un resultado del 15-20% de acierto se consideraría muy
bueno incluso para gente que se dedique a esto. Por lo
tanto, no os extrañe ni os preocupe si el rendimiento final de
vuestro sistema es muy bajo.
- No
se pretende implementar un sistema superoptimizado que
conteste a una pregunta en segundos de forma totalmente
automática. El sistema puede funcionar off-line y en diferentes
etapas: procesar las preguntas todas a la vez sobre Linux, tomar luego
esa salida y
mandarlas a un segundo módulo que trabaja sobre Windows para
obtener todos los documentos,
etc. De igual modo, si tarda varias horas en completar el proceso
completo para el conjunto total de preguntas, no pasa nada.
- Las
florituras innecesarias
que no aporten funcionalidad extra alguna (p.ej. super-interfaz de mero
adorno) no
serán tenidas en cuenta ni positiva ni negativamente de cara a
la nota.
- TreeTagger:
etiquetador-lematizador
disponible
en
varios
idiomas,
castellano
inclusive.
- WordNet: la popular
base de datos léxica (sólo inglés)
- FreeLing:
toolkit de libre distribución para NLP sobre diversos idiomas (español, gallego,
catalán, italiano e inglés).
- NLTK, Natural Language
Toolkit: módulos open-source en Python para diversas tareas de
NLP, corpus lingüísticos y buena documentación. Si
se utiliza, es recomedable mirar el libro Natural Language Processing with
Python --- Analyzing Text with the Natural Language Toolkit
disponible on-line.
- Stanford NLP tools,
otro
de
los
clásicos. Toolkits en Java para NLP de base
estadística
- LingPipe, toolkit de
Java para NLP
- OpenNLP, un
conjunto de herramientas NLP en Java. Pensadas para utilizar
encadenadas mediante pipelines. Escasa documentación.
- GATE (General Architecture for
Text Engineering): toolkit para NLP implementado en Java. Incluye
el sistema de Extracción de Información ANNIE (A Nearly-New Information
Extraction System).
- SharpNLP, conjunto de
herramientas de NLP en C#
- WordFreak, una
herramienta basada en Java para dar soporte a la anotación
manual y automática de textos, compatible con el aprendizaje
activo. Se puede combinar con las herramientas de OpenNLP.
- NOOJ: toolkit para NLP.
Basado en autómatas y traductores finitos, permite la
implementación de etiquetadores y herramientas basadas en la
correspondencia de patrones léxicos, morfológicos y
sintácticos.
- Cognitive Computation
Group (Univ. of Illinois Urbana-Champaign): en su sección de
"software" proporcionan numerosas herramientas de NLP (shallow parsers,
taggers, etc.) puestos a disposición de la comunidad
investigadora
- LIBNAFDA,
Librería
para
el
manejo eficiente de diccionarios de gran
tamaño, basada en autómatas finitos acíclicos
deterministas numerados.
- Apache Mahout:
librerías para Machine
Learning y Data Minig
TUTORIALES:
FOROS
DE EVALUACIÓN:
La
investigación en el ámbito de sistemas de BR ha
avanzado notablemente en los últimos años gracias a
diversos congresos que actúan como auténticos foros de
evaluación y lugar de encuentro e intercambio de ideas. Las
actas (proceedings) de estos
congresos constituyen una de
las principales fuentes bibliográficas acerca del tema: