RAG实战：AI智能体知识库切块、检索、重排与工作流编排

2026年聊AI智能体RAG依然是绕不开的核心话题。从制度条例学习助手到电力设计规范查询再到本地ERP接上大模型做产品检索我看到的实际项目几乎都建立在同一个地基上RAG知识库。但真正动手做过的人应该都有同感抓几个PDF丢进向量库问第一遍像模像样问第二遍就开始胡编第三遍甚至会把不存在的条款引用得头头是道。这篇文章不聊概念只把我过去一年在AI智能体项目里打磨RAG的实操经验、踩坑记录和优化路径完整拆一遍覆盖切块、入库、检索、重排、Agentic RAG和工作流编排这条完整链路。无论你是刚接触AI智能体知识库的初学者还是正在被线上检索效果折磨的同学应该都能找到对号入座的部分。1. 先想清楚你的智能体到底需要RAG解决什么1.1 从实际需求看RAG的三种典型形态热词里反复出现的几个场景很有代表性我挨个拆一下。第一个是在AI Studio上搭建智能体实现制度条例学习助手。这种项目的核心诉求是把企业内部一堆制度文档变成一个24小时在线的问答机器人员工问差旅报销标准是多少就能直接得到答案并附上制度条款原文。第二个是上传电力设计规范方便自己查询这是典型的个人专家库场景文档专业性强、术语多、需要精确到条款号。第三个是本地ERPRAGLLM产品检索这是把结构化系统和非结构化文档揉在一起的混合场景——产品规格在ERP里技术手册在PDF里用户问哪款泵能满足扬程30米且耐腐蚀时智能体需要同时查两边。这三种形态对应的RAG设计完全不是一回事。制度条例学习助手对引用准确性要求极高答错了就是合规事故电力设计规范查询对条款号、版本、适用范围的精确性要求极高参数表必须原样呈现而ERP产品检索则需要结构化数据优先、文档兜底的混合检索策略。我的建议是接到任何项目先别急着搭向量库把场景归好类再动手。1.2 动手前必做的四个自问我在评估一个RAG项目靠不靠谱时一定会先问四个问题也建议你照着问一遍。第一个问题数据是什么形态是纯文本PDF、扫描件、Word里带表格、还是数据库里的结构化记录这决定了你要做OCR、做表格解析还是走SQL查询。第二个问题答案需要原文引用还是综合推理例如制度条例必须引用原文但这两个条款之间有没有冲突就需要综合多篇文档推理前者对检索精度要求高后者还需要一个推理型模型配合。第三个问题知识更新的频率有多高制度条例每个季度修订一次和产品参数每周都在变对索引更新策略的要求完全不同。第四个问题延迟和成本的上限是多少在线调用大模型接口做重排很爽但本地部署的Edge场景就得考虑要不要用轻量级rerank模型。这四个问题答完你基本就能判断该用朴素RAG、Agentic RAG还是RAG工具调用的混合方案。我见过太多人一上来就追求Agentic RAG结果把简单问答搞得又慢又贵也见过有人用朴素RAG硬扛复杂的多条件筛选检索结果自然一路飘。先分类后优化这个顺序不能乱。2. 知识入库切块、清洗与表格处理2.1 切块策略没有万能参数只有匹配场景RAG效果差十有八九是知识入库这一步出了问题。其中切块Chunking又是最容易被轻视的环节。很多人一上来就设一个固定值比如300字或500字一截跑完发现答案断章取义就开始怀疑模型不行其实锅在切块策略上。主流的切块方式我帮你梳理成一张表方便对号入座。切块方式原理适用场景注意点固定长度切块按字符数硬切配overlap滑动窗口文本结构统一、无复杂层级容易切断语义不推荐用于专业文档递归字符切块按段落→句子→子句逐级向下切Markdown、代码、带标题的通用文本对纯文本PDF效果一般语义切块按标题、章节、段落边界切制度条例、技术规范、长文报告需要清洗后保留文档结构父子块父块存上下文子块做检索条款相互引用的法律、规范类文档返回时拼接父块提示词要设计好我自己在制度条例和电力规范类项目里最常用的是结构感知切块父子块兜底。具体做法是先清洗PDF把目录、页眉页脚、页码全部去掉然后用正则识别第X章第X条X.X.X这类结构标记按条款边界切块如果一个条款太长再按子段落拆成小块但保留条款号作为父块ID。这样检索命中的是条款的子块生成时却能带上整条引用效果比固定切块稳得多。切块参数方面我踩过不少坑。中文场景下块大小设在300到800字符之间比较安全块与块之间的overlap取10%到20%。overlap太小边界信息容易丢overlap太大索引体积膨胀检索时重复命中的噪音也变多。如果你的Embedding模型是1024维甚至更高块稍微大一点没关系因为稠密向量有能力表示更长上下文但如果用的是轻量级Embedding模型块就尽量控制在500字符内。2.2 表格数据产品参数、制度条例最容易被问崩的地方热词里有一条特别扎眼系列产品表格怎么存入RAG知识库。这个问题我至少被问了十次因为表格是所有RAG方案最头疼的数据形态。直接把Markdown格式的表格整块丢进向量库效果通常很差——模型检索到的是表格里的一堆数字但用户问的是扬程大于30米的型号有哪些这需要的是行级筛选不是语义匹配。我实际操作中验证下来比较好用的方案是表格三维拆解。第一步把表格标题和列名单独抽出变成一段结构化描述比如本表为XXX系列离心泵技术参数表包含型号、扬程、流量、功率、耐腐蚀等级五列。第二步把每一行数据转为JSON格式然后拼接成自然语言描述比如型号IS100-65-200扬程32米流量100立方米每小时功率15千瓦耐腐蚀等级A。第三步同时保留一份原始Markdown表格在知识库里供生成答案时原样引用。这样做的好处是用户语义查询时模型能通过扬程32米这种属性描述快速命中对应行需要精确列参数时又能拿原始表格做引用输出。电力设计规范里的参数表、ERP里的产品选型表我都用这套思路处理过实测检索准确率能从五六成直接拉到九成以上。表格数据入库还有一个隐藏坑单位。不同章节可能用米和m混着写用户问30米检索起来会不一致。我的习惯是在清洗阶段做一轮单位归一化把常见单位统一成标准写法的同时保留原文作为引用这样既不破坏原始依据又能提升召回率。2.3 元数据与索引设计决定检索上限的隐形工程很多人做RAG只关注向量本身却忽略了元数据。我举一个真实例子一个制度条例知识库里有新旧两版报销制度旧版规定出差住宿上限350元新版是450元。如果你不做版本过滤用户问住宿标准多少时检索结果里新旧条款混在一起模型很有可能选中旧版内容输出这就是实打实的合规事故。我的做法是给每个块打上必要的元数据字段至少包括来源文件名、章节号、条款号、版本号、生效日期、失效日期。然后在检索阶段根据用户问题或预设规则做元数据过滤。比如制度条例QA默认只检索生效日期今天且失效日期为空的块电力规范查询自动带上标准编号过滤条件。元数据过滤能砍掉的错误结果有时候比换一个更强的Embedding模型还多。索引设计上还有两个细节值得说。一个是区分标题向量和内容向量——把标题单独embedding检索时标题和内容分别打分再加权合并能明显提升长文档的命中率。另一个是增量更新制度修订后不能整库重建而是把旧版本块的失效日期置为当天再写入新块。这套逻辑删除物理新增的方案我一直在用稳定可靠。3. 检索优化实战召回、重排与多轮对话3.1 向量检索与关键词检索的配合入库做完了下一步就是检索。这里只说实战干货纯向量检索在中文专业场景下效果并没有想象中那么好。原因很简单向量检索擅长捕捉语义相似但在处理标准编号条款号型号这类精确匹配需求时经常翻车。比如用户问GB 50016-2014的3.2.1条Embedding模型很可能把它跟建筑防火规范的防火分区要求模糊关联起来而不是精确锁定条款原文。所以我强烈建议做混合检索也就是向量检索和关键词检索BM25并行跑然后把两路结果融合。融合的方式不复杂常用的是RRFReciprocal Rank Fusion把两路结果的排名分别取倒数相加后重新排序。这样做的好处是语义相关和精确命中各占权重不会因为某一路表现不佳而整体失效。我实测过的场景里纯向量召回命中率可能在70%左右加上BM25后能到85%再加上Rerank能进一步逼近95%。混合检索的代价是多一路索引和一次并发查询但换来的是稳定性和容错率的显著提升这笔账是划算的。3.2 Rerank提升效果最立竿见影的一步如果你只打算做一项优化我首选Rerank。向量检索召回TopK一般要放到20到50个块因为这阶段宁可多召回也不能漏但直接把这么一大堆上下文塞给大模型既浪费token又干扰生成。Rerank的作用就是在这20到50个候选里用更精细的交叉编码器模型重新打分只保留最相关的3到5个块。Rerank在实操里分两步。第一步用向量检索和BM25各召回TopK经过RRF融合取前20到30第二步用Cross-Encoder模型比如bge-reranker-base或Cohere Rerank对这20到30个块重新打分排序取前3到5个作为最终上下文。为什么不用向量模型直接做Rerank因为双塔结构的向量模型在最后阶段丢失了细粒度交互信息而Cross-Encoder把问题和文档拼在一起过一遍模型相关性刻画要精准得多。这里有一个值得强调的细节Rerank的阈值不能一刀切。制度条例场景要求严谨相关度分数低于0.5的块直接不要宁可答未找到相关信息也不能硬答而产品选型场景可以放宽到0.3多给模型一点上下文做综合判断。不同业务线设置不同的分数门槛是上线前必须做的调参工作。3.3 多轮对话里的RAG怎么设计热词里有一条RAG多轮对话怎么设计这个问题几乎每个项目都会遇到。多轮对话最大的坑在于用户问那它的耐磨性怎么样单看这一句系统根本不知道它指的是什么直接拿去检索必然跑偏。我常用的方案是查询改写历史窗口。查询改写是指在把用户问题送进检索器之前先用一个大模型或一个小模型结合最近两到三轮对话历史把问题改写成一个独立的、完整的查询。比如前文在讨论IS100-65-200型离心泵用户下一句问那它的耐磨性怎么样改写结果就应该是IS100-65-200型离心泵的耐磨性怎么样。这一步看着简单但对检索命中率的影响非常显著。更进阶的做法是把历史会话本身也向量化单独建一个会话记忆索引。当新问题到来时先检索历史会话看有没有相关的上下文可以直接复用再把命中的会话片段和知识库检索结果一起交给大模型。这样一来多轮场景下的指代消解和上下文衔接都能被照顾到。我在AgentScope和LangChain4j两类项目里都试过这种设计稳定性明显优于只靠提示词拼接。4. Agentic RAG让智能体学会什么时候不检索4.1 RAG和MCP到底什么关系热词里高频出现rag和mcp区别我每次都会被问到。这两者其实不在一个维度上。RAG解决的是知识从哪里来——把外部文档变成模型可检索的上下文MCP解决的是工具怎么连——让智能体能调用外部系统比如查ERP、查数据库、发消息、操作文件。可以这样理解RAG是给模型喂参考资料MCP是给模型递工具手柄。但在实际项目里两者经常配合着用。比如一个智能体需要通过MCP的数据库工具直接查ERP里的最新库存同时通过RAG检索产品手册里的技术参数。标准做法是把RAG知识库封装成一个MCP工具比如叫knowledge_search然后把查询数据库封装成另一个工具叫erp_query。智能体根据用户问题自主决定先调哪个、或者两个都调最后把结果汇总。这就是Agentic RAG的雏形——不是固定检索完就生成而是让智能体参与决定查什么、查哪、查几次。4.2 把RAG封装成Skill后的工作流另一条热词是skill怎么和RAG结合起来。我理解这里说的Skill就是智能体的技能模块也就是可复用的能力单元。一个设计良好的RAG流程完全值得被封装成一个Skill而不是每次都在提示词里写一大堆检索指令。以AI Studio或Dify这类平台为例一个制度条例学习助手的工作流可以编排成这样第一步意图识别判断用户问题是否是制度咨询第二步路由如果是制度咨询就进入RAG Skill如果问的是公司组织架构则跳转另一个知识库第三步RAG Skill内部做查询改写、混合检索、Rerank第四步生成答案并要求模型输出引用条款号第五步引用校验检查模型输出的引用是否真实存在于知识库中。这套流程从第一到第五步都可视化地串在画布上调试时每个节点的输入输出都能单独查看比黑盒式的Prompt调用好排查得多。在代码层面用LangChain4j或Spring AI实现同样的机制也不复杂。检索部分的核心代码大致长这样// LangChain4j 中定义一个RAG检索组件 RetrieverTextSegment retriever ContentRetriever.builder() .embeddingStore(embeddingStore) .embeddingModel(embeddingModel) .maxResults(20) .minScore(0.3) .build(); // 查询改写把多轮对话上下文拼接后改写 String rewrittenQuery chatModel.call(改写问题 userMessage 历史 history);这个示例背后的要点是maxResults不能设太小要给Rerank留足候选minScore不能设太高否则召回容易为空。具体数值建议根据你自己的知识库内容做一次小规模评测我习惯的做法是准备50个典型问题跑一遍看召回率再定阈值。4.3 多智能体场景下RAG的职责划分再往上走一步是多智能体协作。我在实际项目中常用的一种组合是知识问答Agent负责检索和引用原文计算Agent负责做参数换算和选型计算文书Agent负责根据前两者的输出起草报告。这种拆法下RAG的职责集中在知识问答Agent身上计算Agent不直接访问知识库而是接收结构化数据。这里有一个关键设计决策共享向量库还是隔离向量库。我的经验是如果两个Agent面向不同的知识域比如一个管制度、一个管技术规范向量库最好隔离避免跨域检索产生噪音如果它们面向同一份知识库但职责不同则可以共享靠元数据过滤来区分使用场景。多智能体的核心不是Agent越多越智能而是每个Agent的边界清晰RAG的检索目标才不会漂移。举一个真实场景用户问按最新制度去上海出差三天住宿和交通一共能报销多少知识问答Agent查制度条款计算Agent根据差标算总额文书Agent把计算过程整理成报销说明。整个过程里RAG只负责把制度原文和差标表格准确捞出来计算和文书不碰知识库。这种职责划分既降低了检索噪音也方便单独优化每个环节。5. 常见问题与排查技巧实录5.1 检索不准先查切块再查Embedding技术人遇到问题总想先换更强的模型但RAG检索不准的排查顺序我的建议是先查数据再查模型。第一步看切块命中的块是不是语义完整的有没有把一个条款拦腰切断第二步看查询改写多轮问题有没有做指代消解第三步看检索策略向量、BM25和Rerank是不是都用了最后才轮到Embedding模型——如果前面的环节都做得干净换模型的收益其实很有限。我遇到过最典型的案例是制度条例里报销这个词用户习惯说报账向量检索因为语义相似能命中但BM25完全匹配不到。解决办法是在清洗阶段维护一份同义词/行业术语表把报账映射到报销再去做查询改写。这类问题换再强的Embedding模型也解决不了只能在数据处理层面下功夫。5.2 幻觉与错误引用强制引用ID和生成后校验RAG的幻觉问题很大一部分出在模型不知道回答的依据是什么。我的方案是在检索阶段就为每个命中的块分配一个唯一的引用ID然后在生成提示词里明确要求回答时必须在每句话末尾标注引用ID引用ID必须是提供的列表中存在的禁止编造。这一步能解决大部分编造引用的问题。更硬核的做法是生成后校验让一个校验Agent把答案里的引用ID逐一去知识库里核对如果发现某个ID不存在或内容对不上就把对应句子删掉或要求重写。这个方案我在合规要求最高的制度条例项目里一直用着虽然多了一次模型调用但换取的是每条引用都有据可查。衡量标准很简单把错误引用率作为上线前的必检指标低于1%才放行。5.3 提示词里如何用好检索到的上下文检索到的内容如何组织进提示词同样影响最终效果。我见过很多失败的Prompt把20个块一口气丢给模型然后指望它自己挑出相关部分结果自然是前后矛盾。正确的做法是在Rerank之后只保留3到5个高相关块然后在提示词里按相关度排序并用明确的分隔符隔开同时附上每个块的来源章节。我常用的上下文模板大致是以下是知识库检索到的参考资料按相关度从高到低排列 【引用ID: 3】来源《差旅管理制度》第5章第3条 - 住宿费标准一线城市450元/天... 【引用ID: 7】来源《差旅管理制度》第6章第1条 - 交通费标准高铁二等座... 回答要求仅依据上述资料回答若资料不包含答案请明确回复未在知识库中找到相关信息。每条结论后标注对应的引用ID。这个模板背后的设计逻辑是给模型明确的援引边界缩小其自由发挥的空间。不要试图引导模型做知识库之外的推理那就背离了RAG的初衷。5.4 本地部署的性能调优缓存、并发、量化最后聊聊本地部署。热词里很多人在问本地RAG怎么搭个人免费版怎么用核心诉求是控制成本。我的经验是抓三个点缓存、并发控制、模型量化。缓存是性价比最高的一环。同一问题在短期内被反复问到尤其是企业制度这类高频内容完全可以加一层结果缓存按问题语义哈希做KeyTTL设置成24小时能砍掉一大半重复计算。并发控制方面向量检索的QPS上限要提前压测不然流量一上来Retriever先挂整体就雪崩。模型量化上Embedding模型用INT8量化几乎没有精度损失生成模型可以开KV Cache和PageAttention如果你用vLLM延迟能降一个量级。本地部署的RAG还有一个隐藏问题向量库的脏数据会逐渐累积。文档更新、删除、版本失效这些操作如果只是在逻辑层面标记而不做物理清理索引体积会越来越大检索速度越来越慢。我的建议是每周做一次自动化清理任务把失效的向量从索引中真正移除并重建小范围的索引分片保持索引健康。我在这些项目里总结的几条铁律做了一年多的AI智能体RAG落地我越来越觉得RAG不是论文里的一个组件而是一套知识工程方法论。切块要跟着文档结构走表格要拆成机器能理解的属性描述检索要混合召回再重排生成要约束引用边界——每一步单独看都不算高深组合起来却决定了智能体到底可不可用。最后再分享一个小技巧无论你用什么框架上线前一定要建一组黄金评测集。准备50个覆盖主要业务场景的问题每个问题标注正确的答案和检索依据每次调整切块参数、检索策略或提示词之后都用这组评测集跑一遍回归。我在项目里坚持这个习惯效果立竿见影——所有优化决策都有了量化依据而不是靠感觉拍脑袋。RAG优化没有一劳永逸的银弹但有了评测集和一整套可复用的排查路径你就能在任何一个项目里稳定地把效果做上去。