RELATÓRIO PRELIMINAR. sobre INFRA ESTRUTURA DE UM SERVIÇO ONLINE DE RESPOSTA A PERGUNTAS COM BASE NA WEB PORTUGUESA. realizado no

Transcrição

1 DEPARTAMENTO DE INFORMÁTICA Faculdade de Ciências - Universidade de Lisboa Bloco C6 - Piso 3 - Campo Grande, Lisboa Tel & Fax: 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 lino.rodrigues@di.fc.ul.pt 20 de Novembro de 2006

2 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á amadureceram, 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

3 ÍNDICE GERAL 1 INTRODUÇÃO DESCRIÇÃO DO PROJECTO Contexto Objectivos Metodologia Planeamento de tarefas ARQUITECTURA DO SISTEMA Processamento da questão Recolha de documentos Extracção de respostas IMPLEMENTAÇÃO DO SISTEMA Processamento da questão Recolha de documentos Extracção de respostas A primeira versão de desenvolvimento RESTANTE TRABALHO REALIZADO...15 ANEXO A: Lista de serviços online de resposta a perguntas...16 ANEXO B: TREC/QA

4 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 sistema 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 projectada, 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 desenvolvimento 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 sistema: 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

5 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 necessidades, 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

6 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 subobjectivo consistirá na adaptação das ferramentas e recursos linguísticos que já existem (e.g. segmentador 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

7 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, nomeadamente uma taxonomia de perguntas/respostas. A arquitectura referida no ponto 1 modela um programa servidor acessível online que recebe pedidos 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 funcionamento 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ísticos 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 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) Setembro Outubro 7

8 Tarefas por realizar Interface do serviço online; Processador de perguntas; Ontologia de respostas; Seleccionador de respostas (avançado); Optimização; Dissertação. Planeamento Nov. Dez. Jan. Fev. Mar. Abr. Maio Interface online Proc. perguntas Ontologia Selec. respostas Optimização Dissertação 8

9 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 componentes 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 tipo de resposta esperado + padrão sintáctico + palavras chave Extracção de respostas 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, à pergunta 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

10 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ísticas 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 processo 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

11 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 prosseguiu 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 processo 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

12 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 originalmente 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

13 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 snippet 1 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 documentos é 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 recolhidos. 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. Posteriormente, 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 parcialmente 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

14 fim de linha. Infelizmente, o módulo de recolha de documentos extrai o texto dos documentos usando 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 palavraschave. 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 encontrar 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

15 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. Familiarização com o estado da arte em RP; 2. Apresentação interna ao grupo; 3. Pesquisa e listagem dos serviços RP de domínio aberto existentes online; 4. 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

16 ANEXO A Lista de serviços online de resposta a perguntas Serviços activos Autor / Instituição Endereço AnswerBus Zhiping Zheng Arizona State University Dmitri Roussinov Ask.com 1 IAC Search & Media asked! Ed Whittaker Brainboost Answers Corp. LCC Language Computer Corp. NSIR CLAIR (Michigan Univ.) START MIT/AI Lab TellMe Luiz Pizzato (Macquarie Univ.) Indisponíveis LAMP IONAUT QuASM SiteQA Demo Universidade de Singapura Steve Abney, Michael Collins UMASS/CIIR DiQuest.com Inc. bin/smadellz/lamp_query.pl Serviços relacionados (listagem não extensiva) Answers.com 2 Wondir 3 Yahoo! Answers 3 Answers Corp. Wondir, Inc. Yahoo! (1) Anteriormente AskJeeves. Proporciona respostas a certas perguntas; para outras apenas recolhe documentos. (2) Incorpora documentos de várias fontes predefinidas. (3) Procura respostas doutros utilizadores. 16

17 ANEXO B TREC/QA A Text REtrieval Conference é realizada anualmente nos E.U.A desde 1992, com o propósito principal 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 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 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

18 ( other ) pedindo mais informação, equiparável às perguntas de definição da TREC 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) 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 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 utilizadores através de formulários HTML. 18

19 BIBLIOGRAFIA [1] Branco, A. e Silva, J. (2004). Evaluating Solutions for the Rapid Development of State ofthe Art POS Taggers. In Proceedings of the 4th Language Resources and Evaluating Conference (LREC), [2] Heaton, J. Parsing HTML with Swing. [3] Text Retrieval Conference, QA track. [4] TREC 2006 ciqa Task Homepage. [5] Voorhees (2003). Overview of the TREC 2003 Question Answering Track. TREC [6] Voorhees (2004). Overview of the TREC 2004 Question Answering Track. TREC [7] Voorhees (2005). Overview of TREC TREC 2005 [8] Zheng (2002). AnswerBus Question Answering System. HLT

20 20