Bing 搜索结果导出：Chronometrica 与 Axiom Works 对比

先确定如何发现页面

读者的问题始于页面抓取之前。你需要先找到可能包含有用内容的 URL。选择搜索 Actor，就是选择哪些搜索记录和结果类型能支持这项工作。

一则关于在抓取前查找 URL 的公开提问，表明了这种页面发现需求。所提供的来源是一段搜索摘录。它没有定义完整的抓取要求，没有推荐这 2 款产品中的任何一款，也不能证明搜索摘要包含所需的页面正文。

用 1 句话定义项目可接受的目标页面。在一个虚构的教程项目中，规则可以是：“接受包含 1 节完整机器学习课的公开页面。”这样，你就有了一条在发现页面后应用的内容要求。

接下来，确定需要哪些搜索结果类型来发现这些页面。按文章开头给出的条件选择产品。清晰的观测记录适合本文所述的小规模页面发现任务。如果还有其他发现需求，产品选择可能会改变。

将这些判断分开。搜索 Actor 提供候选页面和搜索证据。目标页面检查则判断候选页面是否符合内容规则。搜索导出适合你的需求，不代表它返回的每个页面都适合。

为什么 Chronometrica 适合有数量上限的观测记录表

一条观测记录，是保存在查询上下文中的 1 条搜索结果。同一个目标页面如果出现在多个查询中，就可以产生多条观测记录。

Chronometrica 文档为每条观测记录列出了以下字段：

• `runId`：与这条观测记录关联的采集运行。
• `engine`：所用的搜索引擎。
• `executedQuery`：实际使用的完整查询。
• `page`：搜索结果所在的页码。
• `rankOnPage`：结果在该页中的位置。
• `rank`：记录的结果排名。
• `canonicalUrl`：Actor 记录的目标 URL。
• `resultDomain`：结果的域名。
• `observedAt`：观测时间。

这些字段定义了文档所述的各搜索引擎和查询的记录结构。输入还为每个实际执行的查询提供了数量上限。Chronometrica 输出与输入文档

这种结构能帮助你回答一个实际问题：这个页面为什么进入队列？你可以追溯到完整查询、记录的排名和观测时间，无需根据 URL 列表推测这段历史。

假设一个页面出现在发现请求中的 2 个查询结果里。请保留这 2 条观测记录。它们记录了该页面在搜索中出现的 2 次情况，尽管你只需要检查 1 个不同的目标页面。

这就是有证据支持的 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 条观测记录。

这是一种多对一关联：多条搜索观测记录可以指向 1 个目标页面条目。它既能保留页面发现历史，又能让你分别评估每个不同的目标页面。

计数单位很重要。8 行搜索观测记录和 5 个候选页面描述的是不同事物。这 2 个数量都不能说明最终会接受多少个页面。

假设后续检查接受了 3 个页面，拒绝了 1 个，还有 1 个待确定。这些结果也是虚构的。在有足够证据作出判断前，待确定页面应保持未知状态。不要将它计为空文档，也不要用 0 替代缺失值。

按 5 个步骤完成产品选择和页面检查

1. 定义目标页面要求和发现需求。说明合适的页面必须包含什么内容。确定需要哪些搜索结果类型。采集前，按产品选择条件作出决定。

使用其他人也能检查的规则。“有用的页面”留下了太多不明确之处。虚构规则“包含 1 节完整机器学习课的公开页面”，则为目标页面审核给出了明确目的。

1. 选择 Bing，并设置数量上限。使用 Chronometrica 时，设置 `engines: ["bing"]`，并在文档规定的范围内设置 `maxResultsPerExecutedQuery`。确认该上限符合原始要求。Chronometrica 输入文档

记录计划使用的查询集和范围。如果要求超出数量上限，请在运行前解决产品选择问题。不要将数量有限的结果集描述为完整覆盖。

1. 保留每条观测记录。为每条结果保留搜索引擎、完整查询、排名和观测时间。导出时也保留文档列出的其他上下文字段。

删除重复目标页面前，先保存这些记录。除非保留与原始观测记录的关联，否则去重后的 URL 列表无法显示哪些查询找到了各个页面。搜索摘要属于这类搜索证据，不是已获取的目标页面文档。

1. 另建目标页面队列。URL 规范化是指将可比较的 URL 形式转为一致形式。应用明确规则，然后删除重复的目标页面条目，同时保留原始搜索记录。

不要假定 URL 的所有差异都没有影响。查询参数可能会改变内容。只有规则支持将条目视为同一目标页面时，才合并条目。让每条观测记录都保留与其队列条目的关联。搜索结果去重指南 更详细地解释了这一步。

1. 获取并评估每个允许访问的目标页面。获取页面是指请求目标页面本身。使用前，检查其内容和来源状态。将结果记录为已接受、已拒绝或待确定。

返回的 URL 标识了一个候选页面，不能证明已成功获取该页面。搜索摘要不能替代页面检查。完整的接受判定方法，请参阅如何根据 Bing 搜索结果建立抓取队列。

采用流程前，先检查导出结果

根据已写明的需求，审核一小组输出结果。首先检查搜索记录。确认每条观测记录都能找到实际执行的查询和记录的排名。检查重复目标页面是否关联到同一个队列条目，同时保留了各自的搜索历史。

接下来，检查对目标页面作出的判断。接受页面需要有证据证明它符合规则。拒绝页面需要有拒绝理由。待确定页面需要保留未知状态。

这种区分能避免把未成功完成的页面检查变成错误的内容结论。如果你无法评估页面，就还不知道它是否包含所需材料。

分别统计各阶段的数量：搜索观测记录、不同的候选 URL、已获取页面和已接受页面。一个阶段的数量不能确定下一阶段的数量。虚构示例说明了为什么 8 行搜索记录可能对应 5 个候选目标页面，而最终接受的页面更少。

所提供的证据没有证明价格、速度、准确性或可靠性方面的实测优势。推荐依据是文档所述的观测记录和每个查询的数量上限。如果你的任务是在批准目标页面前保留一小组 Bing 页面发现记录，这些优势就很有用。