做AI应用开发的兄弟姐妹们，谁还没被大模型气到过？——明明问的是A，它扯到B；让它说点专业的，它一本正经地胡说八道（俗称“幻觉”）；想让它读咱们公司的内部文档，它直接摆烂说“没见过”。而RAG（检索增强生成），就是救咱们于水火的“大模型纠错神器”。

从最基础、堪称“新手村初始装备”的朴素RAG，到能自主决策、堪比“全自动打工人”的高阶智能体RAG，这16种主流方案，各有各的脾气、各有各的用法。今天咱不搞虚的，不用专业术语堆料，用程序员都能get到的诙谐大白话，把每种技术的核心作用、实际踩过的坑（血的教训）、适合啥场景，一次性唠明白，不管是开发落地避坑，还是面试装X，都能直接抄作业。

先给新手兄弟补个小基础，别慌：RAG的核心逻辑，说白了就是让大模型“开卷考试”——以前它答题全靠死记硬背（还总记混），现在咱给它配个“参考书”（就是咱们的知识库），让它先翻书找答案，再组织语言回复，既不瞎编，还能实时更新知识、读咱们的私有文档，主打一个“靠谱不翻车”。下面就按6个分类，逐个拆解这16种RAG技术，怎么好玩怎么说，怎么好懂怎么来。

一、基础入门类（入门必备，快速落地Demo）

这类技术就是RAG里的“新手村套装”，实现起来简单到离谱，门槛低到感人，适合刚接触RAG的兄弟，先把流程跑通，先解决“能不能搜到、能不能生成答案”的基础问题，至于精度？先别要求太高，能跑起来就赢了一半。

1. Naive RAG（朴素RAG）

核心作用：RAG界的“毛坯房”，最简化的实现方式，没有花里胡哨的操作，就是“文档切块→转成向量存起来→用户提问时检索→生成答案”，一步不落地搭好基础架子，完成从“没有检索”到“有检索”的跨越。说白了，所有进阶RAG，都是在它的基础上“精装修”来的。

具体缺点案例：之前有个冤种朋友，用Naive RAG做公司内部的员工手册问答，犯了个最基础的错——把200页的手册按500字“一刀切”，跟切蛋糕似的，不管句子完不完整。结果翻车现场来了：有员工问“老板不批假怎么办”，手册里对应的内容是“请假审批流程：员工请假需提前3天提交申请，部门经理审批，超过5天需总经理审批”，偏偏这句话被切成了两半——前一块结尾是“超过5天需”，后一块开头是“总经理审批”。

检索的时候，系统只匹配到前一块，大模型直接给出“请提前3天提交申请，超过5天需”这样的半截子答案，员工看了一脸懵，等于白做。这就是Naive RAG的坑：太“朴素”，朴素到有点“愣”，完全不管语义完整，切得乱七八糟。

适配场景：适合做小型Demo、简单的私有知识库（比如自己的笔记、短文档），或者快速验证RAG能不能用——毕竟毛坯房虽然简陋，但能快速入住，不追求高精度和用户体验，只要能演示功能，应付一下需求方就行。

2. Multi-Query RAG（多查询RAG）

核心作用：RAG界的“嘴替”，专门解决“用户提问太随意，系统搜不到”的尴尬。比如有人问“怎么报销”，有人问“花了钱怎么找公司要回来”，其实都是一个意思，但系统可能只认“报销流程”这一种说法。它的操作很简单：让大模型当“嘴替”，把用户的原始问题，改成好几种同义说法，多渠道并行检索，最后把结果合并去重，相当于给检索加了个“保险”。

具体缺点案例：我之前帮一个电商朋友做客服问答系统，用了Multi-Query RAG，结果踩了个坑。用户问“退货怎么退款”，大模型一顿操作，改成了“退货退款流程”“如何申请退货退款”“退货后钱款怎么到账”三个问法。本来挺好，但其中“退货后钱款怎么到账”这个问法，检索时匹配到了一堆“退款到账时效”的无关文档，相当于给大模型喂了一堆“垃圾信息”。

