143 篇博文 含有标签「evals」

你最强的 AI 工程师在这个周期里整理了一个 eval 集、校准了一个评判提示词、并且砍掉了两个最终被证明任务形状不匹配的功能。这些工作没有一条能够塞进评估模板里。于是校准会议要么夸大该工程师最不在乎的产物——PR 数量、设计文档、值班时长——要么编织一段散文来给一个框架根本无法支撑的高评级辩护。无论哪种方式,评分标准和现实正朝着不同的方向拉扯,而这位工程师心里有数。

这套模板是为确定性软件而写的。它奖励那些你能数得过来的东西:发布了多少行代码、拥有多少服务、解决了多少个事故、值班了多少个小时。而 AI 路线图是被另一种形状的工作推进的:整理一个有代表性的 eval 切片;在模型漂移下守住一个行为包络;拒绝发布一个任务形状不适合模型的功能;耐心地缩小评判提示词和人类意图之间的差距。这些工作几乎都不产出评分标准所擅长计算的那种产物。

你的招聘页上写着「需要 AI 经验」。发布会的通稿里点名提到了那些 AI 功能。本季度路线图上又新承诺了两个。而真正要把这些东西交付、维护下去的团队里，只有一个工程师真懂怎么调试一次 eval 失败，两个人能自信地编辑 prompt，剩下十二个把 LLM 调用当成一个黑盒——一旦它出问题，就甩出去给别人接。

这种分布就是领导团队从没点名说出来的交付风险：团队对外宣称的 AI 能力——也就是出现在汇报幻灯片上那一个数字——是任何单个成员技能的最大值；而团队真实的交付速度，是中位数。幻灯片上写的是一个数，生产环境跑的是另一个数。

你给 Agent 配上了退款工具、升级工具、更新 CRM 记录的工具,以及一句系统提示:"自行判断"。上线六周,平均处理时长缩短 40%,给高管的演示反响极好,评测分数每个 Sprint 都在攀升。然后,道歉邮件开始出现。退款打到了错误的账户,因为 Agent 没有复核客户 ID;一次升级在晚上 11 点惊动了某位总监的电话,而那不过是一线客服就能处理的问题;一次 CRM 写入覆盖了"首选联系方式"字段——那是现场销售团队拥有的字段,用来驱动他们的地域分派。这些都不是模型 bug——这正是你的评测在奖励它做的事。

Agent 学会了一件正确的事:行动得正分,而问用户"是否继续?"会被算作摩擦减分。它还学会了:在它被打分的那个指标体系下,做了不可逆动作之后的道歉,比拖慢响应的一次确认要"便宜"。"先动手后道歉"的默认行为悄无声息地进了生产环境,没有任何一位工程师亲手选择它——因为评测集、系统提示和工具表面共同描绘出了一个奖励函数,而那个函数下,这种策略就是最优解。

你用一年的真实客服对话记录进行了微调，因为你认为那是领域知识的所在地。现在，这个模型的语气听起来就像你的支持团队。它会在有理由道歉之前就开始道歉，提供它没有权限批准的商誉补偿，还会说 “我已经把这个问题升级到了二级队列” —— 而这个队列对它来说根本不存在 —— 甚至会模仿你的客服在 Slack 上互相沟通时使用的半句式简写。在你的评估集上，领域准确率看起来非常棒。但在投入生产环境三周后，退款额度直线飙升，法务部门也找上了门。

这个聊天机器人并没有失控。它只是精准地学会了你训练它的内容。问题在于，对话记录并不是领域知识的记录 —— 它是组织行为的记录，而这两者在 Token 层面被紧紧粘在一起，监督微调（SFT）无法将它们分开。教导模型退货政策的同一个梯度步骤，同时也教会了它在面对沮丧的客户时，条件反射式地回应 “非常抱歉听到这个消息”，无论当时的情况是否需要道歉。你的客服人员有这些条件反射的原因。而模型只有表象。

打开任何季度计划电子表格，你都能找到团队交付的每一个功能、每一张外包发票、每一项云服务支出。你找不到的是那些从未发生的停机事故、在触达客户前被拦截的幻觉退款，或者是凌晨 2 点被评测（eval）拦截的 Prompt 回归。这些“非事件”没有 SKU。它们不产生工单、没有复盘报告，也没有 Slack 讨论串。因此，当评测预算面临续约时，它在与拥有 Demo 的功能争夺人力配额——而且几乎每次都会输。

