Search

Caricamento in corso...
23.12.10

Enterprise Search: gli elementi fondamentali e accenni sui costi

Nel post Searching e finding: le caratteristiche di un sistema di information retrieval ho descritto alcuni degli elementi tipici, cognitivi, metodologici, tecnologici necessari per la progettazione di un sistema di enteprise search, qui vorrei proporne una breve schematizzazione. Ricordiamo anche che i sistemi di enterprise search e quelli dedicati alla web search, Google e Bing ad esempio, sono molto diversi come è ben spiegato da Mark Bennett in 20+ Differences Between Internet vs. Enterprise Search.

-Elementi cognitivi: le conoscenze, gli scopi, le strategie e le tattiche dell'utente che effettua una ricerca. Argomenti affrontati diffusamente nei precedenti post.
-Elementi di processo di produzione e diffusione delle informazioni: chi produce i contenuti, come sono prodotti, come sono strutturati se sono strutturati, grado di complessità del dominio, perché si producono contenuti, quali sono i meta dati ideali secondo cui strutturare informazioni non strutturate, come riutilizzare i contenuti etc..
Testo classico di riferimento 'Content management bible' di Bob Boiko, on line ci sono molte risorse sul content inventory, per esempio nel sito di Donna Spencer troviamo link interessanti.
-Elementi tecnologici:
Motori di ricerca. Ne esistono molti sia open source che proprietari. La soluzione open source più popolare è Solr Lucine, è anche quella che conosco meglio perchè utilizzatata in tutti i progetti che ho seguito. Tra i motori proprietari più diffusi ricordiamo Vivissimo, Fast, Autonomy, Endeca e Google. Una fonte interessante sul mondo dei sistemi ricerca enterprise è Searchtools.
GUI ovvero la grafical use interface, l'elemento più importante che incide sulla esperienza dell'utente nell'interazione con le applicazioni, in particolare supporta le strategie di ricerca dell'utente. Un buon riferimento l'articolo di  Wilson, Schraefel e White (2007) Evaluating Advanced Search Interfaces using Established Information-Seeking Models.

Tassonomie, ontologie e tools di supporto alla costruzione delle tassonomie-ontologie. Questi elementi servono sia al miglioramento della precision e della recall quando utilizzati per la mappattura dei documenti sia per aumentare le funzionalità di search e quindi il supporto alle diverse strategie di ricerca abilitate dalla GUI (alberi di navigazione, suggestion, autocomplete, did you mean, faceted navigation, filtering etc)
CMS e ECMS ovvero i content management system ed enterprise content management system. Sono i software che consentono di archiviare, editare, pubblicare, condividere e cercare i contenuti sul web e/ o nelle intranet, i primi sono più economici e meno complessi mentre i secondi incorporano le funzionalità dei primi e offrono altre sofisticate funzionalità, come il supporto ai processi di business, risultando molto più complessi e costosi. Secondo Gartner ciò che rende una soluzione propriamente enterprise è determinato anche dalle caratteristiche del vendor come l'ampiezza del mercato, il numero dei partner tecnologici, la solidità finanziaria etc.. L'offerta di queste soluzioni, dunque, è davvero ampia, diversificata e la scelta del prodotto critica. Ecco alcuni fonti che aiutano a conoscerne il panorama e a supportarne la scelta :
Sistemi di monitoraggio

Metodologia in breve:
1) Analisi del modello di business, analisi dei requisiti funzionali e di sistema, analisi del contenuto, analisi del processo di produzione e fruizione dei contenuti
2) Esplicitazione delle specifiche, configurazione motore di ricerca, costruzione ontologie, progettazione GUI, analisi di fattibilità, scelta del vendor, valutazione costi tempi
3) Deployment, testing, monitoraggio e improvement
Le fasi suddette naturalmente saranno in molti casi iterative e non lineari

