前几篇我们把 Agent 的“骨架”搭起来了模型怎么规划、工具怎么调用、记忆怎么设计。当时我就留了一个尾巴——Agent 如果只吃模型脑子里那点参数知识它其实是个“没读过书的实习生”。你让它回答自家产品的限流阈值、内部流程、某个私有协议的细节它只能硬着头皮编编错了就是幻觉。把外部知识接进来的这套东西业界通行的名字叫 RAGRetrieval-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实现简单、信息无损成本爆炸、延迟爆炸、无关信息稀释注意力一次性分析、文档极少微调把知识写进模型参数推理时不依赖外部检索更新要重新训练、有遗忘风险、数据安全难控风格迁移、领域术语固化RAG检索相关片段 给出原文依据知识实时更新、可溯源、成本可控检索质量决定上限高频更新文档、需要证据链、数据量大我见过特别典型的反面案例有人为了省事把三百页的产品手册整本塞进 prompt结果关键参数被淹没在大量背景介绍里模型注意力被稀释回答质量直线下降最后花的 token 钱还不少。RAG 的本质是筛选器它保证模型只看最该看的那几段。记住模型不是看得越多越好是看得越准越好。1.4 合格知识管道的三条验收标准聊完选型我们得明确一下什么叫“合格”。我一般用三条标准验收任意一条知识获取管道。首先是准确性给定一个验证集系统检索出来的片段到底有多少真正包含标准答案。这个可以用 hit rate 量化后面会细讲。其次是新鲜度文档改了之后多久能反映到检索结果里。最后是可控性任何一个回答能不能追溯到具体原文片段。三条都过这条管道才算能进生产。2. 认识这条管道RAG 的四段式结构RAG 这个名字听着学术管道的骨架其实特别朴素先把知识切碎并做好索引收到问题后从索引里捞相关内容最后把“问题 相关资料”一起交给模型生成答案。我习惯拆成四段接入清洗、切分向量化、检索重排、生成溯源。每一段都有单独的坑这一段道行深一点整体才稳。2.1 第一段知识源接入与清洗很多人把 RAG 项目失败归结于“向量模型选得不够好”但按我的实测超过一半的问题出在最前面的接入环节。你手里的知识源不会乖乖是干净的 Markdown。PDF 里可能混着页眉、页脚、水印Word 里嵌着一堆嵌套表格HTML 里有导航栏和广告正文。真实业务里还有那种扫描版 PDF本质是一张张图片连文字都抽不出来。这一段落后的质量直接决定后面所有环节的上限。垃圾进垃圾出这五个字在 RAG 里体现得淋漓尽致。实际操作上我一般从三类工具里挑规则排版清晰的 PDF 用 pdfplumberWord、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 个 token400 字符大概等于 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(namedemo) vectors model.encode(chunks).tolist() collection.add( ids[str(i) for i in range(len(chunks))], embeddingsvectors, documentschunks, metadatasmetas, ) # 4. 检索问题同样向量化后查库 question 限流阈值能改吗 q_vec model.encode([question]).tolist() results collection.query(query_embeddingsq_vec, n_results2) for doc in results[documents][0]: print(doc)这段代码跑完你会发现检索结果里有“限流阈值可在控制台调整”这一条——这就是语义检索命中的直观体验。后续生成部分也不复杂接 OpenAI 兼容接口用常规 chat 接口调用在 system 提示词里写清楚“基于以下资料回答问题并标注来源编号如果资料中没有答案直接说未找到”然后把检索到的原文拼进用户消息里。这一步的 prompt 写得松不松直接决定模型会不会自由发挥。3.3 参数调优给管道做一次量化体检管道跑通只是起点。我见过太多项目“能出结果”就当成功结果一问就露馅。实际上 RAG 效果是可以量化的最简单也最实用的指标是 hit rate也叫命中率。做法是准备一批“问题-标准答案片段”的验证对然后看检索结果里有多少对真的把标准答案片段捞上来了。这一步做完你对管道的真实水平心里就有底了。我建议建一个 50-100 对的验证集。然后你会很惊喜地发现同样一批数据chunk 大小不同、top_k 不同、有没有重排器命中率会有肉眼可见的差距。我贴一组自己早期实测的对比配置命中率说明chunk800无重排61%块太大语义被稀释chunk400无重排70%明显改善chunk400加 bge-reranker82%重排是最大单项收益chunk400混合检索 重排88%精确术语场景也覆盖了调参这件事没有奇技淫巧就是拿同一批验证集一次改一个变量跑完记录结果。命中率如果低于 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 从“会说”变成“真知道”。
前几篇我们把 Agent 的“骨架”搭起来了模型怎么规划、工具怎么调用、记忆怎么设计。当时我就留了一个尾巴——Agent 如果只吃模型脑子里那点参数知识它其实是个“没读过书的实习生”。你让它回答自家产品的限流阈值、内部流程、某个私有协议的细节它只能硬着头皮编编错了就是幻觉。把外部知识接进来的这套东西业界通行的名字叫 RAGRetrieval-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实现简单、信息无损成本爆炸、延迟爆炸、无关信息稀释注意力一次性分析、文档极少微调把知识写进模型参数推理时不依赖外部检索更新要重新训练、有遗忘风险、数据安全难控风格迁移、领域术语固化RAG检索相关片段 给出原文依据知识实时更新、可溯源、成本可控检索质量决定上限高频更新文档、需要证据链、数据量大我见过特别典型的反面案例有人为了省事把三百页的产品手册整本塞进 prompt结果关键参数被淹没在大量背景介绍里模型注意力被稀释回答质量直线下降最后花的 token 钱还不少。RAG 的本质是筛选器它保证模型只看最该看的那几段。记住模型不是看得越多越好是看得越准越好。1.4 合格知识管道的三条验收标准聊完选型我们得明确一下什么叫“合格”。我一般用三条标准验收任意一条知识获取管道。首先是准确性给定一个验证集系统检索出来的片段到底有多少真正包含标准答案。这个可以用 hit rate 量化后面会细讲。其次是新鲜度文档改了之后多久能反映到检索结果里。最后是可控性任何一个回答能不能追溯到具体原文片段。三条都过这条管道才算能进生产。2. 认识这条管道RAG 的四段式结构RAG 这个名字听着学术管道的骨架其实特别朴素先把知识切碎并做好索引收到问题后从索引里捞相关内容最后把“问题 相关资料”一起交给模型生成答案。我习惯拆成四段接入清洗、切分向量化、检索重排、生成溯源。每一段都有单独的坑这一段道行深一点整体才稳。2.1 第一段知识源接入与清洗很多人把 RAG 项目失败归结于“向量模型选得不够好”但按我的实测超过一半的问题出在最前面的接入环节。你手里的知识源不会乖乖是干净的 Markdown。PDF 里可能混着页眉、页脚、水印Word 里嵌着一堆嵌套表格HTML 里有导航栏和广告正文。真实业务里还有那种扫描版 PDF本质是一张张图片连文字都抽不出来。这一段落后的质量直接决定后面所有环节的上限。垃圾进垃圾出这五个字在 RAG 里体现得淋漓尽致。实际操作上我一般从三类工具里挑规则排版清晰的 PDF 用 pdfplumberWord、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 个 token400 字符大概等于 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(namedemo) vectors model.encode(chunks).tolist() collection.add( ids[str(i) for i in range(len(chunks))], embeddingsvectors, documentschunks, metadatasmetas, ) # 4. 检索问题同样向量化后查库 question 限流阈值能改吗 q_vec model.encode([question]).tolist() results collection.query(query_embeddingsq_vec, n_results2) for doc in results[documents][0]: print(doc)这段代码跑完你会发现检索结果里有“限流阈值可在控制台调整”这一条——这就是语义检索命中的直观体验。后续生成部分也不复杂接 OpenAI 兼容接口用常规 chat 接口调用在 system 提示词里写清楚“基于以下资料回答问题并标注来源编号如果资料中没有答案直接说未找到”然后把检索到的原文拼进用户消息里。这一步的 prompt 写得松不松直接决定模型会不会自由发挥。3.3 参数调优给管道做一次量化体检管道跑通只是起点。我见过太多项目“能出结果”就当成功结果一问就露馅。实际上 RAG 效果是可以量化的最简单也最实用的指标是 hit rate也叫命中率。做法是准备一批“问题-标准答案片段”的验证对然后看检索结果里有多少对真的把标准答案片段捞上来了。这一步做完你对管道的真实水平心里就有底了。我建议建一个 50-100 对的验证集。然后你会很惊喜地发现同样一批数据chunk 大小不同、top_k 不同、有没有重排器命中率会有肉眼可见的差距。我贴一组自己早期实测的对比配置命中率说明chunk800无重排61%块太大语义被稀释chunk400无重排70%明显改善chunk400加 bge-reranker82%重排是最大单项收益chunk400混合检索 重排88%精确术语场景也覆盖了调参这件事没有奇技淫巧就是拿同一批验证集一次改一个变量跑完记录结果。命中率如果低于 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 从“会说”变成“真知道”。
