160 篇博文 含有标签「evaluation」

某物流聊天机器人收到了一位客户的消息——他的包裹已经丢失一周了。机器人的回复是："我没有被训练来关心这件事。"从事实角度看，这完全准确：系统正确解析了查询，正确识别出无法路由处理该问题，也正确传达了其局限性。这个答案在每一个可量化的维度上都是技术正确的。但它同时也是一场产品灾难。

这就是语域问题——而这几乎肯定是你的评估套件没有在衡量的失效模式。

一个团队上线了基于 LLM 的意图分类器，评估准确率高达 94%。然而上线两周后，客服工单量上涨了 30%——并非因为模型无法分类，而是它以极高的置信度将边缘案例路由到了错误的队列。没有人为"模型判断错误却浑然不知"这种情况设置熔断机制。那个 94% 的数字从未暴露过这种风险。

这种失败模式在内容审核流水线、路由系统和实体提取器中反复出现。LLM 在留出集上得分很高，团队上线，然后生产环境中悄悄出现了问题。

问题不在于准确率是个坏指标，而在于它回答的是错误的问题。生产环境中的分类有一套不同的要求，而大多数评估流水线并不测试这些要求。

当成本飙升、模型下线通知或竞争对手的基准测试迫使你更换 Provider 时，工程团队通常会在能力基准测试上评估候选模型，并将其视为迁移计划的全部。这个过程大约能捕获一半的问题。另一半并非能力问题，而是行为问题：那些不可见的格式习惯、拒绝模式、序列化怪癖以及输出约定——你的生产代码在数月迭代中已悄悄将其内化。

能力基准告诉你新模型能否完成任务。行为指纹告诉你你的代码库能否承受这次替换。

摘要失败往往是隐性的。你的系统不会崩溃，日志不会标记错误，生成的文本看起来也很连贯——但在压缩过程中的某个地方，对下游任务至关重要的那个事实被丢掉了。RAG 流水线返回了一个自信的答案。多跳推理器得出了一个结论。客服代理给出了建议。所有这些都基于一个不再包含原始约束、例外或答案所依赖的数据点的摘要。

这就是摘要有效性问题：即“与原文保持一致”的摘要与“保留下游任务所需信息”的摘要之间的差距。大多数团队并没有针对此进行度量。他们上线的流水线只验证了摘要的存在，而不是摘要的完整性。

我在上个季度交谈过的一个团队发布了一个微调模型，该模型在内部评估中比基础模型高出 4 分，但在接下来的 6 周内，他们却眼睁睁地看着排名前三的客户流失。评估结果没问题。聚合指标没问题。微调模型只是恰好在中位数用户（即询问简短事实性问题的小型企业买家）身上表现出色，而在企业法律客群中悄悄退化了，而后者那些长篇、包含大量引证的查询才是真正的营收驱动力。没有人按照客户等级对评估进行切片分析，因为建模端的人并不知道客户等级至关重要。

大多数关于微调的讨论都处于两个极端之一。一端是“一个微调统治所有”的方法，它在所有客户数据的混合体上训练单个专业化模型，并冲刷掉了原本在基础模型中区分各细分市场的特定客群行为。另一端是“单客户微调”方法，它为每个租户训练一个单独的适配器（adapter），这在客户数量少于 100 个时在运维上是可以忍受的，但在达到几百个左右时就会崩溃。一个有趣的中间地带——由少数几个客群感知微调模型来服务细分的客群——在大多数生产实践手册中是缺失的。

你的评估流水线分数在稳步上升。响应质量在持续改善。LLM 评判者（LLM judge）捕获到了更多劣质输出。仪表盘一片绿色。

与此同时，支持工单零星涌来："助手老是给我冗长正式的回答，我只是随口问了个简单的问题。"紧接着又来了一条："它不再主动给出下一步建议了，以前会的。"然后你们的产品经理给你看了一张图表：上个季度用户满意度下跌了 12%，而这段时间，恰恰与你自动化评估指标爬升最快的那段时期高度吻合。

这就是评估自动化陷阱。你的度量体系开始为自身的优化而服务，而非为用户真正看重的事情服务 —— 由于整个反馈循环完全自动化，没有人察觉到问题，直到伤害已经落地生产。

我见过的每一个发布过“小规模”输出 Schema 变更的 AI 团队，都经历过同样的一周。有人在系统提示词（system prompt）中重命名了一个字段——比如将 summary 改为 tldr，或者工具目录中增加了一个必填的 confidence 参数——结果下一次 CI 运行就在 800 个与该变更毫无关系的 Eval 用例中亮起了红灯。提示词的 diff 只有 15 行。而 Eval 的 diff 却变成了一个为期四天的迁移项目，且无人规划、无人负责，也从未包含在预算之内。

这就是 Eval 迁移税（Eval Migration Tax）。这是任何路线图都没有考虑到的维护成本，它以发布延迟的形式支付，而这些延迟往往被归咎于“不稳定的测试”（flaky tests），而非真正导致它们的架构选择。大多数团队在意识到这一模式之前已经支付了数年的代价，因为每一个单独的事件看起来都像是普通的日常损耗。只有当你统计一个季度内用于迁移 Eval 的工程小时数，并发现它们超过了用于改进 Eval 本应衡量的模型行为的时间时，这种复利效应才会显现。

