Digitação por voz omni-modal: entendimento multimodal, MoE e saída de texto em streaming

Sou Shuran, fundador da Loqua.ai. Esta é a nota de engenharia mais profunda por trás da nossa stack de digitação por voz omni-modal: por que separamos reconhecimento acústico de entendimento multimodal de tarefas e renderização de texto, onde especialistas condicionais ajudaram, onde não ajudaram, e por que streaming ditou quase todas as escolhas de arquitetura.

Por que LMs de áudio monolíticos batem no limite do Mac

Um modelo de linguagem de áudio monolítico é atraente no papel: alimente áudio, frames da tela e texto em um único modelo grande e peça para ele emitir o ditado final. No uso diário do Mac, esse desenho encontra três limites ao mesmo tempo. Primeiro, o orçamento de latência é brutal. Se o primeiro token útil chega depois que a pessoa pausa, digitação por voz parece transcrição em lote, não digitação.

Este é o orçamento que exigimos de nós mesmos. Do microfone ao primeiro caractere visível, temos cerca de 200 milissegundos. Desse total, aproximadamente 40 ms são overhead de plataforma (buffering do Core Audio, entrega entre processos e renderização final), 60 ms são extração de recursos acústicos e inferência de front-end, 70 ms são decodificação do planejador de instruções para o primeiro parcial, e sobram 30 ms para o renderizador de texto emitir um commit inicial seguro. Um LM de áudio com 1B+ parâmetros rodando a cada etapa nessa janela é plausível em uma máquina de benchmark, mas não confiável em um laptop real com navegador, IDE e Zoom já abertos.

Segundo, o trabalho visível ao usuário não é apenas reconhecimento automático de fala. A mesma fala precisa virar um parágrafo no Slack, um assunto de Git commit, um prompt do Cursor ou um comentário em Python. Um modelo monolítico pode ser treinado para fazer tudo isso, mas precisa reaprender as convenções de formato de cada app e redescobri-las toda vez que o cursor se move. Terceiro, o modelo precisa caber no envelope térmico e de memória de um laptop. Um modelo de áudio-visão-texto de 7B carregado na VRAM ao lado do índice da IDE é receita para thermal throttling e ventoinha barulhenta. Trabalhos públicos como Whisper e relatórios recentes de omni-modelos ajudaram o campo a entender áudio robusto e modelagem multimodal, mas enviar um produto local exige escolhas mais estreitas e opinativas.

Nossa conclusão foi simples: digitação por voz omni-modal deve ser um pipeline, não um bloco único para todos os fins. O pipeline permite que cada camada mantenha um objetivo pequeno, um modo de falha mensurável e um custo de runtime limitado.

O pipeline multimodal de instruções

O Loqua não tem camada de resposta por fala nem TTS neste caminho de produto. O planejador de instruções consome recursos de áudio em streaming, contexto selecionado da tela, metadados do app ativo, o texto recente ao redor do cursor e o prompt de instrução ativo. Ele produz um plano compacto de saída de texto: intenção, entidades, modo de edição, formato de destino e incerteza.

O renderizador de texto converte esse plano em texto. Ele não gera áudio, respostas faladas ou saída TTS. Ele decide se o plano vira uma checklist em Markdown, uma frase, um comentário de código ou uma instrução estruturada. Essa separação mantém raciocínio cross-modal caro fora do caminho quente quando o usuário está simplesmente ditando prosa.

O que cada camada não pode fazer

A disciplina está no que removemos. O front-end acústico não tenta ser inteligente sobre formato de destino; ele expõe tokens de áudio com timing e confiança. O planejador de instruções não escreve a prosa final; ele cria um plano estruturado pequeno o bastante para ser revisado com baixo custo. O renderizador de texto não relê o áudio nem sintetiza fala; ele confia no plano, no contexto de destino e no prompt de instrução. Deixar qualquer camada cruzar esses limites foi a causa mais comum de regressões de latência em nossos primeiros protótipos, porque loops de feedback entre camadas transformam streaming em processamento em lote sem que ninguém perceba até ler o trace.

O benefício é depurabilidade. Quando a saída está errada, conseguimos dizer se o reconhecedor ouviu a palavra errada, se o planejador de instruções escolheu a intenção errada ou se o renderizador de texto escreveu no registro errado. Isso é muito mais fácil do que interpretar uma trajetória oculta longa. Em nossa triagem interna, cerca de dois terços dos ajustes de qualidade pós-lançamento foram isolados claramente em uma única camada; o restante exigiu mudanças entre camadas, mas só depois de um diagnóstico claro.

MoE no codificador de áudio

O codificador de áudio foi onde computação condicional compensou. Nem toda fala precisa do mesmo tratamento acústico. Fala baixa, inglês com sotaque, inglês e chinês misturados, identificadores de código e ruído de sala de reunião tensionam partes diferentes do modelo. Um pequeno roteador mixture-of-experts permite ao codificador gastar mais capacidade em regiões difíceis sem tornar todo frame caro.

