Quais São As Semelhanças

Um guia prático sobre como identificar e documentar semelhanças entre sistemas, códigos ou processos

Trabalhar com análise de similaridade não é sobre achar pontos em comum de forma genérica. É sobre mapear onde duas coisas se sobrepõem de maneira funcional, técnica ou conceitual, e depois decidir se essa convergência é útil ou apenas ruído. A maioria dos analistas pega ferramentas comodiffrast ou difflib no Python e acha que o trabalho tá pronto. Não tá. A pergunta "quais são as semelhanças" só faz sentido se você definir o critério de comparação antes. Comparar dois arquivos de configuração com hash MD5 te diz se são idênticos. Não te diz se têm a mesma intenção, a mesma estrutura lógica, ou se um é versão mais antiga do outro. Isso é o erro número 1 que eu vejo em reviews de código e em auditorias de migration. No meu trabalho, já peguei dois microserviços escritos em linguagens diferentes — um em Go, outro em Node.js — que pareciam completamente distintos na superfície. A análise estrutural com abstração de AST revelou que ambos implementavam o mesmo padrão de retry exponencial com backoff jitter, mas com tolerâncias diferentes. O serviço em Go retryava 3 vezes com max delay de 2s. O em Node.retryava 5 vezes com max delay de 8s. A semelhança estrutural era clara, mas o comportamento em produção era radicalmente diferente em cenários de carga alta. Documentar apenas "são similares" teria sido uma armadilha.

Método de comparação que funciona na prática

A abordagem que eu uso envolve três camadas, na seguinte ordem: Antes de qualquer comparação, normalise os dados. Para código, remova comentários, whitespace redundante e normalize imports. Para textos ou documentos, normalize case, remova stop words e aplique stemming ou lematização. Para configs e schemas, normalize a ordem das chaves e expanda inherits. Sem normalização, métricas de similaridade dão resultados distorcidos porque capturam ruído de formatação em vez de diferença real de conteúdo. Um detalhe que poucos consideram: a normalização pode esconder semelhanças importantes. Se você normalizar case em diffs de código, vai perder distinções entre variáveis camelCase e SCREAMING_SNAKE_CASE que podem indicar convenções diferentes de namespace ou escopo. Decida antes qual nível de granularidade importa pro seu caso.

Camada 2: Métricas de similaridade apropriadas ao domínio

Não existe métrica universal. Cada tipo de dado pede uma abordagem diferente: Para código-fonte: Use tree-sitter ou AST-based diff para capturar similaridade estrutural, não apenas textual. O LCS (Longest Common Subsequence) funciona bem para diffs lineares, mas falha catastroficamente quando a reestruturação é profunda — como renomear uma classe inteira e mudar sua hierarquia. Nesse caso, a similaridade por AST edit distance ou por graph matching é muito mais reveladora, ainda que computacionalmente mais cara. Para texto natural: Cosine similarity com TF-IDF é o ponto de partida padrão. Mas para documentos técnicos ou legais, a similaridade semântica com embeddings (sentence-transformers, por exemplo) captura relações que o TF-IDF puro perde completamente. O trade-off é custo computacional e necessidade de modelo pré-treinado. Em benchmarks internos, embeddings melhoraram a recuperação de documentos similares de cerca de 62% para 89% em corpus jurídico, mas aumentaram o tempo de processamento em aproximadamente 7x.

Para schemas e estruturas de dados: Use comparação baseada em propriedades estruturais — tipos, constraints, relações. Ferramentas como JSON Schema diff ou even custom logic que compara hierarquias de fields funcionam melhor que diff literal. Para logs e traces: Agrupamento por pattern ou clustering de sequência de eventos é mais útil que comparar linhas individualmente. Fingerprinting de request IDs e correlação por timestamp window resolve o problema de ruído temporal.

Camada 3: Validação contextual e ponderação

