企业官网建设流程全解析

你有没有遇到过这种情况：问大模型一个业务问题，它答得头头是道，引用的编号、流程、人名一应俱全，结果你翻遍原始文档却找不到出处。大模型一本正经地胡说八道，是现在知识库问答场景里最扎手的难题，而RAG（检索增强生成）就是当前行业里公认最直接、最有效的解法之一。这篇文章不打算复制那些满天飞的概念定义，而是结合我自己做私域知识库问答系统的实际经验，拆一拆RAG到底怎么落地、在哪些环节最容易翻车，以及它怎么帮你把大语言模型的“知识边界”重新画清楚。

如果你正在做智能客服、内部文档问答、合同审阅助手或者行业知识库这类项目，这篇文章会告诉你从文档处理到检索调优、上线评测的一整套操作路径；如果你只是对大模型幻觉好奇，也能从中看到RAG为什么被叫做“开卷考试”的底层逻辑。

1. 幻觉是怎么来的，RAG为什么偏偏能治它

1.1 大模型幻觉产生的三个根源

要理解RAG的价值，得先搞明白大模型为什么会产生幻觉。很多人以为幻觉是模型“笨”或者“装懂”，其实根源比这更深。

第一，语言模型本质上是一个概率预测器。它输出的每一个词，都是根据前面的内容计算出的最高概率候选，而不是从某个知识数据库里查出来的确定事实。这就像一个人考试时靠蒙答案，蒙得越来越顺，概率上看起来越来越“合理”，但合理不等于正确。尤其当问题超出了一个模型的训练数据覆盖范围，它没有对应的事实锚点，就只能按语言习惯“顺嘴编”，编出来还因为逻辑通顺显得特别可信。

第二，知识截止日期是硬伤。任何大模型在训练完成后，它的世界知识就固定在那个时间点了。今天上线的制度文件、三天前更新的产品手册、某个团队内部才有的故障排查记录，模型在训练时根本没见过，却照样会被用户追问。没有事实输入，模型为了维持对话不冷场，就会把“我不知道”包装成各种看似专业的描述。

第三，上下文容量看似解决了，实则加剧了幻觉。模型可以接收几十万字的长上下文，但注意力机制在面对超长文本时，并不总能拎出关键的那几句话。你想象一下让你在一本500页的说明书里找某个零件的维修参数，你可能翻到头都找不到，被催急了就会根据前面看过的内容编一个。模型面对长上下文时也有类似的困境，信息存在但无法被有效聚焦。

理解了这三点就会发现：幻觉不是某个模型独有的毛病，而是一种系统性的、概率生成机制带来的必然倾向。想靠换一个更大的模型根治它，路线基本是错的。

1.2 RAG的底层逻辑：从闭卷考试变成开卷考试

RAG的思路非常简单直接：与其让模型靠“记忆”回答，不如在回答之前先给它翻书的机会。

它的流程大致是这样一个链路：先把知识库里的文档做清洗、分块、向量化，存进一个可以被快速检索的索引；用户提问时，系统先把问题也变成向量，在索引里找出最相关的若干块；然后把这些检索到的文本块和用户问题拼在一起，放进大模型的上下文里，由模型依据这些材料组织答案。

这个过程的最大价值，是把“事实信息”从模型静态的参数里抽了出来，放到了动态可控的上下文里。回答问题的依据不再是模型模糊的记忆，而是实实在在检索到的原文。这就好比一场考试从闭卷变成了开卷，学生不需要再靠记忆去蒙答案，而是可以直接翻到第几页第几行来作答。模型生成时看到的材料里如果有确切答案，它就没必要、也不太容易去凭空捏造一个完全不一样的版本。

我在实际项目里对这个效果特别有感触。一套证券行业的知识库问答系统，刚上线时没有接RAG，直接问大模型某个产品准入条件，它答得有理有据但全是错的。接上RAG之后，同样的问题，模型会把检索到的原文条款逐条对照着回答，答案里甚至带上了原文出处。用户不再质疑准确性，而是直接问能不能把来源链接也展示出来。

1.3 RAG不是消除幻觉，是给幻觉画边界

