Chronometrica 與 Kaix 比較：哪個 Naukri Actor 適合你的公開職缺資訊流？

職涯入口網站需要從這篇比較得知什麼

Reddit 上有一則公開提問，詢問是否有現成 API，可為業餘專案的職涯入口網站提供印度職缺刊登資料。這個需求帶出一個實用問題：網站擁有者能否透過資料收集服務取得所需資料，而不必自行建立爬蟲？爬蟲是從網站收集資料的程式。這則提問並未證明使用者偏好哪個供應商、服務涵蓋所有雇主，或使用者有權重新發布職缺說明。原始職涯入口網站提問

做這項選擇時，請將系統必須完成的工作分成 3 項。首先，找出相關職缺刊登資料。接著，儲存每筆觀察到的刊登資料，並保留足夠資訊以供檢查。最後，決定哪些事實可以顯示，以及何時再次檢查。

Actor 協助收集資料。你的入口網站仍需要儲存、審查和顯示資料的規則。因此，API 請求成功還不足以代表結果有用。回傳的資料列必須符合你的必要欄位要求。你也必須知道資料收集為何停止。

本文協助你在這 2 個 Actor 之間做選擇。如需現有的 API 請求方法，請參閱如何透過 API 收集 Naukri 公開職缺刊登資料。

先比較資料收集模式

資料收集模式，是你要求程式尋找職缺刊登資料的方式。比較可用欄位數量之前，先決定需要哪種模式。

此表依據經核對的 Chronometrica 文件與 Kaix 文件。分類 ID 用來識別 Naukri 分類系統中的類別。

針對上述精簡搜尋需求，Chronometrica 明確適用。文件所列的控制設定，讓你能指定職位、地點、經驗和刊登時間，再限制儲存的資料列數。如果必要的資料收集模式需要更完整的表單，表單的廣度才會影響選擇。表單精簡本身，不能證明資料涵蓋範圍較佳。Chronometrica 輸入文件

此表用來協助這項特定選擇，並非完整功能清單。表中未記載某項功能，不代表該功能不存在。

為何 Chronometrica 適合有明確上限的職缺發掘資訊流

Chronometrica 的文件列有 `searchTerm`、`location`、`experienceYears`、`postedWithinDays`、`sortBy`、`searchDepth` 和 `maxItems`。這些欄位為小型入口網站提供明確的搜尋表單，適合能在執行前界定資料收集範圍的網站。Chronometrica 輸入文件

儲存的資料列包含 `jobId`、`jobUrl`、`title`、`companyName`、`location`、`descriptionText`、`skills`，以及可取得的薪資與經驗資訊。每次執行時，Chronometrica 對每個觀察到的不重複 `jobId` 儲存 1 筆資料。缺少的公開資訊維持為 `null`。這個值表示該資訊未知或無法取得。Chronometrica 輸出文件

這種資料列結構，是小型入口網站實用的起點。網站可以識別職缺刊登資料、保留來源連結，並記錄哪些資訊需要審查。職缺 ID 用來識別觀察到的刊登資料，不能證明應徵頁面仍然有效。

共用上限讓資料收集限制更明確。`maxItems` 在篩選與移除重複資料後套用，限制整次執行所儲存的資料列總數。它不會為每個關鍵字分配個別額度。如果你的計畫假設每個關鍵字都有個別額度，請先修改計畫，再收集資料。Chronometrica 儲存資料列上限

`searchDepth` 提供 `standard`、`extended` 和 `deep` 等收集力度等級。較高設定不保證取得所有職缺，也不保證資料品質更好。請用此設定選擇收集力度，再檢查儲存的觀察資料。Chronometrica 搜尋控制設定

這些經核對的功能，支持將它推薦用於有明確上限的職缺發掘。它們不能證明成本較低、執行較快，或資料涵蓋完整。

用小規模輸入檢查是否適用

公開的 Naukri Jobs API Dataset Task 提供起始預設。Task 是為 Actor 儲存的輸入預設。使用前，請檢查它目前的實際輸入。記錄中的頁面檢查回傳 HTTP 200，表示頁面回應成功。該檢查並未驗證目前儲存的設定。

這個虛構查詢提供一個小規模驗收範例。驗收檢查用來判斷結果是否符合你列明的需求。

{
  "searchTerm": "data engineer",
  "location": "Bengaluru",
  "experienceYears": 3,
  "postedWithinDays": "7",
  "searchDepth": "standard",
  "maxItems": 5
}

這組輸入已在本機通過快取的公開 JSON Schema 檢查。JSON Schema 定義允許的輸入欄位、值類型與限制。所有提供的欄位名稱都存在於該結構描述中。檢查結果支持這組輸入的結構，但不能證明即時來源可用，也不能預測會儲存多少資料列。本範例未執行 Actor。Chronometrica 公開結構描述

請保留範例所示的值類型。`searchTerm` 和 `location` 是字串，也就是文字值。`experienceYears` 是 0 至 30 的整數。整數是沒有小數部分的數。`maxItems` 是至少為 1 的整數。此處 `postedWithinDays` 使用字串 `"7"`，`searchDepth` 使用 `"standard"`。這些提供的值已通過快取結構描述的檢查。Chronometrica 輸入結構描述

這個查詢要求 3 年經驗。你仍必須將每筆回傳的職缺刊登資料所列要求，與這個值逐一比較。刊登資料可能列出經驗範圍，或在文字中包含其他條件。僅憑請求的值，不能證明每個回傳職缺都適合。

進行 5 項驗收檢查

收集資料前，先寫下預期結果。資料集即使有資料，也只有在資料列能支援預定資訊流時才有用。請用以下檢查，判斷所選 Actor 是否符合需求。

