引言
检索增强生成（RAG）已成为连接文档与大语言模型（LLM）的主流技术方案。其核心思路并不复杂：对语料库进行向量化嵌入，通过向量相似度检索最相关的文本片段，再将它们整合到提示词中。这种方法在原型演示和许多实际生产系统中表现不俗。然而，它的失败模式同样具有可预测性，有大量文档记录，并且只有在规模化部署时才会真正暴露出来。
那么，这些失败模式具体有哪些表现？工程师们又在探索哪些替代方案来应对这些挑战？本文将逐一深入剖析。
RAG在生产环境中的失效时刻
最常见的失败情形是检索结果不相关。设想这样一个场景：用户查询公司的育儿假政策。检索器返回了2022年版本、2024年版本，以及一篇无关的文化博客文章。每个段落因为与查询共享关键词，在嵌入空间的距离得分都很高。但没有任何一个段落能真正回答用户所关心的问题。
模型并不知道检索到的内容已经过时或偏离主题。它将这些段落混合在一起，自信满满地生成一个详细但事实错误的答案。这就是所谓的“主题相似性而非事实相关性”，也是生产级RAG系统中占主导地位的失败模式。
还有一种更隐蔽的变体——“上下文投毒”。企业知识库中往往存放着同一政策文档的多个版本。当检索器同时返回这些不同版本的段落时，模型并不会主动发现其中的矛盾。它可能选择其中一个，也可能把它们混在一起，或者生成一个自信满满的综合体。用户最终得到了一个“答案”，但这个答案很可能是错误的。关键在于，用户和模型对此都一无所知。
这背后的根本原因，在于“分块-嵌入-检索”这一流程中存在一个结构性冲突。为了实现精准检索，需要将文档切分成小段（约100到256个token），以保证高召回率。但另一方面，为了理解上下文，又需要大段文本（1024个token或更多）来保证连贯性。每个RAG设计者都在两者之间二选一，然后接受相应的代价。
常见的（错误）修复：过度工程化
当标准RAG表现不佳时，常见的“解法”是把系统搞得更复杂：采用更高维度的嵌入、更精密的重新排序、多步检索。这种做法反而让问题雪上加霜。
一个真实的案例：一家全球制造企业为它的RAG系统批了40万美元预算。结果第一年就花了120万美元。最终在技术文档查询上的准确率是多少？23%。项目最终被终止。还有一家医疗健康企业在第六个月时，光向量数据库的月费就达到了7.5万美元。这些案例并非孤例，它们反映了一个更广泛的趋势：2025年，企业级RAG项目的第一年失败率高达72%。
更高维度的嵌入、更先进的向量模型，并不会自动带来性能提升。它们只会提高计算成本，并且延迟了我们本应更早提出的一个更有价值的问题：这个检索架构，从根本上到底适不适合当前的任务？
当RAG失效时的替代方案
长上下文提示词
对于过度工程化一个表现不佳的RAG管道，最直接的替代方案是——干脆跳过检索步骤。
如果整个语料库能装进模型的上下文窗口，那就直接把内容加载进去，让模型自己阅读。一项基准研究发现，在有足够计算资源的前提下，长上下文LLM在问答任务上持续优于RAG，而基于分块的检索方案表现最差。
当然，成本权衡是显著的。在100万个token的规模下，延迟比RAG管道慢30到60倍，每次查询的成本大约是后者的1250倍。不过，对于高流量的应用，如果结合提示词缓存机制，长上下文方式也能变得有成本竞争力。
一个常见的决策规则是：如果语料库能装进上下文窗口，且查询量不大，那么长上下文提示词是更简洁的起点。只有在语料库超出窗口限制、延迟违反了服务水平目标（SLO），或者查询量超出了经济上的盈亏平衡点时，才考虑引入检索。
记忆压缩
当语料库太大，无法直接放进上下文窗口时，可以在检索之前先做摘要。这种基于摘要的检索方式，是在注入模型之前先对文档进行压缩，而不是直接拉取原始分块。基准测试表明，这种方式的效果与完整的长上下文方法不相上下，而基于分块的检索则始终落后于两者。
一个具体的数据：使用精心挑选的48K个token的保序检索方法，在F1评分上比使用117K个token的全量上下文检索高出13个点，而token预算仅为后者的七分之一。一篇压缩得好的相关文档，远胜于一堆不相关的原始段落。
结构化检索
当检索本身是正确的架构选择时，解决方案不是对所有查询一视同仁地应用更好的嵌入，而是根据查询类型进行路由分流。
EMNLP 2024上的一项研究提出了Self-Route方法。该方法让模型在执行检索之前，先判断一个查询是需要完整上下文，还是只需要定向检索。简单的事实查询走定向RAG，复杂的多跳问题（需要全局理解）则走向长上下文。
结果是：以更低的计算成本，实现了更高的总体准确率。采用这种混合方法的自适应系统，通过混合搜索和重新排序，检索精确度提升了15%到30%。
关键的改变在于明确了路由决策。每个查询在执行任何检索之前都被分类，系统不再把所有查询都当作同一个嵌入问题来处理。
基于图的推理
有些查询需要理解数据集中的关系，而不是提取某个具体的段落。对于这类问题，向量检索从一开始就注定会失败。
比如这种多跳问题：董事会在第三季度撤销了哪些决策，每次撤销的理由分别是什么？没有哪一个分块能直接回答这个问题。答案藏在多个文档的关联之中。
微软研究院在2024年推出了GraphRAG。该系统会从语料库中构建一个知识图谱，然后通过遍历实体关系来寻找答案，而不是进行向量匹配。
它直接解决了标准RAG无法处理的失败场景：需要跨文档进行关系推理的综合性任务。
代价是成本。知识图谱的提取成本比基线RAG高出3到5倍，还需要针对特定领域进行调优。GraphRAG适合需要主题分析或多跳推理的场景。对于单段落的简单事实查询，则没有必要。
结论
对于许多用例来说，RAG仍然是一个合理的默认起点。
但它也会以可预测的方式失效：当词汇匹配但语义偏离时出现检索不相关；当语料库中存在相互矛盾的版本时引发上下文投毒；当分块大小无法同时满足召回率和连贯性的结构性限制时暴露短板。而向一个本已失效的检索设计中增加复杂性，只会让问题变得更贵。
根据具体情况，有四个更好的路径可供选择：
- 如果语料库能装进上下文窗口，长上下文提示词可以从根本上避免检索问题。
- 如果需要进行上下文压缩，在检索前做摘要比直接检索原始分块效果更好。
- 如果查询类型多样，使用结构化的显式路由可以提高准确率并节省成本。
- 如果查询需要跨文档的关系综合，基于图的推理是正确架构。
核心原则很简单：让架构匹配查询类型。