CS276B Text Retrieval and Mining Winter 2005 Lecture 15

Plano do dia Abordagens no espaço vetorial para recuperação XML Avaliando recuperação centrada em texto

Recuperação XML centrada no texto Documentos marcados como XML Ex., manuais de montagem, questões de jornais … Consultas são as informações que o usuário nessecita Ex., me dê a Seção (elemento) de um documento que fala como trocar uma lâmpada quebrada Diferente das consultas XML bem estruturadas onde você especifica exatamento o que está procurando.

Espaço vetorial e XML Espaços vetoriais – framework experimentado+testado para recuperação de palavra-chave Outras aplicações de “sacola de palavras” em texto: classificação, clusterização … Para recuperação centrada em texto, podemos usar a idéia de espaço vetorial? Desafio: capturar a estrutura de um documento XML document no espaço vetorial.

Espaço vetorial e XML Por exemplo, distinguir entre os dois casos seguintes Book Title Author Bill GatesMicrosoft Book Title Author Bill Wulf The Pearly Gates

XML rico em contexto: representação Book Title Author BillMicrosoft Book Title Author WulfPearly Gates The Bill Termos lexicos.

Codificando os Gates diferentes Quais são os eixos do espaço vetorial? Em recuperação textual, vai existir apenas um eixo para Gates Nós precisamos separar as duas ocorrências, embaixo de Autor e Título Assim, os eixos devem representar não apenas os termos, mas também alguma coisa sobre sua posição na árvore XML

Consultas Antes de abordar isto, vamos considerar os tipos de consulta que queremos tratar Book Title Microsoft Book Title Author Gates Bill

Tipos de consultas Os exemplos anteriores podem ser vistos como subárvores do documento Mas e sobre? (Gates em algum lugar abaixo de Book ) É difícil, mas vamos retornar a isto depois. Book Gates

Subárvores e estrutura Considere todas as subárvores do documento que inclui ao menos um termo lexicalizado Book Title Author BillMicrosoftGates BillMicrosoft Gates Title Microsoft Author Bill Author Gates Book Title Microsoft Bill Book Author Gates e.g. …

Termos estruturais Chamamos cada subárvore de resultado (8+, no slide anterior) de termos estruturais Note que termos estruturais pode ocorrer muitas vezes em um documento Crie um eixo no espaço vetorial para cada termo estrutural distinto A ponderação é baseada na frequencia do número de ocorrencias (assim como tínhamos em tf) Todas as questões usuais com termos (stemming? Case folding?) continuam

Exemplo de ponderação tf Aqui os termos estruturais que contém to ou be tem mais peso que aqueles que não contém Play Act To be or not to be Play Act be Play Act or Play Act not Play Act to

Ponderação descendente Para o documento da esquerda: em um termo estrutural com raiz no nó Play, Hamlet não deve ter um peso tf maior que Yorick? Idéia: multiplicar a contribuição tf de um termo ao nó k níveis acima por  k, para algum  < 1. Play Act Alas poor Yorick Scene Title Hamlet

Exemplo de ponderação descendente,  =0.8 Para o documento do slide anterior, o tf de Hamlet é multiplicado por 0.8 Yorick é multiplicado por 0.64 Em qualquer termo estrutural com raiz em Play.

O número de termos estruturais Pode ser enorme! É Impraticável construir um índice no espaço vetorial com tantas dimensões Iremos examinar soluções pragmáticas para isto em breve; por enquanto, continue acreditando … Tudo bem, quão grande, realmente?

Termos estruturais: documentos+consultas A noção de termos estruturais é independente de qualquer schema/DTD para os documentos XML Bem aplicado a coleções heterogêneas de documentos XML Cada documento se torna um vetor no espaço de termos estruturais Uma árvore de consulta pode igualmente ser fatorado em termos estruturais E representado como vetor Permite a reponderação de porções da consulta

Exemplo de consulta Book Title Author GatesBill Title Author GatesBill Book Title Gates 0.6 Book Author Bill 0.4 …

Propagação do peso A atribuição de pesos de 0.6 e 0.4 no exemplo anterior para subárvores era simplista Pode ser mais sofisticado Pense nisso como gerado por uma aplicação, não necessariamente um usuário final Consultas, documentos se tornam vetores normalizados A computação da pontuação de recuperação é “apenas” uma questão computação de similaridade de cossenos

Termos estruturais restritos? Dependendo da aplicação, nós podemos restringir os termos estruturais Ex., podemos nunca querer que seja retornado um nó Title, apenas nós Book ou Play Então não enumere/indexe/recupere/pontue termos estruturais com raiz em alguns nós

