Comprensione del dialogo: scarsa

Continuando il mio confronto tra i sistemi di dettatura ho visto che il parlato spontaneo in italiano pone ancora enormi problemi. La percentuale di errori, espressa in WER, è di regola superiore al 50%: 10 volte superiore rispetto a quella per lettura ad alta voce.

 

Una parte di questi problemi è senz’altro dovuta al fatto che i prodotti con cui ho fatto il confronto non sono pensati per interpretare dialoghi. Non compiono quindi alcune operazioni moderatamente semplici e che con ogni probabilità permetterebbero di migliorare molto il risultato: non distinguono tra le voci dei dialoganti, non cercano di disambiguare le sovrapposizioni… Inoltre, eliminano spesso le ripetizioni di parole o segmenti, che però fanno parte costitutiva di un dialogo.

 

Tuttavia, le scarse prestazioni nel riconoscimento sono sicuramente dovute anche ad altri fattori, e in particolare al fatto che il parlato reale è difficile da comprendere, con le sue sovrapposizioni, ripetizioni, incertezze, parole che sfumano l’una nell’altra e via dicendo.

 

Qui di sotto riporto i risultati del riconoscimento di un dialogo interpretato da due diplomati o studenti universitari baresi, un maschio e una femmina, di poco più di vent’anni: Corpus CLIPS, sottocorpus Dialogico – Bari – Map Task, file DGmtA02B.wav. Il dialogo è in italiano, con accento ben percepibile ma lieve; in qualche punto in cui si passa all’italiano regionale o direttamente al dialetto. Ho passato gli audio a Dragon (senza addestramento utente) e a Google (Docs). Le percentuali di errore sono queste:

 

Dragon
Parlante a: 53,9 (22,7 sostituzioni, 30 cancellazioni, 1,3 inserimenti)
Parlante b: 71,4 (28,6 sostituzioni, 39,3 cancellazioni, 3,4 inserimenti)
Totale: 58,6

 

Google
Parlante a: 45,7 (12,1 sostituzioni, 32,3 cancellazioni, 1,3 inserimenti)
Parlante b: 74,3 (15 sostituzioni, 56,8 cancellazioni, 2,4 inserimenti)
Totale: 53,4

 

In entrambi i casi, inoltre, i problemi sono dovuti al riconoscimento di un numero molto basso di parole. La trascrizione ortografica originale del dialogo contiene 767 parole. Dragon ne trascrive solo 530, Google arriva al massimo a 481. Per Google poi occorre mettere in campo tutta una serie di stratagemmi, visto che il riconoscimento online di Google Docs ogni tanto si blocca. La soluzione migliore che ho trovato è stata quella di inserire pause di silenzio di 3 o 5 secondi nel file audio originale e interrompere il riconoscimento di Google Docs in corrispondenza di queste pause: apparentemente questo dà al sistema il tempo di elaborare l’input precedente. Tuttavia, come mostra il WER, anche se riconosce poco, quel poco Google lo riconosce bene.

 

Primi dati: Google meglio di Dragon

 

Finalmente ho i primi risultati del confronto tra i sistemi di dettatura.

 

Per questo lavoro ho usato sei file audio del corpus “Lettura frasi” contenuto all’interno del corpus CLIPS. I testi sono ancora brevissimi (12 minuti in totale) ma l’importante è iniziare…

 

I file che ho usato per il confronto sono:

 

LFp1A02B
LFp1A03B
LFp1B02B
LFp2A02B
LFp2A03B
LFp2B02B

 

Tutti i testi sono in italiano regionale con leggero accento barese e sono letti da diplomati o studenti universitari di poco più di vent’anni. Ho passato gli audio a Dragon (senza addestramento utente) e a Google (Docs). In nessuno dei due casi la trascrizione è stata perfetta, ma le percentuali di errore sono state molto basse – come del resto accade nei testi letti, molto diversi dalle conversazioni spontanee (tra queste ultime, percentuali del genere sarebbero da record).

 

Soprattutto, Google ha ottenuto un ottimo WER: solo il 5,5%. Dragon, che nelle mie prime prove sembrava addirittura superiore, ha commesso errori a un tasso quasi doppio, il 9,2%. Ecco i risultati di dettaglio sui singoli audio, calcolati con SCLITE:

 

Dragon
LFp1A02B: 13,7 (sostituzioni 6,3, cancellazioni 7,3)
LFp1A03B: 8,1 (sostituzioni 3,7, cancellazioni 4,1, inserimenti 0,3)
LFp1B02B: 8,4 (sostituzioni 4,4, cancellazioni 4,1)
LFp2A02B: 7,1 (sostituzioni 3,7, cancellazioni 3,4)
LFp2A03B: 8,7 (sostituzioni 4,3, cancellazioni 4,0, inserimenti 0,3)
LFp2B02B: 9,0 (sostituzioni 4,3, cancellazioni 4,7)
Media: 9,2

 

Google
LFp1A02B: 4,7 (sostituzioni 2,7, cancellazioni 1,3, inserimenti 0,3)
LFp1A03B: 4,1 (sostituzioni 2,0, cancellazioni 1,4, inserimenti 0,7)
LFp1B02B: 7,1 (sostituzioni 3,0, cancellazioni 3,0, inserimenti 1,0)
LFp2A02B: 4,7 (sostituzioni 3,7, cancellazioni 1,0)
LFp2A03B: 6,7 (sostituzioni 3,7, cancellazioni 2,0, inserimenti 1,0)
LFp2B02B: 5,7 (sostituzioni 3,3, cancellazioni 2,0, inserimenti 0,3)
Media: 5,5

 

Assistenti vocali e riga di comando

  

 

Che somiglianza può esserci tra un assistente vocale e una riga di comando? Cioè, tra l’interfaccia informatica più recente e intuitiva e quella più antica e controintuitiva? Più di quelle che si potrebbe pensare, si scopre leggendo un approfondito articolo (pubblicato il 3 novembre da Ars Technica) che discute le funzionalità e i limiti di Google Home: Google Home review: A step forward for hotwords, a step backward in capability.

 

L’autore, Ron Amadeo, nota molte altre cose su Google Home. Per esempio, che diverse funzioni disponibili sui telefoni Pixel non sono presenti in Google Home, anche se il sistema alle spalle, Google Assistant, è lo stesso. Come mai? In parte per ragioni di praticità, in parte per motivi poco chiari. Tuttavia, per me la sezione più interessante dell’articolo è stata quella che riguarda i “Command line problems without comprehensive documentation”. Cioè un problema che ho incontrato spesso: senza manuale di istruzioni è molto difficile capire che cosa un assistente vocale può o non può fare. Per questo proliferano le liste di funzioni — e qualche esempio, anche se non a scopi pratici, si è visto anche su questo blog.

 

Alla radice c’è una moda della comunicazione contemporanea: il divieto di creare manuali di istruzioni. Questa è un’ottima linea guida per applicazioni semplici e con pochi parametri, soprattutto nel caso di un uso occasionale. Tuttavia, quando si devono eseguire compiti complessi, è molto importante avere indicazioni chiare e facilmente reperibili. Anche solo rimanendo nell’ambito dei servizi on-line, se ci si deve iscrivere a un corso di laurea occorre sapere un bel po’ di cose e leggere un bel po’ di informazioni. Se si deve consultare un catalogo di biblioteca alla ricerca di una pubblicazione precisa, tra pubblicazioni che hanno titoli simili o sono opera dello stesso autore, un’interfaccia specializzata può essere indispensabile. E così via. La tendenza a progettare interfacce ipersemplificate (“col gufetto”, come le chiamo io) ha senso solo davanti a compiti ipersemplici. Per attività complesse semplicemente non funziona.

 

Non funziona, però, nemmeno con gli attuali assistenti vocali. Per un programma su computer, perfino un’interfaccia semplificata fornisce almeno qualche indicazione grafica su ciò che si può fare. Con un’interfaccia vocale le cose non funzionano così. Paradossalmente, nota Amadeo, questo riporta gli utenti a una condizione simile a quella delle vecchie interfacce a riga di comando:

 

Using Google Home is a lot like using a command line. With no real interface to speak of, you have an infinite amount of input possibilities—you can say anything to Google Home, and you can type anything into a command line—but getting anything done relies on knowing what commands will actually do something. If you sit down in front of a command line system you've never seen before, you could blindly enter commands into the terminal and hope to hit on something, but you'll quickly find the command line is only as good as the documentation surrounding it.

 

Google è una delle aziende più redditizie del mondo e non avrebbe certo problemi a trovare i fondi per migliorare i servizi: l’anno scorso ha avuto un utile di 16 miliardi di dollari. Tuttavia, non è nuova a questo genere di problemi. Per esempio, con Google in linea strumenti che consentano di trovare libri in modo efficiente dal punto di vista del lettore: la lunga storia di Google Libri è una storia di grandi risultati tecnologici e immense frustrazioni da parte degli utenti. Non sarei sorpreso se la storia si dovesse ripetere e le grandi potenzialità di uno strumento rimanessero prive di utenti semplicemente perché gli utenti non hanno modo di capire in che modo funziona lo strumento stesso.

 

Il corpus CLIPS

  

 

I risultati di un sistema vocale dipendono dalle caratteristiche dei testi cui è applicato. Un conto è essere capaci di riconoscere il parlato di speaker professionisti che leggono singole parole, un conto sbobinare una conversazione spontanea.

 