Aqui é onde a maioria para e entrega um score numérico como se fosse verdado. Score de similaridade sem contexto é inútil. Você precisa ponderar quais aspects da semelhança importam para o objetivo da análise. Se o objetivo é detectar plágio ou cópia, a similaridade textual bruta tem peso maior. Se o objetivo é refatoração ou migration, a similaridade funcional e de comportamento tem peso maior. Se o objetivo é segurança, a similaridade de vulnerabilidades conhecidas (via CVSS matching ou advisory cross-reference) é o que importa, e a similaridade geral do código pode ser irrelevante. No caso dos microserviços que citei acima, a validação contextual mostrou que a semelhança estrutural era sobreposta por diferenças comportamentais críticas. A decisão foi tratar os serviços como distintos em documentação e runbooks, apesar da similaridade algorítmica, porque qualquer engenheiro assumindo que se comportavam igual quebraria produção durante um failover em cascata.

Falhas comuns e where o método quebra

Existem cenários onde a análise de similaridade simplesmente não funciona bem, e é importante saber antes de confiar nos resultados: Dados muito pequenos: Comparar dois blocos de 10 linhas ou menos gera scores de similaridade instáveis. O ruído domina o sinal. Nesses casos, diff visual direto ou análise qualitativa supera qualquer métrica automática. Polimorfismo estrutural: Dois sistemas que resolvem o mesmo problema com abordagens fundamentalmente diferentes podem ter similaridade funcional alta mas similaridade estrutural próxima de zero. Um cache LRU com batching e outro com write-through invalidation podem ter o mesmo throughput em load test, mas parecem completamente diferentes em código. A dependência da métrica define o que você vê.

Versionamento e drift gradual: Quando dois projetos evoluem separadamente a partir de uma base comum, a similaridade decai de forma não-linear. Nos primeiros 6-12 meses de divergence, a similaridade estrutural permanece alta mesmo com mudanças substantivas. Depois desse período, mudanças incrementais acumuladas tornam a similaridade global baixa, mas pontos de divergência crítica ficam escondidos no ruído. Isso é particularmente perigoso em forks de código aberto onde segurança depende de patch. Vieses de normalização: Como mencionado, normalização excessiva apaga diferenças importantes. Normalização insuficiente cria falsos positivos de dissimilaridade. O ajuste fino dessa al depende de validar contra um gold standard conhecido — um conjunto de pares com similaridade documentada manualmente — antes de confiar em automação.

Uma ferramenta que eu recomendo e uma alternativa quando ela não serve

Para código em Python, python-diff e bibliotecas baseadas em tree-sitter como semgrep para matching semântico são sólidos. Para texto, sentence-transformers com langchain ou chroma para embedding-based similarity search é eficiente. Para arquivos binários ou grandes volumes, paradedb ou elasticsearch com analysis plugins especializados entregam throughput adequado. Quando esses tools falham — tipicamente em casos de polimorfismo estrutural ou dados muito heterogêneos — a solução é combinar múltiplas métricas com weight scoring customizado e validação manual em sample. Eu criei um pipeline interno que roda TF-IDF cosine, AST structural match e behavioral fingerprinting em parallel, depois aplica pesos ajustáveis por caso de uso. O resultado não é perfeito, mas reduz drasticamente falsos positivos e falsos negativos comparado a usar qualquer métrica isoladamente. O processo completo, desde coleta de dados até reporte final, leva em média 45 minutos a 2 horas dependendo da complexidade e do volume. A maior variável é o tempo de normalização e limpeza, não o cálculo das métricas em si.

Limitações honestas

Nenhuma ferramenta de similaridade automatizada substitui julgamento humano em contextos críticos. Scores altos não significam que duas coisas são intercambiáveis. Scores baixos não significam que são incompatíveis. O valor real está em usar a análise de similaridade como lente, não como veredito final. Documente os critérios usados, os pesos aplicados e os casos de validação manual. Quem ler seu reporte precisa conseguir reproduzir ou contestar suas conclusões.