代理网页搜索工具：衡量研究决策质量

摘要：

• 搜索质量和答案质量需要分别度量。 相关候选结果仍可能产出缺乏支撑的推荐。
• 每个指标都需要声明其适用总体。 排除未解决的任务会让代理看起来更好，却不一定改善其调研能力。
• 论断支撑需要文本与证据之间的关系。 URL 数量无法证明答案中的实质性断言是否被正当支撑。
• 无抓取的结构化搜索结果支持可审查的发现过程。 在你的应用读取与决策记录旁保留其上下文。

---

引言：一个相关结果仍可能导向错误答案

代理的网页搜索工具参与的是一串决策链。代理会理解问题、选择查询语句、挑选候选结果、阅读源材料并决定要说什么。把这整条链当作单一事件来打一个质量分数，无法解释答案究竟哪里出了问题。

在采购场景中，这种区分尤为重要。服务提供者也许提供了合适的公共来源，但应用读取的是其中过时的章节。另一条工作流也许在收到高质量候选的情况下，仍然选了一个薄弱来源。两者都可能产生糟糕答案，而更换搜索服务只会解决部分可能的原因。

Scrapeless Google Search API 在发现阶段提供结构化结果。为了公平评估这一组件，需要将其输出纳入对整个任务的明确度量设计中。本文提出了一个用于研究型应用的指标词典、评审流程和对比方法。文中不给出任何实测分数、响应示例或基准结果。

在定义分数之前先定义分析单元

研究类度量需要可识别的分析单元。在你的记录中，将用户任务、搜索操作、候选结果、获取到的文档和答案中的论断彼此区分开来。

一个任务可以包含多次搜索操作。同一来源会出现在不同的结果位置，或通过不同的查询被发现。最终答案中可以包含由同一文档支撑的多个断言。若把这些单元压缩在一起，可能会夸大表面覆盖率，或掩盖重复劳动。

以一个假想的产品政策助手为例，任务是用户关于特定产品和适用地区的请求。搜索操作是寻找相关材料的尝试。获取到的政策文档是证据。陈述符合条件的那句话是一个论断。每个单元都回答着不同的评估问题。

这种区分也有助于将模型的已学知识与检索到的材料区分开来，这一区分在检索增强生成研究中已被明确。一个正确答案并不能证明工具提供了相应证据。你的评估应当考察：该论断是否得到了在这条工作流中实际可用材料的支撑。

编写带有显式分母的指标词典

指标词典应说明计入什么、哪些情况有资格被计入，以及如何处理缺失观测。在向仪表盘中加入计算之前，先用文字性定义，让评审人员可以一致地加以应用。

将候选结果相关性定义为：在抽样策略下被评审的候选结果中，被判断对任务信息需求有用的比例。它的分母是被评审的候选集合，而不是网页上的所有页面。将获取完成度定义为：在选定的文档中，通过允许的采集路径成功获得所需文本的比例。这两个指标都不是答案接受度分数。

将“有支撑论断覆盖率”定义为：评审人员能够为之找到充足证据的实质性事实论断所占比例。要说明什么是“实质性论断”。一段无伤大雅的引言句子，不应稀释一个决定推荐结论、却缺乏支撑的断言的影响力。

数据质量词汇（Data Quality Vocabulary）的质量概念为区分一次评估与普适质量标签提供了有用的基础。你的指标词典应当写明任务和判定规则。缺乏这些上下文的分数看起来或许精确，却依然难以解释。

保留“缺失”和“未观测”之间的差别

不能悄悄把一次不可用的观测当作负面搜索结果处理。要记录工作流是否发起了搜索、响应是否可用，以及是否获取到了相关来源内容。
假设一个假想的助手被问及某项公开的保修条款。搜索阶段返回了候选结果，但无法通过获准的渠道获取所需的政策文本。该任务并不能据此认定该条款不存在，只能说明应用当前可用证据存在限制。

对已接受、部分支持、未解决、被拒绝和被取消的工作使用不同的任务结果类别。它们是为应用提出的分类，而不是搜索提供方承诺提供的字段。保留每个类别背后的原因，以便审查人员能够区分证据不足、政策限制或用户取消。

