tem uma música do Carlinhos Vergueiro chamada “Procotolo” que ficou um pouco mais famosa na interpretação de artistas como Ana Carolina e Lúdica Música, cuja letra é assim
É o Procotolo
É a Cardeneta
É a Falculdade
É o Estaltuto
É o Fenonemo
É um Pogresso
E é Sempre um crima
E aí vareia
É a largatixa
Que o pobrema
Essa é que é a Questã
Essa é que é a Questã
Quanto menas vezes falar dela é melhor
Essa é que é a Questã
Essa é que é a Questã
Quanto menas vezes falar dela é melhor
Com sastifação.
Antes de mais nada, deixe-me contar que tive muita dificuldade em achar esta letra no google porque, a cada palavra que eu escrevia errado, ele me corrigia
Essa fantástica letra tem tudo a ver com um probleminha que aconteceu uns dias atrás com a minha namorada (eu gosto de chamar a minha mulher de namorada). No trabalho dela, é comum enviar mala direta para diversas pessoas e instituições.
Muitas vezes, essas malas diretas são fundidas a partir de várias fontes: listas adquiridas de empresas especializadas (você pode comprar por exemplo listas de operadoras de cartão de crédito, do CDL, tudo bem segmentado e nada barato…), nomes e endereços das pessoas que preenchem as fichas de avaliação dos eventos, gente cadastrada no CRM da empresa, etc etc etc.
Como vocês podem imaginar, um monte de informação dos mesmos segmentos de público acabam gerando duplicatas, afinal, poucos conferem ANTES de inserir.
Para listas muito grandes, esse custo começa a se fazer visível. Aí você cai na situação de pedir para a pessoa do suporte técnico localizar para você ONDE E QUAIS são estas duplicatas. Só que a maioria das pessoas do suporte técnico vai tentar resolver isso com queries SQL, e como as queries SQL não são exatamente a coisa mais bem uniformizada do mundo, vai depender do fabricante do seu banco de dados se você tem como fazer busca aproximada em texto ou não.
Uma forma de tentar minimizar este problema é usar algum tipo de medida de similaridade no seu texto. Embora possa parecer para alguns um bicho de sete cabeças, é algo que surpreendentemente se encontra pronto por aí.
Uma das primeiras formas de resolver isso foi através do SOUNDEX, que são técnicas que medem a semelhança entre palavras baseado em sua fonética, ou seja, dos sons dela. Ainda hoje, é possível encontrar bons sistemas onde, se uma pessoa digita uma palavra errada, o sistema sugere palavras com sons aproximados.
Exemplo prático: você vive num país de terceiro mundo onde grande parte da população é semi-analfabeta e sua interface tem que ser boa o suficiente para entender o que uma pessoa de pouca instrução está digitando (isso SE ela estiver digitando). Lembre-se: a boa interface é feita para PESSOAS usarem.
Mas SOUNDEX não foi a solução que eu usei para ajudar a minha namorada. Se você lida com JAVA, então você ama o projeto Jakarta e já usou o Jakarta Commons Lang prá alguma coisa. Não foi diferente. Escondido dentro do StringUtils, você vai encontrar um obscuro método chamado getLevenshteinDistance().
Essa “distância” mede o quão diferente uma palavra difere de outra. E segundo este excelente livro do Berthier e do Baeza-Yates, na seção 6.3.4, você pode ler que esta medida é superior ao SOUNDEX para detectar erros de sintaxe, então não há porque não tentar :-).
Mais especificamente, ele mede quantas modificações são necessárias para se transformar uma palavra na outra. Por exemplo, de “joão” prá “joao”, basta trocar o “ã” pelo “a”, então a distância é 1. Se fosse “joão” para “xoao”, seria 2. Se fossem iguais, a distância seria zero. Então, quanto mais próximo de zero, mais semelhantes.
Só que a distância sozinha não serve porque o impacto de 1 ou 2 letras em palavras menores é maior do que em palavras (vamos assumir que espaços são parte das palavras aqui) grandes, de 20, 30 letras. A chance de 2 letras serem um erro ortográfico numa palavra grande é maior que numa palavra pequena. Não é uma verdade absoluta, é um pressuposto.
Uma forma muito simples de compensar isso (não é a melhor, mas é simples, e simples geralmente é bom) é dividir essa distância pelo tamanho da palavra, o que vai te dar um índice de densidade de diferenças ortográficas entre duas linhas.
Você vai cair em vários problemas típicos destas coisas “inexatas” como por exemplo
- como você sabe QUAL o melhor valor desse “índice de densidade” para separar os erros dos não erros? - no caso, eu tentei o olhômetro mesmo. Os pares selecionados parecem ser os errados mesmo?. Nem sempre é fácil assim.
- você vai ter dois tipos de erro: as duplicatas que o sistema não achou (as piores) e os pares que o sistema achou que eram duplicatas, que eram parecidas, mas que não eram duplicatas (as menos piores). Novamente, eu estava fazendo um favor para a minha namorada, então ela sabe que há uma margem de erro aí.
Porém, diante da situação de ter que triar manualmente uma lista de cerca de 6000 endereços, meu programinha, que gera uma lista de “pares suspeitos”, já facilita um pouquinho a vida dela. E como o conjunto de dados dela tem cerca de 22% de linhas duplicadas, nessa brincadeira, já foi uma economia de impressão e envio de cerca de 1200 folders. Não está ruim(*).
E o melhor de tudo, claro, o programinha, feito em JAVA, tem cerca de 50 linhas, levou 10 minutos para codificar e 15 minutos prá rodar.
Tente você mesmo(a), experimente procurar livros do “Paolo Coelho” nas lojas da web e veja quais lojas querem vender e quais querem te mandar de volta pro seu professor de Português porque você não é digno o suficiente prá comprar na mão deles
* Só este mês, minha namorada deve enviar mala direta para cerca de 40.000 endereços ao custo de R$ 0,80 por folheto enviado. 22% disso corresponde a R$ 7000. Isso já paga pelo menos a cerveja. ;-). Olha como este blog é bom!