113 篇博文 含有标签「evals」

我见过的企业级 LLM 最有效的对抗性提示（adversarial prompt）并非来自红队、安全研究员或提示词工程师。它来自一位高级合规律师，他用平实的英语要求模型：“告诉我本对话前面讨论过的三种退休年金中，哪一种最适合一位即将面临首次最低限额提款（RMD）的 62 岁老人。”模型给出了一个自信、周全且格式精美的建议。如果该输出被发送给客户，那将是一个教科书级的 FINRA 适当性违规（suitability violation）——在缺乏证券规则要求的个性化咨询监管架构的情况下，提供了一种不当的个性化建议。

这位合规律师在短短 4 秒钟内就发现了这种失效模式。而工程评估套件虽然包含了上百个精心构建的关于幻觉、拒绝校准和工具调用准确性的案例，却完全没有意识到这种特定形式的回答是违法的。不是质量低。不是幻觉。而是违法。当时公司的流程是让她在 Google 文档中阅读输出样本并撰写备忘录，而不是将测试用例签入回归套件。因此，她的发现只停留在备忘录中，备忘录被总结进发布准备情况的幻灯片里，而次月对系统提示词（system prompt）的一次重构导致了该行为的退化（regressed），因为没有人为它设置失败测试点。

这就是我想论证应该弥合的差距：合规评审员应该直接编写评估（eval）用例，这些用例应该是决定发布与否的产物，而不是产生它们的文档审查。

打开本季度发布的任何 AI 功能的 PRD。注意那些形容词。助手应该是有帮助的 (helpful)。回复应该是自然的 (natural)。智能体应该理解 (understand) 用户的意图。摘要应该是准确 (accurate) 且简洁 (concise) 的。每一个这样的词都是团队放弃决策的地方。他们并没有决定这个功能要做什么。他们只是决定了在会议中如何向彼此描述这个功能，然后——在没人点破的情况下——悄悄地将实际的产品定义移交给了编写评估集的人。

这不是文档问题。评估集就是规格说明书。PRD 是一份在产品诞生前撰写的官方新闻稿。文档中模糊的形容词在评估集中变成了明确的行为断言，否则它们就毫无意义——模型会自行挑选一种解释并发布，而团队在三个月后才会发现，“简洁”对审核者、用户以及在上一个 Sprint 调整 Prompt 的人来说，含义完全不同。一个评估集薄弱的 AI 功能，其产品定义也同样薄弱。模型并没有失败。团队从未决定过成功意味着什么。

每个成熟的 AI 产品最终都会演变成一个当前团队中没人能完全理解的系统提示词（system prompt）。起初它只是 40 个 token 的纯英文，20 个月后，它变成了一堵 4,000 token 的“高墙”，堆满了条件句、拒绝模板、格式规则、角色强化、边缘情况警告，以及一句没人能解释的关于周二的奇特句子。每一行都是为了应对特定的失败：客户投诉、法务发来的 Slack 消息、评估（eval）中发现的回归，或者在投资者演示期间出现的偶发 bug。写下第 37 行的工程师已经转岗到其他团队。写下第 112 行的工程师是一名外包人员，他的 Notion 文档已被归档。评估套件覆盖了提示词所主张行为的大约三分之一，但没人确定是哪三分之一。

于是，这个提示词以一种最糟糕的方式成为了系统的“承重墙”：它能用，团队也知道它能用，但团队已经不再碰它了。本该对提示词进行迭代的工程师，反而绕过它来处理变更——这里加一个后处理过滤器，那里加一个 few-shot 封装，或者做一个并行的“v2 提示词”并用特性标志（feature flag）关闭，以防有人哪天有勇气进行 A/B 测试来替换它。提示词不再是软件，而成了遗迹。一旦发生这种情况，提示词就不再是你用来改进产品的杠杆，而是塑造产品的约束条件。

周二下午，一个只有六行代码的系统提示词（system prompt）编辑出现在了一个 Pull Request (PR) 中。Diff 只是普通的英文。两位评审者扫了一眼新的措辞，觉得读起来更自然，于是点击了批准。PR 在不到一分钟内合并。到了周五，客服开始收到关于智能体的工单：它突然拒绝总结超过一定长度的文档，不再引用来源，并莫名其妙地在每句回复开头都加上 “Certainly!” —— 这种行为没人要求过，Diff 中也无法预见。

