从“知识割裂”到“Agent有记忆”这是我做AI Agent系列第四篇最想聊透的一件事。前几篇我们拆了Agent的规划、工具调用和记忆机制这一篇回到一个最基础、也最容易被低估的环节知识获取管道。RAGRetrieval-Augmented Generation检索增强生成在2024年之后几乎成了Agent项目的标配但很多人在搭的时候只是照着教程抄了一遍向量数据库结果一问就胡说一查就空白。这篇我把RAG底层的索引、检索、增强、生成四个环节拆开讲结合我实际跑过的LangChain、Spring AI和本地知识库项目说说哪些参数真正影响效果哪些瓶颈是架构问题而不是调参能解决的。不管你是刚入门还是已经在Agent项目里踩过坑这篇都值得花十分钟读完。1. 为什么Agent需要一套“知识管道”1.1 LLM的天生短板与知识割裂大语言模型的强项是语言理解和生成但它的知识来源于训练语料的一个快照。这意味着两个天然问题一是知识有截止日期2025年的模型无法准确说出2026年发布的产品的接口细节二是训练语料覆盖不均对垂直领域、私有数据、实时数据基本束手无策。我们做ERP系统集成的时候业务方拿着产品手册来问“这个订单状态什么时候能自动流转”模型如果没读过这个手册就只能靠猜。这种“知识割裂”不只是信息缺失它会让Agent在关键决策时一本正经地编造答案这比直接说“我不知道”危险得多。有朋友问那我把所有文档塞进Context不就行了受限于上下文窗口和注意力机制塞几十万字进去模型会“迷失在中间”检索关键信息的能力反而下降而且成本高、延迟大。所以我们需要一套机制让Agent在回答之前先找到最相关的知识片段再把片段原样提供给模型参考。这就是知识获取管道的意义——它负责“取回事实”而不是“编造事实”。1.2 RAG的本质把知识挂载到生成流程上RAG的直观理解是“先搜索后生成”。用户提问进来系统先去一个外部的知识库本地文档、数据库、API返回里检索出若干条最相关的文本片段然后把这些片段作为上下文和问题一起交给大模型生成最终答案。这样模型不需要记住所有知识它只需要学会如何从给定的片段中提炼答案。这个做法在2017年就有了领域雏形但真正爆发是2023年以后因为向量检索和Embedding模型的成熟让“语义相似度检索”变得又快又准。RAG解决的不只是知识陈旧问题。它让知识可更新——文档变了重新索引一遍就行模型不用重训它让知识可追溯——答案可以引用检索到的原文方便审计和纠错它让知识可隔离——不同部门、不同项目可以挂在不同的知识库下Agent按场景选择。我在给一家制造企业做生产异常分析Agent的时候就是把设备手册、维修记录、传感器日志分别做成三个知识库Agent根据问题类型决定检索哪份语料效果比把所有内容塞进一个大库好得多。2. RAG管道的四个核心环节2.1 文档加载与切分决定检索质量的上限很多教程一上来就讲向量数据库这是本末倒置。RAG管道的起点是文档处理这一步的质量直接决定了检索效果的上限。加载环节要处理PDF、Word、HTML、markdown等格式我建议用LangChain的「文档加载器」体系或者Hugging Face的DocumentReader它们能保留标题层级和表格结构。这里有个容易踩的坑PDF直接按文本提取会丢段落结构尤其是多栏排版得用布局识别模型先还原阅读顺序。切分策略是RAG中最玄学、也最有价值的环节。切得太小比如100个字符每条片段缺乏上下文检索到但答不完整切得太大比如整个章节向量平均化导致语义不聚焦检索精度下降。根据我的经验一般从300到800字符起步重叠量设为10%到15%然后在你的具体文档上做评测不要照搬800这个默认数。代码文档和自然语言文档要分开处理代码建议按函数块切自然语言按段落和标题层级切。切分时保留元数据标题、来源、页码后面做引用回答时很有用。2.2 向量化与存储Embedding模型的选择把文本片段转成向量是确保语义检索理解力的一环。Embedding模型的选择有这么几个层次中文场景优先考虑「bge-m3」「bge-large-zh」这类专门优化过中文的模型效果比直接用OpenAI的text-embedding-ada-002更贴合国内语料代码场景用「code-embedding」系列如果要跑本地且对硬件敏感可以选5亿以内参数的模型。注意不同Embedding模型输出的向量维度是不一样的我们项目里从768维切到1024维存储空间涨了一些但检索精确率提升了近8%。向量存储上Milvus适合百万级以上的大规模生产环境Qdrant和Weaviate在中小项目里更轻量单机场景用Chroma和FAISS就够了。不要一开始就上分布式向量库项目复杂度会剧增。真正让RAG产生业务价值的是“混合检索”能力向量相似度擅长解决“同义词、口语化提问”而关键词和BM25擅长解决“精确术语、型号、编号”。比如用户问“这个设备报警代码E204怎么处理”假如知识库原文写的是“故障204”向量检索不一定能匹配精准但BM25按关键词“E204”一搜就出来了。所以生产级RAG通常用「稀疏向量稠密向量」双路召回。2.3 检索策略从Top-K到混合检索检索环节最容易犯的错误是只取Top-K条不做筛选融合。我见过太多项目直接similarity_search(k4)就传到Prompt里结果答案质量的波动很大。一个合理的最小流程是先用混合检索拿到候选集再接一个重排模型Reranker对候选集做精细打分最后按阈值过滤掉低分片段。Reranker在本地跑bge-reranker有十几亿参数但用推理引擎量化后单条查询也就几十毫秒。它的作用是把向量召回的前20条精确地重新排到前5这差距在业务文档里特别明显。阈值设置也需要根据场景动态调。有些知识库文档表述模糊高阈值会导致检索不到有些文档词面相似但语义不一致低阈值又会招来噪声。我的做法是跑一个评测集记录不同阈值下的命中率和答案正确率画曲线找出拐点。高价值场景宁可少答也不乱答用高阈值客服场景宁可多给候选用低阈值。2.4 增强生成把上下文塞进Prompt检索完成之后你需要把这些片段整理成Prompt里的上下文块。这个过程不只是“把所有片段拼起来”而是要设计结构让模型学会区分“事实”和“模型自身知识”。我一直在用的一个模板是你是一名基于以下资料回答问题的助理。如果资料中没有足够信息请明确回答“资料中未找到相关内容”不要猜测。 资料块 [1] 来源设备手册第12页 内容故障E204表示压力传感器异常先检查接线…… [2] 来源维修记录2026-03-15 内容复位流程为断电重启并重新校准…… 问题E204报警怎么处理 回答要求优先使用资料块中的内容引用编号。这样的Prompt有几个好处来源备注让模型知道每段信息的可信度禁止猜测的指令减少幻觉要求引用编号让后续人工核对成为可能。还有一点容易被忽略——上下文顺序。最新的、与问题最相关的片段放在最前面因为LLM在长上下文中对开头和结尾位置的注意力更强。这个问题可以在后续做Agentic RAG时通过“自我反思”环节继续优化。3. 从基础RAG到Agentic RAG检索不再是一次性动作3.1 基础RAG的局限性单轮检索的盲区基础RAG是“问题进答案出”的单轮模式看起来很合理但实际业务中问题往往没那么直白。比如用户问“为什么上个月产量下降了8%”你要先检索到产量数据表再检索到设备停机记录再关联到维修日志然后才能给出分析。单轮RAG只会机械地拿“上个月产量下降”去搜可能会搜到一堆看起来相关但没用的事实。这时模型就无法综合多源信息回答问题。这就是为什么基础RAG在企业场景里评测得分不错一上线就露馅。另一个局限是无法处理多跳问题。用户问“A产品在B地区的退货率是多少”你得先搜A产品的型号再搜B地区的订单表再关联退货原因这是多步推理任务。把这一步全扔给基础RAG就相当于让一个只会单步搜索的人做侦探工作。3.2 Agent如何编排RAG多步查询、工具调用与自我反思Agentic RAG的思路是把检索决策交给Agent。Agent先解析用户问题拆成若干子查询分别检索再汇总。比如上面的产量下降问题Agent会先调用“产量查询工具”获取月度数据发现3月设备运行时长异常于是再调用“设备日志检索”查那台设备的故障记录最后生成结论。整个过程不是预设好的规则而是根据每次结果动态调整下一步。这就是“工具调用”与RAG的结合。我实操过的模式有三种路由型先分类问题比如“价格咨询”走产品知识库“售后问题”走故障知识库“技术参数”走官网文档库再进各自库检索。多查询型把用户问题改写成几个不同角度的子问题分别检索后合并去重。自我反思型模型先生成一段答案草稿再对着检索片段做事实核查如果缺失信息就发起新的检索。这就是业界常说的Self-RAG能明显减少幻觉。需要注意Agentic RAG不是越复杂越好。每多一步模型调用延迟和成本都翻倍。我的经验是先判断业务问题是否需要多步不需要就直接走基础RAG只有评测发现多跳问题占比较大时再引入Agent编排。3.3 实战案例本地ERP产品检索的语义内核实现我最近给一家企业做了“本地ERP RAG LLM”的产品检索方案这个案例很能说明问题。他们的ERP里有上万条产品编码、规格参数和库存状态原先的搜索只能靠精确匹配业务人员在系统里找一个旧型号经常要翻十几页表格。我们做的语义内核是把ERP产品数据导出成结构化文档每行生成一段“产品描述文本”内容包括型号、规格、适用场景、替代关系。然后把这些文档切块向量化放在本地向量库。用户用自然语言问“有没有能替代老型号Q234的防爆型传感器”系统先通过向量检索找到候选型号再用Reranker精排最后让LLM把结果组织成对比列表。这里有一个关键的实现细节给每条产品数据生成描述文本时不能只拼接字段值要把同义词和行业黑话也填进去。比如老型号“Q234”在描述里就要加上“防爆”“传感器”“型号已停产”这些标签否则用户换个说法就搜不到。我们管这个叫“语义丰化”是RAG落地最容易被忽略的步骤。这个项目上线后检索命中率从54%提升到92%人工查表时间平均减少70%。所以RAG不是简单的“上一个库”而是要从业务语言出发去设计你的知识表示。4. 落地实战基于LangChain搭建一个最小RAG管道4.1 环境准备与依赖我自己最常用的一套组合是LangChain FAISS Qwen或DeepSeek这类中文本地模型再配一个Reranker。如果你对Spring生态更熟用Spring AI的VectorStore抽象也能实现同样的流程。这里以Python环境为例pip install langchain langchain-community langchain-huggingface pip install faiss-cpu sentence-transformers pypdfEmbedding模型我推荐BAAI/bge-m3中文支持稀疏向量Reranker用BAAI/bge-reranker-v2-m3。FAISS足够跑几万条知识片段不需要上重型数据库。4.2 代码实现加载、切分、向量化、检索、生成下面这段代码是一个真正能跑通的最小闭环我用注释标出了每条关键步骤的意图from langchain.document_loaders import PyPDFLoader, DirectoryLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_community.vectorstores import FAISS from langchain.prompts import PromptTemplate from langchain.llms import HuggingFacePipeline from langchain.chains import RetrievalQA # 1. 加载本地文档目录下的所有PDF loader DirectoryLoader(./data, glob**/*.pdf, loader_clsPyPDFLoader) docs loader.load() # 2. 按标题层级递归切分块大小500重叠50 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , ] ) chunks splitter.split_documents(docs) # 3. 使用bge-m3做向量化 embeddings HuggingFaceBgeEmbeddings( model_nameBAAI/bge-m3, encode_kwargs{normalize_embeddings: True} ) # 4. 建立FAISS索引并持久化 vectorstore FAISS.from_documents(chunks, embeddings) vectorstore.save_local(./faiss_index) # 5. 检索先召回20条候选再用Reranker精排取前5 retriever vectorstore.as_retriever(search_kwargs{k: 20}) # 这里可以用langchain的ContextualCompressionRetriever封装Reranker # 6. 设计增强生成模板 prompt PromptTemplate.from_template(你是一个严谨的助理。仅根据下列资料回答问题资料不足时明确说“资料中未找到相关内容”不要编造。 资料 {context} 问题{question}) # 7. 组装RAG问答链 qa RetrievalQA.from_chain_type( llmllm, retrieverretriever, return_source_documentsTrue, chain_type_kwargs{prompt: prompt} ) result qa.invoke(E204报警怎么处理)生产环境里第5步要换成混合检索FAISS只能做向量检索BM25关键词检索可以借助LangChain的BM25Retriever做并行召回再合并。第6步的Prompt模板要按业务调不要直接用默认。4.3 效果调优chunk大小、检索阈值、Prompt模板调优的顺序很重要不要一上来就换Embedding。我建议按照下面的优先级走调chunk大小在你的评测集上对比512、256、1024三种切分方式的F1值。这个变量影响最大效果差10个百分点很常见。调检索召回数从k5开始逐步加到k20同时加入Reranker。你会发现召回数量大但精排后留下的总是少数这时候阈值设成0.35到0.5之间比较合理。调Prompt模板加上“如果信息不完整列出你需要的额外信息”这类指令有时候模型会主动提出需要检索什么这对后续接Agentic RAG很有帮助。最后才换模型如果上述都没解决再考虑替换Embedding、Reranker或生成模型。因为换模型成本高而且新模型未必适合你的语料。有一个容易被忽略的调优点文档切分后向量的余弦相似度对文本长度比较敏感。同一段内容如果一半是描述一半是表格向量会被表格稀释。这时建议把表格单独提取出来转成纵向的key-value文本再和正文分开展示。我在处理产品参数表时深有体会把两列参数表转成“参数名值”的纯文本后检索精确率提升明显。5. 常见问题与排查技巧5.1 检索命中率hit rate为什么上不去“hit rate”是衡量检索阶段的关键指标在评测集中系统是否能检索到包含正确回答的文档片段。如果你的hit rate一直偏低大概率不是模型问题而是数据问题。排查顺序如下先看文档切分是否破坏了语义主题。如果你把一整段“故障处理步骤”从中间切开了那谁都检索不到完整答案。尝试把chunk_size调大或者改用按标题结构的切分器比如MarkdownHeaderTextSplitter。再看Embedding对业务术语的敏感度。如果你的知识库全是型号、缩写那通用Embedding模型很可能不认。建立一个术语表在文档切分时把缩写和全称扩展成同义文本。然后是检索策略。只用了向量检索吗加上BM25混合召回对hit rate的改善通常比换模型更快。最后看查询改写。用户的问法不会自动和文档关键词对齐用一个LLM把口语问题转成几个关键词组合也能提升召回。我在本地知识库项目里遇到过最典型的案例是“用户搜Java多线程知识库里有‘并发编程’”纯向量检索死活召回不到。后来做了查询扩展把“多线程”和“并发”“线程池”“ExecutorService”一起检索问题当场解决。5.2 RAG的经典瓶颈与破解思路我总结了三个最常见的瓶颈可以说每个真实项目的RAG都会踩到瓶颈一检索到的片段有冲突。知识库里有新旧两版说明对同一操作给出不同步骤。解决办法是给文档加一个“版本/日期”元数据字段检索时按最新时间过滤或者在Prompt里让模型优先采用指定版本号。瓶颈二上下文窗口装不下。检索出20段每段500字再加上问题已经超过一些小模型的上下文限制。破解方案不是暴力截断而是把检索结果分块喂给模型先把前5段放进去如果模型需要额外的信息再补充检索。这正是Agentic RAG的用武之地。瓶颈三答案“好像很有理但其实是错的”。这是零证据幻觉。调用一下事实核查流程让模型在输出答案时同时给出参考片段的编号你再检查编号是否真的包含答案的核心事实。如果经常出现“引用来源但内容对不上”多半是Prompt模板没把“忠实于片段”的约束写清楚。关于RAG瓶颈还有一句真心话很多问题是“知识表示”问题而不是“检索技术”问题。你文档组织得一团糟用再强的RAG框架也救不回来。所以每次项目启动前我建议先花一周时间清洗和重构知识源文档这比写代码值得多。5.3 进阶方向GraphRAG与Ontology RAG走到这里基础RAG的边界你已经看清楚了。接下来如果业务的“多跳关系”问题增多可以考虑GraphRAG先做实体识别和关系抽取构建知识图谱检索时先定位实体再沿边展开。GraphRAG对“A产品影响B产品B产品影响C产线的停产”这类问题表现远好于纯向量检索。但它的搭建成本高实体抽取准确率不稳定不适合小项目。Ontology RAG则是更进一步它不只是抽取实体还定义实体之间的语义关系规范相当于行业规则。比如“订单是客户的子实体订单包含产品产品有采购周期”有了这层本体约束检索更精准但需要领域专家参与建模。对于多数团队我建议先跑通基础RAG在评测集上确认多跳问题占比超过20%再考虑GraphRAG否则就是给自己找事。说到从0到1搭建AI Agent的这个系列我的最大体会是RAG不是锦上添花的插件而是Agent能不能真正走进业务场景的及格线。一个没有知识获取管道的Agent就像一个新入职的员工态度再好不了解公司业务和客户资料就没法独当一面。RAG就是那条把外部知识持续不断地喂给Agent的管道值得你花至少一周时间把基础打牢。先找一份真实的业务文档按这篇里的流程亲手跑通一遍你踩过的坑都会变成后续Agent能力的底气。