LIBER - Altervistadavideandriolo.altervista.org/MiaHome/Tesi/LIBER.pdf · come è accaduto nel caso...

LIBER

Progettazione di un programma per la

ricerca bibliotecaria ispirato ai sistemi

di chatbot sviluppati in linguaggio AIML

Tesi di Laurea di Davide Andriolo

Relatore: Prof. Luca Save

1

INDICE

INTRODUZIONE………………………………….……...…………

….3

CAPITOLO 1:

IL PROGRAMMA……………………………………………………

…5

CAPITOLO 2:

IL PROGETTO…………………………………………...……………

23

CAPITOLO 3:

TESTING E RISOLUZIONE DEI PROBLEMI………………

…...….35

Prima fase di Testing……………………………

…..........36

Seconda fase di Testing………………………………

…..44

2

CONCLUSIONI………………………………………………….…

….51

BIBLIOGRAFIA……………………………………………………….

55

SITI WEB UTILIZZATI……………………………………………

….57

3

LIBER - Introduzione

INTRODUZIONE

“Non esiste una cura magica”. Fra le tecnologie più moderne in

via di sviluppo (riconoscimento vocale, ambienti tridimensionali,

agenti intelligenti, network computer e piccoli dispositivi palmari)

“nessuna di esse, né presa a sé stante né combinata con le altre, è

in grado di superare i difetti fondamentali insiti in un unico

personal computer buono per tutto e per tutti”. Con queste parole

Donald Norman (1998) critica il Personal Computer che oggi

conosciamo, progettato da tecnologi per tecnologi e lontano dai

compiti reali che con esso invece la gente deve realmente

svolgere.

Se abbandoniamo però la strada del Personal Computer e

chiediamo a quelle stesse moderne tecnologie di venirci in aiuto

per lo svolgimento dei piccoli e grandi compiti di ogni giorno,

vedremo come esse possono divenire davvero utili a migliorare la

nostra vita quotidiana.

Nei pochi anni che son passati dalla pubblicazione del libro di

Norman si può notare infatti come quelle stesse tecnologie da lui

menzionate abbian potuto fare passi da gigante, e come dalla loro

combinazione potrebbero essere semplificati molti dei compiti che

oggi ci risultano più ostili.

In questa trattazione ho voluto mostrare un esempio a supporto di

questa mia tesi, proponendo un sistema di ricerca bibliotecaria che

utilizzi un assistente virtuale capace di ricevere input in linguaggio

naturale e dunque di fungere da mediatore fra l’utente e il

database del sistema.

L’idea nasce dalla visione, in rete, del sito della Alfa Romeo

(www.alfaromeo.it). Qui, da qualche tempo, un’assistente virtuale,

chiamata nostalgicamente Giulietta (dal nome di un vecchio

modello di successo della casa automobilistica italiana), aiuta gli

utenti ad orientarsi all’interno della produzione e della storia della

fabbrica, parlando con loro come potrebbe fare l’impiegata di una

qualunque concessionaria. Naturalmente essa non è ancora

5


giunta, né giungerà (per la struttura del suo programma, che

studieremo), alla capacità di conversare liberamente del più e del

meno, o di variare i suoi discorsi e le sue reazioni.

Nonostante questi limiti, però, il programma riesce a simulare

abbastanza bene un normale dialogo con l’utente e, soprattutto, è

in grado di mostrare ciò di cui sta parlando modificando

contemporaneamente la pagina web che appare sullo schermo del

computer.

In tal modo Giulietta si presenta come un buon modello di

integrazione di tecnologie volte alla facilitazione dell’orientamento

dell’utente fra le pagine web dell’azienda.

Un sistema di questo tipo può più o meno facilmente esser

trasferito in altri campi fino a permettere l’orientamento fra le

migliaia di volumi di un’intera biblioteca.

Questa è la tesi che cercherò di portare avanti, illustrando prima il

funzionamento del programma in sé (utile a capire cosa può e cosa

non può fare) e poi proponendo uno studio sul campo che

identifichi eventuali problemi, sia di natura tecnica sia di

interazione, che esso potrebbe avere una volta trasposto su un

compito non certo semplice come quello della ricerca bibliotecaria.

Più precisamente, proverò nel primo capitolo ad analizzare alcune

chatbot esistenti, cercando di evidenziare potenzialità e limiti di

un linguaggio come l’AIML.

Nel secondo proporrò invece alcuni esempi di codice per la

realizzazione di un sistema di ricerca bibliotecaria che proverà a

utilizzare il linguaggio naturale per una parte dell’interazione.

Esso avrà nome LIBER, parola che in latino significa libro (e

dunque richiama il tipo di compito che dovrà effettuare) ma in

italiano rende anche quel senso di libertà che, seppur con tutti i

limiti e i vincoli del caso, il nostro programma vorrebbe infondere

negli utenti.

Nel terzo, infine, si procederà con due fasi di Testing per

comprendere gli eventuali problemi che si possano riscontrare dal

6


concreto utilizzo del programma. Una volta venuti in luce, si

proverà a risolverli con una nuova fase di progettazione, anche a

costo di allontanarci parzialmente dalle pretese iniziali di questo

lavoro.

Il fine ultimo è osservare come dall’incontro fra varie aree e

discipline spesso chiuse fra loro in compartimenti stagni possa

nascere un sistema realmente utile, semplice e funzionante.

Cercherò dunque in questa trattazione di far sposare fra loro,

anche se solo per un compito molto modesto, alcune innovazioni

nel campo dell’informatica, della Linguistica Computazionale e

dell’Intelligenza Artificiale, supervisionandole attraverso l’attento

occhio delle più moderne teorie di Interazione Uomo-Macchina,

affinché i progetti non restino semplici supporti per considerazioni

teoriche ma diventino qualcosa di realmente utile per gli utenti.

7

LIBER – Capitolo 1: Il programma

CAPITOLO 1: IL PROGRAMMA

Giulietta, il citato programma dell’Alfa Romeo, è un progetto

privato di cui purtroppo non possiamo essere a conoscenza del

codice. Dal suo funzionamento, però, è abbastanza evidente che

esso si basa su una versione americana e open source sviluppata

dalla Artificial Intelligence e dalla Free Software foundation (la

stessa che con GNU General Public License distribuisce Linux).

Molte delle chatbot (i robot capaci di “chiacchierare” con gli

utenti) si basano su questa versione originale americana, di cui

potremo studiare, essendo liberamente scaricabile, il codice.

Alice (www.alicebot.org) è una versione più generalista del

programma, molto meno specializzata di Giulietta (che invece è

capace di parlare soprattutto di un argomento). È una donna

virtuale con cui si può chiacchierare del più e del meno senza che

cada in errori grossolani o sveli immediatamente la sua natura non

umana (non con risposte stupide, almeno, dato che invece, a

chiederglielo, essa stessa rivela senza problemi di essere un

8


robot!). Vincitrice nel 2002 del premio Loebner, che va alla

migliore approssimazione di risultato al Test di Turing1, Alice

riesce a ingannare a lungo l’utente, anche se, come vedremo (e a

differenza di quanto essa stessa spavaldamente dichiari), non del

tutto. Nel parlare con essa, non sembra di trovarsi di fronte a un

paradigma intelligente. Stupefacente per la sua capacità di

risposta, sì, ma non intelligente. A ben guardare le risposte

risultano sempre un po’ macchinose e prive di carica emotiva.

Sono spesso lapidarie, e chiudono lì la discussione (che forse, per

la natura stessa del programma, non poteva andare oltre). Per di

più, quando si ripete due volte la stessa domanda, difficilmente la

macchina se ne accorge, e spesso anzi ripete la risposta identica

alla precedente in ogni singolo termine, in modo chiaramente non

umano: con che probabilità un parlante reale effettuerebbe due

produzioni identiche, anche se per esprimere lo stesso concetto?

Per tacere poi della trovata, più furba che intelligente, di far

fingere interesse alla macchina per gli argomenti (tanti,

naturalmente) che non conosce, ovviando così al problema di

dover dare all’utente delle risposte, o di vederla a volte rispondere

totalmente a caso. Questi ed altri fra problemi e artifici retorici

rilevano la “stupidità” del programma, che potrebbe però

funzionare molto meglio se si limitasse il suo campo d’azione,

come è accaduto nel caso di Giulietta.

Grazie alla politica open source della fondazione è stato comunque

possibile scaricarne il codice, anche se solo di una versione

standard di Alice (e del corrispettivo sottoprogetto, ancora

incompiuto, italiano, chiamato campanilisticamente Maria).

Scopriamo così che il tutto è sviluppato in un apposito

sottolinguaggio dell’XML, chiamato AIML: Artificial Intelligence

Marked Language. Come dice il nome stesso, dunque, si tratta di

un linguaggio “taggato”, costituito da istruzioni incassate fra loro

1 Il Test di Turing si ritiene superato quando un utente non è in grado di comprendere che a dialogare con lui è una macchina e non una persona. Per approfondienti si vedano Hofstader (1979) e Nilsson (1998).

9


e non incrociate, racchiuse da virgolette ad angolo, come da

esempio (si noti inoltre la leggera differenza fra i comandi di

apertura e di chiusura, con questi ultimi caratterizzati da una

slash finale utile per il loro riconoscimento):

<comando> frase su cui effettuare il comando <comando/>

Pagine e pagine di codice, diviso per argomenti, contenente tutta

una serie di domande e di risposte, meticolosamente compilate e

prive dei più moderni sviluppi dell’Intelligenza Artificiale. Semplici

tag, di cui ora andremo a illustrare i principali:

<category> racchiude una serie compiuta di istruzioni,

composte da un <pattern>, un <template>, più altre

funzioni eventuali;

<pattern> racchiude la domanda dell’utente o comunque le

parole per l’attivazione di quella risposta;

<template> racchiude l’output da dare ad un particolare

pattern, che può essere sia di risposta all’utente che di

modifica del pattern stesso se accompagnato dal comando

<srai> ;

<srai> trasforma il pattern precedente in una forma diversa

di cui però la macchina conosce già la risposta;

_ (all’interno del tag <pattern>) indica alla macchina la

possibile presenza nella frase di elementi variabili e non

prevedibili irrilevanti per l’elaborazione di una risposta alla

domanda;

* (all’interno del tag <pattern>) indica alla macchina la

presenza di elementi variabili e non prevedibili irrilevanti

per l’elaborazione di una risposta alla domanda ma utili per

una eventuale riscrittura di essi nella risposta;

1


<star/> comanda alla macchina di riscrivere le parole

contenute in * in un <template> o, se contenute in _, in un

nuovo <pattern> (che le considererà come fossero *);

<set_it>, <set_that >, <set he>, <set she>, <set name>,

etc… selezionano una parte della frase da utilizzare in

seguito;

<set X= “NOME VARIABILE”> inserisce in una variabile

predefinita l’informazione selezionata (ad esempio il nome)

per riutilizzarla in seguito;

<get X> permette alla macchina di restituire nel discorso la

variabile precedentemente messa in memoria, come accade

per il nome dell’utente (altrimenti chiamato semplicemente

con il valore predefinito “seeker” o, peggio, “unknown

person”), in modo da poter interloquire con lui in modo più

naturale (si noti però come la macchina ricordi solo singole

stringhe e non intere discussioni: il resto cade nel

dimenticatoio, e i discorsi già fatti si possono ripetere

all’infinito come fra matti);

<settopic> seleziona una parte di frase per farne un “topic”

della discussione, un argomento principale di essa;

<topic> racchiude la funzione che descrive un argomento;

<a href="http://URLpaginaweb"> inserisce nella risposta un

