Digitazione vocale omni-modale: comprensione multimodale, MoE e output testuale in streaming

Sono Shuran, founder di Loqua.ai. Questa è la nota ingegneristica più profonda dietro il nostro stack di digitazione vocale omni-modale: perché separiamo il riconoscimento acustico dalla comprensione multimodale del task e dal rendering del testo, dove gli esperti condizionali hanno aiutato, dove non hanno aiutato e perché lo streaming ha dettato quasi ogni scelta architetturale.

Perché gli audio LM monolitici colpiscono un muro su Mac

Un modello linguistico audio monolitico è attraente sulla carta: gli dai audio, frame dello schermo e testo, e gli chiedi di emettere la dettatura finale. Nell'uso quotidiano su Mac, questo design colpisce tre muri insieme. Primo, il budget di latenza è brutale. Se il primo token utile arriva dopo che chi parla ha fatto una pausa, la digitazione vocale sembra trascrizione batch invece che digitazione.

Questo è il budget a cui ci vincoliamo. Dal microfono al primo carattere visibile abbiamo circa 200 millisecondi. Di questi, circa 40 ms sono overhead di piattaforma (buffering Core Audio, consegna inter-processo e rendering finale), 60 ms sono estrazione di feature acustiche e inferenza front-end, 70 ms sono decoding dell'instruction planner per il primo parziale e 30 ms restano al text renderer per emettere un commit iniziale sicuro. Un singolo audio LM da oltre 1B parametri che esegue ogni passaggio dentro quella finestra è plausibile su una macchina da benchmark, ma inaffidabile su un laptop reale con browser, IDE e Zoom già aperti.

Secondo, il lavoro visibile all'utente non è solo automatic speech recognition. Lo stesso enunciato deve diventare un paragrafo Slack, un oggetto di Git commit, un prompt Cursor o un commento Python. Un modello monolitico può essere addestrato a fare tutto questo, ma deve reimparare le convenzioni di formato per ogni app e riscoprirle ogni volta che il cursore si sposta. Terzo, il modello deve restare dentro l'inviluppo termico e di memoria di un laptop. Caricare in VRAM un modello audio-visione-testo da 7B accanto all'indice di un IDE è una ricetta per thermal throttling e ventole rumorose. Lavori pubblici come Whisper e report recenti su omni-model hanno aiutato il campo a capire audio robusto e modellazione multimodale, ma spedire un prodotto locale costringe a scelte più strette e più opinabili.

La nostra conclusione è stata semplice: la digitazione vocale omni-modale dovrebbe essere una pipeline, non un blocco unico all-purpose. La pipeline permette a ogni livello di mantenere un obiettivo piccolo, una modalità di errore misurabile e un costo runtime delimitato.

La pipeline di istruzioni multimodale

Loqua non ha un livello di risposta vocale o TTS in questo percorso di prodotto. L'instruction planner consuma feature audio in streaming, contesto dello schermo selezionato, metadati dell'app attiva, testo recente intorno al cursore e prompt di istruzione attivo. Produce un piano compatto di output testuale: intento, entità, modalità di modifica, formato di destinazione e incertezza.

Il text renderer converte quel piano in testo. Non genera audio, risposte parlate o output TTS. Decide se il piano diventa una checklist Markdown, una frase, un commento di codice o un'istruzione strutturata. Questa separazione tiene il ragionamento cross-modale costoso fuori dal percorso caldo quando l'utente sta semplicemente dettando prosa.

Cosa ogni livello non deve fare

La disciplina sta in ciò che abbiamo rimosso. Il front end acustico non prova a essere intelligente sul formato di destinazione; espone token audio con timing e confidenza. L'instruction planner non scrive la prosa finale; crea un piano strutturato abbastanza piccolo da revisionare a basso costo. Il text renderer non rilegge l'audio e non sintetizza voce; si fida del piano, del contesto di destinazione e del prompt di istruzione. Lasciare che un livello attraversasse questi confini è stata la causa più comune delle regressioni di latenza nei primi prototipi, perché i loop di feedback tra livelli trasformano lo streaming in batch processing senza che nessuno se ne accorga finché non legge la trace.

Il beneficio è la debuggabilità. Quando l'output è sbagliato, possiamo capire se il recognizer ha sentito la parola sbagliata, se l'instruction planner ha scelto l'intento sbagliato o se il text renderer ha scritto nel registro sbagliato. È molto più facile che interpretare una lunga traiettoria nascosta. Nella nostra triage interna, circa due terzi dei fix di qualità post-lancio si sono isolati pulitamente a un singolo livello; il resto ha richiesto modifiche cross-layer, ma solo dopo una diagnosi chiara.

MoE sull'encoder audio

L'encoder audio è dove il calcolo condizionale ha dato risultati. Non ogni enunciato richiede lo stesso trattamento acustico. Parlato piano, inglese con accento, inglese e cinese mescolati, identificatori di codice e rumore di fondo da sala riunioni stressano parti diverse del modello. Un piccolo router mixture-of-experts consente all'encoder di spendere più capacità sulle regioni difficili senza rendere costoso ogni frame.

