Introduzione - The e-Lite Research Group

Introduzione
La quantità di informazioni disponibili in formato elettronico negli ultimi anni è
cresciuta in maniera esponenziale, basta pensare al World Wide Web, in cui i
navigatori di Internet trovano centinaia di milioni di pagine, ma anche alle banche
dati disponibili on-line che coprono i campi più disparati: dalla medicina alle
leggi, agli articoli scientifici.
L’aumento della mole di dati consultabili ha però avuto come conseguenza da
parte degli utenti l’accresciuta difficoltà di ricercare le informazioni interessanti
per i propri scopi (tale difficoltà viene sovente indicata come information
overload: impossibilità di trovare le informazioni rilevanti a causa dell’eccessiva
quantità di informazioni da controllare) e, con essa, la necessità di avere a
disposizione degli strumenti efficaci per il recupero dell’informazione.
E’ in questo scenario che si colloca quel settore dell’informatica che va sotto il
nome di Information Retrieval.
Grandi quantità
di dati testuali
Information Retrieval
(IR) systems
Quindi, in poche parole, l’Information Retrieval si occupa dei problemi relativi
alla memorizzazione, rappresentazione e reperimento di documenti.
Da questo semplice grafico si deducono due dei problemi più importanti che
bisogna affrontare. Il primo consiste nel fatto che l’information retrieval
i
Accesso il più
possibile veloce ai
dati rilevanti

generalmente si occupa di dati testuali: gli “oggetti” con cui si ha a che fare sono
tipicamente lettere, articoli, libri, pagine web e via discorrendo. Si tratta quindi di
dati non strutturati, contenenti informazioni che sono espresse in linguaggio
naturale; questo comporta una serie di problematiche da affrontare quando si tratta
di effettuare delle ricerche sul loro contenuto:
• Ambiguità, polisemia: le parole possono avere più significati diversi
• Sinonimia: ci possono essere più modi diversi per esprimere il
medesimo concetto
• Imprecisione: il linguaggio naturale è sovente molto vago, non è facile
trovare il confine tra “abbastanza largo” e “relativamente stretto”.
Talvolta in letteratura, si dice che un sistema di IR recupera informazioni che
risolvono uno “stato anomalo di conoscenza” (Anomalous State of Knowledge,
ASK).
Una prima, banale soluzione a questo problema consisterebbe nell’associare ad
ogni documento dei metadati, quali ad esempio una serie di keyword che ne
identifichino il contenuto (qui si intendono metadati compilati a mano, non
generati automaticamente da un calcolatore), in tal modo le ricerche verrebbero
effettuate su questi metadati, anziché su tutto il contenuto dei documenti. Questa
soluzione si scontra però principalmente con la difficoltà di mantenere la coerenza
nella generazione degli indici, infatti l’estrazione dei concetti e delle keyword dai
documenti dipende dall’esperienza e dalle opinioni di chi costruisce l’indice
(alcuni esperimenti hanno dimostrato che mediamente c’è un 20% di differenza
tra i termini scelti da due esperti per caratterizzare un certo documento), un
concetto che per un utente è centrale in un determinato documento può risultare di
scarso interesse per un altro. Gli sforzi maggiori vengono quindi rivolti verso le
tecniche di full text retrieval.
Il secondo problema, che è poi il nocciolo dell’information retrieval, è legato al
reperimento delle informazioni, che da qui in avanti chiameremo anche
documenti, rilevanti per le esigenze dell’utente. Come già detto in precedenza è
impensabile che l’utente proceda con la lettura di tutti i documenti memorizzati
alla ricerca di quelli significativi per la propria richiesta (nel tal caso si avrebbe
ii

una situazione di perfect retrieval), bisogna quindi studiare come caratterizzare in
maniera automatica la collezione di documenti e cercare di duplicare via software
il processo umano di lettura. Più dettagliatamente si deve cercare di estrarre
informazioni di natura sintattica e semantica dal testo ed usarle per decidere se un
documento sia rilevante oppure no a fronte di una determinata richiesta. Come già
detto il concetto di rilevanza è centrale nell’information retrieval, lo scopo
fondamentale di una strategia automatica di retrieval è quello di restituire il più
alto numero di documenti rilevanti e, allo stesso tempo, il minor numero possibile
di documenti non rilevanti.
Apriamo una piccola parentesi: bisogna distinguere tra due diversi tipi di recupero
(o retrieval) dei dati, ossia il recupero deterministico e il recupero incerto. Nel
primo, la collezione oggetto della ricerca è costituita da dati strutturati ed è divisa
in due parti ben distinte: i dati che soddisfano la richiesta e quelli che non la
soddisfano; si è in questa situazione quando si ha a che fare, ad esempio, con le
basi di dati relazionali e con le interrogazioni espresse in linguaggio SQL.
Supponiamo ad esempio di avere una tabella contenente le informazioni sui testi
contenuti in una biblioteca:
LIBRI
Codice Titolo Autore Data_acquisizione
Se voglio sapere quali libri sono stati acquisiti dopo una certa data, è sufficiente
eseguire una query di interrogazione:
SELECT CODICE, TITOLO, AUTORE, DATA_ACQUISIZIONE
FROM LIBRI
WHERE DATA_ACQUISIZIONE > #01/01/2001#
In tal modo i dati contenuti nella tabella vengono inequivocabilmente suddivisi in
due gruppi: quelli che soddisfano la condizione impostata nella query (e che
pertanto vengono restituiti all’utente) e quelli che invece non soddisfano tale
condizione.
iii

Dall’altra abbiamo il recupero incerto, in cui i documenti vengono ordinati in base
ad una certa funzione che ne misura la rilevanza; è anche possibile che vengano
tralasciati quelli che stanno al di sotto di una certa soglia.
Supponiamo ad esempio di avere una collezione di documenti e di voler
sottoporre ad un ipotetico sistema la seguente richiesta (espressa per ora in
linguaggio naturale):
RESTITUISCI TUTTI I DOCUMENTI IN CUI SI PARLA DI TUMORI
Cosa si intende di preciso: i documenti che hanno come argomento i tumori o
quelli in cui se ne fa solo un accenno; inoltre, come faccio a sapere se un articolo
ha come argomento principale lo studio dei tumori o se questo costituisce solo una
parte minima ?
Queste sono le tipiche domande a cui cerca di dare risposta un sistema di
information retrieval.
iv

Indice
Introduzione............................................................................................................i
Capitolo 1 Concetti generali ................................................................................. 1
1.1 Schema di un information retrieval system................................................... 1
1.2 Effectiveness ed efficiency............................................................................ 2
Capitolo 2 Automatic text analysis ...................................................................... 6
Capitolo 3 Strategie di retrieval ......................................................................... 11
3.1 Boolean query.............................................................................................. 11
3.2 Extended (Weighted) boolean query........................................................... 13
3.3 Modelli booleani estesi – MMM=Mixed Min and Max.............................. 15
3.4 Inference network........................................................................................ 17
3.5 Vector space model ..................................................................................... 18
3.6 Probabilistic retrieval .................................................................................. 23
3.7 Genetic algorithm ........................................................................................ 29
Capitolo 4 Utility ................................................................................................. 33
4.1 Relevance feedback..................................................................................... 34
4.2 Parsing ......................................................................................................... 38
4.2.1 Stemming.............................................................................................. 39
4.3 Clustering – Classificazione dei documenti ................................................ 45
4.3.1 Single link............................................................................................. 48
4.3.2 Group average link ............................................................................... 51
4.3.3 Una visione alternativa del problema: SCATTER/GATHER.............. 56
4.4 Latent Semantic Indexing (LSI) .................................................................. 60
Capitolo 5 Implementazioni ............................................................................... 64
5.1 Inverted index.............................................................................................. 64
5.1.1 Procedura di ricerca.............................................................................. 68
5.1.2 Costruzione di un inverted index.......................................................... 71
v

Indice
5.1.3 Compressione di un inverted index ...................................................... 73
5.2 Signature file ............................................................................................... 75
5.2.1 Metodo WS (Word Signature) ............................................................. 77
5.2.2 Superimposed coding ........................................................................... 78
5.2.3 Metodi basati su compressione............................................................. 79
5.2.4 Bit-sliced signature file......................................................................... 81
5.2.5 Frame-sliced signature file ................................................................... 83
5.2.6 S-Tree ................................................................................................... 83
5.2.7 Organizzazioni “Key-based”................................................................ 84
Capitolo 6 Integrazione tra IR e database ........................................................ 86
6.1 Integrazione di sistemi esistenti................................................................... 95
6.2 Estensione di RDBMS con aggiunta di funzioni di IR ............................... 97
6.3 Implementazione di un IRS come applicazione di un RDBMS................ 103
Capitolo 7 Parallel information retrieval system ........................................... 109
Capitolo 8 Information retrieval e Web .......................................................... 116
8.1 Indexing..................................................................................................... 118
8.2 Crawler/robot............................................................................................. 119
8.3 Clustering .................................................................................................. 120
8.4 Metasearch navigator ................................................................................ 121
8.5 Ranking algorithm..................................................................................... 122
8.5.1 Algoritmo PageRank .......................................................................... 123
8.5.2 Algoritmo HITS ................................................................................. 124
8.6 Direzioni di ricerca future ......................................................................... 127
8.7 Architettura di un motore di ricerca .......................................................... 129
vi

Input
Capitolo 1
Concetti generali
1.1 Schema di un information retrieval system
Vediamo ora una rappresentazione schematica, per mezzo di black box, di quello
che dovrebbe essere un tipico information retrieval system.
Queries
Documents
Feedback
Processor
Figura 1 - Architettura di un IR system
Lo schema è costituito da tre parti principali: input, processor e output.
Partiamo dal lato input dello schema: come è già stato accennato in precedenza,
uno dei problemi principali consiste nell’avere una rappresentazione dei
documenti che sia utilizzabile dal calcolatore; è importante sottolineare che una
rappresentazione analoga dovrà essere utilizzata anche per rappresentare le
richieste che l’utente sottopone al sistema (e che da qui in avanti chiameremo
anche query). Tutto ciò implica che tanto i documenti, quanto le query dovranno
essere sottoposti ad una fase di pre-processing al fine di ottenere una loro
rappresentazione interna.
Il secondo blocco, indicato come processor, è quello in cui si realizza la fase vera
e propria di ricerca e di recupero all’interno dei documenti (parleremo di
1
Output

1 – Concetti generali
documenti per semplicità, anche se in realtà il sistema lavora sempre con le loro
rappresentazioni che si è costruito) in risposta alla richiesta sottoposta dall’utente,
quindi è il blocco in cui verranno implementate tutte le tecniche e le strategie che
vedremo più avanti.
Finalmente arriviamo alla parte dell’output, che usualmente consiste in una serie
di citazioni di documenti. Man mano che i risultati vengono proposti all’utente,
questi può ritenerli soddisfacenti oppure no, inoltre può trarre spunto da essi per
nuove direzioni di ricerca: può darsi quindi che l’utente soddisfi il proprio
information need in diverse passate, da qui il ramo di feedback presente nello
schema proposto.
Per concludere questa breve introduzione diciamo che sono tre i campi in cui è
possibile dividere la teoria dell’information retrieval:
• Content analysis: descrizione del contenuto di un documento in una
forma utilizzabile per essere elaborata da un calcolatore
• Information structures: studio delle informazioni sui documenti rese
disponibili per migliorare le strategie usate per recuperare le
informazioni
• Evaluation: misura della bontà dei risultati forniti dal sistema.
1.2 Effectiveness ed efficiency
La maggior parte delle ricerche nell’ambito dell’information retrieval sono rivolte
al miglioramento di due parametri che vengono solitamente indicati come
effectiveness ed efficiency.
Quando si parla di efficiency si fa riferimento al consumo di risorse da parte del
sistema: CPU time, memoria centrale e memoria di massa richieste, tempi di
risposta, tutte grandezze che sono legate alla particolare configurazione della
macchina utilizzata (questa parte viene lasciata abbastanza in disparte) e agli
algoritmi di ricerca che vengono implementati. Il concetto di effectiveness,
invece, è una misura della bontà del sistema, ovvero quanto il sistema è in grado
2

1 – Concetti generali
di soddisfare l’utente fornendogli le sole informazioni rilevanti e semplificandogli
così l’attività di ricerca.
I due parametri in base ai quali viene universalmente valutata l’effectiveness di un
sistema di information retrieval sono precision e recall, dove:
• precision = proporzione di documenti effettivamente rilevanti in
rapporto ai documenti restituiti dal sistema in risposta ad una
interrogazione dell’utente
• recall = proporzione dei documenti rilevanti restituiti dal sistema in
rapporto al totale dei documenti rilevanti (restituiti e non) presenti
nella collezione esaminata.
Supponiamo di poter definire, per ogni documento in una data collezione, se il
documento è rilevante o meno con riferimento ad una data richiesta; l’insieme dei
documenti si può quindi partizionare in quattro sottoinsiemi, dove la
classificazione di un documento considera se lo stesso è rilevante o meno e se è
stato reperito o meno dall’IRS.
Reperiti
Non reperiti
RET_NREL
RET_REL
NRET_NREL
Figura 2 - Suddivisione dei documenti per calcolare precision e recall
I documenti in RET_NREL costituiscono il “rumore”, che ogni IRS dovrebbe
cercare di ridurre al minimo; tali documenti vengono anche detti false drops, o
false hits. I documenti in NRET_REL, viceversa, sono quelli per cui il sistema è
“silenzioso”, per essi si usa anche il termine false dismissals; anche questi
dovrebbero essere ridotti al minimo. Un sistema di information retrieval ideale
dovrebbe avere zero false drops e zero false dismissals.
3
NRET_REL
Rilevanti
Non rilevanti

1 – Concetti generali
Tornando alle nostre misure di effectiveness, si avrà
• RECALL =
• PRECISION =
# RET _ REL
# REL
# RET _ REL
# RET
Talvolta in letteratura si incontra una terza misura:
• FALLOUT =
# RET _ NREL
# NREL
In genere, aumentando il valore di recall, la precision diminuisce e viceversa,
come indicato nel grafico seguente:
1
Precision
Query specifica
0 Recall 1
Figura 3 - Relazione tra precision e recall
Una query molto selettiva lascia passare soltanto pochi documenti, è assai
probabile che un’alta percentuale di questi sia costituita da informazioni rilevanti
(high precision), ma è altrettanto probabile che un buon numero di documenti
altrettanto rilevanti non siano stati recuperati (low recall); l’opposto accade nel
caso di una query poco selettiva, che restituisce un gran numero di documenti.
4
Query generica

