o problema
A web repete a si mesma. O mesmo texto aparece em mirror, em agregador, em versão para impressão, em url com parâmetro de sessão, em página idêntica à anterior exceto pelo anúncio lateral, pelo contador de visitas e pela data no rodapé. Para quem lê, isso é ruído. Para quem baixa a web inteira, é conta: banda gasta, disco ocupado, índice inflado e um crawler que volta a buscar aquilo que já tem guardado em outra url.
Hash exato não fecha o buraco. Um digest do conteúdo só bate quando os bytes batem, e basta um timestamp no rodapé para dois documentos indistinguíveis virarem chaves sem relação nenhuma. A alternativa óbvia — comparar o novo documento com os que já foram coletados — é quadrática, e a escala de um crawler transforma isso em não-solução: com bilhões de páginas na base, não existe orçamento para nenhuma varredura completa por página nova. Pior, a decisão é online. Ela precisa acontecer no momento da coleta, com poucos microssegundos por documento, ou o crawler para de crawlear e vira um job de batch.
a ideia
O material que chegou aqui foi só o registro bibliográfico do trabalho: título, os três autores, e a publicação no WWW 2007, em Banff. O resumo não veio junto. Então este verbete não descreve o método, não cita resultado e não reproduz tabela — nada disso foi lido. Quem quiser o mecanismo precisa abrir o PDF.
O que o título sustenta é o enquadramento, e ele já vale alguma coisa. “For web crawling” não é decoração: é a restrição que define o problema. Detecção de quase-duplicata existe em vários contextos — plágio, deduplicação de corpus, casamento de registros — e cada contexto compra um trade-off diferente. Preso ao crawl, o detector herda três exigências ao mesmo tempo: decidir por documento, decidir rápido e decidir contra um corpus que não cabe na memória de uma máquina. É um problema de vizinho mais próximo sob limiar de similaridade, com o custo concentrado na etapa de gerar candidatos, não na de comparar dois textos.
o que isso custou
Sem o texto, as limitações declaradas pelos autores não estão disponíveis, e não vou inventá-las. O que dá para dizer é o que a classe de problema cobra de qualquer solução.
O limiar é arbitrário e é ele que manda. Duas páginas com 95% de conteúdo comum podem ser o mesmo artigo em dois mirrors ou dois produtos diferentes que compartilham o mesmo template de e-commerce. Nenhuma medida de similaridade textual separa esses dois casos, então todo sistema desses erra nos dois sentidos: descarta página legítima e mantém lixo duplicado. E os erros não custam igual. Falso positivo apaga conteúdo que talvez fosse único no índice inteiro; falso negativo só gasta disco. Um sistema calibrado para não perder nada mantém mais duplicata do que gostaria.
Existe ainda o custo de manutenção que o paper não pode resolver: a web muda de forma. Template, boilerplate de navegação e injeção de anúncio evoluem, e o que conta como “diferença irrelevante” em 2007 não é o mesmo que conta hoje. Um detector de quase-duplicata é infraestrutura viva, não um algoritmo que se instala e esquece.
onde isso aparece hoje
O problema não saiu de moda; mudou de dono. Ele sustenta a limpeza de corpus de treino, onde deduplicação virou etapa padrão antes de treinar modelo de linguagem, e sustenta busca de produto, onde catálogos com o mesmo item repetido por vários vendedores precisam colapsar em uma linha.
No acervo, o vizinho mais próximo é do mesmo ano: Scaling Up All Pairs Similarity Search ataca a mesma dificuldade central, achar pares parecidos sem comparar todos contra todos. A estratégia de reduzir candidatos antes de medir aparece explícita em Scalable blocking for very large databases, e a versão moderna do mesmo problema, agora com texto curto e embedding no lugar de documento, está em Near-duplicate Question Detection. Para o contexto de crawler que dá nome ao paper, The Anatomy of a Large-Scale Hypertextual Web Search Engine mostra o sistema em que essa decisão precisa caber.