Agent 必备知识管道：检索增强生成（RAG）原理与工程实践

前几篇我们把 Agent 的“骨架”搭起来了：模型怎么规划、工具怎么调用、记忆怎么设计。当时我就留了一个尾巴——Agent 如果只吃模型脑子里那点参数知识，它其实是个“没读过书的实习生”。你让它回答自家产品的限流阈值、内部流程、某个私有协议的细节，它只能硬着头皮编，编错了就是幻觉。把外部知识接进来的这套东西，业界通行的名字叫 RAG，Retrieval-Augmented Generation，检索增强生成。说白了就是四个字的逻辑：先查后答。这一篇作为“走进 AI Agent”的第四篇，专门拆这条知识获取管道，要讲清楚它到底解决什么问题、管道每一段在干什么、从 0 到 1 怎么搭一个能用的版本，以及我跑各种 RAG 项目时踩过的一堆坑。适合正在把 Agent 从 demo 往真实业务推的人读，不管你是后端转 AI，还是算法补工程，这篇都能给你一个完整的坐标系。

1. 为什么 Agent 必须有一条知识获取管道

1.1 模型的知识边界，就是你幻觉的上限

先说一个我几乎每次分享都会被问到的问题：“大模型不是已经很强了吗？什么都知道，直接问不就行了？”

这里藏着一个核心误区。模型“知道”的东西，是它训练时见过的东西，这叫参数化知识。它有两个硬伤。第一，训练数据有截止时间。今天刚上线的功能、昨天刚发布的公告，模型一概不知道，你再问它也只会用旧知识猜。第二，训练数据天然偏向公开的、通用的内容。你自己公司的技术文档、业务报表、历史项目复盘，这些私有信息，模型根本没见过。

这两个硬伤叠在一起会发生什么？你在 Agent 里接一个能力很强的模型，然后问“我们 V2.3 版本的迁移步骤”。如果这个问题不在它知识范围内，它不会老老实实说不知道，而是会用最通顺的语言编一个听起来极其专业的答案——这就是幻觉。模型不是坏，是它被设计成“必须回答”。所以 Agent 必须有一条通道，在回答之前先把外部知识“喂”进来。这条通道就是知识获取管道，目前最成熟的标准实现就是 RAG。

1.2 RAG 在 Agent 架构里到底算什么

你去看各种 Agent 架构分析，会看到五花八门的拆分：规划（Planning）、记忆（Memory）、工具（Tools）、行动（Action）。那 RAG 算哪一类？我自己的理解是，RAG 一半属于记忆系统，一半属于输入基础设施。

为什么说一半是记忆？因为 Agent 的长期记忆，如果不用 RAG，就只能靠对话历史或者小规模缓存撑着，完全装不下真实业务里的文档资产。几千页的文档你想全塞进上下文，物理上就不现实，成本更不现实。但你可以把“和当前问题最相关的两三段内容”实时捞出来，塞进去。这本质上就是一次记忆检索调用，只不过检索的载体是向量索引，而不是人脑里的海马体。

另一半为什么是输入基础设施？因为 RAG 的输出直接决定模型“看到什么”，而模型看到的上下文质量，直接决定推理质量。你的 Agent 规划得再严谨、工具链铺得再完善，如果知识管道的出水口是脏的，下游全是白搭。这两年我反复跟团队强调一句大白话：RAG 不是锦上添花，它是和模型同级别的核心组件，只不过一个管“怎么想”，一个管“拿什么想”。

1.3 长上下文、微调和 RAG，到底该选谁

这两年模型动不动就宣称上下文窗口支持几百 K、甚至 1M。于是很多人动起了念头：我把整个知识库全塞进 prompt，是不是就省掉 RAG 了？或者，我干脆微调让模型“背下来”，是不是更彻底？

三个方案我都实际对比过，直接给结论。

