RAG 的完整知识管道
一句话收获：RAG 是知识治理与检索管道，不是一个向量数据库。
这个场景在解决什么问题
这个场景要把 RAG（Retrieval-Augmented Generation，检索增强生成）从"一个向量数据库"的误解里拉出来，讲清它其实是一条从"资料准入"到"引用验证"的完整知识管道。原文的做法是逐层点亮这条管道，并在每一层保留证据。它值得单独学，是因为很多人以为"接个向量库、跑个相似度搜索"就是 RAG，结果错误资料进去了、越检索越稳定地返回错误答案。
先理清这条判断链（文字版）
这个场景是一条"从准入到闭环"的管道：先看资料怎么准入、解析、切分，再看怎么建索引和理解查询，接着看怎么召回、过滤、重排，最后看证据怎么进入上下文、引用怎么反查、更新怎么失效。验收标准是——能不能说清"资料资格先于检索相关度、资格判断和相关度判断要分开"。
- 先看准入、解析与切分：资料先验资格，再恢复结构、形成片段。
- 再看索引与查询理解：建稠密/稀疏/结构化入口，并从任务形成查询。
- 接着看召回、过滤与重排：候选召回后按版本/权限/对象/来源过滤并重排。
- 最后看上下文、引用与更新：证据进模型、回答反查引用、资料变化刷新派生层。
逐层详解
第 1 步：准入、解析与切分
原文：资料先确认来源、版本、权限和状态，再恢复结构并形成片段。
白话：资料进库前，先确认它的来源、版本、权限、状态（有没有失效），然后恢复它的结构（比如标题、段落、表格），最后切成一个个片段。
类比：像图书馆收书——先查这本书是不是正版、是不是最新版、能不能公开借阅，再整理目录，最后才拆开放到各分类书架上。
举例：一份"2024 版退款政策"进知识库，先登记来源、确认是现行版本、确认权限允许检索，然后解析出条款结构，再切成"退款条件""退款时限"等片段。
为什么重要：错误资料进入后，后续检索越强越可能稳定返回错误——如果一开始就放进了错的资料，检索做得越好，就越"稳定地"把错答案推给你。
怎么验证（证据点）：
- 来源登记
- 结构保留
- 片段可回原文
别踩的坑（边界）：成功切分不证明资料现行——切得再整齐，也不代表这份资料还是现行有效的。
落地检查：资料资格先于检索相关度——落地时先回答"这份资料有没有资格进来（来源/版本/权限/状态）"，再谈"它跟问题多相关"。
第 2 步：索引与查询理解
原文：系统建立稠密、稀疏和结构化入口，并从任务形成查询。
白话：建索引时要建三种入口——稠密（语义向量，靠意思找）、稀疏（关键词，靠字面找）、结构化（字段过滤，靠属性找）；同时从任务里理解出"用户到底在问什么"，形成查询。
类比：像图书馆同时建三种检索卡——按主题分类的卡（语义）、按书名字母的卡（关键词）、按出版社/年份的卡（结构化字段），读者问不同问题就走不同卡。
举例：知识库既建了语义向量索引（"退款"和"退货"意思相近也能找到），又建了关键词索引（精确匹配"条款第 3 条"），还建了结构化索引（按"部门""版本""权限"过滤）。
为什么重要：不同查询信号适合不同知识类型——有的问题靠"意思像"找，有的必须靠"字面精确"找，只有一种索引会漏。
怎么验证（证据点）：
- 语义路径
- 关键词路径
- 范围过滤
别踩的坑（边界）：单一向量相似度不能处理所有企业知识——只靠"语义像不像"这一招，遇到"精确条款号""特定编码"这种查询就会翻车。
落地检查：索引要服务查询类型——落地时先盘点会来哪些查询类型，再决定建哪几种索引，别默认一个向量库打天下。
第 3 步：召回、过滤与重排
原文：候选先被召回，再按版本、权限、对象和来源过滤并重排。
白话：先召回一批候选，然后按版本（是不是现行）、权限（能不能看）、对象（是不是这个对象）、来源（可不可信）过滤掉不合格的，最后再重排顺序。
类比：像招聘筛简历——先海量召回一批简历，再按"学历门槛、工作地点、工作经验"过滤掉不达标的，最后把剩下的人按匹配度排个序。
举例：召回 20 段"退款相关"片段后，先过滤掉"已废止的旧版政策"和"当前用户无权限看的内部文件"，再把剩下的按相关度重排。
为什么重要：相关内容只有满足资格才能进入上下文——相关内容很多，但只有"又相关、又有资格"的才能进模型上下文。
怎么验证（证据点）：
- 候选可见
- 拒绝原因可见
- 最终顺序可见
别踩的坑（边界）：排名第一不证明来源最权威——重排后排第一只是"最相关"，不代表它是最权威、最现行的。
落地检查：资格判断和相关度判断分开——落地时把"够不够格"（版本/权限/对象/来源）和"相不相关"（相似度）分成两道独立判断，先资格后相关。
第 4 步：上下文、引用与更新
原文：最终证据包进入模型，回答反查引用；资料变化后刷新所有派生层。
白话：过滤重排后的最终证据包进入模型生成回答，回答要能反查回引用（哪句话来自哪段原文）；当资料变化时，要刷新所有派生出来的层。
类比：像写论文——引用的每个结论都要能查回原始文献；等原始文献出了新版，之前引用过的地方、目录、摘要都得跟着更新。
举例：客服回答"退款时限为 7 天"时，附上引用指向"2024 版退款政策第 3 条"原文；等政策更新成 14 天，旧的片段、索引、摘要都要刷新失效。
为什么重要：回答与知识生命周期需要闭环——回答要有引用可验证，知识变了要能同步失效，两头接上才算闭环。
怎么验证（证据点）：
- 引用支持结论
- 原文可回查
- 旧索引已失效
别踩的坑（边界）：引用文件名存在不证明片段支持结论——回答里挂了个文件名，不代表那段片段真的支撑了这个结论，要回到原文核对。
落地检查：RAG 完成于引用验证和更新失效——落地时把"完成"的标准定为：引用被验证确实支持结论、且资料更新后旧派生层已失效。
落地可行性小结
本场景涉及的技术栈：RAG 管道，包括资料准入（来源/版本/权限/状态校验）、解析与切分、多种索引（稠密向量、稀疏关键词、结构化字段）、查询理解、召回/过滤/重排、引用验证、更新失效。真实落地做法：把 RAG 当成多阶段流水线，每阶段留证据（候选、拒绝原因、最终顺序、引用）；先做资料资格校验，再建多路索引，召回后先过滤资格再重排。要检查的：资料是否登记版本和权限、过滤是否在进入上下文前执行、引用是否能回查原文、更新是否穿透派生层。常见坑：只接向量库不做治理、资格与相关混在一起、引用只挂文件名不核对、资料更新后旧索引不失效。
回顾
- RAG 是一条知识治理与检索管道，不是一个向量数据库。
- 资料资格（来源/版本/权限/状态）先于检索相关度。
- 索引要服务查询类型：稠密、稀疏、结构化多路入口。
- 资格判断和相关度判断要分开，先过滤资格再重排。
- RAG 的完成在于引用验证 + 更新失效的闭环。