Per valutare un prodotto è quindi indispensabile sottoporgli campioni di parlato che rispondano a ciò che il prodotto deve fare. Se si tratta di un sistema di dettatura, dovranno essergli sottoposte registrazioni di dettature. Se si tratta di un assistente vocale, dovranno essergli sottoposti testi esempi di conversazione.

 

Mettere assieme materiali realistici di questo tipo è però molto oneroso. Per fortuna, nel caso italiano esiste un corpus sviluppato proprio per questo: il corpus CLIPS, “Corpora e Lessici dell’Italiano Parlato e Scritto”. Il corpus è stato sviluppato grazie a un finanziamento del Ministero dell’Istruzione, dell'Università e della Ricerca (MIUR) dal 1999 al 2004, e la sua sezione che riguarda il parlato è disponibile in linea assieme a una gran quantità di informazioni di presentazione. Per accedere ai materiali, che comprendono trascrizioni e registrazioni di circa 100 ore di parlato, è sufficiente registrarsi (automaticamente) sul sito.

 

Il fuoco del lavoro è rappresentato dalla variazione diatopica. Il corpus CLIPS infatti mira a rappresentare il parlato di 12 città italiane scelte come rappresentative: Bari, Bergamo, Bologna, Cagliari, Catanzaro, Firenze, Genova, Lecce, Milano, Napoli, Palermo, Parma, Perugia, Roma. Il materiale è poi suddiviso in:

 

a) parlato radiotelevisivo (notiziari, interviste, talk show) b) parlato raccolto sul campo (dialoghi raccolti secondo le modalità del map task e del ‘gioco delle differenze’) c) parlato letto d) parlato telefonico

 

La presentazione della variazione diatopica corrisponde a una fissazione degli altri parametri sociolinguistici. Per il “parlato raccolto sul campo”, il riferimento scelto è quello delle persone di livello socioloinguistico “medio o mediosuperiore”: tutti i parlanti usati sono diplomati o studenti universitari che al momento della registrazione avevano tra i 18 e i 30 anni. Non si tratta quindi di una campionatura del “parlato” italiano nel suo assieme, ma solo di una sua sezione. D’altra parte, raccogliere campioni di n varietà di parlato avrebbe richiesto di moltiplicare il lavoro per n!

 

La disponibilità dei file audio e delle trascrizioni permette quindi di valutare in modo abbastanza semplice le prestazioni di strumenti come Google, Dragon o simili. Io ho cominciato a fare questo lavoro, e conto di fornire qui un po’ di dati nelle prossime settimane.

 

Un punto debole: per gli assistenti vocali sarebbe particolarmente utile il parlato delle conversazioni telefoniche. All’interno di CLIPS queste però sono state registrate con una campionatura molto ridotta (8000 Hz) rispetto al resto del corpus (20.050 Hz). Il risultato è una serie di registrazioni poco comprensibili agli esseri umani, e a maggior ragione anche alle macchine. Ciò non toglie che CLIPS resti uno strumento magnifico, e molto utile.

 

Miglioramenti nel WER

  

 

Il mese scorso Microsoft ha annunciato un risultato notevole: il gruppo di ricerca “Speech & Dialog” guidato da Geoffrey Zweig ha sviluppato un sistema che nel riconoscimento del parlato in lingua inglese ottiene un WER (Word Error Rate) del 6,3%.

 

L’annuncio è rilevante anche perché accompagnato da una pubblicazione scientifica che documenta con un minimo di dettaglio la situazione: W. Xiong, J. Droppo, X. Huang, F. Seide, M. Seltzer, A. Stolcke, D. Yu, G. Zweig, The Microsoft 2016 Conversational Speech Recognition System, arXiv:1609.03528, 12 settembre 2016. In molti casi, invece, le aziende sviluppatrici presentano simili percentuali di errore senza contesto, rendendo impossibile sapere che cosa significhino veramente: a seconda del tipo di parlato con cui è confrontato, uno stesso sistema può avere percentuali di errore dallo 0 al 100%. Nel caso Microsoft sappiamo invece che il WER del 6,3% è riferito a un corpus molto usato nell’industria, Switchboard.

 

Più in dettaglio, il corpus è costituito da due componenti.

 

La prima, Switchboard-1, è una raccolta di parlato telefonico messa assieme dalla Texas Instruments tra il 1990 e il 1991 grazie a un finanziamento della DARPA. La versione della raccolta usata oggi è in sostanza quella revisionata nel 1997 e comprende 2.400 conversazioni telefoniche tra 543 parlanti (302 uomini e 241 donne) provenienti da diverse aree degli Stati Uniti.

 

Le conversazioni raccolte non sono del tutto naturali, anzi, sono state messe assieme in modo complesso. Come spiega il sito di presentazione:

 

A computer-driven robot operator system handled the calls, giving the caller appropriate recorded prompts, selecting and dialing another person (the callee) to take part in a conversation, introducing a topic for discussion and recording the speech from the two subjects into separate channels until the conversation was finished. About 70 topics were provided, of which about 50 were used frequently. Selection of topics and callees was constrained so that: (1) no two speakers would converse together more than once and (2) no one spoke more than once on a given topic.

 

Switchboard-2 è stato invece raccolto dal Linguistic Data Consortium (LDC) per un progetto del Ministero della Difesa degli Stati Uniti. Il corpus è composto da 3.638 conversazioni telefoniche di cinque minuti che hanno coinvolto 657 parlanti (358 donne e 299 uomini). Tuttavia, non mi è chiaro se Microsoft abbia usato anche questo (credo di sì), visto che nella forma originale Switchboard-2 non è stato trascritto.

 

I due Switchboard fanno parte fin dal 2000 del pacchetto di valutazione del NIST statunitense. In aggiunta a loro, il pacchetto di valutazione comprende anche il corpus Call Home, usato anch’esso da Microsoft ma con percentuali d’errore ben più alte (11,9% nel caso migliore).

 

Lo strumento usato da Microsof è innovativo: comprende una serie di sistemi basati su reti neurali Alla base si trovano due diverse architetture di modelli acustici basati su “convolutional neural nets” (CNN) e “long-short-term memory nets” (LSTM); entrambi i modelli sono presenti in diverse varianti. La loro combinazione, permette appunto di arrivare al 6,3% (il miglior sistema singolo si ferma al 6.9%).

 

Naturalmente, però, tutto dipende dal corpus! Nel caso di Switchboard, le conversazioni sono una simulazione ben riuscita di un parlato reale (come si può sentire da questo campione). Il WER è stato quindi calcolato su una ragionevole approssimazione di situazioni tipiche... perlomeno per la lingua inglese.

 

Il word processing, la luce e la voce

  

 

Dal punto di vista storico, il lavoro di ufficio ha spesso avuto una forte componente vocale. Anzi, che le persone importanti (tipo i dirigenti di un’azienda) possano scrivere da sole su una tastiera è un’idea molto recente, nata all’inizio degli anni Ottanta negli Stati Uniti e diffusasi solo con l’avvento dell’informatizzazione. Fino quel periodo, per un dirigente usare una tastiera rappresentava una degradazione sociale: un ridursi al rango di segretaria. Un po’ più tollerata era la scrittura a mano, ma l’unica forma di comunicazione davvero dignitosa era quella orale. “Scrivere” una lettera, nella logica di un dirigente, significava dettarla.

 

Qualche ricordo di quel periodo si trova all’interno di un bel libro di Matthew G. Kirschenbaum, Track Changes, di cui sto parlando a parte su un altro blog. Il centro di interesse del libro è il modo in cui gli scrittori hanno iniziato ad adottare il word processor, ma nel ricostruire questa storia l’autore deve parlare spesso del contesto.

 

In retrospettiva, del resto, uno degli aspetti più curiosi della storia dell’informatica è stata la difficoltà ad accettare l’idea scrivere su uno schermo. “The iconic conjunction of a cathode ray or video display and typewriter has a much more tangled history than many of us realize”, dice Kirschenbaum (p. 120), che se ne occupa nel sesto capitolo del suo libro. Non potrei essere più d’accordo. Come ho cercato di raccontare in altre occasioni, l’avvento questa idea fu graduale e sorprendentemente tardo.

 

Storicamente, la “madre di tutte le demo” di Douglas Engelbart, nel dicembre 1968, rappresentò uno spartiacque e mostrò per la prima volta le possibilità della videoscrittura. Come ricorda Kirschenbaum, uno degli spettatori della demo di Engelbart fu Andy van Dam, che iniziò a collaborare sulla videoscrittura con Ted Nelson, teorico dell’ipertesto (p. 121); un altro pioniere ispirato da Engelbart fu Larry Nelson, così come Douglas Hofstadter. Poi Kirschenbaum cita Charles Simonyi, l’informatico ungherese creatore di uno dei primi programmi di videoscrittura e poi di Word, con una delle sintesi più belle che mi sia mai capitato di sentire: “‘In retrospect it all [la videoscrittura] seems so obvious. Uh-uh, it wasn’t obvious to anyone” (p. 124).

 

