——你做的项目到底是不是完整图谱做企业知识图谱最容易出现一个误会只要用了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 负责保存原文、字段、标签、证据和审核状态。这个阶段是合理的但也要看清它的边界。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