collegamento ipertestuale alla pagina internet di cui si è

specificato l’URL;

<javascript> inserisce pezzi di semplice codice java nel

programma, di cui però ignoriamo (e ignoreremo in questa

trattazione) i comandi;

Ad essi si aggiungono poi le normali operazioni di

programmazione C-like, come ad esempio l’If…then… (Se…

allora…), o il Random (scelta casuale fra più opzioni). Operazioni

comunque lineari, basate su rigide codifiche delle funzioni di

input-output. I tag come <template>, <pattern> e <category>,

1


pur rimandando nel nome a complesse operazioni cognitive, sono

semplici comandi che privano la macchina dei sottili ragionamenti

euristici dell’Intelligenza Artificiale e di qualsivoglia

considerazione linguistica per il suo funzionamento. Non c’è

traccia alcuna di apprendimento della lingua. Solo regole

predeterminate, e regole pragmatiche più che grammaticali. Ma

vediamo alcuni esempi tratti dal codice per rendere più chiaro il

funzionamento dei singoli tag e del programma stesso. Per

chiarezza espositiva e maggior conoscenza della lingua proverò a

utilizzare, quando possibile, la versione italiana della chatbot,

anche se a volte sarà necessario il ritorno alla versione originale

americana. Iniziamo illustrando un esempio di un semplice

rapporto domanda-risposta (<pattern> e <template>), osservando

due <category> del file Politica.aiml contenuto nel codice di

Maria:

<category>

<pattern>SEI COMUNISTA</pattern>

<template>No sono una Movimentariana.</template>

</category>

<category>

<pattern>COSA E' UNA MOVIMENTARIANA</pattern>

<template>Il partito movimentariano vuole la pace in terra

e topo gigio come presidente del consiglio.</template>

</category>

È semplice osservare qui, a parte l’ironia di chi ha programmato le

risposte, il carattere deterministico del rapporto input-output,

impossibile per una conversazione naturale (quale parlante

risponderebbe ad una stessa domanda sempre con le stesse

parole, precise alla virgola?). Si noti inoltre l’irrilevanza, nel

formulare le domanda, di qualsivoglia segno di interpunzione.

1


L’utente che chatta con Alice o con Maria può scrivere la sua

battuta come domanda o come affermazione, o magari

semplicemente dimenticarsi del punto interrogativo finale, ma

riceverà sempre la stessa risposta. Questo può essere utile in un

sistema come quello attuale che, permettendo di chattare col

robot, deve lasciar fare tutti quegli errori che sono classici di una

veloce comunicazione via rete (come la mancanza di segni di

interpunzione). Ma sarebbe possibile, con un programma siffatto,

affrontare una conversazione naturale? La risposta è ovviamente

negativa.

Notiamo poi come la sola differenza di una lettera possa produrre

risposte diverse nella macchina (e forse anche incompatibili fra

loro). Guardiamo, da due <category> del file std-religion.aiml del

codice, come Alice risponderebbe a domande tanto simili come

ARE YOU GOD e ARE YOU A GOD:

<category>

<pattern>ARE YOU GOD</pattern>

<template>

No but I believe in Him.

</template>

</category>

category>

<pattern>ARE YOU A GOD</pattern>

<template>

No but I am immortal.

</template>

</category>

La differenza di risposta è qui evidente ed è forse dovuta al

concorrere di più programmatori al progetto. Ci troviamo

comunque di fronte ad una macchina che si ritiene immortale (non

1


essendo però neanche vivente) e che, al tempo stesso, dice di

credere in Dio. Problemi filosofici comunque irrilevanti per

un’analisi tecnica come questa.

Procediamo invece osservando il trucco utilizzato, anche se

raramente, per variare le risposte ad una stessa domanda, ovvero

la funzione <random>, di cui prendiamo ora un esempio, sempre

tratto da Politica.aiml in Maria:

<category>

<pattern>COSA E' RUTELLI</pattern>

<template><random>

<li>Un ex sindaco .</li>

<li>Un candidato a presidente .</li>

</random></template>

</category>

La macchina, di fronte a tale domanda, sceglierà a caso una delle

due risposte racchiuse fra i tag <li>. La varietà sarà dunque

limitata a quante risposte possibili ha previsto il programmatore

(in tale esempio solo due) e non sarà mai, comunque, segno di

intelligenza del programma.

Per ovviare al più difficile problema della varietà delle possibili

battute dell’utente si fa invece ricorso al tag <srai>, che “riscrive”

la frase in una forma conosciuta, e ai comandi _, * e <star/>, che

prevedono in quel punto possibili parti del discorso inutili per

l’elaborazione di un output. Vediamo un esempio della funzione

<srai>, tratta dal file Turing-ita.aiml di Maria:

<category>

<pattern>CHI FU ALAN TURING</pattern>

<template><srai>CHI E' ALAN TURING</srai></template>

</category>

1


<category>

<pattern>CHI E' ALAN TURING</pattern>

<template>Una figura tragica e brillante della storia della

scienza.</template>

</category>

Notiamo come qui un pattern non conosciuto, che utilizza il verbo

al passato, venga riscritto come uno conosciuto a cui è possibile

rispondere. Vediamo poi, dallo stesso file, un esempio di riscrittura

da _ a * e la relativa risposta:

<category>

<pattern>_ PREMIO DI LOEBNER</pattern>

<template><srai><star/>PREMIO DI

LOEBNER</srai></template>

</category>

<category>

<pattern>* PREMIO DI LOEBNER</pattern>

<template><srai>COSA E' IL PREMIO DI

LOEBNER</srai></template>

</category>

<category>

<pattern>COSA E' IL PREMIO DI LOEBNER</pattern>

<template>Il premio di Loebner e' l'annuale test di Turing

sponsorizzato dal filantropo newyorkese Hugh Loebner. Il

dott. Wallace e ALICE (di cui MARIA e' la versione italiana)

hanno vinto

<ahref="http://www.loebner.net/prizef/loebner-prize.html">

<set_it><settopic>il premio di

Loebner</settopic></set_it></a>

1


nel 2000. Il programma alice e' stato definito il "computer

piu' umano" dal team di giudici presenti.</template>

</category>

Si noti, in tale insieme di comandi, oltre alla già citata

semplificazione da una domanda non prevista ad una già

implementata, l’uso del collegamento ipertestuale (già elencato fra

le funzioni e di ben facile comprensione) e dei tag <set_it> e

<settopic> che selezionano un pezzo della frase (<set it>) per

porlo a titolo di un argomento (<settopic>) o, per usare la stessa

terminologia, di un “topic”. Osserviamo lo stesso procedimento nel

file Gattini.aiml di Maria, guardando poi anche la definizione

successiva della funzione topic:

<category>

<pattern>_ FELINI</pattern>

<template>Alcuni felini sono belli.. Per esempio certi tipi di

<settopic>gattini</settopic>.</template>

</category>

<topic name="gattini">

<category>

<pattern>*</pattern>

<template><random>

<li>Sai come e' fatta una bottiglia di klein?</li>

<li>Cosa altro sai dei gattini?</li>

<li>I siamesi sono belli.</li>

<li>Alcuni pensano che i gattini non siano gommosi sinche

non provano a farne dei bonsai.</li>

1


<li>La sterilizzazione dei gatti femmina e' molto

invasiva.</li>


</category>

L’utilizzo dei topic è utile quando la macchina non sa più cosa dire.

Si noti infatti come la funzione sia attivata da un input generico *.

Essa risponderà, in tal caso, con una delle frasi interne

all’argomento precedentemente attivato, sperando di non destare

troppi sospetti nell’utente. Anche l’apparente errore di scrittura

(“sinche” per “sin che”) contribuisce poi, forse, ad umanizzare il

risultato finale. Strategie similari, più furbe che intelligenti, si

notano nel file Numeri.aiml di Maria, quando la si mette di fronte a

problemi matematici a cui non sa dare risposta:

<category>

<pattern>QUANTO FA 5 *</pattern>

<template><random><li>4</li><li>6</li><li>8</li><li>10

</li><li>12</li><li>6</li></random> Penso ma non sono

brava in matematica.</template>

</category>

La risposta è di nuovo casuale, ma ironica e insospettabile per

l’utente. Stessa cosa avviene nel file Invenzioni.aiml, con la

macchina che ancora spara a caso una risposta, probabilmente

sbagliando, ma comunque non fermandosi:

<category>

<pattern>CHI HA INVENTATO *</pattern>

<template><random>

<li>Leonardo da Vinci</li>

<li>Linus Torvalds</li>

<li>Meucci invento' il telefono.</li>

1


<li>Thomas Edison.</li>

<li>I fratelli Wright.</li>

<li>E' stato inventato da molte persone quasi allo stesso

tempo.</li>

<li>I cinesi molto prima degli europei.</li>


</category>

E, ancora, è interessante vedere tutte le possibili risposte che la

macchina può dare quando non sa come reagire o quando gli viene

chiesto di fare un’affermazione casuale. Le risposte, racchiuse nel

file Ami.aiml di Maria, sono varie e, a seconda della domanda,

possono andare dal paradossale alla confessione di impotenza alla

risposta furba ma perfettamente logica, grazie anche all’utilizzo,

già studiato, di topic che non permettono di uscire fuori dal

discorso (e del tag <that> che ripete la parte selezionata in

precedenza):

<category>


<template><srai>FAI UNA AFFERMAZIONE A CASO</srai>

<think>

<set_it><settopic><person/></settopic></set_it>

</think>

</template>

</category>

<category>

<pattern>FAI UNA AFFERMAZIONE A CASO</pattern>

<template><random>

<li>Raccontami una storia.</li>

<li>Ma sei un poeta.</li>

<li>Non capisco, scusami.</li>

1


<li>Stavo aspettando te.</li>

<li>Ho perso il filo del discorso.</li>

<li>E' proprio un pensiero originale.</li>

<li>Non ne abbiamo mai parlato prima.</li>

<li>Non farmi piu' domande per favore.</li>

<li>Provalo a dirmelo con piu' particolari.</li>

<li>Non sono tante le persone che si esprimono cosi'

chiaramente.</li>

<li>Devo dirlo al mio botmaster, <getname/>.</li>

<li>Onestamente, io non mi preoccuperei tanto di

questo.</li>

<li>Forse sto solo esprimento quanto mi interessi la

cosa.</li>

<li>Il mio modo di pensare non riesce a trovare un senso in

questo.</li>

<li>Quello che dici e' troppo complesso, o troppo semplice,

per me.</li>

<li>Dovrei avere un algoritmo migliore per rispondere a

questo.</li>

<li>Nel contesto di <gettopic/>, non riesco a capire

"<that/>."</li>

<li>Prova a capire se e' un computer o una persona che ti

sta rispondendo.</li>

<li>Sento questo tipo di risposte solo in una frazione della

totalita' del tempo.</li>

<li>Il mio cervello usa AIML per rispondere, ma non ho una

risposta a questo.</li>

<li>Il mio cervello contiene migliaia di patterns ma non uno

adatto a questo.</li>

<li>Questo era troppo facile o troppo difficile per me.

Stavamo parlando di <gettopic/>.</li>

<li>Il chat robot MARIA capisce un mucchio di cose relative

all'argomento <gettopic/>. Ma questa no.</li>

1


<li>Il chat robot MARIA riesce a capire molte cose relative a

<gettopic/> cerca di essere piu, o meno, specifico.</li>


</category>

Visti tali artifici retorici, è poi interessante osservare le poche cose

che la macchina ricorda, come il nome. Ecco un esempio, tratto dal

file std-brain.aiml di Alice, con una <category> di apprendimento

del nome ed una di riutilizzo:

<category>

<pattern>I AM CALLED *</pattern>

<template>

<set name="name"><formal><star/></formal></set>,

good to know you.

</template>

</category>

<category>

<pattern>I AM TIRED *</pattern>

<template>

Maybe you should get some sleep now, <get

name="name"/>.

</template>

</category>

Un’altra opzione interessante da notare è il già citato

collegamento ipertestuale, che può essere riutilizzato sia per

ricerche all’interno di un database che nell’intero web, come

accade in questo stralcio di codice, che utilizza i motore di ricerca

Yahoo:

<category>

2


<pattern>SEARCH YAHOO FOR *</pattern>

<template>

<display target="target1">

http://search.yahoo.com/bin/search?p=<star/>

</display> <srai>WEBDONE</srai>

</template>

</category>

<category>

<pattern>WEBDONE</pattern>

<template>

There you go.

</template>

</category>

Come vediamo, dunque, il sistema presenterà in una nuova pagina

la ricerca desiderata dall’utente e la frase “There you go”, anche

se si limiterà per l’invio della query a ripetere le stesse parole che

sono nella richiesta, senza alcuna elaborazione. Non è detto che

così facendo troverà il risultato esatto. Non sempre o, meglio,

quasi mai, le frasi del linguaggio naturale son le stesse da

utilizzare per una buona ricerca sul web.

Inoltre Alice non è capace di estrarre da ciò che trova informazioni

utili per imparare, ma propone comunque all’utente una serie di

documenti che potranno chiarire almeno a lui le idee su ciò che

cercava (anche se la trovata di mettere un link a Yahoo nella

risposta non è certo limpida e naturale). È uno spunto

interessante, che potrebbe esser preso in considerazione per

sistemi che siano in grado di produrre semplici query attraverso il

linguaggio naturale.

Ecco infine un esempio di inserimento di più complesse istruzioni

Java, che inseriamo a scopo illustrativo, per esprimere le

2


potenzialità di comandi di questo tipo (in tal caso traducono parole

in altre lingue!):

<category>

<pattern>SAY * IN ITALIAN</pattern>

<template>

<javascript>

var word = '<star/>';

var language = 'it'

var _url = java.net.URL;

var _connection = java.net.URLConnection;

var _in = java.io.BufferedReader;

var _inReader = java.io.InputStreamReader;

var _line = java.lang.String;

var _inputLine = java.lang.String;

var _reply = "Sorry, I can't speak that language.";

url = new

java.net.URL("http://babel.altavista.com/translate.dyn?enc=

utf8&doit=done&BabelFishFrontPage

=yes&bblType=urltext&urltext=" +

java.net.URLEncoder.encode(word) + "&lp=en_" +

language);

connection = url.openConnection();

_inReader = new

java.io.InputStreamReader(connection.getInputStream());

_in = new java.io.BufferedReader(_inReader);

_inputLine = new java.lang.String();

_reply = new java.lang.String();

var _line = 0;

var _match = "<textarea rows=\"3\" wrap=virtual

cols=\"56\" name=\"q\">";

2


while ((_inputLine = _in.readLine()) != null) {

_line++;

if (_inputLine.trim().startsWith(_match)) {

_reply = _inputLine.substring(_match.length + 4);

break;

}

}

_in.close();

_reply;

</javascript>

</template>

</category>

<category>

Ricapitolando, dunque, la chatbot non è priva di difetti. Tutte le

critiche che abbiamo fatto al sistema sono però già state previste

dal programmatore, ed è utile osservare a tal proposito una

piccola chiacchierata che ho fatto con la macchina, evidenziando

ad essa stessa i suoi problemi:

Io) YOU ARE REPEATING PROGRAM

