Bing 搜尋結果匯出：Chronometrica 與 Axiom Works 比較

先決定探索需求

讀者面對的問題始於網頁擷取之前。你需要先找到可能通往有用內容的 URL。選擇搜尋 Actor，就是選擇用哪些搜尋紀錄和結果類型來支援這項工作。

一則關於在擷取前尋找 URL 的公開提問，支持這項探索需求。所提供的來源是搜尋摘要。它沒有定義完整的擷取需求，沒有推薦任一產品，也無法證明搜尋摘要包含所需的網頁文字。

用 1 句話定義專案可接受的目的網頁。在虛構的教學專案中，規則可以是：「接受包含完整機器學習課程的公開網頁。」這樣你就有一項內容要求，可在探索後用來檢查網頁。

接著，決定需要哪些搜尋結果類型才能找到這些網頁。依據文章開頭的條件決定是否改選產品。清楚的觀察紀錄適合本文所述的小規模探索工作。額外的探索需求可能改變產品選擇。

請分開處理這些決定。搜尋 Actor 提供候選網頁和搜尋證據。你對目的網頁的檢查，才會判定候選網頁是否符合內容規則。合適的搜尋匯出結果，不代表每個傳回的網頁都合適。

為何 Chronometrica 適合有上限的觀察紀錄表

觀察紀錄是連同查詢資訊儲存的 1 筆搜尋結果。同一個目的網頁若出現在多個查詢中，就可能產生多筆觀察紀錄。

Chronometrica 文件列出每筆觀察紀錄的以下欄位：

• `runId`：這筆觀察紀錄所屬的資料收集執行作業。
• `engine`：使用的搜尋引擎。
• `executedQuery`：實際使用的完整查詢。
• `page`：搜尋結果所在的頁面。
• `rankOnPage`：結果在該頁面上的位置。
• `rank`：記錄的結果排名。
• `canonicalUrl`：Actor 記錄的目的網頁 URL。
• `resultDomain`：搜尋結果的網域。
• `observedAt`：觀察時間。

這些欄位定義了文件所述的紀錄格式，適用於每個搜尋引擎和查詢。輸入也可設定每個實際執行查詢的結果上限。Chronometrica 輸出與輸入文件

這種結構有助於回答一個實際問題：這個網頁為何進入佇列？你可以追溯到完整查詢、記錄的排名及觀察時間，不必只憑 URL 清單推測來源歷程。

假設某個網頁出現在探索請求的 2 個查詢中，請保留這 2 筆觀察紀錄。雖然你只需要檢查 1 個不重複的目的網頁，但這些紀錄代表它在搜尋中出現了 2 次。

這是有證據支持的 Chronometrica 選用理由。文件所述的觀察紀錄，能在你接受目的網頁前提供清楚的來源紀錄。結果上限則讓你能設定一輪規模小、可供審查的探索工作。

記錄的排名仍只是搜尋結果中的位置，不是網頁品質、準確性或適用性的評分。請用排名保留搜尋資訊，再對目的網頁本身套用內容規則。

確認結果上限是否符合需求

Chronometrica 的 `maxResultsPerExecutedQuery` 會設定每個實際執行查詢的結果上限。已檢查的結構定義接受 1 至 100 的整數。其 `queries` 陣列接受 1 至 100 個項目。Chronometrica 輸入結構定義

上限是允許的最大數量，不保證 Actor 會傳回同樣數量的觀察紀錄。設定為 5，代表每個實際執行查詢最多可儲存 5 筆觀察紀錄。這不保證會取得 5 個不重複的 URL，也不保證會有 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 同時出現在這 2 組結果中。

第 1 個查詢找到網頁 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 筆觀察紀錄。

這是多對一連結：多筆搜尋觀察紀錄可以指向同一個目的網頁項目。這樣既能保留探索歷程，也能讓你分別評估每個不重複的目的網頁。

