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

第一次事故很少表现为系统宕机。它通常是来自客户成功团队的一条 Slack 消息：“嘿，我们还好吗？在过去的一小时里，有五个客户升级了工单，这些工单在‘待审核’状态下已经躺了超过一天了。”你检查了模型延迟仪表盘。绿色。你检查了智能体（Agent）的成功率。绿色。你检查了单次调用成本图表。健康。你监测到的一切指标都正常。出故障的是一个你的监控栈根本不知道其存在的队列，负责该队列的人员其日历不在你的容量规划器的读取范围内，而管理它的 SLA（服务等级协议）甚至从未被书写下来。

那个队列就是你的人机回圈（human-in-the-loop, HITL）升级路径。你在三个月前为了“安全起见”添加了它——当智能体在极少数情况下置信度较低或操作风险较高时，它会将案例移交给人工审核员。上线之初，它每天可能只处理十几个条目。运维团队在处理其他任务的间隙就能搞定它们。它曾是一个兜底方案，而不是一个系统。如今，它正在处理数千个条目，解决时间的中位数翻了三倍，排队等待的客户正在悄无声息地流失。HITL 路径本身并没有失效。它只是不再被当作生产环境来对待了。

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

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

我的团队第一次发现我们依赖的模型即将退役时，是从客户那里得知的。弃用通知邮件躺在一个被三名工程师退订了的共享收件箱里。提供商的状态页上挂着横幅。Webhook 事件发射到了虚空中，因为我们从未配置过接收端。60 天的预警时间，被我们浪费成了 0 天，最终以一场停机事故和塞满“紧急迁移”同步会的日程表收场。

我交流过的大多数团队目前都处于这种状态，只是他们自己并不知道。每个主流 LLM 提供商都在悄悄构建通知层面 —— 针对故障的 Webhook、变更日志中的弃用事件、通过电子邮件发送的账户警告、账单异常提醒、区域故障转移信号 —— 而大多数团队要么禁用了这些功能，要么将其路由到了一个没人看的邮件列表。提供商一直在提前告诉你坏消息。是你选择不去听。

你的智能体管道很慢，于是你把任务拆分给五个并行子智能体。p50 下降了，你把它上线了。三天后，告警响了：一批用户请求超时。你挖进去发现 p99 从 4 秒涨到了 22 秒。单个智能体本身没有任何变化。超时是因为编排层在等最慢的那个——它以 1% 的概率遇到了检索抖动，但现在任何触碰全部五条路径的请求都会遇到这个概率。

这就是并行陷阱：这个模式看起来是显而易见的提速方案，实则以一种伤害真实用户更多的方式重构了延迟分布，p50 的改善远不能弥补 p99 的恶化。在生产基准测试中，单个智能体在 64% 的评估任务上能匹配甚至超过多智能体管道。并行扇出奏效的时候，确实奏效得很干净——但仅限于特定类别的问题。把扇出当作默认选项，才是错误所在。

一个用户在周二下午 3 点打开了你的 AI 功能。他们已经轻度使用了三周。这次请求卡住了 8 秒钟，然后返回了一个红色的横幅：“出错了。请稍后再试。”他们又试了一次。还是同样的横幅。他们关闭了标签页，回去做之前在做的事情 —— 并在第二天早上的站会上告诉队友，“那个 AI 功能坏了。”

实际发生的情况是：他们触碰到了一个隐形的单用户配额，这是你的成本团队在六个月前为了防止单个重度用户刷爆 GPU 预算而设置的。配额起作用了。支出保持平稳。仪表盘显示绿色。按照你的工程组织追踪的每一个指标来看，这项功能都是健康的。但它也已经名存实亡了，因为看到那个横幅的用户再也不会回来了，而且他们在站会上告知的那三个队友也永远不会去尝试它。

这就是你的成本仪表盘看不见的鸿沟。单用户 AI 配额是一个产品界面（product surface）。那些将其隐藏在 HTTP 429 错误代码中的团队，正任由其成本控制系统默默地塑造用户对产品的认知，而且直到流失率在季度回顾中显现出来且没有明显原因时，他们才会发现这一点。

确定性软件的 PRD 模板已经演变成了一种肌肉记忆。问题陈述、用户故事、验收标准、边缘情况、成功指标、范围削减。工程师知道如何阅读它，产品经理（PM）知道如何填写它，设计师知道该从哪些章节提取原型图。这是一个被磨损得恰到好处的产物，它交付了一代又一代的 CRUD 应用、仪表盘和 SaaS 工作流。

它也没有“模型在 5% 的情况下会出错”的字段，没有“我们接受的评估（Eval）合格分”的字段，没有“当模型拒绝回答时用户会看到什么”的字段，也没有“该 PRD 锁定了哪个提示词（Prompt）版本，以及发布后允许谁进行更改”的字段。每一个按照这种模板交付的 AI 功能，都带有一份谁也没写下来的隐性契约。复盘总是让人们在遭遇挫折后才痛苦地意识到这一点。

某团队构建了一个 RAG 功能，测量端到端延迟后发现慢得无法接受，随即开始优化模型调用。他们尝试了更小的模型、批量请求，并调整了 temperature 和 token 上限。经过两个迭代周期，延迟下降了 15%，但功能依然太慢。他们从未测量过的是：在 LLM 收到任何提示词之前，文本分块和嵌入生成就已经耗费了 600ms。

