Riconoscimento vocale multimodale: costruire un ascoltatore che vede ciò che vedi

Il riconoscimento vocale solo audio è diventato abbastanza buono da farci sottovalutare i suoi errori residui. I benchmark su parlato pulito nascondono il vero problema di prodotto: gli utenti dettano dentro le app, intorno a codice visibile, in lingue miste e con riferimenti parziali come "questa funzione" o "il punto sopra".

Dove l'ASR fallisce ancora

L'esempio classico sono gli omofoni. "From foo import bar" e from foo import bar suonano simili, ma appartengono a mondi diversi. Lo stesso vale per "cache the auth client" e "cash the auth client" se il modello non sa che il cursore è in un file TypeScript. L'audio da solo non può inferire in modo affidabile la destinazione.

Gli identificatori di codice rendono il problema ancora più netto. Un utente può dire "fetch profile", ma la funzione visibile è fetchProfile. Un modello di trascrizione sente parole; un modello di dettatura dovrebbe preservare l'identificatore. Il riconoscimento vocale multimodale tratta il testo visibile come evidenza, non come decorazione.

La deissi è il terzo spigolo vivo. Quando un utente dice "sostituisci questo con una guard clause", il testo pronunciato è tecnicamente una richiesta completa, ma il suo significato dipende interamente da ciò a cui punta "questo". Senza consapevolezza della selezione o un riferimento stabile al cursore, il sistema deve indovinare, e ogni ipotesi sbagliata fa perdere più tempo che riscrivere. L'ASR solo audio non può risolvere la deissi; può solo trascrivere il dimostrativo e sperare che uno strumento a valle capisca.

• Omofoni: inglese naturale contro sintassi di codice.
• Entità: nomi di pacchetti, classi, percorsi file e flag di comando.
• Deissi: "questo", "quello", "sopra", "la parte selezionata".
• Formato: prosa, elenco puntato, commento di codice, messaggio di commit o prompt.

L'architettura dell'ascoltatore multimodale

L'ascoltatore di Loqua ha tre input locali: feature audio in streaming, contesto derivato dallo schermo e metadati dell'app. Il percorso audio propone ciò che è stato detto. Il percorso del contesto riassume dove atterrerà il testo: app, tipo di campo, testo selezionato, token vicini e indizi strutturali visibili. Il percorso dell'app aggiunge vincoli, per esempio se sono appropriati a capo, Markdown o sintassi di codice.

L'ascoltatore non deve capire l'intero schermo come farebbe una persona. Gli serve la minima evidenza utile alla dettatura. In VS Code possono essere identificatori visibili, modalità del linguaggio e codice selezionato. In Slack può essere l'argomento del thread e il tono recente. In Notes può essere il livello di intestazione e il contesto dell'elenco.

Cosa scegliamo deliberatamente di non fare

Alcune capacità sono fuori ambito di proposito. L'ascoltatore non esegue OCR su screenshot di contenuti remoti, non riassume finestre in cui l'utente non sta digitando attivamente e non costruisce una cronologia visiva persistente. Inoltre non prova a inferire intenti granulari dalle immagini: un grafico, un frame video o una canvas di design non vengono interpretati; viene considerato solo il testo circostante. Ogni esclusione è una scelta di prodotto deliberata, che scambia capacità con prevedibilità e un confine di privacy più pulito.

Per questo parliamo di dettatura audio visiva solo in senso stretto di prodotto: audio più contesto visivo per scrivere. L'obiettivo non è il ragionamento visivo generale. L'obiettivo è avere meno parole sbagliate al cursore.

Come il contesto dello schermo risolve l'ambiguità

La dettatura con contesto dello schermo cambia l'output vincolando le possibilità. Se il cursore è dentro un file Python e la riga visibile contiene già from fastapi import, la parola pronunciata "router" è più probabilmente un simbolo che un sostantivo generico. Se il cursore è in Gmail, la stessa frase dovrebbe diventare una frase naturale.