Chi iniziò a occuparsi di scrittura sul video correva notevoli rischi professionali (p. 125). Tuttavia, è evidente che far comparire le parole su uno schermo produceva un’impressione profonda: tra gli scrittori citati nel libro lo ricorda esplicitamente per esempio Peter Straub. La “scrittura con la luce” (p. 46) aveva insomma fascino. I lavori andarono quindi avanti, e nel giro di pochi anni si iniziò a parlare di WYSWYG (p. 126). Nel 1974 Larry Tesler, insieme ad altri, iniziò a sviluppare un’interfaccia senza modalità (mode) per i computer Bravo. Secondo Tesler questo fu il primo prodotto a funzionare come un programma di scrittura moderno (p. 127). Negli anni successivi, Bonnie McBird, che poi sposò Alan Kay, scrisse con l’interfaccia Gypsy la sceneggiatura del film Tron (pp. 127-131).

 

Ma mentre gli sperimentatori andavano avanti, il mondo delle aziende sposava un altro concetto, completamente basato sulla voce e sulla carta (per la carta, Kirschenbaum cita non solo Sellen e Harper, ma anche il film promozionale di Jim Henson The Paperwork Explosion). Quello era il mondo del “word processing”, etichetta che probabilmente venne usata per la prima volta negli USA nel 1970 secondo una definizione che “includes the concepts of both dictation and typing, utilizes the language of centralization, efficiency, and flow, and compares word processing to what Henry Ford’s assembly line did for automobiles”. Tuttavia, il termine sembra nato da un’interazione “between one of IBM’s German sales executives, Ulrich Steinhilper, and an American counterpart, Samuel J. Kalow” (p. 174). Quest’ultimo sosteneva che un dirigente doveva usare solo due macchine: il telefono e il dittafono (p. 175).

 

Da parte sua, Steinhilper aveva già dal 1955 pensato al textverarbeitung come uno dei due percorsi, assieme all’elaborazione dati, che nascevano dal pensiero e portavano alla realizzazione rispettivamente di testi o di dati. Alla fine, entrambi i percorsi dovevano unirsi sotto il marchio IBM! Steinhilper studiò nella sede della Merceds a Stoccarda il costo della produzione di comunicazioni scritte e lo giudicò tanto alto da giustificare l’acquisto di attrezzature dedicate. All’interno della IBM, nel frattempo, si parlava già di “text processing”, definizione preferita a quella di “word processing”. L’obiettivo finale, comunque, era la carta (p. 176).

 

Questa è la storia che Kirschenbaum racconta soprattutto nel cap. 7 del suo libro, prendendo un punto di partenza insolito, il poeta Wendell Berry. Quest’ultimo pubblicò nel 1987 una lista delle ragioni per cui non intendeva usare il computer: una di queste ragioni era il fatto che i suoi manoscritti venivano già efficientemente ribattuti e corretti dalla moglie! Per questa osservazione, Berry fu (comprensibilmente) criticato e deriso. Tuttavia, l’episodio spinge a distinguere i diversi tipi di lavoro al computer. Scrivere non è solo “composition” ma anche “typing and retyping, to say nothing of the work of correspondence and copying, of filing and bookkeeping, and so forth” (p. 140), e ci si può chiedere chi sia a svolgere questi lavori.

 

Alla fine degli anni Settanta le “killer app” disponibili su computer erano il programma di scrittura e il foglio di calcolo (a partire da VisiCalc, 1979, per Apple II). Gli utenti del foglio di calcolo venivano visti come uomini. “By contrast, the word processor was imagined from the outset as an instrument of what labor and technology historian Juliet Webster has termed ‘women’s work’” (p. 141). Lo stesso era successo per la macchina da scrivere, che però alla fine aveva portato nell’immaginario visivo due figure molto diverse: non solo la segretaria, ma anche lo scrittore di hardboiled. Programmi come Gypsy, invece, erano stati esplicitamente pensati per segretarie. Jeannette Hoffman ha notato che sistemi di videoscrittura come i Wang si basavano su schemi predefiniti di lavoro (un lavoro compartimentalizzato e alienato) e avevano livelli diversi di autorizzazione: una poesia di Patricia Freed Ackerman scritta su un word processor Wang (p. 143) è un buon esempio dei sentimenti che un lavoro di questo genere poteva suscitare.

 

I programmi di scrittura sembravano promettere un approccio diverso. Tuttavia, le prime versioni di WordStar, WordPerfect o Perfect Writer si basavano su un gran numero di comandi non intuitivi e avevano una ripida curva di apprendimento. Erano, insomma, strumenti per chi faceva il “word processor” di mestiere. Secondo Jeannette Hoffman, solo per l’adozione delle interfacce grafiche mise fine a questa impostazione.

 

In ufficio, tutto questo si inseriva all’interno di un paradigma preciso: quello che gli studiosi di management definivano “l’ufficio del futuro” (pp. 143-149). Uno degli obiettivi di questa impostazione era quello di ridurre le perdite di tempo e “razionalizzare” le attività dei lavoratori. Di qui l’idea di una totale divisione del lavoro basata su centri specializzati nel word processing. Per evitare che le segretarie perdessero tempo tra un lavoro e l’altro, per esempio, una delle idee più apprezzate all’epoca era quella di far dettare i dirigenti su nastro e spedire poi le registrazioni al centro di word processing.

Tra i pochi a tenere in considerazione in questo periodo il lavoro delle donne fu Evelyn Berzin con la sua Redactron Corporation, fondata nel 1969 (pp. 149-155). I prodotti della Redactron, come il Data Secretary, vennero presentati come strumenti per eliminare i compiti più ripetitivi – per esempio, la battitura di lettere sempre uguali per le spedizioni di massa – e consentire alle segretarie di dedicarsi a quelli più creativi.

La crisi finale della Redactron Corporation, quando avvenne, alla fine degli anni Settanta, non fu legata a scelte femministe ma alla crisi del concetto generale di “word processing” dal punto di vista organizzativo. A sostituirla fu il modello di “office automation” che nel giro di dieci anni avrebbe portato un computer su tutte le scrivanie. A quel punto, “Executives would increasingly be doing their own typing” (p. 153).

 

Tuttavia, il concetto originale di “word processing” non riguardava solo corpi, mani e tastiere. Includeva anche, come anticipato, “the voice and the ear, speaking and listening, dictation and transcription” (p. 155). Prima di essere elaborate le parole dovevano “originate somewhere”, e questo “was assumed to be oral, from the mouth of an executive”. Come nota Thomas Haigh, i sistemi di dettatura venivano spesso venduti assieme a quelli di scrittura, e tutto il concetto di “word processing” “did not refer exclusively, or even primarily, to the use of full-screen video text editing”. I sistemi inventati includevano spedizione di nastri, dettatura per telefono, registratori “tank type” in cui il nastro permetteva alla segretaria di iniziare a sbobinare la registrazione prima ancora che il dirigente avesse finito di dettare, e così via (p. 156). In un episodio del 1960 di The Twilight Zone si vede un famoso autore teatrale che opera unicamente dettando.

 

E d’altra parte, dice Kirschenbaum, “today dictation is once again rising in importance” (p. 158), essendo diventata finalmente usabile - come cerco di raccontare su questo blog. Il più famoso portavoce di queste tecnologie nell’ambito letterario è Richard Powers, che, secondo Kirschenbaum, vede il “word processing” come “fundamentally multimodal, involving speech, pen or stylus, touch, and the keyboard” (p. 159). Com’è ovvio, anche qui condivido completamente l’idea.

 

Matthew G. Kirschenbaum, Track Changes. A Literary History of Word Processing, Cambridge (Massachusetts), Belknap Press, 2016, pp. xvi + 344, € 25, ISBN 978-067441707-6. Letto nella copia della Biblioteca di Lingue e letterature romanze dell’Università di Pisa.

 

Sogni e realtà degli assistenti vocali

   

L’interazione vocale con i computer oggi passa in buona parte attraverso assistenti vocali come Siri (Apple) o Cortana (Microsoft). Questi strumenti cercano di unificare le funzioni di ricerca attraverso un’interfaccia dotata di una “personalità”, e le possibili scelte in questo campo sono numerose.

 

L’idea non è nuova, anzi. La conversazione con un computer dotato di “personalità” è un’interfaccia intuitiva. In passato, questa è stata una delle prime modalità d’interazione immaginate quando ancora non si erano fatti davvero i conti con le possibilità e i limiti dei dispositivi informatici. Di conversazione si è poi parlato poco, ma l’idea è rimasta nella consapevolezza di molti teorici delle interfacce. Un bell’esempio è dato da un famoso video di presentazione rilasciato da Apple nel 1987 che mostra il modo in cui avrebbe potuto funzionare un dispositivo chiamato “Knowledge navigator” intorno al 2011:

 

 

Tuttavia, come ha notato Walter Mossberg in un articolo recente, al di fuori di ristrettissimi casi d’uso gli assistenti vocali possono risultare sorprendentemente stupidi:

 

why does Siri seem so dumb? Why are its talents so limited? Why does it stumble so often?... Siri’s huge promise has been shrunk to just making voice calls and sending messages to contacts, and maybe getting the weather, using voice commands. Some users find it a reliable way to set timers, alarms, notes and reminders, or to find restaurants. But many of these tasks could be done with the crude, pre-Siri voice command features on the iPhone and other phones, albeit in a more clumsy way.

 

Secondo Mossberg, comunque, il problema non sta nel riconoscimento del parlato: “In my recent experience, Siri has become quite good at transcribing what I’m asking, just not at answering it”. Il giudizio è espresso per l’inglese, ma la mia sensazione è che valga ormai anche per l’italiano. E quella di Siri non è nemmeno un’inferiorità teorica e generica, ma un’inferiorità pratica rispetto a un prodotto concorrente come Google Now per quanto riguarda per esempio le funzioni di ricerca:

 