Mantivemos o roteamento conservador. O roteador é condicionado por estatísticas acústicas e pistas lexicais rasas, não por perfis pessoais de usuário. Especialistas se concentram em padrões como fala de baixa amplitude, ditado técnico rápido e code-switching. Rejeitamos um pool maior de especialistas porque a instabilidade de roteamento piorava o comportamento em streaming: um modelo preciso, mas que muda de estilo no meio da fala, não serve para digitar.

O que tentamos e descartamos

Duas ideias pareciam atraentes na pesquisa e falharam no produto. Primeiro, adaptação de especialistas por usuário: treinar um pequeno adapter por usuário intenso. Isso melhorou a acurácia de cold start em alguns pontos no nosso conjunto interno, mas dobrou o footprint de memória no cold launch e deixou os limites de privacidade mais nebulosos. Segundo, um roteador que usava o identificador do app ativo como sinal forte. Ele overfitou em alguns apps comuns e degradou silenciosamente em apps novos. Substituímos pelo roteador acústico-e-lexical atual e movemos o comportamento app-aware para o planejador de instruções e o renderizador de texto, onde ele pertence.

Em termos práticos, MoE no codificador de áudio ajuda o Loqua a manter o caminho comum rápido enquanto deixa a cauda menos frágil. Esse é o valor de produto: não um truque de benchmark, mas menos momentos em que um nome de biblioteca, uma frase baixa ou um trecho bilíngue quebra o fluxo.

Streaming: token por token vs frase por frase

Streaming foi o tradeoff mais difícil. Saída token por token parece responsiva, mas pode expor palpites prematuros. Saída frase por frase é mais limpa, mas parece atrasada. Usamos um híbrido: parciais iniciais para trechos de baixo risco, commits adiados para entidades e edições que precisam de contexto de tela.

Por exemplo, quando você diz "change the fetch profile function to return early if the auth client is missing", o sistema consegue transmitir palavras comuns rapidamente. Mas os tokens em torno de fetchProfile e authClient esperam a camada de contexto confirmar os identificadores visíveis. É por isso que a renderização de texto é separada do reconhecimento: ela pode revisar um pequeno trecho antes de commitar o texto, sem reiniciar toda a fala.

Entrada bilíngue no meio da frase é um caso relacionado. Quando você diz "把这个 retry 函数改成指数退避," o planejador de instruções produz um plano de saída de texto que intercala trechos em chinês com um token de código em inglês. O renderizador de texto emite os caracteres chineses assim que passam por um limiar interno de confiança e espera alguns milissegundos extras no identificador em inglês para confirmá-lo contra o buffer visível da IDE. O usuário vê primeiro o fluxo em chinês, depois o identificador, depois o restante. Reordenar a saída teria sido mais rápido, mas pareceria errado; o olho espera digitação da esquerda para a direita.

Fronteiras de commit são o outro controle. Uma fronteira de commit é o momento em que o renderizador de texto promete não revisar mais. Fixamos essas fronteiras em pausas naturais, terminadores de frase e transições estruturais como parágrafo, item de lista ou bloco de código. Dentro de uma fronteira de commit, o renderizador de texto pode revisar; depois de commitado, o texto é final do ponto de vista do usuário. Esse contrato é o que faz o streaming parecer honesto em vez de instável.

O resultado é uma stack de voz em streaming que parece imediata, mas não trata todo palpite acústico inicial como final. Para digitação por voz, esse compromisso importa mais do que velocidade bruta de transcrição.

Contexto de pesquisa aberta

Acompanhamos pesquisa aberta de perto porque ela afia nosso vocabulário para os problemas que vemos no produto. Papers e relatórios sobre modelagem áudio-linguagem, codificadores multimodais e otimização por preferência mostram o campo convergindo para responsabilidades divididas, restrições de streaming e alinhamento cross-modal. Para contexto, comece por Whisper, Qwen2 technical reporting e a visão pública de Qwen2.5-Omni.

O limite importante de produto: essas referências são contexto de literatura. A stack de produção do Loqua é pesquisa original treinada e otimizada internamente para ditado no Mac. Citamos trabalhos abertos para explicar o campo, não para sugerir proveniência.

O que construímos e o que vem a seguir

O que saiu dessa direção é um sistema estreito: digitação por voz no Mac que escuta, lê contexto local da tela e escreve texto consciente do app. O próximo trabalho é avaliação mais rigorosa. Precisamos de metodologia pública para latência, NER técnico, WER multilíngue e desambiguação por contexto de tela, para que as afirmações sejam revisáveis fora do nosso loop de dogfooding.

A segunda direção é melhor calibração. Quando o modelo está incerto sobre um identificador visível, ele deve pedir menos do usuário escolhendo uma forma de saída segura ou preservando a frase bruta. Também estamos explorando marcadores leves de incerteza no renderizador de texto para que a UI downstream possa destacar trechos de baixa confiança para uma correção rápida no teclado sem quebrar o ritmo do ditado.

A terceira direção é áudio não verbal. Esse trabalho ainda está em estágio de protótipo, e cobrimos separadamente em Sounds with meaning. Junto com nosso trabalho em reinforcement learning e no ouvinte multimodal, ele forma a agenda para o próximo ano da nossa stack de digitação por voz omni-modal.