RAG 检索增强生成全链路拆解：从文档切块到 Agentic RAG 实战

1. RAG 到底是什么为什么 Agent 开发绕不开它先把结论摆在前面RAGRetrieval-Augmented Generation检索增强生成不是某个具体框架的名字也不是某个产品的功能而是一套“先查资料、再让模型开口”的工程范式。它的核心动作只有三步——把知识切块存起来、根据问题把相关块捞出来、把捞出来的内容塞进大模型的上下文里让它基于这些内容作答。听起来简单到有点朴素但正是这套朴素机制撑起了现在绝大多数企业级 Agent 的知识底座。我最早接触 RAG 是在做一个内部文档问答机器人。当时天真地以为把 PDF 丢给模型就行结果模型张口就来、编得比真话还顺。后来才明白大模型的参数里存的是“世界的一般印象”不是“你公司上周刚改的报销制度”。RAG 解决的就是这个错位让模型在回答前先看一眼你给它的资料把“凭记忆答”变成“开卷考”。对于 Agent 开发来说这一点尤其致命——Agent 要调用工具、要做多步决策如果第一步的知识就是错的后面整条链路全崩。所以这篇文章我打算把 RAG 从里到外拆一遍。适合谁看如果你正在做 Agent 项目、准备面试被问到 RAG、或者单纯想给自己的知识库接个大模型这篇都能用。我会讲清楚每个环节为什么这么设计、参数怎么算、坑在哪里而不是只丢几个 API 调用示例。全文基于我自己的实操经验和常见工程实践展开涉及具体数值的地方我会说明推导过程方便你按自己的场景调整。1.1 一个生活化类比RAG 就是给模型配了个图书管理员你可以把大模型想象成一个博学但记性有点飘的教授。他读过很多书但你问他“我们实验室上周那台仪器的校准参数是多少”他只能瞎猜。RAG 做的事情就是给这位教授配一个图书管理员你提问管理员先去书架上找到最相关的几页递给教授教授照着这几页回答。管理员找得准不准直接决定教授答得对不对。这个类比里藏着 RAG 的三个关键角色知识库书架、检索器管理员、生成器教授。很多人做 RAG 失败不是教授不行而是管理员找错了书或者书架本身就没整理好。后面我会反复回到这个类比因为大部分优化点都能对应到“书架怎么摆”“管理员怎么找”上。1.2 RAG 和微调、长上下文到底怎么选经常有人问既然现在模型上下文能塞几十万 token我直接把所有文档塞进去不就行了还要 RAG 干嘛这个问题问得好我实测过。假设你有 500 份文档、每份 2 万字总共 1000 万字就算上下文够大每次提问都塞进去成本和延迟会让你怀疑人生。而且模型在超长上下文里会“注意力涣散”中间部分的内容经常被忽略这就是所谓的“lost in the middle”现象。微调是另一条路把知识直接训进模型参数。但微调有个硬伤——知识更新要重新训练而且模型容易“记住”却不会“引用”你没法追溯它到底从哪句话得出的结论。RAG 的优势恰恰在于知识可热更新、答案可溯源、成本可控。我的经验是事实性、频繁变动的知识用 RAG风格、格式、语气这类“行为模式”用微调两者不冲突可以叠加。方案知识更新可溯源成本适合场景RAG实时改库即可强能给出出处中主要是检索和推理企业知识库、客服、Agent 工具知识微调需重训弱高训练部署固定风格、特定任务格式长上下文直塞实时中极高token 爆炸少量文档、一次性分析2. RAG 的核心链路拆解从文档到答案的每一步一条完整的 RAG 链路粗略分是“索引”和“查询”两大阶段。索引阶段离线跑把原始文档变成可检索的向量查询阶段在线跑把用户问题变成向量、检索、重排、拼上下文、生成。每个环节都有讲究我逐个拆。2.1 文档加载与清洗垃圾进垃圾出这一步最容易被忽视但它是 RAG 质量的地基。我见过太多项目检索效果差最后发现是 PDF 解析出来一堆乱码和页眉页脚。文档加载的核心任务是把各种格式PDF、Word、HTML、Markdown、数据库记录统一转成纯文本同时保留结构信息。PDF 解析是重灾区。扫描版 PDF 需要 OCR文字版 PDF 要注意分栏、表格、公式。我常用的策略是优先用能保留布局的解析器表格单独抽出来转成 Markdown 或结构化文本页眉页脚用规则或重复检测去掉。清洗阶段要处理的问题包括多余空白、乱码字符、重复段落、超长无意义内容比如版权声明。注意不要在这一步做过度清洗。有些项目为了“干净”把标点、换行全删了结果句子边界丢失后面切块时把一句话切成两半检索出来语义残缺。清洗的目标是去噪不是重写。2.2 文本切块切得好检索就成功了一半切块Chunking是 RAG 里最考验经验的一环。为什么不能整篇文档当一个块因为向量模型对长文本的表示会“平均化”一篇讲十个主题的长文它的向量和任何一个具体主题都不太像。为什么不能切太碎因为一句话的块缺乏上下文检索出来模型看不懂。常见的切块策略有这么几种固定长度切块按 token 数或字符数切简单粗暴但容易切断句子。适合结构松散的文本。递归字符切块按段落、句子、词的优先级递归切尽量在自然边界断开。这是最常用的默认策略。语义切块用 embedding 计算相邻句子的相似度在语义转折处切。效果好但慢。结构化切块按 Markdown 标题、HTML 标签、代码函数切。对有结构的文档最友好。块大小怎么定我的经验值是256 到 512 个 token配合10% 到 20% 的重叠overlap。重叠是为了防止边界信息丢失——一个概念刚好跨在两个块之间没有重叠就会两边都检索不到。这个数值不是拍脑袋太小比如 128会导致上下文不足模型答不完整太大比如 1024会引入噪声检索精度下降。你可以把它理解成切西瓜块太大一口咬不下还沾一脸块太小全是皮没肉。2.3 Embedding 模型选型向量质量的决定因素Embedding 模型负责把文本变成向量它的好坏直接决定检索准不准。选型时我看三个维度语言支持、维度、检索性能。中文场景一定要选对中文优化过的模型很多英文模型在中文上表现断崖式下跌。维度不是越高越好。高维度理论上能表达更多信息但存储和计算成本上升而且边际收益递减。常见的有 384、768、1024、1536 维。我的建议是先用主流的中等维度模型跑通效果不够再换大的。还有一个关键点查询和文档必须用同一个 embedding 模型。我踩过这个坑——索引时用 A 模型查询时手滑用了 B 模型结果检索出来的东西驴唇不对马嘴排查了半天才发现是模型不一致。这个错误很隐蔽因为代码不会报错只是效果差。2.4 向量数据库存哪里、怎么查向量数据库负责存储向量并做相似度检索。选型时考虑数据量、是否需要持久化、是否要混合检索、部署复杂度。小项目用内存向量库就够了数据量上来了再换专业的。向量库特点适合场景内存型如 FAISS轻量、快、无需服务原型验证、小数据量Chroma易用、支持持久化、API 友好中小项目、快速开发专业向量库高并发、分布式、混合检索生产环境、大数据量检索方式上最基础的是余弦相似度或内积的近似最近邻搜索ANN。但纯向量检索有个问题它对关键词不敏感。比如你搜“错误码 E1024”向量检索可能给你返回一堆讲“错误处理”的文档就是找不到那个具体编码。这时候就需要混合检索——向量检索 关键词检索如 BM25两路结果融合。这是提升 RAG 命中率最有效的手段之一。2.5 重排把最相关的顶到最前面检索出来 Top-K 个块后直接塞给模型往往不够好因为向量相似度高不等于真的相关。重排Rerank用一个更精细的模型通常是交叉编码器对“问题-文档”对逐一打分重新排序。它的计算比向量检索慢但精度高所以只对检索出来的少量候选做。我的标准流程是向量检索召回 Top 20 到 50重排后取 Top 3 到 5 塞进上下文。为什么是 3 到 5因为上下文窗口有限塞太多反而稀释重点还可能引入矛盾信息。重排模型的选择上中文场景同样要选中文优化的否则效果打折。2.6 上下文组装与生成最后一步别翻车把检索到的块拼成 prompt 时有几个细节给每个块标注来源方便溯源和引用、控制总长度别超模型上下文、明确指令告诉模型“只根据以下资料回答资料没有就说不知道”。最后这条特别重要不加的话模型又会开始自由发挥。生成阶段还有个技巧让模型引用来源编号。比如资料标了 [1][2]要求模型回答时带上引用。这样用户能验证你也能快速定位是检索错了还是生成错了。3. 动手搭一个最小可用的 RAG完整实操流程光讲原理不够我带你走一遍完整流程。这里用 Python 生态里最常见的组合代码可以直接抄。环境准备、依赖安装、索引构建、查询生成一步步来。3.1 环境准备与依赖安装先建虚拟环境装核心依赖。我习惯用 pip你也可以用 conda。python -m venv rag_env source rag_env/bin/activate # Windows 用 rag_env\Scripts\activate pip install langchain langchain-community chromadb sentence-transformers pypdf这里解释下每个包的作用langchain提供链路编排chromadb是向量库sentence-transformers提供 embedding 模型pypdf负责解析 PDF。如果你要用在线 embedding 服务把sentence-transformers换成对应的 SDK 即可。3.2 文档加载与切块代码假设你有一份 PDF先加载再切块。from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 加载 loader PyPDFLoader(knowledge.pdf) docs loader.load() # 切块块大小 500 字符重叠 100 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap100, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_documents(docs) print(f切出 {len(chunks)} 个块)注意separators里我加了中文标点。默认的分隔符是英文的中文文档如果不加切块会在奇怪的地方断开。这个细节很多人不知道导致中文 RAG 效果莫名差一截。3.3 构建向量索引并持久化from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 选一个中文友好的 embedding 模型 embedding HuggingFaceEmbeddings( model_nameBAAI/bge-small-zh-v1.5, model_kwargs{device: cpu} ) # 建库并持久化 vectordb Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./chroma_db ) vectordb.persist()bge-small-zh-v1.5是个中文效果不错、体积又小的模型适合本地跑。如果你追求更好效果可以换bge-large-zh代价是慢一些、占内存多一些。持久化目录建好后下次直接加载不用重新索引。3.4 检索与生成把链路串起来from langchain_community.llms import Ollama # 加载已有索引 vectordb Chroma( persist_directory./chroma_db, embedding_functionembedding ) # 检索 query 报销流程是什么 retrieved vectordb.similarity_search(query, k4) # 组装上下文 context \n\n.join([f[{i1}] {d.page_content} for i, d in enumerate(retrieved)]) # 生成 llm Ollama(modelqwen2.5) prompt f只根据以下资料回答问题资料没有的内容就说不知道并标注引用编号。 资料 {context} 问题{query} answer llm.invoke(prompt) print(answer)这段代码就是一个最小可用的 RAG。检索 Top 4拼上下文让本地模型基于资料回答。跑通之后你会发现它已经能处理不少文档问答场景了。3.5 参数计算Top-K 和块大小怎么定很多人问 Top-K 到底取多少。我的推导逻辑是这样的假设模型上下文能放 8000 token每个块 500 token那么理论上最多能放 16 个块。但实际不能塞满因为要给问题和回答留空间还要考虑噪声。所以取 3 到 5 个块比较稳妥对应 Top-K 设 4 到 6再配合重排。块大小同理太小检索不准太大噪声多。500 字符约 300 到 400 中文 token是个平衡点。如果你的文档句子特别长可以适当放大到 800如果是 FAQ 这种短问答可以缩到 200。4. 常见问题与排查技巧实录RAG 跑起来容易跑好难。下面这些坑我都踩过整理成速查表你遇到问题时可以对照排查。4.1 检索不准问题出在哪一环检索不准是最常见的问题表现是“答非所问”或“找不到相关内容”。排查顺序应该是先看切块再看 embedding最后看检索策略。现象可能原因排查方法解决检索结果完全不相关embedding 模型不匹配语言手动测几条 query 的相似度换中文优化模型检索结果沾边但不精准块太大主题混杂打印检索到的块内容减小块大小加重叠关键词搜不到纯向量检索对关键词不敏感用具体术语测试加 BM25 混合检索明明有答案却检索不到切块切断了关键句检查原文和块的对应调整分隔符用语义切块我印象最深的一次排查用户问“如何重置密码”检索出来的全是“密码安全规范”。后来发现是切块时把“重置密码”的操作步骤和“密码规范”切到了同一个块里向量被平均了。把块改小、按标题切之后问题解决。4.2 生成胡编模型不听话怎么办检索对了模型还是编通常是 prompt 没约束好。我的做法是明确指令 引用要求 兜底话术。指令里写死“只根据资料回答”要求标注引用编号并给出“资料未提及”的标准回复。另外把 temperature 调低0 到 0.3减少随机性。还有一种情况是检索到的资料本身互相矛盾。这时候模型会“和稀泥”。解决办法是在重排阶段做去重和冲突检测或者让模型明确指出矛盾点而不是强行给一个答案。4.3 性能瓶颈慢在哪里RAG 的延迟主要来自三块embedding 计算、向量检索、大模型生成。embedding 和检索通常很快毫秒级大头在生成。如果整体慢先看是不是模型太大或上下文太长。优化手段包括用更小的生成模型、减少 Top-K、开启流式输出让用户先看到部分结果。向量检索在数据量大时会变慢这时候要考虑索引优化如 HNSW 参数调整或换专业向量库。我实测过百万级向量用内存库检索会明显卡顿换专业库后恢复到毫秒级。4.4 独家避坑清单别在索引和查询用不同 embedding 模型这个错误不报错但致命。中文文档一定要加中文分隔符否则切块质量差。保留元数据来源、页码、标题排查和溯源时救命。定期评估检索命中率建一个测试集每次改动后跑一遍别凭感觉。上下文别塞满留出空间给模型推理塞太满反而答不好。注意 token 计费在线模型按 token 收费Top-K 开太大成本飙升。5. 从基础 RAG 到 Agentic RAG进阶方向基础 RAG 是“一问一查一答”但 Agent 场景下检索本身可能是个需要决策的动作。这就是 Agentic RAG 的思路让 Agent 自己决定要不要检索、检索什么、检索几次、结果够不够。比如用户问一个多跳问题Agent 可能先检索 A根据 A 的结果再检索 B最后综合回答。实现上这通常借助 Agent 框架把检索封装成一个工具tool让模型通过 function calling 自主调用。好处是灵活能处理复杂查询代价是链路变长、延迟增加、调试变难。我的建议是简单问答用基础 RAG复杂多跳、需要推理的用 Agentic RAG别为了炫技把简单问题复杂化。另一个进阶方向是 GraphRAG把知识建成图结构检索时沿图遍历。它适合实体关系密集的场景比如人物关系、组织架构。但构建和维护成本高不是所有场景都值得。5.1 Agentic RAG 的检索决策逻辑Agentic RAG 的核心是让模型判断“我现在的信息够不够回答”。实现时通常给 Agent 一个检索工具和一个“回答”工具模型自己选。如果检索结果不相关它可以改写查询再检一次。这个循环要有次数上限否则模型可能陷入无限检索。我一般设 3 次上限超过就强制回答或承认不知道。5.2 评估怎么知道你的 RAG 好不好没有评估的 RAG 就是盲人摸象。我常用的指标有两个检索命中率正确答案是否在检索结果里和答案正确率最终回答对不对。建一个几十条的测试集覆盖常见问题和边界情况每次改动后跑一遍。别小看这个习惯它能帮你避免“改了一个参数修好一个 case弄坏十个 case”的悲剧。评估工具上可以用现成的 RAG 评估框架也可以自己写脚本对比。关键是要有 ground truth也就是每个问题对应的标准答案和应检索到的文档。这个测试集前期投入大但长期回报极高。5.3 知识库维护RAG 不是一劳永逸很多人以为建好索引就完事了其实知识库需要持续维护。文档更新了要重新索引过期内容要清理新增内容要补充。我建议做一个增量索引流程监听文档变化只对变化的文档重新切块和 embedding而不是全量重建。全量重建在数据量大时非常耗时。另外定期 review 检索日志看看用户都在问什么、哪些问题答不好。这些真实数据是优化 RAG 最宝贵的输入比拍脑袋调参有效得多。最后分享一个我自己的体会RAG 的效果七分靠数据整理两分靠检索策略一分靠模型。很多人把精力全花在换模型、调参数上却忽略了最基础的文档清洗和切块。把地基打牢用中等模型也能跑出好效果地基不牢用再强的模型也是白搭。这个道理我在好几个项目里反复验证过。