作为一个从 NER 项目一路折腾到多智能体系统的工程师，我越来越觉得，AI Agent 真正拉开差距的地方，往往不在模型选得多大、Prompt 写得有多花哨，而在它能不能在需要的时候，把对的知识抓到手里。这也是我写“走进 AI Agent”这个系列的核心视角。第四篇，我想把 Agent 的知识获取管道单独拎出来聊透——也就是 RAG（Retrieval-Augmented Generation，检索增强生成）基础。这篇不讲花活，就讲清楚：AI Agent 的知识从哪来、怎么存、怎么取、怎么用，以及你在实践中最容易踩的坑。

这篇文章适合所有正在从 0 到 1 搭建 AI Agent、或者被“知识库问答”折磨过的开发者。我会先拆解 RAG 作为 Agent 知识管道的整体设计思路，再带着你过一遍索引、检索、生成三个核心阶段，然后给出一套最小可用的代码实现，最后把我在工程化过程中踩过的坑、调过的参、排过的错，原原本本分享出来。看完你至少能明白：什么样的场景该上 RAG、上完之后怎么调优、Agent 接入 RAG 时有哪些隐藏的雷区。

1. 为什么 Agent 离不开知识获取管道：RAG 解决的本质问题

1.1 幻觉与知识边界：Agent 的“记忆盲区”

先说个扎心的事实：你买再大的上下文窗口，模型也装不下一个真实业务系统的全部知识。拿我自己做过的制造企业项目举例，产品目录、图纸说明、质检标准、ERP 里的库存状态、售后工单，数据量是 TB 级的。你不可能把这些全塞进 Prompt，就算塞得进去，模型也不会真的“记住”每条细节，它只是在做预测。

这就是大模型的天生短板：知识有截止日期，且不可溯源。模型训练完成的那一刻，它的知识就冻结了。你问它今年新发布的产品参数，它大概率睁眼说瞎话，因为训练集里根本没有。更麻烦的是，模型还会一本正经地编造——这就是幻觉。很多刚做 Agent 的朋友，第一反应是堆 Prompt，比如加一句“如果你不知道就说不知道”。实测下来，作用有限。因为模型不是不想诚实，它是真的“不知道自己在不知道什么”。

RAG 解决的就是这个“记忆盲区”。它把外部知识切成小块、向量化、存进向量库，等到用户提问时，先从库里把最相关的小块捞出来，塞进上下文，让模型基于这些内容作答。这样做有三个直接好处：知识可以随时更新（换文档就行，不用重训模型）、回答有出处（能定位到具体段落）、幻觉大幅下降（模型只能基于检索到的内容说话）。

1.2 RAG 还是微调：一张表帮你做决策

很多人一上来就问：我该做 RAG 还是微调（Fine-tuning）？我的建议是：别二选一，先分清你缺的是“知识”还是“能力”。

微调改变的是模型本身的权重，本质是在教模型一种行为模式、一种风格、一种输出格式。比如你想让模型固定输出 JSON 结构、学会公司特定的术语缩写，或者把你家客服的说话腔调刻进骨子里，那是微调的活。但微调解决不了“知识随时变化”的问题——每次文档更新都要重新训练，成本高，周期长，而且模型照样可能胡说。

RAG 解决的是“知识”问题。它把外部知识作为即插即用的模块挂载到模型旁边。企业知识库里季度更新产品线？直接替换索引文档就行。要让模型回答时引用某个标准条款？检索到对应章节就行。这才是大多数业务场景的首选。

我把两者的适用场景整理成了一张对比表，方便你决策：

我见过最理想的方案其实是 RAG + 微调配合着用：用微调让模型学会“严谨、分点、引用来源”的输出习惯，用 RAG 负责具体知识供给。但如果你是从零起步，资源有限，请务先把 RAG 跑通，它性价比高得多。我自己的项目基本都是这个路径。

2. RAG 核心流程拆解：从文档到上下文的三段式管道

RAG 整个链路拆开来看，就是一条清晰的三段式管道：索引入库 → 检索召回 → 生成回答。这三段每一段都有讲究，我逐个说。

2.1 索引阶段：加载、切分、嵌入、入库

索引是 RAG 的地基，也是最容易被忽视的环节。很多人的 RAG“检索不准”、回答质量差，根子就出在这。索引阶段有四个步骤：

