23 篇博文 含有标签「evals」

一个团队发布了一次提示词重构（prompt refactor）。离线评估显示准确率提高了三个百分点。产品经理（PM）在 Slack 上发布了图表。两周后，支持工单激增，出现了一个没有任何仪表盘记录的模式：用户信任了他们不该信任的答案，并据此采取了行动，结果蒙受了损失。模型比以前更准确了，但对模型的信任却变差了。

这就是“校准崩溃”（calibration collapse）。模型的置信度不再与其错误率相匹配，但由于准确率数字上升了，团队认为他们发布了一个成功的更新。其实不然。他们发布的是一个更加“自信地犯错”的系统，而用户——他们是根据模型的语气（含糊表达、确定性、拒绝回答）而不是他们从未见过的准确率数字来校准信任的——现在在那些被误导后果最严重的查询中被误导了。

准确率（Accuracy）和校准（Calibration）是独立的维度。你可以改变其中一个而不影响另一个。你可以在提高一个的同时摧毁另一个。大多数团队只测量第一个维度并以此为基准发布产品，而大语言模型（LLM）系统中的大多数生产事故都发生在第二个维度上。

你上线了新模型。综合评估通过率从 91% 提升到了 96%。产品团队在全体员工大会上宣布这是一次重大胜利。六周后，可靠性团队却迎来了有史以来最糟糕的一个季度——并不是因为故障变多了，而是因为现在每一个故障都需要三名工程师花上两天时间才能解决。

这就是智能体能力悬崖 (agent capability cliff)，它是生产环境 AI 中最反直觉的失败模式之一。模型升级并不会均匀地提升所有任务的表现。它们将增益集中在大部分流量上——即那些旧模型原本就能在大部分时间内处理正确的简单和中等案例——而长尾中真正困难的输入却只看到了微乎其微的改进。你的失败面缩小了，但剩下的每一次失败都是能力边界案例，这些案例旧模型也处理不了，而且简单的提示词工程 (prompt engineering) 也无法修复。

这个“悬崖”并不是新模型的缺陷。它是我们衡量模型改进的方式（混合难度评估集的平均通过率）与值班排班中实际遇到的问题（最难流量的残差集，现在已经没有了以前占据主导地位的简单故障的缓冲）之间的不匹配。

你的评估套件通过了。质量仪表板显示为绿色。一周后，用户正在悄悄流失，没人能解释原因。评估集并没有通过犯错来撒谎——它的谎言在于它是一面镜子。你用来评分的标签，可以追溯到正是由你试图评估的那个模型家族生成或过滤的。通过这项评估并不是质量的证明。它证明了你的模型与其过去的输出是一致的。

这是成熟 LLM 流水线中一种隐蔽的失败模式：通过生产泄漏导致的评估集污染。这不同于著名的基准测试污染（即在 GSM8K 上训练的模型又在 GSM8K 上进行评分）——那个故事已经被讲烂了。更微妙的一种发生在下游。你的黄金标签来自用户反馈、来自先看到模型草稿的人类标注员、来自 RLHF 奖励追踪、来自 LLM-as-judge（模型即评委）的偏好数据。这些流水线中的每一个都将当前模型习语的指纹带回到了你的“基准真值”中。几个季度下来，测试集悄悄地记住了你模型的偏好，评估变成了一个自我表扬的循环。

每个在没有评估（evals）的情况下发布 AI 功能的团队都会对自己讲同样的故事：我们会以后再添加衡量标准，等到找到产品与市场契合点（PMF）之后，等到提示词（prompt）稳定之后，等到下一次发布之后。六个月后，提示词已经被四位工程师和两名产品经理修改过，其行为支撑着三个客户集成，团队发现“以后添加评估”意味着要从从未为此目的结构化过的生产日志中重建意图。本应开发新功能的季度变成了考古季度。

这不是规划错误。而是一个复利错误。为了更快发布而跳过评估的团队，正是那个将花费十二周时间从不完整的追踪（traces）中重建评估基础设施、为二月份所谓的“正确”含义争论不休、并悄悄移除没人能证明依然有效的功能的团队。追赶的成本超过了内置的成本——不是一点点，而是随着每一次未经回归检查就发布的提示词修改而倍增。

