233 篇博文 含有标签「observability」

周二还能用的提示词（prompt），到周四就返回了“我无法提供帮助”。CI 评估依然是绿色的。你配置中的模型名称没变。提示词在字节层面完全一致，在源码控制中也经过了哈希处理和固定。然而，一个围绕新出现的拒绝回答（refusal）的客户支持线程正在形成——AI 团队在两周内都不会察觉到这一点，因为它必须经过一级支持、分类，最后才落到能读取追踪信息（trace）的人手中。

这就是服务商侧的安全漂移（provider-side safety drift），它是当今生产环境 AI 中构建最不完善的监控缺口。前沿服务商会以不在你发布日程上的频率，在服务端调整安全过滤器、拒绝阈值和内容分类器。你的团队没有订阅这些变更，通常也没有发布说明。而且这种退化是具有非对称性的，以一种确实难以察觉的方式呈现：正当意图的拒绝率悄悄爬升，而你认为服务商会过滤的有害查询却开始悄悄溜过。边界在两端独立移动，且毫无预警。

打开任何生产环境 LLM 功能的安全仪表盘，你都会看到拒绝率（refusal rate）被绘制成一条单线，并带有颜色标记：下降是坏事，上升是好事。这背后的隐含逻辑是：拒绝是系统对不该做的事情说“不”，因此拒绝率越高，产品就越安全。这种说法只反映了事实的一半，而缺失的另一半，正是已部署助手中大多数无形质量损伤的根源。

拒绝率是一个双面分布。右尾是安全团队痴迷的部分：模型同意编写恶意软件、伪造药物剂量或生成政策明确禁止的内容。左尾则是相反的失败——错误拒绝（false refusals），即模型因为某些表面特征与禁止类别模式匹配，从而拒绝了良性请求。客户询问如何对费用提出异议，却收到“我无法提供财务建议”的样板回复。护士询问药物相互作用，却被引导至“请咨询医疗保健专业人员”。开发者询问如何解析邮件头，却因为提示词中包含 “exploit” 一词而被拒绝。

三个团队正在查看同一个事件流，每个团队都有一个名为 session_id 的列，但每个团队对什么是“会话”都有不同的定义。计费（Billing）继承了来自认证库的 30 分钟空闲窗口。评估（Eval）从聊天机器人框架中继承了“直到用户说‘再见’或停止打字 10 分钟为止”的定义。记忆（Memory）则使用 UI 在用户点击“开启新聊天”时生成的线程 ID —— 而大多数用户从不点击这个按钮。三列数据，三种语义，一个汇总仪表盘，以及三个共用一个根因但互不相关的 Bug。

这就是会话边界问题（session boundary problem）。它看起来像是一个埋点琐事，但实际上是一个披着基础设施外衣的产品问题：一段对话在哪里结束？坦诚的回答是没有单一的标准答案 —— 计费会话、评估会话和记忆会话并不是同一种对象 —— 如果一个团队选择了一个默认定义并让另外两个团队继承它，那么他们交付的就是具有相同根因的计费纠纷、评估偏见和内存泄漏。

由财务主导的“切换到更小模型”的指令，是让你的 LLM 账单季度环比增长最可靠的方式之一。采购团队盯着的仪表盘——单次调用成本、每次请求的平均 token 数——一直在下降。与此同时，发票金额却在不断攀升。当有人终于把这两者对上账时，团队已经花了六个月的时间进行提示词（prompt）迭代，以补偿那个在任务处理上表现更差的模型，而且团队已经陷得太深，如果不承认最初的切换是个错误，就无法走回头路。

错误不在于定价，而在于计量单位。当推理深度、重试次数和提示词大小都随模型而异时，单 token 价格是一个具有误导性的维度。正确的指标是“单次成功完成所需的 token 数”，在这个维度上，更便宜的模型往往会输。

大多数团队作为回归测试套件运行的评估集，是由一名工程师在项目第三周手工挑选的。到了第六周，因为没人想在发布前动它，它就被冻结了；而到了第九个月，它正被用来拦截部署。产品已经调整了两次。用户群翻了三倍。LLM 在生产环境中实际遇到的案例与那个冻结的测试集重合度可能只有 40%。当测试集通过时，没人相信它；当它失败时，没人知道是真实的失败，还是案例已经过时。团队写了一份提议“v2 评估集”的文档，却从未真正动手。

与此同时，系统在生产环境中处理的每一个请求都已被记录在追踪后端中。每一个提示词、每一次工具调用、每一项中间输出、每一次拒绝、每一次重试——所有这些都存储在对象存储中，按时间索引并带有 span 标签，随时准备回放。团队所能拥有的最高保真度的测试语料库已经在磁盘上了。他们却从零开始构建了一个评估集，而不是从中读取。

一位用户将一段 Markdown 粘贴到你的支持代理中。他们粘贴内容中的第一个标题是 ### Steps I tried。你的提示词模板（prompt template）使用 ### 作为停止序列（stop sequence）。模型尽职地读取了用户的输入，开始回答，并生成了 ### 作为其结构化响应的一部分——结果 API 返回了两句自信的回复，随后便是沉默。工单以“模型质量退化”的名义进入你的队列。其实不然。修复方法只是网关中的一行代码。

停止序列是生产级 LLM 技术栈中极其关键却又常被忽视的调节开关。它们通常是在最初编写提示词的那一周选定的，那时输入还是整洁的工程示例，还没有人粘贴过 JIRA 工单的堆栈信息。十二个月后，用户内容的分布已经远远超出了提示词作者的想象，曾经整洁的分隔符现在变成了潜伏在每三百个用户粘贴中就有一个的隐患。没有任何告警。评估套件（eval suite）依然能够通过。受影响部分的 CSAT 指标下降了 0.5 分并维持在那里。

