All chapters Flashcards
(79 cards)
Search engine, quante generazioni abbiamo e caratteristiche di queste ultime.
5 generazioni: 0) semplice, basata su metadati. 1) Basata su contenuto della web page. 2) Introduzione di Anchor text e tiene in considerazione hyperlinks. 3) Si tiene in considerazione Query precedenti degli utenti. 4) Abbiamo un summit delle info, tramite information supply.
Parole possono 2 alcune caratteristiche importanti nei search engine, descrivile:
Polisemia (Stessa parola concetti diversi) , sinonimo (Parole diverse, stesso concetto)
Come è cambiato paradigma di Search engine?
Prima avevamo query semplici, oggi invece query colloquiali. Abbiamo anche interazione tra IoT devices.
Tipologia di dati
Opportunistici, come carte di credito o chiamate telefoniche, utilizzati in modo opportunistico dalle società.
Dati presi con uno scopo, un esempio di questi sono i dati raccolti da sensori.
Dati forniti dall’utente, come quando viene utilizzato un social.
Definizione di information retrieval
Indica il trovare del materiale di tipo non strutturato in una grande collezione di elementi che risolve un bisogno di un utente.
Dati strutturati vs non strutturati, esempio entrambi.
Database hanno dei dati di tipo strutturato, mentre in information retrieval abbiamo dati semi strutturati come XML o JSON.
Perchè non usare un DB tradizionale per search engines?
Poichè se immaginiamo solo wikipedia, abbiamo 1 mil pagine e 1 mil di parole . Troppo grande e documenti non contengono 1 milione di parole diverse, quindi abbiamo tanti zero.
Soft AND vs Hard AND
Quando effettuiamo una query, soft AND utilizzato anche da Google, rimuove alcune parole troppo stringenti dalla query a differenza di Hard AND che le richiede tutte.
Perchè usiamo Inverted index e come funziona?
Poichè salviamo spazio e tempo. Nello specifico creiamo una lista di token, e per ogni token associamo quelli che sono i documenti contenti il token. Approccio naive per il confronto sarà confronto (n * m) elementi. Approccio ottimizzato (n + m) confronti, poichè teniamo ordinata lista dei documenti.
Se avessimo più di due token come effettuiamo operazioni di confronto? potevo usare un metodo più ottimizzato del primo descritto?
In questo caso partiamo da token con minor numero di documenti, in modo da mantenere piccola dimensione di documenti aventi token che ci interessano. Metodo più ottimizzato in questo caso sarebbe utilizzare binary search e non confronto lineare.
Come ottimizzare query in inverted index?
Possiamo usare skip pointers, possiamo muoverci tra blocchi la cui dimensione ideale è sqrt(n) elementi, poichè blocchi troppo grandi pochi skip, blocchi troppo piccoli sostanzialmente inutili.
Altro metodo recursive merge, che tramite binary search + ricorsività va a scartare alcuni elementi della lista, molto elegante ma ricorsività può essere pesante per il sistema.
Problema delle queries con OR NOT
In questo caso query molto pericolosa, poichè dobbiamo unire due liste di docs, una che rispetta prima proprietà e seconda che non rispetta seconda proprietà (“Lista enorme”).
Differenti tipologie di queries.
4 tipologie di queries:
Phrasal: Match perfetto, dobbiamo salvare posizione dei token nel doc.
Proximity: Token si trovano a distanza al più k
Zone/Field queries: Parti del documento di lunghezza variabile (autore, dove scritto, contenuto) , vogliamo sapere se contengono un token che ci interessa. Possiamo salvare o per ciascun token, il field dove contenuto o i token salvati in modo classico e docs contengono reference a field.
Similarity queries: abbiamo token diversi con stesso significato, utilizziamo knoledge graphs.
Com’è strutturato un search engine?
Abbiamo back end: un crawler che analizza il web, un page archive dove vengono salvate le pagine web. Page analyzer che si occupa di analizzarle e costruire inverted index tramite indexer.
Mentre il front end è quello che utilizziamo che a partire dalle queries ci restituisce le pagine in ordine di importanza.
Che db viene utilizzato per salvataggio di dati da Page archive ecc..
Vengono utilizzati no sql, che permettono di gestire big data tramite delle table “infinite”. Che tramite stringhe permettono di accedere ad altre stringhe.
Descrivimi struttura Bow Tie del web
Abbiamo 5 componenti fondamentali:
Strongly connected components, che sono componenti che permettono partendo da uno di loro di tornare al componente di partenza.
In, che permettono di arrivare agli strongly connected components, ma non a quelli di partenza.
Out, partono da strongly connected components ma non tornano a questi ultimi.
Tubes, che portano da IN ad OUT, senza passare per SCC.
Tendrils, che portano verso vicoli ciechi.
Disconnected components, non interessanti non puntano e non sono puntati da SCC, IN o OUT.
Quando creiamo crawlers da dove partire come parte del web?
Partiamo da IN, ovviamente non essendoci
distribuzione delle pagine uniforme le pagine da cui partiamo sono decise in modo “arbitrario”.
Come scegliere le pagine da cui effettuare crawling? Quanto fare crawling? E quanto spesso?
Migliori in relazione al tipo di search engine che costruiamo, dobbiamo evitare spider traps “pagine dove entriamo e troviamo tutti contenuti inutili” e spam “pagine offensive o non interessanti”.
Il crawling va effettuato con tradeoff tra pagine già visitate e pagine nuove.
Alcune pagine hanno bisogno di aggiornamento continuo come newspapers, altre come quelle universitarie di un crawl molto più limitato.
Come funziona life cycle di un crawler?
NOTA CHE FRONTIERA SI PORTA DIETRO LINKS VISITATI; ASSIGNED REPOSITORY GESTISCE LINKS DA VISITARE
Il crawler si porta dietro una frontiera di links inizializzati con seed urls. Assegnamo tramite il crawler manager i link da visitare secondo un ordine. Da questi vengono scaricati links tramite Page Downloader, nel Page Repository. Da quest’ ultimo poi il link extractor si occupa di analizzare una pagina per scegliere links da inserire nuovamente nell’Assigned repository. Importante i links potrebbero appartenere ad host diversi, oppure link già visitati.
Abbiamo più crawler che lavorano in parallelo.
Condizioni di terminazione per un Crawler
Varie, esempi non ci sono altre pagine oppure time limit.
Come verificare se una pagina P è buona per un Crawler?
BFS, DFS, RANDOM.
POPULAR DRIVEN, ogni pagina ha uno score come Page Rank.
TOPIC DRIVEN.
COMBINATI.
Descrivi come funziona Mercator Crawler
Abbiamo URLs incontrati, un prioritazer che assegna priorità ai vari URLs. K front end queue dove inseriamo elementi basandoci sulla priorità. Questi elementi vengono scelti in modo biased da un biased selector (priorità maggiore, possibilità maggiore di essere scelti). Back end BE queue che servono per gestire vari host, ogni queue ha un host assegnato. Quando prendo elementi da BE li inserisco in min heap basato su tempo di attesa con host per non incorrere in blocco per troppi accessi.
Quando prendo nuova pagina da inserire in Min heap potrei trovare queue vuota, in quel caso prendo una pagina da front end e la inserisco nella relativa queue, se non presente la queue vuota viene assegnata al nuovo host.
Prima pagina da cui effettuare Crawling è la minore del min heap.
Buon valore per B = 3 x numero di thread.
Errore nel bloom filter
Dato da (1 - e^ (-k n / m))^k . Dati n, m fixed possiamo settare k = (m/n) ln 2 . In questo modo otteniamo errore uguale ad 0.62^ m/n
Differenza tra bloom filter e hash map.
Per hash map noi possiamo avere dimensione array di hash = numero di chiavi. Ma dobbiamo salvare una lista di chiavi per quando incontriamo una collisione. Quindi scopi differenti.