153 篇博文 含有标签「production-ai」

这是一个在生产环境中比任何人愿意承认的更频繁出现的场景。用户询问 AI 助手当前的利率政策。你的 RAG 系统获取了一份高度相关的美联储文件——语义相似度评分高达 0.91——模型自信地返回了答案。但这个答案已经过时六个月了。RAG 索引上次刷新是在十月份。参数化知识则更为陈旧。一次实时 API 调用本可在 400 毫秒内返回正确的当前数据，但没有人在路由逻辑中加入这样的判断：这个问题的答案允许有多旧？

这种失败不是检索失败，而是时序路由失败。系统在其技术栈的某处确实能够获取正确信息，只是将查询发送到了错误的层级。

当一个 PlanCompiler 风格的智能体（agent）与直接的 LLM 生成代码模式在 300 个分层多步任务中进行基准测试时，结构化方法实现了 92.67% 的成功率，单任务成本为 $0.00128。而直接方法——即 LLM 在自由形式的循环中逐步决定行动——成功率为 62$0.0106。这意味着准确率提高了 50%，而成本仅为原来的八分之一。

差异不在于模型的能力。两种方法使用的是同一个模型。差异在于架构：一个将计划生成与计划执行分离开来；另一个则将两者混为一谈。

大多数团队处理提示词变更的方式，就像他们在2008年处理配置文件变更一样：编辑字符串，重新部署，然后祈祷。没有版本标签，没有测试套件，没有回滚计划。区别在于，配置文件变更很少会改变整个产品的语义行为——而提示词变更几乎总是会这样做。

如果你发布过面向客户的LLM功能，你可能已经经历过这种情况：为了"改善"语气而编辑了系统提示词，将其与无关的错误修复一起部署，三周后却不知道为什么用户满意度下降了。提示词才是罪魁祸首，但你根本没有办法知道这一点。

大多数团队发现“零样本墙”（zero-shot wall）的过程都如出一辙：一个新的边界案例导致模型出错，他们向提示词（prompt）中添加一个示例，问题解决了。三个月后，他们已经累积了 40 个示例，消耗了 6,000 个 token 的上下文，性能指标数周没有变化，而那个清楚每个示例来源的提示词工程师刚刚离职了。

少样本提示（Few-shot prompting）非常具有诱惑力，因为它见效快。你观察到一个失败案例，添加一个演示示例，失败就消失了。反馈循环很紧凑，而且胜利感觉是无成本的。你没有注意到的是，随后的每一个示例带来的收益都在递减——到某个阶段，你为了那些几乎可以忽略不计的改进，付出了大量的 token、延迟和认知开销。

这就是“零样本墙”：它不是性能断崖式下跌的硬限制，而是一个收益锐减的区域。在这个区域，上下文学习（in-context learning）对于你的任务已经达到了天花板，剩下的唯一手段就是微调（fine-tuning）。

打开你的 AI 功能延迟和质量看板，眯起眼睛仔细看。曲线大部分时间是平缓的，偶尔会有一些峰值，你的团队几个月来一直称之为“噪音”或“供应商异常”。现在，按小时和星期几来拆分这些数据。噪音显现出了真面目：在东部时间每个周一上午 9 点到 11 点之间，你的 p95 延迟比周六晚上高出 30–60%，缓存命中率下降 10–20 个点，重试率翻倍，每个任务的 token 支出也在悄然攀升。看板没有撒谎，它只是在做平均。

大多数团队发现这种模式的方式就像发现缓慢漏水一样：通过回溯没人能解释的季度账单。直觉是将其归结为供应商的不稳定性，给推理厂商提个工单，然后就此作罢。但这种模式其实与你的 LLM 供应商无关。事实是，你的 AI 功能现在构建在一堆共享的、对时间敏感的系统之上——模型 API、embedding API、你的 agent 调用的 SaaS 工具、接收 webhook 的客户自身基础设施——而其中每一个系统的周期性负载模式都会发生叠加。你继承了整个依赖链的昼夜曲线，而你的看板向你展示的是所有这些曲线的平均值。

