LLM 应用上线后要监控哪些指标？告警怎么设？

先这样答

LLM 应用上线的监控指标可以分为质量层、行为层、性能层和成本层四个维度。告警的设置原则是区分硬指标和软指标，硬指标实时告警，软指标做周期性复盘并回流。

具体来看，质量层主要看用户的点踩率、人工抽检分以及评测集的回归分，这反映了模型输出的真实业务表现。行为层关注模型在复杂任务中的执行情况，包含工具调用成功率、用户的幻觉投诉量以及模型的拒答率。性能层在传统后端监控的基础上增加了大模型特有的指标，包括首字响应时间（TTFT）、吐字速率、超时率和重试率，这些直接关系到用户等待的体验。成本层则需要监控单次调用的成本、token 消耗的分布情况以及缓存命中率，用来控制整体的推理开销。

在告警设置上，策略需要有所区分。用户可见的硬指标，例如接口错误率、延迟超过设定阈值以及成本突增，需要配置自动告警，以便研发人员快速介入处理。而质量类指标因为主观性强、单条数据的噪声比较大，一般不做实时告警，而是通过日报和周报的形式进行趋势观测。

监控的最终目的是指导迭代。对于触发告警的样本和用户点踩的对话，系统会自动将其放入 badcase 池中。团队在周会上对这些 badcase 进行归因分析，明确是 Prompt 缺陷、检索质量差还是模型能力问题。修复后将其回流补充到评测集中，作为后续版本回归测试的标准。

面试官会怎么追问

• 「如果线上发现成本突然增加，你会怎么排查？」 先看 token 分布监控，确认是输入端还是输出端的 token 突增。如果是输入端，检查检索增强环节召回的文档数量或上下文截断策略是否失效。如果是输出端，检查模型是否陷入了死循环或输出了大量无效内容。同时排查缓存命中率是否出现异常下降。
• 「质量类指标为什么不做实时告警？」 大模型的单次输出具有随机性，用户点踩的原因也很多样，直接用单次点踩触发告警会产生大量误报，导致开发人员对告警疲劳。把质量指标放到日报或周报中看整体趋势，能更准确地判断模型表现是否出现实质性退化。
• 「收集到的 badcase 怎么利用起来？」 badcase 会进入统一的样本池，通过人工介入进行分类归因。修复对应问题后，这些真实的线上 badcase 会被清洗并加入到自动化评测集中。下次更新模型或修改 Prompt 时跑一遍这个评测集，用来检验修复效果并防止指标回退。

回答的坑

• 混淆传统后端监控与 LLM 专属监控。只答 CPU 占用、内存和 QPS，没有提到 TTFT、吐字速率或 token 消耗分布等 LLM 核心指标。
• 把所有指标都设成实时告警。没有区分硬指标和质量指标，在真实业务中会导致告警风暴，正确的做法是质量指标看趋势并做周期复盘。