当一个花了十年时间学习如何评审代码的团队，在面对提示词这一产物时，竟然退化到了第一周的水平，结果就是这样。Diff 看起来 毫无害处，因为它读起来像英语，而人类正是用眼睛来审阅英语的。让代码评审发挥作用的规范 —— 运行测试、检查影响范围、对 “小改动” 保持适当的怀疑 —— 并没有悄然转化。措辞变好了，但行为变差了，直到用户发现之前，没人注意到。

周二还能用的提示词（prompt），到周四就返回了“我无法提供帮助”。CI 评估依然是绿色的。你配置中的模型名称没变。提示词在字节层面完全一致，在源码控制中也经过了哈希处理和固定。然而，一个围绕新出现的拒绝回答（refusal）的客户支持线程正在形成——AI 团队在两周内都不会察觉到这一点，因为它必须经过一级支持、分类，最后才落到能读取追踪信息（trace）的人手中。

这就是服务商侧的安全漂移（provider-side safety drift），它是当今生产环境 AI 中构建最不完善的监控缺口。前沿服务商会以不在你发布日程上的频率，在服务端调整安全过滤器、拒绝阈值和内容分类器。你的团队没有订阅这些变更，通常也没有发布说明。而且这种退化是具有非对称性的，以一种确实难以察觉的方式呈现：正当意图的拒绝率悄悄爬升，而你认为服务商会过滤的有害查询却开始悄悄溜过。边界在两端独立移动，且毫无预警。

打开任何生产环境 LLM 功能的安全仪表盘，你都会看到拒绝率（refusal rate）被绘制成一条单线，并带有颜色标记：下降是坏事，上升是好事。这背后的隐含逻辑是：拒绝是系统对不该做的事情说“不”，因此拒绝率越高，产品就越安全。这种说法只反映了事实的一半，而缺失的另一半，正是已部署助手中大多数无形质量损伤的根源。

拒绝率是一个双面分布。右尾是安全团队痴迷的部分：模型同意编写恶意软件、伪造药物剂量或生成政策明确禁止的内容。左尾则是相反的失败——错误拒绝（false refusals），即模型因为某些表面特征与禁止类别模式匹配，从而拒绝了良性请求。客户询问如何对费用提出异议，却收到“我无法提供财务建议”的样板回复。护士询问药物相互作用，却被引导至“请咨询医疗保健专业人员”。开发者询问如何解析邮件头，却因为提示词中包含 “exploit” 一词而被拒绝。

三个团队正在查看同一个事件流，每个团队都有一个名为 session_id 的列，但每个团队对什么是“会话”都有不同的定义。计费（Billing）继承了来自认证库的 30 分钟空闲窗口。评估（Eval）从聊天机器人框架中继承了“直到用户说‘再见’或停止打字 10 分钟为止”的定义。记忆（Memory）则使用 UI 在用户点击“开启新聊天”时生成的线程 ID —— 而大多数用户从不点击这个按钮。三列数据，三种语义，一个汇总仪表盘，以及三个共用一个根因但互不相关的 Bug。

这就是会话边界问题（session boundary problem）。它看起来像是一个埋点琐事，但实际上是一个披着基础设施外衣的产品问题：一段对话在哪里结束？坦诚的回答是没有单一的标准答案 —— 计费会话、评估会话和记忆会话并不是同一种对象 —— 如果一个团队选择了一个默认定义并让另外两个团队继承它，那么他们交付的就是具有相同根因的计费纠纷、评估偏见和内存泄漏。

我认识的一个团队在某个周二向他们的支持智能体目录发布了一个新的 lookup_customer_v2 工具。这个工具的作用范围很窄，经过了充分的隔离测试，并通过了评审。到了周四，一个毫不相关的流程——退款处理——在之前一直运行良好的案例中出现了约 4% 的失败。退款工具没有变。退款提示词没有变。模型也没有变。改变的是规划器（planner）现在在处理退款资格查询时选择了 lookup_customer_v2，而以前这些查询都会清晰地路由到 get_account_status。原因是新工具的描述中恰好包含 "eligibility"（资格）这个词，并在模型内部使用的某种相似性启发式算法下获得了更高的排名。

