paint-brush
Mejore la detección temprana de fallas (EFD) en Web Scraping con datos de referenciapor@hackerclftuaqw60000356o581zc4bj
261 lecturas

Mejore la detección temprana de fallas (EFD) en Web Scraping con datos de referencia

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

Demasiado Largo; Para Leer

El raspado es un proceso de calibración continua de una herramienta que mide un objeto en constante cambio. El control de calidad tiene como objetivo detectar el problema potencial lo antes posible, *antes de que se infrinjan los SLA*. Para hacerlo, necesitamos aumentar la tasa de detección de fallas (FDR) y reducir la tasa de falsas alarmas (FAR)
featured image - Mejore la detección temprana de fallas (EFD) en Web Scraping con datos de referencia
DBQ-01 HackerNoon profile picture
0-item
1-item

El problema de la "integridad"

Uno de los problemas más comunes en el control de calidad (QA) para el web scraping, aunque desarmante en su trivialidad, es garantizar que el scraper recopile todos los elementos del sitio web de destino.


Es un problema de calibrar continuamente una herramienta que mide un objeto en constante cambio.

¿Por que sucede?

Desde las más fáciles de detectar hasta las más desafiantes (lo que no quiere decir fáciles de resolver...), tenemos las siguientes causas de recopilación de datos incompleta:


  • el raspador se bloquea por los sistemas anti-bot
  • el raspador se pierde en las versiones de prueba A/B del sitio web
  • el raspador está limitado por los límites de paginación del sitio web/API
  • el raspador pasa por alto partes del sitio web (a veces se crea después de que se diseñó el raspador)

Como resultado, tenemos una recopilación de datos parcial.

Detección temprana de fallas

La mayoría de los casos de uso de web scraping tienen acuerdos de nivel de servicio (SLA) que pueden dar lugar a cláusulas de penalización. El control de calidad tiene como objetivo detectar el problema potencial lo antes posible, antes de que se infrinjan los SLA .


Para hacerlo, necesitamos aumentar la tasa de detección de fallas (FDR) y reducir la tasa de falsas alarmas (FAR). Con una cereza en la parte superior: mantener los costos bajos .

Cómo detectar fallas

Análisis de series temporales

Podemos monitorear el conteo de elementos a lo largo del tiempo y activar una alerta cuando esto cae. Es un buen punto de partida, pero si bien es eficaz con cambios repentinos (es decir, una caída del 50 %), es menos funcional cuando las variaciones son incrementales, generando demasiadas falsas alarmas (FAR) o fallando en la detección de errores.


Esto sucede porque:

  1. Los sitios web cambian rápidamente, especialmente cuando son grandes
  2. No tenemos un historial de datos para comprender tendencias o estacionalidades, lo que permitiría aplicar algoritmos de series temporales más sofisticados.


La limitación más crítica de este método es que no detecta elementos faltantes si nunca han sido capturados por el raspador.


Ejemplo

Un sitio web de comercio electrónico de moda puede tener una categoría de "ventas" del sitio web que solo aparece durante los períodos de ventas oficiales. Si construye su raspador cuando la sección no está allí, es posible que nunca se dé cuenta de que le faltan los artículos de venta.

Inspección manual (Verdad del terreno)

La inspección manual brinda la mayor confianza en los resultados, como se explica en esta publicación . Proporciona lo que se conoce como Ground Truth, y puede comparar el recuento de elementos que recopiló con el recuento de elementos realizado manualmente.


Limitaciones:

  1. Difícilmente factible para sitios web grandes (puede saber de manera confiable cuántos elementos hay en el sitio web de Allbirds , pero no tan confiablemente en Farfetch ).
  2. Difícilmente escalable: puede funcionar para algunos sitios web, y rara vez se hace, pero las cosas se complican rápidamente cuando necesita varios sitios web grandes con una alta frecuencia (lea el enfoque de Data Boutique sobre esto en el artículo sobre Ground Truth Testing ).


Esto mantendría una buena tasa de falsas alarmas (FAR) pero no lograría una tasa de detección de fallas (FDR) razonable, ya que la frecuencia sería demasiado baja.

Evaluación comparativa independiente

Una forma inteligente de resolver esto es comparar su resultado, en términos de recuento de elementos, con una colección independiente.


Para que este enfoque funcione correctamente, los datos de referencia deben ser:

  • Independiente: para reducir la posibilidad de verse afectado por los mismos sesgos de codificación
  • Rentable: Ça va sans dire , web scraping es lo suficientemente costoso.


Una recopilación de datos independiente (casi) no está correlacionada con su propia recopilación de datos: está correlacionada porque miran el mismo objeto, por lo que una falla del objeto observado causaría una pérdida en ambas recopilaciones de datos, pero por otro lado, son re resultados de procesos independientes, escritos por am mantenidos por diferentes equipos, con diferentes técnicas.


El uso de una fuente de datos altamente confiable aumenta considerablemente la confiabilidad de los resultados.

Supongamos que su tasa de detección de fallas (FDR) actual es del 90 %, lo que significa que su sistema puede detectar automáticamente el 90 % de las veces que un raspador recopila solo parcialmente del sitio web. O, en otros términos, su conjunto de datos, cuando se publica, contiene el 90 % de las veces una colección completa.


Si suponemos que los datos de referencia son

a) tan capaz de detectar errores como los datos de producción

b) independiente


El uso de datos externos para el control de calidad llevaría la tasa de detección de fallas al 99% ( probabilidad de la unión de dos eventos ).

  1. Supervise el recuento total de artículos en su recopilación de datos
  2. Compararlo con el recuento total de artículos del mismo sitio web en Data Boutique
  3. Cuando su conteo es más bajo que el punto de referencia, tiene su detección de fallas.


Por qué Data Boutique es una opción inteligente

Dado que los conjuntos de datos de Data Boutique incorporan inspecciones manuales en su proceso de control de calidad, usar los datos de Data Boutique como punto de referencia es escalable , rentable y una forma confiable de mejorar el proceso de Garantía de calidad (QA) incluso cuando hace web-scraping internamente porque es muy probable que los conjuntos de datos publicados en Data Boutique excedan esos niveles de FDR.


  1. Las dos estructuras de datos no tienen que ser iguales: solo está comparando recuentos de elementos y no necesita la misma estructura, lo que hace que sea muy fácil de implementar. Solo la granularidad tiene que ser comparable.

  2. Puede seleccionar la frecuencia de su control de calidad que puede ser menor que la frecuencia de su adquisición (si adquiere artículos diariamente, solo puede tener puntos de referencia semanales, lo que aún contribuiría mucho a mejorar las pruebas de calidad de datos).

  3. Dado que los datos de Data Boutique son fraccionables (como se explica en esta publicación ), el costo de comprar estos datos puede ser muy bajo si se compara con todas las demás medidas de calidad.


En otras palabras, incluso si la estructura de datos de Data Boutique no es una combinación perfecta para su caso de uso, usarla para Pruebas de calidad es un enfoque muy eficiente.


Únete al proyecto


Data Boutique es una comunidad para intercambios de datos web sostenibles, éticos y de alta calidad. Puede navegar por el catálogo actual y agregar su solicitud si un sitio web no está en la lista. Guardar conjuntos de datos en su lista de interés permitirá a los vendedores dimensionar correctamente la demanda de conjuntos de datos e incorporarse a la plataforma.

Puede encontrar más información sobre este proyecto en nuestros canales de Discord .



También publicado en Data Boutique