这里要说一个很重要的认知：RAG并不能100%消除幻觉。它更准确的作用，是把幻觉限制在一个可控的知识边界之内。

所谓知识边界，就是“模型知道自己在回答什么范围的问题”。接上RAG之后，优秀的表现不是模型什么都知道，而是模型能区分“资料里有的”和“资料里没有的”。对资料里有的内容，它给出有依据的答案；对资料里没有的内容，它敢于直接说“未找到相关信息”，而不是强行编造。

这个边界感本身就是一种极有价值的治理。对一个企业知识库来说，最可怕的不是模型说“我不知道”，而是模型用毫无破绽的语气输出一个错误结论。RAG能把后者转化成前者，就已经让系统可用性提升了一大截。

当然，RAG也有自己的适用边界。开放域闲聊、天马行空的创意写作、需要大量隐含知识的复杂推理，这类场景RAG帮不上什么忙，反而是纯大模型更合适。RAG真正擅长的是私有知识密集、答案可追溯、内容需要实时更新的场景，比如制度问答、产品手册、合同审阅、技术文档检索，这一块是目前企业落地大模型最成熟的路径。

2. 落地一套知识库RAG需要做的关键决策

2.1 知识库预处理：文档到“干净块”的必修课

把一堆PDF、Word、网页直接丢进去做向量化是不行的，这是新手最容易踩的第一个大坑。知识库预处理的质量，决定了后面检索质量的上限，几乎所有后续问题都能追溯到这一步的不规范。

第一步是格式解析与清洗。PDF要考虑扫描件OCR，Word要考虑表格和样式，网页要去掉导航、页脚、广告这类噪声。实际项目中最痛苦的是PDF里的表格，直接解析出来经常是乱序的，如果强行切块，语义就会碎成一地。我的做法是：表格数据单独走结构化解析，转成每个单元格带字段名和上下文的文本描述，而不是把它当普通文档流处理。

第二步是分块策略。这个环节没有标准答案，只有基于内容结构反复试出来的最优解。我常用的几套方案如下。

按文档结构分块。如果文档本身有清晰层级（比如制度文件、产品手册的章节结构），按标题树进行语义分块远比按固定长度切块好。模型能在块内看到完整章节逻辑，检索结果也不会被拦腰截断。

固定长度分块加重叠。对于没有明显结构的说明文、FAQ文本，通常会按固定tokens长度切分，典型值是256或512个tokens，并设置10%到20%的重叠。重叠的意义是尽量避免一个完整语义单元恰好被切到两个块里。

块大小直接影响召回质量。块太小，单个块包含的信息不完整，模型拿到手也答不出什么；块太大，块里噪声多、有效信息密度低，检索相似度会被无关内容稀释。我踩过的一个典型问题是业务规则类文档用512 tokens分块，检索出来的块经常同时包含十几个不相干的规定，模型根本不知道该用哪一条。后来改成按条款块切分，并给每条规则加业务标签，问题立刻消失。

第三步是元数据设计。每个向量块都必须绑定来源文档、页码、章节路径、业务分类、更新时间这些元数据。它不只是用于展示来源，更重要的是支撑后续的过滤、路由和权限控制。举个例子，一个知识库里既有产品手册又有内部培训材料，培训材料是不能对客户开放的，如果没有元数据做过滤，检索出来就是事故。

2.2 向量化与索引选型：嵌入模型和存储不能拍脑袋

分好块之后，就是把文本变成向量。嵌入模型的选择对检索效果影响极大。选型时首先要区分通用嵌入模型和领域微调的嵌入模型。通用模型在一般语义理解上表现不错，但遇到专业术语密集、表达方式和日常口语差异大的内容（比如法律文书、医学病历、工程规范），相似度计算往往会偏掉。

在有预算的情况下，我建议用领域内真实的问答对去微调或者至少评测两个候选嵌入模型。做法很简单：准备100到200条带标准答案的测试问题，分别用两个模型计算检索命中率，哪个高就用哪个，不靠感觉选型。如果预算实在有限，至少也要用一套有代表性的领域句子去跑相似度排序，观察人工判断的自然类目是否排在前面。

