前几天有个朋友拿着他搭好的 Agent 来找我说模型总是对着公司内部的流程文档一本正经地胡说八道——问他财务报销要走什么流程它能编出一套“提交申请表、领导审批、财务打款”但实际流程里还有预算预审和发票校验两道关卡全被它漏掉了。这不是模型不够聪明而是它压根没见过你们公司的文档。大模型的参数里装的是互联网上的公共知识装不下你私有业务里的那些细则。这时候RAGRetrieval-Augmented Generation检索增强生成就派上了用场。作为 AI Agent 系列第四篇我想把“知识获取管道”这个主题讲透——我们如何用 RAG 给 Agent 接上一条通往外部知识库的管道让它在生成答案之前先学会“查资料”。这篇文章适合正在从零搭建 Agent、又苦于模型不懂私有知识的开发者也适合那些听说过 RAG 但还没动手实践的读者。我会从最基础的链路原理讲到检索质量的调优再到 Agentic RAG 的集成思路最后附上实战里踩过的坑和排查清单。全程用我自己的项目语境来说不用教科书语言。1. 为什么 Agent 会“胡言乱语”知识获取管道的必要性1.1 大模型的知识边界与知识割裂问题所有的大语言模型本质上都只是一个“预测下一段文本”的概率系统。训练阶段它会消化互联网、书籍、论文里的公开语料然后把这些知识的统计规律压缩进几十亿甚至上千亿个参数里。这个压缩过程有两个限制一是知识有截止日期模型永远不知道训练集之后发生的新事情二是权重里只能保存高频、共性、结构化的模式那些长尾的、私有的、高度动态的内容会被无差别地模糊化。我跟很多开发者聊的时候他们最常犯的误解是“我本地部署一个开源模型它就能学会我公司的知识”。不行。本地部署解决的是数据私密性和推理成本问题解决不了知识边界问题。你公司的产品手册、自查清单、客服话术、设备参数这些内容在网上根本查不到也不可能凭空出现在训练语料里。想让模型回答这些私有领域的问题就必须在推理时给它“喂”相关内容这就是“知识割裂”的核心矛盾——模型有强大的语言能力但它没有你需要的“事实”。Agent 比单轮问答更依赖知识管道原因在于 Agent 是要动手做事的。它要写邮件、查库存、生成报表、报修设备。每个动作背后都依赖准确的情境知识。一个 Agent 如果只知道“邮件要礼貌”但不知道对这家客户该用哪种称呼、最近有没有欠款纠纷那它写出来的邮件大概率不能直接用。所以知识获取管道不是可有可无的附属组件而是 Agent 能不能在真实业务里落地的根基。1.2 RAG 的本质把检索能力注入生成过程RAG 的思路非常直白不修改模型参数而是在模型生成之前先从你的知识库里检索出与问题相关的文档片段把这些片段拼进 Prompt让模型基于这些“参考答案”来回答。这就像是给学生换了个考试方式——不再是闭卷全靠背而是允许开卷先翻书再答题。一条最基本的 RAG 管道包含三块知识库、检索器、生成器。知识库存放你已经清洗好的业务文档检索器负责在知识库里找到最相关的若干片段生成器就是你的大模型它把“用户问题 检索到的片段”糅合在一起生成最终回答。这三个字说起来简单但工程上的细节极其多。比如知识库怎么切片、检索器怎么打分、检索结果怎么过滤、片段多了会不会把模型冲晕、少了会不会回答不全这些处理不好RAG 就退化成“花哨的倒垃圾工具”。我在后面几章会按一条最小可用的管道一步步展开。这里先把逻辑讲清楚RAG 的价值不在于让模型“记住”知识而在于让模型在需要的时候“找到”知识。这是一种把外部记忆动态挂载到推理过程的方案天然适合 Agent 这种需要实时查证、多步决策的场景。1.3 RAG 与微调、长上下文的选型逻辑总有朋友问那我是不是直接微调一个模型把所有文档塞进去效果更好我的回答通常分情况。微调Fine-tuning适合学习某种风格、输出格式或固定的行为范式比如让模型学会按你们公司的工单模板输出。微调不适合做知识库因为它需要大量标注数据、训练成本高而且每次文档更新都要重新训练更可怕的是模型会把没见过的内容“一本正经地编”出来微调并不能像检索那样轻易追溯到出处。长上下文是另一个诱人的方向。现在的模型动不动就支持 128K、200K token看起来你可以把整本手册塞进 Prompt。但实际用下来有两个问题一是成本急剧上升每次都把所有文档传一遍Token 费用感人二是“中间遗忘”问题——模型对长文本中间的注意力分配不均匀你的答案很可能埋在几千 token 的茫茫文档里模型会抓不住重点。RAG 相当于先做一遍“注意力预筛”把最重要的内容挑出来再让模型聚焦阅读精准度和成本都更可控。下面的表格是我经常用来给团队决策参考的对比方案适用场景主要成本知识更新难度RAG私有知识、政策文档、实时信息、需要溯源向量库搭建与检索调优低更新文档后重新入库微调风格对齐、输出格式、特定行为规则数据标注与训练算力高需重新训练长上下文单篇长文档、一次性分析推理成本高、局部注意衰减中需随文档变化更新在我自己的项目里常见做法是“RAG 为主微调为辅”。Agent 的行为规范比如回复风格、必须用表格输出用微调搞定具体的业务事实一律走 RAG 管道。这样既能保持模型行为的稳定性又能让知识随文档版本实时变化。2. 搭建一条最小可用的 RAG 管道五步流水线实操2.1 文档加载与清洗别让垃圾进管道很多教程会直接从“切分、向量化、检索”讲起但我在项目里最大的体会是文档清洗才是成败关键。知识库里的原始文档格式五花八门PDF 有扫描版、Word 有页眉页脚、HTML 有导航标签、Excel 里还可能藏着公式。你如果直接把这些内容扔进去向量库里会塞满噪音检索出来的东西自然不靠谱。第一步根据文档类型选择合适的加载器。PDF 类我会先试 PyMuPDF 或 pdfplumber扫描版要接 OCRPaddleOCR 这类开源工具就够了Word 和 HTML 用 LangChain 里的加载器或者自己用 BeautifulSoup 提取正文最重要的是去掉页眉页脚、导航链接和脚本片段。清洗阶段我会写几个正则表达式把多余的空格、换行、以及“仅供内部使用”这类页脚信息统一处理掉。还有一个经常踩的坑PDF 里表格数据被还原成一堆散乱文本检索时根本拼不回来。这个要么把表格结构化把表格转成 Markdown 表格要么在切分时设置“表格区块优先级”。我建议把清洗后的文档统一转成 Markdown 或纯文本保留必要的标题层级#、##和列表结构。这样后面做结构化切分会极其方便。2.2 切分策略chunk size 与 overlap 的选择逻辑切分Chunking是整个管道里最容易被低估的环节。切太小一块内容装不下一句完整的意思检索到的信息残缺切太大一块内容包含多个主题语义会被稀释向量表示变得模糊。我做过一次实验同一份技术手册按 200 字切分时检索 Top5 的命中率大约 62%按 512 字切分时能到 78%按 2000 字切分时反而掉到了 55%——因为太大的片段里只有一两句是用户问的向量被其余无关内容拖偏了。实际操作中固定的字符切分不是最优解我更喜欢“按文档结构切分”。比如用 MarkdownHeaderTextSplitter根据标题和段落生成 chunk每个 chunk 带上它的标题前缀这样上下文天然完整。如果没有明显的结构就用递归字符切分设置 chunk_size500、chunk_overlap50 起步再根据测试效果调整。chunk_overlap 的作用是避免两个相邻块把一段完整信息截断在边界上。50 到 100 字的重叠通常够用。这里有一个细节chunk 里最好带上一个“文档来源”的元数据字段。比如{source: 采购管理制度.pdf, page: 3}。后面做引用溯源、权限过滤、按来源排除某些文档时没有这个字段你会非常痛苦。我见过有人把知识库建完才发现没法做部门隔离只能全部重建。2.3 向量化Embedding 模型的选择与维度陷阱切好的文本块要变成向量。向量就是一组浮点数能表示文本的“语义坐标”。语义相近的句子在向量空间里离得也近。Embedding 模型的选择直接决定了检索的底线。以中文业务场景为例我常用的几个模型是模型维度特点text-embedding-3-small1536可降至 512OpenAI 闭源中英文都不错按调用量计费BGE-large-zh1024中文效果好可本地部署M3E / BCE768面向中文的轻量模型本地部署资源占用低text-embedding-ada-0021536老模型中文一般不推荐新项目用选择 Embedding 模型时最容易忽略的是“领域适配”。通用模型对专业术语、品牌名、缩写词往往编码能力不强。比如“RAG”这个词在通用模型里可能会被拆成“r、a、g”三个字母的模糊向量导致检索不到知识库里的“检索增强生成”。如果你的业务领域很垂直比如医疗、法律、化工强烈建议先在真实文档上用小样本对比几个模型而不是盲目跟风。另外维度不是越高越好。高维度向量计算更慢也需要更大的存储空间而且在数据量不够时反而容易过拟合。采用 OpenAI 的嵌入如果你只是做普通业务知识库维度降到 512 经常已经足够。维度变换不会有明显的精度损失但大模型平台的 API 费用和检索延迟会直观地降下来。2.4 存储与索引向量数据库的选型对比向量数据存哪这一步的选择很影响后续运维。我的建议是小项目、个人跑通 demo直接用Chroma或FAISS前者足够简单后者快且免费团队项目或生产环境考虑Qdrant、Milvus或pgvector。其中pgvector特别适合你已经用了 PostgreSQL 的团队直接把向量和业务数据放一起少一个中间件。向量数据库的核心技术是 ANN近似最近邻索引。常见的 HNSW 算法有两个参数M每个节点的连边数和efConstruction建索引时的搜索范围。M 越大召回率越高但索引越大、查询越慢efConstruction 越大建索引越准但耗时越长。实战中我会建议从 M16、efConstruction200 出发然后针对你自己的知识库规模测试。几万条 chunk 和几百万条 chunk 的参数差别非常大不能照搬默认值。选型时还要看过滤能力。Agent 场景往往需要“只能访问某个部门的文档”或者“按发布时间过滤”。这时候向量库是否支持 metadata 过滤就很关键。Chroma 能做但复杂条件过滤性能一般Qdrant 的 payload 索引做得比较完善Milvus 也支持标量向量混合查询。记得先想清楚你的权限模型再选数据库不然后患无穷。2.5 生成链路Prompt 模板与上下文组装管道前面的辛苦最后都要汇聚到生成这一步。检索到的 chunk 不能直接一股脑塞给模型你需要设计一个结构清晰的 Prompt 模板。我常用的模板长这样你是业务助理请严格基于下面提供的“参考资料”回答用户问题。 要求 1. 如果参考资料中有答案请优先引用并标注来源编号如 [1][2]。 2. 如果参考资料中没有答案直接说“根据现有文档无法回答”不要编造。 3. 回答时用中文条理清晰。 参考资料 [1] 来源采购管理制度.pdf第3页 内容... [2] 来源费用报销规范.pdf第7页 内容... 用户问题...这里最关键的指令是“没有答案就直接说不知道”。很多 RAG 项目效果不好不是因为检索不到而是模型在检索到的材料不充分时依然会“自信地”动用参数记忆去补全产生幻觉。你必须在 Prompt 层面强制切断这个路径。组装上下文时要注意 Token 预算。假设模型上下文窗口是 8K我会把系统提示词 用户消息 历史对话控制在 3K 以内给检索到的 chunks 留出 4K 左右最后留 1K 给模型输出。如果超过了先把排序靠后的 chunk 截断再考虑压缩历史对话。否则检索的 chunk 再准模型也读不完前面的工作白费。3. 检索质量才是真正的分水岭召回、重排与混合检索3.1 为什么 top-k 和 score 阈值不能拍脑袋新手做 RAG 最喜欢把top_k设成 4因为教程里写 4。但 4 到底够不够取决于你的知识库质量和业务问题。我遇到过很多次正确答案恰好排在第 5、第 6 位而用户问的是“某型号设备的保修期是多少”前 4 个 chunk 全是设备简介没有保修条款。这种情况下你必须提高召回数量然后再靠重排把真正相关的顶上来。score阈值同样重要。向量检索返回的相似度分数有时候 0.82 才是相关的有时候 0.6 就已经很相关——这取决于 Embedding 模型和知识库内容的一致性。我的做法是先收集一批真实用户问题配上标准答案所在文档跑检索画出分数分布。看看“相关文档”和“无关文档”的分数有没有明显的分界然后在分界点附近选阈值。当然这只适用于你有一个比较完整的测试集。前期没有测试集时先用一个宽松阈值比如 0.3保证召回再做重排防止因为阈值太高把正确答案挡在门外。3.2 混合检索BM25 向量的取舍与融合纯向量检索有一个短板对精确词、缩写、编号的匹配不敏感。举个例子用户问“GL-280A 型号的防护等级”向量检索可能会找到很多关于“防护等级”的文本却错过了含有“GL-280A”的精确文档——因为这个词在向量的语义空间里辨识度有限。这种问题在工业设备、产品型号、法律法规场景中尤其常见。解决办法是混合检索一边用 BM25 这类传统关键词检索去匹配精确术语一边用向量检索去匹配语义相近的内容再把两路结果融合起来。融合我用得比较多的是 RRFReciprocal Rank Fusion公式很朴素score 1 / (k rank_bm25) 1 / (k rank_vector)其中 k 通常取 60。这个公式不看分数绝对值只看排名所以不受 BM25 分数和余弦相似度的量纲影响。我在项目里验证过纯向量检索的召回率约 72%加上 BM25 的 RRF 融合能做到 88% 左右效果非常明显。不少框架已经内置了混合检索组件比如 LangChain 的EnsembleRetriever、Elasticsearch/OpenSearch 的混合查询。如果你的知识库本身跑在 ES 上用它的关键字 kNN 联合查询能省掉很多胶水代码。3.3 重排模型用 cross-encoder 做最后一公里的精筛两路检索合起来可能召回了几十条结果但最后 LLM 只能读有限的几块。这时候“重排”就非常重要。重排模型和 Embedding 模型不是同一个东西Embedding 是把文本块独立编码成向量属于 bi-encoder 范式它高效但精度有限重排模型通常用 cross-encoder把查询和候选文本拼在一起做深度交互输出一个相关性分数精度更高但速度慢。典型的流程是先向量/关键词检索召回 Top50再用重排模型如bge-reranker-large或cross-encoder/ms-marco-MiniLM逐一打分最后取 Top5 进入 Prompt。这一步消耗的时间通常几百毫秒到几秒但对答案质量提升非常显著。我做过对比实验用同一个知识库和同一组 50 个测试问题不重排直接取 Top5答案命中率为 70%用重排模型从 Top50 里挑 5 个命中率提升到 85%。可以说这是性价比最高的调优环节。生产环境如果延迟敏感可以把重排模型部署在 GPU 上或者只对 Top20 做重排。3.4 查询改写把用户的“废话”翻译成检索语言用户的问题往往不是适合直接检索的。比如对话里他问“这个支持远程升级吗”如果直接把“这个”拿去检索什么都找不到。我们需要把这种指代不清的问题结合对话历史改写成一个独立的、语义完整的查询“XX型号网关设备是否支持远程升级”。查询改写我有两种玩法。一种是用 LLM 做改写把最近几轮对话压缩成一段让模型输出一个“站在当下问题视角的搜索查询”再拿这个查询去检索。另一种是 HyDE假设性文档嵌入让 LLM 先基于用户问题幻觉一篇“可能的答案”再拿这篇假设答案去做向量检索。HyDE 在某些语义检索场景效果好但成本偏高我一般只用在前几轮检索结果不理想时的补偿策略。要注意的是改写不是越复杂越好。用户如果问得很具体比如“报销流程里发票校验在哪个步骤”直接检索原始问题就很好。过度改写反而可能引入模型自己的偏见。我在项目里的做法是先判断当前问题是否包含关键实体名词。如果包含就直接用原文如果不完整或有指代词才触发改写。4. 把 RAG 接进 Agent 的决策循环从工具调用到 Agentic RAG4.1 Agent 中 RAG 的几种集成姿势RAG 在 Agent 里的集成方式直接决定了 Agent 的灵活性和可靠性。我见过三种层次的做法第一种也是最简单的Agent 一启动就把检索结果塞进上下文。比如用户问“帮我看看报销流程”Agent 在接到问题后先调用一次检索把“报销流程”的相关 chunk 放进 Prompt再开始规划。这种模式适合任务目标比较明确的场景缺点是 Agent 没法根据中间结果反复调整检索策略。第二种把 RAG 封装成一个工具例如search_docs(query)让 Agent 在规划阶段自己决定什么时候调用。这种方式把检索变成了 Agent 的一项能力Agent 可以先用思维链分析用户问题再决定查哪个库、查什么关键词如果查到一半觉得信息不够还可以再调一次。热词里的“spring ai rag”“langchain4j rag”在这种模式下都提供了比较成熟的工具调用封装。第三种是多工具协作。知识库只是众多工具之一Agent 手里可能还有 SQL 查询工具、外部 API 工具、工单系统工具。它根据用户意图选择检索哪一类知识再结合其他工具的结果做决策。这套玩法更接近我后面要讲的 Agentic RAG也是目前企业级落地的主流趋势。我个人建议从第二种开始因为第一种很难应付真实业务里多步骤的任务而第三种需要你先把工具层和权限模型设计清楚否则很容易变成“到处搜又到处出错”的失控循环。4.2 多轮对话中的上下文管理与引用溯源Agent 和用户通常不是一轮就结束的。多轮对话里检索的上下文会被历史信息干扰。比如用户先问“我们公司的采购审批流程是怎样的”Agent 检索并回答了“三审制”。接着用户说“那如果金额超过 50 万呢”这条问题单独拿去检索可能搜不到精确答案因为关键在于“50 万”这个限定词而上一轮里的“采购审批流程”其实是不可或缺的查询条件。处理方式通常是把最近几轮对话压缩后生成一个“独立检索查询”。LangChain 的ConversationalRetrievalChain就是这么做的。不过我更推荐自己控制存一个dialogue_summary变量每一轮更新检索时把当前问题 dialogue_summary拼起来给 LLM 改写。这样既能保持上下文又不会把整段历史全部丢进检索器。引用溯源是 Agent 场景里必不可少的一环。你返回的 chunk 上要带source元数据在 Prompt 里要求模型逐条标注 [1][2] 编号并在回答末尾给出引用来源列表。这个设计一方面方便用户信任 Agent 的输出另一方面也是你未来排查幻觉问题时最重要的线索。没有来源标注的 RAG 回答出了问题你都无从下手。4.3 Agentic RAG 是什么从“查一次”到“查得准”Agentic RAG 是最近讨论度很高的方向核心思想很明确检索不再是一条“查完就结束”的流水线而是让 Agent 自主决定“查什么、怎么查、查几次”。它把 RAG 从被动工具升级成了主动的决策过程。具体到实现上我遇到过的典型 Agentic RAG 流程是这样的Agent 先根据用户问题生成一个初始查询调用知识库检索然后它检查召回的 chunks——如果发现没有覆盖关键实体就自动改写查询再检索一轮如果发现回答需要跨两个知识域比如既要技术参数又要价格商务条款就把检索任务拆成多个子检索最后才综合所有片段生成答案。这里面还可能会用到 self-RAG 里“自反射”的机制让模型对自己检索到的信息打分判断是否可靠不可靠就重新检索。有一个例子我印象很深。用户问“能不能把旧款控制器的数据迁移到新款网关”第一轮检索只找到了两个产品各自的说明书没有迁移手册。如果是一般的 RAG模型可能就开始编造迁移步骤了。但 Agentic RAG 的 Agent 发现信息不足主动把查询改成“控制器数据迁移 网关兼容”又检索到一条论坛 FAQ明确了需要先用转换工具导出。整个过程中 Agent 不是在单次检索而是在“检索-评估-调整-再检索”的循环里逼近正确答案。这就是 Agentic RAG 和普通 RAG 的本质区别。4.4 一个完整的 Agent RAG 流程示例我用伪代码来展示我常用的一套简化流程方便你理解整个链路是怎么串起来的def agent_with_rag(user_query, chat_history): # 1. 上下文压缩与查询改写 search_query rewrite_query(user_query, chat_history) # 2. 混合检索BM25 向量召回 Top50 candidates hybrid_retrieve(search_query, top_k50) # 3. 重排精筛 Top5 top_chunks rerank(user_query, candidates, top_k5) # 4. 组装 Prompt带来源编号 prompt build_prompt(top_chunks, user_query, chat_history[-3:]) # 5. LLM 生成 answer llm_generate(prompt) # 6. 检查答案是否引用了来源如果模型说“无法回答”则考虑触发二次检索 if not has_citation(answer): new_query generate_refined_query(prompt, answer) top_chunks hybrid_retrieve(new_query, top_k5) answer llm_generate(build_prompt(top_chunks, user_query, chat_history[-3:])) return answer, top_chunks这段伪代码里最重要的是第 6 步对答案做质量自检信息不足就二次检索。这个“二次检索”就是 Agentic RAG 的最低配实现。你不需要一开始就上很复杂的规划算法先把这个反馈循环跑通再逐步增加“拆解多路检索”“调用 SQL 工具”等能力会更稳妥。5. 实战中的高频踩坑与我的排查清单5.1 切分不合理导致答案碎片化我第一个生产级 RAG 项目上线一周就被业务方吐槽回答经常只有前半句或者把两段不相干的描述强行拼在一起。排查后发现是切分策略的锅。当时我用了固定长度 256 字符切分一个长句子从中间被切开前一段没有结论后一段没有主语。模型读到的都是不完整信息自然回答不完整。解决办法我前面提到过优先按结构切分并在每个 chunk 带上它的父级标题必须固定长度切分时加大 overlap。如果你用的是 LangChain可以看ParentDocumentRetriever——它把文档切得很小去向量化保证检索精准但检索命中后把所属的大段落父文档交给模型生成。这种“查小喂大”的策略对长文档特别管用。5.2 召回噪声与幻觉的对抗手段检索召回的 chunk 不可能百分之百相关。有时你查“报销流程”top1 命中的却是“考勤制度里提到报销”模型就会被带偏。我处理这类问题有三个手段第一在 Prompt 明确“参考资料不一致时以多数来源为准”并要求“不确定的信息不要展开”。第二使用 metadata 过滤比如根据部门、文档类型、发布时间做硬性排除从源头减少噪声。第三引入答案与引用的自洽性校验——让模型输出时强制附带来源编号再让另一个 LLM 或规则检查“回答中的关键断言是否都能在引用 chunks 里找到原文依据”找不到就触发重检索。即使做了这些RAG 也无法做到百分百无幻觉。模型融合信息时依然可能推断出原文没有的因果关系。我的态度是在业务允许的范围内尽量设计“条件回答”——把不确定的部分显式标成“需要人工确认”。在 Agent 场景给用户一个“提交工单”或“转人工”的兜底动作总比让模型硬编一个答案强。5.3 知识库更新的同步难题RAG 的一个隐性成本是知识库维护。文档更新后你不仅要改原始文件还要重新切分、重新向量化并把旧的向量删掉。我见过一个团队用了半年 RAG向量库里已经堆了三个版本的流程文档检索时新老内容互相打架模型回答“既可以这样也可以那样”实际上只有一个版本是对的。我现在的做法是所有文档入库前先计算一个内容 hash作为向量库里的doc_version字段。后台跑一个定时任务检查文档是否有变化如果 hash 变了就把该文档下的旧 chunk 全部删除再重新切分入库。更简单的方案是把所有文档放 Git 仓库里管理每次提交走 CI/CD 流程自动重建索引。对于个人项目你至少也要在代码里给每个 chunk 写上source_id和updated_at否则后期清理起来会非常痛苦。5.4 我的 RAG 调试清单与评估指标RAG 项目没法像传统算法那样靠一个离线指标定生死但也不能全靠肉眼。我自己的调试流程是先准备 20 到 30 个典型业务问题每个问题标注好“标准答案所在的文档块 ID”。然后跑检索算recallk——标准答案块是否出现在前 k 个检索结果里。如果 recall 很低问题大概率在 Embedding 模型、切分策略或查询改写上先调这些而不是急着调 Prompt。如果 recall 不错但生成答案不对问题就在 Prompt 或者上下文组装上。此时我会把检索到的 chunks 原样打印出来人工看一遍确认“有没有证据”。有证据但模型没用是 Prompt 或模型能力的问题没证据但模型答得很溜说明模型在编就需要加强“无法回答”的约束。我还会用 RAGASRAG Assessment这类开源框架做自动化打分忠实度答案是否忠于上下文、答案相关性是否回答了问题、上下文相关性检索内容是否与问题相关。每周跑一遍这个评测集能直观看到管道变更的收益和退化比凭感觉调参靠谱得多。6. 从基础 RAG 走向更聪明的管道GraphRAG 与 Ontology RAG 的启发6.1 向量检索的局限与 GraphRAG 的出现基础 RAG 有一个天然天花板它对“全局性问题”束手无策。向量检索擅长找到“与问题最相似的那段文字”但如果你问“请总结我们公司所有产品线里共用的安全标准”答案散落在几十份文档里没有哪一句话能单独回答。传统 RAG 会给你拼凑出几个片段但没法形成全局洞察。GraphRAG 专门解决这个问题。它的思路是先让 LLM 从文档中抽取实体比如产品、部门、流程节点和实体间的关系比如“关联于”“审批节点是”把这些三元组建成本地知识图谱。然后对图谱做社区检测把关系紧密的实体聚合在一起生成社区摘要。检索时针对全局问题去查这些“社区摘要”针对局部问题则可以沿着图谱的边做路径检索。我这里说一句真实感受GraphRAG 的构建成本比普通 RAG 高不少光是抽取实体和关系就要消耗大量 Token而且抽取质量直接影响效果。所以它适合“需要全局洞察”的场景比如集团知识库、法律合规全文分析而不是所有知识库都应该上。小团队一上来就追求 GraphRAG 往往事与愿违。6.2 Ontology RAG用领域知识约束检索边界热词里有个“ontology rag”引起了我的注意——本体增强检索。这里的“本体”指的是对领域概念和它们之间关系的显式定义比如一个工业企业里“设备”和“保养记录”之间的定义、层级、约束关系。为什么要加本体因为纯向量检索不知道“维修工单”和“备件出库单”之间可能在业务上属于同一故障处理链路它只知道字面相似。Ontology RAG 的做法是把本体作为检索的“地图”。比如检索一个查询先从本体里找到相关概念和别名再扩展查询词或者把本体的规则作为裁剪条件排除在语义上相似但在业务上无关的文档。典型的落地场景是医疗和工业同样是“发热”在“儿科门诊”和“机房服务器”两个本体环境下含义完全不同本体能帮你把检索边界约束清楚。我自己对 Ontology RAG 的态度是如果你的知识领域术语含义很固定、且存在明显的层级关系那值得引入本体如果只是做一个通用问答机器人引入本体的维护成本可能会压过收益。它更像是“垂直领域知识管道”的进阶选项适合与企业内部的业务系统联动时使用。6.3 关于“知识获取管道”的后续扩展思路写完这篇我脑子里还盘旋着一个更大的蓝图RAG 只是知识获取管道的起点。未来的 Agent 会需要更标准化的方式去访问各类数据源——文件、数据库、API、工单系统甚至是另一个 Agent 的知识产出。看起来大家都在往“知识获取协议”这个方向靠拢类似 MCPModel Context Protocol的思路就是把数据访问变成标准化的工具接口让 Agent 可以即插即用地读取不同源的信息。另外知识管道和 Agent 的记忆系统应该合起来设计。短期记忆负责多轮对话的上下文长期记忆负责用户偏好和业务规则而 RAG 知识库则承担“可更新的外部事实库”角色。三者分层各司其职Agent 才能真正像一个有经验的员工那样一边回忆一边查资料一边给出判断。回看这篇从最基础的“为什么要 RAG”讲到了混合检索、重排、Agentic RAG 和 GraphRAG这些内容基本覆盖了搭建一条知识获取管道的全过程。最后分享一个个人习惯每当我准备把新知识接入 Agent 时都会强制自己先写一遍“标准答案从哪一段文档出来”的测试用例再动工写代码。因为 RAG 项目的好坏从来不是代码有多精巧而是你的知识能不能精准、可信、可更新地到达 Agent 手里。 RAG知识获取管道：让Agent学会先查资料再回答
前几天有个朋友拿着他搭好的 Agent 来找我说模型总是对着公司内部的流程文档一本正经地胡说八道——问他财务报销要走什么流程它能编出一套“提交申请表、领导审批、财务打款”但实际流程里还有预算预审和发票校验两道关卡全被它漏掉了。这不是模型不够聪明而是它压根没见过你们公司的文档。大模型的参数里装的是互联网上的公共知识装不下你私有业务里的那些细则。这时候RAGRetrieval-Augmented Generation检索增强生成就派上了用场。作为 AI Agent 系列第四篇我想把“知识获取管道”这个主题讲透——我们如何用 RAG 给 Agent 接上一条通往外部知识库的管道让它在生成答案之前先学会“查资料”。这篇文章适合正在从零搭建 Agent、又苦于模型不懂私有知识的开发者也适合那些听说过 RAG 但还没动手实践的读者。我会从最基础的链路原理讲到检索质量的调优再到 Agentic RAG 的集成思路最后附上实战里踩过的坑和排查清单。全程用我自己的项目语境来说不用教科书语言。1. 为什么 Agent 会“胡言乱语”知识获取管道的必要性1.1 大模型的知识边界与知识割裂问题所有的大语言模型本质上都只是一个“预测下一段文本”的概率系统。训练阶段它会消化互联网、书籍、论文里的公开语料然后把这些知识的统计规律压缩进几十亿甚至上千亿个参数里。这个压缩过程有两个限制一是知识有截止日期模型永远不知道训练集之后发生的新事情二是权重里只能保存高频、共性、结构化的模式那些长尾的、私有的、高度动态的内容会被无差别地模糊化。我跟很多开发者聊的时候他们最常犯的误解是“我本地部署一个开源模型它就能学会我公司的知识”。不行。本地部署解决的是数据私密性和推理成本问题解决不了知识边界问题。你公司的产品手册、自查清单、客服话术、设备参数这些内容在网上根本查不到也不可能凭空出现在训练语料里。想让模型回答这些私有领域的问题就必须在推理时给它“喂”相关内容这就是“知识割裂”的核心矛盾——模型有强大的语言能力但它没有你需要的“事实”。Agent 比单轮问答更依赖知识管道原因在于 Agent 是要动手做事的。它要写邮件、查库存、生成报表、报修设备。每个动作背后都依赖准确的情境知识。一个 Agent 如果只知道“邮件要礼貌”但不知道对这家客户该用哪种称呼、最近有没有欠款纠纷那它写出来的邮件大概率不能直接用。所以知识获取管道不是可有可无的附属组件而是 Agent 能不能在真实业务里落地的根基。1.2 RAG 的本质把检索能力注入生成过程RAG 的思路非常直白不修改模型参数而是在模型生成之前先从你的知识库里检索出与问题相关的文档片段把这些片段拼进 Prompt让模型基于这些“参考答案”来回答。这就像是给学生换了个考试方式——不再是闭卷全靠背而是允许开卷先翻书再答题。一条最基本的 RAG 管道包含三块知识库、检索器、生成器。知识库存放你已经清洗好的业务文档检索器负责在知识库里找到最相关的若干片段生成器就是你的大模型它把“用户问题 检索到的片段”糅合在一起生成最终回答。这三个字说起来简单但工程上的细节极其多。比如知识库怎么切片、检索器怎么打分、检索结果怎么过滤、片段多了会不会把模型冲晕、少了会不会回答不全这些处理不好RAG 就退化成“花哨的倒垃圾工具”。我在后面几章会按一条最小可用的管道一步步展开。这里先把逻辑讲清楚RAG 的价值不在于让模型“记住”知识而在于让模型在需要的时候“找到”知识。这是一种把外部记忆动态挂载到推理过程的方案天然适合 Agent 这种需要实时查证、多步决策的场景。1.3 RAG 与微调、长上下文的选型逻辑总有朋友问那我是不是直接微调一个模型把所有文档塞进去效果更好我的回答通常分情况。微调Fine-tuning适合学习某种风格、输出格式或固定的行为范式比如让模型学会按你们公司的工单模板输出。微调不适合做知识库因为它需要大量标注数据、训练成本高而且每次文档更新都要重新训练更可怕的是模型会把没见过的内容“一本正经地编”出来微调并不能像检索那样轻易追溯到出处。长上下文是另一个诱人的方向。现在的模型动不动就支持 128K、200K token看起来你可以把整本手册塞进 Prompt。但实际用下来有两个问题一是成本急剧上升每次都把所有文档传一遍Token 费用感人二是“中间遗忘”问题——模型对长文本中间的注意力分配不均匀你的答案很可能埋在几千 token 的茫茫文档里模型会抓不住重点。RAG 相当于先做一遍“注意力预筛”把最重要的内容挑出来再让模型聚焦阅读精准度和成本都更可控。下面的表格是我经常用来给团队决策参考的对比方案适用场景主要成本知识更新难度RAG私有知识、政策文档、实时信息、需要溯源向量库搭建与检索调优低更新文档后重新入库微调风格对齐、输出格式、特定行为规则数据标注与训练算力高需重新训练长上下文单篇长文档、一次性分析推理成本高、局部注意衰减中需随文档变化更新在我自己的项目里常见做法是“RAG 为主微调为辅”。Agent 的行为规范比如回复风格、必须用表格输出用微调搞定具体的业务事实一律走 RAG 管道。这样既能保持模型行为的稳定性又能让知识随文档版本实时变化。2. 搭建一条最小可用的 RAG 管道五步流水线实操2.1 文档加载与清洗别让垃圾进管道很多教程会直接从“切分、向量化、检索”讲起但我在项目里最大的体会是文档清洗才是成败关键。知识库里的原始文档格式五花八门PDF 有扫描版、Word 有页眉页脚、HTML 有导航标签、Excel 里还可能藏着公式。你如果直接把这些内容扔进去向量库里会塞满噪音检索出来的东西自然不靠谱。第一步根据文档类型选择合适的加载器。PDF 类我会先试 PyMuPDF 或 pdfplumber扫描版要接 OCRPaddleOCR 这类开源工具就够了Word 和 HTML 用 LangChain 里的加载器或者自己用 BeautifulSoup 提取正文最重要的是去掉页眉页脚、导航链接和脚本片段。清洗阶段我会写几个正则表达式把多余的空格、换行、以及“仅供内部使用”这类页脚信息统一处理掉。还有一个经常踩的坑PDF 里表格数据被还原成一堆散乱文本检索时根本拼不回来。这个要么把表格结构化把表格转成 Markdown 表格要么在切分时设置“表格区块优先级”。我建议把清洗后的文档统一转成 Markdown 或纯文本保留必要的标题层级#、##和列表结构。这样后面做结构化切分会极其方便。2.2 切分策略chunk size 与 overlap 的选择逻辑切分Chunking是整个管道里最容易被低估的环节。切太小一块内容装不下一句完整的意思检索到的信息残缺切太大一块内容包含多个主题语义会被稀释向量表示变得模糊。我做过一次实验同一份技术手册按 200 字切分时检索 Top5 的命中率大约 62%按 512 字切分时能到 78%按 2000 字切分时反而掉到了 55%——因为太大的片段里只有一两句是用户问的向量被其余无关内容拖偏了。实际操作中固定的字符切分不是最优解我更喜欢“按文档结构切分”。比如用 MarkdownHeaderTextSplitter根据标题和段落生成 chunk每个 chunk 带上它的标题前缀这样上下文天然完整。如果没有明显的结构就用递归字符切分设置 chunk_size500、chunk_overlap50 起步再根据测试效果调整。chunk_overlap 的作用是避免两个相邻块把一段完整信息截断在边界上。50 到 100 字的重叠通常够用。这里有一个细节chunk 里最好带上一个“文档来源”的元数据字段。比如{source: 采购管理制度.pdf, page: 3}。后面做引用溯源、权限过滤、按来源排除某些文档时没有这个字段你会非常痛苦。我见过有人把知识库建完才发现没法做部门隔离只能全部重建。2.3 向量化Embedding 模型的选择与维度陷阱切好的文本块要变成向量。向量就是一组浮点数能表示文本的“语义坐标”。语义相近的句子在向量空间里离得也近。Embedding 模型的选择直接决定了检索的底线。以中文业务场景为例我常用的几个模型是模型维度特点text-embedding-3-small1536可降至 512OpenAI 闭源中英文都不错按调用量计费BGE-large-zh1024中文效果好可本地部署M3E / BCE768面向中文的轻量模型本地部署资源占用低text-embedding-ada-0021536老模型中文一般不推荐新项目用选择 Embedding 模型时最容易忽略的是“领域适配”。通用模型对专业术语、品牌名、缩写词往往编码能力不强。比如“RAG”这个词在通用模型里可能会被拆成“r、a、g”三个字母的模糊向量导致检索不到知识库里的“检索增强生成”。如果你的业务领域很垂直比如医疗、法律、化工强烈建议先在真实文档上用小样本对比几个模型而不是盲目跟风。另外维度不是越高越好。高维度向量计算更慢也需要更大的存储空间而且在数据量不够时反而容易过拟合。采用 OpenAI 的嵌入如果你只是做普通业务知识库维度降到 512 经常已经足够。维度变换不会有明显的精度损失但大模型平台的 API 费用和检索延迟会直观地降下来。2.4 存储与索引向量数据库的选型对比向量数据存哪这一步的选择很影响后续运维。我的建议是小项目、个人跑通 demo直接用Chroma或FAISS前者足够简单后者快且免费团队项目或生产环境考虑Qdrant、Milvus或pgvector。其中pgvector特别适合你已经用了 PostgreSQL 的团队直接把向量和业务数据放一起少一个中间件。向量数据库的核心技术是 ANN近似最近邻索引。常见的 HNSW 算法有两个参数M每个节点的连边数和efConstruction建索引时的搜索范围。M 越大召回率越高但索引越大、查询越慢efConstruction 越大建索引越准但耗时越长。实战中我会建议从 M16、efConstruction200 出发然后针对你自己的知识库规模测试。几万条 chunk 和几百万条 chunk 的参数差别非常大不能照搬默认值。选型时还要看过滤能力。Agent 场景往往需要“只能访问某个部门的文档”或者“按发布时间过滤”。这时候向量库是否支持 metadata 过滤就很关键。Chroma 能做但复杂条件过滤性能一般Qdrant 的 payload 索引做得比较完善Milvus 也支持标量向量混合查询。记得先想清楚你的权限模型再选数据库不然后患无穷。2.5 生成链路Prompt 模板与上下文组装管道前面的辛苦最后都要汇聚到生成这一步。检索到的 chunk 不能直接一股脑塞给模型你需要设计一个结构清晰的 Prompt 模板。我常用的模板长这样你是业务助理请严格基于下面提供的“参考资料”回答用户问题。 要求 1. 如果参考资料中有答案请优先引用并标注来源编号如 [1][2]。 2. 如果参考资料中没有答案直接说“根据现有文档无法回答”不要编造。 3. 回答时用中文条理清晰。 参考资料 [1] 来源采购管理制度.pdf第3页 内容... [2] 来源费用报销规范.pdf第7页 内容... 用户问题...这里最关键的指令是“没有答案就直接说不知道”。很多 RAG 项目效果不好不是因为检索不到而是模型在检索到的材料不充分时依然会“自信地”动用参数记忆去补全产生幻觉。你必须在 Prompt 层面强制切断这个路径。组装上下文时要注意 Token 预算。假设模型上下文窗口是 8K我会把系统提示词 用户消息 历史对话控制在 3K 以内给检索到的 chunks 留出 4K 左右最后留 1K 给模型输出。如果超过了先把排序靠后的 chunk 截断再考虑压缩历史对话。否则检索的 chunk 再准模型也读不完前面的工作白费。3. 检索质量才是真正的分水岭召回、重排与混合检索3.1 为什么 top-k 和 score 阈值不能拍脑袋新手做 RAG 最喜欢把top_k设成 4因为教程里写 4。但 4 到底够不够取决于你的知识库质量和业务问题。我遇到过很多次正确答案恰好排在第 5、第 6 位而用户问的是“某型号设备的保修期是多少”前 4 个 chunk 全是设备简介没有保修条款。这种情况下你必须提高召回数量然后再靠重排把真正相关的顶上来。score阈值同样重要。向量检索返回的相似度分数有时候 0.82 才是相关的有时候 0.6 就已经很相关——这取决于 Embedding 模型和知识库内容的一致性。我的做法是先收集一批真实用户问题配上标准答案所在文档跑检索画出分数分布。看看“相关文档”和“无关文档”的分数有没有明显的分界然后在分界点附近选阈值。当然这只适用于你有一个比较完整的测试集。前期没有测试集时先用一个宽松阈值比如 0.3保证召回再做重排防止因为阈值太高把正确答案挡在门外。3.2 混合检索BM25 向量的取舍与融合纯向量检索有一个短板对精确词、缩写、编号的匹配不敏感。举个例子用户问“GL-280A 型号的防护等级”向量检索可能会找到很多关于“防护等级”的文本却错过了含有“GL-280A”的精确文档——因为这个词在向量的语义空间里辨识度有限。这种问题在工业设备、产品型号、法律法规场景中尤其常见。解决办法是混合检索一边用 BM25 这类传统关键词检索去匹配精确术语一边用向量检索去匹配语义相近的内容再把两路结果融合起来。融合我用得比较多的是 RRFReciprocal Rank Fusion公式很朴素score 1 / (k rank_bm25) 1 / (k rank_vector)其中 k 通常取 60。这个公式不看分数绝对值只看排名所以不受 BM25 分数和余弦相似度的量纲影响。我在项目里验证过纯向量检索的召回率约 72%加上 BM25 的 RRF 融合能做到 88% 左右效果非常明显。不少框架已经内置了混合检索组件比如 LangChain 的EnsembleRetriever、Elasticsearch/OpenSearch 的混合查询。如果你的知识库本身跑在 ES 上用它的关键字 kNN 联合查询能省掉很多胶水代码。3.3 重排模型用 cross-encoder 做最后一公里的精筛两路检索合起来可能召回了几十条结果但最后 LLM 只能读有限的几块。这时候“重排”就非常重要。重排模型和 Embedding 模型不是同一个东西Embedding 是把文本块独立编码成向量属于 bi-encoder 范式它高效但精度有限重排模型通常用 cross-encoder把查询和候选文本拼在一起做深度交互输出一个相关性分数精度更高但速度慢。典型的流程是先向量/关键词检索召回 Top50再用重排模型如bge-reranker-large或cross-encoder/ms-marco-MiniLM逐一打分最后取 Top5 进入 Prompt。这一步消耗的时间通常几百毫秒到几秒但对答案质量提升非常显著。我做过对比实验用同一个知识库和同一组 50 个测试问题不重排直接取 Top5答案命中率为 70%用重排模型从 Top50 里挑 5 个命中率提升到 85%。可以说这是性价比最高的调优环节。生产环境如果延迟敏感可以把重排模型部署在 GPU 上或者只对 Top20 做重排。3.4 查询改写把用户的“废话”翻译成检索语言用户的问题往往不是适合直接检索的。比如对话里他问“这个支持远程升级吗”如果直接把“这个”拿去检索什么都找不到。我们需要把这种指代不清的问题结合对话历史改写成一个独立的、语义完整的查询“XX型号网关设备是否支持远程升级”。查询改写我有两种玩法。一种是用 LLM 做改写把最近几轮对话压缩成一段让模型输出一个“站在当下问题视角的搜索查询”再拿这个查询去检索。另一种是 HyDE假设性文档嵌入让 LLM 先基于用户问题幻觉一篇“可能的答案”再拿这篇假设答案去做向量检索。HyDE 在某些语义检索场景效果好但成本偏高我一般只用在前几轮检索结果不理想时的补偿策略。要注意的是改写不是越复杂越好。用户如果问得很具体比如“报销流程里发票校验在哪个步骤”直接检索原始问题就很好。过度改写反而可能引入模型自己的偏见。我在项目里的做法是先判断当前问题是否包含关键实体名词。如果包含就直接用原文如果不完整或有指代词才触发改写。4. 把 RAG 接进 Agent 的决策循环从工具调用到 Agentic RAG4.1 Agent 中 RAG 的几种集成姿势RAG 在 Agent 里的集成方式直接决定了 Agent 的灵活性和可靠性。我见过三种层次的做法第一种也是最简单的Agent 一启动就把检索结果塞进上下文。比如用户问“帮我看看报销流程”Agent 在接到问题后先调用一次检索把“报销流程”的相关 chunk 放进 Prompt再开始规划。这种模式适合任务目标比较明确的场景缺点是 Agent 没法根据中间结果反复调整检索策略。第二种把 RAG 封装成一个工具例如search_docs(query)让 Agent 在规划阶段自己决定什么时候调用。这种方式把检索变成了 Agent 的一项能力Agent 可以先用思维链分析用户问题再决定查哪个库、查什么关键词如果查到一半觉得信息不够还可以再调一次。热词里的“spring ai rag”“langchain4j rag”在这种模式下都提供了比较成熟的工具调用封装。第三种是多工具协作。知识库只是众多工具之一Agent 手里可能还有 SQL 查询工具、外部 API 工具、工单系统工具。它根据用户意图选择检索哪一类知识再结合其他工具的结果做决策。这套玩法更接近我后面要讲的 Agentic RAG也是目前企业级落地的主流趋势。我个人建议从第二种开始因为第一种很难应付真实业务里多步骤的任务而第三种需要你先把工具层和权限模型设计清楚否则很容易变成“到处搜又到处出错”的失控循环。4.2 多轮对话中的上下文管理与引用溯源Agent 和用户通常不是一轮就结束的。多轮对话里检索的上下文会被历史信息干扰。比如用户先问“我们公司的采购审批流程是怎样的”Agent 检索并回答了“三审制”。接着用户说“那如果金额超过 50 万呢”这条问题单独拿去检索可能搜不到精确答案因为关键在于“50 万”这个限定词而上一轮里的“采购审批流程”其实是不可或缺的查询条件。处理方式通常是把最近几轮对话压缩后生成一个“独立检索查询”。LangChain 的ConversationalRetrievalChain就是这么做的。不过我更推荐自己控制存一个dialogue_summary变量每一轮更新检索时把当前问题 dialogue_summary拼起来给 LLM 改写。这样既能保持上下文又不会把整段历史全部丢进检索器。引用溯源是 Agent 场景里必不可少的一环。你返回的 chunk 上要带source元数据在 Prompt 里要求模型逐条标注 [1][2] 编号并在回答末尾给出引用来源列表。这个设计一方面方便用户信任 Agent 的输出另一方面也是你未来排查幻觉问题时最重要的线索。没有来源标注的 RAG 回答出了问题你都无从下手。4.3 Agentic RAG 是什么从“查一次”到“查得准”Agentic RAG 是最近讨论度很高的方向核心思想很明确检索不再是一条“查完就结束”的流水线而是让 Agent 自主决定“查什么、怎么查、查几次”。它把 RAG 从被动工具升级成了主动的决策过程。具体到实现上我遇到过的典型 Agentic RAG 流程是这样的Agent 先根据用户问题生成一个初始查询调用知识库检索然后它检查召回的 chunks——如果发现没有覆盖关键实体就自动改写查询再检索一轮如果发现回答需要跨两个知识域比如既要技术参数又要价格商务条款就把检索任务拆成多个子检索最后才综合所有片段生成答案。这里面还可能会用到 self-RAG 里“自反射”的机制让模型对自己检索到的信息打分判断是否可靠不可靠就重新检索。有一个例子我印象很深。用户问“能不能把旧款控制器的数据迁移到新款网关”第一轮检索只找到了两个产品各自的说明书没有迁移手册。如果是一般的 RAG模型可能就开始编造迁移步骤了。但 Agentic RAG 的 Agent 发现信息不足主动把查询改成“控制器数据迁移 网关兼容”又检索到一条论坛 FAQ明确了需要先用转换工具导出。整个过程中 Agent 不是在单次检索而是在“检索-评估-调整-再检索”的循环里逼近正确答案。这就是 Agentic RAG 和普通 RAG 的本质区别。4.4 一个完整的 Agent RAG 流程示例我用伪代码来展示我常用的一套简化流程方便你理解整个链路是怎么串起来的def agent_with_rag(user_query, chat_history): # 1. 上下文压缩与查询改写 search_query rewrite_query(user_query, chat_history) # 2. 混合检索BM25 向量召回 Top50 candidates hybrid_retrieve(search_query, top_k50) # 3. 重排精筛 Top5 top_chunks rerank(user_query, candidates, top_k5) # 4. 组装 Prompt带来源编号 prompt build_prompt(top_chunks, user_query, chat_history[-3:]) # 5. LLM 生成 answer llm_generate(prompt) # 6. 检查答案是否引用了来源如果模型说“无法回答”则考虑触发二次检索 if not has_citation(answer): new_query generate_refined_query(prompt, answer) top_chunks hybrid_retrieve(new_query, top_k5) answer llm_generate(build_prompt(top_chunks, user_query, chat_history[-3:])) return answer, top_chunks这段伪代码里最重要的是第 6 步对答案做质量自检信息不足就二次检索。这个“二次检索”就是 Agentic RAG 的最低配实现。你不需要一开始就上很复杂的规划算法先把这个反馈循环跑通再逐步增加“拆解多路检索”“调用 SQL 工具”等能力会更稳妥。5. 实战中的高频踩坑与我的排查清单5.1 切分不合理导致答案碎片化我第一个生产级 RAG 项目上线一周就被业务方吐槽回答经常只有前半句或者把两段不相干的描述强行拼在一起。排查后发现是切分策略的锅。当时我用了固定长度 256 字符切分一个长句子从中间被切开前一段没有结论后一段没有主语。模型读到的都是不完整信息自然回答不完整。解决办法我前面提到过优先按结构切分并在每个 chunk 带上它的父级标题必须固定长度切分时加大 overlap。如果你用的是 LangChain可以看ParentDocumentRetriever——它把文档切得很小去向量化保证检索精准但检索命中后把所属的大段落父文档交给模型生成。这种“查小喂大”的策略对长文档特别管用。5.2 召回噪声与幻觉的对抗手段检索召回的 chunk 不可能百分之百相关。有时你查“报销流程”top1 命中的却是“考勤制度里提到报销”模型就会被带偏。我处理这类问题有三个手段第一在 Prompt 明确“参考资料不一致时以多数来源为准”并要求“不确定的信息不要展开”。第二使用 metadata 过滤比如根据部门、文档类型、发布时间做硬性排除从源头减少噪声。第三引入答案与引用的自洽性校验——让模型输出时强制附带来源编号再让另一个 LLM 或规则检查“回答中的关键断言是否都能在引用 chunks 里找到原文依据”找不到就触发重检索。即使做了这些RAG 也无法做到百分百无幻觉。模型融合信息时依然可能推断出原文没有的因果关系。我的态度是在业务允许的范围内尽量设计“条件回答”——把不确定的部分显式标成“需要人工确认”。在 Agent 场景给用户一个“提交工单”或“转人工”的兜底动作总比让模型硬编一个答案强。5.3 知识库更新的同步难题RAG 的一个隐性成本是知识库维护。文档更新后你不仅要改原始文件还要重新切分、重新向量化并把旧的向量删掉。我见过一个团队用了半年 RAG向量库里已经堆了三个版本的流程文档检索时新老内容互相打架模型回答“既可以这样也可以那样”实际上只有一个版本是对的。我现在的做法是所有文档入库前先计算一个内容 hash作为向量库里的doc_version字段。后台跑一个定时任务检查文档是否有变化如果 hash 变了就把该文档下的旧 chunk 全部删除再重新切分入库。更简单的方案是把所有文档放 Git 仓库里管理每次提交走 CI/CD 流程自动重建索引。对于个人项目你至少也要在代码里给每个 chunk 写上source_id和updated_at否则后期清理起来会非常痛苦。5.4 我的 RAG 调试清单与评估指标RAG 项目没法像传统算法那样靠一个离线指标定生死但也不能全靠肉眼。我自己的调试流程是先准备 20 到 30 个典型业务问题每个问题标注好“标准答案所在的文档块 ID”。然后跑检索算recallk——标准答案块是否出现在前 k 个检索结果里。如果 recall 很低问题大概率在 Embedding 模型、切分策略或查询改写上先调这些而不是急着调 Prompt。如果 recall 不错但生成答案不对问题就在 Prompt 或者上下文组装上。此时我会把检索到的 chunks 原样打印出来人工看一遍确认“有没有证据”。有证据但模型没用是 Prompt 或模型能力的问题没证据但模型答得很溜说明模型在编就需要加强“无法回答”的约束。我还会用 RAGASRAG Assessment这类开源框架做自动化打分忠实度答案是否忠于上下文、答案相关性是否回答了问题、上下文相关性检索内容是否与问题相关。每周跑一遍这个评测集能直观看到管道变更的收益和退化比凭感觉调参靠谱得多。6. 从基础 RAG 走向更聪明的管道GraphRAG 与 Ontology RAG 的启发6.1 向量检索的局限与 GraphRAG 的出现基础 RAG 有一个天然天花板它对“全局性问题”束手无策。向量检索擅长找到“与问题最相似的那段文字”但如果你问“请总结我们公司所有产品线里共用的安全标准”答案散落在几十份文档里没有哪一句话能单独回答。传统 RAG 会给你拼凑出几个片段但没法形成全局洞察。GraphRAG 专门解决这个问题。它的思路是先让 LLM 从文档中抽取实体比如产品、部门、流程节点和实体间的关系比如“关联于”“审批节点是”把这些三元组建成本地知识图谱。然后对图谱做社区检测把关系紧密的实体聚合在一起生成社区摘要。检索时针对全局问题去查这些“社区摘要”针对局部问题则可以沿着图谱的边做路径检索。我这里说一句真实感受GraphRAG 的构建成本比普通 RAG 高不少光是抽取实体和关系就要消耗大量 Token而且抽取质量直接影响效果。所以它适合“需要全局洞察”的场景比如集团知识库、法律合规全文分析而不是所有知识库都应该上。小团队一上来就追求 GraphRAG 往往事与愿违。6.2 Ontology RAG用领域知识约束检索边界热词里有个“ontology rag”引起了我的注意——本体增强检索。这里的“本体”指的是对领域概念和它们之间关系的显式定义比如一个工业企业里“设备”和“保养记录”之间的定义、层级、约束关系。为什么要加本体因为纯向量检索不知道“维修工单”和“备件出库单”之间可能在业务上属于同一故障处理链路它只知道字面相似。Ontology RAG 的做法是把本体作为检索的“地图”。比如检索一个查询先从本体里找到相关概念和别名再扩展查询词或者把本体的规则作为裁剪条件排除在语义上相似但在业务上无关的文档。典型的落地场景是医疗和工业同样是“发热”在“儿科门诊”和“机房服务器”两个本体环境下含义完全不同本体能帮你把检索边界约束清楚。我自己对 Ontology RAG 的态度是如果你的知识领域术语含义很固定、且存在明显的层级关系那值得引入本体如果只是做一个通用问答机器人引入本体的维护成本可能会压过收益。它更像是“垂直领域知识管道”的进阶选项适合与企业内部的业务系统联动时使用。6.3 关于“知识获取管道”的后续扩展思路写完这篇我脑子里还盘旋着一个更大的蓝图RAG 只是知识获取管道的起点。未来的 Agent 会需要更标准化的方式去访问各类数据源——文件、数据库、API、工单系统甚至是另一个 Agent 的知识产出。看起来大家都在往“知识获取协议”这个方向靠拢类似 MCPModel Context Protocol的思路就是把数据访问变成标准化的工具接口让 Agent 可以即插即用地读取不同源的信息。另外知识管道和 Agent 的记忆系统应该合起来设计。短期记忆负责多轮对话的上下文长期记忆负责用户偏好和业务规则而 RAG 知识库则承担“可更新的外部事实库”角色。三者分层各司其职Agent 才能真正像一个有经验的员工那样一边回忆一边查资料一边给出判断。回看这篇从最基础的“为什么要 RAG”讲到了混合检索、重排、Agentic RAG 和 GraphRAG这些内容基本覆盖了搭建一条知识获取管道的全过程。最后分享一个个人习惯每当我准备把新知识接入 Agent 时都会强制自己先写一遍“标准答案从哪一段文档出来”的测试用例再动工写代码。因为 RAG 项目的好坏从来不是代码有多精巧而是你的知识能不能精准、可信、可更新地到达 Agent 手里。