In recent weeks, on multiple Apple devices, Siri has been unable to tell me the names of the major party candidates for president and vice president of the United States. Or when they were debating. Or when the Emmy awards show was due to be on. Or the date of the World Series. When I asked it “What is the weather on Crete?” it gave me the weather for Crete, Illinois, a small village which — while I’m sure it’s great — isn’t what most people mean when they ask for the weather on Crete, the famous Greek island. Google Now, on the same Apple devices, using the same voice input, answered every one of these questions clearly and correctly.

 

Mi chiedo quali siano state le esatte espressioni usate da Mossberg, il quale tra l’altro dice che dopo le sue segnalazioni Apple ha eseguito interventi e ora mostra i risultati corretti. Io per esempio, formulando in italiano alcune delle domande citate, oltre a notare che suonano un po’ goffe, ottengo queste risposte:

 

“Chi sono i candidati alla presidenza degli Stati Uniti?”
Siri: “OK, ecco cos’ho trovato su Internet su ‘Chi sono i candidati alla presidenza degli Stati Uniti?’” e ricerche web corrette, con rinvii a siti che presentano i candidati
Google: ricerche web corrette, con rinvii a siti che presentano i candidati

 

“Quando ci sono i dibattiti tra i candidati alla presidenza degli Stati Uniti?”
Siri: “OK, ecco cos’ho trovato su Internet su ‘Quando ci sono i dibattiti tra i candidati alla presidenza degli Stati Uniti?’” e ricerche web generiche, con link a Wikipedia
Google: ricerche web generiche, con link a Wikipedia

 

“Quando ci sono le World Series?”
Siri: “Non so quando si terrà il prossimo incontro di World Series. La squadra Mets ha sconfitto la squadra Royals nell’ultimo incontro del 2 novembre 2015. Il punteggio finale è stato: 2 a 7.”
Google: ricerche web corrette, con link a Wikipedia

 

Vediamo invece alcuni, più spontanei, equivalenti italiani:

 

“Chi è il Presidente del Consiglio?”
Siri: rinvio alla voce di Wikipedia “Presidente del Consiglio dei ministri della Repubblica Italiana”
Google: lo stesso.

 

“Quando c’è la Formula 1?”
Siri: “Mi dispiace, Mirko, ma non riesco a trovare informazioni su questo campionato”, però mostra in accompagnamento link a siti web con il calendario corretto
Google: rinvio al sito web con il calendario corretto

 

“Quando c’è la prossima partita del Pisa?”
Siri: “La partita Torino-Pisa è il 29 novembre 2016 alle nove di sera” (risposta sbagliata)
Google: “Pisa affronterà Latina sabato alle 15 e zero minuti” (risposta giusta)

 

“Chi è Walter Mossberg?”
Siri: “Ecco cosa ho trovato cercando ‘Chi è Walter Moss Berg su Internet’” e ricerche web non pertinenti
Google: profilo della persona corretta.

 

Qui Google sembra decisamente superiore a Siri – che nella metà dei casi, per ragioni diverse, non riesce a fornire la risposta corretta. Oltre la ricerca, poi, Mossberg nota che Siri ha anche molte difficoltà a usare dati che si trovano sul dispositivo (per esempio, nelle schede dei contatti) o su iCloud. Il giudizio complessivo è che quindi oggi Siri sia “too limited and unreliable” per reggere il confronto con la concorrenza.

 

Personalmente, ho visto che uso Siri soprattutto quando sto camminando. Spesso lo faccio per dettare messaggi o scrivere all’interno di Whatsapp; più raramente, per far partire una chiamata vocale. Ogni tanto chiedo cose tipo “Ehi, Siri, com’è il meteo?”. Più spesso dico di fissare una sveglia per una certa ora, oppure faccio partire un timer. L’affidabilità è notevole, nonostante il mio telefono sia un iPhone 4S di quasi cinque anni, però le funzioni cominciano a sembrare davvero limitate – anche perché per gestire buona parte dei miei impegni faccio ricorso ad applicazioni non-Apple (Outlook per la posta, Google Calendar per l’agenda) con cui l’integrazione è limitata.

 

Com’è ovvio, però, niente di tutto questo ha a che fare con la “personalità” del sistema. Più importanti sarebbero capacità pratiche. Per esempio, abitando vicino allo stadio, per questioni di spostamenti e parcheggi a me tornerebbe utile sapere quand’è che il Pisa gioca in casa. Tuttavia una richiesta del tipo “metti nel mio calendario le prossime partite del Pisa che si svolgono a Pisa” sembra ancora molto lontana dalle competenze non solo di Siri, ma anche di Google.

 

Interfacce vocali su sistemi Linux

 

Pubblico una nuova relazione realizzata per il mio corso di Linguistica italiana II del 2015-2016 (Modulo A, CdS in Informatica umanistica, Università di Pisa, anno accademico 2015-2016) .

 

In questo caso, l’argomento è tecnico. Ludwig Bargagli ha infatti realizzato uno studio eccezionalmente approfondito su tutti i sistemi di sintesi vocale e riconoscimento del parlato che possono essere installati su sistemi Linux, direttamente o tramite emulatori di Windows. Il risultato è il lavoro più completo che mi sia capitato di vedere in questo settore.

 

Tutti i programmi sono stati provati in prima persona dall’autore (su Lubuntu), e credo che la sintesi finale possa essere molto utile a chi lavora su sistemi di questo tipo. Anche in questo caso, il testo è scaricabile in formato PDF.

 

Le personalità di Siri e Cortana

  

 

Per il mio corso di Linguistica italiana II (Modulo A, CdS in Informatica umanistica, Università di Pisa, anno accademico 2015-2016), tre studentesse hanno eseguito durante l’estate un’interessante ed estesa analisi delle differenze tra Siri e Cortana. Il lavoro approfondisce quanto avevo già presentato in precedenza attraverso un’altra relazione e, anche in questo caso, presento qui il testo in formato PDF.

In sostanza, Francesca Bellante, Elisa Salatti ed Eleonora Zedda hanno posto ai due assistenti vocali lunghe serie di domande in italiano che puntavano a mettere in luce le differenze tra queste “personalità” artificiali. La conclusione che ne hanno tratto è che le differenze tra i due assistenti siano piuttosto marcate e coerenti. Cortana sembra realizzato per dare l’impressione di una personalità sempre aperta ed espansiva. Siri invece risponde ad alcune categorie di domande personali dando l’impressione di richiudersi, adottando un atteggiamento difensivo.

 

In generale, le scelte di progetto dietro alle due “personalità” mi sembrano ragionevoli. Mi chiedo però quale differenza reale possa produrre questa differenza. Insomma, a parità di capacità di risposta, gli utenti interagiscono meglio con Siri o con Cortana? Non lo sappiamo, ma questa relazione è un buon punto di partenza per esaminare la cosa più in dettaglio.

 

 

Ricerca vocale con Google: sostituzioni e idiosincrasie

  

 

Ho già accennato alla ricerca vocale con Google, possibile per esempio attraverso la home page di Google stesso aperta con browser Chrome.

 

A quel che capisco, la ricerca vocale opera attraverso il pacchetto di tecnologie Google che ho descritto l’altro ieri. Tuttavia in questo caso c’è una componente in più. Quando si dice qualcosa all’interno di una casella di ricerca, infatti, spesso il sistema interviene sulla trascrizione “naturale” e propone invece chiavi di ricerca simili ma non identiche. Ovviamente l’operazione è compiuta per facilitare la ricerca, ma i risultati sono a volte curiosi.

 

Per chiarire il meccanismo, partiamo dalla ricerca più diffusa, basata sulla digitazione. Lasciando da parte il meccanismo dei suggerimenti, Google opera in almeno tre modi diversi, a seconda di quanto la parola o la frase che si scrive nella casella di ricerca corrisponda a una ricerca “verosimile”.

 

1. Se nella casella di ricerca di Google scrivo “alfabetizzazione”, mi arrivano risultati relativi alla ricerca. E va bene.

 

2. Se scrivo “alfabetizzazzione”, con due doppie z, mi arriva un buon numero di risultati basati su questa grafia (molti dei quali provengono da titoli di giornale, documenti scolastici, avvisi rotariani…), ma mi appare anche un suggerimento, “Forse cercavi: alfabetizzazione”, con la possibilità di fare la ricerca sulla grafia corretta.

 

3. Se sbaglio un po’ di più la grafia e scrivo “alfabetizazzione”, sacrificando la prima z, mi arrivano direttamente, come avverte Google, i “Risultati relativi a alfabetizzazione”, scritto con grafia corretta. Appare inoltre la possibilità di fare comunque la ricerca usando la grafia sbagliata (“Cerca invece alfabetizazzione”).

 

Facendo la ricerca vocale, invece, innanzitutto è inutile provare a pronunciare per esempio la prima z come scempia anziché come doppia: appare comunque la grafia corretta (e del resto, per “sbagliare” la pronuncia della seconda z, che nell’italiano standard è comunque doppia, che cosa si dovrebbe fare? Rafforzarla ancora?). Le pronunce vengono interpretate e spinte sulle parole che corrispondono a chiavi di ricerca frequenti. Del resto, questa è una buona simulazione del modo in cui anche gli esseri umani interpretano il parlato!

 

