MOSS-Live aceita áudio de 16 kHz e não pausa a conversa para fazer buscas

A maioria das IAs de voz ainda conversa como um walkie-talkie. Primeiro a pessoa fala; depois, o sistema reconhece a frase, pensa e responde. Se for interrompido no meio, muitas vezes a resposta é cortada de vez ou reiniciada. Em uma conversa ao vivo, isso rapidamente se torna irritante: não é possível intercalar um “sim”, esclarecer um detalhe ou fazer uma pausa natural para escolher uma palavra.

A MOSI Intelligence propõe outra abordagem. Segundo os desenvolvedores, o MOSS-Live continua ouvindo enquanto fala, distingue uma reação curta de um comando para parar e consegue voltar a uma frase inacabada após uma interrupção. A API recebe áudio a 16 kHz e entrega a saída a 48 kHz. A conexão é feita por WebSocket, enquanto as imagens são transmitidas como quadros JPEG separados.

Não uma fila de falas, mas um fluxo compartilhado

Imagine um assistente de voz para uma loja virtual. Ele está explicando as regras de devolução quando, no meio da fala, o cliente pergunta: “E se eu já tiver jogado a caixa fora?”. Um agente convencional continuará falando por cima da pessoa ou esquecerá a resposta original. O MOSS-Live deve ouvir o esclarecimento, responder e depois voltar ao ponto em que parou.

O que importa não é o efeito da interrupção em si, mas o gerenciamento do estado da conversa. O sistema precisa entender que “aham” não significa parar, que uma pausa dentro da frase não encerra a fala e que uma conversa barulhenta nas proximidades pode não ter qualquer relação com o agente. É justamente nesse ponto que os produtos de voz costumam falhar, embora a síntese e o reconhecimento de fala já funcionem razoavelmente bem de forma isolada.

Os desenvolvedores também afirmam que o sistema funciona com câmera, compartilhamento de tela e sons do ambiente. Isso permite criar um assistente que não apenas ouve a pergunta, mas também vê a interface ou o objeto diante do usuário. Um agente de suporte técnico, por exemplo, poderia acompanhar a tela e indicar por voz o próximo passo.

Dois modelos no lugar de uma pausa

A arquitetura separa a parte conversacional rápida do trabalho mais lento executado em segundo plano. A primeira recebe áudio e imagens continuamente e mantém o diálogo. A segunda busca dados, aciona ferramentas ou elabora um plano. Um estado compartilhado conecta as duas, de modo que a conversa não precisa parar durante a busca.

Um cenário prático seria assim: o usuário pede opções de passagens e depois discute restrições de bagagem enquanto o modelo em segundo plano verifica as alternativas. Quando a busca termina, o resultado retorna à conversa no momento adequado. Para um produto, isso é mais útil do que um indicador de carregamento convencional: o agente permanece disponível, pode receber uma nova condição e ajustar uma tarefa que ainda não foi concluída.

Mas também surge aqui um problema complexo de engenharia. Se o usuário alterar a data da viagem enquanto uma busca em segundo plano já estiver em andamento, o sistema deverá cancelar a tarefa desatualizada ou marcar seu resultado como obsoleto. Sem controle de versões do estado, um diálogo contínuo e elegante começará a apresentar com confiança respostas para solicitações antigas.

O que verificar antes da integração

Por enquanto, o MOSS-Live está disponível como uma versão beta gratuita. O preço da futura cobrança por tempo de conexão não foi publicado. Não há pesos do modelo, e a implantação só é possível por meio da API. A documentação não lista todos os idiomas compatíveis; as demonstrações usam inglês e chinês, e a qualidade em russo não foi informada.

Também não existem medições públicas e independentes de latência, precisão na detecção de interrupções ou resistência a ruído. Portanto, ainda é cedo para comparar o sistema com o Gemini Live e o GPT Realtime apenas com base em vídeos de demonstração. É especialmente importante testar falsas paradas, recuperação após queda da conexão, custo de uma sessão longa e comportamento das tarefas em segundo plano quando a solicitação muda.

Para o desenvolvedor, é sensato começar com um protótipo restrito: um único cenário, vários tipos de interrupção e um registro de todas as transições de estado. O produto deve medir não apenas a latência até o primeiro áudio, mas também a proporção de interrupções processadas corretamente, o número de retomadas perdidas e o tempo para o retorno de um resultado em segundo plano. Se o MOSS-Live passar por esse teste, poderá se tornar a base de interfaces de voz que pareçam menos um chat lido em voz alta e mais um interlocutor de verdade.