08-RAG知识库从文档分块、嵌入、混合检索到Agentic RAG智能体化检索《深入理解AI Agent设计原理与工程实践》系列读书笔记 第8篇关键词RAG、Chunking、稠密/稀疏嵌入、混合检索、Rerank、结构化索引、Agentic RAG我们无人售货柜项目攒了 400 多页售后文档柜机维修手册、支付对账说明、补货 SOP、常见故障案例库。最初的做法是把它们全喂给模型做微调——效果惨烈模型记住了名词答不准数字文档一更新就得重训。后来换 RAGRetrieval-Augmented Generation检索增强生成一句话总结它的价值与其让模型背书不如给模型开卷考试。这一篇把 RAG 从基础管道一路讲到 Agentic RAG。一、RAG 基础管道分块 → 嵌入 → 检索 → 生成RAG 的标准流程离线阶段把文档切块、向量化、建索引在线阶段拿用户问题检索出相关片段拼进上下文让模型生成答案。四个环节每个都有讲究。1.1 文档分块Chunking分块是把长文档切成适合独立检索的片段。为什么必须分两个原因其一检索粒度——用户问电磁锁坏了怎么修你希望返回的是半页排障步骤不是 300 页整本手册其二上下文预算——塞整本文档既装不下也稀释注意力。常见三类策略固定长度分块按字数硬切实现最简单。缺陷是割裂语义一句话从中间断开两半都残废结构感知分块按文档天然结构切——章节、小节、Markdown 标题。我们的维修手册就是按故障现象 → 排查步骤 → 备件清单的段落切检索命中率高很多语义分块用嵌入模型判断语义边界在话题转换处切分效果最好、成本最高。分块有个固有缺陷必须先点破分块切断了片段与原始上下文的联系。该故障需要更换该型号电磁锁里的该指什么留在了块的外面。对策是重叠分块相邻块留 overlap和给每块补充元信息设备型号、文档章节路径后文上下文感知检索会正面接这个问题。1.2 稠密嵌入从词汇关联到语义理解稠密嵌入Dense Embedding用深度学习把文本映射成高维向量语义相近的内容向量距离也近。经典例子“男人-女人的向量差约等于国王-女王”向量运算能捕捉语义关系。技术上从早期的 Word2Vec词级共现统计演进到 BERT上下文相关再到如今的大规模嵌入模型国王在国王加冕和国王餐厅里能拿到不同向量一词多义得以区分。稠密检索的杀手锏是同义改写鲁棒性用户问柜机门弹不出来知识库里写的是电磁锁故障导致柜门无法开启——没有任何字面重叠稠密向量依然能把两者拉近。这是关键词检索永远做不到的。1.3 稀疏嵌入精确匹配的关键词检索稀疏嵌入Sparse Embedding根植于传统信息检索BM25 就是代表核心是关键词精确匹配向量维度是词表长度、绝大多数维度为零故名稀疏。它解决稠密的短板专有名词、型号、错误码。用户报V12 版本 App 报错 E-1042稠密模型可能把E-1042糊成错误的语义邻居稀疏检索却能一字不差地锁定知识库里写有 E-1042 的那一页。一句话对比稠密读得懂意思但认不准字符稀疏认得准字符但读不懂意思搜kitty找不到只写cat的文档——各有死穴所以有了混合检索。1.4 混合检索两全其美的艺术混合检索的思路朴素两个引擎都跑结果做融合。典型流水线三阶段召回稠密检索和稀疏检索并行各取 Top-N 候选融合常用 RRFReciprocal Rank Fusion倒数排名融合把两路结果合成统一候选池不依赖两边的分数尺度可比重排序Rerank对候选池前 50 名逐一精细打分产出最终排序。重排序值得单独强调它不是为了补救 RRF 丢的分而是换用了更强的匹配范式。召回阶段的双编码器Bi-encoder是查询和文档各自独立编码再比距离快但糙重排序器是跨编码器Cross-encoder让查询和候选文档面对面逐字斟酌后给分慢但准如 BAAI/bge-reranker-v2-m3。所以标准姿势是粗筛用便宜的双编码器扫全库精排用跨编码器只啃前 50 条——召回管别漏重排管排准。我们售后知识库上混合检索的实测纯稠密 hit5 约 78%加稀疏与 RRF 融合到 86%再加重排序到 93%。错误码类问题几乎全靠稀疏那一路救回来的。二、超越扁平文本结构化索引扁平的切块向量是把知识库当一堆散页检索是从信息检索找文本到知识建模理解实体关系的跃迁。2.1 从信息检索到知识建模知识图谱把知识表示为三元组主语-关系-宾语“电磁锁” -属于- “V系列柜机”、“E-1042” -指示- “网络模块离线”。它的原生强项是实体消歧知识库里有两个张工硬件张工、软件张工在图里是两个节点靠各自的关系边区分无需额外推理——上一讲的 Advanced JSON Cards 靠 person/relationship 字段硬扛的问题图结构天生解决。另一个强项是多跳推理这个故障影响哪些型号→ 沿关系边两跳即得答案文本检索对此基本无解。代价是构建与维护成本高适合医疗、法务这类垂直深水区。2.2 文件系统范式用目录结构组织知识不是所有场景都值得上图数据库。书里给了个工程上很讨喜的中间路线把知识库组织成带语义的目录树像维护代码仓库一样维护知识售后知识库/ ├── 硬件故障/ │ ├── 电磁锁/ │ ├── 制冷系统/ │ └── 屏显模组/ ├── 支付对账/ │ ├── 微信支付/ │ └── 差错处理SOP.md └── 补货运营/目录路径本身就是知识检索结果带上路径硬件故障/电磁锁/锁体卡死.md模型立刻获得定位上下文前文分块切断上下文的缺陷被部分补回而且 Agent 可以像ls一样按目录浏览知识库检索工具和文件工具打通。2.3 知识如何更新知识库不是建完就完。可审计的更新机制新文档进库走分块-嵌入-索引流水线过时内容不是悄悄删而是像 Git 一样版本化——知识变更当成 PR可回滚、可追溯这条结论出自哪个版本的文档。我们的故障案例库每周新增真实工案同时淘汰已被固件更新解决的旧方案没有版本机制的RAG库半年后就开始用去年的答案回答今年的问题。三、Agentic RAG让检索决策本身智能化传统 RAG 是死管道来了问题 → 无脑检索 → 拼上下文 → 生成。三个固有缺陷该检索时不检索模型硬答、不该检索时乱检索浪费、检索词不等于真实需求用户口语 vs 文档术语。Agentic RAG 把检索从固定步骤变成模型的工具让 Agent 自主决定何时检索、检索什么、结果够不够好、要不要换个关键词再来一轮用户机器吞了我五块钱没出货 Agent 内部推理 1. 判断这是具体故障需要事实支撑 → 决定检索 2. 改写口语吞钱 → 检索词支付成功 出货失败 处理流程 3. 评估首轮结果只有补货文档不够 → 换词支付差错 退款再检索 4. 综合拿到SOP调用退款工具回复用户关键能力差异管道式 RAG 检索一次定生死Agentic RAG 是检索-评估-再检索的循环还会把上下文感知注入检索——比如自动带上设备型号、App 版本号作为过滤条件这就是上下文感知检索用当前会话已知信息收窄搜索空间。从数据集中提取深度知识是 Agentic RAG 的进阶玩法让离线 Agent 啃完整历史工单数据集抽取故障现象-根因-解决方案三元组沉淀进知识库——数据集本身不是知识从中蒸馏出的结构化因果才是。多模态记忆是前沿方向售后场景里用户上传的是故障照片和短视频多模态嵌入让这张屏显花屏的照片直接检索到屏线接触不良的图文案例。目前实用化的还停留在图文对齐检索但方向明确记忆不该只有文本一种格式。小结RAG 基础管道四件套分块结构感知优于固定长度、稠密嵌入懂语义、稀疏嵌入认字符、混合检索RRF 融合 Cross-encoder 重排结构化索引是从找文本到懂知识的跃迁知识图谱解决消歧与多跳文件系统范式用目录树提供轻量级结构知识更新要版本化像管代码一样管知识库Agentic RAG 把检索变成工具自主决定何时检索、改写查询、评估结果、循环逼近上下文感知检索带业务上下文收窄搜索和多模态记忆图文检索是落地增效最快的两个方向。至此提示工程、状态栏与压缩、记忆系统、RAG 知识库——上下文工程的四大支柱就齐了。剩下的功课是在真实业务里把它们拧成一套系统。