企业级知识图谱项目之：数据库选型
——你做的项目，到底是不是完整图谱
做企业知识图谱，最容易出现一个误会：只要用了NebulaGraph/Neo4j，就以为系统已经是“知识图谱”了。但真正拆开看，我们现在这套系统更像一个阶段性架构。
它不是把所有知识都直接存进图数据库，而是让不同数据库各自承担一段能力。
一句话说：MongoDB 管原文和治理过程，Milvus 管语义召回，Elasticsearch 管关键词检索，NebulaGraph 管产销品标准实体和别名关系，Redis 管缓存。
所以当前系统最准确的定位，不是“完整业务规则知识图谱”，而是“知识库/RAG + 产销品别名图谱”。
· · · · · · · · ·
一、每个库都在存“知识”，但存的不是同一种东西
如果只问“知识存在了哪里”，答案会很乱。
因为 MongoDB、Milvus、Elasticsearch、NebulaGraph 都和知识有关，但它们解决的问题完全不同。
MongoDB：
Milvus：
Elasticsearch：
NebulaGraph：
Redis / 关系型库：
· · · · · · · · ·
二、NebulaGraph 现在主要解决“叫法不一致”
完整业务图谱里，理论上可以有很多点和边。
产品关联活动，活动适用于客群，活动生效于地域，活动有办理渠道，活动受退订规则和互斥规则约束，FAQ 依据某条规则，新政策替代旧政策。
但从当前项目情况看，NebulaGraph 主要承担的是另一件更基础的事：产销品和别名归一。
天翼云眼 → 别名 → 摄像头天翼云眼 → 别名 → 监控
千兆宽带 → 别名 → 1000M宽带
5G畅享套餐 → 别名 → 5G套餐
这件事看起来不大，但对问答命中率很关键。
用户很少按标准产品名提问。图谱先把“摄像头”归一成“天翼云眼”，再去召回相关文档，命中率会明显更稳。
三、办理条件和限制规则，大多还不在图里
这也是最容易误解的地方。
系统能回答“怎么办理”“有什么限制”“能不能退订”，不代表这些规则已经都以点和边的形式存在 NebulaGraph 里。
更可能的链路是：规则还在 MongoDB 的文档切片或抽取字段里，通过 Milvus 和 Elasticsearch 被召回，再由大模型总结成答案。
所以，NebulaGraph 现在主要不是存“办理条件、限制规则”，而是存“标准产销品和别名关系”。
这样做有现实好处：上线快、工程复杂度低、保留原文上下文，也能降低错误关系直接入图污染全局的风险。
但它也有边界：规则不能稳定计算，冲突发现能力有限，版本治理主要依赖字段控制，图谱展示也会比较薄。
· · · · · · · · ·
四、业务标签不是图谱关系
业务标签很重要，但它不是图谱关系。
比如“营销类 → 产销品 → 宽带 → 活动方案”，这是一棵分类树，不是真正的业务知识图谱。
标签是给知识定位；实体是知识里的对象；关系是对象之间的业务连接。
标签可以帮助系统选择抽取模板、辅助实体分类，也可以作为过滤条件。
但如果直接把标签层级当成图谱主关系，最后建出来的不是业务图谱，而是一棵更复杂的目录树。
五、后面应该把哪些东西逐步入图？
不是所有文档内容都需要入 NebulaGraph。
优先级应该很清楚：高频、高风险、可结构化、可复用。
P0：
P1：
P2：
· · · · · · · · ·
六、判断是否真落地，要问这几个问题
不要只问“你们用了 NebulaGraph 吗”。这个问题太浅。
真正要问的是：
NebulaGraph 里有哪些点类型？只有 Product、Alias，还是已经有 Activity、Rule、Region、Channel、CustomerGroup、FAQ？
有哪些边类型？只有 alias_of，还是已经有 applies_to、valid_in、a vailable_channel、has_rule、mutex_with？
办理条件、限制规则、互斥规则现在存在哪里？是 MongoDB 字段，还是 Rule 节点/边属性？
问答答案来自图查询，还是来自 Milvus/ES 召回后由大模型总结？
每条图谱关系能不能反查 source_doc_id、source_chunk_id 和原文证据？
如果这些问题都能答清楚，这个系统才算真正进入图谱落地阶段。否则，它可能只是一个 RAG 系统旁边接了一个图数据库。当前项目不是没有知识图谱，而是图谱层目前比较聚焦。
NebulaGraph 负责产销品实体和别名归一，RAG 负责从文档中召回办理条件、限制规则、FAQ、客服口径，MongoDB 负责保存原文、字段、标签、证据和审核状态。
这个阶段是合理的，但也要看清它的边界。
登录查看剩余 70% 内容
