RAG知识获取管道：让Agent学会先查资料再回答

前几天有个朋友拿着他搭好的 Agent 来找我，说模型总是对着公司内部的流程文档一本正经地胡说八道——问他财务报销要走什么流程，它能编出一套“提交申请表、领导审批、财务打款”，但实际流程里还有预算预审和发票校验两道关卡，全被它漏掉了。这不是模型不够聪明，而是它压根没见过你们公司的文档。大模型的参数里装的是互联网上的公共知识，装不下你私有业务里的那些细则。这时候，RAG（Retrieval-Augmented Generation，检索增强生成）就派上了用场。作为 AI Agent 系列第四篇，我想把“知识获取管道”这个主题讲透——我们如何用 RAG 给 Agent 接上一条通往外部知识库的管道，让它在生成答案之前，先学会“查资料”。

这篇文章适合正在从零搭建 Agent、又苦于模型不懂私有知识的开发者，也适合那些听说过 RAG 但还没动手实践的读者。我会从最基础的链路原理讲到检索质量的调优，再到 Agentic RAG 的集成思路，最后附上实战里踩过的坑和排查清单。全程用我自己的项目语境来说，不用教科书语言。

1. 为什么 Agent 会“胡言乱语”：知识获取管道的必要性

1.1 大模型的知识边界与知识割裂问题

所有的大语言模型，本质上都只是一个“预测下一段文本”的概率系统。训练阶段它会消化互联网、书籍、论文里的公开语料，然后把这些知识的统计规律压缩进几十亿甚至上千亿个参数里。这个压缩过程有两个限制：一是知识有截止日期，模型永远不知道训练集之后发生的新事情；二是权重里只能保存高频、共性、结构化的模式，那些长尾的、私有的、高度动态的内容会被无差别地模糊化。

我跟很多开发者聊的时候，他们最常犯的误解是“我本地部署一个开源模型，它就能学会我公司的知识”。不行。本地部署解决的是数据私密性和推理成本问题，解决不了知识边界问题。你公司的产品手册、自查清单、客服话术、设备参数，这些内容在网上根本查不到，也不可能凭空出现在训练语料里。想让模型回答这些私有领域的问题，就必须在推理时给它“喂”相关内容，这就是“知识割裂”的核心矛盾——模型有强大的语言能力，但它没有你需要的“事实”。

Agent 比单轮问答更依赖知识管道，原因在于 Agent 是要动手做事的。它要写邮件、查库存、生成报表、报修设备。每个动作背后都依赖准确的情境知识。一个 Agent 如果只知道“邮件要礼貌”，但不知道对这家客户该用哪种称呼、最近有没有欠款纠纷，那它写出来的邮件大概率不能直接用。所以，知识获取管道不是可有可无的附属组件，而是 Agent 能不能在真实业务里落地的根基。

1.2 RAG 的本质：把检索能力注入生成过程

RAG 的思路非常直白：不修改模型参数，而是在模型生成之前，先从你的知识库里检索出与问题相关的文档片段，把这些片段拼进 Prompt，让模型基于这些“参考答案”来回答。这就像是给学生换了个考试方式——不再是闭卷全靠背，而是允许开卷，先翻书再答题。

一条最基本的 RAG 管道包含三块：知识库、检索器、生成器。知识库存放你已经清洗好的业务文档，检索器负责在知识库里找到最相关的若干片段，生成器就是你的大模型，它把“用户问题 + 检索到的片段”糅合在一起，生成最终回答。这三个字说起来简单，但工程上的细节极其多。比如知识库怎么切片、检索器怎么打分、检索结果怎么过滤、片段多了会不会把模型冲晕、少了会不会回答不全，这些处理不好，RAG 就退化成“花哨的倒垃圾工具”。

我在后面几章会按一条最小可用的管道一步步展开。这里先把逻辑讲清楚：RAG 的价值不在于让模型“记住”知识，而在于让模型在需要的时候“找到”知识。这是一种把外部记忆动态挂载到推理过程的方案，天然适合 Agent 这种需要实时查证、多步决策的场景。

1.3 RAG 与微调、长上下文的选型逻辑

