151 篇博文 含有标签「evals」

一名客服代理正准备办理退款。在触发工具调用（tool call）之前，你的团队添加了一个门控：只有当模型表示其置信度至少达到 90% 时才继续。模型尽职地返回了 "confidence: 0.95"，退款发出去了，而模型用来证明金额合理性的引用——一条关于损坏商品的政策条款——其实并不存在。它从未存在过。模型虚构了该条款，然后为自己的虚构给出了 95% 的评分。

这就是陷阱。团队倾向于使用模型的置信度数值，因为它看起来就像你从经过校准的分类器中获得的概率——即 0.9 意味着“十次中有九次是正确的”。但事实并非如此。大语言模型（LLM）自我报告的置信度就像其他任何 token 一样，只是听起来流畅的 token，它受到语气、措辞和训练激励的影响，而这些与底层声明是否属实几乎没有任何关系。

如果你根据那个数字来限制实际行动，你就是在根据一种“感觉（vibe）”来做决定。

你的 Agent 内部指标看起来棒极了。任务完成率达到了 94%。#agent-feedback Slack 频道已经安静了三周。领导层正准备将其推向客户。接着外部用户进场了，不到一个月，数据全线崩溃：工单量激增，信任度降至冰点，复盘时每个人都会问：“Dogfooding 怎么会漏掉这些问题？”

Dogfooding 并没有漏掉问题，而是掩盖了问题。内部用户并不是客户群体的缩影 —— 他们是一群专家级操作员，在无声地修补 Agent 的错误，学习避开哪些提示词（Prompt），并在私信里分享变通方案而不是提交 Bug。每一次修补都让仪表盘（Dashboard）看起来更好，却让产品变得更难理解。你读到的清晰信号并非质量，而是补偿（Compensation）。

在你的代码库中的某个地方，有一个配置文件，在 test 配置下写着类似 model: small-and-cheap，而在 production 下写着 model: frontier。当有人添加这一行时，感觉是很负责任的做法 —— 为什么要为了每天运行 20 次的 CI 任务去消耗 frontier 模型的 token 呢？但那一行代码悄无声息地废除了一项你的团队十五年来一直在不假思索遵循的规则：你测试的环境应该表现得和你上线的环境一致。

“十二要素应用宣言”（Twelve-factor methodology）称之为开发环境与生产环境等同（dev/prod parity），我们在这方面已经做得非常出色，以至于我们开始忽略它的存在。Docker 为我们提供了位级一致的运行时环境。基础设施即代码（Infrastructure-as-code）为我们提供了完全一致的拓扑结构。然后，我们在请求路径中间加入了一个语言模型，重新引入了我们花了十年时间才弥合的差距 —— 只不过这一次，产生差异的组件不再是数据库版本。而是系统中负责做决策的部分。

你的定价页面显示每个用户支付的费用相同。但你的成本仪表板却给出了不同的答案。同样的 AI 功能 —— 同样的提示词模板、同样的模型、同样的特性标志（feature flag） —— 为西班牙语用户提供服务的成本要高出 55%，日语用户大约翻倍，而阿拉伯语或孟加拉语用户则超过 3 倍。与此同时，这些用户获得的质量也明显更差：在翻译成不同语言的相同基准测试问题上，当前沿模型脱离英语分布时，其表现会下降 13 到 24 个百分点。

大多数在全球范围内发布 AI 功能的团队从未衡量过这两项数据。他们拥有分地区的定价、分地区的支持 SLA、分地区的法律审查 —— 却只用一套英语评估测试集来代表全球每个用户的体验。

这就是分词器税（tokenizer tax），它与仅靠规模无法弥补的质量差距相互叠加。在你按语言维度拆分数据之前，这两者在仪表板上都是不可见的。而且这两者早在你写下第一个提示词的几年前，就由你无法控制的分词器训练语料库决定了。