A captura continua Isso tudo é muito promissor, mas … Quão grande é o espaço vetorial? Pode ser exponencialmente grande do tamanho do documento Não podemos ter esperança para construir um índice assim E em qualquer caso, ainda falha para responder consultas como Book Gates ( algum lugar entre)

Duas soluções Materialização de eixos no tempo da consulta Restringir os tipos de subárvores para um conjunto gerenciavel

Materialização no tempo do consulta Em vez de emunerar todos os termos estruturais de todos os documentos (e consulta), enumere apenas para a consulta Este último é esperançosamente um conjunto menor Agora, nós reduzimos à verificação de que termo(s) estruturais da consulta corresponde(m) a uma subárvore de qualquer documento Esta é a correspondência de árvore padrão: dado uma árvore de texto e uma árvore padrão, encontre correspondências Exceto se temos muitas árvores de texto Nossas árvores são rotuladas e pesadas

Exemplo Aqui nós procuramos um documento com Hamlet no título Ao encontrar correspondência nós calculamos o ponto de similaridade de cossenos Depois de todas as correspondência são encontradas, rakeamos por ordenação Play Act Alas poor Yorick Scene Texto = Consulta = Hamlet Title Hamlet Title

(Ainda inviável) Um documento com Yorick em algum lugar: Consulta = Vamos chegar a isso … Yorick Title

Restringindo subárvores Enumerar todos os termos estruturais (subárvores) é proibitivo, para a indexação A maioria de árvores pode nunca ser usada para processar qualquer consulta Será que podemos ir longe com a indexação de uma classe restrita de subárvores Idealmente - foco em árvores que possam surgir em consultas

JuruXML (IBM Haifa) Apenas caminhos incluindo um termo lexicalizado Neste exemplo existe apenas 14 ( por que?) destes caminhos Assim nós temos 14 termos estruturais no índice Play Act To be or not to be Scene Title Hamlet Por que isto é muito mais gerenciável? Quão grande pode um índice ser como uma função do texto?

Variações Poderia ter usado outra subárvore – ex., todas as árvores com dois irmãos em um nó Que subárvores serão usadas: depende da provável consulta na aplicaço Pode ser especificado no tempo de indexação - área com pouca pesquisa até agora Book Title Author BillMicrosoftGates Book Title Author BillMicrosoft 2 terms Gates

Variações Porque isso seria diferente de simplesmente caminhos? Porque nós preservamos mais a estrutura que uma consulta pode procurar Book Title Author BillMicrosoft Title Author GatesBill Book Title Gates Book Author Bill vs.

Descendentes Retornando para os exemplos de descendentes: Yorick PlayBook Author BillGates vs. Book Author BillGates FirstNameLastName DTD não conhecido. Consulta busca Gates embaixo de Author.

Manipulando descendentes no espaço vetorial Elaborar uma função de correspondência que rende um ponto em [0,1] entre termos estruturais Ex., quando os termos estruturais são caminhos, medimos sobreposição Quanto maior a sobreposição, maior a pontuação de correspondência Podemos ajustar a correspondência para quando a sobreposição ocorre Book Author Bill Book Author Bill LastName Book Bill vs. em

Como usamos isto em recuperação? Primeiro enumeramos os termos estruturais na consulta Medimos cada um para correspondência contra o dicionário de termos estruturais Assim como a pesquisa de postings, exceto que não booleano (o termo existe ou não) Ao invés disso, produz um ponto que diz “é 80% próximo ao termo estrutural”, etc. Então, recupera documentos com aquele termo estrutural, calcula o cosseno de similaridades, etc.

Função de semelhança de contexto (semelhança de estrutura) Cq = caminho da consulta Cd = caminho do documento |Cq| e |Cd| número de nós do caminho Cq corresponde a Cd se podemos transformar Cq em Cd inserindo nós adicionais

Exemplo da Função de Semelhança

Exemplo de um passo de recuperação ST1 Doc1 (0.7)Doc4 (0.3)Doc9 (0.2) ST = Structural Term ST5 Doc3 (1.0)Doc6 (0.8)Doc9 (0.6) Index Query ST Match =0.63 Agora classifique os documentos por similaridade de cossenos; Neste exemplo o documento com maior classificação é o Doc9: 1,0 x 0,2 + 0,63 x 0,6 = 0578 então, Doc9 tem pontuação Match =1

