Advanced Payment Solutions leva a piloto um ponto eletrônico com IA para ligações sem equipe de ML

A Advanced Payment Solutions contou como levou a piloto um assistente de IA por voz para ligações sem ter uma equipe própria de ML. Em seis meses, 12 desenvolvedores backend montaram um sistema que sugere ao gerente, em tempo real, como responder ao cliente, com latência de cerca de dois segundos.

Como o MVP foi montado

Internamente, o projeto recebeu o nome de «Suflyor» («Ponto eletrônico»). Sua tarefa é ouvir uma conversa já transcrita, entender de qual produto se fala, identificar a objeção do cliente e mostrar de imediato ao gerente uma dica em texto. O stack final foi construído com Python, FastAPI e PostgreSQL, e a classificação e a geração ficaram a cargo de classificadores BERT e de um Qwen 8B local. Para o negócio, é uma forma de reduzir a carga dos mentores e levar mais rápido os novos funcionários aos KPIs, sobretudo quando o ecossistema tem mais de 35 produtos e o gerente precisa guardar na cabeça cenários demais.

A restrição principal era rígida: o sistema tem apenas 1,5–2 segundos para responder; do contrário, a dica perde o sentido durante uma conversa ao vivo.

A equipe chegou rápido a um protótipo funcional. Nas três primeiras semanas, os desenvolvedores pegaram transcrições de texto de ligações, treinaram dois classificadores BERT com cerca de 1,5 mil diálogos, montaram bases de conhecimento simples com scripts e conectaram tudo por meio de prompts a um modelo GPT na nuvem. A interface foi feita em um dia com Django. Essa prova de conceito era lenta, com latência de 10–15 segundos, mas bastou para defender a ideia diante do negócio e conseguir sinal verde para o MVP. Depois começou o trabalho de engenharia para reduzir a latência, estabilizar o sistema e fazer as integrações.

Por que tudo foi simplificado

No começo, a equipe, como costuma acontecer em projetos de IA, projetou um sistema ambicioso demais: pipeline de áudio próprio, vários classificadores complexos, fine-tuning de um grande modelo de linguagem, banco vetorial e até um ciclo de autoaprendizado. Mas logo ficou claro que esse caminho esticaria o lançamento para 12–18 meses e aumentaria muito o risco de fracasso. Em vez de tentar construir uma arquitetura «perfeita», os desenvolvedores passaram a cortar sistematicamente tudo o que dava para dispensar na primeira versão.

«Não lutamos contra os problemas, mas reprojetamos o sistema para que

esses problemas não surgissem nele».

• Abriram mão do fine-tuning em favor do RAG, para não gastar meses com rotulagem e reduzir o risco de alucinações.
• Não escreveram uma transcrição própria e usaram segmentos de texto prontos da Voximplant.
• Simplificaram o classificador de objeções: em vez de mais de 15 classes, ficaram com um esquema binário «há objeção / não há objeção».
• Não adotaram um banco vetorial pesado para alguns megabytes de dados e carregaram arquivos JSON estruturados direto na memória.
• Saíram das APIs em nuvem para um Qwen 8B local em um servidor com GPU, para cumprir a latência e não levar dados sensíveis para fora do perímetro.

Esse conjunto de concessões foi decisivo. Os modelos em nuvem respondiam em 7–20 segundos, e o Qwen 32B, embora respondesse melhor, também não cabia no tempo. O Qwen 8B, mais compacto, mostrou-se bom o bastante para as dicas ao gerente e estabilizou a latência em cerca de dois segundos. Ao mesmo tempo, a implantação local resolveu as questões de segurança da informação: as transcrições das conversas não precisam ser enviadas a serviços externos, então não foi necessário construir uma camada separada de mascaramento de dados pessoais nem pagar por ela com latência adicional.

O que o piloto mostrou

O problema mais subestimado não foram os modelos, mas os dados. A equipe pegou 200 ligações, dividiu entre 12 participantes e logo esbarrou na rotulagem manual: para classificar corretamente as objeções, não basta destacar uma frase; é preciso entender o contexto da conversa e a lógica de vendas. Como resultado, os desenvolvedores refizeram a própria formulação do problema. Em vez de tentar «ensinar a IA a pensar como um especialista», passaram a mirar um objetivo mais restrito: identificar a tempo o momento em que o gerente precisa de ajuda e, a partir daí, buscar o script certo e gerar a dica.

No piloto, o sistema chegou a uma latência média de cerca de dois segundos, subindo a três em apenas 2–3% dos casos. A classificação de serviços alcançou precisão acima de 70%, e o reconhecimento de fala, a partir de 92%, dependendo da qualidade da conexão.

A equipe afirma que o piloto já teve um efeito qualitativo: surgiram os primeiros sinais de praticidade, redução da carga dos mentores e utilidade geral para os operadores. Mas ainda não há conclusões estatisticamente significativas sobre conversão e KPIs: para isso, o produto precisa de escala e de integração fluida direto no CRM.

O que isso significa

Esse caso mostra que um produto interno de IA nem sempre exige uma equipe de ML pronta desde o início. Se a empresa tem bons engenheiros backend, uma dor de negócio clara e acesso aos processos, o MVP pode ser montado mais rápido com uma simplificação radical da arquitetura e o abandono de componentes «inteligentes» desnecessários. A principal conclusão não está na escolha de um modelo específico, mas na disciplina: primeiro resolver o problema do negócio, depois verificar as restrições de velocidade e segurança, e só então complicar o stack.