最后大模型回答的时候，扯了一大堆“退款72小时到账”“原路返回”，偏偏没说清楚“退货后怎么提交退款申请”，用户看了还是一脸懵。更坑的是，多了几次LLM改写和检索，响应速度直接从1秒变成3.5秒，用户没耐心直接退出了——主打一个“好心办坏事”，精准避开用户需求。

适配场景：适合面向普通用户的口语化问答，比如电商客服、个人助手，用户提问没那么规范，一会儿一个说法；但如果是专业领域，比如程序员问“怎么调接口”，大家说法都统一，用它就纯属浪费资源，多此一举。

3. HyDE（假设文档检索）

核心作用：RAG界的“戏精”，专门搞定“用户提问太短，系统看不懂”的难题。比如用户只问“KV Cache是什么”，就5个字，系统很难匹配到文档里大段的技术解释——毕竟一个短句子和一段长文本，就像小学生和大学生对话，不在一个频道。HyDE的骚操作是：先让大模型“编一段假答案”，不用太准，只要沾边就行，再用这段假答案去检索，因为假答案和文档的“语气、风格”更像，更容易匹配到正确内容。

具体缺点案例：之前做技术博客问答系统，试着用了HyDE，结果翻了车。用户问“KV Cache是什么”，大模型可能是没睡醒，编的假答案居然是“KV Cache是Redis中的一种缓存机制，用来提升数据读取速度”——这纯属瞎编，KV Cache明明是Transformer推理里的优化技术，跟Redis半毛钱关系没有。

用这段假答案去检索，可想而知，搜出来的全是Redis缓存的文档，大模型最后给出的答案，把KV Cache和Redis缓存混为一谈，懂行的人一看就笑了，不懂的人直接被误导。这就是HyDE的坑：戏精演过头，容易“入戏太深”，编的假答案跑偏，反而把检索带沟里。

适配场景：适合用户提问特别短、语义模糊的场景，比如单个技术术语、短句疑问，而且大模型得对这个领域有基本认知，不能是冷门领域——要是问个企业内部的私有术语，大模型编都编不明白，纯属白费功夫。

二、检索增强类（生产必备，提升检索质量）

如果说基础入门类是“新手村套装”，那这类技术就是“职场进阶装备”，专门解决基础RAG“搜不准、搜不全、全是垃圾信息”的问题。毕竟做生产环境，总不能一直用“毛坯房”，得精装修一下，才能扛住实际业务的考验，主打一个“精准不翻车”。

4. 语义分块RAG（Semantic Chunking）

核心作用：RAG界的“精细木匠”，专门纠正Naive RAG“一刀切”的愣头青毛病。它不按固定字数切块，而是先把文档拆成一句一句，再计算相邻句子的“相似度”——就像看两个人长得像不像，相似度高，说明是一个话题；相似度骤降，说明换话题了，就在这里切块，保证每个块的语义都是完整的，不会出现“半截子句子”。

具体缺点案例：之前帮一个科研团队处理论文集，用了语义分块，结果踩了个“成本坑”。100篇论文，每句话都要算一次embedding，比固定切块多花了3倍的计算量，索引构建时间从2小时变成7小时，服务器差点扛不住。更坑的是，相似度阈值太难调了，就像调空调温度，高一点低一点都不行。

阈值设低了，一个块里塞了好几个话题，检索的时候全是噪声；阈值设高了，一个话题被拆成好几个小块，大模型检索到的时候，还是找不到完整的核心观点。最后调试了整整一天，才勉强找到一个合适的阈值，主打一个“精细是精细，就是费人费钱”。

适配场景：适合长文档、逻辑性强的文本，比如论文、会议纪要、访谈记录，这些文档话题切换频繁，用固定切块容易乱；但如果是有清晰章节结构的文档，比如技术手册、产品说明，直接按标题切块就够了，用它纯属“杀鸡用牛刀”。

5. 层级索引RAG（Parent-Child Retrieval，父子块检索）