1. 定義搜尋條件與必要欄位。列明職位、地點、經驗和刊登時間。列出入口網站識別及評估刊登資料所需的資訊。將資料收集需求，與顯示及重新發布的決定分開處理。例如，如果網站保留薪資未知的狀態，薪資未知可能可以接受。
2. 選擇資料收集模式。確定你需要發掘職缺刊登資料，還是取得一組已知資料。選擇 Actor 前，先套用開頭所述會改變推薦選擇的條件。不要假設反覆進行廣泛搜尋，就能找回每筆已知的刊登資料。
3. 設定較小的共用儲存資料列上限。檢查 Task 目前的輸入，並與 Actor 表單比較。只有在範例設定符合需求時才套用。將上限記錄為整次執行的總額，不要乘以關鍵字數量。
4. 審查資料列與執行摘要。檢查重複的 `jobId`、職缺來源 URL、可取得的薪資與經驗文字，以及缺少的欄位。閱讀 `OUTPUT` 摘要，了解停止原因。將結果與書面需求比較，包括是否因達到上限而停止收集。Chronometrica 輸出文件
5. 顯示前檢查來源。開啟來源應徵頁面，檢查目前狀態。發布資訊流前，審查適用的來源條款。缺少的資訊維持為 `null`。在自己的儲存系統中附上觀察時間，以便知道資料何時收集。

這些檢查可導出 3 種實用決定：接受精簡搜尋、修改需求，或評估其他模式。如果模式明顯不符，就不需要大規模測試。即使模式適合，在將輸出接上公開資訊流之前，仍須審查資料列。

如果缺少必要資訊，請將這項發現與資料列數量分開記錄。儲存了 5 筆資料列，不代表符合 5 筆可用資料列的要求，因為其中可能有資料列缺少網站所需欄位。評估結果前，先決定哪些欄位缺失可以接受。

算式經核對的虛構決策範例

假設有一個虛構的職涯入口網站，希望取得少量班加羅爾資料工程職缺刊登資料。它接受薪資未知，但要求有來源 URL，並將這次收集限制為儲存 5 筆不重複的刊登資料。

在這個虛構範例中，候選職缺刊登資料在收集過程中共出現 8 次，其中包含重複出現的情況。有 3 次是重複出現，其 `jobId` 與同一次收集中已透過另一個關鍵字儲存的值相同。移除這些重複項目後，剩下 5 筆不重複的職缺刊登觀察資料：

`8 candidate appearances − 3 duplicate appearances = 5 unique job rows`

算式已核對，數量則是虛構的。此範例不是 Actor 測試、即時資料集、買家引述，也不是實測成本結果。

網站儲存每筆資料列的來源 URL，之後再檢查應徵頁面是否仍然有效。它也記錄觀察時間，並註明缺少的資訊。這讓網站能評估儲存的資料列，並將主張限制在觀察資料能支持的範圍內。

5 筆不重複的資料列，不代表 5 個雇主或 5 個仍在招募的實際職缺。這些資料列也不能證明有權重新發布完整職缺說明。這些決定需要個別檢查。

針對這項有明確上限的職缺發掘需求，Chronometrica 符合選擇規則。網站因此有明確依據，可收集少量觀察到的刊登資料，再進行審查。

現在更改這個虛構需求。網站已持有 5 個特定職缺 ID，需要取得其詳細資料。它應評估 Kaix 的直接查詢，而不是透過發掘搜尋，再次尋找這些記錄。Kaix 查詢模式

儲存觀察資料時，避免多算實際職缺

在自己的系統中使用職缺觀察資料表。每次執行內，以 `jobId` 作為資料列的鍵。鍵是儲存系統用來區分資料列的值。保留標準來源 URL，也就是該刊登資料的主要來源網址。註明所有缺少的欄位。

附上系統觀察到資料的時間。這是儲存方式的建議，並非宣稱 Actor 提供某個特定的時間戳記欄位。將收集記錄，與之後是否在入口網站顯示該職缺的決定分開處理。

重複觀察不會新增一個實際職缺。如果相同刊登資料再次出現，請記錄再次看到它。不要只因它出現在另一個搜尋結果中，或在另一個日期再次出現，就增加不重複刊登資料的數量。

保留資訊未知的狀態。缺少薪資，不代表薪資為 0。缺少經驗資訊，不代表要求 0 年經驗。用數字取代未知值，會產生錯誤資訊。

這種儲存方式，讓工具選擇的價值不只限於第 1 次請求。入口網站在儲存、計數和顯示資料列時，必須保留所收集資料的原意。

何時這項推薦不再適用

Chronometrica 的儲存資料列上限，讓收集範圍更明確。但這不能證明儲存的資料列包含每筆符合條件的刊登資料。如果原始需求是儲存所有結果，而結果數量超過設定上限，Chronometrica 在該設定下就無法符合需求。Chronometrica 儲存資料列控制設定

提高上限不能證明完整涵蓋來源資料，提高 `searchDepth` 也不能。經核對的證據無法證明完整性。評估工具時，請保留取得所有結果的原始要求。不要以較小樣本取代該要求，再宣稱已符合需求。

每項驗收檢查回答的問題都不同。有效輸入具有允許的結構。儲存的資料列記錄了一次觀察。檢查過的應徵頁面，提供該頁面在審查當時的狀態證據。任何一項檢查，都無法單獨回答這 3 個問題。

Chronometrica 是獨立的 Actor API，並非 Naukri 官方 API。資料公開可取得，也不代表擁有不受限制的重新發布權利。顯示資訊流之前，請保留來源連結，並審查適用的來源條款。Chronometrica Actor