先这样答
大模型应用上线后的监控，我会分成工程、成本和质量三层。工程层看 QPS、延迟分位数、错误率和超时率，判断服务是否稳定；成本层看输入输出 token、单次请求成本和预算消耗速度；质量层关注内容安全拦截量、用户负反馈率、点赞点踩和定期人工抽检，因为大模型即使请求成功，也可能给出不相关、不准确或不安全的回答。
排查问题时，单看聚合指标不够，需要把一次请求中的 prompt、模型版本、检索命中内容、工具调用、重试过程和最终回答串成一条 trace。这样延迟升高时能确认是检索慢、模型慢还是工具超时，质量下降时也能回到具体输入和上下文。延迟、错误率适合按服务目标设置固定阈值和持续时间；成本、负反馈率等容易随业务变化，更适合结合历史基线做突增突降检测，并设置最小样本量，避免低流量误报。
灰度发布是监控的一部分，新模型、新 prompt 或新检索策略先放少量流量，对比稳定性、成本和质量；关键指标恶化就暂停放量或回滚。面试时可以收束为：传统监控保证服务可用，成本监控防止失控，质量监控判断答案是否真的可用，trace 负责把异常定位到具体环节。
面试官会怎么追问
- 「没有标准答案，你怎么监控回答质量？」 线上先用用户点踩、重新提问、人工转接和安全拦截作为代理信号，再按业务类型做定期抽检。对于问答、检索或工具执行任务，还可以检查引用是否匹配、工具参数是否合法、任务是否完成。用户反馈有选择偏差，模型自评也可能不稳定，所以不能只依赖一种信号。
- 「告警阈值具体怎么定，拍脑袋吗？」 延迟和错误率先根据服务目标、历史分布和业务容忍度设置阈值，同时要求异常持续一段时间再触发。成本和质量指标更适合比较近期窗口与历史基线，并按模型、版本、场景拆分。告警还要区分严重级别，决定是通知、停止灰度还是自动回滚。
- 「trace 记录 prompt，会不会有隐私问题？」 会，所以不能默认长期保存全部原文。通常采用采样、脱敏、访问控制和保留期限，对敏感场景只记录摘要、标识符或经过处理的字段。可排查性和隐私之间需要按业务风险取舍。
回答的坑
- 只回答 CPU、内存和接口错误率，忽略请求成功但答案错误、成本异常或出现安全风险，正确方向是把工程、成本、质量放在同一套监控视图里。
- 罗列大量指标却不说明 trace、告警条件、灰度和回滚，正确方向是讲清楚异常如何发现、如何定位，以及发现后如何限制影响。
—— 本题完 ——