1 – Concetti generali
Dalle formule presentate prima si nota che, mentre la precision è calcolabile a
partire dalla risposta del sistema (cioè riesco a quantificare sia il numero di
documenti restituiti, sia il numero di quelli ritenuti rilevanti), così non è per il
recall, che richiede di conoscere quanti sono i documenti rilevanti in tutta la
collezione (# RET). Per ovviare a questo problema esistono delle collezioni di
documenti con associate delle richieste per le quali sono disponibili le valutazioni
di rilevanza.
Esiste addirittura un progetto chiamato TREC (Text REtrieval Conference) che ha
lo scopo di valutare nuovi eventuali sistemi di information retrieval usando
opportuni benchmark; si usa una collezione di oltre un milione di documenti
(articoli del Wall Street Journal, Financial Times, Bollettini del Federal Register)
e 50 query, per le quali sono noti i giudizi di rilevanza.
5

Capitolo 2
Automatic text analysis
Per far sì che un sistema computerizzato di information retrieval possa operare per
il recupero delle informazioni desiderate da un testo non strutturato, tali
informazioni devono essere memorizzate all’interno del calcolatore. Abbiamo già
visto che, più dei documenti veri e propri, conviene utilizzare delle
rappresentazioni di questi ultimi in una forma che sia utilizzabile dal calcolatore e
che generalmente viene generata automaticamente: in parole povere, dobbiamo
costruire un modello.
Una delle assunzioni basilari su cui è fondata la teoria dell’information retrieval è
che la frequenza con cui un determinato termine compare in un testo fornisce una
misura di quanto quel termine sia significativo è per il documento in esame. Da
questo ne deriva che la frequenza può essere presa in considerazione per estrarre
parole e frasi da utilizzare per la rappresentazione di un documento.
Consideriamo a tal proposito il seguente grafico:
Figura 4 - Distribuzione di Zipf
6

2 – Automatic text analysis
Sull’asse verticale (indicato con f) è rappresentata la frequenza con cui le varie
parole compaiono in un testo, mentre sull’asse orizzontale (indicato con r) viene
riportato il loro rank, ossia la posizione che occupano in un’ideale scala delle
frequenze.
Tracciando un grafico di f in funzione di r si ottiene una iperbole, come
annunciato dalla legge di Zipf (da cui prende anche il nome la curva
rappresentata), secondo la quale il prodotto della frequenza d’uso delle varie
parole per la loro posizione nella scala delle frequenze è approssimativamente
costante.
In un insieme di dati (nel nostro caso le parole di un testo sufficientemente lungo)
caratterizzati da una distribuzione di Zipf ci saranno:
• Pochi elementi che compaiono molto frequentemente (rappresentati dal
ramo sinistro della curva). Nel caso di linguaggio parlato si tratta di
quelle parole (“the” ,”and” ecc. riportiamo parole della lingua inglese
poiché tutta la letteratura fa riferimento a questa), poche, che vengono
usate con estrema frequenza
• Un numero considerevole, anche se non elevatissimo, di elementi che
occupano posizioni intermedie sulla scala delle frequenze d’utilizzo
• Un altissimo numero di elementi con frequenze tendenti a zero (il ramo
destro della curva). Se ci riferiamo al linguaggio si tratta di tutte quelle
parole che non vengono quasi mai utilizzate.
Alcuni studiosi (in particolare H.P. Luhn ) hanno poi introdotto due valori di
soglia, uno superiore e uno inferiore. Le parole che stanno oltre il valore di soglia
superiore vengono considerate troppo comuni, mentre quelle al di sotto della
soglia inferiore vengono considerate troppo rare; in entrambi i casi questi termini
non danno un contributo significativo al contenuto del testo.
Si assume che il resolving power delle parole, ossia la loro abilità di discriminare
il contenuto dei documenti, raggiunga un picco in una posizione nel rank order
circa a metà tra i due valori di cut-off e tenda a zero all’incirca in corrispondenza
dei due sopraccitati valori di soglia.
7

2 – Automatic text analysis
Figura 5 - Curva di Zipf e resolving power delle parole
Ovviamente i valori di soglia non sono stabiliti univocamente, ma vengono fissati
di volta in volta in maniera arbitraria.
Torniamo ora ad occuparci di come modellare i documenti in modo che possano
essere analizzati in un sistema automatico di IR.
Potremmo pensare a tale modello come ad una lista di class names, dove ogni
class name rappresenta una classe di parole presenti nel testo esaminato (vedremo
più avanti in che modo) che fanno tutte riferimento ad un medesimo concetto; tali
class names diventeranno poi le parole significative che rappresentano il
contenuto del documento.
La costruzione di questo tipo di modello si articola in tre passaggi:
1. Rimozione delle parole che compaiono troppo frequentemente
2. Rimozione dei suffissi (suffix striping o stemming)
3. Individuazione delle radici (o stem) comuni a più parole (questa
operazione viene generalmente indicata come conflation).
8

2 – Automatic text analysis
La rimozione delle parole con un’alta frequenza di occorrenze (tali parole
vengono indicate in letteratura come stop words o, più raramente, come fluff
words) è un modo per implementare il cut-off di cui si è parlato con riferimento al
grafico di fig. 5; l’eliminazione delle stop words è considerato universalmente (o
quasi) come un passo necessario nell’implementazione di un sistema di
information retrieval. I vantaggi di questa operazione sono molteplici: innanzitutto
si rimuovono dei termini che non sono significativi per il contenuto del testo in
quanto compaiono virtualmente in tutti i documenti: tali termini non interferiranno
durante la fase di ricerca e recupero; in secondo luogo si diminuisce la dimensione
del documento, generalmente tra il 30% e il 50%, con evidenti vantaggi in termini
di occupazione di risorse e tempi di elaborazione.
Il secondo passo per la costruzione del modello consiste nella rimozione dei
suffissi dalle parole; tale operazione viene detta suffix striping oppure stemming;
l’approccio standard adottato negli algoritmi di suffix striping più utilizzati
consiste nell’avere una lista completa dei suffissi e nel rimuovere il più possibile
quelli più lunghi, es.
Purtroppo la rimozione “liberalizzata” dei suffissi può portare a commettere degli
errori grossolani:
CONFLICTUAL CONFLICT
EQUAL EQ ???
Per evitare errori di questo tipo è opportuno introdurre delle regole (di tipo quasi
grammaticale) un po’ più restrittive: il suffisso verrà rimosso soltanto se tali
regole saranno rispettate. Ad esempio:
• Lo stem che si ottiene dalla rimozione del suffisso non deve essere più
corto di un certo numero di caratteri
• Lo stem che si ottiene dopo aver rimosso il suffisso non deve terminare
con alcune determinate lettere o sequenze di lettere.
9

2 – Automatic text analysis
L’assunzione che sta alla base del terzo passo (conflation) è che, nel contesto
dell’IR, se due parole hanno la medesima radice o stem, allora si riferiscono al
medesimo concetto e possono essere indicizzate come un’unica entità. Questa
assunzione va bene nella maggioranza dei casi, ma anche qui può portare talvolta
ad errori marchiani in quanto parole molto simili possono avere significati
completamente diversi (es. NEUTRON e NEUTRALISE). Poiché non esiste un
metodo economico per effettuare una simile distinzione, si mette in conto che
permarrà una certa percentuale di errore e si assume che tale percentuale di errore
non degradi troppo l’effectiveness del sistema di IR. Si utilizzano quindi degli
algoritmi di conflation che generano un set di classi, una per ogni diverso stem
che è stato ottenuto.
Alla fine di tutto si ottiene un modello dei documenti costituito da una lista di
class name, che vengono solitamente chiamati index term o keyword.
Una serie di studiosi affermano però che tutti questi passaggi provocano una
riduzione dell’effectiveness del sistema; questi studiosi hanno dimostrato come
alcuni tipi di parole, che normalmente verrebbero eliminate dalle stoplist oppure
collassate in una classe più generale dagli algoritmi di stemming e di conflating,
giochino un ruolo molto importante in alcuni tipi di contesti per discriminare il
contenuto di un testo.
Abbiamo fatto un discorso molto generico riguardo alla costruzione di un modello
dei documenti, più avanti approfondiremo i vari concetti affrontati; è interessante
però notare come i concetti espressi in questa sezione stiano alla base di quasi tutti
gli algoritmi e le strategie utilizzate nei sistemi di information retrieval.
10

Capitolo 3
Strategie di retrieval
Abbiamo visto in precedenza che un sistema di IR ha in ingresso una richiesta o
query da parte dell’utente e genera una risposta costituita da un insieme di
documenti; in questo capitolo ci soffermeremo su alcune possibili organizzazioni
logiche di un sistema di IR (in altre parole: come modellare la collezione dei
documenti esaminati) e vedremo come, in base a queste, differiscano tra di loro il
modo di formulare le richieste al sistema ed il tipo di risposte che questo fornisce
in uscita.
Le retrieval strategy rispondono alla domanda su quale sia il metodo migliore per
modellare ed ordinare i documenti, una volta noti i termini comuni ai documenti
stessi ed alla query.
3.1 Boolean query
Tradizionalmente il progetto logico e l’implementazione dei sistemi di
information retrieval sono stati influenzati dalla tecnologia dei database: il
problema del recupero dei documenti è stato visto di conseguenza come una
variante del recupero dei dati all’interno di una base dati. Un gran numero di
sistemi di information retrieval, quindi, è basato sulla logica booleana e sulla
ricerca di tipo exact matching. In un simile ambiente i documenti sono
rappresentati mediante una lista di termini significativi (ottenuti più o meno nel
modo visto al paragrafo precedente) che non tiene in nessun conto il contributo
apportato da ogni singolo termine alla caratterizzazione del testo: una qualsiasi
parola o appartiene, oppure non appartiene ad un documento; questa è l’unica
informazione presa in considerazione. Lo stesso discorso vale per le query, che
vengono viste come dei semplici elenchi di termini collegati tra di loro medianti
11

operatori booleani. In risposta vengono restituiti quei documenti che contengono i
termini presenti nella query in base alle condizioni specificate da quest’ultima; in
questo modo la collezione viene partizionata esattamente in due set: i documenti
che soddisfano la query e quelli che non la soddisfano.
Per esempio, partendo dalla query:
Q=( K1 AND K2 ) OR ( K3 AND ( NOT K4 ))
la ricerca booleana restituirà tutti i documenti che hanno come index term K1 e
K2, assieme a quelli contenenti K3 ma non K4.
Questo tipo di organizzazione ha il vantaggio di essere relativamente facile da
implementare (infatti è stata la prima adottata in IR), però ha anche una lunga
serie di punti a sfavore; il primo e fondamentale consiste nella mancanza di un
qualsiasi ordinamento sui documenti: tutti i documenti restituiti a fronte di una
richiesta vengono considerati come se avessereo la stessa rilevanza per l’utente,
una condizione, questa, decisamente poco realistica. Nel caso di grandi collezioni
di documenti l’utente rischia di trovarsi nella condizione di passare da query con
condizioni troppo lasche, che restituiscono un numero molto alto di documenti in
maniera “piatta”, senza alcuna informazione su quali siano quelli più interessanti
(bassa precision), a query con condizioni eccessivamente selettive, che
restituiscono un numero esiguo di documenti (basso recall), lasciandone fuori
alcuni potenzialmente rispondenti alle richieste dell’utente.
A monte di questo sta anche il fatto che per utenti inesperti (quali sono nella
stragrande maggioranza dei casi) risulta spesso difficile mettere le proprie
esigenze in forma di query booleana, assai lontana da quello che è il linguaggio
naturale. Inoltre anche un utente più esperto rischia, se non ha già una buona
conoscenza del contenuto dei documenti, di costruire query non efficaci usando
termini troppo generali, quindi con bassa capacità di filtrare i documenti, oppure
troppo specifici, che portano ad avere un numero esiguo di documenti come
risposta.
12

3 – Strategie di retrieval
3.2 Extended (Weighted) boolean query
In base alle considerazioni fatte fino ad ora risulta che in un sistema di IR è
importante avere un qualche ordinamento o ranking sul set di documenti che
viene prodotto in uscita.
La prima soluzione a questo problema è dato dai modelli booleani estesi in cui i
concetti fondamentali sono gli stessi del modello booleano visto prima (quindi i
documenti sono ancora rappresentati mediante liste di termini legati da operatori
booleani).
Questi tipi di modelli si caratterizzano per la presenza di pesi (weight) associati ai
vari termini del testo che ne riflettono in qualche modo l’importanza relativa
all’interno del documento; tali pesi permettono inoltre di adottare dei criteri di
ordinamento dei documenti reperiti, infatti in fase di ricerca non si procede più
soltanto ad un exact match tra i termini presenti nella richiesta e quelli del
documento, ma si lavora sui pesi degli index term mentre gli operatori booleani
presenti nella query vengono associati ad operatori matematici da applicare ai
pesi.
Ad esempio, se indichiamo con WX e WY i pesi associati a due termini X e Y si
ha:
BOOLEAN QUERY EXTENDED BOOLEAN QUERY
X AND Y WX * WY
X OR Y WX + WY
NOT Y 0 SE WY>0 ; 1 se WY=0
Così facendo ad ogni documento non sarà più asseganto un valore booleano, true
o false, a seconda che i suoi index terms soddisfino o no la condizione spressa
dalla query, bensì un valore numerico variabile all’interno di un range predefinito
che permetterà di costruire una classifica dei documenti rilevanti.
13

3 – Strategie di retrieval
Uno dei problemi più importanti è come assegnare i pesi ai vari termini del testo:
una prima semplice soluzione consiste nell’assegnare come peso la frequenza con
cui ogni termine compare all’interno dei vari documenti; in letteratura viene
identificata con tfij ossia term frequency, frequenza con cui il termine i-esimo
della collezione degli index terms compare nel documento j-esimo. La misura
appena introdotta presenta però una serie di inconvenienti: innanzitutto questo
modo di procedere si basa sull’assunzione che un termine sia tanto più importante
in un documento quanto più è frequente al suo interno (se si escludono,
ovviamente, le stop words), un’affermazione, questa, non sempre vera; inoltre
sarebbe più utile una misura che tenesse anche conto della frequenza interdocumenti
anzichè soltanto di quella intra-documenti, in quanto la prima ci può
dire meglio quanto un certo termine sia caratterizzante per un particolare
documento (più avanti vedremo alcuni tipi di misura che utilizzano la frequenza
inter-documenti). Un terzo punto a sfavore è costituito dal fatto che una simile
misura tende a favorire i documenti più lunghi, in cui un certo termine occorre un
numero mediamente più alto di volte: per far fronte a questo problema si procede
sovente ad una normalizzazione dei pesi, cioè si ha
dove
w = K
ij
14
tf ij ∗
• tfij = term frequency di i all’interno del documento j
• j = lunghezza del documento j (numero di index term contenuti nel
documento)
• K = costante arbitraria
Un modello leggermente più complesso è il cosiddetto Euclidean Weighted
Boolean Model, in cui le formule per calcolare il peso dei vari documenti sono
date da:
j

3 – Strategie di retrieval
BOOLEAN QUERY EUCLIDEAN WEIGHTED
X OR Y ( ) p
p p
15
w
x
+ w
p ⎛ p
p p
( 1 w ) ( ) X AND Y x 1 w ⎞
y
1
⎜ − + −
−
⎟
⎜ 2 ⎟
⎝
⎠
(p=1: simple weighting; p=2: Euclidean distance weighting)
Questo modello permette anche ai documenti che non soddisfano la condizione
booleana espressa dalla query di avere comunque un punteggio, allorchè molto
basso.
3.3 Modelli booleani estesi – MMM=Mixed Min and
Max
Questo modello è basato sulla teoria dei Fuzzy Set; senza addentrarci troppo nella
loro trattazione, un fuzzy set è un insieme per cui la funzione di apparteneza non è
booleana, come si può forse capire meglio dalla figura che segue:
Figura 6 - Il concetto di fuzzy set
y
1
1

3 – Strategie di retrieval
Nel caso del modello in esame ad ogni index term ti è assegnato un set (fuzzy) di
documenti ed i pesi Wij [ 0,
1]
∈ rappresentano il grado di appartenenza del
documento docj al set di ti. Per calcolare il grado di appartenenza di un documento
docj all’insieme unione o intersezione dei due fuzzy set dei termini ti e tk bisogna
calcolare rispettivamente
Wi∪k,j = max(Wij , Wkj)
Wi∩k,j = min(Wij , Wkj)
Secondo la teoria dei fuzzy set, i documenti da reperire per la query “ti OR tk”
sarebbero quelli del fuzzy set associato all’unione dei set dei due termini, mentre
quelli per la query “ti AND tk” sarebbero quelli del fuzzy set che si ricava
dall’intersezione dei due set.
Il modello MMM considera pertanto max( Wij , Wkj ) come misura di similarità
tra la query “ti OR tk” ed il documento docj; analogamente min( Wij, Wkj ) risulta
essere la misura di similarità tra la query “ti AND tk” ed il solito documento docj.
Generalizzando, siano dati un documento docj, con pesi W1j, W2j, ..., Wnj e le
query
QOR = ( t1 OR t2 OR ... OR tn)
QAND = (t1 AND t2 AND ... AND tn)
Nel modello MMM si definisce la similarità fra le query ed il documento docj
come
S(QOR , docj) = COR1 * max(W1j, ... , Wnj) + COR2 * min(W1J, ... Wnj)
S(QAND , docj) = CAND1 * min(W1j, ... , Wnj) + CAND2 * max(W1J, ... Wnj)
dove COR1 > COR2 e CAND1 > CAND2 sono dei coefficienti che danno
rispettivamente maggior importanza al termine con il massimo ed il minimo peso.
16

3.4 Inference network
3 – Strategie di retrieval
Questo modello si basa su valutazioni di “presunta rilevanza” dei documenti a
fronte di combinazioni arbitrarie dei termini richiesti nella query sottoposta al
sistema, valutazioni che vengono assegnate dall’utente stesso.
Supponiamo ad esempio di avere:
COMBINAZIONE DI TERMINI PROB. CHE SIA RILEVANTE
NOT COST AND NOT PAPER 0.1
COST AND NOT PAPER 0.4
NOT COST AND PAPER 0.5
COST AND PAPER 0.9
L’utente quindi assegna una probabilità che un documento qualsiasi sia rilevante a
fronte delle varie combinazioni di index term; tali valori vengono poi utilizzati
assieme alla probabilità che tali combinazioni si presentino effettivamente,
assegnata dal sistema in base ai valori di tf. Quindi non è più necessario
mantenere una lista degli index term presenti in ogni documento, con un evidente
risparmio di risorse. Il punteggio assegnato ad ogni documento è la probabilità
totale che tale documento sia rilevante; sempre riferendosi al caso visto prima,
supponiamo di avere un documento doc1 per cui le probabilità che i due termini
siano presenti valgano rispettivamente:
COST = 0.2
PAPER = 0.3
il punteggio assegnato a tale documento sarà quindi:
(0.1)*(0.8)*(0.7) + (0.4)*(0.2)*(0.7) + (0.5)*(0.8)*(0.3) + (0.9)*(0.2)*(0.3)
ottenuto da
• 0.1 = probabilità che doc1 sia rilevante se “cost” e “paper” sono entrambi
presenti AND
• 0.8 = probabilità che “cost” sia presente AND
17

3 – Strategie di retrieval
• 0.7 = probabilità che “paper” sia presente
per il primo monomio,
• 0.4 =probabilità che doc1 sia rilevante se “cost” è presente e “paper” è
assente AND
• 0.2 = probabilità che “cost” sia presente AND
• 0.7 = probabilità che “paper” sia assente
e così via.
3.5 Vector space model
Il più importante tra i modelli usati per costruire un sistema di retrieval che
permetta un ordinamento sul set di documenti prodotto in uscita è sicuramente
quello che viene indicato come vector space model. In questo modello una
collezione di documenti viene rappresentata come uno spazio n-dimensionale,
dove ogni dimensione è associata ad un diverso index term presente nella
collezione stessa.
Figura 7 - Rappresentazione dei documenti nel vector space model
Ogni documento viene quindi rappresentato mediante un vettore (t1, t2, ..., tn)
dove, nel caso più semplice, ti vale 1 se il documento contiene il termine i-esimo e
18

3 – Strategie di retrieval
0 in caso contrario; la stessa rappresentazione verrà adottata per le query
sottoposte al sistema.
Supponiamo ad esempio di avere una collezione di documenti caratterizzata da 7
index term: improvement, information, linguistic, overhead, retrieval, storage,
systems; se avessimo la query “linguistic for information storage and retrieval
systems”, questa verrebbe rappresentata mediante il vettore
q = ( 0 , 1 , 1 , 0 , 1 , 1 , 1 )
dove un componente vale 1 se il corrispondente termine è presente nella query e 0
se non è presente. I documenti che compongono la collezione possono essere
rappresentati nello stesso modo, supponiamo di avere
d
1 = ( 1 , 1 , 0 , 1 , 0 , 1 , 0 )
d
2 = ( 0 , 1 , 1 , 1 , 0 , 0 , 1 )
d
3 = ( 0 , 0 , 1 , 0 , 1 , 1 , 1 )
Per determinare quale documento sia più simile alla query si può calcolare
l’angolo tra il vettore che rappresenta quest’ultima ed i vettori che rappresentano i
vari documenti: quanto più è piccolo l’angolo tra due vettori, tanto più i due
vettori (nel nostro caso la query ed un documento) sono considerati simili.
Uno dei modi per ottenere la misura precedente consiste nel calcolare il prodotto
scalare tra i vettori; nel caso preso in esame si avrebbe quindi
q* d
1 = ( 0 , 1 , 1 , 0 , 1 , 1 , 1 ) * ( 1 , 1 , 0 , 1 , 0 , 1 , 0 ) = 2
q* d
2 = ( 0 , 1 , 1 , 0 , 1 , 1 , 1 ) * ( 0 , 1 , 1 , 1 , 0 , 0 , 1 ) = 3
q* d
3 = ( 0 , 1 , 1 , 0 , 1 , 1 , 1 ) * ( 0 , 0 , 1 , 0 , 1 , 1 , 1 ) = 4
da cui risulta che il documento d3 è quello più similare alla query.
Per migliorare la qualità di questo modello si utilizzano dei vettori pesati
(weighted vectors) in cui i vari elementi non sono più soltanto 0 e 1, ma dei
numeri indicanti l’importanza di quel particolare termine per il documento
corrente. Abbiamo già visto in precedenza che si potrebbe utilizzare come peso il
numero di occorrenze di ogni termine all’interno dei documenti, ma abbiamo già
anche notato come questa misura non sia ottimale in quanto tiene conto soltanto
19

3 – Strategie di retrieval
della frequenza intra-documenti e non di quella inter-documenti. Per gli scopi
dell’information retrieval un index term risulta utile se esplica due funzioni:
1. è rilevante rispetto al contenuto del documento, quindi aiuta a recuperare il
documento in fase di ricerca (recall function, intra-document)
2. permette di distinguere un documento, o un gruppo di essi, dal resto della
collezione in modo da non restituirne un numero troppo elevato,
comprendente sia testi rilevanti, sia non rilevanti (precision function, interdocument)
Queste osservazioni suggeriscono di usare delle misure di frequenza relative per
privilegiare i termini che hanno un alto numero di occorrenze in alcuni documenti
della collezione, ma che risultano essere poco frequenti nel complesso di tutti i
documenti. Il più noto schema di pesatura dei termini che tiene conto di questi
fattori è quello indicato con
tf * idf
ovvero term frequency and inverse document frequency, ottenuto definendo
• term frequency tfij = frequenza del termine i-esimo (ti) nel documento j-
esimo (dj)
• inverse document frequency idfi = log2
normalizzata
idfi = log2
⎛ ⎞
⎜
max_ n
⎟ +1 dove
⎜ ⎟
⎝ ni ⎠
N = numero di documenti nella collezione
ni = numero di documenti contenenti l’index term ti
max_n = max { ni }
e il peso di ti in docj è dato da
Wij = tfij * idfi
20
N + 1 oppure, in forma
ni

3 – Strategie di retrieval
L’uso di tfij permette di discriminare tra termini di uno stesso documento, mentre
l’uso di idfi ne considera l’importanza nel contesto della collezione nel suo
complesso.
Abbiamo visto prima che per confrontare due vettori dobbiamo considerare
l’angolo tra di essi, per fare questo possiamo calcolare il coseno di tale angolo con
la seguente formula:
cos
( q,
d )
=
n
2
∑qi* ∑
21
n
∑
i = 1
q * w
n
i=
1 i=
1
dove n è il numero di componenti dei vettori nello spazio multidimensionale
considerato, qi e wi sono i componenti di q e d ; quanto più è grande il valore del
coseno, tanto più i due vettori sono simili e tanto più alto è il rank del documento.
S q,
d che prendono il
In letteratura vengono presentate altre misure di similarità ( )
nome dagli studiosi che le hanno proposte ed usate:
Dice: S ( q , d )
Jaccard: S(
q,
d )
= n
= 2 * n
n
i
n
i
∑
i = 1
w
2
i
q
2
∑ q * ∑
i
i = 1 i = 1
n
∑q
i=
1
i
*
n
w
i
w
2
2
2
∑q+ ∑w−∑q* ∑w
i
i
i=
1 i=
1 i=
1 i=
1
Una volta calcolato il valore del coseno (o di un’altra misura di similarità) per tutti
i documenti, questi possono essere ordinati in base a tale valore e presentati
all’utente finale; vedremo più avanti come questo modello venga implementato
nella pratica.
Un’altra rappresentazione usata spesso per rappresentare il vector model in
letteratura è quella matriciale; un database contenente in totale d documenti
i
*
wi
n
i
n
i
2
i
2

3 – Strategie di retrieval
rappresentati da t index term viene rappresentato con una term-by-document
matrix di dimensioni t x d, in cui l’elemento aij è il peso associato al termine i-
esimo del documento j-esimo. Le colonne di tale matrice rappresentano i vari
documenti e quindi vengono chiamate document vectors, mentre le righe indicano
i pesi di ogni index term nei documenti e sono chiamate term vectors.
Vediamo un esempio: siano dati t=6 index terms
T1 = bak(e,ing)
T2 = recipes
T3 = bread
T4 = cake
T5 = pastr(y,ies)
T6 = pie
e n=5 documenti
D1: How to bake bread without recipes
D2: The classic art of viennese pastry
D3: Numerical recipes: the art of scientific computing
D4: Bread, pastries, pies and cakes: quantity baking recipes
D5: Pastry: a book of best french recipes
Da cui si ottiene la seguente matrice term-by-document 6 x 5, dove il termine aij è
il numero di volte che il termine i compare nel documento j:
⎛1
⎜
⎜1
⎜1
A
= ⎜
⎜0
⎜
⎜
0
⎜
⎝0
0
0
0
0
1
0
22
0
1
0
0
0
0
1
1
1
1
1
1
0⎞
⎟
1⎟
0⎟
⎟
0⎟
1
⎟
⎟
0
⎟
⎠

3 – Strategie di retrieval
Questo tipo di rappresentazione viene usata perchè con lacune operazioni
particolari sulle matrici è possibile ricavare le relazioni geometriche esistenti tra i
document vector e con esse modellare le similitudini e le differenze di contenuto
dei documenti.
Questo tipo di modello presenta una grossa difficoltà: l’occupazione di risorse
richiesta; supponendo di avere una collezione di 10000 documenti, un vocabolario
di 100000 index terms e di riservare un byte per ogni entry nella matrice ci
vorrebbe 1GB di memoria per contenere quest’ultima. Il problema è
effettivamente importante, però ci sono due punti a favore: il primo è che un gran
numero di entry nella matrice saranno a 0, per cui si può pensare di rappresentarla
come una matrice sparsa con un conseguente risparmio di risorse; inoltre si
possono utilizzare opportune tecniche di compressione che permettono di ridurre
ulteriormente lo spazio occupato.
Un’ultima considerazione: nel modello basato sullo spazio dei vettori la query
sottoposta al sistema viene rappresentata internamente mediante un vettore, quindi
non è più necessario l’uso di operatori booleani; l’utente può sottoporre le
richieste usando il linguaggio normale oppure con un semplice elenco di parole
anzichè con formule ed operatori per lui innaturali.
3.6 Probabilistic retrieval
I modelli probabilistici sono caratterizzati dall’applicazione formale della teoria
delle probabilità alla logica dell’information retrieval; i documenti della
collezione in esame vengono ordinati in base alla probabilità che essi soddisfino le
richieste dell’utente.
Alcuni studiosi (Cooper - Maron) hanno formulato negli anni ’60 il cosiddetto
probability ranking principle: tale enunciato afferma che se un sistema di IR
restituisce i documenti esaminati in ordine decrescente della loro probabilità di
essere rilevanti e se tale probabilità è calcolata il più accuratamente possibile,
23

3 – Strategie di retrieval
allora l’effectiveness ottenibile con tale sistema è la migliore ottenibile sulla base
dei dati a disposizione.
Vedremo che tutta la teoria del probabilistic retrieval si basa sul teorema di
Bayes o teorema della probabilità delle cause, di cui diamo ora una brevissima
trattazione.
Teorema di Bayes
A volte non tutti i possibili eventi sono direttamente osservabili: in tal caso
la probabilità marginale P(A) è indicata come probabilità a priori.
Qualora l’evento A sia in qualche modo legato ad un secondo evento B,
che invece possiamo osservare, la probabilità condizionata P(A|B) prende
il nome di probabilità a posteriori perchè, a differenza di quella a priori,
rappresenta un valore di probabilità valutata dopo la conoscenza di B.
Figura 8 - Insieme degli eventi per la teoria di Bayes
In generale, però, si conosce solamente P(A) e P(B|A) (queste ultime sono
dette probabilità condizionate in avanti), e per calcolare P(A|B) occorre
conoscere anche P(B). Quest’ultima quantità si determina saturando la
probabilità congiunta P(A|B) rispetto a tutti gli eventi marginali Ai
possibili:
∑P( B,
Ai
) = ∑
P ( B)
P(
B | A ) * P(
A )
= i i
24
i
a patto che i vari Ai siano mutuamente esclusivi ed esaustivi dello spazio
degli eventi.
L’ultima relazione ci permette di enunciare il teorema preannunciato, che
mostra come ottenere le probabilità a posteriori a partire da quelle a priori
e da quelle condizionate in avanti:
P(
A | B)
=
i
P(
B | Ai
) * P(
Ai
)
P(
B | A ) * P(
A )
∑
k
k
k
i

3 – Strategie di retrieval
Il modello probabilistico è simile al vector space model in quanto i documenti e le
query vengono rappresentati mediante vettori; la differenza sta nel fatto che,
anzichè recuperare i documenti basandosi sulla loro similarità con la query, il
modello probabilistico ordina i documenti in base alla probabilità che essi siano
rilevanti per la query. Questa probabilità viene calcolata utilizzando un set di
documenti per i quali è noto a priori se siano rilevanti oppure no.
In pratica i pesi associati agli index term che costituiscono la collezione vengono
calcolati basandosi sulla loro distribuzione nei documenti che vengono osservati
come campione. Se assumiamo che le distribuzioni dei vari termini siano tra di
loro indipendenti, il che non è in realtà del tutto vero , la probabilità che un
documento sia rilevante rispetto ad una query può essere calcolata sommando i
pesi associati ai termini comuni tra tale documento e la query; tali pesi indicano
infatti la probabilità che i termini della query compaiano in un documento
rilevante, ma non in uno non rilevante.
Il problema che ci troviamo a dover affrontare può quindi essere espresso nei
seguenti termini: supponiamo di avere un documento descritto dalla
presenza/assenza degli index term ricavati dalla collezione in esame; possiamo
rappresentarlo mediante un vettore binario
D = X , X ,..., X )
( 1 2 n
dove Xi = 0 o 1 indica rispettivamente l’assenza o la presenza del termine i-esimo.
La seconda assunzione che si fa è che ci siano due eventi tra di loro mutuamente
esclusivi, ossia
E1 = il documento esaminato è rilevante
E2 = il documento esaminato NON è rilevante
In base alle convenzioni qui presentate, possiamo dire che per ogni documento D
a noi interessa calcolare P(E1|D) oppure, analogamente P(E2|D).
Abbiamo già detto che in nostro aiuto viene il teorema di Bayes, il quale ci dice
che per distribuzioni discrete si ha:
25

P(
E
3 – Strategie di retrieval
| D)
P(
D | E ) * P(
E )
i
i
i = i=1,2
P(
D)
Da questa formula deriva la regola di decisione di Bayes, che si può così
sintetizzare:
[ P E | D)
P(
E | D)
→ D rilevante,
D non rilevante]
( 1
2
> (1)
Vediamo ora un esempio di una strategia basata sul teorema prima enunciato e
sulle relazioni che da esso ne conseguono. Supponiamo di avere la seguente
collezione di testi: per i primi tre conosciamo a priori se siano rilevanti oppure no,
mentre per il quarto vogliamo determinarlo in qualche maniera.
D1: “cost of paper is up” → rilevante
D2: “cost of jellybeans is up” → non rilevante
D3: “salaries of CEO’s are up” → non rilevante
D4: “paper: CEO’s labor cost up” → ???
Dalla collezione è possibile ricavare la seguente tabella:
TERMINE RILEVANTI NON RILEVANTI SIGNIFICATIVITA’
paper 1 0 FORTE
CEO 0 ½ CONTRARIA
labor 0 0 NON RILEVABILE
cost 1 ½ DEBOLE
up 1 1 NON RILEVABILE
Ad ogni termine si assegnano dei cosiddetti “odds of relevance”, letteralmente
delle “ipotesi di rilevanza” in base alle loro frequenze nel set di documenti
conosciuti preso come campione. Nel nostro caso si ha:
• paper: compare in tutti i documenti rilevanti ed in nessuno di quelli non
rilevanti; ne deriva che la sua presenza in un documento indica un’alta
probabilità che tale documento sia rilevante
26

3 – Strategie di retrieval
• CEO: compare più frequentemente nei documenti non rilevanti che in
quelli rilevanti, quindi la sua presenza suggerisce che un testo non sia
rilevante
• cost: compare in un’alta percentuale di documenti rilevanti ed in una
percentuale più bassa tra quelli non rilevanti; indica rilevanza, ma in
misura minore rispetto al termine “paper”
• labor, up: il primo non compare nè nei documenti rilevanti, nè in quelli
non rilevanti; il secondo compare con egual frequenza in entrambi gli
insiemi. Entrambi non portano nessuna informazione utile.
Una volta calcolati gli odds of relevance associati ai vari index term bisogna
utilizzarli per calcolare la probabilità che un certo documento sia rilevante; a tale
scopo si utilizzano le seguenti equazioni:
odds
odds
doc
term
∏
= term
27
( odds )
odds
=
odds
rel
term
non rel
r + 0.
5
oddsrel =
nei documenti rilevanti
n − r + 0.
5
odds rel
r + 0.
5
=
n − r + 0.
5
non nei documenti non rilevanti
r = numero di documenti contenenti il termine in esame
n = numero di documenti rilevanti o non rilevanti nella collezione
Prima abbiamo visto che l’index term “cost” compare in 1 su 1 dei documenti
rilevanti, da cui si ha:
odds
rel
1+
0.
5
= = 3
1−1
+ 0.
5

3 – Strategie di retrieval
odds non rel
1+
0.
5
= = 1
2 −1+
0.
5
Quindi, se il termine “cost” compare in un documento D, si ha un indice di
rilevanza 3 associato a tale documento. Proviamo ora ad effettuare il calcolo
completo per tutti i termini della collezione:
TERMINE RILEVANTI NON RILEVANTI
ODDS OF
RELEVANCE
paper 1 : 1 0 : 2
1.
5 2.
5
* = 15
0.
5 0.
5
CEO 0 : 1 1 : 2
0.
5 1.
5 1
* =
1.
5 1.
5 3
labor 0 : 1 0 : 2
0.
5 2.
5 5
* =
1.
5 0.
5 3
cost 1 : 1 1: 2
1.
5 1.
5
* = 3
0.
5 1.
5
up 1 : 1 2 : 2
1.
5 0.
5 3
* =
0.
5 2.
5 5
Total
odds
∏
= odds = 15
D 4 term
Tutte le relazioni prese in esame sono state ricavate applicando una serie di
trasformazioni alla relazione (1); da questa Robertson e Sparck Jones hanno
derivato la formula per calcolare il peso degli index term che porta il loro nome e
che ricorre frequentemente in letteratura
W i
⎛ r + 0.
5 ⎞
⎜ ⎟
⎝ R − r + 0.
5
= log
⎠
⎛ n − r + 0.
5 ⎞
⎜
⎟
⎝ N − n − R + r + 0.
5 ⎠
Il significato dei vari simboli è indicato nella tabella seguente, che viene indicata
come contingency table relativa al generico termine Xi nel campione di
documenti di riferimento (dove Xi=1 o 0 indica come al solito la presenza o
l’assenza del termine):
28

n° documenti con
Xi=1
n° documenti con
Xi=0
3 – Strategie di retrieval
n° documenti
rilevanti
29
n° documenti non
rilevanti
r n-r n
R-r N-n-R+r N-n
R N-R N
ci si rende conto che i pesi assegnati da Sparck Jones equivalgono aggli oddsterm
che abbiamo calcolato in precedenza.
Dalle elaborazioni matematiche di cui si è parlato prima si ricava anche che
odds
( A | B)
( A | B)
P
=
1−
P(
A | B)
Quindi, tornando al nostro caso, abbiamo che il documento in esame ha una
probabilità di essere rilevante pari a
15 15
=
1+
15 16
Per la trattazione precedente si è fatta l’assunzione che gli index term fossero
stocasticamente indipendenti; nella realtà non è così, per cui tutte le equazioni
viste non sarebbero più valide: si assume però l’indipendenza perchè altrimenti si
andrebbe incontro ad una trattazione matematica troppo complessa.
3.7 Genetic algorithm
Negli ultimi anni si è cercato in una vasta serie di campi di passare dai
performance system, cioè sistemi che si limitavano ad eseguire le operazioni per
le quali erano stati programmati (quindi senza alcuna capacità di autoapprendimento),
ai machine learning system, cioè a sistemi in grado di acquisire
informazioni direttamente dagli esempi che venivano loro trasmessi. Uno dei
paradigmi seguiti è quello degli algoritmi genetici, basati cioè su processi
naturali, in cui sopravvivono gli elementi che meglio si adattano alle condizioni
imposte.

3 – Strategie di retrieval
In letteratura si possono trovare numerosi esempi di algoritmi genetici utilizzati in
information retrieval per risolvere svariati problemi.
Un algoritmo genetico si può riassumere in una serie abbastanza standard di passi:
1. Si inizia con una collezione più o meno casuale di organismi
2. Si eliminano gli elementi poco “adatti”, nel nostro caso quelli che
risulterebbero in un basso valore di precision/recall
3. Si hanno degli accoppiamenti tra i vari individui (nel caso in cui gli
individui siano dei vettori ciò consiste nell’effettuare degli swap tra i loro
elementi) e si sostituisce una generazione con quella dei suoi discendenti
(crossover)
4. Si hanno delle mutazioni casuali su alcuni organismi (sempre nel caso di
vettori ciò equivale ad avere un peso che cambia in maniera random)
5. Si ripete il processo dal punto 2 fino a che la popolazione non raggiunge il
livello di qualità desiderato
Un algoritmo genetico mantiene ad ogni iterazione t una popolazione P(t)={X1 ,
X2 , ... , Xn} dove ogni individuo rappresenta una potenziale soluzione del
problema ed è implementato mediante una struttura dati S più o meno complessa.
Ogni possibile soluzione Xi viene valutata in modo da determinare una misura di
fitness che indica quanto sia vicina alla soluzione del problema. Abbiamo già
visto che alcuni membri della popolazione subiscono delle trasformazioni in modo
da generare nuove soluzioni: ci sono trasformazioni unarie Mi (mutazioni) che
generano nuovi individui mediante un piccolo cambiamento in un singolo
individuo, e trasformazioni di ordine più alto Ci (crossover) che originano nuovi
individui combinando tra di loro parti provenienti da due o più elementi. Per
esempio, se i genitori sono rappresentati da vettori a cinque dimensioni (a1 , a2 , a3
, a4 , a5) e (b1 , b2 , b3 , b4 , b5), allora un crossover darà origine ad un nuovo
individuo costituito da (a1 , a2 , b3 , b4 , b5) e (b1 , b2 , a3 , a4 , a5); l’operazione
eseguita durante il crossover il crossover è lo scambio di informazioni tra due o
più potenziali soluzioni. Dopo un certo numero di iterazioni il programma
30

3 – Strategie di retrieval
converge verso la soluzione finale e questa dovrebbe rappresentare la soluzione
ottima al problema.
Gli algoritmi genetici utilizzano un vocabolario che deriva da quello della
genetica naturale, quindi si parla di geni (o bit), cromosomi o individui (o stringhe
di bit).
L’algorimo che analizziamo è costituito dai seguenti passi:
1. Inizializzazione della popolazione e valutazione del fitness
In pratica consiste nel decidere il numero di geni per ogni individuo ed il
numero totale di cromosomi (popsize) della popolazione iniziale. La
popolazione iniziale contiene un set di documenti considerati rilevanti da parte
di un utente (ad esempio selezionati tra quelli restituiti da una precedente
query); lo scopo dell’algoritmo è quello di trovare il set ottimo di documenti
che rispondono alle richieste dell’utente. La funzione utilizzata per calcolare il
fitness dei vari individui si basa sul coefficiente di Jaccard: questo indica il
grado di similarità tra due set di dati (nel caso di applicazioni di information
retrieval generalmente si tratta di index term) e vale:
X ∩ Y
dove | S | indica la cardinalità di un determinato set S.
X ∪Y
2. Riproduzione (selezione)
La riproduzione è la selezione di una nuova popolazione in base al valore di
fitness dei vari individui. Allo scopo si definisce una funzione che in maniera
assolutamente casuale sorteggi i vari cromosomi (generalmente in numero
eguale alla cardinalità attuale della popolazione) che debbono dare vita alla
nuova generazione (ovviamente bisogna costruire tale funzione in modo che la
probabilità di un cromosoma di venire sorteggiato sia direttamente
proporzionale al proprio valore di fitness); uno stesso cromosoma può venire
sorteggiato più di una volta. Questo modo di procedere segue la logica
dell’ereditarità del mondo naturale: i cromosomi migliori danno origine a più
31

3 – Strategie di retrieval
copie, quelli di livello medio rimangono in numero all’incirca costante mentre
quelli peggiori muoiono.
3. Ricombinazione (crossover e mutazioni)
A questo punto si procede ad applicare gli operatori di ricombinazione: per il
crossover viene generato per ogni cromosoma un numero random r compreso
tra 0 ed 1, se r < pc (dove pc è la probabilità di crossover ed è un parametro
determinato a priori) allora il cromosoma viene selezionato per il crossover. Si
procede quindi ad unire tra di loro coppie casuali di cromosomi; per ciascuna
coppia si genera un numero random pos nel range (1 , ... , m - 1) dove m è il
numero totale di geni dei cromosomi. Ogni coppia di cromosomi si scambia
quindi i geni a partire dal crossing point nel modo visto in precedenza.
Il secondo operatore di ricombinazione, ossia la mutazione, opera invece su
una base costituita da un singolo bit; anche qui si determina a priori una
probabilità di mutazione pm che è uguale per tutti i bit in tutti i cromosomi
della popolazione. Per ogni bit si genera un numero random r variabile tra 0 ed
1: se r < pm allora il bit muta, ossia passa da 0 ad 1 o viceversa.
Valori tipici per pc sono tra 0.7 e 0.9 mentre per pm si va da 0.01 a 0.03.
4. Convergenza
Dopo tutte le operazioni viste finora si ha una nuova generazione della
popolazione; l’evoluzione procede attraverso ripetizioni cicliche dei passi
precedenti finchè non si è generato un certo numero di nuove generazioni
oppure converge verso una situazione stabile.
Per una presentazione pratica di questo algoritmo si rimanda al paragrafo 4.1.
32

Capitolo 4
Utility
Lo scopo dei sistemi di information (text) retrieval è di associare le query degli
utenti con i documenti che “contengono gli stessi concetti”.
Le strategie viste finora cercano di svolgere questo compito confrontando i
termini presenti nelle query con quelli che si trovano nei documenti; abbiamo
visto che le strategie più usate sono quelle che ordinano i documenti in base ai
risultati di questi confronti. In questo capitolo vengono presentate quelle che in
letteratura sono generalmente indicate come utility; le utility sono tecniche che
permettono di migliorare l’accuratezza del retrieval e possono essere usate in
cooperazione con le strategie viste in precedenza. Fondamentalmente queste
tecniche hanno lo scopo di determinare se una parola può essere un termine
rappresentativo di un documento o no. Finora abbiamo assunto che gli index term
fossero delle singole parole, o parti di esse; in realtà un index term andrebbe visto
più correttamente come un’unità di informazione, quindi potrebbe trattarsi anche
di una coppia di parole, di una frase, o anche di una collezione di termini i cui
significati sono in relazione l’uno con l’altro.
Le utility più frequentemente usate sono:
• Relevance feedback: dopo aver valutato il risultato di una ricerca, la
query viene ridefinita aggiungendo o sottraendo termini, oppure
modificando i pesi assegnati ai vari termini sulla base dei documenti che
sono giudicati rilevanti; si procede quindi ad un nuovo retrieval
• Clustering: i documenti vengono organizzati in gruppi sulla base del loro
contenuto
• Passage based retrieval: i documenti vengono suddivisi in unità più
piccole che vengono poi ordinate e presentate all’utente
• N-grams: si usano delle stringhe di lunghezza N come termini in modo da
fornire una tolleranza agli errori e facilitare le ricerche con i caratteri jolly
33

4 - Utility
• Thesauri: le query vengono automaticamente espanse utilizzando dei
sinonimi dei termini presenti in esse
• Parsing: permette di identificare delle frasi, gruppi di parole o parti di esse
come termini significativi
• Regression analysis: permette di correggere i parametri del sistema in
modo da migliorare le performance, il tutto a partire da un set di
documenti che sono considerati rilevanti.
4.1 Relevance feedback
Abbiamo visto in precedenza che per molti utenti risulta difficoltoso esprimere le
proprie esigenze informative mediante una query da sottoporre ad un sistema di
IR; questo suggerisce che la prima operazione dovrebbe essere considerata
soltanto un tentativo, in modo da ottenere un primo insieme di documenti da
valutare. Partendo dal contenuto di tali documenti si potrebbe modificare la query
di partenza, ad esempio aggiungendo nuovi termini suggeriti dal primo set di
documenti, in modo da migliorare la ricerca nella collezione; l’ideale sarebbe che
questa operazione venisse eseguita in automatico dal sistema, senza caricare
l’utente di ulteriore lavoro.
Su questo concetto si basa la tecnica di relevance feedback: l’idea principale
consiste nello scegliere i termini o le espressioni importanti dei documenti che un
utente ha identificato come rilevanti e nel mettere in risalto tali termini in una
successiva formulazione della query di ricerca; analogamente i termini che sono
presenti nei documenti giudicati non rilevanti vengono eliminati (o perlomeno
posti in secondo piano) quando la query viene riformulata. Il risultato di questo
processo è di “muovere” la query, nel caso di una nuova ricerca, in direzione dei
documenti rilevanti e di allontanarla da quelli che risultano poco interessanti.
Il tutto porta i seguenti vantaggi:
• l’utente non è obbligato a conoscere nel dettaglio i documenti per costruire
delle query efficaci
34

4 - Utility
• si spezza il processo di ricerca in tanti piccoli passi, in modo da arrivare al
risultato desiderato in maniera graduale.
Il primo modello per cui è stato proposto il processo di relevance feedback è il
vector space model, in cui una query può essere espressa mediante un vettore
Q =
(
q
1
,
q
35
2
,...,
dove qi rappresenta il peso assegnato al termine i-esimo nella query; tali pesi
generalmente variano tra 0 e 1. Data la query precedente il processo di relevance
feedback genera un nuovo vettore
q
t
)
, ,..., ) q q q Q ′ ′ ′ = ′
( 1 2 t
dove q′ i rappresenta il peso alterato assegnato al termine i-esimo. Vengono
introdotti nuovi termini assegnando un peso positivo dove prima era 0 ed
eventualmente eliminati alcuni di quelli presenti riportando a 0 i pesi inizialmente
non nulli. Il processo di feedback può essere rappresentato graficamente come uno
spostamento del vettore della queryda un’area ad un’altra nello spazio t-
dimensionale definito dai t termini che costituiscono il vocabolario. Vediamo ora i
vari passi di un processo di relevance feedback: abbiamo visto che possiamo
rappresentare sia i documenti D, sia le richieste di informazione Q mediante dei
vettori t-dimensionali della forma
( 1, 2,...,
t ) w w w D =
, ,..., ) q q q Q =
( 1 2 t
dove wi e qi rappresentano il peso assegnato al termine i-esimo nel documento e
nella query rispettivamente.
Una volta ordinati i documenti in base alla query e dopo che l’utente ha
selezionato n1 documenti rilevanti (supponiamo che n2 indichi invece il numero di
documenti non rilevanti) si può procedere a riformulare la query
1
Q′
= Q+
n
Di
1
∑ −
D n
1 doc. i
rilevanti
∑
Di
D
2 doc. NON i
rilevanti

4 - Utility
Una formula simile alla precedente che si incontra spesso in letteratura è la
formula di Rocchio
dove , γ ∈ [ 0,
1]
β e β + γ = 1.
Di
Q′
= Q + β ∑ −γ
n
doc.
1
rilevanti
36
∑
D
n
doc.
NON 2
rilevanti
I valori dei due parametri vengono scelti in base a quanto si vuole che incidano in
fase di feedback i documenti rilevanti (per inserire nuovi termini nella query),
piuttosto che quelli non rilevanti (per eliminare i termini che non sono
significativi per la ricerca).
Vediamo brevemente un’applicazione che esegue una sorta di relevance feedback
associato all’algoritmo genetico introdotto al paragrafo 3.7. Si è visto che con le
tecniche di relevance feedback l’utente sottopone una query al sistema e questo
risponde proponendo una serie di documenti in risposta; il sistema può però anche
procedere ad una analisi dei documenti che l’utente considera rilevanti in modo da
estrarre quelli che sono i concetti presenti in tali documenti e proporre all’utente
stesso una nuova query di ricerca (o addirittura modificare automaticamente
quella originaria) che dovrebbe, teoricamente, eseguire una ricerca più mirata su
tutta la collezione.
Supponiamo che, un utente abbia selezionato da un elenco i cinque documenti
rappresentati dalle seguenti liste di index term:
• DOC0: DATA RETRIEVAL, DATABASE, COMPUTER NETWORKS,
IMPROVEMENTS, INFORMATION RETRIEVAL, METHOD,
NETWORK, MULTIPLE, QUERY, RELATION, RELATIONAL,
RETRIEVAL, QUERIES, RELATIONAL DATABASES,
RELATIONAL DATABASE, US, CARAT.DAT, GQP.DAT,
ORUS.DAT, QUERY.OPT
• DOC1: INFORMATION, INFORMATIONAL RETRIEVAL,
INFORMATION STORAGE, INDEXING, RETRIEVAL, STORAGE,
US, KEVIN.HOT
• DOC2: ARTIFICIAL INTELLIGENCE, INFORMATION RETRIEVAL
SYSTEMS, INFORMATION RETRIEVAL, INDEXING, NATURAL
LANGUAGE PROCESSING, US, DBMS.AI, GQP.DAT
i

4 - Utility
• DOC3: FUZZY SET THEORY, INFORMATION RETRIEVAL
SYSTEMS, INDEXING, PERFORMANCE, RETRIEVAL SYSTEMS,
RETRIEVAL, QUERIES, US, KEVIN.HOT
• DOC4: INFORMATION RETRIEVAL SYSTEMS, INDEXING,
RETRIEVAL, STAIRS, US, KEVIN.HOT
L’elenco totale di concetti, o index term, è il seguente:
DATA RETRIEVAL, DATABASE, COMPUTER NETWORKS,
IMPROVEMENTS, INFORMATION RETRIEVAL, METHOD, NETWORK,
MULTIPLE, QUERY, RELATION, RELATIONAL, RETRIEVAL, QUERIES,
RELATIONAL DATABSES, RELATIONAL DATABSE, US, CARAT.DAT,
GQP.DAT, ORUS.DAT, QUERY.OPT, INFORMATION, INFORMATION
STORAGE, INDEXING, STORAGE, KEVIN.HOT, ARTIFICIAL
INTELLIGENCE, INFORMATION RETRIEVAL SYSTEMS, NATURAL
LANGUAGE PROCESSING, DBMS.AI, FUZZY SET THEORY,
PERFORMANCE, RETRIEVAL SYSTEMS, STAIRS.
Se rappresentiamo ogni documento mediante una stringa in cui i vari bit a 0 o 1
indicano l’assenza o la presenza di un determinato concetto, otteniamo:
• DOC0 : 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0
• DOC1 : 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0
• DOC2 : 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1 0 0 1 1 1 1 0 0 0 0
• DOC3 : 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 0 1 0 1 0 1 0 0 1 1 1 0
• DOC4 : 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 0 1
Andiamo ora a calcolare il valore di fitness per i vari documenti: allo scopo si
calcola quanto ogni documento sia similare agli altri nel set utilizzando il
coefficiente di Jaccard e facendo poi la media dei valori trovati su tutto il set. Se
ragioniamo su una coppia di documenti, un valore alto di tale coefficiente indica
che i due documenti risultano essere strettamente correlati per quel che riguarda i
concetti espressi; se invece ci riferiamo a tutto il set, un valore alto del
coefficiente medio indica che tutti i documenti condividono parecchi concetti.
Nel caso in esame si ha:
• coefficiente di Jaccard tra DOC0 e DOC0 = 1.000000
• coefficiente di Jaccard tra DOC0 e DOC1 = 0.120000
• coefficiente di Jaccard tra DOC0 e DOC2 = 0.120000
• coefficiente di Jaccard tra DOC0 e DOC3 = 0.115384
• coefficiente di Jaccard tra DOC0 e DOC4 = 0.083333
37

4 - Utility
Facendo la media dei valori calcolati si ottiene il valore della misura di fitness per
DOC0 che vale 0.287744; procedendo in maniera analoga per tutti cinque i
documenti si ha:
• fitness per DOC0 = 0.287744
• fitness per DOC1 = 0.411692
• fitness per DOC2 = 0.367556
• fitness per DOC3 = 0.427473
• fitness per DOC4 = 0.451212
Partendo da questa situazione, attraverso le successive generazioni il sistema
evolve verso la seguente soluzione: 000000000001000100000010101000001; in
essa sono presenti sei keywords: RETRIEVAL, US, INDEXING, KEVIN.HOT,
INFORMATION RETRIEVAL SYSTEMS, STAIRS; sono quelle che meglio
rappresentano il set iniziale di documenti. Utilizzando queste keywords
“ottimizzate” per la ricerca, il sistema di information retrieval dovrebbe restituire
un set di documenti ottimizzato rispetto a quelle che sono le esigenze dell’utente.
4.2 Parsing
Le tecniche di parsing vengono utilizzate in fase di preprocessing, quando si
analizza il testo piatto e si cerca di strutturarlo in maniera che il sistema di IR
possa effettuare in modo conveniente le ricerche. In particolare si procede ad
estrarre i token, o unità di informazione, che verranno poi organizzati in
opportune strutture, come si vedrà più avanti.
Esistono numerose tecniche di parsing, alcune di esse sono convenienti e vengono
largamente utilizzate, altre invece sono difficili da implementare,
computazionalmente espensive e non apportano grossi vantaggi, per cui sono
raramente usate nei sistemi di IR.
Le tecniche di parsing che possiamo incontrare nei sistemi di IR sono:
• Stemming: consiste nel rimuovere i prefissi ed i suffissi comuni a più
parole (ad esempio –s, -ed, -ing, ecc. nel caso della lingua inglese) in
38

4 - Utility
modo da poter raggruppare le parole che hanno la stessa radice. Le regole
adottate variano a seconda del linguaggio in esame e trovano largo
impiego
• Phrasing: molto semplicemente si tratta ogni coppia di parole consecutive
come un singolo termine; alla fine si considerano solo le coppie che si
presentano oltre un determinato numero di volte, tutte le restanti
combinazioni invece possono presumibilmente venire mappate con dei
termini singoli. Questa tecnica viene utilizzata qualche volta, seppure non
molto sovente
• Part-of-speech taggers: questi sistemi sono in grado di identificare nomi,
verbi ed aggettivi, e di metterli in relazione se hanno il medesimo
significato. Si tratta di sistemi pesanti da implementare e per questo sono
usati molto di rado
• Syntactic parsing: permette di identificare alcune strutture nel testo che
hanno il medesimo significato, ma sono espresse in maniera differente.
Esempio: “President of America”=”American president”. Si tratta di
sistemi estremamente complessi, allo stato attuale solo in fase di studio
4.2.1 Stemming
Vediamo ora più in particolare la più usata tra le tecniche a cui si è accennato,
ossia lo stemming. L’assunzione che sta alla base dello stemming è che termini
con una radice (stem) comune solitamente hanno un significato simile, ad esempio
CONNECT
CONNECTED
CONNECTING
CONNECTION
CONNECTIONS.
Molto spesso le performance di un sistema di IR possono essere migliorate se
gruppi di termini come quelli appena visti vengono collassati in un singolo
39

4 - Utility
termine (le tecniche di stemming vengono sempre associate con quelle di
conflation). Questo può essere fatto rimuovendo i vari suffissi –ed, -ing, -ion, -
ions e lasciando soltanto il termine “connect”. Così facendo si riduce il numero
totale di termini che il sistema di IR deve gestire, con conseguente diminuzione
della quantità e della complessità dei dati nel sistema.
Vi sono quattro tipologie di algoritmi di stemming:
• Affix removal algorithms: rimuovono prefissi e/o suffissi dei termini in
base a regole predeterminate e mappate nell’algoritmo; questi metodi
sovente modificano anche lo stem ottenuto
• Successor variety stemmers: utilizzano come base per lo stemming la
frequenza con cui compaiono determinate sequenze di lettere nel testo
• N-grams methods: raggruppano i termini in base al numero di n-gram (=
gruppi di lettere) che condividono. In realtà non è correttissimo definirli
algoritmi di stemming perchè sono più che altro dei metodi di conflation
• Lookup table: i vari termini ed i corrispondenti stem vengono
memorizzati in una tabella ad-hoc
Vediamo ora più in particolare le varie tipologie.
LOOKUP TABLES (Bentley, 1982)
Il primo metodo che può venire in mente è quello di mantenere una tabella con
tutti gli index term ed i corrispondenti stem.
TERMINE STEM
engineering engineer
engineered engineer
engineer engineer
.... ....
I termini presenti nelle query e nel testo vengono troncati utilizzando una tabella
simile come base; la tabella potrebbe essere mantenuta utilizzando un B-tree o una
40

4 - Utility
hash table, il che garantirebbe tempi di accesso ridotti. Gli svantaggi di una simile
implementazione risultano evidenti: innanzitutto è necessario un overhead
notevole per mantenere la struttura dati; inoltre la tabella andrebbe compilata a
priori, se non proprio a mano, quasi.
SUCCESSOR VARIETY STEMMER (Hafer – Weiss, 1974)
Questo algoritmo si basa esclusivamente sulla distribuzione delle lettere
dell’alfabeto nel testo: non necessita di alcuna precompilazione umana. In parole
povere la “varietà di successori di una stringa” (successor variety of a string, da
qui in avanti lo indicheremo con SV) è il numero di differenti caratteri che
seguono una determinata stringa nelle parole del testo in esame. Ad esempio
supponiamo di voler determinare i valori di SV per la parola “apple” e di avere
come campione un testo composto da: “able”,“axle”,“accident”,“ape”,“about”. La
prima lettera che compone la nostra parola, ossia la ‘a’, nel testo è seguita da ‘b’,
‘x’, ‘c’ e ‘p’, per cui il suo valore di SV è 4. Se andiamo avanti troviamo che il
valore di SV per la sottostringa “ap” vale 1 perchè nel testo campione la
sottostringa “ap” è presente una sola volta e seguita dal carattere ‘e’, e così via.
Se consideriamo un testo campione sufficientemente lungo, generalmente i valori
di SV hanno un andamento abbastanza caratteristico: SV diminuisce man mano
che la sottostringa aumenta di lunghezza finchè si raggiunge un valore limite; da
qui in avanti SV torna a salire rapidamente. Questa informazione (ossia il punto in
cui si raggiunge il minimo) viene utilizzato per segmentare la parola in due
sottostringhe; per fare questo si può usare uno di tre metodi seguenti:
a) Cutoff method: si fissa a priori un valore limite (cutoff) per SV e si
divide la parola in corrispondenza del punto in cui si raggiunge tale
limite. C’è il problema tipico di tutti questi tipi di sistemi, vale a dire
trovare una quantità adatta per il valore di soglia.
b) Peak and plateau method: si divide il termine quando si incontra un
carattere per cui il valore di SV eccede sia quello del carattere
immediatamente precedente, sia quello del carattere immediatamente
successivo
41