向量存储方面，市面上可选的方案很多，有专门的向量数据库，也有普通关系数据库加向量插件。底层差别主要在索引算法和部署复杂度。HNSW是目前最主流的索引算法，它有几个关键参数需要调：M值控制每个节点的连接数，M越大，召回率越高，内存和写入成本也越高；efConstruction控制建索引时的动态列表长度，值越大索引质量越好但建库越慢；查询时的ef参数则控制搜索深度，ef越高召回越高，延迟也越高。

在实际项目里，我一般会先用默认参数跑通，然后观察召回率和延迟的平衡点。对于百万量级的向量库，HNSW的M设为16、efConstruction设为100、查询ef设为64是比较稳妥的起点，然后再根据实际数据分布微调。

特别要提醒一点：不要只做向量索引。精确的词匹配能力在大模型场景里被严重低估了。产品型号、报错代码、人名这类高度精确的实体，用向量检索往往匹配不上，因为语义相似的向量可能完全不是同一个字符串。最稳妥的做法是混合检索：稀疏索引（BM25）负责精确词命中，稠密向量索引负责语义相似召回，两者结果做融合后统一进入重排序。这个组合在绝大多数垂直场景下都明显优于单独用任何一边。

2.3 检索参数的实际调优经验：top_k和重排序不是小事

检索流程里有两个参数对最终答案质量影响最大：召回数量（top_k）和是否做重排序。

先说说top_k。很多人以为top_k越大模型看到的信息越多，答案越准，其实不是。检索结果是有噪声的，召回越多，混入的不相关块也越多。把这些噪声全部塞进上下文，模型会被带偏，甚至会基于错误块编出新幻觉。合适的做法是分阶段设定：向量检索阶段先召回一个较大的候选集，比如50条，保证召回率；然后经过重排序，只取前3到5条进入大模型上下文。

重排序是整个RAG链路里性价比最高的一步。向量检索本质上是在高维空间里做“近似”查找，它速度快但精度有限。重排序则用更精细的模型对候选结果重新打分，目前效果最好的是一类叫交叉编码器的模型，它能把问题和文档块拼接在一起做深度语义交互，打分能力远超双塔结构的向量模型。当然它的缺点是慢，所以只能用于候选集精排，没法直接对全库做。

我实测过一组数据：不做重排序时，业务知识库的首答准确率大约在78%左右；加入交叉编码器重排序后，同样的测试题提升到了90%以上。差别非常直观。

重排序之外，还可以设置一个相似度阈值来过滤掉明显不相关的检索结果。典型的做法是计算每个候选结果的得分，与阈值比较后舍弃低分项。阈值不能一刀切，不同领域可以根据测试集反复试，我的经验是宁可让答案变成“未找到”，也不要硬拉一个不相关的块进去凑数。

2.4 提示词设计：把“知识边界”显式写进指令里

检索做得再好，如果提示词设计得稀烂，前面的功夫会全部白费。提示词是模型和检索结果之间的连接器，它的核心目标有两个：第一，让模型只依据给定的资料回答；第二，让模型在资料不足时明确承认不足。

我给知识库问答系统设计的提示词模板，核心结构大致是这样的：

你是一名企业内部知识库问答助手。请严格依据以下资料回答用户问题。 规则： 1. 只允许使用资料中出现的信息，禁止使用外部记忆或常识补全。 2. 如果资料中没有相关内容，请直接回答“未在知识库中找到相关信息”，不要编造。 3. 回答时需在每条结论的末尾标注来源编号，格式【编号】。 4. 当资料之间存在矛盾时，指出矛盾并列出各方观点，不要自行调和。 资料如下： 【1】文档A第12页 部分内容... 【2】文档B第3页 部分内容... 用户问题：...

这套模板看似简单，但“禁止使用外部记忆”和“标注来源编号”这两条规则，对模型行为的影响是决定性的。前者在系统层面明确压制了幻觉的生成倾向，后者则给答案的可追溯性提供了机制保障。

我还习惯在每个检索块前面加上来源信息作为块内容的一部分，比如“来自《XX制度》第三章第2节”。这样即使模型引用内容，它也能自然地在答案中提到出处。很多项目把来源做成“事后通过元数据映射”，效果远不如直接在提示词里给模型原文标注来源来得自然。

