161 篇博文 含有标签「observability」

当一名 on-call 工程师第一次以“模型刚才又表现得有点怪”为由关闭告警页面时，团队就已经悄然越界了。这句话同时表达了三层意思：它宣告了问题不可调查，它将未来类似的告警归类为噪音，并免除了轮值人员记录事件经过的责任。一周后，同样的特征再次触发告警，另一个人看到“之前已经关闭过一次”，于是真正的回归（regression）便会一直潜伏在生产环境中，直到有客户在 Twitter 上发帖投诉。

这种模式并不是因为懒惰。它是将标准的 SRE 直觉运行在一个不再表现出确定性的系统上所产生的必然结果。经典的 on-call 培训教导工程师将“输入相同但输出不同”的情况视为可观测性堆栈中的 Bug——这不可能是系统本身的 Bug，因为系统不会那样运作。但基于大语言模型（LLM）的系统正是在每一次请求中都以这种方式运作，这是其设计使然。如果建立 on-call 轮值机制时没有内化这一点，系统就会滑向两个极端：要么是瘫痪（每一个随机波动都是 P2 级事故），要么是虚无主义（模型总是很奇怪，别再给我发告警了）。

你的 AI 功能满意度评分是 4.2/5，用户点赞率高达 68%，A/B 测试显示任务完成率提升了 12%。团队决定上线。六周后，用户已悄然绕开它，遇到真正重要的事情时不再使用。

这就是指标表演。你优化的是看起来像成功的信号，而不是真正的成功。你收集到的反馈来自那 8% 愿意评分的用户——偏向极度满意和极度不满的两端，对那沉默的大多数一无所知——他们发现该功能时不时不可靠，于是悄悄停止信任它了。

构建 AI 功能需要一套与传统软件不同的度量哲学。你从第一天起就埋下的信号，决定了你是否能足够快地学习并改进，还是花六个月追着一个纹丝不动的满意度分数跑。

你正在值班，凌晨三点，告警触发：过去一小时内 AI 聊天功能的用户满意度下降了 18%。你打开日志，却看到……什么都没有。每个请求都返回了 HTTP 200，延迟正常，没有任何报错。

这就是 AI 事故的体验。传统值班的肌肉记忆——grep 堆栈跟踪、找到异常、部署修复——在这里完全失效。系统并没有崩溃，它做的正是它被设计来做的事。只是输出结果是错的。

我去年合作过的一个团队拥有一套包含 847 个测试用例的评估套件，仪表盘一片绿色，发布节奏从外部看非常有纪律。然而，他们的旗舰摘要功能开始为大约二十分之一的客户支持线程生成言之凿凿的错误摘要。该能力的评估得分在连续六个月里一直保持在 94%。当我们对这套套件进行审计时，发现问题并不在于评估在撒谎。问题在于这些评估已经悄然腐化，测量了错误的东西，惩罚了正确的模型行为，并与它们正在评估的模型共享盲点。这套套件并不是像传统测试那样以一种响亮的方式崩溃，而是像温度计一样坏掉了——无论你把它放在哪里，它都显示室温。

测试异味（Test smells）在传统软件领域已经被研究了二十年。Van Deursen 的目录、xUnit 模式分类以及更近期的工作都记录了那些看起来正常的测试如何能积极地损害代码库——通过编码错误的规范、使重构变得昂贵、以及制造让真正的 bug 隐藏得更深的虚假信心。LLM 评估是一个非常新的领域，以至于同类的文献几乎不存在，但同样的动态已经发生在我交流过的每个 AI 团队中。不同之处在于，LLM 评估异味具有传统测试所不具备的机制：训练数据重叠、随机输出、评委模型反馈循环、能力漂移。你不能只是简单地移植旧的分类体系，你需要一个新的。

你的 LLM 供应商 SLA 涵盖了 HTTP 正常运行时间和首个 Token 到达时间。但它对于模型下个月是否仍会遵从你的格式化指令、是否会拒绝上周还能接受的请求、或者在你未测试的边缘条件下能否返回有效 JSON，只字未提。大多数工程团队是通过生产环境事故才发现这一点的——而非通过更新日志。

这就是隐性 API 契约问题。传统 API 承诺稳定、有据可查的行为；LLM 供应商只承诺一条连接。从请求发出到应用处理响应之间发生的一切，都由你自己负责。

你的 AI 功能在上线时通过了所有评估。六周后，与其交流最频繁的用户群体的流失率翻了一倍，而你的 CSAT 仪表板却显示出一条无人能解释的平线。提示词（Prompts）没有变，模型没有更换，检索索引增长了，但没人觉得它坏了。上线时的表现第一轮（turn one）很好。真正变质的是在第 400 轮、第 17 次会话、注册三周后发生的事情。