核心作用：RAG界的“套娃大师”，专门解决“切块大小的矛盾”——切太小，检索精准但上下文不够；切太大，上下文丰富但全是噪声。它的操作很骚：先切“大块”（Parent，相当于书的章节），再把每个大块切“小块”（Child，相当于章节里的段落）；检索时用小块精准匹配，命中后直接返回它所属的大块，既精准又能拿到完整上下文，相当于“找到一句话，给你一整章”。

具体缺点案例：之前帮一个律所做合同问答系统，用了层级索引，结果翻车在“维护成本”上。每份合同切成分章节的大块，再切成段落小块，还要维护“小块属于哪个大块”的关联关系，就像给每个零件贴标签，后期新增合同、修改合同，都要重新处理索引，运维兄弟天天吐槽“快被这套娃逻辑搞疯了”。

还有个坑，响应延迟变高了——用户问“合同中违约金的计算方式”，检索到小块后，还要去拿对应的大块，再让大模型从大块里筛选内容，响应速度比普通语义分块慢了1.2秒，律所的律师急脾气，每次都催“能不能快点，客户还等着呢”。

适配场景：适合超长文档、需要上下文关联理解的场景，比如法律合同、技术手册、书籍，这些文档光看一句话没用，得结合上下文才能懂；如果是短文档，用它就太复杂了，纯属“小题大做”。

6. 混合检索RAG（Hybrid Search）

核心作用：RAG界的“双保险选手”，专门解决“纯向量检索不会找关键词，纯关键词检索不会懂语义”的尴尬。它一边用向量检索“懂意思”，比如用户问“怎么退款”，能匹配到“退货及返还货款流程”；一边用BM25关键词检索“抓精准”，比如用户问“ERROR_CODE_4012”，能精准匹配到包含这个错误码的文档，最后用算法把两边的结果合并，主打一个“既要懂意思，又要抓精准”。

具体缺点案例：之前帮一个医疗团队做文档问答，用了混合检索，结果翻了车。用户问“ERROR_CODE_4012是什么意思”，BM25精准匹配到了包含这个错误码的文档，但向量检索匹配到了一堆“医疗错误码处理”的无关文档，合并结果的时候，因为无关文档数量多，居然把精准文档挤到了后面。

大模型优先基于无关文档生成回答，说的全是“错误码处理的通用方法”，偏偏没提4012这个具体错误码的含义，医生看了直接懵了，差点影响工作。更坑的是，双路检索比纯向量检索多占了40%的服务器负载，运维兄弟天天来吐槽“服务器快扛不住了”。

适配场景：生产环境首选，尤其是术语密集的领域，比如医疗、法律、技术文档，既要懂语义，又要精准匹配专有名词（错误码、型号、法规条款）；如果是普通文本，比如个人笔记，用纯向量检索就够了，用它纯属浪费资源。

7. Reranking（重排序RAG）

核心作用：RAG界的“质检员”，专门过滤检索结果里的“垃圾信息”。不管是向量检索还是混合检索，搜出来的结果里总会混点无关文档，就像买水果，总会挑到几个烂的。Reranking的作用就是，在生成答案之前，让“质检员”（Reranker模型）逐个打分，把最相关的文档留下，无关的扔掉，保证喂给大模型的都是“优质食材”。

具体缺点案例：之前帮一个企业做核心知识库，用了“混合检索+Reranking”，结果踩了“延迟坑”。语料库有10万+文档块，粗检索先召回150个，再用轻量精排筛到20个，最后用Cross-Encoder精排筛到5个，这一套流程走下来，响应延迟直接增加了1.8秒。

更坑的是，高并发的时候，比如每秒100+请求，服务器直接卡顿，用户半天刷不出来答案，投诉电话都快被打爆了。而且精排模型需要大量标注数据训练，小团队根本承担不起训练成本，最后只能妥协，降低精排精度，勉强能用。

适配场景：生产环境、对精准度要求高的场景，比如企业核心知识库、医疗问答、法律咨询，容不得半点垃圾信息；如果语料库规模小，比如几千个文档块，就没必要用它，纯属“杀鸡用牛刀”。

三、自省纠错类（防幻觉，提升回答可信度）