3. 走向精准的三个进阶动作

3.1 让检索更聪明：自查询和元数据过滤

基础RAG的检索方式是把用户问题原封不动地向量化，然后去全库扫一遍。这在知识库还小的时候问题不大，但一旦库里有几十万条文档、不同业务模块混杂在一起，单纯的语义检索会召回大量不相关的板块。

举个例子，用户问“2024年上半年的设备故障处理方案”，如果直接向量检索全库，很可能把2023年的类似方案、其他设备的故障处理全拉出来，噪声非常大。这时候就需要自查询模式：先让模型从自然语言问题里解析出结构化过滤条件，比如时间范围、业务分类、文档类型，然后带着这些过滤条件去执行检索。

实现方式并不复杂。可以让大模型在检索前先做一次分类或信息抽取，输出一个检索意图的JSON结构，再根据这个结构拼接查询条件。我自己常用的做法是维护一个业务标签体系，让模型先判断问题属于哪个标签，再用标签去向量库里过滤。这样检索范围一下子缩小了一个数量级，答案稳定性和检索性能都明显提升。

另一个非常实用但经常被忽略的设计是权限过滤。企业知识库往往既有公开制度，又有部门内部资料。检索层必须结合用户的身份属性，在查询阶段就过滤掉无权访问的内容，而不是等检索完再靠上层权限去遮盖。否则模型读到了无权的资料，就算不输出原文，也很容易通过暗示泄露信息。

3.2 引用溯源：可验证的答案才值得被信任

RAG系统的体验差异，很多时候不是看答案对不对，而是看答案能不能被验证。一个只输出结论、不提供依据的RAG系统，本质上和闭卷考试没有区别；而一个答案后面跟着“来源文档第几页第几条”的系统，用户的信任感会完全不同。

引用溯源的做法首先是在提示词层面要求模型在每条结论后标注来源编号，其次是前端页面把来源链接和原文片段展示出来。用户点开来源，自己就能核对答案是否忠于原文。这个机制让答案质量接受公开检验，模型也不得不更收敛地生成内容。

在实际系统里，我还会做一层引用校验：答案里出现的每个来源编号，必须对应本次检索真正返回的块。如果模型引用了检索结果之外的编号，说明它开始编造引用了，需要立即标记为低置信度答案。这个校验逻辑不用多复杂，一个简单的映射表就能实现，但对护栏的作用很大。

还有一个细节值得提：当检索结果之间有矛盾时，不要试图让模型强行选择一个正确答案。更稳妥的设计是让模型在答案中并列呈现多个观点，并明确标注来源。这种“展示矛盾”的能力在合同审查和制度对比场景里尤其有价值，用户需要看到的是不同部门的规则差异，而不是一个被模型擅自抹平的伪造一致。

3.3 评估驱动迭代：用数据监控RAG质量，而不是靠感觉

RAG系统上线之后，最忌讳的事情就是“感觉还行”。大模型生成的问题在于每次回答都有随机性，人工抽查几十条根本看不出真实的质量分布。要让系统持续变准，必须建立一套可复用的评估机制。

评估分成两个维度：检索质量评估和生成质量评估。

检索质量评估主要看三件事：

• 命中率：测试问题对应的标准答案块是否出现在检索结果的前N名里，它反映的是召回能力。
• 平均倒数排名：第一个正确结果的排序位置越靠前越好，它反映的是排序精度。
• 归一化折损累计增益：考虑到多正确答案场景的排序质量。

生成质量评估更复杂一些，行业里常用的框架会围绕忠实度、答案相关性和上下文相关性三个指标展开。

忠实度衡量的是模型答案是否忠于检索到的资料，有没有跑出去编造。这是最关键的指标，直接对应“幻觉”问题。答案相关性衡量的是生成内容是否解决了用户问题，有没有答非所问。上下文相关性衡量的则是检索到的块本身是否和问题相关，如果检索出来的都是不相关信息，生成阶段再怎么努力都是白搭。

我的测试集建设经验是：找业务方一起标注80到150条具有代表性的问答对，覆盖高频问题、疑难问题、易混淆问题和缺料问题四类，并给每个问题标注标准答案对应的文档块和正确回答要点。任何一次模型版本升级、嵌入模型替换或者分块策略改动，都先把这套测试集完整跑一遍，对比新旧版本的指标变化。

