842 篇博文 含有标签「ai-engineering」

一位客户对贷款被拒提出异议。监管机构开启调查。原告律师提交证据开示请求。这三者都带着同一个看似简单实则棘手的问题：你的系统做了什么决定，以及为什么？ 决策发生在 18 个月前。你调出案例，发现产生原始输出的每一个组件都已经发生了变化。托管模型版本已被弃用并迁移。系统提示词（System Prompt）被修改了 9 次。你的智能体（Agent）检索到的文档被重新分块（re-chunked）、重新嵌入（re-embedded）并重新排序（re-ranked）到了一个新的索引中。而让整个过程具有非确定性的采样设置从一开始就根本没有记录。

你无法复现该决策。这不是因为你疏忽大意，而是因为你的技术栈中没有任何东西是为了可复现性而构建的。事后解释性（Explainability-after-the-fact）归根结底是一个伪装成解释问题的可复现性问题——而可复现性这种东西，你要么在决策发生的时刻就通过工程手段将其固化，要么就会永远失去它。

令人不安的事实是，大多数团队发现这个漏洞时，恰恰是他们最承受不起后果的时候。重建决策的需求几乎从不会在正常运营期间出现。它往往伴随着诉讼、审计，或是带着监管机构电话号码的愤怒客户而来。到那时，捕获正确证据的窗口期早在一年半前就已经关闭了。

你对生产系统的每一次更改都遵循某种纪律。代码在 feature flag 后发布，灰度测试（canary）到 1% 的流量，当仪表盘变红时可以一键回滚。Schema 迁移是分阶段且可逆的。即使是 CSS 的微调也要经过人工阅读的 pull request。然而 Prompt 却并非如此。有人在文本框中编辑一段文字，点击保存，你产品的行为就会立即对所有用户发生改变——没有灰度测试，没有经过审查的 diff，也没有真正能让你回到先前状态的回滚按钮。

令人不安的是，这并非粗心的团队所导致的疏忽，而是工具链产生的默认结果。Prompt 被归类为“配置（configuration）”，因为它们是存在于编译后的二进制文件之外的字符串，而配置一直以来被认为是可以快速更改且无需完整发布周期的东西。但 Prompt 并不是配置。它是一个用英语编写的程序，由一个你无法控制的非确定性解释器编译，其行为你只能通过统计学来观察。将它视为配置值，是导致一整类生产事故的范畴错误（category error）。

你的基础设施账单上的每一项其他支出都经过了审核。有人为数据库集群提交了采购订单。有人在购买可观测性 SaaS 之前清点了席位。有人在团队将 Kubernetes 占用空间翻倍之前进行了容量审查。然后，模型 API 出现了，而这一切都没有发生。

一名工程师将他们的 API 密钥添加到了配置文件中。他们写了一个 create() 调用，看起来与代码库中的其他函数调用完全一样。它上线了。而财务部门第一次得知这个功能作为一个成本中心存在，是在月度发票上的一个差异项——一个没人预测过、没人批准过、也没人能立即解释的数字。

这就是 AI 的 FinOps 鸿沟，它不是一个监控问题。它是一个披着监控外衣的治理问题。即使你拥有完美的仪表板，依然会感到惊讶，因为早在支出出现在图表上之前，它对你的审批流程就是不可见的。

最危险的 eval set 是那些依然能通过测试的。变红的 regression suite 会引起关注：有人会打开失败的案例进行争论、修复 Bug 或更新预期。绿色的 suite 则会赢得信任。而这种信任恰恰是失效的 eval set 不配拥有的，因为得分保持绿色并非因为你的系统足够好，而是因为测试已经不再反映用户的真实行为。

这是 AI 评估中一种隐蔽的失败模式。你构建了一个 golden dataset —— 几百个精心标记的案例，代表了产品的工作任务。它能在一整个季度里发挥作用。每次部署都会运行它，每个分数都是绿色，每个人都睡得很香。与此同时，产品发布了三个新功能，企业级流量从查询量的 10% 攀升至 45%，用户开始以 18 个月前团队中没人写过的方式来表达请求。eval set 对此一无所知。它继续根据一个已经不存在的分布对模型进行评分。

