2 线上 RAG 系统应该监控哪些指标
1️⃣ 考察意图
面试官想看你是否具备“生产级”RAG 系统的工程思维，而非仅停留在论文 demo 阶段。核心考察点：能否区分离线评估（如 NDCG）与在线监控（如延迟、幻觉率），并理解两者如何联动。刁钻点在于：指标不能孤立看——比如检索延迟低但召回率差，或生成准确率高但用户留存下降，你要能解释背后的 trade-off。答好了能展示你从“跑通流程”到“运维优化”的硬实力，包括对 Prometheus、Grafana 等工具的落地经验。
2️⃣ 标准答
线上 RAG 系统监控必须分层，每层指标对应不同故障模式。我按 检索层 → 生成层 → 系统层 → 业务层 四层展开，并给出具体阈值和坑。
检索质量指标
- 召回率（Recall@k）：监控 top-k 检索结果是否包含正确答案。用离线标注的 golden set 做在线抽样评估，阈值设 >85%（k=5）。坑：线上 query 分布会漂移，需每周更新 golden set。
- MRR（Mean Reciprocal Rank）：关注第一个正确答案的排名。MRR <0.6 说明检索器退化，常见原因是 embedding 模型未随新文档更新。
- 检索延迟 P50/P99：P50 <50ms，P99 <200ms（基于 HNSW 索引）。如果 P99 飙升，检查向量索引是否因增量写入导致未优化（需定期 re-index 或使用 IVF+PQ 平衡）。
- 无结果率：query 返回空结果的比例。>5% 时需检查 chunking 策略（如是否因句子被截断导致语义丢失）或 embedding 维度是否匹配。
生成质量指标
- 回答准确率：用 LLM-as-judge（如 GPT-4 打分）或人工抽样，阈值 >80%。注意：LLM 打分有偏差，需结合人工校准（如每周 100 条抽样）。
- 幻觉率：检测生成内容是否与检索上下文矛盾。用 NLI 模型（如 DeBERTa-v3）或规则（如实体一致性检查）。线上幻觉率 >10% 需立即告警，常见原因是检索上下文不足或 LLM 温度过高（建议温度设 0.1-0.3）。
- 重复率：同一 query 多次回答的语义相似度。>30% 说明 LLM 陷入固定模式，可引入随机采样或 top-p 截断（如 p=0.9）。
系统性能指标
- 端到端延迟 P50/P99：从 query 到回答的完整链路。P50 <1s，P99 <3s。如果 P99 过高，检查 rerank 阶段（如 Cohere rerank 模型延迟高，可降级为 BM25 二次排序）。
- QPS 与吞吐量：监控峰值 QPS 和 GPU 利用率。当 QPS 超过 100 时，需考虑 LLM 推理优化（如 vLLM 的 PagedAttention 或 TensorRT-LLM 的批处理）。
- 错误率：包括检索超时、LLM 调用失败、token 溢出。错误率 >1% 需排查 API 限流或模型负载（可设置熔断机制，如 5 秒内失败 3 次则降级为缓存回答）。
业务指标
- 用户留存率：周留存 <30% 说明系统体验差，需结合日志分析（如用户是否频繁修改 query）。
- 回答采纳率：用户点击“有用”或复制回答的比例。<50% 时需优化检索质量或生成风格（如增加引用来源）。
- 反馈率：用户主动提交负面反馈的比例。>5% 需立即排查，常见原因是回答过于冗长或无关。
实际落地的坑 + 解法：一次线上事故中，检索延迟 P99 从 150ms 飙到 800ms，原因是向量索引未做增量更新，导致 HNSW 图结构退化。解法：改用 IVF+PQ 索引并设置每日重建，同时用 Prometheus 监控索引大小变化，超过阈值自动触发 re-index。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从检索质量、生成质量、系统性能、业务指标四个层面回答。检索层关注 Recall@k 和延迟 P99，生成层用 LLM-as-judge 监控幻觉率，系统层盯端到端延迟和 QPS，业务层看用户留存和采纳率。总结一句：监控不是堆指标，而是通过分层指标联动定位故障，比如延迟高时先查索引是否退化，准确率低时看检索上下文是否不足。”
4️⃣ 高频追问 & 应对
追问 1：如何区分“检索质量差”和“生成质量差”导致的回答错误？
用 归因分析：对错误回答，先检查检索结果中是否包含正确答案。如果检索结果正确但生成错误，说明 LLM 幻觉或指令遵循差（需调低温度或增加 prompt 约束）；如果检索结果错误，则优化检索器（如调整 chunk 大小或 embedding 模型）。线上可埋点记录“检索上下文”和“生成回答”，用 NLI 模型计算矛盾分数，矛盾分数高则归因为生成问题。
追问 2：监控指标告警阈值怎么设定？有没有通用经验？
基于 基线 + 动态调整。初始阈值参考行业经验：检索延迟 P99 <200ms，幻觉率 <10%，端到端延迟 P99 <3s。上线后收集 2 周数据，用 3-sigma 原则 或 移动平均 设定动态阈值。例如，延迟 P99 超过基线 2 倍时告警。注意：不同业务场景阈值不同，比如金融场景幻觉率需 <1%，而闲聊场景可放宽到 15%。
追问 3：如果用户反馈“回答太啰嗦”，你监控哪个指标？
监控 回答长度 和 压缩率。回答长度超过 500 token 且用户采纳率下降，说明 LLM 过度生成。解法：在 prompt 中加“简洁回答”指令，或设置 max_tokens 上限（如 300）。同时监控 重复率，如果回答中反复出现相同短语，说明 LLM 陷入循环，需调整 top-p 或频率惩罚。
5️⃣ 避坑 · 常见错误答法
- ❌ 只提离线指标（如 NDCG、BLEU），忽略在线监控（如延迟、QPS）。✅ 必须区分离线评估和在线监控，并说明两者联动：离线指标用于模型选型，在线指标用于故障定位。
- ❌ 堆砌指标但不给阈值和工具（如“监控召回率”但不提具体数值和采集方式）。✅ 每个指标给出具体阈值（如 Recall@k >85%）和工具（如 Prometheus 采集延迟，Grafana 展示）。
- ❌ 忽略业务指标（如用户留存），只谈技术指标。✅ 业务指标是最终验证，技术指标是手段，面试官想看你能从业务反推技术优化。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“线上监控实战”切入，举例你如何用 Prometheus + Grafana 搭建仪表盘，并解决过检索延迟飙升或幻觉率过高的问题。强调你设定了告警阈值并做了归因分析。
- 如果你只做过传统 NLP：用“搜索系统监控”类比，比如传统搜索关注 CTR 和延迟，RAG 多了生成质量指标（幻觉率）。展示你迁移监控思维的能力，并补充 LLM-as-judge 等新工具。
- 如果你是校招无项目：聚焦“监控体系设计”，引用论文（如《RAGAS: Automated Evaluation of Retrieval Augmented Generation》）中的指标，并模拟一个线上故障排查场景（如检索延迟高 -> 索引重建）。展示你对工具（Prometheus）和阈值设定的理解。
- 《RAGAS: Automated Evaluation of Retrieval Augmented Generation》—— 离线评估指标框架
- 《Evaluating RAG Systems: A Comprehensive Guide》—— 在线监控最佳实践
- Prometheus + Grafana 官方文档 —— 指标采集与可视化
- 《Attention Is All You Need》—— 理解 LLM 生成延迟优化基础
- vLLM 论文《Efficient Memory Management for Large Language Model Serving with PagedAttention》—— 推理优化