这个系列写到《走进 AI Agent》的第四篇我打算把镜头对准一个容易被低估的模块知识获取管道。前面聊过了 Agent 的基础结构、规划能力和工具调用但一个只能思考、没有知识来源的 Agent就像刚毕业的高材生推理能力再强面对具体业务问题时手里没有资料照样抓瞎。RAGRetrieval-Augmented Generation就是目前最接地气、最适合团队从 0 到 1 落地的知识获取方案同时也是 RAG 项目、本地知识库和 AI Agent 开发绕不开的核心话题。这篇我打算按实战路线来写先说明为什么 Agent 需要 RAG再把管道一层层拆开讲清楚最后给一套基于 LangChain 的本地 RAG 代码示例以及对检索质量、生产落地、Agentic RAG 的经验思考。如果你正在搭 AI Agent或者做知识库相关的东西这篇应该能帮你少踩不少坑。1. 为什么 AI Agent 需要一条知识获取管道1.1 大模型的天生短板知识截止与幻觉先说一个几乎每个 LLM 应用团队都会撞上的事实大模型的知识是“有截止日期”的。模型在被训练完的那一刻掌握的信息就基本固定了。它不知道你公司的报销制度不知道昨天发布的版本功能也不知道某个具体客户反馈了什么问题。你可以在提示词里塞一段背景可一旦内容超过上下文窗口或者每次都靠人工复制粘贴这事就没法规模化。比知识截止更麻烦的是幻觉。模型在不知道答案时并不会诚实地告诉你“我不知道”而会更倾向于生成一段听起来很合理的回答。放在对话场景里可能只是尴尬放在 Agent 自动执行任务、自动回复客户的场景里就是事故。我见过不少团队一开始只拿模型提示词做客服问答结果线上被用户截图投诉原因就是模型把不存在的功能说得像真的一样。所以要让 Agent 真正“知道”某个领域的知识不能指望把知识写进模型权重里而是要给它修一条获取知识的管道。知识获取管道让模型在回答之前先去查资料用查到的资料来约束生成。这本质上是从“闭卷考试”变成“开卷考试”模型仍然是那个会答题的人但手里的参考资料是真实、可更新、可追溯的。1.2 RAG 在 Agent 架构中的位置一个完整的 AI Agent 通常包含规划、记忆、工具调用和行动执行四块。RAG 可以算作“记忆”的一部分但又不完全是记忆。因为 Agent 的长期记忆通常需要支持写入和检索而 RAG 对外提供一个标准接口你给我一个问题我从知识库里找出相关的文本片段还给你。在实际系统里RAG 往往有两种接入方式。一种是直接参与生成用户提问后系统先从知识库检索上下文再把上下文和问题一起交给模型生成回答。另一种是把 RAG 包装成 Agent 的一个工具规划器决定“这个问题需要查知识库”于是调用检索器拿到结果后再决定下一步动作——是直接回答还是再查一次还是换一个知识库甚至调用其他工具补充信息。我经常被问到“Skill 和 RAG 怎么结合”。这两者不冲突Skill 解决的是“怎么做”RAG 解决的是“依据是什么”。比如客服 Agent 的 Skill 定义的是退款流程怎么走、需要几个确认步骤而 RAG 负责提供这个产品的具体退换货规则。Skill 告诉 Agent 动作顺序RAG 告诉它每一步背后的业务依据。把它们拆开设计之后的维护成本会低很多。1.3 为什么不是微调或超长上下文每次聊到知识获取总有人问“为什么不直接微调模型”我的回答是能接受成本你可以试但微调适合改变模型的风格、输出格式、专业术语习惯不适合做事实型知识更新。微调的成本包括数据标注、GPU 训练、模型版本管理而且一旦知识变了又要重新训练。更现实的问题是微调后模型依然会产生幻觉你没法掰开它的嘴确认某句话到底来自哪份资料。还有人会问“现在上下文窗口不是越来越大吗把所有文档都塞进提示词不就行了”把文档全塞进去短时间内好像解决了“知道”的问题但成本会暴涨而且长上下文里有大量无关信息注意力会被稀释模型反而更容易抓不住重点。检索的目的不是简单地把资料放到模型面前而是把“最相关的几段”放到模型面前。这跟开会前先看会议纪要而不是把公司三年邮件全打印出来是一个道理。RAG 的核心价值就在这里知识是外置的更新知识库不用重新训练模型知识是可控的每条回答都能追溯到来源文档知识是弹性的可以一个 Agent 挂多个知识库也可以按业务动态调整。2. 拆解 RAG 管道从文档到答案的完整链路2.1 RAG 的本质先查资料再写报告RAG 的官方解释是“检索增强生成”翻译成人话就是模型不直接凭记忆回答而是先在一堆资料里找出相关内容再结合这些内容组织答案。放进现实场景里它很像一个研究员的工作方式接到课题后先去档案室查材料把关键段落摘出来最后写报告而且报告里必须标注引用来源。这听起来不难但要把它做成一个稳定可用的知识获取管道比想象中复杂得多。数据是脏的格式是乱的用户问法千奇百怪检索出来的内容可能答非所问。所以 RAG 不是“向量数据库大模型”两行代码就完事而是由很多细节堆出来的工程系统。2.2 六段式管道概览我习惯把 RAG 管道拆成六个阶段接入、分块、向量化、存储、检索、生成。每个阶段都有独立的输入输出和易错点把它们分开看后面排查问题会清晰很多。阶段主要任务常见技术选型关键产出文档接入加载 PDF、Word、HTML、Markdown 等原始文件PyPDF、Unstructured、Tika清洗后的纯文本分块把长文本切成适合检索的片段RecursiveCharacterTextSplitter、语义切分结构化的 Chunk 列表向量化把文本转成向量让语义相近的内容在空间中靠近bge、text-embedding-3、m3e文本对应的 Embedding 向量存储索引存入向量库并建立索引Chroma、FAISS、Milvus、pgvector、Qdrant可检索的向量索引检索排序根据用户问题找回相关内容并做重排向量相似度、BM25、混合检索、RerankerTop-K 相关文本片段生成引用把检索结果与用户问题组装成 Prompt交给模型生成Prompt 模板、大模型、引用溯源带依据的最终回答这个管道最容易被忽略的是“接入”和“生成”两头。很多人一上来就做向量化结果发现 PDF 里的表格变成了乱码或者检索到了内容但模型没按内容回答。骨架搭好之后大概率要在两端来回调。2.3 索引阶段的设计要点索引阶段直接决定了知识库的“底子”。如果文档加载和分块做得糙后面无论怎么调检索都补不回来。我在这块踩过的坑比后面任何环节都多。文档接入不能只调一个库就完事。PDF 要区分文字版和扫描版扫描版得先 OCRPPT、表格这类结构化文件要尽量保留层级信息。我处理产品手册时经常发现关键参数在表格里表格一旦被简单按行拆开语义就全断了。所以接入阶段不要怕麻烦宁可多花时间把文档结构搞清楚也不要直接一把梭。分块策略更是重灾区。常见做法是用 RecursiveCharacterTextSplitter 按固定字符数切但我强烈建议先按文档结构切比如 Markdown 标题、PDF 章节、HTML 标题再结合段落切。单块大小一般控制在 200 到 800 个 token 之间同时保留 10% 到 20% 的重叠。块太大向量里噪声多检索精度下降块太小语义不完整模型拿到手也读不出完整逻辑。不要迷信网上某个“最佳实践”不同业务语料的最优块大小不一样后面我会专门讲怎么用 hit rate 验证。Embedding 模型选型也要看场景。中文场景里开源模型像 bge-m3 这类效果已经不错英文场景选择更多。Embedding 模型一旦选定了入库和查询必须用同一个模型换模型就意味着重新索引。向量库的选择则看数据量和团队运维能力小项目本地用 Chroma 或 FAISS 很轻量上了规模、要支持权限过滤和高并发再考虑 Milvus 或 pgvector。3. 实操基于 LangChain 从零搭一个本地 RAG3.1 环境准备与依赖安装这一节我按最常见的本地 RAG 项目来写用 LangChain 做管道编排本地加载一个 PDF 文档切片后向量化最后提问和回答。先装依赖我建议用干净的 Python 3.10 以上环境pip install langchain langchain-community langchain-huggingface chromadb pypdf如果你的网络环境里 HuggingFace 下载模型不方便可以把 Embedding 模型换成本地已有的模型目录或者直接用浏览器下载模型文件后加载本地路径。我自己的习惯是先把原始文本抽取出来单独跑一遍确认能正常加载后再连向量库这样出了问题更容易定位。3.2 文档加载与分块实现下面这段代码加载一个本地的 PDF 文件并按字符数做初步切块from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter loader PyPDFLoader(./product_manual.pdf) documents loader.load() text_splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap50, separators[\n\n, \n, 。, , , , ] ) chunks text_splitter.split_documents(documents) print(f切分完成共 {len(chunks)} 个文本块)注意加载回来的 document 对象通常自带page_content和metadatametadata 里一般有页码信息这个后面做引用溯源很有用。有些 PDF 页眉页脚会混进来最好在加载后用正则先清理一遍。切分器里的separators顺序是有讲究的它是按优先级逐个尝试的优先按段落切实在不行再按标点切最后才按字符硬切。这样做能最大限度保留语义完整性。3.3 向量化与入库接下来选择 Embedding 模型并把切片写入向量库。这里用 HuggingFace 的 bge-m3 做示例你也可以换成其他模型from langchain_huggingface import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-m3, model_kwargs{device: cpu}, encode_kwargs{normalize_embeddings: True} ) vector_store Chroma.from_documents( documentschunks, embeddingembedding_model, persist_directory./chroma_db )normalize_embeddings建议打开这样后续计算相似度时会稳定一些。Chroma 的persist_directory是数据落盘的位置测试阶段直接删掉重新跑也不心疼。如果你后续要换 Embedding 模型记得连这个目录一起删掉重新索引否则新旧向量混在一起会影响检索结果。3.4 检索与生成串联向量库建好后可以把它变成检索器再组装回答链路。这里用最基本的 LCEL 写法retriever vector_store.as_retriever( search_typesimilarity, search_kwargs{k: 4} ) from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o-mini, temperature0) prompt ChatPromptTemplate.from_messages([ (system, 你是一个企业知识库助手。请仅根据下面的资料回答问题不要凭记忆编造。 如果资料不足以回答请直接说“根据现有资料无法回答”。\n\n资料{context}), (human, 问题{question}) ]) def format_docs(docs): return \n\n.join(doc.page_content for doc in docs) rag_chain ( {context: retriever | format_docs, question: lambda x: x[question]} | prompt | llm | StrOutputParser() ) result rag_chain.invoke({question: 这个产品支持哪些连接方式}) print(result)这段代码的核心就是把检索出来的内容先格式化然后塞进 Prompt。把temperature调成 0 是刻意为之RAG 场景下尽量让模型克制一点少一点创造性多一点忠实度。系统提示词里那句“资料不足就直说”非常重要这是抑制幻觉的第一道防线。3.5 不同技术栈的落地参考LangChain 只是其中一种选择。Python 生态之外Java 项目可以关注 LangChain4j 和 Spring AI两者都对 RAG 流程做了不错的封装尤其是 Spring AI 提供了与 Spring Boot 紧密结合的接口适合企业级应用平台把 RAG 能力嵌进现有服务。C#/ .NET 团队则可以看 Semantic Kernel它把记忆、规划、工具调用统一在了一套抽象里。我见过不少 ERP 加 RAG 加 LLM 的产品检索需求团队技术栈五花八门其实核心流程都差不多文档入库、切片、向量化、检索、生成差别只在框架 API 上。4. 检索质量决定 RAG 天花板的关键4.1 先用 Hit Rate 给检索效果定标RAG 生成质量的上限是检索质量。如果检索出来的资料本身不含正确答案模型再强也答不对。所以我做 RAG 项目第一件事不是调 Prompt而是先做检索评测。最常用的一个指标叫 Hit Rate也叫 RecallK意思是在一个评测问题集里有多少比例的问题正确答案出现在检索结果前 K 个片段中。比如你有 100 条测试问题设置 K4如果其中 80 条问题的正确答案出现在 Top-4 里Hit4 就是 80%。这个指标非常直观用来验证分块策略、Embedding 模型和检索方式是否有效。除了 Hit Rate我还会看 MRRMean Reciprocal Rank。它衡量正确答案在结果里排得多靠前如果正确答案排第一这一条得 1 分排第二得 0.5 分依此类推。对于“用户只看第一屏结果”的场景MRR 比 Hit Rate 更贴近体感。生成质量方面可以用 RAGAS 这类框架评估 faithfulness 和 answer relevance但前提是检索已经过关。4.2 分块大小与 Embedding 模型怎么调我试过一个典型的中文产品知识库512 字符分块Hit4 约 82%切成 256 字符后Hit4 掉到 74%改成 1024 字符后Hit4 是 79%。看起来 512 最好但换一个文档结构完全不同的语料结论可能反过来。分块大小的选择要跟着语料走如果一段话里包含完整的问答对用小块更好如果业务描述逻辑连续、跨越多个段落就需要大块甚至父子分块。下面是不同分块大小的表现特征可以对照自己的场景来选分块大小优点风险适合场景128-256检索精准噪声少语义可能被切断问答对、规格参数说明400-600效果均衡通用性强需要重叠避免切碎大部分产品手册、制度文档800-1200上下文完整度高噪声增加成本上升技术方案、长段落报告父子分块既有精度的又有上下文实现复杂些对回答质量要求高的业务Embedding 模型对比不能只看常识问答。我建议拿自己的业务语料跑几条典型问题看相似度排序是不是跟直觉一致。有些模型在通用语义上很强但遇到产品型号、代码片段、行业黑话就表现一般。必要时可以做一个小规模测试集批量对比 HitK用数据说话。4.3 混合检索与重排从“能用”到“好用”纯向量检索的问题在于它只懂“语义”不太擅长处理精确匹配。比如用户查“A100 型号”向量检索可能把“A1000”也检索出来反过来用户输入有错别字或专有名词缩写向量检索也可能找不到。解决办法是做混合检索把传统关键词检索BM25和向量检索结果合并再重新排序。重排是另一个性价比很高的优化。第一次用向量检索先把候选集扩大到 20 到 50 条再用一个更强的 reranker 模型做精排只保留 Top-4 或 Top-5 给大模型。这种做法能明显提升准确率。常见方案有 bge-reranker 系列部署也不复杂。重排阶段虽然多了几步计算但换来的是回答质量的稳定提升生产环境我基本都会加。4.4 查询改写与 Metadata 过滤用户问的问题往往很短比如“这个怎么退”如果知识库里都是完整句子直接拿这句话去检索效果不会太好。可以先让大模型把问题补全比如改写成“这个产品如何申请退货退款”再去做检索。技术上可以叫查询改写或 Query Rewriting。还有一种思路叫 HyDE就是先让模型根据问题生成一段伪答案再用伪答案去做相似度检索等于把“模糊的问题”变成“接近答案的文本”在某些场景下效果有惊喜。Metadata 过滤容易被忽略但它能大幅减少无关结果。比如知识库里同时包含多个产品线的文档每条 chunk 都打上“产品线”“文档类型”“日期”等标签。检索时先根据用户问题过滤产品线再做相似度检索。这比把所有文档混在一起检索要准得多尤其是知识库变大了以后Metadata 过滤是必选项。5. 进阶从 RAG 到 Agentic RAG5.1 普通 RAG 不够用的时候基础 RAG 流程是“检索一次、生成一次”它假设问题和资料是一一对应的。但现实中的问题往往更复杂用户先问“这个设备支持远程控制吗”再追问“那报警功能怎么设置”或者问“对比一下 A 型号和 B 型号的功耗差异”。这类问题需要多次检索、多文档对比甚至要根据前面的回答来调整下一步检索。普通 RAG 管道比较傻一次检索不到正确信息它不会换个姿势再查一次。这时候 RAG 就需要具备“智能体”的特征让 Agent 来决定查什么、查几次、查完之后是否继续行动。这个概念现在常被称为 Agentic RAG也就是把 RAG 能力封装成 Agent 的工具或行动策略用规划能力去调度检索过程。5.2 Agentic RAG 的核心模块我理解 Agentic RAG 不单单是“给 RAG 加个循环”而是要让系统具备四个能力。第一个是查询理解能识别出复杂问题需要拆解成子问题第二个是检索策略选择能决定用向量检索、关键词检索、SQL 查数据还是调用外部搜索第三个是记忆能记住之前的检索结果和对话上下文避免重复问同样的问题第四个是自我校验能在生成回答前检查检索结果是否足够支撑结论不够就回头再查。打个比方普通 RAG 是“图书管理员”你问什么他拿什么Agentic RAG 是“专家助理”他会先理解你到底要解决什么问题发现第一份资料不够再去翻行业报告、调历史项目数据最后给你一个完整的判断。在工程实现上可以用 LangGraph、ReAct 框架或者其他 Agent 编排框架来做控制流把检索器、重排器、大模型、外部工具都编排成一个可循环的过程。5.3 GraphRAG、Ontology RAG 与知识割裂问题纯向量 RAG 还有一个隐形问题它把每段文本孤立看待切出来的 chunk 之间没有任何关联回答不了“实体之间的关系”类问题。比如“这个故障会不会影响数据采集模块”知识库里有故障描述和数据采集模块的独立文档但没有一段话同时提到两者向量检索就很难把两段知识串联起来。这就是常说的“知识割裂”问题。RAG 解决的是“模型不知道私有知识”但没解决“知识之间没有关系网”。GraphRAG 的思路是在文档里抽取实体和关系构建知识图谱检索时不只查片段还查实体之间的关联路径从而支撑多跳问题。Ontology RAG 再进一步把知识图谱上加上本体层/概念体系让 Agent 能按业务逻辑去推理而不是只做文本匹配。与之类似的思路还有 LLM Wiki把知识沉淀成结构化的、互相链接的 Wiki让 Agent 在回答时先找到领域入口再细化到具体条目。这些本质上都是在 RAG 外面加一层“知识组织层”。5.4 生产落地与 RAG as Service真正把 RAG 部署到生产环境要面对的事情比 demo 多得多。权限隔离是第一个问题不能让所有用户共享同一个知识库至少要按团队或租户做数据隔离。数据更新也是坑文档改了之后要能增量更新而不是每次全量重建索引。还有可观测性要能查看某次回答命中了哪些文档、走了哪些步骤不然线上出了问题无从查起。行业内已经开始把 RAG 能力沉淀为“RAG as Service”也就是把知识接入、切片、索引、检索、重排都做成标准 API上层 AI Agent 只需要调用服务接口。这样可以避免每个项目都重新写一套管道。我在企业级 AI Agent 应用平台上看到的一个趋势是RAG 不再只是一个库或框架而是平台级的基础设施。对于 Java 技术栈的团队Spring AI、LangChain4j 这类封装能帮助把 RAG 嵌入统一的应用平台对于需要和 ERP、产品主数据打交道的场景RAG 往往还要对接已有系统的 API而不只是读静态文档。6. 常见问题与排查实录6.1 检索不到内容先检查这四步很多“模型回答不对”的问题根源其实是“压根没检索到”。我排查时会按下面顺序走每步都能过滤掉一批问题。第一步看分块。把用户的问题拿到知识库里人工搜一遍看看答案是不是被切碎在了不同 chunk 里。如果答案内容跨了两个 chunk或者关键句刚好在分割线上模型就算拿到了也不完整。第二步看 Embedding 模型。确认查询时用的模型和索引时用的模型完全一致包括本地模型路径、版本、参数不一致会出现“检索结果乱飞”的现象。第三步看 Top-K。K 设太小可能把正确答案挤掉了K 设太大又会有太多噪声建议从 4 到 6 开始调。第四步看 Metadata 过滤条件。别小看这个我遇到过线上环境因为日期过滤条件写死导致所有近期文档都搜不到的情况。6.2 回答质量差问题通常出在生成环节如果确定检索结果里已经有正确答案但模型还是答偏了那问题多半在生成侧。最常见的错误是提示词里没有明确“只依据资料回答”。模型一旦觉得资料不够就会自动用预训练知识补全补出来的内容看着合理实际上没有依据。好的做法是在 Prompt 里写死边界“只能使用参考资料回答如果资料不足直接回答无法判断回答时尽量引用资料原文中的关键句。”第二个常见问题是把整个原文不做筛选地塞给模型。有些团队担心漏信息把 Top-10 的全部内容都放进上下文结果模型被无关资料干扰。先重排只保留最相关的 3 到 5 条通常比塞一堆相关内容效果更好。第三个问题是模型需要引用来源时Prompt 里没有给出 chunk 的 metadata 信息。我给每个 chunk 都保留文档标题、页码和产品线标签生成时要求模型在结论后面标注来源比如[产品手册-v3.pdf 第12页]这对企业场景非常重要。6.3 性能与成本优化笔记用户量上来之后性能优先考虑缓存。完全相同或高度相似的问题可以直接走缓存不用重新检索和生成。其次是向量索引参数Chroma 默认配置能跑 demo但上了百万级向量后需要调 HNSW 的M和ef_construction这些参数直接影响检索速度和精度。再就是 Embedding 计算可以批量编码而不是一条条调接口如果用开源模型可以考虑量化或上 GPU 推理吞吐量差别很大。成本控制方面把“检索”和“生成”分开看。检索阶段用小模型就能完成生成阶段再用强模型。有些简单查询甚至不需要生成直接返回检索到的最佳片段就行。还有一个容易忽略的成本点是分块重复索引同一个文档被多次加载到向量库会产生大量重复向量既占空间又干扰检索。入库前要做去重或者至少维护一个文档版本表。6.4 经验速查表关注点建议做法原因文档加载区分扫描件、表格、复杂版式避免关键信息在解析时丢失分块按结构优先配合 10%-20% 重叠兼顾语义完整度和检索精度Embedding中文优先 bge 系换模型重建索引向量空间一致性决定检索质量检索向量 BM25 混合必要时重排语义匹配和精确匹配互补提示词明确“资料不足就直说”压制幻觉让模型保持克制溯源保留 chunk 的文档元数据回答可追溯便于定位问题权限按租户/团队隔离向量库防止越权读取知识更新增量更新而不是全量重建节省成本保证数据新鲜度最后再分享一个我个人的习惯。每次做一个新的 RAG 项目我不会一上来就追求复杂架构而是先花一天时间把最小的端到端管道跑通一份文档、一次检索、一次回答。跑通之后再做评测、看 badcase、逐步优化。RAG 的坑几乎都藏在真实数据里只有先把管道完整走一遍你才能知道自己的问题到底出在解析、分块、检索还是生成。后续如果要把这个管道升级成 Agentic RAG也别忘了先把基础管道的指标拿在手里否则你根本说不清楚到底是 Agent 的规划变好了还是单纯检索变强了。