在决定这些观察应归属何处时，AI 产品的搜索锚定场景很有帮助。结构化发现可以让搜索阶段变得可审查，而你的应用必须维护后续的证据状态。不要仅仅因为文档获取阶段未能完成其独立的任务，就把这归咎为工具层面的质量缺陷。

在“主张”层面进行支持度判定

对主张进行审查时应当问：引用材料是否足以证明特定断言。仅仅话题相同或提到同一家公司是不够的。

在保修的例子中，一个来源可能证明“确实存在保修”，但并不能说明它是否适用于请求中提到的国家。关于地区适用性的主张需要对应的适用条款。一份针对不同产品版本的资料，可能作为相关背景有用，但在实际支持测试中仍然不合格。

在段落引用及任何限定说明旁边记录支持度判定。有用的区分包括：直接支持、有条件支持、矛盾以及材料不足。当主张本身需要缩小范围时，避免强行把所有证据塞进“正确/错误”的二元标签。

派生信息的来源（provenance）这一概念有助于组织这种关系。保留主张依赖的已获取文本以及产生答案的转换过程。这样引用就可以作为一种证据关系被审视，而不是在回答中被当作装饰性元素来凑数。

Start Scraping with Scrapeless

使用 Scrapeless 强化你的网页抓取和自动化工作流程！
立即注册即可获得 5 美元免费额度 —— 无需信用卡。

立刻在 Scrapeless 控制面板 领取你的免费额度。

在不把镜像当成多个来源的前提下衡量来源独立性

独立佐证要求有不同的证据来源，而不仅仅是不同的 URL。一份被拷贝的公告、一篇联合发布的文章以及一则引用该文章的摘要，都可能依赖于同一条底层声明。

对于需要佐证的任务，应要求审查人员记录每一条实质性主张的表面来源。发布方自己的政策与独立测试，可能提供不同类型的证据。多页复刻同一份政策文档对发现阶段仍然有帮助，但未必能构成独立的相互印证。

资源标识也需要谨慎处理。资源标识符通用语法为解析 URL 提供了基础，但你的去重策略必须保留诸如文档版本和适用法域等有意义的区分。不加区分地移除所有查询参数，可能会把本应独立的证据合并在一起。

在选定的标识键之外，保留原始发现的地址。当评估者质疑一次合并操作时，这条记录可以让团队检查当时实际看到的内容。其目的不是最大化“独立来源”的数量，而是弄清答案是否依赖了足够恰当的证据。

将工具运行时间与获得“被接受答案”的时间分离

获得一个被接受答案的时间包含了用户实际依赖的所有阶段。仅搜索时长应作为一个组成指标，并清晰定义其起止事件。

记录应用接受任务的时间、开始搜索操作的时间、收到可用候选结果的时间、获取所需材料的时间以及作出最终决策的时间。对于涉及人工审批的工作流，要区分自动处理时间与排队等待审查的时间。用户可能同时关心这两者，但它们反映的是不同的约束条件。
要在记录时钟时保持一致，并在时间戳表示的同时保留事件语义。没有定义起始事件的完成时间，会把排队、用户暂停和执行时间混在一起。跨版本比较这个数字无法单独隔离搜索改进的效果。

对于一个代理型网页搜索工具，还要观察额外搜索有多频繁地改变答案的“证据状态”。额外操作可能产生有用材料，也可能只是重新访问熟悉的候选项。这是一个应用层面的效率问题。要把它当作一个需要观察和研究的对比，而不是预设更多操作总是代表更深入的研究。

在版本对比中纳入未解决任务

版本对比应当保留预期工作负载，其中包括未能达到被接受答案的情形。否则，系统可以通过回避困难问题来提升表面上的得分。

使用固定的评审集合，将拟议变更与当前应用进行对比，然后检查结果分布。如果支持的答案增加的同时，未解决任务也增加，就要分析是哪些用户群体或问题族发生了变化。单一平均值可能掩盖这样的情况：改进让某一用例获益，却损害了另一用例。

在新引入的问题族确立评审标准之前，应将它们单独处理。增加一个容易发现的类别可以提高整体接受率，却并未改善产品原先承诺要解决的那些困难政策问题。同样地，增加更严格的评审规则可能降低评分，却使应用更加诚实。

