「完全性」の問題 Web スクレイピングの品質保証 (QA) で最も一般的な問題の 1 つは、スクレイパーがターゲット Web サイトからすべてのアイテムを確実に収集することです。 これは、常に変化する物体を測定するツールを継続的に校正するという問題です。 なぜそれが起こるのか? 検出が最も簡単なものから、最も困難なもの (解決が簡単というわけではありません) まで、不完全なデータ収集の原因は次のとおりです。 スクレーパーはアンチボット システムによってブロックされます Web サイトの A/B テスト バージョンでスクレーパーが失われる スクレイパーは、Web サイト/API のページング制限によって制限されます スクレーパーは Web サイトの一部を見落としています (スクレーパーが設計された後に作成される場合もあります) その結果、部分的なデータが収集されました。 早期故障検出 ほとんどの Web スクレイピングの使用例にはサービス レベル アグリーメント (SLA) があり、ペナルティ条項が発生する可能性があります。品質保証は、 、潜在的な問題をできるだけ早期に検出することを目的としています。 SLA に違反する前に そのためには、障害検出率 (FDR) を高め、誤報率 (FAR) を下げる必要があります。さらに重要なことは、 です。 コストを低く抑えること 障害を検出する方法 時系列分析 時間の経過とともにアイテム数を監視し、アイテム数が減少したときにアラートをトリガーできます。これは出発点としては適していますが、突然の変化 (つまり、50% の低下) には効果的ですが、変化が増分している場合にはあまり機能せず、誤報 (FAR) が多すぎるか、エラーの検出に失敗します。 これは、次の理由で発生します。 ウェブサイトは、特に大規模な場合、急速に変化します 傾向や季節性を理解するためのデータ履歴がありません。これにより、より高度な時系列アルゴリズムを適用できるようになります。 この方法の最も重要な制限は、スクレーパーで一度も捕捉されていない欠落アイテムを検出できないことです。 例 ファッション電子商取引 Web サイトには、公式セール期間中にのみ表示される Web サイトの「セール」カテゴリがある場合があります。セクションがないときにスクレーパーを作成すると、販売アイテムが不足していることに気付かない可能性があります。 手動検査 (グラウンド トゥルース) 説明したように、手動検査では結果の信頼性が最も高くなります。これはいわゆる Ground Truth を提供し、収集したアイテム数を手動で実行したアイテム数と比較してベンチマークを行うことができます。 この投稿で 制限事項: 大規模な Web サイトではほとんど実現できません ( Web サイトではアイテムの数を確実に知ることができますが、 ではそれほど確実ではありません)。 Allbirds Farfetch スケーラビリティがほとんどない: 少数の Web サイトでは機能する可能性があり、めったに実行されませんが、複数の大規模な Web サイトが高頻度で必要になると、状況はすぐに困難になります (これについては、 に関する記事の Data Boutique アプローチを参照してください)。 Ground Truth Testing これにより、良好な誤警報率 (FAR) が維持されますが、頻度が低すぎるため、適切な障害検出率 (FDR) は達成されません。 独立したベンチマーク これを解決する賢い方法は、アイテム数の観点から、独立したコレクションに対して結果をベンチマークすることです。 このアプローチが適切に機能するには、ベンチマーク データが次のとおりである必要があります。 独立型: 同じコーディングバイアスの影響を受ける可能性を減らすため 費用対効果: 、Web スクレイピングには十分な費用がかかります。 悲惨な状況ではないため 独立したデータ コレクションは、独自のデータ コレクションと (ほとんど) 相関関係がありません。相関関係があるのは、それらが同じオブジェクトを観察しているためです。そのため、観察されたオブジェクトの障害は確かに両方のデータ コレクションに損失を引き起こしますが、その一方で、それらは独立したプロセスの結果は、さまざまなチームによってさまざまな手法で作成され、維持されます。 信頼性の高いデータ ソースを使用すると、結果の信頼性が大幅に高まります。 現在の障害検出率 (FDR) が 90% であると仮定します。これは、スクレイパーが Web サイトから部分的にのみ収集する回数の 90% をシステムが自動的に検出できることを意味します。言い換えれば、公開されるデータセットには、90% の確率で完全なコレクションが含まれます。 ベンチマークデータが次であると仮定すると、 a) 本番データと同様にエラーを検出できる b) 独立した QA に外部データを使用すると、障害検出率が 99% ( ) になります。 2 つのイベントの結合確率 データ収集の総アイテム数を監視する Data Boutique 上の同じ Web サイトからの総アイテム数でベンチマークします。 カウントがベンチマークよりも低い場合、障害が検出されます。 Data Boutique が最適な理由 のデータセットには QA プロセスに手動検査が組み込まれているため、Data Boutique のデータをベンチマークとして使用することは、内部で Web スクレイピングを行っている場合でも、スケーラブル 品質保証プロセス (QA) を改善するための 方法です。 Data Boutique で公開されているデータセットは、FDR のこれらのレベルを超えている可能性が非常に高くなります。 Data Boutique で コスト効率が高く、 信頼できる 2 つのデータ構造は同じである必要はありません。項目数を比較するだけであり、同じ構造である必要はないため、実装が非常に簡単になります。比較できるのは粒度だけです。 QA の頻度は、取得の頻度よりも低く選択できます (アイテムを毎日取得する場合は、毎週のベンチマークのみを使用できますが、それでもデータ品質テストの改善に非常に役立ちます。 Data Boutique のデータは分割可能であるため ( 説明されているように)、このデータの購入コストは、他のすべての品質基準と比較すると非常に低くなります。 この投稿で つまり、Data Boutique のデータ構造がユースケースに完全に一致しない場合でも、それを品質テストに使用することは非常に効率的なアプローチです。 プロジェクトに参加する Data Boutique は、持続可能で倫理的、高品質な Web データ交換のためのコミュニティです。 Web サイトがリストされていない場合は、 てリクエストを追加できます。データセットを関心リストに保存すると、販売者はデータセットの需要を正確に見積もってプラットフォームに参加できるようになります。 現在のカタログを参照し このプロジェクトの詳細は、 でご覧いただけます。 Discord チャンネル にも掲載されています データブティック
