为什么你的RAG演示很惊艳，上线就翻车？

为什么同一个RAG系统，演示时答得漂亮，上线后却总在关键问题上翻车？答案往往不在模型，而在检索。把文档塞进向量库只是简单的一半，把对的信息塞进模型的上下文窗口，才是真正的工作。

先看一张失败地图。检索真正会翻车的地方有五种：

• 词汇不匹配：用户输入“怎么取消”，文档里写的是“终止订阅”。语义搜索能帮上忙，但产品代号、错误码、生僻姓氏这类精确词仍然会被漏掉。
• 上下文丢失：一个片段写着“营收增长3%”，可这是哪家公司、哪个季度？片段被从原文里撕出来，向量无从知晓。
• 问题不等于答案：一句简短提问，和那段又长又技术化的答案段落，向量根本对不上。
• 答案就是整份文档：“总结这400份报告的主题”，任何5个片段都答不了，top-k再大也够不着。
• 检索到了，但答错了：系统捞回一堆看起来很像、却不含答案的片段，模型照样自信地据此作答。

没有单一的“高级RAG”。有七种彼此不同的架构，每一种的存在，都是因为检索会以某种特定方式失败。选错了，你只是白白多付成本和延迟。

1. 混合检索 + 重排序，治的是词汇不匹配。纯向量搜索擅长“取消”约等于“终止”，却对精确匹配很差。混合检索同时跑稠密向量和经典关键词检索（BM25），再用倒数排名融合把结果合并。稠密抓语义，BM25抓被向量抹平的那个字面词。之后再做重排序：先多捞（比如150个候选），用一个更慢的交叉编码器对着查询重新打分，留下最好的20个。交叉编码器同时读查询和文档，能抓到双编码器漏掉的相关性。这一条是所有人的必修课，不是进阶技巧。

2. 查询改写，治的是问题不等于答案。用户写的问题又短又乱，那就先改写再搜。四种做法：多查询，让模型把问题换3到4种说法分别检索再合并；RAG-Fusion，在多查询基础上叠加倒数排名融合，在多次改写里都冒头的文档会浮上来，但要注意，生成的查询一旦跑偏，答案也跟着跑偏；HyDE，不嵌入问题，而是让模型先写一个假答案，再用它去检索，假答案长得更像真文档，但它可能编出糟糕的假设，得配上重排序；退一步提问，遇到窄问题先问一个更泛的问题，取回背景再答具体。适合场景：对的文档存在，但查询找不到它。成本很低，多一次模型调用。

3. 上下文检索，治的是上下文丢失。切块时每块都丢了周围的故事。Anthropic的上下文检索，是在嵌入之前给每个片段前置一小段由模型生成的说明，把它放回所属文档的语境里，这样向量索引和关键词索引都带上了上下文。这是七种架构里唯一有干净公开数字的一个：衡量的是正确片段没进前20的比例，从5.7%降到1.9%。成本约为每百万文档token 1.02美元，一次性，用提示缓存实现。一个诚实的提醒：这组数字来自Anthropic测试中表现最好的嵌入模型，不是平均水平。但一个预处理步骤换来这样的降幅，性价比在整张清单里都算高的。

4. 分层检索（RAPTOR），治的是答案就是整份文档。扁平切块假设答案只在一个段落里。面对“这份80页报告的整体论点是什么”，没有哪个片段装得下。RAPTOR建一棵树：把相关片段聚类、给每簇写摘要、再对摘要聚类再摘要，一路向上。查询时跨层级检索，既能抓细节，也能抓高层综合。论文报告在QuALITY长文档问答基准上配合GPT-4取得约20个百分点的绝对准确率提升，当时是最好成绩。把它当作论文在自己数据集上的结果，而不是对你语料的承诺。适合长而结构化的文档：合同、论文、申报文件、技术手册。拿它做FAQ就是杀鸡用牛刀。

5. GraphRAG，治的是关系型和全语料问题。向量RAG对关系是瞎的。“这两个人怎么连上的”“我们所有事故报告里贯穿了哪些主题”，这些不是相似度问题，top-k找不到。微软的GraphRAG用模型抽取实体和关系建成知识图谱，再跑社区检测（Leiden算法）把图聚类，自下而上预摘要每个簇。两种模式：局部搜索从问题附近的实体出发沿图走，便宜，常常一次模型调用；全局搜索靠对每个社区摘要做map-reduce来回答“主题是什么”，强大也昂贵，一次追踪显示单个全局查询要10次以上模型调用、约20万token，而局部查询约1.15万token。代价在索引：建图是对语料做数百次模型调用，微软后来出了LazyGraphRAG来削减这部分。当关系与全局综合就是你的正事、且语料足够稳定能摊薄索引成本时才用。别把它架在客服台前面。

6. Self-RAG与纠正式RAG，治的是检索到了却答错。有时检索返回的是自信的垃圾，模型照着答。这两种都加了一道检查。Self-RAG训练模型输出“反思token”：自己决定要不要检索、判断每段是否相关、批评自己的答案是否真有支撑，判断活在模型内部。纠正式RAG（CRAG）把判断放到外面：一个轻量评估器给检索到的文档打上正确、模糊、错误三档，分数差就不硬着头皮往下走，而是触发兜底（通常是网页搜索）先找更好的来源。它比需要训练token的Self-RAG更容易挂到现有管线上。适合高风险回答：客服、合规、医疗、法律，那里一个自信的错误答案比“我无法核实”更糟。每次查询多付延迟，留给值得的问题。

7. 智能体RAG（与自适应路由），治的是没有单一管线能服务所有查询。前六种是工具，智能体RAG是挑工具、串工具的工作流。它不再是一次检索一次回答，而是先规划：决定查什么、检索、检查够不够、换个更好的查询再检索、也许调第二个索引、回答前先验证。多步问题因此变得可能。危险在于：每个查询都跑智能体循环又慢又贵，而大多数问题并不需要。所以正在成形的默认做法是自适应RAG：前面坐一个便宜的分类器，把每个查询路由到能答它的最轻管线。简单查资料走混合检索，关系型走图，多步走智能体。只在问题需要时才为复杂度付费。

那到底该建哪个？按顺序的诚实决策规则是：所有人都先做混合检索加重排序，跳过这条，别的都无从谈起；召回仍然不稳，加查询改写，多一次调用；片段在丢意义，加上下文检索，这是清单里性价比最高的一项；问题横跨整份文档，上RAPTOR；问题涉及关系或全语料，上GraphRAG，前提是付得起索引成本；自信的错误答案伤害大，上CRAG或Self-RAG；一个产品里混着多种查询类型，把自适应路由放在前面让它分派。

关于这些数字还有一句提醒：上下文检索的降幅、RAPTOR的QuALITY提升、GraphRAG的token成本，都来自各自的论文和厂商文章，不是一次受控的正面对比。没有一份干净的2026年研究把七种架构跑在同一个语料上。把它们当作方向性参考，然后去跑唯一能决定事情的基准：从你自己的用户那里取十个真实问题，定义什么算正确答案，拿这七种架构对着测。

把玩具演示和生产级RAG分开的能力，不是知道最花哨的架构，而是诊断出五种失败里哪一种属于你，然后伸手去拿修它的那一个工具。Naive RAG是悄悄失败的，修它，从给失败命名开始。