谈一谈企业为什么需要 `RAG` 知识库？

谈一谈企业为什么需要 `RAG` 知识库？需要先看清适用场景和关键步骤，避免只记结论却忽略实际限制。

对于绝大多数企业来说，内部通常已经有比较成熟的知识管理系统了，相关的产品包括飞书文档、语雀、`Confluence`、企业 `Wiki`、网盘以及各种业务文档平台。这些系统已经能够完成 **知识创建、协作编辑、目录组织、权限管理、版本维护和内容共享**。

从知识管理角度看，企业并不缺少保存知识的系统，真正发生变化的是**大模型成为新的知识消费者**之后，原有知识系统缺少 /一套面向模型推理过程的知识访问机制/ 。`RAG` 解决的正是这一问题，它将外部知识检索引入大模型生成过程，在模型处理问题时动态获取企业内部知识，并将相关内容构造成当前推理所需的上下文。

因此，企业建设 `RAG` 知识库的技术目标，可以定义为： /将面向人组织和阅读的企业知识，转换为面向模型检索、组合和推理的知识表示，并提供稳定的检索运行机制/ 。

# 一、企业知识库与 `RAG` 的边界

传统企业知识库的核心对象是文档。一个知识空间通常由目录、页面、附件、标签和权限构成，用户通过目录浏览、全文搜索或者组织经验定位到目标内容，再通过阅读和理解完成知识获取。这套模式建立在人的认知能力之上。用户可以判断文档标题，可以理解章节结构，可以识别新旧版本，也可以根据上下文判断某一段话是否适用于当前业务问题。

大模型使用企业知识时没有这些隐含能力。模型接收到的是有限长度的上下文，系统需要在推理开始之前决定哪些知识应该进入上下文、这些知识来自什么版本、是否具备访问权限、多个片段之间是否存在重复或冲突，以及当前问题是否已经获得足够的证据。因此，在原有企业知识系统和大模型之间，需要增加一层专门的知识访问系统。

这一层可以理解为 `Knowledge Retrieval Runtime`；它不负责知识生产，也不承担企业内部知识协同，而是负责把已有知识转换成模型运行时可以使用的证据。企业知识系统继续保存原始文档，`RAG` 系统保存文档的检索表示，包括结构化片段、向量表示、倒排索引、元数据、版本信息、权限信息和实体关系。两者之间形成来源系统与派生系统的关系。

从系统链路看，原始知识首先进入解析和结构化阶段，随后形成适合检索的知识单元，并建立多种索引；用户问题进入系统后经过查询理解、检索、重排和上下文构造，最终形成提供给大模型的证据集合。`RAG` 的主要工作集中在知识源与模型之间，其核心任务是完成 “问题到证据” 的转换。

# 二、文档粒度与模型检索粒度之间的差异

企业知识通常以完整文档为单位进行组织，而大模型处理问题时需要的是与当前问题直接相关的局部知识。两种粒度之间存在明显差异。例如一份几十页的设备检修手册在知识管理系统中是一个完整对象，其中包含设备结构、运行条件、故障定义、检查步骤、安全要求和维护标准。用户提出 *“主轴振动超过一级报警后首先检查什么” *时，大模型需要的是与报警条件、检查顺序和适用范围相关的几个局部片段。将整份文档直接交给模型，会增加上下文长度和无关信息；按照固定字符长度机械切分，又可能破坏章节语义和上下文关系。因此，`RAG` 系统需要重新定义知识的检索单元。文档进入系统之后，首先需要解析 **标题、章节、段落、表格、列表和附件关系，然后基于结构和语义形成 `Chunk`**。一个完整的 `Chunk` 通常不仅包含正文，还需要保存文档标识、标题路径、章节位置、父级节点、前后相邻节点、版本号、更新时间、来源地址和权限信息。这样，当系统检索到某个局部片段时，可以根据父子关系和邻接关系恢复必要上下文。这类设计使 `Chunking` 从简单的文本切割转变为知识结构转换。对于制度、规范和技术手册，标题层级通常具有较高的信息价值；对于表格，表头和数据行需要保持关联；对于操作步骤，顺序关系不能被打散；对于问答型知识，可以将问题和答案作为一个检索单元。不同知识类型需要不同的切分策略。因此，企业 `RAG` 的第一项基础能力是建立面向检索的知识表示。原始文档面向阅读，`Chunk` 面向召回，最终的证据集合面向模型推理，这三个对象具有不同的系统职责。

# 三、企业知识检索需要多种检索机制协同

