企业官网建设流程全解析

从查资料到手写答案：RAG 2.0到底改了什么

做AI应用落地的人，今年应该都被一个词反复轰炸过：RAG。别急着划走，如果说RAG 1.0是“笨办法的典范”，那RAG 2.0就是“开始动脑子的检索增强生成”。这篇内容我会用最直接的话讲清楚RAG 2.0的核心变化、实操链路、常见坑位，适合正在搭知识库问答、私有文档助手、客服机器人，或者被“检索不精准、回答总瞎编”折磨的开发者、产品经理和技术架构师。看完你至少能回答三个问题：2.0比1.0强在哪、落地时每一步该怎么做、出了毛病又从哪儿查起。

我最早接触RAG 1.0的时候，心里那股兴奋劲儿没过两周就凉了。原因特别简单：客户要的不是“能引用文档”，而是“每一次都能引用到对的文档”。1.0的问题非常固定——召回不准、上下文混淆、回答一看就是拼接怪。后来我陆续参与了几个知识库问答项目的改造，自己也踩了不少坑，才把“RAG 2.0到底该怎么做”这事儿想明白。今天这篇，说原理但不说废话，说步骤但不说没用的话。

1. RAG 1.0到2.0：到底变了什么东西

1.1 先回忆一下1.0的经典链路

RAG 1.0的流程，大多数人闭着眼都背得出来：把文档切开，做Embedding（嵌入向量），存进向量数据库；用户提问后，把问题也转成向量，去库里做相似度检索；拿回Top-K个片段，拼到大模型提示词里，让模型基于这些片段生成回答。

这套链路能不能跑？能跑。但只停留在“demo能转”的程度。我举个特别生活化的例子：你问图书馆管理员“最近有什么好看的小说推荐”，1.0的流程等于管理员先去索引卡里翻出几本和“小说”沾边的书，然后直接把这些书的封面复印给你，让你自己猜内容。他没有能力根据你的喜好做筛选、排序、摘要。最终你拿到手的可能是三本悬疑小说加一本菜谱——因为索引卡里“小说”和“食谱”在某个标签维度上离得特别近。

用技术话说，1.0的核心缺陷集中在三个地方：

• 检索层太粗糙：只用向量相似度，根本不理解问题里的否定、比较、条件限定，关键词变个说法就召回失败。
• 排序层缺失：拿回Top-K之后按相似度原样上抛，没有考虑“这个片段是否真的能回答问题”。
• 生成层被污染：这些片段里如果只有一句相关、其余全是无关信息，大模型会被无关内容带偏，生成出一段似是而非的鬼话。

这就是RAG 1.0被诟病“又笨又不可控”的原因。它不是没用，而是上限太低。

1.2 2.0的核心变化：从“检索拼接”到“理解—决策—精炼”

RAG 2.0最大的变化，我认为不是某一个环节的魔法优化，而是整个管线被重新设计成了“理解—决策—精炼”三段式。这个思路有点像人脑处理一道难题：先理解题目在问什么，再决定去翻哪本书，找出关键段落，最后组织语言、过滤噪声、写出答案。它不再是一个简单的“查了就用”的管道，而是一个带着判断力的流程。

具体拆开看，2.0在原有Embedding+向量检索的基础上，主要增加了五类能力：

1. 查询理解与改写：先把原始问题拆解、补全、消除歧义，再用于检索。
2. 混合检索：同时跑向量检索、关键词检索、结构化检索，多路召回。
3. 结果精排：对多路召回结果统一重排，去重、过滤、按相关性排序。
4. 上下文压缩：只保留最有用的一句话或几句，而不是整段塞给大模型。
5. 路由与决策机制：根据问题类型自动选择不同检索策略甚至不检索直接回答。

你可以粗线条地理解为：1.0是“把能找到的都端上来”，2.0是“把能用的挑出来，再炒成菜”。不少团队把这套东西叫“高级RAG”或者“模块化RAG”，但本质上大家解决的是同一个痛点——让模型不要被猪队友检索器坑到。

