生产级大模型应用该监控哪些指标

LLM 服务上线后，接口没报错，不代表回答有用；总耗时变长，也未必是模型出了问题。原文给出一套生产监控的面试答题框架：把单次请求、多步调用链和服务整体健康连起来，再补上质量检查与敏感数据保护。

它没有提供实测数据或工具选型，但适合用来检查自己的 AI 应用：用户反馈一次错误回答时，你能不能找到对应调用、还原执行过程，并判断问题是否影响了更多人？

一次错误回答，要能追到具体调用

作者建议从三个层次建立监控：请求级日志、多步调用追踪、聚合服务指标。它们分别回答三个问题：这次发生了什么，中间经过了哪些步骤，整个服务是否出现异常。

每次请求至少记录以下字段：

• 请求标识，用于关联用户反馈与具体调用。
• prompt 或模板版本，以及模型名称。
• token 数量、延迟和成本。
• 结构化结果状态，用于判断调用结局。

其中，prompt 版本很容易被忽略。同一个接口，即使代码没有改动，模板调整也可能改变输出。如果日志只留下最终回答，没有模型与模板版本，就很难判断问题出在哪一次变更。

对于 agent 或多步工作流，还要增加分布式追踪（distributed tracing）。一次请求可能先检索，再调用模型，接着执行工具。只看最终耗时，无法知道时间花在哪里；只看最终错误，也可能遗漏更早发生的失败。

作者希望追踪能按顺序展示模型调用、工具调用、检索步骤，以及各步骤的输入、输出和错误。这里的关键是保留关联关系，同时控制记录内容，不能为了排障就把所有原始文本完整存下来。

告警负责发现异常，质量检查负责判断有没有用

服务看板应覆盖错误率、p95 延迟、token 使用量和成本。p95 延迟可以理解为：约 95% 的请求耗时不超过这个值，它能帮助观察较慢请求的体验。

但看板上的每次波动都不该变成告警。作者优先关注持续的错误率上升、p95 延迟恶化、异常成本飙升，以及质量信号的突变。告警还应明确受影响的服务和版本，让接手的人知道从哪里查起。

接口成功返回，只能说明调用完成，不能证明输出有用。

质量监控因此需要另一套证据：定期抽样会话做人工评审，收集点赞、点踩等用户反馈，再按场景增加自动检查，例如：

• schema 有效性，检查结构化输出是否符合约定。
• 拒绝率，观察模型拒绝回答的比例是否异常变化。
• 检索命中率，为检索环节提供质量线索。

这些指标都需要按模型和 prompt 版本拆开看。整体平均值可能保持稳定，某个新模板却已经退化。

原文没有给出抽样比例、告警阈值，也没有解释检索命中率的具体口径。这些是监控方向，落地时仍要补齐定义，不能直接当成配置表。

日志越详细，越要先处理敏感数据

作者把个人身份信息（PII）脱敏放在写日志之前，而且范围包括日志和可观测性工具。

这一步不能只覆盖用户输入。prompt、调用追踪和错误消息都可能携带敏感信息，作者明确建议测试这些位置的脱敏是否有效。否则，正常日志处理干净了，异常路径仍可能把原始内容带出去。

此外，还要减少不必要的内容留存、限制敏感记录的访问权限，并明确保存期限。原文特别反对一种做法：因为监控平台属于内部工具，就直接存储原始 PII。

可观测性需要足够的排障证据，但证据不等于完整复制生产对话。

我的判断

这套框架说得对的地方，是把「系统是否正常」和「回答是否有用」分开处理，再通过请求、模型和 prompt 版本把它们连接起来。相比只盯接口成功率，或只保存最终回答，它更有助于定位问题。

不过，原文是一份面试式方案，没有生产实验，也没有对照数据，不能据此认定某套指标一定能改善质量。schema 合法不代表内容正确，检索命中也不代表资料支持答案；拒绝率升高究竟是故障还是合理行为，要结合请求内容判断。

人工抽样同样有前提：团队需要明确评审标准并投入时间。原文没有说明抽样如何覆盖低频问题，也没有给出成本核算方式。这些空白需要团队根据实际业务补上。

能拿来做什么

• 给 Node 侧的模型调用补齐请求标识、prompt 版本、模型、token、延迟、成本和结果状态，让用户反馈能关联到具体请求。
• 如果应用包含检索或工具调用，就把各步骤放进同一条追踪，保留执行顺序和错误信息，便于定位失败环节。
• 对要求 JSON 输出的功能增加 schema 检查，并按模型与 prompt 版本查看结果，同时保留会话抽样评审。
• 在接入日志平台前，检查 prompt、追踪和错误消息中的 PII 脱敏，并落实访问权限与保存期限。