RAG管道深度拆解：从索引、检索到生成的Agent知识获取指南-北京尧图网络

最近在搭建 Agent 的时候很多人第一个卡住的地方不是模型选择也不是工具调用而是怎么把知识喂给 Agent。大模型训练完就固定住了新知识它不知道你公司的内部文档它更不知道。这时候 RAG 就得上场了。作为走进 AI Agent系列的第四篇这篇我就系统聊一聊 RAG 这条知识获取管道它到底是什么、核心环节怎么做、实际搭建会遇到哪些坑。RAG 全称 Retrieval-Augmented Generation检索增强生成。通俗理解就是先从一个外部知识库里把相关内容查出来再把查到的内容连同用户的问题一起丢给大模型让它基于这些材料来回答。用生活化的类比来说这就像开卷考试——模型不再是闭卷硬答而是可以随时翻参考资料。这篇文章适合准备给 Agent 接入知识库的开发者、正在选型 RAG 方案的架构师以及刚接触 RAG 想搞懂原理的学习者。我会从管道拆解一路讲到实操复现和踩坑实录尽量让不同基础的读者都能找到自己需要的部分。1. 为什么 Agent 需要一条知识获取管道1.1 先看清大模型的能力边界大模型虽然能聊会写但它本质上是一个静态参数包训练完成之后知识就凝固在权重里了。它不知道昨天发布的新闻不知道你自己写的内部 SOP也不知道某个私有系统的数据格式。即使模型可以靠推理猜出一些内容但本质上是编造合理化答案这就是大家常说的幻觉问题。你可以把大模型的参数想象成一个非常聪明但只读过旧教材的学生。你问它开放性问题它能给你答出一套逻辑自洽的答案但一旦涉及新教材里的内容、公司内部规范或者实时数据它就开始一本正经地胡扯了。Agent 要做的是帮用户干活而干活必须依赖准确、实时、领域内的知识单靠模型本身是撑不起来的。1.2 知识获取的三种主流路线对比要让 Agent 获得新知识业内目前主要就是三条路微调Fine-tuning、超长上下文Long Context、RAG。我给它们做过一次比较直接看表方案知识更新成本实时性实现复杂度适用场景微调高需要准备训练数据、GPU 资源低更新一次要重新训练较高改变模型风格、注入固定领域知识超长上下文中把文档直接塞进上下文高随用随换低单次问答涉及上百页文档RAG低替换知识库内容即可高索引重建后可立即生效中企业知识库、私有数据问答、Agent 工具增强大多数场景下 RAG 是性价比最优的方案原因在于它的解耦特性知识存在外部数据库里更新知识库完全不影响模型权重成本极低。模型本身并不记住你的文档它只是在回答时查阅了这些文档。这正好契合 Agent 的知识获取管道定位——管道里的数据是可替换的模型只是消费数据的引擎。1.3 Agent 里知识管道的定位在 Agent 的架构里知识获取管道承担的角色很明确把非结构化的原始文档加工成可以被模型高效利用的检索单元。Agent 每收到一个问题第一步就是判断自己缺不缺知识缺的话就从管道里取。取回来的知识需要和用户问题、上下文、工具返回结果一起组装成最终的 Prompt。所以 RAG 不是孤立的它嵌在 Agent 的整体工作流里。管道上游是数据源下游是模型推理和工具调用。如果你只把 RAG 理解成向量数据库相似度搜索那很容易做出来一个玩具真正生产级的 RAG需要理解管道中每个环节的权衡和取舍。2. RAG 管道核心拆解索引、检索、生成2.1 管道全景与时序关系完整的 RAG 管道从时序上可以分成两大阶段离线索引阶段和在线检索阶段。索引阶段把原始文档切块、向量化、入库检索阶段把用户问题向量化、查库、重排、拼装。习惯上会把整个流程归纳成索引-检索-生成三部分但实际拆开看每个部分内部还有不少细活。我用一个直观的顺序来描述整个链路文档加载Document Loading从 PDF、Word、网页、数据库等来源读取原始内容文本清洗Cleaning去掉页眉页脚、乱码、无关格式统一编码分块Chunking把长文档切成合适大小的语义单元向量化Embedding把文本块转换成向量表示向量入库Indexing存入向量数据库建立索引查询向量化Query Embedding把用户问题同样转换成向量检索Retrieval在知识库中找到最相关的候选文本块重排序Re-ranking对候选块重新打分保留最优质的内容生成Generation把检索结果和问题一起交给大模型这个链路有一个容易忽略的点离线阶段的质量直接决定了在线阶段的天花板。你后面检索做得再好如果分块分得太碎语义被切断了模型看到的就是残缺信息。2.2 文档加载与清洗管道的起点文档加载看起来简单实际是事故高发区。PDF 是最让人头疼的格式很多 PDF 是扫描件需要 OCR 识别有些 PDF 是排版复杂的双栏论文直接提取文本会导致左右两栏内容交错在一起。我做过的项目里PDF 文本提取的损坏率如果超过 10%最终问答准确率会明显下降。清洗环节通常包括这几步移除页眉页脚、页码、水印文字统一换行符和编码格式UTF-8 常见问题在 Windows 来源文档里很典型处理表格表格转 Markdown 或 HTML 保留结构比转纯文本好很多去除重复内容比如同一份文档在知识库里被放了多份清洗的目标不是干净而是保真。有些做法的清洗会把表格合并成一堆空格和换行导致语义丢失。我自己的经验是清洗规则宁缺毋滥只处理明确有问题的内容不要过度正则化。2.3 分块策略最容易被低估的环节分块是整个 RAG 管道里最容易影响效果、也最需要反复调试的环节。分块的目标是把知识切成语义自包含的单元一个块内信息量足够且完整块与块之间不过度重叠。常见分块方式有几种固定长度分块按 token 或字符数切简单粗暴常用 300-800 token 一块带少量重叠递归结构分块按段落、标题、项目符号等结构层级递归切分语义分块利用 embedding 计算语义边界找到语义突变的位置再切不同方式适合不同文档类型。固定长度适合纯文本和日志递归结构分块适合有清晰标题结构的 Markdown 或 HTML语义分块更适合长段落、少结构的报告类文档。分块大小的选择也是很有讲究的。块太小语义不完整检索到的是碎片块太大向量表示会被稀释而且给模型的上下文预算浪费了。我的经验值是默认从 500 token 左右开始带 50-100 token 重叠然后根据文档类型和实际评测结果调整。一个容易踩的坑是句号切分法。有的人为了让块更规整按句子切结果把表格、代码块、嵌套列表直接切断。RAG 不是语文断句块的边界应该尽量避开格式内容的中断处。2.4 Embedding 与向量存储怎么选才不踩坑Embedding 模型的作用是把文本变成一串浮点数让语义相近的文本在向量空间里距离更近。这一步的选择很关键因为它是整个检索环节的度量衡。模型选择上有几个维度的权衡是开源还是 API 调用中文效果如何向量维度大小是否支持长文本。国内团队常用的是以下几条路线OpenAI 的 text-embedding-3-small / 3-large英文效果极佳中文也能用但需要海外的网络环境开源的 BGE、m3e、GTE 系列中文效果好可本地部署维度通常在 768 或 1024Cohere、Voyage 等专用 embedding 服务效果强但国内使用和计费模式不一定友好我个人的建议是中文场景优先本地部署开源 embedding 模型效果不一定输给 API而且部署成本低、可控性强。选型时除了看榜单数据一定要拿自己的领域文档做小规模评测——通用榜单和你的业务场景可能差异巨大。向量数据库的选择也很多常用的有 Chroma、Milvus、Qdrant、Weaviate、FAISS、pgvector。它们各有侧重点数据库部署方式擅长场景上手难度FAISS库内集成原型验证、单机检索低Chroma本地/嵌入式快速原型、轻量应用极低pgvectorPostgreSQL 插件已有 PG 体系、事务要求高中Milvus独立服务百万级向量、高并发生产高Qdrant独立服务生产环境、过滤条件丰富中原型阶段用 Chroma 或者 FAISS 都行生产环境如果数据量上了百万建议直接考虑 Milvus 或 Qdrant。切换向量库的成本主要集中在索引构建和查询写法的迁移所以一开始就定好方案能省不少事。2.5 检索与重排序从找到到找对检索是整个 RAG 管道中最能体现技术深度的地方。最基础的实现是向量相似度检索——把用户问题 embedding 之后在向量库里搜索 top-K 最相似的文本块。这个方案足够跑通 demo但真实场景里往往会遇到几个问题。第一个问题是query 与 document 的语义鸿沟。用户提问通常是短句、口语化、含有指代词而文档是长篇幅、正式、客观的表述。向量模型对这两种文本的编码风格可能不在一个平面上直接做相似度比请求出来结果容易偏。第二个问题是纯向量的召回不够稳。有些实体、编号、关键词向量检索真的不如关键词检索。比如你搜BUG-1024这种精确编号向量模型可能给你拉出一大堆语义相关却完全不对的内容。所以生产级的做法是混合检索向量检索保证语义召回BM25 关键词检索保证精确匹配然后两者做融合。融合之后往往还需要重排序。第一轮检索通常召回 20-50 个候选块重排序模型cross-encoder会逐一对问题-候选块打分选出最相关的 3-5 块。为什么需要这一步因为双塔 embedding 模型把问题和文档分别编码语义交互信息有限而 cross-encoder 是把问题和文档拼接在一起过模型交互更充分但耗时也成倍增加。所以正确姿势是向量检索快速初筛重排序精排兼顾效率和质量。我用一个类比来说明向量检索是在图书馆里快速找出一摞可能有用的书重排序是坐下来翻阅这些书把最相关的几页挑出来。一个负责找得全一个负责找得准。2.6 生成环节提示词里到底要不要放元数据检索完成之后把候选块和用户问题拼进 Prompt这一步也有讲究。很多人直接把文本块倒进 Prompt发现效果不稳定。生成环节的质量取决于两块内容本身的准确性和结构上的可消费性。内容准确性指的是检索结果里如果有相互矛盾的块模型会无所适从。所以需要在拼接时让模型感知到哪些内容来自哪些来源、可信度如何最简单的方式是在每块前面加上文档来源标识和相关性分数。结构可消费性指的是大段原文直接堆在 Prompt 里模型很容易被淹没。实践中常见做法是给每条检索结果加上定制的包装格式knowledge source产品手册-第三章 relevance0.87 原文内容 /knowledge这样模型能清晰地知道每段内容的边界和出处回答时也更容易做引用。另外Prompt 里要明确告诉模型知识库内容只是参考资料如果参考资料不足以回答问题要明确说不知道不要强行编造。3. 实操从零搭一个 Agent 知识库3.1 技术选型定一个省心的组合我实际搭建时用的一套组合是LangChain BGE 中文 embedding Chroma 向量库 DeepSeek/GLM 作为生成模型。这个组合的特点是全部组件在国内网络环境友好安装简单文档完善适合快速验证。你也可以换成 LlamaIndex 或 Spring AI核心流程是相通的。LangChain 在这条链路上主要负责三件事文档加载器的统一封装、分块和向量化的编排、检索器的接口抽象。它本身不是必需项你完全可以手写这个管道但在快速搭建阶段它能省下不少胶水代码。3.2 索引构建把文档变成可检索的向量下面我用 Python 演示完整的索引构建流程。先安装依赖pip install langchain langchain-community langchain-chroma chromadb sentence-transformers加载本地文档并用递归分块器切块from langchain_community.document_loaders import DirectoryLoader, TextLoader, PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_chroma import Chroma # 加载目录下的文本和 PDF text_loader DirectoryLoader(./docs, glob**/*.txt, loader_clsTextLoader) pdf_loader DirectoryLoader(./docs, glob**/*.pdf, loader_clsPyPDFLoader) documents text_loader.load() pdf_loader.load() # 清洗去掉多余空行和页面噪声 for doc in documents: doc.page_content \n.join( [line.strip() for line in doc.page_content.splitlines() if line.strip()] ) # 递归分块优先按标题/段落切块大小 500重叠 80 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , , , ], ) chunks splitter.split_documents(documents) # 加载本地 BGE 中文 embedding 模型 embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True}, ) # 构建向量库并持久化 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./kb_store, ) print(f总共索引了 {len(chunks)} 个文本块)这里几个细节值得说明。第一separators的顺序很重要它是按优先级匹配的先按双换行切段落再按单换行、句号、逗号往下走。这样保证大结构优先被保留。第二normalize_embeddingsTrue是为了让向量在做相似度计算时用余弦相似度更稳定。第三persist_directory是向量库持久化的位置下次启动可以直接加载不用重建。3.3 检索服务混合检索与重排序索引构建好之后真正的知识获取管道核心在检索端。我建议不要只做纯向量检索而是在 LangChain 里组装一个混合检索器from langchain_community.retrievers import BM25Retriever from langchain.retrievers.ensemble import EnsembleRetriever from langchain_core.vectorstores import VectorStoreRetriever # 向量检索器 vector_retriever VectorStoreRetriever( vectorstorevectorstore, search_typesimilarity, search_kwargs{k: 20}, ) # BM25 关键词检索器基于分块后的文本 bm25_retriever BM25Retriever.from_documents(chunks) bm25_retriever.k 20 # 混合检索器向量检索 0.6 权重关键词检索 0.4 权重 ensemble_retriever EnsembleRetriever( retrievers[vector_retriever, bm25_retriever], weights[0.6, 0.4], )混合检索器会先把两路结果都拿回来再做 score 归一化融合最后按融合分数排序。这一步能显著缓解纯向量检索在精确词匹配上的短板。如果要上重排序可以再接一个 cross-encoder 模型。动手能力强的可以用sentence-transformers的CrossEncoder加 BGE-rerankerfrom sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-large) def rerank(query, docs, top_k5): pairs [[query, doc.page_content] for doc in docs] scores reranker.predict(pairs) scored_docs sorted(zip(docs, scores), keylambda x: x[1], reverseTrue) return [doc for doc, _ in scored_docs[:top_k]]重排序之后的 top 5 块基本就是最终进 Prompt 的内容。这里有一个注意点bge-reranker-large 的输入长度有限制如果你的块超过 512 token需要截断或者换更长的 reranker 模型。3.4 Agent 如何接入这条管道到这里还是纯 RAG 服务。要把它接入 Agent关键是让 Agent 能主动调用检索能力把检索结果作为上下文用于后续推理和工具调用。以 LangChain 的 Agent 为例我把检索封装成一个 Toolfrom langchain_core.tools import tool tool def search_knowledge_base(query: str) - str: 搜索知识库返回与问题最相关的文档片段用于解答业务问题。 docs ensemble_retriever.invoke(query) docs rerank(query, docs, top_k5) blocks [] for i, doc in enumerate(docs, 1): source doc.metadata.get(source, 未知来源) blocks.append( f[{i}] (来源: {source})\n{doc.page_content} ) return \n\n.join(blocks)Agent 在推理时会自己决定要不要调用search_knowledge_base用户问题涉及私有知识时就会走这条管道。这种方式比每次都检索效率更高也符合 Agent 动态规划的特性。更进阶的做法是让 Agent 先拆解问题生成多个子查询再分别检索。比如用户问对比 A 产品和 B 产品的售后服务政策一个宽泛 query 可能检索效果很差Agent 可以拆出 A 产品售后服务和 B 产品售后服务两个子查询分别检索最后再汇总。这就是 Query Rewriting 和 Multi-Query Retrieval 的思路也是 Agentic RAG 的雏形。4. 常见问题与排查技巧实录4.1 检索结果相关但答非所问这个是最常见的现象检索出来的片段单独看都对但模型回答就是不对。出现这种情况我建议按以下顺序排查分块粒度是否合适块太大导致内容杂糅模型抓不住重点检索 top-K 是否合理K 太小可能漏关键内容K 太大上下文被无关信息淹没Prompt 里是否给了足够的指令约束是否明确要求只基于参考内容回答是否有跨块的关联信息答案需要拼接多个块的知识模型如果看不到全貌就会答偏排查方法也很直接把检索结果打出来人工看一遍看它和问题的相关性到底如何。如果检索结果本身就偏那是检索问题如果结果都挺准但答案不对那大概率是 Prompt 或分块问题。这里我强烈推荐一个调试习惯把每轮问答的完整链路都打印出来包括用户问题、子查询、检索到的块和分数、最终 Prompt。没有这些日志排查问题全靠猜效率极低。4.2 明明有答案但检索不到这类问题更让人崩溃。知识库里有明确的内容但检索时就是召不回。常见原因有几个embedding 模型的泛化能力不足同一个意思文档里用的是专业术语用户用的是口语向量距离过远分块时把关键信息切碎了比如一个知识点分散在两个块里每块都只含一半信息分词不匹配BM25 对中文分词敏感不同分词器效果差异很大针对召回不足的解决办法一个是做查询改写把用户口语问题改写成文档风格另一个是扩充召回范围——把 top-K 从 5 调到 20甚至 50然后靠重排序模型精选。还有一个很实用的招索引时把文档的标题、章节标题、摘要等信息拼到块开头相当于给每个块加了导读信息检索时这些位置往往更容易命中。4.3 索引更新之后线上不生效知识库内容更新了但线上问答还是旧答案。这个坑我在生产环境里踩过好几次。核心原因是向量库的索引没有同步更新有些向量库的删除操作是异步的旧向量可能还在索引里参与检索增量更新的文档没有重新切块新的内容没有被向量化检索端缓存了旧结果规范的做法是每次知识库变更都走一次完整的更新流程——删除旧文档对应的向量、重新加载和分块、重新 embedding、重新 upsert。更新完成后用几个知识探针问题验证一下确认新知识确实被检索到。如果用的是 Chroma注意persist_directory在每次写入后要执行持久化否则重启后数据可能回滚。4.4 性能问题与成本控制RAG 管道里最常见的性能瓶颈是 embedding 和 rerank 环节。embedding 计算是 CPU 密集型量大的时候处理速度会很慢rerank 的 cross-encoder 更慢因为它要逐对计算。我的优化策略是按优先级来的能缓存的都缓存相同问题在短时间内不要重复检索控制 rerank 的候选数量rerank 前先截断到 30-50 个不要拿全部结果去 rerankembedding 用 GPU 推理哪怕是一张消费级显卡速度也能翻好几倍向量检索前加前置过滤如果知识库有业务分类、文档类型等元数据先在元数据层面过滤减少向量搜索范围成本方面embedding API 的费用虽然不高但文档量大时也是一笔开销。本地部署开源 embedding 模型基本可以忽略边际成本这也是我前面推荐开源方案的原因之一。5. 评估与优化没有评测的 RAG 都是盲调5.1 评测指标怎么定RAG 系统的效果评估分两层检索质量和生成质量。检索质量看的是 hit rate命中率、MRR、RecallK生成质量看的是回答准确率、忠实度faithfulness、答案完整性。实操中最常用的一个指标是 hit rate判断正确的答案是否出现在检索返回的 top-K 里。这个指标实现成本低能快速反映检索环节的问题。做法是准备一批问题-预期答案所在文档的评测集然后用检索器跑每个问题看预期文档是否在返回结果里。我自己常用的评测集规模不大30-50 条就够了但每条都要覆盖不同的业务场景和问法风格。评测发现问题后调整方式和验证闭环改一个参数比如块大小跑同一套评测集看指标涨跌。没有这个闭环你改的任何配置都只是在碰运气。5.2 从 RAG 到 Agentic RAG前面拆的这套管道属于传统 RAG固定流程、固定检索、一次拼装。Agent 接入之后有了更大的发挥空间。Agentic RAG 的核心区别在于检索不再是问一个问题就查一次而是交给 Agent 自主编排。比如 Agent 发现第一轮检索结果不足以回答问题它可以继续追问、改写 query、检索另一个知识库甚至结合工具返回的数据再次检索。这种多轮、动态的知识获取行为才是 Agent 知识管道的完整形态。我在实际项目里体验最深的是传统 RAG 适合单轮问答Agentic RAG 适合多步任务比如帮我写一份新员工入职指引并对比公司内部制度文档和最近更新的政策这种需要反复查阅的任务。5.3 知识管道的演进方向RAG 这个领域变化很快目前几条值得关注的方向GraphRAG 利用知识图谱组织实体关系能回答需要多跳推理的问题LightRAG 做了更高效的图索引Ontology RAG 在文档检索之上增加本体约束让检索结果更符合行业术语体系。此外把 RAG 做成服务RAG as a Service也是国内不少平台的方向——知识库、索引、检索全托管业务方只需要对接 API。不过我的态度一直比较务实新技术出来先看它解决了什么真实问题而不是追新。GraphRAG 确实能提升多跳推理能力但它的构建成本和对算力的要求也不低。项目初期把基础 RAG 的每个环节做到位收益往往比盲目上新框架大得多。最后分享一点个人实感。很多人以为 RAG 的核心是模型和向量库但我在好几个项目里折腾下来发现真正的差距在数据治理和评测闭环上。你愿意花多少精力把文档清洗干净、把分块策略调好、把评测集做实你的知识管道就有多稳。模型和向量库只是执行者数据质量和评估体系才是决定 Agent 知识获取能力的上限。如果你也正在搭自己的知识管道建议第一步不要急着写代码先把你的文档摸底一遍想想哪些是结构化的、哪些是扫描件、哪些是干垃圾数据。这一步想清楚了后面就顺了。

RAG管道深度拆解：从索引、检索到生成的Agent知识获取指南

相关推荐

JMeter性能测试脚本编写与优化实战指南

TCP Socket编程实战：从基础到性能优化

低功耗SoC IP摄像头开源固件刷机与本地录像实践

更多资讯

Superpowers技能框架：提升Claude Code与Codex CLI的AI编程稳定性

Superpowers 框架：为 Claude Code 与 Codex CLI 构建可复用 AI 编程技能体系

Axure Bridge Chrome插件安装与排错全指南

RTK Query日志精简：3个钩子将500行测试输出压缩为LLM友好摘要

superpowers 框架实战：AI 编程助手能力增强与 Java 落地指南

无刷电机AX/BY/CZ绕组命名与120度电角度解析

今日更新

AI辅助技术栈评估：提升研发决策效率60%

从生成Token到直接决策：Jev如何重塑AI Agent工程实践

32G统一内存跑大模型：内存账、TPS实测与端云分流

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？