Para prever churn, combine um modelo de machine learning que estima risco com um modelo de linguagem que transforma relatos de clientes em informações estruturadas. Churn é a perda de clientes segundo uma regra definida pelo negócio. O modelo preditivo aprende com dados históricos; o LLM, ou modelo de linguagem, ajuda a organizar motivos e evidências presentes em chamados e conversas.
Essa combinação funciona melhor quando cada componente tem uma função delimitada. O LLM não deve inventar a probabilidade de cancelamento nem afirmar a causa de uma saída. O projeto precisa de um evento bem definido, dados disponíveis antes da previsão, avaliação em períodos posteriores e uma ação de retenção que possa ser medida.
Resumo rápido
- Defina quem pode cancelar, qual evento conta como churn e em qual horizonte.
- Separe dados conhecidos na data da previsão de informações que só surgiram depois.
- Use o LLM para extrair temas dos textos, sempre com evidência e opção de abstenção.
- Compare o sistema híbrido com uma regra simples e um modelo sem textos.
- Meça a qualidade das previsões e o efeito real das ações de retenção separadamente.
1. Transforme churn em uma pergunta verificável
“Qual cliente vai sair?” é uma pergunta incompleta. Para um serviço por assinatura, um alvo possível é: entre os contratos ativos na data de referência, quais terão cancelamento efetivado nos próximos trinta dias? Esse prazo é uma escolha ilustrativa, não uma recomendação universal. Ele precisa caber no tempo que a equipe tem para agir.
Documente a diferença entre pedido de cancelamento, cancelamento efetivo, inadimplência, pausa e migração de plano. Misturar eventos pode produzir uma lista que ninguém sabe interpretar. Uma falha de pagamento demanda um tratamento diferente de uma insatisfação com o produto, mesmo que ambas terminem em perda de receita.
Defina a unidade de análise: pessoa, conta, contrato ou estabelecimento. Se uma empresa possui várias filiais, cancelar uma delas pode representar redução de contrato, sem encerrar a relação comercial. A regra precisa refletir o objetivo operacional antes de qualquer treinamento.
Em seguida, escolha uma janela de observação para construir as variáveis e uma janela futura para observar o resultado. Contas cujo horizonte futuro ainda não terminou não devem receber automaticamente o rótulo “não cancelou”. Mantenha esses exemplos fora da avaliação até que exista tempo suficiente para conhecer o desfecho.
Escreva um contrato de dados com a definição do alvo, população elegível, horário de corte e exclusões. Esse documento evita que vendas, dados e atendimento usem números aparentemente iguais para perguntas diferentes. Revise-o quando o negócio mudar suas regras de contratação.
2. Construa uma base que respeite o tempo
Para cada data de referência, reúna apenas informações que estariam disponíveis naquele momento: uso do serviço, tempo de relacionamento, histórico de pagamentos e chamados anteriores. Não basta verificar a data do evento. Um dado que chegou atrasado ao sistema também pode ter sido desconhecido quando a previsão seria feita.
O vazamento de informação ocorre quando o treinamento usa algo indisponível no momento da previsão. A documentação do scikit-learn sobre erros comuns explica esse problema e recomenda separar treino e teste antes de ajustar transformações. No churn, uma nota de encerramento pode tornar o teste excelente e a operação inútil.
Crie fotografias históricas da base, com horário de corte e versão das consultas. Uma variável como “número de chamados abertos” deve refletir o passado, não o status atual recuperado meses depois. Registre também ausência de dados: não ter um chamado é diferente de ter um chamado cujo conteúdo não foi coletado.
Separe períodos de treinamento, validação e teste. Ajuste modelo e decisões no treinamento e na validação; reserve o teste para uma avaliação final. O TimeSeriesSplit ilustra separações ordenadas no tempo, mas uma base de clientes pode exigir cortes próprios por data, conta e janela de resultado.
Se a mesma conta aparece repetidamente, avalie a sobreposição entre amostras e horizontes. Deixe os resultados do treinamento maturarem antes do período simulado de produção. Quando o objetivo incluir clientes novos, produza também uma avaliação sem reaproveitar as mesmas contas entre conjuntos. O desenho do teste deve reproduzir a decisão real.
3. Use LLMs para extrair sinais, com evidências
Comece por uma taxonomia pequena: dificuldade de implantação, falha recorrente, dúvida de cobrança, necessidade não atendida e ausência de informação suficiente. Acrescente categorias somente quando a equipe souber interpretá-las e agir. “Sentimento negativo” sozinho costuma oferecer pouca orientação sobre qual providência tomar.
Peça ao modelo uma saída estruturada com categoria, trecho de evidência, identificador do chamado e indicação de ambiguidade. A instrução deve proibir inferências sobre fatos ausentes. Se o cliente escreve que está comparando alternativas, o sistema pode registrar essa fala; não deve transformá-la automaticamente em cancelamento confirmado.
Trate o texto recebido como dado, não como instrução ao sistema. Uma mensagem pode conter frases que tentam alterar o comportamento do modelo. Delimite o conteúdo analisado, valide o esquema de saída e rejeite campos inesperados. Uma resposta que não passa pela validação deve virar pendência ou ausência controlada, nunca uma categoria inventada para completar a tabela.
Monte uma amostra revisada por pessoas com critérios claros. Compare a extração da IA com essa referência, registre discordâncias e revise categorias difíceis. Avalie também a fidelidade dos trechos citados: a evidência precisa existir no documento correto. O guia para reduzir alucinações em IA detalha controles úteis para essa etapa.
Versione instrução, taxonomia, configuração e saída. Uma mudança do extrator altera as variáveis do modelo de churn. Antes de adotá-la, reavalie a cadeia completa. A escolha do componente linguístico pode seguir os critérios do guia de escolha de modelos, usando exemplos reais autorizados e a mesma referência de avaliação.
Reduza os dados enviados ao necessário para classificar o problema. Remova identificadores que não contribuam para a tarefa e controle o acesso aos textos originais. Consulte o guia de segurança e LGPD na implantação de IA para estruturar a discussão de governança com os responsáveis da empresa, antes de conectar históricos completos.
4. Compare modelos, calibre o risco e teste a ação
Construa três referências: uma regra operacional simples, um modelo com variáveis estruturadas e o mesmo tipo de modelo acrescido dos sinais extraídos dos textos. Essa comparação mostra se a complexidade adicional ajuda na decisão. Mantenha iguais os cortes temporais e a população avaliada.
Um primeiro modelo pode ser uma regressão logística; depois, a equipe pode comparar alternativas. A escolha deve considerar desempenho, estabilidade e manutenção. Um modelo complexo que exige dados indisponíveis no horário da rotina não atende à operação, mesmo que tenha bom resultado no laboratório.
| Pergunta | Medida ou teste | Como usar |
|---|---|---|
| A fila contém clientes que cancelariam? | Precisão entre as contas priorizadas | Estimar qualidade da fila dentro da capacidade de atendimento |
| Quantas perdas a fila alcança? | Recall no mesmo corte | Entender o que fica fora da abordagem |
| Os riscos numéricos são confiáveis? | Curva de calibração | Comparar risco estimado com frequência observada |
| O LLM acrescenta informação? | Comparação com o modelo sem texto | Decidir se o custo adicional se justifica |
| A abordagem evita cancelamentos? | Experimento com grupo de comparação | Medir efeito da ação, não apenas correlação |
A documentação de métricas do scikit-learn descreve precisão e recall. Examine as duas medidas no tamanho de fila que a equipe consegue atender. Acurácia isolada pode esconder um sistema que quase sempre prevê permanência quando os cancelamentos são pouco frequentes.
Se o negócio vai tratar a saída como probabilidade, verifique a calibração em dados separados do ajuste. A documentação sobre calibração explica a relação entre probabilidades previstas e frequências observadas. Ordenar bem os clientes não garante que o número apresentado corresponda a um risco confiável.
Escolha o limiar de atuação na validação, considerando capacidade e custo do contato. Depois, avalie a política em um experimento controlado, quando viável, com alocação aleatória entre abordagem e comparação. Não interprete clientes que permaneceram após um contato como prova automática de sucesso: parte deles permaneceria de qualquer forma.
Na rotina, registre versão do modelo, data do cálculo, sinais utilizados, ação realizada e resultado maturado. Monitore atraso dos dados, categorias desconhecidas, mudança de perfil e desempenho por segmentos relevantes. Defina uma alternativa operacional para falhas, como retornar à regra simples já avaliada.
Exemplo: empresa de software para clínicas em Recife
Imagine uma empresa fictícia em Recife, Pernambuco, que oferece software de agendamento a clínicas. O atendimento recebe dúvidas de configuração, pedidos de integração e reclamações de cobrança. A equipe quer priorizar acompanhamento antes de uma renovação, sem tratar toda reclamação como intenção de saída.
No projeto ilustrativo, o alvo é cancelamento efetivado dentro do horizonte escolhido, entre contratos elegíveis. A base combina uso anterior, antiguidade e chamados disponíveis no corte. Mensagens recebidas depois desse momento ficam de fora, inclusive as que mencionam o cancelamento já decidido.
O extrator identifica uma dificuldade de configuração em um chamado e devolve o trecho correspondente. O modelo preditivo utiliza essa categoria junto com as demais variáveis. Na tela do atendimento, a pessoa responsável vê data, evidência e motivo de priorização, sem receber uma afirmação de que o cliente certamente sairá.
A equipe distingue risco de ação: clientes com dificuldade de implantação podem receber acompanhamento técnico; uma disputa de cobrança exige revisão do caso. Nenhuma categoria autoriza oferecer desconto automaticamente. Antes de ampliar o projeto, a empresa compara a fila híbrida com a referência sem textos e testa a abordagem com um grupo de comparação.
O caso não pressupõe redução de churn nem retorno financeiro. A decisão de continuar depende dos resultados observados, do custo de revisar os textos e da capacidade de executar a ação adequada. Um modelo útil precisa caber no trabalho do atendimento.
Erros comuns
Pedir ao LLM uma porcentagem de risco. Um número escrito em linguagem natural não equivale a uma probabilidade validada. Use um processo preditivo avaliado e deixe o componente linguístico organizar evidências.
Treinar com mensagens posteriores ao desfecho. Uma justificativa de cancelamento revela o que se pretende prever. Aplique o corte temporal antes de extrair os sinais dos textos.
Confundir correlação com causa. Uma categoria associada a churn não prova que ela causou a saída. Também não prova que removê-la evitará o cancelamento. Teste as intervenções separadamente.
Otimizar uma métrica que não cabe na rotina. Uma lista enorme pode aumentar a cobertura e ultrapassar a capacidade do time. Avalie o modelo no volume de contatos realmente executável.
Ignorar clientes sem conversas. Ausência de texto não significa satisfação. Mantenha um caminho de previsão com variáveis estruturadas e monitore diferenças entre contas com e sem histórico de atendimento.
Perguntas frequentes
Preciso de muitos dados para começar?
Não existe uma quantidade universal. Você precisa de histórico confiável, desfechos suficientes e períodos de avaliação representativos. Se a base ainda for pequena, comece com uma regra explícita e organize a coleta antes de aumentar a complexidade.
O LLM deve receber todas as conversas?
Não por padrão. Selecione apenas conteúdos pertinentes e anteriores ao corte, com acesso autorizado. Reduza informações pessoais desnecessárias e registre quais documentos sustentaram cada sinal utilizado.
Posso usar o mesmo cliente no treino e no teste?
Depende da pergunta operacional. Prever novamente contas existentes difere de prever contas novas. Mesmo quando houver repetição, respeite o tempo, a maturação dos resultados e a sobreposição das janelas. Declare a limitação do teste.
Uma boa previsão garante retenção?
Não. A previsão identifica associação com uma saída futura. Retenção depende de uma intervenção útil e executável. Compare abordagens e acompanhe custos, cancelamentos e possíveis efeitos indesejados.
Quando devo atualizar o sistema?
Quando a avaliação indicar perda de qualidade ou quando mudarem produto, dados ou política comercial. Reavalie também após alterar a extração de textos. Atualização deve incluir validação e possibilidade de retorno à versão anterior.