这是多智能体系统设计在架构评审中很少被提及的一个令人不安的事实：当你让两个智能体处理同一任务时，它们在20%到40%的情况下不会就答案达成一致，具体比例取决于任务类型。大多数系统的应对方式是静默地选择其中一个答案。日志中只显示最终决策，中间的分歧消失无踪。一切看起来运转正常，直到下游出现故障——而你要花费三到五倍的时间来调试，因为你搞不清楚哪个智能体出错了，甚至根本不知道它们曾经存在过分歧。

智能体之间的分歧不是一个可以稍后处理的边缘情况。随着并行智能体拓扑逐渐成为标准架构模式，冲突解决从脚注升级为一级可靠性纪律。

一个 AI 功能在周二出现了回归。评估（eval）CI 是绿色的。护栏（guardrail）仪表盘很干净。检索（retrieval）P95 指标正常。模型供应商没有任何故障。然而，支持队列中挤满了用户，他们反映助手“本周感觉变差了”。产品经理（PM）是房间里唯一能说出哪里回归的人，但即便是她也无法告诉你哪个仪表盘能捕获到这个回归。欢迎来到“接缝 Bug”（seam bug）的世界——这种故障中，每个单独的产出物负责人（artifact owner）都能证明自己的部分没问题，但集成后的体验依然是坏的。

这是 AI 功能人员分配方式的必然结果。纸面上的负责人名单看起来很合理：提示词作者负责系统提示词，评估负责人负责离线测试集和 CI 门禁，工具/检索负责人负责函数调用和搜索索引，护栏负责人负责审核和策略过滤器。此外，还有一个模型选择决策，通常游离在这四者之外——有时归属于平台团队，有时归属于最近提交采购单的那个工程师。五个负责人，却没人对“这个功能对用户是否有用”负责。

那些将“我们使用最新模型”视为美德的团队，距离长达一个季度的计划外工作只差一封下线邮件。当弃用通知送达时，决定你是否能消化它的架构决策早在几个月前就已经做好了——而且是由那些根本没考虑过迁移的人做出的。评估套件（eval suite）隐式地针对特定检查点（checkpoint）进行了训练。提示词（prompts）是针对特定的拒绝风格（refusal style）进行调整的。成本预测假设了特定的任务令牌（token-per-task）基准。路由器的硬编码回退（fallback）模型本身也即将消失。在邮件到来之前，这些决策看起来都不像是风险，而一旦邮件到来，它们看起来就全都是同一种风险。

模型弃用现在是 AI 技术栈中最可预测的意外。Anthropic 对公开发布的模型至少提供 60 天的通知期。OpenAI 的通知窗口从针对特定快照（snapshot）的 3 个月到针对基础模型的 18 个月不等，但在实践中，最近一批 ChatGPT 模型的退役对某些团队来说只有短短两周的预警。GitHub 在 2026 年 2 月的一次协调变更日志条目中，集中弃用了一系列 Anthropic 和 OpenAI 模型。现在的模式不再是“如果模型退役”——而是“每个季度，你的技术栈所依赖的至少一个模型会进入退役窗口，而这个时间表与你的路线图并不同步”。

工程主管们对“代码腐烂”这一概念已经习以为常。依赖项需要更新，基础设施有生命周期管理，证书会在无人质疑的日期过期。然而，提示词仓库（prompt repository）却往往被视为一种“一次编写，多次读取”的产物——尽管它定义了你的产品如何与一个每六周就发布一次行为变更的概率引擎进行对话。

六个月前针对当时主流模型调优的系统提示词，现在依然在生产环境中使用。针对早已变更的分词器（tokenizer）挑选的 Few-shot 示例，仍在每次调用时被注入。重排序提示词是针对供应商上季度已废弃的嵌入端点调优的。没有人安排审查。也没有人打算去安排。

