大模型应用如何排查生产故障：提示、检索、模型与工具的全链路观测

传统监控看不见答案质量

接口返回成功并不代表答案可用。一次请求可能经历提示组装、检索、重排序、模型生成和工具调用，任何环节变化都会影响结果。应为整条链路分配追踪标识，记录模型版本、提示模板版本、知识库版本、调用参数和每段耗时，同时对敏感内容进行脱敏。

把质量信号变成指标

在线无法为每个答案人工打分，可以使用引用覆盖、格式通过率、工具成功率、拒答率和用户纠错作为代理信号。抽样请求再由人工或独立评测器深入判断。指标要按业务、模型和版本拆分，否则一次局部退化会被总体流量掩盖。

延迟需要逐段预算

分别观察排队、检索、首字等待、生成和外部工具耗时。输出令牌增加可能让总延迟变长，而首字时间仍正常；检索库负载则会同时影响召回与响应。为每段设置服务目标，超时后采取缩短上下文、切换模型或跳过非核心工具等降级。

费用异常必须可归因

记录输入输出令牌、缓存命中和重试次数，按用户、功能与租户归集。提示模板意外膨胀、失败循环和恶意请求都可能造成费用突增。设置日预算、单请求上限和异常速率告警，并保留快速关闭高成本功能的开关。

版本发布与回滚

提示词、模型、索引和工具都应版本化，小流量灰度并对照基线评测。故障记录要能重放，但需去除个人数据。AI 可观测性的目标是让“答案变差了”转化为具体版本、具体环节和具体输入类型的证据。