要说现在的 AI Agent 项目真正拉开体验差距的往往不是模型选得多新、Prompt 写得有多花哨而是它到底能不能拿到“对的知识”。前面几篇聊了 Agent 的编排框架、记忆设计到了第四篇必须把知识获取管道讲清楚。RAGRetrieval-Augmented Generation检索增强生成说白了就是给 Agent 装一条正式的知识管道从外部文档、数据库、知识库里把和用户问题相关的内容捞出来再交给模型组织答案。它解决的是大模型三大天生缺陷幻觉、知识滞后、无法读取私域数据。这篇内容适合两类人一类是正准备从 0 到 1 搭建自己的 Agent、但不知道知识库部分从哪入手的初学者另一类是已经在做 RAG 检索但效果不理想、想搞清楚切分和检索那块到底该怎么调优的工程师。我会把 RAG 的完整链路拆开讲再给一套我在实际项目中反复验证过的搭建和排查方案。1.1 先理清 Agent 对“知识”的真实需求很多朋友第一次接触 Agent会把“知识库”和“记忆”混为一谈这个必须掰开。记忆是会话级的负责记住用户上一句说了什么、之前聊过什么偏好它的载体通常是对话历史摘要或向量化的记忆片段。而知识是领域级的比如一份产品操作手册、一整套企业规章制度、一个售后 FAQ 库这些东西和“聊了多久”没关系属于长期稳定的外部事实源。Agent 要回答“我们公司请假流程是什么”“这个路由器怎么恢复出厂设置”这类问题光靠模型训练时学到的通用知识根本不够必须去查资料。RAG 就是这个“查资料”的动作本身。理解了这一点再看 Agent 的知识获取管道其实无非四种方式第一种是把知识写死在 Prompt 里适合上下文很短、总量小于几千字的场景第二种是外挂 RAG动态检索插入上下文这是目前最通用的方案第三种是干脆对模型做领域微调把知识压缩进参数里但成本高、更新慢适合知识极其稳定且需求量极大的场景第四种是这两年兴起的让 Agent 自己调用工具取数本质上是把知识获取行为变成了一个工具调用决策。RAG 处在“长期外部知识”和“灵活更新”的交集上性价比最高。1.2 为什么不是微调也不是无脑塞长上下文有个高频问题我把整本手册塞进上下文行不行短文档可以文档一长就出问题。上下文窗口再大模型对中间位置信息的注意力会自然衰减而且塞入大量无关内容会明显干扰生成质量。成本也在那里每轮对话都带着几十万字跑一遍Token 费用完全吃不消。微调则更像“把书背进脑子里”适合行为习惯的塑造不适合事实类的精确问答——今天业务规则变了你不可能天天微调一次。RAG 的做法是“现用现查”每次只把最相关的几段内容喂给模型更新知识只需要替换索引里的文档成本低、反馈快。我实际跑过的项目里有一个印象很深的对比同一批售后文档纯 Prompt 硬答的准确率在 62% 左右接入 RAG 之后直接跳到 89%而微调模型在新增产品的问答上反而出现了严重幻觉——它太“自信”了把旧知识泛化到了新产品上。从那以后凡是面向动态知识的场景我都默认先上 RAG。2.1 先把整条链路画清楚从文档到答案的六步RAG 看起来名字唬人拆开其实就六个环节加载、切分、向量化、存储、检索、生成。前四个环节属于“离线建索引”也就是提前把文档处理成可供检索的形态后两个环节属于“在线服务”用户每次发问时实时执行。理解这种“离线在线分离”的架构非常重要它决定了系统的扩展方式——文档量大了就横向加索引节点用户量大了则要关注检索服务的吞吐。加载环节负责把 PDF、Word、Markdown、HTML 等不同格式的内容读成纯文本切分环节把长文档切成适当大小的片段也就是 Chunk向量化环节用 Embedding 模型把每段文本转成一个高维向量存储环节把这些向量连同原文、元数据一起写进向量数据库。到了在线阶段用户的问题同样会被向量化然后在库里做相似度检索捞回最相关的 Top-K 段文本最后把问题和这些文本拼成一个 Prompt 交给大模型生成答案。这里面的每一步都有大量可调参数调整空间甚至比模型本身还大。2.2 文档加载与清洗索引质量的地基文档加载看似无聊却是整条管道里坑最多的地方。以最常用的 PDF 为例用 PyMuPDF 这类工具读取文本往往带着页眉页脚、换行符错乱、目录页码混排的垃圾内容。有些 PDF 的表格区域会被读成完全错乱的字符串明明是一个三列的参数表读出来变成一坨不明所以的字符。我处理数据时有个习惯拿到原始文档先做三层清洗去噪把页眉页脚、页码、超链接标记、无意义的空白符清掉合并把因为排版断开的句子按语义重新拼接丢弃对乱码严重、扫描件且没有 OCR 的页面宁可删掉也不要放进索引里污染效果。清洗完还要做“结构感知”。Word 和 Markdown 文档天然带章节层级PDF 里通常也有目录信息这些结构是切分时的上等原料。比如按标题层级切分能保证每个片段对应一个相对完整的主题而不是机械地按字符数掰开。我在做企业知识库的时候常常会用 LangChain 里的 MarkdownHeaderTextSplitter 先按章节拆一遍再对特别长的章节做二次切分效果比单一切分策略好得多。2.3 Chunk 切分最容易被低估的调优点很多人第一次搭 RAG直接选了默认的固定长度切分chunk_size 设成 1000 就完事了。实际测试下来切分策略对检索命中的影响往往比换 Embedding 模型还显著。切太细单个片段可能语义不完整一个问题的答案被拆到两个 Chunk 里检索就召回不齐切太粗片段里混入无关内容相似度被稀释而且喂给模型的有效上下文利用率也会下降。我自己常用的经验值是这样通用文档切 400 到 600 字重叠区设 50 到 80 字。为什么中文要设重叠因为切分点恰好落在一句话中间时重叠区能保证后半段不会完全丢失上下文。对于代码片段、JSON 这类结构文本要按代码块边界切对于问答对要保证“问答”在一个 Chunk 里否则检索只捞到问题没捞到答案就尴尬了。from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , , ], keep_separatorFalse, ) chunks text_splitter.split_documents(documents)像上面这段separators 里特意加了中文标点这是 LangChain 默认配置没有的。默认的递归切分器主要按换行和空格切英文友好中文文本会被切得七零八落。把中文句号、问号、分号、逗号按优先级加进去切出来的片段会自然落在语义边界上。这一行配置值几千个测试样本的经验。2.4 Embedding 模型与向量库选型不同量级不同答案Embedding 模型决定了文本之间的距离感选错了后面检索做再多优化都是隔靴搔痒。现在的中文场景里BGE 系列比如 bge-large-zh-v1.5、bge-m3是开源里口碑很稳的选择m3e 和 text2vec 也有一批用户。如果完全不想自建直接用云厂商的 Embedding API 也行但要注意两点一是中文场景尽量用专门优化过的中文模型不要拿通用英文模型硬扛二是查询文本和入库文本的指令格式要一致比如 BGE 要求查询侧加“为这个句子生成表示以用于检索相关文章”的前缀漏了会掉几个点的命中率。向量数据库这一层我的选择逻辑很简单项目原型和文档量在百万级以内直接上 Chroma 或 FAISS部署成本低内存里就能跑数据量上了千万级、需要分布式和实时写入再考虑 Milvus 或 Qdrant。还有一个常被忽略的点是多模态和过滤需求——如果你的文档需要按部门、按时间、按文档类型过滤向量库的元数据过滤能力会比纯粹的距离计算重要得多。向量化之后每个片段都带上 source 和 page 这样的元数据才能在检索阶段做精确圈定。3.1 技术选型用 Python LangChain 快速跑通还是其他搭建 RAG 管道目前最省力的路线是用 LangChain 生态把各个组件串起来。虽然有朋友会质疑 LangChain 抽象层太多、不够透明但对大多数业务项目来说它内置的文档加载器、切分器、检索器、集成封装能省掉一多半的对接工作。如果你在 Java 生态Spring AI 也在快速发展RAG 相关组件已经比较完整LangChain4j 也值得关注。但作为入门和排查问题的基础Python 生态的调试效率和社区资料仍然是最好的。我之前给一个内部项目搭知识库问答需求是把 30 多份产品手册做成一个可问答的“数字客服”。技术路线选的是 PyMuPDFLoader 读 PDF、BGE 做 Embedding、Chroma 做向量存储、OpenAI 兼容接口的大模型做生成。全套跑通加调优大概花了一个下午。下面把核心代码拆开讲。3.2 完整实现加载、切分、入库、检索、生成一条龙先处理文档加载和切分。这里有个细节加载 PDF 之后不仅要拿到文本还要把页码信息保留到 metadata 里这样检索结果还能溯源定位到原文第几页用户或 Agent 后续核查起来也方便。from langchain_community.document_loaders import PyMuPDFLoader loader PyMuPDFLoader(docs/产品手册.pdf) documents loader.load() # 清洗与元数据补充 for doc in documents: doc.page_content clean_text(doc.page_content) # 去页眉页脚、处理乱码 doc.metadata[source] 产品手册.pdf切分器用上一节讲到的中文优化配置from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , , ], ) chunks splitter.split_documents(documents) print(f切分成 {len(chunks)} 个片段)然后是 Embedding 模型和向量库。这里用 BGE 模型注意查询侧的指令前缀。from langchain_community.embeddings import HuggingFaceBgeEmbeddings embedding_model HuggingFaceBgeEmbeddings( model_nameBAAI/bge-large-zh-v1.5, query_instruction为这个句子生成表示以用于检索相关文章, )from langchain_chroma import Chroma vectorstore Chroma.from_documents( documentschunks, embeddingembedding_model, persist_directory./chroma_db, ) retriever vectorstore.as_retriever(search_kwargs{k: 4})这段代码执行完RAG 的索引部分就建好了。注意 Chroma 会持久化到本地磁盘目录下次启动可以直接加载不用重复入库。Top-K 我这边设成 4这是经过测试的折中值——太少容易漏信息太多则把无关内容也塞进上下文反而干扰生成。如果你的文档比较长、问题拆解较细可以试试 5 到 6。生成环节直接接大模型。OpenAI 兼容接口的好处是国内很多模型服务商都提供兼容协议换模型只要改 base_url 和 api_key 就行。from langchain_core.output_parsers import StrOutputParser from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o-mini, temperature0.0, base_url你的接口地址, api_key你的API Key) prompt ChatPromptTemplate.from_template( 你是一个知识库问答助手。请仅根据以下资料回答问题如果资料中没有相关信息就说资料中未找到不要编造。\n\n资料\n{context}\n\n问题{question} ) rag_chain ( {context: retriever, question: lambda x: x[question]} | prompt | llm | StrOutputParser() ) answer rag_chain.invoke({question: 产品 X 的保修政策是什么}) print(answer)这里 temperature 设成 0尽可能减少自由发挥的空间。资料中未找到就直说这是抑制幻觉的关键一步。很多人做完这一步就开始欢呼“我有了 RAG”其实这才是起点。检索质量、切分粒度、文档质量这些才是决定上限的地方。3.3 把 RAG 接入 Agent把它变成 Agent 的一项工具上面这套 RAG 管道本质上还是一个“你问我答”的检索问答链。放进 Agent 里正确的做法是把检索能力封装成工具让 Agent 根据用户问题自行判断要不要调用。为什么要绕这么一层因为真实的用户问题往往不是直接针对知识库的可能是闲聊、可能是要执行动作也可能是先要检索再基于检索结果做推理。如果每次对话都强制走 RAG既浪费 Token又可能在不需要知识的时候引入干扰。用 LangChain 的 tool 装饰器可以把检索问答函数变成一个 Agent 可调用的工具from langchain_core.tools import tool tool def search_knowledge_base(query: str) - str: 当用户询问产品功能、参数、保修、故障排查等信息时调用此工具检索产品知识库。 docs retriever.invoke(query) if not docs: return 知识库中没有找到相关信息 context \n\n.join( f[来源: {d.metadata.get(source, 未知)}第 {d.metadata.get(page, ?)} 页]\n{d.page_content} for d in docs ) return rag_chain.invoke({question: query, context: context})然后把工具传给 Agent 的绑定函数。这样一来Agent 收到的用户消息会先经过意图判断只有需要知识库支持时才会触发检索整个交互更像真人客服。我实际体验下来这种设计还能把“查文档”和“查历史订单”“计算报价”这类其他工具组合在一起实现更复杂的任务流。4.1 检索不准七成问题出在 Query 和 Chunk而不是模型我见过太多人一遇到效果不好就想着换更大的模型、换更强的 Embedding结果优化半天毫无起色。这里我总结过一条经验先看召回再看排序最后才是生成。召回不准答案天花乱坠也没用。而且召回的问题七成出在 Query 和 Chunk 身上。Query 问题最常见的表现是用户问题太口语化和文档里的表述对不上。比如用户问“电脑老卡怎么办”文档里写的是“系统性能优化”字面上完全不像语义相似度也难以拉近。解决办法是在检索之前加一道 Query 改写让大模型把口语化的问题转换成适合检索的关键词组合或者扩展出多个角度的子查询。Agent 场景下这一步更自然——Agent 本来就会对用户意图做拆解把改写后的 Query 喂给检索器即可。Chunk 问题多表现为切分不当导致信息碎片化。有一次我排查一个效果极差的问答发现答案分散在第 13 和 14 两个 Chunk 里每个都是 400 字单独看都不是完整的答案合并起来才算完整。这就要么调大 chunk_size要么做“父子切分”父片段保语义完整子片段做精确检索命中后把父片段喂给模型。另一个性价比极高的手段是混合检索。向量检索擅长语义相似但精确的词面匹配比如型号、编码往往不如 BM25。把两者用 EnsembleRetriever 加权组合大多数场景都有明显提升from langchain.retrievers import EnsembleRetriever from langchain_community.retrievers import BM25Retriever bm25_retriever BM25Retriever.from_documents(chunks, k4) ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, retriever], weights[0.4, 0.6], )加权比例我一般给 BM25 三到四成、向量六到七成。具体可以跑一批测试问题调一下但 0.4/0.6 作为起点很稳。如果混合检索之后还是觉得排序不对再加重排Rerank。重排是拿一个专门训练的 Cross-Encoder 模型对候选结果做精细的二度打分效果非常明显但对性能有要求。可以使用 bge-reranker-base 这类模型。重排模型可以单独部署成服务Agent 检索时只对 Top-20 的候选做重排取前 4 个喂给大模型成本可控。4.2 常见问题排查速查表我把自己和身边朋友踩过的坑整理成一张速查表排查时可以按图索骥。症状大概率原因排查方向与解法回答经常说“资料中未找到”召回率太低相关文档没被捞出来检查切分粒度尝试混合检索加 Query 改写回答引用了无关段落排序不准相似但无关的内容排在前面引入 Rerank调整 Top-K检查是否有元数据污染同一问题每次回答不一致检索到的 Chunk 不稳定排查向量库是否被并发写入确认 Top-K 是否固定降低温度参数答案明显编造检索内容不足但模型强行作答Prompt 中强调“没有资料就直说”降低 temperature必要时加“拒答”分支相似问题效果差异巨大切分点破坏了答案的完整性尝试父子切分或按文档结构切分公司内部专有名词频繁出错通用 Embedding 不理解领域语义积累领域平行语料对 Embedding 做领域微调或引入同义词表测试下来如果 hit_rate 低于 0.7说实话别急着调生成侧的 Prompt先把索引侧问题解决。命中率的意思是测试集里有多少比例的问题其标准答案所对应的片段出现在检索 Top-K 结果中。这个指标和最终问答质量强相关而且不需要大模型参与评估手工标注一轮就能算出来。4.3 从 RAG 到 Agentic RAG知识管道的下一步RAG 管道做到这一步已经可以支撑不少业务了。但真实场景里还有一类问题它搞不定需要多步推理才能完成的检索。比如用户问“A 型号和 B 型号都支持什么充电协议哪个兼容我的笔记本”这个问题的答案需要从多个文档片段中分别找到 A 的参数、B 的参数、充电协议列表最后再做对比。普通 RAG 一次检索捞回来的内容不一定能覆盖全部信息这时候就需要 Agentic RAG——让 Agent 自己决定查几次、先查什么再查什么每查一次就检查当前信息够不够不够就再发起一轮新的检索。这也是为什么前面强调“把 RAG 封装成工具”而不是“让 RAG 直接处理所有问题”。工具化之后Agent 天然具备多轮检索能力。作为知识管道的进阶方向还有两条路径值得关注一条是 GraphRAG适合实体关系密集的文档先构建知识图谱再做检索回答“谁和谁有关系”这类问题时远胜纯向量检索另一条是本体增强的 RAG用 Ontology 定义领域概念和关系约束在检索前做语义对齐适合术语体系严谨的专业领域。这些属于后续深入的方向但底色还是今天这套基础管道把地基打牢再往上盖楼不迟。把 RAG 管道完整跑通之后我个人的体会是它不是一个“跑通就行”的组件而是一个需要持续度量、持续迭代的子系统。我自己踩过几次坑之后最大的心得其实就一句话——先在检索评估上投入时间建立二三十个代表性问题的测试集每次改动都拿 hit_rate 说话而不是凭感觉调参。这套方法虽然朴素但能少走很多弯路。希望这篇基础篇能帮你把知识管道立起来后面我们再往下钻聊多轮检索、聊知识图谱也聊聊更复杂的 Agent 记忆和工具的协同。
要说现在的 AI Agent 项目真正拉开体验差距的往往不是模型选得多新、Prompt 写得有多花哨而是它到底能不能拿到“对的知识”。前面几篇聊了 Agent 的编排框架、记忆设计到了第四篇必须把知识获取管道讲清楚。RAGRetrieval-Augmented Generation检索增强生成说白了就是给 Agent 装一条正式的知识管道从外部文档、数据库、知识库里把和用户问题相关的内容捞出来再交给模型组织答案。它解决的是大模型三大天生缺陷幻觉、知识滞后、无法读取私域数据。这篇内容适合两类人一类是正准备从 0 到 1 搭建自己的 Agent、但不知道知识库部分从哪入手的初学者另一类是已经在做 RAG 检索但效果不理想、想搞清楚切分和检索那块到底该怎么调优的工程师。我会把 RAG 的完整链路拆开讲再给一套我在实际项目中反复验证过的搭建和排查方案。1.1 先理清 Agent 对“知识”的真实需求很多朋友第一次接触 Agent会把“知识库”和“记忆”混为一谈这个必须掰开。记忆是会话级的负责记住用户上一句说了什么、之前聊过什么偏好它的载体通常是对话历史摘要或向量化的记忆片段。而知识是领域级的比如一份产品操作手册、一整套企业规章制度、一个售后 FAQ 库这些东西和“聊了多久”没关系属于长期稳定的外部事实源。Agent 要回答“我们公司请假流程是什么”“这个路由器怎么恢复出厂设置”这类问题光靠模型训练时学到的通用知识根本不够必须去查资料。RAG 就是这个“查资料”的动作本身。理解了这一点再看 Agent 的知识获取管道其实无非四种方式第一种是把知识写死在 Prompt 里适合上下文很短、总量小于几千字的场景第二种是外挂 RAG动态检索插入上下文这是目前最通用的方案第三种是干脆对模型做领域微调把知识压缩进参数里但成本高、更新慢适合知识极其稳定且需求量极大的场景第四种是这两年兴起的让 Agent 自己调用工具取数本质上是把知识获取行为变成了一个工具调用决策。RAG 处在“长期外部知识”和“灵活更新”的交集上性价比最高。1.2 为什么不是微调也不是无脑塞长上下文有个高频问题我把整本手册塞进上下文行不行短文档可以文档一长就出问题。上下文窗口再大模型对中间位置信息的注意力会自然衰减而且塞入大量无关内容会明显干扰生成质量。成本也在那里每轮对话都带着几十万字跑一遍Token 费用完全吃不消。微调则更像“把书背进脑子里”适合行为习惯的塑造不适合事实类的精确问答——今天业务规则变了你不可能天天微调一次。RAG 的做法是“现用现查”每次只把最相关的几段内容喂给模型更新知识只需要替换索引里的文档成本低、反馈快。我实际跑过的项目里有一个印象很深的对比同一批售后文档纯 Prompt 硬答的准确率在 62% 左右接入 RAG 之后直接跳到 89%而微调模型在新增产品的问答上反而出现了严重幻觉——它太“自信”了把旧知识泛化到了新产品上。从那以后凡是面向动态知识的场景我都默认先上 RAG。2.1 先把整条链路画清楚从文档到答案的六步RAG 看起来名字唬人拆开其实就六个环节加载、切分、向量化、存储、检索、生成。前四个环节属于“离线建索引”也就是提前把文档处理成可供检索的形态后两个环节属于“在线服务”用户每次发问时实时执行。理解这种“离线在线分离”的架构非常重要它决定了系统的扩展方式——文档量大了就横向加索引节点用户量大了则要关注检索服务的吞吐。加载环节负责把 PDF、Word、Markdown、HTML 等不同格式的内容读成纯文本切分环节把长文档切成适当大小的片段也就是 Chunk向量化环节用 Embedding 模型把每段文本转成一个高维向量存储环节把这些向量连同原文、元数据一起写进向量数据库。到了在线阶段用户的问题同样会被向量化然后在库里做相似度检索捞回最相关的 Top-K 段文本最后把问题和这些文本拼成一个 Prompt 交给大模型生成答案。这里面的每一步都有大量可调参数调整空间甚至比模型本身还大。2.2 文档加载与清洗索引质量的地基文档加载看似无聊却是整条管道里坑最多的地方。以最常用的 PDF 为例用 PyMuPDF 这类工具读取文本往往带着页眉页脚、换行符错乱、目录页码混排的垃圾内容。有些 PDF 的表格区域会被读成完全错乱的字符串明明是一个三列的参数表读出来变成一坨不明所以的字符。我处理数据时有个习惯拿到原始文档先做三层清洗去噪把页眉页脚、页码、超链接标记、无意义的空白符清掉合并把因为排版断开的句子按语义重新拼接丢弃对乱码严重、扫描件且没有 OCR 的页面宁可删掉也不要放进索引里污染效果。清洗完还要做“结构感知”。Word 和 Markdown 文档天然带章节层级PDF 里通常也有目录信息这些结构是切分时的上等原料。比如按标题层级切分能保证每个片段对应一个相对完整的主题而不是机械地按字符数掰开。我在做企业知识库的时候常常会用 LangChain 里的 MarkdownHeaderTextSplitter 先按章节拆一遍再对特别长的章节做二次切分效果比单一切分策略好得多。2.3 Chunk 切分最容易被低估的调优点很多人第一次搭 RAG直接选了默认的固定长度切分chunk_size 设成 1000 就完事了。实际测试下来切分策略对检索命中的影响往往比换 Embedding 模型还显著。切太细单个片段可能语义不完整一个问题的答案被拆到两个 Chunk 里检索就召回不齐切太粗片段里混入无关内容相似度被稀释而且喂给模型的有效上下文利用率也会下降。我自己常用的经验值是这样通用文档切 400 到 600 字重叠区设 50 到 80 字。为什么中文要设重叠因为切分点恰好落在一句话中间时重叠区能保证后半段不会完全丢失上下文。对于代码片段、JSON 这类结构文本要按代码块边界切对于问答对要保证“问答”在一个 Chunk 里否则检索只捞到问题没捞到答案就尴尬了。from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , , ], keep_separatorFalse, ) chunks text_splitter.split_documents(documents)像上面这段separators 里特意加了中文标点这是 LangChain 默认配置没有的。默认的递归切分器主要按换行和空格切英文友好中文文本会被切得七零八落。把中文句号、问号、分号、逗号按优先级加进去切出来的片段会自然落在语义边界上。这一行配置值几千个测试样本的经验。2.4 Embedding 模型与向量库选型不同量级不同答案Embedding 模型决定了文本之间的距离感选错了后面检索做再多优化都是隔靴搔痒。现在的中文场景里BGE 系列比如 bge-large-zh-v1.5、bge-m3是开源里口碑很稳的选择m3e 和 text2vec 也有一批用户。如果完全不想自建直接用云厂商的 Embedding API 也行但要注意两点一是中文场景尽量用专门优化过的中文模型不要拿通用英文模型硬扛二是查询文本和入库文本的指令格式要一致比如 BGE 要求查询侧加“为这个句子生成表示以用于检索相关文章”的前缀漏了会掉几个点的命中率。向量数据库这一层我的选择逻辑很简单项目原型和文档量在百万级以内直接上 Chroma 或 FAISS部署成本低内存里就能跑数据量上了千万级、需要分布式和实时写入再考虑 Milvus 或 Qdrant。还有一个常被忽略的点是多模态和过滤需求——如果你的文档需要按部门、按时间、按文档类型过滤向量库的元数据过滤能力会比纯粹的距离计算重要得多。向量化之后每个片段都带上 source 和 page 这样的元数据才能在检索阶段做精确圈定。3.1 技术选型用 Python LangChain 快速跑通还是其他搭建 RAG 管道目前最省力的路线是用 LangChain 生态把各个组件串起来。虽然有朋友会质疑 LangChain 抽象层太多、不够透明但对大多数业务项目来说它内置的文档加载器、切分器、检索器、集成封装能省掉一多半的对接工作。如果你在 Java 生态Spring AI 也在快速发展RAG 相关组件已经比较完整LangChain4j 也值得关注。但作为入门和排查问题的基础Python 生态的调试效率和社区资料仍然是最好的。我之前给一个内部项目搭知识库问答需求是把 30 多份产品手册做成一个可问答的“数字客服”。技术路线选的是 PyMuPDFLoader 读 PDF、BGE 做 Embedding、Chroma 做向量存储、OpenAI 兼容接口的大模型做生成。全套跑通加调优大概花了一个下午。下面把核心代码拆开讲。3.2 完整实现加载、切分、入库、检索、生成一条龙先处理文档加载和切分。这里有个细节加载 PDF 之后不仅要拿到文本还要把页码信息保留到 metadata 里这样检索结果还能溯源定位到原文第几页用户或 Agent 后续核查起来也方便。from langchain_community.document_loaders import PyMuPDFLoader loader PyMuPDFLoader(docs/产品手册.pdf) documents loader.load() # 清洗与元数据补充 for doc in documents: doc.page_content clean_text(doc.page_content) # 去页眉页脚、处理乱码 doc.metadata[source] 产品手册.pdf切分器用上一节讲到的中文优化配置from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , , ], ) chunks splitter.split_documents(documents) print(f切分成 {len(chunks)} 个片段)然后是 Embedding 模型和向量库。这里用 BGE 模型注意查询侧的指令前缀。from langchain_community.embeddings import HuggingFaceBgeEmbeddings embedding_model HuggingFaceBgeEmbeddings( model_nameBAAI/bge-large-zh-v1.5, query_instruction为这个句子生成表示以用于检索相关文章, )from langchain_chroma import Chroma vectorstore Chroma.from_documents( documentschunks, embeddingembedding_model, persist_directory./chroma_db, ) retriever vectorstore.as_retriever(search_kwargs{k: 4})这段代码执行完RAG 的索引部分就建好了。注意 Chroma 会持久化到本地磁盘目录下次启动可以直接加载不用重复入库。Top-K 我这边设成 4这是经过测试的折中值——太少容易漏信息太多则把无关内容也塞进上下文反而干扰生成。如果你的文档比较长、问题拆解较细可以试试 5 到 6。生成环节直接接大模型。OpenAI 兼容接口的好处是国内很多模型服务商都提供兼容协议换模型只要改 base_url 和 api_key 就行。from langchain_core.output_parsers import StrOutputParser from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o-mini, temperature0.0, base_url你的接口地址, api_key你的API Key) prompt ChatPromptTemplate.from_template( 你是一个知识库问答助手。请仅根据以下资料回答问题如果资料中没有相关信息就说资料中未找到不要编造。\n\n资料\n{context}\n\n问题{question} ) rag_chain ( {context: retriever, question: lambda x: x[question]} | prompt | llm | StrOutputParser() ) answer rag_chain.invoke({question: 产品 X 的保修政策是什么}) print(answer)这里 temperature 设成 0尽可能减少自由发挥的空间。资料中未找到就直说这是抑制幻觉的关键一步。很多人做完这一步就开始欢呼“我有了 RAG”其实这才是起点。检索质量、切分粒度、文档质量这些才是决定上限的地方。3.3 把 RAG 接入 Agent把它变成 Agent 的一项工具上面这套 RAG 管道本质上还是一个“你问我答”的检索问答链。放进 Agent 里正确的做法是把检索能力封装成工具让 Agent 根据用户问题自行判断要不要调用。为什么要绕这么一层因为真实的用户问题往往不是直接针对知识库的可能是闲聊、可能是要执行动作也可能是先要检索再基于检索结果做推理。如果每次对话都强制走 RAG既浪费 Token又可能在不需要知识的时候引入干扰。用 LangChain 的 tool 装饰器可以把检索问答函数变成一个 Agent 可调用的工具from langchain_core.tools import tool tool def search_knowledge_base(query: str) - str: 当用户询问产品功能、参数、保修、故障排查等信息时调用此工具检索产品知识库。 docs retriever.invoke(query) if not docs: return 知识库中没有找到相关信息 context \n\n.join( f[来源: {d.metadata.get(source, 未知)}第 {d.metadata.get(page, ?)} 页]\n{d.page_content} for d in docs ) return rag_chain.invoke({question: query, context: context})然后把工具传给 Agent 的绑定函数。这样一来Agent 收到的用户消息会先经过意图判断只有需要知识库支持时才会触发检索整个交互更像真人客服。我实际体验下来这种设计还能把“查文档”和“查历史订单”“计算报价”这类其他工具组合在一起实现更复杂的任务流。4.1 检索不准七成问题出在 Query 和 Chunk而不是模型我见过太多人一遇到效果不好就想着换更大的模型、换更强的 Embedding结果优化半天毫无起色。这里我总结过一条经验先看召回再看排序最后才是生成。召回不准答案天花乱坠也没用。而且召回的问题七成出在 Query 和 Chunk 身上。Query 问题最常见的表现是用户问题太口语化和文档里的表述对不上。比如用户问“电脑老卡怎么办”文档里写的是“系统性能优化”字面上完全不像语义相似度也难以拉近。解决办法是在检索之前加一道 Query 改写让大模型把口语化的问题转换成适合检索的关键词组合或者扩展出多个角度的子查询。Agent 场景下这一步更自然——Agent 本来就会对用户意图做拆解把改写后的 Query 喂给检索器即可。Chunk 问题多表现为切分不当导致信息碎片化。有一次我排查一个效果极差的问答发现答案分散在第 13 和 14 两个 Chunk 里每个都是 400 字单独看都不是完整的答案合并起来才算完整。这就要么调大 chunk_size要么做“父子切分”父片段保语义完整子片段做精确检索命中后把父片段喂给模型。另一个性价比极高的手段是混合检索。向量检索擅长语义相似但精确的词面匹配比如型号、编码往往不如 BM25。把两者用 EnsembleRetriever 加权组合大多数场景都有明显提升from langchain.retrievers import EnsembleRetriever from langchain_community.retrievers import BM25Retriever bm25_retriever BM25Retriever.from_documents(chunks, k4) ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, retriever], weights[0.4, 0.6], )加权比例我一般给 BM25 三到四成、向量六到七成。具体可以跑一批测试问题调一下但 0.4/0.6 作为起点很稳。如果混合检索之后还是觉得排序不对再加重排Rerank。重排是拿一个专门训练的 Cross-Encoder 模型对候选结果做精细的二度打分效果非常明显但对性能有要求。可以使用 bge-reranker-base 这类模型。重排模型可以单独部署成服务Agent 检索时只对 Top-20 的候选做重排取前 4 个喂给大模型成本可控。4.2 常见问题排查速查表我把自己和身边朋友踩过的坑整理成一张速查表排查时可以按图索骥。症状大概率原因排查方向与解法回答经常说“资料中未找到”召回率太低相关文档没被捞出来检查切分粒度尝试混合检索加 Query 改写回答引用了无关段落排序不准相似但无关的内容排在前面引入 Rerank调整 Top-K检查是否有元数据污染同一问题每次回答不一致检索到的 Chunk 不稳定排查向量库是否被并发写入确认 Top-K 是否固定降低温度参数答案明显编造检索内容不足但模型强行作答Prompt 中强调“没有资料就直说”降低 temperature必要时加“拒答”分支相似问题效果差异巨大切分点破坏了答案的完整性尝试父子切分或按文档结构切分公司内部专有名词频繁出错通用 Embedding 不理解领域语义积累领域平行语料对 Embedding 做领域微调或引入同义词表测试下来如果 hit_rate 低于 0.7说实话别急着调生成侧的 Prompt先把索引侧问题解决。命中率的意思是测试集里有多少比例的问题其标准答案所对应的片段出现在检索 Top-K 结果中。这个指标和最终问答质量强相关而且不需要大模型参与评估手工标注一轮就能算出来。4.3 从 RAG 到 Agentic RAG知识管道的下一步RAG 管道做到这一步已经可以支撑不少业务了。但真实场景里还有一类问题它搞不定需要多步推理才能完成的检索。比如用户问“A 型号和 B 型号都支持什么充电协议哪个兼容我的笔记本”这个问题的答案需要从多个文档片段中分别找到 A 的参数、B 的参数、充电协议列表最后再做对比。普通 RAG 一次检索捞回来的内容不一定能覆盖全部信息这时候就需要 Agentic RAG——让 Agent 自己决定查几次、先查什么再查什么每查一次就检查当前信息够不够不够就再发起一轮新的检索。这也是为什么前面强调“把 RAG 封装成工具”而不是“让 RAG 直接处理所有问题”。工具化之后Agent 天然具备多轮检索能力。作为知识管道的进阶方向还有两条路径值得关注一条是 GraphRAG适合实体关系密集的文档先构建知识图谱再做检索回答“谁和谁有关系”这类问题时远胜纯向量检索另一条是本体增强的 RAG用 Ontology 定义领域概念和关系约束在检索前做语义对齐适合术语体系严谨的专业领域。这些属于后续深入的方向但底色还是今天这套基础管道把地基打牢再往上盖楼不迟。把 RAG 管道完整跑通之后我个人的体会是它不是一个“跑通就行”的组件而是一个需要持续度量、持续迭代的子系统。我自己踩过几次坑之后最大的心得其实就一句话——先在检索评估上投入时间建立二三十个代表性问题的测试集每次改动都拿 hit_rate 说话而不是凭感觉调参。这套方法虽然朴素但能少走很多弯路。希望这篇基础篇能帮你把知识管道立起来后面我们再往下钻聊多轮检索、聊知识图谱也聊聊更复杂的 Agent 记忆和工具的协同。
