1. 先搞明白RAG 到底解决了什么问题1.1 为什么大模型聪明但“健忘”做企业级 AI 应用的人迟早会撞上一堵墙大模型再厉害它知道的也只是训练数据截止那一天之前的世界。我见过太多项目在这个点上翻车。业务方兴致勃勃地接入大模型结果一问到企业内部制度、最新产品参数、上季度的销售数据模型就开始一本正经地胡说八道。不是模型不行是它压根没有这些信息。打个比方你请了一位学识渊博的顾问但他手里没有你们公司的档案你问他公司报销流程他只能凭经验猜一个大概猜错了也不算意外。RAGRetrieval-Augmented Generation检索增强生成解决的就是这个问题。它的思路很朴素模型不知道没关系我们先把相关知识从企业文档库里捞出来塞给模型看再让它基于这些资料回答问题。相当于给那位顾问配了一个专属资料员每次开口前先递上相关卷宗让他照着卷宗说话。这也是 RAG 能成为企业知识库问答主流方案的根本原因。它不需要重新训练模型不需要昂贵的算力投入只需要把企业现有的文档管理好、检索好就能让大模型“长出”企业专属的知识边界。对于绝大多数企业来说这是性价比最高的私有化知识服务落地路径。1.2 RAG 和微调为什么不是二选一很多人刚接触 RAG 时都会问那为什么不直接微调一个模型这个问题很关键想清楚了你才算真正理解 RAG 的定位。微调是改变模型本身的参数让模型“记住”新的知识。听起来很美好但它有几个天然短板。第一是成本每次知识更新都要重新训练训练一次少则几千、多则几万的成本知识每月一变企业扛不住。第二是污染把零散的业务知识混进模型参数里模型可能记住了新知识却把原来的通用能力“冲淡”了这种现象叫灾难性遗忘实际调过的团队都懂。第三是时效今天新增一份制度文件今天就想让模型知道微调的产出周期根本跟不上。RAG 没有这些问题。文档更新了重新走一遍索引就行分钟级别生效。它更像是给模型外挂了一个实时更新的知识库模型本身的参数一动不动。所以在企业场景里RAG 通常作为默认首选微调一般留给特定领域的语言风格适配、输出格式约束这类更底层的需求。两者也常常配合使用先微调让模型具备领域语言习惯再用 RAG 拉取实时业务知识这属于进阶玩法后文会展开。2. RAG 核心链路拆解从文档到回答的三段式2.1 索引阶段把企业文档变成机器能读的“字典”RAG 的第一步是把散落的 Word、PDF、Excel、网页等文档处理成一个可供快速检索的“字典”。这个阶段如果做不好后面检索和生成全是空中楼阁。索引阶段的关键动作有三个解析、切分、向量化。解析是把 PDF 里的文字、表格、图片里的内容提取出来。看着简单做起来全是坑。扫描版 PDF 需要 OCR表格提取经常乱序多栏排版的论文会把阅读顺序搞乱。我的经验是解析阶段起码要留出整个项目 30% 的时间宁可在这里磨刀也不要急着往后跑流程。切分是把长文档切成一段一段的“块”chunk。这个环节最考验经验切大了一块里塞了太多主题检索时噪音大模型容易抓到无关信息切小了语义不完整模型只看到半句话答不出所以然。常用的策略包括按固定字符数切分、按段落切分、按语义边界切分每种各有适用场景。固定字符数最简单但对中文来说500 字左右是一个比较好用的起点配合 10% 到 20% 的重叠率能有效避免语义在边界处被拦腰截断。结构化文档按章节层级切分效果更好因为本来就有天然的语义边界。向量化是把文本块转换成一组数字向量。这里有个朴素的直觉语义相近的文本在向量空间里距离也近。比如“怎么请假”和“休假申请流程”说的不是同一句话但向量距离会很近。这一步依赖嵌入模型Embedding Model目前主流的开源选择有 BGE、M3E、通义文本向量等商用闭源的有 OpenAI 的 text-embedding-3 系列。选型时注意两点一是看中文效果直接用英文榜单排名选模型容易踩坑二是向量维度维度越高表达能力越强但存储和计算成本也越高需要平衡。2.2 检索阶段向量搜索里藏着哪些门道索引建好之后用户提问进来系统把问题也变成向量然后在知识库里找出最相似的 Top-K 个文本块。这个“相似”的度量方式最常见的是余弦相似度和内积。但实际项目里单纯靠向量搜索远远不够。向量搜索擅长捕捉语义相似却不擅长精确匹配。你问“员工编号 HR-2024-001 的入职日期”向量搜索可能在语义上找到一段相关文本但精确的编号匹配它就不太行了。所以成熟的 RAG 系统普遍采用混合检索Hybrid Search——向量搜索和关键词搜索比如 BM25的结果做融合再一起交给重排模型。这里必须提一下重排序Rerank。召回阶段为了不遗漏通常会多召回一些比如 Top 50但模型上下文窗口有限不能全塞进去。重排序就是用专门的 Rerank 模型对召回结果重新打分挑出最相关的 Top 5 或 Top 10。这一步对回答质量的提升是肉眼可见的很多团队把 Rerank 模型加入流程后回答准确率直接上了一个台阶。光有 Embedding 没有 Rerank就像筛选简历只看了学校名字没有细看项目经历错配率自然高。Dense Vector Search 只是检索体系里的一环完整的关键词、稀疏向量、稠密向量、Rerank 的组合方式才是 RAG 检索质量的分水岭。你在面试里被问到 RAG 检索流程怎么设计能把这个组合链路讲明白基本就过关了。2.3 生成阶段让模型“拿着资料说话”检索出相关内容后还要做一道“组装”工序把用户的问题和检索到的文本块按一定格式拼接成 Prompt交给大模型生成回答。这一步听起来简单实际上对回答质量的影响不亚于检索。Prompt 的组装里有几个要点。第一是明确指令你要告诉模型“只依据提供的资料回答资料中没有的信息不要编造直接说不知道”。第二是对检索内容的呈现格式做处理让模型能区分哪句是用户的问题、哪句是参考资料通常用清晰的标记分隔。第三是控制上下文长度塞进去太多文本块模型容易迷失重点而且推理成本也跟着涨。生成阶段还有一个容易被忽视的细节引用来源。企业场景里AI 给出的答案如果无法追溯到原始文档业务方是不敢直接采信的。好的 RAG 系统会让模型在回答时标注参考来源用户点一下就能跳回原始文档确认。这不仅是产品体验问题更是信任问题。3. 从基础 RAG 到 Agentic RAG技术演进路径3.1 基础 RAG 的痛点在哪里你把上面三段式流程搭起来了跑通了 Demo业务方试用后问了几个问题你很快就发现不对劲。第一个痛点是“一步检索定生死”。用户的问题先检索一次结果不好就完了模型只能基于这些错的内容硬着头皮回答。真实场景中用户很少会一次把问题问清楚更多是“我要做市场活动预算但是不知道公司对礼品采购金额有规定吗”这种口语化、意图混杂的表达一次检索很难命中。第二个痛点是多跳问题不会处理。用户问“公司今年新入职员工的电脑配置标准是什么”这个问题分解开来是两步先找出今年新入职员工适用的制度版本再找电脑配置章节。基础 RAG 没有这种多步推理能力只能一把抓。第三个痛点是缺乏工具调用能力。如果用户的问题是“我们部门上季度的报销总额是多少”知识库里根本不会有现成的数字正确路径是去数据库查。但基础 RAG 不会查库它只能告诉你报销流程是什么。3.2 模块化 RAG重写、路由、融合检索为了应对上述痛点社区里演化出了模块化 RAG 的思路。它的核心思想是把基础 RAG 的固定管道拆成可编排的模块在中间插入各种处理逻辑。比较常见的模块包括查询改写Query Rewriting、查询路由Query Routing、检索优化等。查询改写解决的是“用户不会问问题”的痛点。原问题可能包含指代、口语表达、冗余信息模块先对问题做改写再拿改写后的版本去检索。比如用户问“它的报销标准是多少”改写模块先判断“它”指代的是“部门团建”然后生成更清晰的检索词。原来是用户迁就检索现在让检索去理解用户。查询路由解决的是“一个问题多类数据源”的问题。用户问“我们产品的市场占有率”知识库是文档数据库是结构化数据路由模块判断这个问题的答案需要从数据库取把请求转到 SQL 查询链路而不是向量检索链路。融合检索在前面提过把向量检索和关键词检索的结果做加权融合可以在语义匹配和精确匹配之间取得平衡。模块化 RAG 的框架下这些模块可以自由组合按业务需求编排这也是 RAG 项目逐渐从“一条管道”变成“一个灵活的检索系统”的过程。3.3 Agentic RAG把检索变成决策Agentic RAG 是最近被讨论最多的方向热搜词里的“agentic rag”指的就是它。理解它之前先看一个传统 RAG 回答不了的问题用户问“对比一下我们公司和 A 公司过去三年的营收增长并给出分析结论”。这种问题需要检索公司财务文档、可能需要查库获取营收数字、需要计算增长率、需要生成分析结论中间还可能要来回修正检索策略。传统 RAG 一次检索就给出答案根本撑不起这个流程。Agentic RAG 的思路是把大模型当作一个“决策者”Agent由它自己规划完成任务需要哪些步骤每一步调用什么工具去哪里检索检索结果不满意就换个关键词再检索甚至调用计算工具做数值分析然后综合所有信息给出答案。打个比方传统 RAG 是给顾问配了一个资料员Agentic RAG 是给顾问配了一个助理团队助理自己决定去哪个档案室、查哪个文件、叫谁来做数据分析最终汇总成报告交给顾问。我这里要提醒一句Agentic RAG 虽热但复杂度也成倍上升。检索链条越深出错的概率越大一个环节查错后续全错而且每次 Agent 决策都在消耗模型调用成本。实践中的建议是能用基础 RAG 解决的场景不要上 Agent只有当真需要多步推理、多工具协作时才考虑引入 Agent 能力。先跑通基线再用 Agentic 优化别一上来就整花活。4. 一次完整的 RAG 项目落地实战4.1 工具选型Dify、LlamaIndex还是自己写做 RAG 项目首先要回答一个现实问题用现成框架还是从头搭如果你想快速验证业务价值或者团队没有太多 AI 工程经验Dify 这类平台是非常好的起点。它封装好了文档解析、切分、向量化、检索、Prompt 编排的完整链路你只需要上传文档、配置参数、发布应用几小时就能跑通一个知识库问答机器人。我见过不少政务、企业知识库项目是基于 Dify 搭建的尤其是非技术团队用可视化编排就能维护整个系统。Dify 社区版本功能已经很完整支持知识库多分库、混合检索、Rerank 接入对小团队来说非常友好。如果你要做的系统对检索链路有深度定制需求比如复杂混合检索、多路召回、自定义重排逻辑LlamaIndex 是更合适的底座。它是一个 Python 框架灵活性极高从数据加载器、切分策略、向量存储到检索器每个环节都能自定义。代价是你得自己组装、自己调试对工程能力有要求。LangChain 也可以做但我的体感是 LangChain 更适合做 Agent 相关的编排纯 RAG 链路里它的抽象层较厚排查问题的时候有一层又一层包装容易晕。当然这个属于个人偏好如果你团队已经熟 LangChain用起来也不差。还有一个选择是刚发布的 LlamaIndex 搭配自家向量库或者用 Milvus、Weaviate、Qdrant、Elasticsearch 做存储层每个组件单独选型适合对性能要求很高的大规模项目。工具选型的判断标准就一句话团队的工程能力和项目的定制深度要匹配。资源少就站在巨人肩膀上别为了炫技从头造轮子。4.2 数据准备与切分策略数据是 RAG 的命根子。这一步偷懒后面所有环节都是在垃圾堆上盖房子。第一步做数据盘点。别急着上传所有文档先看你的知识库里有哪几类数据制度规范类结构清晰、长文本、条款化、流程操作类步骤多、有顺序逻辑、FAQ 类问题对短文本、表格类强结构、需要特殊解析。不同类型的文档切分策略完全不同。制度规范类适合按章节层级切分每一章、每一节作为独立语义块保留标题层级信息。我在项目里会把标题作为元数据存进去检索时优先匹配标题命中率会明显提升。流程操作类要注意顺序问题。切分时不能把完整步骤拆散否则模型可能只看到第 2 步和第 4 步答出来的流程是断的。这种情况建议按步骤块整体切分宁可块大一点也不要破坏步骤的完整性。表格类是最容易翻车的。直接把 PDF 里的表格转成文本再切分原来的行列关系全丢了模型看到的是一团乱字。正确做法是单独做表格解析把表格转成 Markdown 格式或者按行转成结构化描述再决定是单独存储还是并入上下文。FAQ 类最简单一条问题对应一条答案可以直接作为一个整体块。切分时记得把问题和答案拼接在一起检索时命中问题就能带回答案。4.3 RAG 测评怎么做指标和方法很多人把 RAG 系统搭起来就急着上线结果被业务方问“回答准确率是多少”的时候拿不出一个数据。RAG 测评是项目能否交付的关键一环但也是很多文章讲得最少的一环。RAG 的测评拆成两层来看。第一层是检索质量第二层是生成质量。检索质量最核心的指标是召回率Recall和命中率Hit Rate。召回率回答的是“正确的那份文档是否在召回结果里”命中率回答的是“Top-K 结果里是否有正确答案”。测法不复杂准备一批测试问题每个问题标注出正确的文档或答案片段然后用系统去检索看正确结果有没有出现在 Top-K 里。不需要太数学化的公式业务方关心的是“50 个问题里正确答案被捞出来的有多少个”生成质量指标相对主观一些但也能量化。三个维度就够了准确性生成的回答是否与参考文档一致、完整性是否漏掉了关键点、忠实度是否出现了文档里没有的信息也就是幻觉程度。测评方式可以让人工打分也可以让大模型当裁判来打分后者叫 LLM-as-a-Judge。用大模型评测时最好几个模型交叉打分避免单一模型自带偏好。回答质量评估与 RAG 试验测试场景检索命中率生成准确率幻觉率优化动作基线纯向量检索68%61%22%无加入混合检索82%74%15%引入 BM25 融合再加入 Rerank91%86%9%接入 Rerank 模型优化切分策略93%90%6%按章节切分元数据这个表格是我在一个企业制度问答项目里的真实提测数据能直观看到每个环节对最终质量的影响。回到评测目标RAG 评测做出来的不是一张好看的报表而是告诉你下一个环节该优化哪里。一次全链路跑完分别测检索和生成的指标你就能精准定位是“没找到”还是“找到了没用对”这比拍脑袋猜问题要靠谱得多。5. 常见问题与排查技巧实录5.1 检索质量差问题出在哪检索结果不准是 RAG 项目里最常遇到的问题。每次排查我建议按下面这个顺序一层层看。先看数据再看检索最后看排序。数据层面最常见的问题是文档切分不合理。切分太碎语义被拆散切分太整多个主题混在一个块里。你可以把几个典型问题的检索结果打印出来肉眼看看召回的文本块到底是什么基本就能判断是不是切分的问题。这个方法土但有效。检索层面先确认 Embedding 模型选得对不对。中文场景用英文优化的模型效果不会好。再确认是否启用了混合检索如果你的系统只用了纯向量搜索碰到编号、型号、精确名称类的问题召回率上不去是必然的。排序层面大概率是没接 Rerank。没接 Rerank 的系统Top-5 结果里可能只有 1 个是真正相关的。接上之后好的 Rerank 模型能把相关结果顶到前排这个改善是立竿见影的。5.2 幻觉率居高不下怎么办模型生成了知识库里根本没有的内容这个是 RAG 最让业务方头疼的问题。排查思路这么展开。第一看 Prompt 约束有没有到位。有些团队的 Prompt 里压根没写“只能依据提供的资料回答”这句话模型自由发挥的空间很大。先把这个约束加上用词要强硬“如果资料中没有答案请明确回答不知道不要臆测或编造。”这个改动就能解决一部分幻觉问题。第二看检索到的资料质量。如果检回来的 Top-K 块本身包含不相关内容模型会很自然地被带偏。低相关度的文本对模型来说是噪音甚至是误导。办法有两个一是提高相关性阈值低于阈值的直接不返回给模型二是减少返回条数只给最精准的两三条让模型聚焦。第三看输出方式。复杂问题上让模型先列出找到的依据再基于依据作答比让它直接给出答案要稳得多。相当于让模型“先翻译后回答”强制它把思考路径和对资料的依赖关系显式化幻觉空间被大幅压缩。5.3 几个容易踩的坑文档更新后没有重建索引也没有做增量更新导致系统回答的还是旧版本内容。凡是知识库系统一定要考虑文档版本管理和索引更新机制否则时间一长库里的新旧信息混杂答案精度断崖式下滑。把所有文档一股脑塞进去不区分业务领域导致检索时不同领域的内容互相干扰。建议按业务域分库或分集合检索时先明确在哪个库里找可以显著提升精确度。忽略了权限控制。很多企业内部知识库是有阅读权限区分的但 RAG 系统的检索层不会自动感知权限一个普通员工可能通过提问检索到只对管理层开放的文档内容。这块在架构设计阶段就要考虑进去常见方案是按权限域做隔离索引。上线后不做监控。RAG 系统的坏会坏得很隐蔽它不是崩溃是慢慢变笨。一个文档被错误上传一个切分规则被调坏没有人会发现但用户会逐渐流失。我现在的习惯是给系统搭建一个简单的问题日志面板每天记录用户的提问、系统的回答和检索来源隔几天扫一眼能发现很多潜在问题。6. 聊聊我对 RAG 的一点实战体会做了这么多 RAG 项目最大的感受是RAG 看起来简单做精了很难。它不像大模型训练那样需要前沿算法突破而是由无数个细节堆积起来的系统工程。数据质量、切分策略、检索方式、排序模型、Prompt 设计、评测体系每个环节都只能及格综合效果才会及格任何一环掉链子整个系统的体验就会被拖下水。对于刚入门的团队我给三个建议。第一先用 Dify 跑通端到端流程亲眼看到 RAG 的长板和短板再决定要不要深入底层定制。第二无论用什么框架先把评测体系搭起来哪怕只是 50 条测试问题的人工标注它也能成为你后续所有优化的标尺。第三从基础 RAG 开始跑稳了再叠加 Rerank、混合检索、查询路由这些增强能力最后才考虑 Agentic RAG步子迈太大容易扯着。最后再分享一个小技巧RAG 系统里提问引导界面比想象中重要。用户提出的问题质量直接决定检索结果的上限。做一个“猜你想问”的推荐列表或者在输入框里给几个示例问题都能明显提升用户的提问质量最终反馈在回答准确率上。这个细节几乎不出现在技术文档里但实际效果很好值得一试。
从RAG到Agentic RAG：企业知识库问答的检索增强生成实战指南
1. 先搞明白RAG 到底解决了什么问题1.1 为什么大模型聪明但“健忘”做企业级 AI 应用的人迟早会撞上一堵墙大模型再厉害它知道的也只是训练数据截止那一天之前的世界。我见过太多项目在这个点上翻车。业务方兴致勃勃地接入大模型结果一问到企业内部制度、最新产品参数、上季度的销售数据模型就开始一本正经地胡说八道。不是模型不行是它压根没有这些信息。打个比方你请了一位学识渊博的顾问但他手里没有你们公司的档案你问他公司报销流程他只能凭经验猜一个大概猜错了也不算意外。RAGRetrieval-Augmented Generation检索增强生成解决的就是这个问题。它的思路很朴素模型不知道没关系我们先把相关知识从企业文档库里捞出来塞给模型看再让它基于这些资料回答问题。相当于给那位顾问配了一个专属资料员每次开口前先递上相关卷宗让他照着卷宗说话。这也是 RAG 能成为企业知识库问答主流方案的根本原因。它不需要重新训练模型不需要昂贵的算力投入只需要把企业现有的文档管理好、检索好就能让大模型“长出”企业专属的知识边界。对于绝大多数企业来说这是性价比最高的私有化知识服务落地路径。1.2 RAG 和微调为什么不是二选一很多人刚接触 RAG 时都会问那为什么不直接微调一个模型这个问题很关键想清楚了你才算真正理解 RAG 的定位。微调是改变模型本身的参数让模型“记住”新的知识。听起来很美好但它有几个天然短板。第一是成本每次知识更新都要重新训练训练一次少则几千、多则几万的成本知识每月一变企业扛不住。第二是污染把零散的业务知识混进模型参数里模型可能记住了新知识却把原来的通用能力“冲淡”了这种现象叫灾难性遗忘实际调过的团队都懂。第三是时效今天新增一份制度文件今天就想让模型知道微调的产出周期根本跟不上。RAG 没有这些问题。文档更新了重新走一遍索引就行分钟级别生效。它更像是给模型外挂了一个实时更新的知识库模型本身的参数一动不动。所以在企业场景里RAG 通常作为默认首选微调一般留给特定领域的语言风格适配、输出格式约束这类更底层的需求。两者也常常配合使用先微调让模型具备领域语言习惯再用 RAG 拉取实时业务知识这属于进阶玩法后文会展开。2. RAG 核心链路拆解从文档到回答的三段式2.1 索引阶段把企业文档变成机器能读的“字典”RAG 的第一步是把散落的 Word、PDF、Excel、网页等文档处理成一个可供快速检索的“字典”。这个阶段如果做不好后面检索和生成全是空中楼阁。索引阶段的关键动作有三个解析、切分、向量化。解析是把 PDF 里的文字、表格、图片里的内容提取出来。看着简单做起来全是坑。扫描版 PDF 需要 OCR表格提取经常乱序多栏排版的论文会把阅读顺序搞乱。我的经验是解析阶段起码要留出整个项目 30% 的时间宁可在这里磨刀也不要急着往后跑流程。切分是把长文档切成一段一段的“块”chunk。这个环节最考验经验切大了一块里塞了太多主题检索时噪音大模型容易抓到无关信息切小了语义不完整模型只看到半句话答不出所以然。常用的策略包括按固定字符数切分、按段落切分、按语义边界切分每种各有适用场景。固定字符数最简单但对中文来说500 字左右是一个比较好用的起点配合 10% 到 20% 的重叠率能有效避免语义在边界处被拦腰截断。结构化文档按章节层级切分效果更好因为本来就有天然的语义边界。向量化是把文本块转换成一组数字向量。这里有个朴素的直觉语义相近的文本在向量空间里距离也近。比如“怎么请假”和“休假申请流程”说的不是同一句话但向量距离会很近。这一步依赖嵌入模型Embedding Model目前主流的开源选择有 BGE、M3E、通义文本向量等商用闭源的有 OpenAI 的 text-embedding-3 系列。选型时注意两点一是看中文效果直接用英文榜单排名选模型容易踩坑二是向量维度维度越高表达能力越强但存储和计算成本也越高需要平衡。2.2 检索阶段向量搜索里藏着哪些门道索引建好之后用户提问进来系统把问题也变成向量然后在知识库里找出最相似的 Top-K 个文本块。这个“相似”的度量方式最常见的是余弦相似度和内积。但实际项目里单纯靠向量搜索远远不够。向量搜索擅长捕捉语义相似却不擅长精确匹配。你问“员工编号 HR-2024-001 的入职日期”向量搜索可能在语义上找到一段相关文本但精确的编号匹配它就不太行了。所以成熟的 RAG 系统普遍采用混合检索Hybrid Search——向量搜索和关键词搜索比如 BM25的结果做融合再一起交给重排模型。这里必须提一下重排序Rerank。召回阶段为了不遗漏通常会多召回一些比如 Top 50但模型上下文窗口有限不能全塞进去。重排序就是用专门的 Rerank 模型对召回结果重新打分挑出最相关的 Top 5 或 Top 10。这一步对回答质量的提升是肉眼可见的很多团队把 Rerank 模型加入流程后回答准确率直接上了一个台阶。光有 Embedding 没有 Rerank就像筛选简历只看了学校名字没有细看项目经历错配率自然高。Dense Vector Search 只是检索体系里的一环完整的关键词、稀疏向量、稠密向量、Rerank 的组合方式才是 RAG 检索质量的分水岭。你在面试里被问到 RAG 检索流程怎么设计能把这个组合链路讲明白基本就过关了。2.3 生成阶段让模型“拿着资料说话”检索出相关内容后还要做一道“组装”工序把用户的问题和检索到的文本块按一定格式拼接成 Prompt交给大模型生成回答。这一步听起来简单实际上对回答质量的影响不亚于检索。Prompt 的组装里有几个要点。第一是明确指令你要告诉模型“只依据提供的资料回答资料中没有的信息不要编造直接说不知道”。第二是对检索内容的呈现格式做处理让模型能区分哪句是用户的问题、哪句是参考资料通常用清晰的标记分隔。第三是控制上下文长度塞进去太多文本块模型容易迷失重点而且推理成本也跟着涨。生成阶段还有一个容易被忽视的细节引用来源。企业场景里AI 给出的答案如果无法追溯到原始文档业务方是不敢直接采信的。好的 RAG 系统会让模型在回答时标注参考来源用户点一下就能跳回原始文档确认。这不仅是产品体验问题更是信任问题。3. 从基础 RAG 到 Agentic RAG技术演进路径3.1 基础 RAG 的痛点在哪里你把上面三段式流程搭起来了跑通了 Demo业务方试用后问了几个问题你很快就发现不对劲。第一个痛点是“一步检索定生死”。用户的问题先检索一次结果不好就完了模型只能基于这些错的内容硬着头皮回答。真实场景中用户很少会一次把问题问清楚更多是“我要做市场活动预算但是不知道公司对礼品采购金额有规定吗”这种口语化、意图混杂的表达一次检索很难命中。第二个痛点是多跳问题不会处理。用户问“公司今年新入职员工的电脑配置标准是什么”这个问题分解开来是两步先找出今年新入职员工适用的制度版本再找电脑配置章节。基础 RAG 没有这种多步推理能力只能一把抓。第三个痛点是缺乏工具调用能力。如果用户的问题是“我们部门上季度的报销总额是多少”知识库里根本不会有现成的数字正确路径是去数据库查。但基础 RAG 不会查库它只能告诉你报销流程是什么。3.2 模块化 RAG重写、路由、融合检索为了应对上述痛点社区里演化出了模块化 RAG 的思路。它的核心思想是把基础 RAG 的固定管道拆成可编排的模块在中间插入各种处理逻辑。比较常见的模块包括查询改写Query Rewriting、查询路由Query Routing、检索优化等。查询改写解决的是“用户不会问问题”的痛点。原问题可能包含指代、口语表达、冗余信息模块先对问题做改写再拿改写后的版本去检索。比如用户问“它的报销标准是多少”改写模块先判断“它”指代的是“部门团建”然后生成更清晰的检索词。原来是用户迁就检索现在让检索去理解用户。查询路由解决的是“一个问题多类数据源”的问题。用户问“我们产品的市场占有率”知识库是文档数据库是结构化数据路由模块判断这个问题的答案需要从数据库取把请求转到 SQL 查询链路而不是向量检索链路。融合检索在前面提过把向量检索和关键词检索的结果做加权融合可以在语义匹配和精确匹配之间取得平衡。模块化 RAG 的框架下这些模块可以自由组合按业务需求编排这也是 RAG 项目逐渐从“一条管道”变成“一个灵活的检索系统”的过程。3.3 Agentic RAG把检索变成决策Agentic RAG 是最近被讨论最多的方向热搜词里的“agentic rag”指的就是它。理解它之前先看一个传统 RAG 回答不了的问题用户问“对比一下我们公司和 A 公司过去三年的营收增长并给出分析结论”。这种问题需要检索公司财务文档、可能需要查库获取营收数字、需要计算增长率、需要生成分析结论中间还可能要来回修正检索策略。传统 RAG 一次检索就给出答案根本撑不起这个流程。Agentic RAG 的思路是把大模型当作一个“决策者”Agent由它自己规划完成任务需要哪些步骤每一步调用什么工具去哪里检索检索结果不满意就换个关键词再检索甚至调用计算工具做数值分析然后综合所有信息给出答案。打个比方传统 RAG 是给顾问配了一个资料员Agentic RAG 是给顾问配了一个助理团队助理自己决定去哪个档案室、查哪个文件、叫谁来做数据分析最终汇总成报告交给顾问。我这里要提醒一句Agentic RAG 虽热但复杂度也成倍上升。检索链条越深出错的概率越大一个环节查错后续全错而且每次 Agent 决策都在消耗模型调用成本。实践中的建议是能用基础 RAG 解决的场景不要上 Agent只有当真需要多步推理、多工具协作时才考虑引入 Agent 能力。先跑通基线再用 Agentic 优化别一上来就整花活。4. 一次完整的 RAG 项目落地实战4.1 工具选型Dify、LlamaIndex还是自己写做 RAG 项目首先要回答一个现实问题用现成框架还是从头搭如果你想快速验证业务价值或者团队没有太多 AI 工程经验Dify 这类平台是非常好的起点。它封装好了文档解析、切分、向量化、检索、Prompt 编排的完整链路你只需要上传文档、配置参数、发布应用几小时就能跑通一个知识库问答机器人。我见过不少政务、企业知识库项目是基于 Dify 搭建的尤其是非技术团队用可视化编排就能维护整个系统。Dify 社区版本功能已经很完整支持知识库多分库、混合检索、Rerank 接入对小团队来说非常友好。如果你要做的系统对检索链路有深度定制需求比如复杂混合检索、多路召回、自定义重排逻辑LlamaIndex 是更合适的底座。它是一个 Python 框架灵活性极高从数据加载器、切分策略、向量存储到检索器每个环节都能自定义。代价是你得自己组装、自己调试对工程能力有要求。LangChain 也可以做但我的体感是 LangChain 更适合做 Agent 相关的编排纯 RAG 链路里它的抽象层较厚排查问题的时候有一层又一层包装容易晕。当然这个属于个人偏好如果你团队已经熟 LangChain用起来也不差。还有一个选择是刚发布的 LlamaIndex 搭配自家向量库或者用 Milvus、Weaviate、Qdrant、Elasticsearch 做存储层每个组件单独选型适合对性能要求很高的大规模项目。工具选型的判断标准就一句话团队的工程能力和项目的定制深度要匹配。资源少就站在巨人肩膀上别为了炫技从头造轮子。4.2 数据准备与切分策略数据是 RAG 的命根子。这一步偷懒后面所有环节都是在垃圾堆上盖房子。第一步做数据盘点。别急着上传所有文档先看你的知识库里有哪几类数据制度规范类结构清晰、长文本、条款化、流程操作类步骤多、有顺序逻辑、FAQ 类问题对短文本、表格类强结构、需要特殊解析。不同类型的文档切分策略完全不同。制度规范类适合按章节层级切分每一章、每一节作为独立语义块保留标题层级信息。我在项目里会把标题作为元数据存进去检索时优先匹配标题命中率会明显提升。流程操作类要注意顺序问题。切分时不能把完整步骤拆散否则模型可能只看到第 2 步和第 4 步答出来的流程是断的。这种情况建议按步骤块整体切分宁可块大一点也不要破坏步骤的完整性。表格类是最容易翻车的。直接把 PDF 里的表格转成文本再切分原来的行列关系全丢了模型看到的是一团乱字。正确做法是单独做表格解析把表格转成 Markdown 格式或者按行转成结构化描述再决定是单独存储还是并入上下文。FAQ 类最简单一条问题对应一条答案可以直接作为一个整体块。切分时记得把问题和答案拼接在一起检索时命中问题就能带回答案。4.3 RAG 测评怎么做指标和方法很多人把 RAG 系统搭起来就急着上线结果被业务方问“回答准确率是多少”的时候拿不出一个数据。RAG 测评是项目能否交付的关键一环但也是很多文章讲得最少的一环。RAG 的测评拆成两层来看。第一层是检索质量第二层是生成质量。检索质量最核心的指标是召回率Recall和命中率Hit Rate。召回率回答的是“正确的那份文档是否在召回结果里”命中率回答的是“Top-K 结果里是否有正确答案”。测法不复杂准备一批测试问题每个问题标注出正确的文档或答案片段然后用系统去检索看正确结果有没有出现在 Top-K 里。不需要太数学化的公式业务方关心的是“50 个问题里正确答案被捞出来的有多少个”生成质量指标相对主观一些但也能量化。三个维度就够了准确性生成的回答是否与参考文档一致、完整性是否漏掉了关键点、忠实度是否出现了文档里没有的信息也就是幻觉程度。测评方式可以让人工打分也可以让大模型当裁判来打分后者叫 LLM-as-a-Judge。用大模型评测时最好几个模型交叉打分避免单一模型自带偏好。回答质量评估与 RAG 试验测试场景检索命中率生成准确率幻觉率优化动作基线纯向量检索68%61%22%无加入混合检索82%74%15%引入 BM25 融合再加入 Rerank91%86%9%接入 Rerank 模型优化切分策略93%90%6%按章节切分元数据这个表格是我在一个企业制度问答项目里的真实提测数据能直观看到每个环节对最终质量的影响。回到评测目标RAG 评测做出来的不是一张好看的报表而是告诉你下一个环节该优化哪里。一次全链路跑完分别测检索和生成的指标你就能精准定位是“没找到”还是“找到了没用对”这比拍脑袋猜问题要靠谱得多。5. 常见问题与排查技巧实录5.1 检索质量差问题出在哪检索结果不准是 RAG 项目里最常遇到的问题。每次排查我建议按下面这个顺序一层层看。先看数据再看检索最后看排序。数据层面最常见的问题是文档切分不合理。切分太碎语义被拆散切分太整多个主题混在一个块里。你可以把几个典型问题的检索结果打印出来肉眼看看召回的文本块到底是什么基本就能判断是不是切分的问题。这个方法土但有效。检索层面先确认 Embedding 模型选得对不对。中文场景用英文优化的模型效果不会好。再确认是否启用了混合检索如果你的系统只用了纯向量搜索碰到编号、型号、精确名称类的问题召回率上不去是必然的。排序层面大概率是没接 Rerank。没接 Rerank 的系统Top-5 结果里可能只有 1 个是真正相关的。接上之后好的 Rerank 模型能把相关结果顶到前排这个改善是立竿见影的。5.2 幻觉率居高不下怎么办模型生成了知识库里根本没有的内容这个是 RAG 最让业务方头疼的问题。排查思路这么展开。第一看 Prompt 约束有没有到位。有些团队的 Prompt 里压根没写“只能依据提供的资料回答”这句话模型自由发挥的空间很大。先把这个约束加上用词要强硬“如果资料中没有答案请明确回答不知道不要臆测或编造。”这个改动就能解决一部分幻觉问题。第二看检索到的资料质量。如果检回来的 Top-K 块本身包含不相关内容模型会很自然地被带偏。低相关度的文本对模型来说是噪音甚至是误导。办法有两个一是提高相关性阈值低于阈值的直接不返回给模型二是减少返回条数只给最精准的两三条让模型聚焦。第三看输出方式。复杂问题上让模型先列出找到的依据再基于依据作答比让它直接给出答案要稳得多。相当于让模型“先翻译后回答”强制它把思考路径和对资料的依赖关系显式化幻觉空间被大幅压缩。5.3 几个容易踩的坑文档更新后没有重建索引也没有做增量更新导致系统回答的还是旧版本内容。凡是知识库系统一定要考虑文档版本管理和索引更新机制否则时间一长库里的新旧信息混杂答案精度断崖式下滑。把所有文档一股脑塞进去不区分业务领域导致检索时不同领域的内容互相干扰。建议按业务域分库或分集合检索时先明确在哪个库里找可以显著提升精确度。忽略了权限控制。很多企业内部知识库是有阅读权限区分的但 RAG 系统的检索层不会自动感知权限一个普通员工可能通过提问检索到只对管理层开放的文档内容。这块在架构设计阶段就要考虑进去常见方案是按权限域做隔离索引。上线后不做监控。RAG 系统的坏会坏得很隐蔽它不是崩溃是慢慢变笨。一个文档被错误上传一个切分规则被调坏没有人会发现但用户会逐渐流失。我现在的习惯是给系统搭建一个简单的问题日志面板每天记录用户的提问、系统的回答和检索来源隔几天扫一眼能发现很多潜在问题。6. 聊聊我对 RAG 的一点实战体会做了这么多 RAG 项目最大的感受是RAG 看起来简单做精了很难。它不像大模型训练那样需要前沿算法突破而是由无数个细节堆积起来的系统工程。数据质量、切分策略、检索方式、排序模型、Prompt 设计、评测体系每个环节都只能及格综合效果才会及格任何一环掉链子整个系统的体验就会被拖下水。对于刚入门的团队我给三个建议。第一先用 Dify 跑通端到端流程亲眼看到 RAG 的长板和短板再决定要不要深入底层定制。第二无论用什么框架先把评测体系搭起来哪怕只是 50 条测试问题的人工标注它也能成为你后续所有优化的标尺。第三从基础 RAG 开始跑稳了再叠加 Rerank、混合检索、查询路由这些增强能力最后才考虑 Agentic RAG步子迈太大容易扯着。最后再分享一个小技巧RAG 系统里提问引导界面比想象中重要。用户提出的问题质量直接决定检索结果的上限。做一个“猜你想问”的推荐列表或者在输入框里给几个示例问题都能明显提升用户的提问质量最终反馈在回答准确率上。这个细节几乎不出现在技术文档里但实际效果很好值得一试。