@Similarweb 如何在无标准答案的情况下评估深度研究型代理：

• 对工具调用的确定性检查
• 基于评分标准（Rubric）的 LLM 裁判质量评估
• 对检索数据的忠实性检查
• 与保存的基线进行 A/B 比较 所有结果都通过 LangSmith 连接到追踪。

SimilarWeb 如何使用 LangSmith 评估代理报告

来源：https://www.langchain.com/blog/how-similarweb-evaluates-long-form-agent-research-reports-with-langsmith 作者：Liora Korni，SimilarWeb 高级 AI 工程师

你是否有过这样的经历：发布了一个新的代理提示词、模型或工具更新，检查了第一个输出感觉不错，但心里仍然不踏实？一个输出看起来变好了，但另一个却丢失了来源归属、遗漏了重要注意事项，或者开始过度依赖单一数据源。

这是代理构建者面临的典型问题。在传统软件中，一个修改要么通过测试，要么不通过，行为是可重复的。而代理系统则不同：相同的输入可能走不同的路径，调用不同的工具，产生不同但仍然有效的答案。每一次更新都是一场赌注——系统到底是变好了，还是你只是把故障转移到了别处。

这就是我们在构建 Similarweb Data Studio 时面临的问题。Similarweb 衡量数字世界，估算网站和应用的流量、流量来源、竞争对手表现以及受众注意力转移的方向。Data Studio 是构建在这些数据之上的代理层。用户不再需要操作仪表盘和筛选器，只需用自然语言提问，代理就会规划工作、调用正确的数据工具、检索数据并撰写答案。它可能处理一个快速查询（比如“spotify.com 有多少直接流量？”）、一个竞争对手比较，或者一份完整的多步骤研究报告。对于每个请求，它自行决定如何达成目标，而不是遵循固定脚本。

一个代理系统不仅仅生成文本。它会选择工具、检索数据并综合证据，因此回归故障可能隐藏在任何一步中。这就是为什么评估必须成为产品架构的一部分。我们需要一个工作流，能够显示哪些案例发生了变化、哪些质量维度发生了变动、评估者说了什么，以及追踪记录了哪些操作。

LangSmith 将这一工作流整合在一个地方，并使每个结果都可被检查，从分数一直追溯到背后的追踪记录。

本文你将获得什么。 如果你正在构建代理、RAG 流水线，或任何输出具有开放性、主观性或长篇幅特征的 LLM 功能，并且你曾在发布某个修改前犹豫不决，那么这篇文章就是为你写的。读完本文，你将了解：

• 如何在没有单一正确答案的情况下评估代理；
• 基于评分标准的 LLM 裁判提示如何工作，以及它相对于确定性检查的适用场景；
• 如何在 LangSmith 中连接数据集、反馈、追踪和 A/B 比较，使得每个分数始终能追溯到背后的推理和行为；
• 为什么一个校准不当的评估比没有评估更糟糕，以及如何避免让我们浪费了一周的校准陷阱。

评估输出的两种方式：确定性检查与 LLM 裁判评分

我们对代理输出运行两种检查。

第一种是确定性检查。代理是否调用了所需的工具？是否碰了不该碰的工具？是否返回了有效的结构化输出？这些是机械化的通过/失败比较，不涉及模型。

第二种是LLM 裁判（LLM-as-a-judge）。当我们关心的东西是意义或质量时，确定性规则就不够用了，因此我们将决策权交给一个模型。裁判提示向该模型提供三样东西：1）用户问题，2）代理输出，3）评分标准。然后返回一个分数和一段解释该分数的评论。评分标准可以是一个黄金答案（“内容是否一致？”），或者带有明确评分锚点的评分框架（“在每个质量维度上表现如何？”）。

我们将裁判视为一个可扩展的评审员。它产生可检查的信号——分数、背后的推理以及指向追踪的链接——这样我们就能看到代理实际做了什么。

两种检查在同一个评估循环中运行，并在 LangSmith 中作为反馈并排显示。对于我们来说，更难的问题是：裁判应该根据什么来评分？

简单情况：常规聊天

