实体识别与定义：核心实体的建模方法
做供应链知识图谱，第一步不是画图，而是搞清楚「有哪些东西要建模」。
我见过不少团队，一上来就堆概念，结果图谱建出来又乱又难用。说白了，实体识别就像盖房子打地基——地基歪了，后面全白搭。
一、供应商实体：不只是个名字
供应商这个实体，很多人觉得简单——不就是个公司名嘛？
我在项目中遇到过，同一个供应商在不同系统里叫法完全不一样。比如「华为技术有限公司」和「华为」，在采购系统里是两个ID，但其实是同一家。这就尴尬了。
供应商实体的核心属性：
- 唯一标识：建议用统一社会信用代码或内部编码，别用名称做主键
- 层级关系：集团→子公司→工厂，这个关系链很重要
- 资质信息：ISO认证、行业许可、环保资质等
- 绩效标签：准时交付率、质量评分、价格趋势
我的建模习惯：供应商实体一定要保留「历史名称」字段。为什么？因为企业会改名、会并购，你查历史数据时，没有这个字段就全乱套了。
二、物料实体：BOM的基石
物料实体是供应链知识图谱里最「碎」的东西。一个手机有上千个物料，每个物料还有不同版本。
你想想看，物料编码在不同部门之间经常打架。研发叫它「A001」，采购叫它「P-001」，仓库叫它「WH-001」——其实都是同一个螺丝钉。
物料实体的关键设计：
- 多编码映射：保留所有系统的物料编码，建立映射关系
- 物料分类：原材料、半成品、成品、辅料，分类要清晰
- 版本管理：工程变更（ECO）会影响物料版本，这个必须建模
- 替代关系：A物料缺货时，B物料可以替代，这是知识图谱的强项
避坑指南：我曾经在建模时忽略了「物料状态」字段，结果查到一个物料既在「试产」又在「量产」——数据直接打架。后来我强制要求每个物料必须有且只有一个状态。
三、订单实体：流动的血液
订单实体是供应链里最动态的东西。它不像供应商和物料那样相对稳定，订单是「活」的——从创建到关闭，状态一直在变。
订单实体的建模要点：
- 订单类型：采购订单、销售订单、调拨订单、退货订单
- 状态机：草稿→审批→执行→部分收货→完成→关闭
- 关联关系：一个订单对应多个物料行，每个行又有自己的状态
- 时间戳：下单时间、承诺交期、实际交期，这三个时间缺一不可
嗯，这里要注意：订单实体和物料实体之间是「多对多」关系。一个订单包含多个物料，一个物料出现在多个订单里。这个关系在知识图谱里用边来表示，比关系数据库灵活得多。
四、仓库实体：物理世界的映射
仓库实体看起来简单——不就是个地点吗？但实际建模时，坑不少。
仓库实体的层级结构：
| 层级 | 示例 | 说明 |
|---|---|---|
| 仓库 | 上海松江仓 | 物理仓库，有地址和负责人 |
| 库区 | 常温区、冷藏区 | 按存储条件划分 |
| 库位 | A-01-02-03 | 具体存放位置，精确到货架 |
我个人习惯把仓库实体拆成三层：仓库→库区→库位。这样粒度够细，又不会太碎。你想想看，如果只建模到仓库级别，那「物料在哪个货架上」这种问题就永远答不出来。
注意：仓库和物料之间是「库存」关系。库存是有属性的——批次号、生产日期、入库时间。这些属性不能挂在物料上，也不能挂在仓库上，必须挂在「库存」这个关系上。
五、运输路线实体：连接节点的血管
运输路线是供应链里最容易被忽视的实体。很多人觉得「不就是A到B嘛」，但实际没那么简单。
运输路线的核心要素：
- 起点和终点：可以是仓库、供应商、客户、港口
- 运输方式：公路、铁路、海运、空运、多式联运
- 时效信息：标准运输时间、波动范围、季节性影响
- 成本模型：固定成本+变动成本，不同路线差异很大
我在项目中遇到过，两条路线看起来都是从上海到深圳，但一条走陆运，一条走海运，时效差了3天。如果不把「运输方式」作为路线实体的属性，那查询结果就完全不准。
六、实体间的关系建模
实体定义好了，接下来就是「连线」。知识图谱的核心优势就在这里——关系比属性更重要。
核心关系列表：
- 供应商→物料：供应关系，包含价格、最小起订量、交期
- 物料→仓库：库存关系，包含数量、批次、库位
- 订单→物料：订单行关系，包含数量、单价、交期
- 订单→供应商：采购关系，包含合同条款、付款条件
- 仓库→运输路线：配送关系，包含频次、承运商
我的经验：关系也可以有属性。比如「供应商→物料」这个关系，可以带上「最近一次采购价格」「历史交付准时率」等属性。这样查询时就不用绕到别的实体去拿数据了。
七、知识图谱结构总览
下面这张图，是我自己画的核心实体关系图。你看一眼，就能明白整个供应链知识图谱的骨架长什么样。
这张图里，五个核心实体通过不同的关系连接起来。你仔细看，每个关系都有方向——供应商「供应」物料，但物料不会「供应」供应商。方向性在知识图谱里很重要，它决定了查询的路径。
八、建模时的常见坑
最后，我总结几个自己踩过的坑，你建模时注意避开：
- 实体粒度不一致：有的实体很粗（比如「供应商」只到公司级），有的很细（比如「物料」到SKU级），查询时匹配不上。建议统一粒度标准。
- 忽略时间维度：供应商的资质会过期，物料的价格会变动，订单的状态会流转。没有时间戳的实体，查历史数据时就是一团浆糊。
- 关系冗余：同一个关系在多个实体里重复存储。比如「供应商地址」既挂在供应商实体上，又挂在订单实体上。改一个地方，另一个就不同步了。
- 过度建模：把所有东西都变成实体。比如「颜色」「尺寸」这种属性，没必要单独建实体，除非它们本身有复杂的层级关系。
我的建议：刚开始建模时，先做「最小可行图谱」。只保留最核心的5-7个实体，把关系理清楚。跑通一个查询场景后，再逐步扩展。别想着一步到位，那只会让你陷入细节的泥潭。
好了，实体识别和定义这部分就聊到这儿。记住一句话：实体是骨架，关系是血肉。骨架搭好了，后面的工作才能顺起来。