这并非假设性的失效模式。当一个团队将其精心针对 GPT-4-32k 稳定化的提示词套件迁移到 GPT-4.1 和 GPT-4.5-preview 时，其回归测试的通过率分别仅为 95.1% 和 97.3%。在生产环境中，3-5% 的隐性质量退化绝非可以忽略的误差；在任何具有一定规模的场景下，这都是一种用户可见的退化，而团队中没人是有意发布这种退化的。而且，这些还是拥有回归测试套件的团队。中等水平团队的“回归测试”，不过是值班工程师在处理上一次事故时凭感觉形成的印象。

我们缺失的范畴是提示词资产折旧（prompt asset depreciation）：这是一种维护纪律，它将每个生产环境中的提示词视为具有已知寿命的折旧资产，而非一成不变的常数。

评测榜单的分数一夜之间掉了两分。在绿色运行（通过）和红色运行（失败）之间，唯一发布的内容就是上周的提示词 PR —— 那个包含了 17 处修改的 PR。两个章节调整了顺序。三个新的 few-shots。一个更严厉的拒绝条款。一个更换过的角色描述。还有一些人称之为“润色”的单词级改动。当复盘开始时，有人说了句显而易见的话：“肯定就是其中之一。”然后他们花接下来的两天时间去搞清楚到底是哪一个。

这两天时间是寻找单一回归最昂贵的方式。而另一种只需几分钟的方法则完全借用了一个有着 40 年历史的内核调试技巧：对补丁进行二分查找 (bisect)。将提示词视为一系列可回滚的变动块 (hunks)，将评测套件作为断言条件，让二分查找隔离出导致分数波动的代码行。其中的数学原理与 git bisect 在提交记录上运行的原理一致，而且它强制要求的提示词管理规范，其带来的收益甚至超过了二分查找本身。

在过去六个月中，我审计过的每一个团队都声称自己是供应商无关的。但实际上没有一个团队能做到。在评估套件中得分最高的系统提示词之所以表现出色，是因为它倾向于单一供应商的分词器行为、JSON 模式协议、拒绝节奏以及停止序列处理 —— 而编写该提示词的团队甚至无法说出其中哪些偏差在起作用。当 CFO 询问为什么采购清单上更便宜的模型不能直接替换时，诚实的回答是：这需要两个工程师季度的提示词重新调优以及对每个评估进行完全的基准重设。这不仅仅是一个勾选项。它是一个季度的成本项。

一直困扰团队的心智模型是将供应商可移植性视为一次性的架构决策。你添加了一个抽象层，在配置中写了一个 model: 字段，以此自我庆贺，然后继续前进。一年后，当供应商提价、发布弃用通知，或者在你关注的某个类别上出现了一周糟糕的拒绝服务时，你发现那个抽象层只是一个围绕特定模型提示词的薄包装。你买到的可移植性是语法上的。而你真正需要的是行为上的可移植性，且行为上的可移植性在你停止支付的那一刻就会衰减。

在一个严肃的 LLM 项目进行到第六周时，总会有那么一个时刻，Prompt 迭代日志开始变得像一本心理治疗日志。每一次微调都是在用一种失败模式交换另一种。增加一个更严格的 “do not”（不要）条款，模型在以前能处理的情况下就开始回避。放软语气，另一类幻觉又回来了。评测得分板在三四个点的范围内徘徊，拒绝突破。有人说，“让我再试一次重新排序，”于是又是半天时间烟消云散。

这就是局部最优陷阱（local-maximum trap）。团队正在爬山，但这山头已经到顶了。残忍的是，这座山是真的——每一次 Prompt 的改动确实会在某些案例子集上产生可衡量的变化，而这正是让每个人持续微调的信号。被忽略的是：上方的天花板根本不是 Prompt 的天花板。