RAG实战：AI Agent知识获取管道搭建与调优指南-平芜编程栈

把AI Agent系列写到第四篇，终于要碰最硬核、也最容易翻车的环节——知识获取管道。前面几篇聊了Agent的规划、工具调用和记忆，但真正跑业务的Agent总会撞上一个现实：模型参数里的知识是“上一个训练周期”的知识，它不知道你刚更新的业务文档，也不知道你们公司内部的知识库。RAG（Retrieval-Augmented Generation，检索增强生成）就是给Agent补上“知识外挂”的标准做法：在模型回答之前，先从外部知识库检索出一批相关资料，再把“问题＋资料”一起交给模型，让它基于证据回答。这套管道不解决所有问题，但它是让Agent从“嘴强王者”变成“能干活”的基础设施。这篇文章会把RAG最基础的链路完整拆一遍，并给出可以直接参考的落地代码、参数选型与排查清单，适合刚入门Agent开发、或已经跑通Demo但对效果不满意的朋友。

先说结论：别急着上重编排、多跳推理、知识图谱，先把“切分—向量化—检索—生成”这四个环节的每个参数吃透，后面的一切才有意义。

1. RAG在Agent架构里的角色，远不止“加个知识库”

1.1 Agent为什么必须有知识获取管道

Agent应用和纯聊天机器人最大的区别，在于它要朝着一个目标去行动，需要调用工具、做规划、跟外部系统打交道。但不管怎么流转，最终给用户的那段回复，都依赖“当前这个模型脑子里的知识”。问题是，模型参数里的知识在训练完成那一刻就冻结了，它记不住昨天更新的产品手册，也没读过你上传的几百份PDF。

这时候如果硬让模型回答，它就只能“编”。Agent圈里这种现象特别常见：任务规划头头是道，一旦涉及具体业务数据，就开始一本正经地胡说八道，比如把退货政策的截止日期说错，把内部审批流程的负责人搞混。根本原因不是模型不够聪明，而是知识获取环节是断的。

所以RAG要承担的角色，是给Agent接一条“外挂记忆”通路。在模型生成之前，先从一个受控的知识源里把相关资料捞出来，塞进上下文，再让模型基于这些材料作答。这样回答不仅更新鲜，还能给出依据，用户问“你怎么知道的”，你可以直接把原文片段甩过去。

还有一个经常被拿来对比的方案是微调。RAG和微调不是二选一，但适用场景明显不同：RAG适合频繁更新的知识、私有文档、需要引用溯源的任务；微调适合改变模型的说话风格、领域术语习惯、固定格式输出。实际项目里，混合方案也不少见——先用RAG解决“内容对不对”，再用微调解决“说法像不像”。但在Agent这个语境下，知识获取管道是必选课，因为Agent要操作的业务知识总是在变，你不可能每次业务更新都去重新微调模型。

1.2 “知识获取”本身就该是一条管道

很多人第一次接触RAG，以为就是“开个向量数据库，问一句查一下”。真做起来会发现，从原始文档到模型能用的一段上下文，中间隔着好几个环节：文件采集、格式清洗、语义切分、向量化、索引存储、检索召回、上下文组装。任何一个环节做得糙，最终效果都会塌。

这也是为什么我坚持把它叫“知识获取管道”，而不是“知识库”。管道强调的是流程可控、每段可测。比如切分大了，召回太粗；切分小了，一条完整信息被撕碎；embedding模型和你的文档语言不匹配，召回率直接腰斩；检索到的chunk不加清洗就直接塞给模型，模型很容易淹没在噪声里。

管道思维还能帮你做效果归因。线上问答效果变差了，你是该怀疑新上传的文档，还是该怀疑切分参数，又或者是embedding模型被动过？只要每个环节都有单独的日志和评估指标，问题定位就是分钟级的事。这是我带RAG项目时最深的体会。

给工具链做个简单对比（基于常见实践）：
手动拼接脚本做Demo没问题，但一旦文档量过万、问题类型变多，必须有“阶段划分和指标埋点”。
先用简单链路跑通，再逐步替换某个环节，比如把固定切分换成语义切分，把单路向量检索换成BM25+向量混合检索。
上了Agentic RAG后，管道里会多出“决策”环节，但基础数据层仍然是这条管道。

2. RAG基础链路拆解：索引、检索、生成

2.1 文档处理与切分：chunk_size不是随便填的