第一步是文档加载。PDF、Word、Markdown、HTML、数据库里的字段，不同来源要选不同的 Loader。这里有个大坑：PDF 看着是文字，实际可能是扫描图片，直接加载出来全是乱码。我一般先用 OCR 工具把扫描件转成文本，再进管道。这不是 RAG 的问题，是数据工程的老问题——数据质量决定检索质量。

第二步是文本切分。这是 RAG 里最“玄学”的一环。切大了，一个 chunk 塞进太多主题，检索时上下文噪声大；切小了，语义不完整，明明讲同一件事却断成两截。我的经验是：没有万能参数，只有适合你文档的参数。通用起步配置是 chunk_size=500 个 token、overlap=50 个 token，但代码文档、技术规范这类结构化内容往往需要按章节、按条款边界切，而不是死板地按字树。你甚至可以自己写规则：先用标题结构定位边界，再在边界内控制长度。

第三步是嵌入计算。把文本片段映射成高维向量，让语义相近的文本在向量空间里距离更近。这里需要选一个 Embedding 模型。对于中文场景，我之前长期用bge-m3和text-embedding-v4，效果都稳；英文场景用text-embedding-3-small比较多。选择标准非常简单粗暴：先在你自己业务数据的少量样本上测一下检索命中率，别只看模型排行榜的分数。

第四步是向量入库。把向量和原文、元数据（文件名、章节、页号、更新时间）一起写进向量数据库。自用小项目用 Chroma 或者 FAISS 完全够；团队协作、数据量大、要求高可用，则要考虑 Milvus、Qdrant 这类专门的服务。如果你们公司已经用了 PostgreSQL，直接上 pgvector 也很省事——少维护一个中间件。

2.2 检索阶段：向量相似度、混合检索、重排序

检索阶段是把“用户问题”转换成“相关文档片段”的关键一环。最朴素的实现是：把问题也嵌入成向量，然后在向量库里做相似度搜索，取 top_k 个最相似的 chunk。这条路线有效，但不足够好。

问题在于：向量相似度对词面重叠敏感，对语义迁移没那么敏感。用户问“怎么发货慢”，你的知识库里写的是“物流时效异常处理流程”，词面完全不搭，但语义相关。这时候纯靠向量检索，大概率召回失败。所以业界的常见做法是混合检索：向量检索 + 关键词检索（BM25）并行跑，再把两路结果做加权融合。我实测下来，混合检索对问答场景的命中率提升非常显著，值得一开始就做成标配。

还有一个容易被忽略的步骤：重排序（Rerank）。向量召回阶段为了速度，用的是轻量级相似度计算，召回 TOP 50 或 TOP 100；但到了生成阶段，上下文有限，就必须从这 50 个里精中选精。重排序模型会逐个计算候选文本与问题的真实相关性，把最相关的 3~5 个排到最前面。我在项目里用bge-reranker系列模型做本地排序，效果比“直接取相似度最高的 top_k”稳得多。

2.3 生成阶段：Prompt 组装与上下文窗口

检索做完，拼装 Prompt 也是一门手艺。许多人直接把所有检索结果一股脑塞进 Prompt，结果模型被一堆无关内容带偏。我的做法是：在组装 Prompt 时做三层控制——筛选、排序、裁剪。

筛选：只保留重排序后质量最高的前 3~5 个 chunk。不要贪多，检索结果质量不高时，加再多也只是噪音。排序：把最相关的放在最前面，模型对早期内容的注意力通常更强。裁剪：限制每个 chunk 的 token 数，有些长 chunk 中间有冗余段落，可以只取与查询最相关的那一小段。

Prompt 的结构我通常长这样：先声明系统指令，要求在回答时只基于给定上下文、不要编造；再把检索到的内容按“文档名 + 原文片段”的格式列出来；最后放用户问题。同时一定要标注哪些内容找不到依据，模型就明说“未找到相关信息”，不要让模型脑补。这套写法能在不换模型的前提下，显著提升回答质量。

3. 实操：搭建一个最小可用的 RAG，并把它挂进 Agent

3.1 技术选型：LangChain vs Spring AI vs 直接手写

很多朋友老纠结框架选型。我先说结论：RAG 的复杂度根本不在框架，而在数据质量和检索策略。框架只是帮你省掉模板代码的脚手架。

