Local blog for Italian speaking developers
Sistemi congiunti di riconoscimento vocale e diarizzazione degli oratori tramite trasduzione di sequenze
2 settembre 2019
Pubblicato da Laurent El Shafey, Software Engineer, e Izhak Shafran, Research Scientist, Google Health
Essere in grado di riconoscere "chi ha detto cosa", ovvero
la diarizzazione degli oratori,
è un passaggio fondamentale nella comprensione vocale del dialogo umano attraverso mezzi automatizzati. Ad esempio, in una conversazione di carattere medico tra medici e pazienti, un "
Sì
" pronunciato da un paziente in risposta a "
Ha assunto regolarmente i farmaci per il cuore?
" ha implicazioni sostanzialmente diverse da un "
Sì?
" retorico pronunciato da un medico.
I sistemi di diarizzazione degli oratori (SD) convenzionali prevedono due fasi: la prima rileva i cambiamenti nello spettro acustico per determinare quando cambiano gli oratori in una conversazione, la seconda identifica i singoli oratori durante la conversazione.
Questo approccio di base a più fasi
viene impiegato da quasi due decenni, nel corso dei quali ha subito miglioramenti solo il componente per il rilevamento del cambiamento degli oratori.
Con il recente sviluppo di un nuovo modello di rete neurale, il
trasduttore di rete neurale ricorrente
(RNN-T), ora disponiamo di un'architettura in grado di migliorare le prestazioni della diarizzazione degli oratori mediante la risoluzione di alcune delle limitazioni del precedente sistema di diarizzazione che abbiamo
da poco presentato
. Come riportato nel nostro recente articolo "
Sistemi congiunti di riconoscimento vocale e diarizzazione degli oratori tramite trasduzione di sequenze
", che sarà presentato in occasione del convegno
Interspeech 2019
, abbiamo sviluppato un sistema di diarizzazione degli oratori basato su RNN-T, ottenendo un incredibile miglioramento nelle prestazioni con un passaggio da circa il 20% al 2% del tasso di errore della diarizzazione delle parole, un fattore di miglioramento di 10.
Sistemi di diarizzazione degli oratori convenzionali
I sistemi di diarizzazione degli oratori convenzionali si avvalgono delle differenze nel modo in cui le parole pronunciate dalle persone risultano da un punto di vista acustico per distinguere gli oratori nelle conversazioni. Mentre gli oratori di sesso maschile e femminile possono essere identificati con relativa facilità dal loro tono utilizzando semplici modelli acustici (ad esempio, i
modelli di miscela gaussiana
) in una singola fase, i sistemi di diarizzazione degli oratori utilizzano un approccio multifasico per distinguere tra oratori con tono potenzialmente simile. Innanzitutto, un algoritmo di rilevamento dei cambiamenti suddivide la conversazione in segmenti omogenei, idealmente contenenti un singolo oratore, in base alle caratteristiche vocali rilevate. Quindi, vengono utilizzati modelli di deep learning per mappare segmenti ottenuti da ciascun oratore a un vettore di embedding. Infine, in una fase di clustering, tali embedding vengono raggruppati così da poter delineare una traccia degli interventi dello stesso oratore durante la conversazione.
In pratica, il sistema di diarizzazione degli oratori funziona in parallelo al sistema di riconoscimento vocale automatico (ASR) e gli output dei due sistemi sono combinati in modo da associare le parole riconosciute al relativo oratore mediante un'etichetta.
Il sistema di diarizzazione degli oratori convenzionali applica le etichette degli oratori nel dominio acustico, quindi sovrappone le etichette degli oratori alle parole generate da un sistema ASR separato.
Tuttavia, questo approccio implica delle limitazioni che hanno ostacolato i progressi in questo campo. Innanzitutto, la conversazione deve essere suddivisa in segmenti che contengano solo parole di un unico oratore. In caso contrario, l'embedding non rappresenterà accuratamente l'oratore. Nella pratica, tuttavia, l'algoritmo di rilevamento dei cambiamenti è imperfetto, risultando in segmenti che possono contenere più oratori. In secondo luogo, la fase di clustering richiede che il numero di oratori sia noto ed è particolarmente sensibile all'accuratezza di questo input. In terzo luogo, il sistema deve trovare il giusto compromesso, non senza difficoltà, tra la dimensione del segmento su cui sono stimate le firme vocali e l'accuratezza del modello desiderata. Più lungo è il segmento, migliore è la qualità della firma vocale, poiché il modello può avvalersi di maggiori informazioni sull'oratore. Ciò comporta il rischio di attribuire brevi tratti del discorso all'oratore sbagliato, il che potrebbe avere conseguenze gravi, ad esempio nel contesto dell'elaborazione di una conversazione di carattere clinico o finanziario in cui l'affermazione o la negazione devono essere tracciate con precisione. Infine, i sistemi di diarizzazione degli oratori convenzionali non sono dotati di un meccanismo semplice che consenta di sfruttare i segnali linguistici che sono facilmente identificabili in molte conversazioni spontanee. Un'espressione come "
Con quale frequenza ha assunto il farmaco?
" in una conversazione di carattere clinico è molto probabilmente pronunciata da un medico, non da un paziente. Allo stesso modo, l'espressione "
Quando dobbiamo consegnare i compiti?
" è molto probabilmente pronunciata da uno studente, non da un insegnante. I segnali linguistici indicano inoltre un'alta probabilità di cambiamento nei turni degli oratori, ad esempio dopo una domanda.
Esistono alcune eccezioni al sistema di diarizzazione degli oratori convenzionale e una di queste è stata segnalata in un nostro
recente post sul blog
. In quel lavoro, gli stati nascosti della rete neurale ricorrente (RNN) hanno tracciato gli oratori, aggirando i punti deboli della fase di clustering. Il lavoro riportato in questo post ha un approccio diverso e incorpora anche i segnali linguistici.
Un sistema integrato di riconoscimento vocale e diarizzazione degli oratori
Abbiamo sviluppato un nuovo modello di facile impiego che non solo combina perfettamente segnali acustici e linguistici, ma accorpa anche la diarizzazione degli oratori e il riconoscimento vocale in un unico sistema. Il modello integrato non inficia le prestazioni del riconoscimento vocale in modo significativo rispetto a un sistema equivalente di solo riconoscimento.
L'intuizione chiave nel nostro lavoro è stata quella di riconoscere che l'architettura RNN-T è adatta a integrare segnali acustici e linguistici. Il modello RNN-T è costituito da tre diverse reti: (1) una rete di trascrizione (o
encoder
) che mappa i frame acustici su una rappresentazione latente, (2) una rete di previsione che prevede la successiva etichetta di destinazione sulla base delle etichette di destinazione precedenti e (3) una rete comune che combina l'output delle due reti precedenti e genera una distribuzione di probabilità sul set di etichette di output in quel passaggio. Esiste un ciclo di feedback nell'architettura (diagramma seguente) in cui le parole precedentemente riconosciute vengono restituite come input e ciò consente al modello RNN-T di incorporare i segnali linguistici, come la fine di una domanda.
Un sistema integrato di riconoscimento vocale e diarizzazione degli oratori in cui il sistema determina congiuntamente chi ha detto cosa e quando.
L'addestramento del modello RNN-T su acceleratori come unità di elaborazione grafica (GPU) o unità di elaborazione tensore (TPU) non è banale poiché il calcolo della
funzione di perdita
richiede l'esecuzione dell'
algoritmo forward-backward
, che include tutti i possibili allineamenti delle sequenze di input e di output. Questo problema è stato affrontato di recente in un'
implementazione intuitiva della TPU
dell'algoritmo forward-backward, che riformula il problema come una sequenza di moltiplicazioni di matrice. Abbiamo anche approfittato di un'
implementazione efficiente della perdita di RNN-T
in TensorFlow che ha permesso rapide iterazioni sullo sviluppo del modello e addestrato una rete molto profonda.
Il modello integrato può essere addestrato esattamente come un sistema di riconoscimento vocale. Le trascrizioni di riferimento per l'addestramento contengono parole pronunciate da un oratore e seguite da un tag che definisce il ruolo di chi parla. Ad esempio, "
Quando vanno consegnati i compiti?
" ≺studente≻, "
Vanno consegnati domani prima della lezione
", ≺insegnante≻. Una volta che il modello è stato addestrato con esempi di audio e le corrispondenti trascrizioni di riferimento, l'utente può applicarlo alla registrazione della conversazione e aspettarsi un output in una forma simile. Le nostre analisi mostrano che i miglioramenti del sistema RNN-T incidono su tutte le categorie di errori, inclusi brevi turni degli oratori, interruzione delle parole, assegnazione errata degli oratori in presenza di parti di discorso sovrapposte e scarsa qualità audio. Inoltre, il sistema RNN-T ha mostrato prestazioni costanti nel corso della conversazione con una variazione sostanzialmente inferiore del tasso di errore medio per conversazione rispetto al sistema convenzionale.
Un confronto tra gli errori commessi dal sistema convenzionale rispetto al sistema RNN-T, come classificato dagli annotatori umani.
Inoltre, questo modello integrato può prevedere altre etichette necessarie per generare trascrizioni ASR più facili da leggere. Ad esempio, siamo stati in grado di migliorare con successo le nostre trascrizioni con i simboli di punteggiatura e l'uso delle maiuscole grazie ai dati di addestramento opportunamente associati. I nostri risultati presentano errori di punteggiatura e nell'uso delle maiuscole inferiori rispetto ai nostri modelli precedenti, che sono stati addestrati separatamente e aggiunti come fase di post-elaborazione dopo l'ASR.
Questo modello è ora diventato un componente standard del nostro progetto sulla
comprensione delle conversazioni mediche
, oltre a essere più largamente adottato anche nei nostri servizi relativi alle conversazioni di carattere non medico.
Ringraziamenti
Vorremmo ringraziare Hagen Soltau senza i cui contributi questo lavoro non sarebbe stato possibile. Questo lavoro è stato eseguito in collaborazione con i team di Google Brain and Speech.
Etichette
Android
Firebase
machine learning
Google Cloud Platform
GDL
Eventi
Google Developers Live
Google Play
TensorFlow
App
Chrome
Cloud
api
GDLItalia
GDE
GDG
Google Assistant
iOS
Kotlin
Actions on Google
Deep Learning
AppEngine
AMP
BigQuery
Cloud Functions
Flutter
Android Studio
Google Developers Expert
Università
Google AppEngine
JavaScript
AI
Android Wear
GAE
Google Play Store
HTML5
Maps
security
Android App Development
AngularJS
IoT
Kubernetes
Annunci
Cloud Firestore
Cloud Machine Learning
Google I/O
Polymer
Android Things
Community
DevTools
Google App Engine
intelligenza artificiale
Entrepreneurship
Firebase Analytics
GSoC
Games
Google Cast
ML
open source
Crashlytics
Dart
Diversity
Drive
Google Data Studio
Google Play Games
TensorFlow Lite
Android Developers
Android O
Cloud Spanner
Cloud TPU
Compute Engine
DevFest
Google Compute Engine
Google Developers
Material Design
Mobile
PWA
Python
Startup
AIY Project
ARCore
Android Jetpack
AndroidDev
Androidq
Apps Script
Artificial Intelligence
Augmented Reality
Firebase Cloud Messaging
Google Cloud
Google Maps
Gsuite
IO19
ML kit
Research
VR
coding
unity
#io19
AR
Android Dev Summit
Android Developer
Android Q
Cardboard
Cloud AI
Coral
Developers
Dialogflow
Firebase Realtime Database
Gmail
Google AI
Google Cloud Messaging
Google ContainerEngine
Google Play Console
Kotlin Coroutines
NLP
Programming
Responsive Design
TensorFlowjs
Testing
WTM
Women
beacons
cloud storage
developer
node JS
student programs
women techmakers
API Cloud Vision
Add-ons
Android P
AndroidDevStory
Animation
AutoML
Brillo
Classroom
DSC
Database
Developer Student Clubs
Edge TPU
Fabric
Featured
Flutter Web
G Suite
GWT
GoLang
Google
Google Brain
Google Cloud Next
Google Container Engine
Google Developer Groups
Google I/O Extended
Graph
Hosting
Instant Apps
Keras
Livedata
Mobile Sites
Prediction
Privacy
Project Tango
SDK
Stackdriver
Tales
UI
Udacity
Virtual Reality
Web
Web Development
YouTube
analytics
android security
api.ai
courses
google io
indies
natural language processing
reti neurali
sign-in
young developers
2d Animation
3d
AIY
ARkit
Adversarial Learning
Alpha
Android App
Android App Developmen
Android App bundle
Android Architecture
Android Architecture Components
Android Auto
Android Automotive OS
Android Dev Summit Android Developer
Android Developer Challenge
Android Developers GooglePlayAwards
Android Development
Android Go
Android Instant App
Android Pie
Android Q Scoped Storage
Android Q audio
Android Styles
Android audio playback capture
Android codelabs
AndroidTV
AndroidX
Angular
Aogdevs
Api Design
App Development
App Distribution
Apps
Architecture
Architecture Components
Arduino
Best Practices
Betatesting
Bugs
C++
Certification
Cloud Anchors
Cloud Next
Cloud Run
Cloud Service Platform
Cloud Shell
Cloud Study Jam
Coached Conversational Preference Elicitation
Commerce
Community Connector
Computer Science
Consistency
Containers
Converge
Conversation Design
Crash Reporting
DLS Design
Dagger
Data Science
Databases
Dependency Injection
Design
Developer Communities
Developer Community
Developer Culture
Developer Story
Developing Media Apps
Development
Eager
Edge TPU Dev Board
Education
Emulatore Android
Error Message
Eslint
Europe
Firebase Extensions
Firebase Summit 2019
Firebasehosting
Flutter 1.5
Flutter at IO
FlutterDark
GCE
GDD
Game Development
Gboard
Gesture Navigation
Glass
Go
Google AI Quantum
Google App Script
Google Cloud Functions
Google Cloud billing
Google Coral
Google Developer Days
Google Home Hub
Google IOS Android
Google Identity Platform
Google Launchpad
Google Lens
Google Now
Google Photos
Google Play Devs
Google Play Indie Games Festival
Google Play Instant
Google Plus
Google codelabs
Google+
GoogleDevWeekly
GoogleLaunchpad
GooglePlay
Graphics
Healthcare
I/O
IO
IO19 Flutter
In-app Billing
Indie Games
Indie Games Festival
Indie games showcase
Indie showcase
Ingress
Instant Games
Issues
Java
Jetpack
Knative
Kotlin Beginners
Kotlin Everywhere
Kotlin codelabs
Lighthouse
Live Caption
Live Streaming
Localization
Location
M-Theory
Mondaygram
Monetization
NYT
NativeScript
Navigation
Neural Graph Learning
Neural Structured
Nodejs
OS
OS Updates
Olivex
One Time Codes
Online Education
PHA
Performance Monitoring
Policy
Posenet
Project Mainline
Project Treble
Quantum Computing Theory
Reactive Programming
Regression
Remote Config
Resonance Audio
Room
Scoped Storage
Semantics
Semi Supervised Learning
Serverless
Sms Retriever Api
Sms Verification
Speech Recognition
Swift
Tensorflow Core
Tensorflow Hub
Test Lab
Text
Tokenizer
Tpu
Transformers
UX
UX Design
UX Research
Universal Sentence Encoder
Unsupervised Data Augmentation
Unsupervised Learning
User Experience
Viewmodel
Voice
WWW
Wear OS
WebAssembly
Widget
Women in Tech
WomenTechmakers
android kotlin
app stability
assistant
audio recording
augmented faces
authsub
best practices and updates
billing
botnet
business
c++ games
cancer
chatbot
chrome privacy
codelab
codelabs
competition
daydream
designer
dominio .dev
error handling
event
firebase games
firebase gdc
firebase hosting
firebase unity
game center authentication
game testing
games authentication
gdc
google summer of code
googledevelopers
grow
hashcode
indie
indie developers
internship
kids
machine intelligence
machine learning accelerator
maker
multi-platform
nearby
oauth
openid
performance
persistent AR
privacy sandbox
prizes
prototype
purchase flows
queries
realtime
responsible AI
security rules
showcase
solutions challenge
startup africa roadtrip
startup times
students
summer of code
unity crashlytics
verify apps
win
Archivio Blog
2020
feb
gen
2019
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2018
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2017
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2016
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2015
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2014
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2013
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
Feed
Follow @GoogleDevsItaly