所有知识获取管道都从原始文档开始。第一步是把它变成纯文本：PDF要解决扫描版还是文字版，HTML要去掉标签，表格要决定保留原样还是转成Markdown。这一步看起来琐碎，但特别影响后续质量——很多PDF里的表格被简单拼成一行文字后，检索到了也读不出含义。

清洗完，就要切分。常见的切分策略有三种：固定长度切分、按标点/段落的递归切分、语义切分。固定长度简单粗暴，但容易把一句话从中间腰斩；递归切分（RecursiveCharacterTextSplitter）先按段落、再按句子、再按换行去切，尽量让每个chunk在语义上完整；语义切分更进一步，用embedding判断句子之间相似度，在意思变化的地方断开。

chunk_size和chunk_overlap这两个参数，是新手最容易拍脑袋填的地方。我见过有人无脑填256，也有人填2000。关键要看两个约束：一是chunk内部语义要完整，二是多个chunk拼起来的上下文长度不能超过模型窗口。向量维度方面，不管用bge-m3（1024维）还是其他768维模型，chunk大小影响的不是向量维度，而是向量库的规模和检索颗粒度。更关键的是token估算：假设一个512字的中文块，经过主流大模型分词后大约消耗300到450个token，那么8K上下文的窗口，模型最多只能吃下10个chunk左右，再算上给答案留的空间，top_k不能拍脑袋设太高。

我自己的经验是，中文场景从chunk_size=512、chunk_overlap=48~64起步，跑一轮评测集看命中率，再上下调整。如果文档本身是学术论文、产品手册这种段落清晰的，递归切分往往比固定长度好不少；如果是聊天记录这种碎片文本，固定长度反而更省心。

2.2 向量化与索引：embedding选型与向量库

切分完，每个chunk要变成向量。这里有个常见的认知误区：embedding模型不是“随便下载一个英文模型就能用”。中文场景如果你用的是纯英文训练的text-embedding-ada-002（当然这里只是举例，反映问题），对中文长句的语义区分度会差很多。更适合中文的方案包括bge系列、m3e、text2vec、gte等开源模型，或者直接用国产商业模型API。选型时重点看三个指标：检索评测集上的召回率、向量维数（影响存储成本）、CPU/GPU推理延迟。

向量库这边，按部署复杂度从小到大排：

方案	部署形态	适合规模	特点
FAISS	内存索引	单机/原型	轻量，上手快
Chroma	本地文件型	小团队验证	持久化方便
Milvus	分布式服务	生产环境	横向扩展强
Qdrant	独立服务	中等规模	元数据过滤强
Elasticsearch	已有集群扩展	存量ES用户	复用已有设施

选型另一个关键点是metadata。每个chunk在入库时，除了向量和原文，最好还带上来源、章节、更新时间、权限标识等字段。这样检索时既能按时间过滤，也能按来源过滤，还方便做权限隔离。很多人忽略metadata，出了问题只能把整个索引重建，非常被动。

还有一个低级错误必须提醒：建索引和线上查询必须用同一个embedding模型。我见过不止一个项目，建索引时图省事用模型A，线上查询时换了模型B，向量空间完全不一致，检索效果直接崩溃。这个问题在日志里很隐蔽，因为系统不会报错，但hit_rate会掉到不忍直视。

2.3 检索与生成融合：召回、重排、上下文组装

向量化只是给检索做准备，真正的核心动作发生在查询那一刻。一个具体的流程是：把用户query用同一个embedding模型转成向量，然后在向量库里做相似度搜索，常见度量有余弦相似度、内积和欧氏距离。返回的chunk不能直接全塞给模型，要经过几道处理。

第一道是召回，先取一个稍大的候选集合，比如top_k=20，保证“正确答案在里面”的概率。第二道是重排，用一个rerank模型（比如bge-reranker系列，或基于cross-encoder）对候选chunk重新打分，把最相关的几个放最前。重排对效果提升非常明显，因为向量检索的相似度排序未必对应“真正有用的顺序”。

第三道是上下文组装。这里要处理几个细节：

去掉明显重复或冲突的chunk，重复信息会让模型无所适从。
用清晰的模板拼接chunk，比如每条前面加“【资料3】来源：产品手册_第2章”，方便模型引用。
如果chunk数量多，要做一个简单的去噪：过短的、跟query相关性明显偏低的小块可以丢弃。

