Bing検索結果のエクスポート：ChronometricaとAxiom Worksの比較

まずURL探索の要件から判断する

読者の課題は、ページをスクレイピングする前から始まります。有用な内容につながる可能性があるURLを見つける必要があります。検索Actorを選ぶとは、その作業に必要な検索記録と結果タイプを選ぶことです。

スクレイピング前にURLを見つける方法に関する公開の質問は、このような探索の必要性を裏づけています。提供された資料は検索結果の抜粋です。クロールの要件全体を定義するものでも、どちらかの製品を推奨するものでもありません。また、検索結果のスニペットに必要なページ本文が含まれることを証明するものでもありません。

プロジェクトで採用できるリンク先の条件を、1文で定義してください。架空のチュートリアル作成プロジェクトなら、「機械学習のレッスンを完全な形で掲載した公開ページを採用する」という条件が考えられます。これにより、探索後に適用する内容の要件が決まります。

次に、そのようなページを見つけるために必要な検索結果のタイプを決めます。冒頭に示した製品の使い分け条件を適用してください。ここで扱う小規模な探索作業には、明確な観測記録が適しています。探索の要件が増えれば、適切な製品も変わる場合があります。

これらの判断は分けてください。検索Actorは、候補と検索の根拠を提供します。候補が内容の条件を満たすかどうかは、リンク先の確認で判断します。検索結果のエクスポートが用途に適していても、返されたすべてのページが適しているとは限りません。

上限付きの観測記録テーブルにChronometricaが適する理由

観測記録とは、クエリ情報とともに保存した1件の検索結果です。同じリンク先が複数のクエリで表示されれば、複数の観測記録ができます。

Chronometricaは、観測記録ごとの次のフィールドを文書化しています。

• `runId`：その観測記録を取得したときのデータ収集処理。
• `engine`：使用した検索エンジン。
• `executedQuery`：実際に使用した正確なクエリ。
• `page`：検索結果のページ。
• `rankOnPage`：そのページ内での結果の表示位置。
• `rank`：記録された検索結果の順位。
• `canonicalUrl`：Actorが記録したリンク先URL。
• `resultDomain`：検索結果のドメイン。
• `observedAt`：観測時刻。

これらのフィールドが、検索エンジンとクエリごとの文書化された記録を構成します。入力では、実行するクエリごとに上限も指定できます。Chronometricaの出力と入力のドキュメント

この構造は、「このページはなぜキューに入ったのか」という実務上の疑問に答えるのに役立ちます。正確なクエリ、記録された順位、観測時刻まで追跡できます。URLの一覧から、その経緯を推測する必要はありません。

探索リクエストに含まれる2つのクエリの両方に、あるページが表示されたとします。両方の観測記録を保持してください。確認すべきリンク先は1つでも、記録は検索に2回表示されたことを示します。

これが、根拠に基づいてChronometricaを選べる理由です。文書化された観測記録により、リンク先を採用する前に、その出所を明確に記録できます。上限を設定すれば、自分で確認できる規模の探索を定義できます。

記録された順位は、あくまで検索での表示位置です。ページの品質、正確さ、適合性の評価点ではありません。順位は検索時の情報を残すために使い、内容の条件はリンク先自体に適用してください。

上限が要件を満たすか確認する

Chronometricaの`maxResultsPerExecutedQuery`は、実行するクエリごとの最大件数を設定します。確認済みのスキーマでは、1から100までの整数を指定できます。`queries`配列には、1から100までの要素を指定できます。Chronometricaの入力スキーマ

上限は最大許容件数です。Actorがその件数の観測記録を返すと保証するものではありません。5に設定すると、実行したクエリごとに最大5件の観測記録を保存できます。重複しないURLが5件得られることや、採用できるページが5件得られることを保証するものではありません。

これは小規模な探索作業に適しています。候補を確認し、クエリを評価して、追加の検索に意味があるか判断できます。必要な根拠の量と、自分で評価できる量に基づいて上限を設定してください。

