O problema de ligar registros que nunca vão se parecer idênticos
Você já tentou fazer a correspondência correta entre duas bases de dados e percebeu que o mesmo nome de pessoa aparece de quinze formas diferentes? Já vi muita gente perder um dia inteiro com fuzzy matching manual porque ninguém explicou que o problema nunca é só o algoritmo. O processo de correspondência de registros, conhecido também como record linkage ou entity resolution, serve para identificar que dois registros distintos na verdade referem-se à mesma entidade do mundo real. Parece simples na teoria. Na prática, você vai lidar com erros de digitação, abreviações inconsistentes, nomes artísticos versus nomes legais, e campos que foram mapeados de formas completamente diferentes entre sistemas.
O que é e quando usar
Fazer a correspondência correta é o ato de determinar, com base em regras ou probabilidades, se dois registros representam a mesma pessoa, empresa, produto ou qualquer outra entidade. Você usa isso quando precisa unificar dados que vêm de fontes separadas: cadastro comercial e ERP, por exemplo, ou planilhas de vendas espalhadas por filiais que cada uma usou um formato próprio. O caso clássico é quando o sistema A salva "José da Silva Santos" e o sistema B salva "Jose S. Santos". Sem uma estratégia de matching, esses dois registros ficam duplicados e suas métricas ficam impossíveis de consolidar.
A abordagem prática: blocos de blocking
A técnica que funciona na maioria dos cenários reais se chama blocking. A ideia é simples e economiza muito tempo de processamento: você divide os registros em blocos menores com base em uma ou mais chaves aproximadas antes de comparar tudo com tudo. Comparar 50 mil registros entre si gera 1,25 bilhão de comparações. Com blocking por CEP mais sobrenome, você cai para algo em torno de 200 mil comparações. O ganho é absurdo. O fluxo básico funciona assim:
Primeiro, normalise os campos. Remova acentos, converta para maiúsculas, tire pontuação e espaços extras. Isso sozinho resolve boa parte dos falsos negativos que vejo as pessoas reclamando. Depois, defina os blocos. CEP, inicial do nome, truncated CPF, trimestre de data de nascimento. Escolha combinações que reduzam o espaço de busca sem eliminar possibilidades reais. Teste com uma amostra de 5 mil registros antes de rodar no dataset inteiro.
Em seguida, aplique a comparação dentro de cada bloco. Para campos nominais, use edit distance (Levenshtein) ou Jaro-Winkler. Para campos numéricos, defina tolerâncias: um CPF nunca terá variação, mas uma data de nascimento pode ter erro de um dia ou até um ano se for estimada. Por fim, Some os scores e defina um limiar. Registros acima do limiar são matches. Abaixo, não são. No meio do espectro, você tem a zona cinza que precisa de revisão manual.
Um problema que ninguém avisa antes
Na minha experiência, o erro mais caro não é configurar o algoritmo errado. É transitive matching. Imagine que o registro X corresponde ao Y, e o Y corresponde ao Z, mas X e Z não têm score alto o suficiente para serem ligados diretamente. Se você trata cada par isoladamente, cria clusters inconsistentes. A solução é aplicar transitividade: após o matching par a par, rode um algoritmo de componentes conexos (Union-Find) para agrupar todos os registros que estão conectados direta ou indiretamente. Outro problema que aparece frequentemente: campos com baixa cardinalidade destroem seu blocking. Se você bloqueia por "uf" por exemplo, você vai terminar com 27 blocos enormes que não reduzem nada o trabalho comparativo. Evite campos com poucas categorias distintas como chave de blocking. Prefira campos que realmente separram o conjunto em grupos pequenos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Ferramentas que eu uso
Para projetos pequenos até médios, o pacote dedupe do Python resolve a maior parte dos casos. Ele faz blocking automático, aprende pesos de campos a partir de amostras marcadas por você, e exporta os pares matchados. Leva cerca de 10 a 15 minutos para configurar um dataset de 50 mil registros se você já tiver os campos normalizados. Para volumes maiores ou ambientes empresariais, existem soluções comerciais como Semarchy, Informatica Match Center, ou Azure Purview Data Matching. Elas custam dinheiro, mas oferecem governança, linha de audição de decisões, e integração com pipelines existentes. O custo de manutenção manual de correspondência em bases de milhões de registros costuma superar o preço da licença em poucos meses.
Se o orçamento é zero e o volume é grande, dê uma olhada no Splink. Ele roda em SQL e Spark, lida bem com billions de comparações potenciais, e é usado por organizações de saúde e governo. O curva de aprendizado é mais íngreme, mas o resultado é sólido.
Pegadinhas comuns
A primeira pegadinha é confiar cegamente no limiar que a ferramenta sugere. Cada dataset tem uma distribuição de score única. O que é 0,85 de confiança para uma base pode ser 0,60 para outra. Sempre valide com uma amostra manual de pelo menos 200 pares, separando verdadeiros positivos, verdadeiros negativos, falsos positivos e falsos negativos. Calcule precision e recall. Se a precision estiver abaixo de 90%, ajuste os pesos dos campos ou refine o blocking. A segunda pegadinha é esquecer dados censura. Se você está fazendo correspondência de dados de saúde ou financeiros, campos sensíveis podem ter restrições de uso que impedem o matching direto. Nesse caso, considere técnicas de privacy-preserving record linkage como secure multi-party computation ou hashing com salt compartilhado.
A terceira, e talvez mais importante: não tente fazer correspondência perfeita. O objetivo é correspondência boa o suficiente para a decisão que depende dela. Se você está limpando um cadastro para marketing, 85% de recall com 92% de precision é aceitável. Se é para integração financeira, você precisa de 99% de precision, mesmo que isso signifique deixar muitos registros não ligados. Defina o requisito antes de escolher a ferramenta.
Quando a correspondência automática não funciona
Existem cenários onde o matching puramente baseado em dados falha. Nomes extremamente comuns como "John Smith" ou "Maria Silva" sem outros identificadores fortes criam ambiguidade intratável. Empresas com nomes genéricos e endereços similares em shopping center também geram falsos positivos crônicos. Nesses casos, a única saída é adicionar identificadores únicos: CNPJ, CPF, IE, ou IDs internos que já existem em pelo menos uma das bases. Sem um identificador único, você está essencialmente adivinhando com estatística. Se nenhuma combinação de campos textuais resolve o problema, considere coletar dados adicionais. Um telefone, um e-mail, ou até mesmo uma foto de perfil podem ser chaves muito mais poderosas do que qualquer algoritmo de similaridade textual. O trabalho de enriquecimento de dados muitas vezes paga o investimento em ferramentas de matching sozinho.
Fazer a correspondência correta exige paciência com a limpeza dos dados antes do matching, experimentação nos parâmetros de blocking, e validação humana constante. Não existe configuração universal que funcione para qualquer base. O que funciona para cadastro de clientes não funciona para cadastro de fornecedores, e vice-versa. Trate cada caso como um problema novo, coleto os dados, monte os blocos, valide com amostras, e ajuste até o recall e precision atendem ao requisito de negócio. O resto é detalhe de implementação.
