MWS remove ruído de chamadas direto na rede da operadora: processamento leva 20 ms

A frase “vamos integrar uma rede neural” parece simples até esbarrar em milissegundos, tokens e um objetivo mal definido. No décimo primeiro meetup da MWS, três palestras trataram justamente desses obstáculos: nas chamadas, na documentação de arquitetura e no planejamento estratégico. Veja o que os profissionais podem aproveitar.

O ruído é removido na rede, e não no telefone

Maksim Maslennikov, Cluster lead Architect na MWS, apresentou um sistema de supressão de ruído que opera na infraestrutura da operadora. Ele funciona sem aplicativos e sem participação do smartphone: a voz é limpa antes de chegar ao interlocutor. A ideia surgiu após um episódio no metrô, quando o dirigente da empresa não conseguiu conversar direito por causa do barulho.

A implementação foi a parte mais difícil. Em 2G e 3G, a voz trafega por um canal dedicado, e a equipe considerou encaminhar a chamada por um prefixo especial. No LTE, as chamadas passam pelo IMS, ou seja, trafegam em pacotes IP. Nesse ambiente, a equipe integrou um serviço próprio de mídia por onde passa o fluxo de voz. Não é preciso mudar o número.

A principal restrição é o tempo. Cada pacote precisa ser recebido, convertido para um formato adequado à rede neural, limpo e encaminhado em aproximadamente 20 ms. Se esse prazo não for cumprido, os participantes ouvirão estalos e cortes. Além disso, o modelo trabalha com uma conversa contínua, e não com gravações isoladas. Por isso, foi necessário adaptá-lo para manter o estado entre os trechos.

Os modelos abertos disponíveis para melhoria da fala não atenderam à necessidade sem ajustes. Eles passaram por treinamento adicional com gravações de ruídos reais, incluindo um compressor em funcionamento. Para evitar consumir recursos de GPU em todas as conversas, a equipe adicionou um pequeno modelo de monitoramento: ele decide quando é necessária uma limpeza mais pesada e quando um algoritmo leve é suficiente. Há também uma questão geográfica: quanto mais distante o nó de processamento estiver do assinante, mais difícil será cumprir o limite de latência.

Também há desvantagens: a voz muda ligeiramente após o processamento, embora continue compreensível. A solução já está em produção, mas a MWS não pretende divulgar os pesos dos modelos. O próximo desafio é reconstruir a voz perdida durante a transmissão pela rede.

Agentes que corrigem a documentação

Evgeny Artemyev, Stream lead Architect na MWS, mostrou uma ferramenta que enfrenta um problema clássico: o código avançou, mas os documentos de arquitetura ficaram no passado. Novos microsserviços e alterações nas APIs não entram na descrição do sistema, que deixa de corresponder à realidade.

A ferramenta reúne dados de repositórios, DevOps, Jira e Confluence. Um agente analisa as mudanças e seleciona materiais; outro consolida as informações e prepara propostas de atualização. Um orquestrador coordena o trabalho, enquanto uma camada separada remove informações confidenciais antes do envio ao modelo. O resultado são arquivos YAML e Markdown que permitem buscar tecnologias desatualizadas, visualizar relações entre sistemas e avaliar riscos. A decisão sobre as alterações cabe ao arquiteto.

O ponto mais útil da palestra foi a comparação entre dois modos de operação. No determinístico, os desenvolvedores definem previamente as etapas e as ferramentas. No não determinístico, o próprio agente decide o que fazer. Em um experimento com Claude, a segunda opção teve um resultado pior: o modelo consumiu mais tokens, executou ações desnecessárias e teve mais dificuldade para manter a estrutura. Por isso, a equipe escolheu o LangGraph, que permite definir as etapas e as transições possíveis, além de executar vários agentes em paralelo. O custo foi uma depuração mais complexa: é preciso acompanhar o estado de cada agente e salvar os resultados intermediários.

Uma armadilha à parte é a verificação dos dados antes do envio ao modelo. Isso pode ser feito com expressões regulares ou com um modelo classificador. Mas, em um dos projetos, o classificador em CPU levou de três a quatro segundos, diante de um limite de 500 ms.

“Mapa de hipóteses”: o objetivo continua nas mãos de uma pessoa

Aleksandr Byndyu apresentou uma metodologia que conecta os objetivos da empresa, seus recursos e as condições externas às apostas estratégicas. A base é uma análise SWOT com elementos interligados. Sua tese principal: acelerar operações isoladas não garante o crescimento do negócio. Se um e-mail é escrito em cinco minutos em vez de duas horas, isso economiza tempo, mas não necessariamente aumenta a receita.

Em um caso prático, a IA montou um mapa a partir de um pequeno PDF e chegou perto da realidade. Mas tudo depende da formulação do objetivo: um erro nessa etapa leva a métricas inadequadas, algo que fica evidente na comparação com a referência. Na segunda demonstração, o modelo usou habilidades obtidas no GitHub, fez perguntas para esclarecer a tarefa e entregou um mapa com um protótipo de interface.

Ele errou ao identificar o sujeito da análise, e foi preciso corrigir isso manualmente. Quando se descobriu que uma das tendências não existia, os dados foram substituídos e uma nova versão ficou pronta em cerca de dez minutos. O valor do protótipo, nesse caso, está na rapidez do feedback, e não na qualidade da implementação.

As limitações são claras: parte das relações é configurada manualmente, e o usuário precisa conhecer a metodologia para orientar o modelo e avaliar suas respostas.

O que levar para a prática

No encerramento, os participantes imaginaram serviços com as tecnologias da MWS: um assistente para gestores, um concierge por voz, um tradutor e um assistente para conseguir contato telefônico com órgãos públicos. Para cenários como o registro de acordos, a validade jurídica do resultado continua sendo uma questão em aberto.

O resultado pode ser resumido em três regras. Para aplicações em tempo real, calcule primeiro o orçamento de latência e o custo de GPU e use uma cascata de modelos leves e pesados. Para agentes, comece com um grafo rígido e flexibilize-o apenas onde houver justificativa, medindo previamente o custo das verificações de proteção. Para tarefas estratégicas, dedique tempo à formulação do objetivo, porque é dele que depende a qualidade de todo o restante.

Ressalva: este texto relata as apresentações dos próprios desenvolvedores. Não foram apresentados testes independentes da qualidade da supressão de ruído ou da precisão dos agentes.