元の要件が、実行した1つのクエリから100件を超える結果を保存することなら、確認済みのスキーマではChronometricaはその要件を満たしません。Bingのすべての検索結果を上限なしでエクスポートするという要件も満たしません。クエリを変更しても、元のクエリについてすべての結果を取得するという要件を満たしたことにはなりません。

提供された資料には、文書化された4つの検索エンジンで成功した小規模な確認が含まれています。ただし、その確認は完全な網羅性や、継続的な網羅性を証明するものではありません。この比較はBingのみを対象とし、入力例でもBingだけを選択しています。

収集前に、必要な範囲を書き出してください。「2つのクエリについて、それぞれ最大5件の観測記録を確認する」は、明確で範囲を限定したリクエストです。「関連するすべてのページを見つける」には、上限付きのこのエクスポートでは得られない根拠が必要です。

入力を明示してBing Taskを使う

製品名にはGoogleが含まれますが、Chronometricaの公開仕様ではBingへの対応が明示されています。この比較では、`engines`を`["bing"]`に設定します。Chronometricaのドキュメント

Taskは、Actor用に保存された入力プリセットです。公開されているBing Search Results Scraper Taskを初期プリセットとして使えます。記録されたページ確認では、ページの応答が成功したことを示すHTTP 200が返されました。ただし、この確認は、現在保存されている入力内容を証明するものではありません。

実行前にプリセットを確認し、必要な設定を適用してください。次の架空の探索リクエストでは、2つのクエリを使い、観測記録の上限を5件に設定しています。

{
  "queries": [
    "machine learning tutorials",
    "machine learning guide"
  ],
  "engines": [
    "bing"
  ],
  "maxResultsPerExecutedQuery": 5,
  "country": "US",
  "language": "en",
  "includeSponsoredResults": false
}

この入力は、キャッシュに保存された公開JSON Schemaとの照合に合格しました。JSON Schemaは、使用できる入力フィールドと値を定義するものです。指定したフィールド名は、すべてそのスキーマに存在します。これは入力形式の確認です。この比較では、収集は実行していません。

確認済みのスキーマでは、`country`に指定できる値は`US`だけです。`language`には文字列、`includeSponsoredResults`には真または偽の値を指定できます。`engines`配列には、少なくとも1つの要素が必要です。Chronometricaの入力スキーマ

入力時には、フィールド名を正確に保ってください。有効な入力であっても、実際にBingを利用できることや、リンク先が用途に適することの証明にはなりません。確認済みの入力仕様にリクエストが従っていることを示すだけです。

2つのクエリは、意図する2つの検索を表しています。検索語が違っても、異なるリンク先が得られるとは限りません。重複しない候補ページを数える前に、保存された観測記録の重複を確認してください。

架空の例：8件の観測記録と5つのリンク先

この例は架空のものです。Actorのテスト、実際のデータセット、購入者の発言、費用の実測結果ではありません。スキーマと照合したのは、上に示した入力形式だけです。

各クエリが4件の観測記録を返したとします。各クエリの結果には、重複しないリンク先が4つ含まれます。そのうち3つのリンク先URLが、両方の結果に含まれています。

最初のクエリでは、ページA、B、C、Dが見つかります。2つ目では、ページA、B、C、Eが見つかります。これらの文字は、架空のページを示すラベルです。

計算は次のとおりです。

1. 観測記録4件に観測記録4件を足すと、検索の観測記録は8件になります。
2. 2つのクエリの結果で、3つのリンク先URLが重複しています。
3. 観測記録8件から重複するリンク先3つを引くと、重複しない候補ページは5つになります。

検索の観測記録は8件すべて保持してください。それとは別に、リンク先5件のキューを作成します。ページA、B、Cには、それぞれ2件の観測記録を関連づけます。ページD、Eには、それぞれ1件の観測記録を関連づけます。

これは多対1の関連づけです。複数の検索観測記録が、1件のリンク先エントリを参照できます。これにより、探索の履歴を保ちながら、重複しない各リンク先を個別に評価できます。

