利用LLM评估进行更好的实验——是漏斗，而非分叉（阅读时间约6分钟）

# 用 LLM 评估实现更好的实验——漏斗，而非岔路 | Spotify Engineering 来源：https://engineering.atspotify.com/2026/5/better-experiments-with-llm-evals-a-funnel-not-a-fork **TL;DR** LLM 评估（即能够规模化评估相关性、连贯性和质量的自评裁判）是一种强大的新工具。与在线实验相结合，它们能提高测试的命中率，并形成一个反馈回路，让评估和实验随时间推移都变得更加智能。 --- 在 Spotify，大约只有 12% 的 A/B 测试最终以成功上线告终。大约 64% 产生了有效的经验：发现了回归、排除了一个想法、改进了假设。胜率低估了实验的价值。(https://confidence.spotify.com/blog/experiments-with-learning) 现在我们拥有了一项新能力。**LLM 评估可以衡量我们之前无法规模化的维度**（相关性、连贯性、语气、意图对齐），比人工标注更快、更便宜，适用于从测试集到 A/B 测试变体的任何数据。评估和实验衡量的是不同的事物。正确的关系是漏斗，而非岔路。Schultzberg 和 Ottens (2024) (https://arxiv.org/abs/2404.08671) 将其称为**评估漏斗**，其中评估属于实验*之前*，而不是*替代*实验。一个强大的评估堆栈意味着，你进行测试并不是为了查明改动是否达到预期——评估已经告诉你了。**你进行测试是为了验证预期的改动是否驱动了它本来要驱动的业务成果，并避免对业务造成损害的风险。** 验证 - 验证 - 校准 - 实验 ## 评估带来了什么，以及无法带来什么 Schultzberg 和 Ottens 区分了*验证*和*确认*。评估负责验证：输出是否符合质量标准？实验负责确认：真实用户的反应是否如预期？评估在它们消耗实验带宽之前就摒弃了没有前景的候选方案。**它们提高了后续实验的命中率。** **评估还能产生假设**。假设一个团队构建了一个 LLM 裁判来标记破坏信任的内容，比如一个不适用于用户的推荐。该裁判发现了团队未曾寻找的模式。这些模式变成了产品修复。修复上线后，同一个裁判可以验证它是否有效：标志的违规行为应该会下降。这就是评估发挥的两项作用：发现需要改进的地方，并确认改进已经实现。 评估无法告诉你的是，收到改进版本的用户是否确实获得了更好的结果：修复是否阻止了最终导致流失的信任缓慢侵蚀。这个问题需要实验来解决。 除了你正在衡量的维度，还有你未衡量的维度。在 Spotify，团队会回滚大约 42% 的上线实验，以防止次要指标出现回归：会话时长下降、崩溃率上升、留存率下滑。这些都没有被任何评估或离线评测标记出来。正如我们在关于护栏指标的工作中所描述的 (https://confidence.spotify.com/blog/better-decisions-with-guardrails)，护栏的作用是关注你关心但暂未优化的维度。评估衡量的是某个维度的实现质量。实验量化的是对生产系统和最终用户的影响。 ## 两个校准层，一个反馈回路 评估是代理指标。它们用一个分数替代了你实际关心的结果。这种替代只有在分数能追踪到真实结果时才有效——这和我们之前关于代理指标的论述相同 (https://confidence.spotify.com/blog/proxy-metrics)。 现在，LLM 裁判在传统量化指标（排名分数、精确率、召回率）之上又增加了一个校准层。这两层都需要通过与在线结果进行验证来确认其有效性。两者都可能发生漂移。当裁判说变体 A 更好时，它是否真的带来了更好的用户体验？还是裁判在奖励那些不驱动结果的表面模式？ 例如，当 Anthropic 发布 Opus 4.5 模型时，Qodo 的编码评估显示没有改进 (https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)，但该模型在较长的任务上有显著提升，这本应通过受控实验才能浮现。校准偏差是双向的。**没有离线-在线信号的校准，我们的评估只是观点，而非证据。** 由于设计上的限制，长期运行的任务和长期行为很难通过评估来捕获。通过持续调整评估，使其更好地映射到在线结果，评估正在成为越来越好的*验证*工具。我们并不排除未来随着 AI 的发展，评估能够充分映射到足以开始充当*确认*工具：通过建立离线/在线校准回路，我们能够持续透明地了解，随着 AI 不断进步，评估在评估漏斗中*可以扮演*什么角色。 面临速度压力的团队有时会说 A/B 测试“成本高昂”。根据我们的经验，未经实验就上线可能代价极其高昂——如果核心业务指标出现重大回归未被发现的话。系统越复杂，约束风险就越重要。 ## 闭环运行 尽早并频繁地运行评估，以找到最佳处理方案。然后通过实验来验证真实用户和系统是否如预期响应，并监控你未优化的指标。并非所有更改都需要同等程度的证据：用于快速方向性测试和收集数据的迭代可以宽松一些，用于上线的决策则需要严格验证。 然后：在 A/B 测试数据本身上运行你的 LLM 评估。裁判偏好的版本在用户那里的表现是否真的更好？这扩展了传统的评估漏斗。LLM 裁判让我们不仅能够问“指标是否发生了变化？”，还能问“定性的方面是否发生了变化？” 当评估分数与实验结果之间的差距较大时，这本身就是诊断的黄金信息。每个周期都有助于校准下一轮。 回到标记破坏信任推荐的团队：实验是最后一步。如果收到改进版本的用户显示出更好的长期参与度，团队就证实了裁判所衡量的内容确实重要。如果裁判得分提高了但用户结果没有变化，那就是校准信号：裁判捕捉到了某些东西，但不是真正驱动价值的东西。这两种结果都让系统变得更智能。 Spotify 已经通过实验形成了强大的评估文化。LLM 评估将这种文化推向上游，在漏斗中扮演着明确的角色：在实验之前找到最佳处理方案，并在实验之后校准裁判。正如 Ankargren (2025) (https://confidence.spotify.com/blog/experimental-evidence) 所论证的，成功来自于规模化地做好基础工作。**当系统既简单易用又足够严谨值得信赖时，其价值会成倍增加。**