4 - Utility
c) Complete word method: si fissa un break quando si incontra una
stringa che è anche una parola completa nel testo campione
Es.
Problema: determinare lo stem della parola READABLE
Testo campione: ABLE, APE, BEATABLE, FIXABLE, READ, READABLE,
READING, READS, RED, ROPE, RIPE.
PREFISSO SUCCESSOR VARIETY LETTERE
R 3 E, I, O
RE 2 A, D
REA 1 D
READ 3 A, I, S
READA 1 B
READAB 1 L
READABL 1 E
READABLE 1 blank
Utilizzando il complete word segmentation method la parola viene suddivisa in
READ e ABLE, poichè READ appare come una parola nel testo campione; lo
stesso risultato si ottiene con il metodo peak and plateau.
Dopo che una parola è stata segmentata bisogna selezionare il segmento da usare
come stem: Hafer e Weiss proposero il seguente metodo empirico
if first segment occurs in n

4 - Utility
a) Determinare i valori di SV per una parola
b) Utilizzare le informazionio al punto (a) per dividere la parola in due
segmenti
c) Selezionare uno dei due segmenti come stem
SHARED DIGRAMS METHOD (Adamson - Boreham)
Un digramma è una coppia di lettere consecutive tra quelle che formano una
parola; questi metodi calcolano opportune misure di associazione tra le varie
coppie di termini basate sul numero di digrammi che queste hanno in comune.
Es.
Statistics st ta at ti is st ti ic cs Digrammi unici : at cs ic is st ta ti
Statistical st ta at ti is st ti ic ca al Digrammi unici : al at ca ic
is st ta ti
Una volta identificati i digrammi unici per i due termini si calcola la loro
similarità sulla base del coefficiente di Dice
S ( x,
y)
= 2
x ∩ y
x + y
dove x = insieme dei digrammi unici del primo termine
y = insieme dei digrammi unici del secondo termine
Una misura di similarità come questa viene calcolata per ogni coppia di termini da
analizzare e si ottiene così una matrice triangolare di similarità; una volta riempita
la matrice si raggruppano i termini che hanno un valore di similarità maggiore o
uguale di un determinato valore di soglia e si collocano nella medesima classe.
Quello appena visto non è quindi propriamente un algoritmo di stemming (non
calcola infatti la radice per i termini che si analizzano) bensì un algoritmo di
conflation.
AFFIX REMOVAL STEMMERS
questa tipologia di algoritmi opera rimuovendo i suffissi e/o i prefissi dai termini
analizzati lasciando uno stem; alcuni di essi inoltre modificano anche gli stem
43

4 - Utility
risultanti dall’elaborazione. Un algoritmo di questo tipo assai banale è quello che
rimuove i plurali dei termini; le regole che costituiscono tale algoritmo (sempre
riferendosi alla lingua inglese) sono le seguenti:
• se una parola termina in -ies ma non in -eies o -aies: sostituire –ies con –y
• se una parola termina con –es ma non con –aes, -ees, -oes: sostituire –es
con –e
• se una parola termina con –s ma non con –us o –ss: sostituire –s con
NULL
La maggior parte degli stemmers appartenenti a questa tipologia sono degli
iterative longest match stemmers: essi rimuovono dai termini la più lunga stringa
di caratteri possibile in base ad un certo set di regole; questo processo viene
ripetuto fino a che non può più essere eliminato alcun carattere. Esempi di
algoritmi molto utilizzati sono quelli proposti da Lovins (1968), Salton (1968),
Dalton (1974), Porter (1980) e Paice (1990).
Algoritmo di Porter
Più che di un algoritmo si tratta di una serie di regole (una sessantina circa); ogni
regola rappresente una possibile struttura che può avere un determinato termine, e
per ognuna di queste regole è indicata una trasformazione che da eseguire sulla
parola in esame; ogni regola quindi è costituita da una tripla del genere:
Condizione Vecchio suffisso Nuovo suffisso (può
anche essere blank, il
che significa che il
suffisso va eliminato)
Dove la condizione viene espressa con una particolare notazione formale.
Le regole sono divise in una serie di step; le regole in ogni step vengono valutate
in sequenza e sono strutturate in modo che una sola di essa possa eventualmente
trovare applicazione; le regole sono ordinate in modo tale che ad ogni step venga
rimosso il più lungo suffisso possibile.
44

4 - Utility
4.3 Clustering – Classificazione dei documenti
Nell’ambito dell’information retrieval si definisce cluster un gruppo omogeneo di
documenti che sono tra loro più fortemente associati di quanto lo siano con
documenti in altri gruppi; quindi, a grandi linee, un processo di clustering si può
vedere come l’organizzazione degli oggetti in gruppi i cui membri sono similari in
qualche modo.
Prima di descrivere i vari metodi di classificazione che vengono adottati mi
sembra opportuno citare l’enunciato che sta alla base del loro utilizzo e che in
letteratura viene indicato come Cluster Hypothesis: i documenti che sono simili
l’uno con l’altro tendono ad essere rilevanti per le medesime query.
Per la ricerca risulta conveniente assegnare ad ogni cluster un elemento
rappresentativo, generalmente chiamato centroide, che rappresenta in qualche
modo la media dei documenti appartenenti a quel determinato cluster; anzichè
confrontare la query dell’utente con tutti i documenti della collezione la si
confronta con i vari centroidi e come risultato si restituisce il cluster, o i cluster,
che risulta essere più rispondente alla query. A questo punto si può eventualmente
procedere ad una ricerca ulteriore tra i documenti appartenenti al cluster
selezionato.
Per organizzare i documenti in cluster bisogna innanzitutto definire una qualche
misura di similarità tra i documenti e in secondo luogo definire i metodi per
suddividere in classi questi ultimi. Nell’ipotesi di rappresentare i documenti
mediante vettori, una misura di similarità potrebbe essere il coseno dell’angolo
che intercorre tra le varie coppie di vettori, oppure si possono adottare i
coefficienti di Dice o di Jaccard già visti in precedenza. Alcuni studi hanno
dimostrato che la scelta della misura di similarità ha un impatto qualitativo
trascurabile rispetto a quello legato alla scelta dell’algoritmo di clustering vero e
proprio.
Una volta scelta la misura di similarità da adottare e compilata la matrice delle
similarità tra i documenti, si può procedere alla loro suddivisione. Ci sono due tipi
45

4 - Utility
principali di classificazioni che possono essere adottate: la prima è una
suddivisione piatta in gruppi mutuamente esclusivi, la seconda è una
classificazione gerarchica su più livelli; in questo caso ogni documento fa parte di
un gruppo che a sua volta appartiene ad un gruppo più generale, e così via. A loro
volta gli algoritmi di clustering gerarchico si dividono in due grandi categorie: gli
algoritmi divisivi e quelli agglomerativi. Gli algoritmi divisivi iniziano
considerando l’intera collezione come un unico gruppo, il quale viene suddiviso in
sottogruppi; ciascuno di questi sottogruppi viene a sua volta diviso in gruppi più
piccoli e così via fino a che ogni oggetto costituisce un gruppo a sè. Viceversa gli
algoritmi agglomerativi iniziano dalla situazione in cui ogni oggetto costituisce un
gruppo e i vari gruppi vengono via via combinati fino a che non ne rimane uno
unico. Si avranno quindi dei cluster piccoli ad un estremo della gerarchia
contenenti documenti molto simili tra di loro e cluster via via più grandi man
mano che ci si sposta verso l’estremo opposto, contenenti documenti sempre più
distanti l’uno dallaltro.
Documento 1
Documento 9
Documento 5
Documento 3
Documento 8
Documento 2
Documento 6
Documento 10
Documento 4
Documento 7
Figura 9 - Esempio di dendogramma
46

4 - Utility
Il risultato dell’applicazione di questi algoritmi viene solitamente descritto
mediante un particolare albero binario detto dendogramma: i documenti vengono
rappresentati come nodi mentre i vari archi indicano come gli algoritmi di
clustering costruiscono i gruppi contenenti i vari oggetti.
Nel caso di una suddivisione in partizioni si confronta la query con i vari centroidi
e viene restituito come risultato il cluster, o i cluster, il cui centroide si avvicina di
più alla query (anche qui spesso si realizza un ordinamento dei cluster in base alla
loro vicinanza alla query); nel caso di una suddivisione gerarchica, invece, si
inizia ad analizzare la gerarchia a partire da un estremo e si procede ad analizzare
il dendogramma finchè non si raggiunge una certa stop condition o stopping rule ;
il subtree che si apre a partire dal punto di stop viene restituito come risultato.
Generalmente la ricerca parte dal nodo radice e si procede valutando una
matching function tra la query ed i nodi immediatamente discendenti (ogni nodo
corrisponde al centroide del cluster associato al sottoalbero che parte da tale
nodo). Se ad un determinato livello ho più di un nodo (= più cluster) si procederà
ovviamente ad espandere quello per cui si ha la matching function più alta; si ha
la stop condition che interrompe la navigazione quando, ad un determinato livello,
tutte le matching function risultano inferiori a quella del livello padre.
Passiamo ora ad analizzare gli algoritmi che realizzano una classificazione
gerarchica di una collezione di documenti, ed in particolare tre di questi:
• single link clustering
• complete link clustering
• group average link clustering
La differenza tra i tre metodi sta fondamentalmente nel modo in cui viene valutata
la distanza tra le varie coppie di cluster composti: nell’algoritmo single link si
prende come distanza la minima tra quelle esistenti tra le varie coppie di oggetti
appartenenti a gruppi diversi. Nell’algoritmo complete link, viceversa, la distanza
tra due cluster risulta essere la massima distanza tra due oggetti appartenenti uno
al primo cluster e l’altro al secondo; infine nell’algoritmo group average link si
47

4 - Utility
considera come distanza tra due gruppi la media delle distanze tra le varie coppie
di oggetti appartenenti agli opposti cluster.
Vedremo che, quando si parla di clustering, ci si riferisce indifferentemente sia
alla similarità, sia alla distanza tra i documenti; ovviamente alla massima distanza
corrisponde la minima similarità e viceversa.
Vediamo ora una breve classificazione dei clustering method.
4.3.1 Single link
Un documento qualsiasi viene inserito nella gerarchia, quindi si inizializza un
vettore con i valori di similarità tra il documento selezionato ed i rimanenti N-1
della collezione (tali valori vengono presi dalla matrice di similarità). Se il
documento i-esimo non è ancora stato inserito nella gerarchia la i-esima entry nel
vettore conterrà la maggiore delle similarità, o equivalentemente la minore
distanza, tra il documento i ed ogni altro documento nella gerarchia, oltre al
numero di documento della gerarchia con la massima similarità. Il documento
associato con la entry più alta nel vettore viene quindi inserito nella gerarchia ed
ogni entry j del vettore viene ricalcolata considerando la più alta tra sim(j,d)
(sempre prese dalla matrice di similarità) ed il valore corrente della entry. Il
processo viene ripetuto finchè tutti i documenti non sono nella gerarchia.
Supponiamo ad esempio di partire dalla seguente matrice di similarità:
A B C D E
B 0.3
C 0.5 0.4
D 0.6 0.5 0.3
E 0.8 0.7 0.5 0.4
F 0.9 0.8 0.2 0.1 0.3
48

4 - Utility
Se si inizia inserendo il documento A nella gerarchia, lo stato iniziale del sistema
è rappresentato dalla figura 10.a; la massima similarità tra un documento nella
gerarchia ed uno non ancora nella gerarchia è tra la coppia A e F, quindi il
documento F viene inserito nella gerarchia e il vettore delle similarità viene
ricalcolato in base ai valori contenuti nella matrice di similarità (10.b). Poichè il
documento B ha una similarità più alta con F piuttosto che con A, la entry
corrispondente viene modificata. A questo punto la più alta similarità si ha per le
coppie A,E e B,F e vale 0.8: si decide arbitrariamente di inserire il documento B
nella gerarchia (10.c).
Figura 10 - Costruzione di una single link hierarchy
49