这类技术就是RAG界的“自我反省大师”，专门解决“检索到垃圾文档还乱答、生成答案夹带私货”的问题。毕竟大模型有时候很“叛逆”，就算给它喂了垃圾，它也能一本正经地胡说八道，这类技术就是让它“多反省、少犯错”，主打一个“严谨不翻车”。

8. Corrective RAG（CRAG，纠错式RAG）

核心作用：RAG界的“安检员”，在检索之后、生成之前，加一道“安检”——让大模型逐个审查检索到的文档，看看是不是和用户问题相关。相关的就留下，无关的直接扔掉，要是全无关，就自动去Web搜索兜底，相当于“找不到靠谱资料，就去网上查”，避免基于垃圾文档生成错误答案。

具体缺点案例：之前帮一个政务部门做问答系统，用了CRAG，结果翻了个“兜底坑”。用户问“2026年个人所得税起征点是多少”，内部知识库只有2024年的旧政策，检索到的文档全是无关的，安检后直接触发Web搜索，但那天网络波动，Web搜索只拿到了不完整的信息，大模型最后给出的答案是“2026年个人所得税起征点为5000元（以最新政策为准）”。

看似严谨，实则等于没说，政务部门的工作人员直接吐槽“这答案跟没答一样”。而且多了安检和Web搜索，响应延迟从2秒变成5秒，用户体验直接拉胯，主打一个“纠错没纠明白，还添了新麻烦”。

适配场景：事实性问答、知识类问答，比如政务、医疗、金融，对准确率要求高，容不得半点错误；而且内部知识库可能存在信息滞后、覆盖不全的情况，需要Web搜索兜底，要是内部知识库很完善，用它就有点多余。

9. Self-RAG（自反思RAG）

核心作用：RAG界的“完美主义者”，比CRAG更较真，在整个流程中设置了4个“反省点”，让大模型全程自我审视：① 这个问题需要检索吗？② 检索到的文档相关吗？③ 我的回答有文档支撑吗？④ 这个答案对用户有用吗？，从检索到生成，每一步都要“反省”，生怕出错。

具体缺点案例：之前帮一个律所做法律咨询系统，用了Self-RAG，结果踩了“成本坑”。4个反省点，意味着要多调用4次大模型，成本直接翻了3倍，律所老板天天吐槽“这成本快扛不住了”。更坑的是，它只反省“有没有支撑”，不反省“支撑对不对”。

有一次，用户问“劳动合同到期未续签，员工可以要求赔偿吗”，大模型生成初步答案后，反省发现“赔偿标准”没有文档支撑，于是重新生成，但重新生成时，误把“未续签超过1个月”的赔偿标准，写成了“未续签超过3个月”，原因是它没检查文档支撑的准确性，只检查了“有没有支撑”，最后差点给律所惹了麻烦。

适配场景：高严谨场景，比如医疗诊断、法律诉讼咨询、政务答复，容不得任何幻觉和错误，宁愿多花点成本、多等几秒，也要保证答案的严谨性；如果是普通场景，比如个人助手，用它就太矫情了，纯属浪费钱。

10. Adaptive RAG（自适应RAG）

核心作用：RAG界的“智能调度员”，专门解决“所有问题都走完整流程，浪费成本和时间”的问题。它在流程最前面加了一个“路由器”，先判断问题的复杂度：简单问题（比如“公司地址在哪”），直接让大模型回答，不用检索；中等问题（比如“年假怎么休”），走基础检索流程；复杂问题（比如“对比两个方案的优缺点”），走完整CRAG流程，主打一个“能省则省，效率优先”。

具体缺点案例：之前帮一个企业做客服系统，用了Adaptive RAG，结果翻了“误判坑”。分类器把“公司地址在哪”判定为简单问题，直接让大模型回答，但大模型的知识滞后，把公司的旧地址（已经搬迁半年）当成了答案，用户按地址找过去，发现根本没人，直接投诉。

更坑的是，对于“模糊复杂度”的问题，比如“公司年假怎么休”，既不算特别简单，也不算特别复杂，分类器经常误判——有时候直接回答，漏了关键信息；有时候走复杂流程，增加延迟，客服人员天天吐槽“还不如不用，反而更麻烦”。