上线后的线上监控同样重要。每次对话结束后记录用户是否满意、是否点击了参考答案中的引用链接、是否有“未找到”但实际存在的答案。这些信号最终汇总成一份质量日报，能帮你快速定位是知识库更新滞后、还是检索排名出现了偏移。

4. 实操问题排查与避坑记录

4.1 检索到了正确答案，模型还是答错了怎么办

这个现象在RAG项目里非常常见，也是最容易让人困惑的。检索结果明明包含了正确答案块，重排序也把它排在了前面，但模型最终输出的答案还是偏了。

排查步骤我建议按这个顺序来。

先确认正确答案块是否进入了最终上下文。很多情况下是提示词里拼接的上下文过长，正确答案块虽然在前50名候选里，但重排序阶段模型给它的分不够高，被挤出了最终前5名的名单。这种情况要回头调重排序模型或增大最终上下文中的块数量。

再检查提示词里资料的呈现顺序。大模型对长上下文的关注度并不均匀，开头和结尾的内容更容易被注意，中间内容容易淹没。如果正确答案块恰好在中间位置，模型可能就把它忽略掉了。我解决这个问题的方法是调整上下文拼接顺序，把重排序得分最高的块放在最前面，并在提示词里显式要求模型优先考虑前部资料。

还有一个容易被忽视的问题是问题改写。用户原始问法可能和知识库里的表达方式差异很大，比如用户问“这个产品支不支持蓝牙”，文档里写的是“具备蓝牙通信模块”。向量检索对这种同义改写还算容忍，但嵌入模型对短句的理解其实非常有限。遇到这个问题，可以在检索前让大模型把用户问题改写成一个更规范的查询语句或假设性答案，再用改写后的语句去检索，效果往往会好很多。

4.2 接上RAG之后模型反而变笨了

有些团队接上RAG之后发现，模型回答简单问题的水平下降了，本来能答的常识题也开始答错。这不是模型变笨了，而是检索注入的上下文污染了答案。

最常见的污染源是检索出来一堆不相关但语义略有关联的块。模型看到这些块，会倾向于把它们当作事实依据，哪怕这些块和问题实际没多大关系。解决这个问题可以从三个方向入手。

一是提高检索质量，先过滤掉明显低分的块。二是设置硬性阈值，如果所有候选块的相似度都低于某个值，直接放弃检索结果，让模型走无资料模式。三是引入“无答案”通道，在提示词里明确要求资料不足时输出“未找到”，避免模型硬着头皮从废料里凑答案。

我还见过一个更隐蔽的问题：知识库里混入了大量低质量文本。某个企业内部知识库收录了各种来路不明的抓取资料，其中不少内容和正式制度互相矛盾。这种情况不是靠提示词能解决的，必须回到知识源治理，建立明确的知识审核流程，把不可信来源的内容标记为低优先级或者直接清除。

4.3 知识库更新了，模型回答没跟着变

这个问题通常发生在新版本文件替换旧版本之后。用户在系统里看到新文件已经上传，但问问题得到的还是旧版本答案。

排查时先看索引状态。很多系统的索引是异步更新的，文件上传成功不代表向量索引已经刷新，中间可能延迟几分钟甚至更久。如果索引更新逻辑本身没问题，那就要看重排序模型是否考虑到了新文件，有些重排序服务有缓存，短时间内的重复检索会命中缓存结果。

另一个需要留意的是版本管理策略。不要物理删除旧文档然后覆盖新文档，更好的做法是给每个知识块绑定版本号和生效时间，查询时按当前时间过滤生效范围内的版本。这样即使新旧版本共存，检索也只会命中当时有效的那一版。这个设计在制度类知识库里尤其重要，因为制度文件经常有修订、废止状态，单纯按时间上传来判断非常容易出错。

我踩过的坑是这样的：某次上线了一批新制度，但测试时旧版答案一直出现，后来发现原因是旧版文件保留在文档库里没有被标记废止，向量检索仍然能召回它，并且因为新旧内容相似度极高，重排序模型甚至更偏好旧版块。后来引入了版本状态标签和过滤逻辑，才彻底解决。