总有朋友问：那我是不是直接微调一个模型，把所有文档塞进去，效果更好？我的回答通常分情况。微调（Fine-tuning）适合学习某种风格、输出格式或固定的行为范式，比如让模型学会按你们公司的工单模板输出。微调不适合做知识库，因为它需要大量标注数据、训练成本高，而且每次文档更新都要重新训练，更可怕的是模型会把没见过的内容“一本正经地编”出来，微调并不能像检索那样轻易追溯到出处。

长上下文是另一个诱人的方向。现在的模型动不动就支持 128K、200K token，看起来你可以把整本手册塞进 Prompt。但实际用下来有两个问题：一是成本急剧上升，每次都把所有文档传一遍，Token 费用感人；二是“中间遗忘”问题——模型对长文本中间的注意力分配不均匀，你的答案很可能埋在几千 token 的茫茫文档里，模型会抓不住重点。RAG 相当于先做一遍“注意力预筛”，把最重要的内容挑出来，再让模型聚焦阅读，精准度和成本都更可控。

下面的表格是我经常用来给团队决策参考的对比：

在我自己的项目里，常见做法是“RAG 为主，微调为辅”。Agent 的行为规范（比如回复风格、必须用表格输出）用微调搞定，具体的业务事实一律走 RAG 管道。这样既能保持模型行为的稳定性，又能让知识随文档版本实时变化。

2. 搭建一条最小可用的 RAG 管道：五步流水线实操

2.1 文档加载与清洗：别让垃圾进管道

很多教程会直接从“切分、向量化、检索”讲起，但我在项目里最大的体会是文档清洗才是成败关键。知识库里的原始文档格式五花八门：PDF 有扫描版、Word 有页眉页脚、HTML 有导航标签、Excel 里还可能藏着公式。你如果直接把这些内容扔进去，向量库里会塞满噪音，检索出来的东西自然不靠谱。

第一步，根据文档类型选择合适的加载器。PDF 类我会先试 PyMuPDF 或 pdfplumber，扫描版要接 OCR（PaddleOCR 这类开源工具就够了）；Word 和 HTML 用 LangChain 里的加载器或者自己用 BeautifulSoup 提取正文，最重要的是去掉页眉页脚、导航链接和脚本片段。清洗阶段我会写几个正则表达式，把多余的空格、换行、以及“仅供内部使用”这类页脚信息统一处理掉。还有一个经常踩的坑：PDF 里表格数据被还原成一堆散乱文本，检索时根本拼不回来。这个要么把表格结构化（把表格转成 Markdown 表格），要么在切分时设置“表格区块优先级”。

我建议把清洗后的文档统一转成 Markdown 或纯文本，保留必要的标题层级（#、##）和列表结构。这样后面做结构化切分会极其方便。

2.2 切分策略：chunk size 与 overlap 的选择逻辑

切分（Chunking）是整个管道里最容易被低估的环节。切太小，一块内容装不下一句完整的意思，检索到的信息残缺；切太大，一块内容包含多个主题，语义会被稀释，向量表示变得模糊。我做过一次实验：同一份技术手册，按 200 字切分时检索 Top5 的命中率大约 62%，按 512 字切分时能到 78%，按 2000 字切分时反而掉到了 55%——因为太大的片段里只有一两句是用户问的，向量被其余无关内容拖偏了。

实际操作中，固定的字符切分不是最优解，我更喜欢“按文档结构切分”。比如用 MarkdownHeaderTextSplitter，根据标题和段落生成 chunk，每个 chunk 带上它的标题前缀，这样上下文天然完整。如果没有明显的结构，就用递归字符切分，设置 chunk_size=500、chunk_overlap=50 起步，再根据测试效果调整。chunk_overlap 的作用是避免两个相邻块把一段完整信息截断在边界上。50 到 100 字的重叠通常够用。

这里有一个细节：chunk 里最好带上一个“文档来源”的元数据字段。比如{"source": "采购管理制度.pdf", "page": 3}。后面做引用溯源、权限过滤、按来源排除某些文档时，没有这个字段你会非常痛苦。我见过有人把知识库建完才发现没法做部门隔离，只能全部重建。

2.3 向量化：Embedding 模型的选择与维度陷阱

切好的文本块要变成向量。向量就是一组浮点数，能表示文本的“语义坐标”。语义相近的句子，在向量空间里离得也近。Embedding 模型的选择直接决定了检索的底线。

以中文业务场景为例，我常用的几个模型是：

