3 篇博文 含有标签「schema」

凌晨 3 点让财务部门收到告警的成本飙升其实并不是真正的成本飙升。那只是一个 Span 重命名。Agent 平台团队的某个人觉得 llm.completion.synthesis 应该改为 llm.generate.answer，因为这样读起来更自然。他们提交了一个小的 PR，运行了测试，然后发布了。三天后，财务的月度 Token 消耗仪表盘显示下降了 60%。没有人削减支出。聚合规则仍然按旧名称分组，而新的 Span 流向了一个仪表盘甚至没有渲染的 “其他” 桶中。账单没有变。仪表盘变了。

这是我一直看到团队在重复经历的一类事故。Span 名称和属性键并不是为了让人在追踪 UI 中阅读而存在的标签。它们是一个未公开 API 的公开 Schema，其消费者是生产团队从未谋面的——过滤它们的评估流水线、按它们分组的成本仪表盘、根据其持续时间触发的 SLO 告警、汇总其 Token 属性的 FinOps 报告。一个团队内部 “无害的重命名”，对于另外四个从未看过该 PR 的团队来说，就是一个网络协议破坏。

大多数 AI 流水线故障并非模型问题。模型运行正常，输出看起来也是 JSON，但下游阶段却悄然崩溃——原因可能是字段被重命名、类型发生变化，或者嵌套对象新增了一个下游阶段根本不知道如何处理的必填属性。流水线执行完毕并报告成功，而某个数据仓库里的数字已经悄悄出错。

这就是 AI 流水线的契约测试问题，也是生产 AI 系统中最被忽视的可靠性风险之一。根据近期基础设施基准数据，企业 AI 系统平均每月发生近五次流水线故障，每次解决耗时超过十二小时。主要原因并非模型质量差，而是数据质量和 Schema 契约违规：64% 的 AI 风险存在于 Schema 层。

你上线了一个功能，使用 LLM 从用户文本中提取结构化数据。你进行了彻底的测试。它工作正常。三个月后，模型提供商悄悄更新了权重，在没有修改任何代码的情况下，你的下游流水线开始静默丢弃记录。没有抛出异常。没有触发报警。只是错误的数据在系统中流动。

这就是 Schema 问题。尽管结构化输出 API 已经改进了多年，它仍然是 LLM 驱动的系统中最少被讨论的故障模式之一。