2. 核心细节逐一拆解：五大关键环节怎么落地

2.1 查询改写：一句话问得不好，后面全崩

我见过太多团队花大力气调Embedding模型、刷向量库参数，结果召回率上不去，查来查去发现问题出在用户提问本身太“脏”。用户不是搜索引擎专家，他们不会好好说话。

举一个我在某客服项目中遇到的真实例子。用户问：“你们这个套餐能不能退？昨天刚办的，没用过，不想用了可以退吧？违约金多少？”如果直接把这句话提交给向量检索，效果很不好，因为它包含大量冗余信息。拆解之后真正要查的是三个子问题：“未使用套餐能否退订”“退订流程是什么”“违约金多少”，这是典型的多意图查询。

查询改写这个环节，2.0一般会做四件事：

• 去除口语语气词和冗余信息：把“那个”“就是说”“嗯”之类的词清掉。
• 补全指代词：把“它”“这个”替换成具体名词。
• 子问题拆分：一个复杂问题拆成多个独立子问题，分别检索再合并。
• 假设性文档生成：让大模型先把问题改写成一段假设性答案，那这段假设性答案常常比原问题更好检索。这个技巧在学术上比较流行，实测下来对召回率提升明显，但要注意成本翻倍，不是所有场景都推荐。

实操上，我个人不建议直接用大模型做“开放式改写”，因为大模型改写经常添油加醋，凭空加条件。更稳妥的做法是用结构化指令：先让模型判断“问题是否模糊、是否有多个意图、是否有指代”，然后再进行对应处理，每一步都被约束住。实测下来，结构化改写的稳定性远高于直接让模型自由发挥。

2.2 混合检索：向量不是万能的，BM25还能打

我在很多技术社区看到新人问：我都用了业界最强的Embedding模型了，为什么召回还是不准？因为向量检索理解语义，但不擅长精确匹配。你搜一个产品型号“A-1000X”，向量检索很可能把它识别成“A1000”“1000X”之类的变形，而关键词检索能精确命中。反过来，你搜“怎么退款”，关键词检索可能匹配到一堆含“退款”但不含相关步骤的内容，向量检索却能找到语义相近的“退钱流程”。

混合检索的思路就是让两个人比赛，然后综合成绩。通常的做法是向量检索+BM25关键词检索+结构化字段过滤三路并行。BM25是什么？说人话就是：一个词在文档里出现得越多、文档越短、整体语料里这个词越稀有，分就越高。它非常朴素，但在精确词汇匹配上往往比向量模型更靠谱。

我建议你拿到任何RAG项目，第一件事不是去调Embedding参数，而是先把BM25接进去做基线。很多情况下，BM25单独出战就能解决四成以上的召回问题，混合后整体召回率提升非常明显。

混合检索的另一个关键是结果融合。两条路返回的结果怎么合并？最简单的做法是分数加权，比如向量分×0.6+BM25分×0.4，但权重需要实测调整。进阶做法是使用RRF（Reciprocal Rank Fusion）算法——按排名而不是分数去融合，思路是“两条路都把这个结果排前面，那它一定值得被排到最前”。我比较推荐RRF，它对不同模型的分数尺度差异不敏感，通用性和稳定性都更好。

2.3 重排序：精排才是质量的真正分水岭

如果说混合检索解决的是“找得全”，那重排序解决的就是“排得准”。为什么必须单独做精排？因为向量检索+BM25的分数定义的是“语义相似度”或“关键词命中度”，而用户真正需要的是“对当前问题的有用程度”。相似≠有用，这是RAG系统最常见的认知误区之一。