适配场景：用户提问参差不齐的场景，比如企业客服、通用助手，既有简单的事实查询（地址、电话），又有复杂的综合查询，需要平衡效率和准确率；如果用户提问都很简单，或者都很复杂，用它就没必要了。

四、结构化&多跳推理类（适配特殊数据，解决复杂推理）

这类技术就是RAG界的“特种部队”，专门处理“普通RAG搞不定的特殊情况”——比如表格数据、关系网络，还有需要跨文档推理的问题，普通RAG要么处理不了，要么处理得很烂，这类技术就是来“救场”的，主打一个“专治各种不服”。

11. GraphRAG（图谱RAG）

核心作用：RAG界的“侦探”，专门解决“答案散落在多个文档，需要跨文档推理”的问题。它先把文档里的“人物、部门、产品”等实体，还有它们之间的关系（比如“张三是AI部门负责人”），抽出来构建成一张“知识图谱”，就像侦探的线索板，然后基于这张图谱，跨文档多跳推理，找到最终答案。

具体缺点案例：之前帮一个企业做组织架构问答系统，用了GraphRAG，结果踩了“构建成本坑”。1000篇文档，用大模型逐个抽取实体和关系，花了整整3天，而且还需要人工核对，避免抽错——有一次，文档里写的是“AI部门属于技术中心”，结果大模型抽成了“AI部门属于运营中心”，导致用户问“张三属于哪个中心”时，推理出“张三属于运营中心”的错误答案。

更坑的是，后期维护成本极高，公司一调整组织架构，就要重新抽取实体、更新图谱，运维兄弟天天加班，直呼“顶不住”。而且对于简单的事实查询，比如“张三是哪个部门的”，用普通RAG一秒就能搞定，用它反而要走一遍图谱推理，纯属“小题大做”。

适配场景：需要跨文档多跳推理的场景，比如人物关系查询、企业架构查询、因果链路分析，实体和关系明确的文档；如果是简单事实查询，就别用它了，又费钱又费时间。

12. Text-to-SQL RAG

核心作用：RAG界的“数据库高手”，专门处理结构化表格数据——比如销售数据、财务报表、用户日志，普通RAG对这些表格束手无策，只能把表格当成文本处理，效率极低。它的操作很简单：让大模型把用户的自然语言问题，翻译成SQL语句，去数据库里查询，再把查询结果用自然语言组织成答案，相当于“让大模型帮你写SQL”。

具体缺点案例：之前帮一个电商做数据分析系统，用了Text-to-SQL RAG，结果翻了“SQL写错”的坑。用户问“上个月销售额最高的产品是哪个”，大模型把SQL写成了“SELECT product FROM sales WHERE month = ‘this’ ORDER BY amount DESC LIMIT 1”，把“last”写成了“this”，导致查询到的是本月销售额最高的产品，和用户需求完全不符。

更危险的是，一开始没做安全控制，大模型居然生成了“DELETE FROM sales”这样的危险SQL，差点把整个销售数据删了，吓得我们赶紧加了权限控制和SQL审计——这玩意儿要是不做好安全，简直是“定时炸弹”。

适配场景：数据分析类需求，比如BI看板问答、财务报表查询、后台数据检索，数据以结构化表格为主；一定要搭配权限控制、SQL审计等安全措施，不然容易出大问题。

五、智能体高阶类（自主决策，适配复杂场景）

这类技术就是RAG界的“全自动打工人”，引入了AI智能体（Agent），让RAG具备“自主决策、灵活调度”的能力，不用人工预设流程，能自己判断该用什么工具、该检索什么内容，适合企业级复杂系统，主打一个“省心省力”。

13. Agentic RAG（单智能体RAG）

核心作用：RAG界的“全能打工人”，一个智能体就能搞定所有事——它手里有一堆工具：向量检索、Web搜索、SQL查询、图谱遍历，用户提问后，它会自己思考：“这个问题该用哪个工具？”“检索到的信息够不够？”“不够的话再搜一次？”，循环补全信息，直到生成满意的答案，不用人工干预。

