coding-agent/GraphRAG增强版_20260920/course-source/lessons/5.3.md

5.3 企业知识图谱建模与案例数据

店长想知道缺草莓会影响什么，先要知道店里卖什么、怎样做、谁负责。建图就从这些真实问题出发，不是把资料里每个名词都画成一个点。

{{figure:03-domain|图 5-5　套餐包含蛋糕，蛋糕需要果酱，果酱需要草莓；奶昔直接需要草莓。}}

一、从食材走到顾客能买的东西

从图底部的新鲜草莓开始反向找：它用于草莓酱和草莓奶昔；果酱用于招牌蛋糕；蛋糕又被双人下午茶、周末分享套餐包含。因此本题对外售卖的受影响对象是草莓奶昔、招牌蛋糕、双人下午茶、周末分享套餐。

草莓酱是店内半成品，不单独售卖。它必须出现在解释链里，却不应该被算成第五个出售商品。这就是为什么图里还要记录对象类型。

二、分类和关系，直接用生活中的中文

图中分类标签	这一类的具体节点
食材	新鲜草莓、可可粉
半成品	草莓酱
商品	招牌蛋糕、草莓奶昔
套餐	双人下午茶、周末分享套餐
店员	小林、小周、小陈
销售位置	店内点单台、外卖菜单

图中关系名称	按箭头读一遍
需要	招牌蛋糕 → 需要 → 草莓酱
包含	双人下午茶 → 包含 → 招牌蛋糕
由谁负责	双人下午茶 → 由谁负责 → 小陈
在哪里售卖	双人下午茶 → 在哪里售卖 → 店内点单台

这些就是配套 Neo4j 中实际使用的中文标签与关系，查询时可以直接写 :商品、:需要。分类回答“它属于哪一类”，名称属性回答“具体是哪一个”。

“包含”和“需要”共同构成影响链，但它们不是同义词。通知对象也不能靠关系距离猜：小林做蛋糕，小陈负责套餐上架。店长问套餐通知谁，需要查分工原文。

三、每条边都要能回到资料

{{figure:03-evidence|图 5-6　关系上的来源编号指向配方原文，学生可以核对箭头是否有依据。}}

只有“蛋糕需要果酱”这条边，读者不知道它来自哪张配方。配套数据因此分成三个文件：corpus.jsonl 保存原文，entities.json 保存对象与别名，facts.jsonl 保存关系及来源。

下面的读取方法会拒绝引用不存在、版本不一致或跨知识域的事实：

{{snippet:schema-load}}

先确认原句真实存在，再检查它是否支持这条关系。比如“不需要草莓”不能被读成“需要草莓”；仅凭 JSON 格式正确不能保证理解正确。

四、名称会变，编号负责认出同一个东西

顾客叫“草莓”，库存表写“新鲜草莓”，可以指向同一个稳定编号。图上的属性分别叫 名称、别名、编号；名称给人阅读，编号让计算机确认“改名后还是同一个东西”。学生查询时可以先用中文名称，不必背程序编号。

知识域=甜品店 是当前小店的资料范围；另一门店使用不同范围。同名商品不一定有同样配方或负责人，查询时不能把两家店的资料混起来。这是知识域过滤；完整用户权限还需要把登录身份映射到可访问范围。

五、用巧克力饼干检验“有没有乱连”

配套饼干配方使用可可粉，不需要草莓。它也是甜品，却不能因此自动连到草莓。同一主题，不等于有同一关系。

练习：在纸上画出“草莓 → 双人下午茶”的解释链，再标出要查哪份分工表通知小陈。下一节把这些约定写成数据库约束，重复导入时仍是一份正确资料。