做 AI Agent 的人迟早会撞上一堵墙模型把推理玩得很溜但一问到它没见过的业务细节就开始一本正经地胡诌。我之前给团队做内部问答 Agent 时最典型的场景就是同事问退款 pending 状态下一步要做什么模型回答得很流畅但流程完全是自己编的。这不是模型不够聪明而是它压根没见过我们系统里的那份退款状态说明。这篇是 AI Agent 系列的第四篇专门聊 Agent 的知识获取管道RAG 基础。前三篇我们分别聊了 Agent 的整体骨架、任务规划、工具调用今天把目光移到知识的来源。RAGRetrieval-Augmented Generation检索增强生成解决的是一个大问题模型参数是它出生时的世界而业务知识在你自己的身体里。如何把这两者接起来让 Agent 既能推理又能查证就是这条管道的核心任务。这篇文章会从原理、最小实现、检索质量指标、Agent 场景下的演化再到落地踩坑把 RAG 这条线完整过一遍。1. 为什么 Agent 需要一个知识接口1.1 模型参数是出生时的世界不是你的知识库先说一个常被忽略的事实LLM 的所有知识都来自训练时见过的数据。这意味着三件事。第一它有知识截止时间。训练完成那一刻它对这个世界的认知就冻结了。你问它昨天的系统故障、上周上线的功能它没有任何概念只能靠猜。第二它不知道你的私有知识。公司内部的 API 文档、历史项目复盘、产品手册、合同条款这些东西从来不会出现在公开语料里模型天然不知道。第三即使是公开的长尾事实它也可能记错。训练语料里某个冷门实体只出现过几次模型大概率是在编而不是在忆。做 Agent 时这些缺陷会被直接放大。因为 Agent 要完成任务不是陪聊。任务型场景对知识准确性的要求极高差一个字段就可能导致整个流程走错。你不能让 Agent 靠猜去执行任务。知识获取管道的本质就是在模型推理之前或推理过程中把外部知识检索出来、拼接进上下文让模型基于证据作答而不是基于记忆猜测。1.2 微调不是万能的RAG 才是日常主力可能有人会问那为什么不直接微调这其实是很多团队最初的想法我也走过这条路。要理解为什么 RAG 是常态、微调是特例得看清两者的分工。微调改变的是模型的行为模式和输出风格比如让模型学会按你公司的文档格式写周报、学会在回答里附带风险提示。它适合固化一种做事方式但完全不适合承载事实型知识。原因很现实微调一次要准备数据集、要训练、要评估、要上线整个周期以天甚至周计。而业务知识是高频变动的——今天改了接口参数明天新增了退款规则后天修正了某个配置的默认值。如果每次知识变动都走一遍微调光是维护成本就能拖垮一个小团队。RAG 的知识注入是改库而不是改模型文档更新了把新文档切块、向量化、写进向量库Agent 下次回答就能用到新知识。整个过程可以做到分钟级甚至做成自动管道。那么什么时候该微调我的经验是两个场景一是模型在特定任务上始终学不会你期望的格式或风格且规则很难用 prompt 描述清楚二是你希望模型对某个专业领域形成直觉比如医疗术语的读法、编程语言的代码风格迁移。但即便这样微调之后通常还要配 RAG 兜底因为事实性知识依然要实时更新。1.3 早期硬塞 prompt的做法有多痛苦在引入 RAG 之前团队最常用的土办法是把知识库内容整个塞进 system prompt。小规模验证时好像还行知识量一大就全面崩坏。我印象很深的一次某项目的知识文档整理出来大概是 80 个片段全塞进 prompt 后单次请求的 token 数直接翻了五倍延迟从 1 秒涨到 4 秒成本同步上升。更隐蔽的问题是注意力稀释——模型面对一长串背景资料开始复读prompt 里的内容而不是真正回答问题甚至会把早期提到的过时规则和后期修正过的规则混在一起输出。这个经历让我确定了技术选型方向Agent 的知识获取不能靠把库搬进 prompt必须靠检索。模型一次能吃的上下文有限而知识库可能有几十万条文档唯一可行的路径是——先精准定位再小范围投喂。2. 知识管道从零搭建两段式 RAG 的最小形态RAG 管道的完整链路可以拆成两条离线侧的索引构建和在线侧的检索生成。索引侧包含文档加载、解析、分块、向量化、入库在线侧包含查询改写、向量检索、重排序、拼接上下文、生成答案。下面按最小可用形态一条条展开。2.1 文档加载与解析上游决定下游很多新手一上来就调 Embedding、调检索但我建议先检查文档解析这一步。因为下游的一切都依赖上游给到的文本质量。以最常见的企业 PDF 文档为例你拿到的 PDF 可能是扫描件、可能是排版混乱的导出件、可能是包含复杂表格的年度报告。如果解析环节把表格结构拆坏了后面的分块和检索都是在垃圾上做优化。我的建议如下先把文档类型盘清楚PDF、Word、Markdown、HTML、Confluence 导出、数据库里的字段说明每一种的解析策略都不同。表格是最容易翻车的地方。PDF 里的表格如果用纯文本抽取行列关系会稀碎。优先用带结构识别能力的解析器比如把表格转成 Markdown 表格或 HTML 表格再入库。实测下来表格用结构化格式保留检索效果比纯文本好非常多。给每个被索引的片段打好 metadata来源文件、章节路径、更新时间、文档类型、业务线。这部分信息后面做过滤和引用溯源全都要用别偷懒。解析这一步的产出是一批干净且带元信息的纯文本块。但解析完还不能直接切先想清楚你要按什么粒度切。2.2 分块策略边界划在哪决定了检索效果的上限分块是整个 RAG 管道里最容易被低估的环节。我见过太多人直接按固定 token 数切比如每 512 个 token 一刀切完就入库。这种做法在短文档、FAQ 类语料上勉强能用但一遇到长文档就出问题。固定长度切块会把语义从中间切断。比如产品文档里写退款状态分为 pending、approved、rejected。其中 pending 表示等待财务审核……如果按固定长度切状态说明很容易被切到下一个 chunk。用户问pending 是什么意思检索到的 chunk 里只有状态列表没有解释模型就只能瞎编。更合理的做法是按语义单元切一个小节的标题连同它下面的内容作为一个 chunk一个表格作为独立 chunk一段完整的操作说明作为 chunk。同时让 chunk 保留它的上下文信息比如在内容前注入文档标题和章节路径。我常用的一种做法def parse_document_to_chunks(doc): chunks [] for section in doc.sections: # 按文档结构遍历 text f# {doc.title} {section.heading}\n{section.content} chunks.append({ text: text, metadata: { doc_id: doc.id, source: doc.source_url, section: section.heading, updated_at: doc.updated_at } }) return chunks分块的粒度也直接影响检索效果。块太大向量包含太多无关信息检索精度下降块太小单个块可能无法独立回答问题。我的经验是优先保证每个块是一个能被独立理解的语义单元而不是死守某个 token 数。FAQ 场景可以一个问答对一块操作手册按步骤分组长报告按小节切。如果有些块确实太长超过 800 token再按段落二次切分但要让子块携带父块标题。另外还有两个常用技巧一是重叠切分相邻块留 10% 到 20% 的重叠缓解边界割裂二是父文档回填检索命中子块时把父块或相邻块一并作为上下文返回保证信息完整。这两招不用一开始就上但当你发现检索到了但答案不完整时优先考虑加它们。2.3 Embedding 与向量库选型别在工具上花太多时间先跑通Embedding 的本质是把一段文字变成一个向量让语义相近的文字在向量空间里靠得近。选 Embedding 模型时要看中文能力、领域词汇的覆盖度、维度大小、能否私有化部署以及成本。我的选型经验分三档想快速验证直接用 openai 的 text-embedding-3-small效果稳定成本低中文内容占比高优先试开源的 BGE-M3 或 m3e 系列可以本地跑对中文支持很好有预算且追求上限再考虑更大的商业模型或领域微调过的 Embedding 模型。一个重要提示Embedding 模型的效果差异在领域词汇上体现得最明显。如果你做的是金融、医疗、法律这种术语密集的领域通用 Embedding 可能把两个看似相近但含义不同的术语拉得很近这时候就需要领域微调。但对于大多数场景先别折腾微调把精力放在分块和检索策略上收益更大。向量库的选择取决于数据规模和运维条件几千到几万条用 Chroma 或 FAISS 起步足够本地文件即可不需要部署服务。已有 Postgres 数据库直接上 pgvector少一个组件事务和权限都复用现有体系。数据量到百万级、有高并发或复杂过滤需求再考虑 Milvus、Qdrant 这类专用向量库。我的建议是MVP 阶段别纠结向量库Chroma 能让你把整条管道跑通后面再迁移不迟。把数据规模、过滤条件、并发量这些需求先验证清楚选型才有依据。2.4 检索从 Top-K 到可用门槛检索阶段大多数教程会让你做三步查询向量化 → 相似度 Top-K → 把结果拼进 prompt。这个流程能跑通但离可用有距离。先说 K 的选择。K 太小容易漏信息K 太大则把不相关内容塞进上下文、稀释注意力。我的默认值是 5如果知识库内容比较长或问题复杂度高会调到 8-10。但盲目调 K 不如把候选范围扩大后在重排序阶段收敛后面细说。其次是相似度阈值。向量检索本质上是一个排序问题和这个查询到底相不相关是两回事。哪怕 query 和知识库毫无关系它也会返回相似度最高的几个结果。所以一定要设阈值当最高相似度低于某个值比如 0.4 到 0.5取决于 Embedding 模型的打分分布宁可返回空让 Agent 明确告诉你知识库里没有相关信息也不要硬塞一堆不相关内容。这也是避免幻觉的重要防线。再就是利用 metadata 做预过滤。如果你的知识库有文档类型、更新时间、业务线这些字段检索前先做结构化过滤能显著提升准确率。比如用户问2025 年的活动规则那就先在 metadata 里过滤掉 2024 年的文档再做向量检索。这比纯靠语义相似度区分时间信息靠谱得多。最后说一个基础但重要的认知纯向量检索对同义改写和专有名词缩写不敏感。比如用户问订单 WAITING 状态卡住了而文档里写的是待支付状态两者的向量相似度可能并不高。这个问题靠后面的混合检索和查询改写解决但你要先知道检索不到不等于知识库没有。3. 检索质量才是 RAG 的命门Hit Rate 与调优玩法3.1 为什么盯 Hit Rate 而不是盯生成答案很多人评估 RAG 效果时直接看答案对不对。这个视角有问题因为你看到的是生成环节的最终结果它同时受检索质量、上下文质量、模型能力、prompt 设计四方面影响。一旦答案错了你很难判断是哪一环出的错。所以我把评估拆成两段先独立评估检索质量再评估生成质量。而检索质量的核心指标就是 Hit Rate。Hit Rate 的定义很直白给一组测试问题每个问题标注出标准答案所依赖的知识块跑检索看 Top-K 结果里是否包含这个知识块包含算命中最后统计命中比例。举个例子你准备了 100 条测试问题每条问题对应知识库里的一个或几个 doc_id。跑完检索后发现在 Top-5 结果里有 82 条问题命中了对应文档Hit Rate5 就是 82%。为什么这个指标重要因为它把检索环节从整个链路里独立出来了。你可以在不调用 LLM 的情况下快速迭代分块策略、Embedding 模型、检索参数观察 Hit Rate 的变化。只有检索命中率上去了调 prompt 和生成才有意义。我踩过最大的坑就是没建评测集就猛调 prompt调了半天发现答案还是错的——一查才知道是检索本身就漏了prompt 怎么调都白搭。3.2 影响 Hit Rate 的真实因素清单根据我的实测影响 Hit Rate 的因素按权重排大概是这样的因素影响方式调优方向分块质量语义被切断直接导致检索不到按语义单元切块保留标题上下文重叠切分查询与文档的措辞差异用户口语和文档书面语对不上查询改写、同义词扩展、多路查询Embedding 模型领域术语和中文支持不足换开源中文模型或领域微调检索策略纯向量检索无法精确匹配BM25 混合检索、metadata 过滤重排序Top-K 候选里相关结果被埋没扩大候选后用 cross-encoder 重排其中分块质量和查询改写这两个因素在工程实践里贡献的收益最明显。Embedding 模型的影响当然也大但在中文通用场景下从开源模型起步基本够用。重排序是最后一公里能把 Hit Rate 再往上推一截但前提是前面的分块和检索没出大问题。3.3 查询改写、混合检索与重排序的实测收益先说查询改写。用户提问通常是口语化的比如那个 Activity 系统最近咋老加载失败。文档里写的是Activity 模块启动异常排查指引两者在词汇上没有重合向量相似度也不会太高。怎么解决用 LLM 把用户原始问题改写成适合检索的查询。实际操作上我一般让 LLM 输出 2-3 个检索查询一个尽量贴近原文表达一个补全同义词一个翻译成文档可能的写法。比如用户问题Activity 系统为什么一直加载失败 检索查询1Activity 系统加载失败原因 检索查询2Activity 模块启动异常排查 检索查询3Activity loading failure然后把这三路查询分别去做检索合并结果去重后再进重排。这个操作的效果非常显著尤其是用户提问方式和文档写法差异较大的场景。代价是每次查询多调一次 LLM但可以用小型模型来做成本不高。混合检索是因为纯向量检索有盲区它对精确的实体名、缩写、代码片段、版本号不敏感。而 BM25 关键词检索恰好擅长这些。两者结合后用 RRFReciprocal Rank Fusion合并排名每个文档在两路结果里的名次都参与打分公式是 score Σ 1/(k rank_i)k 通常取 60。这样即使一路漏掉了另一路也能捞回来。重排序是收益最直观的优化。向量检索的相似度是一种粗略匹配而重排序用 cross-encoder 模型把 query 和每个候选文档重新精确比较一遍能捕捉到双塔结构容易忽略的交互信号。我的一组实测数据可以给你参考在某个内部知识库上纯向量检索 Hit Rate5 只有 0.58加上 BM25 混合检索 RRF 后提升到 0.71再把候选从 20 扩到 50、用 rerank 模型取 Top-5 拼接Hit Rate 到了 0.84。也就是说单靠检索侧的优化就能把命中率从不到六成拉到八成以上。注意一个细节重排序的候选集要足够大。如果你只取向量检索的 Top-5 再重排重排序几乎没有意义应该先混合检索取 Top-20 到 Top-50再重排取 Top-5。这一步会多花 100-300ms 的延迟但在需要准确答案的业务场景里非常值得。4. 从查一次到按需查Agent 场景中的 RAG 演化4.1 传统 RAG 与 Agent 工作流的落差传统 RAG 的用法是用户问一个问题 → 系统检索一次 → 把结果拼进 prompt → LLM 生成答案。这个模式适合单跳问答——一条问题可以通过一次检索获得答案。但 Agent 的真实任务往往是复杂的比如帮我分析一下这个月销售额下降的原因。这个问题无法通过一次检索解决。Agent 需要先了解哪几个地区、哪几条产品线在下降然后分别查询对应数据再综合判断甚至可能需要检索不止一轮先查月度销售报表得到初步线索后再追查具体的产品线明细。传统 RAG 的一次命中模式支撑不起这种多步骤任务。这就是 Agent 与传统 RAG 的核心差异传统 RAG 把检索当作回答问题前的固定动作而 Agent 需要把检索当作可随时调用的工具。至于什么时候查、查什么、查几轮应该由 Agent 根据当前任务状态动态决策。4.2 Agentic RAG 的几种工作模式Agentic RAG 没有统一标准但实践中我常用这几种模式按复杂度递增排序路由式Router先对用户输入做分类判断应该走 RAG、走数据库查询、还是直接由模型回答。比如昨天晚上系统报了什么错走日志检索2024 年全年财报走数据库简述 Transformer 结构直接模型回答。路由能避免把所有问题都塞给 RAG 导致检索垃圾进上下文。多跳式Multi-HopAgent 先执行一次检索拿到初步结果后如果发现信息不足再改写查询、检索第二轮甚至第三轮。每轮检索之间可以穿插推理。比如查某功能上线后用户投诉最多的三个原因第一轮检索拿到投诉列表第二轮基于列表里的关键词再去查对应原因。反思式ReflectionAgent 生成答案后不直接返回而是先自我检查这个答案有没有引用检索证据证据是否充分如果发现关键信息缺失主动补充检索再修正答案。这种模式能显著减少幻觉代价是增加一轮到两轮的额外调用。总结式Summarization当问题涉及大量知识块时比如把这份 50 页的研究报告浓缩成要点Agent 会把文档拆成若干部分对每部分分别检索和总结最后再汇总。这可以理解成 RAG 的并行版本。这几种模式并不是互斥的一个生产级 Agent 很可能同时具备路由、多跳和反思能力。另外这两年出现的 RAG-as-a-Service 理念也值得关注它可以理解为把知识获取能力封装成标准服务供 Agent 在运行时按需调用而不是把检索逻辑和 Agent 逻辑耦合在一起。这算是 Agentic RAG 走向工程化的一个趋势。4.3 知识割裂问题的本质与图方向另一个在 Agent 场景中会被放大的问题是知识割裂。传统 RAG 把文档切成块之后块与块之间的语义关联就丢失了。如果答案需要跨多个 chunk 的线索拼接检索就会力不从心。举个实际例子你的知识库里有一份退款流程说明另一份是风控规则明细。用户问退款金额超过 5000 元时流程有什么特殊处理。正确的答案需要把两份文档的信息拼起来但传统 RAG 可能只检索到流程说明风控规则那条信息排在 Top-5 之外模型只凭一半信息作答。解决这个问题有三个方向第一用 metadata 做关联过滤。如果两份文档都打上了退款这个业务标签检索时把标签作为硬条件可以降低跨文档漏召回的概率。这是成本最低的做法。第二用父文档结构做关联。当命中一个子块时把同一文档的相邻块或父块都取回来。这个方法能解决同一份文档内跨小节的知识割裂但对跨文档割裂无效。第三用图结构建模实体关系也就是 GraphRAG 或本体 RAG。先把文档中的实体产品、状态、部门、系统和关系抽出来构建知识图谱检索时先定位用户问题涉及的实体再沿着图关系找到关联文档。这个方向对多实体关系型问题很有效比如A 系统变更会影响哪些下游系统但代价是抽取成本高、维护复杂。我的建议是循序渐进基础 RAG 的 Hit Rate 还没达标时先别碰图方向。先把分块、混合检索、重排序做好再考虑结构化关联。GraphRAG 不是银弹它解决的是关联关系问题但解决不了基础检索就漏的问题。5. 落地中的坑与我的操作习惯5.1 没有评测集就优化等于闭眼开车这是最想说的一条经验。RAG 管道的每个环节都有参数可调——分块大小、重叠比例、K 值、相似度阈值、重排模型、查询改写 prompt。没有评测集你根本不知道改动是在变好还是变坏最后只能凭感觉调调完心里也没底。我的做法是每条知识库对应准备一批测试问题。第一轮不追求多50 条即可但必须涵盖真实用户提问的方式而不是你自己写的标准问法。给每条问题标注好它应该命中的 doc_id。之后每次改管道都跑一遍这批问题记录 Hit Rate 和端到端答案质量。有了评测集之后你会发现很多你以为的玄学优化其实都是可以量化对比的。这也是我推荐所有人做的第一件事。5.2 优化优先级先检索再生成最后调 prompt很多人一上来就调生成 prompt试图让模型更准确地从给定上下文里抽取答案。但如果检索回来的内容本身就不对prompt 写得再好也没用。我的调试顺序是先看解析和分块有没有破坏语义。再看 Hit Rate如果低于 0.8优先做查询改写、混合检索、重排序。Hit Rate 达标后再观察生成答案。这个时候如果答案还是不对才轮到 prompt 工程的事。还有一个小习惯每次检索都要记录下 query、检索到的 chunk、每个 chunk 的相似度分数、最终答案、以及用户的反馈。这样当线上出问题时你能回放完整链路定位到底哪一环出了错。没有日志排错基本靠猜。5.3 知识库的增量更新与版本管理知识库不是一次性建完就完事的。业务文档每周都在变你需要一个可重复执行的更新流程。我踩过的坑是早期全量重建每次文档一更新就要把整个库重新 embedding 一遍。文档少还好文档一多既浪费时间又浪费钱而且更新期间检索会拿到旧数据。更合理的做法是维护 document ID 级别的增量更新新增文档时只对新文档做分块和向量化文档变更时先按 doc_id 删除旧块再写入新块文档下线时对应删除。向量库基本都支持按 metadata 过滤删除关键是在写入时就打好 doc_id 标记。版本管理的另一面是旧知识保留问题。比如退款规则在 2025 年改过那 2024 年的旧规则还有参考价值吗如果完全删掉历史问题就查不到了如果保留新问题可能检索到旧规则。我的做法是在 metadata 里存生效时间检索时按当前生效过滤同时保留历史版本供特定查询使用。5.4 成本控制与资源有限时的取舍最后聊一下成本。RAG 管道的成本大头有三个Embedding 调用、向量库存储、重排序模型的推理开销。Embedding 成本很低但如果你有百万级文档且频繁全量重建账单也不小。增量更新能省一大块。重排序是延迟和算力的大头但只在查询时才跑规模可控。如果预算紧张可以先用 BM25 混合检索替代重排序虽然 Hit Rate 会差一截但至少把地基打好。向量库存储的成本反而不高真正贵的是 GPU 推理资源。如果你用开源 Embedding 和 rerank 模型一台普通的推理服务器就够支撑中等规模团队的使用如果是调用商业 API那就更省心只需要关注调用量和配额。用一个小规模项目起步时我的建议是先全部用开源模型本地跑通等验证了业务价值再考虑采购更强的模型或商业化组件。不要一上来就追求最贵的方案RAG 的瓶颈从来不在模型有多强而在数据准备和检索策略这些脏活累活上有没有下功夫。我自己在踩过一轮坑之后的体会是RAG 工程里没有银弹但有一条很明确的主线——先把 Hit Rate 管住。你如果现在正准备给 Agent 接知识库我强烈建议先拿 50 条真实问题跑一遍离线评测无论结果多难看先记录下来再开始调。知识获取管道做通容易做专业需要持续打磨等基础命中率稳定了再往多跳检索、图结构方向走也不迟。