企业级 RAG 的知识分层：实体、关系、属性与规则如何落库

很多团队在做企业知识库时，陷入了一个误区：把所有文档塞进向量库，或者把所有知识塞进图数据库，然后发现系统要么召回乱，要么查询慢，要么答案不可信。 

问题的根源不是工具选错了，而是没想清楚每类知识该以什么形式存在哪里。

· · · ✦ · · ·

一、企业知识库和 RAG 系统分层

这五层不是竞争关系，而是分工。

例如用户问：

上海用户办理 5G畅享199 后，还能不能叠加宽带融合优惠？

Milvus 可以召回相关政策、活动说明和客服口径。

但 Neo4j / NebulaGraph 才适合查询：

5G畅享199套餐 --互斥--> 老融合优惠
宽带融合优惠 --适用客户群--> 新装用户
宽带融合优惠 --适用区域--> 上海
宽带融合优惠 --生效时间--> 2026年7月1日到2026年12月31日
规则A --来源于--> 政策文档B

这些是确定性业务关系，不能只靠向量相似度判断。

二、知识分类

企业的业务知识大致分为四类，存储方式完全不同。

第一类：主数据与实体（必须结构化，进图数据库）

这是业务的骨架，是所有问答的起点。

产品（套餐、服务、商品）

产品编码、标准名称

别名（用户说的非标准叫法）

权益（套餐包含的内容）

活动（促销、优惠、限时政策）

客户群（新装用户、存量用户、企业客户）

区域（省市分公司、渠道区域）

渠道（线上营业厅、实体营业厅、客服热线）

这些内容的特点是：稳定、有唯一标识、可复用、需要精确命中。

不能只存成文档切片，因为文档是“某一份政策里写了这个产品”，但主数据是“这个产品在整个系统里是谁”。

推荐存入：Neo4j / NebulaGraph 图数据库，作为节点（Node）。

第二类：关系（业务规则的骨架，进图数据库）

关系是图数据库真正发挥价值的地方。企业业务中，关系不是模糊的，而是确定的。

包含：套餐包含哪些权益。例：5G畅享199 → 包含 → 100G流量包。

互斥：两个优惠不能同时享受。例：5G畅享199 → 互斥 → 老融合优惠。

适用：活动适用哪些客户群。例：宽带融合优惠 → 适用于 → 新装用户。

依赖：办理条件依赖什么。例：宽带融合优惠 → 依赖 → 宽带在网状态。

来源于：规则出处。例：规则A → 来源于 → 政策文档B。

别名是：非标准名称与标准名称映射。例：“畅享199” → 别名是 → 5G畅享199套餐。

限制于：地域或时间限制。例：活动C → 限制于 → 上海区域。

覆盖：新规则覆盖旧规则。例：规则2026版 → 覆盖 → 规则2025版。

这些关系是业务的真实逻辑，无法从语义相似度中推断出来。

向量库可以找到“和这份文档内容相似的文档”，但它不知道两个产品是否互斥。

推荐存入：Neo4j / NebulaGraph 图数据库，作为边（Edge）。

第三类：属性（节点和边上的限定条件）

每个实体和关系都有属性，属性是做过滤和判断的关键。

实体节点属性示例（以产品为例）：

     product_id: P1000199
     canonical_name: 5G畅享199套餐
     aliases: ["畅享199", "199融合", "5G 199套餐"]
     product_code: P1000199
     status: 生效中
     launch_date: 2025-01-01
     valid_regions: ["上海", "浙江", "江苏"]
     channels: ["线上营业厅", "客服热线"]   

关系边属性示例（以互斥关系为例）：

     relation_type: conflicts_with
     subject: 5G畅享199套餐
     object: 老融合优惠
     region: 上海
     valid_from: 2026-01-01
     valid_to: 2026-12-31
     confidence: 1.0（人工确认）
     source_doc_id: policy_doc_202601
     confirmed_by: 业务负责人A
     confirmed_at: 2026-03-15   

属性的核心价值是做查询时的过滤条件。

如果没有属性，查出来的关系是“全局的”，不知道这个互斥规则是否在上海生效、是否还在有效期内。

有了属性，查询就可以是：

    查 5G畅享199 在上海当前生效的互斥关系，且经过人工确认的。

第四类：规则（从文档里来，但不能直接进图）

这是企业知识里最难处理的部分。

规则通常藏在文档里，表现形式是：

“新装宽带用户不可重复享受老融合优惠”

“合约期内退订需收取违约金”

“活动期间叠加权益包，需在线上渠道办理”

“仅限上海、浙江、江苏区域生效”

这类规则有时间限制、区域限制、渠道限制、客户群限制，而且可能随政策更新而变化。

错误做法是：让模型直接从文档抽取，然后写入图数据库。

正确流程应该是：

文档原文 → 模型抽取候选规则

记录候选关系（含置信度、证据片段、来源文档）

进入候选池（待确认状态）→ 业务人员审核

确认后写入 Neo4j / NebulaGraph 正式图谱 → 保留版本记录和审计记录