Un mio studente, Alberto Guaita, ha notato che in qualche caso il meccanismo produce risultati diversi nella ricerca rispetto alla dettatura all’interno di documenti (che pure, presumibilmente, sfrutta lo stesso sistema di riconoscimento). Se si detta “Alchemico” nella casella di ricerca, per esempio, la parola viene presentata come “Alkemico”, che è il nome di una catena di negozi (il nome in questa grafia compare in 3640 risultati: Google lo preferisce ad “alchemico”, che compare in 262.000 pagine). Se si detta la parola in un Documento Google, invece, compare “alchemico” (prove compiute il 5 ottobre 2016). Nella ricerca non compare nessun avviso sui criteri di sostituzione, ma l’input viene verosimilmente ricondotto con forza alle chiavi di ricerca privilegiate da Google.

 

In altri casi, lavorando durante la dettatura, Google fa spesso vedere nella casella di ricerca l’inizio della trascrizione (corretto), e poi lo sostituisce con una ricerca più “probabile”. Se si pronuncia “Il pesce non ha bocca”, per esempio, nella mia esperienza compare prima “Il pesce non ha…” e poi la ricerca completa viene eseguita su “Il pesce non abbocca”, nonostante la forte differenza fonetica tra le due espressioni. Anche all’interno di documenti, se si detta “Il pesce non ha bocca” compare scritto “il pesce non abbocca”; tuttavia, non c’è nessuna visualizzazione di fasi intermedie di trascrizione.

 

Altre idiosincrasie più specifiche, notate da Alberto Guaita e in parte verificate anche da me a inizio settembre, ma oggi non replicabili, sono:

 

1. Ricercando numeri a 5 cifre che terminano con 991, 992, 993, e così via, le migliaia venivano interpretate come il numero di una legge italiana e il “99x” diventava l’anno di promulgazione: “23.994” diventava così la legge 23 del 1994. Per la corretta ricerca occorreva pronunciare le due componenti del numero come se fossero due numeri distinti, ossia prima 23 e poi 994; il sistema poi le univa in un numero solo.

 

2. Sempre con i numeri, non era possibile chiedere di dividere 5 per un numero (per esempio, “5/73” o “5/40”), poiché il programma cambia il 5 in una V (numero romano) e modifica la ricerca.

 

3. Frasi come “togligli la giacca” o “spediscili via” venivano riportate senza il pronome enclitico.

 

In apparenza, il sistema viene aggiornato spesso; e la cosa non mi sorprende.

 

Come funziona il riconoscimento vocale di Google

  

 

Le attività di Google nel settore delle interfacce vocali e delle tecnologie del linguaggio si stanno intensificando. Oggi pomeriggio è previsto che Google presenti un nuovo prodotto hardware, Google Home, direttamente rivolto a contrastare Alexa di Amazon. Dal mio punto di vista (al di là delle ovvie questioni di privacy), mi chiedo soprattutto se Google Home supporterà l’italiano: Alexa funziona solo in inglese.

 

Su un altro piano, 2016 Google ha iniziato a introdurre un nuovo sistema di traduzione automatica. Il nuovo sistema, GNMT, si basa su reti neurali e per la traduzione tra inglese e cinese mandarino ha già sostituito il precedente sistema, basato – come tutti quelli per altre coppie di lingue – sulla statistica; il miglioramento di prestazioni dichiarato arriva quasi al 60% (annuncio; articolo completo). Anche qui, sono curioso di vedere se è vero… ammesso che il sistema arrivi a coprire presto l’italiano.

 

Le reti neurali sono state però usate da tempo, sembra, in un tassello chiave di questo blocco di tecnologie, il riconoscimento vocale. Google incorpora i servizi di riconoscimento vocale nei propri prodotti e contemporaneamente li commercializza attraverso Google Cloud Speech API (in concorrenza con Nuance). Dal punto di vista tecnico, sembra che il riconoscimento vocale di Google impieghi reti neurali già dal 2012. Qualche dettaglio sul funzionamento del sistema è stato fornito l’anno scorso in un post del Google Research Blog; sintetizzo qui di seguito i contenuti fondamentali, ma tutto il post va letto con attenzione.

 

Google ha iniziato a supportare i servizi vocali nel 2009, usando come modello acustico il Gaussian Mixture Model (GMM), rafforzato con altre tecniche. Dal 2012 ha iniziato a usare le Recurrent Neural Networks (RNNs), e in particolare un’architettura proposta nel 1997 e chiamata LSTM RNNs (“Long Short-term Memory Recurrent Neural Networks”). Quest’ultima è, credo, lo strumento usato ancora oggi – per tutte le lingue, incluso l’italiano? Probabilmente sì, ma non ho trovato informazioni più specifiche.

 

Le reti neurali richiedono allenamento, e i corpora usati per altre attività di elaborazione del linguaggio non aiutano molto, perché sono composti soprattutto di testi scritti, molto lontani dall’uso parlato normale. Google ha quindi chiesto la donazione volontaria di grandi raccolte di posta vocale (“voicemail”) e su queste ha poi condotto l’elaborazione in un modo che non mi torna del tutto chiaro (usando una “delicate iterative pipeline”, si dice… ma come sono stati valutati, esattamente, i risultati?). Il processo, si dichiara, ha prodotto grandi miglioramenti e ha permesso addirittura di arrivare all’inserimento della punteggiatura nei testi – cosa che per l’italiano non ho ancora visto.

 

Google dichiara che l’architettura LSTM RNNs funziona attraverso “discriminative training,” differenziando le unità fonetiche invece di modellarle in modo indipendente (“differentiating phonetic units instead of modeling each one independently”). Non ho approfondito il discorso e non sono in grado di valutare l’osservazione, ma parto dal presupposto che le cose stiano così. Dopodiché, arriva il momento di valutare quanto nella pratica il sistema funzioni per l’italiano.

 

Un confronto tra assistenti vocali

Per il mio corso di Linguistica italiana II (Modulo A, CdS in Informatica umanistica, Università di Pisa, anno accademico 2015-2016) una brava studentessa, Eleonora Marini, ha presentato qualche settimana fa un confronto tra assistenti vocali.

 

Gli assistenti presi in considerazione sono stati i principali:

• Siri 
• Cortana 
• Google Now 
•  S Voice

Il lavoro mi sembra molto interessante, anche in considerazione della scarsità di confronti sistematici per l’italiano. Il panorama è oltretutto in rapido mutamento – e per questo mi sembra importante presentare qui il lavoro, d’accordo con l’interessata, in formato PDF. Soprattutto, spero che su questa base possano essere preparati molti altri confronti sistematici, in futuro.

 

Dettatura con Mac

Windows non è l’unico sistema operativo a includere funzioni di riconoscimento vocale. Anche i sistemi Mac, a partire dal sistema operativo OS X 10.8.2 (2012), hanno un sistema di riconoscimento in italiano. Come nel caso di Windows e di Dragon, questo sistema è offline e non ha quindi bisogno di collegamento internet.

 

Alcune informazioni sono disponibili sul blog di Salvatore Aranzulla.

 

Non ho ancora provato di persona il sistema, ma un amico è stato così gentile da farlo per me con il file audio che ho usato nelle altre prove. Il risultato è stato questo:

 

Non è comunque facile fare stime anche quando si guardano le cose dal punto di vista del lettore. Negli Stati Uniti, blog di successo come la finta un post un po' in poi registra centinaia di migliaia di accessi al giorno. In Italia, l'unico blog che sembrano Duncan pubblico non specialistico è quello di Beppe grillo, spesso collocato nelle liste dei siti italiani più visitati.

 

Il testo originale, in cui ho indicato in corsivo gli errori, era:

 

Non è comunque facile fare stime anche quando si guardano le cose dal punto di vista del lettore. Negli Stati Uniti, blog di successo come l’Huffington Post o BoingBoing registrano centinaia di migliaia di accessi al giorno. In Italia, l’unico blog che sembra noto anche a un pubblico non specialistico è quello di Beppe Grillo, spesso collocato nelle liste dei siti italiani più visitati.

 

Su 64 parole del testo di partenza, ne sono state sbagliate 12 (“l’Huffington Post o BoingBoing registrano”, “sembra noto anche a un”, “Grillo”), ma quattro di esse sono nomi propri. La percentuale di errore è quindi circa del 19% complessivo e del 12% se si considerano inevitabili gli errori sui nomi propri. Leggermente meno accurato degli altri sistemi di cui ho parlato finora, ma comunque di buon livello.

 

Dettatura con Google

I servizi di Google comprendono una grande quantità di prodotti online e offline. Tra questi non manca un sistema di riconoscimento vocale, che si manifesta in varie forme. Per esempio, la casella di ricerca visualizzata nella home di Google usando il browser Chrome include a destra l’icona di un microfono per il riconoscimento vocale:

 

Cliccando sull’icona si può dettare una ricerca a Google, con percentuali di successo sorprendentemente buone.
 

Il riconoscimento vocale è gestito da Google attraverso le Web Speech API, integrate in molti altri prodotti di Google e di terze parti. Il sistema è molto sofisticato e permette anche la dettatura, che nel 2015 è stata integrata anche in Documenti Google. Aprendo un documento con Documenti Google, infatti, nel menu “Strumenti” è adesso possibile attivare la funzione “Digitazione vocale” (etichetta non troppo intuitiva!), che fornisce risultati di alta qualità.

 