我见过特别典型的反面案例：有人为了省事，把三百页的产品手册整本塞进 prompt，结果关键参数被淹没在大量背景介绍里，模型注意力被稀释，回答质量直线下降，最后花的 token 钱还不少。RAG 的本质是筛选器，它保证模型只看最该看的那几段。记住，模型不是看得越多越好，是看得越准越好。

1.4 合格知识管道的三条验收标准

聊完选型，我们得明确一下什么叫“合格”。我一般用三条标准验收任意一条知识获取管道。

首先是准确性：给定一个验证集，系统检索出来的片段到底有多少真正包含标准答案。这个可以用 hit rate 量化，后面会细讲。其次是新鲜度：文档改了之后，多久能反映到检索结果里。最后是可控性：任何一个回答，能不能追溯到具体原文片段。三条都过，这条管道才算能进生产。

2. 认识这条管道：RAG 的四段式结构

RAG 这个名字听着学术，管道的骨架其实特别朴素：先把知识切碎并做好索引，收到问题后从索引里捞相关内容，最后把“问题 + 相关资料”一起交给模型生成答案。我习惯拆成四段：接入清洗、切分向量化、检索重排、生成溯源。每一段都有单独的坑，这一段道行深一点，整体才稳。

2.1 第一段：知识源接入与清洗

很多人把 RAG 项目失败归结于“向量模型选得不够好”，但按我的实测，超过一半的问题出在最前面的接入环节。

你手里的知识源不会乖乖是干净的 Markdown。PDF 里可能混着页眉、页脚、水印；Word 里嵌着一堆嵌套表格；HTML 里有导航栏和广告正文。真实业务里还有那种扫描版 PDF，本质是一张张图片，连文字都抽不出来。这一段落后的质量，直接决定后面所有环节的上限。垃圾进，垃圾出，这五个字在 RAG 里体现得淋漓尽致。

实际操作上，我一般从三类工具里挑：规则排版清晰的 PDF 用 pdfplumber；Word、HTML、PPT 这类混合格式交给 unstructured 统一处理；扫描件先过 PaddleOCR 做文字识别，再做版面还原。清洗环节至少干掉目录、页眉、页脚、重复段落和乱码字符。很多团队觉得“先跑起来再说”，结果检索出来的片段前言不搭后语，最后骂 RAG 不行——其实文档压根是脏的。

2.2 第二段：切分与向量化

把文档变成模型能检索的东西，先要切块，这个动作叫 chunking。为什么不能把整篇文档当一个块？因为你的检索目标是“语义相关的片段”，而块越大，里面无关信息越多，向量化之后的语义就越平均，检索精度就越差。但块太小也不行，太小会切断上下文。比如一段 API 调用参数说明，如果散落在三个块里，拿到的每一块都不完整，模型拼不出全貌。

我目前常用的经验值是：通用说明文档切 512 token 左右，带 50-80 token 重叠；代码文档按函数或类边界切；合同、法规这类强结构文档按条款切。数值不是玄学，要根据文档粒度来定，后面我给实战调参思路。

切完块就得向量化，也就是每个块用一个 embedding 模型转成一组高维浮点数。向量的物理含义，你可以理解成把一段文本映射到一个“语义坐标空间”，意思相近的文本坐标靠得近。这个空间长什么样，是 embedding 模型“画”出来的。选型上，国产开源的 bge-m3、m3e、gte 都是我很常用的；商用接口当然也行，但私有部署场景优先考虑本地模型，不然每次灌文档都要过一道网，数据安全上不安稳。

2.3 第三段：检索与重排

知识切碎、向量化、入库之后，就进入检索阶段。用户提问时，系统把问题也转成向量，去向量库里找“语义距离最近”的前 K 个片段，这个 K 通常叫 top_k。

