Il rilevamento dell’attività vocale, VAD, identifica il parlato in un flusso audio. Per un agente vocale aiuta a rispondere a “qualcuno sta parlando?”. La domanda più difficile è “ha finito?”.
Chi chiama dice “il mio indirizzo è…” e si ferma per controllare il civico. Un rilevatore può segnalare correttamente silenzio mentre l’agente inizia erroneamente a parlare. Nessuno aveva chiesto un’interruzione particolarmente sicura di sé.
Se costruisci un agente conversazionale, usa il VAD dove servono confini del parlato, poi scegli una politica esplicita per i turni. Vediamo come si combinano queste parti, dove aiutano i rilevatori autonomi e cosa provare prima di far rispondere l’agente alle chiamate.
Come funziona il VAD
Un VAD elabora brevi finestre audio e stima se contengono parlato. Secondo l’implementazione, l’output è una decisione binaria, una probabilità o una serie di timestamp ricavati dalle decisioni.
Una semplice soglia energetica considera parlato l’audio abbastanza forte. È economica da calcolare, ma un suono forte può essere anche una porta sbattuta. Rilevatori più sofisticati usano caratteristiche acustiche o modelli neurali per distinguere il parlato dagli altri suoni. Il VAD moderno non si limita a misurare il volume.
L’applicazione di solito aggiunge logica intorno al rilevatore. Può richiedere diversi frame vocali prima di iniziare un segmento, conservare un breve buffer precedente all’attivazione e aspettare un breve silenzio prima di chiuderlo. Questa logica influisce su ciò che sente l’utente: senza buffer, un rilevamento corretto può comunque arrivare troppo tardi per conservare l’inizio di una parola.
Il VAD non trascrive parole, non identifica una persona specifica e non rimuove il rumore. Sono compiti separati. Può riconoscere correttamente una voce televisiva come parlato e attivare comunque il comportamento sbagliato in un agente che dovrebbe ascoltare solo chi chiama.
VAD, endpointing e rilevamento semantico dei turni
Questi termini descrivono decisioni diverse:
| Componente | Domanda a cui risponde | Limite da considerare |
|---|---|---|
| Rilevamento dell’attività vocale | Questo audio contiene parlato? | Una pausa dice poco sulla completezza di un pensiero. |
| Endpointing basato sul silenzio | Il parlato si è fermato abbastanza a lungo da chiudere il turno? | Un timeout fisso tratta in modo simile una pausa di riflessione e una frase finita. |
| Rilevamento semantico dei turni | Audio e contesto linguistico suggeriscono che chi parla abbia finito? | Le previsioni possono essere anticipate o tardive; serve recupero nell’applicazione. |
| Gestione delle interruzioni | L’agente deve fermare la risposta quando inizia il parlato? | Vanno fermati o scartati anche buffer di riproduzione e generazione in corso. |
Un endpointer basato sul silenzio è spesso un punto di partenza sensato. Il compromesso è diretto: un timeout breve risponde prima ma rischia di troncare chi sta ancora pensando; uno lungo lascia spazio ma ritarda le risposte dopo frasi complete.
Il rilevamento semantico usa altro contesto per distinguere i casi. “La mia email è…” e “è tutto, grazie” possono richiedere attese diverse anche con una pausa simile dopo. Resta una stima, non il permesso di presumere che l’interlocutore non possa cambiare idea.
L’annuncio di Ink 2 spiega perché abbiamo integrato l’endpointing semantico nel riconoscimento vocale. L’obiettivo è una conversazione in cui si possa finire il proprio pensiero e ricevere una risposta tempestiva. Ottimizzare solo l’accuratezza sui frame non dimostra di offrire questa esperienza.
Quando usare un VAD autonomo
Un rilevatore autonomo è utile quando devi trovare il parlato prima di decidere cosa farne. Per esempio, segnare regioni vocali nelle registrazioni, pilotare un indicatore di parlato o fornire eventi di inizio alla tua pipeline. Il rilevamento locale può anche mantenere quella specifica elaborazione sul dispositivo; non rende privato o offline il resto di un agente collegato al cloud.
Due implementazioni da valutare sono WebRTC VAD tramite py-webrtcvad e Silero VAD.
| Implementazione | Input ed esecuzione | Cosa verificare nell’applicazione |
|---|---|---|
| WebRTC VAD | Il wrapper Python accetta PCM mono a 16 bit a 8, 16, 32 o 48 kHz, in frame da 10, 20 o 30 ms. Espone quattro modalità di aggressività. | Se il filtraggio più severo perde parlato a basso volume e se l’acquisizione fornisce frame validi. |
| Silero VAD | Rilevatore neurale con opzioni PyTorch e ONNX; il progetto documenta supporto per 8 e 16 kHz. | Costo di modello e runtime sul dispositivo, requisiti dei segmenti e false attivazioni sul tuo audio. |
I requisiti di formato dipendono dall’implementazione. Un’intestazione WAV non è un campione PCM e un pacchetto MP3 non è un frame da passare direttamente a WebRTC VAD. Decodifica e converti prima del rilevamento quando l’input lo richiede. Consulta la documentazione attuale anziché presumere che la frequenza predefinita del microfono browser sia accettata.
Nessuno dei due è un gestore completo di conversazioni. Servono ancora endpointing, gestione delle interruzioni e recupero quando l’interlocutore continua a parlare.
Usa il rilevamento dei turni integrato in Ink
Se vuoi trascrizione in streaming e confini dei turni insieme, l’API Realtime Speech-to-Text (Auto) di Cartesia include entrambi. Non serve un VAD separato per quei confini.
Il ciclo degli eventi distingue utilmente una fine possibile da una confermata:
| Evento | Cosa deve considerare l’applicazione |
|---|---|
turn.start | Chi chiama ha iniziato a parlare. Applica la politica di interruzione a qualsiasi risposta attiva. |
turn.update | Aggiorna la trascrizione visualizzata o conservata del turno. |
turn.eager_end | Il turno potrebbe essere completo. Puoi iniziare a generare una risposta speculativa. |
turn.resume | Chi chiama ha continuato. Annulla o scarta il lavoro basato sulla fine provvisoria. |
turn.end | Il rilevatore conferma la fine del turno. Procedi con la trascrizione completa. |
Per esempio, una fine anticipata dopo “devo annullare” può essere seguita da “il secondo appuntamento, non il primo”. Inizia a preparare la risposta se aiuta la latenza, ma trattieni la riproduzione fino alla conferma della fine. Mantieni azioni con conseguenze, come annullare una prenotazione, dietro le regole di validazione e conferma dell’applicazione. Una previsione anticipata non è autorizzazione dell’utente.
Due dettagli d’integrazione sfuggono facilmente. Primo, gli eventi con trascrizione contengono il testo cumulativo del turno. Sostituisci il testo corrente; concatenare ogni aggiornamento ripete le parole. Secondo, l’API richiede audio continuo, silenzio incluso. Non usare un VAD a monte per eliminare segmenti silenziosi: l’assenza di audio significa attesa di altro input, non prova che chi chiama abbia smesso.
La documentazione sul rilevamento dei turni copre soglie, annullamento e svuotamento degli eventi nel buffer alla chiusura della connessione. Parti dai valori predefiniti e cambia una sola impostazione alla volta usando errori conversazionali registrati.
Prova la conversazione, non solo il rilevatore
Decidi come dovrebbe funzionare l’interazione prima delle soglie. Un receptionist che raccoglie un indirizzo deve lasciare tempo per cercarlo. Un breve scambio sì/no può richiedere meno attesa. Un unico timeout globale non esprime ogni requisito.
Usa registrazioni raccolte con il permesso necessario e includi il microfono o collegamento telefonico effettivo. Ascolta scambi completi, non solo clip isolate:
| Scenario | Errore da cercare |
|---|---|
| Prima sillaba debole dopo il silenzio | Registrazione o trascrizione perde l’inizio della parola. |
| Pausa a metà indirizzo | L’agente risponde prima della fine. |
| Risposta breve e completa | L’agente aspetta quando il turno è chiaramente finito. |
| ”Anzi, facciamo giovedì” durante la risposta | L’agente continua a riprodurre audio nel buffer sopra la correzione. |
| Parlato di fondo, tastiera o eco | L’agente si ferma o risponde al suono sbagliato. |
| Accenti, velocità ed esitazioni diversi | L’impostazione funziona per l’autore del test ma interrompe altri. |
Monitora fini anticipate e interruzioni perse insieme al ritardo di risposta. Separa l’attesa prima della chiusura del turno dal tempo in LLM, strumenti, generazione e riproduzione. Ridurre un timeout VAD non corregge una ricerca lenta nel calendario.
Quando l’agente viene interrotto, esamina l’intero percorso di output. Annullare il testo non svuota necessariamente l’audio già in coda nel client. A chi dice “stop” interessa quando il suono si ferma, non quale attività server abbia ricevuto l’annullamento.
Per provare il rilevamento integrato, usa la demo browser di Ink e fermati deliberatamente a metà frase. Poi esegui l’esempio Realtime STT nelle tue condizioni audio. Il test utile è se l’agente lascia finire gli utenti e risponde quando sono pronti.