Progettare un querybot per posizionarsi su Google Suggest

Riprendo l’idea del posizionamento su Google Suggest introdotta in un articolo precedente per impostare la progettazione di un querybot per la simulazione di ricerche su Google.

Posto che l’aumento di visibilità di una query su Google Suggest può essere conseguenza di fenomeni che vanno ben oltre l’incremento di ricerche della query, ho ritenuto comunque opportuno progettare un sistema che produca un volume minimo di ricerche sulla query da posizionare.

Questo è il comportamento che vorrò dare al querybot:

• una distribuzione naturale delle ricerche durante la giornata
• la simulazione di un affinamento della ricerca: prima [keyword], poi [keyword brand]
• la simulazione del click sul link che punta al sito del brand (possibilmente senza sporcare le statistiche del sito con una reale visita)

Il primo dei comportamenti indicati l’ho ottenuto abbozzando graficamente una distribuzione realistica degli accessi dai motori di ricerca durante l’arco di una giornata (ho tratto ispirazione dai reali accessi di un sito) e sfruttandola come base per distribuire le query automatizzate.

Il querybot verrà chiamato da un cronjob e ad ogni chiamata effettuerà X query, con X che varia a seconda della fascia oraria e a seconda della quantità giornaliera di query che si intende raggiungere.

Per semplificare il calcolo di X, ho usato un semplice foglio excel, il cui risultato potete osservare nell’immagine allegata al post.

Per calcolare il valore “Queries per script call”, è sufficiente fornire le seguenti informazioni:

Volume of daily queries to produce: la quantità complessiva di query giornaliere da effettuare. Tale quantità va calcolata in base al totale di query mensili che si desiderano e, per essere perfettini, dovrebbe in teoria essere variabile per simulare la diversa affluenza degli utenti sul web (e sui motori) durante l’arco della settimana. Ma per il momento mi accontenterò della simulazione delle fasce orarie.

Total activity in 24h: questa è la somma dei valori provenienti dal grafico “Hour activity”, che rappresenta una distribuzione abbozzata delle ricerche degli utenti nell’arco della giornata. I valori variano da zero (nessuna attività) a dieci (attività massima).

Script called every X minutes: questo dato indica ogni quanti minuti lo script per la simulazione delle ricerche verrà chiamato dal cron.

Immesse queste informazioni, la colonna “Queries per script call” (QSC) viene popolata con la quantità di query che lo script dovrà effettuare ad ogni chiamata.

Si noti che i valori QSC sono con virgola ma che ciò non rappresenterà un problema in fase di implementazione. Per esempio, se il QSC di una fascia oraria è 2,824858757, ad ogni chiamata lo script effettuerà due query (la parte intera di QSC) più una query condizionale, con probabilità pari a 0,824858757.

Tenuto conto che lo script verrà chiamato diverse volte durante la stessa ora, le query condizionali produrranno più o meno la quantità complessiva di query giornaliere che si desiderano raggiungere.

Il sistema progettato ha il vantaggio di mantenere fissa la frequenza di lanci dello script (così mi risparmio la modifica del cronjob) producendo senza difficoltà la quantità di query desiderata, che potrà anche variare nel tempo nel caso in cui dovessero cambiare le esigenze sui volumi da produrre.

Whatsup 0.2: sorgenti dei dati e query importanti

Nel precedente post su Whatsup 0.2, segnalavo che una novità introdotta in questa nuova versione era l’indicazione di quali keyphrase, nei cluster, potevano essere considerate più importanti di altre. Ripubblico per comodità l’immagine del cluster già usata nel post precedente e vi invito a dare un’occhiata alle keyphrase evidenziate in neretto.

Ovviamente la definizione di che cosa è importante o meno è squisitamente arbitraria: acquisite informazioni e segnali che esistono attorno alle ricerche del momento, la scelta di che cosa considerare più importante l’ha fatta il sottoscritto.

Come ho deciso di muovermi? Innanzitutto dalla versione 0.2, Whatsup inizia ad acquisire dati da più fonti.

Riguardo le fonti dalle quali è possibile ottenere informazioni in tempo reale sulle ricerche degli utenti, degli hint ben espliciti erano stati dati pubblicamente già durante il mio intervento al Convegno GT del 2009, incentrato su Google News (ecco la presentazione usata durante l’intervento).

