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

我建议的一个团队花了两个月时间在其 RAG 流水中不断更换 LLM。从 Claude 到 GPT，再到 Gemini，最后又换了回来。每一次更换都能让幻觉率降低几个百分点，但从未在关键指标上有所进展：他们的支持代理找到正确知识库文章的概率仍然不到 60%。他们调优的层级错了。检索器返回的是无关的文本块，而无论 LLM 多聪明，都无法根据检索器从未呈现过的文档来回答问题。

嵌入模型是 RAG 系统中决定 LLM 甚至“被允许”看到什么的部分。它描绘了语料库的几何结构——即在向量空间中，哪些文档会落在哪些查询附近。一旦这种几何结构出错，LLM 就只是一个对错误上下文侃侃而谈的自信叙述者。换一个更聪明的 LLM 通常只会让回答更显“文采”，而不会让回答更准确。

评估分数连续两个季度呈上升趋势。仪表盘是一片绿色，回归测试套件自三月以来从未标记过真实的失败，团队交付 prompt 更改的速度也变快了，因为评估（eval）给出了清晰的通过/失败答案。与此同时，用户反馈的质量正在下滑。NPS 下降了 4 分，支持队列里堆满了没人标记过的失败模式，产品负责人开始质疑：如果客户这么生气，为什么评估结果看起来却这么好？

评估集没有撒谎。它正在回答六个月前它被构建时要回答的问题，针对的是发布周存在的流量分布。产品已经发生了偏移。用户群体已经发生了偏移。发布时团队未预见到的长尾用例现在占了流量的三分之一。评估集仍在衡量第一周的世界，而团队正在用昨天的产品对今天的模型求平均值。

这就是评估集腐化（eval set rot）。它是现代 AI 工程中最隐蔽的失败模式之一，而且随着评估集的变大而变得更糟，因为维护它的人将“更多用例”误认为是“更好的覆盖”。

我最近合作的一个团队有三个不同的“总结这份合同”提示词。一个存在于 Notion 页面中，法律科技小队将其复制粘贴到他们的服务里。一个存在于客户成功后端的 prompts/ 文件夹中，为了适应他们的语气偏好做了轻微修改。还有一个内联在数据团队 notebook 里的 Python 文件中，被硬编码在两个 f-string 插值之间。当 OpenAI 弃用了它们运行的所有模型时，迁移计划变成了一场 “Slack 考古” —— 必须追踪到每个所有者，重新评估每个变体，其中两个变体在生产环境中默默地出了一周的故障才被察觉。

这就是规模化后的提示词 Cookbook 的样子。对于十个提示词和一个团队来说，Cookbook 是合理的。但当提示词达到一百个、团队达到四个左右时，它们就会变得难以管理。当你运行一个 AI 组织时，你的 prompts/ 文件夹（装满 .md 文件）的表现就像 2008 年那种靠复制粘贴引入的第三方代码：每个消费者都有自己的快照，偏差（drift）是不可见的，而破坏性变更会以不可预测的方式向外扩散。

你团队每季度演练的灾备 (DR) 操作手册是为了一套你已经不再完全运行的技术栈编写的。手册上写着：提升从库、重新指向 DNS、清空队列。它假设状态存储在数据库、队列和对象存储中 —— 这些是 SRE 团队已经管理、命名并测试了十年的地方。接着在上个季度，你上线了一个智能体 (agent)。现在，工作内存存在于推理提供商的会话缓存中、工作节点本地磁盘上的草稿文件里、尚未回写的在途工具调用结果中，以及仅存在于单次模型调用提示词历史中的部分“计划-执行”轨迹 (trace) 里。这些都不在资产登记簿上，也不在操作手册里。

当区域宕机时，智能体并不会干净利落地失败，而是处于一种“半完成”的状态。用户看到工作流已经开始，但故障转移后的区域无法恢复进度；客户收到了两次账单，或者根本没收到，因为幂等键存在于已经失效的工作节点上；值班工程师读着 Slack 频道里的讨论，开头是“编排器已启动，但是...”，六小时后以处理信用卡拒付队列告终。

