Audio event detection nella dettatura: suoni con significato oltre le parole

Questo post e volutamente più cauto delle nostre altre note ingegneristiche. Sounds with meaning non è una funzione rilasciata. E una direzione di ricerca iniziale: la comprensione sonora nella digitazione vocale può catturare segnali non verbali utili preservando il flusso calmo della dettatura?

Il gap dell'audio non verbale

I sistemi di digitazione vocale di solito scartano tutto ciò che non è una parola. Ha senso per una trascrizione pulita, ma perde informazioni. In una riunione, una risata può segnare accordo o tensione. In un diario, una lunga pausa può contare. Nei workflow di accessibilità, un campanello, timer o pianto di bambino può essere contesto utile.

Pensa a com'e una trascrizione tipica dopo una riunione di un'ora. Le parole ci sono, ma il ritmo e appiattito: la lunga pausa prima che qualcuno dissenta, la risata che ha ammorbidito un feedback duro, il momento di silenzio dopo una domanda difficile. Un umano che rilegge la trascrizione riempie quei vuoti con la memoria. Un collega che non ha potuto partecipare non ha alcun segnale. L'audio event detection nella dettatura e un modo per rimettere una piccola quantita di quella texture nel record scritto, senza chiedere all'utente di narrarla.

Il rischio e ovvio: non ogni suono dovrebbe diventare testo. Gran parte dell'audio di fondo e irrilevante. Parte e privata. Parte e ambigua. L'audio event detection nella dettatura ha senso solo se e opzionale, local-first e conservativa su quando un suono cambia l'output scritto.

AED vs audio captioning

L'audio event detection (AED) risponde a una domanda compatta: quale evento e accaduto e più o meno quando? L'audio captioning scrive una descrizione in linguaggio naturale di una scena sonora. Per la dettatura, spesso AED basta. Un tag come "laughter" o "doorbell" può essere un marker; una caption completa può essere troppo verbosa.

Perche tendiamo prima verso AED

Un tag AED fallisce in modo silenzioso. Se il modello etichetta qualcosa come "applause" e non lo era, l'utente vede un singolo marker tra parentesi facile da eliminare. Una caption audio sbagliata e più difficile da annullare: modella il paragrafo circostante, influenza il lettore e resta nei riassunti. Per un prodotto di dettatura in cui la fiducia si costruisce una frase alla volta, il costo di un piccolo tag sbagliato e molto più basso del costo di una frase sbagliata ma sicura. Il nostro bias iniziale e verso piccoli marker strutturati, non prosa automatica. Un marker e più facile da revisionare, eliminare o ignorare.

Cosa potrebbe significare per la dettatura

Nelle riunioni, l'audio non verbale potrebbe creare marker opzionali: "[laughter]" dopo una battuta, "[long pause]" prima di una decisione o "[doorbell]" quando lo speaker viene interrotto. Nel journaling, potrebbe aiutare a preservare texture emotiva senza obbligare l'utente a narrarla. Nei workflow di accessibilità, potrebbe trasformare un suono ambientale in una breve nota o reminder.

Uno sketch concreto. Immagina una nota di riunione in cui l'utente ha optato per i meeting marker. La trascrizione si leggerebbe come prosa ordinaria con tag rari e compatti: "We agreed to ship the migration this week. [laughter] Then we walked through the rollback plan. [long pause] Someone asked whether we should defer the index changes." Il lettore ottiene un senso più ricco di ciò che e successo senza un paragrafo di regia.

Uno sketch di journaling e ancora più stretto. L'utente detta una breve nota di fine giornata; una lunga pausa udibile potrebbe emergere come tag "[reflection]" che l'utente può tenere, modificare o eliminare in review. Nulla viene committato automaticamente nel corpo della voce di diario senza la possibilità di guardare.

Non stiamo cercando di rendere teatrale la dettatura. L'obiettivo non è scrivere ogni colpo di tosse o click di tastiera. L'obiettivo è rilevare un insieme stretto di eventi ad alto segnale e lasciare all'utente decidere se quegli eventi diventano testo, tag o niente.

Fondamenta di ricerca

Diverse linee di ricerca pubbliche sono rilevanti. CLAP esplora il pretraining contrastivo linguaggio-audio. BEATs studia il pretraining audio per comprensione acustica. AudioSet e un dataset su larga scala per eventi audio, e AudioCaps e un riferimento per l'audio captioning.

Queste sono fondamenta di ricerca, non una dichiarazione di dipendenza di prodotto. Il lavoro prototipale di Loqua e concentrato sulla domanda di dettatura Mac: quali cue sonori sono utili al cursore, quali dovrebbero restare invisibili e come l'utente può controllare il confine?

Cosa stiamo prototipando

Stiamo prototipando tre comportamenti stretti. Primo, meeting marker: tag opzionali per risate, silenzio, applausi e interruzioni. Secondo, cue di journaling: tag approvati dall'utente per lunghe pause o esasperazione udibile. Terzo, alert di accessibilità: un cue sonoro locale che può diventare reminder o nota quando l'utente lo chiede.

L'esperienza utente che stiamo abbozzando internamente e volutamente quieta. Gli eventi rilevati appaiono come chip in una piccola superficie di review accanto al testo dettato, non nel testo stesso. L'utente può trascinare un chip nel documento, scartarlo o convertirlo in un tag specifico per la destinazione. Il comportamento di default e "mai inserire senza consenso". La modalità di default e off finche l'utente non fa opt-in per un workflow specifico.

Il prototipo e local-first e opt-in. Niente in questa direzione dovrebbe annotare silenziosamente audio privato di sfondo. Stiamo anche testando una modalità "marker only" in cui i suoni rilevati non entrano mai automaticamente nella prosa; appaiono come chip revisionabili prima dell'inserimento.

Problemi difficili che non abbiamo risolto

Il problema più difficile e il significato. Una risata può voler dire accordo, disagio, sarcasmo o niente. Un sospiro può voler dire fatica, sollievo o rumore del microfono. Non vogliamo che un modello inventi interpretazioni emotive da prove deboli. Il secondo problema difficile e la privacy: il suono ambientale può rivelare più di quanto gli utenti si aspettino.

Il terzo problema difficile sono gli spazi condivisi. Anche con opt-in rigoroso, un microfono in una sala riunioni sente persone che non hanno optato per nulla. Una funzione audio non verbale che cattura risate in quella stanza sta comunque catturando informazioni su persone che non sono l'utente. Non pensiamo sia irrisolvibile, ma plasma pesantemente il set di vincoli: il detector dovrebbe girare localmente sul dispositivo dell'utente, i marker non dovrebbero mai essere condivisi senza azione esplicita e il default per le classi ambientali dovrebbe tendere al silenzio più che all'inferenza.

Quindi lo standard attuale e conservativo. L'audio captioning nella dettatura dovrebbe richiedere controllo utente chiaro, marker visibili ed eliminazione facile. La soglia per spostare l'audio event detection nella dettatura da prototipo a funzione rilasciata e concreta: un flusso opt-in che un utente attento descriverebbe come onesto, comportamento default-off in ogni ambiente che non abbiamo testato esplicitamente, e una UX che rende un tag sbagliato eliminabile con un singolo tasto. Finche questi pezzi non sembrano giusti, resta lavoro di frontiera di ricerca, non una promessa core rilasciata.