4.4 成本与性能的平衡怎么把握

RAG系统上线后，成本大头通常在两个环节：向量化与重排序。

向量化成本发生在文档入库阶段，是一次性的。对于一个大中型知识库，几百万个块的向量化可能要跑上几个小时，解决办法是做并行分批处理，并把嵌入模型部署在GPU上。如果预算紧张，可以在非高峰时段跑。

重排序成本则是每次问答都会发生的，而且是实时的。交叉编码器模型推理速度慢，高并发下很容易变成性能瓶颈。我做过的性能优化主要有三个方向：

• 缩小重排序候选集：向量检索阶段召回50条，重排序阶段可以先用粗粒度方法过滤到15到20条，再交给交叉编码器精排。减少精排数量能显著降延迟。
• 结果缓存：对常见问题建立语义缓存，当用户问题与缓存问题的向量相似度超过阈值时直接复用历史答案。语义缓存比普通文本缓存的命中率高得多，因为用户每次问话措辞都可能不一样。
• 分级加载：把高频知识块的索引常驻内存，低频块走磁盘索引。这个优化在冷热数据分布明显的场景下性价比很高。

延迟预算上，我一般建议整个问答链路控制在5秒以内，其中向量检索100毫秒到300毫秒，重排序300毫秒到1秒，大模型生成耗时通常是大头。如果总耗时超时，优先压缩检索候选集和重排序输入长度，而不是去换一个更贵的生成模型。

5. 从朴素RAG到GraphRAG和Agentic RAG的演进

5.1 朴素RAG的三段式缺陷

上面讲到的RAG实现方式，业内通常叫朴素RAG，它的核心缺陷在于检索单元是“孤立块”。这个机制本质上是把知识库当成一堆互不相干的碎片，查询时找到和问题最相似的几块，然后完事。

它的第一个缺陷是局部性。大量知识需要跨文档才能完整理解。比如问“某业务从申请到审批的全流程涉及哪些部门”，这个信息散落在管理制度、权限说明、流程规范三份文档里，朴素RAG可能分别找到三块，但模型把它们拼在一起时，往往搞不清先后顺序和依赖关系。

第二个缺陷是缺乏规划能力。一个复杂问题往往需要拆解成多个子问题，每个子问题通过不同检索路径获取信息，最后融合答案。朴素RAG只做一轮检索和生成，没有能力做这种多步推理。

第三个缺陷是忽略结构化关系。知识库里的实体之间往往有明显关系，比如“A部门负责审批B类型的申请”，这种关系在文本块里虽然存在，但向量检索并不能稳定地把握它。朴素RAG把文本当成bag of tokens来处理，结构化信息被浪费了。

这三个缺陷催生了两个主要的演进方向：GraphRAG和Agentic RAG。

5.2 GraphRAG：用知识图谱重塑大模型的知识组织方式

GraphRAG的核心思路是在文档入库阶段，先用大模型从文本中自动抽取实体和关系，构建成知识图谱，再结合图的结构化检索能力和文本向量的语义检索能力来回答问题。

具体落地会涉及一系列复杂流程。先做实体抽取，把文档中的人名、部门、产品、法规、流程节点等实体识别出来。再抽取关系，识别实体之间的语义关联，比如“某部门负责某环节”“某制度约束某流程”。然后做社区检测，把图谱中联系紧密的节点聚类成子社区，并为每个社区生成摘要。查询时，系统先判断问题更适合走纯文本检索还是图谱检索，并基于图谱执行多跳查询，穿越多个实体节点收集信息。

GraphRAG最擅长的是回答“跨实体、跨文档的关系型问题”。比如“哪些流程在某个部门审批后需要再经过某个委员会复核”，单纯靠向量检索很难回答，因为它需要把“流程-部门-委员会”之间的多跳关系串联起来。在构建好的图谱上跑一次图遍历，结果会清晰得多。