向量检索能够解决自然语言表达差异带来的语义匹配问题，但企业知识中还包含大量精确对象，例如设备型号、接口名称、错误码、制度编号、版本号、项目名称和专业缩写。这类信息对词面匹配的依赖很强，单一向量相似度难以覆盖全部检索需求。企业 `RAG` 因此通常需要同时保留关键词检索和语义检索。`BM25` 用于处理精确词项、编号和专业术语，`Dense Retrieval` 用于处理自然语言语义近似，`Sparse Retrieval` 用于在词项和语义表示之间建立更细粒度的匹配能力，元数据过滤用于限定时间、文档类型、业务领域、组织范围和有效状态，实体检索用来处理设备、项目、人员、组织和系统之间的明确关联。用户查询进入系统后，需要首先完成查询理解。系统需要识别问题中的核心实体、时间条件、领域范围和查询意图，并决定采用哪些检索通道。例如错误码查询更依赖关键词和字段匹配，故障现象描述更适合语义检索，制度查询需要结合生效时间和正式状态过滤，跨项目关系问题则可能需要额外查询结构化数据或图关系。多个检索通道返回候选结果后，需要执行结果融合。关键词检索与向量检索的分值不处于同一尺度，直接比较没有实际意义，因此常见做法是使用 `RRF` 或归一化后的加权融合获得统一候选集合。召回阶段的目标是提高覆盖率，最终进入模型上下文的内容还需要经过 `Rerank`。重排模型同时读取查询和候选文本，对候选结果进行更精细的相关性判断，用于从较大的召回集合中筛选最终证据。从检索链路看，企业 `RAG` 更接近一个分阶段搜索系统： /查询理解负责定义检索任务，多路召回负责扩大候选范围，融合负责合并不同检索信号，重排负责提高局部精度，后续上下文构造负责决定哪些内容最终进入模型。/ 向量数据库只承担其中的一个索引能力。

# 四、检索排序需要考虑知识有效性

**企业内部知识具有明显的生命周期和权威性差异**。相同主题下可能同时存在正式制度、历史版本、征求意见稿、会议纪要、个人总结和业务实践记录。从文本语义看，这些内容都可能与用户问题高度相关，但从业务有效性看，其可信程度和适用范围存在差异。例如用户询问当前差旅住宿标准时，系统可能同时召回多个年份的制度文件和部门内部经验说明。如果排序仅依赖语义相似度，旧版本或者非正式材料可能排在当前正式制度之前。企业 `RAG` 因此需要将知识元数据纳入检索排序过程。可以将一个知识片段的最终排序分数理解为多个信号的组合，其中包含语义相关性、关键词匹配程度、来源权威性、知识时效性、结构位置和业务适用范围。语义相关性决定内容与问题是否接近，关键词匹配解决编号和专业词项，来源权威性反映正式制度与一般记录的差别，时效性处理新旧版本关系，结构信息用于识别标题、正文、附录和引用之间的差异。这意味着企业 `RAG` 的知识模型需要保存比向量更多的信息。每份文档至少需要明确来源系统、文档类型、发布主体、正式状态、生效时间、失效时间、版本关系、适用组织和责任人。对于存在替代关系的文档，还需要明确当前版本与历史版本之间的关联。检索阶段使用这些信息进行过滤和排序，生成阶段才能获得稳定的知识依据。因此，企业知识治理中的一部分元数据会直接进入检索运行时。原来用于文档管理的属性，在 `RAG` 中进一步成为检索算法的输入。

# 五、跨文档问题需要从检索扩展到证据组合

单一事实类问题通常可以通过一次检索获得答案，但企业中的复杂问题经常涉及多个知识源。例如分析某个项目延期原因时，相关信息可能分散在需求变更记录、项目周报、会议纪要、测试报告和资源排期中。任何一个文档都只能提供局部事实，完整答案依赖多个证据之间的组合。这类查询对 `RAG` 提出了第二层要求，即系统需要处理多跳检索和证据覆盖问题。一个复杂问题可以先被拆分成多个子问题，再分别进行检索。例如“项目为什么延期”可以拆分为需求是否变化、开发周期是否变化、测试是否受阻、资源是否调整、外部依赖是否延迟等子问题。每个子问题对应不同的知识源和检索策略，最终结果在上下文阶段重新组合。对于具有显式关系的数据，还可以引入图结构。项目依赖、设备拓扑、组织关系、事件链和知识引用关系都适合使用图模型表示。向量检索擅长发现语义相似内容，图检索擅长沿确定关系查找关联对象，两者解决的问题不同。企业 `RAG` 可以根据问题类型在文本索引、图索引和结构化数据库之间进行路由。随着问题复杂度提高，检索目标也会发生变化。系统需要判断当前证据是否覆盖问题中的主要信息，是否存在相互矛盾的来源，是否仍需追加检索，以及哪些证据可以合并。此时 `RAG` 的运行机制已经从单次相似度查询扩展为面向任务的检索过程。

