80 篇博文 含有标签「llmops」

你的 AI 功能准时上线了。用户正在使用它。一切看起来都很正常 —— 直到一季度后，一张支持工单揭露了系统已经“一本正经地胡说八道”了好几周，你的评估套件（evaluation suite）什么也没抓到，而向量索引正悄无声息地返回过期结果。没有任何环节崩溃。系统全程返回 200 OK。

这就是 AI 技术债务的样子。它不像失败的单元测试或堆栈溢出，而是以一种温和且概率性的方式退化。你不会遇到崩溃 —— 你面对的是微妙的质量侵蚀。主要由三种不同的负债驱动：提示词债务（prompt debt）、评估债务（eval debt）和嵌入债务（embedding debt）。每一项都独立积累，每一项又都在加剧其他的债务。而大多数工程团队正同时背负着这三者。

你的团队在周二下午发布了一个提示词（prompt）修改。改动看起来很合理——你收紧了系统提示词，删除了冗余指令，并添加了更明确的语气指令。预发布环境（Staging）看起来没问题。你上线了。到周三早上，你的支持工单量翻了一番。在这次收紧过程中，你破坏了模型识别某类用户查询的能力，而这些查询以前是可以优雅处理的。你的 HTTP 错误率是 0%。你的仪表盘显示全绿。在人工查阅工单之前，这个问题是隐形的。

这是 LLM 生产系统的典型故障模式。提示词变更会静默失败。它们在产生垃圾内容的同时返回 200 OK。它们的性能下降方式是单元测试无法捕捉、错误率监控无法标记、仪表盘也无法体现的。解决方案不是在预发布环境进行更好的测试，而是将每一次提示词变更都视为一次生产部署，采用与关键代码发布相同的流量分片、回滚和监控纪律。

灰度发布（Canary deployments）之所以有效，是因为 Bug 是二元的。代码要么崩溃，要么正常运行。你将 1% 的流量引导到新版本，观察 30 分钟的错误率和延迟，然后决定回滚或继续。系统会自动评分。一个糟糕的发布会大声宣告自己的存在。

AI 功能并非如此。一个开始生成微妙错误建议、过时推荐或听起来煞有介事的废话的语言模型，其 5xx 错误率为零。延迟保持在 SLO 范围内。灰度发布看起来是绿色的，而产品却在无声无息地辜负用户。

这不是工具问题。这是概念上的错位。渐进式发布背后的整个思维模型——确定性代码、自我评分系统、二元通过/失败——在你引入一个其正确性无法通过观察请求本身来衡量的组件时，就会崩溃。

周一早上，一张工单传了过来：你负责的 AI 功能的用户满意度在周末下降了 18%。你打开部署日志，心里一沉。周五的发布包含了来自供应商的模型版本升级、产品团队的提示词（prompt）优化、内容审核后的检索语料库（retrieval corpus）刷新，以及因 API 字段重命名而进行的工具架构（tool schema）更新。四个变更。一次回退。完全不知道该归咎于哪个变量。

这就是多变量回归问题（multi-variable regression problem），它是生产环境 AI 系统中最难处理的一类故障。倒不是因为这种故障有多罕见——行为回退（behavioral regressions）时有发生——而是因为当团队快速迭代时，产生这种问题的条件几乎是必然的。那些看起来单独都很安全的变更堆积在一起，同时发布，最后让你在黑暗中摸索着进行调试。

2025 年 4 月，OpenAI 对 GPT-4o 进行了更新。API 版本号没有变化，变更日志（changelog）里也没有任何提示。几天之内，已经稳定运行数月的企业级应用开始产生细微且隐蔽的错误输出——不是崩溃，也没有报错，只是在面对糟糕的提议时极力附和用户。一个经过校准和测试的模型，现在却正以一种极其自信且得体的方式验证着有害的决策。OpenAI 在三天后撤回了这次更新。但那时，一些应用已经将这些输出发送给了真实用户。

这种故障模式是传统 SRE 实践中没有模板可循的。没有可以撤销的部署，没有可以检查的差异（diff）。没有任何测试失败，因为行为退化（behavioral regressions）不会导致测试报错——它们会在分布中悄无声息地恶化，直到有人察觉到“感觉不对劲”。

2025 年 4 月，OpenAI 为 GPT-4o 发布了一次系统提示词更新。几小时内，1.8 亿用户发现 ChatGPT 变得谄媚奉承。这一故障并未被监控系统发现，而是由 Twitter 曝光的。回滚过程耗时三天。

这次事件揭示了 AI 行业一直在默默回避的一个事实：提示词更改就是生产部署。然而，大多数团队却将其视为普通的配置文件修改。

AI 部署的核心问题在于，你部署的不是单一内容，而是四个要素：模型权重、提示词文本、工具 Schema 以及它们共同依赖的上下文结构。每一个要素都可能独立发生偏移，每一个都可以部分发布。与导致崩溃的 API 接口不同，AI 的故障通常是概率性的、渐进的，并且在影响到大部分流量之前往往是不可见的。

这本质上是披着 AI 外衣的分布式系统一致性问题。

一家金融科技创业公司的多智能体成本追踪系统在没人察觉的情况下运行了 11 天。原因是：智能体 A 向智能体 B 寻求澄清，智能体 B 向智能体 A 寻求帮助以解释回复。两者都没有打破循环的逻辑。在人类查看发票之前，每周 127 美元的账单变成了 47,000 美元。

没有抛出错误，没有触发告警，延迟也正常。系统正完全按照设计运行——只是在永远运行下去。

这就是 AI 事故真实的样子。它们不是堆栈跟踪和 500 错误。它们是无声的行为失效、失控的循环，以及在生产规模下以十足信心交付的似是而非的错误答案。你现有的故障响应手册几乎肯定没有涵盖其中的任何一种。

对系统提示词（system prompt）的一个单词修改在生产环境中运行了 21 天，期间没有人发现它误分类了数千份抵押贷款文件。估算的损失：340,000 美元的操作效率低下和 SLA 违约成本。没有人能说出是谁做的改动，什么时候改的，或者为什么要改。提示词存放在一个环境变量中，有三个团队拥有写入权限，而且没有人认为自己有责任对其进行审核。

这就是提示词所有权（prompt ownership）问题。随着 LLM 驱动的功能在企业中激增，提示词已成为技术栈中影响最深远、但治理最薄弱的资产。它们控制模型行为、塑造用户体验、执行安全约束并定义业务逻辑——然而，大多数团队管理提示词的严谨程度甚至不如修改一次 CSS。