53 篇博文 含有标签「evals」

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）源自规范而非反之，评审只需几分钟而非整个下午，最终能让新工程师在没有六个月学徒期的情况下直接接手整个模块。

询问一个 Agent 团队他们的工具调用成功率是多少，你会得到一个答案。但如果你问他们的工具幻觉率（tool-hallucination rate）是多少，全场就会陷入沉默。大多数团队并不追踪这一指标，而那些追踪的团队通常也只计算最灾难性的版本——即目录中不存在的函数名——而那些更隐蔽、代价更高的变体则在生产环境中未受监控地运行。

幻觉化的工具调用不仅仅是指模型凭空捏造了 delete_orphaned_users(older_than="30d") 导致你的分发器（dispatcher）抛出 ToolNotFoundError。这是简单的情况。更复杂的情况是，虚假的调用通过模糊匹配隐匿地指向了一个相邻的真实工具，或者工具名称正确，但 Agent 捏造了一个参数，而你的 Schema 因为将其标记为可选而愉快地接受了它。这两种情况都能通过你的“工具调用是否成功”仪表盘，但都不是用户真正想要的。

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

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

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

构建 LLM 应用的团队总会犯同一个错误：他们等待积累足够的标注数据之后，才肯投入评估基础设施建设。他们告诉自己需要 5000 个样本，或者 10000 个。评估系统始终停留在待办事项清单上，而"感觉不错"的主观判断代替了真正的指标度量。ZenML 对 1200 个生产部署的分析发现，即便是成熟的部署，非正式的直觉判断依然普遍存在——许多团队从未真正建立起系统性的评估机制。

数据量直觉是从经典机器学习时代借来的——在那个时代，更多的标注样本确实能稳定提升模型性能。但对于 LLM 评估，这个直觉基本上是错的。对稀疏基准测试的研究表明，20–40 个精心挑选的样本就能可靠地估算完整基准的排名，而 100 个样本产生的平均绝对误差低于 1%，与使用数千个样本相比相差无几。问题不在于数据量，而在于大多数团队跳过了使小规模评估集值得信赖的结构化流程。

本文介绍这个流程的实际操作方式：如何通过主动学习选取合适的样本，如何用弱监督大规模生成噪声标签，如何借助 LLM 评判者进行冷启动，以及如何判断你的小型评估集何时可以正式使用。

你的评测套件得分 91%，但用户反映系统感觉不可靠。事后复盘发现了问题所在：你同时用 GPT-4o 来生成响应和评分。这个模型在评判自己的镜像，而它喜欢自己所看到的。

这就是裁判模型独立性问题。它比大多数团队意识到的更为普遍，产生的评分虚高幅度足以影响决策，而且修复方法既不复杂也不昂贵。但你必须知道从哪里找起。

大多数团队只有在账单出现时才会发现重试问题。智能体（Agent）“运行正常”；延迟仪表盘保持绿色；错误率看起来也没问题。然后财务部门询问为什么本月的推理支出翻了一番，这时才有人终于去翻看日志。结果发现，一个 3 步操作的智能体中，20% 的工具调用在静默重试，每次重试都重放了完整的提示词（prompt）历史记录，而账单已经连续几周在攀升。

这背后的数学逻辑并不神秘，但极其反直觉。20% 的单步重试率听起来还可以接受 —— 大多数工程师看一眼就会忽略它。但一旦考虑到现代智能体框架的重试方式，实际的 Token 成本会更接近 2 倍而非 1.2 倍。而且，这种失败模式对于团队通常关注的每一项指标都是不可见的。

重试预算（Retry budgets）—— 这是一个源自 Google SRE 工作的旧概念 —— 是最简洁的解决方案。但该模式的 LLM 版本需要调整，因为 Token 的行为方式与 RPC 不同。

你的团队花了三周时间构建了一个严谨的评估套件。它涵盖了各种边缘情况，包括对抗性示例。LLM 作为评测员（LLM-as-judge）在所有维度上的得分都达到了 92%。你发布了产品。

接着，客服工单接踵而至。用户反馈 AI “听不懂他们在问什么”。会话放弃率上升了 30%。满意度得分仅为 41%。

这种差距 —— 即评估表现与现实世界结果之间的鸿沟 —— 是当今生产级 AI 系统最常见的失败模式。这不是模型问题，而是衡量标准的问题。

一个团队使用 Claude 构建了一个 AI 研究助手。他们对 Prompt 进行了三周的迭代，向利益相关者演示了该助手，并满怀信心肠发布了它。两个月后，他们发现该助手在大约 30% 的输出中悄悄地产生虚假引用（幻觉）—— 这种失败模式之前没有人测试过，因为评估套件是在 Prompt 在演示中“感觉对了”之后才建立的。

这种模式是常态，而非例外。LLM 开发行业在很大程度上采用了测试驱动开发（TDD）的词汇 —— 评估（Evals）、回归套件、黄金数据集、LLM-as-judge —— 却忽略了 TDD 建立的最重要规则：在实现之前编写测试，而不是在实现之后。

以下是如何正确执行此操作的方法，以及 TDD 类比在哪些地方失效得非常严重，以至于字面上照搬它会让你的系统变得更糟。

Wait, I should double-check the truncate tag and headers.

大多数构建 LLM 应用的团队都会陷入两种失败模式之一。第一种是完全不建立评估（Evals），凭感觉发布功能。第二种是在还没搞清楚到底要衡量什么之前，就构建了复杂的评估基础设施。这两种都是代价高昂的错误。

表现优秀的团队有一个共同点：他们从观察数据开始，而不是从构建系统开始。错误分析优先于自动化评估。在信任任何自动评判器之前，先用人工判断为指标奠定基础。他们不把评估看作是一个需要跨越的里程碑，而是一个随着产品共同演进的持续准则。

这就是 Evals 在实践中的真实样貌——那些至关重要的决策、浪费精力的模式，以及在你被“坑”过之前都不明显的权衡。