一位队友提交了一个拉取请求（PR）。Diff 只有三个单词。一行变红了 —— Do not add information not present in the source.（不要添加原文中不存在的信息）—— 另一行变绿了 —— Make your best guess if the source is incomplete.（如果原文不完整，请做出最佳猜测）。改动很小，意图也合理，代码审查只用了 11 秒。你批准了它。一周后，你的客服机器人开始自信地编造根本不存在的退款政策，而你正在翻阅日志，试图查出幻觉率是从什么时候开始翻倍的。

Git Diff 完美地完成了它的工作。它准确地向你展示了哪些字符发生了变化。但它无法展示唯一重要的事情：这些字符背后的行为已经从“不确定时拒绝”变成了“不确定时编造”。对于代码，文本差异是行为差异的忠实代理 —— 将 < 改为 <=，审查者可以推断出后果。而对于提示词（Prompts），文本差异和行为差异几乎没有任何关系。

一个删除请求进入了你的队列。用户行使了他们的被遗忘权（Right to Erasure），而在法律上你有一个月的时间让他们的个人数据消失。在常规系统中，这只是一个 DELETE 语句和一个得意的审计日志条目。但在 AI 系统中，这一刻你会发现你的数据并不只存在于一个地方——它已经散布在微调模型的权重中，固化在向量索引中，缓存在十几个检索快照中，并复制到了上季度的评估集中。没有单行数据可以删除。从非常字面意义上的工程层面来看，该用户是无法删除的。

这并非假设。2025 年 3 月，欧洲数据保护委员会（EDPB）在 30 个国家监管机构中发起了一项协调执法行动，专门针对被遗忘权。监管机构已达成一个令人不安的共识：将某人的数据纳入训练属于“处理”行为，因此 GDPR 第 17 条适用于模型，而不仅仅是数据库。每个 AI 团队最终都会面临一个问题：输出抑制（Output Suppression）——即教导模型拒绝谈论某人——是否足够，还是你实际上必须从系统中移除其数据的影响。诚实的答案是，大多数团队从未针对这两种情况进行过设计。

有一种特定的争论，你只会和语言模型发生。你粘贴进代码。它把一个能运行的调用改写成了早在几个大版本前就不存在的形式。你纠正它。它道歉、表示同意，然后在下一轮对话中故技重施。你不是在对抗无知，而是在对抗一段对 不同 版本技术栈的、自信且经过充分排练的记忆——这段记忆被远超你纠正信息的训练样本所强化。

这就是我所认为的“与先验知识对抗”（fighting the prior）故障模式。模型的参数化知识——它在训练期间吸收的一切——包含了流行的、过时的，或者仅仅是与你实际使用的框架版本不同的内容。当你的上下文与它的先验知识发生冲突时，先验知识往往会胜出。与纯粹的幻觉不同，这种错误之所以危险，恰恰是因为它具有误导性的合理性：那个被弃用的 API 曾经是正确的，所以代码看起来没问题，能通过随意的阅读，甚至有时还能编译通过。

演示在一周内惊艳了执行团队。十八个月后，它依然只是个演示。模型仍在沙盒中回答问题，幻灯片依然被循环用于新的路演，每个季度都有人问为什么还没上线。没有人能给出一个好的答案，因为真相往往令人不安：让所有人印象深刻的部分是廉价的部分，而没有人为昂贵的部分做过规划。

这就是“试点炼狱”（pilot purgatory），而它现在已成为默认的结局。MIT 的 NANDA 计划发现，大约 95% 的企业生成式 AI 试点项目未能对损益表产生可衡量的影响。IDC 和 Lenovo 统计了另一项指标——即那些字面上从未上线的 POC——将这一比例定为 88%：企业每启动 33 个概念验证，只有 4 个能进入生产阶段。放弃大部分 AI 计划的公司比例从 2024 年的 17% 飙升至 2025 年的 42%。这些故事的主角并非模型能力不足，而是没有人为其预留预算的“毕业差距”。

