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.