何を数えているかが重要です。観測された検索結果の8行と、候補ページの5件は、異なるものを表しています。どちらの件数からも、採用するページ数はわかりません。

その後の確認で、3ページを採用し、1ページを不採用とし、1ページを未解決のままにしたとします。これらの結果も架空のものです。未解決のページは、判断に十分な根拠が得られるまで不明のままにします。空の文書として数えたり、欠損値を0に置き換えたりしないでください。

製品選びからページ確認までの5つの手順

1. リンク先と探索の要件を定義します。適切なページに必要な内容を明記してください。必要な検索結果のタイプを決めます。収集前に、製品の使い分け条件を適用してください。

他の人でも確認できる条件を使ってください。「有用なページ」では、不明な点が多すぎます。架空の条件である「機械学習のレッスンを完全な形で掲載した公開ページ」なら、リンク先を確認する目的が明確になります。

1. Bingを選択し、上限を設定します。Chronometricaでは、`engines: ["bing"]`を使い、文書化された範囲内で`maxResultsPerExecutedQuery`を設定します。その上限が元の要件を満たすことを確認してください。Chronometricaの入力ドキュメント

予定するクエリの組み合わせと対象範囲を記録してください。要件が上限を超える場合は、実行前に製品の選択を見直してください。限られた結果の集合を、完全に網羅したものとして説明しないでください。

1. 各観測記録を保持します。検索エンジン、正確なクエリ、順位、観測時刻を各結果とともに保存してください。文書化されたその他の関連情報フィールドも、エクスポートに残します。

リンク先の重複を除去する前に、これらの記録を保存してください。重複を除いたURL一覧だけでは、どのクエリで各ページを見つけたのか示せません。そのためには、元の観測記録との関連づけを残す必要があります。検索スニペットも、この検索の根拠に含まれます。取得したリンク先の文書とは異なります。

1. 別のリンク先キューを作成します。URLの正規化とは、比較可能なURL表記を統一した形式にそろえることです。明確なルールを適用し、元の検索記録を削除せずに、重複するリンク先エントリを除去してください。

URLの違いが、すべて内容に影響しないとは考えないでください。クエリパラメータによって内容が変わる場合があります。ルールに基づいて同じリンク先と扱える場合に限り、エントリを統合してください。各観測記録とキューのエントリとの関連づけを保ちます。この手順は、検索結果の重複除去ガイドで詳しく説明しています。

1. アクセスが認められる各リンク先を取得し、評価します。ページの取得とは、リンク先ページ自体をリクエストすることです。使用する前に、内容と情報源の状態を確認してください。採用、不採用、未解決のいずれかの結果を記録します。

返されたURLは候補を示します。取得の成功を証明するものではありません。スニペットはページ確認の代わりにはなりません。採用判断の方法全体については、Bing検索結果からクロールキューを作成する方法を参照してください。

この手順を採用する前にエクスポートを確認する

少量の出力結果が、明記した要件を満たすか確認してください。まず、検索記録を調べます。各観測記録について、実行したクエリと記録された順位を特定できることを確かめます。重複するリンク先が、検索履歴を失わずに1件のキューエントリに関連づけられていることを確認してください。

次に、リンク先に対する判断を確認します。採用したページには、条件を満たす根拠が必要です。不採用のページには、その理由が必要です。未解決のページは、不明という状態を保持する必要があります。

この区別により、ページを確認できなかったことから、内容について誤った結論を出すのを防げます。ページを評価できなかった場合、必要な内容が含まれているかどうかは、まだわかりません。

検索の観測記録、重複しない候補URL、取得したページ、採用したページは、段階ごとに分けて数えてください。ある段階の件数から、次の段階の件数が決まるわけではありません。架空の例では、検索結果8行から候補のリンク先が5つになり、採用するページはさらに少なくなり得る理由を示しています。

提供された資料は、価格、速度、正確さ、信頼性について、実測に基づく優位性を示していません。この推奨は、文書化された観測記録とクエリごとの上限に基づいています。リンク先を採用する前に、Bingによる小規模な探索結果を保持する作業では、これらが役立つ強みになります。