举例来说，用户问“苹果公司的创始人是谁”，文档里有一句话是“苹果公司的总部位于美国加州库比蒂诺”，向量相似度可能给这句话打了高分，因为它和问题共享了“苹果公司”“美国”等词。但这句话对回答问题毫无帮助。重排序模型的作用，就是站在“这个片段能否解答当前问题”的角度重新打分。

实践中，我推荐在架构中单独部署一个交叉编码器（Cross-Encoder）模型用于精排。它比双塔Embedding模型慢，但精度高得多，因为它把“问题+片段”拼接在一起输入模型，能捕捉到更细粒度的交互关系。重排后取Top-3或Top-5就够用了，送入生成器的知识量越小，噪声越少，生成质量越高。

精排模型怎么选？我一般推荐用开源的Reranker模型，在中文场景下效果都不错。如果不方便部署独立模型，也有退而求其次的方案：让大模型自己做“段落排序”。把Top-10个片段标号后让大模型挑出其中最相关的3个，这相当于用大模型代替精排模型。成本高，但胜在简单，适合快速验证效果。

2.4 上下文压缩：给大模型“少而精”的材料

很多RAG项目跑起来之后，检索做得还行，但生成质量差，原因在于喂给模型的上下文太乱。我拆过一个实际案例：用户问“这款手机的屏幕参数是什么”，检索系统召回了Top-5片段，但其中只有一句话包含屏幕分辨率，另外四段分别是手机外观评测、拍照样张描述、电池续航数据和购买建议。大模型拿到这样一个“大杂烩”，生成的回答极易被带偏——它会先谈外观，再谈拍照，最后顺手提一句屏幕，整体答非所问。

上下文压缩就是为了解决这个问题。思路很简单：在把片段塞进提示词之前，先对每个片段做一次清洗和压缩。具体手段有很多：

• 相关句子抽取：让模型只保留与问题相关的句子，其他全部删掉。
• 摘要生成：把整段内容压缩成两三句摘要，保留核心信息的同时缩短篇幅。
• 指代消解：把分割后碎片里缺失的主语、宾语补全，防止模型读到“它采用了XX技术”时不知道“它”是谁。
• 冗余去除：多个片段如果包含相同的信息，只保留一个。

尤其是指代消解，很多团队完全忽略这一点。文档切分后，一个完整的上下文被打散到不同片段里，片段A说“该公司发布了新产品”，片段B说“该产品定价4999元”，如果不把“该公司”和“该产品”还原成具体名词，大模型拿到材料后很容易理解错。

上下文压缩最朴素的做法就是让大模型对每个片段执行一段压缩指令。如果预算有限，可以设置一个阈值——当片段数量少且单片段内容清晰时，跳过压缩，直接送入生成器，压缩只在与问题强相关的片段比例低于某阈值时启用。

2.5 路由与决策：不是所有问题都需要检索

这是RAG 2.0中我认为最容易被忽略、但价值极高的一环。很多人把RAG当成一个固定流程——只要有用户提问，就一定先去向量库里捞。但实际情况是，用户的问题分很多种：

• “你好，在吗？”——不需要检索，直接寒暄。
• “苹果公司在哪一年成立的？”——这是常识问题，大模型自己就知道，检索反而可能引入错误文档。
• “请帮我总结一下《浪浪山》前五章的内容。”——需要检索，而且是定向检索。
• “按价格从低到高排序，列出你们在售的蓝牙耳机型号。”——需要多路检索加结构化过滤。

如果没有路由机制，所有问题都往检索管道里塞，会出现三个坏结果：常识问题被不相关文档干扰、寒暄问候浪费检索资源和时间、复杂问题因为走了单一检索路径而召回不足。

RAG的“路由”做法，一般是用一个轻量级分类器（小参数模型或大模型单次调用）对用户问题做标签分类，常用四类：

• 闲聊类：直接走对话模型，不检索。
• 常识知识类：不检索，靠模型内部知识回答。
• 私域知识类：启用完整检索链路。
• 复杂推理类：先拆分、再检索、再汇总。