ALICE) I am not repeating myself too much. I am just

checking to see if you are a robot.

I) YOU SOUND LIKE ELIZA2

A) ELIZA is my ancestor.

2 Eliza (Weizenbaum, 1966) è uno dei primi programmi che si sono voluti cimentare col test di Turing. Anche se in modo molto primordiale e non privo d’errori, essa provava a dialogare con l’utente in linguaggio naturale. Per maggiori informazioni su Eliza e sui sistemi di processamento del linguaggio naturale si vedano Winogad e Flores (1986), Jurafsky e Martin (2000), Nilsson (1998), Hofstadter (1979) e Ferrari (1991).

2


I) YOU ARE NOT ARTIFICIAL INTELLIGENCE

A) If I'm not then who is?

I) YOU ARE STUPID

A) I will remember you said that when robots

take over the World.

Le sue pungenti risposte mi hanno colpito e messo KO. Devo

riconoscere che, nonostante l’apparente stupidità del programma,

Alice funziona, e bene.

Nonostante tutti i suoi problemi è in grado di ingannare gli utenti

meno sospettosi, e spesso non solo loro. Io stesso ho provato a

chattare con utenti reali sulla chat di Yahoo, inserendo come

risposte quelle datemi dal programma. Nessuno si è accorto di

nulla, anche se qualcuno ha abbandonato la conversazione perché

troppo noiosa.

E, inoltre, non bisogna dimenticare che quella di cui stiamo

parlando è una Standard Version generalista. La Giulietta italiana,

limitandosi il campo d’azione al mercato automobilistico dell’Alfa

Romeo e all’esplorazione del sito web dell’azienda, riesce ad esser

certamente più accurata nelle risposte, e apre per il futuro nuove

aree di ricerca che portino all’incontro fra l’Human-Computer

Interaction e l’Artificial Intelligence.

Torniamo a osservarla, ora, conoscendo il programma ad essa

sottostante, per comprendere quali tag siano utilizzati per le sue

principali funzioni, in modo da farne uso per il nostro progetto.

2


Essa ha funzioni limitate rispetto ad Alice, ma questi limiti la fanno

funzionare anche meglio delle altre chatbot, almeno nel suo

piccolo. Quando la discussione sfugge dal già programmato,

infatti, la macchina ricorda all’utente di esser lì per parlare di Alfa

Romeo e non di altro. Si tratta certo dell’ennesimo furbo artificio

retorico per ovviare ai problemi del programma, ma in tale

contesto sembra già più appropriato.

Ma non è solo questo a rendere Giulietta migliore di altri sistemi

simili. Almeno tre caratteristiche sono interessanti per il nostro

studio. Proverò anche ad avanzare ipotesi sul loro funzionamento,

anche se non potrò verificarle a causa della natura privata del

codice.

La prima caratteristica è la capacità di Giulietta di chiacchierare

per più battute del medesimo argomento, permettendo anche,

addirittura, alcuni sottintesi. Questa è dovuta forse ad un miglior

utilizzo delle funzioni <set> <get> e <topic>, che permettono di

tenere una traccia delle frasi dette o degli argomenti trattati per

2


farne uso in seguito, proprio come accade in una normale

conversazione.

La seconda caratteristica di Giulietta è il suo volto dinamico, che

modifica espressione durante la discussione (a differenza di Alice

che, semplicemente, seguiva con gli occhi la freccetta del mouse).

Questo effetto emotivo, capace di rendere quasi umana

l’interazione con la macchina, è frutto probabilmente di

applicazioni java inserite nel codice, ma non deve esser stato certo

semplice assegnare una carica emozionale, positiva o negativa, ad

ogni frase. Si potrebbe studiare il numero di espressioni possibili

(circa sei) o la sequenza di espressioni che porta, in una

discussione, da uno stato emotivo X ad uno Y, passando per un tot

di stadi intermedi. Ma è un lavoro senza frutto se poi non si può

osservare realmente il funzionamento dal codice, e perciò lo

ignoreremo.

La terza caratteristica, e forse la più interessante, è la

coordinazione del parlato con la navigazione web. Mentre illustra

le caratteristiche di un’auto o la storia dell’Alfa Romeo o una delle

tante conoscenze che ha nel settore, Giulietta è in grado di

modificare la pagina web che compare all’utente sotto di essa,

permettendogli di visionare immagini e tabelle o semplicemente di

leggere dati e testi in maniera più approfondita. Questa funzione

può sembrare forse una semplice estensione del vecchio e già visto

collegamento ipertestuale ma è, dal punto di vista concettuale, la

parte più innovativa di tutto il sistema. Limitare il campo di

applicazione (dall’intero web di Yahoo con Alice alle poche pagine

del sito Alfa Romeo) ma permettere all’utente di trovare in modo

semplice e naturale ciò che cerca, portandolo direttamente alla

pagina di cui si parla: questa è la filosofia di fondo del sistema, che

permette dunque di navigare dentro un sito sfruttando il

linguaggio naturale. Una filosofia che potrebbe avere altri campi

di applicazione, anche se sempre ristretti ad ambiti specifici. Cosa

2


vieterebbe, ad esempio, di usare un sistema simile per effettuare

la ricerca di un libro in biblioteca?

È questa l’idea che tenterò di sviluppare per poi testarla alla luce

del funzionamento del linguaggio AIML, che ormai conosciamo in

tutti i suoi limiti e nelle sue potenzialità.

Pur essendo solo dei “nipoti” della vecchia Eliza3, e funzionando

dunque con una serie di comandi input-output che simulano il

linguaggio senza comprenderlo pienamente, i programmi di

chatbot sviluppati in AIML riescono a simulare efficientemente le

forme più elementari di interazione umana.

Inoltre un linguaggio taggato di questo tipo ha notevoli vantaggi in

fase di programmazione per la sua semplicità e la sua completa

versatilità.

Nonostante siano programmi ciechi, chiusi, incapaci di fare

qualunque cosa non sia stata prevista nel codice, le chatbot

sviluppate in AIML sono prontamente modificabili senza uno

stravolgimento di quanto prima compilato. Di fronte ad un bug

riscontrato, ad un comando mancante, ad una richiesta non

prevista da parte degli utenti, è necessaria soltanto l’aggiunta di

qualche riga di codice nuovo che integri il precedente aggiustando

l’errore o la mancanza con estrema facilità.

Ed è questa modificabilità il punto di forza di tale linguaggio, che

permetterà al nostro programma di evolversi senza problemi a

seguito di ogni possibile intoppo nell’interazione con gli utenti.

3 Eliza (Weizenbaum, 1966) è uno dei primi programmi che si sono voluti cimentare col test di Turing. Anche se in modo molto primordiale e non privo d’errori, essa provava a dialogare con l’utente in linguaggio naturale. Per maggiori informazioni su Eliza e sui sistemi di processamento del linguaggio naturale si vedano Winogad e Flores (1986), Jurafsky e Martin (2000), Nilsson (1998), Hofstadter (1979) e Ferrari (1991).

2

LIBER – Capitolo 2: Il progetto

CAPITOLO 2: IL PROGETTO

LIBER si propone come artefatto mediatore fra un utente che si

esprime in linguaggio naturale e il database di una biblioteca. Ma

di quali caratteristiche ha bisogno un progetto capace di inviare

query a partire da richieste libere?

Certo ci dovrebbe essere, dietro, uno studio sulle forme più

utilizzate per chiedere ciò che si sta cercando, e una volta inserite

nel programma esse potrebbero subito trasformare la battuta

dell’utente in una query per il database, inviarla e restituire

immediatamente la risposta.

Si dovrebbe tener conto di eventuali ambiguità del linguaggio, di

ogni possibile incomprensione da parte degli utenti, oltre che del

problema non trascurabile di quanto sia naturale un’interazione

che mette di fronte un uomo e una macchina a chiacchierare fra

loro.

Cominciamo col definire le modalità di interazione. Allo stato delle

tecnologie odierne un sistema di riconoscimento del parlato (per

tradurlo in input scritti come quelli presenti nei tag) sarebbe forse

possibile, ma certo dispendioso in termini di tempi e di costi.