选择 Embedding 模型时最容易忽略的是“领域适配”。通用模型对专业术语、品牌名、缩写词往往编码能力不强。比如“RAG”这个词，在通用模型里可能会被拆成“r、a、g”三个字母的模糊向量，导致检索不到知识库里的“检索增强生成”。如果你的业务领域很垂直，比如医疗、法律、化工，强烈建议先在真实文档上用小样本对比几个模型，而不是盲目跟风。

另外维度不是越高越好。高维度向量计算更慢，也需要更大的存储空间，而且在数据量不够时反而容易过拟合。采用 OpenAI 的嵌入，如果你只是做普通业务知识库，维度降到 512 经常已经足够。维度变换不会有明显的精度损失，但大模型平台的 API 费用和检索延迟会直观地降下来。

2.4 存储与索引：向量数据库的选型对比

向量数据存哪？这一步的选择很影响后续运维。我的建议是：小项目、个人跑通 demo，直接用Chroma或FAISS，前者足够简单，后者快且免费；团队项目或生产环境，考虑Qdrant、Milvus或pgvector。其中pgvector特别适合你已经用了 PostgreSQL 的团队，直接把向量和业务数据放一起，少一个中间件。

向量数据库的核心技术是 ANN（近似最近邻）索引。常见的 HNSW 算法有两个参数：M（每个节点的连边数）和efConstruction（建索引时的搜索范围）。M 越大，召回率越高，但索引越大、查询越慢；efConstruction 越大，建索引越准，但耗时越长。实战中我会建议从 M=16、efConstruction=200 出发，然后针对你自己的知识库规模测试。几万条 chunk 和几百万条 chunk 的参数差别非常大，不能照搬默认值。

选型时还要看过滤能力。Agent 场景往往需要“只能访问某个部门的文档”或者“按发布时间过滤”。这时候向量库是否支持 metadata 过滤就很关键。Chroma 能做，但复杂条件过滤性能一般；Qdrant 的 payload 索引做得比较完善，Milvus 也支持标量+向量混合查询。记得先想清楚你的权限模型，再选数据库，不然后患无穷。

2.5 生成链路：Prompt 模板与上下文组装

管道前面的辛苦，最后都要汇聚到生成这一步。检索到的 chunk 不能直接一股脑塞给模型，你需要设计一个结构清晰的 Prompt 模板。我常用的模板长这样：

你是业务助理，请严格基于下面提供的“参考资料”回答用户问题。 要求： 1. 如果参考资料中有答案，请优先引用，并标注来源编号，如 [1][2]。 2. 如果参考资料中没有答案，直接说“根据现有文档无法回答”，不要编造。 3. 回答时用中文，条理清晰。 参考资料： [1] 来源：采购管理制度.pdf，第3页 内容：... [2] 来源：费用报销规范.pdf，第7页 内容：... 用户问题：...

这里最关键的指令是“没有答案就直接说不知道”。很多 RAG 项目效果不好，不是因为检索不到，而是模型在检索到的材料不充分时，依然会“自信地”动用参数记忆去补全，产生幻觉。你必须在 Prompt 层面强制切断这个路径。

组装上下文时要注意 Token 预算。假设模型上下文窗口是 8K，我会把系统提示词 + 用户消息 + 历史对话控制在 3K 以内，给检索到的 chunks 留出 4K 左右，最后留 1K 给模型输出。如果超过了，先把排序靠后的 chunk 截断，再考虑压缩历史对话。否则检索的 chunk 再准，模型也读不完，前面的工作白费。

3. 检索质量才是真正的分水岭：召回、重排与混合检索

3.1 为什么 top-k 和 score 阈值不能拍脑袋

新手做 RAG 最喜欢把top_k设成 4，因为教程里写 4。但 4 到底够不够，取决于你的知识库质量和业务问题。我遇到过很多次：正确答案恰好排在第 5、第 6 位，而用户问的是“某型号设备的保修期是多少”，前 4 个 chunk 全是设备简介，没有保修条款。这种情况下你必须提高召回数量，然后再靠重排把真正相关的顶上来。

score阈值同样重要。向量检索返回的相似度分数，有时候 0.82 才是相关的，有时候 0.6 就已经很相关——这取决于 Embedding 模型和知识库内容的一致性。我的做法是：先收集一批真实用户问题，配上标准答案所在文档，跑检索，画出分数分布。看看“相关文档”和“无关文档”的分数有没有明显的分界，然后在分界点附近选阈值。

