89 篇博文 含有标签「llm-ops」

目前你的系统中有一个损坏的 prompt 影响了约 3% 的流量，但你的仪表盘根本察觉不到它的存在。p99 延迟图表是绿色的。错误率保持平稳。模型调用成功率指标高达四个九。唯一的故障迹象出现在一张平台团队无法复现的客户支持工单中，而等这张工单进入调试环节时，相关的 trace 已经因为采样而被丢弃了。

这不是监控缺失，而是一个分类错误。你正在运行的 APM 是为维度受限（如 endpoint、status_code、region、service）的世界设计的，在这种情况下，增加一个标签的成本最多只是增加几个新的时间序列。LLM 工作负载完全不符合这种模式。真正有趣的维度是用户的 prompt、检索到的 context ID、工具调用序列、模型版本、prompt 模板版本、租户（tenant）、语言区域（locale），以及请求所属的 eval bucket。每一个维度都是高基数（high-cardinality）的，只要你用其中任何一个子集来标记 span，指标存储瞬间就会爆炸。

在你的技术栈中，每一个设计良好的 HTTP API 都会返回分页结果。没有人会把一百万行数据加载进内存并祈祷一切顺利。然而，你的智能体（agent）所调用的工具却会返回整个列表，而智能体也会尽职尽责地阅读它，因为函数签名写的是 list_orders() -> Order[]，且智能体不像人类用户那样拥有“滚动并加载更多”的协议。

智能体在原本可以跳过的行上浪费了 Token。拥有 50K 记录的长尾客户遇到了中等规模客户从未见过的上下文窗口失败。工具作者无法从追踪（trace）中判断智能体是需要所有这些行，还是仅仅因为无法请求更少的数据。而且，在你评估套件的某个地方，原本会标记这种退化的回归测试从未运行，因为每个测试固件（test fixture）的记录都少于 100 条。

分页不是一种 UI 交互功能。它是一种负载卸载（load-shedding）原语 —— 而在没有分页的情况下使用工具的智能体，正在重新犯下你们公司的 API 设计师们花了十年时间才学会避免的每一个 SELECT * FROM orders 错误。

事故报告读起来就像一个单元测试的恐怖故事。一次 Prompt 编辑作为“前置说明清理（preamble cleanup）”的一部分，删除了一段五行的安全条款。测试套件中的每个 Eval（评估）都通过了。每个 Judge（裁判）评分都保持在容差范围内。两周后，一个面向客户的助手产生了一个本该被拒绝的响应，这种响应会在深夜 11 pm 触发信任与安全（Trust & Safety）页面的报警。复盘将这次回归追溯到了一个 PR 中的单处删除，而当时没有任何人标记它，因为负责捕捉回归的套件对安全条款是否存在没有意见——它只对模型在套件记得询问的情况下的表现有意见。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=Prompt%20Linting%20%E6%98%AF%20Eval%20%E4%B8%8E%E7%94%9F%E4%BA%A7%E7%8E%AF%E5%A2%83%E4%B9%8B%E9%97%B4%E7%BC%BA%E5%A4%B1%E7%9A%84%E9%82%A3%E4%B8%80%E5%B1%82"]

这就是行为评估（behavioral evals）与结构正确性之间的鸿沟。Eval 衡量的是模型生成的内容；它们不衡量 Prompt 本身是什么。而 Prompt 就像代码一样，有一个独立于行为而存在的结构层——必须存在的章节、必须解析的引用、必须插值的变量、必须遵守的长度预算、以及绝不能出现的弃用标识符。当结构层断裂时，行为表现通常会在一段时间内保持绿色，直到生产环境中的某个边缘情况将故障暴露为事故。

评估套件在凌晨 2 点运行。流量很低。缓存是冷的，但队列是空的。供应商的连续批处理程序有空闲插槽，并将以接近其 TTFT（首 Token 延迟）底线的水平处理每个请求。延迟分布很紧凑，评测模型分数稳定，仪表盘显示一片绿色。团队发布上线。

六个小时后，太平洋时间上午 8 点，同样的 Prompt 在美国早高峰期间进入生产环境。p95 延迟是评估报告的 2.4 倍。相当一部分请求从一个供应商那里收到了 529 错误，并回退到另一个供应商的较小路由层级。流式传输的节奏更加断断续续。评测模型（当天晚上对生产环境追踪样本进行重新运行）给出的中位数得分比凌晨 2 点给出的相同 Prompt 的得分低了半分。代码库没有变化。Prompt 没有变化。只是挂钟时间变了。

