做 AI Agent 这段时间我最大的体会是模型本身决定下限知识获取管道决定上限而 RAGRetrieval-Augmented Generation就是这条管道最基础、也最关键的形态。之前几篇我们聊过 Agent 的总体架构、推理循环和工具调用这一篇开始就要花大力气把“知识”这件事拆透。我的经验是几乎所有启动时雄心勃勃的 Agent 项目最后项目难点都集中在同一个地方模型能不能查到、能不能查对、能不能把查到的内容真正用起来。RAG 基础没打牢后面的 Agentic RAG、多智能体协作、复杂工具编排全都是空中楼阁。这篇内容我会从“Agent 为什么需要知识获取管道”讲起沿着文档加载、切分、向量化、检索、生成这一条链路逐一展开再补上我压箱底的评估方法和调优心得最后聊聊从基础 RAG 走向 Agentic RAG 的方向以及本地搭一套可用系统时最容易踩的坑。不管你是在用 LangChain、LlamaIndex、Spring AI还是干脆手写一套这篇的思路都能直接复用。1. Agent 为什么必须有一条知识获取管道1.1 大模型的知识边界参数里装不下整个世界先把结论放在前面大模型的知识是“参数化知识”不是“经历式知识”。你问它“巴黎是哪个国家的首都”它能秒答因为训练语料里到处是这句话你问它“你们公司内部《报销管理办法》第 3.2 条写了什么”它一顿胡编的概率超过八成。原因很简单那条内部制度从没出现在它的训练数据里。更麻烦的是即便不是私域知识公共知识的时效性也是个问题。模型训练到某个时间点就截止了之后的新闻、政策、规格变更它一概不知道。很多人喜欢把大模型想象成一个“什么都知道的博士”但它更像一个闭卷考试的学生——学得再多没背过的题就是不会憋急了还会一本正经地瞎编。这就是幻觉的根源之一。模型不是故意撒谎它只是在“不知道”和“必须给出完整回答”之间被迫选择了编造。而 Agent 和普通聊天机器人不一样Agent 是要行动的是要基于事实做判断的。如果一个 Agent 把幻觉当事实去调用工具、改配置、写结论后果就不是闹着玩的了。1.2 RAG 不是“数据库插件”而是一个完整的能力模块很多人有个误解觉得 RAG 就是“向量数据库 相似度检索”把它当一个外挂存储。但在我理解里RAG 的本质是一条“从外部知识到模型上下文”的管道包含四个环节知识入库Ingestion、索引构建Indexing、检索召回Retrieval、增强生成Generation。前面三个环节解决“能不能查到”最后一个环节解决“能不能用好”。对一个 Agent 来说RAG 的意义不是“塞给它一个数据库”而是赋予它一种可随时调用的能力面对问题时它可以主动去查资料再把资料组织成决策依据。这和直接查数据库完全两码事——数据库查出来的是一行行的结构化记录而 RAG 返回的是与问题相关的自然语言片段需要推理模型再判断怎么用、用哪些。所以我会把 RAG 看成 Agent 的“长期外部知识层”。模型自身参数是它的本能层上下文窗口是它的工作记忆层知识库和搜索工具是它的长期记忆层。三层各有分工RAG 专门负责让长期记忆层变得可用、可信、可持续更新。2. 先把 RAG 的数据侧打通加载、切分与向量化2.1 文档加载格式杂、版式乱是第一个坎做 RAG 时很多人一上来就写切分和检索结果忘了数据侧才是地雷区。我接手过一个内部知识库项目里面有 PDF 制度文件、Word 流程说明、Markdown 技术文档、还有一堆从 Confluence 导出的 HTML。不同格式的处理复杂度完全不是一个量级。先说 PDF。最坑的是两栏排版和扫描件。两栏 PDF 直接用PyPDF2提取文字顺序会被打乱成“左栏全部、右栏全部”切分出来的 chunk 语义完全割裂。扫描件更直接根本提不出文字必须先接 OCR。我现在处理 PDF 的偏好是机器生成的 PDF 用PyMuPDF或marker转 Markdown扫描件用paddleocr或云服务 OCR先出文本再走后续管线。Word 文档要注意的是目录、页眉页脚以及嵌套表格这些都会污染切分结果。这一阶段的经验法则是无论什么格式尽量在提取阶段保留结构化元数据——来源路径、页码、章节标题、作者、日期。后面做元数据过滤、做引用溯源时全靠它们。图文混排的内容也不要急着丢图很多图表信息比正文还关键可以先为图表生成文字描述再入库。2.2 切分策略chunk 大小如何定overlap 怎么用文档加载完下一步就是切分。为什么必须切两个原因一是模型上下文窗口有限你不能把整本手册塞进去二是向量化和检索的粒度问题——如果整篇文档一个向量检索到之后你根本不知道命中的是哪个段落等于没查。切分的目标是让每一个 chunk 尽量像一个“完整的语义单元”。最常用的基线是递归字符切分RecursiveCharacterTextSplitter按分隔符优先级从大到小切分段落、换行、句号、分号。chunk_size和chunk_overlap是两个最关键的参数我的默认起点是 512 或 768overlap 取 64~128。chunk 太小单块信息量不够模型上下文里全是碎片chunk 太小还导致检索时相关片段散落在多个块中拼起来逻辑断裂。chunk 太大一个 chunk 里可能混了好几个主题向量表征被平均化检索精度反而下降。overlap 的作用是保留边界上下文防止一句话被硬生生从中间切开。但 overlap 也不应过大否则相邻 chunk 大量重复召回后组装上下文时冗余太多。实操层面我强烈建议按文档类型设计切分规则而不是全库一把梭。操作手册按“步骤”切SOP 按“流程节点”切技术方案按“章节标题”切。代码和注释最好一起保留表格单独处理甚至可以为表格单独建一条检索通道。另一个值得试的是语义切分Semantic Splitter通过 embedding 相似度判断句子是否属于同一段落。效果确实更好但开销大适合知识库文档不是特别多的场景。2.3 Embedding 与向量库选型各有各的取舍切分完的文本要做向量化也就是 embedding。这块选型直接影响整个管线的上限。Embedding 模型方面我按场景给一个参考英文通用场景OpenAI 的text-embedding-3-small性价比高3-large效果好但贵中文场景建议试试开源的bge-m3或qwen3-embeddingbge-m3对中英混合和长文本都友好还支持稀疏向量和混合检索天然配合。如果数据本身离这几个预训练分布很远比如大量古文、五金件规格、生物医学术语那就拿自己的业务语料微调一个 embedding 模型效果提升非常显著。向量数据库方面不用一上来就上最重的。我的选型阶梯是百级测着玩用 FAISS轻量级原型用 Chroma生产环境中文文档多就 Qdrant 或 Milvus数据库里已经用 Postgres 就顺手加pgvector。不要为了“分布式”而用重组件一个小知识库拿 Milvus 全套武装属实没必要运维成本远超收益。这里有一个极其常见的坑向量维度必须和 embedding 模型严格匹配。bge-m3 输出 1024 维OpenAI 新版模型可能有 1536 维你换 embedding 模型之后如果不重建索引查相似度时维度报错还算好的更多时候是不报错但结果稀烂。还有很多人忽略了纯向量召回对短文本友好对长文档、专有名词密集的内容单靠向量不够要进到检索侧混合方案。3. 真正决定 RAG 上限的是“检索”这一段3.1 查询改写用户不知道自己要什么很长一段时间我都在埋头折腾索引参数结果 hit rate 迟迟不涨。后来静下心看日志才发现问题根本不在文档侧而是用户的 query 是一坨没有上下文的口语碎片。你拿一句“那个政策还能报吗”直接去检索向量空间里和“2023年差旅报销实施细则”的相似度大概率不如预期。解决办法是加一层查询改写Query Rewriting。在进入检索前用大模型结合对话历史把问题补成一条信息完整的独立查询。比如把“那个政策还能报吗”改写成“2023年差旅报销政策中住宿费标准是否仍然有效”。还有一个思路是生成多个子查询把“法律风险和财务风险分别有哪些”拆成“公司合同中的法律风险”和“项目预算中的财务风险”两条分别检索后合并结果。我的实测是给对话型 Agent 加 query 改写hit rate 能提升 5~15 个百分点成本几乎可以忽略。更进阶一点的 HyDEHypothetical Document Embeddings思路是先让 LLM 根据问题写一个“假答案”然后拿假答案的 embedding 去检索。这段话和知识库文档重合词更多所以经常能捞回真答案。但 HyDE 也有副作用——假答案如果幻觉严重会污染语义方向。我自己只在部分场景开 HyDE生产环境默认不启用。3.2 召回策略向量不够混合检索来补向量检索擅长语义匹配但有两个软肋一是对专有名词、编号、精确关键词不敏感。你搜“单据编号 AB-2031”向量检索可能召回一堆“流程单据”泛泛的内容而 BM25词频/逆文档频率稀疏检索能精准命中那串编号。二是向量检索对同义改写有优势对“关键词缺失”却很无力——文档里根本没说“发票”但你的问题里全是“发票”向量检索照样找不到。混合检索Hybrid Search就是把两者结果合并排序通常做法是向量检索拿 TopK 候选BM25 检索拿 TopK 候选用 RRFReciprocal Rank Fusion或加权分数融合两组结果再统一进入重排阶段。我印象很深的一个案例知识库里有两版报销政策用户问 2024 年的标准向量检索总是把 2023 年的旧文一并召回来。后来我在索引里给每条 chunk 打上“生效日期”和“标签”元数据检索时先按元数据过滤问题立刻缓解。混合检索加上元数据过滤是我认为生产级 RAG 的标配没有之一。3.3 重排与上下文组装最后 100 分的关键召回 TopK 一般会取 20~50 条但模型上下文窗口有限不能全塞进去。这时需要重排Rerank。专职 Rerank 模型bge-reranker-base、bge-reranker-v2-m3、Cohere Rerank会对“查询-候选文档”两两打分比 embedding 向量相似度准得多。没有 Rerank 模型时可以临时用 LLM 做二次筛选把候选标题和摘要发给模型让它挑出最相关的 5~8 条。慢一点但关键时刻能救场。重排之后是上下文组装这里有几个容易忽略的细节按相关性从高到低排序组装不要按原文顺序否则模型容易跟着原文顺序跑偏给每条材料编上引用序号 [1][2][3]并在生成指令里要求标注引用后续做溯源审计全靠它控制发送到模型的 token 总量别把 8K 上下文全塞满知识而挤掉对话历史和系统指令在 prompt 里明确写“只依据上述材料回答如果材料不足直接说不知道禁止编造”。这句话是我见过降低幻觉最有效的一行指令。有人觉得组装是 prompt 工程师的事但在我看来它更像系统设计。真实场景里我甚至会把若干不相关的候选文本拆成多条消息分段注入让模型在长上下文里不至于被大量噪音干扰。4. 不建立评估体系RAG 调优就是玄学4.1 拆开测召回侧指标怎么算调 RAG 最忌讳“凭感觉”。今天加了 100 条文档感觉效果好一点明天改了切分策略又觉得差了一点到底差在哪说不上来。正确做法是把链路拆开分别评估检索质量和生成质量。检索侧我日常关注三个指标Hit RateK在 TopK 结果里是否至少包含一条相关文档。最直观常用于快速验证。RecallKTopK 结果中相关文档占全部相关文档的比例。比 Hit Rate 更严格。MRRMean Reciprocal Rank第一个相关文档在结果中排名的倒数。排名越靠前越高。比较实用的做法是构建一组“问题-相关文档 ID”的标注集然后离线跑检索输出上面三个指标。我习惯先看 Hit Rate5。如果 Hit Rate5 不达标就说明问题出在索引或检索链路这时候再怎么调生成 prompt 都没意义。4.2 端到端测回答忠实度比流畅度更重要检索指标好不代表答案对。检索可能是满分但 LLM 在生成时可能张冠李戴把 A 文档的信息说成 B 文档的结论。所以还要做端到端评估重点看两个东西忠实度/幻觉率答案里的每个断言是否都能在召回文档中找到依据。找不到依据的断言就是幻觉候选。引用完整性如果答案里标了 [1][2]那这些引用是否真的指向含有相应论据的片段。端到端评估可以用 LLM-as-Judge 自动打分也可以用人工抽检。我的经验是自动打分适合回归测试人工抽检适合上线前最终验收。你把忠实度维度单独拆出来后会发现很多知识库“回答很流畅”但“其实都在胡说”的问题这比召回率低了更致命。4.3 一份可复制的评估集构建流程评估集怎么建我建议按业务场景手工造 50~100 条问题覆盖三个层次单点事实查询比如“XX产品最大功率是多少”跨文档综合查询比如“对比 A 和 B 两个方案的成本结构”否定查询也就是知识库里没有答案的问题专门用来测“不知道时会不会装懂”。建集时挑 20~30 篇代表性文档找业务同学按文档内容提问题并记录答案来自哪几篇文档。这样生成的问题天然有答案依据可直接用于召回指标计算。每次调整切分、重排、prompt 之后都跑一遍回归用同一套评估集对比新旧指标。没有这套东西所有优化都只是你的主观运气。5. 从 RAG 到 Agentic RAG获取管道开始有“判断力”5.1 Agent 自主规划检索拆 Query、选工具、判中止基础 RAG 是“一次检索一次生成”。到了真实 Agent 场景这个模式经常不够用。用户问题往往是模糊的、多跳的。比如“我们项目想用新方案帮我评估可行性和成本影响”你可能需要先检索新方案的技术文档再检索当前基础设施现状最后检索财务审批流程。这串动作不是一个静态 RAG 管道能覆盖的需要一个能自主规划检索的 Agent。Agentic RAG 的思路就是让大模型扮演检索编排者它先判断“要不要查”、“先查什么”、“用什么工具查”拿到第一批结果后继续判断“结果够不够”、“还要不要再查一轮”直到信息集齐再统一生成回答。实现上可以是简单的 ReAct 循环也可以引入 Rewriter、Retriever、Grader 三个独立模块协同工作。Grader 模块负责判断当前召回结果能否回答原问题不能就继续发起新的检索。这个“评估-再检索”的循环是 Agentic RAG 相比基础 RAG 最大的增量。我自己的体会是Agentic RAG 的价值在复杂问题场景下极其明显但代价也很明显延迟变高、成本变高、出错点变多。所以不要一上来就全部业务都上 Agentic RAG。把问题分类简单问题走直线 RAG复杂问题才启用多步检索性价比更高。5.2 GraphRAG 与 Ontology RAG解决知识割裂传统向量检索有一个天然缺陷知识割裂。每个 chunk 是独立向量彼此之间没有关系链。当问题需要跨文档、跨节点推理时向量检索往往只能拿到局部片段回答出来的东西缺乏全局结构。GraphRAG 的思路是从文档中抽取实体和关系构建知识图谱再结合图谱的社区聚合路径来检索和生成。典型场景“某供应商供应了哪些产品其中哪些产品被某方案使用并包含某种关键属性”——这种多跳关系问题纯向量检索很难一次命中图谱结构则天然适合。微软开源的 GraphRAG 实现已经能直接跑值得一试。Ontology RAG 则是在图谱上加一层本体约束把实体类型、关系类型、属性定义显式固化下来。比如产品、供应商、价格、库存这些概念及它们的关系要先建模再驱动信息抽取和检索。对结构化程度较高的领域ERP、产品库、合规文档本体约束能显著提升检索稳定性和可解释性也方便和现有业务数据模型对齐。“知识割裂”这个问题最近在社区里讨论得越来越多我自己实践后的结论很明确如果要回答“知识关系型问题”Ontology RAG 或 GraphRAG 是绕不开的单纯优化 chunk 和向量库边际收益会越来越低。5.3 RAG 与 Skill/Tool 组合从“查资料”到“办事情”Agent 语境下 RAG 很少孤立存在它通常长成一个或多个 Skill技能。一个技能是“查询产品知识手册”另一个技能是“查询本地 ERP 的实时库存”再一个是“调用计算器算折扣”。RAG 解决的是“静态知识检索”Tool Calling 解决的是“动态状态获取和动作执行”两者要配合使用。拿一个我最近做的本地 ERP 产品检索项目举例产品规格放知识库走 RAG 检索库存数量调 ERP API 实时获取。Agent 先检索产品手册确定有哪些规格型号再拿着型号查询库存接口最后汇总成“有货/无货/可替代型号”的结论。这个过程中 RAG 不是终点而是给后续工具调用提供参数和依据。理论框架上这也是从“查资料”到“办事情”的能力跃迁——Agent 可以基于知识做决策再通过工具执行动作最终把知识管道和执行管道闭环到一起。如果你的 Agent 项目基于 Spring AI 这类框架开发可以把 RAG 检索封装为一个工具函数同时注册查询类工具函数让 Agent 在推理循环中自行选择调用。这样 RAG 就不再是“一次检索一个答案”的静态环节而是 Agent 工具箱里一个可随时按需调用的独立能力。6. 一套本地可落地的参考选型与踩坑记录6.1 技术栈选型对比与推荐很多朋友问我自己搭一套 RAG Agent 到底该用什么技术栈。给一个我自己常用的选型表纯属个人经验供参考场景推荐组合优点注意快速验证/学习LangChain FAISS OpenAI/bge-m3上手快示例多生产可用性低FAISS 单机内存控制注意中文文档知识库LlamaIndex bge-m3 Qdrant bge-reranker中文效果好检索可控Qdrant 要用 Docker 持持久化Java 背景团队Spring AI pgvector BGE和现有 Java 服务整合顺滑向量搜索能力偏弱复杂检索需自己补充企业级生产自研管线 Qdrant/Milvus BGE/Rerank 评估平台可控性最好效果上限最高开发量大需要维护 CI 评估我自己多数项目以 LlamaIndex 或纯手写方案为主。有人觉得框架省事有人觉得框架是黑盒我的看法是先用一个成熟框架把链路跑通边跑边拆开看每一层在做什么。等你已经能解释链路每一步原理的时候再决定继续用框架还是手写。手写一套最简 RAGEmbedding FAISS Prompt也就一百来行代码作为深入理解特别有价值。6.2 高频踩坑清单与规避建议最后列几个我实际踩过、且周围同行也频繁踩的坑Embedding 维度不匹配。换用模型后忘记清空旧索引向量相似度必崩。建议把 embedding 模型名称作为索引元数据保存每次启动做一致性校验。切分策略用“统一模板”。不同文档类型共用一个切分参数结果长文档语义流失、短文档碎片化。建议先做文档分类再按类型配置切分规则。检索到了但上下文被截断。召回 TopK 太大组装后超过模型上下文长度。Rerank 之后硬性限制注入 token 总量超出部分果断丢弃。混合检索权重只看效果拍脑袋。向量和稀疏得分量纲完全不一样合并前必须先归一化或用 RRF。否则 BM25 结果几乎永远排不上去。知识库更新后索引不重建或重建策略粗暴。全量重建成本高增量更新又容易漏 chunk。生产环境建议引入版本管理按批次更新索引并保留回滚能力。没有停用词和标点清洗。直接向量化包含大量符号噪声的文本会拉低检索精度。切分前后各做一轮文本清洗成本极低但收益稳定。版本升级不兼容。向量库或 embedding 库升级后原有索引文件可能无法读取。升级前务必先备份索引并做兼容验证。这些坑大多数都是“刚开始用没问题数据量上来之后突然暴雷”。我在实际操作中学到的习惯是所有索引和中间数据都带上版本号所有检索参数和评估结果都落到日志里。这样万一副本回退至少能知道是哪个参数导致的效果漂移。RAG 这条知识获取管道一旦搭好后面给 Agent 加再多的技能和工具心里都有底这条管道没搭好Agent 的每一项后续能力都会建立在随时会裂开的地基上。