当然，这只适用于你有一个比较完整的测试集。前期没有测试集时，先用一个宽松阈值（比如 0.3）保证召回，再做重排，防止因为阈值太高把正确答案挡在门外。

3.2 混合检索：BM25 + 向量的取舍与融合

纯向量检索有一个短板：对精确词、缩写、编号的匹配不敏感。举个例子，用户问“GL-280A 型号的防护等级”，向量检索可能会找到很多关于“防护等级”的文本，却错过了含有“GL-280A”的精确文档——因为这个词在向量的语义空间里辨识度有限。这种问题在工业设备、产品型号、法律法规场景中尤其常见。

解决办法是混合检索：一边用 BM25 这类传统关键词检索去匹配精确术语，一边用向量检索去匹配语义相近的内容，再把两路结果融合起来。融合我用得比较多的是 RRF（Reciprocal Rank Fusion），公式很朴素：

score = 1 / (k + rank_bm25) + 1 / (k + rank_vector)

其中 k 通常取 60。这个公式不看分数绝对值，只看排名，所以不受 BM25 分数和余弦相似度的量纲影响。我在项目里验证过：纯向量检索的召回率约 72%，加上 BM25 的 RRF 融合能做到 88% 左右，效果非常明显。

不少框架已经内置了混合检索组件，比如 LangChain 的EnsembleRetriever、Elasticsearch/OpenSearch 的混合查询。如果你的知识库本身跑在 ES 上，用它的关键字 + kNN 联合查询能省掉很多胶水代码。

3.3 重排模型：用 cross-encoder 做最后一公里的精筛

两路检索合起来可能召回了几十条结果，但最后 LLM 只能读有限的几块。这时候“重排”就非常重要。重排模型和 Embedding 模型不是同一个东西：Embedding 是把文本块独立编码成向量，属于 bi-encoder 范式，它高效但精度有限；重排模型通常用 cross-encoder，把查询和候选文本拼在一起做深度交互，输出一个相关性分数，精度更高，但速度慢。

典型的流程是：先向量/关键词检索召回 Top50，再用重排模型（如bge-reranker-large或cross-encoder/ms-marco-MiniLM）逐一打分，最后取 Top5 进入 Prompt。这一步消耗的时间通常几百毫秒到几秒，但对答案质量提升非常显著。

我做过对比实验：用同一个知识库和同一组 50 个测试问题，不重排直接取 Top5，答案命中率为 70%；用重排模型从 Top50 里挑 5 个，命中率提升到 85%。可以说这是性价比最高的调优环节。生产环境如果延迟敏感，可以把重排模型部署在 GPU 上，或者只对 Top20 做重排。

3.4 查询改写：把用户的“废话”翻译成检索语言

用户的问题往往不是适合直接检索的。比如对话里他问“这个支持远程升级吗？”，如果直接把“这个”拿去检索，什么都找不到。我们需要把这种指代不清的问题，结合对话历史改写成一个独立的、语义完整的查询：“XX型号网关设备是否支持远程升级”。

查询改写我有两种玩法。一种是用 LLM 做改写：把最近几轮对话压缩成一段，让模型输出一个“站在当下问题视角的搜索查询”，再拿这个查询去检索。另一种是 HyDE（假设性文档嵌入）：让 LLM 先基于用户问题幻觉一篇“可能的答案”，再拿这篇假设答案去做向量检索。HyDE 在某些语义检索场景效果好，但成本偏高，我一般只用在前几轮检索结果不理想时的补偿策略。

要注意的是，改写不是越复杂越好。用户如果问得很具体，比如“报销流程里发票校验在哪个步骤”，直接检索原始问题就很好。过度改写反而可能引入模型自己的偏见。我在项目里的做法是：先判断当前问题是否包含关键实体名词。如果包含，就直接用原文；如果不完整或有指代词，才触发改写。

4. 把 RAG 接进 Agent 的决策循环：从工具调用到 Agentic RAG

4.1 Agent 中 RAG 的几种集成姿势

RAG 在 Agent 里的集成方式，直接决定了 Agent 的灵活性和可靠性。我见过三种层次的做法：

第一种，也是最简单的：Agent 一启动就把检索结果塞进上下文。比如用户问“帮我看看报销流程”，Agent 在接到问题后先调用一次检索，把“报销流程”的相关 chunk 放进 Prompt，再开始规划。这种模式适合任务目标比较明确的场景，缺点是 Agent 没法根据中间结果反复调整检索策略。