在代理系统中，最容易评估的情况是常规聊天。

说明：常规聊天：焦点明确的问题，答案形状更可预期。

每个基准示例都有一个固定的提示词、一个黄金答案、预期的工具检查，以及一个代理输出。我们可以将输出与黄金答案进行比较，验证代理是否调用了所需工具，并随时间追踪分数。

experiment_results = await aevaluate(
    target,
    data=dataset_id,
    evaluators=evaluators,
    experiment_prefix=experiment_prefix,
    num_repetitions=num_repetitions,
    max_concurrency=max_concurrency,
)

两种检查都在这里出现。工具检查是确定性的。然而，将输出与黄金答案进行比较，这需要 LLM 裁判来完成，因为正确的答案可以有多种表述方式，精确文本匹配过于脆弱。这个裁判就是锚定到黄金答案的 semantic 评估器。它唯一的问题是输出是否意味着相同的事情。

每个评估器返回一条反馈：一个键、一个分数和一条评论。对于上面按渠道分解流量的问题，semantic 裁判会返回类似下面的内容：

{
    "key": "semantic",
    "score": 0.7,
    "comment": "在前几个渠道（直接和自然搜索）上与参考答案匹配，并且直接流量的份额正确，但遗漏了黄金答案提到的引荐流量，因此接近但不完整。"
}

LangSmith 将这种反馈转化为实验列。这样我们就不用在电子表格中收集分数，而是可以比较运行，点击分数，并检查背后的追踪记录。

对于常规聊天，这就足够了。有一个预期答案，所以确定性检查和一个锚定到它的语义裁判覆盖了大多数重要内容。

困难情况：深度研究

深度研究的输出是包含来源、解释、建议、注意事项和叙述结构的长篇报告。对于同一个问题，可能存在多个优秀的报告。

说明：深度研究：开放式问题，可能产生多个好的报告。

一份优秀的报告可能侧重于流量获取。另一份可能侧重于竞争定位。还有一份可能侧重于变现风险。只要主张有根据、推理合理，所有报告都可以是有效的。

黄金答案在这种情况下不太适用。因为没有单一的参考对象，匹配一份参考报告只会奖励相似性，而非质量。因此，我们不给裁判一个参考，而是给它一个评分标准：每个质量维度都有自己的评分框架，并带有明确的评分锚点，这样裁判会返回每个维度的分数，而不是一个整体 verdict。例如，source_integration 标准询问报告是否在原始平台数据之外有效整合了外部来源：

source_integration:
报告是否在原始平台数据之外有效整合了外部来源？
评估来源整合的多样性和质量。

Score 0.0: 完全依赖单一数据 API，没有外部背景。
Score 0.3: 模糊提及外部来源，例如“根据行业报告”。
Score 0.8: 引用多个具名来源，包含日期、数据和背景。
Score 1.0: 使用大量、有归属的来源，并很好地融入叙述。

返回：
- source_integration: 0.0 到 1.0 的分数
- source_integration_gap: 差距的简短总结
- source_integration_detail: 一句解释该分数的话

每个标准返回一个分数和一段简短解释，这样低分数总是附带着可检查的原因。一个来源薄弱的报告会得到这样的结果：

{
    "source_integration": 0.3,
    "source_integration_gap": "外部背景只是暗示，从未注明出处",
    "source_integration_detail": "几乎完全依赖 Similarweb 流量数据，两次提及“行业报告”但没有说出任何一个来源、日期或数据。外部背景是装饰性的，而非证据性的。"
}

在质量评分标准之外，我们还运行忠实性检查来验证：每个主张是否确实来自检索到的数据，还是代理夸大了来源支持的内容？ 自信但没有根据的表述会在这里显现出来，这在输出较长且具有说服力时最为重要。

评分标准和忠实性检查会评估报告本身的质量。为了判断新版本是否确实更好，我们还会运行与基线的 A/B 比较：基线是一个保存的、之前已被接受的运行结果，我们将其视为参考点，而非绝对真理。裁判会同时看到新报告和基线，并指出哪个更强，而不是孤立地评分。

LangSmith 将评估分数连接到追踪记录和基线比较