明确说明被用户中断或被策略阻止的任务的处理方式。它们应保持可见，但正确的分母取决于所衡量的问题。如果定义解释清楚原因，“获客指标”和“用户完成指标”可以合理地使用不同的任务总体。

利用评审分歧改进评判标准

评审员之间的分歧表明测量规则需要关注。要保留关于来源适用性、论断范围和重要性的分歧，而不是立刻用平均值把它们抹平。

让评审员解释导致分歧的段落或任务条件。如果一人认为地域限定是关键，另一人却忽略它，产品团队就需要决定用户被承诺的到底是什么。解决方案可能是更清晰的接受规则，而不是更换搜索提供方。

用授权材料建立一个小型的裁决示例库。每个示例应展示问题、相关来源段落、提出的论断以及裁决理由。重点放在那些曾引起混淆的细微差别上。这样评审员在遇到不熟悉的任务时就有一个实用参考。

这一过程还会产生更好的采购问题。你的团队可以询问：某项服务是否暴露了足够的上下文，便于检查候选相关性和来源选择。当前的 Scrapeless 定价可以根据这一运营要求进行评估，收集与评审工作可分别预算。避免把一个有利的“候选相关性”结果，偷换成对“最终答案准确性”的未测量保证。

构建能指向责任人的仪表盘

有用的研究仪表盘会把每个缺陷连接到一个阶段和一个负责团队。每个展示的度量都应触发某种调查，而不是单纯奖励数字变大。

候选相关性低，指向的是查询改写、收集上下文或发现契合度的问题；候选合适但来源选择薄弱，指向的是应用策略的问题；来源文本有力却得出不被支持的论断，指向的是推理或答案评审的问题；评审队列不断扩张，则指向产能不足或任务承诺过宽的问题。

Google Search 解决方案总览展示了如何将持续的搜索收集连接到业务决策上。内部也要应用同样的纪律：为每个研究度量决定它能授权什么行动。仪表盘不应在没有明确定义的决策流程下，就自动改变对外宣称、扩展搜索权限，或宣布某个来源值得信赖。
对于架构规划，搜索 AI 应用使用的参与方有助于将“发现”与其他收集界面区分开来。即使这些阶段共享同一供应商或出现在同一智能体界面中，也要在度量中保持它们可被识别。你的评审者需要知道自己在评估系统的哪一部分。

结论：度量工具所支撑的决策

代理式网页搜索工具应通过一条从任务到候选、获取的证据以及被支持的论断的清晰链条进行评估。定义评估单位，保护分母，并保留那些暴露应用边界的未解决案例。

Scrapeless 为团队提供了一个可在该链条中进行评估的结构化发现界面。一个有用的下一步是：为一个窄范围的任务族编写度量词典，裁决含糊示例，并在采购或发布评审中使用得到的定义。这样得到的分数就描述了一个你的团队能理解的运行承诺。

准备规划你的搜索研究应用了吗？

在 Discord 和 Telegram 上与开发者分享实际问题。

在你的研究工作流中探索 Scrapeless，配合已定义的问题族和你的团队可以评估的证据标准。

常见问题

问：代理式网页搜索工具的最佳指标是什么？

代理式网页搜索工具需要多个特定阶段的度量，而不是一个通用分数。候选相关性评估发现阶段，而被支持论断的覆盖率和被接受任务的结果则评估后续应用责任。

问：引用能证明答案得到支持吗？

只有在其来源材料在请求范围内证明了相关论断时，引用才算支持答案。仅仅统计链接数量无法建立这种关系。

问：未解决的任务应当算作失败吗？

未解决的任务应当连同其原因保持可见，并按照该指标声明的符合条件总体被纳入统计。它们可能反映的是证据不足、收集限制或政策边界，而不是搜索相关性上的缺陷。

问：不同 URL 可以算作独立来源吗？

不同的 URL 可能代表同一底层证据。在将它们视为独立佐证之前，应审查其来源及内容关系。

问：团队如何公平比较应用的不同版本？

团队应在一个稳定的任务集上比较不同版本，并采用相同的评审规则、结果类别和统计边界。在解读整体平均值之前，先按任务族来审视变更。