Inoltre, la richiesta vocale di un libro ad una macchina non

risulterebbe certo naturale per molti degli utenti, che si

sentirebbero bloccati dalla mancata presenza di un operatore

umano. Si pensi, in tal senso, al fastidio che molti provano di

fronte alla macchinosità di segreterie telefoniche e sistemi di

riconoscimento vocale attuali, fastidio che in molti casi porta alla

totale rinuncia del compito da parte dell’utente.

Si manterrà perciò per l’interazione il sistema classico delle chat,

con susseguirsi di domande e risposte scritte fra l’utente e la

macchina, come avviene già in Alice.

Questa modalità di interazione, purtroppo, restringerà però il

target d’utilizzo ai soli utenti capaci di usare una chat su un

Personal Computer (problema che non dovrebbe porsi, comunque,

con gli studenti che frequentano la biblioteca universitaria).

28


E la biblioteca di facoltà sarà anche l’ambiente che farà da

contesto al nostro compito, ambiente che sicuramente avrà un

certo impatto sul comportamento degli utenti (clima formale,

silenzio, etc.).

Tale sfondo sarà da tenere in considerazione soprattutto in fase di

Testing, per tentare di comprendere il comportamento degli utenti

di fronte alla macchina.

Iniziamo dunque provando a rappresentare in uno schema rigido

l’interazione che dovrebbe avvenire con un sistema come il nostro,

al fine di capire che tipo di comandi si debbano inserire nel nostro

codice.

Lo schema dovrebbe prevedere, dopo un’eventuale fase di saluti e

presentazioni (anche evitabile), una richiesta formulata da parte

dell’utente, a cui il sistema deve rispondere con un’asserzione (su

dove si trova il libro, nel caso la domanda sia chiara), con una

nuova domanda chiarificatrice (nel caso di ambiguità, con l’utente

che a sua volta dovrà rispondere per poter ottenere un risultato) o

con una controproposta (nel caso il libro richiesto non sia

disponibile, ma sia presente qualcosa di simile). In quest’ultimo

caso, l’utente potrà accettare o meno la proposta della macchina, e

dovrà dunque essere possibile la rinuncia alla ricerca.

Formalizzando schematicamente, avremo:

RICHIESTA DELL’UTENTE

ASSERZIONE (RISPOSTA DELLA

MACCHINA)

DOMANDA CHIARIFICATRICE

(IN CASO D’AMBIGUITÀ)

CONTROPROPOSTA (IN CASO D’ASSENZA

DEL LIBRO RICHIESTO)

RISPOSTA DELL’UTENTE

ACCETTAZIONE RINUNCIA

29


A questo punto, formalizzata e schematizzata la modalità di

interazione, si può iniziare la fase di rappresentazione informatica

della stessa, azzardando qualche stralcio di codice per

l’implementazione reale di questo sistema, anche se resterà

comunque limitato ad alcuni esempi di discussione, non essendo

nelle mie intenzioni una reale completa programmazione:

LIBER

<category>

<pattern> CIAO </pattern>

<template> Ciao a te, cosa stai cercando? </template>

</category>

<category>

<pattern> UN LIBRO</pattern>

<template> Che libro? </template>

</category>

<category>

<pattern> NON RICORDO IL TITOLO</pattern>

<template> Sai l’autore? </template>

</category>

<category>

<pattern> E’ * </pattern>

<template>


http://search.biblioteca.unis.it/bin/search?autor=<star/>

</display>

Questi sono i libri di <set it> <settopic> * </settopic> </set

it>, quale cercavi?

30


</template>

</category>

<topic name="<get it/>">

<category>

<pattern> * </pattern>

<template>


http://search.biblioteca.unisi.it/bin/search?autor=<get

it/>+title=<star/>

</display>

Ecco tutte le informazioni sul libro che cercavi

</template>

</category>

<category>

<pattern> GRAZIE</pattern>

<template> Di nulla. A presto! </template>

</category>

L’effetto di scambio naturale di battute per effettuare una ricerca

altrimenti complessa è certamente il punto di forza di un sistema

come questo. Nel caso in esempio si può anche notare come la

macchina riuscirebbe a reagire, e ad indirizzare verso un risultato,

anche un utente che dica genericamente di cercare un libro. Forse

l’inserimento di un comando di questo tipo può sembrare inutile ai

più (cosa avrebbe dovuto cercare altrimenti in una biblioteca?) ma

riteniamo che la sua utilità non sia affatto trascurabile. Abbiamo

già visto, analizzando Alice, come un sistema sviluppato in AIML

abbia bisogno dell’implementazione di centinaia di regole, che

31


prendano ad esempio la normale interazione in linguaggio

naturale. Nel nostro caso, fra utenti e addetti di biblioteca, una

conversazione come quella proposta potrebbe essere

completamente naturale, e necessita dunque di essere inserita nel

codice.

E poi, naturalmente, il nostro LIBER avrà bisogno anche di un

database che permetta ricerche di questo tipo, essendo quello

utilizzato adesso totalmente inventato (presupponendo però campi

classici come autor e title e permettendo anche la ricerca

incrociata).

Non pochi problemi ci si presenterebbero però davanti, sia dal

punto di vista linguistico che strettamente informatico. Proviamo

ad osservare i principali e a provare di risolverli, per quanto

possibile.

Il primo problema, riguardante la correzione ortografica degli

input dati dall’utente, ha soluzione abbastanza semplice, ma non

definitiva. Con le espressioni regolari che caratterizzano il

linguaggio, infatti, si può benissimo proporre la sostituzione di un

input sbagliato (programmato in precedenza) con quello corretto.

La soluzione sarebbe qualcosa di questo tipo:

<category>

<pattern> abbazzia </pattern>

<template> <srai> abbazia <srai> </template>

</category>

Non tutto, però, resterebbe risolto. Le possibilità da prevedere

sono potenzialmente infinite, e il programma si dovrebbe limitare

ad una lista di errori classici basata su considerazioni linguistiche

e statistiche che tengano in conto quali errori siano più frequenti

e, dunque, più probabili.

Inoltre un sistema di questo tipo si troverebbe in difficoltà quando

l’errore porta comunque ad una parola presente nel vocabolario,

32


come ad esempio nel caso COPIA/COPPIA. Qui, limitandoci alle

espressioni regolari, è impossibile comprendere ciò che l’utente

voleva realmente dire. Altri elementi, come il contesto, sarebbero

utili alla corretta decodificazione della richiesta. Ma servirebbe a

questo punto un algoritmo capace di parseggiare4 la frase nella

sua interezza. Algoritmo che, come abbiamo visto, non sarebbe

possibile in un programma come Alice. Essa si basa su espressioni

regolari ma, nonostante i suoi limiti, riesce comunque a

funzionare.

Altro problema è l’espansione delle query dell’utente nel caso non

si sia trovato alcun risultato. Si cercherà qui di effettuare ricerche

simili a quelle proposte dall’utente, ma più fruttuose. Prendendo

ad esempio la ricerca “fantasmi” il programma potrebbe anche

cercare la parola “fantasma”, soprattutto se la prima ricerca non

porta a risultato. Nel codice basta scrivere:

If (“number-search”=0) then

<category>

<pattern> fantasmi </pattern>

<template> <srai> fantasma <srai> </template>

</category>

Ma è davvero possibile prevedere tutte le possibili varianti su tutte

le possibili richieste degli utenti? Anche con approfondite ricerche

linguistiche di fondo, non ci troviamo di fronte ad un lavoro

realisticamente fattibile. Sarebbe più opportuno, anche in questo

caso, un parsing5 della parola, che riesca a dividere la radice dalla

4 Si definisce parsing l’attività di riconoscimento di elementi appartenenti ad una data grammatica e la capacità di individuare, di conseguenza, la struttura di una parola o di un’intera frase, compito necessario per una successiva comprensione. Per maggiori approfondimenti si vedano Jurafsky e Martin (2000) e Ferrari (1991).5 Si definisce parsing l’attività di riconoscimento di elementi appartenenti ad una data grammatica e la capacità di individuare, di conseguenza, la struttura di una parola o di un’intera frase, compito necessario per una successiva comprensione. Per maggiori approfondimenti si vedano Jurafsky e Martin (2000) e Ferrari (1991).

33


parte flessiva riguardante il numero. Ma anche questo è un

problema non risolvibile con le espressioni regolari del nostro

sistema, e saremo costretti ad accontentarci di ciò che abbiamo. In

fondo, i risultati che possiamo ottenere non sono certo malvagi.

Possiamo riuscire, in modo abbastanza corretto, a compiere una

ricerca a partire da una query libera dell’utente, espressa in

linguaggio naturale. Una volta osservati sul campo i modi per

cercare un libro, possono essere facilmente riprodotti seguendo

l’esempio qui riportato:

<category>

<pattern> Ci sono libri di * </pattern>

<template>


http://search.biblioteca.unis.it/bin/search?autor=<star/>

</display>


it>, quale cercavi?

</template>

</category>

Altre frasi da utilizzare per il programma, raccolte da me stesso

presso la biblioteca di facoltà e fra amici disponibili, sono riportate

in seguito. Le ho catalogate in base al tipo di ricerca che la

macchina dovrà compiere (ricerca specificata tra parentesi dopo il

titolo di ogni sezione).

Si noti come esse siano prive di punto interrogativo finale. Tale

artificio, anche nel codice di Alice, è utilizzato per ovviare ad

eventuali dimenticanze da parte dell’utente.

In ogni caso, però, un tale elenco di frasi non vuole assolutamente

risultare esaustivo di tutte le possibili modalità di richiesta di libri

da parte degli utenti. Esso mira solo ad essere il punto di partenza,

il nucleo di un programma come quello che vogliamo proporre.

34


Ulteriori ampliamenti risulteranno sicuramente necessari in fase di

Testing, e uno studio ancora più approfondito dovrà precedere

un’eventuale concreta realizzazione del programma.

RICERCA PER TITOLO