具体缺点案例：之前帮一个企业做综合问答系统，用了Agentic RAG，结果踩了“决策混乱”的坑。用户问“张三上个月的考勤记录和所属部门”，Agent先调用向量检索查“张三所属部门”，再调用SQL查“张三上个月考勤”，但调用SQL时，没明确“上个月”的时间范围（比如2026年3月），结果查询到的是2026年2月的考勤记录，导致回答错误。

更坑的是，当问题涉及多个工具切换时，Agent容易“乱了阵脚”，比如一会儿调用向量检索，一会儿调用Web搜索，来回切换，响应延迟直接飙到6秒，用户根本没耐心等，主打一个“看似全能，实则偶尔掉链子”。

适配场景：复杂复合问题、多数据源混合查询，比如同时需要检索文档、查询数据库、联网获取信息，不用人工预设流程，适合企业综合助手、智能分析师。

14. Multi-Agent RAG（多智能体RAG）

核心作用：RAG界的“团队协作”，把单个智能体拆成多个“专职打工人”，分工明确、各司其职：Router Agent负责“分发问题”，看哪个问题该交给谁；Doc Agent负责“文档检索”；SQL Agent负责“结构化查询”；Verifier Agent负责“质检”；Writer Agent负责“润色输出”，每个Agent专注于一件事，效率和准确率更高。

具体缺点案例：之前帮一个大型企业做知识库，用了Multi-Agent RAG，结果踩了“协同混乱”的坑。用户问“2026年第一季度销售额最高的产品，对应的部门负责人是谁”，Router Agent把问题分给了SQL Agent（查销售额）和Doc Agent（查部门负责人），但两个Agent的结果返回不同步——SQL Agent用了3秒，Doc Agent用了5秒，Writer Agent等了半天，才拿到完整信息，响应延迟直接达到8秒。

更坑的是，多Agent协同需要复杂的调度机制，后期维护成本极高，一个Agent出问题，整个流程都卡住，技术团队天天加班排查问题，老板还觉得“这玩意儿怎么这么难维护”，主打一个“团队协作好，但维护起来要命”。

适配场景：企业级复杂系统、大型知识库、多数据源（文档、表格、图谱）、权限复杂、语言多样的场景，适合有足够技术团队支撑的大型企业，小团队就别碰了，根本维护不起。

六、拓展场景类（适配特殊需求，提升性能）

这类技术就是RAG界的“拓展包”，专门适配“特殊需求”——比如多模态数据（图片、表格、截图）、低延迟要求，普通RAG满足不了，这类技术就能“补位”，主打一个“按需拓展，满足个性化需求”。

15. 多模态RAG（Multimodal RAG）

核心作用：RAG界的“全能视觉选手”，打破传统RAG只处理文本的局限，能搞定文本、图片、表格、截图等多模态数据——它把这些数据统一编码到同一个“向量空间”，相当于给所有数据贴了“统一标签”，检索时能跨模态匹配（比如用文本提问，检索到相关图片和表格），再用视觉语言模型处理混合数据，生成完整答案。

具体缺点案例：之前帮一个企业做产品手册问答系统，用了多模态RAG，结果踩了“视觉识别坑”。产品手册里有很多产品截图和参数表格，用户问“产品的外观尺寸是多少”，系统检索到了包含尺寸的截图和表格，但视觉语言模型无法精准识别截图中的尺寸数字（因为截图有点模糊），最后给出的答案是“产品尺寸约为10cm×5cm（具体以截图为准）”，不够精准。

更坑的是，多模态编码的计算成本极高，比纯文本RAG多占了80%的服务器负载，服务器经常卡顿，而且需要大量多模态训练数据，小团队根本搞不起，主打一个“功能强大，但成本感人”。

适配场景：包含图片、表格、截图的文档，比如产品手册、PPT、图文教程、设计文档，需要跨模态问答的场景（比如“图片中产品的参数是什么”）。

16. Speculative RAG（推测式加速RAG）