Abbiamo mantenuto il routing conservativo. Il router è condizionato su statistiche acustiche e indizi lessicali superficiali, non su profili personali dell'utente. Gli esperti si specializzano in pattern come parlato a bassa ampiezza, dettatura tecnica veloce e code-switching. Abbiamo rifiutato un pool di esperti più grande perché l'instabilità del routing peggiorava lo streaming: un modello accurato che cambia stile a metà enunciato non è utilizzabile per digitare.

Cosa abbiamo provato e abbandonato

Due idee sembravano attraenti in ricerca e hanno fallito nel prodotto. Primo, adattamento degli esperti per utente: addestrare un piccolo adapter per ogni utente pesante. Migliorava l'accuratezza cold-start di alcuni punti sul nostro test set interno, ma raddoppiava il footprint di memoria al cold launch e rendeva più confusi i confini di privacy. Secondo, un router che usava l'identificatore dell'app attiva come segnale forte. Si sovradattava a poche app comuni e degradava silenziosamente in quelle nuove. Lo abbiamo sostituito con il router acustico-lessicale attuale e spostato il comportamento app-aware più in alto, nell'instruction planner e nel text renderer, dove appartiene.

In pratica, il MoE sull'encoder audio aiuta Loqua a mantenere veloce il percorso comune rendendo meno fragile la coda. Questo è il valore di prodotto: non un trucco da benchmark, ma meno momenti in cui un nome di libreria, una frase detta piano o un frammento bilingue spezzano il flusso.

Streaming: token per token o frase per frase

Lo streaming è stato il tradeoff più difficile. L'output token per token sembra reattivo, ma può esporre ipotesi premature. L'output frase per frase è più pulito, ma sembra tardivo. Usiamo un ibrido: parziali precoci per span a basso rischio, commit ritardati per entità e modifiche che richiedono il contesto dello schermo.

Per esempio, quando dici "change the fetch profile function to return early if the auth client is missing", il sistema può streammare rapidamente le parole ordinarie. Ma i token intorno a fetchProfile e authClient aspettano che il livello di contesto confermi gli identificatori visibili. Ecco perché il rendering del testo è separato dal riconoscimento: può revisionare un piccolo span prima di confermare il testo, senza riavviare l'intero enunciato.

L'input bilingue a metà frase è un caso collegato. Quando dici "把这个 retry 函数改成指数退避," l'instruction planner produce un piano di output testuale che intreccia span cinesi con un token di codice inglese. Il text renderer emette i caratteri cinesi appena superano una soglia interna di confidenza e aspetta qualche millisecondo in più sull'identificatore inglese per confermarlo contro il buffer visibile dell'IDE. L'utente vede prima il flusso cinese, poi l'identificatore, poi il resto. Riordinare l'output sarebbe stato più veloce, ma sembrava sbagliato: l'occhio si aspetta digitazione da sinistra a destra.

I confini di commit sono l'altra manopola. Un confine di commit è il momento in cui il text renderer promette di non revisionare più. Li fissiamo su pause naturali, terminatori di frase e transizioni strutturali come paragrafo, elemento di lista o blocco di codice. Dentro un confine di commit il text renderer è libero di revisionare; una volta confermato, il testo è finale dal punto di vista dell'utente. Questo contratto fa sembrare lo streaming onesto invece che tremolante.

Il risultato è uno stack vocale in streaming che sembra immediato ma non tratta ogni ipotesi acustica iniziale come finale. Per la digitazione vocale, questo compromesso conta più della velocità della trascrizione grezza.

Contesto di ricerca aperto

Seguiamo da vicino la ricerca aperta perché affina il vocabolario per i problemi che vediamo nel prodotto. Paper e report su modellazione audio-linguistica, encoder multimodali e preference optimization mostrano il campo convergere su responsabilità separate, vincoli di streaming e allineamento cross-modale. Per il background, parti da Whisper, dal report tecnico Qwen2 e dalla panoramica pubblica Qwen2.5-Omni.

Il confine di prodotto importante: questi riferimenti sono contesto di letteratura. Lo stack di produzione di Loqua è ricerca originale addestrata e ottimizzata internamente per la dettatura Mac. Citiamo lavori aperti per spiegare il campo, non per suggerire provenienza.

Cosa abbiamo costruito e cosa viene dopo

Ciò che è stato spedito da questa direzione è un sistema stretto: digitazione vocale Mac che ascolta, legge contesto locale dello schermo e scrive testo consapevole dell'app. Il prossimo lavoro è una valutazione più rigorosa. Servono metodologie pubbliche per latenza, NER tecnica, WER multilingue e disambiguazione tramite contesto dello schermo, così le affermazioni siano verificabili fuori dal nostro dogfooding.

La seconda direzione è una calibrazione migliore. Quando il modello è incerto su un identificatore visibile, dovrebbe chiedere meno all'utente scegliendo una forma di output sicura o preservando la frase grezza. Stiamo anche esplorando indicatori di incertezza leggeri nel text renderer, così l'UI a valle possa evidenziare span a bassa confidenza per una rapida correzione da tastiera senza spezzare il ritmo della dettatura.

La terza direzione è l'audio non verbale. Quel lavoro è ancora in fase prototipale e lo copriamo separatamente in Sounds with meaning. Insieme al nostro lavoro sul reinforcement learning e sull'ascoltatore multimodale, forma l'agenda per il prossimo anno del nostro stack di digitazione vocale omni-modale.