All chapters Flashcards
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.
Quanto vale errore nello spectral bloom filter
Vale come quello del bloom filter, infatti se ho un errore vuol dire che ho collisioni per tutti gli elementi. Ma questo proprio errore bloom filter poichè non posso avere valori minori di valore reale.
Come posso ottimizzare spectral bloom filter?
Uso due spectral bloom filter, SPF2 «_space;SPF1, con hash functions ovviamente differenti. Se presente recurring minimum uso quello, altrimenti inserisco elementi partendo da Single minimum.
Crawling parallelo che tipologie posso avere
Static assignment, prevede assegnazione ad ogni crawler di una specifica porzione del web.
Dynamic assignment, prevede assegnazione tramite hash function che restituisce un valore per ogni url tra [0, c - 1] con c numero di crawlers.
Consistent hashing ci permette di assegnare urls tramite fault tollerance.
Utilizzo un ring, dove nodi sono o servers o urls, leggo clock wise ed il primo server che incontro gestirà tutti gli urls.
Il remapping nel caso di aggiunta o rimozione di server riguarda n/s elementi.
Per boostare possiamo prendere s log s servers, visto ad AE, quindi non credo mi interessi.
Quali proprietà utilizzo per la compressione del web graph?
Utilizzo tre proprietà:
- Skewed, ossia probabilità che un nodo abbia x links = 1/x^alfa dove alfa è una costante che vale circa 2.1. Questa tipologia di distribuzione è chiamata power law, difficile da distinguere da polinomiale ad occhio nudo, quindi applichiamo log a y = x^-alfa. In questo modo ottengo una funzione lineare data da log 2 y = -alfa log 2, utilizzando un grafo log log scale (1 2 4 8).
Power law indica anche numero di strongly connected components ed altre proprietà del web.
-Locality, molti link in un dominio riportano a pagine dello stesso dominio
-Similarity, pagine dello stesso dominio condivideranno molti link.
Basandomi su queste 3 proprietà posso usare Web Graph Compressor algorithm.
Come funziona LSH? Quali sono due versioni dell’algoritmo?
Locality sensitive hashing algorithm si basa su Hamming distance (numero di bits differenti), che permette di costruire similarity partire da un bit vector che rappresenta un elemento = numero di bits totali - Hamming distance / bits totali.
Se effettuiamo delle proiezioni di un elemento per confrontare due vettori, evitando costo lineare per confronto, possiamo vedere come probabilità che vettori dichiarati uguali = similarity s. Se effettuiamo k proiezioni s^k.
Probabilità di errore quindi 1 - s^k.
k è inversamente proporzionale a falsi positivi e direttamente proporzionale a falsi negativi.
LOCALITY SENSITIVE HASHING
Parte da questo concetto, iterando per L volte, con proiezioni di dimensione k. Crea una fingerprint di un vettore con tutte le proiezioni di dimensione k. La probabilità che ci siano dei falsi positivi = 1 - [1 -s^k]^L
Abbiamo due versioni algoritmo:
Offline, che costruisce le varie proiezioni, per poi ordinarle in base al i-esima proiezione trovando vettori simili. Una volta fatto questo costruisce connected components, per i quali vale proprietà transitiva. Si avanza i e si ordina per successiva proeizione.
Online, abbiamo L hash table, dove inseriamo ogni proiezione. Se collisione inseriamo piu elementi. Per ogni query L accessi alle hash table, per tutti i documenti retrieved poi effettuo confronto tra vettori, volendo evitare false positives. Dove numero di celle per hash table = 2^k. Poichè k posizioni possono rappresentare 2^k elementi.
K-Means vs LSH
K-Means trova local optimal, mentre LSH trova clusters con alta probabilità.
K-Means compara vettori, LSH compara sketch.
K-Means richiede poche iterazioni, mentre LSH elementi piccoli, pochi scan.
K deve essere conosciuto in anticipo per K-Means, mentre LSH non deve conoscerlo in anticipo.
Posso applicare K-Means ad LSH.
Come trovare duplicati Exact Match?
Per exact match posso:
-Fare confronti brute force tra tutti elementi
-Fare confronti tra tutti elementi, ma solo di fingerprint
-Ordinare fingerprint ottenute in modo da ottenere cluster di elementi uguali
Algoritmo che utilizzo per fingerprint Karp Rabin, tra pattern da matchare e documento.