ARTICLE · 1039278
什么是 AI Observability?为什么AI系统出问题,比传统软件更难排查?
什么是 AI Observability?为什么AI系统出问题,比传统软件更难排查?上一篇介绍了： AgentOps。 我们提到： 当AI Agent开始真正“做事”之后， 企业不能只关心： 还必须知道： 它调用了什么工具？ 经历了哪些步骤？ 为什么做这个决定？ 花了多少Token？ 任务到底有没有完成？ 有没有越权？ 这背后其实指向了一个越来越重要的概念： 也就是： AI可观测性。 如果让我用一句简单的话解释： 因为AI系统越复杂： 越不能只看最后一个答案。
Observability并不是AI时代才出现的概念。 传统软件工程早就在做： Logs 日志。 Metrics 指标。 Traces 调用链。 比如一个网站突然变慢： 工程师可以看： CPU是不是过高？ 数据库是不是慢了？ 哪个API超时？ 哪个服务报错？ 一次请求经过了哪些Microservice？ 于是可以逐步找到： 但是到了AI时代： 事情变得不太一样。
假设一个普通API： 请求成功。 HTTP Status： 200。 没有Exception。 响应时间： 正常。 从传统监控角度来看： 但是AI回答： 可能是错的。 例如用户问： AI回答： 实际上正确答案： 是15,000日元。 这时候： 服务器正常。 模型调用正常。 RAG正常返回。 没有任何Error。 但是： 这就是AI Observability和传统Monitoring最大的不同之一。
这两个词很容易混在一起。 可以简单理解： Monitoring 告诉我们： 例如： 错误率突然升高。 响应时间变慢。 Token成本增加。
Observability 进一步帮助我们回答： 例如： 是不是RAG找错文档？ 是不是Prompt变化了？ 是不是模型升级了？ 是不是Context太长？ 是不是Agent选错Tool？ 是不是某一步推理出现偏差？ 所以：
假设我们做一个RAG应用。 用户问： 表面看起来只是： Question → Answer 但实际上可能经历： 用户问题 ↓ Query Rewrite ↓ Embedding ↓ Vector Search ↓ Document Retrieval ↓ Reranking ↓ Context Construction ↓ System Prompt ↓ LLM ↓ Output 如果最终回答错误： 问题可能发生在： 任何一步。 所以只保存： 用户问题。 AI答案。 往往远远不够。
这时候一个非常重要的概念就是： Trace 也就是： 执行轨迹。 例如一次RAG请求： Step 1 用户问了什么？ ↓ Step 2 系统改写成了什么Query？ ↓ Step 3 检索了哪些文档？ ↓ Step 4 哪些文档最终进入Context？ ↓ Step 5 用了哪个Prompt？ ↓ Step 6 调用了哪个Model？ ↓ Step 7 模型返回了什么？ 有了完整Trace： 工程师才能开始回答：
到了AI Agent： 链路会更长。 例如用户说： Agent可能： 理解任务 ↓ 制定Plan ↓ 查询CRM ↓ 查询订单 ↓ 读取会议记录 ↓ 调用数据分析工具 ↓ 发现异常 ↓ 再次查询 ↓ 综合分析 ↓ 生成报告 这时候： 如果最后结论错误： 我们必须知道： 所以Agent Observability通常需要记录： Planning Tool Calls Tool Results LLM Calls Agent Decisions Errors Retries Final Result
我觉得可以分成几个层次。 第一层：System 传统系统指标。 比如： Latency。 Error Rate。 Availability。 CPU。 Memory。 这些仍然需要。
第二层：Model 观察模型。 例如： 使用哪个Model？ 输入多少Token？ 输出多少Token？ 响应时间多少？ 调用成本多少？
第三层：Prompt 观察Prompt。 例如： 使用哪个版本？ System Prompt是什么？ Context是什么？ Prompt有没有发生变化？
第四层：RAG 观察知识检索。 例如： 搜到了什么？ Top-K是多少？ 哪些文档进入Context？ Retrieval Score是多少？
第五层：Agent 观察行动过程。 例如： 调用了什么Tool？ 为什么调用？ 调用成功了吗？ 执行多少Step？ 有没有Retry？ 有没有Loop？
第六层：Business 最终还要观察： 任务成功率多少？ 用户是否接受结果？ 人工修改率多少？ 节省多少时间？ AI到底创造了多少价值？
这三个概念可以简单区分。 Logs 回答： 例如： 14:02 Agent调用CRM API。 14:03 CRM返回成功。 14:04 Agent调用Sales DB。
Metrics 回答： 例如： Task Success Rate：92% Average Latency：4.2s Average Cost：$0.08 Error Rate：3%
Traces 回答： 从： 用户输入。 一路看到： LLM → RAG → Tool → Agent → Output。 所以： Logs 看事件。 Metrics 看趋势。 Traces 看过程。 三者结合： 才能真正理解： AI系统发生了什么。
但是： 即使有了Trace， 仍然有一个问题： 这时候就需要： AI Evals。 比如： Trace告诉我们： RAG找到了3份文档。 但是： 这3份文档： 是不是正确的？ LLM生成了回答。 但是： 回答： 是不是准确？ Agent完成了10个步骤。 但是： 任务： 到底有没有完成？ 所以： 两者其实非常紧密。
对于Agent系统： 我觉得未来一个非常核心的指标就是： Task Success Rate 也就是： 比如： 1000个任务。 920个成功。 那么： Task Success Rate： 92%。 然后进一步拆解失败原因： 3%： Tool Error。 2%： Wrong Planning。 1%： Permission。 1%： Context不足。 1%： Model Error。 这时候： 团队就知道： 这就是Observability带来的价值。
AI应用还有一个很特别的问题： 尤其Agent。 一个任务可能： 调用模型10次。 搜索5次。 调用数据库3次。 再运行代码。 所以我们需要看到： Cost per Request 一次请求多少钱？ Cost per User 一个用户多少钱？ Cost per Agent 哪个Agent最贵？ Cost per Task 完成一个业务任务多少钱？ 最终才能回答：
假设现在使用： Model A。 Task Success Rate： 91%。 后来升级到： Model B。 模型更快。 价格更低。 大家觉得： 结果上线之后： Task Success Rate： 降到： 86%。 如果没有： Evals + Observability， 团队可能很长时间： 都不知道发生了什么。 所以AI系统需要： 这也是上一篇LLMOps的重要内容。
有时候听到： AI Monitoring。 AI Observability。 很容易感觉： 其实它还有一个非常重要的价值： 比如通过Observability发现： 大量失败： 都来自RAG。 那么： 优化Retrieval。 如果发现： 大量Agent失败： 都来自某一个Tool。 那么： 优化Tool。 如果发现： 某种任务成本特别高。 那么： 使用更小模型。 所以Observability最终形成： Observe ↓ Understand ↓ Improve ↓ Evaluate ↓ Deploy ↓ Observe Again 这样一个持续优化循环。
上一篇之前讲了： LLMOps。 可以简单理解： LLMOps负责： 而Observability是其中非常重要的一部分。 LLMOps包括： 版本管理。 Evals。 部署。 Monitoring。 Cost。 Safety。 Observability。 所以： 没有它： AI系统虽然在运行， 但团队其实： 看不清里面发生了什么。
AgentOps关注： 而AI Observability提供： 比如： AgentOps需要管理： Task Success。 Cost。 Permission。 Safety。 Human Approval。 而Observability帮助它看到： 每次Agent： 做了什么。 为什么这么做。 调用了什么工具。 在哪一步失败。 所以可以理解：
以前大家经常说： AI是： Black Box。 输入进去。 结果出来。 中间发生什么： 不太清楚。 但是企业真正使用AI： 不能接受： 完全黑盒。 尤其当AI开始： 做财务判断。 操作客户系统。 生成代码。 执行Agent任务。 企业必须知道： 所以未来成熟的AI系统： 会越来越像： Glass Box 也就是： 玻璃盒。 不是说： 我们能完全理解模型内部每一个神经元。 而是：
因为AI正在经历一个非常明显的变化。 第一阶段 Chatbot AI只是： 回答问题。 ↓ 第二阶段 RAG AI开始： 使用企业知识。 ↓ 第三阶段 Agent AI开始： 调用工具。 ↓ 第四阶段 Agentic System AI开始： 自主完成复杂任务。 AI自主性越高： 企业就越需要： 因为：
前面介绍AgentOps时： 讲过： Controlled Autonomy。 也就是： 可控自主。 那么实现它的第一步其实就是： 因为： 看不见： 就无法评价。 无法评价： 就无法控制。 无法控制： 企业就不敢给AI更大权限。 所以可以形成一个很重要的关系： Observable ↓ Evaluable ↓ Controllable ↓ Trustworthy 也就是：
如果让我用一句话理解AI Observability： 传统AI Demo： 我们经常只看： 但真正进入Production之后： 远远不够。 我们还需要知道： 因为未来AI系统： 不会只是： 一个聊天框。 它会越来越像： 而当AI开始真正参与工作： 企业就必须能够： 看见它。 理解它。 评价它。 控制它。 所以： AI Observability最终解决的并不只是： 更重要的是： 当AI真正做到： 看得见 评得了 管得住 它才有可能： 从辅助工具， 逐渐走向： 企业核心业务。 继续学习，继续实践，继续记录我的AI学习笔记。
最后输出了什么？
AI Observability
AI Observability，就是让我们能够真正“看见”AI系统内部到底发生了什么。
01 传统软件其实已经有Observability
问题到底发生在哪里。
02 AI系统最麻烦的问题：它可能“正常运行，但结果是错的”
系统完全正常。
公司海外出差住宿标准是多少？
每晚最高20,000日元。
业务结果错了。
03 Monitoring 和 Observability 不完全一样
“有没有出问题？”
“为什么会出问题？”
Monitoring更像报警器，Observability更像诊断系统。
04 一个AI回答背后，其实有一条很长的链路
公司的年假制度是什么？
05 Trace：看见AI到底经历了什么
“到底哪里出了问题？”
06 Agent让Trace更加重要
帮我分析这个客户最近为什么销售下降。
Agent到底走过哪条路？
07 AI Observability到底要观察什么？
业务结果。
08 Logs、Metrics、Traces分别是什么？
发生了什么？
整体表现怎么样？
某一次任务到底是怎么完成的？
09 AI Observability还需要Evals
怎么知道结果好不好？
Observability让我们看见过程，Evals帮助我们判断过程和结果的质量。
10 一个非常重要的指标：Task Success Rate
AI到底成功完成了多少任务？
下一步到底应该优化什么。
11 成本也必须变得“可观测”
每次执行都有成本。
这个Agent的ROI到底怎么样？
12 为什么模型升级之后必须观察？
应该更好了。
持续比较不同版本的实际表现。
13 Observability不是为了“监视AI”
是不是为了防止AI犯错？
帮助AI持续变好。
14 AI Observability和LLMOps是什么关系？
AI应用整个生产运营体系。
Observability可以看作LLMOps的“眼睛”。
15 AI Observability和AgentOps又是什么关系？
怎么运营和管理Agent。
看见Agent行为的能力。
Observability是AgentOps非常重要的基础设施。
16 AI系统正在从“黑盒”走向“玻璃盒”
AI到底做了什么。
我们至少能够完整观察AI系统的行为过程。
17 企业为什么越来越需要AI Observability？
可观测性。
你不能把越来越大的权限交给一个你完全看不见的系统。
18 从可观测走向“可控”
先看得见。
看得见 → 评得了 → 管得住 → 才值得信任。
写在最后
AI Observability，就是让AI系统从“结果可见”，走向“过程可见”。
最后答案好不好。
AI用了哪个模型？
看到了什么Context？
RAG找到了什么？
Agent调用了什么工具？
为什么失败？
花了多少钱？
任务有没有真正完成？
企业数字化世界中的一个“工作者”。
“怎么Debug AI？”
“我们怎么建立对AI系统的信任？”