RAG流水线到底败在哪：检索还是生成？

RAG 失败的两个战场

检索增强生成（RAG）几乎成了企业落地大模型应用的标配方案。它把外部知识库与大语言模型拼接在一起，让模型能够引用私有文档、实时数据来回答问题。理论很美好，但真正把 RAG 系统投入生产环境的团队几乎都会遇到同一个困扰：输出结果不对，可到底是哪一环出了问题？

这正是 Reddit 社区里被反复讨论的核心议题——RAG 流水线的失败，究竟发生在「检索」阶段，还是「生成」阶段？搞清楚这个问题，直接决定了你该往哪里投入优化资源。

检索阶段的典型失败

检索是 RAG 的第一道关卡，也是最容易被低估的环节。它的任务是从知识库中找出与用户问题最相关的文档片段（chunk）。这一步一旦出错，后面无论用多强的模型都是「巧妇难为无米之炊」。

检索失败通常有几种表现：

• 切分策略不当：文档被切得太碎，语义被割裂；或者切得太大，噪声信息过多，稀释了关键内容。
• 向量嵌入不匹配：使用的 embedding 模型无法准确捕捉领域术语的语义，导致相关文档排不到前列。
• 召回数量失衡：top-k 设置过小漏掉关键信息，过大又引入无关内容干扰模型判断。
• 查询与文档表述差异：用户提问的措辞和文档中的表达方式差别很大，纯向量相似度难以桥接这种语义鸿沟。

判断检索是否失败有一个实用方法：把检索出来的文档片段单独拎出来看，如果连人都无法从这些片段中找到正确答案，那问题就出在检索，而非模型。

混合检索（Hybrid Retrieval）是当前缓解检索失败的主流手段之一。纯向量检索依赖语义相似度，对措辞差异敏感；而基于 BM25 等算法的关键词检索则擅长精确匹配专业术语和专有名词。将二者结合，通过 RRF（Reciprocal Rank Fusion）等方式融合排名，可以显著提升召回的鲁棒性。此外，查询改写（Query Rewriting）和 HyDE（Hypothetical Document Embeddings，假设文档嵌入）也是常用手段——前者用大模型将用户问题改写成多个变体再分别检索，后者则让模型先生成一段假设性答案，再用这段文本的向量去检索真实文档，以此拉近查询与文档之间的语义距离。

生成阶段的典型失败

即便检索环节交出了正确的上下文，生成阶段依然可能翻车。这时模型拿到了对的材料，却没能给出对的答案。

常见的生成失败包括：

• 忽略上下文：模型没有充分利用检索到的内容，反而依赖自己的参数化记忆，产生幻觉。
• 上下文淹没：当检索片段过多过长时，关键信息被埋没在中间位置，模型出现「中间遗忘」（lost in the middle）现象。
• 推理能力不足：需要跨多个片段整合信息才能回答的问题，模型难以完成多跳推理。
• 指令遵循偏差：prompt 设计不佳，模型没有严格按照「仅依据提供的上下文作答」的约束执行。

生成失败的诊断方式同样直接：如果人类拿着相同的检索片段能轻松答对，而模型却答错，那问题就在生成端——可能是模型能力、prompt 工程，或上下文组织方式的问题。

「中间遗忘」（Lost in the Middle）现象已由斯坦福等机构的研究正式量化：实验表明，大语言模型在处理长上下文时，对位于开头和结尾的信息注意力最高，而中间部分的关键内容容易被低估甚至忽略。这对 RAG 系统的上下文组织方式有直接影响——将最相关的片段置于 prompt 的首位或末位，而非简单按检索分数顺序排列，往往能明显改善生成质量。针对多跳推理问题，可以考虑引入迭代检索（Iterative Retrieval）或将问题拆解成子问题逐步求解的 Chain-of-Thought 策略，而非一次性把所有片段塞入上下文。

为什么定位失败点如此关键

RAG 优化最大的陷阱，是在错误的环节上花力气。很多团队一遇到效果差就急着换更大的模型，结果发现问题根本在检索——再强的模型也救不回缺失的上下文。反过来，有人拼命调优检索，实际瓶颈却是 prompt 写得太模糊。

建立一套「分层评估」机制因此变得必要：

1. 检索评估：用 recall、precision、命中率等指标衡量检索质量，确认正确答案是否出现在召回结果中。
2. 生成评估：在检索结果正确的前提下，单独评估模型输出的准确性与忠实度（faithfulness）。

只有把这两层解耦，才能精准定位问题、对症下药。业界已有 RAGAS、TruLens 等评估框架专门做这件事，把检索质量和生成质量拆开来量化。

RAGAS 是目前使用最广泛的 RAG 专项评估框架之一，它将评估指标拆分为四个维度：Context Precision（检索片段中相关内容的比例）、Context Recall（答案所需信息是否被完整召回）、Faithfulness（生成答案是否忠实于检索内容，不产生幻觉）以及 Answer Relevancy（答案是否切题）。其中前两项对应检索质量，后两项对应生成质量，恰好契合分层评估的思路。TruLens 则提供了更偏向可观测性的视角，支持对整条 RAG 流水线进行追踪和记录，便于在生产环境中持续监控各环节表现。使用这类框架，团队可以将主观的「感觉效果不好」转化为可量化、可追踪的工程指标。

实践建议

对于正在维护 RAG 系统的团队，可以按以下顺序排查：

• 先构建一个带标准答案的测试集，覆盖真实业务场景的问题。
• 对每个失败案例，先检查检索片段是否包含答案——这是分流的第一步。
• 若检索无误但生成出错，优先调整 prompt 和上下文排序，再考虑升级模型。
• 若检索本身缺失答案，从切分策略、embedding 模型、混合检索（向量+关键词）入手改进。

RAG 的工程实践没有银弹，但清晰的失败归因能让每一次优化都落在刀刃上。检索与生成不是非此即彼的选择，而是一条流水线上必须协同优化的两个环节。