这种模式在分布式系统中普遍到有了专有名词：优化了错误的组件。在 AI 流水线中，LLM 调用显而易见且易于测量，而其之前的所有环节都是隐形的——除非你主动做埋点，否则根本发现不了——而吞吐量恰恰死在那里。

你团队中晋升理由最充分的 AI 工程师，其晋升材料（Promotion Packet）看起来却可能是空洞的。两个季度的努力，影响力图表却是一条平线。曾经在每次模型切换时都会飙升至 12% 的评估回退率（Eval-regression rate），现在稳定在 4%。财务部门差点就要介入调查的每月 4 万美元成本飙升从未发生，因为有人在网关中加入了预算守卫（Budget Guard）。本会导致公司状态页（Status Page）挂彩的 P0 级事故从未发生，因为紧急开关（Kill-switch）被触发，将流量导向了之前的 Prompt 版本。

这种材料在“已发布功能 X”一栏无话可说。定级委员会面对两个并排坐着的工程师：一个是这半年发布了两个显性功能的工程师，另一个是默默承担了让这些功能成为可能的负载的工程师。委员会一如既往地给发布功能的工程师打了高分。那位基建型（Infra-shaped）工程师要么拿了一个不应得的“符合预期”评分并在一个季度内辞职，要么学会用委员会真正能听懂的语言来撰写材料。

一个用户问你的助手，“这季度我们的退款政策有什么变化？”系统返回了一个当前退款政策的、格式良好的自信总结。用户点点头，关闭聊天，并根据一个与他们提出的问题完全无关的信息采取行动。你的评测套件（eval suite）没有捕捉到这一点。你的忠实度指标（faithfulness metric）没有标记它。检索看起来很完美——它返回了高度相关的分块（chunks）。合成看起来也很完美——它引用了它使用的每个分块。唯一的问题是，问题是关于 变化 的，而你的索引没有变化的概念。

这是向量相似度检索无法通过调优修复的失败模式。同一文档的两个版本具有几乎相同的嵌入（embeddings）——这就是好的嵌入所 做 的，它们将语义等效的文本折叠到同一个邻域中。因此，当你问“什么改了”时，检索器返回其中一个版本，LLM 总结该版本，而答案在沉默中成为了“什么都没变”的幻觉。用户无法察觉。你的评测集可能也无法察觉，因为你的评测集是围绕“什么是 X”的问题构建的，而不是“现在 X 有什么不同”。

拥有面孔的语音智能体并非简单的“带脸的语音助手”。它是一个同步视频 AI 系统，当人类第一次看到口型落后于音频三帧，并下意识地（即使无法准确说出原因）判定屏幕上的东西是假的时候，这种差异就显现出来了。那些构建了 300 毫秒语音流水线，然后又在末尾强行塞入一个渲染模型的纯语音团队，刚刚继承了一个他们在路线图中未曾预料到的实时多模态问题。

这个门槛并不宽松。在音视频偏移低于约 45 毫秒时，观众会认为是完美同步。一旦音频领先超过 125 毫秒或音频滞后超过 45 毫秒，大脑就会将这种不匹配标记为错误，即使观众无法指出具体原因。在一个数字人必须同时倾听、思考、说话和渲染的对话循环中——且在你和用户之间还隔着网络——音频输出和渲染面孔之间没有任何余地来容纳拙劣的衔接。

用户要求智能体（agent）“告知 Karen 我们完成了”。智能体调用了 send_email，收件人字段设置为 karen-team@，这是它的联系人查询工具返回的最合理的地址。这条包含三段内部专用项目状态的信息——其中包括一行关于客户续约风险的坦率描述——最终发送到了四十个收件箱。其中一个收件箱恰好属于该客户。事后分析（postmortem）持续了两周。

没有提示词注入。没有模型越狱。工具完全按照规范运行。团队为 send_email 编写的契约是“向收件人发送消息”。而现实世界强制执行的契约是“广播给一个发送者未审计其构成的群体”。这种差距——即工具的命名与其核心实际能力之间的鸿沟——正是大多数出站智能体事故的源头。

电子邮件是显而易见的例子，但同样的风险潜伏在智能体接触的每一个消息工具中。人类为这些渠道建立的三十年肌肉记忆，并未转移到那些正在通过联系人列表进行模式匹配的规划器（planner）中。

这里的数学逻辑很简单，但没人去算。在 AI 时代之前，单个用户操作（例如“总结这张工单”或“发送这封邮件”）只会产生一行应用程序日志。而在 AI 时代之后，同样的操作会产生一条请求日志、一个 LLM 调用追踪、代理调用的每个工具的工具调用 span、它读取的每个数据块的检索 span、一条响应日志，如果你采样进行离线评分，还会产生一条评估日志。一次用户点击的扇出（fan-out）现在会在你的可观测性流水线中产生 30 到 50 条记录，这还是在重试、子代理以及会让一切翻倍的规划器-执行器（planner-executor）拆分出现之前。

你在第一季度发布了一个 AI 功能。到了第二季度，你的安全总监拿着一份比上一个周期高出 4 倍的 Splunk 续订合同走进预算审查会议。AI 团队的人都不在现场。接下来的对话——关于谁来承担这笔费用、为什么威胁检测规则失效了，以及是否真的必须对每次对话进行法律保留（legal hold）——是你在设计阶段就应该进行但没有进行的对话，因为这笔成本没有出现在 LLM 的发票上。它出现在下游，出现在一个 AI 团队从未登录过的工具中。