企业知识库建设中，盲目堆砌文档往往导致系统低效。本文揭示知识分层存储的黄金法则：从主数据结构化存储到业务关系图谱构建，再到文档向量化处理，五层架构协同发力。通过电信套餐互斥规则等实战案例，详解如何让Neo4j处理确定性关系，Milvus负责语义检索，实现可治理、可追溯的企业级知识管理方案。

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

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

一、企业知识库和 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 更“炫”，而是：

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

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

• 可治理（有人工审核机制）
• 可追溯（有证据链和版本记录）
• 可复用（别名归一、节点去重）
• 可解释（答案有关系路径支撑）
• 可审计（每条关系有来源和确认记录）

的企业知识能力。