这里有个特别关键的点：向量检索并不是万能的。它是语义搜索，对数字、编号、精确术语经常无能为力。比如用户问“BUG-2040 的处理记录”，文档里满屏是 BUG-2039、BUG-2041、BUG-2040，向量距离几乎分不出区别，反而是传统的 BM25 关键词匹配能直接命中。所以现在主流做法是混合检索（hybrid）：向量负责语义近邻，BM25 负责字面命中，两边结果合并再去重。你真想把命中率做上去，混合检索是绕不开的一步。

合并之后，我还会加一道重排。检索出来的候选可能有一两百个，但真正有资格进上下文的只有五六个。embedding 模型这种双塔结构，在做“候选和问题谁更相关”的精细排序时，先天不如 cross-encoder 重排模型。重排模型会把候选逐对和问题算一遍精细相关性，重新打分挑出前排。这一步是工程上最容易被忽略、但收益最高的单项优化。bge-reranker 这类开源模型实测效果已经很稳。

2.4 第四段：生成与引用溯源

最后一段反而简单，但简单不代表不重要。把检索到的候选片段按固定模板组装进 prompt，交给大模型生成最终答案。

有两个细节值得单独讲。第一，prompt 里必须明确告诉模型：“只能根据提供的资料回答，资料里没有的，直接说不知道。”不加这个约束，模型还是会靠“本能”输出一个华丽但不可靠的答案，前面检索做得再好也白费。第二，给每个片段编号，强制模型在答案里标注来源编号。好处是用户能自己点开原文核对，一旦答错了，排查链路会非常短，你立刻能知道是哪个片段误导了模型。

到这里 RAG 管道的全貌就很清楚了：在生成之前，先做一轮高质量的信息挑选与组织。管道每一段的输出质量都会传导到最终答案，所以你不能只在某一个环节用力，得整条链路一起调。

3. 从 0 到 1 搭建一个最小可用 RAG 管道

理论讲再多，不动手都是隔靴搔痒。这一节我从零带你把一条最少依赖的 RAG 管道跑起来。为了把原理讲透，我故意不引入 LangChain 这类重型框架，直接用 Python 手写核心流程。框架以后随便换，但底层逻辑必须自己过一遍。

3.1 环境准备与数据选择

先准备三样东西：一段文档、一个 embedding 模型、一个向量存储。

数据建议选你自己最熟悉的文档练手。比如你手头某个产品的操作手册，或者干脆挑一套开源项目文档。第一次跑别贪多，五页十页就够，关键是走通整个流程。我对所有入门者都强调：小数据跑通一次完整闭环，比拿大数据折腾一周更有价值。

向量存储我用 Chroma，本地运行，pip 一条命令装好，数据自动落盘，对新手最友好。等真正上生产，再迁到 Milvus、Qdrant 这类独立服务，或者直接用 PostgreSQL 的 pgvector 插件，那都是后话。Embedding 模型选 bge-m3 或者 m3e 都行，HuggingFace 直接下载，加载进本地推理，不依赖外部网络。我强烈建议你在项目目录里建虚拟环境隔离依赖，不然装一套 RAG 下来，全局 Python 环境基本就废了。

3.2 核心代码实现与运行过程

我用一个极简但完整的流程演示，整个代码可以分四步看。

第一步是读取并清洗文档。假设你拿到的是一份 Markdown 格式的操作手册，直接按行读进来，以空行作为段落边界，粗切成自然段落。如果是 PDF，就用 pdfplumber 逐页抽文本再做清洗。这里我省略 OCR 和复杂版面处理，毕竟是最小实现，够用就行。

第二步是切块并向量化。我对自然段落做一次长度控制：每 400 个字符切一块，前后重叠 80 个字符。为什么是 400 而不是 512 token？因为中文语境里，一个汉字大约对应 0.6-1 个 token，400 字符大概等于 250-400 token，对大多数说明文档是安全区。这个值后续要用验证集去调，现在的目标只有一个：先跑通。

