去年我接手公司内部知识库 Agent 的改造时收到的最典型需求是“能不能让员工直接问‘报销单多久之内必须提交’模型先查咱们自己的制度文件再回答”我试过把制度文档直接粘进提示词里结果上下文窗口撑爆回答还是模棱两可。后来才真正理解AI Agent 要落地第一关不是模型多聪明而是给它接一条靠谱的“知识获取管道”——也就是 RAG。这篇内容就是“走进 AI Agent”系列的第四篇重点讲 RAG 基础为什么 Agent 需要它、从 0 到 1 怎么搭、哪些参数真正影响效果。不管你是刚开始学 AI Agent 开发还是已经在做企业级应用这篇文章都能帮你把基础打结实。1. 为什么不直接问大模型Agent 知识断片的现实问题1.1 模型什么都懂却不知道你公司的报销制度很多人刚接触 AI Agent 时会有个错觉大模型已经读过互联网上的海量资料所以任何问题它都能答。这个说法有一半是对的——模型确实记住了非常广的常识但它的知识有两个天然边界一个是训练数据的截止时间另一个是它根本读不到你的私有资料。你公司的薪酬制度、产品规格、售后流程、ERP 里的库存数据这些都不在模型预训练阶段能看到的世界里。哪怕是最新最强的模型在面对“我们华南仓的发货时效是多久”这种问题时也只能靠通用常识去猜猜出来的答案一旦错了员工拿去执行代价就大了。给 Agent 补知识有几种路径我先把它们摆在一起看方案成本更新效率适用场景微调 Fine-tuning高算力数据标注慢每次知识变更都要重新训固定语气风格、领域术语、输出格式长上下文全塞入中Token 费用高快但受到窗口上限约束少量单篇长文档如一本书RAG 检索增强低向量存储检索链路快文档入库即生效动态更新、大规模知识库、企业私有资料为什么微调不是最优解微调更像是“给模型补性格”而不是“给模型补记忆”。企业知识的特点是变更频繁报销流程可能一季一改产品手册每周都有新版本。如果你每次文档变动都要重新微调一次训练成本、回归验证成本、发布成本都让你吃不消。1.2 RAG 的本质是给 Agent 配一个“随取随用的资料库”我习惯用一个类比来解释 RAG你身边有个刚毕业的高材生基础知识扎实但你让他回答“公司的年假制度”他答不上来因为没有看过人事手册。RAG 做的事情不是把手册背下来塞进他脑子里而是给他配了一个随取随用的资料库他回答前先去资料库翻相关章节再基于翻到的内容来回答。所以 RAGRetrieval-Augmented Generation检索增强生成本质上是一条知识获取管道它把“外部知识”从“实时查找”的方式灌进 Agent 的生成过程。对 Agent 来说RAG 解决的是感知层问题——Agent 能感知到当前任务需要哪部分知识然后主动调取。从 0 到 1 搭建 AI Agent 时RAG 通常是我建议做的第一个能力模块。因为它见效快、结果可解释也最容易暴露问题。很多 Agent 项目最后翻车不是 Agent 的规划能力不行而是检索回来的知识不对、不及时、不完整——管道一旦有问题后面所有环节都会跟着崩。2. 索引管道把散落文档变成可检索的子弹库2.1 从文档到数据库加载与清洗比想象中耗时RAG 基础链路的第一步是离线索引。你要把企业内部的各种文档——PDF、Word、Markdown、Excel 表格——统一清洗、切分、向量化再存入向量数据库。这一步听起来简单实际操作时最耗时的是加载与清洗。先说加载。PDF 是重灾区扫描版 PDF 需要 OCR文字版 PDF 不同库解析出来的效果差异很大表格经常被解析得乱七八糟。我处理实战项目时会先抽样 10 页人工过一遍确定解析器输出质量再决定要不要额外做表格结构化提取。清洗也很关键。文档里的页眉页脚、导航文字、重复的免责声明这些内容如果不清掉会污染向量化结果。检索时经常出现一个奇怪现象你问“报销时限”召回的内容全是页脚的“本文件仅供内部使用请勿外传”。不是模型不聪明是垃圾内容占据了 chunk 的语义空间。清洗完就是大小写归一化、去空白、保留或剔除特定标记。对于 Markdown 类文档我建议保留标题层级因为后续能利用标题做段落切分效果比纯固定长度切分好得多。2.2 文本切分chunk_size 和 overlap 不是玄学文本切分是索引管道里最容易被忽视、但也最影响检索效果的环节。切太大了一个 chunk 里包含多个主题检索时噪声多切太小了语义不完整向量表示也偏弱。我的经验是默认从 500 字或 300~500 token 起步同时设置 50~100 字的 overlap。overlap 的作用是避免句子在边界处被拦腰截断比如一个段落正好被切成两半两端各残留半句话Embedding 出来的向量都不完整。有了 overlap边界处的信息会同时出现在相邻 chunk 里至少有一边是完整的。切分方式和文档结构相关固定长度切分简单粗暴适合纯文本段落。递归字符切分先按段落分再按句子分LangChain 的 RecursiveCharacterTextSplitter 就是这个思路。结构化切分利用 Markdown 标题、PDF 章节标记来做边界识别适合长手册、规范文档。我实际项目里的一个教训是别在切分上追求“完美语义边界”那是无底洞。先跑一版固定切分端到端测一遍再调整性价比最高。2.3 向量化与入库Embedding 模型怎么选切好的 chunk 需要转成向量这里涉及 Embedding 模型的选择。英文场景下选择很多但中文场景要考虑是否支持中英双语。如果你的知识库里有英文技术文档务必选双语支持的模型否则英文内容召回会很差。向量维度也是个值得关注的参数。常见的有 768 维、1024 维嵌入式模型对语义的区分度差异很大。维度太低可能区分不够细维度太高又带来存储和计算开销。做过对比后你会发现对业务文本好的模型在语义相关性排序上的优势远比维度大小重要。入库之前要做一遍批量向量化一般建议 batch size 设在 32 或 64避免批量太大造成显存压力。向量库选型我也整理一个参考场景推荐选择理由单机小规模原型Chroma、pgvector部署简单几十万向量够用中大规模生产Milvus、ES 向量插件分布式扩展、过滤能力强已有 Redis 的基础设施Redis 向量检索复用运维体系降低改造成本Spring AI、LangChain4j 这一票 Java 生态框架也都在做向量存储抽象如果你的团队是 Java 背景不需要自己拼装轮子直接用 spring ai 的 vector store 抽象即可。3. 检索不是“搜到就行”TopK、混合召回和重排的实战配置3.1 向量检索的盲区精确关键词和编号信息索引建完检索就是整个 RAG 命中率的关键。很多人的第一版实现是只做向量检索也就是把用户问题 Embedding 后去向量库里找余弦距离最近的一批 chunk。这在泛泛的语义问答里很流畅但真实企业场景很快会暴露问题。比如用户问“PRD-2024-0715 这个项目号对应什么产品”这种查询里起决定性作用的是精确字符串“PRD-2024-0715”而不是语义。向量检索擅长的是“语义相近”对这种精确匹配非常不敏感经常把最关键的编号信息丢掉。解决思路是混合检索Hybrid Search把传统的 BM25 关键词检索和向量语义检索结合起来各自召回一批结果再取并集进重排。BM25 保证精确匹配不掉链子向量检索保证“换个说法也能找到”两者是互补关系。我做过一个测试纯向量检索在某产品文档问答项目上的 hit rate 大概在 62% 左右加入 BM25 混合召回后hit rate 直接提升到 78%。这个提升不用改模型、不用微调只是把检索策略改一下性价比非常高。3.2 TopK 与重排宁可多召回再精挑细选TopK 的设置直接决定后续生成质量。设得太小比如 3~5容易漏掉正确答案设得太大比如 50上下文里全是弱相关片段模型会被噪声带偏。我的习惯是第一轮召回时 TopK 设到 20 左右宁可多拿也别漏。多拿之后怎么办靠重排Rerank来压缩。重排模型会拿用户问题和每个 chunk 做一次深度交互计算输出更精准的相关性得分然后把 Top20 压缩成 Top6~8 送进生成环节。这类模型通常用交叉编码器架构效果比向量检索的双塔结构好不少缺点是延迟更高。用不用重排取决于你的实时性要求知识库规模小、问题简单可以不做重排直接 TopK6~8。知识库规模大、答案分散建议接重排检索质量提升非常明显。生产环境对延迟敏感可以把重排模型用小版本或者对前 20 个结果做重排而不是全量重排。3.3 metadata 过滤一个经常被忽略的杀手锏检索阶段还有一个经常被忽略的配置——metadata 过滤。很多 RAG 项目只靠语义相似度排序完全不看文档来源。结果就是员工问报销政策系统从 2021 年的旧制度里召回了一大段而 2024 年新制度明明就在库里。如果你在入库时为每个 chunk 打上部门、日期、文档版本、文档类型这些标签检索时就能先按条件过滤再按向量相似度排序。这一步对命中率的提升有时比重排还明显。给知识库打标签听起来增加工作量但收益很直接。我通常会要求文档团队在导入文件时勾选对应的知识域或者在文件名里约定前缀。后续做分类时用 Embedding 做一次聚类初筛再人工确认可以省很多时间。3.4 用 hit rate 建立你的评估基线聊到检索质量就绕不开“rag hit rate”这个概念。它衡量的是面对一组预定义问题检索系统能否在前 N 个结果里召回包含正确答案的文档。比如准备了 50 个问题系统在 Top10 内正确命中其中 40 个那 hit rate 就是 80%。我的建议是 RAG 项目启动时就准备一个小型评估集哪怕先做 20 条问题。把团队里常见的用户提问收集起来标注好答案出现在哪篇文档、哪个段落。跑检索看命中率迭代切分参数、Embedding 模型、TopK、过滤条件都用这个评估集来衡量。没有评估集你所有的调优都是在凭感觉走。4. 生成阶段让回答既“有证据”又“不说胡话”4.1 把检索到的知识组装成有效的上下文检索到的内容不是直接丢给模型就行。组装 Prompt 的格式会直接影响模型是“照着资料回答”还是“自由发挥”。我会给 Agent 的 RAG 生成环节画一条明确的边界只能根据提供的资料回答问题资料里没有的明确说不知道。下面是我在项目里常用的一个 Prompt 模板def build_prompt(query, chunks): context \n\n.join( f[{i1}] {chunk.page_content} for i, chunk in enumerate(chunks) ) return f请根据以下资料回答问题。只允许使用资料中的信息资料中未提及的内容请回答“资料不足”。 资料 {context} 问题{query} 回答这里一个很关键的细节是给每个 chunk 编号 [1]、[2]、[3]……并在 prompt 里要求模型回答时标注依据来源比如“根据 [2] 和 [4]”。这样做的好处不只是让用户知道答案出处更重要的是它逼着模型基于给定材料推理而不是自己编一套理由。生成结束后前端还能根据编号直接跳转并高亮原文体验会好很多。4.2 控制上下文长度不是塞得越多越好我见过不少 RAG 实现把 TopK 调到 10 以上把 10 个 chunk 全部塞进 prompt认为这样信息最全。但在实际评测中这种做法经常导致回答质量下降。原因很简单上下文里无关内容越多关键信号被稀释得越厉害模型更容易被次要内容带偏。合理的做法是控制最终进入生成阶段的 chunk 数量我一般维持在 5~8 个。如果某些知识库的文档非常长比如一本操作手册整体分割后产生 200 个 chunk那么一次检索拿 8 个 chunk 可能仍然不够。这种情况下就要考虑两级检索第一级先按文档粒度粗筛找出最相关的 2~3 篇文档第二级再在这几篇文档的内部精细检索取最后的 TopK。上下文窗口比较大的模型可以容忍更多 chunk但“容忍多”不等于“效果好”。生成质量的最优值永远需要你用评估集去实测而不是盯着参数大小拍脑袋。4.3 幻觉防线知道“答案”和“推理”不是一回事RAG 能显著降低幻觉但不可能完全消灭幻觉。主要有两个风险点一是检索到的资料里本身就包含错误信息二是模型在整合上下文时做了过度推理。我在生成环节会加一道简单的防线把答案做一次“硬校验”如果答案里出现了资料中没有的数值、人名、日期系统可以自动标记“未经资料证实”。实现方式可以是规则匹配也可以再用一个小模型对答案做一致性校验。虽然做不到完美但能把幻觉风险降低一个量级。另一个实用做法是做缓存。同一个问题如果在近一段时间内被问了三次答案基本一致就直接返回缓存结果不再走完整 RAG 链路。这样既能省成本还能避免模型因为随机性给出不同表述让产品经理以为系统不稳定。5. 从基础 RAG 到 Agentic RAG进阶方向与选型判断5.1 当“单轮检索”不够用Agentic RAG 的出现基础 RAG 的逻辑是“用户问题 → 检索一次 → 生成答案”整个过程是静态的。它的局限很明显遇到复杂问题时一次检索可能无法覆盖全部信息。比如“对比 A 产品和 B 产品的售后政策差异”最优做法是先分别查 A、B 两套知识库再把结果汇总。Agentic RAG 就是在基础 RAG 之上引入决策能力Agent 自己决定要不要检索、去哪里检索、检索几次甚至能改写用户问题再做二次检索。它把“知识获取”从单发动作变成了多步规划。从实现角度Agentic RAG 有几种常见模式Query Rewriting对输入问题做改写拆成多个子问题分别检索。Self-RAGagent 先检索再自评检索结果够不够回答不够就追加检索。Multi-Hop 检索第一次检索得到的实体再作为线索去查另一份相关文档。这些模式都有各自适合的场景但如果你的基础 RAG 命中率还没压到 80% 以上不建议直接上 Agentic RAG。复杂度的提升会让问题更难排查到时候你分不清是检索问题还是规划问题。5.2 GraphRAG 与 Ontology RAG面向复杂关系的知识组织除了 Agentic RAG还有一条进阶方向是把知识库从“向量片段集合”升级成“图结构”。GraphRAG 在向量检索之外额外构建实体关系图擅长回答“全局性问题”。比如你问“我们公司有哪些业务线之间存在协作关系”这种问题依赖的是实体间的关联网络纯向量检索很难答全。Ontology RAG 更进一步用本体论来定义概念、属性和关系让检索更精准。这类方案适合知识体系庞大、术语规范、关系复杂的行业比如医疗、金融、工业制造。它们的问题是建设成本高通常需要领域专家参与建 schema。对企业级 Java 技术栈的团队来说Spring AI 生态里已经能通过 Spring AI 的 ETL 流程把 RAG 能力和业务系统打通再往上是把 RAG 封装成内部服务类似 RAG as Service 的思路。如果你面对的是一堆 ERP、CRM、内部 Wiki先把基础 RAG 跑成服务未来塞进 Agent 的能力列表比一步到位做 GraphRAG 稳妥得多。5.3 从 0 到 1 的落地路线先打通最小闭环我接触到的不少团队谈到 RAG 就直接说“我们要做 Agent GraphRAG Agentic RAG”结果项目拖了三个月还没上线。如果让我给一条从 0 到 1 的路线图顺序应该是这样的先做一个最小闭环文档加载 → 切分 → 向量化 → 向量库 → TopK 检索 → Prompt 生成。跑通看效果。照着 30~50 条评估集反复调检索质量调切分参数、调 Embedding、加混合检索、加 metadata 过滤先把 hit rate 提上去。再做生产级别的补强加重排、加引用溯源、加缓存、加权限过滤。以上都稳了再考虑引入 Agent 交互层多轮检索、工具调用、动态决策。每一步都有明确的验证标准不会出现“做到一半不知道算不算完成”的尴尬。RAG 这个东西单看任何一个环节都不复杂难的是整条管道的稳定性和可维护性。这也是为什么我反复强调评估集和检索质量——它们是整个知识获取管道的锚点。我个人的体会是Agent 的能力上限很大程度上由知识获取管道的质量决定。模型选得再好如果管道里检索出来的是一堆过时或无关的内容输出照样稀烂。反过来只要管道稳即使用开源的模型也能在企业场景里做出让人愿意每天打开的产品。所以别急着上炫酷的 Agent 框架先把 RAG 这条“数据动脉”打扎实Agent 才有发挥的空间。 AI Agent 落地的关键：从 0 到 1 搭建 RAG 知识获取管道
去年我接手公司内部知识库 Agent 的改造时收到的最典型需求是“能不能让员工直接问‘报销单多久之内必须提交’模型先查咱们自己的制度文件再回答”我试过把制度文档直接粘进提示词里结果上下文窗口撑爆回答还是模棱两可。后来才真正理解AI Agent 要落地第一关不是模型多聪明而是给它接一条靠谱的“知识获取管道”——也就是 RAG。这篇内容就是“走进 AI Agent”系列的第四篇重点讲 RAG 基础为什么 Agent 需要它、从 0 到 1 怎么搭、哪些参数真正影响效果。不管你是刚开始学 AI Agent 开发还是已经在做企业级应用这篇文章都能帮你把基础打结实。1. 为什么不直接问大模型Agent 知识断片的现实问题1.1 模型什么都懂却不知道你公司的报销制度很多人刚接触 AI Agent 时会有个错觉大模型已经读过互联网上的海量资料所以任何问题它都能答。这个说法有一半是对的——模型确实记住了非常广的常识但它的知识有两个天然边界一个是训练数据的截止时间另一个是它根本读不到你的私有资料。你公司的薪酬制度、产品规格、售后流程、ERP 里的库存数据这些都不在模型预训练阶段能看到的世界里。哪怕是最新最强的模型在面对“我们华南仓的发货时效是多久”这种问题时也只能靠通用常识去猜猜出来的答案一旦错了员工拿去执行代价就大了。给 Agent 补知识有几种路径我先把它们摆在一起看方案成本更新效率适用场景微调 Fine-tuning高算力数据标注慢每次知识变更都要重新训固定语气风格、领域术语、输出格式长上下文全塞入中Token 费用高快但受到窗口上限约束少量单篇长文档如一本书RAG 检索增强低向量存储检索链路快文档入库即生效动态更新、大规模知识库、企业私有资料为什么微调不是最优解微调更像是“给模型补性格”而不是“给模型补记忆”。企业知识的特点是变更频繁报销流程可能一季一改产品手册每周都有新版本。如果你每次文档变动都要重新微调一次训练成本、回归验证成本、发布成本都让你吃不消。1.2 RAG 的本质是给 Agent 配一个“随取随用的资料库”我习惯用一个类比来解释 RAG你身边有个刚毕业的高材生基础知识扎实但你让他回答“公司的年假制度”他答不上来因为没有看过人事手册。RAG 做的事情不是把手册背下来塞进他脑子里而是给他配了一个随取随用的资料库他回答前先去资料库翻相关章节再基于翻到的内容来回答。所以 RAGRetrieval-Augmented Generation检索增强生成本质上是一条知识获取管道它把“外部知识”从“实时查找”的方式灌进 Agent 的生成过程。对 Agent 来说RAG 解决的是感知层问题——Agent 能感知到当前任务需要哪部分知识然后主动调取。从 0 到 1 搭建 AI Agent 时RAG 通常是我建议做的第一个能力模块。因为它见效快、结果可解释也最容易暴露问题。很多 Agent 项目最后翻车不是 Agent 的规划能力不行而是检索回来的知识不对、不及时、不完整——管道一旦有问题后面所有环节都会跟着崩。2. 索引管道把散落文档变成可检索的子弹库2.1 从文档到数据库加载与清洗比想象中耗时RAG 基础链路的第一步是离线索引。你要把企业内部的各种文档——PDF、Word、Markdown、Excel 表格——统一清洗、切分、向量化再存入向量数据库。这一步听起来简单实际操作时最耗时的是加载与清洗。先说加载。PDF 是重灾区扫描版 PDF 需要 OCR文字版 PDF 不同库解析出来的效果差异很大表格经常被解析得乱七八糟。我处理实战项目时会先抽样 10 页人工过一遍确定解析器输出质量再决定要不要额外做表格结构化提取。清洗也很关键。文档里的页眉页脚、导航文字、重复的免责声明这些内容如果不清掉会污染向量化结果。检索时经常出现一个奇怪现象你问“报销时限”召回的内容全是页脚的“本文件仅供内部使用请勿外传”。不是模型不聪明是垃圾内容占据了 chunk 的语义空间。清洗完就是大小写归一化、去空白、保留或剔除特定标记。对于 Markdown 类文档我建议保留标题层级因为后续能利用标题做段落切分效果比纯固定长度切分好得多。2.2 文本切分chunk_size 和 overlap 不是玄学文本切分是索引管道里最容易被忽视、但也最影响检索效果的环节。切太大了一个 chunk 里包含多个主题检索时噪声多切太小了语义不完整向量表示也偏弱。我的经验是默认从 500 字或 300~500 token 起步同时设置 50~100 字的 overlap。overlap 的作用是避免句子在边界处被拦腰截断比如一个段落正好被切成两半两端各残留半句话Embedding 出来的向量都不完整。有了 overlap边界处的信息会同时出现在相邻 chunk 里至少有一边是完整的。切分方式和文档结构相关固定长度切分简单粗暴适合纯文本段落。递归字符切分先按段落分再按句子分LangChain 的 RecursiveCharacterTextSplitter 就是这个思路。结构化切分利用 Markdown 标题、PDF 章节标记来做边界识别适合长手册、规范文档。我实际项目里的一个教训是别在切分上追求“完美语义边界”那是无底洞。先跑一版固定切分端到端测一遍再调整性价比最高。2.3 向量化与入库Embedding 模型怎么选切好的 chunk 需要转成向量这里涉及 Embedding 模型的选择。英文场景下选择很多但中文场景要考虑是否支持中英双语。如果你的知识库里有英文技术文档务必选双语支持的模型否则英文内容召回会很差。向量维度也是个值得关注的参数。常见的有 768 维、1024 维嵌入式模型对语义的区分度差异很大。维度太低可能区分不够细维度太高又带来存储和计算开销。做过对比后你会发现对业务文本好的模型在语义相关性排序上的优势远比维度大小重要。入库之前要做一遍批量向量化一般建议 batch size 设在 32 或 64避免批量太大造成显存压力。向量库选型我也整理一个参考场景推荐选择理由单机小规模原型Chroma、pgvector部署简单几十万向量够用中大规模生产Milvus、ES 向量插件分布式扩展、过滤能力强已有 Redis 的基础设施Redis 向量检索复用运维体系降低改造成本Spring AI、LangChain4j 这一票 Java 生态框架也都在做向量存储抽象如果你的团队是 Java 背景不需要自己拼装轮子直接用 spring ai 的 vector store 抽象即可。3. 检索不是“搜到就行”TopK、混合召回和重排的实战配置3.1 向量检索的盲区精确关键词和编号信息索引建完检索就是整个 RAG 命中率的关键。很多人的第一版实现是只做向量检索也就是把用户问题 Embedding 后去向量库里找余弦距离最近的一批 chunk。这在泛泛的语义问答里很流畅但真实企业场景很快会暴露问题。比如用户问“PRD-2024-0715 这个项目号对应什么产品”这种查询里起决定性作用的是精确字符串“PRD-2024-0715”而不是语义。向量检索擅长的是“语义相近”对这种精确匹配非常不敏感经常把最关键的编号信息丢掉。解决思路是混合检索Hybrid Search把传统的 BM25 关键词检索和向量语义检索结合起来各自召回一批结果再取并集进重排。BM25 保证精确匹配不掉链子向量检索保证“换个说法也能找到”两者是互补关系。我做过一个测试纯向量检索在某产品文档问答项目上的 hit rate 大概在 62% 左右加入 BM25 混合召回后hit rate 直接提升到 78%。这个提升不用改模型、不用微调只是把检索策略改一下性价比非常高。3.2 TopK 与重排宁可多召回再精挑细选TopK 的设置直接决定后续生成质量。设得太小比如 3~5容易漏掉正确答案设得太大比如 50上下文里全是弱相关片段模型会被噪声带偏。我的习惯是第一轮召回时 TopK 设到 20 左右宁可多拿也别漏。多拿之后怎么办靠重排Rerank来压缩。重排模型会拿用户问题和每个 chunk 做一次深度交互计算输出更精准的相关性得分然后把 Top20 压缩成 Top6~8 送进生成环节。这类模型通常用交叉编码器架构效果比向量检索的双塔结构好不少缺点是延迟更高。用不用重排取决于你的实时性要求知识库规模小、问题简单可以不做重排直接 TopK6~8。知识库规模大、答案分散建议接重排检索质量提升非常明显。生产环境对延迟敏感可以把重排模型用小版本或者对前 20 个结果做重排而不是全量重排。3.3 metadata 过滤一个经常被忽略的杀手锏检索阶段还有一个经常被忽略的配置——metadata 过滤。很多 RAG 项目只靠语义相似度排序完全不看文档来源。结果就是员工问报销政策系统从 2021 年的旧制度里召回了一大段而 2024 年新制度明明就在库里。如果你在入库时为每个 chunk 打上部门、日期、文档版本、文档类型这些标签检索时就能先按条件过滤再按向量相似度排序。这一步对命中率的提升有时比重排还明显。给知识库打标签听起来增加工作量但收益很直接。我通常会要求文档团队在导入文件时勾选对应的知识域或者在文件名里约定前缀。后续做分类时用 Embedding 做一次聚类初筛再人工确认可以省很多时间。3.4 用 hit rate 建立你的评估基线聊到检索质量就绕不开“rag hit rate”这个概念。它衡量的是面对一组预定义问题检索系统能否在前 N 个结果里召回包含正确答案的文档。比如准备了 50 个问题系统在 Top10 内正确命中其中 40 个那 hit rate 就是 80%。我的建议是 RAG 项目启动时就准备一个小型评估集哪怕先做 20 条问题。把团队里常见的用户提问收集起来标注好答案出现在哪篇文档、哪个段落。跑检索看命中率迭代切分参数、Embedding 模型、TopK、过滤条件都用这个评估集来衡量。没有评估集你所有的调优都是在凭感觉走。4. 生成阶段让回答既“有证据”又“不说胡话”4.1 把检索到的知识组装成有效的上下文检索到的内容不是直接丢给模型就行。组装 Prompt 的格式会直接影响模型是“照着资料回答”还是“自由发挥”。我会给 Agent 的 RAG 生成环节画一条明确的边界只能根据提供的资料回答问题资料里没有的明确说不知道。下面是我在项目里常用的一个 Prompt 模板def build_prompt(query, chunks): context \n\n.join( f[{i1}] {chunk.page_content} for i, chunk in enumerate(chunks) ) return f请根据以下资料回答问题。只允许使用资料中的信息资料中未提及的内容请回答“资料不足”。 资料 {context} 问题{query} 回答这里一个很关键的细节是给每个 chunk 编号 [1]、[2]、[3]……并在 prompt 里要求模型回答时标注依据来源比如“根据 [2] 和 [4]”。这样做的好处不只是让用户知道答案出处更重要的是它逼着模型基于给定材料推理而不是自己编一套理由。生成结束后前端还能根据编号直接跳转并高亮原文体验会好很多。4.2 控制上下文长度不是塞得越多越好我见过不少 RAG 实现把 TopK 调到 10 以上把 10 个 chunk 全部塞进 prompt认为这样信息最全。但在实际评测中这种做法经常导致回答质量下降。原因很简单上下文里无关内容越多关键信号被稀释得越厉害模型更容易被次要内容带偏。合理的做法是控制最终进入生成阶段的 chunk 数量我一般维持在 5~8 个。如果某些知识库的文档非常长比如一本操作手册整体分割后产生 200 个 chunk那么一次检索拿 8 个 chunk 可能仍然不够。这种情况下就要考虑两级检索第一级先按文档粒度粗筛找出最相关的 2~3 篇文档第二级再在这几篇文档的内部精细检索取最后的 TopK。上下文窗口比较大的模型可以容忍更多 chunk但“容忍多”不等于“效果好”。生成质量的最优值永远需要你用评估集去实测而不是盯着参数大小拍脑袋。4.3 幻觉防线知道“答案”和“推理”不是一回事RAG 能显著降低幻觉但不可能完全消灭幻觉。主要有两个风险点一是检索到的资料里本身就包含错误信息二是模型在整合上下文时做了过度推理。我在生成环节会加一道简单的防线把答案做一次“硬校验”如果答案里出现了资料中没有的数值、人名、日期系统可以自动标记“未经资料证实”。实现方式可以是规则匹配也可以再用一个小模型对答案做一致性校验。虽然做不到完美但能把幻觉风险降低一个量级。另一个实用做法是做缓存。同一个问题如果在近一段时间内被问了三次答案基本一致就直接返回缓存结果不再走完整 RAG 链路。这样既能省成本还能避免模型因为随机性给出不同表述让产品经理以为系统不稳定。5. 从基础 RAG 到 Agentic RAG进阶方向与选型判断5.1 当“单轮检索”不够用Agentic RAG 的出现基础 RAG 的逻辑是“用户问题 → 检索一次 → 生成答案”整个过程是静态的。它的局限很明显遇到复杂问题时一次检索可能无法覆盖全部信息。比如“对比 A 产品和 B 产品的售后政策差异”最优做法是先分别查 A、B 两套知识库再把结果汇总。Agentic RAG 就是在基础 RAG 之上引入决策能力Agent 自己决定要不要检索、去哪里检索、检索几次甚至能改写用户问题再做二次检索。它把“知识获取”从单发动作变成了多步规划。从实现角度Agentic RAG 有几种常见模式Query Rewriting对输入问题做改写拆成多个子问题分别检索。Self-RAGagent 先检索再自评检索结果够不够回答不够就追加检索。Multi-Hop 检索第一次检索得到的实体再作为线索去查另一份相关文档。这些模式都有各自适合的场景但如果你的基础 RAG 命中率还没压到 80% 以上不建议直接上 Agentic RAG。复杂度的提升会让问题更难排查到时候你分不清是检索问题还是规划问题。5.2 GraphRAG 与 Ontology RAG面向复杂关系的知识组织除了 Agentic RAG还有一条进阶方向是把知识库从“向量片段集合”升级成“图结构”。GraphRAG 在向量检索之外额外构建实体关系图擅长回答“全局性问题”。比如你问“我们公司有哪些业务线之间存在协作关系”这种问题依赖的是实体间的关联网络纯向量检索很难答全。Ontology RAG 更进一步用本体论来定义概念、属性和关系让检索更精准。这类方案适合知识体系庞大、术语规范、关系复杂的行业比如医疗、金融、工业制造。它们的问题是建设成本高通常需要领域专家参与建 schema。对企业级 Java 技术栈的团队来说Spring AI 生态里已经能通过 Spring AI 的 ETL 流程把 RAG 能力和业务系统打通再往上是把 RAG 封装成内部服务类似 RAG as Service 的思路。如果你面对的是一堆 ERP、CRM、内部 Wiki先把基础 RAG 跑成服务未来塞进 Agent 的能力列表比一步到位做 GraphRAG 稳妥得多。5.3 从 0 到 1 的落地路线先打通最小闭环我接触到的不少团队谈到 RAG 就直接说“我们要做 Agent GraphRAG Agentic RAG”结果项目拖了三个月还没上线。如果让我给一条从 0 到 1 的路线图顺序应该是这样的先做一个最小闭环文档加载 → 切分 → 向量化 → 向量库 → TopK 检索 → Prompt 生成。跑通看效果。照着 30~50 条评估集反复调检索质量调切分参数、调 Embedding、加混合检索、加 metadata 过滤先把 hit rate 提上去。再做生产级别的补强加重排、加引用溯源、加缓存、加权限过滤。以上都稳了再考虑引入 Agent 交互层多轮检索、工具调用、动态决策。每一步都有明确的验证标准不会出现“做到一半不知道算不算完成”的尴尬。RAG 这个东西单看任何一个环节都不复杂难的是整条管道的稳定性和可维护性。这也是为什么我反复强调评估集和检索质量——它们是整个知识获取管道的锚点。我个人的体会是Agent 的能力上限很大程度上由知识获取管道的质量决定。模型选得再好如果管道里检索出来的是一堆过时或无关的内容输出照样稀烂。反过来只要管道稳即使用开源的模型也能在企业场景里做出让人愿意每天打开的产品。所以别急着上炫酷的 Agent 框架先把 RAG 这条“数据动脉”打扎实Agent 才有发挥的空间。