I costi di un sistema di enterprise search: tecnologici e sociali.
Nella guida InfoWorld Test Center Guide: Content management systems si afferma in definitiva che il costo di tali sistemi può andare dai 25.000 dollari ai milioni di dollari. Si consideri inoltre il costo della costruzione di una tassonomia, i prezzi di Intellisophic, importante fornitore di tassonomie di dominio, sono di circa 5 dollari a nodo a cui bisogna aggiungere i costi per l'eventuale estensione della tassonomia che consistono in tool di supporto, ad esempio, Semaphore la piattaforma di SmartLogic e nella consulenza di esperti di dominio.
In una realtà complessa diciamo una banca è possibile che i costi tecnologici e di progetto siano più facili da sopportare rispetti ai costi 'sociali', mentre è più facile che in una realtà piccola sia vero il contrario. Intendo per costi tecnologici e di progetto quelli legati propriamente al progetto stesso ipotizzando che tutti gli attori decisionali e non di una organizzazione siano d'accordo nell'adottare un sistema di information retrieval e siano collaborativi rispetto al processo di progettazione.
I costi sociali sono quelli causati da una non collaborazione di uno o più attori dell'organizzazione destinataria del progetto. Questo può accadere per molteplici ragioni che non non starò ad elencare, bisogna sapere però che quando ciò si verifica il progetto è destinato a fallire o ad avere costi spropositati. E' importante che tutti siano incentivati a contribuire al successo del progetto oppure è meglio lasciar perdere se il contesto è molto conflittuale o passivo.
18.12.10

I paramentri base per valutare un information retrieval system: recall, precision e relevance. Parte 2

Nel post precedente ho esaminato un caso realistico per valutare le performance di un motore di ricerca dove nell'ultimo esempio l'operatore booleano era OR: la recall era di 1/3 e la precision 1/4
Questi risultati non sono soddisfacenti o sono addirittura disatrosi in contesti reali. Con un sforzo logico proviamo, infatti, ad immaginare se i nostri documenti fossero non 7, ma 7000 avremmo una recall, nel caso di OR, esagerata e una precision bassissima, in pratica la SERP sarebbe composta da decine, forse un centinaio di risultati  tra i quali sarebbe impossibile individuare quelli interessanti. I risultati ottenuti non pertinenti sono i cosiddetti falsi-positivi.









Google infatti, che indicizza milioni di pagine web, non a caso utilizza l'operatore AND di default!
Nel caso di AND, infatti, avremmo invece una recall molto più bassa e una precision  più alta, ma ancora rimarrebbero fuori molti documenti utilissimi, i cosiddetti falsi-negativi. In Google questo normalmente non rappresenta un grosso problema perché appunto c'è una ridondanza altissima quindi l'utente presumibilmente troverà quasi sempre risultati soddisfacenti.
In alcuni casi non sarà immediatamente così e quindi sia per mezzo delle funzionalità messe a disposizione da Google sia grazie alle strategie messe in atto dall'utente più esperto si otterranno i risultati desiderati. Google, per esempio, offre la possibilità di eseguire query correlate oppure di estendere la ricerca morfologicamente e semanticamente aumentando la recall e fornendo altri risultati. Analogamente un utente esperto può utilizzare gli operatori in modo più sofisticato. Con questi meccanismi si agisce sempre sulla recall,  la precision e la relevance.
In conclusione quindi per avere un motore di ricerca performante  bisogna  trovare un modo per bilanciare recall e precision e ottenere risultati ottimali.  Argomenti dei prossimi post saranno appunto i meccanismi e le soluzioni che si possono adottare per migliorare un sistema di information retrieval.
30.11.10

I paramentri base per valutare un information retrieval system: recall, precision e relevance. Parte 1

I paramentri base rispetto a cui per valutare un information retrieval system ovvero un motore di ricerca
Tra tutti elementi che compongono un buon sistema di Enterprise Content Management citati da AIIM, il sistema e le tecnologie di search e retrieval sono essenziali e costituiscono l'argomento principale di questo blog.
I paramentri base rispetto a cui per valutare un information retrieval system sono:
la recall: il rapporto tra il numero dei documenti rilevanti che il sistema ritorna dopo la query  il numero dei documenti  rilevanti effettivamente esistenti nel nostro database di riferimento
la precision: il rapporto tra il numero dei documenti rilevanti restituiti dal sistema  e il totale dei documenti restituiti dalla query
la relevance: quando ognuno di questi documenti risultanti in seguito alla query è importante rispetto al mio scopo di ricerca. Si esplica nell'ordinamento dei risultati: un meccanismo, ad esempio, è dato dalla capacità del motore di contare la frequenza dei termini  presenti nel documento, maggiore frequenza termini= maggiore rilevanza
Un motore di ricerca ben progettato deve soddisfare i suddetti parametri contemporaneamente. Esistono  tecnologie, metodologie e tools che aiutano a raggiungere questi obiettivi migliorando gli algoritmi di search, molti motori di ricerca sono integrati o/e consentono tramite API di sfruttare questi approcci per migliorare le performance del motore di ricerca.
Come funziona un motore di ricerca. Alcuni esempi.
Vediamo qualche esempio 'estremo' per semplificare.  Voglio consultare tutti i documenti in cui si parla delle  condizioni fiscali connesse con l'acquisto di una casa e le tasse relative alla casa (scopo pagare meno tasse possibili, tattica: conoscere il regime fiscale relativo, etc..).
Ci sono più modi per formulare questa query come del resto nei documenti pertinenti ci sono più modi di esprimere questo concetto.  Uno dei problemi principali consiste nel gap tra la query e la formulazione del concetto nel documento, un buon motore colma questo gap.