这一步虽然逻辑简单，但很多团队没做。原因我也理解：路由模型要单独维护一套分类规则，增加了系统的复杂度和失败点。但从项目效果看，不做路由的系统，上限都很低。早期做了路由判断，后期调优的日子会好过得多。

3. 实操过程：一个可复现的RAG 2.0最小闭环

3.1 基础架构与工具选型

RAG 2.0不是某一种技术产品，而是一条链路。我就以一套低成本、可复现的组合为例，把完整链路跑通。先说明，这套选型不是唯一答案，但它是我在轻量级项目中实测过的稳定方案：

这个组合基本能满足中小型私有知识库问答场景。如果你的项目达到百万级文档规模，HNSW内存占用和BM25索引规模可能需要额外关注。

3.2 三步完成RAG 2.0改造

如果你有一个已经跑通的RAG 1.0系统，改造不是推翻重来，而是分三步升级，每一步都能立即看到效果变化。

第一步：加查询改写

在用户提问进入向量检索之前，插入一个改写LLM调用。强制让模型完成三步动作：拆解子问题、补全指代、去掉冗余语气词。这个步骤对召回率的提升是最立竿见影的，很多模糊问题在这一步之后就“能查了”。

第二步：加混合检索+RRF融合

保留原有向量检索，并行加入BM25关键词检索。融合方式用RRF，避免手动调权重的麻烦。这一步做完，你会发现一些精确型号、特殊名词类的检索效果明显变准了。

第三步：加重排序+上下文压缩

把原来Top-K的向量结果改为“混合召回Top-20”→精排模型打分→取Top-4→再压缩，最后送入生成器。这一步做完，生成质量的提升是肉眼可见的——回答开始有重点了，不再像以前那样东拉西扯。

我建议按这个顺序逐步改造，每完成一步就做一次评测对比，这样你能清楚地知道每一层到底带来了多少收益，而不是一股脑全上然后凭感觉说“效果变好了”。

3.3 关键参数选多少

关于参数，我直接给基于实践的经验值，但提醒一句：具体值需要根据你的文档情况实测。

• 切分块大小：512个Token是相对安全的默认值，如果文档是法律、医学类长句多的内容，建议降为256，避免关键信息被截断。
• 向量检索Top-K：不要直接设10，混合召回阶段建议设20到30，给精排留足候选空间。只召回10个的话，精排再好也难翻身。
• 精排后Top-K：控制在3到5，推荐4。给大模型4个高质量片段，生成质量和响应速度最均衡，多了会让模型“选择困难症”发作。
• 上下文压缩长度：每个片段压缩后尽量控制在200字以内。大模型的注意力窗口是有限的资源，不要浪费在废话上。
• RRF常数K：默认60就好，不需要过分调参。

参数选择的核心逻辑很简单：前面宽进（多召回），中间精排（去噪声），后面窄出（只留精品）。

4. 常见问题与排查技巧实录

4.1 问题排查速查表

我整理了一个排查清单，全是实际项目中反复遇到的问题，你按照这个表格去对照分析，比自己瞎调参数高效得多：

4.2 三个我最想强调的坑

第一个坑：太迷信向量检索。RAG 1.0时代养成的最固执习惯。向量检索是利器，但不是万能钥匙，混合检索在绝大多数中文场景都能带来明确收益。我见过好几个团队把所有精力花在挑选更好的Embedding模型上，结果召回率提升微乎其微，加了个BM25反而涨了十几个点。

第二个坑：把精排做成摆设。很多人做了精排，但没有真正审视“精排之后的Top-4到底是不是对的”。精排模型选型不匹配域时，它的排名甚至不如向量相似度靠谱。验收精排效果的方法很简单：随机抽取50个问题，人工评判“Top-4是否包含正确答案”，如果命中率低于80%，说明精排环节需要优化。