如果你在 Python 生态，LangChain 是目前生态最全的，Loader、Splitter、Embedding、VectorStore 都封装好了，适合快速验证。但它太重量级，版本 API 变动频繁，之前我项目里升级 LangChain 版本差点把索引管道改吐了。如果你图稳，字写太抽象的话，可以直接用官方 SDK 组合，代码量不大，逻辑还全在你掌控之中。

如果你在 Java 生态，Spring AI 和 LangChain4j 都值得关注。特别是企业里已经有 Spring Cloud 这套基础设施的，用 Spring AI 把 RAG 能力包成服务，和现有业务系统打通非常顺。热词里看到的“Spring AI RAG”“LangChain4j RAG”，都是这个路子。至于 Semantic Kernel，是微软那套，如果你团队主打 .NET，也可以试试，但认知度还不如前两者。

我自己现在是这么分工的：项目初期用 LangChain 快速跑通；一旦逻辑验证完毕，进入正式开发，核心管道要么自己封装，要么固定在某个稳定版本上取必要模块。这比整天跟着框架改 API 舒服得多。

3.2 最小实现：文档入库与检索代码（Python 示例）

下面给你一套可以直接本地跑的最小 Python 实现。我以 OpenAI Embedding API 和 FAISS 为例，主要是为了方便演示；生产环境你把模型和向量库换成你自己的基础设施即可。

先安装依赖：

pip install langchain-core langchain-text-splitters langchain-community faiss-cpu openai

然后看索引入库的代码：

import os from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.vectorstores import FAISS from langchain_openai import OpenAIEmbeddings os.environ["OPENAI_API_KEY"] = "your-api-key" # 1. 准备知识文本，实际项目里从 Loader 读取 docs = [ "物流时效异常处理流程：当订单超过承诺时效未送达，客服应在第一时间安抚用户，并提交物流异常工单。", "关于退换货：用户签收后 7 天内支持无理由退换货，但需保证商品不影响二次销售。", # ... 更多文档 ] # 2. 文本切分：chunk_size 控制单块长度，overlap 保留上下文衔接 splitter = RecursiveCharacterTextSplitter( chunk_size=200, chunk_overlap=50, separators=["。", "！", "？", "\n\n", "\n", " ", ""], ) chunks = splitter.create_documents(docs) # 3. 嵌入并入库 embeddings = OpenAIEmbeddings(model="text-embedding-3-small") vectorstore = FAISS.from_documents(chunks, embeddings) # 4. 保存到本地，之后每次启动直接从磁盘加载，不用重新嵌入 vectorstore.save_local("faiss_index")

检索与生成的代码：

from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate # 加载本地索引 embeddings = OpenAIEmbeddings(model="text-embedding-3-small") vectorstore = FAISS.load_local("faiss_index", embeddings, allow_dangerous_deserialization=True) query = "退换货的时间要求是什么？" retriever = vectorstore.as_retriever( search_type="similarity_score_threshold", search_kwargs={"score_threshold": 0.45, "k": 3}, ) results = retriever.invoke(query) context = "\n\n".join([doc.page_content for doc in results]) prompt = ChatPromptTemplate.from_messages([ ("system", "你是一名客服助手。请严格根据下方给定的上下文作答，如果上下文中没有相关信息，直接回答“未找到相关信息”。"), ("human", "上下文：\n{context}\n\n用户问题：{question}"), ]) llm = ChatOpenAI(model="gpt-4o-mini") chain = prompt | llm answer = chain.invoke({"context": context, "question": query}) print(answer.content)

这套代码能跑，但离“好用”还差几步。score_threshold这个参数的值依 Embedding 模型的分布而变，不是统一标准，你需要在业务数据上多测几个值。k也不是越大越好，我实测在多数问答场景下 k=3 到 k=5 之间的效果最均衡，超过 5 上下文噪声会明显增加。

3.3 接入 Agent：从 Tool 到 Agentic RAG

RAG 管道跑通之后，还得接进 Agent 才算完整闭环。常规做法是：把 RAG 检索封装成一个 Tool，Agent 在规划阶段按需调用。这在 LangChain 里用@tool装饰器几行代码就能实现。但我想分享一个更进阶的思路——Agentic RAG。

