Reconhecimento de voz multimodal: construindo um ouvinte que vê o que você vê

O reconhecimento de fala baseado apenas em áudio ficou bom o bastante para que suas falhas restantes sejam fáceis de subestimar. Benchmarks com fala limpa escondem o problema real de produto: usuários ditam dentro de apps, perto de código visível, misturam idiomas e usam referências parciais como "esta função" ou "o bullet acima".

Onde o ASR ainda falha

O exemplo clássico são homófonos. "From foo import bar" e from foo import bar soam parecidos, mas pertencem a mundos diferentes. O mesmo vale para "cache the auth client" e "cash the auth client" se o modelo não sabe que o cursor está em um arquivo TypeScript. Só o áudio não infere o destino de forma confiável.

Identificadores de código tornam isso mais nítido. O usuário pode dizer "fetch profile", mas a função visível é fetchProfile. Um modelo de transcrição ouve palavras; um modelo de ditado deve preservar o identificador. O reconhecimento de voz multimodal trata o texto visível como evidência, não como decoração.

Dêixis é a terceira aresta. Quando alguém diz "substitua isto por uma guard clause", o texto falado é tecnicamente um pedido completo, mas seu significado depende inteiramente do que "isto" aponta. Sem consciência da seleção ou uma referência estável do cursor, o sistema precisa adivinhar, e qualquer palpite errado custa mais tempo do que redigitar. ASR só com áudio não resolve dêixis; ele só transcreve o demonstrativo e torce para uma ferramenta downstream entender.

• Homófonos: inglês comum versus sintaxe de código.
• Entidades: nomes de pacotes, classes, caminhos de arquivo e flags de comando.
• Dêixis: "isto", "aquilo", "acima", "a parte selecionada".
• Formato: prosa, bullet, comentário de código, mensagem de commit ou prompt.

A arquitetura do ouvinte multimodal

O ouvinte do Loqua tem três entradas locais: recursos de áudio em streaming, contexto derivado da tela e metadados do app. O caminho de áudio propõe o que foi dito. O caminho de contexto resume onde o texto vai entrar: app, tipo de campo, texto selecionado, tokens próximos e pistas estruturais visíveis. O caminho do app acrescenta restrições, como se quebras de linha, Markdown ou sintaxe de código fazem sentido.

O ouvinte não precisa entender a tela inteira como um humano entenderia. Ele precisa da evidência mínima útil para o ditado. No VS Code, isso pode significar identificadores visíveis, modo de linguagem e código selecionado. No Slack, pode ser o tópico da thread e o tom recente. No Notes, pode ser o nível de título e o contexto de lista.

O que deliberadamente não tentamos fazer

Algumas capacidades ficam fora do escopo de propósito. O ouvinte não faz OCR em capturas de tela de conteúdo remoto, não resume janelas nas quais o usuário não está digitando ativamente e não cria um histórico visual persistente. Ele também não tenta inferir intenção detalhada a partir de imagens: um gráfico, um frame de vídeo ou uma tela de design não é interpretado; apenas o texto ao redor é usado. Cada remoção é uma escolha deliberada de produto que troca capacidade por previsibilidade e por um limite de privacidade mais limpo.

É por isso que chamamos isso de ditado audiovisual apenas no sentido restrito de produto: áudio mais contexto visual para escrever. O objetivo não é raciocínio visual geral. O objetivo é ter menos palavras erradas no cursor.

Como o contexto da tela resolve ambiguidades

Ditado com contexto de tela muda a saída ao restringir as possibilidades. Se o cursor está dentro de um arquivo Python e a linha visível já contém from fastapi import, a palavra falada "router" tem mais chance de ser um símbolo do que um substantivo genérico. Se o cursor está no Gmail, a mesma frase deve virar uma sentença.

O ouvinte também lida com edição consciente da seleção. Se há texto selecionado, o ditado é interpretado como uma instrução sobre esse texto, a menos que o usuário peça explicitamente para inserir uma nova prosa. Essa única distinção remove uma classe inteira de duplicações acidentais.

Conflitos de contexto são tratados confiando primeiro na evidência mais forte. O app ativo é o sinal mais confiável porque é estruturalmente garantido pelo sistema operacional. O texto selecionado vem em seguida. Tokens visíveis próximos são o sinal mais fraco, porque podem estar desatualizados ou ser acidentais. Quando dois sinais discordam, o ouvinte prefere o mais rígido e reduz a confiança, em vez de escolher um e se comprometer.

Privacidade: o contexto da tela fica local

Reconhecimento de fala sensível ao contexto tem custo de privacidade se for implementado sem cuidado. A regra do Loqua é que o contexto de tela necessário ao ouvinte fica local por padrão. O resumo de contexto é calculado no dispositivo; ele é usado para moldar a fala atual; ele não é retido como um log geral da tela.

Concretamente, o que chega ao ouvinte no dispositivo é um pacote curto e efêmero de contexto: identificador do app ativo, linguagem e tipo de campo, intervalo de seleção e algumas centenas de caracteres de texto visível próximo. O que nunca sai do dispositivo por padrão é o conteúdo amplo da janela, outras abas, outros apps ou qualquer histórico persistente desses dados. Recursos opcionais em nuvem, quando ativados pelo usuário, recebem o áudio ou texto ditado dentro dos limites já descritos em nossa nota de privacidade híbrida; eles nunca recebem o pacote bruto de contexto.

Esse limite importa porque um ouvinte que vê o que você vê pode observar código, mensagens ou rascunhos. Tratamos isso como dado sensível. A arquitetura de privacidade é coberta em mais detalhe em nossa nota de privacidade híbrida, mas a versão curta é clara: o caminho de contexto de tela é local-first, e recursos opcionais em nuvem não recebem conteúdo bruto da tela ao redor.

Contexto de pesquisa aberta

O pano de fundo de pesquisa inclui modelagem áudio-linguagem, projeção visão-linguagem e ajuste multimodal por instruções. Bons pontos de partida incluem Whisper para ASR robusto, LLaVA para padrões de ajuste visual por instruções e ImageBind para alinhamento entre modalidades.

Esses papers são contexto de literatura. A stack de reconhecimento de voz multimodal do Loqua é trabalho original ajustado para a superfície de ditado no Mac: contexto local, streaming de baixa latência e saída consciente do app. Tomamos emprestado o vocabulário do campo, não uma cadeia de dependências.

Roadmap

O próximo passo é relatar melhor a incerteza. Se o contexto sugere dois identificadores possíveis, o sistema deve preservar a ambiguidade em vez de inventar confiança. Também queremos adaptadores de app mais refinados para terminais, planilhas, painéis de chat em IDEs e ferramentas de design, onde a forma da saída útil muda drasticamente.

O adaptador de terminal é o trabalho de curto prazo mais concreto. Um terminal é estruturalmente uma única linha no cursor, mas contextualmente é um longo histórico de comandos e saídas anteriores que deve informar o que o usuário está prestes a digitar. Um adaptador de planilha tem a forma oposta: uma janela de contexto visível minúscula, com significado rígido de colunas. Os dois adaptadores reutilizam a mesma arquitetura de ouvinte; a diferença está no que conta como evidência e de onde o renderizador de texto tira suas pistas de formatação.

A direção de longo prazo não é "o modelo vê tudo". É mais estreita e mais segura: o ouvinte vê contexto local suficiente para escrever o que você quis dizer, onde você quis dizer, com menos limpeza depois. Essa é a promessa de produto do reconhecimento de voz multimodal.