"Soluções de Pagamento Avançadas" lançou assistente de voz com IA para chamadas em piloto sem equipe de ML

A empresa "Soluções de Pagamento Avançadas" contou como lançou um assistente de IA por voz para chamadas no piloto sem seu próprio time de ML. Em seis meses, 12 desenvolvedores backend construíram um sistema que em tempo real sugere ao gerente como responder o cliente e se encaixa em um atraso de cerca de dois segundos.

Como o MVP foi construído

Dentro da empresa o projeto ganhou o nome "Apromptador". Sua tarefa é ouvir uma conversa já transcrita, entender qual produto está sendo discutido, notar objeções do cliente e imediatamente mostrar ao gerente uma dica em texto. O stack final foi montado em Python, FastAPI e PostgreSQL, enquanto classificadores BERT e Qwen 8B local cuidavam da classificação e geração.

Para o negócio isso é uma forma de reduzir a carga nos mentores e colocar novos funcionários em KPI mais rápido, especialmente quando o ecossistema tem mais de 35 produtos e o gerente precisa manter muitos cenários em mente. A restrição chave era rígida: o sistema tem apenas 1,5–2 segundos para responder, caso contrário a dica perde sentido bem no meio de um diálogo ao vivo.

O time atingiu um protótipo funcional rapidamente. Nas primeiras três semanas os desenvolvedores pegaram transcrições de texto das chamadas, treinaram dois classificadores BERT em aproximadamente 1.500 diálogos, montaram bases de conhecimento simples com scripts e conectaram tudo através de prompts com um modelo GPT na nuvem. A interface foi feita em um dia usando Django. Tal prova de conceito funcionava lentamente, com atraso de 10–15 segundos, mas foi o suficiente para defender a ideia na frente do negócio e conseguir o aval para o MVP. Então começou o trabalho real de engenharia para reduzir atrasos, estabilização e integrações.

Por que tudo foi simplificado

No começo o time, como frequentemente acontece em projetos de IA, projetou um sistema muito ambicioso: seu próprio pipeline de áudio, vários classificadores complexos, fine-tuning de um modelo de linguagem grande, banco de dados vetorial e até um loop de autoaprendizado. Mas bem rápido ficou claro que tal caminho estenderia o lançamento para 12–18 meses e aumentaria drasticamente a chance de fracasso. Em vez de tentar construir a arquitetura "perfeita" os desenvolvedores começaram sistematicamente a remover tudo aquilo que poderia ser dispensado na primeira versão.

"Não lutamos contra problemas, redesenhamos o sistema para que esses

problemas não surgissem nele."

• Recusaram fine-tuning em favor de RAG para evitar gastar meses em anotação e reduzir o risco de alucinações.
• Não escreveram sua própria transcrição e pegaram segmentos de texto prontos do Voximplant.
• Simplificaram o classificador de objeções: em vez de 15+ classes deixaram um esquema binário "tem objeção / sem objeção".
• Não puxaram um banco de dados vetorial pesado para alguns megabytes de dados e carregaram arquivos JSON estruturados direto na memória.
• Saíram das APIs em nuvem para Qwen 8B local em um servidor GPU para se encaixar no atraso e não enviar dados sensíveis para fora do perímetro.

Este conjunto de compromissos provou ser chave. Modelos em nuvem davam uma resposta em 7–20 segundos, e Qwen 32B apesar de responder melhor ainda não passava no teste de tempo. Qwen 8B mais compacta provou ser boa o bastante para dicas ao gerente e estabilizou a latência em cerca de dois segundos. Paralelamente a implementação local fechou questões de segurança: transcrições de chamadas não precisam ser enviadas para serviços externos, o que significa que não precisavam construir uma camada separada de mascaramento de dados pessoais e pagar por isso com atrasos adicionais.

O que o piloto mostrou

O problema mais subestimado provou ser não modelos mas dados. O time pegou 200 chamadas, dividiu entre 12 participantes e rapidamente bateu na parede da anotação manual: para classificar corretamente objeções não é suficiente destacar uma frase, você precisa entender o contexto da conversa e a lógica de vendas. Como resultado os desenvolvedores reconstruíram a própria definição do problema. Em vez de tentar "ensinar IA a pensar como um especialista" eles focaram em um objetivo mais estreito: notar em tempo quando o gerente precisa de ajuda, e então puxar o script necessário e gerar uma dica.

Ao final do piloto o sistema atingiu atraso médio de cerca de dois segundos, apenas em 2–3% dos casos subindo para três. Classificação de serviços deu acurácia acima de 70%, e reconhecimento de fala — de 92% dependendo da qualidade da conexão. O time escreve que o piloto já deu um efeito qualitativo: os primeiros sinais apareceram em conveniência, redução de carga nos mentores e utilidade geral para operadores. Mas conclusões estatisticamente significativas em conversão e KPI ainda não estão lá — para isso o produto precisa de escalonamento e integração perfeita direto no CRM.

O que isso significa

Este caso demonstra bem que um produto de IA interno nem sempre requer um time de ML pronto do zero. Se uma empresa tem engenheiros backend fortes, dor de negócio clara e acesso aos processos, um MVP pode ser montado mais rápido através de simplificação rígida da arquitetura e recusa de componentes "inteligentes" desnecessários. A principal lição aqui não está na escolha de um modelo específico mas em disciplina: primeiro resolver o problema de negócio, depois verificar restrições de velocidade e segurança, e só então complicar o stack.