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 年经验。用数字替代未知值会产生错误信息。

这种存储方法让工具选择在首次请求之后仍有价值。门户在存储、计数和展示采集记录时，必须保留这些记录的原有含义。

哪些情况下这项推荐不再适用

Chronometrica 的保存记录数上限让采集范围更明确，但不能证明已保存记录包含所有匹配的职位信息。如果你的原始要求是保存全部结果，而结果数量超过所设上限，那么在该配置下，Chronometrica 无法满足这一要求。Chronometrica 保存记录数控制选项

提高上限不能证明已完整覆盖来源。提高 `searchDepth` 也不能证明。已核查的证据无法证明完整性。评估工具时，请保留获取全部结果的要求。不要用更小的样本替代它，再宣称已满足要求。

每项验收检查回答的问题不同。有效输入说明结构符合允许的要求。保存的记录记载了一次观察。检查过的申请页面可提供该页面在审核时状态的证据。任何一项检查都无法单独回答全部 3 个问题。

Chronometrica 是独立的 Actor API，并非 Naukri 官方 API。公开可访问也不代表拥有不受限制的转载权。展示职位数据流前，请保留来源链接，并审核适用的来源条款。Chronometrica Actor