4 - Utility
Nei passi successivi il documento più simile con uno di quelli appartenenti alla
gerarchia viene aggiunto a quest’ultima, fino a che non è stato inserito l’ultimo
documento della collezione(10.f)
Vediamo ora una pseudocodifica dell’algoritmo. Vengono utilizzate due
procedure: ComputeSim(did) e InsertHierarchy(did1,did2,sim); la prima calcola la
similarità tra il documento did e tutti gli altri documenti nella collezione ed
inserisce la similarità tra il documento did ed il documento j nel j-esimo elemento
dell’array sim; la InsertHierarchy invece inserisce did1 nella gerarchia.
for(i:=2 to CollectionSize)
{
info[i].sim:=0;
info[i].InHierarchy:=FALSE;
info[i].nn:=UNDEF;
}
/* Inizializza la gerarchia inserendo il documento 1 */
CurrentDid:=1;
/* Ad ogni passo inserisco nella gerarchia il documento
con la massima similarità con un documento già presente
in essa fino a che tutti i documenti non sono stati
inseriti */
while (CurrentDid!=UNDEF)
{
info[CurrentDid].InHierarchy=TRUE;
ComputeSims(CurrentDid);
MaxSim=0;
NextDid=UNDEF;
/* Aggiorno i valori di similarità per tutti i
documenti non ancora inseriti nella gerarchia */
for(i=1 to CollectionSize)
{
if(not info[i].InHierarchy)
{
if(sims[i]>info[i].sim)
{
info[i].sim:=sims[i];
info[i].nn:=CurrentDid;
}
if(info[i].sim>MaxSim)
50

}
4 - Utility
{
MaxSim:=info[i].sim;
NextDid:=i;
}
}
}
if(NextDid!=UNDEF)
{
InsertHierarchy(NextDid,info[NextDid],MaxSim);
}
CurrentDid:=NextDid;
4.3.2 Group average link
L’algoritmo mantiene una lista dei cluster attivi: un cluster è attivo se non è
ancora stato unito con un altro; ad esempio se
r=merge(p,q)
allora p e q sono dei cluster attivi prima del merge (e r non esiste); dopo il merge
invece p e q non sono più attivi mentre r sì. Le informazioni sui cluster attivi
includono la rappresentazione del centroide del cluster, il cluster attivo a cui
quello corrente è più simile ed il valore della similarità.
All’inizio ogni documento è anche il centroide del cluster di cui è anche l’unico
componente e tutti i cluster risultano attivi; i cluster con la più alta similarità
vengono uniti, viene calcolato un nuovo centroide ed il cluster viene inserito nella
gerarchia. Infine viene ricalcolato il vettore delle similarità ed aggiornato con il
nuovo insieme di cluster attivi; il processo viene reiterato fino a che non rimane
un solo cluster attivo.
51

4 - Utility
Figura 11 - Costruzione di una group average link hierarchy (I parte)
52

4 - Utility
Figura 12 - Costruzione di una group average link hierarchy (II parte)
Vediamo ora la pseudocodifica per l’algoritmo:
/* Inizializzazione */
MaxSim:=0;
for(i=1 to CollectionSize)
{
/* Creo un cluster per ogni documento */
info[i].centroid:=documento i;
ComputeSim(i,nn,sim);
info[i].nn:=nn;
info[i].sim:=sim;
info[i].size:=1
53

4 - Utility
if(sim>MaxSim)
{
id1:=i;
id2:=nn;
MaxSim:=sim;
}
}
NumActive:=CollectionSize;
for(i=1 to NumActive)
{
active[i]:=i;
}
/* Eseguo il merge dei cluster finchè non rimane un
solo cluster oppure tutte le similarità sono pari a 0
*/
while(MaxSim>0 and NumActive>1)
{
smaller:=MIN(id1,id2);
larger:=MAX(id1,id2);
}
info[smaller].centroid:=MergeCentroids
(smaller,larger);
info[smaller].size:=info[smaller].size+
info[smaller].size;
a:=index of larger in active;
active[a]:=active[NumActive];
NumActive:=NumActive-1;
MergeClusters(smaller,larger,MaxSim);
MaxSim:=0;
for(each cluster a in active)
{
if(info[a].nn=larger or info[a].nn=smaller)
{
FindMaxSim(a,nn,sim);
info[a].nn:=nn;
info[a].sim:=sim;
}
if(info[a].sim>MaxSim)
{
id1:=a;
id2:=info[a].nn;
MaxSim:=info[a].sim;
}
}
54

4 - Utility
Il ciclo principale esegue il merge dei cluster con la massima similarità finchè non
resta un solo cluster; per fare questo si utilizzano due procedure: la
FindMaxSim(cid,nn,sim) e la MergeCentroids(cid1,cid2). L’inizializzazione viene
realizzata usando una terza procedura ComputeSim(did,nn,Sim). La ComputeSim
calcola le similarità tra il documento did e gli altri documenti nella collezione;
restituisce l’identificativo del documento più simile a did in nn ed il valore della
misura di similarità tra i due documenti nella variabile Sim. FindMax è simile a
ComputeSim: calcola il valore della similarità tra il cluster cid e tutti gli altri
cluster attivi e restituisce l’identificativo del cluster più vicino a cid ed il valore
della similarità tra i due. La similarità viene calcolata usando i centroidi dei
cluster. La funzione MergeCentroids, infine, crea un nuovo centroide partendo da
quelli dei cluster cid1 e cid2; se indichiamo con wi1 e wi2 i pesi assegnati al
termine i-esimo nei vettori rappresentanti i due centroidi e con size1 e size2 le
dimensioni di questi ultimi, una soluzione proposta per il peso wi new del centroide
risultante è la seguente:
( * size ) + ( w * size )
wi1 1 i2
size
1
+ size
Un’altra ipotesi è quella di mantenere nel centroide risultante solo quei termini
che sono presenti in entrambi i centroidi di partenza, con un peso ottenuto da una
media opportuna dei due originali.
L’algoritmo di complete linkè analogo a quello per il single link, con l’unica
variante costituita dal diverso modo di ricalcolare il vettore delle similarità:
anzichè considerare il massimo valore di similarità tra ogni documento non ancora
nella gerarchia, si prende invece il minore; in tal modo si costruiscono i cluster in
modo da limitare la similarità minima tra i documenti di ogni gruppo.
Un secondo algoritmo di complete link citato in letteratura è stato elaborato da
Buckley: per approfondimenti si rimanda all’articolo di E. Voorhees
“Implementing agglomerative hierarchic clustering algorithms for use in
document retrieval”.
55
2
2

4 - Utility
Un punto che gioca a sfavore degli algoritmi di clustering gerarchico è costituito
dalla loro elevata complessità; infatti un algoritmo di hierarchical clustering
generalmente richiede
• ( )
2
O n passi per calcolare la matrice di similarità tra i documenti
• O (n)
passi per inserire gli n documenti nella collezione
• O (n)
passi per ricalcolare il vettore delle similarità ogni volta un nuovo
documentro viene inserito nella gerarchia
(dove n è ovviamente il numero di documenti che costituiscono la collezione) .
In totale abbiamo quindi una complessità pari a
2
O( n ) + O(
n)
O(
n)
≅ O(
n
2
)
che risulta essere alquanto elevata: nel caso di 500.000 documenti si renderebbero
necessari circa 250.000.000.000 passi.
4.3.3 Una visione alternativa del problema: SCATTER/GATHER
Come già visto, una delle maggiori obiezioni che vengono mosse agli algoritmi di
clustering gerarchico è la loro complessità computazionale troppo alta, quindi
risultano troppo lenti per grandi quantità di dati e non portano miglioramenti
apprezzabili al processo di retrieval.
Alcuni studiosi però sostengono che questa argomentazione sia valida solo se si
vede il clustering come un artifizio per cercare di migliorare altre tecniche di
ricerca convenzionali: a tal proposito hanno quindi introdotto un nuovo modello
(o paradigma, come si trova spesso indicato in letteratura) in cui il clustering è
l’operazione primaria nella ricerca dei documenti.
La formulazione standard del processo di information retrieval prevede che venga
sottoposta al sistema una query che è l’espressione dell’information need
dell’utente; si procede quindi ad una ricerca selettiva tra i documenti per trovare
quelli che soddisfano tale richiesta. Abbiamo già visto però come spesso sia
56

4 - Utility
difficile da parte dell’utente esprimere quelle che sono le proprie necessità:
potrebbe non avere familiarità con il vocabolario appropriato per descrivere
l’argomento di interesse, potrebbe utilizzare dei termini sbagliati, potrebbe anche
non avere ben chiare le sue reali esigenze.
È nata quindi l’idea di non concentrarsi essenzialmente sulla fase di searching,
ma di realizzare una fase di browsing, in cui viene presentata all’utente una
visione d’insieme della collezione con una prima suddivisione ad alto livello dei
contenuti. L’utente inizia quindi con un obiettivo generico, che viene via via
definendosi man mano che si conosce più in dettaglio il contenuto dei documenti
a disposizione. Si è quindi pensato ad un modello di information access detto
Scatter/Gather (letteralmente sparpagliare/raccogliere) che fa uso di un sistema
di clustering per estrarre i concetti comuni ai documenti e navigare la collezione.
Si inizia con una fase di scatter in cui la collezione viene suddivisa in un piccolo
numero di gruppi e all’utente viene proposto un breve sommario del contenuto del
cluster. Basandosi su tali riassunti l’utente seleziona uno o più di questi gruppi per
un ulteriore studio: i gruppi scelti vengono estratti nella fase di gather e diventano
una sub collezione che è il nuovo oggetto dell’analisi. Il sistema procede ad una
nuova fase di scatter suddividendo nuovamente i documenti rimanenti in una serie
di gruppi che condividono argomenti più dettagliati e che vengono nuovamente
presentati all’utente. Il processo va avanti con iterazioni successive, i gruppi
diventano via via più piccoli e più dettagliati; quando i gruppi diventano
sufficientemente piccoli si sposta l’attenzione sui singoli documenti.
Per questo modello si utilizzano algoritmi di clustering piatto, che partizionano la
collezione in una serie di gruppi mutuamente esclusivi ed esaustivi (vengono
anche detti k-means algorithms). Questi algoritmi hanno il vantaggio di essere
meno complessi di quelli gerarchici (alcuni arrivano all’ordine di O (kn)
), però
sono non deterministici (a differenza di quelli gerarchici), ossia il risultato finale
cambia a seconda dell’ordine in cui vengono analizzati i documenti.
Generalmente gli algoritmi di partitional clustering sono costituiti da tre fasi:
1. Individuare k centri (dove k è il numero richiesto di cluster)
57

4 - Utility
2. Associare ogni documento della collezione ad un centro
3. Rifinire le partizioni costruite
Alcuni esempi di algoritmi per identificare i centri iniziali sono il Buckshot
Algorithm ed il Fractional Algorithm; entrambi assumono che esista una qualche
routine di clustering su cui appoggiarsi e fanno uso di questa.
Intera
collezione
Scatter
Cluster 11 Cluster 21 ..... Cluster n1
Sub
Collection
Scatter
Figura 13 - Processo di scatter/gather
Buckshot Algorithm
Si sceglie in maniera assolutamente casuale un sottoinsieme campione di
documenti (di dimensione kn dove k=numero di cluster desiderati e
58
Gather
Cluster 12 Cluster 22 ..... Cluster m2
......
Gather

4 - Utility
n=cardinalità della collezione) e si applica a tale sottoinsieme la clustering
subroutine; il risultato è costituito dai centroidi dei cluster così calcolati. Tale
algoritmo ha una complessità pari a O (kn)
.
Fractional Algorithm
Questo algoritmo identifica k centri dividendo inizialmente la collezione in n/m
gruppi di dimensione fissa m. Ad ognuno di essi si applica separatamente la
clustering subroutine in modo da agglomerare i documenti singoli in gruppi in
maniera tale da avere una riduzione di individui pari ad un fattore ρ . Questi
gruppi vengono poi trattati come individui singoli e l’intero processo ripetuto
finchè non restano soltanto k gruppi. La complessità di questo algoritmo è pari a
O (mn)
.
Una volta identificati i k centri, si tratta di trovare un criterio per assegnare i vari
documenti della collezione ad uno di questi. Il più semplice algoritmo che si può
applicare è quello Assign-to-nearest, che consiste nell’assegnare ogni documento
al centro più vicino.
Una volta determinato un primo clustering si tratta di rifinirlo in qualche maniera;
vediamo alcune soluzioni possibili:
• Iterare l’algoritmo Assign-to-nearest: una volta determinato il primo
clustering si generano i centroidi per ogni gruppo, quindi si riassegna ogni
documento al più vicino centro in modo da formare dei nuovi cluster.
Tipicamente questo processo porta i maggiori cambiamenti alle prime
iterazioni, per cui è sufficiente un piccolo numero di step.
• Utilizzare l’algoritmo di Split: questo algoritmo divide in due ulteriori
partizioni quei cluster i cui documenti sono poco correlati tra di loro in
base ad un qualche criterio di similarità. Uno di questi criteri è la
cosiddetta self-similarity del cluster, ossia il valore medio di similarità tra i
documenti del cluster.
Un’altra misura di similarità è quella che calcola la similarità media tra i
59

4 - Utility
documenti del cluster ed il centroide che lo rappresenta. I cluster per cui la
misura di similarità è sotto una determinata soglia fissata ad-hoc vengono
bipartiti (usando ad esempio l’algoritmo di buckshot).
• Utilizzare l’algoritmo di Join: questo algoritmo esegue un merge dei
gruppi i cui centroidi hanno una distanza al di sotto di una certa soglia
Un altro esempio di algoritmo di clustering a singolo livello senza overlap è
l’algoritmo a passo singolo (single-pass), così detto in quanto ogni documento
viene esaminato una sola volta e, una volta asseganto ad un cluster, non viene più
riallocato. A differenza degli algoritmi visti in precedenza, dove era determinato a
priori il numero di cluster da ottenere, in questo caso tale numero non è
imponibile, ma risulta del tutto casuale. L’algoritmo fa uso di una misura di
similarità SIM(doci,docj), di un valore di soglia STHR (definito a priori) e di
centroidi CK ottenuti come media dei vettori assegnato al cluster k-esimo ClusK.
Vediamone una breve descrizione:
assegna doc1 a C1
per ogni docj (j=2,3,...,n)
{
per ogni ClusK
{
calcola SIM(docj,CK)
se SIM(docj,CK)>STHR allora
assegna docj a ClusK e aggiorna CK
altrimenti
crea un nuovo cluster con docj come centroide
}
}
4.4 Latent Semantic Indexing (LSI)
Si tratta di un metodo nato per risolvere un problema molto importante legato alle
tecniche di retrieval basate sul matching tra i termini delle query ed i termini nei
documenti. In un sistema di IR l’utente dovrebbe in teoria poter effettuare una
60

4 - Utility
ricerca basandosi sui concetti contenuti nei documenti anzichè basarsi sui singoli
termini; infatti generalmente ci sono più modi per esprimere un determinato
concetto ed è possibile che i termini contenuti nella query non corrispondano a
quelli utilizzati nei documenti. In altre parole, con questo metodo si cerca di
superare i problemi legati a due caratteristiche del linguaggio parlato, ossia:
• SINONIMIA = esistono più nomi per riferirsi ad un medesimo oggetto o
idea
• POLISEMIA = molte parole possiedono più di un significato
La polisemia ha l’effetto di ridurre la precision delle ricerche in quanto vengono
restituiti anche dei documenti che risultano irrilevanti per l’argomento in esame;
viceversa la sinonimia può causare una riduzione del recall per una data ricerca in
quanto alcuni documenti che sono rilevanti possono essere tralasciati solo perchè
non utilizzano le parole “giuste” per esprimere un determinato concetto. Per
cercare di ridurre il problema della sinonimia si è sovente fatto ricorso a tecniche
di term expansion oppure a thesauri; queste tecniche portano ad un miglioramento
del recall, accompagnato però da una diminuzione della precision dovuta alla
polisemia: infatti i termini introdotti possono avere più significati e quindi
recuperare anche documenti irrilevanti ai fini della ricerca corrente.
La polisemia risulta assai più difficile da affrontare in quanto legata alla naturale
ambiguità del linguaggio normale. Un approccio che è stato tentato consiste
nell’utilizzare un vocabolario controllato nella costruzione delle query in modo da
eliminare le ambiguità; un tale metodo ha un ovvio problema di usabilità in
quanto un vocabolario controllato risulta innaturale e difficile da ricordare.
Il concetto chiave su cui si basa il metodo di latent semantic indexing è che,
anzichè ricercare nel testo dei termini specifici, si effettua una ricerca basandosi
sui concetti contenuti nei documenti. Un altro modo di vedere questo metodo è
quello di pensare i documenti e le query mappati in uno spazio a m dimensioni,
dove m è il numero dei concetti, anzichè in uno spazio a t dimensioni, dove t è il
numero dei termini osservati. Il risultato è un’evidente diminuzione della
complessità, dato che m

Terms
4 - Utility
decomposition (SVD). Il latent semantic indexing non è altro che un metodo di
retrieval basato su informazioni di tipo statistico; esso cerca di determinare uno
spazio di concetti artificiali analizzando se e quanto di frequente determinate
parole vengono usate insieme. Vediamola così: è probabile che le parole
“macchina” e “automobile” compaiano in una collezione di documenti sempre
con le medesime parole (es. “motore”, “modello”, “veicolo”, “carrozzeria”,
“cilindrata”, ecc.), quindi tali termini avranno una rappresentazione similare nello
spazio dei concetti. L’idea principale nel LSI è di modellare le relazioni che
intercorrono tra i vari termini e di utilizzare queste informazioni per migliorare il
retrieval.
Il primo passo nel processo di singular value decomposition consiste nel generare
una matrice termini per documenti A; ogni termine analizzato è rappresentato da
una riga nella matrice A e ogni documento è rappresentato da una colonna ; ogni
elemento aij in A rappresenta quindi la frequenza del termine i nel documento j.
Documents
A
t x d
=
Terms
T
t x m
Figura 14 - Singular value decomposition
Il metodo di singular value decomposition viene utilizzato per decomporre la
matrice A in tre matrici separate: la prima è una matrice termini per concetti, la
seconda è una matrice concetti per concetti (diagonale, di dimensione m x m,
dove m è il rango di A) e la terza è una matrice concetti per documenti.
La matrice S può poi essere ridotta alle dimensioni k x k (con k

4 - Utility
essere considerato come il numero di concetti su cui vogliamo mappare i
documenti della collezione. In teoria questa approssimazione risulterebbe positiva
in quanto eliminerebbe il “rumore” contenuto nei documenti e manterrebbe
soltanto le caratteristiche concettuali più salienti. Il valore di k dovrebbe essere
sufficientemente grande da catturare tutti i concetti importanti e, allo stesso
tempo, sufficientemente piccolo da escludere tutti i dettagli poco rilevanti.
Una volta che la decomposizione (e la eventuale approssimazione) è stata
effettuata, è possibile utilizzare il modello per le ricerche. In questo modello una
query, così come un qualsiasi documento, è inizialmente un semplice set di
parole; una query viene vista come uno pseudo-documento che deve essere
mappato nello spazio dei concetti; una volta sistemata la query nello spazio si
procederà a restituire i documenti ad essa più vicini. Per poter confrontare una
query o pseudo-documento q con gli altri documenti della collezione dobbiamo
quindi partire dal vettore dei termini Xq che la rappresenta, da questo dobbiamo
derivare una rappresentazione Dq nello spazio dei concetti equivalente ad una
colonna della matrice D. A questo punto è possibile calcolare il coseno
dell’angolo formato dal vettore rappresentante la query e i vari vettori
rappresentanti i documenti della collezione e restituire quelli per cui il coseno
supera un certo valore di soglia.
Questo metodo presenta una serie di problemi: il primo è che lo spazio dei
concetti non è di facile comprensione; un altro problema è legato alle prestazioni
2 3
di questo sistema: l’algoritmo SVD ha una complessità quadratica O ( N k ) , dove
N è dato dalla somma dei termini e dei documenti mentre k è il numero di
dimensioni dello spazio dei concetti. Quest’ultimo, in particolare, fa sì che il
metodo LSI risulti inadatto per grandi collezioni che vengono aggiornate
frequentemente (in quanto bisognerebbe applicare l’algoritmo SVD ogni volta che
viene aggiunto o eliminato un documento della collezione e quindi cambia la
matrice A).
63

Capitolo 5
Implementazioni
Un sistema di IR è costituito da due parti principali: una collezione di documenti e
un metodo (strutture dati + algoritmi) di accesso a tale collezione. In questo
capitolo vedremo alcuni dei metodi di accesso che sono stati proposti e
sperimentati e ci soffermeremo in particolare sulle strutture dati necessarie per
realizzarli.
La soluzione che viene quasi universalmente adottata è quella di costruire un
indice per la collezione: in tale modo è possibile ricercare i documenti che
soddisfano una determinata query senza dover accedere ai documenti veri e
propri, velocizzando così notevolmente le operazioni.
L’utilizzo di un indice richiede un overhead legato alla costruzione e al
mantenimento di quest’ultimo, oltre ovviamente allo spazio fisico per la sua
memorizzazione, ma tutto ciò viene messo in secondo piano di fronte alla
velocizzazione che si ha nella fase di ricerca e di accesso ai documenti, in risposta
alle query dell’utente.
5.1 Inverted index
La maggior parte dei metodi di ricerca di tipo free-text visti finora (standard
boolean, extended boolean, proximity search e relevance ranking) possono essere
implementati in maniera efficiente mediante l’utilizzo di un inverted index (in
letteratura vengono spesso indicati anche come inverse index o inverted file). Al
momento gli inverted index costituiscono lo standard de facto per l’indicizzazione
word-based dei documenti.
Un inverse index è una struttura dati che associa un termine, o un’unità atomica di
informazione, con il set di documenti che contengono tale unità di informazione;
64

Term m
Term n
5 - Implementazioni
questo insieme di documenti viene detto posting list.
La struttura logica di un inverse index può essere rappresentata come in figura; in
letteratura abbiamo incontrato poi diversi modi di implementare questa struttura:
Index file
Posting list m
Posting list n
Posting file
Figura 15 - Struttura logica di un inverted index
La posting list non è altro che una lista associata con ognuno degli index term
considerati; in tale lista possiamo trovare talvolta una semplice indicazione binaria
riguardo la presenza di un certo termine in un determinato documento, spesso
però è presente una serie di informazioni aggiuntive quali la frequenza con cui la
parola in esame compare nel documento, oppure l’offset del termine rispetto
all’inizio del testo; queste informazioni aggiuntive sono necessarie per poter
implementare alcuni degli algoritmi di ricerca non booleana visti in precedenza.
L’utilizzo di un indice riduce drasticamente il numero di operazioni di I/O
richieste per soddisfare le query di ricerca: una volta ricevuta la query si
recuperano le posting list necessarie e si ordinano i documenti in base alle
informazioni in esse contenute.
65
Doc. 1
Doc. 2
Doc. 3
Doc. i
Doc. i+1
Documents file

cat
giraffe
5 - Implementazioni
Molto spesso gli indici (index file + posting file) hanno dimensioni paragonabili a
quelle della collezione a cui si riferiscono, per cui è impensabile mantenerli in
memoria centrale; dato che la parte più consistente (circa il 90%) è costituita dal
posting file, la soluzione più logica consiste nel memorizzare quest’ultimo in
memoria di massa, mantenendo l’index file in memoria centrale.
L’operazione principale che generalmente si effettua su di un indice è la ricerca,
per cui un inverted index deve sicuramente avere un response time il più basso
possibile: poichè l’accesso avviene sulla base di una singola chiave (ossia il
termine da ricercare), un modo per garantire un accesso veloce consiste nel
mantenere l’indice ordinato, in modo da poter eseguire una ricerca dicotomica,
oppure organizzarlo come una hash table. Utilizzando una tabella hash,
nell’ipotesi di riuscire a definire un perfect hashing (o comunque una funzione che
si avvicini ad esso), si avrebbe una complessità della fase di ricerca dell’ordine di
O () 1 .
dog
goat
eel
gerbil
iguana
horse
koala
carp
lion
okapi
frog
Figura 16 - Esempio di un B-tree
Nel caso in cui l’indice abbia dimensioni molto grandi, tali da non poter essere
mantenuto in memoria centrale, bisogna adottare una struttura dati che permetta di
66
racoon
rat
lizard
tiger
sea lion
mouse
snail
nut-hatch
wolf
otter
woodpecker
panda
zebra
pigeon

5 - Implementazioni
minimizzare il numero di accessi al disco necessari per recuperare la entry
dell’indice desiderata e, con essa, il riferimento alla posting list associata; alcune
tra le strutture che meglio si adattano a questa esigenza (e per questo molto
diffuse) sono quelle basate su B-tree o B + -tree.
Ogni nodo del B-tree include una serie di index-term che dividono l’indice, o una
parte di esso, in diverse frazioni; in altre parole le chiavi fungono da punti di
divisione per l’indice, il cui ordinamento è incorporato nella struttura dell’albero.
Ogni chiave, ad ogni livello, punta ad un nodo al livello inferiore: questo conterrà
gli index term che riempiono il gap tra quelli presenti nel nodo padre.
Per ottenere l’elenco ordinato di tutti i termini presenti nel B-tree bisogna
procedere con una visita preorder: per ogni sottoalbero si visita la radice (intesa
qui come un singolo termine del nodo) poi i sottoalberi figli, procedendo da
sinistra verso destra.
Poichè l’indice viene mappato usando il B-tree, ad ogni chiave nei vari nodi
dovranno anche essere associate le posting list corrispondenti e le informazioni
relative ai pesi dei termini; se si adotta un B + -tree le posting list verranno
associate soltanto ai nodi foglia.
I nodi dell’albero vengono mantenuti in memoria di massa e risulta conveniente
far corrispondere ad ogni nodo una pagina su disco; gli algoritmi di bilanciamento
dei B-tree consentono di effettuare le operazioni di ricerca con O(logb N)
accessi
al disco, dove b rappresenta il branching factor del B-tree (ossia il numero
massimo di figli di un nodo), mentre N è il numero di entry contenute del B-tree
(ossia il numero di index term trattati).
Il branching factor b è collegato con la dimensione delle pagine fisiche su disco ed
in genere è un valore piuttosto alto: un valore tipico è dell’ordine delle centinaia;
supponendo di avere un numero di entry dell’ordine del milione, una qualsiasi di
queste può essere raggiunta con tre accessi al disco al massimo (tale numero può
essere ulteriormente diminuito mantenendo in memoria il nodo radice, oppure
applicando delle strategie di caching di tipo LRU dei nodi del B-tree, ecc.).
67

5 - Implementazioni
Un occhio di riguardo deve essere riservato anche alla fase di aggiornamento
dell’indice: infatti la collezione in esame potrebbe venire modificata, potrebbero
venire aggiunti nuovi documenti o (meno probabile) eliminati alcuni di quelli
presenti; in questo caso l’indice deve essere aggiornato e questa operazione,
ovviamente, deve produrre il minor overhead possibile; nel caso di una struttura
B-tree si ha un numero di accessi al disco paragonabile a quello visto per la
ricerca, ossia O(logb N)
.
5.1.1 Procedura di ricerca
La procedura di ricerca all’interno di un inverted index è legata al modello di IR
system che si vuole realizzare. Se si sta implementando un sistema basato sulla
ricerca booleana pura e semplice si procede a ricercare nell’indice le entry
corrispondenti ai termini della query e si esaminano le posting list associate: nel
caso di una query congiuntiva (AND) si procede ad intersecare queste ultime,
mentre se la query è di tipo congiuntivo (OR) bisogna effettuare un merge delle
singole liste; in tal modo si ottiene il set dei documenti soddisfacenti la query.
Supponiamo ora di utilizzare un inverted index in associazione con il modello
vector space: come abbiamo già visto, sia i documenti che le query possono essere
visti come punti in uno spazio n-dimensionale; il problema del retrieval è quindi
un nearest neighbour searching, ossia dato un set di punti Di nello spazio, trovare
quelli più vicini al punto Q rappresentante la query.
Abbiamo già visto che la misura di similarità tra i documenti e la query è data da:
S ( D , Q ) =
i
n
∑
q
× t
j ij
j = 1
j = 1
n
2
q j ×
n
j = 1 j = 1
∑ ∑
68
t
2
ij
=
n
∑
L
Q
q
j
× t
× L
dove LQ e LD indicano la lunghezza dei vettori rappresentanti la query ed il
documento.
D
ij

5 - Implementazioni
Utilizzando un inverted index non è più necessario calcolare il valore di tale
similarità per tutti i documenti della collezione, in quanto si avrà S( Di
, Q)
≠ 0 se
e solo se la query ed il documento hanno almeno un termine in comune; questo
vuol dire che bisogna prendere in considerazione soltanto quei documenti che
appaiono almeno in una delle posting list associate ai termini della query.
Un primo algoritmo fu proposto da Noreault; l’idea base è di scorrere le liste
relative ai termini della query e di allocare un contatore inizializzato a uno per
ogni nuovo documento incontrato; se lo stesso documento viene nuovamente
incontrato in una delle liste seguenti, il suo contatore viene incrementato di uno. Il
risultato finale è che in ogni contatore si ha il numero di termini comuni al
documento e alla query; se ai termini sono associati dei pesi, i contatori verranno
incrementati di un valore pari al prodotto di tali pesi.
Vediamo una pseudocodifica per l’algoritmo:
Procedure Search;
for each QueryTerm qj do
Read InvertedList; /*composed of couples(Di,wi)*/
for each Document Di in the list do
if NewDocument then
AllocateCounter C(Di);
C(Di):=0;
endif;
C(Di):=C(Di) + (qj * wj);
endloop;
endloop;
for eachCounter C(Di) do
C(Di):=C(Di) / (LQ * LDi); /*evaluation of Sfunction*/
endloop
Sort C(Di) in decreasing order;
Present the top r documents;
end Search.
L’algoritmo appena visto calcola la similarità tra la query e tutti i documenti che
condividono almeno un termine con quest’ultima; tale numero potrebbe essere
molto alto, tuttavia è plausibile pensare che un buon numero dei documenti
interessati abbia una bassa similarità con la query.
69

5 - Implementazioni
L’algoritmo precedente quindi spende un considerevole numero di passi nel
calcolare similarità per documenti che non saranno nel set di quelli restituiti.
Partendo da queste considerazioni sono stati apportati alcuni miglioramenti alla
procedura seguita per la ricerca; lo scopo è stato quello di minimizzare il numero
di posting list da valutare: se ci si accorge, prima della fine, di avere già ottenuto il
set di documenti ottimo, non è necessario controllare le rimanenti posting list.
Come primo passo i termini della query vengono ordinati in ordine decrescente di
peso: supponendo di utilizzare il sistema di pesatura tf x idf, si ha come
conseguenza che i termini presenti in un basso numero di documenti vengono a
trovarsi in cima all’elenco; quindi verranno processate prima le liste più brevi,
mentre quelle più lunghe verranno eventualmente processate tardi. Supponiamo
ora di avere già processato m liste su un totale di n e di aver ottenuto un closest set
R composto dai documenti D1, D2, ..., Dr in ordine decrescente di similarità.
Dobbiamo ora processare la m+1 esima lista: per ogni documento Di presente in
tale lista si assume che contenga anche tutti i termini della query che non sono
ancora stati analizzati e si calcola un upper bound per il valore di similarità; se il
valore così ottenuto è inferiore a quello per il documento Dr, significa che il
documento Di non raggiungerà mai il closest set R e quindi posso evitare di
considerarlo ulteriormente; posso inoltre terminare l’algoritmo se il documento
Dr+1, il primo tra quelli che non rientrano in R, ha un upperbound inferiore a
quello di Dr.
Procedure Search;
sort QueryTerms in decreasing order of weight;
repeat /*for each query term qj*/
Read InvertedList; /*composed of couples(Di,wi)*/
for each Document Di in the list do
if RelSetNotFull then
Compute C(Di);
Enter Di into the RelSet;
else
Compute U(Di);
if U(Di)

5 - Implementazioni
else
Compute C(Di);
if C(Di)>C(LastDocIn) then
Enter Di into RelSet;
endif;
endif;
endif;
endloop;
Compute U(FirsDocOut);
until LastQueryTerm or U(FirstDocOut)

5 - Implementazioni
collisione e bisogna procedere ad aggiornare la posting list, che, come già visto, è
generalmente costituita da una lista linkata in cui i nuovi documenti (o meglio, i
riferimenti ad essi) vengono inseriti in testa. Si effettua quindi un controllo sulla
prima entry della lista per verificare se l’identificativo del documento corrisponde
a quello in esame: in caso affermativo si incrementa il contatore delle occorrenze
del termine nel documento (se si necessita di tale informazione per implementare
la ricerca), altrimenti significa che è la prima occorrenza del termine nel
documento, per cui si inserisce una nuova entry in testa alla posting list in esame.
In questo processo le posting list dovrebbero venire mantenute interamente in
memoria; poichè un inverted index con le posting list associate può arrivare a
richiedere uno spazio dello stesso ordine di grandezza di quello necessario per la
collezione, è impensabile che tutto il processo possa avvenire interamente in
memoria centrale. Ogni volta che viene allocata una parte di memoria durante il
processo, si controlla di non superare la quota ad esso riservata e in caso
affermativo si trasferiscono tutte le posting list su disco; ogni volta che si compie
questa operazione si procede anche a linkare le liste in memoria con quelle già
presenti su disco che si riferiscono ai medesimi termini. La costruzione dell’indice
termina quando tutti gli index term sono stati processati; a questo punto si hanno a
disposizione anche le informazioni sulla totalità dei documenti e, se necessario, si
procede a calcolare i pesi da assegnare agli index term, in particolare il valore di tf
x idf.
Nell’allocare lo spazio su disco per le liste si possono seguire due politiche: la
prima è pensata per ottimizzare il tempo in fase di scrittura (update time) e
consiste nell’accodare i nuovi dati sequenzialmente a quelli già presenti su disco;
così facendo si ottimizza la fase di scrittura in quanto il disco non dve compiere
alcuna operazione di seek. La seconda politica ha l’obiettivo di ottimizzare la fase
di lettura delle liste durante la ricerca (query time): quando si deve aggiornare la
lista relativa ad un determinato termine w si legge la posting list L ad esso
associata, si accoda la nuova entry, quindi si riscrive L in una nuova locazione del
disco; così facendo si minimizza il query time perchè ogni lista può essere letta
con un’unica operazione di seek.
72

5 - Implementazioni
5.1.3 Compressione di un inverted index
Uno degli obiettivi che si hanno quando si sviluppa un sistema di information
retrieval è quello di ridurre il più possibile l’overhead dovuto alle operazioni di
I/O; tale overhead è ovviamente proporzionale alle dimensioni dell’index file,
quindi una delle vie per ridurre il processing time consiste nel cercare di ottenere
degli indici il più compatti possibile. In letteratura viene dato ampio spazio alle
tecniche di compressione; le due aree su cui si focalizzano le tecniche proposte
sono la compressione dell’indice dei termini e la compressione delle posting list;
una maggiore attenzione verrà dedicata a quest’ultima poichè le posting list
costituiscono il grosso della struttura di un inverted index, per cui le tecniche per
la loro compressione sono quelle che potenzialmente possono portare i maggiori
vantaggi.
Fixed length index compression: questa tecnica può essere applicata se le entry
in ogni posting list vengono memorizzate in ordine crescente o decrescente di
identificativo dei documenti; così facendo è sufficiente memorizzare in ogni entry
soltanto la differenza tra il valore corrente e quello contenuto nella entry
immediatamente precedente. In tal modo è possibile ottenere dei valori
relativamente bassi, che possono essere memorizzati utilizzando un numero
ridotto di bit. La tabella seguente indica i range di valori che si possono ottenere
conuno, due, tre e quattro byte:
Range di valori Num. di byte necessari
0 ≤ X < 64 1
64 ≤ X < 16384 2
16384 ≤ X < 4194304 3
4194304 ≤ X < 1073741824 4
Un esempio di compressione di tipo byte-aligned (BA) utilizza i due bit più alti
per indicare il numero di byte utilizzati per codificare effettivamente il valore, che
73

5 - Implementazioni
viene mappato a questo punto su 6, 14, 22 o 30 bit. Nella migliore delle ipotesi si
ottiene una compressione del volume di dati fino a quattro volte, infatti il caso
ottimo sarebbe quello in cui tutti i valori da codificare fossero inferiori a 2 6 =64 e
potessero quindi venire memorizzati usando un singolo byte mentre, senza
compressione, si utilizzerebbero sempre comunque quattro byte per ogni entry
della posting list.
Variable length compression: la tecnica che vedremo ora presuppone
nuovamente che in ogni entry venga mantenuta soltanto la differenza tra
l’identificativo corrente e quello nella entry precedente e utilizza per la
compressione di tali valori un codice detto Elias encoding. Questo codice
rappresenta un certo intero x utilizzando 2⎣log2 x ⎦ + 1 bit; i primi ⎣ 2 x⎦
la rappresentazione unaria del valore ⎣ 2 x⎦
74
log bit sono
log (la rappresentazione unaria è una
rappresentazione degli interi usando solo il digit 1), questa rappresentazione
unaria viene poi seguita da uno stop bit a 0; a questo punto abbiamo rappresentato
la più alta potenza di 2 che non superi il nostro valore x; i restanti ⎣ 2 x⎦
rappresentano il valore
k
x− 2 (dove k ⎣log2 x⎦
Supponiamo di dover codificare il numero 14:
= ) in binario.
1. ⎣log2 14⎦=
3 va rappresentato in unario: 111
2. Si inserisce uno stop bit a 0: 1110
3. Si codifica il resto 2 14 8 6
3
− = − =
110
log bit
x in binario usando ⎣ 14⎦
3
log 2 = bit:
4. Si concatenano le codifiche parziali ottenute ai punti 1), 2) e 3) e si ottiene
quindi 1110110
La decodifica viene eseguita in un singolo passo perchè si sa che per un numero
con n bit prima dello stop bit a 0, ci saranno n bit successivi a tale stop bit.
Gamma encoding: questo schema è basato su un vettore V contenente dei valori
interi positivi vi ordinati in modo crescente tali che ∑vi ≥ N (dove N è il
massimo valore che si deve poter codificare); per codificare un numero intero x ≥
1 relativamente a V occorre trovare quel valore di k tale che

