以我自己的实操经验先给这个“走进 AI Agent”系列定个调很多人学 Agent一上来就冲规划、多智能体协作、工具调用这些花活结果连最基础的知识获取都没打通Agent 就是个只会聊天、一问正经事就瞎编的空壳。所以第四篇我专门写RAG也就是检索增强生成它是 Agent 连接外部知识的“取水管”决定你的机器人到底是“有脑子的助手”还是“复读机”。这个内容能解决什么问题简单说就是让大模型在回答时不再只靠训练时的那点记忆而是能从你指定的文档、数据库、网页里实时把相关内容捞出来再结合问题生成答案。适合谁看准备从零搭 AI Agent 的开发者、在折腾本地知识库的工程师、以及想搞懂 RAG 原理、不想被各种概念忽悠的产品和技术同学。下面我把管道怎么设计、代码怎么写、坑怎么踩一次说透。1. 先把知识获取这件事掰开揉碎1.1 Agent 为什么需要 RAG 这条管道要理解 RAG得先想清楚一个问题大模型的知识是“死”的。训练完成那一刻它的知识就冻结了。你问它今天天气它不知道你问它公司内部某个项目的上线日期它不知道你问它一个 2025 年才发布的研究成果它大概率还是不知道甚至开始一本正经地编。Agent 和普通聊天机器人最大的区别在于“要干活”。干活就得依赖准确、及时、可追溯的信息。这时候我们有几个选择让模型重新训练去更新知识成本太高不可能天天训让模型上网搜能拿到实时信息但没有定向性和可靠性搜出来一堆营销号垃圾也没辙。RAG 的思路更务实把知识从模型里“搬出去”放到一个可检索的外部存储里模型在回答前先查资料再把资料作为参考依据来生成。我常给身边同事打一个比方模型是学生RAG 是开卷考试时的参考书。你不需要把整本书背下来但知道去哪一页找答案翻到之后照着答还能在答案后面批注“见第几章第几节”。这不光是提高准确率更是让 AI 的回答“有据可查”这在企业落地场景里几乎是必须的。1.2 从“聊天式 RAG”到“Agent 化检索”的转变初学 RAG 时会看到一个经典流程用户提问系统去知识库检索拼进 Prompt模型生成答案。这个流程适合问答机器人但放到 Agent 场景里是不够的。因为 Agent 有自主决策权它可以自己决定“我现在需不需要查知识”“查完这个要不要再查那个”。我把这两者的区别总结为“被动检索”和“主动检索”。普通 RAG 是“每个问题都检索一遍”Agent 则可以根据任务拆解在不同阶段触发不同的检索动作。比如说让 Agent 写一份产品竞品分析报告它可能会先检索“我们产品的技术白皮书”再检索“竞品公开资料”两步检索可能要拼装成不同的上下文甚至要判断某些资料是否可信、是否过时。这就是热词里常说的Agentic RAG。后面我会详细展开但你先记住一个核心认知RAG 不是给 Agent 外挂的一个“搜索按钮”它是 Agent 的长期记忆和工作台检索的时机、粒度、策略都应该由 Agent 的目标来驱动。知识获取管道说白了就是让 Agent 知道“该去哪儿拿知识、拿到什么程度、怎么用知识”的完整链路。2. 知识获取管道的整体设计与几个硬选择2.1 索引、检索、生成到底哪一段最影响效果任何一套 RAG 系统拆到底都是三个大件索引构建把文档切成小段、转成向量存进向量数据库。检索根据用户问题找出最相关的若干条片段。生成把检索到的片段和问题一起交给大模型产出最终回答。三条链路各有各的坑但以我实测经验80% 的 RAG 效果问题都出在索引构建上。很多人拿到文档随手一切就灌进向量库后面检索出来的内容牛头不对马嘴还怪模型不行。其实模型是无辜的你喂给它的材料本身就没切好。索引构建里最要命的决定是切分粒度。比如一份技术手册按固定字符数切可能把“函数定义”和“函数说明”切到两段里检索时只召回后半段模型根本不知道参数是什么意思。按语义段落去切又可能切出几千字的超长片段向量检索的关联度被稀释。我的建议是“默认走 Markdown 标题或段落结构切分再结合业务的问答粒度微调没有万能参数必须试”。向量化模型的选择同样关键。现在主流用 BGE、M3E、OpenAI embedding 这一类的模型中英文混合场景需要特别关注模型对中文的语义覆盖度。有些英文模型转中文向量近邻检索结果一看就是谐音梗聚会完全没法用。这属于典型的基础设施选型失误不是在调参能救回来的。2.2 技术栈选型LangChain、LlamaIndex 还是自己拼确定完 RAG 的大方向就得选实现框架。我见过不少团队一上来就全盘抱 LangChain理由是“生态全”结果项目后期被框架的抽象层折腾得够呛。我的选型原则一向是“按需使用不要为了框架而框架”。如果以 Python 为主、要快速验证 ideaLangChain 和 LlamaIndex 都可以个人偏 LlamaIndex它本身就以“文档索引”为核心对 RAG 场景抽象得更好。如果团队是 Java 技术栈、要接 Spring Cloud 那套体系Spring AI 的 RAG 支持已经可用LangChain4j 也是主流方案不要强行跨语言层。如果是大型企业要做统一知识服务甚至可以考虑把 RAG 封装成独立服务这就是热词里提到的“RAG as a service”由平台团队统一管理文档接入、权限、索引策略业务团队只管调用。我自己的习惯是核心链路可以手写。因为框架帮你省的是“胶水代码”的时间但也框死了你的控制力。文档切分、检索逻辑、提示词组装这些核心动作手写一遍能让你对每个环节发生什么了如指掌。实际落地时可以先用框架做原型跑通后再把慢的、不对劲的地方替换成自己的实现。2.3 向量数据库和混合检索的取舍向量数据库是 RAG 的存储底座。市面上可选的不少Chroma、FAISS 适合本地轻量场景Milvus、Qdrant、Weaviate 适合规模化和云原生场景。选型标准无非看三点支持的数据量、检索性能、是否方便做过滤。但这里有个误区很多人以为 RAG 就是“向量检索”其实关键词搜索的价值被严重低估了。例如检索一段包含型号“A1-200B”的技术参数向量模型经常把 A1-200B 和 A1-200C 混在一起关键词却能精准命中。所以成熟方案普遍走混合检索向量检索负责捞语义相近内容BM25 或全文检索负责捞字面精确匹配再用 RRF倒数排名融合或重排序模型把两路结果合并排序。我在一个智能客服项目里做过对比实验单独用向量检索的命中率hit rate大概 68%叠加关键词检索后能到 88%再加重排能冲到 94%。这个过程很能说明问题RAG 每一步微调效果都是肉眼可见的。3. 核心环节逐层拆解从文档加载到上下文组装3.1 文档加载和清洗垃圾进垃圾出RAG 的起点是喂文档。这一步看起来没有技术含量却是最容易埋雷的环节。PDF 排版混乱、扫描件缺字、Word 里的文本框丢失、网页上的导航栏混入正文这些都是常见坑。你需要根据公司实际文档形态开发一套加载清洗流程目标是“只把该留的正文留下来”。我的经验里必须处理三类脏数据页眉页脚和重复导航栏它们是天然的噪声会让切分后的每个片段都带着无关信息乱码字符和特殊符号会干扰向量化表格。表格是 RAG 的老大难直接把 Markdown 表格灌进模型经常丢行错列我建议对大表格做结构化提取把每个表格转成自然语言描述再入库。这一步做到位的判断标准是你随手抽一个片段看它是否单独拿出来就是一个有信息量的完整表达。如果片段读起来前言不搭后语就别指望模型能从里面学到什么。3.2 切分策略的实操要点文档清洗完就进入切分。切分时要考虑的不是“多少字一段”这个数字而是“切出来的片段是否语义自洽”。实操中我按优先级使用三种策略结构切分优先按标题层级、段落、列表项、表格边界切分能保留章节上下文。滑动窗口切分对结构不明的文本设定块大小如 512 字、重叠 64 字保证边界信息不那么突兀。父子切分父块是整章或整节子块是更小的内容单元检索时命中小块上下文却带上大块的内容。这种方式非常适合技术文档因为一个概念往往要结合前后文才能解释清楚。切分完毕还需要做一轮元数据标记。比如这个片段来自哪个文档、哪个章节、什么时间、针对什么产品线。元数据在后续检索时会发挥大作用尤其是做权限过滤或业务筛选时没有它你只能把所有文档混在一起检索。3.3 向量化、存储和检索参数和算法都别将就向量化的目标是把文本变成一串浮点数让语义相近的文本在向量空间里靠得近。Embedding 模型的选择我建议直接在 MTEB 这类排行榜上筛选适合自己语言场景的模型而不是道听途说。切分好的一批文档先跑一个小的相似度抽查人工看几组检索结果比任何理论指标都直观。存储方面如果团队已经用了 ES现在的 ES 也支持向量检索算是兼顾关键词和向量的折中方案。如果从零搭建Milvus 这种专用向量库能省去很多运维心力。检索时相似度算法通常用余弦相似度但向量检索召回的结果默认只能看“距离”并不能区分“绝对不相关但距离近”和“高度相关但距离稍远”的细微差别。所以新增一层重排是性价比极高的做法召回 20 条重排后只取前 5 条送给模型效果往往比直接取前 5 条好一截。我统计过一个病案知识库项目的检索实验结果用 BGE-large 做 embeddings、设置 Recall 20 Rerank 5Top-5 命中率比直接取 Top-5 高 11 个百分点。这里多说一句重排模型的推理成本比 embedding 高但它是管道的最后一道闸门这个开销花得值。3.4 怎么把上下文组装进 Prompt才不会让模型“飘”检索做完剩下的就是生成。可很多人偏偏在最后一步翻车。模板大概是“请基于以下资料回答资料...”。问题在于上下文塞得太满模型抓不住重点塞得太杂模型容易把不相关内容也编进答案甚至你要问的问题和检索材料不匹配时模型还理直气壮地硬答。我现在的做法是尽量给模型制造“翻译”的语境先让它把资料里与问题最相关的部分摘出来再让它据此作答并在 Prompt 里明确写上“如果资料里没有充分依据请直接说不知道”。这样做的效果比直接命令“你必须根据资料回答”好很多。本质上是把“从资料中找根据”这个隐性任务显式化模型完成质量会更高。另外生成时不要把原始问题丢给模型就完事。很多场景需要先做一轮问题改写把“它的故障率如何”改写成“产品型号 X 的年度故障率指标是多少”再进入检索召回效果天差地别。这一步在 Agentic RAG 里往往是 Agent 自己完成的。4. 实操5 分钟从零跑通一条本地 RAG 管道4.1 技术选型和准备这里我演示一条适合本地起步的完整管道技术栈选 Python LlamaIndex Chroma BGE embedding。为什么这么选LlamaIndex 对文档索引和检索的抽象做得顺手Chroma 零配置跑本地BGE 模型对中文友好、可以本地离线跑不依赖外部服务。先准备环境Python 3.10 以上安装依赖库pip install llama-index chromadb torch transformers sentence-transformers如果你想把 embedding 换成国内模型也可以直接加载 BGE 系列。这个环境在小内存机器上也能跑就是切大文档时慢一点不影响演示。4.2 构建索引的核心代码先加载文档我建议直接让 LlamaIndex 用默认的加载器处理 txt 或 markdownfrom llama_index.core import SimpleDirectoryReader, VectorStoreIndex, Settings from llama_index.embeddings.huggingface import HuggingFaceEmbedding from llama_index.vector_stores.chroma import ChromaVectorStore import chromadb # 设置本地 embedding 模型 Settings.embed_model HuggingFaceEmbedding( model_nameBAAI/bge-small-zh-v1.5 ) # 读取文档目录 documents SimpleDirectoryReader(docs/).load_data() # 初始化 Chroma 客户端 db chromadb.PersistentClient(path./chroma_db) chroma_collection db.get_or_create_collection(my_knowledge) vector_store ChromaVectorStore(chroma_collectionchroma_collection) # 生成索引 index VectorStoreIndex.from_documents( documents, vector_storevector_store, )注意目录下不要混入临时文件和隐藏文件否则加载器会全部吃进去索引里出现一堆乱码。4.3 检索和问答的代码实现索引构建好后检索问答就很简单了query_engine index.as_query_engine(similarity_top_k5) response query_engine.query(BGE 模型支持的最大序列长度是多少) print(response)similarity_top_k5表示从库里取最相关的 5 个片段。默认的 query engine 其实已经封装了检索、组装 Prompt、生成答案的全过程适合快速验证。但真实场景下我更喜欢把它拆开操作便于定位问题retriever index.as_retriever(similarity_top_k10) nodes retriever.retrieve(BGE 模型支持的最大序列长度是多少) for node in nodes: print(node.node.get_text()[:200]) print(score:, node.score)先打印检索返回的片段确认材料对不对再决定要不要把全部片段直接送给模型。很多诡异问题看一眼原始检索结果就明白了。4.4 本地知识库管道优化的几个直接做法基础管道跑通之后可以从三个方向快速提效果把切分调成“按段落切”而不是“按固定字数切”尤其是 Markdown 文档LlamaIndex 支持 MarkdownNodeParser可以用它替代默认切分。检索前加一个问题改写比如把口语化问题补全成技术文档的检索用语。给索引加元数据过滤器比如只检索特定目录或特定标签的文档。这些都是低成本高回报的改动。但我要提醒你不要一上来就追求 GraphRAG、知识图谱这种高阶玩法。先把这个线性管道做到极致再看需求决定要不要引入更复杂的结构。5. 常见问题、排查思路与调优实录5.1 检索效果差第一步不是调模型而是看切分我在一个合同审查 Agent 项目里遇到过典型问题用户问“违约金比例”检索回来的片段全是“合同双方约定违约金比例不超过 30%”但合同里的具体条款是被拆开的模型拼不回去答非所问。排查过程很简单直接把检索结果打印出来发现命中片段里缺失了上下文部分。这让我把切分策略换成父子切分让检索时带上父块信息。效果立竿见影。所以排查 RAG 问题时永远先去“看检索中间结果”而不是直接怪生成模型。这一步能省你一半的调参时间。5.2 hit rate 低、召回率差的常用解法“hit rate”就是命中率指问题相关文档片段被检索出来的比例。平时我们总说“检索不准”其实就是 hits 不够。解法优先级我排一下切分和 embedding 不匹配先换 embedding 模型单路向量检索不够加关键词检索召回数量太少从 5 调到 20再用重排模型把前 3 条选出来相关性判断太粗改为给每个片段加业务权重例如产品手册比新闻稿优先级高。这些动作按顺序逐个试每次只改一个变量保留测试集记录变化。RAG 优化最怕“一次改三样”出了问题你根本不知道是哪一步的功劳。5.3 模型仍然幻觉和胡说该怎么堵住RAG 已经给了知识模型却还是编多半是上下文和指令的问题。我有个土办法在 Prompt 里加一句“如果资料中没有描述该内容直接回复‘知识库中没有相关信息’不要推测”它确实能硬性压住一部分幻觉。另外一定要观察模型实际看到了什么。有些框架会把“检索到的内容”和“历史对话”一股脑塞进去上下文里混着用户早期说的错误信息模型就被带偏了。解决办法是限制上下文只保留与当前问题最相关的内容减少干扰。如果模型反复从资料里抽取数字却算错账就别让它直接算改为先抽取关键参数再用代码计算。这一步已经是把一个单纯 RAG 升级成拥有工具调用能力的 Agent 了也是绕过模型弱点的经典策略。5.4 常见问题速查表现象可能原因首选排查动作检索结果不相关embedding 模型不适合领域人工查看 Top-10 相似片段答案合并多段信息时出错切分粒度太碎上下文丢失切分策略改父子切分专业术语检索不到向量模型对术语不敏感叠加 BM25 关键词检索模型回答和资料不一致Prompt 约束不足显式要求“资料无依据就直说”同义改写后检索变差问题改写丢失关键实体检索前做实体/关键词保留多个文档主题混杂缺少元数据过滤按文档类型/部门加过滤条件这张表基本覆盖了从入门到进阶的第一批坑。遇到问题先对着表定位别一上来就重新训练模型。6. 从基础 RAG 走向 Agentic RAG检索成为能力而不是流程6.1 把检索封装成 Agent 可以调用的工具如果你按前面的内容搭好了基础 RAG下一步不是去做知识图谱而是先让 RAG 变成 Agent 的一个“工具”。在 Agent 框架里一个工具是有名字、有描述、有入参出参的函数。比如定义一个名为“knowledge_search”的工具描述为“用于检索内部技术文档和产品手册”参数是查询字符串。为什么要这么做因为基础 RAG 是“每问必检”而 Agent 能自己判断“这个问题需不需要查知识”。有些简单事实性问题模型直接答更快有些需要最新数据的问题Agent 就会主动调用检索工具。这样既省成本又避免无关检索干扰生成。我在一个企业内部问答 Agent 里把文档检索做成工具后Agent 还可以先检索“是否有相关规范”再检索“该规范对应的模板”两个检索之间夹杂其他操作这是普通 RAG 流程根本做不到的。6.2 自我反思、问题改写和多轮检索的落地套路Agentic RAG 的进阶玩法是让 Agent 参与检索质量的闭环。典型的流程是Agent 拿到用户问题先做意图分析决定用哪个检索策略把原始问题改写成适合搜索的查询这步可以交给大模型自己完成检索后Agent 自评“这些资料足够回答问题吗”不够就换一个角度再检索最后汇总多次检索结果组织答案。这就是热词里常说的自我反思和多轮检索也是 GraphRAG、Ontology RAG 这些概念兴起的原因。结构化知识确实能提升复杂问题的回答能力但初学阶段不建议碰连线性管道都没调好就上知识图谱只会多出一堆调度和维护成本。6.3 与 Skill 机制结合让知识获取带业务逻辑现在 Agent 框架里流行 Skill 机制也就是把某个业务能力做成一段可复用的带 Prompt 和工具定义的“技能包”RAG 完全可以作为一个 Skill 嵌入进更大的 Agent。比如我有客户在 ERP 系统里做产品检索就是把“产品参数检索”和“库存状态查询”封装成两个 Skill一个做 RAG 检索一个去查数据库Agent 通过决策把它们拼成完整回答。这里的关键点是RAG 不应该是一个孤立的 service而是知识管道里的一个环节它的上层有业务规则下层有数据治理。只有当 RAG 和 Agent 的其他工具协同起来知识获取才真正“管道化”。一些个人体会我从做第一个 RAG demo 到现在最大的感触是RAG 的资料和风口远没有 T恤上印的那么光鲜真正决定落地效果的是数据库整理、切分调优、检索评估这些脏活累活。很多人问我要“最好用的 RAG 框架”我通常回一句框架只是帮你省掉从 0 到 1 的时间从 1 到 100 全靠你对文档、对业务的理解。如果你现在正准备从零搭建 Agent我的建议很直接先用五页以内的文档跑通管道再逐步加文档类型、加元数据规则、加 Agent 决策。每一个环节都打印中间结果给自己看肉眼确认过的东西才可信。RAG 这条管道没有放之四海而皆准的参数但它有一条放之四海而皆准的原则——检索只是手段知识真正被用上才算数。