编写评估提示词只是工作流的一部分。更困难的部分是重复运行循环，并决定一个修改是否真正有效。

LangSmith 使这成为可能，因为没有任何东西是孤立的。aevaluate 在一个固定数据集上运行循环，带有重复和并发设置；每个评估器分数都作为一个列出现，每个分数都附带其评论，每次运行都直接链接到追踪记录和一个用于比较的基线。区别在于数字、评估者推理以及背后代理行为之间的连接。

我们不再只问“平均分变动了吗？”，而是可以问：

哪些案例变动了？哪些标准变动了？评估者说了什么？追踪记录中发生了什么？

这就是评估作为记分板与评估作为构建代理系统的工程工作流之间的区别。

校准不当的评分标准可能让好的更新看起来像回归

深度研究评估的第一个版本不但没有加快我们的速度，反而拖慢了进度。

我们做了一个小小的提示词修改，重新运行基准测试，整体分数下降了。于是我们将其视为回归：回滚、调整、重新运行。然后又来一次。每次报告看起来都不错，但分数却不断唱反调，而我们选择相信分数而不是自己的阅读。

我们花了几乎一周时间与自己的评估斗争，直到有人打开了每个标准对应的评论。当我们终于看到时，答案几乎令人尴尬……新的报告引用了更多来源，这提升了来源广度，但那些来源很模糊，这拉低了归因分。两个标准相互冲突，而总分掩盖了这种冲突。那个修改从头到尾都是没问题的。我们花了整整一周与一个校准不当的尺子较劲。

其中一个问题是冲突的标准——这正是让我们浪费一周的那个问题。从产品角度来看，我们学到了一件事：我们并不是为了更多的来源而要来源。我们需要的是命名、相关的来源，并且与具体主张绑定。

你可以在评论中看到校准不当。在我们修正评分标准之前，一份充满模糊引用的报告仅仅因为涉及了平台以外的内容就能拿到高分：

{
    "source_integration": 0.7,
    "source_integration_detail": "广泛的外部背景，九个引用，但大多数未具名（“行业报告”、“分析师预计”），所以归因很薄弱。"
}

分数奖励了广度；但评论已经知道归因很薄弱。一旦我们将评分锚点重写为奖励具名、可验证的来源而非原始数量，同一份报告就降到了 0.3 分，数字终于与推理一直以来所说的一致了。

另一个问题是错误的激励。如果简洁性比完整性得到更明确的奖励，报告就会变得更短，即使用户要求的是需要注意事项、方法和更广泛背景的战略研究。

在这两种情况下，变动的分数并不是最有用的部分。每个分数背后的评论和追踪记录才是让我们看到哪个标准校准不当以及为什么的原因。我们可以调试评分标准，而不是从总分中猜测。

一个校准不当的评估比没有评估更糟糕，因为它给你虚假的信心。在信任评估结果之前，我们必须问：评估者衡量的是我们真正关心的行为吗？

有效的工作流

一旦标准校准完毕，我们形成的循环是：

1. 从一个假设开始。
2. 运行一个小型评估获取信号。
3. 检查反馈评论和追踪记录。
4. 运行包含重复的完整基准测试。
5. 与基线或 A/B 输出进行比较。
6. 决定是合并、迭代还是重新校准。

最终要点：黄金答案、评分标准、追踪记录和基线服务于代理评估的不同部分

当存在预期答案时，黄金答案就足够了。长篇幅的代理输出则不同，因此它们需要评分标准提示、忠实性检查和 A/B 判断。

评估和可观测性应该共存。分数告诉你该看哪里，追踪记录告诉你发生了什么，反馈告诉你评估者为什么这样打分。

这改变了我们构建代理系统的方式。我们不再将评估视为发布前清单上的一个检查项。我们用它来塑造产品决策，例如：哪些行为值得优化、哪些回归是真实的、哪些提示词校准不当、以及代理需要在哪些地方改进工具使用或综合能力。

评估并不会取代人工判断。它让判断变得可检查、可重复，并与代理的实际行为相关联，这样每次更新都是基于证据，而不是基于一个看似不错的输出。