这就是没人点破的鸿沟：智能体特性拥有现有灾备计划未曾描述的状态模型。如果团队还没有记录下这些状态表面，那么只需一次区域性停机，他们就能深刻体会到操作手册的缺失所带来的代价。

周二，客户给支持团队发了一张截图。他们的账户显示六天前有一笔他们从未要求的退款。你的 CRO 转发了这张截图，并问了一个问题：“这是怎么产生的？”你知道是智能体（agent）干的——审计日志显示 actor: refund-agent-v3。但自那以后，提示词（prompt）已经修改了四次。由于财务部门为了追求 12% 的成本削减而更换了供应商，模型 ID 在上周四进行了轮换。系统提示词是根据三个检索到的文档生成的模板，而检索索引在周一重新进行了索引。对话历史被运行时（runtime）裁剪，以适应更小的上下文窗口。

你可以告诉 CRO 是智能体做的。你无法告诉他们为什么。这种差距——即知道发生了某个操作与能够重建导致该操作的输入之间的差距——是大多数智能体团队在工程团队之外的人提出真正的取证问题时发现的。

一个平台团队在周三下午发布了他们的每周智能体 (agent) 版本。内部更新日志写得很尽职：三次系统提示词 (system-prompt) 提交，模型别名从 -0815 快照升级到 -1019，四处工具描述修改，新的评估准则 (eval-rubric) 权重，以及更新后的检索器索引。到了周五，支持队列里出现了 18 个工单，平台团队中没人能把这些工单与变更对应起来。工单 2 和 7 说 “机器人突然拒绝总结私有仓库”。工单 11 说 “输出中的每个代码块现在都带有语言标签，我们的下游解析器因此崩溃了”。工单 15 说 “在长输入下工具 X 的调用频率翻了一番，我们触及了速率限制”。

这些工单没有一个提到更新日志中的任何一行。平台团队的发布说明是一份文件移动清单。集成方的工单是一份行为变更清单。这两份文档互不交集，而信任就在这个鸿沟中流失。

浏览任何成熟工程团队的 PR 队列，你都会看到同样的现象：一个四行的 Bug 修复会引来三轮关于命名、错误处理和测试覆盖率缺失的评论；而对系统提示词（System Prompt）的四十行修改却能凭借一句 “LGTM, ship it” 轻松过关。作者对此不以为意，因为差异对比（diff）看起来就像文档；审查者也无所谓，因为他们对于那段英文块中什么是“好”没有心理模型。结果是，一个具有功能发布级别影响范围的提示词更改，却仅以修复拼写错误的门槛通过了审查。

这是每个在生产环境中使用 LLM 构建产品的团队所面临的隐秘质量危机。代码库拥有数十年积累的纪律——Linter、类型检查、代码所有者（Code Owners）、测试关卡、发布窗口。而真正引导模型的产物——系统提示词、评估准则（Eval Rubric）、工具描述、少样本示例（Few-shot Exemplars）——虽然存放在同一个仓库中，却通过为英文散文设计的审查流程进行发布。因此，提示词回归、评估准则漂移和工具模式（Schema）损坏，却能以团队永远不会接受的代码质量标准通过。

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

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

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

一位平台工程师修改了公司“品牌风格”序言中的开场白——这是用于统一所有面向客户的助手语气的一行代码。这项改动通过 feature flag 发布。到了周二，搜索团队的相关性退化指标激增，支持机器人的评估通过率下降了四个百分点，入职引导 Agent 的重试率翻了一倍。这些团队中没有一个动过自己的代码。他们都没有收到任何预警。平台工程师对这一切一无所知，因为没人收到过类似的警报：“你的修改刚刚搞坏了三个下游功能。”

这就是定义 AI 团队成立第二年后的典型失效模式。第一年，每个团队都在各自的角落闭门造车。第二年，这些角落开始共享产物——这里一个提示词片段，那里一个种子评估集，或者一个被当作协议复用的工具 Schema。当这种共享变得隐性时，AI 功能之间的依赖图就变得不可见了。你现在拥有的是一个没人能叫出其边缘名称的分布式系统。

