AI Agent系列写到第四篇我觉得是时候聊聊那个最容易被低估、却最能决定Agent靠不靠谱的环节——知识获取管道。官方叫法你可能已经听过无数遍RAGRetrieval-Augmented Generation检索增强生成。热搜里那些 rag知识库、rag实战、本地知识库、rag检索、rag框架说的其实都是同一件事怎么让大模型在回答问题时先查到资料、再组织答案而不是全靠脑子里那点训练记忆硬编。这文章的目标很直接把RAG从概念到落地讲透。你会搞清楚为什么Agent必须有一条知识获取管道RAG的完整链路里每个环节都在干什么怎么用一段可运行的代码搭出最小可用的知识问答Agent以及真实项目中那些文档上不会写的坑。适合准备从0到1搭建AI Agent的开发者、正在选型的企业技术负责人以及所有被“看似能聊、一测就翻车”的对话机器人折磨过的朋友。1. 为什么Agent需要一条“知识获取管道”1.1 LLM的天生短板与RAG的出现大语言模型本质上是一个“根据上文预测下文”的统计模型。它确实能把大量知识压缩进参数里但你得承认它有几个硬伤知识有截止日期训练语料里没有你们公司的内部流程遇到超出预训练分布的问题时会一本正经地编答案。这个“一本正经编答案”就是所谓的幻觉。很多团队在测试Agent时发现模型面对陌生问题常常给出逻辑完整但完全错误的结论不是因为模型不够聪明而是它没有获取外部知识的通道。RAG的思路其实特别朴素模型不知道那就让它去查。提问进来之后先从外部知识库中检索出相关的候选片段再把候选片段拼进Prompt让模型基于这些片段来回答。这个“先检索、后生成”的流程就是一条知识获取管道。它把模型从“必须什么都记得”解放成“知道去哪里找”也让每一次回答都有据可查。对于Agent来说这条管道是运行时唯一的“事实来源”也是目前低成本让Agent拥有领域知识的主流方式。1.2 从“靠参数背知识”到“按需查资料”打个比方。过去的对话机器人像是招了一个记忆力很好但只参加过入职培训的员工你问什么它都凭印象答答错了它自己也不知道。而RAG给你的Agent配置了一个档案室员工回答前先去档案室查资料查到什么就答什么查不到就老实说不知道。档案室里的资料你可以随时更新员工的知识立刻同步不需要重新培训也不需要换人。这就是RAG在工程上最大的价值——知识解耦。模型参数负责语言能力和推理能力外部索引负责具体事实和领域细节。你换一批文档Agent掌握的知识就跟着变你更新一篇公告检索结果立刻反映出来。相比之下靠微调更新知识不仅要花钱花时间还可能破坏模型原有的能力。你可以把RAG理解成给Agent外挂了一块可插拔的记忆硬盘而不是每次把“记忆”焊死在模型里重做。1.3 RAG在Agent里的角色以及Agentic RAG是什么在单轮问答里RAG是一次性的检索、注入、生成。但放在AI Agent的框架里这个流程不再是一条直线而是可以被反复调用的工具。Agent会规划任务、拆解步骤、决定什么时候需要查资料、查完资料做什么这时RAG就成了Agent众多工具中的一项能力。你给Agent接一个“知识检索工具”它自己判断该不该调用、要不要换关键词再查一次这就是Agentic RAG的雏形。Agentic RAG和普通RAG的区别在于控制权。普通RAG由用户问题直接触发一次检索结果固定Agentic RAG让Agent自主决定检索策略比如先查宽泛主题、再根据初步答案查具体细节或者检索多轮直到信息足够。走得再远一些还有GraphRAG、Ontology RAG这类把实体关系也纳入检索的变种。但不管名词怎么变底座还是那条管道文档入库、索引构建、召回、注入、生成。把这个底座打牢了后面所有高级玩法才有支撑。2. RAG完整链路拆解从文档到上下文2.1 数据准备加载、清洗、切分管道的第一站是让非结构化的文档变成可以检索的单元。现在的框架都提供了现成的加载器PDF、Word、Markdown、HTML、纯文本、数据库表都可以往里灌。但“能读”和“能读好”是两码事。PDF经常有表格和多栏排版直接抽出来文字顺序就乱了扫描件还得先做OCRHTML里的导航栏和页脚会混进正文。这些脏数据会直接污染后面的切分和向量化所以清洗是RAG里最脏最累、却最重要的一步。清洗完就要做切分chunking。切分的目的是把一个长文档切成若干小段每段作为独立的检索单元。常见的做法是按固定字符长度切比如512字符一段或者用递归切分器按段落、句子边界回退尽量保持语义完整。切太短上下文不够模型看不到完整逻辑切太长向量计算容易模糊检索精度下降还浪费Prompt容量。我自己的经验是先按结构切标题、段落、列表再设定chunk_size在300到800字符之间overlap设成10%到20%别让一句话被硬生生砍成两半。表格数据更要小心最好把表头信息拼到每个单元格片段上否则检索到“12345”你根本不知道它代表什么。2.2 Embedding与向量索引选型切分完的文本要变成向量才能和用户问题做相似度计算。这一步的核心是Embedding模型。中英文混合场景建议直接选对中文支持好的模型比如BGE系列或者多语言模型英文为主用OpenAI的text-embedding-3-small也够用。选模型时别只看榜单分数还要看维度、最大输入长度、推理成本。维度越高信息越丰富但存储和计算开销也更大最大输入长度如果小于你的chunk长度就需要先截断再做向量化。实际项目里Embedding模型往往比后面的LLM更能影响检索效果。向量存到哪里就是向量数据库的活。简单原型可以用FAISS它在本地跑、内存充裕、毫秒级返回要做生产级服务首选Qdrant、Milvus或pgvector。Qdrant对RAG场景支持友好Milvus适合海量数据和高并发pgvector则是Postgres用户的最省事方案——不用额外维护一套存储。你在热搜里看到的“本地知识库”“本地RAG”基本就是FAISS或Qdrant加本地Embedding模型跑起来的。索引类型方面HNSW是主流参数里的M和ef_construction影响召回速度和内存的平衡默认值通常够用不必一上来就调。2.3 检索向量检索、混合检索、重排向量检索的原理是计算用户问题和文档向量的余弦相似度或内积取Top K。它擅长解决“语义相近但字面不同”的问题比如搜“有没有退款政策”能匹配到“支持7天无理由退货”。但它也有弱点纯向量检索对专有名词、精确编号、少见缩写不敏感搜“API-2024-01”可能因为语义向量差得远而召回失败。这时候需要混合检索把传统的BM25关键词检索和向量检索结合起来各取所长。Elasticsearch里有标准的混合检索实现Qdrant从较新版本开始也原生支持稀疏向量和稠密向量的加权组合。检索完之后通常还要接一个重排Rerank环节。向量检索只负责“粗筛”Top K重排模型负责“精排”这几十条候选里哪条最相关。很多团队忽略这一步我建议至少在知识库超过一万条文档时把它加上。重排模型如BGE-Reranker会把用户问题和每个候选片段成对打分比向量相似度更准但速度慢所以只对粗筛结果跑。结构上就是先混合检索取回50到100条再用重排模型取前5到10条进Prompt。这个“粗召回精重排”的设计是提升RAG命中率最立竿见影的招数。2.4 注入把证据拼进Prompt检索回来的片段最终要进Prompt这一步看似简单坑其实不少。最基本的结构是System消息里写清楚规则“你是一个客服助手只根据提供的参考资料回答问题不要使用先验知识如果资料里没有相关内容就直接说不知道”用户消息里把问题写在最后把检索到的文档片段按顺序放在问题前面。这里有一个容易被忽略的细节片段之间要有清晰的分隔标记并给每个片段编号比如“文档1、文档2”这样模型在回答时可以明确说“根据文档3的信息”。你还可以要求模型在回答末尾附上参考来源。注入时还要注意“上下文污染”问题。如果检索结果里混入大量无关片段模型会被带偏所以宁可只保留高置信度的3到5条也不要贪多。Prompt里检索内容的格式也会影响生成质量我习惯用XML标签把证据包起来让模型明确知道哪些是引用材料、哪些是待回答的问题。另一方面对话类Agent要注意历史消息的裁剪把之前几轮问答放进去即可别把整段历史都塞进上下文否则检索片段很容易被历史噪声淹没影响回答准确度。3. 真实项目实操搭一个最小可用的知识问答Agent3.1 技术栈选型理论讲了这么多咱们直接动手。我用Python来搭一个能跑在本地的最小RAG Agent技术栈选得尽量轻LangChain做流程编排FAISS做向量存储HuggingFace上用BGE-M3做Embedding如果网络受限或者不想拉大模型也可以换成OpenAI的Embedding接口生成部分用一个在线的大模型API或者本地基于Ollama跑Qwen等开源模型。这里选LangChain不是因为它是性能最优解而是它把加载、切分、检索、Prompt拼装都抽象好了适合快速验证链路。等你确认了整体可行再替换掉其中的组件也不迟。需要说明真实项目里LangChain并非必需品。你完全可以直接调用Embedding模型API、自己写切分逻辑、自己算向量距离、自己拼Prompt。我见过不少生产系统就是完全手写的。但作为一篇偏入门的文章用LangChain能帮助你少写一堆胶水代码把注意力集中在理解RAG本身。下面这份代码我用的是最直白的方式故意不叠加太多框架魔法。3.2 完整代码流程文档入库和查询先安装依赖langchain、langchain-community、faiss-cpu、bge-m3这里用sentence-transformers加载。入库流程分四步读文档、切块、向量化、存入FAISS。查询流程分三步向量检索、重排可选、拼Prompt送LLM。为了控制篇幅我用一个简单的文本文件作为示例生产环境换成你自己的文档加载器就行。from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS # 1. 加载文档 loader TextLoader(./knowledge_base.txt, encodingutf-8) documents loader.load() # 2. 切分 splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap64, separators[\n\n, \n, 。, , ], ) chunks splitter.split_documents(documents) print(f切分得到 {len(chunks)} 个片段) # 3. Embedding 向量化入库 embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-m3, encode_kwargs{normalize_embeddings: True}, ) vectorstore FAISS.from_documents(chunks, embeddings) # 4. 保存和加载索引生产环境建议持久化 vectorstore.save_local(./faiss_index) # vectorstore FAISS.load_local(./faiss_index, embeddings, allow_dangerous_deserializationTrue)查询侧代码同样不复杂。先从向量库按相似度检索前20条候选然后交给重排模型精排最后拼Prompt给LLM。这里我用了FlagEmbedding的Reranker做示范如果你不想引入额外模型也可以跳过重排直接取Top 5。from flagembedding import FlagReranker # 从向量库检索候选 query 你们的退款政策是什么 docs vectorstore.similarity_search_with_score(query, k20) # 重排精排 reranker FlagReranker(BAAI/bge-reranker-v2-m3) pairs [(query, doc.page_content) for doc, _score in docs] scores reranker.compute_score(pairs) ranked sorted(zip(docs, scores), keylambda x: x[1], reverseTrue) # 取前5条拼进Prompt context \n\n.join( f[文档{i1}] {doc.page_content} for i, (doc, _s) in enumerate(ranked[:5]) ) prompt f请根据以下参考资料回答问题。 参考资料 {context} 问题{query} 要求 - 只能依据参考资料回答 - 如果资料中没有相关内容直接回答“资料中未找到相关信息” - 回答后附上引用的文档编号把prompt发给大模型就完成了一次RAG问答。第一次跑通后你会发现代码本身平平无奇真正的难点全在数据切分、检索质量这些看不见的地方。3.3 交互闭环结果与溯源最小管道跑通后我更推荐你先别急着加花活把“溯源”功能加上。所谓溯源就是在Answer旁边返回命中的文档片段来源比如文件名、章节标题、原始段落。这不仅是用户体验问题更是RAG调试的基础设施一旦回答错了你能立刻看到模型是基于哪一段证据编的问题到底出在检索漏了、切分错了还是Prompt规则没立好。实现上无非是把检索到的metadata一并放进返回结构里前端展示一个“参考来源”折叠框。如果做的是对话式Agent还要处理历史消息。最简单的做法是维护一个消息列表每次提问前把最近两三轮历史拼进Prompt然后调用一次RAG。注意历史消息里的用户旧问题不应该触发检索、也不应该拼进当轮的检索要求。把历史输入单独放在对话历史区块检索只针对“当前这一问”效果最干净。这块处理不好很快会出现“带着上一轮的问题检索出奇怪内容”的毛病。我早期踩过这个坑后来定了条规矩检索表达式永远只基于本轮用户问题历史仅作为LLM生成时的参考背景。4. 让RAG在Agent里更好用的几个关键经验4.1 检索质量的度量不只是“感觉”RAG上线前一定要评估不然你会被“偶尔答得好”骗过去。最基础的两个指标Hit Rate命中率和MRR平均倒数排名。Hit Rate衡量的是对于测试集里的每个问题正确答案的片段是否出现在检索返回的前K条里。MRR更进一步看正确答案排在第几位排第一得1分排第五得0.2分。这两个指标只评估检索环节不关心生成结果用来快速验证索引和切分策略是否合理。更完整的评估还要看生成答案本身。你可以小规模人工评分也可以拿GPT/其他强模型当裁判对比标准答案和RAG生成答案的相关性、忠实度、完整性。注意忠实度在RAG场景里比准确率更关键——就算事实没错模型如果脱离了检索片段自由发挥也是失败的。我的习惯是把检索评估和生成评估分开跑先调检索Hit Rate低于80%就别急着优化Prompt检索稳定了再看生成这时的问题往往出在Prompt规则或上下文结构上。4.2 切分策略和元数据RAG的两大隐形变量很多团队把时间花在调模型上实际上切分策略才是RAG效果的最大变量。我做过一个对比同样一份产品手册固定512字符切分的Hit Rate只有42%改成按章节和语义段落切分后直接涨到71%。原因是固定切分把很多表格、列表拦腰截断导致检索到的片段信息残缺。后来我根据文档类型分了三套切分方案规范制度类按标题层级切FAQ类一条一问答一个片段产品参数类把表格转为“键值对描述”再切。切分是一个反复试错的过程没有万能参数。元数据也一样重要。给每个片段打上文档名、章节、页码、更新时间、业务线标签这些信息至少有三个用途一是作为过滤条件比如“只检索2024年之后的制度”在查询时用filter把范围收窄比单纯靠向量相似度精准得多二是作为Prompt里的来源信息增强回答的可信度三是做权限控制不同角色的用户只能检索到对应标签的文档。很多RAG项目上线后被人诟病“老资料和公告混在一起、答非所问”根子就在元数据设计缺失上。4.3 多路检索、GraphRAG与Ontology RAG的边界当知识库结构复杂到一定程度单库单路的RAG就不够用了。实际Agent里我常常按业务域拆多个索引库制度库、产品库、工单库各一个Agent工具由Agent在规划时选择调哪个。这就是你听到的“RAG as a Tool”“skill和RAG结合”的现实场景。多路检索的好处是隔离噪音、能按场景做不同的切分和Embedding配置坏处是增加了编排复杂度需要Agent具备准确的“路由选库”能力。GraphRAG和Ontology RAG是这两年讨论很多的方向。它们的共同点是在纯文本片段之外把实体和关系也建进索引里。GraphRAG用知识图谱表达实体之间的连接擅长回答“A和B之间有什么关联”这类多跳问题Ontology RAG更进一步依赖本体定义概念间的语义关系。这些方案确实能解决纯向量RAG在关系推理上的短板但代价是构建和运维成本高。我的态度是知识库文档数量在几千篇以内先老老实实把混合检索重排调好等开始频繁遇到“跨文档多跳问题”或“同义词实体合并问题”再考虑引入图谱不要为了概念热度给自己上重量。有意思的是你看到的“ontology rag”“llm wiki 本体rag”热搜本质也是在聊同一种能力——只是大家都在找最适合自己的落地方式。4.4 常见问题排查速查表下面这张表是我在实际项目中反复踩过的坑按症状、可能原因、排查顺序整理出来你可以直接拿去当排查手册用。症状可能原因排查和解决思路回答明显错误但检索片段看起来有相关切分破坏了关键信息打印命中的chunk原文看语义是否完整尝试调小或调大chunk_size检索结果和问题毫无关联Embedding模型和文档语言/领域不匹配换中文/领域专项Embedding模型检查是否要做基础预处理如去HTML标签真正常用的知识永远排在后面检索返回了太多相似片段正确答案被埋没增加重排环节提高Top K再精排调整向量检索的相似度阈值模型完全不按资料回答、自己乱编Prompt规则没约束住在System消息中强调只能使用资料禁用先验知识必要时用few-shot示范更新了文档回答还是旧内容索引没同步或缓存检查入库流程是否增量更新向量库中是否存在旧chunk残留清理缓存多个知识库时总选错库Agent路由策略太简单给每个工具写清晰的功能描述先让Agent基于用户问题做意图分类再到库对话越聊越乱后几轮回答质量下降历史消息混入了检索上下文隔离历史消息和检索证据限制历史轮数检索只基于当轮问题除了表格里的问题还有两个容易被忽略的运维要点一是定期评估索引版本的回归情况不要把更新EST的知识库直接上线而不跑一遍测试集二是密切关注Token成本和延迟RAG链路长了之后检索重排Prompt可能让单次请求从几百毫秒变成几秒需要结合业务场景决定是否用缓存、是否降级为纯向量检索。5. 写在最后把RAG当成Agent的“外挂记忆”回到开头那句话RAG的本质是Agent的知识获取管道但它不是接入一个数据库那么简单。它是一整套数据处理流程是检索策略和Prompt工程的结合体也是Agent能否稳定输出事实性回答的关键底座。我见过不少团队痴迷于最新的Agent框架、花哨的工具编排结果地基没打牢上线后用户问第一个业务问题就答非所问。与其这样不如把时间花在清洗文档、设计切分、建立评估集这三件事上。我个人在后来的项目里体会到一件事RAG的调试过程极其细致但每一次优化都是有迹可循的。你改了切分策略Hit Rate会告诉你有没有进步你加了重排答案的忠实度肉眼可见提升你完善了元数据用户反馈立刻改善。这种“能感知到改善”的反馈正反馈是其他模型优化手段很少给到的。最后再分享一个小技巧如果团队还在纠结要不要上GraphRAG或重排模型先挑几十条真实用户问题把你的RAG系统跑一遍把失败case按“检索失败”和“生成失败”分类。哪个环节占比高就优化哪个环节。技术的取舍永远服务于管道本身的质量而不是热搜上的名词。这一篇把RAG的地基讲清楚了。下一篇我会沿着知识获取管道继续往上搭聊聊多路检索怎么跟Agent工具编排结合以及如何让Agent学会自己判断“该不该查、查到了没有”这里回归到真正的Agentic RAG实战。你自己动手搭过一遍之后再看那些概念会轻松很多。祝跑通。