您的RAG流水线可能毫无用处。这里有一个更好的替代方案

检索增强生成（RAG）已成为将文档与大语言模型（LLM）连接的标准方法。其模式简单：对语料库进行嵌入，通过向量相似性检索最相关的块，并将其注入提示中。在演示和许多生产系统中，这种方法效果良好，但也会以可预测、有记录的方式失败，且这些失败只有在规模扩大时才会显现。

最常见的失败模式是检索不相关。用户查询产假政策，检索器返回2022年版本、2024年版本以及一篇文化博客文章。每个块由于与查询共享词汇而在嵌入距离上得分很高，但都没有回答用户实际提出的问题。模型不知道检索到的内容已过时或离题，它将多个块混合成一个自信、详细但事实错误的答案。这是主题相似性而非事实相关性，是生产RAG系统中的主导失败模式。

另一种更微妙的失败是上下文污染。企业知识库通常包含同一政策文档的多个版本。当检索器返回不同版本的块时，模型不会指出矛盾，而是选择其中一个、混合两者，或呈现一个自信的综合答案。读者得到一个答案，但答案可能是错误的。用户和模型都不知道这一点。

根本原因在于块-嵌入-检索流程中的结构性冲突。良好的召回需要小块（约100-256个token）以实现聚焦检索，而良好的上下文理解需要大块（1024个token以上）以保证连贯性。每个RAG设计者都只能选择其一并接受权衡。

当标准RAG表现不佳时，常见的修复方法是使其更复杂：更高维的嵌入、更精细的重排序、多步检索。但这只会加剧问题。一家全球制造公司为其RAG系统预算40万美元，第一年实际花费120万美元，技术文档查询的最终准确率仅为23%，项目被终止。一家医疗企业在第六个月时向量数据库成本达到每月7.5万美元。这些结果反映了一个更广泛的模式：2025年企业RAG实施的第一年失败率为72%。更高维的嵌入和更复杂的向量模型并不会自动提高性能，它们只会提高计算成本，并推迟一个更有用的问题：检索架构本身是否是正确的选择。

当RAG失败时，有以下替代方案：

长上下文提示：如果语料库适合模型的上下文窗口，直接加载并让模型阅读。一项基准研究发现，当计算资源可用时，长上下文LLM在问答任务上始终优于RAG，而基于块的检索表现最差。成本权衡显著：在100万token时，延迟比RAG流水线慢30-60倍，每次查询成本约为1250倍。但对于高流量应用，通过提示缓存，长上下文可以变得具有成本竞争力。一个常见的决策规则：如果语料库适合上下文窗口且查询量适中，长上下文提示是更干净的起点。仅在语料库超出窗口、延迟违反SLO或查询量超过经济盈亏平衡点时，再添加检索。

记忆压缩：当语料库太大而无法放入上下文窗口时，在检索前进行摘要。基于摘要的检索在注入前压缩文档，而不是提取原始块。基准测试显示，这种方法的表现与完整长上下文方法相当，而基于块的检索始终落后于两者。一个具体结果：使用精心选择的4.8万个token的保序RAG方法，在13个F1分数点上优于使用11.7万个token的全上下文检索，而token预算仅为后者的七分之一。一个压缩良好的相关文档胜过一堆粗略相关的原始块。

结构化检索：当检索是正确架构时，解决方案是根据查询类型进行路由，而不是统一应用更好的嵌入。EMNLP 2024的研究引入了Self-Route，让模型在运行前分类查询是否需要全文上下文或聚焦检索。简单事实查找走聚焦RAG，需要全局理解的复杂多跳问题走长上下文。结果是在更低计算成本下获得更好的整体准确率。使用这种混合方法的自适应系统通过混合搜索和重排序显示出15-30%的检索精度提升。关键变化是使路由显式化：每个查询在运行任何检索前被分类，系统不再将所有查询视为相同的嵌入问题。

图谱推理：对于需要理解数据集内关系而非获取特定段落的查询，向量检索天生失败。这些是多跳问题：董事会在第三季度推翻了哪些决定，每次的陈述理由是什么？没有单个块能回答这个问题，答案存在于文档之间的连接中。微软研究院在2024年引入了GraphRAG，该系统从语料库构建知识图谱，然后遍历实体关系而非匹配向量。它直接解决了标准RAG无法处理的失败情况：需要关系推理的跨文档综合。代价是成本：知识图谱提取比基线RAG贵3-5倍，并且需要领域特定调优。GraphRAG对于主题分析和多跳推理值得开销，但对于单段落事实查找则不然。

RAG是许多用例的合理默认选择，但它以可预测的方式失效：词汇匹配但语义偏离时的检索不相关，语料库中存在矛盾版本时的上下文污染，以及块大小无法同时满足召回和连贯性时的结构性限制。给一个破碎的检索设计增加复杂性只会使问题更昂贵。有四个更好的路径，取决于具体情况：如果语料库适合上下文窗口，长上下文提示完全避免检索问题；如果需要上下文压缩，检索前摘要优于原始块检索；如果查询类型多样，显式路由与结构化检索提高准确性和成本效益；如果查询需要文档间的关系综合，图谱推理是正确架构。将架构与查询类型匹配。