跳到主要内容

16 篇博文 含有标签「llmops」

查看所有标签

AI 回滚仪式:当损害是行为性而非二元性时的事故后恢复

· 阅读需 13 分钟
Tian Pan
Software Engineer

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

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

零停机 AI 部署:这是一个分布式系统问题

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

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

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

生产环境 AI 故障响应:当你的智能体在凌晨 3 点出错时

· 阅读需 13 分钟
Tian Pan
Software Engineer

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

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

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

提示词所有权问题:当所有团队都将提示词视为配置时会发生什么

· 阅读需 10 分钟
Tian Pan
Software Engineer

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

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