5 - Implementazioni
k −1
∑
j = 1
v
j
< x ≤
ossia trovare il primo componente di V tale che la somma di tutti i componenti
precedenti sia maggiore o uguale al valore x da codificare.
Supponiamo ad esempio di avere x=7 e V={1, 2, 4, 8, 16, 32}. Allora i primi tre
componenti di V, cioè {1, 2, 4} sono quelli necessari per ottenere t, quindi k=3; a
questo punto il valore di k viene rappresentato con una qualche codifica
(tipicamente quella unaria), seguita dalla differenza
d
1
= − ∑ − k
x
75
j = 1
k
∑
v
j = 1
j
v
j
−1
Nel nostro caso d=7-(1+2)-1=3, che viene codificato in ⎡ v ⎤= ⎡log 4⎤=
2
log2 k
2
bit. Una scelta tipica è quella di avere un vettore V composto da potenze di 2,
ossia {1, 2, 4, 8, ...}, chiaramente però si può modificare il vettore V in modo da
dare caratteristiche diverse alla compressione.
5.2 Signature file
Una possibile implementazione di un sistema di information retrieval molto citata
in letteratura è quella che fa uso dei cosiddetti signature file.
Un signature file memorizza sotto forma di stringhe binarie delle astrazioni
(signature appunto) dei documenti (o parti di essi) che vengono poi confrontate
con una corrispondente signature della query di ricerca.
I vari termini presenti nel documento vengono codificati mediante una funzione
hash, quindi combinati in modo da ottenere una bitstring (di lunghezza fissa o
variabile) che rappresenta il documento in esame.
La tecnica di recupero basata sui signature files è di tipo booleano, cioè si cercano
i documenti che contengono i termini espressi nella query.

0100101101001010
1100010110101000
1000101101100011
....
....
signature file pointer
file
5 - Implementazioni
Figura 17 - Sistema di IR basato su signature file
Le query subiscono lo stesso trattamento dei documenti: si codificano i vari
termini mediante una funzione hash e si combinano i valori ottenuti in modo da
generare una stringa binaria. A questo punto si confrontano le signature dei vari
documenti con quella della query: ogni record contenente una signature in cui
sono a “1” tutti i bit corrispondenti a quelli a “1” della query indica un documento
che potenzialmente soddisfa la query di ricerca. Si è detto potenzialmente, infatti è
inevitabile che più documenti abbiano le signature in cui risultano settati gli stessi
bit che sono a “1” nella codifica della query ma che in realtà non contengono i
termini indicati in essa. Quando si verifica questa condizione si ha un false drop;
ovviamente quando si studia un sistema di signature uno degli obiettivi a cui si
punta è quello di minimizzare la probabilità di avere dei false drop. In fase di
ricerca quindi bisogna effettuare un’ulteriore analisi per verificare se i record
restituiti corrispondono ad un false match oppure ad un true match; tale analisi
può essere fatta decodificando opportunamente le signature recuperate oppure,
ove questo non fosse possibile, effettuando una ricerca full-text sul subset di
documenti restituiti.
76
doc. #1
doc. #2
doc. #3
....
document file

5 - Implementazioni
Faremo ora una rapida carrellata delle principali tecniche per ottenere un signature
file.
5.2.1 Metodo WS (Word Signature)
Si genera la signature di ogni termine (significativo) del documento mediante una
funzione hash, in modo da ottenere per ognuno una stringa di fT bit; la signature di
un documento è una stringa di f bit ottenuta concatenando tutte le D signature dei
singoli termini (quindi f = D * fT
). Vediamo un esempio:
TERMINE signature extraction method
SIGNATURE 0100 0111 1011
La signature del documento completo risulta 0100 0111 1011 (D=3 ; fT=4 ; f=12).
Questo metodo ha il vantaggio di preservare l’ordine dei termini, ma presenta una
serie di inconvenienti: il primo è ovviamente quello di generare signature di
dimensioni variabili, il che complica la fase di ricerca.
La probabilità di false drop vale:
F
d
≈
2
D
f
D
dove D=numero di word signature per documento, f=numero di bit per signature,
fT=numero di bit per ogni word signature (D e f sono valori medi).
Esempio: con D=40 termini per signature e fT=25, cioè f=1000 bit assegnati ad
ogni documento (in media), la probabilità di false drops per una query di un
−6
termine risulta pari a Fd = 1.
2 * 10 , cioè un false drop per milione di documenti.
77
=
2
D
fT

5.2.2 Superimposed coding
5 - Implementazioni
Il metodo di superimposed coding è di gran lunga il più diffuso tra i vari signature
method, grazie alla sua velocità in fase di ricerca ed al limitato overhead di
memoria (dal 10% al 20% del file dei documenti).
Ogni termine, mediante una funzione hash, pone a “1” un determinato numero m
di bit di una stringa di lunghezza fissa f; la signature del documento è ottenuta
facendo l’OR delle signature dei singoli termini.
TERMINE SIGNATURE DEL TERMINE
signature 010 000 100 001
extraction 010 010 010 000
method 000 100 010 001
SIGNATURE DEL DOCUMENTO = 010 110 110 001
In fase di ricerca la signature S associata ad un determinato documento soddisfa la
query se e solo se, data la signature q della query generata allo stesso modo, si ha
S AND q = q, ovvero se e solo se la signature S del documento contiene tutti “1”
nelle posizioni in cui q vale “1”. Le conjunctive query, ossia le query contenenti
termini in AND, vengono trasformate nello stesso modo visto per i documenti; le
disjunctive query, ossia quelle contenenti termini in OR, vengono invece mappate
mediante un insieme di signature distinte, una per ogni blocco in OR: tali
signature sono trattate separatamente e si procede poi ad effettuare il merge dei
risultati parziali così ottenuti.
La probabilità di false drop per una query con un singolo termine è data da:
F
d
⎡
≈ ⎢1
− e
⎢⎣
78
m D
−
f
*
ed è pari alla probabilità che una signature abbia a “1” tutti gli m bit specificati
nella query. Si può notare che Fd, per valori fissati di D e f , dipende dal numero
m di bit settati a “1” (tale valore viene spesso indicato come peso della signature);
⎤
⎥
⎥⎦
m

5 - Implementazioni
in particolare si può dimostrare che Fd aumenta sia se m è troppo grande (quindi
se la signature del documento ha troppi bit a “1”), sia se è troppo piccolo (e quindi
si hanno pochi “1” nella signature). A fronte di queste considerazioni si deduce
che esiste un valore ottimale di m; tale valore si ottiene a partire dalla formula
f
precedente mediante alcuni passaggi matematici e vale mopt = ln 2 , con cui si
D
ottiene
Fd
−m
opt
= 2 .
Operativamente si è visto che, con il valore di m appena ottenuto, le signature dei
documenti avevano mediamente la metà dei bit a “1”.
Esempio: supponiamo di avere signature di f=1024 bit ed un numero D=40 di
termini. Si ottiene mopt=18 e la probabilità di false drop risulta pari a
−6
F d = 4.
6 * 10 , ossia una query con un solo termine produce in media 5 false
drops su un milione di documenti.
5.2.3 Metodi basati su compressione
Questi metodi fanno uso di signature sparse, cioè contenenti un basso numero di
bit a “1”, che vengono poi compresse con diverse tecniche. Questi metodi
permettono di ottenere signature file di dimensioni assai ridotte e probabilità di
false drop inferiori a quelle viste per i casi precedenti; il tempo di ricerca, però,
risulta abbastanza elevato.
Vediamo ad esempio la tecnica di Bit-Block Compression: essa fa uso della
tecnica di superimposed coding, ma con signature di dimensione B molto grande
divise in blocchi contenenti b bit che vengono poi compressi separatamente.
TERMINE
SIGNATURE DEL TERMINE
(B=20; b=4; m=1)
signature 0000 0000 0010 0000 0000
extraction 0001 0000 0000 0000 0000
method 1000 0000 0000 0000 0000
79

5 - Implementazioni
SIGNATURE SPARSA = 1001 0000 0010 0000 0000
A questo punto si procede alla compressione della signature: la signature
compressa è costituita da tre parti, una per ogni blocco:
A. un bit a “1” o a 0 a seconda che esista oppure no un bit settato nel blocco
B. il numero di bit a “1” nel blocco meno 1, il tutto espresso in notazione
unaria, più uno “0” terminale
C. la posizione dei bit a “1” nel blocco (espressa usando log2b bit per ogni
posizione).
Partendo dall’esempio precedente si avrebbe:
SIGNATURE SPARSA 1001 0000 0010 0000 0000
PARTE A 1 0 1 0 0
PARTE B 10 0
PARTE C 0011 10
La signature compressa può venire memorizzata in due modi:
1. BCG (per gruppi-blocchi): 1100011 0 1010 0 0
2. BCP (per parti): 10100 100 001110
Il metodo BCP è quello che richiede meno confronti in fase di ricerca, in quanto
l’esame dei soli bit della parte A è sufficiente per eliminare molte signature dal
risultato.
Utilizzando questi metodi si ottiene una probabilità di false drop pari a:
F d
≈ 1 . 913*
m−
Esempio: con m=1, D=40 e f=1024 si ottiene
quindi, di quella ottenuta con gli altri metodi.
80
f
D
−8
F d = 4.
5*
10 , molto più bassa,
Le signature relative ai documenti che costituiscono la collezione vengono
ovviamente mantenute in uno o più file separati; le dimensioni di questi file
generalmente sono assai inferiori a quelle della collezione a cui si riferiscono e la
scansione risulta assai più veloce rispetto a quella dell’intero set di documenti. Le

5 - Implementazioni
due strutture più utilizzate e più citate in letteratura sono quella sequenziale (SSF,
Sequential Signature Files) e quella Bit-Sliced (BSSF, Bit Sliced Signature Files).
L’organizzazione sequenziale è quella più semplice, ma allo stesso tempo risulta
inadeguata per grandi database a causa della lentezza nella scansione. Per ovviare
a questo problema sono state ideate diverse soluzioni che sfruttano l’idea di base
di suddividere in più parti il signature file.
La classificazione principale delle tecniche sopracitate distingue innanzitutto tra
organizzazioni basate su:
PARTIZIONAMENTO VERTICALE
Idea di base: Signature file memorizzato per colonne
Vantaggio: Si esaminano solo alcune colonne
Svantaggio: Gli inserimenti sono onerosi
Esempi: bit-sliced, frame sliced
PARTIZIONAMENTO ORIZZONTALE
Idea di base: Signature simili raggruppate in bucket
Vantaggio: Si devono esaminare solo alcuni bucket
Svantaggio: Tende a SSF per query con peso basso
Esempi: S-tree, Key based
Vediamo ora più in dettaglio alcuni dei metodi citati.
5.2.4 Bit-sliced signature file
Questo metodo fa uso di f file, uno per ogni posizione dei bit nella signature (o,
per vederla in un’altra maniera, uno per ogni colonna del signature file). Il
vantaggio sta nel fatto che in fase di ricerca si accede soltanto ai file relativi alle
colonne in cui i bit della signature della query sono a “1”; a questo punto si
81

5 - Implementazioni
restituiscono i documenti per cui tutti i bit del sottoinsieme così ottenuto sono a
“1”.
Supponiamo ad esempio di avere un file costituito dalle seguenti signature (f=8):
s1: 00011110
s2: 11010001
s3: 00111100
s4: 11000011
s5: 00110110
s6: 11001001
Organizzandolo con una struttura bit-sliced si ottengono 8 file, ognuno
corrispondente ad una colonna del signature file, e cioè:
c1: 010101
c2: 010101
c3: 001010
c4: 111010
c5: 101001
c6: 101010
c7: 100110
c8: 010101
Se dovessimo analizzare una query con signature q=00100010 sarebbe sufficiente
quindi accedere ai file c3 e c7 e restituire quei documenti i cui bit della signature
presenti nei file considerati sono tutti a 1.
Questo metodo risulta particolarmente efficace nel caso di query con basso peso,
ma presenta dei costi di inserimento elevati: bisogna infatti fare accesso a f file
diversi ogni volta che si inserisce un nuovo documento nella collezione; questa
tecnica risulta quindi poco efficiente se si hanno database fortemente dinamici.
Un modo ulteriore per ottimizzare la ricerca potrebbe essere quello di selezionare
le slice in ordine crescente di densità, dalle più sparse alle più dense, in modo che
le prime riducano subito il campo di ricerca; una simile implementazione richiede
ovviamente che ad ogni slice venga associata una qualche indicazione sulla sua
densità.
Con i bitsliced signature file ci si trova spesso di fronte a problemi di scala:
collezioni con un grande numero di documenti hanno delle slice molto lunghe,
che richiedono quindi un notevole overhead in termini di I/O per essere lette;
un’eventuale compressione delle slice porterebbe dei benefici in termini di
occupazione di spazio (sperimentalmente si è visto che si arriva ad una riduzione
82

5 - Implementazioni
del 50% delle dimensioni), ma la successiva fase di decodifica renderebbe
estremamente lento l’intero processo (le tecniche di compressionedecompressione
che possono essere utilizzate con le slice risultano infatti assai
più complesse di quelle utilizzabili con gli index file).
5.2.5 Frame-sliced signature file
L’idea di questo metodo è quella di forzare a “1” i bit di un termine in una zona
ristretta della signature (frame, composto da s =
f
bit); la signature del
k
documento viene poi ottenuta come nel superimposed coding, realizzando ciè
l’OR delle signature relative ad ogni singolo termine. Si ha ancora un
partizionamento verticale del signature file, ma ora le partizioni non sono più a
livello di singola colonna, bensì a livello di frame.
In fase di ricerca, per una query di n termini saranno richiesti al massimo n accessi
su disco, poichè al massimo n frame della query signature conterranno dei bit a
“1”; rispetto al metodo bit-sliced si ha il vantaggio che, in fase di inserimento, gli
accessi saranno solo k (=numero di frame) e non più f (=numero di colonne).
TERMINE SIGNATURE DEL TERMINE
signature 1010 0000 0000
extraction 0000 1100 0000
method 1001 0000 0000
SIGNATURE DEL DOCUMENTO = 1011 1100 0000
5.2.6 S-Tree
Un signature tree è un’organizzazione a partizionamento orizzontale multilivello.
Ogni foglia dell’S-tree contiene signature “simili”, ossia con distanza di Hamming
bassa, oltre ai puntatoriai documenti; l’OR di queste signature costituisce la
83

5 - Implementazioni
chiave della foglia, che viene riportata in un nodo al livello superiore dell’albero
assieme al puntatore alla foglia.
Sempre partendo dal signature file visto in precedenza si otterrebbe un signature
tree come quello in figura (supponendo di avere nodi con capacità di 3 signature):
00111110
11011011
B s1: 00011110
s3: 00111100
s5: 00110110
C
Figura 18 - Esempio di S-Tree
La query con signature q=00100010 porta ad accedere inizialmente al nodo A,
quindi al nodo foglia B.
I signature tree presentano alcuni grossi inconvenienti: uno di questi sta nel fatto
che i nodi ai livelli superiori tendono a “saturare” generando signature con molti
“1”, che sono quindi inutili per guidare la ricerca. Nel caso precedente, se
avessimo avuto una query con signature q1=00011010, il nodo radice non sarebbe
stato in grado di indirizzare la ricerca ad uno dei due nodi foglia; in una tale
situazione i nodi foglia avrebbero dovuto necessariamente essere letti in maniera
sequenziale.
5.2.7 Organizzazioni “Key-based”
A
L’idea comune a queste organizzazioni è quella di raggruppare in bucket le
signature con uno stesso valore di chiave, definita come il valore di una parte
della signature. In fase di ricerca, se un bucket ha chiave Kb e la query ha chiave
Kq, allora si accede a tale bucket se e solo se Kb AND Kq = Kq.
84
s2: 11010001
s4: 11000011
s6: 11001001

5 - Implementazioni
Vediamo ora alcuni esempi di organizzazioni “Key-Based”:
ORGANIZZAZIONE DESCRIZIONE
Fixed Key (o Fixed Prefix) Usa una chiave di k bit
Extended Key
Floating Key
Usa una chiave con un numero fisso, z, di bit
a “0”
La chiave è la prima stringa di k bit con il
minimo numero di bit a “1”
Ad ognuna di queste organizzazioni corrisponderebbero le seguenti suddivisioni
del signature file di esempio:
Fixed Key (k=2)
s1: 00011110
s3: 00111100
s5: 00110110
Key=”00” Key=”11”
Extended Key (z=2)
s1: 00011110
s3: 00111100
s5: 00110110
Floating Key (k=2)
Ovviamente, nel caso di un’organizzazione key-based si può pensare di
memorizzare le varie chiavi in una key-table sufficientemente piccola da poter
essere mantenuta in memoria centrale, in modo da rendere ancora più efficiente e
veloce la fase di ricerca.
85
s2: 11010001
s4: 11000011
s6: 11001001
s2: 11010001 s4: 11000011
s6: 11001001
Key=”00” Key=”11010” Key=”1100”
s1: 00011110
s3: 00111100
s5: 00110110
s2: 11010001 s4: 11000011
s6: 11001001
Key=”00” Key=”****00” Key=”**00”

Capitolo 6
Integrazione tra IR e database
I due campi dei database e dell’information retrieval si sono evoluti separatamente
per un lungo periodo, questo a causa delle differenze tra i rispettivi argomenti di
studio: mentre l’IR si occupa di testi in linguaggio naturale (quindi dati non
formattati) e recupero incerto di informazioni, l’applicazione e lo studio dei
database si focalizza su data model (quindi informazioni strutturate), query
language, ossia linguaggi dichiarativi, e recupero booleano delle informazioni.
Con l’andare del tempo però si è arrivati ad una sempre maggiore integrazione tra
i due campi a causa di una serie di motivi. Alcuni di questi sono di tipo
funzionale, in quanto sempre più applicazioni richiedono di poter accedere ad una
combinazione di dati formattati e non; tali applicazioni vengono sovente indicate
in letteratura come textual database e fondamentalmente sono dei repository di
documenti. I textual database forniscono una combinazione di content
management, ossia gestione del contenuto dei documenti, e manipolazione di dati
formattati: queste due parti vengono generalmente indicate come content structure
e logical structure di un documento. Consideriamo ad esempio una richiesta,
sottoposta ad una qualche raccolta digitale, dei “Rapporti tecnici del CNR a
partire dal 1990 sull’attività eruttiva del Vesuvio” (posto che il CNR si occupi di
queste cose!): in questo esempio abbiamo sia delle informazioni associate ad
attributi degli oggetti presenti nella raccolta, ossia “Rapporto tecnico” (= tipo di
documento), “CNR” (= redattore del documento), “a partire dal 1990” (= periodo
di pubblicazione), sia delle informazioni legate al loro contenuto, l’ “attività
eruttiva del Vesuvio”.
Altri argomenti a favore dell’integrazione sono di natura tecnologica, in quanto un
DBMS offre un indispensabile supporto per la risoluzione di una serie di problemi
che un sistema di IR, come qualsiasi altra applicazione, deve affrontare, vale a
dire:
86

concurrency control
recovery
indexing dei dati
6 – Integrazione tra IR e database
parallel processing.
I campi qui elencati, nell’ambito dei database vantano anni di esperienza, studi ed
implementazioni.
Argomento di questo capitolo è l’integrazione tra i sistemi di IR ed i database di
tipo relazionale. Il modello relazionale è basato sul concetto di tabella, che viene
anche chiamata relazione: una singola colonna di una relazione viene detta
attributo, una relazione, infine, è un set di tuple; come requisito fondamentale,
una relazione deve essere in prima forma normale (tipicamente indicata 1NF),
cioè tutti i valori degli attributi devono essere atomici. Il linguaggio standard di
interrogazione di un database relazionale è SQL (Structured Query Language): si
tratta di un linguaggio dichiarativo, ossia uno statement SQL specifica solo quale
debba essere il risultato e non quali operazioni devono essere eseguite per
ottenerlo.
L’uso dei database relazionali ha una serie di vantaggi, ma anche una serie di
problemi non indifferenti: il primo sta nel fatto che, anche per richieste al sistema
relativamente semplici, le interrogazioni SQL che ne derivano possono essere
molto complicate; per questa ragione il linguaggio SQL risulta poco adatto in
un’interfaccia utente come linguaggio di interrogazione a disposizione degli
utilizzatori del sistema: si dovrà prevedere un qualche parser che trasformi le
richieste dell’utente, espresse in un qualche linguaggio ad esso più congeniale, nei
corrispondenti statement di interrogazione per il motore di database.
Il secondo inconveniente è legato al fatto che le relazioni debbano essere in 1NF:
dovendo utilizzare dei database relazionali bisogna decidere quale debba essere
l’unità atomica di informazione da registrare in ogni singola tupla. Un database
relazionale consiste di un insieme di tabelle (o relazioni), ogni tabella consiste di
un set di tuple, ogni tupla consiste di una sequenza di attributi il cui valore deve
87