第三步是向量化并写入 Chroma。用 sentence-transformers 加载 embedding 模型，把每个 chunk 转成向量，再调用 collection.add 写入。这里有一个特别容易被忽略的细节：每个 chunk 入库时，必须带上 meta 信息，比如来源文件名和段落编号。没有这一步，后面想溯源就得哭。

第四步是检索并生成。把用户问题做同样的向量化，调用 collection.query 取出 top_k 个结果，然后把问题和结果一起拼进 prompt，交给大模型生成答案。我写一段核心代码，你照着自己改一版：

from sentence_transformers import SentenceTransformer import chromadb # 1. 加载 embedding 模型（本地推理） model = SentenceTransformer("BAAI/bge-m3") # 2. 准备文档 chunks，并记录来源元信息 chunks = [ "API 限流规则：默认每用户每分钟 60 次请求，超过返回 429。", "限流阈值可在控制台调整，调整后一分钟内生效。", "若需要更高配额，请提交工单并说明业务场景。", ] metas = [{"source": "faq.md", "idx": i} for i in range(len(chunks))] # 3. 向量化并写入本地向量库 client = chromadb.PersistentClient(path="./rag_demo_db") collection = client.get_or_create_collection(name="demo") vectors = model.encode(chunks).tolist() collection.add( ids=[str(i) for i in range(len(chunks))], embeddings=vectors, documents=chunks, metadatas=metas, ) # 4. 检索：问题同样向量化后查库 question = "限流阈值能改吗？" q_vec = model.encode([question]).tolist() results = collection.query(query_embeddings=q_vec, n_results=2) for doc in results["documents"][0]: print(doc)

这段代码跑完，你会发现检索结果里有“限流阈值可在控制台调整”这一条——这就是语义检索命中的直观体验。后续生成部分也不复杂：接 OpenAI 兼容接口，用常规 chat 接口调用，在 system 提示词里写清楚“基于以下资料回答问题，并标注来源编号；如果资料中没有答案，直接说未找到”，然后把检索到的原文拼进用户消息里。这一步的 prompt 写得松不松，直接决定模型会不会自由发挥。

3.3 参数调优：给管道做一次量化体检

管道跑通只是起点。我见过太多项目“能出结果”就当成功，结果一问就露馅。实际上 RAG 效果是可以量化的，最简单也最实用的指标是 hit rate，也叫命中率。做法是准备一批“问题-标准答案片段”的验证对，然后看检索结果里有多少对真的把标准答案片段捞上来了。这一步做完，你对管道的真实水平心里就有底了。

我建议建一个 50-100 对的验证集。然后你会很惊喜地发现：同样一批数据，chunk 大小不同、top_k 不同、有没有重排器，命中率会有肉眼可见的差距。我贴一组自己早期实测的对比：

调参这件事没有奇技淫巧，就是拿同一批验证集，一次改一个变量，跑完记录结果。命中率如果低于 70%，先别急着调生成侧，回头查检索侧——大概率是切分、embedding 或者重排其中一个环节出了问题。

4. 常见问题与排查技巧实录

老实讲，我在 RAG 项目里踩过的坑，绝对比成功经验多。这一节把最容易撞上的几类问题整理成速查清单，希望你能绕开。

4.1 明明文档里有答案，检索却捞不到

这是最让人崩溃的一类问题。症状很典型：你随便抽一个文档片段去问，系统答不上来，但你打开向量库一看，文档又确实都在。

排查按顺序走。第一步，检查 chunking 是否把关键上下文切成了两半。比如“如果调用失败，请先在控制台开启调试模式，再重试”这句话，如果被拦腰切断，单看任何一半都理解不了。第二步，看 embedding 模型和领域的匹配度。通用模型对中文长文还行，但对代码、医疗术语、金融术语经常抓不准，这种场景要么换领域模型，要么上多路召回。第三步，加混合检索。特别是含编号、型号、日期、精确参数的问题，BM25 往往一击命中，而向量检索只能给你一个“感觉相似”的片段。