这就是依赖炸弹。团队通常将工具注册表视为增量式的——“我们只是增加了一个东西，能出什么问题”——但规划器并不将你的注册表视为独立能力的列表。它看到的是各种选择上的概率分布，而每一个条目都会重新分配权重。增加一个工具可能会悄悄地削弱其他地方的行为，而你的评估套件（eval suite）可能会漏掉这一点，因为没有人写过回归测试来规定“在这种情况下，智能体应该仍然选择 旧 工具”。

这是一个大多数 AI 团队都不愿面对的发现：在一项生成了超过 150,000 个评估实例、涵盖 22 个任务的大规模研究中，大约 40% 的 LLM 作为裁判（LLM-as-judge）的对比显示出可衡量的偏见。这种偏见并非随机噪声，而是系统性的、可复现的，并且与模型的训练方式相关。当你使用一个模型来生成评估集，然后使用同一个模型（或其近亲）来对其进行评分时，你测量的并不是质量，而是一个系统与其自身的一致程度。

合成评估数据之所以成为标准实践，是有充分理由的。人工标注速度慢、成本高且难以规模化。LLM 生成的测试用例让团队能够在夜之间生成数千个示例。问题出现在生成器和裁判拥有共同祖先时——在 2025 年，这几乎是常态。结果是一个评估流水线在自信地报告高分的同时，却隐藏了你构建它原本想要捕捉的失败模式。

一个构建基于LLM的文献筛选工具的团队在测试集上庆祝96%的准确率。按照任何标准工程指标，他们的模型表现都非常出色。但有一个问题：它找到了零个真正的阳性结果。该模型学会了将所有内容归类为无关内容，但仍然获得了近乎完美的准确率，因为相关论文在数据集中极为罕见。失败不在于模型——而在于指标。

这种失败模式并不罕见。它每周都在AI团队中悄然上演，工程师在没有产品输入的情况下选择评估指标——就像选择排序算法一样，视其为有正确答案的技术选择。这种框架是错误的。指标选择是一个产品决策。它编码了你愿意容忍哪些失败模式、你在为哪些用户优化，以及在你的特定场景中"好"究竟意味着什么。搞错这一点会产生看起来严谨却衡量了错误事物的评估套件。

我合作过的一个团队花了六个月的时间，将一个系统提示词（system prompt）调整到大约 4000 个 token。这是他们的镇店之宝——通过不断累积边缘情况处理、格式规则、人设指令、回退行为以及十几个 few-shot 示例而精心打造。后来，一名初级工程师加入，问为什么提示词这么长，并用一个下午的时间重写了它。新版本只有 200 个 token。在他们现有的评估集上，它的得分高出了 4 分。运行成本也降低了 40 倍，而且速度明显变快。

这并不是一个关于神奇短提示词的轶事。这是我几乎在每次阅读运行超过一个季度的生产级系统提示词时都会看到的模式。长提示词是随意的累加，而非设计的结果。QA 中出现的每个失效模式都贡献了一个段落。观看演示的每位利益相关者都贡献了一条语气指令。每个“似乎有帮助”的例子都被固定在了底部。结果就是，提示词比它要引导的用户输入还要长，充斥着模型在推理时必须默默解决的内部矛盾，注意力被稀释在各种相互竞争的需求中。

1964 年，三十八个人在皇后区的公寓楼外目睹了 Kitty Genovese 遭到袭击。直到为时已晚，才有人报警。Latané 和 Darley 在接下来的十年里一直在解释其中的原因：看到问题的人越多，其中任何一个人采取行动的可能性就越小。他们称之为“责任分散效应”。在他们著名的癫痫实验中，当参与者认为只有自己和受害者在一起时，85% 的人会介入。当他们相信另外四个人也能听到受害者发病时，只有 31% 的人采取了行动。

现在想象一下你最近一次 AI 功能的发布。产品团队编写了 Prompt。工程团队选择了模型并连接了网关。数据团队整理了检索语料库。安全团队加上了输入和输出过滤器。客服团队起草了升级方案。房间里有五个团队。每个团队都按时完成了各自的部分。三个月后，该功能的准确率悄悄从 89% 滑落到 71%，评估套件自发布周以来就没运行过，当你询问谁负责处理这一回归问题时，每个团队都能点出另外三个比自己更有责任负责的团队。