RELATÓRIO PRELIMINAR sobre

DEPARTAMENTO DE INFORMÁTICA
Faculdade de Ciências - Universidade de Lisboa
Bloco C6 - Piso 3 - Campo Grande, 1749-016 Lisboa
Tel & Fax: 351.217500084
RELATÓRIO PRELIMINAR
sobre
INFRA­ESTRUTURA DE UM SERVIÇO ONLINE
DE RESPOSTA­A­PERGUNTAS
COM BASE NA WEB PORTUGUESA
realizado no
NLX ­ GRUPO DE FALA E LINGUAGEM NATURAL
DEPARTAMENTO DE INFORMÁTICA
FACULDADE DE CIÊNCIAS DA UNIVERSIDADE DE LISBOA
por
Lino Miguel Silva Rodrigues
[email protected]
20 de Novembro de 2006
RESUMO
A Internet promoveu uma nova forma de comunicação global, com impacto profundo na disseminação da informação. Em consequência, exige novas soluções tecnológicas que permitam explorar esses recursos. Numa era em que os motores de busca já amadurece­
ram, o próximo passo é permitir que os utilizadores da rede obtenham breves respostas a perguntas específicas.
A web portuguesa ainda não é explorada através de Resposta­a­Perguntas tal como já é tecnologicamente viável. O objectivo principal do projecto QueXting, encetado pelo grupo NLX, é contribuir para um melhor acesso à informação, através da realização de perguntas em Português e da obtenção de respostas a partir da informação disponível nos documentos escritos em língua portuguesa.
O Projecto em Engenharia Informática aqui descrito visa implementar, no âmbito do projecto QueXting, um sistema de resposta a perguntas factuais na língua portuguesa. Este sistema terá como pilares a arquitectura e metodologia recentemente amadurecidas no campo de resposta­a­perguntas e algumas ferramentas linguísticas para o Português que o NLX tem vindo a desenvolver.
Projecto de Engenharia Informática (60 ECTS) realizado no âmbito do Mestrado em Engenharia Informática, Faculdade de Ciências da Universidade de Lisboa.
2
ÍNDICE GERAL
1 INTRODUÇÃO................................................................................................................................4
2 DESCRIÇÃO DO PROJECTO........................................................................................................5
2.1 Contexto...............................................................................................................................5
2.2 Objectivos.............................................................................................................................6
2.3 Metodologia.........................................................................................................................6
2.4 Planeamento de tarefas.........................................................................................................7
3 ARQUITECTURA DO SISTEMA..................................................................................................9
3.1 Processamento da questão....................................................................................................9
3.2 Recolha de documentos......................................................................................................10
3.3 Extracção de respostas........................................................................................................10
4 IMPLEMENTAÇÃO DO SISTEMA.............................................................................................11
4.1 Processamento da questão..................................................................................................11
4.2 Recolha de documentos......................................................................................................11
4.3 Extracção de respostas.......................................................................................................13
4.4 A primeira versão de desenvolvimento..............................................................................14
5 RESTANTE TRABALHO REALIZADO......................................................................................15
ANEXO A: Lista de serviços online de resposta­a­perguntas............................................................16
ANEXO B: TREC/QA........................................................................................................................17
3
1 INTRODUÇÃO
Este capítulo inicial descreve brevemente o presente relatório preliminar, o projecto nele relatado, o enquadramento institucional, e o trabalho realizado durante os dois meses que antecederam a redac­
ção deste relatório. No Capítulo 2, o projecto será alvo de uma descrição pormenorizada ao nível do seu contexto, objectivos, metodologia e planeamento. O Capítulo 3 aborda a arquitectura do sistema em desenvolvimento, e os Capítulos 4 e 5 relatam o trabalho realizado respectivamente dentro e fora do âmbito da implementação do sistema.
O Projecto de Engenharia Informática
O presente Projecto de Engenharia Informática (PEI) visa desenvolver a infra­estrutura de um siste­
ma online de Resposta­a­Perguntas (RP), de domínio aberto. O sistema permitirá a realização de perguntas factuais em língua portuguesa e a obtenção de respostas a partir dos documentos escritos em Português existentes na Internet, e será disponibilizado gratuitamente através de uma página na Internet. O desenvolvimento desta infra­estrutura envolve a implementação da arquitectura pro­
jectada, a adaptação e o desenvolvimento de ferramentas linguísticas específicas para o Português e/ou para RP, a criação de uma página web que sirva de interface para os utilizadores, e um processo geral de optimização ao nível do desempenho e dos resultados devolvidos.
Enquadramento institucional
Este PEI enquadra­se no projecto de I&D QueXting do Grupo de Fala e Linguagem Natural (NLX) do Departamento de Informática da FCUL. O NLX realiza actividades de investigação e desenvol­
vimento nos domínios de inteligência artificial e ciência cognitiva, focando­se particularmente em interacção em linguagem natural. O grupo tem vindo a desenvolver diversos recursos e ferramentas linguísticas para o processamento computacional da língua portuguesa. QueXting é um projecto financiado pela Fundação para a Ciência e Tecnologia (FCT), sob o contrato POSI/PLP/61490/2004.
Trabalho realizado até agora (2 meses)
Nesta primeira fase de trabalho, foram levadas a cabo três tarefas principais.
Integração no projecto QueXting: estudo da arquitectura do sistema; pesquisa sobre os sistemas de resposta­a­perguntas existentes online; familiarização com algumas soluções desenvolvidas no domínio de resposta­a­perguntas para responder a perguntas factuais; consolidação da aprendizagem através de uma apresentação interna do grupo.
Reactivação e extensão do código existente com vista à obtenção de uma versão básica do sis­
tema: familiarização com o código existente, respeitante ao segundo dos três módulos principais da arquitectura do sistema; desenvolvimento de outro módulo essencial; verificação do funcionamento do sistema desenvolvido até à data.
Criação de uma página web descrevendo o projecto QueXting.
4
2 DESCRIÇÃO DO PROJECTO
O presente capítulo descreve pormenorizadamente o projecto ao nível do seu contexto, objectivos, metodologia e planeamento de tarefas.
2.1 Contexto
Informação na Web
O estabelecimento da Internet ofereceu novas oportunidades de acesso a informação e serviços; entretanto fez também surgir novas necessidades na exploração dessas oportunidades. Isto é especialmente visível no que diz respeito a ferramentas para lidar com grandes quantidades de informação de forma relevante e atempada, dado que a informação espalhada pelo ciberespaço constitui ela própria uma enorme rede de conhecimento. Os actuais motores de busca (ex. Yahoo!, Google) constituem uma primeira geração de instrumentos úteis para responder a estas neces­
sidades, permitindo encontrar documentos que poderão ser relevantes dadas as palavras­chave introduzidas pelo utilizador.
Figura 1: Caixa de pesquisa num motor de recuperação de documentos
Figura 2: Exemplo de lista de resultados relevantes
Avanços em Resposta­a­Perguntas
Porém, mais que uma pilha de documentos, é frequente o cibernauta precisar de respostas para questões específicas, como “Quem foi a segunda pessoa a pisar a Lua?” ou “Qual é a diferença entre ovos de galinha brancos e castanhos?”. Questionar é uma forma natural de expressão e raciocínio do ser humano, que não se traduz simplesmente em palavras­chave e não exige apenas documentos relevantes. De facto, mesmo documentos relevantes (cujo assunto se refere realmente à pesquisa feita) podem não conter uma resposta. Por exemplo, o primeiro documento devolvido pelo Google à pesquisa “Quem são os Gato Fedorento?” é o blogue desse grupo de comediantes, contudo em nenhuma parte desse blogue é dada uma resposta específica.
Nos últimos anos, vários projectos de I&D têm formulado técnicas para sistemas RP que obtêm uma resposta concreta, e não uma lista de documentos, em resultado de uma pergunta formulada em linguagem natural [3]. Protótipos que participam em competições como a TREC/QA (Text Retrieval 5
Conference / Question Answering track – anexo B) têm vindo a mostrar progressos neste domínio [Vorhees 03, 04, 05].
Interrogar a rede portuguesa
Havendo sistemas RP de acesso livre e sem restrição de domínio cuja base de conhecimento é a web (cf. listagem no anexo A), um aspecto relevante a focar é o de que essas aplicações são centradas na língua Inglesa. Mesmo quando é permitido ao utilizador introduzir perguntas em Português (por exemplo, no caso do AnswerBus), as questões são traduzidas automaticamente para Inglês e é a rede de documentos em Inglês que é pesquisada para se obter respostas para essas traduções.
A questão da língua constitui um problema desconhecido na busca de documentos: um motor de busca é em grande medida independente dos idiomas visto os algoritmos que usa serem apropriados para encontrar documentos escritos em qualquer língua. Porém, um sistema RP usa ferramentas de Processamento de Linguagem Natural (PLN) que o restringem a encontrar respostas a partir de documentos escritos em idiomas com os quais esses componentes PLN possam lidar.
O projecto QueXting
Tal como a maioria das redes de idiomas diferentes do Inglês, a rede portuguesa ainda não se encontra acessível através de RP tal como é já tecnologicamente viável. O projecto QueXting do grupo NLX pretende colmatar essa lacuna, proporcionando um melhor acesso à informação pelos utilizadores da rede portuguesa. Para tal, pretende oferecer livre acesso online a um serviço RP para obter respostas a perguntas factuais formuladas em Português, com base na informação contida na rede dos documentos escritos em Português.
O PEI descrito neste relatório visa a implementação da infra­estrutura projectada para o sistema QueXting. As próximas secções deste capítulo pormenorizam a forma como esse objectivo global deverá ser concretizado.
2.2 Objectivos
O objectivo essencial deste PEI consiste, portanto, na concretização da infra­estrutura do sistema RP QueXting. Este objectivo implica o estudo da arquitectura prevista (descrita em pormenor no próximo capítulo) e a implementação dos módulos que a constituem.
Os módulos em questão deverão socorrer­se de ferramentas linguísticas, algumas delas específicas para o Português, que foram, estão a ser, ou serão desenvolvidas pelo grupo NLX. Portanto, um sub­
objectivo consistirá na adaptação das ferramentas e recursos linguísticos que já existem (e.g. seg­
mentador de frases, ontologias), e no desenvolvimento de outros que ainda não estão concretizados (e.g. taxonomia de perguntas/respostas).
Outro objectivo importante consiste na disponibilização do serviço RP, ou seja, na colocação do motor online através de uma página web, o que implicará uma avaliação e optimização da qualidade do serviço e dos resultados obtidos nas pesquisas.
2.3 Metodologia
A montagem rápida de um sistema RP para Português será alcançada através de:
1. Adopção de uma arquitectura de sistema e métodos independentes de idioma que têm sido 6
testados e amadurecidos recentemente pela I&D em RP para outros idiomas;
2. Uso dos motores de busca disponíveis online para construir o corpus de documentos­fonte onde poderão ser encontradas respostas;
3. Exploração do potencial dos recursos e ferramentas de PLN que o NLX tem desenvolvido (analisador sintáctico, segmentador de excertos, reconhecedor de entidades nomeadas, etc.), usando­os como componentes para adequar o motor RP à língua portuguesa;
4. Desenvolvimento de ferramentas adicionais, específicas para RP em Português, nomeada­
mente uma taxonomia de perguntas/respostas.
A arquitectura referida no ponto 1 modela um programa servidor acessível online que recebe pedi­
dos de clientes através da página web do sistema. Os detalhes da arquitectura deste sistema servidor serão descritos no capítulo seguinte.
A abordagem ao desenvolvimento é iterativa: após uma versão básica que demonstre o funciona­
mento dos componentes essenciais, os módulos do sistema serão completados para obter uma versão avançada e, posteriormente, optimizados com vista à obtenção de um desempenho razoável em termos de tempo e resultados.
2.4 Planeamento de tarefas
As tarefas planeadas estão estreitamente ligadas aos objectivos do PEI e do projecto QueXting. Como tal, existem tarefas relacionadas com o desenvolvimento do sistema, com os recursos linguís­
ticos em que este se apoia, e com o serviço online.
Tarefas realizadas
●
●
●
●
●
●
●
Familiarização com o estado do campo de RP, com o projecto QueXting e com a arquitectura prevista do sistema;
Apresentação interna;
Operador de motores de busca;
Seleccionador de documentos;
Seleccionador de respostas (simples);
Primeira versão de desenvolvimento do sistema;
Página web para descrição do projecto QueXting.
Execução
Setembro Outubro
Familiarização
Apresentação
Operador de motores de busca
Seleccionador de documentos
Seleccionador de respostas
1ª versão de desenvolvimento
Página web (descrição)
7
Tarefas por realizar
●
●
●
●
●
●
Interface do serviço online;
Processador de perguntas;
Ontologia de respostas;
Seleccionador de respostas (avançado);
Optimização;
Dissertação.
Planeamento
Interface online
Proc. perguntas
Ontologia
Selec. respostas
Optimização
Dissertação
Nov.
Dez.
Jan.
8
Fev.
Mar.
Abr.
Maio
3 ARQUITECTURA DO SISTEMA
Neste capítulo é descrita em pormenor (excepto, nesta fase preliminar, ao nível das ferramentas ainda por utilizar ou desenvolver) a arquitectura projectada para o sistema em desenvolvimento. Como referido em relatórios das últimas conferências TREC/QA, a arquitectura básica de sistemas de resposta a perguntas factuais não tem mudado, tendo amadurecido nos últimos anos [Vorhees, 04]. O sistema AnswerBus, descrito em [Zheng, 02] constitui o ponto de partida de referência.
O sistema em desenvolvimento segue estas referências e é composto por três módulos principais: (i) processamento da questão, (ii) recolha de documentos e (iii) extracção de respostas. Estes compo­
nentes são invisíveis para o utilizador, que apenas interage com a página onde irá realizar a pergunta e obter respostas. O diagrama seguinte mostra o fluxo de informação desde a entrada até à saída do sistema, passando pelos módulos referidos:
questão
Processamento da questão
palavras­chave
Recolha de documentos
documentos seleccionados
Extracção de respostas
tipo de resposta esperado
+ padrão sintáctico
+ palavras­chave
respostas
Diagrama 1: Fluxo de informação através dos módulos da arquitectura
As ferramentas e os recursos linguísticos utilizados neste processo serão abordados no próximo capítulo, exceptuando aqueles que, neste momento, ainda não foram utilizados ou implementados. O papel de cada um deles será clarificado no relatório final.
3.1 Processamento da questão
O sistema recebe o pedido do utilizador através da interface online: cada pedido corresponde a uma questão factual, que pode (ou não) terminar com um ponto de interrogação.
Frequentemente, uma pergunta contém indícios sobre a resposta correspondente. Este é um dos factores que permite a um sistema RP distinguir as respostas mais adequadas. Por exemplo, à per­
gunta “Quem foi a segunda pessoa a pisar a Lua?” corresponderá certamente uma resposta do tipo pessoa. O mesmo se prevê para a pergunta “Qual foi o segundo astronauta a pisar a Lua?” embora através dum raciocínio diferente. No primeiro caso, as palavras “quem” e “pessoa” são evidências directas; enquanto o segundo caso envolve o conhecimento de que um astronauta é uma pessoa.
Portanto, a expressão que constitui a pergunta pode ser processada de forma a identificar:
a) as palavras­chave que deverão estar presentes na resposta;
b) as palavras que constituem pistas sobre o tipo semântico da resposta;
9
c) o padrão sintáctico dessa resposta.
Em conjunto, a informação destas alíneas permite prever, a partir da própria questão, as caracterís­
ticas da resposta. Esta informação permitirá mais tarde avaliar excertos dos documentos a obter no módulo seguinte.
A identificação de palavras­chave permite ainda construir a query final que é enviada aos motores de busca. A criação desta query envolve um processo de simplificação e outro de expansão. Na simplificação, as palavras funcionais (preposições, conjunções, etc.) são eliminadas; as palavras não funcionais muito frequentes também sofrem o mesmo destino em virtude de terem um impacto negativo na precisão e desempenho do sistema, especialmente no caso de uma query longa. No pro­
cesso de expansão adicionam­se termos semanticamente relacionados com os existentes na query original, melhorando a cobertura do sistema.
3.2 Recolha de documentos
A recolha de documentos relevantes é feita a partir das palavras­chave extraídas na fase anterior, usando motores de busca existentes online. O sistema contacta cada motor escolhido enviando uma query com as palavras­chave, recebe os resultados de topo que são devolvidos, e faz download dos respectivos documentos evitando documentos semelhantes. É, assim, criada uma colecção de textos que servirá de fonte para procurar as respostas específicas. Esta colecção será constituída pelos documentos considerados mais relevantes pelos motores de busca.
Poderá ser considerada a hipótese de usar motores de busca diferentes consoante a pergunta introduzida, possivelmente criando queries específicas para determinados motores. Seja como for, apenas dois ou três motores devem ser escolhidos, para garantir o desempenho do sistema em tempo útil para os utilizadores. Caso sejam utilizados mais motores pelo sistema, pode ser usado um método automático para a escolha dos motores usados para uma determinada query. Uma heurística simples será seleccionar motores que oferecem mais respostas para as palavras individuais que compõem a query [Zheng, 02]. Esta informação acerca do número de respostas previsto para cada palavra pode ser obtida manualmente durante o desenvolvimento do sistema.
3.3 Extracção de respostas
Obtidos os documentos­fonte, resta ao sistema encontrar excertos que contenham uma resposta específica. Esperam­se respostas curtas e directas (além de relevantes), já que o sistema se destina a responder a perguntas factuais.
Antes de mais, as frases têm que ser identificadas, ou seja, isoladas das restantes frases do documento para processamento individual. Em seguida, cada frase é analisada com o objectivo de atribuir um tipo de resposta de acordo com os tipos definidos na taxonomia referida no capítulo anterior. A distância semântica entre o tipo atribuído e o tipo antecipado (no processamento da questão) será um dos factores de ranking da resposta.
As características da frase em termos do tipo de resposta que constitui, padrão sintáctico e presença das palavras­chave são, assim, comparadas com as características esperadas, determinadas durante o processamento da questão. As eventuais semelhanças são pesadas por uma heurística que irá determinar o valor da frase e as candidatas às quais se atribuiu maior valor são retornadas ao utilizador, através da página web, constituindo a resposta do sistema à pergunta introduzida.
10
4 IMPLEMENTAÇÃO DO SISTEMA
Neste capítulo é descrito o trabalho efectivamente realizado ao nível da implementação do sistema RP nos dois primeiros meses do PEI. O desenvolvimento começou pelo módulo central de recolha de documentos, que já dispunha de uma base funcional de código­fonte (escrito em Java), e pros­
seguiu pelo módulo final de extracção de respostas, tendo como objectivo a obtenção de uma primeira versão (básica) do sistema.
A linguagem de programação utilizada durante o desenvolvimento efectuado até ao momento foi a Java (Standard Edition), através do Java Development Kit 5.0 e do IDE Eclipse, em ambiente Linux (Ubuntu 6.06).
4.1 Processamento da questão
Este módulo será o alvo dos próximos desenvolvimentos do sistema; no entanto, no código fonte anteriormente desenvolvido pelo NLX, são já implementadas as seguintes funcionalidades: a recep­
ção da pergunta pelo sistema, a partir de uma página web; e um dos processos de transformação da query a enviar para os motores de busca.
Funcionalidade existente
Num pacote denominado webserver, foram implementadas as classes para a recepção de ligações, através de sockets, provenientes da página web onde os utilizadores introduzem pedidos (perguntas). Estas classes usam ainda as classes do pacote docretriever, que realiza a busca propriamente dita: para cada pedido, é criada uma query para os motores de busca escolhidos. A escolha de motores consiste num só motor ou em todos eles, não existindo ainda nenhum mecanismo automático de escolha por parte do próprio sistema. Para efeitos de teste do sistema, existe uma página básica que permite introduzir a pergunta, escolhendo o(s) motor(es).
A transformação da pergunta original numa query para os motores de busca deve envolver um pro­
cesso de simplificação e outro de expansão. O primeiro destes processos já é abordado: a eliminação de palavras funcionais permite deixar de fora as palavras que não são relevantes para a query. A implementação propriamente dita baseia­se num léxico de palavras de classes morfo­sintácticas fechadas: todas as palavras da pergunta que façam parte do léxico são automaticamente eliminadas. Normalmente, os motores de busca realizam, eles próprios, uma filtragem deste tipo; no entanto, a sua realização pelo próprio sistema permitirá, mais tarde, avaliar as possíveis respostas em termos das palavras­chave mais relevantes.
4.2 Recolha de documentos
Como referido anteriormente, o módulo de recolha de documentos já se encontrava relativamente desenvolvido à data de início deste PEI. Portanto, o trabalho realizado neste módulo consistiu essencialmente na interpretação e teste do código existente. Os testes que foram sendo realizados permitiram detectar alguns problemas que foram corrigidos ou listados para correcção futura. Foram também realizadas melhorias a nível da legibilidade do código.
11
Funcionalidade existente
O pacote docretriever implementa as classes relacionadas com os motores de busca, a query, os documentos, e o download desses documentos. As suas funcionalidades incluem o envio de queries bem definidas para os motores de busca, a recepção e análise dos resultados obtidos, e o download desses resultados (i.e. dos documentos referenciados por URL nos resultados obtidos).
Para tal, estas classes incluem, para cada motor de busca, informação sobre: tipos de links que devem ser chamados (incluindo a restrição de linguagem das páginas a recolher); marcas de início e fim de resultado, link URL e snippet; formato e tamanho estimado de ficheiro. Este pacote usa a classe HttpURLConnection para efectuar a ligação aos motores de busca, e ainda o pacote de expressões regulares da biblioteca do Java para reconhecer as marcas referidas durante o parsing da lista de resultados.
Posteriormente, cada documento extraído da rede também é sujeito a parsing, com o objectivo de reconhecer e extrair o texto útil. É usado o parser de HTML existente na biblioteca swing do Java para este processo. A utilização deste parser é feita através da definição dos métodos que são chamados quando o parser encontra texto, comentários ou determinada etiqueta HTML. No código desenvolvido anteriormente a este PEI, apenas a função handleText() era utilizada, para ir guardando o texto do documento à medida que se lia o respectivo ficheiro HTML. Na secção seguinte aborda­se, entre outros assuntos, uma extensão feita a este parser.
A web é constituída por documentos de vários formatos, e não apenas por páginas HTML. No entanto, certos motores de busca possibilitam obter uma versão HTML de documentos original­
mente noutros formatos (e.g. PDF, DOC, PPT). Esta potencialidade é explorada, quando disponível, e permite ao sistema lidar com diferentes formatos sem precisar de implementar nem executar um conversor ou parser para cada tipo de documento.
Correcções
As restrições de linguagem nas chamadas aos motores de busca foram alvo de correcção (para os motores em falha).
No caso de um dos motores, o download dos documentos devolvidos como resultado da pesquisa não era efectuado. O parsing dos resultados devolvidos por esse motor passou a reconhecer uma marca adicional de início de link URL, sem a qual o URL desse documento não era reconhecido.
Após o download dos documentos, ainda sob a forma de páginas HTML, é obtido o texto propriamente dito, isto é, o conteúdo. No entanto, com alguma frequência, existe código de estilo (nomeadamente de CSS) que é interpretado como texto pelo parser de HTML, o que resulta em texto com algum lixo. Devido a isso, o parser foi extendido para ignorar tudo o que está contido entre as etiquetas <STYLE> e </STYLE>. Infelizmente, o próprio parser parece ter limitações pois há etiquetas desse tipo que não são reconhecidas, o que implica que algum desse lixo ainda se mantém nos textos, apesar de grande parte já ser evitado.
Redundância de documentos
Para evitar obter documentos repetidos, já era realizada uma comparação ao nível dos URLs referenciados nos resultados dos diferentes motores de busca. No entanto, podem existir na rede documentos de conteúdo idêntico, alojados em URLs diferentes. Uma funcionalidade adicionada a este módulo do sistema foi a capacidade de detectar documentos redundantes em termos de conteúdo.
12
As páginas podem ter cabeçalhos e menus diferentes, pelo que uma comparação que dependa da posição do texto não pode ser utilizada. Isso descarta opções simples como a comparação do primeiro parágrafo ou do documento inteiro linha­a­linha (potencialmente usando uma percentagem de semelhança para acusar páginas redundantes).
Logo, como ponto de partida, foi criada uma função que verifica se as passagens do snippet1 de um documento (seleccionadas pelo motor de busca e normalmente apresentadas nos resultados) fazem todas parte do conteúdo do outro documento – e vice­versa. Esta forma de comparação dos docu­
mentos é bastante simples, o que poderá constituir uma desvantagem – ocasionalmente podem ocorrer falsos positivos, i.e. documentos erroneamente considerados redundantes devido a um deles conter os excertos do snippet do outro documento – mas também uma vantagem em termos de velocidade de processamento.
Numa fase de optimização do sistema, métodos alternativos de comparação de documentos poderão vir a ser pesquisados e testados.
4.3 Extracção de respostas
O módulo de extracção de respostas deve, em primeiro lugar, extrair excertos dos documentos reco­
lhidos. Para este fim foi usado o segmentador LX­Chunker, desenvolvido anteriormente pelo grupo NLX, aplicando­o sobre o texto de cada um dos documentos recolhidos, permitindo marcar os excertos (parágrafos e frases) que o compõem.
Segmentador
O LX­Chunker é um programa que pode ser utilizado a partir duma linha de comandos no sistema operativo Linux. A sua funcionalidade consiste em tomar o texto que lhe é dado como entrada e assinalar: o início e fim de parágrafos, respectivamente com as marcas <P> e </P>; e o início e fim de frases, respectivamente com as marcas <S> e </S>. O texto com as marcas adicionadas constitui a saída do programa. O seu método de funcionamento é baseado num autómato finito que representa diferentes estados do discurso. Para mais pormenores, ver [Branco & Silva, 04].
Dada a necessidade de executar o segmentador através de uma linha de comandos, foi criado um shell script para ser chamado no código Java. O script recebe como argumentos os nomes dos ficheiros de entrada e saída: o primeiro irá conter o texto de cada documento recolhido, enquanto o segundo irá conter o mesmo texto com as marcas de segmentação. Para cada documento, o texto original, tal como foi reconhecido pelo parser de HTML, é escrito no ficheiro de entrada. Posterior­
mente, as frases são lidas à vez no ficheiro de saída.
Problema no texto dos documentos (revisitado)
Uma característica inevitável e problemática nos documentos extraídos da web é a identificação do conteúdo útil, que constitui realmente o texto do documento. Esta questão já havia levantado o problema da inclusão de código (estilo CSS) no texto dos documentos extraídos, que foi parcial­
mente corrigida. No entanto, ainda levanta outro problema.
Numa página HTML, tudo o que não é código de HTML ou das suas extensões, é considerado texto, pelo que expressões que façam parte de menus ou títulos serão incluídas no texto do documento. No entanto, o segmentador não estava preparado para este tipo de textos, não conseguindo identificar frases que não terminam com sinais de pontuação, a não ser que a frase termine com um caracter de 1 Pequeno conjunto de excertos do documento de origem. Exemplo no capítulo 2, figura 2.
13
fim­de­linha. Infelizmente, o módulo de recolha de documentos extrai o texto dos documentos usan­
do um parser de HTML que ignora estes caracteres de fim­de­linha, resultando em texto que fica todo numa só linha.
A solução encontrada foi voltar a editar o módulo de recolha de documentos, extendendo o parser para reconhecer e lidar com as terminações de linha. O parser passou a ter uma regra para, quando encontrar uma etiqueta HTML do tipo <P> e <BR>, acrescentar ao texto do documento um caracter de fim­de­linha. Desta forma, mesmo as frases que não terminam com a devida pontuação são marcadas correctamente pelo segmentador.
Avaliação de frases
As frases encontradas nos documentos recolhidos são alvo de uma avaliação que permite distinguir as melhores candidatas a fazer parte da lista final de respostas.
Foi criada uma primeira função de avaliação, baseada na função utilizada no AnswerBus [Zheng, 02]. Esta função baseia­se apenas no número de palavras­chave, exigindo um número mínimo de palavras­chave na frase relativamente ao número de palavras­chave identificadas na pergunta inicial. As frases em que esse limite mínimo não é atingido recebem o valor 0; as restantes recebem um valor tanto maior quanto maior for o número de palavras­chave efectivamente presentes. O número de respostas candidatas é limitado pelo que, quando a lista está cheia, uma nova frase só entra na lista se tiver um valor maior que outra frase lá existente. Naturalmente, esta é uma heurística básica que deverá ser melhorada no futuro, para distinguir entre frases com o mesmo número de palavras­
chave. Nesse sentido, o código foi desenvolvido com o intuito de possibilitar diferentes funções de avaliação.
Foram implementadas duas formas de detecção de palavras­chave no texto dos documentos. A primeira realiza uma detecção simples e rápida, ignorando naturalmente as diferenças de case (maiúsculas/minúsculas). A segunda alternativa foi criada para o caso de se querer detectar palavras muito semelhantes, ignorando diferenças mínimas adicionais como, por exemplo, ao nível da acentuação.
4.4 A primeira versão de desenvolvimento
Apesar de o primeiro módulo estar pouco desenvolvido, o estado actual do sistema constitui uma primeira versão de desenvolvimento funcional. A pergunta, excluindo as palavras funcionais, é transformada numa query e passada ao segundo módulo, que usa os motores de busca para encon­
trar e extrair da web os documentos mais relevantes. O texto destes documentos é processado pelo terceiro módulo, sendo já encontradas pelo sistema as frases consideradas mais valiosas pela função de avaliação básica definida. As figuras seguintes exemplificam uma execução possível do sistema:
Figura 3: Pergunta de teste
Figura 4: Primeiras respostas
14
5 RESTANTE TRABALHO REALIZADO
Para além do desenvolvimento do sistema RP propriamente dito, a integração no projecto levou à realização de algumas tarefas adicionais:
1.
2.
3.
4.
Familiarização com o estado da arte em RP;
Apresentação interna ao grupo;
Pesquisa e listagem dos serviços RP de domínio aberto existentes online;
Criação de uma página web de descrição do projecto.
A familiarização com o projecto e com o estado da arte em RP foi essencialmente um trabalho de leitura e pesquisa, tendo sido finalmente produzida uma apresentação e um resumo acerca do tema, em termos de tecnologia e testes de RP, das conferências TREC/QA dos últimos anos (resumo disponível no anexo B).
A pesquisa acerca de serviços RP, permitiu definir algumas referências a ter em conta durante o desenvolvimento do projecto e, possivelmente, a disponibilizar na página web do QueXting. Esta lista de serviços RP está disponível para consulta no anexo A.
Quanto à página web, foi adaptada de outros projectos do NLX, usando como ferramentas auxiliares o editor de imagens GIMP e o editor de HTML Bluefish em ambiente Linux.
15
ANEXO A
Lista de serviços online de resposta­a­perguntas
Serviços activos Autor / Instituição
Endereço
AnswerBus
Arizona State University Ask.com 1
askEd!
Brainboost
LCC
NSIR
START
TellMe
Zhiping Zheng
Dmitri Roussinov
IAC Search & Media
Ed Whittaker
Answers Corp.
Language Computer Corp.
CLAIR (Michigan Univ.)
MIT/AI Lab
Luiz Pizzato (Macquarie Univ.)
http://answerbus.de
http://qa.wpcarey.asu.edu/
http://www.ask.com/
http://asked.jp/
http://www.brainboost.com/
http://www.languagecomputer.com/
http://tangra.si.umich.edu/clair/NSIR/html/nsir.cgi
http://start.csail.mit.edu/
http://www.ics.mq.edu.au/~pizzato/tellme
Universidade de Singapura
Steve Abney, Michael Collins
UMASS/CIIR
DiQuest.com Inc.
http://hal.comp.nus.edu.sg/cgi­bin/smadellz/lamp_query.pl
http://www.ionaut.com:8400/
http://ciir.cs.umass.edu/~reu2/
http://ressell.postech.ac.kr/~pinesnow/siteqeng/
Indisponíveis
LAMP
IONAUT
QuASM
SiteQA Demo
Serviços relacionados (listagem não extensiva)
Answers.com 2
Wondir 3
Yahoo! Answers 3
Answers Corp.
Wondir, Inc.
Yahoo!
http://www.answers.com/
http://www.wondir.com/
http://answers.yahoo.com/
Anteriormente AskJeeves. Proporciona respostas a certas perguntas; para outras apenas recolhe documentos.
(1)
(2)
Incorpora documentos de várias fontes predefinidas.
Procura respostas doutros utilizadores.
(3)
16
ANEXO B
TREC/QA
A Text REtrieval Conference é realizada anualmente nos E.U.A desde 1992, com o propósito princi­
pal de desenvolver a pesquisa sobre recuperação de informação, a sua avaliação e aplicação prática [3]. A conferência envolve uma série de workshops com o objectivo de realizar testes de larga escala e trocas de ideias sobre a tecnologia de recuperação de informação, sendo a tecnologia de RP alvo de um destes workshops [Vorhees, 05]. O foco e a evolução deste evento em anos recentes permitem discernir o estado da arte.
2003
De acordo com [Vorhees 03], no ano de 2003 a TREC/QA envolvia 2 tarefas distintas:
●
●
Passages: dedicada a perguntas factuais. A resposta esperada era um extracto de até 250 caracteres que devia tornar clara a resposta, sem ambiguidades.
Main: factóides, listas e definições. O componente factóide desta tarefa distinguia­se pela exigência de uma resposta exacta em vez de um extracto. As perguntas de listas exigem ainda a construção da resposta a partir de múltiplos documentos. As definições exigem respostas mais complexas que não podem ser avaliadas simplesmente como certas ou erradas; a sua avaliação baseou­se na divisão dos conceitos em pedaços (nuggets) atómicos de informação, devendo as respostas conter pelo menos os nuggets essenciais.
Os métodos utilizados para responder a perguntas factuais não têm mudado significativamente. Os sistemas geralmente determinam o tipo de resposta esperado, recolhem documentos ou passagens que podem conter a resposta a partir de palavras­chave da pergunta e termos relacionados, e realizam um matching entre essas palavras e as passagens recolhidas para extrair uma resposta.
Para responder com listas, muitos dos concorrentes do TREC’03 usaram o mesmo sistema das perguntas factuais, alterando apenas o número de respostas dadas (problema: determinar o número de respostas adequado).
Nas respostas com definições, o importante era encontrar o maior número de nuggets de informação. Usaram­se técnicas distintas; por exemplo, pattern­matching para encontrar padrões, tais como a presença de apositivos nas frases. Tentavam depois eliminar informação redundante, com medidas de sobreposição de palavras ou técnicas de sumarização automática.
Foi a primeira vez que foram integradas perguntas de definições, e a primeira vez que as perguntas de listas tiveram um número significativo de participantes. Os resultados mostraram que estas tarefas apresentam desafios, assim como a sua avaliação. A necessidade de um maior número de perguntas de definições, com vista a solidificar a avaliação, levou a uma reformulação da QA track em 2004.
2004
A TREC’04 [Vorhees, 04] abordou os 3 tipos de perguntas numa só tarefa: cada conceito foi alvo de um conjunto de perguntas factuais, outro conjunto de perguntas de listas, e uma pergunta final 17
(“other”) pedindo mais informação, equiparável às perguntas de definição da TREC 2003. O conjunto total de perguntas para cada alvo constitui uma série.
Exemplo acerca de um escritor:
●
●
●
Factóides: data de nascimento/morte, nacionalidade;
Lista: livros do autor;
Última pergunta: inclui itens como um dos livros ter ganho o prémio X, ou o autor trabalhar na universidade Y.
Dificuldade adicional: reconhecer/remover informação já dada (um dos aspectos essenciais no QA interactivo). O alvo e as perguntas anteriores formam um contexto para a última pergunta.
Não houve grandes novidades em termos tecnológicos (a pergunta “other” foi tratada pelos grupos concorrentes como as perguntas de definições da TREC’03).
2005
A TREC’05 [Vorhees, 05] manteve este esquema, permitindo ainda que os conceitos­alvo fossem também eventos, para além de pessoas, organizações e entidades. Razão: os documentos utilizados como fonte de respostas contêm notícias.
Dado o interesse em examinar o papel das técnicas de recuperação de documentos (document retrieval) no apoio ao QA, foi exigido a cada participante um ranking dos documentos usados para responder a cada questão. Estes dados irão servir de base para comparar as diferentes técnicas de recuperação de documentos.
Outra novidade na TREC’05 foi a abordagem às perguntas relacionais (relationship questions), proposta como tarefa opcional. Definiu­se relação como a capacidade de uma entidade influenciar outra, e identificaram­se 8 esferas de influência: financeira, movimento de bens, laços familiares, linhas (pathways) de comunicação, laços de organização, co­localização, interesses comuns, e temporal. Foi fornecida aos sistemas uma declaração que definia o contexto para uma questão final sobre um dos tipos de influência. A resposta do sistema foi um conjunto de nuggets de informação que proporcionavam as evidências (ou falta delas) para a hipotética relação.
2006
Em 2006, a TREC/QA inclui uma tarefa secundária denominada complex, interactive Question Answering [4]. Esta tarefa pretende promover o desenvolvimento de sistemas capazes de processar pedidos de informação consistindo num template e numa narrativa (que elabora o que o utilizador procura, providencia contexto, etc).
Exemplo:
●
●
Template: What evidence is there for transport of [cigarettes] from [North Carolina] to [Michigan]?
Narrative: The analyst wants to know if there is any evidence that cigarettes are being purchased in North Carolina and then illegally transported and resold in northern states such as Michigan which levy much higher taxes on tobacco.
A componente de interacção é opcional e deve permitir ao sistema solicitar informação aos utiliza­
dores através de formulários HTML.
18
BIBLIOGRAFIA
[1] Branco, A. e Silva, J. (2004). “Evaluating Solutions for the Rapid Development of State­of­
the­Art POS Taggers”. In Proceedings of the 4th Language Resources and Evaluating Conference (LREC), 507­510.
[2] Heaton, J. “Parsing HTML with Swing”. http://www.samspublishing.com/articles/article.asp?p=31059&rl=1
[3] Text Retrieval Conference, QA track. http://trec.nist.gov/data/qa.html
[4] TREC 2006 ciQA Task Homepage. http://www.umiacs.umd.edu/~jimmylin/ciqa/
[5] Voorhees (2003). “Overview of the TREC 2003 Question Answering Track”. TREC 2003.
[6] Voorhees (2004). “Overview of the TREC 2004 Question Answering Track”. TREC 2004.
[7] Voorhees (2005). “Overview of TREC 2005”. TREC 2005
[8] Zheng (2002). “AnswerBus Question Answering System”. HLT2002.
19
20