第二种，把 RAG 封装成一个工具（例如search_docs(query)），让 Agent 在规划阶段自己决定什么时候调用。这种方式把检索变成了 Agent 的一项能力，Agent 可以先用思维链分析用户问题，再决定查哪个库、查什么关键词，如果查到一半觉得信息不够，还可以再调一次。热词里的“spring ai rag”“langchain4j rag”在这种模式下都提供了比较成熟的工具调用封装。

第三种，是多工具协作。知识库只是众多工具之一，Agent 手里可能还有 SQL 查询工具、外部 API 工具、工单系统工具。它根据用户意图选择检索哪一类知识，再结合其他工具的结果做决策。这套玩法更接近我后面要讲的 Agentic RAG，也是目前企业级落地的主流趋势。

我个人建议，从第二种开始，因为第一种很难应付真实业务里多步骤的任务，而第三种需要你先把工具层和权限模型设计清楚，否则很容易变成“到处搜又到处出错”的失控循环。

4.2 多轮对话中的上下文管理与引用溯源

Agent 和用户通常不是一轮就结束的。多轮对话里，检索的上下文会被历史信息干扰。比如用户先问“我们公司的采购审批流程是怎样的？”，Agent 检索并回答了“三审制”。接着用户说“那如果金额超过 50 万呢？”，这条问题单独拿去检索，可能搜不到精确答案，因为关键在于“50 万”这个限定词，而上一轮里的“采购审批流程”其实是不可或缺的查询条件。

处理方式通常是把最近几轮对话压缩后，生成一个“独立检索查询”。LangChain 的ConversationalRetrievalChain就是这么做的。不过我更推荐自己控制：存一个dialogue_summary变量，每一轮更新，检索时把当前问题 + dialogue_summary拼起来给 LLM 改写。这样既能保持上下文，又不会把整段历史全部丢进检索器。

引用溯源是 Agent 场景里必不可少的一环。你返回的 chunk 上要带source元数据，在 Prompt 里要求模型逐条标注 [1][2] 编号，并在回答末尾给出引用来源列表。这个设计一方面方便用户信任 Agent 的输出，另一方面也是你未来排查幻觉问题时最重要的线索。没有来源标注的 RAG 回答，出了问题你都无从下手。

4.3 Agentic RAG 是什么：从“查一次”到“查得准”

Agentic RAG 是最近讨论度很高的方向，核心思想很明确：检索不再是一条“查完就结束”的流水线，而是让 Agent 自主决定“查什么、怎么查、查几次”。它把 RAG 从被动工具升级成了主动的决策过程。

具体到实现上，我遇到过的典型 Agentic RAG 流程是这样的：Agent 先根据用户问题生成一个初始查询，调用知识库检索；然后它检查召回的 chunks——如果发现没有覆盖关键实体，就自动改写查询再检索一轮；如果发现回答需要跨两个知识域（比如既要技术参数又要价格商务条款），就把检索任务拆成多个子检索；最后才综合所有片段生成答案。这里面还可能会用到 self-RAG 里“自反射”的机制：让模型对自己检索到的信息打分，判断是否可靠，不可靠就重新检索。

有一个例子我印象很深。用户问“能不能把旧款控制器的数据迁移到新款网关”，第一轮检索只找到了两个产品各自的说明书，没有迁移手册。如果是一般的 RAG，模型可能就开始编造迁移步骤了。但 Agentic RAG 的 Agent 发现信息不足，主动把查询改成“控制器数据迁移 网关兼容”，又检索到一条论坛 FAQ，明确了需要先用转换工具导出。整个过程中 Agent 不是在单次检索，而是在“检索-评估-调整-再检索”的循环里逼近正确答案。这就是 Agentic RAG 和普通 RAG 的本质区别。

4.4 一个完整的 Agent + RAG 流程示例

我用伪代码来展示我常用的一套简化流程，方便你理解整个链路是怎么串起来的：