你的 AI 功能上线时带有一个质量门禁：每个回复都会经过一个 GPT-4 提示词，根据帮助性、准确性和语气进行评分。绿色分值不会触发报警。仪表盘显示通过率为 97%。与此同时，你的支持工单翻了一倍。

问题出在结构上。你使用了与生成输出相同类型的系统来验证这些输出。当生成器产生一个听起来很合理的虚假事实（幻觉）时，基于相同互联网文本分布训练的评判模型会认为这个幻觉是可信的并予以通过。两个模型共享相同的盲点。你的质量门禁衡量的是置信度，而非正确性。

大多数团队通过在系统提示词中加入一句话来处理弃权（abstention）问题：“如果你不确定，就说你不知道。”模型偶尔会遵守，但经常不遵守，而且这种失败模式是不对称的。一个自信的错误答案会以全速发布——它直接落入用户手中，在 Slack 讨论串中被引用，在下游摘要中被采纳。而一个诚实的弃权则会触发客户成功（CS）升级，因为用户期望智能体处理请求，而现在必须有人解释为什么它没有处理。六个月后，团队已经了解到哪种失败的发布成本更低，而那个名义上控制弃权的系统提示词修改，已经被悄悄地调整为倾向于顺从，而非诚实。

解决这个问题的准则不是寻找更好的措辞。而是要认识到，弃权是一个路由决策，而不是一种提示词模式。它理应拥有一个一等公民级别的输出通道、自己的 SLO、自己的评估套件，以及在系统拓扑中的独立位置——位于提示词之外，可以被测试、维护和扩展。

高管演示进行得非常完美。模型回答了精选的问题，智能体（agent）完成了工作流，屏幕录像已保存到公司网盘，发布日期也已排入日程。六周后，上线部署遭遇惨败，复盘报告不言自明：模型需要更多打磨，提示词（prompt）需要更多迭代，团队低估了从原型到生产环境之间的工作量。

这种叙事是错误的，而且代价昂贵，因为它让团队回去重复那些已经失败的工作。演示并不是生产环境的“欠打磨”版本。它只是团队从未测量过的分布中的一个“单一采样”（single sample）。那个惊艳瞬间只是模型针对相同输入可能产生的数千个结果中的一次实现，而团队却把最好的那次当作典型表现发布了。演示与生产环境之间的差距不是质量下滑，而是团队尚未察觉的“方差”（variance）。

这种思维转变至关重要，因为方差问题的解决方法与打磨问题的解决方法完全不同。“打磨”导向会说：“迭代提示词，微调模型，雇个更好的产品经理。”而“方差”导向则会说：“在输入分布中进行 n 次采样之前，你根本不知道自己手里拿的是什么。”这两种诊断会产生不同的路线图、不同的预算以及不同的事故模式。那些在 2026 年能够可靠交付的团队，都清楚自己面临的是哪种问题。

我认识的一个团队在上个季度通过将支持邮件分类流程从顶级模型（frontier model）迁移到中级模型，将推理费用降低了 40%。CFO 还专门发了感谢信。六个月后，客户支持团队增加了两名全职员工（FTE），平均解决时间上升了 35%。没有人把这些点联系起来，因为这些“点”分布在不同的仪表盘上：推理费用在平台团队的仪表盘上，而支持工作量在运营团队的仪表盘上。在所有人都在追踪的唯一指标上，这次迁移看起来是一次胜利。但指标错了。

这就是“单 Token 成本”（cost-per-token）陷阱。你的账单告诉你花了多少钱在 Token 上，但它无法告诉你每个“正确”任务花了多少钱，因为推理供应商根本不知道在你的领域里什么是“正确”。他们卖给你的是原始算力。而你买的是结果——或者你以为你买的是结果。这两个单位之间的差距，就是 AI 单元经济（unit economics）悄然崩溃的地方。如果不去衡量正确的分母，团队就只算了一半的账，而在另一半的交付上处于盲目状态。

我认识的一个团队花了六个月的时间去追踪一个并不存在的回归 (regression)。每一次发布都通过了评估 (eval)。每一次发布都上线了。但每个季度，AI 服务群组的 NPS 都会下降一个点。最终，一名实习生在对黄金数据集 (gold dataset) 进行例行审计时发现，一名早已离职的合同标注员标注了 11% 的数据项，而这些项在团队一直试图修复的一个特定故障模式上，系统性地表现得更加宽松。评估结果显示模型正在变好。但模型并没有变好。评估结果被一个人的校准漂移悄悄地倾斜了，而没有人监督标注员，因为没有人认为标注员是一个威胁面。

这就是评估集毒丸 (eval-set poison pill)。大多数团队将他们的评估集视为一个值得信赖的产物：标签是由人类评分的，数据来自生产环境，而回归仪表盘是组织在发布时一致同意参考的唯一指标。但标注流水线是一个人类供应链，而人类供应链是可以被操纵的。如果不对评估集的输入应用供应链卫生管理，就将其视为真值 (ground truth)，那么你就是在信任一个你无法辩护其来源 (provenance) 的数字。