7.8
深览指数
科技人人都是产品经理·是AD··AI 生成
从数据库的选择与存储看知识图谱项目
文章深度拆解一个企业知识图谱的真实架构，指出常见的误区是将“用图数据库”等同于“建成知识图谱”。作者揭示了一个多数据库混合系统的分工：MongoDB 管理原文档与治理过程，Milvus 负责语义召回，Elasticsearch 支撑关键词检索，NebulaGraph 主要存储产销品标准实体与别名关系，形成“知识库/RAG + 别名图谱”的阶段性方案。文章提供了当前架构的清晰边界、未来入图优先级（P0-P2），以及判断图谱是否真落地的六个灵魂拷问。适合正在规划或建设企业知识图谱、RAG 系统，且关心架构实际落地的产品经理、技术负责人阅读。原文 ↗
核心观点
- ▍企业知识图谱的真实架构是多数据库混合系统：MongoDB 管原文和治理，Milvus 管语义召回，Elasticsearch 管关键词检索，NebulaGraph 管产销品标准实体和别名关系，Redis 管缓存。而不是所有知识都存进图数据库。
- ▍当前项目最准确的定位是“知识库/RAG + 产销品别名图谱”，而非完整的业务规则知识图谱。图数据库当前主要解决“叫法不一致”（实体归一），而非存储完整的办理条件与限制规则。
- 01NebulaGraph 当前存储的点主要是“产品”和“别名”两种类型，边主要是“alias_of”。例如“天翼云眼”有别名“摄像头”“监控”，“千兆宽带”有别名“1000M宽带”。
- 02对“怎么办理”“有什么限制”等问题的回答，其链路是规则仍存于 MongoDB 的文档切片或抽取字段中，通过 Milvus 和 ES 被召回，再由大模型总结成答案，而非图查询。
- 03文章提出了图谱落地的六个灵魂拷问，包括检查 NebulaGraph 中有点类型和边类型有哪些、办理条件存在哪里、答案来自图查询还是 Milvus/ES 召回+大模型总结等。
- 04业务标签（如“营销类→产销品→宽带→活动方案”）本质是目录树，不是图谱关系。标签用于定位知识，而非表达对象之间的业务连接。
- 05未来入图的优先级按 P0（产销品和别名）、P1（产品-活动关系、互斥规则、退订规则等）、P2（FAQ-规则关系、投诉场景等）划分。
反方 / 局限
- — 当前架构的边界在于：规则不能稳定计算，冲突发现能力有限，版本治理主要依赖字段控制，图谱展示也会比较薄。
- — 系统能回答如何办理等问题，但不代表所有规则都以点和边形式存在于图数据库中，这可能让外界误认为该项目已建成完整的业务规则图谱。
6 分钟 · 3 卡片 · 9 资料
读原文 →