必须意识到的架构真相是：LLM 调用不是其输入 Token 的纯函数。它是一个随机分布式系统调用，其输入包括挂钟时间、供应商集群的负载、Prompt 缓存的状态、当前解码批次的大小，以及供应商负载均衡器在你的请求到达的那一毫秒所做出的路由决策。在凌晨 2 点运行评估的团队，是在一种用户永远无法体验到的条件下校准仪器。

一个功能发布时通过率为 92%。发布演示稿（Launch deck）为此庆祝。12 个月后，同样的功能通过率降到了 78% —— 没有事件报告，没有部署失败，没有任何单一的变更可以追责，仅仅是无人负责监控的缓慢侵蚀。团队将其归咎于“幻觉”或“用户行为转变”，选了一名初级工程师去调查，并设定了一个“提高质量”的季度 OKR。OKR 没能达成。该功能上线了一个道歉对话框，告诉用户 AI 有时会犯错。六个月后，它被弃用，取而代之的是一个发布时通过率为 91% 的新版本，循环再次开始。

这并非运气不好。这是 AI 功能运行的“第二时钟”，一个在发布时没有人会在日程表上标注的时钟。传统软件也有功能衰减 —— 依赖漂移、代码库腐化、缓慢积累的半成品重构 —— 但这些衰减是发生在工程团队已经理解并预留预算的时钟上。AI 功能具备上述所有问题，此外还有一系列传统摊销假设无法建模的并行衰减源：模型弃用、厂商权重轮换、用户输入的分布偏移、不断叠加的 Prompt 补丁、评估器（Judge）校准偏移，以及不再能代表生产流量现状的评估集的悄然老化。

在下一个 AI 功能发布之前，而不是之后，必须落地的架构认知是：AI 功能具有非零的基础维护成本。功能在发布时并没有“完成”。它已经进入了一个无法逃避的维护周期，而那些没有为这个周期预留预算的团队，终将通过惨痛的方式发现这一点。

团队承诺“在本季度交付 AI 摘要生成器”，在第十周通过了技术门槛，在全员大会上庆祝胜利，然后正式上线。六周后，遥测曲线开始向错误的方向弯曲——无声且缓慢，没有人为其制作仪表盘，因为没有人负责这个曲线的走向。OKR 已经被标记为绿色。下个季度的 OKR 已经围绕新功能的发布起草好了。摘要生成器现在成了某个人的次要维护工作，到季度末评审时，团队开始纳闷，为什么在没有任何明显变化的情况下，该功能的客户满意度下降了 15 分。

这不是团队的缺陷，而是运营模式的缺陷。季度 OKR 是为软件校准的，在这种模式下，一个功能可以被界定范围、构建、交付，然后很大程度上就可以不管它，直到下一次重大版本更新。AI 功能不具备这种特性。它们有一条上线曲线和一条持续曲线，而持续曲线才是大部分价值——以及大部分风险——真正所在。将它们视为带有发布日期的交付物的 OKR 模板，悄悄地产生了一系列在下一个规划周期之前就已失效的演示产品。

页面告警在凌晨 2:47 响起。智能体（Agent）正向客户支持工单发送语气错误的回复，延迟仪表盘显示平稳，错误率正常，而且由于过去 12 小时内没有进行过任何部署，没有任何东西可以回滚。值班工程师打开了运维手册（runbook），滑过了“重启工作线程池”和“扩容队列”，直到翻到底部，也没发现任何能与眼前告警相匹配的内容。他们在凌晨 3:04 开始阅读系统提示词（system prompt）。到凌晨 3:31，他们仍在阅读。

这是全新的故障形态。那些为“高延迟意味着重启 Pod，5xx 错误增加意味着回滚部署，队列深度增加意味着扩容工作线程池”而设计的轮值制度，已无法应对此类问题。第一直觉——回滚部署——是错误的，因为根本没有部署：模型在版本化别名（versioned alias）后静默升级了，第三方工具的响应结构发生了偏移，提示词版本在不同区域间出现了偏差，或者评估集在几周前就已失效，而回归问题一直在持续累积。告警是真实的。运维手册却保持沉默。AI 值班现在已经成为一门独立的学科，试图将其强行套入现有的轮值体系，只会产生那种在告警发生时，所有人第一步都是在通话中相对无言、第一次开始阅读提示词的方案。

