LLM 可观测到底应该观测什么
一句话判断
LLM 可观测不只是记录 prompt 和 response，也不只是看 token、延迟和错误率。它应该帮助企业回答：一次 AI 调用为什么发生、效果如何、成本多少、风险在哪、能否复现和改进。
为什么现在值得写
很多团队上线 AI 应用后，才发现传统日志和 APM 不够用。模型输出不稳定、prompt 经常变化、上下文难以复现、质量问题难以定义，导致线上问题很难排查。
目标读者
- 正在上线 LLM 应用的工程团队
- 想建设 AI 可观测平台的 AI Infra 团队
- 负责线上稳定性和质量的技术负责人
文章要解决什么问题
建立一套 LLM 可观测的维度框架，让读者知道应该观察哪些层：调用链路、输入输出、上下文、模型版本、成本、延迟、错误、用户反馈、业务结果、安全风险。
可能标题
- LLM 可观测到底应该观测什么
- 只记录 prompt 和 response，不叫 AI 可观测
- 企业 LLM 应用上线后，为什么传统日志不够用
素材/案例
- 同一个 prompt 在不同模型版本下输出变化
- RAG 上下文错误导致回答错误，但模型本身没报错
- 用户反馈和业务结果比单次响应是否“看起来正确”更重要
- 安全审计需要知道谁调用了什么、带了哪些数据、输出了什么
结论倾向
LLM 可观测要从“技术日志”升级为“AI 行为记录系统”。它既服务排障，也服务评估、成本治理、安全审计和产品迭代。
如果你正在建设企业 AI Gateway、多模型管理、可观测或评估体系，欢迎交流。