别再混淆CDM、本体和知识图谱

Generated by M365 CoPilot

先问自己一个问题：“我们到底要解决什么问题？” 这个简单的提问，曾经让无数场架构讨论避免滑向失控。

如果你参加过那种有人随口说“我们建个知识图谱吧”的会议，一定懂那种感觉：大家点头、兴奋，有人提到AI，有人聊API，很快三个概念被搅拌成一锅粥。

标准数据模型（CDM）、本体（Ontology）、知识图谱（Knowledge Graph）——不都是一回事吗？

差远了。但在白板会议、架构文档、供应商推销里，它们被反复混用。结果呢？困惑、过度设计，系统想一口吃成胖子，最后啥也没做好。

今天咱们不玩学术，不说理论，就用你能拿去反驳别人的方式，把这一团乱麻拆开。

“一个模型统治一切”的诱惑

---

老实说，谁不想用一个万能模型解决所有问题？CDM 规定数据交换格式，本体定义概念关系，知识图谱存实体连线——看起来可以合一。但实际一动手就发现：三个工具的目标完全不同。

• Canonical Data Model（标准数据模型）：专注于系统间的数据交换格式，保证两端能“说同一种语言”。它的核心是协议和兼容。
• Ontology（本体）：是对领域概念的共享理解，描述“什么东西存在”以及“它们之间有什么关系”。它更像一套词典和语法书。
• Knowledge Graph（知识图谱）：是具体存储实体、属性、关系的数据库，用来支持查询和推理。它是一张已经填好的地图。

混为一谈的后果是：你明明只需要接口标准化，却非要去建推理引擎；你明明要共享概念，却去纠结数据字段的单复数。架构越做越重，最后谁也说服不了谁。

回到问题本身

下次再有人问“要不要用知识图谱”，先暂停三秒，问清楚：“我们想解决数据集成问题？还是想统一业务术语？或者是需要灵活的关联查询？”

• 数据集成长什么样？一个 CDM 可能就够了。淘宝和支付宝的订单同步，不需要本体。
• 业务术语混乱？建一个本体，像微信小程序的各种分类体系一样，让各方用同一套标签对话。
• 想发现实体间的隐藏关系？知识图谱上场，类似百度百科的知识卡片。

别让“听起来酷”的词汇绑架你的架构决策。CDM、本体、知识图谱各有用处，分开用反而更清爽。

记住：没有银弹，只有明确的问题才能指引正确的工具。