候选规则字段建议：

     候选关系 ID
     subject（主体）
     predicate（关系类型）
     object（客体）
     置信度
     来源文档 ID
     证据原文片段
     抽取时间
     状态：待确认 / 已确认 / 已驳回
     确认人
     确认时间
     备注   

· · · ✦ · · ·

三、弱结构文档：不要强行抽成图

企业里有大量文档，根本就不适合直接进图数据库：

政策原文

客服话术

培训材料

活动说明

FAQ

投诉处理口径

营销方案

采访纪要、会议纪要

这些内容的特点是：语言自然、颗粒度不一、结构不稳定，但它们是系统回答问题的“原始证据”。

这类内容的正确处理方式：

     文档 → 切片（chunk）→ 向量化 → 存入 Milvus

     同时保留：
     原文存入 MongoDB
     文档状态、版本、上传时间、所属业务域等元数据
     切片与产品/活动/规则节点的关联 ID   

这样，Milvus 负责语义检索，MongoDB 负责原文回填，而切片本身通过 ID 与图谱里的产品、规则建立引用关系。

四、查询链路：五层如何协同工作

用一个具体例子说明整条链路：

用户问题：上海用户办理 5G畅享199 后，还能不能叠加宽带融合优惠？

Step 1 — 意图识别 + 实体提取（LLM）

     产品：5G畅享199
     区域：上海
     动作：叠加办理
     目标：宽带融合优惠
     关注点：互斥限制、办理条件   

Step 2 — 别名归一（Neo4j / NebulaGraph）

     “畅享199” → 标准产品 ID：product_5g_199
     “宽带融合优惠” → benefit_broadband_bundle   

Step 3 — 向量召回（Milvus + ES）

     召回相关政策原文、活动说明、客服口径
     过滤条件：region=上海, status=生效中, channel包含线上   

Step 4 — 图谱关系扩展（Neo4j / NebulaGraph）

     以 product_5g_199 为起点，查询：
     → conflicts_with 关系（互斥）
     → applies_to 关系（适用客户群）
     → requires 关系（办理条件）
     → valid_in 属性过滤（上海，当前生效）

     查出：
     5G畅享199 → 互斥 → 老融合优惠（上海，生效中）
     宽带融合优惠 → 适用于 → 新装用户
     宽带融合优惠 → 依赖 → 宽带在网状态   

Step 5 — 证据回填（MongoDB）

     找到政策文档原文片段：
     “5G畅享199套餐面向上海新装融合用户，不可与老融合优惠重复享受...”  

Step 6 — 答案生成（LLM）

     如果该用户已享受老融合优惠，则不能叠加宽带融合优惠。
     原因：5G畅享199与老融合优惠存在互斥关系（上海区域，2026年全年生效）。
     如用户为新装宽带用户且宽带在网，则满足宽带融合优惠的办理条件，可以单独办理。
     依据：政策文档A 第3条。   

五、什么情况下不该上图数据库？

并非所有 RAG 项目都需要图数据库。以下情况可以暂缓：

知识量少，关系不复杂，全靠文档语义检索就能满足；

业务规则频繁变化、尚未稳定，图谱很快就会过期；

团队缺乏运维 Neo4j / NebulaGraph 的能力；

没有人工审核机制，关系质量无法保证。

如果以上条件都符合，可以先用 Milvus 做轻量化的 Vector Graph RAG：

把实体、关系、文档切片都向量化，通过 ID 引用串联，待关系稳定后再逐步沉淀到 Neo4j / NebulaGraph。

六、一个容易踩的坑：让模型直接生成图查询语句

很多团队尝试让大模型根据用户问题，自动生成 Cypher（Neo4j 查询语言）或 nGQL（NebulaGraph 查询语言）。

这在 Demo 阶段很流畅，但在生产环境容易出问题：

模型生成的查询语句可能引用不存在的边类型；

变长路径查询没有剪枝，容易路径爆炸；

模型不了解图谱的实际数据分布，查出空结果或超大结果集；

每次生成的查询不一致，难以调试和监控。

推荐做法是：预定义查询模板，让 LLM 负责填参数，而不是生成查询本身。

例如：

     查询模板：
     查找产品 {product_id} 在区域 {region} 的所有互斥关系，过滤条件：生效中，人工确认。

     LLM 只需要识别：
     product_id = product_5g_199
     region = 上海   

这样既保证查询稳定，又降低图数据库的风险。

七、总结：企业知识分层存储原则

主数据 + 标准实体：Neo4j / NebulaGraph（节点）

确定性业务关系：Neo4j / NebulaGraph（边 + 属性）

候选关系（待确认）：候选池（MongoDB 或专用表）

文档原文 + 版本：MongoDB

文档切片 + 语义向量：Milvus

关键词 + 产品编码：Elasticsearch

LLM：意图理解 + 关系抽取 + 答案生成

图数据库（Neo4j / NebulaGraph）真正的价值，不是让 RAG 更“炫”，而是：

让知识不只是能被检索到，还能被治理、被校验、被追溯、被复用。

最终目标不是建一个很大的图，而是建立一套：

可治理（有人工审核机制）

可追溯（有证据链和版本记录）

可复用（别名归一、节点去重）

可解释（答案有关系路径支撑）

可审计（每条关系有来源和确认记录）

的企业知识能力。