大多数团队的评估套件无法察觉到这种失败。他们测试的是固定数据集上的单轮准确性，如果有追求的话，可能会测试单次会话中的多轮对话，然后就宣布该功能可以上线。真正重要的失败模式——即随着系统积累用户状态而质量下降——存在于评估工具从未设计去覆盖的时间维度中。在记忆研究文献中，研究人员称之为“自我退化”（self-degradation）：在初始阶段之后，受记忆膨胀（memory inflation）和错误记忆累积的驱动，性能出现明显且持续的下降。生产工程师则将其称为留存用户群无声流失的原因。

当你的 LLM 功能上线后，监控面板可能会追踪准确率、延迟和错误率。但几乎可以肯定，它不会追踪方差——即同一个提示每次输出差异有多大。这个盲区，正是生产环境 AI 功能悄然崩溃的地方。

方差决定了你的产品是让用户感觉可信赖还是喜怒无常。一个在评估套件中得分 88% 的功能，如果 40% 的时候返回两句话、60% 的时候输出十个段落，其对用户信任的侵蚀速度，会比一个得分 80% 但表现一致的功能快得多。只优化准确率的团队，解决的是可靠性问题的错误一半。

提示熵预算正是填补这一空白的概念：一种结构化的方法，用于衡量、预算和控制模型在相同输入下的输出分布——就像你在 SLO 框架中对待 p99 延迟或错误预算一样。

当一位人工贷款官员拒绝一份申请时，这个决定背后有一个具体的名字。这位官员接收了特定信息，经过深思熟虑后做出了行动。推理过程或许并不完美，但它是可归因的——有人可以被联系、被质询、被追责。

当一个 AI 智能体拒绝同一份申请时，留下的只有一条数据库记录。这条记录表明决定已做出，但没有说明原因，没有说明是什么输入驱动了这个决定，没有说明当时运行的是哪个版本的模型，也没有说明系统提示词是否在两周前悄悄更新过。当你的合规团队将这条记录交给监管机构时，监管机构不会满意。

这就是智能体审计追踪问题，而大多数构建 AI 智能体的工程团队至今尚未解决它。

一家金融科技初创公司在他们的系统提示词中添加了一个逗号。第二天，他们的发票生成机器人开始输出乱码，在有人追踪到原因之前，他们已经损失了 8,500 美元。没有抛出任何错误。没有触发任何报警。应用程序继续运行，虽然错了但很自信。

这就是在生产环境中调试 LLM 的真实样子。没有指向行号的堆栈追踪。没有你可以检查的核心转储（core dump）。系统不会崩溃——它在继续运行的同时，悄无声息地产生降级的输出。传统的调试直觉不再适用。大多数工程师的反应是随机调整提示词，直到看起来好一点，然后基于三个示例进行部署，并称其已修复。结果两周后，问题又以另一种形式浮出水面。

有一种更好的方法。LLM 的故障遵循系统性的模式，而这些模式对结构化的调查有反应。这就是这套方法论。

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

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

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

模型卡会告诉你模型是否经过了针对CBRN误用的红队测试，以及它对哪些人群服务不足。但它不会告诉你：在10,000个并发请求下的p95 TTFT、性能在上下文窗口80%处出现的断崖、复杂JSON模式的格式错误率，或者自模型卡发布以来模型行为漂移了多少。

这种差距是结构性的，而非偶然。模型卡设计于2019年，用于公平性和安全性文档，目标受众是公民社会组织和监管机构。构建生产系统的工程团队并不是其使用场景。七年的推广之后，这一框架依然未变——而将模型卡视为部署规范的代价从未如此高昂。

2025年基础模型透明度指数（斯坦福CRFM + 伯克利）证实了这一遗漏的范围：OpenAI在100项透明度指标中得24/100，Anthropic得32/100，Google得27/100。平均分从58分降至40分，这意味着随着模型能力增强，AI透明度不升反降。四大主要实验室均不披露训练数据构成、能源使用情况或与部署相关的性能特征。

异步 AI 任务有一个传统后台 Worker 没有的问题：它们会静默而自信地失败。一个文档处理 Agent 返回 HTTP 200，输出格式规整的结果，然后继续执行——而实际输出却悄悄出错了：可能不完整，可能建立在三步前幻觉出的事实上。你的仪表盘依然绿色，值班工程师照常入睡，客户最终才发现异常。

这不是边缘情况，而是未经可观测性设计的异步 AI 系统的默认行为。让传统分布式系统中后台作业队列保持可靠的工具——死信队列、幂等键、Saga 日志——同样适用于 AI Agent。但失败模式足够不同，需要做一些"翻译"。