这是“走进 AI Agent”系列第四篇。前几篇我们把一个 Agent 的主干搭扎实了——意图识别、任务规划、工具调用都跑通了模型能根据用户的指令自己决定下一步该做什么。但真把 Agent 放到业务场景里不管是写行业报告、答客户咨询还是做企业内部的制度问答、产品知识服务大家很快就会撞上同一个问题模型脑子里那点知识不够用。这个问题的解决方案就是这一篇要聊的主题——知识获取管道而其中最基础、也最常用的实现就是 RAG。我自己把知识获取管道拆成三件事拿什么知识、怎么拿、怎么让模型拿得准。RAG 解决的就是后两件事。它会先把外部文档处理好存进向量库用户提问时先检索相关片段再把检索结果和问题一起交给大模型生成答案。这个模式很像我们考开卷试——先翻书再作答而不是闭卷硬憋。这篇文章适合正在从 0 到 1 搭建 AI Agent、想给自己的 Agent 接上私有知识库、或者看过 RAG 教程但没真正跑通一个最小项目的开发者。1. Agent 为什么需要一条“知识获取管道”1.1 一次失败的问答暴露出的核心短板我在本地跑通第一个 Agent 原型的时候做了一个很基础的测试问它“我们团队 2024 年的年度总结文档里提到的三个核心指标是什么”。结果让我印象很深——模型非常流畅地编出了一套看起来完全合理的答案指标名称、数值、趋势描述一应俱全但文档里根本没有那些内容。这不是模型“笨”而是它的知识来源决定的。预训练语言模型的知识来自训练数据有严格的截止日期也不可能覆盖你们团队的内部文档、你公司刚发的制度文件、或者某个产品的私有规格说明。第二个问题是就算把文档塞进上下文模型处理超长文本时也会出现“中间迷失”——几千 token 以后的信息它经常抓不住重点。这里还得区分一个容易混淆的概念记忆和知识获取不是一回事。记忆解决的是“同一段对话里前面说过的话后面还记得”它面向的是会话上下文。知识获取管道解决的是“模型本来不知道、但回答这个问题又必须知道的内容”它面向的是外部语料。两者可以配合用但记忆不能替代 RAG。这也是我后来在实际项目里反复被教训的一点。1.2 RAG 不是“查数据库”而是“开卷考试”我习惯用“开卷考试”来跟第一次接触 RAG 的同事解释这个机制。闭卷状态下模型靠的是肚子里那点“预训练存货”碰到没见过的问题就只能编。RAG 做的事情是考试时给你一本可以翻的参考书——先通过检索把和问题最相关的几段内容捞出来再让模型只基于这些内容作答。但这个“翻书”的动作没那么简单。直接全文检索文档字面关键字很多语义相近的问题会漏掉。比如用户问“公司今年经费紧张吗”文档里写的是“预算缩减 30%”字面上没有“紧张”两个字传统关键字检索就匹配不上。RAG 的做法是把文档和问题都转换成向量用数学上的相似度来匹配语义这样“经费紧张”和“预算缩减”在向量空间里距离足够近就能被正确召回。所以完整地说RAG 是在用户的提问和外部文档之间搭一座语义桥梁。它在 Agent 里的位置也不是一个独立战略模块而更像Agent管道的“输入处理器”——用户在发起任务前先把必要的知识检索出来作为后续规划和回答的事实基础。理解这一点再往下看三阶段流程就会清楚很多。2. RAG 三阶段全流程拆解索引、检索、生成2.1 索引阶段把“整本书”拆成“知识卡片”索引阶段的目标是把一堆杂乱的原始文档变成可快速检索的结构化知识。前提是先把内容拆碎再逐个向量化入库。这一步做好了后面检索质量至少不会太差做不好后面花再多时间调参也没用因为“源头”就是脏的。整个过程可以想象成给一本书做索引卡片你不会把整本书作为一个条目塞进卡片目录那太大了检索的时候既慢又不准。正确做法是把书按章节、段落拆成若干小块每一块单独做成一张卡片卡片上除了原文内容还要有一个能代表它语义的“特征码”——也就是向量。具体实现里我最常用的是RecursiveCharacterTextSplitter它会按固定长度切文档同时尽量保留语义边界。切分粒度需要手调我用过的合理区间是 300 到 800 个 token 一段。切完以后把每一段文本交给 Embedding 模型转成一个固定维度的浮点数数组这就是“向量”。最后把向量和原文一起写进向量数据库索引阶段就完成了。2.2 检索阶段相似度计算与召回策略检索阶段解决的核心问题是把用户的问题也转换成向量然后在向量库里找出“语义上最接近”的那几段文档。向量库本质上是一棵高性能的搜索树或者更准确地说是一个支持近似最近邻搜索的存储引擎。常见的实现有 Chroma、FAISS、Milvus、Qdrant 等。个人做原型、本地测试用 Chroma 最顺手生产环境数据量大、并发高Milvus 或 Qdrant 更稳。选型逻辑很简单先用最轻量的把流程跑通再按瓶颈换方案。召回时有两个核心参数必须搞清楚。第一个是top_k意思是取最相似的几个片段回来第二个是相似度阈值低于阈值的片段即使排在前几也直接丢弃。这两个参数直接影响答案质量top_k太小相关信息可能漏掉top_k太大不相关内容会干扰模型判断还浪费 token。这里还要补充一个经验向量检索不等于全文检索的替代品。很多项目用的是混合检索向量抓语义BM25 抓关键词两者结果做加权融合能显著提升实体名、编号、专有名词的命中率。我的建议是第一版先只做向量检索跑通流程等出现“明明有这个文档但搜不到”的情况再上混合检索。2.3 生成阶段Prompt 组装与引用约束检索出来的片段不会直接丢给用户看它们要作为“参考资料”和一个精心设计的 Prompt 拼在一起再交给大模型生成答案。生成阶段最容易被忽视的是 Prompt 的质量。我的标准做法是在 Prompt 里明确告诉模型两种情况。第一种检索内容里有足够信息就直接基于内容回答不要额外发挥第二种检索内容没有覆盖用户的问题要明确说“资料中没有相关信息”而不是强行给出一个可能出错的答案。这个约束能从根上压住一大半的幻觉问题。还有一个细节叫引用溯源。让模型在回答后附上信息片段的来源编号比如“根据资料[1][2]”这样用户能自己去核验。实现上不复杂只要在组装 Prompt 时给每个片段带上序号要求模型回答时标注序号即可。这一招对提升用户信任感特别有效尤其是知识管理、法律、医疗这类对准确性要求高的场景。三个阶段的输入输出我用一张表整理一下阶段输入核心动作输出索引原始文档切分、向量化、入库向量库中的文档片段检索用户问题向量化、相似度搜索top_k 个相关片段生成问题 片段 Prompt大模型基于资料作答带引用的最终回答3. 实操五分钟搭一条最小可用的 RAG 管道3.1 环境准备与最小代码骨架我一直觉得RAG 这个概念听起来很玄但最小实现其实非常短。这里给你一份我最近在本地跑过的最小骨架用 Python LangChain 实现。先装依赖pip install langchain langchain-community langchain-text-splitters langchain-chroma chromadb pip install langchain-ollama sentence-transformers我这边用的是本地模型不需要申请 API key方便复现。Embedding 用国产开源模型BAAI/bge-small-zh-v1.5对中文支持相当好体积小普通 CPU 也能跑生成模型用 Ollama 里的qwen2.5:7b本地跑完全够用。准备一个测试目录./docs里面放几个 txt 或 md 文件比如你们的项目文档、会议纪要。然后跑这段代码from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma from langchain_ollama import OllamaLLM from langchain.chains.retrieval_qa.base import RetrievalQA # 1. 加载文档 loader DirectoryLoader(./docs, loader_clsTextLoader) docs loader.load() # 2. 切分文档 splitter RecursiveCharacterTextSplitter( chunk_size500, # 每段 500 token 左右 chunk_overlap50, # 段之间重叠 50 token防止切断语义 ) chunks splitter.split_documents(docs) # 3. 向量化入库 embedding HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectordb Chroma.from_documents( chunks, embedding, persist_directory./chroma_db, # 持久化路径 ) # 4. 构建检索问答链 qa RetrievalQA.from_chain_type( llmOllamaLLM(modelqwen2.5:7b), retrievervectordb.as_retriever(search_kwargs{k: 3}), return_source_documentsTrue, ) # 5. 提问 result qa.invoke(根据资料我们 2024 年的三个核心指标是什么) print(result[result])这段代码最简化地串联了索引、检索、生成三步。第一次运行会把文档向量化存入./chroma_db后续再跑会直接读库不会重复建索引。注意如果你是第一次用HuggingFaceEmbeddings模型会从网上下载到本地缓存目录需要能联网。下载完成之后之后离线也能跑。生成模型qwen2.5:7b需要提前用ollama pull qwen2.5:7b拉取。3.2 影响检索效果的三个关键参数跑通之后你的直接感受可能是“为什么回答质量忽高忽低”。这时候该调参数了。我从实际测试里总结出三个最值得优先调整的点。第一个是chunk_size。切太细比如 200 token语义容易不完整一个结论被拦腰切断切太粗比如 1500 token单个片段里塞了太多主题检索时“踩中了凑合、踩不中拉倒”的偏差很大。我自己的经验是中文场景从 500 起步根据文档类型微调规范制度类可以适当放大到 800问答类、对话类文档建议压到 300 左右。第二个是top_k。在知识问答场景里我建议先设 3 到 5。top_k设得太大比如 10模型会被不相关内容干扰回答开始“东拉西扯”设得太小又容易出现信息缺失。检索质量不稳定时你可以在代码里把retriever单独拿出来打印召回结果看看真正相关的文档片段有没有出现在前几名里。第三个是 Embedding 模型本身。这个最容易被忽略但影响是全局性的。通用场景用bge-small-zh-v1.5足够如果你的文档非常垂直比如医疗、法律、代码仓库建议对比几个模型的表现别只看网上跑分。这块没什么捷径多测几组真实问题肉眼判断召回的语义相关度。3.3 把 RAG 作为 Agent 的一个工具接入最小管道跑通以后下一步就是把 RAG 接进 Agent 的流程里。我的做法是把整个 RAG 问答链封装成 Agent 的一个”工具”Agent 规划任务时判断“这个问题需要查资料”就调用这个工具。这样做的好处是Agent 的主链路不用做大改动原有的意图识别、任务规划、工具调用逻辑全部保留只是多挂了一个新工具。用户说“查一下我们团队的季度报告里关于进度的部分”Agent 把它拆成两步——先调用 RAG 工具检索相关内容再把结果作为上下文生成回答。伪代码思路def rag_tool(query: str) - str: result qa.invoke({query: query}) return result[result] # 注册进 Agent 的工具列表 tools [ Tool(namerag_query, funcrag_tool, description查询本地知识库中的文档内容), # 其他工具... ]有一定基础的朋友可以去看 LangChain 官方文档里的create_react_agent和Tool注册方式如果用的是 Spring AI 生态langchain4j也提供了完整的 RAG 集成——EmbeddingStoreRetriever配合ContentRetriever注册到 AgentService 即可。这就是热词里spring ai rag、langchain4j rag相关的典型用法。需要特别提醒的是RAG 作为工具接入 Agent 后要设计好“检索不到怎么办”的兜底逻辑。我见过不少项目Agent 调用 RAG 工具没搜到有效内容但 Agent 为了完成任务仍然硬着头皮编了一个答案。这比不接 RAG 还危险。我在 Agent 的 system prompt 里明确写了检索结果不足以回答问题时必须直接回复“知识库中没有相关信息”并且终止当前工具链。4. 接入 Agent 之后的调参与排坑实录4.1 检索质量差先查数据再查代码这是最常遇到的问题现象是模型回答“牛头不对马嘴”。很多人第一反应是换大模型但我觉得要先花 10 分钟做一个“检索体检”把 RAG 链路中的检索结果单独打印出来不经过生成阶段自己先看看召回的内容到底相不相关。体检结果通常有三种情况。第一种召回的内容乱七八糟跟问题毫无关系——多半是 Embedding 模型和领域不匹配或者文档切分粒度不合理。第二种召回的内容相关但信息不完整比如问题要 A 和 B 两个指标只召回了一段只讲 A 的内容——调整chunk_size和top_k能解决。第三种召回内容没问题但模型回答还是没用好——这是 Prompt 约束问题不是检索问题。我踩过最隐蔽的一个坑是文件加载环节静默出错。之前有一个项目DirectoryLoader默认只解析txt和md我放了一批 docx 进去文档其实压根没被加载索引库是空的检索当然什么也搜不到。查了半天最后用len(docs)输出数量才发现。遇到检索异常第一件事永远是确认数据真的进库了。4.2 幻觉问题怎么让模型老老实实引用资料很多人以为做完 RAG 就不会有幻觉了这是误解。RAG 能显著降低幻觉但不能完全消除。模型生成时仍然可能“脑补”资料里没有的细节尤其是当检索到的片段里恰好有一句相关的话但不够完整时模型会自己补全后半段。我的处理方式分三层。第一层Prompt 强约束要求回答必须基于给定资料资料中没有的信息一律不答。第二层引用溯源给每个检索片段编号要求回答后标注 [1]、[2]凡是没有编号支撑的内容视为无效。第三层生成后校验用简单的规则脚本检测回答中是否包含资料中不存在的数值、日期、人名一旦发现就触发“重新生成一次”的流程。对于高敏场景我还会加一层“不答策略”。比如用户问的问题超出资料范围但模型觉得“凭常识也能回答”这时宁可让它说“知识库中没有相关信息”也不要让它用常识兜底。你可能会觉得这样会让 Agent 显得“不够聪明”但用户真正想要的是准确不是一本正经地胡说。4.3 响应慢与成本高缓存、压缩与混合检索把 RAG 接入 Agent 后另一个体验上的问题是响应变慢。原因很直接Agent 本身有规划成本RAG 又要先检索再生成链路变长了一倍。实测下来本地 7B 模型单次回答总耗时在 8 到 15 秒之间这在很多对话场景里已经超出用户的等待耐心。我做的第一件事是加缓存。相同或高度相似的问题直接复用之前的检索结果不走 Embedding 不走模型。实现上可以用简单的dict存 query 的向量哈希或者接 Redis。实测对高频重复问题能节省 60% 以上的资源。第二件事是控制上下文长度。很多 RAG 框架默认把top_k个完整片段全部拼进 Prompt一个片段 800 token5 个就是 4000 token开销非常大。我的做法是先召回 8 到 10 个片段用一个重排序模型比如bge-reranker-base重新排序只保留最相关的 3 个进入生成阶段。这能显著降低每次请求的 token 消耗生成速度也更快。第三件事是混合检索。前面提过向量检索擅长语义匹配BM25 擅长精确关键词匹配。两者融合后实体名、编号、型号这类信息命中率大幅提升也能减少“该搜到但没搜到”而去反复重试的情况。经验总结RAG 的性能优化要按“缓存 压缩 换模型”的顺序来。先让系统少干活再让单个活干得快最后才考虑上更大的模型。一上来就上大模型只会让速度和成本同时失控。5. 从基础 RAG 到 Agentic RAG后续还能怎么走前面聊的都是静态 RAG——用户问一句检索一次生成一次。实际业务中很多问题需要多步推理用户问“对比 A 产品和 B 产品的售后政策”单一检索要么只找到 A 的文档要么只找到 B 的简单合并又不够深入。这就是 Agentic RAG 要解决的方向——把检索动作内嵌到 Agent 的推理循环里允许模型根据初步结果决定要不要二次检索、要不要查更细的文档。这个方向最近特别热热词里也有不少相关信息。graph rag和ontology rag是另一条线它们解决的是“文档之间的关系”问题。传统 RAG 把每段文本当成独立个体检索时只能按语义找片段Graph RAG 会把文档里的实体、关系构建成图检索时既能找到片段也能顺着关系找到上下游知识。这在企业制度、产品体系这类强关联的知识场景里效果提升非常明显。我给想继续深入的朋友一个建议不要把 Agentic RAG 想得太复杂它其实就是把这一篇里讲的“RAG 作为工具”再往前推一步——RAG 工具具备自我评价、二次检索、汇总融合的能力。你先要把基础 RAG 的每一个参数、每一个坑都摸清楚再去碰这些进阶方案。地基不稳往上加的每一层都会变成新的计数器。从最早跑通那个“一本正经编答案”的 Agent到现在能在私有知识库上稳定回答我最大的体会是RAG 不是一次性工程而是一条需要持续维护的管道。前期把文档切分、检索参数、Prompt 约束这几件事做扎实Agent 会越用越顺前期偷懒所有隐患都会在 Agent 的输出里以“幻觉”的形式加倍还回来。所以我的建议始终是——第一版宁可拆得简单、控制得严格也别把链路做得花里胡哨自己都说不清楚。跑通之后你自然会知道下一个参数该往哪个方向调。
