Entendendo similaridade na prática
Quando você vê "similar" em documentação técnica ou num erro de compilação, geralmente não se trata de sinônimo no sentido dicionarista. Significa que duas coisas compartilham atributos suficientes para serem intercambiáveis em um contexto específico, mas não idênticas. A barreira entre "similar" e "igual" é onde a maioria dos problemas acontece. Na minha experiência com migração de código legado, já vi desenvolvedores trocarem variáveis por acharem que eram similares quando na verdade tinham estruturas de memória diferentes. O compilador não reclamou porque os tipos eram compatíveis superficialmente, mas o runtime executou valores errados em produção por três dias até alguém notar que o campo `status` era `int` em um caso e `enum` no outro. A similaridade enganosa custou uma madrugada inteira de debugging.
O que significa similar em contextos diferentes
Em programação, similaridade pode significar coisas radicalmente distintas dependendo da linguagem. Em JavaScript, dois objetos com as mesmas propriedades e valores não são similares no sentido de identidade — o operador `===` devolve `false` porque compara referências, não conteúdo. Já em Python, o método `__eq__` pode ser sobrescrito para definir o que similaridade significa para aquela classe específica. Em bancos de dados, a cláusula `SIMILAR TO` no PostgreSQL segue a regex SQL-99, que é diferente do comportamento padrão do `LIKE`. Muita gente usa sem saber e acaba com consultas que parecem certas mas filtram resultados inesperados porque `_` e `%` têm semantics diferentes nesse contexto.
Na área de machine learning, similaridade é pura matemática de espaço vetorial. Distância cosseno, Jaccard, Euclidiana — cada métrica define "similar" de forma diferente e escolher a errada pra seu caso de uso gera modelos que parecem funcionar em teste mas falham em produção. Já configurei um sistema de recomendação usando distância Euclidiana quando o dado era sparse e disperso, e a qualidade das sugestões era péssima. Troquei para cosseno e o recall melhorou de 12% pra 67% em uma tarde.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Como testar similaridade corretamente
A primeira coisa é definir qual dimensão da similaridade importa pro seu problema. Não adianta escrever código de comparação sem saber se você está mediando equivalência estrutural, semântica ou comportamental. Essas três camadas frequentemente se sobrepõem mas raramente são idênticas. Para comparação estrutural em código, use bibliotecas de diff especializados ao invés de escrever seu próprio comparador. Ferramentas como `deepdiff` em Python ou bibliotecas de snapshot testing em JavaScript detectam diferenças que comparações superficiais ignoram — tipos aninhados, ordem de chaves, valores nulos versus indefinidos.
No PostgreSQL, se você precisa de similaridade textual real e não apenas pattern matching, instale a extensão `fuzzystrmatch` e use as funções `soundex`, `levenshtein` ou `metaphone`. Elas implementam algoritmos reais de similaridade string que levam em conta transposições, substituições e inserções de caracteres, não apenas correspondência de padrões. Umapegar-se a uma única definição de similaridade é armadilha comum. Em sistemas distribuídos, dois registros podem ser similares o suficiente pra merge mas diferentes o bastante pra causar divergência de consenso. O consenso eventual funciona até aparecer aquele edge case onde a similaridade percebida não corresponde à similaridade real dos dados.
O que significa similar, no final das contas, depende do threshold que você estabelece. E esse threshold nunca é universal — muda conforme a tolerância do domínio, a qualidade dos dados e o custo do erro. Defina explicitamente qual semelhança você está buscando, teste nos extremos, e documente o critério. Sem isso, você só tem intuição, e intuição em sistema técnico é o que gera bugs silenciosos.
