简介(未完成)
AI时代的可观测性跟以前不同了,也更重要了,因为LLM带来了非确定性的决策逻辑,系统的行为比以前更难以预测了。可观测性的侧重点不同了,但思路和原则并没有发生颠覆性的变化。以前的系统,复杂度集中体现在分布式服务的调用关系上;而在AI智能体开发中,复杂度来源于如何理解智能体内部的自主行为上,也包括多智能体之间的调用关系上。这种复杂度跟分布式没有直接关系,而是跟LLM的生成行为和推理轨迹有关。在以前的可观测性系统中,span一般对应一次微服务的调用;而现在,span可能对应一次LLM调用、一次工具调用、一次subagent的handoff,或者其他关键逻辑的调用。
与传统微服务应用所关注的黄金三指标(请求数,错误,耗时)类比,我们认为 AI 应用的黄金三指标可能是 Token,Error,Duration。
- 耗时主要关注的是模型推理延迟,也就是在推理过程中我们通常需要关注模型的首包延迟,即 TTFT(Time to first token),这个指标反映了相应的速度,还有像 TPOT (Time Per Output Token) 反映生成的效率和流畅度。另外一个比较重要的指标就是吞吐率。吞吐率可以衡量我们这个模型本身,能够同时去支撑多少个推理请求。所以这几个指标是需要进行一些平衡的,三个指标不可能同时满足得特别好。
- Token 可能是 AI 应用最重要的一个指标,所以每次请求会记录 Token 的消耗情况,甚至我们需要精确地区分 Input Token 和 Output Token 的消耗,因为大家知道模型的定价里面 Input Token 和 Output Token 是不一样的,我们在成本核算的时候,会将输入 Token 和输出 Token 分别进行统计。
AI系统的错误往往源于上下文缺失或工具调用顺序不当,而非代码逻辑错误。传统系统能靠日志/指标等追踪定位;Agent则需要还原“它为什么这么推理、调用了什么、依据是什么”。
- “真相来源”从代码(Code)转移到了轨迹(Traces),仅通过查看代码来了解应用实际行为的可见性就越来越低。没有端到端追踪、记录与回放,就无法快速定位与修复;
- 调试变成轨迹分析。当用户报告“智能体失败了”时,你不会打开代码寻找 bug。你会打开轨迹,查看推理哪里出了问题。智能体是否误解了任务?调用了错误的工具?陷入了死循环? “Bug”不再是你代码中的逻辑错误。它是智能体实际行为中的推理错误。不必要的工具调用、冗余的推理、低效的路径。瓶颈在于智能体的决策,而这些只存在于轨迹中。
- 你无法在推理中设置断点
- 测试变成评估驱动(Eval-Driven)。既然逻辑的真相来源在于轨迹,你需要测试这些轨迹。你需要一个管道将轨迹添加到你的测试数据集中。随着智能体的运行,你捕获轨迹并将它们添加到一个可以进行评估(Eval)的数据集中。
- 监控从“在线时间”转向“质量”。一个智能体可能“在线”且 0 错误,但表现极其糟糕,在错误的任务上成功、以 10 倍的成本低效地成功、或者给出正确但无用的答案。 你需要监控决策的质量,而不仅仅是系统健康状况,任务成功率、推理质量、工具使用效率。如果不采样和分析轨迹,你就无法监控质量。 以“轨迹(Trace)”为中心的可观测性体系:过去你用代码做的一切,调试、测试、优化、监控、协作,现在你都要用轨迹来做。为了实现这一点,你需要良好的可观测性。结构化的轨迹,你可以搜索、过滤和比较。
- 没有“刹车”策略(HITL、阈值等),错误更会被放大。
耗时耗在哪? ==> 全链路追踪
业务/应用层,还是推理引擎层?
问答质量
我们要解决模型回答得好不好,每次模型的升级和优化,都需要建立一个基线,并且确保模型的迭代满足这个基线,否则回答的质量会导致用户体验受损。为此,我们把模型的 input/output 全部都采集到日志平台中,接下来我们可以筛选出一批记录,通过数据加工,引用外部的裁判员模型,对当前这个模型回答的输入输出结果进行一个评估。