第三个坑：没有评测体系就上线。不少团队上线RAG系统后，全靠“看着还行”来判断好坏。RAG系统是一个多环节组成的复杂管线，任何一个环节坏了都没法靠肉眼定位。没有评测集和指标，优化就是盲人摸象。这是我觉得RAG项目里最容易被忽视又最致命的问题。

4.3 搭建一个简易评测集

RAG评测不需要等“完美再开始”。拿最小可用的方案来：准备几十个真实用户问题，人工写好标准答案，同时标注“这个问题来自哪个文档片段”。然后跑系统，记录四个数据：

1. 召回命中率：正确答案的片段是否出现在精排后的Top-5里。
2. 忠实度：回答中的信息是否都能在检索片段中找到依据。
3. 答案相关度：人工打分，1到5分，看回答是否切题、完整、没有废话。
4. 端到端延迟：单次请求从发起到返回的总时间。

我习惯的做法是先跑一遍基线，记录召回命中率；每改一个环节，就重新跑同一批问题，对比指标升降。有了这套笨办法，每次改动是好是坏一目了然，不会被“感觉好像变好了”蒙混过关。

常在RAG项目里待的人会知道，这种评测集维护起来需要持续补充新问题。每上线一轮新功能、每接入一个新领域的文档，就往评测集里加20到30个问题。日积月累，评测集会成为比算法模型还珍贵的资产。

5. 落地评估与持续迭代

5.1 离线指标要看，但别只看生成质量

我遇到过不少团队，评估RAG时只盯着最终回答是否“像那么回事”，这很容易误判。建议把评估拆成两段看：检索质量和生成质量。检索质量看两个指标：召回率（正确答案是否在候选里）和命中率（正确答案是否排在第一位或者Top-K），这两个指标反映的是管道前半段的健康度。生成质量看忠实度和答案相关度，反映的是后半段的能力。

我在实际项目里更看重忠实度这个指标。它是说“回答里的每一个关键信息能否在检索片段中找到依据”。如果忠实度高，哪怕回答有点生硬，系统也是可用的、可控的。如果忠实度低——模型开始自由发挥、脑补事实——那就危险了，轻则回答不靠谱，重则产生幻觉信息，在医疗、法律、金融等严肃场景里是完全不可接受的。

5.2 线上监测怎么设计

系统上线后，离线评测的那套就不能完全覆盖了。真实用户的问题分布永远比你想象的野。我习惯性的线上监测方案由三条线组成：

• 线上日志抽样：每天从真实问答日志中随机抽样50条，人工打标“好/中/差”，观察波动趋势。
• 用户反馈通道：在对话界面放“回答是否解决了问题”的按钮，直接收集用户侧满意度的信号。
• 失败案例复盘：每周固定抽半天时间，把所有“差”评案例拿出来逐条分析，定位失败环节是检索、精排还是生成。这个习惯虽然原始，却是我见过最能驱动系统迭代的机制。

5.3 从2.0继续往前走

RAG 2.0不是终点，但这个架构的精髓——理解、决策、精炼，而不是简单拼接——会是下一代方案的基础骨架。接下来值得关注的方向还有不少，比如图表混合的文档问答、结构化数据与文本混合检索、以及模型自主决定何时检索何类工具的智能体模式（Agentic RAG）。

如果让我给一个务实建议：不要等所有新技术成熟了再动手，先把2.0的完整链路跑通、把评测体系搭好，未来不管底层模型怎么换、检索策略怎么升级，你都有能力快速迁移和验证。

做RAG这么久，我最大的体会是：这个领域没有银弹，只有一条条链路、一个个环节的细致打磨。你每次多解决一个环节的小问题，系统的整体效果就上一个台阶。今天把RAG 2.0这套东西讲透，就是希望你在搭自己的知识库系统时，少走一些我走过的弯路。先把自己的数据样例和评测集准备好，剩下的问题，遇到一个，解决一个，路就通了。