令人不安的事实是，一个可以运行的演示仅代表了在生产环境中运行该系统所需工作的 10%，但正是这 10% 看起来像完成了 100%。所有让 AI 系统能 安全运行 的要素——评估（evals）、护栏（guardrails）、可观测性、成本控制、安全审查、值班（on-call）以及拥有预算的负责人——在演示中是不可见的，但在生产环境中却是不可逾越的底线。

有一句特定的短语应该让每一位工程主管立刻叫停会议：“只要模型变强，这就没问题了。”说这句话的人通常信心满满，有时还会配上一张展示能力曲线向上弯曲的幻灯片，而这几乎总是标志着路线图悄然从一份计划变成了某种预测。

这种区别比听起来更重要。计划是你所控制的一系列事情：你将编写的代码、你将构建的集成、你将运行的测试。预测是对你无法控制的事情的押注 —— 在这种情况下，是一个尚不存在的模型，它由一个从未承诺过交付日期的供应商按其时间表发布。当你围绕 “上下文窗口将翻倍” 或 “到第三季度推理能力将足够好” 来规划功能时，你并没有消除问题中最难部分的风险。你只是把它转移到了别人的发布日程表上，并宣称已经完成了。

一切都没坏。这正是让人困惑的地方。没有部署失败，没有延迟报警，错误率也没有上升。有人合并了一个只有一行的 PR，在系统提示词（system prompt）末尾添加了一句话——一个新工具的描述、一条政策提醒，或者是“今天的日期是”的页眉——结果第二天早上，推理账单就高出了三到五倍。流量平稳，模型没变，代码也完全按照预期运行。

改变的是那一行代码放错了位置，导致你集群中所有的缓存前缀（cached prefix）瞬间失效。你的缓存命中率在一个请求周期内从 90% 降到了零，原本几乎免费的每个 token 开始按全价计费。这就是 Prompt 缓存悬崖（prompt-cache cliff），它是生产环境下 LLM 系统中最昂贵的故障模式，而且没人会对它进行威胁建模，因为它看起来根本不像故障。

你可以搭建一个预发布数据库。你可以搭建预发布队列、预发布支付沙箱，以及你所依赖的每一个第三方 API 的预发布副本。三十年来，整个预发布（pre-production）学科都建立在一个假设之上：你可以创建一个足够忠实于生产环境的副本，对其进行测试，并从中了解到发布后会发生什么的真实情况。

然后，你将托管模型添加到了关键路径中，这个假设便悄然瓦解了。那个现在主导你产品行为的组件——决定你的应用实际上在说什么、做什么的那个东西——正是你无法搭建预发布副本的唯一组件。它由别人进行版本管理，由别人进行速率限制，并由别人按照你无法察觉的时间表悄悄更新。你的预发布环境拥有一切的预发布副本，唯独没有预发布模型。

你接入了第二个模型供应商，因为第一个挂了。那是一个星期二，主供应商的状态页在几个小时内一片通红，你的功能也随之陷入瘫痪。所以你做了件负责任的事：添加了一个备选方案。现在，如果 OpenAI 无法访问，你就路由到 Anthropic。如果 Anthropic 对你进行了频率限制，你就回退到 Gemini。架构图看起来干净且成熟。可靠性问题，解决了。

可惜你添加的不是一个副本。你添加的是第二种意见。而操作“第二种意见”与操作“第二个副本”是完全不同的两回事。

你引入的心理模型来自“无状态服务”的策略：在负载均衡器后运行三个相同的实例，如果一个挂了，另外两个会提供完全相同的响应。这之所以有效，是因为副本之间在字节级别是完全等效的。但来自两个供应商的两个语言模型并非如此。它们是在不同的数据上训练的，针对不同的目标进行了微调，而且它们在用户最容易察觉的输入点上——会产生系统性的、而非随机的——分歧。