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

企业级RAG系统如何避免“召回乱、查询慢”？关键在于为不同知识类型匹配合适的存储，实现精准召回与逻辑推理的结合。
核心内容：
1. 企业知识库的分层架构与不同数据库的分工
2. 四类核心业务知识（实体、关系、属性、规则）的存储策略
3. 图数据库在表达确定性业务逻辑上的关键作用

实体、关系、属性、规则如何与业务真正挂钩_{很多团队在做企业知识库时，陷入了一个误区：把所有文档塞进向量库，或者把所有知识塞进图数据库，然后发现系统要么召回乱，要么查询慢，要么答案不可信。} 

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

· · · ✦ · · ·

一、企业知识库和 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）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

正确流程应该是：

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

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

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

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

候选规则字段建议：

· · · ✦ · · ·

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

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

政策原文

客服话术

培训材料

活动说明

FAQ

投诉处理口径

营销方案

采访纪要、会议纪要

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

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

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

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

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

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

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

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

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

Step 5 — 证据回填（MongoDB）

Step 6 — 答案生成（LLM）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例如：

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

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

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

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

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

文档原文 + 版本：MongoDB

文档切片 + 语义向量：Milvus

关键词 + 产品编码：Elasticsearch

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

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

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

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

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

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

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

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

的企业知识能力。

登录查看剩余 70% 内容