Per vedere quanto è alta la qualità io ho fatto una prova con la registrazione che ho già usato per Dragon NaturallySpeaking. Per far ascoltare il file a Google ho usato il missaggio stereo sul mio computer e ho aperto Documenti Google all’interno di Chrome per Windows, versione 49.0.2623.87 m.

 

Il testo originale (provenienti dal mio libro L’italiano del web, Roma, Carocci, 2011, p. 147) dice:

 

Non è comunque facile fare stime anche quando si guardano le cose dal punto di vista del lettore. Negli Stati Uniti, blog di successo come l’Huffington Post o BoingBoing registrano centinaia di migliaia di accessi al giorno. In Italia, l’unico blog che sembra noto anche a un pubblico non specialistico è quello di Beppe Grillo, spesso collocato nelle liste dei siti italiani più visitati.

 

La mia lettura, registrata usando Dragon Recorder 1.3 su iPhone 4S e scaricando il risultato sotto forma di file .wav, è questa:

 

 

La trascrizione fornita da Google, in cui evidenzio in corsivo gli errori e integro tra parentesi quadre l’unica parola saltata, è stata:

 

Non è comunque facile faresti neanche quando si guardano le cose dal punto di vista del lettore. Negli Stati Uniti, blog di successo come la finta un post su Boing Boing registrano centinaia di migliaia di accessi al giorno. In Italia, l'unico blog che sembra nota anche [a] un pubblico non specialistico e quello di Beppe Grillo, spesso collocato nelle liste dei siti italiani più visitati.

 

Su 64 parole del testo di partenza, ne sono state sbagliate nove (“fare stime”, “l’Huffington Post o”, “noto”, “a” e “è”) di cui un solo nome proprio. La percentuale di errore è quindi circa del 14% complessivo e del 12% se si considerano inevitabili gli errori sui nomi propri… che sono riconosciuti in forma molto efficiente. Molto meglio di Dragon per quanto riguarda i nomi propri, un po’ peggio per quanto riguarda la qualità complessiva.

 

Prova di Dragon NaturallySpeaking

Per l’italiano esiste in sostanza un unico prodotto per il riconoscimento vocale in ambito di “produttività”, cioè facilmente utilizzabile con gli strumenti da ufficio: Dragon® NaturallySpeaking. Prodotto da Nuance, questo programma è arrivato alla versione 13 per la lingua italiana (14 per la lingua inglese) e può essere installato su PC a un costo che sul sito aziendale parte da € 99 per la versione base. Sullo stesso sito sono inoltre disponibili versioni dotate di comandi aggiuntivi per il controllo del computer e di piccoli accessori per facilitare il lavoro.

 

Dragon permette sia la dettatura sia il controllo del computer attraverso la voce. Sul controllo non vorrei ancora dire molto, perché credo che per ottenere risultati soddisfacenti sia molto importante l’allenamento. Tuttavia, per la dettatura, Dragon è notevole. Forse dal punto di vista del riconoscimento puro e semplice Google adesso fornisce un risultato migliore, e spero di verificare questa impressione più avanti con qualche dato preciso. Però Google non si integra con i programmi da ufficio, e in ciò Dragon non ha semplicemente concorrenti. Io lo trovo molto efficiente... e ammetto che questo post è stato in buona parte dettato con Dragon!

 

Dal punto di vista operativo, l’installazione di Dragon (Premium, versione 13 per Windows) avviene da CD o da installatore scaricabile. Dopo l’installazione, c’è una brevissima fase (pochi minuti) di addestramento al riconoscimento del parlato di una singola persona. Anche in seguito è poi possibile effettuare un riconoscimento e addestrare il programma su un assieme di testi – ma finora ho sempre preferito evitare. In ogni caso, non è mai stato necessario usare il microfono in dotazione alla versione che ho ordinato io. Il sistema di microfoni del Surface che uso normalmente si è rivelato del tutto adeguato al compito.

 

Completato l’addestramento, Dragon funziona in modo piuttosto intuitivo. Facendo partire il programma in cima allo schermo compare una minuscola finestra che permette di attivare e disattivare il riconoscimento vocale. Quando il riconoscimento è attivo è possibile usarlo per dettare, per esempio, direttamente all’interno di Word: vicino al normale cursore appare una minuscola fiammella verde e da quel momento Dragon trascrive nella pagina di Word (o di un altro programma) ciò che sente attraverso il microfono. Inoltre, numerose funzioni aggiuntive permettono di eseguire le operazioni più comuni nell’elaborazione di testi. Per esempio: aprire virgolette, annullare le ultime azioni, selezionare e modificare il testo.

 

Anche dettando a una velocità naturale, senza bisogno di scandire le parole, Dragon ha percentuali di successo sorprendenti. Dal punto di vista dell’utente, il principale collo di bottiglia è quindi rappresentato dalla capacità di pensare a che cosa dettare: il programma riesce a tenere il passo.

 

Come per quasi tutti i programmi di questo tipo, occorre peraltro ricordarsi di dettare la punteggiatura. Sia le virgole sia i punti fermi a fine frase devono essere esplicitamente indicati al programma. Lo stesso succede con parole che, insolitamente, hanno un’iniziale maiuscola.

 

Per quantificare il funzionamento ho scelto sei righe di testo provenienti dal mio libro L’italiano del web (Roma, Carocci, 2011, p. 147). Il testo originale dice:

 

Non è comunque facile fare stime anche quando si guardano le cose dal punto di vista del lettore. Negli Stati Uniti, blog di successo come l’Huffington Post o BoingBoing registrano centinaia di migliaia di accessi al giorno. In Italia, l’unico blog che sembra noto anche a un pubblico non specialistico è quello di Beppe Grillo, spesso collocato nelle liste dei siti italiani più visitati.

 

La mia lettura, registrata usando Dragon Recorder 1.3 su iPhone 4S e scaricando il risultato sotto forma di file .wav per l’elaborazione con Dragon (Strumenti > Trascrivi registrazione…), è questa:

 

 

La trascrizione fornita da Dragon è stata questa, in cui evidenzio in corsivo gli errori:

 

Non è comunque facile fare stime anche quando si guardano le cose dal punto di vista del lettore. Negli Stati Uniti, blog di successo come la finto post o Borboni registrano centinaia di migliaia di accessi al giorno. In Italia, l’unico blog che sembrano anche un pubblico non specialistico è quello di Beppe grillo, spesso collocato nelle liste dei siti italiani più visitati.

 

Su 64 parole del testo di partenza, ne sono state sbagliate otto (“l’Huffington Post”, “BoingBoing”, “sembra noto”, “a” e “Grillo”); quattro di esse però erano nomi propri. La percentuale di errore è quindi circa del 12% complessivo e del 6% se si considerano inevitabili gli errori sui nomi propri. Anzi, non è poco che il programma sia stato in grado di mettere le giuste maiuscole sia a “Stati Uniti” sia a “Beppe”.

 

Percentuali di successo

Quanto è accurato il riconoscimento vocale, oggi? Come per molte altre domande in linguistica, il primo livello di risposta deve essere: “dipende”.

 

Quasi un anno fa alcune delle massime cariche Apple e Google hanno fatto qualche dichiarazione polemica ma generica in proposito. Nel maggio del 2015 Sundar Pichai, allora Senior Vice President e oggi Amministratore delegato di Google, ha infatti vantato le percentuali di successo dell’azienda nel riconoscimento vocale. Alla manifestazione I/O di Google e in un’intervista a The Verge pubblicata il 29 maggio 2015 (da cui riprendo le parole) la sua dichiarazione è stata:

 

Just in the last three years, we have taken things like error in word recognition down from about 23 percent to 8 percent. And it’s because of what we call deep neural nets.

 

Del fatto che Google oggi faccia ricorso non solo alla statistica ma a “deep neural nets” si dovrà parlare più avanti. Per quanto riguarda la percentuale grezza, però, alle dichiarazioni di Pichai ha risposto pochi giorni dopo Craig Federighi, “Senior Vice President of software engineering” per Apple. Federighi ha infatti dichiarato l’8 giugno 2015 alla Worldwide Developers Conference della Apple che Siri ha una percentuale di errore del 5% e che questo “word error rate” è “an industry-leading number”.

 

Non mi sembra che in seguito ci siano state dichiarazioni dello stesso peso; sarebbe inoltre sorprendente se in un anno ci fossero stati cambiamenti drammatici della situazione. Ma che cosa significano questi numeri?

 

Innanzitutto, mentre non è chiarissimo che cosa intenda Pichai parlando di “error in word recognition”, la misura indicata da Federighi è ben nota. Il “word error rate”, o WER, nella sua forma più semplice si ottiene dividendo per il numero totale delle parole in un testo la somma delle parole erroneamente sostituite, cancellate o inserite durante il riconoscimento automatico; spesso si esprime non in frazioni ma in percentuali. Probabilmente Pichai parlava della stessa cosa, ma un margine di incertezza c’è.

 

Il WER di un sistema automatico poi dipende molto dal lavoro che deve fare. Come mostrano anche alcuni dati sintetizzati in The Voice in the Machine di Roberto Pieraccini (p. 188 e dintorni), un sistema automatico può ottenere risultati molto accurati se l’input è in qualche modo circoscritto, cioè se si tratta per esempio di discorsi scanditi e fatti con un vocabolario limitato. Per testi più liberi, come conversazioni o trasmissioni radiofoniche, a cavallo del millennio le percentuali d’errore si collocavano poco sotto il 20%, che è più o meno la percentuale indicata da Pichai. L’incertezza più grossa è quindi: a quali tipi di parlato fanno riferimento Apple e Google? Se si tratta del parlato generico dei loro utenti, nella somma di tutti i casi d’uso, la percentuale di errori è veramente buona.

 