6 – Integrazione tra IR e database
essere atomico. I dati di un sistema di IR sono molto più complessi: al livello più
alto si ha una collezione di documenti e ogni documento può essere composto da
una serie di campi; oltre questo livello di dettaglio la struttura dei dati diventa
diversa: anzichè essere atomico, un campo di un documento (potrebbe essere un
abstract, il corpo del documento, l’indice) contiene una sequenza di frasi che a
loro volta sono composte da più parole; ogni parola, in conclusione, è una
sequenza di valori atomici, ossia le lettere. La soluzione più ovvia è quella di
associare ad ogni tupla una singola parola del testo (anche in considerazione dei
tipi di dati standard presenti nei DBMS sul mercato); questa soluzione, unita al
vincolo che le tabelle devono essere devono essere in 1NF fa sì che gli oggetti del
modello di IR (in particolare i documenti) siano “spalmati” su più relazioni. Tutto
questo fa sì che le query di interrogazione risultino alquanto complesse da
scrivere; inoltre queste ultime richiederanno una lunga serie di join per poter
essere valutate, join che rallentano il processo di ricerca: se ne deduce quindi che
la normalizzazione delle relazioni è accompagnata da una perdita di efficienza.
Le ultime generazioni di database relazionali supportano anche tipi di dati non
tradizionali, come testi complessi o dati multimediali (i cosiddetti campi di tipo
BLOB, Binary Large OBject), per cui si potrebbe pensare di memorizzare in una
singola tupla un intero documento o una parte di esso; tutto questo risulterebbe
però alquanto inefficiente, in quanto sarebbe assai problematico per il DBMS
gestire degli indici su tali campi e le ricerche si risolverebbero in una scansione
sequenziale del testo, con prestazioni decisamente insoddisfacenti. In realtà
vedremo più avanti che questo tipo di soluzione è molto utilizzata, sono però
necessarie delle estensioni dei database al fine di migliorarne l’efficienza.
Individuato nella prima forma normale uno dei problemi maggiori del modello
relazionale (limitatamente all’ambito dell’IR ovviamente), alcuni studiosi hanno
proposto delle estensioni di quest’ultimo che, nelle loro ipotesi, dovevano favorire
la gestione di documenti testuali; riportiamo questi studi anche se non abbiamo
trovato informazioni riguardo ad implementazioni o prototipi basati (direttamente)
su di essi.
88

6 – Integrazione tra IR e database
Schek e Pistor hanno introdotto un modello relazionale in cui le relazioni non
erano più necessariamente in prima forma normale: un singolo attributo poteva
essere a sua volta una relazione, ossia un set di tuple. Tale modello risultava
quindi essere in non-first-normal-form (NF 2 ).
Supponendo di voler mantenere le informazioni bibliografiche su una collezione
di libri, una soluzione possibile con il modello NF 2 potrebbe essere la seguente:
BOOKS
Authors Title Price Descriptors
A1, A2 T1 P1 D1, D2
A2 T2 P2 D1, D4
A1 T3 P1 D1, D2, D3
Figura 19 - Esempio di relazione in non-first-normal-form
A causa della presenza di più valori per gli attributi Autors e Descriptors questa
tabella viola la condizione 1NF del modello relazionale; per adattarla al modello
classico dovrebbe essere ristrutturata nel modo seguente:
BOOKS
BNO Title Price
1 T1 P1
2 T2 P2
3 T3 P1
AUTHORS
BNO Author
1 A1
1 A2
2 A2
3 A1
89

6 – Integrazione tra IR e database
DESCRIPTORS
BNO Descriptor
1 D1
1 D2
2 D1
2 D4
3 D1
3 D2
3 D3
Figura 20 - Normalizzazione di una relazione in non-first- normal-form
E’ indubbio che la prima soluzione sia quella di impatto più immediato in fatto di
chiarezza delle informazioni.
Schek e Pistor proposero anche una nuova definizione per alcuni degli operatori
standard dell’algebra relazionale, in modo da poter essere usati nel nuovo
modello; in particolare per l’operatore di selezione σ si potevano ora utilizzare
delle costanti che in realtà erano oggetti composti (ossia insiemi di termini),
mentre alle operazioni di confronto si aggiungevano quelle di appartenenza e
inclusione importate dalla teoria degli insiemi (⊂, ⊆, ⊇, ⊃, ∈).
Le operazioni di boolean retrieval potevano ora essere formulate mediante un
nuovo linguaggio SQL-NF 2 ; tornando all’esempio di fig. 19, una query per
cercare i titoli dei libri il cui descrittore contenesse i termini D1 e D2 sarebbe stata
del tipo
SELECT Title FROM Books WHERE descriptors ⊇ {D1, D2}
o, analogamente
90

6 – Integrazione tra IR e database
SELECT Title FROM Books WHERE D1 ∈ descriptors AND D2
∈ descriptors
Un esempio leggermente più complicato è quello seguente, in cui ad ogni libro
vengono associati gli index term con i relativi pesi associati:
BOOKS_WD
BNO Authors Title Price
1 A1, A2 T1 P1
2 A2 T2 P2
3 A1 T3 P1
91
WDesc
Descriptor WGT
D1
D2
D1
D4
D1
D2
D3
W1
W2
W3
W1
W3
W2
W4
Supponiamo ora di voler trovare tutti i titoli dei libri scritti dall’autore A1 in cui
l’index term D1 compare con peso maggiore o uguale a 0.5 :
SELECT Title FROM BOOKS_WD WHERE A1 ∈ Authors AND
(SELECT * FROM WDesc WHERE Descriptor=D1 AND WGT ≥ 0.5)
≠ {}
Gli operatori più interessanti dell’algebra sono probabilmente quelli chiamati
“NEST” e “UNNEST”, che vengono usati per trasformare una relazione 1NF in
una in NF 2 e viceversa. Per vedere come funzionano supponiamo di dover definire
una vista, partendo dalla tabella AUTHORS di Fig. 20, che contenga per ogni
libro la lista degli autori che lo hanno scritto:
DEFINE VIEW Authors_NF2 (bookno, authors) AS
SELECT BNO, NEST(Author) FROM AUTHORS

6 – Integrazione tra IR e database
Questo statement raggruppa il set degli autori che hanno in comune
l’identificativo del libro.
Supponiamo ora di voler eseguire l’operazione inversa, ossia mappare in 1NF una
tabella che è in NF 2 ; si può ottenere tale risultato mediante la seguente query:
DEFINE VIEW Authors_1NF (bookno, author) AS
SELECT BNO, UNNEST(authors) FROM Authors_NF2
Il modello NF 2 si integra molto bene con le applicazioni di IR poichè i documenti
possono essere rappresentati in una singola relazione annidata; inoltre il
linguaggio di interrogazione risulta essere molto potente e ricerche anche
complicate possono essere effettuate mediante un unico, semplice statement SQL-
NF 2 . Il problema principale risulta essere la costruzione e la gestione degli indici:
dato che i valori degli attributi possono essere non-atomici, anche le chiavi degli
indici avranno un dominio complesso (come vedremo più avanti, questo risulta
essere uno dei principali ambiti di studio nel campo dei database).
Un altro modello per la gestione di un testo strutturato che viene sovente citato in
letteratura è quello proposto da Clarke, Cormack e Burkowski. Nel loro modello è
prevista la gestione di documenti strutturati e la struttura viene descritta viene
descritta mediante l’uso di appositi tag che delimitano i vari elementi strutturali
del documento (un pò come avviene, ad esempio, per il linguaggio HTML). Gli
oggetti atomici, in questo modello, sono nuovamente i vari termini del
documento, a cui vengono però associati i tag che eventualmente si aprono e si
chiudono immediatamente prima o dopo il termine in questione. Tale modello
prevede poi una index function che associa ai vari termini (o, come vengono
chiamati dagli autori, simboli del text alphabet) la corrispondente posizione nel
database; una funzione analoga viene usata per mappare i vari tag (o simboli del
markup alphabet) nel database. L’aspetto interessante di questo modello sta
nell’uso dei tag per descrivere la struttura del documento e nel loro utilizzo nelle
primitive dell’algebra. Si tratta nuovamente di un modello concettuale: non viene
92

6 – Integrazione tra IR e database
spiegato come dovrebbe venire implementato e non viene fatto alcun riferimento
ad un’eventuale grammatica per un linguaggio di interrogazione simil-SQL; gli
autori si limitano a dire che il loro modello può coesistere con quello relazionale e
che le interrogazioni possono venire sottoposte tramite query SQL standard.
Un terzo modello che cerca di riempire il gap esistente tra i database ed i sistemi
di information retrieval è quello proposto da Fuhr. Quest’ultimo parte dalla
considerazione che la differenza fondamentale tra i due campi sta nel fatto che in
IR si ha a che fare con query vaghe e dati imprecisi ed incompleti, mentre
l’assunzione basilare nell’area dei DB è che le query sono precise ed i dati esatti, e
propone di combinare l’algebra relazionale con il probabilistic retrieval; il
risultato è quello che l’autore definisce come Probabilistic Relational Algebra
(PRA).
Data una relazione R, si introduce una funzione di probabilità ( r)
∈ [ 0,
1]
93
ς tale
che, se r ∈ dom(R), allora ς () r = P(
r ∈ R)
, cioè ς (r)
indica la probabilità che
R
la tupla r appartenga alla relazione R, ossia la probabilità dell’event expression r
∈ R. L’autore procede poi alla ridefinizione delle operazioni
dell’algebrarelazionale; tali operazioni vengono ridefinite basandosi su
combinazioni booleane delle event expression associate agli operatori (ossia alle
tuple coinvolte nell’operazione).
La probabilistic relational algebra rappresenta un’estensione del modello
relazionale in modo che questo possa trattare anche informazioni e predicati vaghi
o incerti; la base su cui opera è però sempre il modello relazionale che, come già
messo in evidenza precedentemente, risulta piuttosto inadatto se combinato con
un sistema di IR. L’autore propone quindi un’ulteriore evoluzione in cui associa i
concetti probabilistici con il modello NF 2 : nuovamente il concetto di base è
quello di associare ad ogni tupla una funzione di probabilità; vengono poi
nuovamente ridefiniti gli operatori dell’algebra relazionale. Si ottiene così un
modello probabilistico che fa uso di relazioni annidate (probabilistic non-firstnormal-form).
R
R

6 – Integrazione tra IR e database
Se mi è permesso muovere una critica a questo modello, come a tutti i modelli di
sistemi di IR di tipo probabilistico, vorrei dire che sono molto rigorosi e precisi,
ma partono sempre dal presupposto che siano note le probabilità associate ai vari
eventi elementari: nessuno dà una spiegazione esauriente e definitiva riguardo a
come dovrebbero venire effettivamente calcolate queste probabilità.
Dopo aver fatto una breve panoramica su alcuni modelli concettuali che integrano
IR e database relazionali, passiamo ad analizzare alcune soluzioni implementate
mediante prototipi oppure nei database commerciali. Gli approcci che vengono
seguiti sono principalmente tre:
combinare i sistemi di IR e RDBMS esistenti: i dati strutturati vengono
salvati nel database relazionale, mentre quelli non strutturati vengono
mantenuti nel sistema di IR; bisogna poi creare un’interfaccia in grado di
estrarre dalle query le richieste di dati per ogni sottosistema, indirizzarle e
combinare poi le risposte provenienti dalle singole parti
modificare un sistema di IR in modo che sia in grado di gestire query
relazionali, oppure estendere un RDBMS in modo che possa trattare query
su oggetti di tipo testuale. Il secondo è l’approccio seguito nei database
relazionali presenti in commercio: vengono aggiunte delle estensioni al
linguaggio SQL in modo da poter gestire dati strutturati predefiniti o anche
definiti ex-novo dall’utente. Tutto questo non viene realizzato
specificatamente per le applicazioni di information retrieval, ma queste
possono trarre un indubbio vantaggio dalle evoluzioni introdotte nei
sistemi in commercio
implementare un IR system come applicazione di un database relazionale:
la soluzione più gettonata è quella di rappresentare l’inverted index
associato ad una collezione di documenti mediante un set di tabelle.
94

6 – Integrazione tra IR e database
6.1 Integrazione di sistemi esistenti
Questa soluzione consiste nel memorizzare la parte strutturata dei dati in un
DBMS commerciale e quella non strutturata in un sistema di IR preesistente o
realizzato ad-hoc. Bisogna prevedere un’interfaccia che:
1. effettui il parsing dell’interrogazione sottoposta al sistema in un qualche
linguaggio specifico
2. la divida in due parti, una strutturata e una non
3. traduca ognuna delle due parti (tipicamente in una query SQL ed in una
query booleana)
4. invii ognuna delle due parti al sottosistema opportuno
5. esegua un merge dei due risultati parziali restituiti dai sottosistemi.
Il vantaggio sta nel fatto che si sfrutta il lavoro che è stato già fatto nei due singoli
campi; i problemi sono legati soprattutto alla comunicazione tra i due
sottosistemi: ad esempio potrebbe avvenire un update nel sistema di IR mentre la
corrispondente operazione nel DBMS è stata interrotta e ha subito un rollback.
Inoltre l’ottimizzazione delle query non è molto agevole in quanto l’ottimizzatore
del DBMS ha solo delle informazioni parziali sulla richiesta sottoposta al sistema
e può solo lavorare sulla propria parte di query.
Un esempio di questo tipo di implementazione è costituita dal progetto CORDIS
(Community Research and Development Information Service; si tratta del servizio
comunitario di informazione in materia di ricerca e sviluppo fornito dalla
commissione europea: www.cordis.lu).
95

6 – Integrazione tra IR e database
Figura 21 - Architettura di sistema di CORDIS
Il sistema è diviso in una parte definita host (un database relazionale Sybase) ed
una parte subordinata (costituita da una serie di inverted file), integrate in modo
da formare un IR database. Le ricerche e le valutazioni sui dati testuali vengono
effettuate utilizzando un sistema basato sul modello INQUERY; quest’ultimo è un
sistema di information retrieval che fa uso di reti di inferenza di tipo bayesiano
per valutare la rispondenza di un certo set di informazioni ad una determinata
richiesta.
Figura 22 - Collegamento tra i due sottosistemi di CORDIS
I dati strutturati sono memorizzati in un RDBMS Sybase, il collegamento con le
parti testuali viene mantenuto mediante puntatori ai corrispondenti blocchi di testo
negli INQUERY DB.
96

6 – Integrazione tra IR e database
Per integrare le possibilità di interrogazione di un RDBMS e di INQUERY è stata
definita un’estensione del linguaggio SQL chiamata E-SQL; in tale linguaggio
vengono integrate le funzionalità di INQUERY nell’SQL standard.
Un esempio di query E-SQL potrebbe essere il seguente:
SELECT * FROM publications WHERE
probability_rate(“information retieval”, publications)
> 0.5
AND publication.project_acronym=”ESPRIT 2”
Questa query restituirà tutte le informazioni riguardo le pubblicazioni relative al
progetto ESPRIT 2 che risultano rilevanti rispetto alle keyword “information
retrieval” con un indice di rilevanza superiore a 0.5. La parte relativa al calcolo di
probability_rate viene inviata al sottosistema INQUERY, che restituirà
come risultato una tabella temporanea in Sybase ordinata per valore di rilevanza;
in particolare la tabella temporanea conterrà una chiave esterna verso i record
relativi alle pubblicazioni. A questo punto verrà costruita una nuova query Sybase
del tipo
SELECT publication.*
FROM publication, publication_INQUERY
WHERE publication.project_acronym=”ESPRIT 2”
AND publication.code=publication_INQUERY.code
6.2 Estensione di RDBMS con aggiunta di funzioni di
IR
Le applicazioni di information retrieval hanno tratto un indubbio vantaggio dalle
ultime evoluzioni della tecnologia nel campo dei database; infatti le ultime
generazioni di RDBMS permettono una gestione intelligente di dati complessi,
intendendo per dati complessi testi, immagini, video ed ogni tipo di dati user-
97

6 – Integrazione tra IR e database
defined. Queste nuove piattaforme vengono sovente indicate come object
relational DBMS.
La possibilità di definire dei nuovi data type, sia che si tratti di dati molto
semplici, sia che questi nascondano strutture interne ed attributi anche complessi,
presuppone però tutta una serie di caratteristiche molto importanti che i DBMS
devono garantire: una volta che si hanno dei nuovi tipi di dati bisogna anche
riuscire a manipolarli e ad effettuare ricerche su di essi in maniera efficiente; ecco
allora che un object relational DBMS deve necessariamente garantire:
la possibilità di definire delle funzioni da parte dell’utente (User Defined
Functions, UDF) mediante le quali le applicazioni possono creare,
manipolare e ricercare i nuovi data type
la possibilità di definire delle index structure che permettano di accedere
in maniera efficiente a dati complessi quali testi, immagini o altro, in
quanto i metodi di indirizzamento standard dei RDBMS risultano
inadeguati per queste tipologie di dati
un ottimizzatore in grado di valutare il costo delle funzioni utente e
l’efficacia delle index structure per determinare l’execution plan ottimale
per le query.
Queste sono le tre caratteristiche che vengono da tutti riconosciute indispensabili
per un object relational DBMS, altre sono l’abilità di accedere a tutti i tipi di dati e
di funzioni con una singola query e di non interferire con le funzionalità esistenti
del RDBMS.
Alcuni database, oltre a permettere agli sviluppatori di definire degli user defined
type “well suited” per le loro applicazioni, forniscono già delle architetture e
delle API in forma di plug-in per l’integrazione di dati testuali e content
management. E’ il caso ad esempio del DB2 Universal Database dell’IBM: questo
prodotto mette a disposizione una serie di moduli chiamati DB2 Relational
Extenders che forniscono una serie di abstract data type predefiniti per la gestione
di testi, immagini e video. In particolare il DB2 Text Extender permette di
definire una serie di indici full text e fornisce una vasta gamma di funzioni di
98

6 – Integrazione tra IR e database
ricerca sul testo (prossimità, wild cards, ecc.) oltre alla possibilità di ordinare i
documenti in base alla loro rilevanza rispetto ai criteri di ricerca impostati.
Un altro database commerciale che offre delle funzionalità fortemente orientate
verso un sistema di information retrieval è l’Universal Server di Informix (siamo
sempre comunque nell’orbita IBM), la cui architettura è espandibile con dei plugin
chiamati DataBlade.
Figura 23 - Architettura Informix Universal Server
Un modulo DataBlade è un componente che indica al server come gestire nuovi
data type, nuove funzioni e nuove index structure per migliorare l’accesso ai dati
complessi; anche qui è presente un modulo pensato specificatamente per la
gestione di dati testuali: contiene una serie di data type definiti ad hoc, funzioni di
ricerca basate su concetti di prossimità e rilevanza, la possibilità di gestire un
inverted index sul testo.
Un discorso simile può essere fatto anche per l’ Universal Server di Oracle: qui i
plug-in vengono chiamati Data Cartridge e il modulo dedicato alla gestione dei
dati testuali è il ConText Cartridge che, come i precedenti, fornisce una serie di
funzioni di text analysis e retrieval technology.
99

6 – Integrazione tra IR e database
Questo trend si ritrova anche nelle ultime evoluzioni dello standard SQL, vale a
dire il progetto SQL/MM (SQL multimedia and application package), da cui è
derivato l’ultimo SQL3. Lo standard SQL3 specifica le estensioni del linguaggio
per definire degli user data type complessi; il progetto SQL/MM in particolare
cerca di standardizzare la definizione di ADT (abstract data type) di tipo testuale,
oltre alla loro interfaccia funzionale, ossia alle proprietà ed ai metodi loro
associati.
Ad esempio viene introdotto l’ADT FullText, oltre ad un certo numero di funzioni
operanti su di esso; una volta definito questo nuovo data type, l’utente può creare
delle tabelle facendovi riferimento come se fosse uno dei tipi standard di dati
dell’SQL:
CREATE TABLE projects(
project_no integer,
title varchar(50),
budget integer,
description FullText)
Inoltre la specifica SQL/MM definisce una serie di funzioni operanti con dati di
tipo FullText: ad esempio la funzione contains, che viene usata per effettuare
ricerche testuali su colonne del suddetto tipo:
SELECT proj_no, title FROM projects
WHERE contains(description, ‘“database” IN SAME
SENTENCE AS “object relational”’)
La query precedente restituirà tutti i progetti a cui è associata una descrizione
testuale contenente i termini “database” e “object relational” nella medesima
frase.
Il DB2 Text Extender di cui abbiamo parlato in precedenza supporta alcune delle
caratteristiche introdotte dallo standard SQL3 che permettono di integrare ricerche
testuali all’interno di statement SQL.
Supponiamo di avere la seguente tabella:
100

6 – Integrazione tra IR e database
CREATE TABLE projects(
project_no integer,
title varchar(50),
budget integer,
description_id db2text)
(dove il tipo db2texth è un tipo predefinito di Text Extender che serve per
identificare in maniera univoca i vari documenti della collezione in esame) e
riprendiamo in esame la query introdotta precedentemente, che risulta ora
leggermente modificata poichè la tabella contiene un riferimento al testo, anzichè
il testo vero e proprio; la query sarà:
SELECT proj_no, title FROM projects
WHERE contains (description_id, ‘”database” IN SAME
SENTENCE AS “object relational”’)
La figura seguente mostra l’architettura del modulo Text Extender per quel che
riguarda l’interazione del motore di database con il motore di ricerca del testo:
Figura 24 - Integrazione tra DB2 Engine e Text Search Engine
Per ogni riga della tabella projects il motore DB2 richiama la funzione contains
passandole come parametri l’identificatore della colonna contenente i riferimenti
ai documenti ed il pattern da ricercare; in pratica la ricerca all’interno dei dati
testuali viene eseguita soltanto una volta, durante la prima chiamata della
101

6 – Integrazione tra IR e database
funzione. Il motore di ricerca nel database testuale genera una lista di
identificatori di documenti, l’UDF (user defined function) controlla se
l’identificatore passatole dal motore del database è presente in tale lista e
restituisce a questo il risultato opportuno (true o false). Basandosi sui risultati
delle chiamate alla funzione, il DB engine costruisce quindi il set risultato della
query. Questo modo di procedere ha però il grosso difetto che, comunque, bisogna
effettuare una scansione completa sulla tabella dei progetti: sarebbe auspicabile
invece che il set di identificatori recuperati dal text search engine diventasse una
sorta di index lookup, in modo da evitare la scansione completa della tabella. Per
fare questo bisogna definire una nuova UDF containing che, anzichè restituire un
valore booleano, restituisca una tabella:
CREATE FUNCTION containing(
schema VARCHAR(10)
table VARCHAR(10)
column VARCHAR(10)
searcharg LONG VARCHAR)
RETURNS TABLE (resultid db2texth)
Il risultato della chiamata della funzione sarà, come già detto, una tabella
contenente i documenti per cui si ha un match con le condizioni di ricerca; la
nuova query sarà quindi:
SELECT proj_no, title FROM projects
WHERE description_id IN
(SELECT resultid FROM
TABLE(containing(‘COMPSCHEMA’,’PROJECTS’,’DESCRIPTION_I
D’,‘”database” IN SAME SENTENCE AS “object
relational’))
AS restab(resultid))
Questa query produce il medesimo risultato di quella in cui si faceva uso
dell’UDF contains, con la differenza che in questo secondo caso la funzione
containing produce un set di identificatori che può essere usato come una qualsiasi
tabella del database.
102

6 – Integrazione tra IR e database
Una forma alternativa per l’uso della funzione containing è quella usata nella
seguente query, che utilizza un join anzichè una subquery:
SELECT proj_no, title
FROM
projects,TABLE(containing(‘COMPSCHEMA’,’PROJECTS’,’DESC
RIPTION_ID,‘”database” IN SAME SENTENCE AS “object
relational”’)) AS restab(resultid)
Il vantaggio significativo nell’uso di una funzione di tipo “tabella” quale la
funzione containing sta nel fatto che gli identificatori che questa restituisce
possono venire utilizzati dal motore del database per localizzare le tuple nella
tabella dei progetti; gli indici del text engine vengono ora realmente sfruttati
anche dal motore di database (ovviamente bisognerà definire un indice sulla
colonna description_id al fine di permettere un lookup veloce): si ha quindi
un’integrazione completa tra il DB engine ed il text search engine. E’ anche
possibile istruire l’ottimizzatore del DBMS in modo che sostituisca, dove
possibile, una funzione scalare con una equivalente che restituisca invece un set di
record.
6.3 Implementazione di un IRS come applicazione di
un RDBMS
Per poter effettuare delle ricerche full-text in un database relazionale in modo
efficiente bisogna utilizzare una opportuna struttura di accesso ai dati. La struttura
più comune è quella che fa uso di un inverted index: vedremo ora come
quest’ultimo possa essere mappato in un database relazionale e come utilizzarlo
per effettuare alcune operazioni di text retrieval. Di seguito presentiamo quale
potrebbe essere lo schema logico di massima di un database in cui implementare
un simile sistema :
103

6 – Integrazione tra IR e database
DOC (doc_id, doc_name, date)
DOC_TERM (doc_id, term, tf)
DOC_TERM_PROX (doc_id, term, offset)
IDF (term, idf)
QUERY (term, tf)
STOP_TERMS (term)
La tabella DOC contiene le informazioni strutturate riguardanti i documenti della
collezione, DOC_TERMS invece viene usata per modellare l’inverted index: le
tuple con lo stesso valore dell’attributo term corrispondono alla posting list
dell’index term contenuto in tale attributo; la tabella QUERY, infine, contiene i
termini presenti nella richiesta che viene sottomessa al sistema. Quelle appena
viste sono le tabelle principali per realizzare il sistema, altre tabelle meno
importanti sono DOC_TERM_PROX che è usata per ricerche di prossimità e IDF
che contiene un peso assegnato ad ogni termine usato come index term (il peso
usato, come suggerisce il nome, è l’Inverted Document Frequency, di cui si è già
parlato). La tabella STOP_TERMS, infine, contiene i termini che compaiono
troppo frequentemente nel testo e può essere usata in fase di preprocessing per
eliminare questi ultimi dalle tabella DOC_TERM e DOC_TERM_PROX.
E’ importante l’uso della tabella QUERY per contenere i termini presenti nella
richiesta sottomessa al sistema; se non ci fosse, per implementare l’AND di n
termini input_term_1, input_term_2, ..., input_term_n sarebbe necessaria una
query come la seguente:
SELECT d.doc_id FROM DOC_TERM WHERE term=input_term_1
INTERSECT
SELECT d.doc_id FROM DOC_TERM WHERE term=input_term_2
INTERSECT
....
SELECT d.doc_id FROM DOC_TERM WHERE term=input_term_N
Il problema di un tale statement è che la lunghezza della query cresce con il
numero di termini da ricercare: alcuni sistemi in commercio limitano la lunghezza
sintattica della query e quindi ne precluderebbero l’uso; si avrebbero inoltre dei
104

6 – Integrazione tra IR e database
problemi nel caso in cui le parole da ricercare fossero molto frequenti nel testo e
quindi poco selettive: il tempo necessario per l’intersezione dei set restituiti dalle
subquery potrebbe risultare molto alto, per cui il sistema avrebbe delle
performance non accettabili.
Utilizzando invece una tabella in cui si ha una tupla per ogni termine presente nel
pattern da ricercare, si ottengono delle query la cui lunghezza sintattica è costante
(in letteratura si parla di unchanged SQL); la seguente query, ad esempio, realizza
una ricerca booleana con un AND di una serie di termini (che si suppone siano
stati caricati nella tabella QUERY):
SELECT d.doc_id FROM DOC_TERM d, QUERY q
WHERE d.term=q.term
GROUP BY d.doc_id
HAVING COUNT(d.term)=(SELECT COUNT(*) FROM QUERY)
La condizione WHERE elimina tutti i termini di DOC_TERM che non sono
presenti in QUERY; per un documento di che contiene k termini (t1, t2, ...,tk) tra
quelli presenti in QUERY, nel set risultante saranno presenti le seguenti tuple:
doc_id term
di
di
105
t1
t2
... ...
di
Il GROUP BY partiziona il risultato in una serie di subset e la clausola HAVING
elimina tutti i gruppi con una cardinalità diversa da quella di QUERY (= gruppi
che non contengono tutti i termini presenti in QUERY). Affinchè il tutto funzioni
bisogna ovviamente imporre che la tabella QUERY non contenga duplicati e che
DOC_TERM non abbia termini duplicati per il medesimo documento .
tk

