RAG（Retrieval-Augmented Generation）在生产环境中，常见的失败模式有哪些？你会如何系统性排查和优化？
请从以下维度展开：
不知道。
本次未作答，完整示范回答如下。
RAG 的生产失败主要集中在四个环节：检索、生成、Pipeline 串联和效果评估。
一、Retrieval 阶段
这里的问题可以分成三类。
第一类是 embedding 错配。通用 embedding 模型处理垂直领域查询时效果差，原因是训练语料和业务场景不匹配。比如用 text-embedding-ada-002 做法律文档问答，法律术语的语义相似度往往不准确。解法是针对领域做 embedding 微调，或者至少用领域相关的评测集做选型对比。
第二类是 chunking 不当。chunk 太大引入噪声，模型被无关上下文干扰；chunk 太小丢失语义完整性。常见做法是先按语义单元（段落、表格）分块，再加适当的 overlap，并按实际效果调参。
第三类是索引和召回策略缺失。只用纯向量检索会漏掉关键词敏感的场景，需要引入 BM25 做混合检索，加上向量检索的多路召回和 reranker 重排。同时元数据过滤要做好，支持按时间、类别等维度筛选。
二、Generation 阶段
即使检索回来了，模型也可能用不好。常见问题有两个。
一是上下文污染。检索结果得分高但语义不相关，模型仍会参考它，造成 hallucination。解法是在 reranker 之后加一个质量过滤步骤，过滤掉相关性低于阈值的结果。
二是 prompt 约束不足。没有要求模型"只基于上下文回答"或"不确定时说不知道"，模型就会自由发挥。所以生成侧的 prompt 设计很关键，要有明确的约束指令。
三、端到端 Pipeline
从 query 进来到 answer 出来，整条链路有几个常见断点：用户 query 和文档表述不一致，需要 query rewriting；多跳推理场景下单次检索不够，需要迭代检索或子问题分解；检索质量差时没有兜底策略，需要 answer relevance scoring 来判断是否走 fallback；相似 query 重复检索浪费资源，需要结果缓存。
四、评估与监控
离线指标分两层。检索层用 Hit Rate@K 和 MRR，看 top K 结果里有多少命中了相关文档。生成层用 RAGAS 框架，衡量 answer faithfulness（答案是否忠实于上下文）、answer relevance（答案是否切题）和 context relevance。也可以用 LLM-as-Judge 做端到端打分。
在线监控盯三个指标：P99 延迟（瓶颈通常在向量检索和模型推理）、answer faithfulness rate（模型回复中有多少内容可追溯到检索上下文）、fallback rate（走兜底策略的频率）。
总结一下，RAG 系统的核心矛盾是检索追求高召回、生成追求精准不幻觉，这两个目标天然存在张力。好的 RAG 系统本质上是在两者之间找平衡，主要靠 reranker + 质量过滤 + 分层检索来实现。系统性排查的 SOP 是：先手动检查 retrieval 结果质量，再做端到端消融实验，逐环节定位瓶颈。