Para deduplicar cadastros de clientes com IA, separe duas decisões: encontrar registros parecidos e confirmar que representam a mesma pessoa. Use regras para normalizar os campos, um mecanismo de busca para sugerir pares e revisão humana para os conflitos. A união definitiva precisa preservar o histórico de cada origem e permitir desfazer a operação.
A IA pode ajudar a interpretar abreviações e explicar divergências, mas semelhança de nome não comprova identidade. Uma loja que junta duas clientes chamadas Ana Souza pode misturar pedidos, endereços e preferências de contato. O método proposto abaixo começa em uma cópia da base e trata a fusão como uma alteração de cadastro com evidências, responsável e registro de execução.
Resumo rápido
- Guarde o identificador original e a origem de cada cadastro antes de qualquer limpeza.
- Normalize texto, telefone e endereço em colunas auxiliares, sem apagar os valores recebidos.
- Use similaridade para buscar candidatos, nunca como prova isolada de identidade.
- Separe pares confirmados, diferentes e inconclusivos; não force uma decisão binária.
- Valide também grupos de registros, preserve restrições de contato e teste a reversão.
1. Defina o que significa um cadastro duplicado
Comece pela unidade que o sistema representa. Pessoa, domicílio, empresa e contato comercial são entidades diferentes. Duas pessoas podem morar no mesmo endereço; uma pessoa pode comprar para duas empresas. Uma filial pode ter endereço próprio e compartilhar o telefone da matriz. Se tudo vira um único tipo de cliente, qualquer algoritmo tende a misturar relações legítimas com duplicações.
Escreva uma regra operacional: dois registros de pessoa física são duplicados quando existem evidências suficientes de que pertencem ao mesmo titular, dentro da finalidade do cadastro. Uma semelhança apenas sugere investigação. Cadastros empresariais exigem política própria para matriz, filiais e representantes. Evite aplicar a mesma chave de comparação a todas essas situações.
Faça um inventário dos sistemas envolvidos: caixa, comércio eletrônico, atendimento e importações antigas. Para cada origem, registre responsável, campos disponíveis, frequência de atualização e significado dos identificadores. O código 215 no caixa não precisa representar o mesmo cliente que o código 215 na loja virtual. A chave de origem deve combinar sistema e identificador.
Escolha também o que será considerado sucesso. Além de reduzir duplicatas, o projeto precisa evitar fusões indevidas, manter pedidos acessíveis e conservar escolhas de comunicação. Uma base menor com históricos incorretos é uma piora. Descreva os testes de aceitação antes de escolher ferramenta ou escrever instruções para o modelo.
2. Prepare campos comparáveis sem destruir evidências
Crie uma área de trabalho com acesso restrito e cópia recuperável. Mantenha colunas como nome_original e nome_normalizado. A documentação do módulo unicodedata do Python descreve formas de normalização Unicode, úteis para tornar representações de caracteres comparáveis. Essa transformação não resolve identidade: ela apenas prepara texto para comparação.
No nome, trate espaços repetidos, capitalização e caracteres equivalentes. Se remover acentos para uma chave de busca, preserve a grafia original para exibição. Não retire automaticamente partículas ou sobrenomes em todas as etapas: isso pode transformar pessoas diferentes em uma chave muito genérica. Nome abreviado deve receber um sinal de informação incompleta, não uma expansão inventada.
Telefone precisa guardar país e contexto de preenchimento. Não acrescente um código de área apenas porque a loja atende determinada cidade. E-mail deve ser separado de espaços acidentais; regras especiais de um provedor não podem ser aplicadas a todos. Apagar pontos ou sufixos arbitrariamente pode criar colisões entre endereços válidos.
Para endereço, separe logradouro, número, complemento, município e CEP quando a origem permitir. Apartamento diferente não é detalhe descartável. Campos ausentes devem continuar ausentes. Evite transformar falta de informação em zero, texto vazio tratado como coincidência ou endereço presumido. Uma tabela de preparação ajuda a tornar essas escolhas verificáveis.
| Campo | Preparação proposta | Cuidado na comparação |
|---|---|---|
| Nome | Espaços e chave auxiliar sem acentos | Homônimos e nomes incompletos |
| Telefone | Separar dígitos, país e ramal informado | Número compartilhado ou reutilizado |
| Remover espaços externos e validar formato | Caixa postal familiar ou corporativa | |
| Endereço | Separar componentes disponíveis | Moradores diferentes no mesmo local |
| Documento | Preservar origem e validar estrutura | Formato válido não comprova titularidade |
3. Busque candidatos e limite o papel da IA
Comparar cada linha com todas as outras gera muitos pares irrelevantes. Uma alternativa é criar blocos de busca: mesmo e-mail informado, telefone coincidente ou combinação de município com parte do nome. Use mais de uma estratégia, porque uma única chave perde pessoas que mudaram de contato. Depois una os candidatos encontrados sem duplicar o próprio par.
Para nomes com erro de digitação, ferramentas determinísticas já podem ajudar. A extensão pg_trgm do PostgreSQL oferece funções de similaridade textual baseadas em trigramas. O resultado mede aproximação entre textos; não é uma probabilidade de que dois clientes sejam a mesma pessoa. Um nome comum pode obter uma comparação perfeita e ainda pertencer a titulares diferentes.
Reserve o modelo para pares em que interpretar abreviações realmente ajude. Envie apenas os campos necessários e peça uma saída limitada: decisão sugerida, evidências coincidentes, conflitos, informações ausentes e necessidade de revisão. O modelo não deve completar CPF, pesquisar pessoas na internet ou escolher o contato mais provável por intuição.
Uma instrução possível é: “Compare os dois registros somente com as evidências fornecidas. Retorne mesmo_cliente, diferentes ou inconclusivo. Liste conflitos sem tentar resolvê-los. Nomes parecidos, endereço compartilhado ou telefone isolado não bastam para confirmar identidade”. Essa é uma regra de trabalho proposta, que precisa ser testada na sua base.
O texto recebido do cadastro também pode conter instruções maliciosas ou observações indevidas. Trate todos os campos como dados, limite a saída a um esquema e valide os identificadores antes de aceitar a sugestão. Na primeira etapa, dê ao processo permissão de leitura e geração de propostas, sem poder alterar o sistema principal.
4. Revise decisões e execute uma união reversível
Monte uma amostra rotulada por pessoas que conhecem o cadastro. Inclua homônimos, famílias, mudança de endereço, telefone antigo, acentos e importações incompletas. Separe parte dos casos para avaliação final, sem reutilizá-los para ajustar as regras. Meça quantas propostas aceitas eram corretas e quantas duplicatas conhecidas ficaram de fora.
Não escolha um limiar universal porque parece alto. Ajuste a política ao custo do erro e à qualidade dos campos. A fila de revisão deve mostrar valores originais, origem, datas e conflitos lado a lado. Para organizar casos inconclusivos, veja também o guia sobre classificadores com opção de não responder. Abster-se mantém a dúvida visível.
Revise os grupos inteiros antes da execução. Se A parece B e B parece C, isso não garante que A e C sejam a mesma pessoa. Um telefone familiar pode conectar vários titulares. Bloqueie grupos com evidências contraditórias e peça análise específica, em vez de propagar automaticamente todas as relações sugeridas.
Defina uma política por campo para escolher os valores do cadastro principal. A informação mais recente pode ser um erro recém-importado; a mais antiga pode estar desatualizada. Prefira origem confiável e confirmação documentada. Preserve os valores anteriores e o mapa entre registros antigos e novo identificador. Não some saldos, benefícios ou limites comerciais sem regra própria.
Execute o lote em transação quando a arquitetura permitir e confira se houve atualização concorrente desde a aprovação. A documentação de restrições do PostgreSQL explica mecanismos como chaves primárias, referências e unicidade. Eles ajudam a manter relações consistentes, mas não substituem a validação da identidade. O guia de concorrência de agentes no CRM aprofunda conflitos de escrita.
Exemplo: uma loja de utilidades em Campinas
Imagine, em um cenário ilustrativo, uma loja de Campinas que reúne cadastros do balcão e do site. Ela encontra “Mariana Alves”, com compra retirada na loja, e “Mariana A. Alves”, com entrega em apartamento. O telefone coincide, mas o nome completo está ausente na segunda origem. A proposta fica inconclusiva até que a equipe consulte evidências adicionais permitidas.
Em outro grupo, duas pessoas têm o mesmo sobrenome, endereço e telefone residencial. Uma comprou como presente para a outra. A equipe mantém os clientes separados e registra a relação familiar apenas se houver finalidade e procedimento adequados. Não é necessário fundir pessoas para reconhecer que compartilham um ponto de contato.
Quando um par é confirmado por procedimento interno, a loja conserva o identificador de cada pedido e cria o vínculo com o cadastro principal. Uma preferência de não receber campanhas não desaparece porque o outro registro estava sem preenchimento. Divergências de autorização de contato seguem para o responsável, em vez de virar uma permissão por padrão.
Antes do primeiro lote real, a equipe simula a fusão e a reversão em ambiente de teste. Confere pedidos, endereços, etiquetas de atendimento e exportação para o sistema financeiro. O exercício não promete ganho percentual: ele mostra se o desenho suporta os fluxos que a loja realmente utiliza.
Erros comuns
Usar a confiança escrita pelo modelo como garantia. Uma porcentagem produzida na resposta não demonstra calibração. Compare decisões com casos revisados e observe em quais tipos de registro o processo erra.
Apagar a origem depois da limpeza. Sem rastreabilidade, fica difícil responder por que um endereço mudou ou reconstruir o atendimento anterior. Guarde o mapa de fusão e teste como recuperar as relações antigas.
Enviar a base inteira para um serviço externo. Separe necessidade técnica de conveniência. A LGPD estabelece princípios como finalidade, necessidade e qualidade dos dados. A definição da base legal, das condições de compartilhamento e da retenção depende do contexto; a deduplicação não dispensa essa análise.
Corrigir o passado e manter a entrada defeituosa. Ajuste também formulários, validação de origem e busca antes de criar novo cliente. Sem isso, uma nova importação pode recriar as duplicatas removidas. Registre a versão da regra e o lote para distinguir entradas novas de casos já analisados.
Perguntas frequentes
É obrigatório usar IA para deduplicar?
Não. Coincidências exatas e regras verificáveis resolvem parte dos casos. A IA merece entrar quando a interpretação de texto acrescenta valor comprovado. Compare uma solução simples com a proposta assistida antes de ampliar o processo.
Mesmo CPF significa união automática?
Não necessariamente. Um documento pode ter sido copiado ou informado incorretamente. Estrutura válida e coincidência são evidências, mas conflitos relevantes pedem investigação. Evite coletar novos documentos apenas para facilitar o algoritmo sem avaliar a necessidade.
Como tratar quem mudou de telefone?
Mantenha histórico com datas e origem, e combine evidências adicionais. Um telefone diferente não prova que são pessoas diferentes, assim como um telefone igual não prova identidade. A política deve aceitar mudanças sem transformar ausência de confirmação em certeza.
O que fazer quando a equipe discorda?
Marque o caso como inconclusivo, registre o motivo e encaminhe ao responsável definido. Use as divergências para melhorar o manual de revisão. Não escolha a maioria automaticamente em decisões que possam misturar dados de titulares distintos.
Quando liberar fusões sem revisão individual?
Somente depois de validar critérios específicos, avaliar o risco e demonstrar reversão e monitoramento. Comece por situações restritas e auditáveis. Uma mudança de origem ou formulário exige reavaliar o desempenho antes de manter a mesma automação.