esempi di search  query 
a) Fisco acquisto case
b) Condizioni per detrazione fiscale acquisto casa
f)...

documenti  presenti nel repository o database
A) Fisco. Agevolazioni prima casa
B)la casa sotto osservazione del fisco per scoprire gli evasori
C)Prima casa 2010 Agevolazioni fiscali: quanto vale l’imposta di registro
D) agevolazioni fiscali per recupero del patrimonio edilizio
E) Case abusive come regolarizzarsi col catasto: norme fisco
F) Le case più costose nel mercato italiano
G) le tasse sulla casa

Meccanismi  e leve di recall e precision
In un sistema ideale mi piacerebbe trovare tutti i documenti che mi interessano (recall) vorrei che tutti i documenti siano pertinenti (precision) e che siano ordinati secondo l'importanza che hanno rispetto al mio scopo di ricerca (relevance). Se cio fosse vero rispetto alla query a) dell'esempio mi aspetto come risultato nella SERP ( search engine result page)  A) C) G) così ordinate.Nella fig. 2 i risultati ideali sono indicati dal cerchio numero 2.
La prima ipotesi da fare è circa l'operatore booleano configurato: per la query a) ad esempio, possiamo avere AND (nel documento devono essere presenti [fisco] AND [acquisto] AND [case] contemporaneamente per ottere dei risultati) oppure OR ( è sufficiente che solo una parola  [fisco]OR [acquisto] OR [case] sia presente nel documento per ottenere dei risultati [fisco] [acquisto] [case] ). Vedi fig.1

fig 1. I documenti presenti nel nostro database e gli operatori booleani




Supponiamo dunque di digitare nel box di ricerca la query  a) fisco acquisto case, e che l'operatore configurato sia  AND, in questo caso non otterremo nessun risultato perchè in nessun documento pertinente sono presenti esattamente e contemporaneamente le tre parole, quindi la recall è pari a o.  E' una pessima performance
Vediamo cosa succede se per la stessa query l'operatore fosse invece OR.

Otteniamo i risultati E), B), A), F)   quindi una recall di 1 su 3, (è migliorata). Vedi fig. 2 e 3
Osserviamo però che la precision è solo di 1 su 4 ovvero tra i documenti restituiti solo uno risponde alle mie esigenze (documento A) inoltre  l'ordinamento non è assolutamente soddisfacente poichè A compare dopo risultati non pertinenti. Vedi fig 4
Sappiamo anche che ci sono documenti pertinenti e utilissimi che non compaiono assolutamente nella search, i cosiddetti falsi negativi (documento C e G). 
Anche questo risultato non è soddisfacente o addirittura disatroso in contesti reali. Nel prossimo post vediamo perchè, capiremo come Google affronta il problema e tireremo le somme del nostro esperimento

fig. 2 Risultati della search nel nostro esempio con l'operatore OR
















Fig 3. Recall nel nostro esempio

fig 4 Precision nel nostro esempio
27.5.08

Searching e finding: le caratteristiche di un sistema di information retrieval