GraphRAG的代价也非常明显，建设成本高，一次完整流程耗时很长。实体抽取需要逐块跑大模型，一个几十万块的知识库光抽实体就非常费算力。所以我的建议是：先评估知识库类型。如果是制度、法规、流程等关系密集型知识，值得考虑GraphRAG；如果是松散的FAQ或产品手册，也许不需要为构建图谱付出额外成本。实践中还可以折中：只对关系最密集的那部分知识构建局部图谱，其余仍然用增强RAG文本检索。

5.3 Agentic RAG：让模型自己决定查什么、查几次

如果说GraphRAG改变的是知识的组织方式，Agentic RAG改变的则是检索的决策方式。朴素RAG的检索决策是单一的：不管什么问题，都按固定流程走一遍。Agentic RAG则把检索控制权交给模型本身，让模型根据问题动态决定调用什么工具、要不要改写查询、需要几轮检索。

实际设计里，一个基础的Agentic RAG系统会包含这样一些能力：

查询路由。系统收到问题后先判断属于哪个领域，是制度问答就走制度索引库，是产品参数就走产品手册索引库，是闲聊就直接进入无检索模式。路由分类可以由大模型或一个小分类器完成，这是降低检索污染最有效的手段之一。

查询改写。对于复杂问题，模型可以把原始问题改写成多个具体的子查询，分别检索后再合并答案。比如“我要给一个设备做维护，需要注意什么”，改写后的子查询可以是“设备维护前安全注意事项”“设备维护步骤”“设备维护后的检查项”，每个子查询独立检索，再融合生成。

多轮检索与自我校验。模型先生成一个草稿，再根据草稿缺失的信息发起第二轮检索补充，最后形成答案。这种模式能应对信息不足的情况，但也要防止无限循环。必须设定最大检索轮数和总token预算，超过预算就强制收敛。

Agentic RAG的效果上限确实高于朴素RAG，但它的风险和调试成本也更高。最大的风险是模型可能做出错误的工具调用，导致检索目标完全偏离。我在实践中的体会是：Agentic模式适合问题模式多样、无法用固定规则穷尽的开放型知识库；但如果是问题模式相对稳定的业务场景，用固定流水线加少量路由分支，调试成本和稳定性表现其实更好。

5.4 如何选择哪种RAG方案，卡点在哪里

很多人一上来就问我用什么RAG框架，我的回答通常是先回头盘点自己的知识库场景。

我用一个简单分类逻辑来评估：

如果知识库内容本身就是独立的问题与答案对，比如常见问题集，朴素RAG加上好的分块与重排序已经能达到一个很高的水平上限，不需要复杂演进。

如果知识库是成体系的制度、法规、标准，且问题经常涉及条款之间的关联，那优先考虑增强RAG与GraphRAG的结合，为体系化程度最高的几块知识构建图谱。

如果用户问题复杂多变，需要多轮推理和信息融合，且团队有足够的模型调试能力，可以尝试Agentic RAG，但第一步还是先把基础的检索质量打牢。

这里有个容易被忽略的点：RAG的效果天花板往往不在模型环节，而在知识组织环节。同样的问题，在高质量的元数据体系和分块策略下，朴素RAG就能答得很好；反之，知识源一团糟，上多高级的RAG变体也只是用一个更贵的方案把垃圾检索出来。

6. 最后说几句实在话

做一个RAG系统，最大的感受就是：大模型的幻觉问题，不能指望靠模型自己解决，也不能指望靠一个框架解决，它本质上是工程治理问题。

我自己做过的几个知识库项目里，最有效的每一次质量提升，都发生在基础环节的优化上：把分块切得更符合文档语义、把元数据补得更完整、把重排序候选集调得更合理。相反，模型从更大版本换到更新版本，或者把一个成熟方案替换成更花哨的框架，带来的提升反而不明显。

所以如果你正在规划一个新的RAG项目，我的建议是先花70%的精力做知识治理和检索质量，剩下30%再考虑模型选型和花样架构。上线前一定要建一套固定的评测集，哪怕只有五十个问题，每次改动都跑一遍，用数据说话，不然你很容易被一两次偶然的“感觉变好”欺骗。

最后再分享一个操作上的小技巧：在检索结果的每个块前面加上业务标签和来源路径，别嫌麻烦。等你被用户追问“这个答案的依据是什么”的时候，就知道这个设计值多少钱了。