做 Agent 做到这个系列第四篇，终于轮到许多朋友最关心的知识获取问题了。之前几篇聊过 Agent 的规划、工具调用、记忆，但大家动手搭 Agent 时最容易卡住的反而是另一件事：模型推理再强，它依然不知道你们公司内部的业务细节。前阵子有个朋友让我帮看他的客服 Agent，问产品手册里的型号参数时总是胡编，比如问“XX-200 的防护等级是多少”，模型能一本正经给出一个根本不存在的数据。我一看，问题根本不在推理，而在知识获取管道是断的。到今天为止，AI Agent 的知识获取最成熟、最通用的方案仍然是 RAG，全称 Retrieval-Augmented Generation，检索增强生成。这篇文章就把 RAG 基础拆开讲透：它到底解决什么问题、索引阶段怎么做、检索阶段怎么调、怎么接到 Agent 工作流里，再加上我实际跑项目时踩过的坑。适合正准备做知识库问答 Agent、或者已经照着网络 Demo 跑通但效果不理想的开发者。
1. 大模型答不好领域问题，不是因为它笨，而是因为“没资料”
1.1 知识过期、幻觉、无法溯源：本质上是一场闭卷考试
你可以把大模型想象成一个读过很多书、但记性不稳定的考生。平时你问它常识性问题，它答得头头是道，因为那些知识在训练阶段见过。可一旦你问的是“我们 2025 年 Q3 的价格表”“内部合同编号规则”“设备维护手册第七页的参数”，它就傻眼了。原因很直接：这些内容根本不在它的训练数据里，或者只存在于某个隐蔽角落但早就过时了。
这就解释了幻觉为什么必然发生——模型面对不知道的问题，最自然的反应是“编一个看起来合理的答案”，因为它的训练目标就是生成连贯文本，而不是承认自己不知道。你如果不给它参考资料，它就只能闭卷硬答。所以很多人以为是 prompt 写得不够好，拼命加“请不要胡说”之类的约束，效果依然有限。真正的问题不是态度，而是信息源。
RAG 的思路是把它从闭卷考试变成开卷考试。系统先从一个外部知识库里检索出与问题相关的文档片段，再把这些片段拼到上下文里，让模型基于这些资料作答。这样做有三层价值：知识可以随时更新，不用重训模型；回答有出处，能溯源；幻觉发生的概率大幅下降，因为模型是被“喂着答案”答题的。
1.2 RAG 和微调怎么选：先做管道，再做“性格调教”
很多人一提到“让模型懂业务”，第一反应就是微调（Fine-tuning）。我在社群答疑时经常遇到这种思路，但说实话，大多数场景下微调并不是第一步。把两者放在一张表里对比，选择就会很清楚：
| 维度 | RAG | 微调 |
|---|---|---|
| 知识更新 | 改文档、重索引即可，分钟级生效 | 需要准备训练集、重新训练，周期以天计 |
| 幻觉问题 | 显著缓解，因为生成有上下文依据 | 缓解有限，模型仍可能凭记忆发挥 |
| 溯源能力 | 天然支持，可以指出引用来源 | 很难回答“你从哪学来的” |
| 数据量要求 | 几十篇文档就能见效 | 通常需要大量高质量问答对 |
| 成本 | 主要是向量检索资源和 Prompt Token 开销 | 训练和推理部署成本高 |
我的结论是：领域知识优先用 RAG，微调更适合做“性格调教”，比如让模型固定输出格式、模仿某种语气，或者把特定行业的表达习惯内化进模型。你甚至可以两者结合，但顺序一定是先建 RAG 管道，把检索做扎实，再考虑要不要微调。
1.3 RAG 在 AI Agent 中的定位：知识获取管道
在 AI Agent 的整体架构里，RAG 不是独立单点，而是一条标准的知识获取管道。它和普通 API 工具有一个本质区别：API 工具返回的是直接可执行的结果，而 RAG 的检索结果只是“参考资料”，最终还要交给模型去阅读、理解、归纳成答案。
你可以把它理解成 Agent 团队里配了一个“内部资料管理员”。Agent 是那个负责分析问题、制定计划的项目经理，它手里的工具列表里有文档搜索、数据库查询、代码执行等技能，其中“知识检索”就是 RAG 服务。当项目经理发现用户的问题涉及公司内部知识时，就向资料管理员说：“帮我查一下相关材料”，拿到资料之后再决定怎么组织答案。这个比喻也解释了为什么 RAG 在 Agent 里最自然的接入方式是工具调用，而不是写死在主流程里，后面我会专门展开。
2. 索引阶段：让文档变成 Agent 能“读懂”的向量记忆
2.1 文档接入：先解决“数据能不能被正确解析”
RAG 管道的第一步不是向量化，而是把文档变成干净、结构化、可检索的文本。这一步被很多人跳过了，网络教程通常直接拿现成的 txt 文件演示，但真实项目里全是 PDF、Word、网页、表格，甚至扫描图片。
我踩过的第一个坑就是扫描版 PDF。某些设备手册是扫描图转成的 PDF，文字根本不存在，直接解析出来是一堆空白。当时我没检查，结果 80% 的检索结果都是垃圾。正确处理方式是先做 OCR，用 PaddleOCR 或 Tesseract 把图片转成文字再进管道。另外一个常见问题是表格。Word 里的表格如果按普通文本抽取，行列关系全丢，检索时会把表头和表体拆开。我现在的习惯是：解析阶段优先考虑版面分析工具，比如 Unstructured 或者 PyMuPDF 抽取结构，表格尽量转成 Markdown 格式保留语义；网页内容则要抓正文主体，把导航、广告、版权信息全部过滤掉。
这一阶段花的时间可能占整个项目的 40% 以上，但非常值得。因为 RAG 的上限由文档质量决定，解析不干净，后面所有调优都是给一栋歪楼装修。
2.2 切分：chunk 太小没上下文，太大有噪声
文本解析完之后，不能整篇塞给模型，因为大模型上下文窗口虽然越来越大，但向量检索的输入长度和相关性精度都有上限。切分（Chunking）是决定 RAG 精度的重要关口。
先讲参数含义。chunk_size 是每个切块的最大长度，比如 512 tokens；overlap 是相邻块之间的重叠长度，比如 50 tokens。为什么要重叠？因为文档在切分处可能被拦腰截断，比如一个段落讲到一半被切开，后半块缺少前文的主语，检索到它时模型看不懂。重叠能在一定程度上保留上下文连续性。
更重要的其实是“怎么切”。我强烈建议不要无脑按固定长度切，而是按语义结构切。Markdown 标题感知切分是性价比最高的：按章节、小节边界切，如果某节内容太长再递归切大块。LangChain 的 RecursiveCharacterTextSplitter、LlamaIndex 的 SentenceSplitter 都支持这种思路。如果文档里有代码块、表格、列表，也要尽量把它们作为完整单元保留。
| 切分方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 固定字符切分 | 简单、快 | 容易切断语义 | 纯文本、无结构内容 |
| 递归字符切分 | 保留常见边界 | 对复杂文档仍会误切 | 通用默认选择 |
| 标题/段落感知切分 | 保留章节语义 | 需要文档结构清晰 | Markdown、技术文档 |
| 语义切分 | 按语义边界切，效果好 | 计算成本高 | 对质量要求高的场景 |
中文场景还有个细节：token 计算方式不同。中文一个 token 通常对应一到两个汉字，如果你按英文文档的习惯把 chunk_size 设成 1024，实际切出来的中文块会比想象的大很多。我通常从 300 到 500 tokens 开始试，再结合手动观察结果调整。
2.3 Embedding 选型：中文场景别乱用模型
切分完的文本要变成向量，这一步靠 Embedding 模型。Embedding 的作用是把一段文本映射成高维向量，让语义相近的文本在向量空间里距离更近。模型选型对 RAG 效果的影响非常大，而且没有免费的“通用最优解”。
常见的选项有这些。OpenAI 的 text-embedding-3-small 是英文场景的默认选择，但直接用在中文上效果一般；中文场景建议用专门优化过的模型，比如 bge-m3、bge-large-zh、gte-Qwen2 系列。bge-m3 是目前中文社区用得最多的一个，支持最长 8K 输入，多语言效果好，而且有现成的本地部署方案。如果你对数据安全有要求，或者文档涉及敏感信息，本地部署 embedding 模型是更稳妥的做法。
这里有一个很容易被忽略的原则：查询侧的文本和文档侧的文本，要用同一个 embedding 模型。很多人会把用户输入的 Embedding 和服务端文档的 Embedding 用不同模型生成，导致相似度计算在语义空间里“牛头不对马嘴”。另外，向量维度也不是越高越好，维度高的模型匹配效果更好但存储和计算成本都上去了，很多项目 1024 维已经够用。
2.4 向量数据库选型：从 Chroma 到 Milvus，按场景定
Embedding 生成的向量需要一个地方存起来并支持检索，这就是向量数据库的活。选型直接看你的项目阶段，不必一步到位上重型系统。
我自己的经验是：练手项目直接用 Chroma，pip install 就能跑，几十行代码完成入库和检索，非常适合跑通流程。原型验证阶段可以用 FAISS，它是内存索引，速度快，但数据量大了之后持久化和集群能力不行。如果你的团队已经有 PostgreSQL，想省一个中间件，pgvector 是个务实选择，它在现有数据库里加一个向量列就能用。生产级场景再考虑 Milvus、Qdrant 或 Elasticsearch，这几个支持高并发、丰富的过滤条件和混合检索。
这里重点提一下 Elasticsearch。很多人对它的印象停留在“全文搜索引擎”，但新版 ES 自带向量检索，可以同时支持 BM25 关键词检索和 KNN 向量检索。这对 RAG 项目太重要了，因为实际开发中你会发现“关键词匹配”和“语义匹配”缺一不可。关于混合检索，下一章细说。我的建议是：先别沉迷选型，用 Chroma 把整条链路跑通，确认业务瓶颈到底在检索精度、并发量还是运维复杂度，再决定要不要换库。过早引入重系统只会拖慢开发节奏。
3. 检索阶段：命中率，才是衡量知识管道的硬指标
3.1 向量检索的原理和一个关键误区
索引建好之后，查问题时就进入检索阶段。流程是把用户的问题也用同一个 Embedding 模型转成向量，在向量数据库里找距离最近的 Top-K 个文档块，通常用余弦相似度作为距离度量。说白了就是高维空间里找“邻居”。
但这里有一个关键误区：向量检索不等于万能语义理解。它对专有名词、编号、型号、人名这类信息并不敏感。比如用户问“那个额定电流 3A 的型号是什么”，文档里写的是一个设备参数，且整段没有直接出现完整的“3A 型号”这样的字符串，纯向量检索很可能召回一堆“电流”相关但不相关的段落。反过来，如果用户直接说“XX-200 的防护等级”，向量模型可能识别了 XX-200 和防护等级，但如果你同时有大量相似型号的文档片段，它们之间的向量距离其实很接近，相似度就分不开。
这也是为什么很多项目“照着教程跑通了，效果却很一般”——教程里的 demo 问题是“什么是 RAG？”这种大而泛的问题，向量检索能轻松命中。但真实业务问题往往是精确、指代性强的，这时候单靠向量相似度就露怯了。记住一句话：向量检索负责语义泛化，关键词检索负责精确匹配，两者要互补。
3.2 Hit Rate 怎么算，为什么它直接决定 RAG 上限
聊 RAG 效果，首先得有个量化的尺子。Hit Rate（命中率）是我看的第一指标，定义是：在测试集里，标准答案对应的文档块是否出现在检索返回的 Top-K 结果中，出现则计为命中，总体命中的比例就是 Hit Rate。
举例来说，你准备了 100 个“问题-答案文档块”组成的测试集，检索时每条取 Top-5，如果 100 条里有 80 条在 Top-5 中能找到标准答案块，那么 Hit Rate 就是 80%。之所以说它决定 RAG 上限，是因为检索都没命中，生成模型再强也只能瞎编，后面无论怎么调 prompt 都救不回来。反之，如果命中率已经 95% 以上，你就可以把优化重心放到生成端，比如控制格式、减少冗余，而不是继续调检索参数。
我见过很多团队把大量时间花在调 prompt 上，却从没统计过自己的 Hit Rate。这是本末倒置。建议建项目第一天就准备一个 50 到 100 条的 golden set，之后每次改动切分参数、Embedding 模型、检索方式，都重新跑一遍 Hit Rate，让每个决策都有数字支撑。
3.3 混合检索和 Rerank：检索质量提升最快的两板斧
如果你的 Hit Rate 卡在 70% 到 80% 上不去，大多数情况下缺的就是混合检索和 Rerank。先说混合检索。思路是同时跑两路召回：一路是传统的关键词检索，BM25 算法，对型号、编号、人名等精确字符串非常有效；另一路是向量检索，对语义近义词、同义表达更擅长。然后把两路结果用 RRF（Reciprocal Rank Fusion）做融合排序，也就是根据每条结果在两路召回中的排名打分合并，排在越前面的综合得分越高。
我用一个例子说明效果差异：用户问“那个支持双频的型号”，假设文档里写的是“支持 2.4GHz 和 5GHz”，纯向量检索很可能命中这段（语义匹配成功了）；但用户问“WG-602 支持什么频段”，纯向量检索可能会被文书里其他 WG 系列设备干扰，而 BM25 对字符串“WG-602”极其敏感，一下子就把正确的文档块拉回来了。两者一融合，检索覆盖范围宽了很多。
Rerank 则是更精细的一道工序。前面的粗召回把候选切块扩大到 50 条甚至 100 条，Rerank 用一个交叉编码器（Cross-Encoder）模型把“问题+候选文本”拼在一起，逐条计算相关性分数，再取分数最高的 Top-5 返回给模型。这类模型如 bge-reranker-v2-m3 比普通向量检索精确得多。它的缺点是多了一步打分，延迟会高几十毫秒，但相对检索质量提升而言完全值得。我在项目里几乎是无脑加 Rerank 的，尤其文档数量超过 100 个之后，效果从 72% 的 Hit Rate 直接提到 90%。
3.4 查询改写和多路召回：针对难问题的补充手段
有些时候 Hit Rate 低不是因为检索模型不行，而是用户的问题本身太“口语化”或者太“复合”。常见救命手段有两个。
查询改写是让一个小模型先对用户问题进行改写，再去做检索。比如用户问“之前讨论过的那个安全方案你还记得吗”，这句话直接拿去检索基本废了。我会先用一个轻量模型把它改写成“历史讨论:安全方案 主要措施”这种适合检索的形式，命中率立刻提升。改写可以做得更复杂，比如拆出关键词、补全缩写、翻译成英文再检索，但核心原则是“检索时的查询句子要和文档的表述风格接近”。
多路召回则是把复杂问题拆成多个简单查询分别检索。比如用户问“A 方案和 B 方案哪个性价比高”，一次性检索很难同时兼顾两个方案和成本信息。正确做法是拆成“A 方案 特点”“B 方案 特点”“A B 方案 成本”三路检索，把结果去重合并后再交给模型。我之前做开发文档问答时，凡是遇到“对比”“结合”“以及”这类词，都会下意识拆多路，效果比只在 prompt 里要求“请全面回答”好得多。
4. 把知识管道接到 Agent 工作流里：从单次 RAG 到 Agentic RAG
4.1 一次性检索的局限：Agent 需要“按需取用”
基础 RAG 流程是一条直线：问题进来，检索一次，生成回答。这在单个事实类问答场景下够用，但接到 AI Agent 工作流里就会碰壁。
举个具体例子。用户说：“帮我对比一下 A 方案和 B 方案，重点看成本，结合我们上季度的数据给个建议。”这个问题里，模型需要回答“A 方案是什么”“B 方案是什么”“它们的成本数据”“上季度公司数据”四块信息。一次性检索很难把四块信息同时拉全，即便强制 Top-K 拉到 20，大量无关内容也会把有效信息稀释成噪声，模型的注意力被分散，生成质量直线下降。
Agent 的做法应该不一样：它先把任务拆解，第一步检索 A 方案资料，第二步检索 B 方案资料，第三步检索成本相关数据，每一步都拿到精确结果后再综合。这种“让 Agent 自己决定何时检索、检索几次”的形式，就是不折不扣的 Agentic RAG。它不是替代基础 RAG，而是在基础管道外面包了一层 Agent 决策逻辑。
4.2 路由、工具调用与 Skill：RAG 在 Agent 里的标准接法
要把 RAG 接入 Agent 工作流，最标准的做法是把它封装成 Agent 的一个工具（Function / Tool），而不是写死流程。这样 Agent 可以在规划阶段决定“这个问题是否需要知识库”，而不是每次都无脑检索。
这里有个细节叫路由（Routing）。很多简单问题并不需要 RAG，比如“你是什么模型”。如果每次调用都走一次知识库检索，既浪费算力，还可能把无关内容塞进上下文造成干扰。路由可以用大模型判断，也可以用 embedding 相似度做一个“知识库意图匹配”的过滤，后者便宜且快，适合高频请求。
当你发现某个领域的检索有固定套路时，可以把这些套路封装成 Skill。比如医疗 QA 领域的流程是“先按症状检索疾病条目，再按疾病检索用药指南，最后做交互冲突检查”，把这三步封装成一个 Skill，Agent 判断用户问题属于“症状咨询”后直接调用它，检索质量会比通用 RAG 稳定得多。这也是很多人在问“Skill 怎么和 RAG 结合起来”时的答案：Skill 负责编排检索逻辑，RAG 负责底层获取内容，二者是上下层关系，不是竞争关系。
4.3 往下走：GraphRAG、本体 RAG 与 LLM Wiki 的关系
聊到“RAG 进阶方向”，你大概率见过 GraphRAG、Ontology RAG、LLM Wiki 这些词。它们并不是互相替代的关系，而是从不同角度优化知识获取质量。
GraphRAG 由微软开源，核心做法是先让大模型从文档中抽取实体和关系，构建一张知识图谱，检索时支持多跳关系推理。典型场景是“某部门下有哪些项目组，项目组里谁负责 XX”，普通向量检索很难回答这种关系型问题，但图谱检索可以沿边走路。Ontology RAG 更进一步，在知识库里加入本体层，也就是“类、属性、关系约束”的正式定义，让检索结果更符合领域逻辑。LLM Wiki 则是把知识库变成一个对模型友好的、可交互的 wiki 形态，强调知识的可维护性和链接关系。
这些方向各有价值，但对刚接触 RAG 的人来说，优先把基础链路打磨到能稳定回答、能溯源、能评估，再考虑进阶形态。知识库的规范化、本体设计、图谱构建都是重活，基础不牢时贸然上这些方案，只会换来一堆维护负担。
5. 跑通 RAG 之后，我踩过的坑和调试清单
5.1 命中率低但模型还在编：先查这三个位置
我接手过好几种“RAG 效果差”的案例，最后基本都是同一个套路：问题在检索链路，却总有人去调生成端的 prompt。如果你发现自己调 prompt 调了半天没什么起色，务必按下面的顺序排查。
第一，切分是不是破坏了语义。把每道检索失败的问题单独拿出来，看看返回的 Top-5 里到底是什么样的片段。如果片段明显被拦腰截断、上下文缺失，去调切分策略。第二，Embedding 模型是不是不适合你的语言和领域。把问题直接和文档块算一遍相似度，如果你发现正确答案的相似度分数和其他无关块差不多，就考虑换模型。第三，是不是只有向量检索、没有混合检索。这种问题最隐蔽，因为大部分题目看起来都能命中，但涉及精确型号、编号的就集体翻车。
调试顺序一定要记得：先解决“检索里有没有正确答案”，再解决“生成端有没有正确使用”。不要一上来就改 prompt。我见过最多的无效努力，就是在 Hit Rate 只有 60% 的时候把 prompt 改来改去，最后发现正确答案根本没被检索出来。
5.2 知识更新：向量库里的旧内容比你想的更难清理
RAG 项目上线之后，最容易被忽略的是知识更新问题。知识每天都在变，比如价格表每月一调、产品手册出新版，但向量库里还躺着旧版本的 chunk。检索时新旧内容一起返回，模型看到两套数据互相冲突，轻则答错，重则直接混乱。
我自己的处理方法是文档级版本管理。入库时给每个 chunk 打上 doc_id、版本号、更新时间的 metadata。文档更新后，先把该 doc_id 下所有旧 chunk 删除，再重新解析、切分、写入。更进一步，我会在入库前计算文档哈希，如果哈希没变就直接跳过，避免重复索引浪费算力。
这个坑之所以隐蔽，是因为大多数网络教程只教怎么插入，不教怎么更新和删除。你如果只跑 Demo 当然感觉不到，一旦放到生产环境跑一个月，陈旧知识带来的错误率会逐渐暴露。建议从一开始就把 metadata 设计好，不要等出问题再补。
5.3 没有评估就没有优化：给 RAG 建立 Golden Set
优化 RAG 最忌“感觉流”。这个参数调一下，感觉好一点；那个模型换一下，感觉又差一点。没有数字支撑，你永远不知道到底哪一个改动真正有效。
所以我的强烈建议是：项目第一天就建立 Golden Set。具体做法是挑 50 到 100 条真实用户问题，逐条标注它对应的标准答案文档块和标准回答。之后所有改动，无论是切分、Embedding、检索策略还是 Rerank 模型，都用这套集子跑一遍评估，输出 Hit Rate 和 RAGAS 指标。RAGAS 里有几个关键值：Faithfulness（生成回答是否忠实于检索内容）、Answer Relevance（回答是否与问题相关）、Context Precision（检索内容是否精确命中关键信息）。
我习惯把评估脚本挂在 CI 上，每次改完配置自动跑一遍，出一份报告。这样团队里任何人做了改动，效果升降都一目了然。没有这套机制之前，我调参基本靠猜，有了之后，每一个优化点都有清晰归因。
5.4 我的调试顺序和一份可复用的检查清单
最后分享一份我目前固定使用的 RAG 调试清单，照着做，能避免大部分无效劳动：
- 检查文档解析质量：扫描版是否 OCR、表格是否结构化、网页是否只保留正文。
- 首次入库后人工抽样：随机抽 20 个文档块，看切分是否语义完整。
- 建立 50 条以上 Golden Set，记录 Hit Rate 基线。
- 打印检索失败案例的 Top-5，定位是切分问题还是 Embedding 问题。
- 开启混合检索（BM25 + 向量），对比 Hit Rate 变化。
- 加入 Rerank，对比 Hit Rate 变化。
- 确认 Hit Rate 达到 90% 以上后，再调整生成端 prompt。
- 上线后持续收集 Bad Case，每周回灌到 Golden Set。
这里我想特别说一句：很多人以为 RAG 的核心是“大模型多厉害”，但我做了这么多项目后的体会是，RAG 的核心永远在数据管道。谁把文档解析、切分、检索、评估这些笨功夫做扎实了，谁的效果就稳。那些看起来花哨的进阶方案，都是在基础管道可靠的前提下才能发挥作用的。你手里要是有一套干净、可控、可评估的知识获取管道，Agent 的可靠程度会远超你的预期。