Infine, do per scontato che le percentuali indicate da Pichai e Federighi si riferiscano unicamente all’inglese. Con altre lingue, a cominciare dall’italiano, i risultati sono probabilmente peggiori… anche se le differenze fonetiche potrebbero in alcuni casi giustificare risultati migliori!

 

Il nucleo della questione è comunque un altro. Le trascrizioni eseguite da esseri umani hanno tassi d’errore collocati tra il 2 e il 4%, e quindi continuano ancora oggi a essere preferibili a quanto fanno Google e Apple. Non è uno scalino da poco: il passaggio dall’8% dichiarato da Pichai al 2% di un bravo ascoltatore umano corrisponde probabilmente a una notevole differenza di usabilità. Tuttavia, è chiaro che questa percentuale non potrà che migliorare. Superata la soglia del 2%, la faccenda si farà seria!

 

Microsoft Speech Recognition, l’italiano e l’inglese

Creare voci sintetiche è complesso… ma nella costruzione delle interfacce vocali è comunque la parte facile. Mettere il computer in grado di usare il parlato umano è decisamente più difficile.

 

I primi sistemi commerciali in grado di trascrivere il parlato normale, senza stacchi artificiali tra le parole, hanno meno di vent’anni. Le funzioni di riconoscimento vocale (Text-to-Speech) hanno tuttavia fatto di recente passi da gigante.

 

Va però detto subito che, a differenza di quanto accade di solito, l’italiano non è supportato da uno dei principali prodotti di questo tipo. Il sistema di riconoscimento vocale di Windows 10 copre infatti solo sei lingue: inglese (con cinque diverse pronunce locali), francese, tedesco, giapponese, cinese mandarino e spagnolo. Per una volta l’italiano non è entrato nel gruppo di punta, e chissà se sarà supportato più avanti.

 

Se si vuole provare il prodotto, comunque, è sufficiente impostare su un computer con Windows una di queste prescelte come lingua del sistema operativo (Pannello di controllo > Orologio e opzioni internazionali > Lingua). Io ho provato con l’inglese, e al riavvio ho potuto attivare senza problemi il sistema di riconoscimento vocale (con il percorso che in italiano è: Pannello di controllo > Accessibilità > Riconoscimento vocale). A quel punto, nella parte alta dello schermo è comparsa questa finestrella:

 

Tuttavia, i risultati non sono stati particolarmente positivi. Do per scontato che la mia pronuncia dell’inglese, per quanto comprensibile a esseri umani, sia molto diversa da quella accettabile per Microsoft Speech Recognition. Con un po’ di fatica sono quindi riuscito a far partire programmi sul computer (aiutato anche da una finestra di dialogo che presenta diverse opzioni), però la dettatura è assolutamente deludente. L’ho messa alla prova i versi iniziali di una celebre poesia di Yeats, An Irish Airman Foresees His Death, di cui avevo dovuto curare la pronuncia molti anni fa, per un esame universitario:

 

I know that I shall meet my fate
Somewhere among the clouds above;
Those that I fight I do not hate,
Those that I guard I do not love…

 

Il risultato non è stato dei migliori, anche se ha una certa qualità da poesia metafisica:

 

I knew that they should and the roof E
somewhere under a mound to oust abound
those that pay for my item if he knows a thing
of the kind enough to allow!

 

In queste circostanze, Microsoft Speech Recognition non serve a molto. Per mia fortuna, esistono però diversi sistemi sostitutivi che coprono l’italiano, e il più importante è Dragon Dictate, di cui spero di parlare qui tra poco.

 

Confronto di voci

Avendo parlato separatamente di Elsa e di Carla, provo adesso a confrontare direttamente le due voci.

 

Innanzitutto, parto da questo blocco di testo, che mi sembra rappresentativo di ciò che si può trovare in linea e viene da un sito dedicato alle interfacce vocali:

 

Le persone parlano in modo più veloce di quanto non siano capaci di scrivere al computer; la conversazione telefonica offre quindi una buona alternativa all’input attraverso la tastiera. Le applicazioni vocali, infatti, sono mezzi di comunicazione molto versatili; il telefono e l’utilizzo della voce sono strumenti familiari, richiedono uno sforzo fisico minimo e lasciano liberi occhi e mani.

 

Questa è la lettura che ne offre Elsa (Microsoft), su Windows 10, impostata a velocità media:

 

 

Questa è invece la lettura di Carla (Ivona):

 

 

Non mi sembra ci sia confronto: la voce di Carla è molto più naturale (anche se mi colpiscono l’innalzamento di tono e l’allungamento nella pronuncia della parola “offre”). Entrambe le voci, peraltro, riconoscono e pronunciano correttamente le parole straniere inserite nel testo italiano, computer e input.

 

Ecco la lettura di una frase che contiene anche nomi propri e parole straniere di uso meno comune, proveniente dal bollettino AIB:

 

Paul Needham, nel suo Venetian printers and publishers in the fifteenth century, procede a un'indagine serrata sugli stampatori veneziani del '400, tanto noti nel loro insieme alla storia del libro quanto poco indagati nel dettaglio.

 

Tutti e due le voci interpretano correttamente ’400 come Quattrocento. Tuttavia, mentre Elsa legge nomi e parole inglesi con pronuncia inglese, l’interfaccia online di Carla non fa differenza e le legge con pronuncia italiana.

 

Lettura di Elsa:

 

 

Lettura di Carla (Ivona):

 

 

Anche in questo caso, la pronuncia di Carla mostra dei tratti insoliti, per cui non riesco a individuare una ragione precisa: in particolare, mi sembrano molto lunghe le a accentate di serrata e di dettaglio, ma non quelle di stampatori e di indagati. Che siano variazioni inserite a caso per rendere la voce un po’ meno meccanica?

 

Pieraccini, The Voice in the Machine

La migliore sintesi divulgativa sulle interfacce vocali è in lingua inglese, ma è opera di un italiano. The Voice in the Machine (sottotitolo: Building Computers That Understand Speech), pubblicata nel 2012, è un raro caso di alta divulgazione scritta da un addetto ai lavori; e non guasta che all’interno ci siano anche riferimenti alla lingua italiana e a esperienze italiane, a cominciare da quelle dello CSELT. Sono stato quindi ben contento di inserire questo libro nel programma del mio corso di Linguistica italiana II, visto tra l’altro che, semplicemente, non ci sono altri testi che si avvicinino a questo taglio e a questa copertura.

 

Il lavoro ha un’impostazione storica, ma l’ordine cronologico conosce alcune eccezioni. Il primo capitolo, soprattutto, è dedicato a mostrare in forma sintetica ma rigorosa le caratteristiche del linguaggio parlato umano più pertinenti per la discussione successiva. Dalla semantica si passa fino alla fonetica e alle caratteristiche biologiche degli apparati fonatorio e uditivo. Le ultime pagine sono dedicate in buona parte a mostrare la complessità del linguaggio e i motivi per cui i sistemi informatici hanno molta difficoltà a gestirlo.

 

Per il resto il discorso procede in ordine cronologico. Dopo un’introduzione in cui ampio spazio viene dato all’idea tradizionale che produrre il parlato sia più difficile che comprenderlo, i capitoli sono:

 

1. Humanspeak (pp. 1-45)
2. The Speech Pioneers (pp. 47-81)
3. Artificial Intelligence versus Brute Force (pp. 83-107)
4. The Power of Statistics (pp. 109-133)
5. There Is No Data like More Data (pp. 135-166)
6. Let’s Have a Dialog (pp. 167-190)
7. An Interlude at the Other End of the Chain (pp. 191-205)
8. Becoming Real (pp. 207-233)
9. The Business of Speech (pp. 235-261)
10. The Future Is Not What It Used to Be (pp. 263-283)

 

Andiamo con ordine. Il secondo capitolo è una rassegna storica che in sostanza parte dal primo tentativo moderno di sintesi vocale, e in particolare dal Voder prodotto dai Laboratori Bell nel 1939. Si passa poi al primo sistema di riconoscimento, AUDREY, prodotto sempre dai Laboratori Bell nel 1952 e capace di riconoscere il nome dei primi nove numeri interi.

 

AUDREY si basava sul semplice riconoscimento delle prime due formanti, cioè delle frequenze a massima energia sonora all’interno delle vocali. Sviluppi immediati furono però impediti da due difficoltà all’epoca insormontabili: distinguere le parole all’interno del parlato continuo e adattarsi alla diversità delle voci individuali. Seguirono tentativi di individuare i singoli elementi fonetici, o fonemi, all’interno della parola; ma questi tentativi (“phonetic segmentation approach”, p. 61) furono frustrati dal fatto che non ci sono transizioni nette tra un fonema e l’altro e i fonemi stessi sono piuttosto variabili.

 

Nel frattempo, tuttavia, si stavano affermando i sistemi per la conversione digitale dei suoni e divenne possibile il “template-matching approach” (p. 65). Le macchine poterono infatti confrontare spettrogrammi digitalizzati con spettrogrammi di riferimento. Per eseguire il confronto, un ostacolo importante era rappresentato dal fatto che la durata di una parola varia moltissimo, non solo da parlante a parlante ma da enunciazione a enunciazione. La gestione matematica di questa complicazione attraverso la tecnica del “dynamic time warping” (p. 71), basata sulla programmazione dinamica, risolse il problema.

 