A colleghi e compagni di aperitivi, inoltre, ho sempre sciorinato diversi dettagli di metodo e implementativi: molto era sostanzialmente incentrato sul monitoraggio del Google Suggest del servizio Google News.

Whatsup 0.2 ottiene però informazioni provenienti da altri strumenti in grado di riportare dati in tempo reale sulle abitudini di ricerca degli utenti. Di bello c’è che tali nuove fonti sono ben compatibili con la fonte usata finora e consentono di incrociare i dati in maniera molto armonica.

Il concetto di “maggiore importanza” che ho tirato fuori è nato in modo molto spontaneo: ad essere considerate più importanti sono quelle ricerche riportate da più di una fonte. Una banalissima intersezione ha permesso di mixare sia la caratteristica di freschezza tipica del suggest di Google News sia aspetti più quantitativi, acquisiti da fonti molto usate dagli utenti ma aggiornate meno frequentemente o con criteri diversi di quelli usati da Google per il suggest delle notizie.

I risultati ottenuti, come potete notare dall’immagine pubblicata in questo post, non sono davvero niente male e le keyphrase evidenziate in neretto dall’algoritmo sembrano anche coincidere con le keyphrase che le fonti stesse indicano esplicitamente come le più cercate.

Ovviamente un dettaglio su quali siano le nuove fonti non verrà fornito, perché l’obiettivo dei miei post su Whatsup è quello di produrre un diario degli aspetti informatici del progetto e non un vademecum completo che permetta ad altri di replicare esattamente il mio lavoro.

Il prossimo post sarà incentrato sulla versione 0.3 di Whatsup e sulla produzione automatizzata delle mappe mentali.

Whatsup 0.2: rinominare i cluster

Whatsup è e rimarrà uno strumento semplice, votato all’appoccio KISS.

La ragione di tale scelta è che dovrà macinare informazioni che gli arrivano da Google in qualche modo già filtrate; il fatto che si tratti delle keyphrase che mostrano un picco di ricerche, rappresenta a tutti gli effetti una prima selezione operata dagli stessi utenti, prima ancora che dal motore di ricerca.

Tuttavia l’esiguità dei dati ed il fatto che l’approccio al clustering sia strettamente statistico, impone dei limiti nel momento in cui si vuol tentare di migliorare un po’ il risultato.

Uno dei due obiettivi della versione 0.2 di Whatsup era quello di rivedere i nomi da assegnare alle categorie (parlo al passato perché nel momento in cui scrivo è già pronta la versione 0.3).

Nella versione 0.1 i nomi dei cluster erano scelti estraendo semplicemente la singola parola più frequente nelle keyphrase, spostando in un cluster così nominato le keyphrase che contenevano la parola stessa e ripetere il processo cercando la nuova parola più frequente nelle keyphrase rimanenti.

Se date un’occhiata all’immagine della mappa mentale pubblicata sul post iniziale di Whatsup 0.1, noterete che i cluster prodotti con questo criterio presentavano parole quasi sempre ben correlate con il nome del cluster, ma a volte la scelta era “sgraziata”.

Per esempio il cluster che conteneva le keyphrase “asse terrestre” e “asse terrestre spostato” acquisiva semplicemente il nome “terrestre”.

Nella versione 0.2 di Whatsup sono stati dunque aggiunti dei controlli per rinominare ciascun cluster con espressioni di due o più parole contigue (si veda Ngram), purché presenti più di una volta nelle keyphrase associate al cluster stesso.

Potete osservare il risultato della modifica nell’immagine presente su questa pagina.

La soluzione funziona molto bene con i nomi propri di persone perché naturalmente composti da almeno due parole. E l’osservazione può essere ovviamente estesa anche ai nomi propri in genere, come si può notare dalla presenza di un cluster chiamato “explorer 9”.

Esiste tuttavia un rischio nel rinominare i cluster in questo modo: assegnando un nome più specifico ci si allontana dalla genericità attorno alla quale il cluster è stato costruito. Il che significa che una volta rinominato, il cluster potrebbe presentare al proprio interno keyphrase generiche concettualmente più distanti dal nuovo nome.

Questo effetto negativo non si coglie dall’immagine allegata al presente post ma non mancherò di farvelo notare nelle prossime clusterizzazioni quando capiterà. Va detto però che tale problema è stato minimizzato con l’acquisizione di una maggiore quantità di keyphrase, come spiegherò quando tratterò la versione 0.3 del software.

