——你做的项目，到底是不是完整图谱

做企业知识图谱，最容易出现一个误会：只要用了NebulaGraph/Neo4j，就以为系统已经是“知识图谱”了。   

但真正拆开看，我们现在这套系统更像一个阶段性架构。

它不是把所有知识都直接存进图数据库，而是让不同数据库各自承担一段能力。

一句话说：MongoDB 管原文和治理过程，Milvus 管语义召回，Elasticsearch 管关键词检索，NebulaGraph 管产销品标准实体和别名关系，Redis 管缓存。

     所以当前系统最准确的定位，不是“完整业务规则知识图谱”，而是“知识库/RAG + 产销品别名图谱”。   

· · · · · · · · ·

一、每个库都在存“知识”，但存的不是同一种东西

如果只问“知识存在了哪里”，答案会很乱。

因为 MongoDB、Milvus、Elasticsearch、NebulaGraph 都和知识有关，但它们解决的问题完全不同。

MongoDB：更像知识治理主库。原始文档、文档切片、抽取字段、标签、证据链、审核状态、版本状态，主要都在这里。

Milvus：负责语义召回。用户说“摄像头怎么办理”，原文写的是“天翼云眼办理说明”，这种意思相近但字面不同的情况，靠它找回来。

Elasticsearch：负责关键词和全文检索。比如“退订”“合约期”“黑名单”“违约金”这种必须精确命中的词，靠它补足语义召回的短板。

NebulaGraph：当前主要存产销品标准实体、别名实体，以及产销品和别名之间的关系。

Redis / 关系型库：前者管缓存和临时状态，后者更多管权限、菜单、标签字典、审核流这些后台配置。

     当前这套架构的本质是：图数据库负责“认准对象”，RAG 负责“找原文内容”，大模型负责“组织答案”。   

· · · · · · · · ·

二、NebulaGraph 现在主要解决“叫法不一致”

完整业务图谱里，理论上可以有很多点和边。

产品关联活动，活动适用于客群，活动生效于地域，活动有办理渠道，活动受退订规则和互斥规则约束，FAQ 依据某条规则，新政策替代旧政策。

但从当前项目情况看，NebulaGraph 主要承担的是另一件更基础的事：产销品和别名归一。

     天翼云眼 → 别名 → 摄像头
     天翼云眼 → 别名 → 监控
     千兆宽带 → 别名 → 1000M宽带
     5G畅享套餐 → 别名 → 5G套餐   

这件事看起来不大，但对问答命中率很关键。

用户很少按标准产品名提问。图谱先把“摄像头”归一成“天翼云眼”，再去召回相关文档，命中率会明显更稳。

三、办理条件和限制规则，大多还不在图里

这也是最容易误解的地方。

系统能回答“怎么办理”“有什么限制”“能不能退订”，不代表这些规则已经都以点和边的形式存在 NebulaGraph 里。

更可能的链路是：规则还在 MongoDB 的文档切片或抽取字段里，通过 Milvus 和 Elasticsearch 被召回，再由大模型总结成答案。

     所以，NebulaGraph 现在主要不是存“办理条件、限制规则”，而是存“标准产销品和别名关系”。   

这样做有现实好处：上线快、工程复杂度低、保留原文上下文，也能降低错误关系直接入图污染全局的风险。

但它也有边界：规则不能稳定计算，冲突发现能力有限，版本治理主要依赖字段控制，图谱展示也会比较薄。

· · · · · · · · ·

四、业务标签不是图谱关系

业务标签很重要，但它不是图谱关系。

比如“营销类 → 产销品 → 宽带 → 活动方案”，这是一棵分类树，不是真正的业务知识图谱。

     标签是给知识定位；实体是知识里的对象；关系是对象之间的业务连接。   

标签可以帮助系统选择抽取模板、辅助实体分类，也可以作为过滤条件。

但如果直接把标签层级当成图谱主关系，最后建出来的不是业务图谱，而是一棵更复杂的目录树。

五、后面应该把哪些东西逐步入图？

不是所有文档内容都需要入 NebulaGraph。

优先级应该很清楚：高频、高风险、可结构化、可复用。

P0：产销品和别名。当前已经在做，解决实体归一。

P1：产品—活动关系、活动适用客户、适用地域、办理渠道、生效时间、资费优惠、互斥规则、退订变更规则。

P2：FAQ—依据规则、投诉场景—处理规则、新政策—替代旧政策。

· · · · · · · · ·

六、判断是否真落地，要问这几个问题

不要只问“你们用了 NebulaGraph 吗”。这个问题太浅。

真正要问的是：

NebulaGraph 里有哪些点类型？只有 Product、Alias，还是已经有 Activity、Rule、Region、Channel、CustomerGroup、FAQ？

有哪些边类型？只有 alias_of，还是已经有 applies_to、valid_in、available_channel、has_rule、mutex_with？

办理条件、限制规则、互斥规则现在存在哪里？是 MongoDB 字段，还是 Rule 节点/边属性？

问答答案来自图查询，还是来自 Milvus/ES 召回后由大模型总结？

每条图谱关系能不能反查 source_doc_id、source_chunk_id 和原文证据？

     如果这些问题都能答清楚，这个系统才算真正进入图谱落地阶段。否则，它可能只是一个 RAG 系统旁边接了一个图数据库。   

当前项目不是没有知识图谱，而是图谱层目前比较聚焦。

NebulaGraph 负责产销品实体和别名归一，RAG 负责从文档中召回办理条件、限制规则、FAQ、客服口径，MongoDB 负责保存原文、字段、标签、证据和审核状态。

这个阶段是合理的，但也要看清它的边界。