Questa tecnica “is still the foundation of all modern speech recognizers” (p. 78), anche se di solito non viene più applicata al riconoscimento di singole parole. Soprattutto, però, va notato che questo fu il primo esempio di un approccio puramente matematico al problema, eseguito senza prendere in considerazione questioni linguistiche.

 

Il capitolo 3 è dedicato appunto allo scontro tra gli approcci di questo tipo e quelli basati sull’intelligenza artificiale. Non si rovina la suspense se si rivela subito che a vincere sono state le soluzioni puramente matematiche, basate sulla “forza bruta” e non sulla comprensione delle regole del linguaggio. Nel 1971, l’Information Processing Technology Office della DARPA, all’epoca diretto da Lawrence Roberts, lanciò il programma SUR per il riconoscimento del parlato basato sull’intelligenza artificiale (nel programma era coinvolta anche una figura centrale nello sviluppo dei moderni computer, J. C. R. Licklider). Il programma non riuscì a raggiungere gli obiettivi prefissati, ma permise di notare che sistemi basati sulla forza bruta, come Harpy della Carnegie Mellon, ottenevano risultati molto superiori a quelli dei sistemi basati su regole (p. 92). In particolare, soluzioni come le macchine a stati finiti permettono di trasformare il problema di segmentare il parlato nel problema di trovare (approssimativamente) il percorso migliore all’interno di una rete di intersezioni.

 

Il capitolo 4 descrive il trionfo dell’approccio a forza bruta, che, in particolare attraverso il lavoro di Fred Jelinek alla IBM, ha portato a rimpiazzare gli approcci linguistici con quelli statistici. Alla base di questo trionfo c’è l’uso delle catene di Markov, o meglio, dei modelli di Markov nascosti (HMM), che danno per scontato che gli eventi siano osservabili ma che non si sappia nulla sugli stati che determinano le probabilità degli eventi stessi. Si procede quindi alla cieca, ma con successo. L’uso di uno specifico algoritmo (l’algoritmo di Baum-Welch, p. 127) permette per esempio di trovare la segmentazione più probabile di un corpus mediante la semplice ripetizione di una procedura statistica. Va anche detto che qui la necessità di spiegare argomenti piuttosto tecnici viene soddisfatta solo in parte: le caratteristiche dei modelli di Markov, per esempio, restano poco chiare pur essendo spiegate in modo un po’ troppo denso per il non addetto ai lavori.

 

Nel capitolo 5 si arriva all’inizio degli anni Ottanta e ai primi seri tentativi di costruire macchine in grado di riconoscere davvero il parlato, con il coinvolgimento di aziende come la Texas Instruments, che nel 1978 aveva ottenuto un buon successo per un giocattolo educativo a sintesi vocale, lo “Speak & Spell”. Il corpus TI-DIGITS, creato appunto dalla Texas Instruments, fu uno dei punti di riferimento nel periodo iniziale, seguito dalle valutazioni della DARPA. Ne seguirono miglioramenti graduali dei sistemi, che portarono al progetto ATIS, sempre della DARPA (p. 148); questi miglioramenti resero anche necessario lo sviluppo di sistemi per la misurazione delle prestazioni.

 

“The most important lesson learned in the five years of the ATIS program was how different spontaneous speech is from read speech” (p. 161). In aggiunta, il programma dimostrò che era possibile ottenere risultati anche con il discorso spontaneo. Tuttavia, per l’interazione mancava una componente essenziale: i sistemi sviluppati non potevano fare domande agli interlocutori.

 

La questione del dialogo è quindi centrale per il capitolo 6, anche se la descrizione riguarda più che altro un vicolo cieco e una direzione di ricerca. Il vicolo cieco è il progetto Communicator, lanciato dalla DARPA nel 1997 e chiuso nel 2001. Il progetto era interessante anche per il requisito di supporto per una struttura informatica modulare (i sistemi che supportano il dialogo sono complessi ed è quindi una buona idea comporli di moduli diversi, che comunicano tra di loro attraverso frame). Tuttavia, come viene raccontato nei capitoli successivi, in un contesto in cui ormai le applicazioni commerciali stavano diventando concrete, i progetti di ricerca perdono importanza. La direzione di ricerca promettente, e ancora in sospeso, lanciata da Communicator era invece “the evolution of machine learning to automatically determine an optimal interaction strategy” (p. 181).

 

Per quanto riguarda i risultati, per la lingua inglese i tassi di errore valutati dal NIST per il parlato in lingua inglese raggiungono la stabilità a cavallo del millennio, anche se rimangono piuttosto alti. Le trascrizioni eseguite da esseri umani hanno infatti tassi d’errore collocati tra il 2 e il 4 %, mentre i sistemi automatici arrivano in questo periodo al 13-19 su corpora creati di conversazioni o trasmissioni radiofoniche (p. 188).

 

Il settimo capitolo interrompe l’ordine cronologico per parlare dei problemi di sintesi vocale, e ne parlerò in un prossimo post. L’ottavo capitolo è dedicato invece, appunto, all’evoluzione dei sistemi commerciali. La prima vera applicazione di questo tipo fu un sistema messo in linea nel 1992 dall’AT&T per riconoscere un comando tra cinque: “calling card”, “collect”, “third-party”, “person-to-person” e “operator” (p. 208). Questa semplice applicazione, secondo le stime (un po’ gelide, ammettiamolo) dell’AT&T avrebbe consentito di licenziare seimila operatori…

 

Questioni umane a parte, l’adozione pratica di sistemi simili richiedeva un lavoro enorme, anche quando le tecnologie erano già state sperimentate in laboratorio. La stessa applicazione AT&T richiese l’uso di algoritmi “barge-in” (p. 210) e “word-spotting” (p. 211) creati per l’occasione. Un esito più curioso del lavoro fu l’uso della sintesi vocale per parlare non a esseri umani ma ad altre macchine (p. 211).

 

A questo punto entra in scena il primo nome specializzato ancora oggi rilevante per il grande pubblico: Dragon. L’azienda originaria, Dragon Systems, era stata fondata già nel 1982 da Jim e Janet Baker, ma nel 1997 lanciò il suo prodotto più rivoluzionario: Dragon Naturally Speaking, un programma per personal computer in grado di riconoscere il parlato continuo (contrapposto alle parole isolate), seguito subito dopo da ViaVoice della IBM. Tuttavia:

 

The dream of typing documents, opening and closing files, and issuing commands on a personal computer through voice alone, a dream pursued by IBM, Dragon Systems, and later Apple and Microsoft, was never realized for a number of practical reasons. Chief among these was PC users’ clear preference to control their computers by touch rather than speech deep. Typing, clicking, and double clicking had become a second nature and nearly effortless for most computer users, whereas speaking required more effort and could be impractical in many situations, such as in a noisy room or when sharing an office with other people, where the added issue of privacy arose when working on personal or sensitive documents (p. 213).

 

Inoltre, le guerre dei prezzi e la disponibilità gratuita (per l’inglese) di sistemi di riconoscimento vocale attraverso Windows hanno reso il settore poco redditizio. In compenso, medici e avvocati, abituati a registrare il proprio parlato e a farlo trascrivere, hanno abbracciato prodotti specializzati, e gli smartphone sembrano un settore di sviluppo promettente.

 

Nella realtà, già a partire dalla fine degli anni Ottanta era stata dedicata una certa attenzione a un concetto rivoluzionario: le interfacce vocali (“voice user interface”, VUI; p. 215), come sviluppo anche di tecnologie del tutto prive di capacità di riconoscimento del parlato.

 

Aziende come SpeechWorks e Nuance hanno lavorato nel settore, che, come viene descritto più in dettaglio nel nono capitolo, può portare molti vantaggi immediati anche per le interfacce telefoniche, permettendo di uscire dai classici modelli ad albero (“call flow”). Gradualmente si sono affermati anche standard come Voice XML – mentre nel libro non viene fatta menzione, se ho ben visto, di standard alternativi come SAPI per le voci.

 

Il capitolo decimo conclude e lancia diversi spunti per gli sviluppi futuri, in particolare per quanto riguarda la ricerca vocale (una realtà già ben definita) e le interfacce multimodali. Anche l’epilogo si proietta verso il futuro, accennando a quello che ai tempi della pubblicazione del libro era il recente successo di Siri.

 

In prospettiva egoistica, queste ultime sezioni risultano un po’ troppo sintetiche: una carrellata sullo stato dell’arte sarebbe stata molto utile. Tuttavia ciò toglie poco al libro, che secondo me è un modello di successo anche per il taglio: la prospettiva storica è fondamentale per inquadrare e comprendere bene ciò che sta succedendo adesso. Consiglio quindi senza riserve la lettura del libro di Pieraccini a chiunque sia interessato a questo genere di argomenti… e spero anche che venga aggiornato presto con le ultime novità, e magari venga anche tradotto in italiano.

 

Roberto Pieraccini, The Voice in the Machine. Building Computers That Understand Speech, Cambridge MA, The MIT Press, 2012, pp. xxviii + 325, ISBN 978-0-262-01685-8 (€ 37,08 su Amazon.it). Nota: a p. 35 si cita il caso di Victor Zue, in grado di leggere gli spettrogrammi.