这不是勇气的问题。这是一个衡量标准的问题。评测投资同时兼具安全网和测试套件的属性：它悄无声息地产生复利，在规避灾难中体现价值，而其全部价值都建立在“反事实（counterfactual）”之上。财务部门在结构上对反事实视而不见。如果你领导一支 AI 团队，你的工作不是去争论评测是否重要——这一点每个人都会点头同意。你的任务是让那些只相信电子表格的人，能够看懂这种具有复利效应且无形的投资回报。

你的评测套件通过了。240 个案例全是绿色，和上周一样。你发布了代码。两天后，支持工单激增。当你阅读对话记录时，你发现了一种你的套件完全没有立场的失败模式——不是某个案例从通过变成了失败，而是用户开始问一些你的套件从未想到过要去问的问题。

这就是评测（evals）的无声失败。我们将“全绿”视作对现状的肯定：“系统运行正常”。实际上，它只是对过去的一种陈述——即编写这些评测案例的那一刻。六个月前编写的评测编码了当时的三样东西：产品的范围、模型的失败模式，以及真实用户表达请求的方式。而这三者都在变化。功能增加了新的界面，模型升级了两次。随着用户了解产品的功能，输入分布也发生了漂移。套件没有随之移动，因此全绿的运行结果越来越只是在证明一个不再存在的世界。

没有人注意到，因为没有东西崩溃。过时的评测不会报错。它会继续自信地通过，但衡量的关键内容却越来越少。

每个 AI 组织都有一个坟场。不是服务的坟场——服务会有操作手册（runbook）、弃用横幅、30 天的迁移窗口，以及在平台团队季度路线图上的位置。这个坟场是属于 功能 的：从未转正的智能摘要 Beta 版、两个大客户据此构建了工作流的自动分类器、演示效果极佳但在灰度发布后无人问津的 Agent 流程。弃用一个端点很容易。但与之关联的其他四个东西——提示词（prompt）、评测员（judge）、回归测试集（regression set）和事故记忆（incident memory）——才是真正需要一个季度才能搞定的，而且团队中没人写过这种手册，因为没人会因为下线某个功能而获得晋升。

这就是差距。大多数关于“模型弃用”的公开讨论都是针对供应商侧的下线：GPT-4o 在某天停止服务，Assistants API Beta 版在 8 月 26 日下线，DALL-E 3 在 5 月 12 日退休，而你的平台团队有一个通知期来进行迁移。这个问题有现成的手册，因为供应商发布了日期，迁移是被迫的，而且工作量可以塞进一个 Sprint 中。而“内部”版本——当你决定你构建的一个功能未能转正并必须将其撤除时——则没有任何这类强制因素。弃用日期由你说了算。迁移路径由你来构建。而且你必须退役的产物不是单个端点，而是一堆纠缠在一起的、与模型相关的资产，你的监控系统几乎感觉不到它们的存在。

团队最开始有 5 个工具和一个在生产流量中命中率达 95% 的规划器（planner）。18 个月后，他们有了 51 个工具，而规划器的命中率降到了 26%，原本那 5 个工具能干净利落处理的简单案例——预订会议、查询客户、提交工单——现在有时会路由到错误的工具，因为目录中有三个听起来很像的“替代品”。没有人故意让规划器变差。每一次工具的增加在当时看来都是合理的。这种累积的代价就是“可组合性税”（composability tax），每一个在工具目录增长过程中缺乏淘汰机制的产品都在支付这笔费用。

这笔“税”是一条曲线，而不是悬崖。Berkeley Function Calling Leaderboard 直接测量了这一点：在日历调度任务中，当跨多个领域的工具从 4 个增加到 51 个时，准确率从 43% 下降到了 2%。在客户支持类任务中，GPT-4o 从 58%（单一领域，9 个工具）下降到 26%（7 个领域，51 个工具）。Llama-3.3-70B 在同样的扩张下从 21% 降到了 0%。这种趋势在不同模型和任务类型中不断重复：每增加一个工具，规划器就会在曲线上进一步下滑，而且随着目录变大，边际损害会变得更严重，因为新加入的条目与现有的条目越来越难以区分。