组装完成后，最终把这个“问题＋资料”模板交给大模型。生成阶段的建议也要写进prompt：只能基于提供的上下文回答，资料里没有的信息要明确说不知道，不能自己编。这一点在4.2还会展开，但本质上属于“上下文工程”的一部分，检索质量和prompt约束缺一不可。

3. 最小可用RAG管道：从0到1跑通全程

3.1 环境准备与依赖选型

下面给的是我自己用着比较顺的一套最小组合，适合在一台普通开发机上把流程跑通：Python 3.10+、一个本地大模型（Ollama拉起的qwen2.5:7b）、一个embedding模型（BAAI/bge-m3）、向量库用FAISS，编排用LangChain的轻量API。不建议上来就引入复杂的RAG框架，因为那样你看不清每一步到底在发生什么。

依赖大致如下，实际装的时候注意版本兼容，以官方文档为准。

pip install langchain langchain-community langchain-text-splitters pip install sentence-transformers faiss-cpu pip install ollama

如果你所在团队不允许直接用第三方编排框架，也可以不用LangChain，直接把加载、切分、embedding、存FAISS、检索、拼接prompt这些步骤写成普通函数。最小实现反而更可控，出问题好排查。

3.2 核心实现：让Agent学会查内部手册

我用一个具体场景来说明：公司内部的IT支持手册，包含设备申请流程、网络故障排查、软件安装规范等几十个文档。目标是做一个Agent，员工问“忘记密码怎么办”，它必须先检索手册，再给出流程，并且标注摘自哪里。

下面是完整的最小实现，前面加载和切分是给“离线构建索引”用的：

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 from langchain.chains import RetrievalQA # 1. 加载并清洗文档（这里是本地txt文件） loader = TextLoader("it_manual.txt", encoding="utf-8") docs = loader.load() # 2. 切分：先按段落，再按句子，中文加了标点分隔 splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=48, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""] ) chunks = splitter.split_documents(docs) # 3. 向量化并写入FAISS索引 embedding = HuggingFaceEmbeddings(model_name="BAAI/bge-m3") vector_store = FAISS.from_documents(chunks, embedding) vector_store.save_local("faiss_index") # 4. 构建检索问答链，QA环节使用本地模型 from langchain_community.llms import Ollama qa = RetrievalQA.from_chain_type( llm=Ollama(model="qwen2.5:7b"), retriever=vector_store.as_retriever(search_kwargs={"k": 4}), chain_type="stuff", ) resp = qa.invoke("员工忘记密码，应该按什么步骤重置？") print(resp["result"])

先说几个注释里没写的坑。第一，HuggingFaceEmbeddings首次运行会下载模型权重，如果是内网环境，记得提前把模型文件拷到本地仓库。第二，FAISS.save_local之后，加载用FAISS.load_local，同时传embedding对象，否则取向量时没人帮你做query向量化。第三，Ollama要在后台先拉好模型并且把服务跑起来，url默认是localhost:11434，不需要额外配置。

这个chain_type="stuff"的意思是：把检索到的chunk直接拼成一个长文本塞进prompt。好处是简单，缺点是chunk一多容易超窗口，所以k先别调太大。等后面需要处理更多资料时，再换成map_reduce或refine策略。

3.3 效果评估与参数调优：先定义“什么是答得好”

很多团队跑通上面的代码，看到能回答就开始欢呼。我通常建议先别高兴，准备一套评测问题集再说。RAG最核心的评估指标叫hit_rate（命中率），它衡量的是：对于一批有标准答案的问题，检索结果top_k里有没有包含“正确答案所在的chunk”。

可以这么算：假设你有20个测试问题，每个问题都人工标注了它在文档中的正确答案段落ID（chunk_id）。跑一次检索，看top_k返回的chunk_id列表里是否包含标注的chunk_id。如果20个问题里有16个的答案被召回，那么hit_rate=80%。别小看这个数，50%和80%的差距，往往就是召回策略和切分参数的差距。

基于评测集，我一般这样调参：

提高hit_rate：加大chunk_overlap、把切分策略改成递归优先，或换成更合适中文领域的embedding模型。
降低噪声：如果top_k返回一堆无关片段，检查chunk_size是不是太小，以及embedding模型是否和文档领域匹配。
回答不准确：先看hit_rate是不是过了60%~70%，如果召回本身很差，调生成侧的prompt几乎没有意义。
回答太长/超窗口：降低k，或改成“先重排再取前3”。