6 – Integrazione tra IR e database
Una richiesta in cui fosse presente un OR di una serie di termini può venire
mappata eliminando la clausola HAVING dalla query precedente, mentre per un
TAND (ossia un threshold AND, che restituisce i documenti contenenti almeno k
dei termini specificati) la query è la seguente:
SELECT d.doc_id FROM DOC_TERM d, QUERY q
WHERE d.term=q.term
GROUP BY d.doc_id HAVING COUNT(d.term) ≥ k
Molti sistemi di IR forniscono la possibilità di eseguire delle ricerche basate su
prossimità (proximity search); una proximity search restituisce tutti i documenti
che contengono n termini specificati in una term window di dimensione width.
Nel modello che abbiamo preso come esempio, per implementare delle proximity
search si utilizza la relazione DOC_TERM_PROX che contiene, tra l’altro,
l’offset di ogni index term rispetto all’inizio del documento in cui è presente:
SELECT a.doc_id FROM DOC_TERM_PROX a, DOC_TERM_PROX b
WHERE a.term IN (SELECT q.term FROM QUERY q) AND
b.term IN (SELECT q.term FROM QUERY q) AND
a.doc_id=b.doc_id AND
(b.offset-a.offset) BETWEEN 0 AND (width-1)
GROUP BY a.doc_id, a.term
HAVING COUNT(b.term)=(SELECT COUNT(*) FROM QUERY)
Finora abbiamo visto delle query che realizzavano delle ricerche di tipo booleano;
supponiamo avere implementato un modello vector space e di voler effettuare un
relevance ranking dei documenti: la query che utilizziamo deve fare riferimento
anche alla tabella IDF, che contiene il valore dell’inverse document frequency per
ogni index term:
SELECT d.doc_id, SUM((q.tf*i.idf)*(d.tf*i.idf))
FROM QUERY q, DOC_TERM d, IDF i
WHERE q.term=i.term AND d.term=i.term
GROUP BY d.doc_id
ORDER BY 2 DESC
106

6 – Integrazione tra IR e database
Ricordiamo che nel modello vector space ogni documento o query viene
rappresentato mediante un vettore contenente un peso per ogni index term
presente nella collezione (ovviamente i termini che non sono presenti nel
documento vengono rappresentati con peso 0). Uno dei metodi per effettuare un
relevance ranking consiste nel calcolare la distanza cartesiana tra il vettore della
query e quello di ogni documento. La query precedente calcola il prodotto scalare
tra i vettori e ordina il set risultante in base a tale valore; si potrebbe però ordinare
in base ad altre funzioni, come ad esempio il coefficiente di Dice o quello di
Jaccard, entrambi già introdotti.
Le implementazioni di questo tipo di sistema hanno dimostrato che le prestazioni
sono influenzate pesantemente dalla selettività dei termini presenti nella query;
nel caso tali termini siano sufficientemente selettivi si ottengono prestazioni
equiparabili a quelle di sistemi di IR realizzati ad-hoc.
Molti DB, oltre ai tipi di dati di base, permettono di memorizzare degli oggetti
non strutturati chiamati BLOB (Binary Large OBject); una soluzione alternativa
per implementare un inverted index mediante un database relazionale consiste nel
memorizzare le posting list associate ai vari index term come oggetti BLOB. In
pratica ogni BLOB viene visto come una bitlist in cui il bit i-esimo è settato se il
documento i-esimo della collezione contiene l’index term in questione.
L’inverted index verrà mappato mediante una tabella simile a quella che segue:
INDEX TERM POSTING LIST
INFORMATION 0001001...
RETRIEVAL 0011000...
SYSTEM 1000001...
.... ....
Un’ulteriore soluzione è quella proposta da Putz: nel suo modello l’inverted index
viene implementato in maniera analoga alla precedente, ossia mediante una tabella
che associa ad ogni index term la corrispondente posting list. Quest’ultima viene
107

6 – Integrazione tra IR e database
però implementata utilizzando dei campi di lunghezza fissa (nell’esempio
presentato si utilizza un campo VARCHAR(255) su un database Sybase) anzichè
lasciare la possibilità di avere campi di lunghezza arbitraria. Per ogni documento
contenente l’index term viene riservata una certa “fetta” della posting list in cui
memorizzare il proprio identificativo, più altri dati come ad esempio la frequenza
del termine al proprio interno o l’offset di quest’ultimo rispetto all’inizio del testo.
Man mano che si inseriscono nuove informazioni in una posting list, questa può
diventare troppo lunga per essere contenuta in un singolo blocco: tale lista viene
allora spezzata e vengono aggiunti nuovi record nel database. Poichè la maggior
parte degli index term generalmente hanno una bassa frequenza nel testo, le
posting list risultano essere in media relativamente corte e possono quindi essere
contenute in una singola tupla; operativamente si è visto che circa il 5% dei
termini richiedeva più righe per memorizzare la corrispondente posting list.
Ovviamente questa soluzione richiede un’ulteriore fase di decodifica dei dati
restituiti dalle query di ricerca in quanto, come detto, le informazioni presenti
nelle posting list vengono codificate per ridurre l’occupazione di memoria.
108

Capitolo 7
Parallel information retrieval system
Le applicazioni di document retrieval si prestano molto bene ad essere eseguite in
un ambiente parallelo; ad esempio è possibile dividere la collezione in esame in
una serie di porzioni che vengono esaminate indipendentemente in fase di ricerca,
salvo provvedere poi ad un merge dei risultati parziali così ottenuti. In teoria, se si
ottengono N sub-collezioni che vengono esaminate in contemporanea da N
“lettori” diversi, la ricerca dovrebbe essere N volte più veloce rispetto ad un
sistema di un solo processore. In realtà non è così perchè entrano in gioco una
serie di fattori che rallentano le prestazioni di un tale sistema ideale:
INTERFERENZA: rallentamento imposto da un processo a tutti gli altri
durante l’accesso ad eventuali risorse condivise
SBILANCIAMENTO DEL CARICO (data skewness): la durata
complessiva di un lavoro suddiviso in passi eseguibili in parallelo è
vincolata alla durata del passo più lento
Bisogna poi tenere in considerazione la legge di Amdahl secondo cui lo speedup
S(n), ossia il rapporto tra il tempo di esecuzione di un medesimo test in una
macchina parallela con parallelismo n e su una macchina sequenziale, è dato da
n
S(
n)
=
1+
( n −1)
* f
dove f indica la frazione di istruzioni ad operazioni non parallelizzabili. Nel caso
di un sistema con m=80 processori e circa il 20% delle operazioni che devono
essere forzatamente essere eseguite in maniera sequenziale, si ottiene un valore di
speedup che indica come il sistema parallelo arrivi ad essere solo circa 5 volte più
veloce di quello sequenziale.
109

7 – Parallel information retrieval system
Un altro concetto che è opportuno introdurre perchè verrà ripreso più volte è
quello logato alla differenza da sistemi di tipo MIMD e di tipo SIMD
(classificazione di Flynn). Una macchina di tipo SIMD (Single Instruction stream,
Multiple Data stream) consiste in un master controller ed una serie di processori
slave; il master controller invia in broadcast un’istruzione a tutti gli slave in modo
che questi possano eseguirla simultaneamente. Questo tipo di soluzione è adatta
quando tutti i processori devono eseguire le medesime istruzioni su dati differenti.
Una macchina di tipo MIMD (Multiple Instruction stream, Multiple Data stream)
invece è costituita da più processori che possono anche eseguire programmi
indipendenti; i vari processori comunicano sia attraverso una memoria condivisa,
sia tramite il passaggio di messaggi. I sistemi di information retrieval vengono
prevalentemente implementati su architetture di tipo MIMD perchè generalmente i
vari nodi devono compiere operazioni diverse.
Il primo esempio di sistema parallelo analizzato è quello costutuito dal progetto
PADRE (PArallel Document Retrieval Engine), proposto da Hawking. Partendo
da due assunzioni di base, ossia:
1. una macchina parallela con un alto grado di parallelismo può operare
sufficientemente veloce in full text scanning in modo da rendere non
necessario l’uso di indici sul testo
2. una buona percentuale delle collezioni tra quelle disponibili in formato
elettronico hanno dimensioni tale da poter essere contenute nella memoria
RAM di un discreto numero di calcolatori paralleli
l’autore ha sviluppato un motore di ricerca su un sistema parallelo basato su
metodi di full text scanning e in cui i documenti sono tutti contenuti nella RAM
del sistema.
Si utilizza un calcolatore Fujitsu AP1000, una macchina parallela a memoria
distribuita con 1024 processori SPARC (chiamati celle), interconnessi mediante
una rete broadcast a 50 Mbyte/sec; ogni cella è equipaggiata con 16 Mbyte di
RAM, quindi il sistema ha una configurazione massima di 16 Gigabyte. Tutto
l’I/O è controllato da una stazione front-end della SUN che viene chiamata host.
110

7 – Parallel information retrieval system
PADRE consiste di un “programma host” che viene replicato su ognuna delle
celle dell’ AP1000; i programmi cella accettano dati e comandi dall’host,
eseguono le operazioni sulle porzioni di dati che hanno in memoria, infine
trasmettono i propri risultati parziali all’ host.
Non viene fatto alcun riferimento all’algoritmo seguito per effettuare il ranking
dei documenti; a tal proposito occorre dire che da più parti in letteratura si pone
l’accento sul fatto che i sistemi paralleli vengono utilizzati dove i requisiti di
efficiency sono molto rigidi (detto in altre parole: dove si vogliono tempi di
risposta molto bassi), mentre si può accettare di avere un’effectiveness non
ottimale.
Come già accennato in precedenza, si cerca di avere un load balancing del
sistema: il tempo che occorre per effettuare un full-text scanning nel sistema in
esame coincide con il tempo impiegato dalla cella più lenta per esaminare la
propria porzione di dati, e la cella più lenta sarà quella con la maggior quantità di
teste da controllare. Il sistema prevede quindi una fase di load balancing in cui le
varie celle comunicano a tutte le altre le dimensioni del proprio chunk di dati in
modo che ognuna possa costruirsi una tabella contenente le dimensioni di tutte le
porzioni di testo; tale tabella è ordinata per dimensione del chunk e la prima cella
viene associata all’ultima, la seconda alla penultima, e così via. A questo punto le
celle di ogni coppia negoziano sui documenti che eventualmente possono
scambiarsi in modo da avere ognuna una quantità il più possibile simile di testo.
La condizioni che un documento non possa venire suddiviso tra due celle fa sì che
sia praticamente impossibile raggiungere un load balancing perfetto.
Passiamo ora ad analizzare il progetto PFIRE (Parallel Full Information Retrieval
Engine) sviluppato presso il Computer Technology Institute di Patrasso. Si tratta
di un sistema basato sul vector space model ed implementato su un calcolatore
Parsytec GCe13/512; si tratta di una macchina parallela di tipo MIMD costituita
da 512 processori RISC a 30MHz, ognuno con una memoria locale di 4 MByte. I
processori sono organizzati fisicamente in una rete interconnessa di dimensione
32*16 (la terminologia adatta è 2D-mesh structured network), però è possibile
111

7 – Parallel information retrieval system
creare dei link virtuali tra i vari nodi della rete in modo da organizzare i processori
in una struttura ad albero; una tale struttura è molto diffusa nei sistemi paralleli,
poichè permette di parallelizzare in maniera efficiente la fase di calcolo e di
mantenere basso il totale dei tempi di comunicazione poichè questi ventono
distribuiti sui vari livelli dell’albero.
L’algoritmo utilizzato per la ricerca si basa sulle seguenti assunzioni:
1. ogni documento è rappresentato da un vettore di termini (Di); le query
dell’utente sono rappresentate da un vettore di temini (qi) dello stesso tipo
2. il retrieval task consiste nelle operazioni classiche di calcolo della
similarità e ordinamento dei documenti in base a questa. La similarità
viene valutata calcolando il prodotto scalare tra il vettore della query e
quelli dei documenti
3. uno dei processori (Ph) costituisce l’host processor, mentre P processori
(Pi, i=1, ..., P) costituiscono i working processor; tra i working processor
ce n’è uno particolare (Pir) che costituisce la radice dell’albero
4. tutti i processori accedono ad uno spazio comune su disco contenente tutti
i vettori dei documenti (D= numero totale di vettori)
L’host processor ed i working processor eseguono algoritmi diversi:
Host processor Ph
1: Formula il query vector qi
2: Invia qi al nodo radice Pir
3: Attendi di ricevere il ranked set finale da Pir in
RDh
4: Presenta gli X documenti più rilevanti all’utente
Working processor Pi, i=1,..., P=2 h -1
(dove h=numero di livelli dell’albero di processori)
1: IF (NOT(nodo radice)) THEN
Ricevi il query vector qi dal nodo padre
2: IF (NOT(nodo foglia)) THEN
112

7 – Parallel information retrieval system
Invia il query vector qi ai nodi figli
3: Calcola il prodotto scalare tra qi ed i D/P
document vector che gestisci
4: Ordina il risultato nel set RDi (considerando solo
gli X documenti più rilevanti)
5: IF (NOT(nodo foglia)) THEN
5.1: Ricevi i set RD da ognuno dei nodi figli
5.2: Esegui il merge dei set ricevuti nel set RDi
locale(mantenendo solo gli X documenti più
rilevanti)
6: IF (NOT(nodo radice)) THEN
Invia il set RDi locale al nodo padre
ELSE
Invia il set RDi locale all’host processor
Ogni node processor invia il vettore della query qi ai propri figli, fichè qi non
arriva ai processori foglia; a questo punto i processori foglia calcolano la
similarità tra qi ed i propri D/P vettori di documenti e generano una tabella RD
con il risultato parziale. A questo punto si esegue progressivamente il merge dei
risultati attraverso i vari livelli dell’albero: ogni node processor riceve i set RD
dai propri nodi figli e li fonde nel proprio set RD che viene trasmesso al modo
padre; si ripete questo passo per ogni livello fino a che non si raggiunge il nodo
radice in cui verrà costruito il ranking set definitivo.
Figura 25 - Esecuzione dell'algoritmo lungo i nodi dell'albero
Vediamo ora il progetto PANDORA (PArallel DOcumentation Retrieval
Architecture) proposto da Kopesky; il prototipo è stato implementato su un
calcolatore parallelo CRAY T3D, un sistema MIMD con 2048 processori; si è
lavorato sulla gestione parallela dell’inverted index di una collezione.
113

7 – Parallel information retrieval system
Figura 26 - Architettura del sistema PANDORA
Molto brevemente, i processori sono stati suddivisi un tre classi: query node, index
node e score node.
QUERY NODE: sono i nodi responsabili dell’interazione con l’utente,
nel senso che comunicano con l’interfaccia utente, ricevono un input le
query di ricerca e comunicano i ranked set ottenuti dall’elaborazione.
Oltre a questo trasmettono agli index node gli index term della query
per cui i vari index node sono responsabili (più altre informazioni che
potrebbero essere loro utili, come ad esempio i pesi assegnati ai vary
query term)
114

7 – Parallel information retrieval system
INDEX NODE: ogni index node è responsabile di una porzione
dell’inverted index; accetta dai query node una lista di keyword
appartenenti alla propria porzione, accede all’inverted index e
restituisce le informazioni contenute nelle posting list allo score node
responsabile di ogni documento della posting list
SCORE NODE: ogni score node è responsabile per uno specifico set
di documenti; riceve in input dagli index node le informazioni
contenute nelle posting list ed esegue l’ordinamento del subset di
documenti su cui ha visibilità. Gli score node, infine, cooperano con i
query node per effettuare il merge dei risultati parziali ottenuti in modo
da avere un ranking sull’intera collezione.
L’ultimo sistema che citiamo è quello proposto da Pamegopoulos e Faloutsos per
implementare un bit-sliced sigmature file su una macchina parallela di tipo SIMD;
nel loro studio si ipotizza che il sistema non abbia memoria sufficiente per
mantenere tutte le bit slice e si propone come soluzione un algoritmo di swapping
chiamato partial fetch. Purtroppo anche in questo caso non viene fatto alcun
cenno all’algoritmo di ricerca vero e proprio; dalle varia bibliografie che abbiamo
esaminato pare che una delle massime autorità in questo campo sia Craig Stanfill
della Thinking Machines Corporation, purtroppo però non è stato possibile
recuperare nessuno dei suoi articoli.
115

Capitolo 8
Information retrieval e Web
Con l’enorme crescita di internet, sempre più informazioni sono disponibili sul
web: la ricerca di informazioni è una delle attività più comuni tra gli utenti della
rete, ma anche una delle più frustranti.
Le tecniche di ricerca tradizionali, basate sulla ricerca full text delle keyword
richieste all’interno delle pagine web, solitamente restituiscono troppi documenti,
di questi solo una piccola parte risulta essere rilevante per le necessità dell’utente
e spesso i documenti rilevanti non compaiono in cima alla lista presentata.
Gli algoritmi di retrieval e di ranking tradizionali, infatti, sono stati sviluppati per
collezioni isolate (e il più delle volte statiche) e non è detto che siano adatti alle
applicazioni su internet.
Due delle maggiori differenze tra i metodi di retrieval classici e quelli basati sul
web sono il numero di utenti che possono accedere simultaneamente agli
strumenti di ricerca ed il numero di documenti a cui si deve poter accedere;
entrambi infatti superano di diversi ordini di grandezza i valori associati alle
applicazioni di IR tradizionali, ed entrambi crescono a ritmi impressionanti.
Inoltre i sistemi di web information retrieval lavorano con dati completamente
diversi da quelli delle collezioni tradizionali; le differenze possono essere
riassunte nei seguenti punti:
dimensione: secondo stime il numero di pagine sul web ad Aprile del 2001
si aggirava sui 4 miliardi; di queste i motori di ricerca ne coprono circa il
15% (Google, ad esempio costruisce i propri indici in 560 milioni di
pagine)
cescita continua: come già detto, il numero di pagine e documenti
disponibili in rete cresce continuamente, mentre i metodi di IR tradizionali
erano rivolti a collezioni statiche
116

8 – Information retrieval e Web
eterogeneità: il web contiene una grande varietà di tipi di dati, documenti
testuali, immagini, audio, video, ecc...
varietà di linguaggi: più di 100 linguaggi usati
dati duplicati: si stima che circa il 30% delle pagine web siano duplicate
documenti collegati tra loro: ogni documento ha in media 8 link verso altre
pagine
Altre particolarità importanti dei sistemi di web information retrieval che devono
essere tenute in considerazione sono:
formato delle query: da uno studio esegiuto da Jamsen e Pooch sui log di
alcuni tra i motori di ricerca più importanti si è visto che le query
sottoposte sono generalmente molto brevi (più del 50% delle query sono
sostituite da uno o due termini nel caso di Altavista)
comportamenti particolari: si stima che quasi l’85% degli utenti controlli
soltanto la prima schermata degli elenchi restituiti dai motori di ricerca; il
78% invece non esegue una seconda ricerca modificando la prima query
dopo aver verificato il set restituito
Sono state proposte diverse misure per valutare i sistemi di information retrieval
classici, molte delle quali possono essere estere anche ai web search engine; gli
utenti del web però tendono a dare molta importanza ad alcune caratteristiche che
non erano di primissimo piano nei sistemi tradizionali: l’aspetto più importante è
un response time basso, seguito dall’abilità di presentare il maggior numero di siti
altamente rilevanti nella prima videata dell’elenco, in modo da non doversi
muovere tra le pagine per trovare il risultato cercato.
Faremo ora un rapido accenno ad alcune tra le tecniche di web searcing che sono
state proposte e vedremo poi come vengono applicate in pratica in uno dei motori
di ricerca disponibili in rete.
117

8.1 Indexing
8 – Information retrieval e Web
Qui per indexing si intende il provesso di costruzione di una struttura dati che
permetta di velocizzare la ricerca dei dati richiesti dall’utente.
I servizi di web searching che vengono messi a disposizione degli utenti della rete
si dividono in due grandi categorie:
1. i motori di ricerca propriamente detti (genuine searchengine in letteratura),
che creano automaticamente i propri indici (Altavista, Excite, Google per
citarne alcuni)
2. i directory le cui liste vengono compilate ed organizzate dall’uomo (il più
famoso directory è sicuramente Yahoo). Questa pratica avrà, secondo gli
esperti, sempre meno successo con l’andare del tempo a causa della
velocità con cui cresce il numero di pagine sul web e quindi
all’impossibilità da parte degli operatori di effettuare un’analisi e una
classificazione accettabile dei dati disponibili. Questo tipo di approccio è
oggetto di molte discussioni: da una parte c’è che mette in evidenza la
diversità con cui gli indexer organizzano le informazioni recuperate (si è
visto che meno del 20% delle informazioni vengono trattate nello stesso
modo); dall’altra c’è che fa notare che, se confrontati con liste create
automaticamente, i directory facilitano molto il processo di ricerca perchè
gli indexer umani selezionano con molta più cura le informazioni. Diverso
è anche il formato con cui questi sistemi presentano le informazioni
all’utente: i siti vengono infatti divisi in varie categorie, organizzati in un
modo simile alle comuni “pagine gialle”.
Non mancano poi i sistemi ibridi, costituiti da entrambe le parti.
Un ulteriore approccio molto trattato in letteratura è quello che fa uso dei
cosiddetti web querying language: si utilizzano delle query con degli operatori
118

8 – Information retrieval e Web
che permettono di selezionare singole URL o gruppi di queste per ridurre il
dominio della ricerca; potenzialmente offrono buoni risultati ma sono molto
complessi, ragione per cui il loro utilizzo, almeno su larga scala, è ancora oggi
quasi nullo.
8.2 Crawler/robot
Un crawler è un programma che restituisce delle pagine web, tipicamente per
essere utilizzate da un motore di ricerca (per la costruzione automatica di un
indice); in letteratura questi processi vengono chiamati in diversi modi: il termine
più comune è crawler, ma si può trovare anche bot, robot, spider e worm.
In pratica esso parte da una pagina iniziale P0, estrae tutti gli URL a cui si fa
riferimento in tale pagina e li inserisce in un’apposita coda di indirizzi da
controllare. Il crawler quindi recupera gli URL dalla coda, accede alle pagine e
ripete il processo; ogni pagina controllata viene inviata ad un processo client che
la salva, crea un indice o ne analizza il contenuto.
A meno che disponga di risorse illimitate per quel che riguarda lo spazio su disco
e il CPU time, un crawler deve decidere a quali URL accedere ed in quale ordine,
in modo da recuperare le pagine web più importanti; deve inoltre decidere quanto
frequentemente rivisitare una determinata pagina in modo da mantenere il
processo client aggiornato sui cambiamenti apportati.
Come già detto non tutte le pagine sono ugualmente importanti per il client
associato al crawler: Cho, Garcia-Molina e Page presentano una serie di parametri
che possono essere utilizzati da un crawler per scegliere quali URL visitare prima.
Data una pagina P, è possibile definire l’importanza della pagina, I (P), in uno dei
seguenti modi:
Similarità con una query guida Q (similarità calcolata con uno dei metodi
tradizionali visti precedentemente)
119

8 – Information retrieval e Web
Backlink Count: il valore di I(P) è dato dal numero di link verso P che
compaiono nel web; intuitivamente, una pagina è tanto più importante
quante più pagine fanno riferimento ad essa. Ovviamente è impossibile
effettuare un calcolo su tutto il web, per cui ci si basa sul subset visitato
fino a quel punto
PageRank: il metodo precedente tratta tutti i link nello stesso modo, così
un link sulla home page di Yahoo ha lo stesso peso di uno sulla mia home
page personale. L’algoritmo pagerRank definisce in maniera ricorsiva il
peso dei link di una pagina come la somma dei pesi dei link che puntano a
quest’ultimo. Vedremo più avanti nel dettaglio questo algoritmo.
Location metric: questa tecnica calcola l’importanza di una pagina in base
al suo URL, anzichè in base al contenuto. Ad esempio si dà la precedenza
alle locazioni che terminano con “.com” oppure a quelle che contengono la
stringa “home”, e così via.
Ovviamente, anche quì è possibile avere delle combinazioni pesate dei vari valori.
8.3 Clustering
Abbiamo già visto che il clustering consiste nel raggruppare i documenti simili
per velocizzare le operazioni di information retrieval; i maggiori motori di ricerca
utilizzano tecniche di clustering, anche se non sono noti, come è facile capire, gli
algoritmi seguiti per raggruppare i documenti.
Zamir, Etzione, Madani, Karp hanno proposto tre algoritmi di clustering per
documenti e pagine del web; il primo viene detto word-intersection clustering
method e raggruppa i vari documenti in base alle parole condivise da questi,
creando un centroide costituito dall’insieme dei termini comuni.
Il secondo metodo proposto è il phrase-intersection clustering method: trattando i
documenti semplicemente come delle sequenze di parole si possono perdere delle
informazioni importanti legate alle occorrenze di determinate frasi, quindi in
120

8 – Information retrieval e Web
questo approccio le unità atomiche di informazione sono le le frasi e quelle
comuni ai documenti sono usate come indice per valutare la loro coesione.
Un terzo algoritmo è il suffix-tree clustering algorithm: esso si basa
fondamentalmente sul medesimo concetto del precedente, ma fa uso di una
struttura dati particolare (un suffix-tree per l’appunto) che permette di ridurre la
complessità e con essa il tempo di esecuzione dell’algoritmo.
Modha e Spangler, infine, hanno proposto un’algoritmo di clustering che è basato
sui termini contenuti nei documenti, sugli outlink che partono da questi e sugli inlink
entranti.
8.4 Metasearch navigator
Come abbiamo già accennato in precedenza, nessuno dei motori di ricerca
disponibili è in grado di coprire interamente il web, per cui utilizzando un motore
piuttosto che un altro si rischia di non poter accedere a delle informazioni
importanti. I metasearch engine inviano le query che hanno in input ad una serie
di motori di ricerca, analizzano e combinano le risposte di questi ultimi e
presentano all’utente il risultato di questa integrazione. Ovviamente la maggiore
copertura del web va a scapito della velocità di risposta.
Figura 27 - Metasearch engine
121

8 – Information retrieval e Web
Come si vede dalla figura , un metasearch engine è composto da tre componenti
principali:
DISPATCH: determina a quale o quali motori di ricerca deve essere
inviata una determinata query
INTERFACE: adatta il formato della query utente a quello richiesto dai
singoli motori
DISPLAY: analizza i risultati parziali di ogni singolo motore e li integra
per presentarli poi all’utente.
8.5 Ranking algorithm
In letteratura non sono disponibili informazioni dettagliate riguardo agli algoritmi
di ranking utilizzati dai maggiori motori di ricerca, anche se molti studiosi
concordano nell’affermare che l’approccio più usato consiste nell’utilizzare il
modello vector space opportunamente modificato, magari in collaborazione con
tecniche di latent semantic indexing per ridurre il numero di dimensioni dello
spazio vettoriale.
Tutti gli algoritmi, comunque, sembrano basarsi pesantemente su una peculiarità
dei documenti presenti sul web, ossia la presenza di link tra le varie pagine. Una
base teorica per questo appoggio si può trovare nell’articolo di Kleinberg: l’autore
parte dalla considerazione che i motori di ricerca soffrono del cosiddetto
abundance problem, ossia restituiscono agli utenti un numero di pagine troppo
alto perchè questi riescano a valutarle in modo efficiente e, soprattutto, veloce.
Perchè le ricerche siano veramente efficaci, bisognerebbe riuscire a filtrare un
piccolo set di pagine effettivamente importanti: quelle che l’autore chiama
authoritative o definitive pages. Per fare questo bisognerebbe essere in grado di
valutare la qualità delle varie pagine: questo però è un concetto umano e non è
possibile tradurlo in una funzione matematica. A questo punto l’autore fa notare
che, analizzando i link ed i collegamenti tra le varie pagine è possibile estrarre una
122

8 – Information retrieval e Web
qualche valutazione riguardo al giudizio degli utenti della rete rispetto ad una
determinata pagina: in poche parole, se esiste un numero molto alto di pagine che
puntano ad una certa pagina P, allora è probabile che P sia considerata molto
interessante ed il suo contenuto significativo; gli autori di tali pagine hanno
implicitamente conferito “autorità” a P. Ovviamente questo approccio presenta
una serie di controindicazioni in quanto i link possono essere creati per una lunga
serie di ragioni, molte delle quali hanno poco o nulla a che fare con il concetto di
authority: molti link ad esempio vengono utilizzati unicamente per aiutare la
navigazione (“Click here to return to the home page”, “Back”, ecc.). A
prescindere da queste controindicazioni, questo approccio è stato considerato
molto interessante e oggi gli algoritmi di link analysis, assieme alle tecniche
tradizionali di IR, costituiscono la base per numerosi motori di ricerca.
Vediamo ora due dei più importanti algoritmi utilizzati per l’analisi dei link.
8.5.1 Algoritmo PageRank
Questo algoritmo è stato proposto da Brin e Page e viene utilizzato da Google. Si
basa fondamentalmente sul conteggio dei backlink verso le pagine, però estende
questa tecnica in quanto non assegna lo stesso valore a tutti i link: il valore di un
link dipende dall’importanza della pagina da cui parte e dal numero di link che
sono presenti in tale pagina; si tratta quindi di un algoritmo recursivo.
L’algoritmo è basato sulla seguente definizione:
Si assuma che la pagina A abbia n pagine T1, ..., Tn che puntano ad essa.
C(A) sia definito come il numero di link che partono dalla pagina A.
Il valore di PageRank per la pagina A è dato da:
⎡ PR(
T
⎤
1)
PR(
Tn
)
PR ( A)
= ( 1−
d)
+ d ⎢ + ... + ⎥
⎣ C(
T1)
C(
Tn
) ⎦
I valori di PageRank vengono calcolati usando tecniche di tipo matriciale in cui si
costruisce una matrice dei link presenti tra le pagine web che costituiscono il
repository su cui si lavora; gli autori fanno notare che i valori di PageRank per un
set di 25 milioni di pagine possono venire calcolati in poche ore su una
123

