很多人在搭 AI Agent 时会遇到同一个困惑：模型明明很能聊，一碰到自己业务里的具体问题就开始胡说八道。原因很简单，大模型的“记忆”是训练时固化的，它记不住你的私有文档，也拿不到实时更新的业务数据。这个系列前面几篇聊了 Agent 的规划、记忆和工具调用，这一篇我聚焦 Agent 体系里最容易被低估的一个环节——知识获取管道，也就是 RAG 的基础实现。所谓 RAG，全称 Retrieval-Augmented Generation，检索增强生成，本质上就是给模型配一个随时可查的档案库，让它回答问题时先翻资料再开口。这篇文章面向正在自己动手搭 Agent、被知识库命中率不高和数据割裂折磨的朋友，我会把 RAG 这条管道的核心环节、参数选择和常见坑都过一遍，尽量做到看完了能直接照着落地。
1. 知识获取管道在智能体里的位置
1.1 为什么智能体不能只靠模型自带的“记忆”
把大模型想象成一个阅读量很大、但记忆有截止日期的员工：他读书的时候确实知道很多通用常识，但公司内部的上架规范、某款产品的具体参数、上周刚更新的售后流程，他不可能凭空知道。这不是模型能力的问题，而是信息时效和私有性的问题。模型的参数是训练完成的瞬间冻结的，之后发生的任何变化，模型本身都不知道，唯一能改变这个状态的办法，是让它在推理阶段从外部拿信息。
所以在一个完整的 Agent 系统里，知识获取管道承担的角色，就是“让模型在正确的时间拿到正确的资料”。它不是把一堆文档直接塞给模型，而是要做索引、检索、筛选、组织，最后把最相关的内容拼进上下文里，让模型基于这些事实去推理和回答。没有这条管道的 Agent，本质上只是一个包装过的语言模型接口，很多业务场景根本没法用。
这里有个常见的误区：有人觉得既然模型上下文窗口已经很大了，把全部文档都塞进去不就行了。窗口大不等于可以乱堆，上下文太长会稀释注意力，让模型分不清重点，而且每次都全量塞入的成本和时间都不可接受。RAG 的核心价值恰恰在这里——按需取用，只在回答问题时拉取那几段真正相关的内容。
1.2 RAG 与其它知识接入方式的取舍
知识获取管道不是只有 RAG 一种实现，至少还有微调和缓存两种路径可选，但它们解决的问题完全不同。微调改变的是模型本身的权重，适合让模型学习某种固定的风格、格式或者特定的领域知识结构，但每次数据更新都要重新训练，成本高、周期长，不适合频繁变化的内容。缓存方案适合那些高频且答案固定的问题，比如“退货政策是什么”，直接命中缓存返回结果，省时省力，但对新问题没有生成能力。
RAG 的不可替代性在于它把“存储”和“推理”解耦了。文档更新时只需要重新跑一遍索引，模型本身不用动；回答时可以引用原文片段，方便溯源和修正。它在知识获取管道里的地位，就像一个总能把最新版文件递到你手边的资料员。当然它不是银弹，上下文里的资料如果没有被正确检索到，模型再聪明也只能干瞪眼。这也是我把它称为管道而不是组件的原因——RAG 是一条完整的链路，任何一个环节掉了链子，整个回答的质量都会崩。
2. RAG 核心链路拆解：索引、检索、生成
2.1 索引阶段：切分、向量化、存储
RAG 的第一步是给文档建立索引，这个阶段决定了后续检索的上限。常见做法是：读入文档 → 切成文本块 → 用 embedding 模型把每块转成向量 → 存入向量数据库。听起来简单，但每一步都有讲究。
先说切分。我见过很多人直接把整个 PDF 当成一块塞进去，这样检索出来的“相关段落”往往是一整篇大杂烩，模型根本无法定位答案。反过来切得太碎也不行，几百条片段互相之间丢失了上下文，检索出来也读不懂。比较稳妥的做法是使用递归字符切分器，按照\n\n、\n、句号、逗号这样的优先级逐层往下拆，保证尽量把完整段落或完整句子保留在一起。块大小我常用 512 到 800 字之间，重叠区设 64 到 128 字。512 这个值对中文比较友好，一段话大概覆盖几百 token，既不至于把相关语义切散，也不至于让冗余信息污染结果。
然后是向量化。选择 embedding 模型时，优先看它在目标语言上的表现，中文场景下直接用英文为训练主力的模型会吃亏，建议选对中文支持较好的模型。一个容易被忽略的点是：embedding 模型一旦选定，后期不要频繁更换，因为换模型意味着向量空间变了，旧索引全部作废，必须重建。存储方面，向量数据库的选择很多，简单项目可以直接用 FAISS 或者 Chroma，量大了再考虑 Milvus、PGVector 或者 ES 的向量插件。不用一上来就上重型武器，我见过很多项目连数据量都没有就急着搭集群，完全是浪费精力。
2.2 检索阶段：向量检索和关键词检索的配合
索引建好之后，查询时把用户的提问也转成向量，然后到库里找最相似的前 K 条，这就是最基本的向量检索。向量检索擅长捕捉语义相似：用户问“产品怎么退换货”，即使文档里没有出现“退换货”三个字，只要存在语义接近的描述，也能被找到。但向量检索有个很实际的毛病——它对专有名词和精确 ID 极不友好，用户问“SN 码在哪里”，向量会把“码”和“哪里”当语义重点，反而忽略 SN 这个关键限定词。
所以成熟一点的 RAG 管道，都会做混合检索：向量检索召回语义相似的，关键词检索（BM25 或全文索引）召回精确匹配的，然后把两路结果合并去重，再统一评分。这套组合的思路其实和搜索引擎一样——语义召回兜底长尾表达，关键词召回保证精确命中。个人项目里如果不想额外引入 Lucene 这类索引库，可以考虑在 SQLite 里用 FTS5 做关键词检索，配合向量库一起用，效果比单路检索好很多。
检索质量的好坏，业界常用 hit rate（命中率）来衡量：正确相关的那条文档是否出现在检索结果的前 K 条里。我在实践中有一条经验：如果 Top-5 里都找不到正确答案，就别指望大模型能脑补出来，这时候要排查的是切分和 embedding 的问题，而不是生成端的问题。这个指标在设计评测集的时候就要预留，最好准备几十条真实问题，每条标注对应的文档位置，每次改动完管道就跑去跑一遍，用数据说话。
2.3 生成阶段：上下文组装与提示词设计
检索完成的最后一步，是把命中的片段拼进提示词，交给大模型生成回答。这里有一个很多人容易忽略的细节：原始片段不能直接原样塞进去，最好做一层格式化处理。引用内容可以加上“以下是参考材料”这样的边界标记，让模型知道哪些是事实来源、哪些是标准回答，方便它区分和引用。对模型来说，清晰的上下文结构和指令说明会直接影响输出质量。
提示词里除了放资料和问题，还应该明确两件事：一是“如果资料里没有答案，必须如实说明，不要编造”，这一点是抑制幻觉的关键；二是“回答中尽量引用提供的原文信息”，确保输出的每个结论都能回溯到资料库。很多人以为只要把资料塞进去，模型就会乖乖用，这是不对的，不写约束，模型经常会把资料里没有的东西也一本正经地讲出来。
上下文组装还有个实际约束：窗口和成本。每次问答都把所有相关资料塞进去是不现实的，我一般设置 Top-K 为 4 到 6，超过这个数量对回答质量的提升非常有限，反而增加 token 消耗和响应延迟。在这个环节还可以加一道 Rerank（重排）：先粗召回几十条，再用一个更精准的排序模型挑出最合适的几条，能显著提升最终命中质量。如果项目预算有限，也可以不做 Rerank，但至少要在提示词里按相似度降序排列好资料的顺序，模型会习惯性地更关注前面的内容。
3. 实操：一条最小可用的 RAG 管道
3.1 工具选型与两种实现路径
纸上谈兵说完，我们直接动手。先说工具选型。目前搭建 RAG 管道的路径大致分两类：一类用 LangChain、LlamaIndex 这类框架，把加载、切分、向量化、检索、生成串成现成的组件；另一类不依赖框架，直接用 API 手动实现各个环节。我的建议是第一次尝试先用框架快速跑通，但一定要理解每个组件背后的逻辑，否则出了问题只能瞎猜。
下面以 LangChain 为例，配合 OpenAI 的 embedding 和 chat 模型，跑一条最小可用的中文 RAG 管道。为什么用这个组合？教程多、资料全、出错容易排查，适合建立对管道的直觉。生产环境可以根据预算和合规要求换成本地模型，但逻辑是一样的。先安装依赖：
pip install langchain langchain-community langchain-openai chromadb pypdf3.2 建立索引：从 PDF 到向量库
我拿一份常见的企业操作手册 PDF 作为例子。第一步把 PDF 加载进来，然后切块，然后向量化，然后存进 Chroma。代码如下：
from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import OpenAIEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载 PDF loader = PyPDFLoader("./操作手册.pdf") documents = loader.load() # 2. 递归字符切分 text_splitter = RecursiveCharacterTextSplitter( chunk_size=512, # 每块最大字符数 chunk_overlap=64, # 相邻块重叠字符数 separators=["\n\n", "\n", "。", "！", "？", "，", " ", ""], ) chunks = text_splitter.split_documents(documents) # 3. 向量化并写入 Chroma 本地库 embeddings = OpenAIEmbeddings(model="text-embedding-3-small") vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_db", # 索引持久化目录 ) print(f"已索引 {len(chunks)} 个文本块")这段代码里最值得解释的是切分器的 separators 顺序，它决定了文本优先按什么层级断开。我把\n\n放在最前面，是为了尽量保留完整段落；随后才是\n和句号。如果一开始就把句号当最高优先级，段落里的每个句子都会被拆散，检索出的片段上下文严重缺失。chunk_overlap 的作用是保留切分边界的语义衔接，防止关键信息恰好落在切口上，比如某句话被从中间劈开，导致前后都读不通。
3.3 检索与回答：拼上下文、设约束
索引建好后，把用户问题转为查询，取回 Top-K 块，再拼进提示词。下面是一段完整的问答代码：
from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate # 4. 创建检索器 retriever = vectorstore.as_retriever( search_kwargs={"k": 4} ) # 5. 组装提示词 prompt = ChatPromptTemplate.from_template( """你是一个企业知识助手。请优先根据下面提供的资料回答用户问题。 如果资料中没有相关信息，请直接说明“资料中未找到相关内容”，不要编造。 参考资料： {context} 用户问题：{question} 回答：""" ) # 6. 执行问答 def ask(question: str): docs = retriever.invoke(question) context = "\n\n".join([f"[片段 {i+1}] {d.page_content}" for i, d in enumerate(docs)]) chain = prompt | ChatOpenAI(model="gpt-4o-mini", temperature=0) answer = chain.invoke({"context": context, "question": question}) return answer.content # 示例 print(ask("产品的外包装尺寸是多少？"))有几个细节值得认真对待。temperature 我设置成 0，在知识问答场景里不需要模型发挥创造性，稳定的输出比花哨的表达有价值得多。提示词里“没有相关信息就说明”这段约束，是幻觉控制的第一道防线，它直接告诉模型：资料是你的唯一事实来源。给片段编号也有实际用处，模型在回答时可以引用片段编号，方便人工溯源。
3.4 参数对照与调参优先级
动手的时候，很多人会问这些参数到底怎么设。我给一张常用对照表，大家可以根据自己的数据情况微调：
| 参数 | 建议值 | 作用 | 调节优先级 |
|---|---|---|---|
| chunk_size | 512-800（字符） | 控制语义块的粒度 | 高 |
| chunk_overlap | 64-128 | 防止关键信息跨界丢失 | 高 |
| k（召回条数） | 4-6 | 决定进入上下文的片段数 | 中 |
| embedding 模型 | 通用型即可 | 决定语义表达效果 | 中（后期勿换） |
| temperature | 0-0.3 | 控制输出随机性 | 低 |
| Rerank 模型 | 按需引入 | 二次筛选精排结果 | 低（预算充足再上） |
从我的经验看，大部分命中率问题都出在 chunk_size 和检索条件上，先调这两个，再考虑模型层面的升级。召回条数 k 也不是越大越好，k 过大会把不相关的内容也带进上下文，反而干扰判断。有一次我把 k 从 4 调到 10，准确率不仅没升，还因为噪音变多导致模型开始从无关片段里找答案，这就是典型的过度召回反效果。
4. 从“能用”到“好用”：命中率、上下文与智能体编排
4.1 检索命中率上不去，先查这三件事
基础管道跑通之后，你很快会面临一个真问题：几十个测试问题里总有几条检索不到正确答案。我排查命中率低的情况，几乎都是三个原因。第一个是切分粒度不对，这是最常见的问题，某些文档的关键信息横跨多个块，切分后完整内容被拆成碎片，向量检索只能命中其中一半，导致信息残缺；第二个是提问表达和文档表达差异过大，用户习惯口语化提问，而文档写得非常正式，纯向量检索有时无法跨越这个距离，这种情况下混合检索能显著提升命中率；第三个是 embedding 模型的语义捕捉能力不够，同一个词组在不同语境下的含义，层次不够深的模型分辨不出来。
定位是哪一类问题，有个很直接的办法：把检索回来的原始片段打印出来看一眼。如果返回内容和问题有明显语义关联，但缺少关键细节，是切分问题；如果返回内容完全偏了，是检索策略问题；如果返回内容看起来都对，但模型还是答错，那就得看生成端的提示词和模型选型。别一上来就怀疑大模型，RAG 的绝大多数质量问题，根源都在检索端，也就是在“有没有把正确答案拿出来”这一步。
4.2 Agentic RAG：让模型自己决定查什么
前面介绍的是单次检索的 RAG，管道是直线型的：问题进来、检索一次、拼上下文、输出回答。这种形式解决单点问题没问题，但一旦用户的提问涉及多跳推理，比如“最近涨价的那个品类的售后政策是什么”，需要先定位哪个品类涨价了、再查这个品类的售后政策，单次检索就会顾此失彼。Agentic RAG 的思路，是把检索能力接入 Agent 的工具列表，让模型自己判断需要查几次、用什么样的查询词去查。
实际落地的时候，我倾向于让 Agent 在执行中维护一个“查询计划”：先拆解问题成子任务，每执行一次检索就检查一遍结果是否足够回答问题，不够就继续追加查询。这种行为模式的代价是响应变慢，但换来了对复杂问题更可靠的回答。有一种折中方案是先用单次 RAG 快速回答，同时让模型给一个“置信度”判断，如果置信度低再自动转入多轮检索。这种在有真实业务压力时非常实用。Skill 与 RAG 的结合也有类似的逻辑：RAG 负责非结构化文档的理解，Skill 负责调用数据库、API 做结构化查询，两者组合起来，智能体才能真正覆盖业务场景里混合查询的需求。
4.3 知识割裂问题：多个文档源如何统一
RAG 落地一段时间后，你会开始碰到数据源变多带来的“知识割裂”问题。比如公司文档既有产品手册、又有售后规范、还有同事沉淀的零散笔记，三个来源对同一件事的说法可能不一致，或者各自只管自己的一部分。这时候只管把文档丢进向量库，会发现两个毛病：一是不同来源的相似内容检索时互相打架，难以去重；二是用户问一个跨领域问题时，检索结果可能只来自某一个源，另一个源里的关键信息被淹没了。
我的处理经验是层层治理。首先在索引阶段就给每个文档块打上元数据标签，比如来源、更新时间、文档类型，这样检索时可以加权过滤；其次在检索阶段引入混合检索后，再做一轮来源层面的多样性约束，尽量让结果覆盖不同的文档源，而不是全被同一份文档霸占；最后如果是长期负责的知识库，可以考虑用图结构组织实体和概念之间的关系，这种演进路线常被叫做 GraphRAG，能弥补纯向量索引缺乏全局关联的短板。但说实话，大部分团队连前两步都还没做好，先别急着上知识图谱。
5. 常见问题与排查实录
5.1 症状、原因与解法速查表
我把实际操作中遇到的高频问题整理成一张表，方便大家对照排查：
| 症状 | 可能原因 | 排查方法 | 解决办法 |
|---|---|---|---|
| 检索结果相关但答案不准 | 上下文关键信息缺失 | 打印返回片段查看 | 调整切分块与重叠区 |
| 检索结果完全不相关 | 向量索引未正确切换模型 | 检查 embedding 版本 | 重建索引，统一模型 |
| 精确 ID 查不到 | 纯向量检索忽略精确词 | 打印相似度得分 | 接 BM25 混合检索 |
| 回答编造资料外内容 | 提示词缺少约束 | 检查 prompt 指令 | 明确“无资料即不知道” |
| 多个来源互相矛盾 | 缺少来源优先级策略 | 查看引用来源标签 | 按文档类型加权，加权威源优先 |
| 同一问题每次结果不同 | 温度设置过高 | 检查生成参数 | 将 temperature 调低 |
这张表基本覆盖了从“跑通”到“可用”之间会遇到的主要障碍。我在实际排查中有一个习惯：先用一条已知正确答案的问题做回归测试，把检索片段、相似度分数、模型输出三级日志全部打印出来，这样做一次，问题在哪个环节基本就一目了然了。多数时候问题并不是出在最引人注意的模型身上，而是出在那些不起眼的中间环节。
5.2 我踩过的一些细节坑
最后分享几个很具体、但几乎不会写在教程里的坑。
第一个是换 embedding 模型后忘记重建索引。有个阶段我觉得某个检索效果不好，直接把 embedding 配置换成了新模型，然后继续用旧索引查询，结果命中率暴跌。原理很简单：新旧模型的向量空间完全不一致，旧索引里的向量表达已经失效。换模型不是改个配置的事，必须全量重新跑一遍索引。
第二个是切分器把中文排比句拆得七零八落。初期我的 separators 里没有放顿号，遇到一段“包括但不限于：防潮、防尘、防震、防腐蚀”时，切分器把整段当成一个块，检索长尾问题时会漏掉细节。之后我在分隔符列表里调整了顺序，中文标点的优先级需要根据文档风格做适配。
第三个是上下文顺序影响模型关注度。模型对上下文开头的部分注意力更强，如果一个问题需要多个片段，我会按相关性从高到低排列片段顺序，把最相关的放在最前面。一开始我按数据库返回顺序直接拼接，等于把最优的答案放在最后，模型注意力分配不均匀，回答效果明显打折。
还有一个容易被忽略的点：PDF 加载时经常出现表格被解析变形的问题。比如一张规格表在 PDF 里是行列整齐的，解析出来可能变成一行行文本，切分后表格上下文彻底丢失。这种场景我一般会先用工具做一次表格抽取，手动清洗后再进索引，不能指望通用加载器直接给出一份堪用的数据。数据进管道的那一刻，输入质量就已经决定了大模型的回答上限。
6. 结尾的话
RAG 说到底是“把资料递给模型之前，先帮它把资料挑好”的艺术。这条管道看起来只有索引、检索、生成三段，但每一段里都有足够多的细节值得打磨。我自己搭过不少 Agent 项目，最大的体会是：不要急着把框架越整越复杂，先把一条最简单的链路跑通，然后用评测数据找出瓶颈，再逐步加混合检索、Rerank、多轮决策这些进阶能力。知识获取管道的核心指标不是 tps，而是那一个朴实无华的 hit rate——它上去了，后面生成端的事情就好办了。如果你正在为检索结果不理想发愁，建议先打印一条查询的完整链路看看，大概率能发现答案就藏在那些你认为“没必要”的小细节里。