传统的 RAG 是一锤子买卖：用户提问，查一次库，生成回答。Agentic RAG 让 Agent 自己决定怎么查、查几次。举个例子，用户问“物流超时了怎么处理，能退运费吗？”一个普通 RAG 管道可能只召回物流流程那块。但 Agentic RAG 的 Agent 会拆解问题：先查“物流超时处理流程”，再查“退运费规则”，如果查回来的内容里提到“需提交工单”，Agent 还会再查“工单怎么提交”。几次检索结果都被拼进上下文，最后生成一个综合回答。

这种多步检索对复杂问题的命中率提升非常明显，而且每一步决策都透明可追踪，排错也方便。但代价是：多了一次 LLM 调用，延迟和成本都上去了。我的建议是：简单问题用传统 RAG，复杂问题走 Agentic RAG，或者用路由规则先判断问题类型，再决定走哪条管道。

热词里有人问“Skill 怎么和 RAG 结合起来”，我认为可以这样理解：Skill 是 Agent 的行为能力封装，比如“查天气”“下订单”“画图表”，而 RAG 是它的知识来源。两者不冲突，Skill 内部可以调用 RAG 拿资料，RAG 检索到的内容也可以触发某个 Skill 执行。真正优秀的 Agent 架构里，它们是交织的，不是二选一。

4. 从“能跑”到“好用”：检索质量与工程化避坑

4.1 检索质量的核心指标：Hit Rate 与 MRR

很多项目“能跑”，但用户用起来感觉“答非所问”。这时候别急着换大模型，先量化一下你的检索质量。我每次调优 RAG 之前，都先建一套评测集：准备 50~100 条真实问答对，每条问题标注它应该命中哪篇文档的哪个段落。然后跑检索，看两个指标。

Hit Rate（命中率）：评测集中，检索结果在前 N 条里包含正确文档的比例。比如 100 条问题里，有 80 条的正确答案出现在检索结果中，那 top-5 Hit Rate 就是 80%。这是最直观的指标，低于 70% 基本说明管道有问题，别急着优化 Prompt。

MRR（Mean Reciprocal Rank，平均倒数排名）：它更严格，不仅看有没有命中，还看正确答案排在第几位。如果正确答案排在第 1 位，记 1 分；排第 2 位，记 0.5 分；排第 5 位，记 0.2 分。全部问题的平均分就是 MRR。这个指标对重排序环节尤其敏感，你调了 Rerank 模型后，重点观察 MRR 的变化。

我操盘过的项目里，最常见的情况是 Hit Rate 不错但 MRR 很低——这代表相关文档能捞回来，但排得太后，被无关内容挤占了。这时候优先调重排序，而不是盲目加大 k。

4.2 切分策略、Embedding 选型、元数据过滤

先讲切分。我见过一个高密度技术文档的翻车案例：按固定 token 数切分，结果一个完整的接口定义被拦腰斩断，前半段讲入参，后半段讲返回值，检索到哪一半答案都不完整。后来改成“按 Markdown 二级标题优先切块 + 超长段落再二次切分”的双层策略，命中率直接从 62% 干到 84%。所以别迷信参数，要从你文档的实际结构出发设计切分规则。

Embedding 选型也是老生常谈，但我想分享一个真实测试结果：同一个中文知识库，我用某个通用 Embedding 模型跑，top-5 Hit Rate 只有 68%；换成长文本优化过的模型并加版本切换，直接到了 81%。差距是怎么来的？通用模型对长句、专业术语的表征能力远不如专攻这块的模型。所以选型建议始终不变：必须拿你自己的数据做 A/B 测试，别只看榜单分。

元数据过滤是很多人忽略的加速器。向量库支持预过滤时，千万别浪费这个能力。比如知识库里同时有产品手册和售后政策，用户明确问“退货规则”，你可以在检索前先用元数据把文档类型限定为“售后政策”，再在限定子集里做向量检索。这个操作不仅能提升精度，还能减少无用计算，响应速度也快了。

4.3 文档更新、向量库选型与成本控制

RAG 的一大卖点是知识实时更新，但实现起来有讲究。直接删了全量索引重建，简单粗暴但你承受不起频繁操作。我建议采用“增量更新 + 版本标记”策略：每个文档写入时带上版本号和更新时间，文档变更时标记老版本为“待失效”，新版本索引写入后异步清理老向量。检索时优先返回最新版本的内容。

关于向量库，我做个快速决策参考：