8 – Information retrieval e Web
workstation di media potenza (ovviamente il calcolo di tali valori viene eseguito
off-line). Si tratta di valori generali: non sono riferiti ad una specifica query, ma
all’importanza delle varie pagine in base ai link esistenti. La giustificazione
intuitiva degli autori è che questo algoritmo può essere visto come un modello del
comportamento di un certo utente ideale che naviga il web; si suppone infatti di
avere un “random surfer” che parte da una pagina a caso e, cliccando sui vari link,
naviga tra le pagine del web. Tale utente non esegue mai un “back” sulla pagina
precedente, ma ad un certo punto può stufarsi e ricominciare nuovamente la
navigazione da una pagina a caso (il parametro d è proprio la probabilitò che il
random surfer si annoi e richieda una nuova starting page casuale); la probabilità
che un utente visiti una determinata pagina è proprio il valore di PageRank di
quest’ultima.
8.5.2 Algoritmo HITS
Questo algoritmo è stato proposto da Kleinberg e, a differenza del precedente,
calcola l’importanza delle varie pagine rispetto a una specifica query di ricerca;
data una query, HITS dovrebbe individuare le pagine le pagine il cui contenuto è
rilevante per la query (definite authority) e le pagine contenenti dei link utili
rispetto alla richiesta della query (definite hub).
Prima di applicare l’algoritmo vero e proprio, bisogna decidere su quale set di
pagine tale algoritmo lavorerà; idealmente si vorrebbe una collezione Sσ di pagine
con le seguenti proprietà:
1. Sσ relativamente piccolo
2. Sσ ricco di pagine rilevanti
3. Sσ contenente molte authority
L’autore suggerisce la seguente soluzione per determinare la collezione iniziale di
pagine: dato un parametro t (si è visto che i risultati migliori si ottengono con
t≈200), si prendono le t pagine con il più alto rank che vengono restituite da un
qualsiasi motore di ricerca in risposta alla query di riferimento σ. Tali pagine
124

8 – Information retrieval e Web
vengono indicate come root set Rσ; si procede quindi ad aumentare il numero di
presunte authority nel sottografo espandendo Rσ in base ai link entranti ed
uscenti, utilizzando il seguente algoritmo:
Subgraph(σ,ε,t,d)
σ: query string
ε: text-based search engine
t,d: natural numbers
Let Rσ=top t results of σ on ε
Set Sσ:=Rσ
For each page p ∈ Rσ
Let Γ + (p)=set of all pages p points to
Let Γ – (p)=set of all pages pointing to p
Add pages in Γ + (p) to Sσ
If |Γ - (p)| ≤d then
Add pages in Γ - (p) to Sσ
Else
Add an arbitrary set of d pages from Γ - (p) to
Sσ
End if
Next p
Return Sσ
Possiamo utilizzare un’euristica per evitare di considerare i link che servono
soltanto per funzioni di navigazione; allo scopo bisogna distinguere tra due tipi di
link: i link transverse sono quelli tra pagine con lnomi di dominio diversi, mentre
quelli intrinsic sono quelli tra pagine con lo stesso nome di dominio (per nome del
dominio si intende il primo livello nell’URL associato alla pagina). Gli intrinsic
link spesso svolgono puramente funzioni di navigazione all’interno di un sito, per
cui portano molte meno informazioni dei transvere link per quel che riguarda
l’authority delle pagine: tali link possono quindi venire ignorati quando si espande
il sub-grafo Rσ.
HITS associa ad ogni pagina due pesi: un authority weight x ed un hup weight
y ; entrambi i pesi sono non negativi e sono normalizzati, così che la somma dei
loro quadrati sul subset Sσ vale 1:
125

8 – Information retrieval e Web
∑
p∈S
∑
p∈S
σ
σ
< p>
2
( x ) = 1
< p>
2
( y ) = 1
I due pesi si rafforzano mutuamente: se p punta a tante pagine con dei valori di x
alti, avrà un valore di y alto; se p viene referenziata da tante pagine con dei buoni
valori di y, avrà un valore alto di x.
Figura 28 - Calcolo dei pesi con l'algoritmo HITS
Vengono ora definite le due operazioni fondamentali sui pesi delle pagine:
l’operazione α aggiorna i pesi x nel modo seguente:
x
∑ < p>
< q>
← y
p:
∈E
126
( p,
q)
mentre l’operazione β esegue l’aggiornamento dei pesi y:
y
∑ < p>
< q>
← x
p:
∈E
( p,
q)

8 – Information retrieval e Web
Vediamo ora l’algoritmo per calcolare i vari pesi; si rappresenta il set dei valori
x come un vettore X avente una coordinata per ogni pagina della collezione in
esame Gσ, analogamente si rappresenta il set dei valori y come un vettore Y:
Iterate(G,k)
G: collection of n linked pages
k: natural number
Let Z=the vector (1,1,1,...,1) ∈R n
Set X0:=Z
Set Y0:=Z
For i=1,2,...,k
Apply α to (Xi-1,Yi-1), obtaining new x-weights
Xi’
Apply β to (Xi’,yi-1), obtaining new y-weights Yi’
Normalize Xi’, obtaining Xi
Normalize Yi’, obtaining Yi
Next i
Return (Xk,Yk)
8.6 Direzioni di ricerca future
Alcuni studiosi hanno proposto alcune idee piuttosto innovative per migliorare le
qualità delle ricerche delle pagine sul web; si tratta di progetti che affrontano
problemi completamente diversi dai metodi tradizionali di IR:
Lawrence propone un client based personalized search service che tenga
traccia dei documenti creati o visionati dall’utente e che crei un vero e
proprio modello degli interessi di quest’ultimo. Basandosi su un tale
profilo i client potrebbero modificare le query dell’utente o selezionare un
particolare motore di ricerca specializzato, o ancora modificare
l’ordinamento delle pagine restituite. Tutto questo richiederebbe
ovviamente una grande quantità di risorse per mantenere il profilo dei vari
utenti (oltre a dover affrontare infiniti problemi legati alla privacy):
l’autore fa notare che l’evoluzione dei sistemi potrebbe rendere possibile
127

8 – Information retrieval e Web
l’implementazione di server di ricerca su larga scala personalizzati entro
breve tempo. In tal modo verrà superato il concetto su cui si basano oggi i
motori di ricerca:”one size fits all”, tutti gli utenti ricevono la medesima
risposta a fronte di una stessa query.
Questi sistemi non esistono solo sulla carta: alcune compagnie infatti
iniziano a dedicare delle risorse per mantenere informazioni sul profilo dei
propri utenti da utilizzare in fase di ricerca (DriveWay,
www.driveway.com oppure Xdrive, www.xdrive.com).
Lawrence e Giles propongono un modello di motore di ricerca che sia in
grado di riconoscere le query espresse in forma generica e di trasformarle
in una forma che possa incrementare il valore di precision della ricerca.
Ad esempio “What does NASDAQ stand for ?” potrebbe venire
trasformata in “NASDAQ is the acronym for”; in pratica un tale motore
dovrebbe convertire le query nella loro specific expressive form, ossia
nella forma più espressiva ai fini della ricerca
Zhu e Gauch introducono il concetto di qualità delle pagine web e
propongono un approccio che combini le metodologie di ranking
tradizionali con dei metodi di quality ranking. I valori che vengono
proposti per misurare la qualità delle pagine sono:
1. currency: indica il tempo trascorso dall’ultima modifica della
pagina
2. availability: calcolata come il numero di link interrotti nella
pagina, diviso per il numero totale di link che questa contiene
3. information-to-noise ratio: rapporto tra il numero di index term
ottenuti nella pagina dopo una fase di preprocessing e la lunghezza
totale della pagina
4. authority: autorità di una pagina, basata sul servizio Yahoo Internet
Life (YIL) di ZDNet (www.zdnet.com/yil). Tale servizio assegna
un punteggio da 2 a 4 ai siti che analizza; se un sito non è ancora
stato analizzato gli viene assegnato come punteggio 0
128

8 – Information retrieval e Web
5. popularity: il numero di link che puntano ad una pagina web è
indice della popolarità di quest’ultima. Una tale informazione è
recuperabile, ad esempio, dal sito Altavista
6. cohesiveness: viene definita un’euristica per individuare gli
argomenti più importanti in una pagina e per determinare quanto
siano correlati tra di loro.
8.7 Architettura di un motore di ricerca
In questa parte viene presentato un possibile modello di un sistema per la
costruzione e la gestione di un inverted index per il web, assieme ai problemi che
si devono affrontare e ad alcune possibili soluzioni. Infine verrano presentate
l’architettura ed il funzionamento di Google, uno dei motori di ricerca più
utilizzati sul web.
Come anche per i sistemi di IR, gli inverted index sono la struttura dati più usata
dai motori di ricerca; anche se si sta diffondendo la tendenza ad utilizzare la
struttura dei link tra le varie pagine e la loro analisi semantica per produrre
risultati di alta qualità per le ricerche on-line, le tecniche di retrieval text-based
restano il metodo principale per identificare le pagine rilevanti a fronte di una
query dell’utente: in molti motori di ricerca viene infatti utilizzata una
combinazione di metodi text-based e link-based. I searchengine solitamente
utilizzano delle custom network architecture e dell’hardware ad alte performance
per rispondere alle query in tempi dell’ordine di pochi secondi.
Si può quindi modellare un sistema di indexing per un motore di ricerca come
un’architettura shared-nothing distribuita, costituita da una collezione di nodi
(workstation) collegati da una rete locale:
129

8 – Information retrieval e Web
Figura 29 - Architettura di un sistema per la costruzione di un inverted index
In questo sistema si possono identificare tre tipi di nodi:
DISTRIBUTOR: questi nodi memorizzano sui propri dischi la collezione
di pagine web che devono essere indicizzate
INDEXER: nodi dedicati alla costruzione dell’inverted index
QUERY SERVER: ognuno di questi nodi memorizza una parte
dell’inverted index finale; a seconda dell’organizzazione di tale indice,
uno o più di questi server possono venire coinvolti nella risposta ad una
determinata query di ricerca.
L’input per il sistema di indexing è una collezione di pagine web che vengono
memorizzate sui nodi distributor; in output viene prodotto un set di coppie
(inverted index, lexicon), uno per ogni query server. L’inverted index su un query
server copre un subset dei documenti della collezione oppure un subset degli
index term considerati, mentre il lexicon elenca tutti gli index term presenti
nell’indice associato, oltre ai dati statistici che vengono usati per il ranking.
L’indice viene costruito in due passi, nel primo passo ogni distributor node esegue
un distributor process che suddivide la collezione di pagine web tra i vari indexer;
ogni indexer riceve un subset di pagine disgiunto dagli altri, esegue un parsing del
130

8 – Information retrieval e Web
testo, costruisce le posting list per i vari termini, le ordina e le memorizza in una
struttura temporanea su disco. Nel secondo passo queste strutture temporanee
vengono unite e riordinate per creare uno o più inverted index con il relativo
lexicon. Ogni coppia (inverted index, lexicon) può anche essere memorizzata in
più query server, nel caso si voglia avere una replica delle strutture dati.
In un sistema distribuito ci sono due possibili strategie per distribuire un inverted
index tra più query server:
partizionare la collezione di documenti in modo che ogni query server sia
responsabile di un set di documenti disgiunto dagli altri (solitamente si
parla di local inverted index)
partizionare l’inverted index in modo che oqni query server contenga le
posting list di un subset degli index term presenti nella collezione (in
questo caso si parla di global inverted index)
Gli inverted index possono essere memorizzati e manipolati utilizzando strutture
dati create ad hoc, oppure usando i database relazionali o ad oggetti offerti dal
mercato. Il vantaggio di un’implementazione di tipo custom è che permette di
realizzare un sistema fortemente ottimizzato (es. caching delle posting list usate
più di frequente, compressione di quelle usate raramente in modo da ottimizzare
lo spazio, anche a scapito delle performance, ecc.); se si utilizzano sistemi di tipo
commerciale non è possibile avere un controllo così spinto, ma si ha il vantaggio
di ridurre la complessità del sistema ed i tempi di sviluppo.
Vediamo ora alcuni problemi che devono essere affrontati quando si costruisce
un inverted index su un’architettura distribuita:
1. page distribution: quando e come distribuire le pagine agli indexing node
2. collecting global statistic: quando, come e dove calcolare le statistiche
generali sull’intera collezione in esame.
131

8 – Information retrieval e Web
Page distribution. Molto spesso la collezione di pagine web si trova su un set di
nodi disgiunto dai nodi usati per l’indexing; ci sono due strategie per far
comunicare i nodi distributor e gli indexer:
1. distribuzione a priori: tutte le pagine vengono trasferite dai distributor agli
indexer prima che inizi la fase di indexing. Durante l’indexing, il processo
che funge da index-builder riceve le pagine dal disco locale anzichè dalla
rete
2. distribuzione runtime: in questa strategia la distribuzione della collezione
avviene in concorrenza con l’index-building. Il processo index-builder
opera quindi sulle pagine non appena queste arrivano attraverso la rete dai
distributor.
Con la distribuzione runtime è possibile realizzare una sorta di load balancing dei
vari indexer: i processi distributor vengono progettati per inviare le pagine agli
indexer a diverse velocità, a seconda del processing speed di ogni nodo indexer.
Con il secondo metodo, inoltre, i nodi indexer ricevono i dati da elaborare dalla
rete e scrivono i risultati temporanei su disco: non vi è il rischio che ci siano
conflitti sulle risorse; nel primo caso invece i processi devono leggere e scrivere
su disco e le due fasi potrebbero interferire tra di loro. La distribuzione runtime ha
però lo svantaggio di richiedere una gestione più complessa nel caso di
malfunzionamento di un nodo indexer, perchè si perde il subset di pagine che
questo aveva in memoria e che aveva già processato: bisogna quindi recuperare
questo subset dai nodi indexer e ritrasmetterlo.
Collecting global statistic. Alcuni autori suggeriscono di calcolare le statistiche
globali sulla collezione al momento della ricerca (query time); questo approccio
richiede però che i vari query server si scambino le statistiche sul proprio subset
mantenute nel lexicon: dato che il query response time è un parametro critico del
sistema, un simile approccio potrebbe introdurre un ritardo non accettabile dovuto
alle comunicazioni sulla rete locale tra i vari server.
132

8 – Information retrieval e Web
Una soluzione alternativa consiste nell’avere un server dedicato che viene usato
per il calcolo dei dati statistici: in tal modo tutte le attività di calcolo vengono
eseguite in parallelo con le altre operazioni di indexing.
Presentiamo per concludere l’architettura di Google, le sue strutture generali e
come queste interagiscono tra di loro; la scelta di Google non è dovuta al fatto che
sia migliore degli altri motori di ricerca (opinione comunque sostenuta da molti),
ma per il semplice motivo che, essendo parte di un progetto accademico (portato
avanti dall’università di Stanford), è l’unico per cui siano disponibili informazioni
dettagliate.
Figura 30 - Architettura di Google
133

8 – Information retrieval e Web
Il crawling del web viene eseguito da diversi crawler distribuiti e comandati da un
URL server che invia la lista degli URL che ogni crawler deve recuperare. Le
pagine web che vengono scaricate sono poi inviate allo store server che le
comprime e le memorizza in un repository; ogni pagina web ha un identificatore
univoco chiamato docID che viene assegnato ogni volta che un URL viene
identificato su una pagina qualsiasi.
La funzione di indexing viene svolta da un indexer e un sorter; il primo legge il
repository, decomprime i documenti e ne esegue il parsing, ogni documento viene
convertito in un set di occorrenze di termini chiamate hit; gli hit sono degli oggetti
che memorizzano il termine, la sua posizione nel documento, le dimensioni del
font, se si trova in un titolo, sottotitolo, ecc.
L’indexer distribuisce questi hit in un set di barrels, creando una sorta di indice
parzialmente ordinato; l’indexer inoltre esegue il parsing di tutti i link presenti
nelle pagine e memorizza le informazioni così ottenute in anchor file (in fase di
ricerca viene anche valutato il contenuto testuale dei link).
L’URL resolver legge l’anchor file, memorizza il testo dei link nel forward index
e lo associa con il docID a cui punta il link; inoltre genera un database in cui
memorizza, per ogni link, il docID associato alla pagine web su cui si trova e
quello della pagina a cui punta. Tale database viene utilizzato per calcolare il
valore di PageRank per i vari documenti.
Il sorter analizza i barrel, li ordina per wordID e genera l’inverted index vero e
proprio; un programma chiamato DumpLexicon associa una serie di informazioni
presenti nell’inverted index con quelle generate dall’indexer e crea un nuovo
lexicon che verrà utilizzato dal searcher.
Il searcher gira su un web server ed utilizza il lexicon, l’inverted index e le
informazioni generate da PageRank per risolvere le query dell’utente.
134

Bibliografia
GROSSMAN, FRIEDER, Information retrieval: algorithms and heuristics
– Kluver Publishers, 1998
VAN RIJSBERGEN, Information retrieval
Capitolo 1 Concetti generali
DELLA ROCCA, Sistemi a tecnologia avanzata per l’acquisizione,
l’elaborazione ed il recupero dell’informazione bibliografica
WEISS, Glossary for informazion retrieval (1997)
1.1 Schema di un information retrieval system
1.2 Effectiveness ed efficiency
Capitolo 2 Automatic text analysis
SALTON, BUCKLEY, Approaches to text retrieval for structured
documents (1990)
Capitolo 3 Strategie di retrieval
CIACCIA, Dispense del corso di sistemi informativi II, Università
di Bologna (1999)
YAN, GARCIA-MOLINA, Index structures for information
filtering under the vector space model
3.1 Boolean query
3.2 Extended (Weighted) boolean query
3.3 Modelli booleani estesi – MMM=Mixed Min and Max
3.4 Inference network
3.5 Vector space model
BERRY, DRMAC, JESSUP, Matrices, vector spaces and
information retrieval
3.6 Probabilistic retrieval
135

Bibliografia
LAFFERTY, ZHAI, Probabilistic IR models based on document
and query generation
ROLLEKE, BLOMER, Probabilistic logical information retrieval
for content, hypertext and database querying
3.7 Genetic algorithm
CHEN, Machine learning for information retrieval: neural
networks, sysmbolic learning and genetic algorithms
Capitolo 4 Utility
BAEZA-YATES, Text Retrieval: theory and practice
JING, CROFT, An association thesaurus for information retrieval
4.1 Relevance feedback
4.2 Parsing
FOX B., FOX C.J., Efficient stemmer generation
PORTER, An algorithm for suffix striping (1980)
RILOFF, Little words can make a big difference for text
classification
SADAKANE, A fast algorithm for making suffix arrays
4.3 Clustering – Classificazione dei documenti
CUTTING, PEDERSEN, KARGER, TUKEY, Scatter/gather: a
cluster-based approach to browsing large document collections
(1992)
FASULO, An analysis of recent work on clustering algorithms
(1999)
JOACHIMS, A probabilistic analysis of the Rocchio algorithm
with TFIDF for text categorization (1996)
LEVSKI, ALLAN, Improving interactive retrieval by combining
ranked lists and clustering
136

Bibliografia
MAKOTO, TAKENOBU, Hierarchical bayesian clustering for
automatic text classification (1995)
RAJARAMAN, PAN, Document clustering using 3-tuples
SALTON, ARAYA, On the use of clustered file organization in
information search and retrieval (1989)
SALTON, BUCKLEY, Approaches to global text analysis (1990)
STOCKBURGER, Cluster analysis
VOORHEES, Implementing agglomerative hierarchic clustering
algorithms for use in document retrieval (1986)
VOORHEES, The cluster hypotesis revisted (1985)
VOORHEES, The efficiency of inverted index and cluster searches
4.4 Latent semantic indexing (LSI)
ASHWORTH, An overview of latent semantic indexing (2001)
BERRY, DUMAIS, O’BRIEN, Using linear algebra for intelligent
information retrieval (1994)
BERRY, DUMAIS, SHIPPY, A case study of latent semantic
indexing (1995)
DEERWESTER, DUMAIS, Indexing by latent semantic indexing
HONG, An overview of latent semantic indexing (2000)
Capitolo 5 Implementazioni
5.1 Inverted index
CLARKE, CORMACK, Dynamic inverted indexes for a
distributed full-text retrieval system
CUTTING, PEDERSEN, Optimizations for dynamic inverted
index maintenance
FRIEDER G., GROSSMAN, FRIEDER G., CHOWDHURY,
Efficiency considerations for scalable information retrieval servers
LEE, YOO, YOON, Index structures for structured documents
LUCARELLA, A search strategy for large document bases
137

Bibliografia
MOFFAT, ZOBEL, Compression and fast indexing for multi-
gigabyte text databases
TOMASIC, GARCIA-MOLINA, SHOENS, Incremental updates
of inverted lists for text document retrieval
WONG, LEE, Implementations of partial document ranking using
inverted files (1992)
YAN, GARCIA-MOLINA, Index structures for selective
dissemination of information under the boolean model (1993)
ZOBEL, MOFFAT, RAMAMOHANARAO, Inverted files versus
signature files for text indexing (1998)
ZOBEL, MOFFAT, SACKS-DAVIS, An efficient indexing
technique for full-text database systems (1992)
5.2 Signature file
DERVOS, MANOLOPOULOS, LINARDIS, Comparison of
signature file models with superimposed coding (1998)
LEE, KIM, PATEL, Efficient signature file methods for text
retrieval (1995)
NORVAG, Efficient use of signature in object-oriented database
systems
RINFRET, O’NEIL P., O’NEIL E., Bit-sliced index arithmetic
(2001)
Capitolo 6 Integrazione tra IR e database
BAEZA-YATES, NAVARRO, Integrating contents and structure
in text retrieval
CLARKE, CORMACK, BURKOWSKI, An algebra for structured
text search and a framework for its implementation (1994)
DE VRIES, WILSCHUT, On the integration of IR and databases
FUHR, A probabilistic relational model for the integration of IR
and databases
138

Bibliografia
FUHR, Logical and conceptual models for the integration of
information retrieval and database systems
FUHR, Models for integrated information retrieval and database
systems
FUHR, ROLLEKE, A probabilistic NF2 relational algebra for
integrated information retrieval and database systems (1996)
GOLDMAN, SHIVAKUMAR, GARCIA-MOLINA, Proximity
search in databases
GOLDMAN, WIDOM, Interactive query and search in
semistructured databases
GROSSMAN, FRIEDER, HOLMES, ROBERTS, Integrating
structured data and text: a retrieval approach
GROSSMAN, Integrating structured data and text: a relational
approach (1995)
SCHEK, PISTOR, Data structures for an integrated database
management and information retrieval system (1982)
6.1 Integrazione di sistemi esistenti
CALLAN, CROFT, HARDING, The INQUERY retrieval system
GU, THIEL, ZHAO,Efficient retrieval of complex objects: query
processing in a hybrid DB and IR system
6.2 Estensione di RDBMS con aggiunta di funzioni di IR
BALOWNEW, BODE, CREMERS, KALINSKI, WOLFF,
ROTTMANN, Maintaining library catalogues with an RDBMS –
A performance study
CHAUDURI, SHIM, Query optimization in the presence of foreign
functions
COTTON, SQL multimedia and application packages (SQL/MM)
project plan (1994)
DAVIS, Creating an extensible, object-relational data management
environment – IBM’S DB2 Universal Database (1996)
139

Bibliografia
DAVIS, Informix Universal Server – Extending the relational
DBMS to manage complex data (1996)
DESSLOCH, MATTOS, Integrating SQL databases with content-
specific search engines
EISENBERG, MELTON, SQL standardization: the next steps
PUTZ, Using a retrieval database for an inverted text index
STONEBRAKER, ANTON, HANSON, Extending a database
system with procedures
STONEBRAKER, Inclusion of new types in relational database
systems
STONEBRAKER, WONG, The empire strikes back: DB2
universal database
ZHANG, NAUGHTON, DEWITT, LUO, LOHMAN, On
supporting containment queries in retrieval database management
systems
6.3 Implementazione di un IRS come applicazione di un
RDBMS
KAUFMANN, SCHEK, Text search using database systems
revisted
Capitolo 7 Parallel information retrieval system
BAILEY, HAWKING, A parallel architecture for query processing
over a terabyte of text
CAHOON, McKINLEY, Performance analysis of distributed
information retrieval architectures
FRIEDER G., GROSSMAN, FRIEDER G., CHOWDHURY,
Efficiency considerations for scalable information retrieval servers
GROSSMAN, HOLMES, FRIEDER, A parallel DBMS approach
to IR in TREC-3
140

Bibliografia
HAWKING, The design and implementation of a parallel
document retrieval engine
KOPESKY, PANDORA: parallel documentation retrieval
architecture (1996)
LU, McKINLEY, CAHOON, A performance evaluation of parallel
information retrieval on symmetrical multiprocessors
MAMALIS, SPIRAKIS, TOMPAKAS, High performance paralle
text retrieval over large scale document collections: the PFIRE
system
MAMALIS, SPIRAKIS, TOMPAKAS, Optimal high performance
parallel text retrieval via fat trees
MAMALIS, SPIRAKIS, TOMPAKAS, Parallel techniques for
efficient searching over very large text collections
PANAGOPOULOS, FALOUTSOS, Bit-sliced signature files for
very large text databases on a parallel machine architecture
SALTON, BERGMARK, Parallel computations in information
retrieval
SALTON, BUCKLEY, Parallel text search methods
Capitolo 8 Information retrieval e Web
ABITEBOUL, VIANU, Queries and computation on the web
AMATO, RABITTI, SAVINO, Multimedia document search on
the web
AROCENA, MENDELZON, MIHAILA, Applications of a web
query language
BAILEY, HAWKING, Server selection on the world wide web
CARRIERE, KAZMAN, WebQuery: searching and visualizing the
web through connectivity
COOLEY, MOBASHER, SRIVASTAVA, Web mining:
information and pattern discovery on the world wide web
141

Bibliografia
DEAN, HENZINGER, Finding related pages in the world wide
web
FENG, Integrating database and www technologies
FLORESCU, LEVY, MENDELZON, Database techniques for the
world wide web: a survey
FRIEDER G., GROSSMAN, FRIEDER G., CHOWDHURY,
Efficiency considerations for scalable information retrieval servers
HU, CHEN, SCHMALZ, RITTER, An overview of world wide
web search technologies
HUANG, A survey on web information retrieval technologies
KOBAYASHI, TAKEDA, Information retrieval on the web
KONOPNICKI, SHMUELI, Bringing database functionality on the
WWW
LAWRENCE, GILES, BOLLACKER, Digital libraries and
autonomous citation indexing (1999)
LAWRENCE, GILES, Searching the world wide web (1998)
MAY, LAUSEN, Information extraction from the web (2000)
MENDELZON, MIHAILA, MILO, Querying the world wide web
8.1 Indexing
8.2 Crawler/robot
CHO, GARCIA-MOLINA, PAGE, Efficient crawling through
URL ordering
8.3 Clustering
MODHA, SPANGLER, Clustering hypertext with applications to
web searching
ZAMIR, ETZIONI, Web document clustering: a feasibility
demonstration
ZAMIR, ETZIONI, MADANI, KARP, Fast and intuitive clustering
of web documents
8.4 Metasearch navigator
142

Bibliografia
SVIDZINSKA, A world wide web meta search engine using an
automatic query routing algorithm (2001)
8.5 Ranking algorithm
BHARAT, HENZINGER, Improved algorithms for topic
distillation in a hyperlinked environment
CUTLER, SHIH, MENG, Using the structure of HTML documents
to improve retrieval
HENZINGER, HEYDON, MITZENMAKER, NAJORK,
Measuring index quality using random walks on the web
KING, KOBAYASHI, Information retrieval and ranking the web:
benchmarking studies (1999)
KLEINBERG, Authoritative source in a hyperlinked environment
LJOSLAND, Evaluation of web search engines and search for
better ranking algorithms (1999)
PAGE, The PageRank citation ranking: bringing order to the web
(1998)
ZHANG, DONG, An efficient algorithm to rank web resources
ZHENG, JORDAN, Stable algorithms for link analysis
8.6 Direzioni di ricerca futura
JAMES, POOCH, A review of web searching studies and a
framework for future research (2000)
LAWRENCE, Context in web search (2000)
LAWRENCE, GILES, Context and page analysis for improved
web search (1998)
ZHU, GAUCH, Incorporating quality metrics in
centralized/distributed information retrieval on the world wide web
8.7 Architettura di un motore di ricerca
BRIN, PAGE, The anatomy of a large-scale hypertextual web
search engine
143

Bibliografia
JEONG, OMIECINSKI, Inverted file partitioning schemes in
multiple disk systems (1993)
KWOK, ETZIONI, WELD, Scaling question answering to the web
LU, Scalable distributed architectures for information retrieval
MELNIK, RAGHAVAN, YANG, GARCIA-MOLINA, Building a
distributed full-text index for the web
TOMASIC, GARCIA-MOLINA, Caching and database scaling in
distributed shared-nothing information retrieval systems
TOMASIC, GARCIA-MOLINA, Performance of inverted indices
in distributed text document retrieval systems
TOMASIC, GARCIA-MOLINA, Performance of inverted indices
in shared-nothing distributed text document information retrieval
systems
TOMASIC, GARCIA-MOLINA, Query processing and inverted
indices in shared-nothing distributed text document information
retrieval systems (1992)
La maggior parte degli articoli citati è reperibile sui seguenti siti:
• Researchindex – The NECI Scientific Literature Digital Library
http://citeseer.nj.nec.com/cs
• Stanford University Database Group
http://www-db.stanford.edu
144