这不是模型的问题。这是一个伪装成模型问题的输入契约（input-contract）问题，它的形态类似于典型的分布式系统 Bug：为一方的内容分布选择的分隔符被强制应用于另一方的内容分布，且在边界处没有任何监控。

我在上个季度交流过的一个团队花了六周时间追踪其智能体（agent）平台上的内存压力报警。这些智能体的运行成本很低——每次运行只需几美分。但追踪（trace）却不是。他们的遥测流水线消耗的预算是其所监测的 LLM 调用预算的三倍，而且大部分支出都花在了几个月没人看过的字段上：每个 span 上存储的完整 prompt 正文、在父级和子级追踪中重复出现的工具输出，以及一个在每次捕获的追踪上重新支付推理费用的 LLM-judge 评估器。

这是 AI 可观测性成本危机的缩影。一份 2026 年的行业报告模拟了一个拥有 10,000 个对话且每个对话有五轮互动的客户服务机器人——这相当于每天 200,000 次 LLM 调用、4 亿个 token，以及大约 100 万个追踪 span。Datadog 用户广泛报告，在处理其 REST API 的相同后端上监测 AI 工作负载后，可观测性账单飙升了 40-200%。流水线在为同样的 token 支付两次费用：一次是为了生成它们，一次是为了记住它们。

解决方法不是“减少日志”。解决方法是将 AI 系统的可观测性视为一种具有自身单位经济效益的工作负载，与传统服务发出的请求-响应遥测分开处理。传统日志是你可以压缩并遗忘的结构化字段；AI 日志则是无限制的文本正文，每当有人读取它们时，就会重新计入推理预算。这种区别就是“Token 感知日志”的含义。

一个欺诈检测模型的准确率在三周内悄无声息地下降了一半。延迟正常，错误率为零，所有基础设施仪表盘都显示绿色。工程师们在第一周审计数据管道，第二周比较模型权重，第三周重新审视工单，直到有人发现欺诈者只是改变了他们的语言模式。修复工作——用最近的样本重新训练——只花了两天。而误诊却花了三周。

这种模式在生产环境中的 AI 团队里不断重复：性能下降触发了笼统的“模型问题”警报，团队开始基于直觉而不是根本原因来调整参数。原因并不是缺乏监控纪律，而是大多数可观测性技术栈将三个结构上截然不同的问题混为一谈。模型漂移（Model drift）、数据漂移（Data drift）和提示词漂移（Prompt drift）具有不同的检测特征、不同的警报拓扑结构和不同的修复路径。将它们混淆，就会在错误的修复方案上浪费数周时间。

上季度，某推荐引擎推送了冒犯性内容，随后召开的事故复盘会议以一种我们再熟悉不过的方式收场：两小时的会议里，ML 工程师把矛头指向检索语料库，数据工程师把矛头指向提示词，产品工程师把矛头指向监控，基础设施团队把矛头指向没人记得何时升级的模型版本。最终产出了三条行动项，却没有一条落实到具体负责人。事故就此关闭。六周后，同样的故障模式再次上线。

这不是某一个团队的故事，而是大多数组织处理 AI 事故时的默认结局。AI 功能在生产环境中造成的后果，由足够多的参与方共同承担，导致标准的事故复盘根本无法锁定因果关系。那套在排查数据库超时时行之有效的"5 Why"分析法，面对"模型给出了错误答案"时便彻底失灵——因为下一步该追问什么，从来都不显而易见。

麦当劳得来速 AI 的失败，并非因为用户抱怨。它失败，是因为用户停止使用得来速。三年来，这套系统一直记录着"健康"的接受率，而病毒式传播的视频却显示顾客在苦苦哀求它从订单中删除 260 块鸡块。当合作关系终止时，官方给出的理由是技术"尚未成熟"。真正的信号其实一直隐藏在客流量数据里——无人阅读，无人量化，无人汇报。

这就是大多数 AI 功能在生产环境中失败的样子。用户不会关闭你的功能。他们不会提交工单。他们不会留下一星评价。他们悄悄地绕开它，而你的仪表板依然一片绿色。

你的团队刚刚花了三周时间优化推理。你们换成了量化模型，调整了批处理策略，成功缩短了 12% 的首字延迟 (TTFT)，然后上线了。接着你查看了实际的面向用户的延迟，发现几乎没有变化。

这就是“推理陷阱”。它是 LLM 应用中最常见的性能分析失效模式，其发生的原因是工程师们习惯于测量那些容易测量的指标——GPU 利用率、推理吞吐量、每秒 Token 数 (TPS)——而不是真正缓慢的部分。在一个典型的 RAG 流水线中，如果包含所有涉及 GPU 的环节，推理大约占延迟的 80%。但剩下的 20% 通常分布在六七个没人追踪的阶段中。孤立地看，每一项似乎都很小，但它们共同占据了主要的优化空间。

你的 RAG 系统存在一个不会抛出异常的 Bug。它不会拉高错误率，不会在延迟仪表盘上留下痕迹。相反，它会悄悄地给出听起来自信、合理却错误的答案——而没有人在数周内察觉。

这就是 RAG 中的数据契约问题：你的摄取管道是下游所有环节的事实来源，但它没有 Schema 校验、没有新鲜度保障，也没有在外部世界的形态悄然改变时发出告警。每当上游数据源新增字段、分块参数发生偏移，或者嵌入模型被更新，检索质量就会无声地退化。

80% 的企业级 RAG 项目在生产环境中会遭遇严重故障，而其中最隐蔽的那些故障从不宣告自身的存在。