发布六周后，你的质量仪表盘开始下滑。点踩率攀升，任务完成率下降，值班频道里塞满了糟糕回复的截图。团队做了该做的一切：对比 Prompt（未变），检查模型版本（已锁定），审计检索索引（是最新的），并对部署历史进行二分查找（没有任何发布）。大家一致认为模型提供商悄悄降低了模型性能。当然，提供商坚持说没有任何变动。

大家都找错了地方。系统没有任何改变，改变的是用户。

发布周的指标是基于发布周的用户假设的。但人们会在几周内适应一款 AI 产品，而这种适应方式会系统性地破坏你在 Prompt、评估集（Evals）和发布基准测试中预设的假设。你的模型是冻结的，但你的用户不是。两者之间的鸿沟是一种大多数团队根本没有监测到的“漂移”——它产生了一种 AI 工程中最令人困惑的故障模式：在没有部署的情况下指标发生衰减。

你的评估套件报告了一个数字。那个数字背后是一个标签。标签背后是一个人 —— 通常是一个你从未见过的人，通过 WhatsApp 管理着为期两周的零工，通过移动支付应用领取报酬，对只有 15 秒阅读时间的模型输出进行排序。你提交给副总裁的评估分数、阻止你部署的回归门禁、你放在发布博客中的排行榜排名 —— 这一切都继承了那个人在那个下午的注意力质量。

我们谈论评估（evals）时，仿佛它们是仪器：经过校准、可重复且客观。事实并非如此。评估是一种测量设备，其传感器是人力劳动流水线，而大多数团队只为测试框架做预算，却将人视为免费输入。这种会计错误正是评估分数漂移、你的“地面真值”（ground truth）前后矛盾，以及前沿 AI 最昂贵的瓶颈不再是算力的原因。

一位工程副总裁决定公司需要“做 AI”。公司已经有一个机器学习团队——三个人，他们构建了推荐模型，调整了反欺诈分类器，并维护着一个特征存储（feature store）。显而易见的举措是让他们负责新的 LLM 项目。他们懂数学，也发布过模型。能有多大区别呢？

六个月后，原型演示效果惊艳，但在生产环境中却惨遭失败。没人能解释为什么智能体（agent）偶尔会订错会议，每个请求的成本是预估的四倍，而且根本无法判断上周的提示词（prompt）更改是让情况变好了还是变坏了。机器学习团队感到很沮丧，因为他们擅长的所有工具——梯度下降、数据流水线、超参数搜索——在他们既无法重新训练也看不透内部构造的模型上都派不上用场。

这是目前 AI 领域最常见的组织架构错误，它源于一个听起来很合理的假设：构建模型的技术与基于模型构建应用的技术是同一份工作的不同标签。事实并非如此。它们之间的重合度甚至比“前端工程师”和“后端工程师”还要低。

演示成功了。你输入了一个问题，智能体调用了三个工具，经过多步计划的推理，最后给出了一个让全场人都为之振奋的答案。有人说：“上线吧。”三个月后，你的产品依然没有上线，而且没人能解释时间都去哪儿了。

时间都花在了这里：演示只占了 10% 的工作，它只是大脑。剩下的 90% 是管道工程——那些在正常运作时无人喝彩，一旦出故障就是灾难性的评估（Evals）、护栏（Guardrails）、可观测性、成本控制和备用路径。这 90% 就是“从演示到生产的税”，而大多数团队在做预算时，却把它当成了一个可以忽略不计的舍入误差。

数据说明了另一番景象。MIT 2025 年的一项企业 AI 研究发现，95% 的生成式 AI 试点项目未能产生可衡量的损益（P&L）影响。另一项分析则更加直截了当：企业每启动 33 个概念验证（PoC）项目，只有 4 个能进入生产阶段。这意味着夭折率高达 88%，而死因几乎从未出现在模型身上，而是演示让你跳过的所有环节。

分块器开始在每个块前添加 [line N]。Eval 变绿了（通过了）。从那天起，模型生成的每一条引用都指向了实际证据前的一个段落，这种情况出现在该产品所服务的受监管行业的每一份文档中。团队并不是通过评估发现这个问题的，而是通过一位审计人员发现的。审计人员查看了引用的句子，阅读后指出，该句子与其本应支持的断言完全矛盾。