你账单中最便宜的推理费用，是那些你付了两次的钱。几乎所有主流模型提供商现在都提供批处理层（batch tier），价格大约只有同步推理的一半，代价是接受以小时而非毫秒计的完成窗口。大多数工程团队要么完全忽视这一选项，要么只是随手扔进一个深夜定时任务（cron），然后宣称省下了钱。这两种做法都白白浪费了 30%–50% 的推理总支出——并非因为折扣不够大，而是因为批处理并不是一种代金券。它是一个全新的产品层面，拥有自己的 SLA、重试语义和失败模式。那些仅将其视为计费优化的团队，最终要么使用率低下，要么上线了需要数周才能排查出来的细微回归问题。

技术核心不在于“我们是否应该使用批处理？”，而在于：你系统中的哪些动作在用户感知层面确实是同步的，哪些是工程团队为了开发体验方便而“误当成”同步的，以及哪些可以在下游消费者不预设结果实时性的前提下重新塑造为任务（jobs）。回答这个问题需要进行工作负载审计、从“请求型（request-shaped）”到“任务型（job-shaped）”契约的架构转变，以及根据用户预期而非开发便利性，对每个智能体动作进行延迟层级的诚实映射。

评测团队在 PPT 上写下一个数字：“p95 延迟为 1.2s。” 产品上线。一周后，值班人员发布了一张图表：生产环境中的 p95 为 4.8s，并且在晚餐高峰期持续攀升。工程师们在接下来的五天里争论是否有性能倒退、为模型版本增加埋点、向供应商提交工单——最终发现，除了测量数字的地点之外，什么都没有改变。评测环境报告的是一台安静的机器在热缓存上运行串行调用的延迟。而生产环境是另一套系统。p95 从未出错；它只是在回答一个不同的问题。

这就是评测工具的延迟谎言。这并不是因为基准测试做得不好——大多数团队使用的工具都很合理，报告数字也很诚实。问题在于“模型延迟”与“用户感知的延迟”之间的鸿沟，以及你为开发构建的环境几乎总是测量前者，却暗示后者这一事实。一旦你理解了这一点，基于基准测试得出的延迟 SLO 就不再像是产品承诺，而更像是对一个没人能复现的私人测试环境的声明。

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

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

一个用户在 14:32:07 向你的助手提问。你的检索器在 14:32:08 触发，从政策手册中提取了五个分块。模型思考了几秒钟，起草了回复，并在 14:32:12 流式传回了一个答案，自信地引用了第 4.3 节——而管理员在 14:32:10 刚刚删除了这一节，因为它有误。用户读到了一段来自已不存在文档的权威引用，甚至还附带了一个返回 404 的可点击链接。

你的技术栈中没有任何环节报错。检索器返回了有效的命中结果。模型生成了流利、有据可查的文字。引用的分块 ID 在检索发生时确实存在。然而，根据任何合理的定义，这个答案都是一个幻觉——并不是因为模型胡编乱造，而是因为在它观察世界与开口表达的间隙，底层数据已经发生了变化。

这就是 RAG 的“写后读竞争”（read-after-write race），而大多数生产级流水线对此毫无防备。

你的推理火焰图（inference flame graph）有一个成本轴，但没有能源轴。这种差距在某天早上之前都没问题，直到客户的采购团队给你发来一份包含 23 列供应商可持续性披露信息的电子表格，其中一列是 每 1,000 次推理的 kgCO2e。你没办法填那一格，你的供应商给出的答案是一篇方法论论文，而交易将在 9 天内关闭。你的平台团队磨练了两年的 token 成本仪表盘突然看起来像是解决了一个错误的问题。

这里的转变并非抽象的。可持续性披露正在从公司层面的汇总转向产品层面的颗粒度。第一波浪潮于 2025 年进入了 CSRD 和 ESRS，而第二波浪潮现在正冲击着 B2B 采购合同。构建了成本可观测性的工程组织即将发现，他们需要针对碳排放的可观测性，而这两者在同一个 span 上并非同一列。