L'ascoltatore gestisce anche l'editing consapevole della selezione. Se del testo è selezionato, la dettatura viene interpretata come un'istruzione su quel testo, a meno che l'utente non chieda esplicitamente di inserire nuova prosa. Questa singola distinzione elimina un'intera classe di duplicazioni accidentali.

I conflitti di contesto vengono gestiti fidandosi prima dell'evidenza più forte. L'app attiva è il segnale più affidabile, perché è garantito strutturalmente dal sistema operativo. Subito dopo viene il testo selezionato. I token visibili nelle vicinanze sono il segnale più morbido, perché possono essere obsoleti o accidentali. Quando due segnali non concordano, l'ascoltatore preferisce quello più solido e abbassa la confidenza invece di sceglierne uno e impegnarsi.

Privacy: il contesto dello schermo resta locale

Il riconoscimento vocale consapevole del contesto ha un costo di privacy se implementato con leggerezza. La regola di Loqua è che il contesto dello schermo necessario all'ascoltatore resta locale per impostazione predefinita. Il riassunto del contesto viene calcolato sul dispositivo; serve a modellare l'enunciato corrente; non viene conservato come log generale dello schermo.

In concreto, ciò che arriva all'ascoltatore on-device è un breve pacchetto di contesto effimero: identificatore dell'app attiva, lingua e tipo di campo, intervallo di selezione e poche centinaia di caratteri di testo visibile vicino. Per impostazione predefinita, ciò che non lascia mai il dispositivo è il contenuto più ampio della finestra, altre schede, altre app o qualsiasi cronologia persistente di questi elementi. Le funzionalità cloud opzionali, quando abilitate dall'utente, ricevono l'audio o il testo dettato entro i confini già descritti nella nostra nota sulla privacy ibrida; non ricevono mai il pacchetto di contesto grezzo.

Questo confine conta perché un ascoltatore che vede ciò che vedi può osservare codice, messaggi o bozze. Li trattiamo come dati sensibili. L'architettura di privacy è descritta più in dettaglio nella nostra nota sulla privacy ibrida, ma la versione breve è chiara: il percorso del contesto dello schermo è local-first, e le funzionalità cloud opzionali non ricevono contenuto grezzo dello schermo circostante.

Contesto di ricerca aperto

Il contesto di ricerca include modellazione audio-linguistica, proiezione visual-language e instruction tuning multimodale. Punti di partenza utili sono Whisper per ASR robusto, LLaVA per pattern di visual instruction tuning e ImageBind per l'allineamento tra modalità.

Quei paper sono contesto di letteratura. Lo stack di riconoscimento vocale multimodale di Loqua è lavoro originale, ottimizzato per la superficie di dettatura su Mac: contesto locale, streaming a bassa latenza e output consapevole dell'app. Prendiamo in prestito il vocabolario del campo, non una catena di dipendenze.

Roadmap

Il prossimo passo è una migliore segnalazione dell'incertezza. Se il contesto suggerisce due possibili identificatori, il sistema dovrebbe preservare l'ambiguità invece di inventare sicurezza. Vogliamo anche adapter più fini per terminali, fogli di calcolo, pannelli chat degli IDE e strumenti di design, dove la forma dell'output utile cambia drasticamente.

L'adapter per terminale è il lavoro più concreto nel breve periodo. Strutturalmente, un terminale è una singola riga al cursore; contestualmente, però, è una lunga cronologia di comandi e output precedenti che dovrebbe informare ciò che l'utente sta per digitare. Un adapter per fogli di calcolo ha la forma opposta: una piccola finestra di contesto visibile con significati di colonna rigidi. Entrambi riusano la stessa architettura dell'ascoltatore; cambia cosa conta come evidenza e da dove il renderer del testo trae gli indizi di formattazione.

La direzione di lungo periodo non è "il modello vede tutto". È più stretta e più sicura: l'ascoltatore vede abbastanza contesto locale per scrivere ciò che intendevi, dove lo intendevi, con meno pulizia successiva. Questa è la promessa di prodotto del riconoscimento vocale multimodale.