計量單位很重要。8 筆搜尋觀察紀錄和 5 個候選網頁描述的是不同事物。這 2 個數量都無法告訴你最後會接受多少個網頁。

假設後續檢查接受 3 個網頁、拒絕 1 個，並留下 1 個尚待判定的網頁。這些結果也都是虛構的。在取得足夠證據作出決定前，尚待判定的網頁仍須保留未知狀態。不要將它計為空白文件，也不要用 0 取代缺失值。

依照 5 個步驟，從產品選擇進行到網頁檢查

1. 定義目的網頁與探索需求。說明合適的網頁必須包含哪些內容。決定需要哪些搜尋結果類型。收集資料前，先依據條件決定是否改選產品。

採用其他人也能檢查的規則。「有用的網頁」仍有太多不明確之處。虛構規則「包含完整機器學習課程的公開網頁」，則為目的網頁審查提供明確目標。

1. 選擇 Bing 並設定上限。使用 Chronometrica 時，請設定 `engines: ["bing"]`，並在文件規定的範圍內設定 `maxResultsPerExecutedQuery`。確認此上限符合原始需求。Chronometrica 輸入文件

記錄預定使用的查詢組合與範圍。如果需求超過上限，請在執行前重新確認產品選擇。不要將有限的結果集描述為完整涵蓋。

1. 保留每筆觀察紀錄。為每筆結果保留搜尋引擎、完整查詢、排名及觀察時間。匯出時，也要保留文件列出的其他相關資訊欄位。

移除重複的目的網頁前，先儲存這些紀錄。除非你保留與原始觀察紀錄的連結，否則不重複的 URL 清單無法顯示各網頁是由哪些查詢找到。搜尋摘要屬於這些搜尋證據，並不是已取得的目的網頁文件。

1. 另外建立目的網頁佇列。URL 正規化是指將可比較的 URL 形式轉為一致形式。先套用明確規則，再移除重複的目的網頁項目，同時保留原始搜尋紀錄。

不要假設每種 URL 差異都不影響內容。查詢參數可能改變內容。只有在規則支持將項目視為同一目的網頁時，才合併項目。保留每筆觀察紀錄與其佇列項目的連結。搜尋結果去重指南 更詳細地說明了這個步驟。

1. 取得並評估每個允許存取的目的網頁。取得網頁是指向目的網頁本身發出請求。使用網頁前，先檢查其內容與來源狀態。將結果記錄為已接受、已拒絕或尚待判定。

傳回的 URL 只代表一個候選網頁，無法證明已成功取得網頁。搜尋摘要不能取代網頁檢查。完整的接受判定方法，請參閱如何從 Bing 搜尋結果建立擷取佇列。

採用流程前，先檢查匯出結果

依據已列明的需求，審查一小組輸出結果。先檢查搜尋紀錄。確認你能辨識每筆觀察紀錄的實際執行查詢與記錄的排名。檢查重複的目的網頁是否連結至同一個佇列項目，同時保留各自的搜尋歷程。

接著，檢查目的網頁的判定。已接受的網頁需要有證據證明它符合規則。已拒絕的網頁需要有拒絕理由。尚待判定的網頁則須保留未知狀態。

這項區分能避免將失敗的網頁檢查變成錯誤的內容主張。如果你無法評估某個網頁，就還不知道它是否包含所需資料。

分別記錄各階段的數量：搜尋觀察紀錄、不重複的候選 URL、已取得的網頁，以及已接受的網頁。某個階段的數量無法證明下一階段的數量。虛構範例說明了為何 8 筆搜尋資料列可能形成 5 個候選目的網頁，而最終接受的網頁更少。

所提供的證據無法證明價格、速度、準確性或可靠性方面的實測優勢。本推薦依據的是文件所述的觀察紀錄，以及每個查詢的結果上限。如果你的工作是在核准目的網頁前，保留一小組 Bing 探索結果，這些優點就很實用。