Il capitolo dedicato al search e al finding del libro Information Architecture for Information Professional di Sue Batley comincia con questa considerazione: dato che durante la ricerca e il finding l’utente attua molteplici strategie-tattiche e che maggiori sono le sue competenze per performarle maggiore sarà la probabilità di ottenere risposte soddisfacenti allora il migliore sistema di information retrieval è quello che supporta il maggior numero e tipo di strategie in modo user friendly.
Il modello detto 'berrypicking' proposto da Marcia Bates (The design of browsing and berrypicking techiques for on-line search interface) infatti incorpora sia le strategie di analytical searching che quelle di finding (browsing or foreging).
Le strategie di analytical searching sono ulteriormente descritte nell’approccio building block e pearl-growing di Harter, e la tecnologia a supporto di questo tipo di strategia è il motore di ricerca, Google ad esempio. E’ una strategia iterativa e il successo dipende sia dai feedback del motore di ricerca che, come già accennato, dalla capacità del searcher di interagire col sistema. 
Le tecniche base che un motore di ricerca deve consentire sono
A) Poter combinare i termini (ricerca logica, di frase e prossimità)
B) Modificare i singolo termini:wildcards e troncamento
C) Restringere il campo della ricerca: campi e limiti
Queste sono discusse tutte in modo esaustivo dall’autrice attraverso esempi.
Il finding, il trovare, è invece basato sulla struttura che organizza l’informazione. L’informazione e i contenuti vengono organizzati in strutture e navigando tra queste noi troviamo ciò che cerchiamo. Le strutture si basano sui sistemi di classificazione o-e sulle tassonomie o ontologie, possiamo affermare dunque la tecnologia che supporta questo tipo di strategie è appunto la tassonomia o l'ontologia: quanto migliore è la sua costruzione tanto più alta la possibilità di trovare ciò che cerchiamo. 

26.5.08

Information Architecture for Information Professional Designer di Sue Batley, breve recensione

Information Architecture for Information Professional Designer di Sue Batley, esperta di Information Retrieval Systems alla London Metropolitan University, è un libro che si propone di dare delle guideline pratiche per sviluppare, valutare e mantenere efficiente un sistema informativo che ha l’ obiettivo di rendere accessibile l’informazione.

Come afferma l’autrice, infatti:

‘The aim of a information architecture is to create well-structurated, attractive and one deployed, well-maintained information system that allow user to search for and retrieve information quickly and efficentely’.


In questa ottica la progettazione del sistema deve essere basata sui core concepts dell’architettura dell’informazione: indicizzazione, classificazione, catalogazione e user-center design. I primi tre concetti riguardano l’organizzazione dell’informazione, il quarto discute il modo in cui deve essere resa accessibile agli utenti.

E’ una analisi dunque indirizzata alle diverse professionalità che si occupano dell’organizzazione e gestione della conoscenza e delle informazioni in generale, e delle biblioteche in particolare. Le figure professionali e le specifiche competenze (skills) degli architetti dell’informazione sono illustrate negli ultimi paragrafi, al fine di ricapitolare tutte le questioni implicate nella progettazione.

L’autrice dopo avere fornito una definizione di architettura dell’informazione (Cap 1) nei successivi 6 capitoli spiega come affrontare le singole ‘fasi’ della progettazione, ognuna delle quali ha un ‘esperto ideale’

2. Conoscere profondamente gli utenti, Information Audit and Task Analysis

3. Le funzioni di searching e finding

4. Descrizione dei documenti e gestione del contenuto, Dubline Core e Thesauri

5. Design dell’interfaccia

6. Gestione e manutenzione dell’architettura dell’informazione

7. Metodi per valutare architettura, applicati in tutte le fasi in modo iterativo

Normalmente ‘i professionisti dell’informazione’ entrano nel merito delle diverse fasi anche se difficilmente possono padroneggiarle, la materia è troppo vasta. Quindi questo libro si rivela utile per avere una visione d’insieme e un linguaggio comune dell’intero processo progettuale. Ogni ‘fase’ è discussa evidenziando i fondamenti e lo stato dell’arte, fornendo sia le basi teoriche che le applicazioni pratiche.

Molto utili sono anche i riferimenti argomentati nel testo alle più importanti organizzazioni che sviluppano e-o adottano determinati sistemi di information retrieval e che sono facilmente accessibili on-line. Ulteriore risorse per approfondire sono suggerite alla fine di ogni capitolo, i guru del settore relativo, oltre alla usuale bibliografia di riferimento.

Ho trovato ovvio, ma non superficiale, il capitolo dedicato all’interface design, proprio perché è il tema con cui ho maggiore familiarità, mentre in ognuno degli altri ho sempre colto stimoli nuovi per ulteriori approfondimenti. Diversamente, un bibliotecario potrà rimanere ‘folgorato’ dal concetto di affordance di Norman e sorvolare sulle caratteristiche della classificazione della Library of Congress.