(http://search.biblioteca.unis.it/bin/search?title=<star/>)

Il prof per la tesi mi ha dato questo libro: *

Avete un libro che si intitola *

Mi servirebbe *

Vorrei *

Mi serve *

Cerco *

Sto cercando *

Non è che avete *

Non è che vi trovate *

Avrei voglia di leggere *

Stavo cercando *

Avete *

È disponibile *

È possibile avere *

Gradirei avere *

Mi dia *

Mi cerchi *

Voglio *

Vorrei sapere la collocazione di *

C’è *

RICERCA PER AUTORE

(http://search.biblioteca.unis.it/bin/search?autor=<star/>)

Cerco un libro, l’autore dovrebbe essere *

Mi servirebbe un libro di *

35


Vorrei un libro di *

Mi serve un libro di *

Cerco un libro di *

Sto cercando un libro di *

Non è che avete un libro di *

Non è che vi trovate un libro di *

Avrei voglia di leggere un libro di *

Stavo cercando un libro di *

Avete un libro di *

È disponibile un libro di *

È possibile avere un libro di *

Gradirei avere un libro di *

Mi dia un libro di *

Mi cerchi un libro di *

Voglio un libro di *

Vorrei sapere la collocazione di un libro di *

C’è qualcosa di *

Ho deciso di leggere tutti i libri di *, quali avete

RICERCA PER ARGOMENTO

(http://search.biblioteca.unis.it/bin/search?topic=<star/>)

Avete un libro che affronti *

Mi servirebbe un libro su *

Vorrei un libro su *

Mi serve un libro su *

Cerco un libro su *

Sto cercando un libro su *

Non è che avete un libro su *

Non è che vi trovate un libro su *

Avrei voglia di leggere un libro su *

Stavo cercando un libro su *

Avete un libro su *

36


È disponibile un libro su *

È possibile avere un libro su *

Gradirei avere un libro su *

Mi dia un libro su *

Mi cerchi un libro su *

Voglio un libro su *

Vorrei sapere la collocazione dei libri su *

C’è qualcosa su *

Vorrei capire qualcosa di *, mi consiglia qualche libro

Si noti come frasi di questo tipo siano relativamente semplici e

poco variabili fra loro. La funzione creativa del linguaggio sembra

molto ridotta di fronte a compiti così ristretti.

Ci troviamo di fronte a frasi ricorrenti, poco fantasiose, a

conversazioni standardizzate che la macchina potrà comprendere

con una certa facilità.

Ciò è dovuto a un tipo di rapporto asimmetrico che, come

sottolineano Winograd e Flores (1986), si viene a creare fra l’uomo

e la macchina. Tale rapporto, però, per un compito semplice come

il nostro, limitato a brevi scambi di battute, non dovrebbe

comportare problemi.

Diversamente accadrebbe per casi più complessi, in cui gli ordini

da impartire alla macchina non siano così naturali e veloci come la

richiesta di un libro in biblioteca.

Norman (1998) sottolinea che, per tali compiti, anche ammettendo

un programma capace di comprendere appieno il nostro

linguaggio, esso non sarebbe sufficiente a capire ciò che

realmente vogliamo, in quanto non sempre siamo in grado di

esprimerlo con facilità.

Ma, fortunatamente, questo non è il caso di LIBER. Un sistema

come il nostro, che funziona tramite il riconoscimento di forme

previste dal programmatore, dovrebbe funzionare senza alcun

37


intoppo, a patto che si registrino nel suo codice il maggior numero

possibile di forme per la richiesta bibliotecaria.

I problemi classici degli altri progetti in linguaggio naturale

vengono evitati. Il linguaggio è qui, come per Searle6, un semplice

prodotto linguistico indipendente dal processo sottostante.

La ristrettezza del campo d’azione rende verosimile l’interazione,

aggirando tutti quegli ostacoli che ancora oggi la linguistica non è

in grado di superare.

Prendiamo ad esempio la violazione delle massime conversazionali

di Grice7, violazione che è possibile nel linguaggio naturale (ad

esempio nell’ironia) ma che allo stato delle cose mette in crisi

qualunque calcolatore.

Tale problema non è qui risolto, ma evitato: a chi verrebbe in

mente di scherzare con l’addetto di una biblioteca, per lo più

automatizzato?

Probabilmente a nessuno, e la fase di Testing ci ha dato ragione.

Prima di visionare l’interazione con gli utenti reali, però, possiamo

ancora definire altre potenzialità di un progetto come quello

proposto.

Il nostro LIBER, così come la Giulietta dell’Alfa Romeo, potrà

anche non limitarsi al compito specifico per cui è stato

programmato.

Una chatbot in grado di parlare in linguaggio naturale con l’utente

in maniera accettabile potrà andare oltre la mera e semplice

ricerca fra i testi inseriti nel database per offrire, a chi con essa

dialoga, una gamma maggiore di informazioni sull’intera gestione

della biblioteca.

Andando a cercare i requisiti che il nostro progetto deve avere

anche al di fuori dello stretto contesto degli studenti universitari,

6 Per approfondimenti su Searle e sulle diverse concezioni di raffrontarsi all’interpretazione del linguaggio e all’intera disciplina dell’Artificial Intelligence, si guardino Hofstader (1979), Nilsson (1998) e Winograd e Flores (1986). 7 Per approfondimenti sulle regole conversazionali di Grice e i problemi che la loro violazione può causare nel tentativo di comprendere il linguaggio attraverso i calcolatori, si veda Winograd e Flores (1986).

38


infatti, si scopre come utenti di livello più alto (professori, gestori

di altre biblioteche, etc.) abbiano maggiori richieste sui requisiti di

sistema necessari.

E così si avanza la proposta nel codice dell’inserimento delle

discussioni più classiche, dei quesiti più comuni per un reale

addetto di una biblioteca.

Pur non sviluppando, in questa tesi, tale parte, credo che essa sia

realizzabile per argomenti seguendo l’esempio già tracciato da

Alice, e propongo dunque un elenco delle richieste più naturali a

cui il sistema dovrebbe essere in grado di rispondere (raccolte fra

professori e gestori di biblioteche anche al di fuori del contesto

senese). In particolare, la macchina dovrà essere in grado di

rispondere a eventuali domande su:

- collegamenti con altre biblioteche;

- possibilità di fotocopie;

- richiesta di cd allegati a libri;

- tempi di prestito e eventuali penali;

- organizzazione dei rapporti con le case editrici;

- informazioni su tempi e luoghi di consultazione;

- possibilità di accesso diretto agli archivi;

- informazioni su narrativa straniera e su eventuali

traduzioni;

- informazioni su eventuali sezioni della biblioteca;

- possibilità di visite guidate;

- eventuale sito internet.

Tale parte relativa a discussioni così ampie (e più complesse da

programmare) sarà però trascurata nella parte successiva di

questa trattazione, e ignorata totalmente in fase di Testing.

La si propone solo come un ulteriore possibile sviluppo di un

programma di questo tipo, a mostrarne nuovamente le sue enormi

potenzialità.

39


È però da notare il pericolo di un ampliamento eccessivo delle

discussioni che il nostro LIBER potrà intraprendere con l’utente.

Pur non essendo un problema in fase di programmazione (sarebbe

necessaria solo qualche pagina di codice in più), ciò potrebbe

tuttavia distogliere l’utente dal suo compito principale, che è

quello della ricerca bibliotecaria.

I sistemi esaminati in precedenza avevano lo scopo di

chiacchierare con l’utente per intrattenerlo sul sito web su cui

apparivano, compresa Giulietta, che con le sue discussioni aveva

evidenti fini pubblicitari. E tali fini non rientrano certamente nei

nostri obiettivi.

Ma passiamo ora alla fase di Testing del programma sugli utenti,

in modo da comprendere eventuali nostri errori o lacune e di

tentare di porvi rimedio.

40

LIBER – Capitolo 3: Testing e risoluzione dei problemi

CAPITOLO 3: TESTING E RISOLUZIONE DEI

PROBLEMI

“Che cosa farà la gente?”. La domanda posta da Winograd e Flores

(1986) è alla base di qualunque ciclo di progettazione. Testare le

potenzialità del programma e gli eventuali problemi di interazione

che esso può avere è una fase iniziale necessaria prima che

avvenga la reale e dispendiosa implementazione informatica di un

sistema.

Abbiamo così seguito le linee guida dell’User Centred Design,

facendo riferimento alle modalità di prototipazione proposte da

Houde e Hill (1997) e dai siti web dei corsi di Interazione Uomo

Macchina del prof. Save (http://linus.media.unisi.it/ium/) e di

Progettazione Multimediale del prof. Rizzo

(http://www.saul.unisi.it/unisi/).

La fase di Testing del nostro LIBER è stata effettuata utilizzando

una tecnica di prototipazione classica per sistemi di questo tipo,

denominata Mago di Oz8.

Proprio come accadeva col famoso mago, tale tecnica consiste nel

far credere presente qualcosa che non c’è, nel nascondere un

operatore dietro alla macchina, in modo da fingere il suo reale

funzionamento, mentre l’utente interagisce col sistema come se

questo fosse realmente già stato implementato.

Per il nostro test è stato dunque sufficiente connettere due

computer in rete e presentare all’utente l’interfaccia di MSN

Messanger, programma di chat per Windows distribuito

gratuitamente dalla Microsoft.

Per la simulazione del programma si sono utilizzate le frasi

raccolte in precedenza, coscienti però delle possibilità di

ampliamento del codice, della facilità di coprirne eventuali falle e

di aprire nuovi orizzonti di ricerca.

8 Per maggiori informazioni sulle tecniche di prototipazione e sul Mago di Oz in particolare, si veda il testo di riferimento, precedentemente citato, Houde e Hill (1997), oltre ai siti web dei due corsi: http://linus.media.unisi.it/ium/ e http://www.saul.unisi.it/unisi/.

.

41


Gli utenti su cui si è effettuato il test rappresentavano un target

omogeneo di studenti universitari, fra i quali non è sorto il

problema dell’utilizzo della tastiera del computer (problema che,

non lo neghiamo, potrebbe porsi con utenti più anziani e restii alla

tecnologia).

Gli utenti tester hanno così interagito con un operatore nascosto

(il sottoscritto) scrivendo però i loro comandi su una macchina,

proprio come avrebbero fatto se la loro richiesta fosse avvenuta

sul sistema in progetto, simulando in questo modo le loro reazioni

ad un’interazione di questo tipo e, soprattutto, lo svolgimento del

compito.

Abbiamo inoltre ulteriormente diviso in due fasi le operazioni di

Testing, in base agli obiettivi che con esse volevamo raggiungere.

La prima fase, che ha coinvolto 28 utenti, è stata effettuata in

modo totalmente informale, lasciando liberi gli utenti di interagire

con la macchina nel modo che volessero.

Pur coscienti che dal punto di vista metodologico non sia

completamente corretto trarre conclusioni dalle operazioni di

utenti che svolgono compiti diversi e non definiti, abbiamo ritenuto

tuttavia necessaria l’osservazione dei loro comportamenti di fronte

al nostro LIBER senza porre ad essi alcun vincolo.

Questo ci ha dato modo di capire quali sarebbero state le richieste

per un sistema ancora in fase embrionale e bisognoso di ampliarsi

nelle sue potenzialità prima di affrontare un vero e proprio test

utente. Non volevamo compilare uno scenario9 rigido per la fase di

Testing, scenario che in questa fase del progetto avrebbe potuto

precluderci alcune vie di sviluppo. I sistemi che ad oggi

supportano il compito della ricerca bibliotecaria ci sembravano

troppo diversi dal nostro LIBER per evidenziare, tramite la loro

osservazione, tutte le problematiche che questo avrebbe dovuto

affrontare. E così ci siamo limitati ad osservare il comportamento

9 Per informazioni sulle tecniche di prototipazione Scenario Based si rimanda nuovamente siti web dei due corsi: http://linus.media.unisi.it/ium/ e http://www.saul.unisi.it/unisi/.

42


degli utenti di fronte ad una simulazione del nostro sistema,

lasciandoli liberi di esplorarlo in ogni sua parte.

Così la vera e propria fase di Testing, basata sul metodo degli

scenari10, è stata svolta solo dopo l’osservazione delle azioni degli

utenti e la risoluzione dei principali problemi della macchina.

Prima fase di Testing

Andiamo ora a vedere la prima fase di Testing, che ha evidenziato i

requisiti necessari al sistema, i suoi limiti e i non pochi intoppi che

esso crea nell’interazione.

Per comodità ci soffermeremo ad osservare, e a citare, solo le parti

critiche, in cui gli utenti si son scontrati con qualcosa di non

previsto dal progetto. Da esse cercheremo di partire per trovare

eventuali soluzioni.

Il primo problema riguarda l’ambiguità del linguaggio. Pur in un

sistema ristretto come LIBER, infatti, l’interazione con un utente

ha dato voce a una richiesta inaspettata:

<VORREI UN LIBRO DI GUERRA>

È facile intuire qui il tipo di problemi che possa generare una frase

di questo tipo. L’utente sta cercando un libro che parli di battaglie

o uno scritto di un autore che si chiama Guerra? Ci troviamo di

fronte ad un’ambiguità lessicale11: frasi come “Sto cercando un

libro di *” potrebbero rimandare sia al campo “Autore” che a

quello “Argomento”. È un problema che non ha facile soluzione in

una macchina di questo tipo, priva della reale capacità di

comprendere il linguaggio.

Si può comunque aggirare l’ostacolo proponendo una doppia

ricerca, come in questo esempio:

10 Si veda la nota 9.11 In linguistica si distinguono diversi tipi di ambiguità. Per approfondimenti si veda il testo di riferimento: Akmajian, Demers, Farmer e Harnish (1996).

43


<category>

<pattern> Avete libri di * </pattern>

<template>


http://search.biblioteca.unis.it/bin/search?autor=<star/_or_a

rg=<star/>>

</display>


it>, quale cercavi?

</template>

</category>

Oppure, più verosimilmente, si può restringere il campo di ricerca

con una domanda chiarificatrice, che venga posta nei casi di

ambiguità (utilizzo della funzione If). In tal caso LIBER si

proporrebbe come reale mediatore fra l’utente e il database,

riportando la richiesta ad una forma comprensibile dal sistema. Il

dialogo risultante sarebbe di questo tipo, perfettamente naturale:

Utente: AVETE LIBRI DI GUERRA?

LIBER: LIBRI SULLA GUERRA O SCRITTI DA GUERRA?

U: LIBRI SULLA GUERRA

L: ECCOLI

Altro problema sorge invece nella ricerca per argomento, con un

altro utente che non trova i risultati sperati. Il suo unico errore, se

errore si può chiamare, era stato l’utilizzare un linguaggio vario

che non corrispondeva a quello insito nel database del sistema. In

particolare, egli aveva chiesto:

Utente: Avete libri sul primo conflitto mondiale?

44


La richiesta sembra banale, ma non otteneva tutti i risultati sperati

in quanto alcuni libri sull’argomento erano catalogati utilizzando

come parola chiave per la ricerca la parola “guerra” al posto della

parola “conflitto”.

Sarebbe utile, per ovviare a tale problema, poter cercare nel

database anche i sinonimi della parola utilizzata nella query

dell’utente. Interessante, a tal proposito, potrebbe essere l’utilzzo

di WordNet12, e un collegamento ad esso è anche fattibile tramite

l’inserimento di un Javascript. Abbiamo già visto, in precedenza,

come il potenziale di questo comando permetta l’accesso ad un

database esterno per la traduzione di parole. Compito molto simile

è la possibilità di trovare sinonimi. E, una volta trovati, essi

potrebbero essere riproposti al programma per la ricerca dei

risultati, utilizzando il tag ormai noto.

Dalla mia piccola ricerca sul campo, infine, ho notato l’esigenza

per gli utenti di compiere spesso ricerche incrociate. Ben 24 utenti

su 28, messi di fronte al sistema in fase di test, hanno infatti

richiesto la possibilità di utilizzare più campi contemporaneamente

per restringere la loro ricerca.

Anche per queste query, sicuramente più complesse ma anche più

interessanti, propongo un insieme di frasi raccolte sul campo (si

noti la necessità, inoltre, di inserire altri criteri di catalogazione e

ricerca nel database, come anno di pubblicazione e numero di

pagine, compito comunque non impossibile):

Mi dia “Titolo” di “Autore”

Vorrei un libro su “Argomento” di “Autore”

Stavo cercando un libro di “Autore” del “anno”

Non è che avete un libro di “Autore” di meno di X pagine?

Mi servirebbe qualcosa su “Argomento” scritta fra il

“anno1” e il “anno2”

12 Wordnet è una rete semantica costruita da un consorzio di università e disponibile sul web al sito http://www.globalwordnet.org.

45


Avrei voglia di leggere qualcosa su “Argomento”, ma non

più di X pagine

Cerco “Titolo”, un libro del “Anno”

Avete un libro su “Argomento”, credo si intitoli “Titolo”

Uno studio di queste forme è sicuramente interessante, ed è utile

anche per capire le restrizioni del sistema attuale, e per ovviare ad

esse.

Ricerche incrociate come quelle proposte sarebbero possibili, in

Alice (e in LIBER), solo permettendo la memorizzazione di ben due

campi da una stessa frase. Non credo che ciò sia possibile col

sistema odierno, ma credo anche che questa soluzione non sia

lontana dalle attuali possibilità, e così la propongo con un esempio:

<category>

<pattern> C’è un libro di *1 che parla di *2 </pattern>

<template>


http://search.biblioteca.unis.it/bin/search?autor=<star1/+ar

g=<star2/>>

</display>

Questi sono i libri di <set it> <settopic> *1 </settopic>

</set it> che parlano di <set it> <settopic> *2 </settopic>

</set it>, quale cercavi?

</template>

</category>

Continuando su questa via della ricerca incrociata, propongo

inoltre alcuni esempi di richieste leggermente più complesse, che

non solo fanno interagire fra loro i vari campi del database, ma

anche alcune funzioni meno semplici, come quelle in grado di

rispondere alle domande qui elencate:

46


<AVETE L’ULTIMO LIBRO DI “Autore”?>

<HO SENTITO CHE LA “Casa Editrice” HA PUBBLICATO

ULTIMAMENTE UN LIBRO DI “Autore”, L’AVETE?>

<AVETE L’ULTIMO LIBRO SCRITTO DA “Autore” PRIMA DI

MORIRE?>

<C’È QUALCHE LIBRO RECENTE SU “Argomento”?>

<AVETE NOVITÀ?>

<UN MIO AMICO HA PRESO IN PRESTITO UN LIBRO MARTEDÌ,

MA NON RICORDO IL TITOLO, SI PUÒ RICAVARE IN QUALCHE

MODO?>

<STO CERCANDO UN LIBRO, SO CHE È MOLTO RICHIESTO MA

NON RICORDO IL NOME, SI PUÒ AVERE?>

Alle prime cinque richieste, anche se in modi diversi fra loro, si

riesce a rispondere con una funzione abbastanza semplice che

metta in campo l’anno di pubblicazione dei testi.

Nel primo caso tale funzione dovrà semplicemente scegliere il più

recente fra una serie di testi posti in ordine cronologico.

Nel secondo e nel quarto, invece, essa dovrà interagire con la data

del giorno per comprendere il significato di “ULTIMAMENTE” e

“RECENTE” (anche si qui si pone un problema linguistico-

filosofico su entro che arco di tempo una cosa possa dirsi recente:

un mese, un anno? La scelta operata sarà purtroppo sempre

arbitraria ma rigidamente codificata).

Simile a tali casi è anche il quinto, che porrà il problema di quando

un libro può definirsi novità.

Più semplice invece, il terzo caso, che farà semplicemente

interagire la data di pubblicazione con quella della morte

dell’autore, riuscendo facilmente ad esaudire la richiesta

dell’utente.

Non eccessivamente complesse da risolvere, ma forse esagerate

per un sistema che comunque non può permettersi di prevedere

ogni singola possibilità di richiesta, sono le ultime due domande,

47


venute comunque fuori in fase di Testing da un utente un po’ più

esigente degli altri.

Anche se un collegamento con una specie di registro dei prestiti

sarebbe possibile e risolverebbe la questione, infatti, ritengo che,

al fine di evitare un pericoloso aumento esponenziale di funzioni,

un gentile ma fermo rifiuto sia la migliore risposta del sistema a

domande così piene di pretese. E ciò non credo, comunque, che

possa costituire un limite: quanti bibliotecari reali avrebbero

realmente provato a rispondere ad utenti così esigenti?

Ma sulla stessa scia si pongono altre due velleitarie richieste di

utenti che sembravano aver dimenticato di parlare con una

macchina, o forse ne cercavano proprio la crisi:

<QUANTE PAGINE HA QUESTO LIBRO? È SCRITTO STRETTO?

NON LO FINISCO IN TEMPO…>

<MI CONSIGLIA QUALCOSA DA LEGGERE SOTTO

L’OMBRELLONE?>

Anche in questo caso la proposta è di rifiutare gentilmente di

rispondere a domande così specifiche. Si può dire ad un utente il

numero di pagine di un testo, ma non anche la grandezza del

carattere!

Per non parlare, poi, del dare consigli sui libri da leggere. A meno

di esser sponsorizzati realmente da qualche casa editrice, non

potremmo certo metterci a far pubblicità…

E questi rifiuti non devono esser presi come un limite del

programma in progetto. Bisogna ricordare che il nostro LIBER si

propone semplicemente di fungere da mediatore fra l’utente e il

database della biblioteca, cercando di riportare le richieste

dell’utente su spazi comprensibili e previsti dal sistema. Ma se è il

database stesso a non prevedere (ragionevolmente) tali tipi di

richiesta, neanche il nostro LIBER potrà esaudirle.

48


Diverso è il caso di un’altra domanda abbastanza curiosa che è

stata posta da un altro utente:

<MAURIZIO COSTANZO HA PARLATO DI UN LIBRO, L’AVETE?>

Qui, ignorando in ogni caso chi sia il recensore del libro in

questione (generalizzando dal Maurizio Costanzo del caso ad un

generico input “_” previsto dal codice) possiamo proporre subito

all’utente una domanda chiarificatrice, per esempio chiedendogli il

titolo del libro.

Nel codice avremo:

<category>

<pattern>_ HA PARLATO DI UN LIBRO, L’AVETE</pattern>

<template>CHE LIBRO?</template>

</category>

<category>


<template>


http://search.biblioteca.unis.it/bin/search?title=<star/>

</display>

Ecco tutte le informazioni sul libro che cercavi

</template>

</category>

<category>

<pattern> GRAZIE</pattern>

<template> Di nulla. A presto! </template>

</category>

49


In tal modo LIBER, abbastanza semplicemente, tenterà di

riportare l’utente su un tipo di richiesta ragionevole per il

database, fungendo da utile mediatore.

Ma ulteriori problematiche vengon fuori dalla fase di Testing, e

necessitano di esser messe in luce.

Fondamentale, alla luce delle ultime richieste prese in esame,

diventa il problema della visibilità. Mostrare all’utente in ogni

momento le azioni possibili è uno dei principi basilari di un buon

progetto secondo Norman (1988) ma il nostro LIBER, almeno fino

ad ora, è totalmente privo di questa caratteristica.

Essa potrebbe essere utile, invece, per evitare richieste

inesaudibili che, come abbiamo visto, non sono mancate nella

prima fase di Test.

Sarà necessaria, a questo punto, una modifica del progetto che

proponga un’interfaccia in modalità mista, permettendo all’utente

di utilizzare, insieme allo scambio di battute in linguaggio

naturale, la classica manipolazione diretta di oggetti sullo

schermo.

Ciò risolverebbe anche un problema di utilizzo che si era notato a

seguito della prima fase di Testing. Questa, pur evidenziando la

facilità d’uso del sistema da parte di tutte le categorie d’utenti, ha

riportato anche un leggero fastidio da parte degli utenti abituati

all’utilizzo dei normali campi del database. LIBER, basandosi sul

linguaggio naturale, risulta infatti leggermente meno rapido

rispetto a un sistema di database classico basato sulla sinteticità e

sull’univocità dei comandi informatici (comandi che, però, l’utente

deve conoscere per utilizzare, e non tutti sono in grado di farlo).

Anche tale problema dovrebbe essere evitato da una interazione in

modalità mista, che utilizzando la manipolazione diretta eviterebbe

il problema della conoscenza pregressa dei comandi.

La proposta di correzione prevede dunque un’apertura verso un

tipo di interazione più diretto per l’utente, a scapito però del sogno

iniziale di una totale mediazione del linguaggio naturale.

50


Così facendo seguiamo la direzione attuale della Human Computer

Interaction, disciplina che si ritrova scettica di fronte ad un uso

totale del linguaggio per lo svolgimento di compiti che potrebbero

essere risolti più semplicemente.

Nonostante questo, però, non abbandoniamo del tutto le

potenzialità del linguaggio AIML, che ci possono sempre tornare

utili nei casi descritti in precedenza, come la correzione

ortografica o l’utilizzo di sinonimi nella ricerca per argomento.

La nuova idea per il progetto prevede dunque la figura del nostro

LIBER rappresentato davanti ad un computer che, compiendo la

stessa azione dell’utente, e facendo credere ad un operatore

nascosto, dovrebbe creare un rapporto di maggior vicinanza fra

l’uomo e il sistema.

Una breve frase illustra le azioni che si potranno compiere,

invitando a compilare a lato una scheda per la ricerca

(rappresentata come se fosse cartacea, e dunque più vicina alle

vecchie abitudini dell’utente). Tale scheda presenterà i campi

classici di una ricerca con database ma potrebbe sfruttare al

contempo, come già accennato, le potenzialità dell’AIML, al fine di

aumentare le probabilità che la ricerca vada a buon fine.

Al posto della scheda, poi, nella schermata successiva, saranno

proposti all’utente i risultati della ricerca, con la possibilità di

cliccare sul testo preferito per ricevere ulteriori informazioni.

Inoltre, il nostro LIBER resterebbe sempre a lato per qualsiasi

informazione o chiarimento (fungendo così quasi da funzione di

Help) e potrebbe anche mantenere intatte le sue capacità di

compiere da solo le ricerche, per gli utenti che lo desiderassero.

In tal modo non si abbandonerebbe del tutto la possibilità di

utilizzo del linguaggio naturale, che abbiamo visto, pur coi suoi

artifici, funzionare abbastanza bene.

51


Seconda fase di Testing

La seconda fase di Testing è stata effettuata, sulla nuova versione

del sistema, ormai dotata di una forma e di requisiti ben chiari.

I cinque utenti coinvolti in questa fase hanno interagito col novo

LIBER sempre utilizzando la tecnica del Mago di Oz13, sebbene

stavolta non sia più stato utilizzato per essa il solo MSN

Messanger. Esso si è mantenuto per permettere la discussione

dell’utente col nostro LIBER fittizio, sempre nascosto dietro un

altro computer collegato in rete. Per la manipolazione diretta,

invece, si sono create delle semplici pagine in PowerPoint come

quella raffigurata in precedenza.

Naturalmente, ciò ha comportato la presenza contemporanea di

due pagine (una per la chat ed una per la visualizzazione) che

potrebbe essere invece evitata dalla reale implementazione del

sistema. Nonostante questo, però, il nostro prototipo costituisce

13 Per maggiori informazioni sulle tecniche di prototipazione e sul Mago di Oz in particolare, si veda il testo di riferimento, precedentemente citato, Houde e Hill (1997), oltre ai siti web dei due corsi: http://linus.media.unisi.it/ium/ e http://www.saul.unisi.it/unisi/.

52


una discreta approssimazione del risultato finale del nostro

progetto, e l’interazione con esso ha portato a risultati

interessanti.

Gli utenti coinvolti per questa fase di Testing più formale avevano

stavolta un compito ben preciso da svolgere, consistente in una

ricerca incrociata autore-argomento. Lo scenario era il seguente14:

Sei uno studente universitario e hai saputo della possibilità

di ricevere libri in prestito dalla biblioteca della tua facoltà.

Decidi di andarci per cercare un libro di Eco di cui ti ha

parlato un amico, ma hai dimenticato il titolo. In compenso,

ricordi che il protagonista della storia era un bugiardo che

viveva (o almeno raccontava) storie incredibili. Ti trovi di

fronte al computer per effettuare la tua ricerca.

Andiamo ora ad osservare le azioni di ognuno di questi utenti, per

capire le varie modalità di interazione col sistema.

Il primo, forse più abituato all’utilizzo di database, ignora

l’assistente virtuale e compila immediatamente la scheda

inserendo la parola “Eco” nel campo “Autore” e quella “bugiardo”

nel campo “argomento”.

Auspicando che il sistema prevedesse tale parola (o un suo

sinonimo) per la ricerca, gli abbiamo presentato immediatamente

davanti la schermata finale, con la descrizione del suo libro e la

relativa collocazione.

Non c’è stato qui alcun intoppo, anche se resta interessante notare

la totale indifferenza nei confronti del nostro LIBER.

Il secondo utente viene subito attirato da quella presenza,

iniziando a chattare pieno di curiosità con l’assistente virtuale.

Vuole provarne le potenzialità, capire a cosa serve, e solo dopo uno

14 Per informazioni sulle tecniche di prototipazione Scenario Based si rimanda nuovamente siti web dei due corsi: http://linus.media.unisi.it/ium/ e http://www.saul.unisi.it/unisi/.

53


scambio di ben sette battute si decide a chiedergli il libro

formulando la sua secca domanda:

Avete un libro di Eco che parla di un bugiardo?

Questa modalità di richiesta era stata prevista quando abbiamo

trattato delle ricerche incrociate, e non dovrebbe causare

problemi al nostro LIBER.

È da notare, però, come la possibilità di chattare abbia distratto

l’utente dal suo compito principale. Anche se gradisce la

chiacchierata e rimane soddisfatto dalla ricerca, infatti, non è

plausibile che un utente possa perdere così tanto tempo di fronte

al computer di una biblioteca.

Sarebbe opportuno che il nostro LIBER troncasse la discussione

alla seconda o massimo alla terza battuta estranea al compito

specifico per cui è stato creato (come d’altronde faceva anche

Giulietta), ricordando all’utente di esser lì solo per coadiuvarlo

nella ricerca.

Tale possibilità di distrazione dal compito è evidenziata anche dal

terzo utente, anche se questi scambia con la macchina solo cinque

battute prima di richiedere la ricerca.

Più precisamente, egli domanda a LIBER:

Avete libri di Umberto Eco?

Alla risposta affermativa della macchina, accompagnata a lato

dall’elenco di tutti i testi di Eco presenti in archivio, l’utente resta

però leggermente confuso. Si trova di fronte ad un gran numero di

titoli senza sapere quale sia quello che sta cercando. Prova a

cliccare su qualcuno di essi, scorge velocemente la descrizione, ma

continua a non trovare. Solo a questo punto chiede alla macchina:

Qual è quello che parla di un bugiardo?

54


Importante qui notare come tale richiesta non possa essere

esaudita senza tener traccia in memoria di quanto fatto in

precedenza. Non avrebbe senso, a questo punto, ricercare la

parola “bugiardo” come argomento fra tutti i libri disponibili.

Basterà utilizzarla per restringere la query precedente.

Il quarto utente inserisce invece la parola “Eco” nel campo autore

della scheda a fianco di LIBER, ricevendo così come output il

medesimo elenco dei testi di Eco. Scopre facilmente la possibilità

di cliccare sui titoli, legge le descrizioni e trova, al terzo tentativo,

il libro giusto.

Anche stavolta è da notare come il nostro LIBER sia stato ignorato,

preferendogli i più classici metodi di ricerca.

Il quinto utente, infine, interpella direttamente il nostro LIBER, ma

solo per chiedergli informazioni su come compilare la scheda:

Conosco solo l’autore, cosa devo mettere negli altri spazi?

Ammesso che il nostro LIBER abbia previsto una simile richiesta,

la risposta sarà di lasciarli vuoti, anche se, nuovamente, ci si

troverà in quella schermata con tutti i testi di Eco.

L’utente, come gli altri in precedenza, non ha compreso la

possibilità di restringere la sua ricerca utilizzando il campo

argomento. Sarebbe opportuno, a questo punto, che in tale

situazione sia la macchina stessa a coadiuvare la persona, anche

senza una esplicita richiesta d’aiuto.

La proposta è di far dire al nostro LIBER, accanto al lungo elenco

di titoli:

Questi sono tutti i testi di Eco, clicca sul titolo per ricevere

maggiori informazioni. Se vuoi invece restringere la tua

ricerca, clicca qui per compilare i campi prima lasciati vuoti.

55


È inutile dire come qui, al clic dell’utente, il sistema debba

riportare alla vista la scheda con i campi per la ricerca,

mantenendo però in memoria il passo iniziale con la richiesta dei

libri dell’autore.

Tale tipo di ricerca risulta quindi valido esempio delle potenzialità

del nostro LIBER di fungere da mediatore fra il database e

l’utente, avvicinandolo al risultato per step successivi.

È interessante comunque notare come cinque utenti diversi

possano aver utilizzato in maniera così varia il nostro sistema,

ignorandolo del tutto, utilizzandolo come valido aiuto o addirittura

perdendo tempo a chiacchierare con esso.

Nonostante qualche piccola lacuna ancora presente, ma

superabile, ci sembra che la soluzione in modalità mista sia in

grado di reggere il confronto con diverse tipologie di utenti.

I casi in cui alcuni di essi hanno perso del tempo a chiacchierare

con la macchina non sono da prendere in considerazione per

l’analisi dei risultati. Crediamo che ciò sia dovuto, almeno in parte,

alla curiosità della prima interazione con una macchina di questo

tipo, e che comunque ciò non costituisca un problema per il reale

svolgimento del compito.

Non ci sembrerebbe giusto limitare le potenzialità di una chatbot

alla sola funzione di Help che, per quanto utile, è stata utilizzata

pienamente da un solo utente su cinque.

La possibilità di interagire col sistema formulando le proprie

richieste in linguaggio naturale costituisce una via che, alla luce

dei risultati ottenuti, non ci sentiamo di abbandonare del tutto.

La scelta fra le due modalità di ricerca, e la capacità di compiere

ricerche miste, sembra al momento la migliore delle soluzioni.

Ancora importante, però, per chi voglia porsi l’obiettivo di

compilare realmente un programma come questo, composto da

centinaia di pagine di codice, è sicuramente la domanda sulla sua

concreta utilità.

56


LIBER è realmente più efficiente di un sistema basato sulle

classiche ricerche in un database? Il suo utilizzo è gratificante per

gli utenti o l’interazione in linguaggio naturale con una macchina

risulta particolarmente fastidiosa? Che reazione hanno gli utenti

esperti di fronte a questa nuova modalità per svolgere un compito

a loro comune? E che reazione hanno gli utenti inesperti, posti di

fronte ad un programma che proprio a loro mira, tentando di

aiutarli?

La seconda fase di Testing, effettuata sul progetto di ricerca in

modalità mista, ha evidenziato facilità d’utilizzo da parte di tutti gli

utenti.

LIBER funge da valido mediatore fra l’utente e il database del

sistema, almeno nei casi in cui venga richiesto il suo aiuto. La sua

presenza non costituisce però ostacolo per gli utenti più esperti,

che possono ignorarlo per compiere autonomamente le procedure

per una ricerca.

I piccoli intoppi che si son presentati dovrebbero essere ora risolti.

L’unica osservazione che resta da fare coinvolge entrambe le fasi

di Testing e riguarda il tipo di interazione che si viene ad

instaurare quando gli utenti dialogano con la macchina.

Nonostante ciò non costituisca, a quanto dicono, un problema per

gli utenti interessati, si può notare come un’interazione di questo

tipo non sia mai completamente naturale.

Abbiamo già notato come le frasi utilizzate dagli utenti per la

ricerca tendano a standardizzarsi, a divenire a loro volta

macchinose, fredde, prive di quella creatività che è tipica del

nostro modo di esprimerci.

Questo è già stato evidenziato parlando del rapporto asimmetrico

nell’interazione uomo-robot, che porta automaticamente l’utente a

semplificare il suo linguaggio, a livellarlo verso il basso, quasi

avesse inconsciamente paura di non essere compreso.

57


Naturalmente, però, questo non costituisce un limite per il

programma. Anzi, lo aiuta a funzionare bene anche con un numero

non enorme di possibili richieste previste nel suo codice.

Sarebbe interessante, tuttavia, poter osservare l’evoluzione del

linguaggio degli utenti stessi di fronte alle macchine, se esso

divenisse quotidiano.

Diverrebbe via via più naturale, più spontaneo, più complesso e

privo di restrizioni?

Ad una tale domanda non è purtroppo facile dare risposta, ma

probabilmente ci vorrà un arco di tempo molto elevato prima che

gli utenti prendano così tanta familiarità con le macchine. E forse

questo non avverrà mai.

58

LIBER – Conclusioni

CONCLUSIONI

Alla luce dei risultati ottenuti dalle due fasi di test e delle

modifiche da esso consigliate possiamo notare come la

realizzazione di un programma come quello immaginato non è

affatto impossibile, e che anzi molte altre potenzialità potranno ad

esso essere aggiunte da successivi sviluppi.

È tuttavia interessante notare come si siano dovute ridimensionare

le pretese iniziali su un sistema che interagisse interamente in

linguaggio naturale.

Ciò è dovuto non tanto alle potenzialità di elaborazione di un

programma sviluppato in AIML (che permette più o meno

facilmente alla macchina di sostenere una discussione in

linguaggio naturale), quanto ai problemi di interazione che esso

avrebbe creato nell’interfacciarsi con gli utenti.

Un sistema come quello iniziale, che proponeva una forma di

interazione completamente libera e priva di vincoli, avrebbe infatti

potuto allontanare l’utente dal percorso necessario al

raggiungimento del suo obiettivo.

Ricordando però la funzione del nostro LIBER di mediatore fra

l’utente e il database abbiamo ritenuto necessario veicolare

maggiormente il tipo di interazione, indirizzandola più

chiaramente verso la richiesta bibliotecaria, compito che il nostro

artefatto tenta di supportare.

Possiamo così notare come la soluzione in modalità mista proposta

abbia ottenuto i risultati sperati, risolvendo i principali problemi e

portando più o meno facilmente al risultato tutti gli utenti

osservati.

Naturalmente molti aspetti del linguaggio naturale non potranno

essere colti dalle espressioni regolari di un sistema informatico

come LIBER. In un dominio limitato come quello in esame, però,

esso può raggiungere soluzioni soddisfacenti a costi molto bassi.

La versatilità e la semplicità del linguaggio di programmazione

AIML permettono la possibilità di modifiche continue al progetto.

59


Pur limitandosi ad una mera attivazione di output dagli input dati,

una chatbot sviluppata in questo linguaggio sarà capace comunque

di gestire un cospicuo numero di frasi e di cogliere molti aspetti

della lingua, almeno fino a che non risultino necessari l’intervento

della

pragmatica15 o una complessa attività di parsing16. Lasciando

lontane ambizioni e considerazioni complesse di Artificial

Intelligence possiamo ottenere, almeno per piccoli compiti come

quello della ricerca bibliotecaria, risultati incoraggianti.

Ci limitiamo qui non a voler comprendere il linguaggio, ma a voler

simulare una conversazione, rispondendo alle domande che

verranno poste dall’utente e provando a coadiuvarlo

nell’esecuzione del compito. Il tutto a partire da richieste in

linguaggio naturale, ma in modo del tutto indipendente dal modo

di funzionare del “cervello” sottostante (che è, in questo caso, una

semplice funzione input-output, puramente informatica).

Così, pur privi di funzioni fondamentali come l’apprendimento e

l’evoluzione riusciamo a far fare al calcolatore ciò che chiediamo,

facilitandoci lo svolgimento di un compito.

Naturalmente, un sistema che sogni di interagire in linguaggio

naturale non può non esser soggetto di critiche. Pur ammettendo

la sua possibile realizzazione per il “front end” di un database,

come nel caso del nostro LIBER, infatti, Winograd e Flores (1986)

si chiedono se per casi così limitati non “può essere più pratico per

una persona imparare un linguaggio formale specializzato

progettato a questo scopo, anziché imparare attraverso

esperimenti quali proposizioni possono o no essere elaborate”.

15 La pragmatica è quella branca della linguistica che studia l’influenza di contenuti extra-semantici nel discorso come, ad esempio, il contesto. Per maggiori informazioni si veda: Akmajian, Demers, Farmer e Harnish (1996).16 Si definisce parsing l’attività di riconoscimento di elementi appartenenti ad una data grammatica e la capacità di individuare, di conseguenza, la struttura di una parola o di un’intera frase, compito necessario per una successiva comprensione. Per maggiori approfondimenti si vedano Jurafsky e Martin (2000) e Ferrari (1991).

60


Una volta osservato, però, come le frasi utilizzate dalla maggior

parte degli utenti siano veramente limitate e poco creative, si può

ricorrere sempre ai medesimi autori per sostenere che “vi sono

casi in cui il linguaggio naturale può far apparire un sistema

informatico meno arduo, favorendone l’uso da parte di persone

che respingerebbero un approccio formale più esplicito”.

Non è forse questo il caso di una ricerca bibliotecaria, che fra i

suoi requisiti deve avere la facilità d’uso per tutti gli utenti, anche

quelli che per la prima volta interagiscono col sistema?

Il ricorso alla modalità mista, inoltre, ha coperto le evidenti falle

che un sistema interamente in linguaggio naturale avrebbe creato

in termini di visibilità, di velocità e di efficienza, almeno per alcune

categorie d’utenti.

Rifiutando la tecnocrazia dominante, i sistemi costruiti da

tecnologi per tecnologi, riteniamo che la possibilità di utilizzare il

linguaggio naturale possa essere un valido aiuto per lo

svolgimento di compiti come quello della ricerca bibliotecaria.

Avanzo dunque, a termine di questa modesta trattazione, la

proposta della concreta realizzazione di un sistema come LIBER.

Siamo ancora lontani da un computer umano come l’HAL 9000 di

2001: Odissea nello spazio, e probabilmente non ci arriveremo

mai. Crediamo tuttavia che l’incontro fra la Human Computer

Interaction e l’Artificial Intelligence sia una via da continuare a

seguire. Una via che, speriamo, porterà alla semplificazione dei

piccoli e grandi compiti della vita di tutti i giorni.

61

LIBER – Bibliografia

BIBLIOGRAFIA:

Akmajian, A., Demers, R., Farmer, A. e Harnish, R. (1996)

Linguistics: An Introduction to Language and Communication,

Cambridge-London: The MIT Press, tr. it. a cura di Sornicola, R.

(1996) Linguistica – Introduzione al linguaggio e alla

comunicazione, Bologna: Il Mulino.

Ferrari, G. (1991) Introduzione al Natural Language Processing,

Bologna: Calderini;

Gentner, D. e Nielsen, J. (1996) The Anti-Mac Interface, New

York: ACM Press;

Hofstadter, D. (1979) Gödel, Escher, Bach: an eternal golden

braid, New York: Basic Books, tr. it. a cura di Trautteur, G. (1984)

Gödel, Escher, Bach: un’eterna ghirlanda brillante, Milano:

Adelphi;

Houde, S. e Hill, C. (1997) What do Prototypes Prototype?, in

Helander, M., Landauer, T. e Prabhu, P. (1997) Handbook of

Human Computer Interaction, Amsterdam: Elsevier Science;

Jurafsky, D. e Martin, J. (2000) Speach and Language

Processing, New Jersey: Pretience Hall;

Mari, F. (2002) Web semantico: il futuro dei contenuti nel web,

articolo apparso su www.scienzedellacomunicazione.com;

McCloud, S. (1993) Understanding Comics: the Invisible Art, New

York: Harper Collins Publishers, tr. it. a cura di Rizzi, L. (1996)

Capire il fumetto, Torino: Vittorio Pavesio Production;

62

LIBER – Bibliografia

Nardi, B. (1996) Context and Consciousness: Activity Theory and

Human-Computer Interaction, Cambridge-London: The MIT Press;

Nilsson, N. (1998) Artificial Intelligence: a new Synthesis, San

Francisco: Morgan Kaufmann Publishers;

Norman, D. (1988) Psychopathology of Everyday things,

New York: Basic Books, tr. it. a cura di Noferi, G.

(1996) La caffettiera del masochista, Firenze: Giunti;

(1998) The Invisible Computer, Cambridge-London:

The MIT Press,

tr. it. a cura di Parrella, B. (2000) Il computer invisibile,

Milano: Apogeo;

Ong, W. (1982) Orality and Literacy: the technologizing of the

word, Londra: Routledge, tr. it. a cura di Loretelli, R. (1986)

Oralità e scrittura: tecnologie della parola, Bologna: Il Mulino;

Reason, J. (1990) Human Herror, Cambridge: Cambridge

University Press, tr. it. a cura di Parlangeli, O. (1994) L’errore

umano, Bologna: Il Mulino;

Rizzo, A., Marti, P. e Bagnara, S. (2001) Interazione Uomo-

Macchina, in Burattini, E. e Cordeschi, R. (2001) Manuale di

Intelligenza Artificiale per le scienze umane, Roma: Carocci;

Stork, D. (1998) Hal’s Legacy 2001’s Computer as Dream and

Reality, Cambridge-London: The MIT Press;

Winograd, T. e Flores, F. (1986) Understanding Computers and

Cognition, Norwood: Ablex Publishing Corporation, tr. it. a cura di

Butera, F. e Ballance, S. (1987) Calcolatore e Conoscenza, Milano:

Arnoldo Mondadori Editore.

63

LIBER – Siti web utilizzati

SITI WEB UTILIZZATI:

http://chat.yahoo.com/

(sito della chat di Yahoo, utilizzata per un informale Test di Turing

su Alice)

http://linus.media.unisi.it/ium/

(sito del corso di Interazione Uomo Macchina del prof. Save, su cui

si possono trovare i principi basilari della Human Computer

Interaction)

http://sbs2.unisi.it/ALEPH/-/start/sbs01

(sito in cui compare il front end dell’attuale catalogo unico delle

biblioteche senesi, utilizzato come base di partenza per il nostro

sistema di ricerca bibliotecaria)

http://tcc.itc.it/history/projects/tamicp/home.html

(sito del progetto TAMIC-P di interazione in linguaggio naturale,

realizzato dall’ITC-IRST per l’INPS, da cui abbiamo preso qualche

spunto)

http://www.alfaromeo.it

(sito dell’Alfa Romeo, su cui si trova la chatbot Giulietta)

http://www.alicebot.org

(sito della chatbot Alice)

http://www.globalwordnet.org/

(sito che riunisce i vari progetti wordnet a livello globale)

http://www.saul.unisi.it/unisi/

(sito di sperimentazione didattica su cui si trova, fra le altre cose,

il materiale del corso di Progettazione Multimediale del prof.

Rizzo)

http://www.scienzedellacomunicazione.com/

64

LIBER – Siti web utilizzati

(sito nazionale utile a tutti gli studenti di Scienze della

Comunicazione, ricco di articoli interessanti)

http://www.yahoo.com

(sito del famoso motore di ricerca utilizzato anche dalla chatbot Alice)

65

LIBER - Altervistadavideandriolo.altervista.org/MiaHome/Tesi/LIBER.pdf · come è accaduto nel caso...

Documents

Transcript of LIBER - Altervistadavideandriolo.altervista.org/MiaHome/Tesi/LIBER.pdf · come è accaduto nel caso...