Ho anche scritto che la rinominazione dei cluster era il primo di due obiettivi che mi ero posto di raggiungere nella versione 0.2; qual’era il secondo?

Come potete notare nell’immagine, alcune keyphrase appaiono in neretto e sono le keyphrase che l’algoritmo giudica più “importanti” di altre. Nel prossimo post scriverò come tale selezione è stata operata.

Whatsup 0.1: tipologia dei dati e algoritmo di clustering

L’algoritmo di clustering che ho sviluppato è estremamente semplice ma riesce ad ottenere discreti risultati nonostante l’esiguità di dati.

Il “nonostante” si applica perché in Information Retrieval la bontà di molte soluzioni non si fonda principalmente sulla qualità degli algoritmi bensì sulla qualità delle informazioni sulle quali gli algoritmi devono lavorare.

Uno stesso algoritmo può produrre risultati scadenti se applicato a pochi dati e risultati ottimi se applicato a basi di dati molto grandi. Google non è il leader nell’IR solo perché sviluppa buoni algoritmi ma anche perché disponde di una gigantesca quantità di informazioni sulla quale farli macinare.

Le informazioni prese in esame da Whatsup sono le keyphrase cercate dagli utenti su Google e, trattandosi nello specifico delle sole keyphrase che in un dato istante mostrano un picco di ricerche, la loro quantità è limitata. Attraverso i metodi che sto sfruttando al momento, la quantità delle keyphrase “hot” che è possibile estrarre da Google varia da 100 a 200 elementi.

Fortunatamente, nonostante la quantità non sia alta, i dati possiedono caratteristiche che vengono facilmente incontro anche all’algoritmo di clustering più semplice. In particolare, gli utenti sul Web cercano informazioni su uno specifico soggetto digitando ricerche molto diverse, varianti che fanno uso di sinonimi e altre che ripropongono le stesse parole in ordine differente.

A seguito di un’estrazione di keyphrase “di picco” da Google capita quindi che diverse di esse facciano riferimento allo stesso tema, usando parole e variazioni leggermente diverse, ma facilmente accomunabili da una o più parole in comune.

Di fronte a questi elementi di similarità, ho pensato che buoni risultati potessero essere ottenuti anche con un semplice algoritmo di clustering che cercasse nelle keyphrase la presenza di parole “importanti”. Ma cosa si intende per “importante”?

Il concetto di importanza va definito. Nel contesto in cui sto operando, ovvero un elenco di keyphrase “hot”, una parola che posso considerare importante potrebbe essere una parola che si ripete in più keyphrase. Più sono le keyphrase in cui la parola è presente e più essa può essere considerata importante per questo specifico contesto.

Tradotto in numeri, significa che il mio concetto di importanza si può limitare per il momento a calcolare la frequenza di ciascuna parola all’interno del corpus (in questo caso l’elenco delle keyphrase) e considerare importanti i termini che sono più frequenti.

Il metodo funziona bene solo se tiene conto del fatto che esistono particelle linguistiche che possono apparire frequentemente nelle keyphrase (articoli, preposizioni, ecc.) ma che non dovrebbero essere considerate importanti.

Le soluzioni per evitare che le particelle del discorso frequenti in lingua italiana inficino i risultati, sono sostanzialmente due: usare una lista di stop words oppure riuscire ad assegnare un peso inferiore o nullo a tali termini sfruttando statistiche su un corpus più grande.

Nonostante io possieda un grande storico delle ricerche su Google (in particolare su Google News), nella versione 0.1 di Whatsup mi sono limitato a usare una semplice lista di stop words. E’ stato veloce, indolore ed i risultati non sono niente male. Ovviamente le versioni successive di Whatsup preferiranno implementare soluzioni basate sull’analisi di dati storici.

Ho preso una lista di stop words italiane da qua, ne ho aggiunta qualcuna che mancava all’appello (es: “quando”) e ho prodotto una seconda lista di termini molto generici, come “news”, “notizie”, “video” o “ansa”. Ho infatti deciso di gestire normalmente questi termini tranne che durante la scelta dei nomi da attribuire ai cluster, che desidero incentrare su parole più specifiche.

