299 篇博文 含有标签「observability」

当你的 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。但失败模式足够不同，需要做一些"翻译"。

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

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

生产环境中的 LLM 给出了一个错误的答案。一张支持工单到来。你翻查日志，只看到提示词、补全内容和延迟指标——却没有任何信息说明检索系统到底拉取了哪些文档、哪些块进入了上下文窗口，或者模型在综合答案时最依赖的是哪段内容。你只能像做考古一样：重新对一个已经更新过的语料库跑一次查询，祈祷结果还和之前一样，同时不知道问题究竟出在检索、分块、文档本身还是模型推理上。

这就是数据溯源的缺口，而大多数 AI 团队直到掉进去才意识到它的存在。

你的团队在周二执行了一次常规数据库迁移——将 last_login_date 重命名为 last_activity_ts，并扩展其语义以包含 API 调用。没有服务中断。测试通过。仪表盘更新。但你的 AI Agent——那个回答客户关于用户活跃度问题的 Agent——开始悄悄给出错误答案。没有报错，没有告警，没有堆栈跟踪。它只是自信地基于一个已经不存在的世界进行推理。

这就是 AI 工程中几乎无人关注的 Schema 迁移问题。你的 Agent 从工具描述、few-shot 示例和检索上下文中构建了一个隐式的数据模型。当底层 Schema 发生变化时，这个模型就变成了谎言——而 Agent 没有任何机制来检测这种矛盾。

你上周二发布了一个智能体。代码库没有任何改动。到了周四，它开始拒绝之前已经可靠处理了好几周的工具调用。你的 git 日志是干净的，测试全部通过，CI 流水线一片绿色。但智能体坏了——而且你没有可以回滚的版本，因为真正发生变化的东西根本不在你的代码仓库中。

这就是智能体版本控制的核心悖论：你追踪的制品（代码、配置、提示词）是必要的，但不足以定义你的智能体实际做了什么。行为是从代码、模型权重、工具 API 和运行时上下文的交叉中涌现出来的——其中任何一个都可以在版本控制系统中不留痕迹地发生变化。

你的智能体在开发环境中运行得完美无缺。它能回答测试查询、调用正确的工具、产出干净的输出。然后它上了生产环境，在一个十二步工作流的第七步出了问题。日志显示最终输出是一堆垃圾，但你完全不知道为什么。

你开始加打印语句。你在编排代码中到处散布 logger.debug() 调用。你盯着成千上万行输出，然后意识到你在用单进程的工具调试一个分布式系统。这就是大多数团队在 AI 智能体上犯的根本错误——他们把智能体当作程序来对待，但智能体的行为更像分布式系统。

一套联络中心 AI 系统在验证基准上的准确率超过 90%，但主管们仍然要求客服人员手动录入笔记。18 个月后，该产品以"采用率低"为由被砍掉。这种模式在企业 AI 部署中反复上演——技术上无可挑剔却无人使用的系统，被一套根本看不见失败的指标所衡量。

问题在于，团队所度量的内容与预测产品成败的内容之间存在系统性错配。工程组织从经典 ML 那里继承了度量本能：准确率、精确率/召回率、BLEU 分、延迟百分位、评估通过率。这些指标描述的是孤立的模型行为，几乎无法告诉你 AI 是否真正有用。