# 六、上下文构造决定最终进入模型的知识质量

检索结果不能直接等同于模型输入。检索阶段通常会返回多个候选片段，其中可能存在重复内容、不同版本、局部语义和缺失的结构信息。如果将 `TopK` 结果直接拼接到 `Prompt`，模型会面对大量冗余和冲突内容，最终答案质量会受到影响。因此，在检索与生成之间需要一个独立的 `Context Construction` 阶段。这个阶段首先处理重复内容，同一段知识可能被多个文档引用，也可能因为不同切分窗口形成近似片段。随后需要恢复结构信息，例如命中表格中的一行时补充表头，命中正文片段时补充父级标题和必要的前置条件。对于来自同一文档的连续片段，可以重新合并成更完整的上下文。版本和冲突处理也发生在这一阶段。系统可以根据生效时间和权威等级保留当前有效内容，同时对存在明显矛盾的知识进行标记。对于复杂问题，不同来源的证据需要按照时间、实体、因果关系或者子问题重新组织，使模型能够理解证据之间的关系。最后还需要满足模型上下文长度约束。检索系统可能返回几十个高相关片段，但模型可用于知识上下文的 `Token Budget` 是有限的，因此系统需要在相关性、覆盖度、权威性、时效性和冗余度之间进行权衡。最终目标是选出一组能够最大程度支持当前问题的证据集合，并控制其总长度。这一阶段决定了企业 `RAG` 的实际效果上限。高召回率只能说明相关内容被找到了，最终答案是否稳定，还取决于这些内容能否被正确组合成模型可以理解的上下文。

# 七、权限属于检索模型的一部分

企业知识具有严格的访问边界，因此权限信息需要进入检索过程本身。用户可访问的知识集合决定了系统实际执行检索的范围，后续的向量搜索、关键词搜索、重排和上下文构造都应基于这个范围进行。用户发起查询后，系统需要解析其身份、部门、用户组和角色，并将这些信息转换为 `ACL Filter`。过滤条件可以在索引查询阶段直接生效，也可以通过独立权限服务计算可访问对象集合。对于高敏感知识，还可以在候选返回后进行二次鉴权，以保证权限变更能够实时生效。权限前置的原因与检索质量和安全性都有关系。如果先从全量知识中召回，再在输出阶段过滤，无权限文档会占用 `TopK` 候选位置，降低实际召回率；同时，无权限内容还可能进入重排模型、缓存、日志或者模型上下文。权限作为查询条件参与检索，可以从源头限制候选空间。因此，企业 `RAG` 中的 `ACL` 与关键词、向量、时间和文档类型一样，都是检索条件。不同用户提出同一个问题时，由于可访问知识集合不同，最终的证据集合和生成结果也可能不同。

# 八、企业 `RAG` 知识库可以理解为知识的运行时表示

** /从技术体系看，企业原有知识系统保存的是知识原本，`RAG` 保存的是知识的运行时表示/ **。一个原始文档进入 `RAG` 后，会派生出结构化片段、倒排索引、向量表示、实体关系、版本信息、权限映射和检索元数据。这些派生结构共同形成模型访问企业知识所需要的基础设施。因此，同一份知识可以同时存在多个表示层次。原始文档负责完整性和阅读体验，检索表示负责快速定位，任务视图负责限定特定业务场景下的知识范围。部门、团队或者个人知识库可以通过 `Knowledge View` 实现，它根据知识来源、权限、业务领域、元数据和检索策略动态定义可见范围，不需要重复保存相同文档。企业建设 `RAG` 知识库所增加的技术能力集中在这一链路中。原有知识系统提供知识来源，`RAG` 将这些知识转换为可以按问题检索、按权限访问、按版本筛选、按证据组合并进入模型推理过程的运行时知识结构。**它解决的是企业私有知识如何进入大模型实时推理的问题，也构成了企业知识从文档系统走向模型运行时的技术接口。**","createTime":1786435592,"ext":{"closeTextLink":0,"comment_ban":0,"description":"","focusRead":0},"favNum":0,"html":"","isOriginal":0,"likeNum":0,