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.
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.
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.
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.
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.
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.
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.
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.