解决这一问题的方法论（discipline）并不是一个新平台，而是绘制这张图。

我上个季度合作的一个团队发布了一个 AI 助手，并附带了一整套完备的支撑文档：一个提醒 AI 可能会生成不准确结果的产品内工具提示（Tooltip）、一篇题为“助手如何工作”的帮助中心文章、一份处理升级问题的内部支持操作指南（Runbook），以及一份列出了底层模型、助手可调用的工具及其覆盖的数据领域的公开模型卡（Model Card）。发布过程非常顺利。六个月后，提示词（Prompt）被修改了 14 次，模型在不同层级间进行了切换，拒绝行为（Refusal Behavior）发生了微妙的变化，增加了两个新工具，一个工具被废弃但未从提示词中移除，语言设置也从仅限英语扩展到了 9 个语种。

每一份文档都出错了。并非灾难性的错误——而是那种一句话半真半假、描述的功能与模型实际表现不再匹配、记录的拒绝模式在新模型中从未触发、或者帮助文章里出现的工具名称助手根本不会调用的那种错误。这类错误会产生持续不断的令人困惑的支持工单，当 AI 做了文档说它不会做的事情时会导致客户信任倒退，并且——因为公司在受监管的垂直领域销售——还会产生一个微小但真实的合规漏洞，而 AI 团队中没有人想到要跟踪这一点。

我上个月交流过的一个团队，在四个星期内将一项新的 Agent 功能从 1% 的用户灰度推广到了 50%。聚合质量指标保持在噪声范围内，延迟也保持在 SLA 之内。他们正在准备 100% 全量发布的备忘录时，支持队列突然“起火”了——一个拥有六工具研究工作流的客户，自 10% 灰度阶段以来就一直在接收静默损坏的输出。困难查询（Hard queries）一直存在，均匀地分布在每个分群中，被平均化到了底噪中。直到一个高频用户在大规模使用中撞上了这些问题，大家才发现。

这不是监控失败，而是灰度发布维度的失败。功能标志工具（Feature flag tooling）——包括 LaunchDarkly、Flagsmith、Unleash 和 Cloudflare-Flagship 等所有此类工具——都假设爆炸半径（blast radius）随接触到的人数成比例扩大。对于确定性软件，这在很大程度上是正确的：一个空指针异常（NullPointerException）要么影响所有人，要么谁都不影响，将其暴露给 1% 的用户会将可见的爆炸范围限制在 1%。但对于 AI 功能，爆炸半径并不在“人”这个维度上扩展，而是在“输入”维度上扩展。而几乎没有人会在输入维度上进行灰度发布。

打开公司里那位上线真实的 AI 功能超过六个月的工程师的日历。数一数那些重复出现的 “30 分钟同步 —— 关于 Agent 的问题” 邀请，那些最终被预定的即时 “能耽误你 15 分钟吗？” Slack 消息，那些被标记为 “可选” 但他们实际上不得不参加的架构评审，以及最初只是周五下午的一个时段、现在却每天吞噬两个小时的 Office Hours。然后看看路线图，追踪哪些功能取决于该工程师尚未做出的决定。两者的交集才是你真正的发布时间表。Jira 看板只是虚构。

这就是 AI Office Hours 瓶颈，它在 2026 年的 AI 组织中是核心承重约束，尽管组织里没人会大声说出来。团队快速扩展了 AI 功能开发 —— 每个产品小组都拿到了模型预算，每个 PM 都学会了写 Prompt —— 然后把每一个 “这个模型对吗”、“这里该不该用 RAG”、“我们的评估设计是否有效”、“为什么缓存命中率很奇怪” 的问题都抛给了唯一那个真正上线过足够多生产环境 AI 功能、能给出答案的工程师。六个月后，那位工程师的日历成了半个路线图的限速试剂，“我需要找他谈 30 分钟” 成了你的事故响应本该明确化的核心升级路径。