def agent_with_rag(user_query, chat_history): # 1. 上下文压缩与查询改写 search_query = rewrite_query(user_query, chat_history) # 2. 混合检索：BM25 + 向量召回 Top50 candidates = hybrid_retrieve(search_query, top_k=50) # 3. 重排精筛 Top5 top_chunks = rerank(user_query, candidates, top_k=5) # 4. 组装 Prompt，带来源编号 prompt = build_prompt(top_chunks, user_query, chat_history[-3:]) # 5. LLM 生成 answer = llm_generate(prompt) # 6. 检查答案是否引用了来源，如果模型说“无法回答”则考虑触发二次检索 if not has_citation(answer): new_query = generate_refined_query(prompt, answer) top_chunks = hybrid_retrieve(new_query, top_k=5) answer = llm_generate(build_prompt(top_chunks, user_query, chat_history[-3:])) return answer, top_chunks

这段伪代码里最重要的是第 6 步：对答案做质量自检，信息不足就二次检索。这个“二次检索”就是 Agentic RAG 的最低配实现。你不需要一开始就上很复杂的规划算法，先把这个反馈循环跑通，再逐步增加“拆解多路检索”“调用 SQL 工具”等能力，会更稳妥。

5. 实战中的高频踩坑与我的排查清单

5.1 切分不合理导致答案碎片化

我第一个生产级 RAG 项目，上线一周就被业务方吐槽：回答经常只有前半句，或者把两段不相干的描述强行拼在一起。排查后发现是切分策略的锅。当时我用了固定长度 256 字符切分，一个长句子从中间被切开，前一段没有结论，后一段没有主语。模型读到的都是不完整信息，自然回答不完整。

解决办法我前面提到过：优先按结构切分，并在每个 chunk 带上它的父级标题；必须固定长度切分时，加大 overlap。如果你用的是 LangChain，可以看ParentDocumentRetriever——它把文档切得很小去向量化（保证检索精准），但检索命中后把所属的大段落（父文档）交给模型生成。这种“查小喂大”的策略对长文档特别管用。

5.2 召回噪声与幻觉的对抗手段

检索召回的 chunk 不可能百分之百相关。有时你查“报销流程”，top1 命中的却是“考勤制度里提到报销”，模型就会被带偏。我处理这类问题有三个手段：第一，在 Prompt 明确“参考资料不一致时以多数来源为准”，并要求“不确定的信息不要展开”。第二，使用 metadata 过滤，比如根据部门、文档类型、发布时间做硬性排除，从源头减少噪声。第三，引入答案与引用的自洽性校验——让模型输出时强制附带来源编号，再让另一个 LLM 或规则检查“回答中的关键断言是否都能在引用 chunks 里找到原文依据”，找不到就触发重检索。

即使做了这些，RAG 也无法做到百分百无幻觉。模型融合信息时依然可能推断出原文没有的因果关系。我的态度是：在业务允许的范围内，尽量设计“条件回答”——把不确定的部分显式标成“需要人工确认”。在 Agent 场景，给用户一个“提交工单”或“转人工”的兜底动作，总比让模型硬编一个答案强。

5.3 知识库更新的同步难题

RAG 的一个隐性成本是知识库维护。文档更新后，你不仅要改原始文件，还要重新切分、重新向量化，并把旧的向量删掉。我见过一个团队用了半年 RAG，向量库里已经堆了三个版本的流程文档，检索时新老内容互相打架，模型回答“既可以这样也可以那样”，实际上只有一个版本是对的。

我现在的做法是：所有文档入库前先计算一个内容 hash，作为向量库里的doc_version字段。后台跑一个定时任务检查文档是否有变化，如果 hash 变了，就把该文档下的旧 chunk 全部删除，再重新切分入库。更简单的方案是把所有文档放 Git 仓库里管理，每次提交走 CI/CD 流程自动重建索引。对于个人项目，你至少也要在代码里给每个 chunk 写上source_id和updated_at，否则后期清理起来会非常痛苦。

5.4 我的 RAG 调试清单与评估指标

RAG 项目没法像传统算法那样靠一个离线指标定生死，但也不能全靠肉眼。我自己的调试流程是：先准备 20 到 30 个典型业务问题，每个问题标注好“标准答案所在的文档块 ID”。然后跑检索，算recall@k——标准答案块是否出现在前 k 个检索结果里。如果 recall 很低，问题大概率在 Embedding 模型、切分策略或查询改写上，先调这些，而不是急着调 Prompt。

如果 recall 不错但生成答案不对，问题就在 Prompt 或者上下文组装上。此时我会把检索到的 chunks 原样打印出来，人工看一遍，确认“有没有证据”。有证据但模型没用，是 Prompt 或模型能力的问题；没证据但模型答得很溜，说明模型在编，就需要加强“无法回答”的约束。