成本控制这块，最大的隐藏开销是 Embedding API 调用。全量文档重新嵌入要花钱且耗时，所以增量更新一定要做。另外，Rerank 模型需要 GPU 推理，如果只是小项目，可以用 API 形式按量调用，不必买卡。我在实际项目中，把 RAG 管道从“全部用 API”切到“本地小模型嵌入 + API Rerank”的混合模式后，单月成本降了 40%，响应时间反而短了。

还有一个容易被忽略的点：缓存。同样的用户问题，短时间内反复问，完全可以缓存检索结果，不用每次都跑一遍完整管道。我上线过一层 Redis 缓存 + 时效 10 分钟的简单方案，就把高频问题的平均响应时间从 3 秒压到了 1 秒以内。这个优化性价比极高。

5. 常见问题排查与实操心得

5.1 典型问题与排查思路实录

我做 RAG 相关项目的过程中，踩了不少坑，有代表性的集中列在下面：

问题一：检索命中率低，正确答案不在召回结果里。

排查顺序：先看切分是否合理（正确内容是不是被拦腰截断了）；再看 Embedding 模型和领域是否匹配；再看查询词和文档词面差异是否过大。最常见的原因是文档切分过碎，语义被破坏。解决方法是调整 chunk_size，或改成按文档结构切分。

问题二：数据全部入库了，但 Agent 回答还是“未找到相关信息”。

这种情况我至少见过三种原因：一是向量库和旧版本索引文件不同步，读的是旧数据；二是 score_threshold 设太高，把合格文档过滤掉了；三是检索到了正确 chunk，但 Prompt 的 system 指令写得过于保守，模型宁可拒答也不肯用上下文。第三个原因经常被忽略，检查时记得看模型实际收到的上下文。

问题三：回答内容张冠李戴，引用的段落是对的，但结论跑偏。

多半是上下文里混入了多个相关但不同的主题，模型被次要信息带偏了。对策是重排序后只保留前 3 个最相关的 chunk，并确保每个 chunk 只聚焦一个主题。如果文档本身就信息杂糅，那要回到切分环节去解决，Splitter 的分离符要考虑到文档的语义边界。

问题四：长文档问答效果差，问题问的是第 50 章，前面检索到的全是第 3 章的相似内容。

这个问题的根源在于向量检索本质是“全局找相似”，对长文档里局部位置关系不敏感。我的做法是给每个章节构造小节标题和摘要作为额外的索引入口，相当于做了两层索引：先按章节锚点找位置，再在位置内做精确匹配。

5.2 我私藏的几个实操技巧

最后分享几个不写进文档的实战心得。

第一，一定要建问答评测集，而且要从真实用户问题里采样。我见过太多团队用“我们自己编的漂亮问题”评测，结果上线后被用户一问就现原形。真实问题往往是口语化的、冗余的、带错别字的。评测集里包含这些“脏问题”，调优才有意义。

第二，RAG 的优化迭代要小步快跑。每次只改一个变量，改完立刻跑评测集看 Hit Rate 和 MRR。不要同时调切分参数又换 Embedding 模型，那样你根本分不清是哪个改动起了作用。我踩过最惨的一次就是一次性换了三个环节，结果指标上去了，但完全不知道谁贡献的，后续优化又一夜回到解放前。

第三，给 RAG 管道加一层“可观测性”。记录每次查询的 top_k 检索结果、打分、重排序后的顺序、最终 Prompt 内容。上线后一旦遇到差反馈，你能直接回放当时模型看到了什么。这一条建议我强烈推荐，能省掉大量“盲猜式”排错时间。

第四，如果你想做更深的方向，可以关注 Ontology RAG、GraphRAG 这些图谱增强方案。它们适合多跳推理、实体关系密集的场景，比平铺的向量检索更擅长抓住知识点之间的结构联系。但别一上来就上重型方案，先把基础 RAG 的准确率做到 90% 以上，再考虑图谱增强。

我个人在实际项目里最大的体会是：RAG 听着是个“技术”，做起来其实是“数据工程 + 检索策略 + 模型调优”三件事的交叉。真正把它做扎实了，Agent 的每一次回答都会变得有据可依，那种感觉跟裸奔式 Prompt 完全不是一个体验。这套基础管道能用到什么程度？我目前正在把技能库（Skill）与 RAG 检索做更深层次的编排，让 Agent 在复杂任务里按需组合多种工具和知识源。这个方向还有不少空间，后面等我跑出稳定的方案，再来跟你分享。