Ecco dunque di seguito l’algoritmo finale di Whatsup 0.1, già obsoleto nel momento in cui scrivo ma che vi riporto perché nei post successivi sarà più facile spiegare il motivo di alcuni cambiamenti fatti nelle versioni successive del software, via via che ho acquisito visibilità sulla qualità della classificazione.

1. Estraggo la parola più frequente nelle keyphrase (escludendo le stop words)
2. Creo un cluster e lo chiamo come la parola trovata
3. Assegno al cluster tutte le keyphrase che contengono la parola
4. Una volta che una keyphrase viene assegnata ad un cluster, viene tolta dal bacino di keyphrase dalle quali estrarre, al prossimo giro, la nuova parola più frequente
5. Prossimo giro: si torna al punto 1 fino a quando ci saranno parole ripetute in almeno due keyphrase diverse
6. A questo punto rimarranno solo keyphrase che non contengono alcuna delle parole usate per dare nome ai cluster. Per ciascuna keyphrase non assegnata, l’assegno al cluster che condivide con essa la quantità maggiore di parole.
7. Tutto ciò che rimane termina in un cluster speciale che chiamo “UNCATEGORIZED”

Pubblico nuovamente l’immagine con il risultato del clustering dell’algoritmo appena descritto.

Nei prossimi post vedremo i limiti del presente approccio e che cosa ho deciso di cambiare nelle versioni successive di Whatsup.

Whatsup 0.1, la genesi

Mentre attendo che la pasta cuocia, vi scrivo il primo di una serie di post attraverso i quali vi darò visibilità del nuovo software che sto progettando.

Come forse qualcuno avrà intuito da qualche mia passata partecipazione al Convegno GT, è da un po’ di tempo che mi interesso di Google News.

Oltre a incamerare una quantità industriale di informazioni sul motore di ricerca verticale, ho trovato il modo per avere accesso alle ricerche in tempo reale fatte dagli italiani. Si tratta di informazioni che Google non divulga esplicitamente ma alle quali è possibile arrivare smontando il giocattolo e cercando dentro.

Il primo risultato di questa ricerca si chiama Whatsup, un software attualmente in fase embrionale ma già in grado di fornire dati interessanti a chiunque debba scrivere articoli e notizie online (e non solo); conoscere in tempo reale i temi a cui gli italiani sono interessati è un’informazione dal valore altissimo.

Lo screenshot che trovate su questa pagina mostra non semplicemente un elenco delle keyphrase estratte da Google ma anche una sua elaborazione: ho implementato un algoritmo di clustering nel tentativo di mettere ordine a informazioni prive di struttura.

Inizialmente ho ipotizzato di poter sfruttare un algoritmo della classe K-Means ma successivamente mi sono reso conto che, almeno nelle sue implementazioni più semplici, il K-Means non sarebbe andato bene per i miei scopi.

Nelle forme più semplice del K-means, infatti, la scelta dei cluster iniziali può avvenire attraverso criteri un po’ deboli: a volte persino facendo una scelta casuale. Nel tipo di classificazione che volevo ottenere io, invece, avrei desiderato ottenere una definizione dei cluster fondata su una prima analisi dei dati stessi.

La seconda perplessità sull’uso di un K-means è collegata al fatto che la quantità di dati da classificare (le keyphrase) è abbastanza bassa: intorno al centinaio di elementi. Di fronte a queste quantità e ad un numero di cluster potenzialmente elevato, fino a qualche decina, non è detto che il concetto cardine sul quale si basa il K-Means (la ridisposizione in spazi multidimensionali di elementi che condividono caratteristiche) si riveli in grado di produrre buoi risultati.

Insomma, mi son detto che non conveniva smobilitare la NASA per classificare un centinaio di keyphrase e quindi ho sviluppato un mio algoritmo di clustering, a mio parere più adatto a quanto volevo ottenere. Per esempio la scelta dei nomi dei cluster avviene facendo delle statistiche sulle parole più frequenti nel gruppo di keyphrase.

Il risultato potete notarlo nello sceenshot già citato. Dati e classificazione sono fatti dal software, la mappa mentale l’ho creata a mano con XMind.

Notate che si tratta solo della prima versione dell’algoritmo di clustering e che nel momento in cui scrivo questo primo post sono già giunto a versioni superiori e a mio parere migliori sotto molti aspetti, che tratterò nei post successivi di questa serie.

Salumi e caci.