还有一个很隐蔽的坑：用户的口语化提问和文档的书面表达之间存在词汇鸿沟。比如文档写“工单升级”，用户问的是“我这问题能不能加急”。单轮检索通常无能为力，这时候需要做 query 改写，把原始问题拆成几个子问题分别检索再汇总。这其实就是从普通 RAG 走向 Agentic RAG 的一个很自然的动机。

4.2 检索到了，生成答案还是错的

这类问题最气人，因为资料明明就在上下文里摆着，模型却给了一个风马牛不相及的答案。

我总结下来，原因大多出在三处。第一，top_k 设得太大，上下文太长，无关片段干扰了模型注意力。第二，prompt 没有做硬约束，模型默认进入“自由发挥模式”。第三，片段没有来源编号，模型根本不清楚自己的用词应该以什么为准。

对症的药引子就六个字：约束、溯源、精简。prompt 里强制写“只能依据资料回答、不得推测、资料没有就回答未找到”，同时要求答案中标注来源编号。把 top_k 从 8 降到 5，把无关候选切掉。这样改完之后，我实测模型胡说的概率大幅下降，而且万一还错，你也能立刻定位是哪个片段误导了它，排查效率翻倍。

4.3 生产环境里的性能、权限与更新问题

把 RAG 从 demo 推上线，会再遇到三座山。

第一座是增量更新。知识库不是静态的，今天加一条 FAQ，明天改一个参数，你不能每次都全量重建索引。低成本方案是给 chunk 加版本号或时间戳，只更新增量部分，删除用 meta 精确标记。第二座是权限隔离。真实业务里，不同角色能看的知识不一样，这必须在检索引擎层就用过滤条件筛掉，不能等到拼完 prompt 再后悔。Chroma 的 where 条件、Milvus 的 partition 都能做。第三座是缓存。高频重复问题，可以直接把问题和答案一起缓存，省掉一轮检索加一次模型调用，成本下降非常可观。

我还见过有人把几千个 PDF 一次性灌进去，索引构建跑了十几个小时，中途崩了一次。最后排查发现，是某个大 PDF 里嵌着几千张图片，解析器把图片当成无文本页面反复处理。这种脏数据问题，与其写一百行清理正则，不如在接入环节做“采样检查”——随机抽几页人工过一遍，效率高得多。

4.4 什么时候该升级 Agentic RAG 和 GraphRAG

如果你的 RAG 已经稳定运行，但有几个边界场景搞不定，才需要考虑升级。

需要多轮询问、子问题拆解、工具式检索的场景，属于 Agentic RAG 的范畴。它本质上是把 RAG 从一个“函数”改造成一个“会规划的流程”：模型根据问题决定先查用户文档，还是先查订单系统，还是拆成几个小问题分别查再汇总。这已经不只是知识获取，而是知识策略。

另一种场景是强关系型知识，比如几十个项目之间的依赖关系、组织架构、产品-模块-功能的层级。普通向量检索把每个片段当孤岛，GraphRAG 则把实体和关系建图，能回答“A 模块会影响哪些下游”这类关系问题。最近大家常聊的 ontology RAG，本质就是增加一层本体约束让关系图更规范。但这类方案构建成本高，我强烈建议先把普通 RAG 跑透、把指标测到位，再谈升级。一上来就搞 GraphRAG 的项目，我见过的九成是给自己找麻烦。

最后再多说一句我的实际体会。RAG 这东西，门槛不高，天花板很高。绝大多数团队的问题不是模型不够强，而是知识管道的输入侧一团浆糊：文档没清洗、切分没策略、检索没混合、输出没溯源。我到现在仍保留着一个习惯：每批文档入库前，随机抽几段用肉眼读一遍。这个习惯帮我躲过了至少十次线上事故，每次都有惊喜，也每次都有惊吓。希望这篇能帮你把知识获取管道的每个环节都抠明白，让 Agent 从“会说”变成“真知道”。