Il libro si apre e conclude con due cattive notizie: prima di tutto, non esiste un sistema ideale preconfezionato e universalmente valido, il Capitolo 2 e 3 argomentano questa criticità e ci illustrano i metodi per fare il meglio possibile a seconda del contesto; in secondo luogo, il sistema deve essere continuamente monitorato e aggiornato perché l’informazione è una materia vivente e la conoscenza sempre in evoluzione,a questo proposito ho trovato il capitolo 6 ‘ Management and Maintenance, con la gerarchia del processo di McKeever’s ‘semplice’ e illuminante.

Nel prossimo post un approfondimento sul capitolo dedicato al finding e searching

19.5.08

I fondamentali dell’E-Commerce: non solo marketing. Le strategie dell’utente, cosa cerca come e perché.

Si enfatizza molto il ruolo del posizionamento del sito web sui motori di ricerca e il pay per click, quando ciò che conta è il tasso di conversione e di fidelizzazione ovvero il fatturato. Sempre più diffusi i tools che consentono di valutare e comparare le specifiche campagne marketing (come i web analytics), e-o i comportamenti degli utenti, (i web-tracking), per poi scoprire che la user experience è il fattore più importante.

Con piacere ho constatato che al Forum sul e-commerce, organizzato da Netcomm il 14 giungo a Milano, gli interventi hanno affrontato la ‘questione e-commerce’ come sistema e processo complesso da pesare costantemente intorno all’utente, in questo caso al consumatore.

Nei paesi anglosassoni, dove è nato lo user center design, la user experience è al centro delle strategie dello sviluppo del web e sappiamo che il web 2.0 ha il suo core nell’intelligenza collettiva più che nel marketing e nella tecnologia di per sé. Certo si continua a parlare di marketing e tecnologia, ma come viral marketing, marketing esperienziale e co-design ovvero includendo sempre l’utente, i suoi bisogni ludici, informativi, creativi, partecipativi.

Ma ciò che è fondamentale per un sito e-commerce è la capacità di supportare le strategie di ricerca dell’utente, al tempo stesso idiosincratiche e cognitivamente determinate.
Per essere esatti l’utente cerca e trova, e qualsiasi sia la natura del sito queste azioni imprescindibili.

Quindi come responsabile del marketing di prodotto di Intellisemantic devo approfondire tutti gli aspetti che riguardano l’information retrieval. Non è sufficiente conoscere i bisogni di business dei nostri partner e il mercato di riferimento, ma occorre avere una visione completa delle problematiche legate a questo universo, aggiornarsi per discernere i fads, le soluzioni ‘alla moda’ e quelle davvero sostanziali.

E’ anche vero che l’Italia presenta un quadro diverso, e mi si può obbiettare che l’arretratezza italiana giustifichi la trascuratezza della progettazione, eppure sono convinta che sia tale superficialità nel design a contribuire allo scoramento di tanti potenziali utenti del web.

Quindi voglio condividere questo approccio con le letture ed eventi che mettono al centro l’utente, e i metodi e le tecnologie per un information retrieval system efficace e user friendly.

Il prossimo post è dedicato al libro Information Architecture for Information Designer di Sue Batley Senior Lecturer in Information Managemented ed esperta di Information Retrieval Systems alla London Metropolitan University.

4.4.08

Il mock up sulla carta e l'irritazione del mio programmatore


Alle volte nel mio lavoro non è semplice: 
  • comunicare con il cliente
  • comunicare con il boss
  • comunicare con sviluppatore
per via dei gap tra i modelli mentali

Definizione non scientifica di modello mentale: è una specie di incrostazione che si attacca alle sinapsi, è originata da conoscenze e skill acquisiti e ti impedisce di metterti nei panni di un altro, di vedere le cose da un altro punto di vista, quello della mitica casalinga di Voghera ad esempio, o per ritornare al nostro soggetto quella della logica dei processi cognitivi

Backside effects: interfaccia inusabile e/o fallimento del progetto

Frasi tipiche del programmatore a cui fai notare che l'interfaccia è incomprensibile, pronunciata con una certa stizza: ' Ma come, è ovvio!'

Soluzione: Il mock up sulla carta ovvero il paper prototyping
è uno strumento indispensabile per la progettazione e la comunicazione anche se all'inizio i tuoi interlocutori ti guardano come un creativo fallito o un bimbo dell'asilo

Ora con il programmatore, il mio amico e collega Davide, c'è un'armonia perfetta e non potrei far nulla senza la sua dedizione bravura e soprattutto...pazienza!
Con il cliente e il boss c'è ancora da lavorare...