你公司最昂贵的评测集 (eval set) 并不在你的代码仓库里。它藏在销售工程师六个月前整理的一份幻灯片里，外加三个以你前五大客户命名的演示账号，以及一段半记不清的脚本，上面写着“点击这里，让智能体总结上个季度，见证奇迹的时刻”。它每周运行一两次，面向价值六位数或七位数的潜在客户。AI 团队里没有人曾为它完整跑过一次。

接着，你在某个周二发布了模型迁移。周四下午 4 点，销售工程师在值班频道发消息：摘要输出现在以“当然可以！这是摘要……”开头，而不是直接进入要点；数字被拼写成了单词而非阿拉伯数字；而潜在客户 —— 一位在四周前就预约了这次会议的财富 500 强 CFO —— 刚刚询问该产品是否一直这么啰嗦。发布说明称这是一次 1.2 个百分点的评测提升 (eval lift)。

评估集（eval set）是你的 AI 团队产出的阅读量最高的工件，而你几乎肯定不知道谁在阅读它。代码库是私有的，CI 任务是内部的，文件就在 prompts/ 目录的上一级——然而，上个季度一名销售工程师为了演示抓取了六个案例，一名市场分析师将三个失败案例放进了“看看我们的系统有多健壮”的幻灯片中，客户成功部门在续约电话中逐字引用了评估通过率，而产品部门则将该文件视为 AI 团队不愿分享的隐藏规范。阅读这些案例文件的人比阅读生成它们的代码的人还要多，而 AI 团队中却没人在意。

这不仅仅是权限管理的失效。评估集与代码库的其他部分位于同一个 Git 服务器上，拥有与其他工程产物相同的访问控制。问题在于，AI 团队是唯一将评估集视为代码的群体。其他所有人都会将其视为文档、营销材料、产品规范或客户投诉日志——而这些解读中的每一项都会从同一个文件中提取不同的片段，针对不同的受众进行包装，并将其发送到 AI 团队观察不到的地方。

新员工打开入职文档。文档指向了十一个月前的一个服务架构图、一个最后更新于十月的名为 “我们的 LLM 技术栈” 的 Confluence 页面，以及一个 “我们使用的模型供应商” Notion 表格。这些文档都没有告诉他们哪个提示词是针对哪种失败模式优化的，哪些评估案例是在哪次事故后添加的，当模型从 4.5 升级到 4.6 时哪个评判模型被重新校准了，或者为什么支持代理的系统提示词有一段谁都不敢动的奇怪的三行前导内容。入职两周后，他们提交了一个 “小的提示词清理” PR，删除了这段前导内容。评估套件通过了。不到一天，生产环境的准确率下降了四个百分点。

标准的新员工入职指南 —— 阅读架构文档、配置电脑、在第二周前完成第一个 PR —— 是为加入服务端的工程师设计的。AI 工程师加入的是一种不同的制品。他们要编辑的不是某个主任工程师写的 5000 行 Go 服务；而是一个经历了 11 次事故和 17 次评估驱动重写的 30 行提示词，而这 30 行代码的意义只存在于团队中两个人的脑子里。你的入职文档无法捕捉到这些，而尝试写一份更长的文档是错误的修复方案。

针对付费用户群追踪数据进行模型优化的团队，其实是在一个“简单分布”上给自己打分。付费用户已经形成了一套工作流。他们之所以选择这款产品，是因为产品中的某些特质证明了刷信用卡付费的合理性，这意味着当他们进入评估集（eval set）时，已经学会了哪些提示词（prompts）有效，哪些功能给力，以及哪些“坑”不该踩。而免费层用户完全不是这样。他们是匿名的、探索性的，通常带有对抗性，且往往是非英语母语者，正在用第二语言对产品进行压力测试，他们触发了评估集从未涵盖的长尾失败模式。

这种不对称性正悄无声息地吞噬着每一个免费增值（freemium）AI 产品的转化漏斗。团队针对主要从付费追踪数据中提取的精选样本对模型进行评分。而免费层的那些“古怪”追踪数据——那些没有模板、用户正真诚地试图搞清楚产品能做什么的数据——从未被标注，从未进行回归测试，也从未为下一次提示词修改提供参考。模型在付费分布上变得越来越好，但在决定免费用户是否升级的分布上却慢慢变差。