一个在提示词未发生任何更改的情况下，测试结果由绿转红的回归测试套件，通常源于以下三种情况之一：测试框架损坏、检索库不稳定，或者评估模型（Judge）在周末学习了“新口味”。第三种情况最常见，也最难调试，因为你的代码仓库里没有任何提交记录与之相关。评分模型在静默状态下完成了质量更新，你与上个月仪表盘对比的所有分数，现在都已经是在用另一种“货币”计价了。

这是 LLM-as-judge 令人不安的地方：你有两个处于变动中的模型，而不仅仅是一个。待测模型（Candidate Model）是你发布的产物；评估模型（Judge Model）则是告诉你待测模型表现如何的工具。当两者独立演进时，分数的变化量（Score Deltas）不再具有以往的含义，你家产品经理每天早上刷新的仪表盘正在悄悄地撒谎。

每个复杂的 AI 产品最终都会产生一个谁也不敢碰的 prompt。它包含三个条件分支，两个在处理客户报告的事故时临时粘贴进去的内联示例，以及一个以 “IMPORTANT:” 开头的句子，后面跟着一段没人记得是谁写的语气指令。这个 prompt 长达 1,400 个 token。最后一次修改它的 PR 是由一名早已转岗的工程师审核的。当新模型发布时，没人敢保证这个 prompt 依然有效。当评估（evals）结果下降时，没人确定是 prompt、模型、检索流水线还是下游工具导致的。这个字符串被四个服务共享。每个团队都有自己的本地覆盖（override），而且这些覆盖都没有文档记录。

这就是 Prompt 所有权问题，它是多团队 AI 工程中讨论最少却最普遍的失效模式。这不只是一个技术问题，而是康威定律（Conway's Law）在 token 层面的体现。一个组织的 prompt 最终会反映出它的组织架构、RACI 缺口和协作成本——而模型并不关心你的 Jira 层级，它只会为同样不在乎这些的终端用户产生不连贯的行为。

你刚接入的前沿模型对你的竞争对手早有定见。对于你产品旨在反驳的那些难题，它有一套默认答案。它对你所在的领域有一套“最佳实践”，而这些实践往往源于训练语料库中占据主导地位的内容；对于你在设计文档中反复纠结的每一个争议性决策，它都暗自偏向于传统做法。这些都不会出现在你的系统提示词（system prompt）中，也不是你写的。在涉及到你产品核心差异化的查询上，模型会先倾向于那些默认设定，而不是你告诉它的内容。

大多数团队在发布产品时，都把模型当成了一张可以任意配置的白纸。写好角色设定（persona），列出规则，粘贴品牌语气指南，运行几个能产生正确回答形式的 QA 提示词，然后就大功告成了。通过审核的提示词往往是处理简单查询的——在这些查询中，模型的先验认知（prior）恰好与你的预期相符。而那些真正有趣的查询，即如果产生通用回答就会让你的产品惨败的查询，几乎从未进入提示词迭代循环。在这些查询中，先验认知正在悄无声息地取胜。

200K token 的上下文窗口并不是真正的 200K token 窗口。将其填满，你刚刚付费使用的模型就会悄然变成一个更糟糕的版本——这种退化并非发生在“迷失在中间（lost in the middle）”所预言的中间位置，而是在右侧边缘，也就是近因偏差（recency bias）本应拯救你的地方。包装盒上的标签卖给你的是余量；而硅片卖给你的却是悬崖。

这是一种大多数团队尚未内化的不同失效模式。“迷失在中间”训练了一代提示词工程师（prompt engineers），让他们习惯于将关键指令放在开头，将关键问题放在结尾，坚信首因效应（primacy）和近因效应（recency）能确保信号得以传递。然而，当利用率接近宣称的窗口极限时，这种启发式方法会悄然失效。这种下降并非逐渐的、线性的，也与模型在半满状态下的表现不对称。一旦超过某个随模型而异的利用率阈值，你就进入了一个不同的运行机制，在 30K 时有效的提示词结构在 180K 时会彻底失败。

经济上的诱惑让情况变得更糟。如果你刚刚为百万 token 的窗口付费，那么使用它的压力是巨大的——你会倾倒整个代码库，喂入每一张支持工单，交给它季度财报，并让它找出重点。结果就是，你会得到一个看似推导严密、实则自信错误的答案，而在审计时它会瞬间瓦解。