我还会用 RAGAS（RAG Assessment）这类开源框架做自动化打分：忠实度（答案是否忠于上下文）、答案相关性（是否回答了问题）、上下文相关性（检索内容是否与问题相关）。每周跑一遍这个评测集，能直观看到管道变更的收益和退化，比凭感觉调参靠谱得多。

6. 从基础 RAG 走向更聪明的管道：GraphRAG 与 Ontology RAG 的启发

6.1 向量检索的局限与 GraphRAG 的出现

基础 RAG 有一个天然天花板：它对“全局性问题”束手无策。向量检索擅长找到“与问题最相似的那段文字”，但如果你问“请总结我们公司所有产品线里共用的安全标准”，答案散落在几十份文档里，没有哪一句话能单独回答。传统 RAG 会给你拼凑出几个片段，但没法形成全局洞察。

GraphRAG 专门解决这个问题。它的思路是：先让 LLM 从文档中抽取实体（比如产品、部门、流程节点）和实体间的关系（比如“关联于”“审批节点是”），把这些三元组建成本地知识图谱。然后对图谱做社区检测，把关系紧密的实体聚合在一起，生成社区摘要。检索时，针对全局问题去查这些“社区摘要”，针对局部问题则可以沿着图谱的边做路径检索。

我这里说一句真实感受：GraphRAG 的构建成本比普通 RAG 高不少，光是抽取实体和关系就要消耗大量 Token，而且抽取质量直接影响效果。所以它适合“需要全局洞察”的场景，比如集团知识库、法律合规全文分析，而不是所有知识库都应该上。小团队一上来就追求 GraphRAG 往往事与愿违。

6.2 Ontology RAG：用领域知识约束检索边界

热词里有个“ontology rag”引起了我的注意——本体增强检索。这里的“本体”指的是对领域概念和它们之间关系的显式定义，比如一个工业企业里，“设备”和“保养记录”之间的定义、层级、约束关系。为什么要加本体？因为纯向量检索不知道“维修工单”和“备件出库单”之间可能在业务上属于同一故障处理链路，它只知道字面相似。

Ontology RAG 的做法是把本体作为检索的“地图”。比如检索一个查询，先从本体里找到相关概念和别名，再扩展查询词；或者把本体的规则作为裁剪条件，排除在语义上相似但在业务上无关的文档。典型的落地场景是医疗和工业：同样是“发热”，在“儿科门诊”和“机房服务器”两个本体环境下含义完全不同，本体能帮你把检索边界约束清楚。

我自己对 Ontology RAG 的态度是：如果你的知识领域术语含义很固定、且存在明显的层级关系，那值得引入本体；如果只是做一个通用问答机器人，引入本体的维护成本可能会压过收益。它更像是“垂直领域知识管道”的进阶选项，适合与企业内部的业务系统联动时使用。

6.3 关于“知识获取管道”的后续扩展思路

写完这篇，我脑子里还盘旋着一个更大的蓝图：RAG 只是知识获取管道的起点。未来的 Agent 会需要更标准化的方式去访问各类数据源——文件、数据库、API、工单系统，甚至是另一个 Agent 的知识产出。看起来大家都在往“知识获取协议”这个方向靠拢，类似 MCP（Model Context Protocol）的思路就是把数据访问变成标准化的工具接口，让 Agent 可以即插即用地读取不同源的信息。

另外，知识管道和 Agent 的记忆系统应该合起来设计。短期记忆负责多轮对话的上下文，长期记忆负责用户偏好和业务规则，而 RAG 知识库则承担“可更新的外部事实库”角色。三者分层，各司其职，Agent 才能真正像一个有经验的员工那样，一边回忆一边查资料一边给出判断。

回看这篇，从最基础的“为什么要 RAG”讲到了混合检索、重排、Agentic RAG 和 GraphRAG，这些内容基本覆盖了搭建一条知识获取管道的全过程。最后分享一个个人习惯：每当我准备把新知识接入 Agent 时，都会强制自己先写一遍“标准答案从哪一段文档出来”的测试用例，再动工写代码。因为 RAG 项目的好坏，从来不是代码有多精巧，而是你的知识能不能精准、可信、可更新地到达 Agent 手里。