核心作用：RAG界的“速度选手”，专门解决“传统RAG延迟高、成本高”的问题。它的骚操作是：把检索到的文档拆成多个子集，让多个“小模型”（廉价、快速）并行生成候选草稿，就像多个实习生同时写报告，最后让一个“大模型”（昂贵、精准）来校验、筛选最佳答案，既快又省成本，主打一个“高效不费钱”。

具体缺点案例：之前帮一个C端智能助手做优化，用了Speculative RAG，结果踩了“草稿跑偏”的坑。用户问“2026年AI领域的最新趋势”，检索到15个文档块，拆成5个子集，5个小模型并行生成草稿，但其中2个小模型“摸鱼”，把AI趋势写成了区块链趋势，大模型校验时，因为草稿数量多，没完全识别出偏离主题的内容，导致最终回答里混入了区块链相关的无关信息。

更坑的是，多小模型并行需要更多的服务器资源，部署成本增加，虽然省了大模型的调用成本，但服务器成本上去了，相当于“拆东墙补西墙”，主打一个“速度有了，但偶尔会掺水”。

适配场景：高并发、低延迟要求的场景，比如C端智能助手、线上客服，用户对响应速度要求高，而且对成本敏感，适合流量大的产品。

七、总结：16种RAG技术场景适配总表（快速抄作业）

技术名称	核心作用（大白话）	核心缺点（血的教训）	适配场景（直接对号入座）
Naive RAG	毛坯房，搭好RAG基础架子，能跑就行	切块愣，易截断语义，答案不完整	Demo开发、小型短文档、快速验证功能
Multi-Query RAG	嘴替，多问法检索，解决用户表述乱的问题	延迟高，易混入无关文档，成本上升	电商客服、个人助手，用户口语化提问多
HyDE	戏精，编假答案检索，解决短问题匹配难	假答案易跑偏，误导检索结果	短问题、语义模糊，大模型有基础认知的领域
语义分块RAG	精细木匠，按语义切块，保证答案完整	计算成本高，相似度阈值难调	论文、会议纪要，话题切换频繁的长文档
层级索引RAG	套娃大师，小块检索、大块返回，兼顾精准和上下文	索引复杂，维护成本高，延迟增加	法律合同、技术手册、书籍等超长文档
混合检索RAG	双保险，语义+关键词检索，精准不跑偏	计算成本高，融合时易排序偏差	生产环境、医疗/法律/技术等术语密集领域
Reranking	质检员，过滤垃圾文档，提升答案质量	延迟高，训练成本高，高并发扛不住	企业核心知识库、医疗/法律咨询，高精准要求
CRAG	安检员，检索后质检，无效则Web兜底	延迟高，兜底检索可能信息不完整	政务、医疗、金融，事实性问答，高准确率要求
Self-RAG	完美主义者，全流程自检，避免幻觉	成本高，只查有没有支撑，不查支撑对不对	医疗诊断、法律诉讼，高严谨场景
Adaptive RAG	智能调度员，按复杂度路由，省成本提效率	分类器易误判，简单问题可能出错	企业客服、通用助手，用户提问参差不齐
GraphRAG	侦探，知识图谱+多跳推理，解决跨文档问题	构建成本高，易抽错实体，维护复杂	人物关系、企业架构，多跳推理场景
Text-to-SQL RAG	数据库高手，自然语言转SQL，处理表格数据	SQL易写错，存在安全风险	BI看板、财务报表，数据分析类需求
Agentic RAG	全能打工人，单Agent自主调度工具	决策易混乱，延迟高	复杂复合问题、多数据源混合查询
Multi-Agent RAG	团队协作，多Agent分工，提升复杂任务能力	协同复杂，维护成本高，延迟高	大型企业、复杂系统、多数据源场景
多模态RAG	全能视觉选手，处理图文表格混合数据	计算成本高，视觉识别易出错	产品手册、PPT，跨模态问答场景
Speculative RAG	速度选手，小模型起草、大模型校验，降延迟	易混入跑偏草稿，部署成本高	C端助手、线上客服，高并发低延迟需求