对于绝大多数企业来说，内部通常已经有比较成熟的知识管理系统了，相关的产品包括飞书文档、语雀、`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` 将这些知识转换为可以按问题检索、按权限访问、按版本筛选、按证据组合并进入模型推理过程的运行时知识结构。**它解决的是企业私有知识如何进入大模型实时推理的问题，也构成了企业知识从文档系统走向模型运行时的技术接口。**

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

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

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

高级系统架构师

人工智能

数据库

企业RAG知识库的核心是将面向人阅读的文档知识，转换为面向大模型检索、组合和推理的运行时表示。它通过多路检索、元数据过滤、权限控制和上下文构造，解决文档粒度与模型检索粒度差异、跨文档证据组合及知识有效性问题，实现企业私有知识安全、精准地进入模型推理过程。

向量数据库

结构化数据

路由

2026上云采购 | AI焕新·智启新局

lexiang

ES特惠专场，新客首购5.5折起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

谈一谈企业为什么需要 `RAG` 知识库？-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