很多团队在做企业知识库时，陷入了一个误区：把所有文档塞进向量库，或者把所有知识塞进图数据库，然后发现系统要么召回乱，要么查询慢，要么答案不可信。
问题的根源不是工具选错了，而是没想清楚每类知识该以什么形式存在哪里。
· · · ✦ · · ·
一、企业知识库和 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 更“炫”，而是：
让知识不只是能被检索到，还能被治理、被校验、被追溯、被复用。
最终目标不是建一个很大的图，而是建立一套：
可治理（有人工审核机制）
可追溯（有证据链和版本记录）
可复用（别名归一、节点去重）
可解释（答案有关系路径支撑）
可审计（每条关系有来源和确认记录）
的企业知识能力。
