LLM 可观测性是什么？如何看懂 AI 应用为什么出错

传统服务出错会看日志、指标和调用链；AI 应用也需要同样的能力。用户只会说“它昨天答得对，今天为什么不对”，但背后可能是提示词变了、检索没命中、工具超时、模型升级，或是输入本身不同。

**LLM 可观测性（Observability）**就是让每一次模型调用都能被追踪、比较和诊断。

一次调用该记录什么

至少记录这些字段，并对隐私数据做脱敏：

• 请求 ID、用户或会话标识、时间
• 模型、参数、提示词与版本号
• 输入和输出 token、延迟、成本
• 检索到的资料、工具调用及其结果
• 最终输出、错误码、重试次数

对 Agent 来说，还要把一次复杂任务串成一条 trace：计划了什么、调用了哪些工具、每一步为何继续或失败。没有这条链，排查就只能猜。

三类最重要的指标

质量指标：用户采纳率、人工纠错率、引用是否准确、任务是否完成。模型输出流畅不等于质量高。

性能指标：首 token 延迟、总耗时、超时率、工具失败率。它决定用户是在“等待思考”还是“认为卡死”。

成本指标：输入/输出 token、缓存命中、每次任务成本、不同模型的占比。成本突然上升常意味着上下文膨胀或重试失控。

最常见的排查路径

当答案错误时，先问：检索到正确资料了吗？资料进入提示词了吗？模型是否遵守了格式和约束？工具结果是否可靠？当延迟上升时，再看 token、排队、重试和模型路由。

这与RAG 评测的分层思想一致：把问题拆开，才能找到真正的瓶颈。

别把日志变成新的风险

提示词和工具结果往往含用户资料、代码或业务数据。日志应最小化保存、限制访问、设置保留期限；不该为了排查方便就永久记录密码、完整合同或个人信息。

总结

LLM 可观测性不是多装一个监控面板，而是给 AI 系统建立可解释的运行记录：知道它用了什么上下文、做了什么工具调用、花了多少成本、在哪一步失败。只有看得见，才能稳定地优化、回归和上线。