“完整性”问题 网络抓取的质量保证 (QA) 中最常见的问题之一是确保抓取器从目标网站收集所有项目，但它的琐碎性却让人解除武装。 这是一个不断校准测量不断变化的对象的工具的问题。 为什么会发生？ 从最容易检测到最具挑战性（这并不意味着容易解决..），我们有以下原因导致数据收集不完整： 刮板被反机器人系统阻止 爬虫在网站的 A/B 测试版本中丢失 抓取器受网站/API 的分页限制限制 爬虫忽略了网站的某些部分（有时是在爬虫设计后创建的） 因此，我们收集了部分数据。 早期故障检测 大多数网络抓取用例都有可能导致惩罚条款的服务水平协议 (SLA)。质量保证旨在尽早发现潜在问题 - 。 在违反 SLA 之前 为此，我们需要提高故障检测率 (FDR) 并降低误报率 (FAR)。最重要的是： 。 保持低成本 如何检测故障 时间序列分析 我们可以随着时间的推移监控项目计数，并在下降时触发警报。这是一个很好的起点，但虽然对突然变化（即下降 50%）有效，但当变化是增量时，它的功能会降低，产生太多误报 (FAR) 或无法检测到错误。 发生这种情况是因为： 网站变化很快，尤其是大型网站 我们没有数据历史来理解趋势或季节性，这将允许应用更复杂的时间序列算法。 这种方法最关键的限制是，如果它们从未被刮板捕获过，它就不会发现丢失的物品。 例子 一个时尚电子商务网站可能有一个“销售”类别的网站，只在正式销售期间弹出。如果您在该部分不存在时构建刮板，您可能永远不会意识到您缺少销售项目。 人工检查（真值） 正如 所讨论的那样，手动检查对结果的置信度最高。它提供了所谓的 Ground Truth，您可以将您收集的项目计数与手动执行的项目计数进行基准比较。 这篇文章中 限制： 对于大型网站来说几乎不可行（您可以可靠地判断 网站上有多少商品，但在 上则不那么可靠）。 Allbirds Farfetch 难以扩展：它可能适用于一些网站，而且很少有人这样做，但是当您需要多个高频的大型网站时，事情就会变得很糟糕（请阅读有关 的文章中关于此的 Data Boutique 方法）。 地面实况测试 这将保持良好的误报率 (FAR)，但无法实现合理的故障检测率 (FDR)，因为频率太低。 独立基准 解决此问题的明智方法是根据项目计数将结果与独立集合进行基准测试。 为了使这种方法正常工作，基准数据必须是： 独立：减少受相同编码偏差影响的机会 成本效益： ，网页抓取的成本已经够高了。 Ça va sans dire 一个独立的数据集合（几乎）与你自己的数据集合不相关：它是相关的，因为它们看的是同一个对象，所以被观察对象的失败确实会导致两个数据集合的损失，但另一方面，它们'它们是独立过程的结果，由不同的团队使用不同的技术维护。 使用高度可靠的数据源可以大大提高结果的可信度。 假设您当前的故障检测率 (FDR) 为 90%，这意味着您的系统可以自动检测 90% 的抓取工具仅从网站收集的部分数据。或者，换句话说，您的数据集在发布时包含 90% 的时间是一个完整的集合。 如果我们假设基准数据是 a) 与生产数据一样能够检测错误 b) 独立的 使用外部数据进行 QA 将使故障检测率达到 99%（ ）。 两个事件合并的概率 监控数据收集的项目总数 用 Data Boutique 上同一网站的总项目数对其进行基准测试 当您的计数低于基准时，您就会进行故障检测。 为什么 Data Boutique 是一个明智的选择 由于 的数据集在其 QA 流程中嵌入了人工检查，使用 Data Boutique 的数据作为基准是 、 并且是改进质量保证流程 (QA) 的 方法，即使您在内部进行网络抓取也是如此，因为Data Boutique 上发布的数据集很可能超过了 FDR 的水平。 Data Boutique 可扩展的 具有成本效益的， 可靠 这两个数据结构不必相同：您只是比较项目计数，不需要相同的结构，这使得它很容易实现。只有粒度必须是可比较的。 您可以选择低于获取频率的 QA 频率（如果您每天获取项目，则可以只有每周基准，这在改进数据质量测试方面仍然有很长的路要走。 由于 Data Boutique 的数据是可分割的（如 所述），与所有其他质量指标相比，购买此数据的成本可能非常低。 本文 换句话说，即使 Data Boutique 的数据结构不能完美匹配您的用例，将其用于质量测试也是一种非常有效的方法。 加入项目 Data Boutique 是一个可持续、合乎道德、高质量的网络数据交换社区。如果未列出网站，您可以 并添加您的请求。将数据集保存到您的兴趣列表将使卖家能够正确调整对数据集的需求并在平台上使用。 浏览当前目录 有关此项目的更多信息，请访问 。 我们的 Discord 频道 也发布在 上 Data Boutique
