1. 为什么 Agent 需要一条知识获取管道先讲个我自己的经历。去年我在做一个客服问答类 Agent 原型模型用的是当时综合能力还不错的一款通用大模型。产品经理拿着一个很常见的业务问题来测试我们最近一个月的新用户退款政策是什么模型的回复有理有据政策内容、适用范围、注意事项写得清清楚楚。产品经理想夸我两句但我拦住了——因为我心里清楚这个问题的答案根本不在模型的知识范围内它是根据退款政策这四个字的语义惯性编了一份看起来像那么回事的东西。这就是大模型最核心的短板知识截止日期 幻觉。模型内部的参数化记忆本质上是压缩过的训练语料它无法覆盖你的私有知识、实时数据而且就算覆盖了它也不能保证记住的是最新版本。在这个背景下RAGRetrieval-Augmented Generation检索增强生成成了最主流、也最务实的解决方案。它做的事说起来很直白在模型回答问题之前先从一个外部知识库里检索出相关的片段把片段塞进上下文里让模型看着资料回答问题。但如果你只停留在检索 拼接 生成这个粗粒度理解上那你做出来的所谓 RAG 大概率只能跑通 Demo上不了生产。因为 RAG 不是一个单独的功能点它在 Agent 架构里扮演的是知识获取管道这个角色。它决定的是 Agent 的整个知识底座数据从哪来、怎么清洗、怎么切分、怎么索引、怎么检索、怎么把检索结果变成模型能高效利用的上下文。这也是走进 AI Agent这个系列里RAG 值得单独开一篇来写的原因。从 0 到 1 搭一个 Agent最容易被低估的往往不是模型选型而是知识侧的地基工程。这篇我把自己从理论到实战、踩过一遍坑之后沉淀的经验整理出来希望能帮你少走弯路。2. 从向量检索到Agent 知识管道搞懂 RAG 的完整链路2.1 很多人对 RAG 的误解以为它只是向量搜索 拼上下文我看过不少团队写 RAG 项目第一版的结构基本都是这样的# 伪代码简化版 RAG 的直觉写法 query_vector embed(user_question) docs vector_store.search(query_vector, top_k5) context .join(doc.page_content for doc in docs) answer llm.generate(prompt context)这个流程粗看没毛病但你会发现三个非常典型的问题第一embed(query)这个概念本身就有问题。用户的提问通常是简短的、口语化的甚至带有指代模糊比如这个功能怎么开里的这个指代什么它和知识库里的文档片段在表达风格上差距很大。拿这样的 Query 直接做向量相似度检索命中率往往不理想。第二vector_store.search只用到了一种检索策略。实际场景中很多知识库里的内容是结构化数据比如表格、配置项、JSON 字段向量检索对这种数据的召回到不了业务要求。第三检索回来的相关文档没有做精细的排序和筛选。Top 5 个片段里可能只有 2 个真正含有答案另外 3 个是噪音。模型被噪音干扰之后照样给不出高质量回答。所以我的观点是不要为了 RAG 而 RAGRAG 首先是知识管道设计其次才是检索算法选型。你要先想清楚知识是怎么流进 Agent 的再谈用什么工具来实现。2.2 一条完整的 Agent 知识管道包含哪几个环节以我自己的一个真实项目为例这个项目做的是企业内部的产品知识问答 Agent知识源包括 PRD 文档、技术方案、上线公告、客服话术手册格式有 PDF、Word、Markdown、HTML甚至还有几张 Excel 表格。整个知识获取管道我拆成了六个环节缺一个后面都要还债环节核心任务常见工具/方法数据接入Ingestion从多个数据源收集原始文档文件解析器、爬虫、API 连接器清洗转换去除页眉页脚、乱码、敏感信息正则、文档解析库、规则引擎切分Chunking把长文本切成可检索的块递归字符切分、语义切分向量化与索引把块转为向量构建索引Embedding 模型、向量数据库检索Retrieval从索引中召回候选片段向量检索、BM25、混合检索重排与组织Rerank/Context Assembly精排候选片段组装上下文Rerank 模型、上下文拼接策略你可能注意到了我特意把重排与组织单独拎出来。这恰恰是很多教程里一句话带过、但实战里影响最大的环节。2.3 检索阶段不是终点上下文组装才是真正体现功力的地方同样的检索结果给模型拼上下文的方式不一样输出质量天差地别。我做过一个对比实验同样的 Top 5 候选片段一种方式是把片段按相关度顺序直接拼接喂给模型另一种方式是先做一个答案定位——把候选片段里同时出现匹配关键词的句子提取出来再按逻辑顺序重排最后加上文档来源标记。两种方式在同样 100 个测试问题上跑出来的指标差距明显。第二种方式的准确率高出约 17 个百分点。原因不难理解模型虽然可以处理长上下文但上下文里的信息密度如果太低注意力机制容易被无关信息稀释。所以设计 RAG 管道时评估的不仅是检索好不好还有检索出来的东西模型用上了多少。3. 从 0 搭建 RAG 知识管道核心环节的选型与实操经验3.1 切分策略决定整个 RAG 效果上限的因素我在项目里花时间最多、返工次数也最多的环节不是模型调优而是文档切分。ChatGPT 刚火的那阵子很多人以为切分就是把长文本按固定长度切比如每 500 个字符切一块。后来发现这是个坑。举一个具体例子某次我处理一份 PRD 文档里面有一个功能说明表格表格的字段解释被分成了多个列。按照固定长度切分表格的字段名和字段说明很容易被切到两块里。用户问A 字段怎么填检索到的块里恰好只有字段名没有说明模型就只能瞎猜。我的切分策略后来演进成了这样结构化文档HTML、Markdown、Word 带标题层级优先用标题结构切分保证每个块内部语义完整。标题和对应的正文段落是强关联的暴力切分等于主动拆散这种关联。PDF 类文档先按页解析再结合段落间距和缩进做切分。遇到表格时尽量把表格整体保留为一个块不做行级别拆分。代码文档或配置说明按代码块切分代码和对应的注释文字放在同一个块里。长文本分块时设置重叠overlap比如每块 800 字符重叠 100 字符。这样即使答案正好落在两块的交界处检索时也能命中其中一块的完整信息。关于块大小我个人的经验值是这样的切得太小小于 200 字符检索粒度细但上下文碎片化严重模型经常拿到半句话切得太大超过 1500 字符单块内部的噪音会显著拉低命中精度。最终我压在了 600-900 字符之间再配合重叠整体表现最稳定。3.2 Embedding 模型选型性能、成本和场景的三角平衡Embedding 模型直接决定了向量检索的上限。选型时我会先问三个问题我的文档是什么语言的我需不需要对长文本做 embedding我对成本敏感到什么程度我做一个中文项目时一开始用了某个面向通用英文场景的 embedding 模型结果中文语义的召回效果惨不忍睹——同义词检索不出来因为模型训练语料里中文占比少中文语义空间压缩得不够。后来换成了针对中文优化过的 embedding 模型同样的检索逻辑召回率提升了一大截。另外要注意 embedding 的输入长度上限。有的模型单条文本上限是 512 tokens有的是 8000 tokens。如果你的 Chunk 大小在 600-900 字符那这两种模型都能覆盖但如果你的业务文档里有大段的技术规格表最好还是选长文本处理能力强的模型免得在管道里做二次截断。向量数据库的选型上我也给一个务实的建议项目早期不要上来就上分布式向量数据库。单机版的向量索引比如 FAISS、LanceDB完全能撑住百万量级以下的知识库而且部署简单、不用运维。等你的知识量真的到了千万级、需要水平扩展和增量更新时再考虑分布式方案不迟。3.3 检索方案向量检索不是唯一答案混合检索才是常态纯向量检索的短板在实务中很容易暴露。你对着一篇含大量专有名词的文档做问答用户问的可能是上次说的那个接口超时问题后来怎么修的——这种问法里几乎没有和文档有直接字面重叠的部分向量检索靠语义相似度能勉强拉回来。但如果用户问的是TIMEOUT_MS 这个参数默认值是多少向量检索会把TIMEOUT_MS和默认值分别映射到语义空间里反而不如一个简单的关键词匹配来得精准。所以我在生产环境里几乎所有项目都是混合检索向量检索负责语义召回BM25 这类关键词检索负责精确匹配最后把两种结果合并、去重再进重排。合并时要设置权重我常用的经验值是向量召回和关键词召回各占一部分比例具体数值要看领域文档的字面重叠特征来调。3.4 Rerank让检索中的第二名也有机会被翻盘Rerank 模块是我最想让刚接触 RAG 的开发者重视起来的部分。简单说Rerank 是一个专门用来衡量这段文档和当前问题是否相关的排序模型它会把向量检索回来的 Top 20 或 Top 50 个候选块逐条和问题做精细相关性打分然后重排只取最相关的前 2-3 块进上下文。为什么要专门做这一步因为向量检索的相似度计算比如余弦相似度是粗匹配它在语义空间里找的是整体相近的文本而 Rerank 是精匹配它关注的是这个块的内容是否真的包含对当前问题的答案。两者的目标函数不一样组合使用是互补关系而不是替代关系。我的实际经验是加不加 RerankRAG 回答质量的差距很多时候比换一个大模型还明显。因为大模型再聪明喂给它的上下文是错的它也只能将错就错。4. 落地过程中的三个隐形杀手元数据、数据更新与评估方法4.1 元数据RAG 项目里最容易被忽视、但价值极高的设计很多 RAG Demo 里向量数据库的存储结构就是向量 文本两列完事。但在生产环境里我一定会为每个 Chunk 挂上元数据Metadata至少包括这些字段来源文档 ID、文档标题、章节路径、文档更新时间、权限级别、Chunk 序号。元数据有什么用举个例子——权限过滤。企业内部知识库里有大量机密文档不是所有人都能查。我在检索阶段加了权限过滤条件先从用户身份信息里判断他的访问级别再在向量检索的元数据过滤条件里把高于他权限的 Chunk 全部排除掉。另一个例子是引溯源。Agent 给用户的回答如果带上了来源xxx.doc 第3节用户和业务方都会更信任。要实现这个效果必须在检索返回的 Chunk 里保留文档来源信息这就是元数据设计的价值。4.2 数据更新增量索引、删除与知识漂移问题文档会改版旧数据会作废新数据在不断产生。如果你的 RAG 管道只做了一次全量索引那第三天起知识库就失真了。增量索引是我遇到的第二个高频难点。我的做法是给每个知识源接入一个变更感知机制每天定时扫描知识源目录的文件修改时间把变更过的文件重新走一遍清洗、切分、向量化的流程对删除的文件则按文档 ID 在向量库里执行元数据过滤删除。还有一个稍微进阶一点的场景同一个知识点在不同文档里有不同版本用户问这个问题时应该参考哪个版本这里我用的是时间戳优先 版本优先级的策略——同源冲突时选较新版本不同源冲突时按知识源的可信度优先级排序比如官方 PRD 优先于客服话术。4.3 评估RAG 没有充分测试就上线等于裸奔最后这部分要重点说因为我见过太多人跑通 Demo 后就直接上线的。RAG 系统的评估指标和普通功能模块不一样它不是能不能跑通而是检索命中准不准、生成答案对不对。业界用得最多的两个指标是Hit Rate / Recall给定问题正确答案对应 Chunk 是否在 Top N 中被检索到。MRRMean Reciprocal Rank正确答案排在结果列表里的倒数位置——排第一得 1 分排第二得 0.5以此类推。我在项目里会构造一个真实的评测集至少 100 个问题每个问题标注出正确的 Chunk ID 或者标准答案。每次改动切分策略、Embedding 模型、Rerank 参数就用这个评测集跑一遍 Hit Rate 和 MRR用数据说话来决策而不是凭感觉。我第一次在评估里发现苗头不对的时刻就是调整了 Chunk 大小从 500 改成 800 之后Hit Rate 不但没升反而掉了好几个点。后面定位原因发现是某些问法本身就是短句大 Chunk 里包含太多无关段落稀释了相关性。所以参数越大越好或者越精细越好这种直观判断在 RAG 里往往不成立——一切以评测集的数据为准。5. 当 RAG 遇上 Agent多轮对话里的自适应检索策略5.1 单轮 RAG 够用多轮 Agent 场景完全不一样把 RAG 从问答机器人升级为AI Agent中的知识模块时最大的变化来自多轮对话和任务拆分。单轮问答场景里每个问题都是独立的检索时直接拿用户问题去查就行。但 Agent 场景里用户的请求往往是模糊的、多步骤的帮我看一下之前讨论过的那个方案的第三版然后跟新方案做个对比列出关键差异。这句话里有三个子任务找到之前讨论过的那个方案、定位到第三版、和新方案做对比。直接拿整句话去做向量检索召回效果会非常差。因为向量检索擅长的是单语义意图匹配而不是多语义意图拆分。正确的做法是让 Agent 先做查询改写Query Rewriting。在 Agent 的规划环节先把用户的复杂请求拆解成多个子查询每个子查询单独走一遍检索管道然后把检索结果按子任务的逻辑顺序组合起来作为上下文。5.2 让 Agent 自己决定要不要查知识库另一个关于 Agentic RAG 的核心设计问题是不是每个问题都需要查知识库。如果用户问的是你好在吗你没必要去检索一大堆文档回来占用上下文窗口如果用户问的是今天天气怎么样知识库里根本没有气象数据检索也查不到什么。我采用的策略是给 Agent 配备一个知识检索的门控模块先判断用户意图是否需要外部知识支撑。这个门控可以由一个轻量级意图分类器实现也可以让大模型自己做是否需要搜索工具的工具选择决策。只有工具触发时才真正调用检索管道否则直接走正常对话生成。这个设计看起来多了一步但实际收益非常大一方面减少了无谓的检索开销另一方面避免了检索结果太弱反而带偏模型的反效果。我在日志里观察过未加门控前模型经常把一些通用的闲聊问题也硬生生地带上根据已有资料回答显得僵硬且画蛇添足。5.3 结合 GraphRAG 与结构化知识向量检索之外的另一种可能顺带提一个近期在行业社区里讨论很多的方向GraphRAG。如果说传统 RAG 是找相关片段GraphRAG 的思路就是把知识库变成一张关系图谱通过实体与实体的关联关系做多跳推理。这个思路特别适合解决 RAG 里一个老大难问题知识割裂。举个实际场景你的知识库里有 A 文档说某系统依赖 Redis 缓存B 文档说Redis 在版本升级后默认持久化了数据C 文档说双十一大促期间缓存集群扩容规则。如果用户问双十一期间系统变更会影响缓存持久化吗这三个文档之间没有字面重复向量检索可能只在返回结果里拼出 A 文档而拼不出 A、B、C 的关联。GraphRAG 则可以通过Redis这个实体节点把三份文档都关联起来做多跳推理。不过我自己在项目里对 GraphRAG 的使用还是很克制的。原因是它的落地成本明显高于传统 RAG——需要额外的实体抽取、关系构建和图存储在当前大多数业务场景下传统 RAG 加上合理的查询改写已经能解决 80% 的问题。我会在知识之间的关系链路特别强、多跳推理成为刚需的特定领域比如医疗知识库、法规体系优先考虑 GraphRAG其他场景还是先用好传统 RAG 的底子。6. 从 RAG 到知识管道两个容易被忽略的工程硬指标6.1 延迟和成本RAG 调优的隐形约束RAG 管道看起来只是检索 生成但生产环境里的延迟和成本往往超出了预期。举一个真实的测量数据我的问答 Agent 原来一问答完整链路耗时约 4.2 秒其中生成耗时 2.8 秒、检索加 Rerank 耗时 1.2 秒。用户觉得太慢我做了三个优化把 Top K 召回从 20 降到 8、去掉了一个冗余的重排序调用、把上下文长度压缩到只需前 2 个相关块。最后整体耗时降到了 2.5 秒以内检索阶段降到 0.4 秒而回答质量经过评测集验证几乎没有下降。这件事给我的启发是检索管道里的召回数量和重排序环节是最容易被过度设计的部分。更多检索、更多重排不总是带来更好的答案但一定会带来更高的延迟和成本。做工程调优一定要有量化意识用评测集对比说话。6.2 可观测性RAG 管道必须留下审计痕迹最后一件事我会强烈建议所有做 RAG 上生产的人尽早做全链路日志和审计痕迹。RAG 系统的故障和模型幻觉不一样它往往有比较明确的可追溯性。用户回来说这个答案是错的而且错得离谱如果你日志里只有最终的模型输出排查起来基本上只能猜。但如果日志里有这些信息用户的原始问题、改写后的子查询、检索返回的 Top N Chunk 及各自的分数、Rerank 之后的排序、最终进入上下文的片段、模型最终的生成结果——那你就能很快定位出问题出在检索、重排还是生成阶段。我在项目里还发现了一个出乎意料的价值日志里的检索 Chunk 和用户真实问题的匹配情况反过来可以用来持续修正我的评测集。用户的负反馈如果出现了多次模型没找到关键信息我就把那些 case 补充到评测集里下次调参数时就有了更真实的考核标准。RAG 这个概念看着简单但从跑通 Demo到上生产稳定服务中间隔的全是细节。知识获取管道先于模型而存在它决定了 Agent 的上限。如果你打算从 0 到 1 搭建一个带知识库的 AI Agent我建议你先在建索引、切分、重排这几个环节上扎扎实实地走一遍而不要急着堆模型和框架。等到你手上有了一个能稳定评测、可观测的知识管道后面接什么模型、做什么 Agentic 扩展都会顺手很多。