一位队友提交了一个 PR，将你 Agent 的系统提示词（System Prompt）从 420 行重写为 380 行。Diff 是一片红绿交错的“惨状”：删除了段落、移动了章节、精简了语言。你批准了它，因为这些清理看起来很合理。一周后，退款请求的准确率下降了 8 个百分点，却没人能说出到底是哪一行导致的。

另一位队友在一条指令中添加了“简洁”（concise）这个词。Diff 只有三个字符。没人仔细审查它，因为几乎没有什么可看的。但这次修改导致 22% 的查询在工具调用（Tool-call）行为上发生了变化。

在生产环境中固定（Pinning）模型版本感觉像是一种工程纪律。你将 claude-opus-4-0 或 gpt-4o-2024-08-06 锁定到配置中，在 README 中写下原因，然后继续交付功能。输出分布不再发生偏移，评估（Evals）保持绿色，你上个季度做的提示词调优也依然有效。但实际上，你已经启动了一个静默计时器。十二到十五个月后，弃用通知邮件随之而来，三个冲刺周期（Sprint）的未记录行为依赖——提示词调优、评估校准、输出形状假设、温度特征（Temperature Quirks）——都会在瞬间到期结算。

这就是“交付即固定”（Ship-and-Pin）陷阱。从短期来看，固定版本是正确的，但从长期来看，它却是灾难性的，因为稳定性的成本会在你忽略的地方不断复利。一年前“足够好”的提示词，现在正以无人记录的方式承载着关键逻辑。你的下游服务所期望的 JSON Schema 是根据某个模型的分词习惯塑造的。你手动调优的少样本示例（Few-shot Examples）是针对特定模型对“有用性”的认知而优化的。当提供商停用该版本字符串时，这些依赖关系都不会自动迁移，而重新验证它们的工作总是在最后期限的压力下到来。

我接手时，我们客服智能体的提示词已经达到了 2,400 个 token，而编写它的工程师已经离职了。其中的每一条指令对于某些生产行为来说都是“承重的”，但没人能告诉我哪些才是关键。一条关于“在回答之前务必先复述用户问题”的条目看起来像是凑数的，直到我们删掉它后，CSAT（客户满意度）在一周内下降了四个百分点。事实证明，提示词就是规范（specification）。它既是实现（implementation），也是测试套件（test suite）——它是隐性的、未记录的，仅存在于那位已经离职的工程师脑中。

这就是“提示词即规范”的终局。提示词既是智能体应该做什么，也是它如何做，一旦提示词规模超过了单个作者的掌握范围，两者就会变得无法区分。你无法重构它，因为你不知道哪些行编码了需求，哪些行仅仅是暗示。你无法评审变更，因为没有可以与之对比的基准产物。你无法让任何人接手并负责它，因为负责意味着“最近阅读过全文并记得每一项条款存在的原因”，这是一项没人愿意批准的、长达六个月的投资。

“规范优先”颠覆了这种顺序。契约（contract）——输入、输出、不变量、错误情况、拒绝语义、升级触发条件——是一个先于提示词并约束每次修订的一等产物（first-class artifact）。对提示词的修改变成了针对规范的补丁（diff），而不是对规范本身的重写。这种转变听起来很官僚，直到你看到它所释放的潜力：评估（evals）源自规范而非反之，评审只需几分钟而非整个下午，最终能让新工程师在没有六个月学徒期的情况下直接接手整个模块。

常见的失败模式不是构建了不起作用的AI功能，而是在不知道功能是否有效的情况下就将其上线。团队跳过评估基础设施的原因不是懒惰——而是构建评估需要标注数据，而在第一天你根本没有。

这就是评估的冷启动问题。要获得有效信号，你需要系统在生产环境中运行。要有信心地部署，你首先需要评估基础设施。这种循环依赖是真实存在的，它导致团队做出三种选择之一：没有评估就上线，在生产环境中才发现故障；延迟上线，同时花数月时间手动标注数据；或者使用合成评估——并承担其中的所有风险。

本文讨论的是第三条路如何正确走通。合成评估冷启动是可行的，但前提是你要理解它无法检测什么，并从一开始就围绕这些盲点进行设计。