Closing technicalities Mas o que exatamente é um Doc? Em um sentido, um corpus (conjunto de textos que servem como base de análise) inteiro pode ser visto como um documento XML Corpus Doc1Doc2 Doc3Doc4

O que são os documentos em um índice? Qualquer coisa que preparamos para retornar como resposta Pode ser nós, alguns dos seus filhos …

Quais são as consultas que não podem ser tratadas usando espaço vetorial? Encontra figuras que descrevem a arquitetura do Corba e os parágrafos que se referem a estas figuras Requer JOIN entre 2 tabelas Recupere os títulos de artigos publicados na seção de Special Feature da revista IEEE Micro Depende da ordem de nós irmãos.

Podemos calcular IDF? Sim, mas não faz sentido fazer isso em escala corpus Pode ser feito, por exemplo, dentro de todo texto abaixo de um certo nome de elemento, digamos Chapter Produz um peso tf-idf para cada termo abaixo do elemento Questões: como vamos propagar as contribuições para nós de nível superior.

Exemplo Digamos que Gates tem um IDF alto abaixo do elemento Author Como deve ser o peso tf-idf do elemento Book ? Devemos usar o idf para Gates em Author ou em Book ? Book Author BillGates

INEX: um benchmark para a recuperação XML centrada em texto

INEX Benchmark para avaliação de recuperação XML Análogo do TREC (relembre CS276A) Consiste de: Conjunto de documentos XML Coleção de tarefas de recuperação

INEX Cada mecanismo indexa documentos Time de mecanismos converte tarefas de recuperação em consultas Em linguagem de consulta XML compreendida pelo mecanismo Em resposta, o mecanismo não recupera documentos, mas os elementos dentro dos documentos Mecanismo classifica os elementos recuperado

Avaliação INEX Para cada consulta, cada elemento recuperado é avaliado por humanos em duas medidas: Relevância – o quão relevante é o documento recuperado Cobertura – o elemento recuperado é muito específico, muito geral, ou apenas certo Ex., se a consulta busca uma definição de Transformação Rápida de Fourier, posso obter a equação (muito específico), o capítulo contendo a definição (muito geral) ou a própria definição Estas avaliações são transformadas em medidas compostas precisão/retorno

Corpus INEX 12,107 artigos de publicações da IEEE Computer Society 494 Megabytes Média de artigos:1,532 nós XML Média de profundidade de nós = 6.9

Tópicos INEX Cada tópico é uma necessidade de informação, um de dois tipos: Somente Conteúdo (CO) – Consultas de texto livre Conteúdo e Estrutura (CAS) – limitações estruturais explícitas, ex., condições de contenção.

Exemplo de tópico CO do INEX computational biology computational biology, bioinformatics, genome, genomics, proteomics, sequencing, protein folding Challenges that arise, and approaches being explored, in the interdisciplinary field of computational biology To be relevant, a document/component must either talk in general terms about the opportunities at the intersection of computer science and biology, or describe a particular problem and the ways it is being attacked.

Avaliação INEX Cada mecanismo formula o tópico como uma consulta Ex., usa palavras-chaves listadas em um tópico. Mecanismo recupera um ou mais elementos e classifica-os. Avaliadores humanos atribuem para cada elemento recuperado pontos de relevância e cobertura.

Avaliações Avalia relevância em uma escala de Irrelevante (pontuação 0) até Altamente Relevante (pontuação 3) Avaliação de cobertura em uma escala com quatro níveis: Sem cobertura (N: o tópico da consulta não corresponde a nada no elemento) Muito grande (L: o tópico é apenas um tema menos do elemento recuperado) Muito pequeno (S: o elemento é muito pequeno para prover a informação requerida) Exato (E). Então todo elemento retornado pelo mecanismo de busca tem classificação do tipo {0,1,2,3} × {N,S,L,E}

Combinando as avaliações Definindo pontos:

Os valores f Medida escalar da bondade (goodness) dos documentos recuperados Pode computar os valores f para diferentes números de elementos recuperados 10, 20 … etc. Meios para comparar mecanismos.

Resources Querying and Ranking XML Documents Torsten Schlieder, Holger Meuss Generating Vector Spaces On-the-fly for Flexible XML Retrieval. T. Grabs, H-J Schek -xml/xmlirws.pdf -xml/xmlirws.pdf

Resources JuruXML - an XML retrieval system at INEX'02. Y. Mass, M. Mandelbrod, E. Amitay, A. Soffer. See also INEX proceedings online.