4. 常见问题排查与避坑实录

4.1 检索空召回或命中率低，先查这五个地方

检索命中低是RAG项目里出现频率最高的问题，而且八成不是向量库的锅。我按概率从高到低列出排查顺序：

切分是否合理。整段怼进去，检索出来一大块，看似相关，实际证据被淹没；切太碎，问题里的关键实体被切开，检索更找不到。
query与文档的语言表达是否一致。用户口语问“密码丢了咋办”，文档里写的是“重置密码申请流程”，如果只用向量相似度，可能反而匹配不上。解决方式是做query改写，或者同时做关键词命中（BM25）。
embedding模型是否匹配。直接用英文模型处理中文，或是用通用模型处理高度垂直的法律/医疗文本，都会导致语义偏差。
top_k太小。有些问题答案分散在多个chunk里，只取2~3个很容易漏。
索引数据本身脏。重复文档、旧版本覆盖新版本、乱码内容，都会把正确的chunk挤下去。

排查时可以临时打印检索出来的chunk原文，手工比对“既然你没召回到正确答案，那到底召回到了什么”，这个动作能快速告诉你问题出在切分、embedding还是query处理上。

4.2 生成侧幻觉严重，prompt和管道都要管

RAG项目里的“幻觉”并不总是模型的错。如果你检索到的资料里根本没提“审批需要3天”，但模型还是回答了3天，那问题十有八九出在prompt没有把“只允许基于资料回答”写死，或者上下文里夹带了不少无关信息，模型自己“脑补”了出来。

一个比较稳的prompt模板大概是这样的：

你是一个知识库问答助手。你需要严格基于下方提供的资料片段回答问题。 规则： 1. 只在资料片段能支撑答案时回答。 2. 资料中没有的信息，直接说“资料中未找到相关内容”，不要猜测。 3. 回答末尾列出参考来源编号。 资料片段： 【资料1】来源：it_manual.txt_第3章 （内容...） 【资料2】来源：it_manual.txt_第8章 （内容...） 用户问题：{question}

另外，生成参数建议把temperature调低一些，0.1~0.3之间。对一些“必须按流程来”的任务，模型创造欲太强不是好事。还有一个很容易被忽略的点：如果多个chunk里同时存在互相矛盾的信息，模型也很容易混乱。这种情况不能只靠prompt约束，要在检索阶段就通过metadata过滤掉过期版本。

4.3 知识更新、去重与多知识库管理

上线之后遇到的麻烦往往是知识维护。业务文档一个月更新三次，之前的索引还留在向量库里，检索时旧文档的chunk会和新文档打架。可靠的思路是给每个索引加版本号或更新时间字段，更新时对同一来源的旧chunk做软删除，而不是不断叠加。

多知识库管理也需要提前想好：按部门建多个索引，query进入前先路由到对应知识库，或者用一个索引但靠metadata过滤。比如“市场部员工手册”和“研发部应急预案”放在一个向量库没问题，但检索时用filter字段限定部门范围，效果通常比全库搜要好很多。

还有一个很多人会忽略的坑：权限隔离。如果知识库里有些文档只有部分人能看到，向量库本身不做权限控制。开放RAG服务接口时，一定要在检索环节把用户权限传进去做metadata过滤，否则很容易出现越权检索。这个看起来是工程问题，但出一次就是事故。

5. 从基础RAG到Agentic RAG：进阶方向与实际建议

5.1 把“检索”变成一个决策动作

基础RAG的流程是一条固定的流水线：query进来，检索，生成。Agentic RAG最大的不同，是把“检索”本身变成Agent可以决策的动作。Agent不再每次都检索，而是先判断这个问题自己能不能回答；也不能只检索一次，它可能先模糊搜一下，再根据返回的chunk判断是继续检索细化，还是换一个检索工具，或者干脆调用一个业务API拿数据。

这一转变听起来很美，但我对团队的劝告一直是：不要为了概念而概念。Agentic RAG适合两类场景：一是问题链路特别长的多跳问答（比如“上个季度华南区哪款产品退货率最高”），中间需要聚合多次查询结果；二是检索工具很多、需要自动选路的时候（比如既有API又有文档库又有表格）。如果只是一问一答式的知识库问答，固定管道反而更快、更可控。