paint-brush
Melhore a detecção precoce de falhas (EFD) em Web Scraping com dados de referênciapor@hackerclftuaqw60000356o581zc4bj
261 leituras

Melhore a detecção precoce de falhas (EFD) em Web Scraping com dados de referência

por DBQ-015m2023/05/11
Read on Terminal Reader

Muito longo; Para ler

A raspagem é um processo de calibração contínua de uma ferramenta que mede um objeto em constante mudança. A garantia de qualidade visa detectar o possível problema o mais cedo possível - *antes que os SLAs sejam violados*. Para fazer isso, precisamos aumentar a taxa de detecção de falha (FDR) e reduzir a taxa de falso alarme (FAR)
featured image - Melhore a detecção precoce de falhas (EFD) em Web Scraping com dados de referência
DBQ-01 HackerNoon profile picture
0-item
1-item

A questão da “completude”

Um dos problemas mais comuns na garantia de qualidade (QA) para web scraping, ainda que desarmante em sua trivialidade, é garantir que o scraper colete todos os itens do site de destino.


É um problema de calibrar continuamente uma ferramenta que mede um objeto em constante mudança.

Por que isso acontece?

Do mais fácil de detectar ao mais desafiador (o que não significa fácil de resolver...), temos as seguintes causas de coleta de dados incompleta:


  • o raspador é bloqueado por sistemas anti-bot
  • o raspador se perde nas versões de teste A/B do site
  • o raspador é limitado pelos limites de paginação do site/API
  • o raspador está ignorando partes do site (às vezes criado depois que o raspador foi projetado)

Como resultado, temos uma coleta de dados parcial.

Detecção Precoce de Falha

A maioria dos casos de uso de web scraping tem Acordos de Nível de Serviço (SLAs) que podem resultar em cláusulas de penalidade. A garantia de qualidade visa detectar o possível problema o mais cedo possível, antes que os SLAs sejam violados .


Para isso, precisamos aumentar a Taxa de Detecção de Falha (FDR) e reduzir a Taxa de Falso Alarme (FAR). Com uma cereja no topo: mantendo os custos baixos .

Como detectar falhas

Análise de série temporal

Podemos monitorar a contagem de itens ao longo do tempo e acionar um alerta quando isso cair. É um bom ponto de partida, mas embora eficaz com mudanças repentinas (ou seja, uma queda de 50%), é menos funcional quando as variações são incrementais, gerando muitos alarmes falsos (FAR) ou falhando na detecção de erros.


Isso acontece porque:

  1. Os sites mudam rapidamente, especialmente quando grandes
  2. Não temos histórico em dados para entender tendências ou sazonalidades, o que permitiria aplicar algoritmos de séries temporais mais sofisticados.


A limitação mais crítica desse método é que ele não detecta itens ausentes se eles nunca foram capturados pelo raspador.


Exemplo

Um site de comércio eletrônico de moda pode ter uma categoria de “vendas” do site que só aparece durante os períodos oficiais de vendas. Se você construir seu raspador quando a seção não estiver lá, talvez nunca perceba que está perdendo os itens de venda.

Inspeção Manual (Ground Truth)

A inspeção manual oferece a maior confiança nos resultados, conforme discutido neste post . Ele fornece o chamado Ground Truth, e você pode comparar a contagem de itens coletada com a contagem de itens realizada manualmente.


Limitações:

  1. Dificilmente viável para sites grandes (você pode dizer com segurança quantos itens estão no site Allbirds , mas não tão confiável no Farfetch ).
  2. Dificilmente escalável: pode funcionar para alguns sites e raramente é feito, mas as coisas pioram rapidamente quando você precisa de vários sites grandes com alta frequência (leia a abordagem da Data Boutique sobre isso no artigo sobre testes de verdade ).


Isso manteria uma boa Taxa de Alarme Falso (FAR), mas não atingiria uma Taxa de Detecção de Falha (FDR) razoável, pois a frequência seria muito baixa.

Benchmarking Independente

Uma maneira inteligente de resolver isso é comparar seu resultado, em termos de contagem de itens, com uma coleção independente.


Para que essa abordagem funcione corretamente, os dados de referência devem ser:

  • Independente: para reduzir a chance de ser afetado pelos mesmos vieses de codificação
  • Custo-benefício: Ça va sans dire , a raspagem da web é cara o suficiente.


Uma coleta de dados independente é (quase) não correlacionada com sua própria coleta de dados: é correlacionada porque eles olham para o mesmo objeto, então uma falha do objeto observado realmente causaria uma perda em ambas as coletas de dados, mas por outro lado, eles re resultados de processos independentes, escritos por am mantidos por equipes diferentes, com técnicas diferentes.


O uso de uma fonte de dados altamente confiável aumenta fortemente a confiabilidade dos resultados.

Vamos supor que sua taxa de detecção de falhas (FDR) atual seja de 90%, o que significa que seu sistema pode detectar automaticamente 90% das vezes que um scraper coleta apenas parcialmente do site. Ou, em outros termos, seu conjunto de dados, quando publicado, contém 90% das vezes uma coleção completa.


Se assumirmos que os dados de referência são

a) tão capaz de detectar erros quanto os dados de produção

b) independente


O uso de dados externos para QA traria a Taxa de Detecção de Falha para 99% ( probabilidade da união de dois eventos ).

  1. Monitore a contagem total de itens em sua coleta de dados
  2. Compare-o com a contagem total de itens do mesmo site no Data Boutique
  3. Quando sua contagem é menor que o benchmark, você tem sua detecção de falha.


Por que a Data Boutique é uma escolha inteligente

Como os conjuntos de dados do Data Boutique incorporam inspeções manuais em seu processo de controle de qualidade, usar os dados do Data Boutique como referência é escalável , econômico e uma maneira confiável de melhorar o processo de garantia de qualidade (QA), mesmo quando você faz web-scraping internamente porque é muito provável que os conjuntos de dados publicados no Data Boutique excedam esses níveis de FDR.


  1. As duas estruturas de dados não precisam ser iguais: você está apenas comparando contagens de itens e não precisa da mesma estrutura, o que facilita muito a implementação. Apenas a granularidade deve ser comparável.

  2. Você pode selecionar a frequência do seu controle de qualidade que pode ser menor do que a frequência de sua aquisição (se você adquirir itens diariamente, poderá ter apenas benchmarks semanais, o que ainda ajudaria muito a melhorar os testes de qualidade dos dados.

  3. Como os dados do Data Boutique são fracionáveis (conforme explicado neste post ), o custo de compra desses dados pode ser muito baixo se comparado a todas as outras medidas de qualidade.


Em outras palavras, mesmo que a estrutura de dados do Data Boutique não seja uma combinação perfeita para o seu caso de uso, usá-la para o Teste de qualidade é uma abordagem muito eficiente.


Junte-se ao Projeto


A Data Boutique é uma comunidade para trocas de dados na web sustentáveis, éticas e de alta qualidade. Você pode navegar no catálogo atual e adicionar sua solicitação se um site não estiver listado. Salvar conjuntos de dados em sua lista de interesses permitirá que os vendedores dimensionem corretamente a demanda por conjuntos de dados e integrem a plataforma.

Mais informações sobre este projeto podem ser encontradas em nossos canais do Discord .



Publicado também na Data Boutique