这种回归错误（regression）能躲过代码审查、对三个示例文档的手动 QA 测试以及功能开关（feature-flag）的逐步推送。孤立地看，这些检查都没有错。它们都在问同一个问题——在预期的地方是否出现了引用——但没有一个检查在问审计人员问的问题，即：引用是否指向了断言来源的那个句子。这两个问题之间的差距，正是那个“差一错误”（off-by-one）长期潜伏的地方。

这种失效模式之所以值得专门写篇文章，不在于 Bug 本身。差一错误是陈年旧事了。有趣的地方在于，这个失效是由两个系统共同产生的：它们在整数的结构上保持一致，却在整数的含义上产生了无声的分歧。

评估仪表盘连续三个迭代（sprints）都在攀升。困难切片的质量提升了 6 个百分点，回归切片提升了 9 个百分点，而在支持团队根据上季度最糟糕的工单亲手整理的切片上，质量提升了 12 个百分点。团队据此发布了模型升级。两天后，一位客户提出了一个与评估集中的任何内容都不沾边的问题，结果得到的答案比六个月前还要糟糕。

一旦有人想到进行排查，原因很快就浮出水面了。提示词工程师（prompt engineers）一直与评估团队在同一个代码仓库中工作。他们发现了那些精心策划的示例——这些示例来之不易，有的甚至是某人为了一个理想答案的措辞争论了一个小时才定下来的。在几个迭代中，他们把其中最有代表性的示例以 few-shot 演示的形式直接复制到了生产环境的系统提示词（system prompt）中。仪表盘持续攀升，是因为模型在推理时处理的正是它曾经逐字见过的输入。没有人指出这个问题。没有人负责划定“用于衡量质量的示例”与“用于发布到提示词中的示例”之间的界限。两个团队都准确地完成了他们被雇佣来做的工作。

你的可靠性仪表盘显示为 99.95% 。但你的支持收件箱却在诉说另一番景象。每周有那么两次，每次持续 10 到 20 分钟，极少数用户会遇到一个说话风格完全像另一家公司的产品版本。拒绝响应读起来很奇怪。一个原本总是渲染为整洁双栏卡片的结构化字段，现在变成了一个塞满了项目符号的段落。语气从“冷静的专家”变成了“热情的助手”。没有人会为此提交工单——他们只会直接关闭标签页，稍后再试。

你的供应商宕机了。故障转移生效了。延迟保持在 SLO 之下。错误预算没有变动。然而，用户在那个窗口期获得的体验，并不是你真正发布的那款产品。

大多数团队在采用多供应商架构时所持的心智模型是：系统提示词（System Prompt）是可移植的——它是一份与“能力出众的模型”这一抽象概念达成的协议，任何理解 LLM 方言的模型都能读懂。这种模型是错误的。系统提示词是一个经过调优的产物（Artifact）。它是针对特定模型的偏好、拒绝语法、格式习惯和指令遵循偏差进行调优的。当故障转移发生时，你并不是将同样的合同交给一个对等的签约方，而是将一份用主模型（Primary Model）的习语编写的合同，交给了一个阅读习惯完全不同却依然强行签字的模型。

用户提交了一个问题。你的模型生成了一个答案，这个答案以一种非常具体的方式“自信地出错”：格式完美，推理结构严密，并且出现了一个特定的限定词——这个限定词完全不适用于这个问题——它出现的位置，恰好是你系统提示词（system prompt）中示例三出现类似限定词的地方。这既不是幻觉，也不是提示词注入。模型只是精确地执行了示例教它的操作，尽管这些示例原本并非为了涵盖这个问题。

这就是 Few-Shot 提示主动诱发的故障模式，而大多数评估套件（eval suites）在结构上对此是视而不见的。你的示例并不是“优秀范式”的中立演示。它们是判例法（case law）。模型通过表面 token 选择最匹配的项，并将该先例——包括其限制条件——应用到眼前的任何案例中。